7 ms·

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

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)

devwastaken 4y ago
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.
- MSFT_Edging 4y ago
  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.
- fragmede 4y ago
  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.
- gregmac 4y ago
  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.
- briHass 4y ago
  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.
- tony-allan 4y ago
  It’s a microcontroller and not meant to run to run an OS. Single program and a couple of MB of ram and flash.
- regularfry 4y ago
  The equivalent in the pi ecosystem is the Pico, not the pi zero.
farkanoid 4y ago
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.
- girvo 4y ago
  You can use TX/RX for other things but it’s a whole pain and you have to turn off basically all serial output
- DannyBee 4y ago
  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".
hacker_junky 4y ago
[flagged]
- DannyBee 4y ago
  I agree. This article seemed like person who wanted to pick something up and make something and just have it work. The ESP is often a good series for that. It is widely used and well tested. Cubecell is great for very low power. But it took more work to get it working. The scale of use is clearly lower so I ran into bugs at the time that I'm sure are worked out by now. The result was great mind you. I built a remote controller for some things and it will easily last 10 years on a simple 1/2 as cell. nrf is definitely more featured and thoroughly tested then either. But the startup can be harder to do depending on what you do (ie running zephyr on it)
  - dotancohen 4y ago
    I think that you replied to a ChatGPT frontend bot.
mkesper 4y ago
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.
- DannyBee 4y ago
  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.
  - mplewis 4y ago
    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.
    - waste_monk 4y ago
      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.

devwastaken 4y ago

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.

MSFT_Edging 4y ago
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.
fragmede 4y ago
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.
gregmac 4y ago
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.
briHass 4y ago
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.
tony-allan 4y ago
It’s a microcontroller and not meant to run to run an OS. Single program and a couple of MB of ram and flash.
regularfry 4y ago
The equivalent in the pi ecosystem is the Pico, not the pi zero.

farkanoid 4y ago

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.

girvo 4y ago
You can use TX/RX for other things but it’s a whole pain and you have to turn off basically all serial output
DannyBee 4y ago
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".

hacker_junky 4y ago

[flagged]

DannyBee 4y ago
I agree. This article seemed like person who wanted to pick something up and make something and just have it work. The ESP is often a good series for that. It is widely used and well tested. Cubecell is great for very low power. But it took more work to get it working. The scale of use is clearly lower so I ran into bugs at the time that I'm sure are worked out by now. The result was great mind you. I built a remote controller for some things and it will easily last 10 years on a simple 1/2 as cell. nrf is definitely more featured and thoroughly tested then either. But the startup can be harder to do depending on what you do (ie running zephyr on it)
- dotancohen 4y ago
  I think that you replied to a ChatGPT frontend bot.

mkesper 4y ago

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.

DannyBee 4y ago
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.
- mplewis 4y ago
  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.
  - waste_monk 4y ago
    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.