Comment by DannyBee | Hacker News Reader

Comment by DannyBee | Hacker News Reader

ESP32 is nice in that a lot of things you might have to fiddle with elsewhere just work. They have a good ecosystem that they've spent time on. So things like auto-reconnecting wifi just works (it's been ported from ESP32 elsewhere but is a bit hit or miss). Same with bluetooth and OTA upgrades, and you name it.

Especially coming from some other board types, it was like "oh i guess that just worked the first time" for a lot of things.

I have a bunch of ESP32-S3's locked in some woodworking machine cabinets (they are used to monitor the machines for dust collection control/failure/etc.). It's trivial to make them do firmware reprogramming over bluetooth. You could do over wifi too, but in my case, the machines are too RF noisy (VFD's, etc) and enclosed to make it work. bluetooth only works because i'm like 2 feet away, but it works and i don't have to open the cabinet to update the programming.

I also use one to broadcast a stupid bluetooth beacon that my garage door opener uses for "UL compliance" - It has bluetooth lights, and it won't let you open/close the door remotely unless it detects them, because UL requires they visually signal the open/close when done over wifi. Which again, just works. I never had that experience outside of the nRF52/nRF53 series

There are some good low-power boards with the S3's, though it can be hit or miss (IE assuming you really want the 20ua deep sleep to be ~20ua).

If you want something like a remote running off a small battery for 10 years, you may be better off with the heltec cubecell's or something. (They really easily get 3.5ua in sleep)

I honestly had a hard time getting started with ESP32-C3 (my first ESP device). Admittedly all of it was my fault, I got too cocky and assumed things based on previous work with competing devices that I shouldn't have.

Once up and running they really are quite pleasant to use, and pretty damn cheap.

The issues that hurt me the most were:

1/ It doesn't come preloaded with 'AT' firmware, it took me a while to figure this out as well as a PCB respin.

2/ The clearly labelled TX and RX pins are for flashing and debug output only, not for communication with an an external microcontroller. Two to four GPIO pins (decided by the AT firmware) are used for communication in 'AT' mode

3/ Two GPIO pins need to be asserted high and low on startup to enter flash mode. This fine when you figure it out, however the flash tool still tries to upload the firmware and 'fails successfully' with the correct upload delay.

You can use TX/RX for other things but it’s a whole pain and you have to turn off basically all serial output

The C3 is very new. It's the risc-v series they just started. I'm not surprised at hitting these. It is still in the "early adoption" time frame.

The MVP they use does not always include "as good as our other parts are now".

Coming from the rpi platform one thing I miss is there's no standard UI configurator or desktop OS. For wifi credentials or cloud authentication and such it ends up getting programmed in, or you have to build a UI yourself that is specific. But if it doesn't include all the amenities an OS would have like mouse/keyboard, USB file transfer, corporate wifi setup, etc - it's not useable for environments where IT has to co figure it.

I feel like the modern world of embedded hobbyist computing has really obscured the embedded aspect. This is good for getting people going but terrible for newcomers understanding the difference between a tiny personal computer with IO(raspberry pi) and baremetal/rtos devices that range in various levels of compatibility.

When I read this, at first I thought "well DUH it doesn't have a desktop OS or various desktop utilities built in, its a microcontroller!"

Then I realized for a lot of people now, their first led blink "hello world" was possibly not on a microcontroller at all. To me, the idea of wanting a mouse and keyboard for a microcontroller to set up wifi seems silly, but to others, they just haven't experienced the alternative.

There is great support for various wifi security standards for the ESP though, you just need to create something equivalent to how a chromecast connects to the internet for the first time. bootstrap an AP, connect to a portal, configure on the portal, reboot and connect to the actual AP.

I must be reading your comment wrong, because it sounds like your IT department can't handle devices without a mouse and keyboard, which means they don't use any networking switches or access points. Or badge readers. IT departments can handle it just fine if required to, they just don't want to have to.

OTA upgrades are quite useful.

What use case prompts you to making this statement?

It's not a general purpose PC with I/O tacked on, like a Pi is, but more like the reverse: I/O and a wifi/bluetooth chip that also has a small (but powerful) processor.

Depending on what you want to actually build, another option is ESPHome coupled with the Home Assistant ecosystem or standalone with MQTT. Most of the sensors, displays, etc. you'd want to interface with are supported, and everything is some simple YAML config. If you need more flexibility, it supports 'lambdas' which are snippits of any arbitrary C++ code you want, or you can write custom components in C++.

The big benefit to ESPHome is it handles all the 'boring' stuff like Wifi updates, timers, and API/MQTT glue code. I still write one-off stuff in PlatformIO, but most of my devices are running ESPHome with some custom code added on, because I don't feel like reinventing the wheel.

It’s a microcontroller and not meant to run to run an OS.

Single program and a couple of MB of ram and flash.

The equivalent in the pi ecosystem is the Pico, not the pi zero.

I bet the line of sight check is so you don't accidentally crush children or animals in your garage door while closing. So I don't think it's that stupid.

No you are misunderstanding. It's not the line of sight sensors that are Bluetooth (that would be highly dangerous), its just a light.

When you have an overhead opener the light is built in, and hard wired. It blinks when the door is triggered remotely.

When you have a side mount (jack mount) opener, there is no light built in. They give you a Bluetooth light, meant to be mounted on the ceiling like you would have in an overhead opener.

The light is only required when the door is opened over wifi. All keypads (which are RF as well) and remotes work regardless. It is only wifi opening.

This is not a useful safety device. Either it should be required and trigger regardless of how the door is opened (so that I know that it means door is about to move) or not be required at all. Having it required and triggering only some of the time the door opens is not something dependable or useful.

This safety device is useful because other methods of closing the garage door require physical proximity, i.e. the wired button, the remote in your car. These operators are necessarily close enough to the door to see if it is clear.

But if you close the garage door over wifi, the user closing the door could be anywhere. This user may not be able to see the door or warn people nearby that it is closing.

I own a Tailwind device which implements this safety feature.

But it would cost nothing to also have the light activate on all occasions when the door is actuated. Someone who is hard of hearing may be physically present but unaware that the door is being operated.

It seems strange to not at least have the option to choose if you want the light to operate in such cases. The manufacturers have gone out of their way to reduce safety.

Err, no. The buttons are not wired anymore. All buttons are battery powered remotes, even wall pads. This is how it's done now - the manufacturer does not ship any hardwired buttons for these models (Genie 6170)

Not sure why everyone keeps making assertions about the setup instead of asking questions. First claims that it's a line of sight safety device (which is wrong), now weird claims about physical proximity (which are also wrong).

Zero of the manufacturer shipped mechanisms to open or close these require physical proximity. Someone can open the door while i am in there using the remote, etc. It works fine from 300 feet away, and in fact, it's quite common for it to be opened or closed while someone is 150ft away at the bottom of the driveway.

We also had a wall pad in the house that triggers the garage, also (it's no longer needed but we started with one).

Wifi is no better or worse here - So i still maintain having a device that does not trigger all the time, despite lack of physical proximity, but instead based on whether it's FSK or wifi, is confusing and pointless

It's also more unsafe.

Reply on news.ycombinator.com