11 ms·

I often end up giving the opposite unpopular opinion: RPis are overkill for a lot of DIY IoT uses. Want to have something that opens your curtains or flashes so

by nippoo 4y ago

I often end up giving the opposite unpopular opinion: RPis are overkill for a lot of DIY IoT uses. Want to have something that opens your curtains or flashes some RGB lights in your hallway or whatever? Pick yourself up an Arduino / ESP32 with built-in WiFi, often an Ethernet port, tons of GPIO. It consumes milliwatts of power, boots in under a second, and is cheap enough to be disposable.

dale_glass 4y ago
And most importantly, it doesn't have an OS that provides next to no benefit for many of those tasks, and suffers from inconsistent timing. Something like ESP32 is much more reliable at controlling hardware. It will never miss on a triggered limit switch in time because memory ran out for some reason and it started swapping.
- blacksmith_tb 4y ago
  Ah, that kind of timing. I have made several kinds of clocks with RPis, one that ran fine for years driving a little servo to strike an hourly chime like a grandfather clock, which was all very easy thanks to having an OS with NTP and cron. But I mostly agree with the article, I have a Gigabyte Brix fanless NUC-alike as my real home server, and a couple of Pis doing little things (and switched to 'overlay file system' so running only from memory and not writing to those frail SD cards).
  - bschwindHN 4y ago
    > very easy thanks to having an OS with NTP and cron. An ESP32 can still have both of those things in some capacity. https://randomnerdtutorials.com/esp32-ntp-client-date-time-arduino-ide/ https://randomnerdtutorials.com/esp32-ntp-client-date-time-a... https://github.com/DavidMora/esp_cron https://github.com/DavidMora/esp_cron
    - cinntaile 4y ago
      The point the GP made was that timing issues weren't a real problem on the rpi thanks to the tools mentioned.
      - monocasa 4y ago
        That's not the kind of timing the original point was talking about AFAICT. Real time response is the issue with regular Linux, not vaguely accurate wall time.
      - dale_glass 4y ago
        There are different kinds of timing issues. There's knowing the time, which you can do with something like NTP. That the RPI can manage just fine. And there's acting with precise timing, eg, if you need to control a mechanism and reliably react on a deadline of a few ms. A RPI doesn't perform well there, which is why 3D printers use microcontrollers instead.
        ahepp 4y ago
        A few ms? In my experience that seems well within the capabilities of Linux. I guess last time I measured wasn't on a Raspberry Pi. I'm kinda tempted to take a shot at profiling this and writing up a blog post since it seems like a useful topic, although it will probably be a few months until I can get around to it.
        josefx 4y ago
        Being within the capabilities of something and guaranteeing that it will never exceed that are two different things. At least in the past real time guarantees for Linux came as part of an optional patch set for the kernel since guaranteeing that an algorithm would complete within a set time frame or that things like priority inversion issues would be handled correctly came with a performance cost.
        petsfed 4y ago
        I think milliseconds overestimates by a few orders of magnitude, but non-real-time OSs really suffer for the intermediate IO stuff you expect in an embedded project (e.g. SPI, I2C, etc) A long time ago, I was playing with Project Nerves on an Orange Pi running some flavor of debian. I was doing some I2C transaction (at 400 kHz, each bit is single-digit microseconds), and I ultimately had to have a re-attempt loop because the transaction would fail so often. I found a failure cutoff of 5 attempts was sufficient to keep going. I don't recall the failure rate, but basically, whenever a transaction failed, I'd have to reattempt 2-3 times before it eventually succeeded. Meanwhile, on a bog-standard Arduino with an ATMega328P, I send the I2C traffic once, and unless the circuit is physically damaged, the transaction will succeed.
gaudat 4y ago
Shhhh stop spilling our secret to the software people... The semiconductor shortage is bad enough already... That said though, programming embedded devices like Arduino and ESP32 needs a completely different style of thinking than with high level languages or web stuff. Things like MicroPython reduces the friction just a bit to make it easy enough to get on board.
- steve_adams_86 4y ago
  The thing that tripped me up the most was concurrent tasks. In languages like Go or JavaScript it’s pretty easy to figure out how to decrement a timer or wait until x time to perform a task without having the waiting period be blocking. On an arduino, you have a few options but none of them are likely to be familiar to high level software devs. It isn’t rocket science, but there are loads of little details like that which will make you pause and then write loads of bugs and awful software before you finally figure it out. Meanwhile, accomplishing the same thing with a high level language might be trivial. It can be discouraging but I’ve come to love it. You learn a lot, and having a physical board doing a tangible thing with actuators and sensors can be really gratifying.
  - nicky0 4y ago
    Not having high-level languages available is a big part of the fun of programming microcontrollers.
    - steve_adams_86 4y ago
      I completely agree. It brings you back to more fundamental aspects of problem solving that sometimes you miss with higher level programming. There are a lot of things I can do on a modern web server with a language like Go that are pretty cool, but not particularly interesting because it's kind of trivial. There are so many resources available to the program, things to fall back on for resilience, plenty of common problems are ironed out into popular libraries, etc. Trying to automate something truly reliable and consistently with a microcontroller on the other hand can be simultaneously soul crushing and exciting — there are so many edge cases and challenging problems. Sometimes I'll spend hours trying to figure out how to interface with a single sensor, and while it isn't important or impressive in the scheme of things, I really enjoy it.
PaulBGD_ 4y ago
Even in the Raspberry ecosystem you can easily pick up a Pico, which offers all of that.
- ahepp 4y ago
  I prefer the Pico to the ESP32. I'm very impressed with the quality and organization of the Pico SDK and documentation. Although I have heard the Pico is not very competitive in terms of power optimization. I haven't done many battery powered projects to encounter these issues though.
tstack 4y ago
Yes. I followed a tutorial for building a doorbell that uses an ESP32 to send a notification to our phones when the button is pushed. I haven’t touched it since installation and I’m always a bit amazed it still works. An RPi would’ve been overkill.
gravitronic 4y ago
I don't see it mentioned in the thread, so I'll link to ESPHome. It is an incredible platform when you just want to read some sensors or put some relays or switches onto the network, integrates with Home Assistant. One of the most enjoyable firmware installation procedures I've ever encountered. https://esphome.io https://esphome.io Most of the use cases I've seen have them report to Home Assistant or something similar, but I think some people use them directly without a host.
cmrdporcupine 4y ago
Even easier, in a way... a Parallax Propeller and program in SPIN (their proprietary structured BASIC-like language), or C++ etc. Exotic, but simpler mental model for most people. 8 independent cores and a simple non-interrupt driven programming model for doing basic timing and I/O with any of the 32 pins configurable for either input or output. And super easy to interface both 3v and 5v, available in DIP, and in various easy format boards.
DeathArrow 4y ago
ESP32-C3 is cool if you want to play with RISC-V for cheap.
ahepp 4y ago
I can't really disagree with what you're saying about Pis often being overkill, but I've been using Raspberry Pi Zero Ws for more projects where I might have used ESP32s, and I've been very happy with the choice. Basically any project I have that isn't battery powered or timing critical, I'd prefer to use a Pi. Zero Ws have a $10 MSRP (of course, huge shortage at the moment). I think they're pretty cost competitive for DIY IoT. Buildroot makes it really easy to create a custom Linux OS with your software preinstalled, any kind of custom kernel tweaks you want, and an impressive amount of software packages available. If you strip unneeded functionality from your kernel you can boot a lot faster too. Here's a list of some stuff I like about a Pi Zero W vs an ESP32 * Ease of programming. Flash an SD card and swap it out, without having to hook the device up to a programmer. * Extremely solid TCP/IP stack. * Multitasking with real process isolation. * Program organization (related to above). I find the OS abstraction very useful for enforcing cleaner designs. * Access to Linux software packages. I can easily add nginx, apache, or lighttpd to my rootfs. It doesn't involve mangling any of my other software packages * Interactive access. I can debug the applications by sshing into the Pi and looking at logs. I can scp new files onto the Pi.
- arbuge 4y ago
  "huge shortage at the moment" AFAIK this "at the moment" period has now extended all the way from the time they were introduced to the present day. One long moment for sure.
  - ahepp 4y ago
    My recollection is shit really hit the fan after the pandemic? It looks like the Zero W was released in 2017. I remember up until the last couple years, you could at least get one per order from Adafruit/Sparkfun at MSRP. I think there may have even been a time when you could get like, 10 per order or something?
dheera 4y ago
> Want to have something that opens your curtains or flashes some RGB lights in your hallway or whatever? Pick yourself up an Arduino / ESP32 The reason I'd go for an ESP32 for this use case isn't because RPis are overkill, but rather because it's much easier to write, compile, flash, and run code on bare metal on an ESP32 that has access to Bluetooth and Wi-Fi but isn't vulnerable to file system corruption. You can do this on an RPi, it's just much harder.
adql 4y ago
Well, it is right-sized to run a hub controlling all that little devices. But yeah, especially now with various ESP32 firmwares like ESPHome you can essentially just make a YAML with specification on where to listen and what bit to flip and get simple switch/controller with zero actual coding. There is even custom firmware to turn off-the-shelf IOT devices to work with "open" standards.
MrFoof 4y ago
Strongly agree here. Local SD storage IO aside, a Pi 4B 8GB is basically on par with a high end desktop I had in the mid-2000s. That’s an insane amount of compute on something that can be sub-2W over POE, or 1.3W on WiFi. Though for all the homelabbers out there, you probably have a NAS. Use Log2RAM, and present some ISCSI volumes to the Pi, and you’d be staggered with the very real work a Pi can do when not saddled by the SD card - without having to directly attach storage. - - I’d argue that for “IoT” stuff even Arduinos are overkill in terms of computing power. Granted, I realize this is the case functionally because of BOM optimization and making it forgiving (more power than needed) for beginners. - - Granted, going back to the original article: Yes, 1L form factors are nuts. Mac Minis are insane (but not cheap), and if you look at 35W Zen 3 Ryzen 7 PROs you can get similarly insane power cheaper if you need x86. But all the much older former office 1Ls are everywhere and offer ludicrous performance to hobbyists for pennies on the dollar, with (as mentioned by the article) sub-10W idle. - - Honestly, it’s just a great time to be a tinkerer. We’re drowning in ubiquitous, cheap compute.
- hammyhavoc 4y ago
  Distro/stack recommendations for a Pi? Intrigued by your usage with Log2RAM and ISCSI volumes!
  - MrFoof 4y ago
    Personally I've standardized on "DietPi" which is functionally a super-stripped down Debian.
paxys 4y ago
This combined with the main article shows the exact reason why Raspberry Pi is as popular as it is. When I'm starting a new project I can either worry about Arduino or ESP32 or other microcontrollers or various NUCs or getting a board fabricated from scratch...or I can grab a RPi from the drawer and know that it will just work, regardless of whether I need to toggle some RGB lights, browse the web, or run a Kubernetes cluster. There is nothing else out there that hits the sweet spot in between price, power consumption, processing speed, extensibility, software compatibility, out-of-box experience and lots more.
- repomies69 4y ago
  It is the software compability. Things working out of the box, without hassle. Almost nothing beats that. Almost everything is secondary.
  - sokoloff 4y ago
    I find the lifetime effort of an AVR/ESP8266/ESP32 to be lower than a Pi. I’ve had AVRs (of mine) running in the house for 9+ years without being touched (and ESPs for over 5). Things do just work out of the box on them (often easier than installing Raspian, getting it onto wifi, setting up ssh, looking up the commands to set a GPIO, figuring out cron, rc.d, etc.) It’s way faster IME to just use the Arduino digital_write() functionality in setup and loop. (I’m a long-time c/c++ programmer, which helps a bit.) The exploitable footprint is way lower, so you pretty much never need to do a security patch. If the power fails, you’ll never* end with a bad volume; it just boots back from flash and resumes working.
    - ahepp 4y ago
      There's a lot of stuff you can do to Linux on the Pi to make it have some of the nice qualities you're describing. I've set up my Buildroot project to copy "authorized_keys" and "wpa_supplicant.conf" from the fat32 formatted boot partition to their normal locations. So I flash an SD card, drag and drop the files onto the SD card, plug it in the Pi and SSH right in. With regards to filesystem corruption on power failure, you can mount the root filesystem as read-only. If you need to write to files you could mount a tmpfs volatile filesystem.
brabel 4y ago
I've been playing with home automation and I agree. This guy is creating a mini AWS at his place while I am using a small Pi to run my Lua server[1] that takes less than 2MB of RAM and can run even on a microcontroller.... if anything the Pi is totally overkill already, but it's nice to be on GNU/Linux and have access to so many utilities, even a browser. [1] https://realtimelogic.com/ba/doc/ https://realtimelogic.com/ba/doc/
deleted 4y ago
[deleted]

by nippoo 4y ago

dale_glass 4y ago

And most importantly, it doesn't have an OS that provides next to no benefit for many of those tasks, and suffers from inconsistent timing. Something like ESP32 is much more reliable at controlling hardware. It will never miss on a triggered limit switch in time because memory ran out for some reason and it started swapping.

blacksmith_tb 4y ago
Ah, that kind of timing. I have made several kinds of clocks with RPis, one that ran fine for years driving a little servo to strike an hourly chime like a grandfather clock, which was all very easy thanks to having an OS with NTP and cron. But I mostly agree with the article, I have a Gigabyte Brix fanless NUC-alike as my real home server, and a couple of Pis doing little things (and switched to 'overlay file system' so running only from memory and not writing to those frail SD cards).
- bschwindHN 4y ago
  > very easy thanks to having an OS with NTP and cron. An ESP32 can still have both of those things in some capacity. https://randomnerdtutorials.com/esp32-ntp-client-date-time-arduino-ide/ https://randomnerdtutorials.com/esp32-ntp-client-date-time-a... https://github.com/DavidMora/esp_cron https://github.com/DavidMora/esp_cron
  - cinntaile 4y ago
    The point the GP made was that timing issues weren't a real problem on the rpi thanks to the tools mentioned.
    - monocasa 4y ago
      That's not the kind of timing the original point was talking about AFAICT. Real time response is the issue with regular Linux, not vaguely accurate wall time.
    - dale_glass 4y ago
      There are different kinds of timing issues. There's knowing the time, which you can do with something like NTP. That the RPI can manage just fine. And there's acting with precise timing, eg, if you need to control a mechanism and reliably react on a deadline of a few ms. A RPI doesn't perform well there, which is why 3D printers use microcontrollers instead.
      - ahepp 4y ago
        A few ms? In my experience that seems well within the capabilities of Linux. I guess last time I measured wasn't on a Raspberry Pi. I'm kinda tempted to take a shot at profiling this and writing up a blog post since it seems like a useful topic, although it will probably be a few months until I can get around to it.
        josefx 4y ago
        Being within the capabilities of something and guaranteeing that it will never exceed that are two different things. At least in the past real time guarantees for Linux came as part of an optional patch set for the kernel since guaranteeing that an algorithm would complete within a set time frame or that things like priority inversion issues would be handled correctly came with a performance cost.
        petsfed 4y ago
        I think milliseconds overestimates by a few orders of magnitude, but non-real-time OSs really suffer for the intermediate IO stuff you expect in an embedded project (e.g. SPI, I2C, etc) A long time ago, I was playing with Project Nerves on an Orange Pi running some flavor of debian. I was doing some I2C transaction (at 400 kHz, each bit is single-digit microseconds), and I ultimately had to have a re-attempt loop because the transaction would fail so often. I found a failure cutoff of 5 attempts was sufficient to keep going. I don't recall the failure rate, but basically, whenever a transaction failed, I'd have to reattempt 2-3 times before it eventually succeeded. Meanwhile, on a bog-standard Arduino with an ATMega328P, I send the I2C traffic once, and unless the circuit is physically damaged, the transaction will succeed.

gaudat 4y ago

Shhhh stop spilling our secret to the software people... The semiconductor shortage is bad enough already... That said though, programming embedded devices like Arduino and ESP32 needs a completely different style of thinking than with high level languages or web stuff. Things like MicroPython reduces the friction just a bit to make it easy enough to get on board.

steve_adams_86 4y ago
The thing that tripped me up the most was concurrent tasks. In languages like Go or JavaScript it’s pretty easy to figure out how to decrement a timer or wait until x time to perform a task without having the waiting period be blocking. On an arduino, you have a few options but none of them are likely to be familiar to high level software devs. It isn’t rocket science, but there are loads of little details like that which will make you pause and then write loads of bugs and awful software before you finally figure it out. Meanwhile, accomplishing the same thing with a high level language might be trivial. It can be discouraging but I’ve come to love it. You learn a lot, and having a physical board doing a tangible thing with actuators and sensors can be really gratifying.
- nicky0 4y ago
  Not having high-level languages available is a big part of the fun of programming microcontrollers.
  - steve_adams_86 4y ago
    I completely agree. It brings you back to more fundamental aspects of problem solving that sometimes you miss with higher level programming. There are a lot of things I can do on a modern web server with a language like Go that are pretty cool, but not particularly interesting because it's kind of trivial. There are so many resources available to the program, things to fall back on for resilience, plenty of common problems are ironed out into popular libraries, etc. Trying to automate something truly reliable and consistently with a microcontroller on the other hand can be simultaneously soul crushing and exciting — there are so many edge cases and challenging problems. Sometimes I'll spend hours trying to figure out how to interface with a single sensor, and while it isn't important or impressive in the scheme of things, I really enjoy it.

PaulBGD_ 4y ago

Even in the Raspberry ecosystem you can easily pick up a Pico, which offers all of that.

ahepp 4y ago
I prefer the Pico to the ESP32. I'm very impressed with the quality and organization of the Pico SDK and documentation. Although I have heard the Pico is not very competitive in terms of power optimization. I haven't done many battery powered projects to encounter these issues though.

tstack 4y ago

Yes. I followed a tutorial for building a doorbell that uses an ESP32 to send a notification to our phones when the button is pushed. I haven’t touched it since installation and I’m always a bit amazed it still works. An RPi would’ve been overkill.

gravitronic 4y ago

I don't see it mentioned in the thread, so I'll link to ESPHome. It is an incredible platform when you just want to read some sensors or put some relays or switches onto the network, integrates with Home Assistant. One of the most enjoyable firmware installation procedures I've ever encountered. https://esphome.io https://esphome.io Most of the use cases I've seen have them report to Home Assistant or something similar, but I think some people use them directly without a host.

cmrdporcupine 4y ago

Even easier, in a way... a Parallax Propeller and program in SPIN (their proprietary structured BASIC-like language), or C++ etc. Exotic, but simpler mental model for most people. 8 independent cores and a simple non-interrupt driven programming model for doing basic timing and I/O with any of the 32 pins configurable for either input or output. And super easy to interface both 3v and 5v, available in DIP, and in various easy format boards.

DeathArrow 4y ago

ESP32-C3 is cool if you want to play with RISC-V for cheap.

ahepp 4y ago

I can't really disagree with what you're saying about Pis often being overkill, but I've been using Raspberry Pi Zero Ws for more projects where I might have used ESP32s, and I've been very happy with the choice. Basically any project I have that isn't battery powered or timing critical, I'd prefer to use a Pi. Zero Ws have a $10 MSRP (of course, huge shortage at the moment). I think they're pretty cost competitive for DIY IoT. Buildroot makes it really easy to create a custom Linux OS with your software preinstalled, any kind of custom kernel tweaks you want, and an impressive amount of software packages available. If you strip unneeded functionality from your kernel you can boot a lot faster too. Here's a list of some stuff I like about a Pi Zero W vs an ESP32 * Ease of programming. Flash an SD card and swap it out, without having to hook the device up to a programmer. * Extremely solid TCP/IP stack. * Multitasking with real process isolation. * Program organization (related to above). I find the OS abstraction very useful for enforcing cleaner designs. * Access to Linux software packages. I can easily add nginx, apache, or lighttpd to my rootfs. It doesn't involve mangling any of my other software packages * Interactive access. I can debug the applications by sshing into the Pi and looking at logs. I can scp new files onto the Pi.

arbuge 4y ago
"huge shortage at the moment" AFAIK this "at the moment" period has now extended all the way from the time they were introduced to the present day. One long moment for sure.
- ahepp 4y ago
  My recollection is shit really hit the fan after the pandemic? It looks like the Zero W was released in 2017. I remember up until the last couple years, you could at least get one per order from Adafruit/Sparkfun at MSRP. I think there may have even been a time when you could get like, 10 per order or something?

dheera 4y ago

> Want to have something that opens your curtains or flashes some RGB lights in your hallway or whatever? Pick yourself up an Arduino / ESP32 The reason I'd go for an ESP32 for this use case isn't because RPis are overkill, but rather because it's much easier to write, compile, flash, and run code on bare metal on an ESP32 that has access to Bluetooth and Wi-Fi but isn't vulnerable to file system corruption. You can do this on an RPi, it's just much harder.

adql 4y ago

Well, it is right-sized to run a hub controlling all that little devices. But yeah, especially now with various ESP32 firmwares like ESPHome you can essentially just make a YAML with specification on where to listen and what bit to flip and get simple switch/controller with zero actual coding. There is even custom firmware to turn off-the-shelf IOT devices to work with "open" standards.

MrFoof 4y ago

Strongly agree here. Local SD storage IO aside, a Pi 4B 8GB is basically on par with a high end desktop I had in the mid-2000s. That’s an insane amount of compute on something that can be sub-2W over POE, or 1.3W on WiFi. Though for all the homelabbers out there, you probably have a NAS. Use Log2RAM, and present some ISCSI volumes to the Pi, and you’d be staggered with the very real work a Pi can do when not saddled by the SD card - without having to directly attach storage. - - I’d argue that for “IoT” stuff even Arduinos are overkill in terms of computing power. Granted, I realize this is the case functionally because of BOM optimization and making it forgiving (more power than needed) for beginners. - - Granted, going back to the original article: Yes, 1L form factors are nuts. Mac Minis are insane (but not cheap), and if you look at 35W Zen 3 Ryzen 7 PROs you can get similarly insane power cheaper if you need x86. But all the much older former office 1Ls are everywhere and offer ludicrous performance to hobbyists for pennies on the dollar, with (as mentioned by the article) sub-10W idle. - - Honestly, it’s just a great time to be a tinkerer. We’re drowning in ubiquitous, cheap compute.

hammyhavoc 4y ago
Distro/stack recommendations for a Pi? Intrigued by your usage with Log2RAM and ISCSI volumes!
- MrFoof 4y ago
  Personally I've standardized on "DietPi" which is functionally a super-stripped down Debian.

paxys 4y ago

This combined with the main article shows the exact reason why Raspberry Pi is as popular as it is. When I'm starting a new project I can either worry about Arduino or ESP32 or other microcontrollers or various NUCs or getting a board fabricated from scratch...or I can grab a RPi from the drawer and know that it will just work, regardless of whether I need to toggle some RGB lights, browse the web, or run a Kubernetes cluster. There is nothing else out there that hits the sweet spot in between price, power consumption, processing speed, extensibility, software compatibility, out-of-box experience and lots more.

repomies69 4y ago
It is the software compability. Things working out of the box, without hassle. Almost nothing beats that. Almost everything is secondary.
- sokoloff 4y ago
  I find the lifetime effort of an AVR/ESP8266/ESP32 to be lower than a Pi. I’ve had AVRs (of mine) running in the house for 9+ years without being touched (and ESPs for over 5). Things do just work out of the box on them (often easier than installing Raspian, getting it onto wifi, setting up ssh, looking up the commands to set a GPIO, figuring out cron, rc.d, etc.) It’s way faster IME to just use the Arduino digital_write() functionality in setup and loop. (I’m a long-time c/c++ programmer, which helps a bit.) The exploitable footprint is way lower, so you pretty much never need to do a security patch. If the power fails, you’ll never* end with a bad volume; it just boots back from flash and resumes working.
  - ahepp 4y ago
    There's a lot of stuff you can do to Linux on the Pi to make it have some of the nice qualities you're describing. I've set up my Buildroot project to copy "authorized_keys" and "wpa_supplicant.conf" from the fat32 formatted boot partition to their normal locations. So I flash an SD card, drag and drop the files onto the SD card, plug it in the Pi and SSH right in. With regards to filesystem corruption on power failure, you can mount the root filesystem as read-only. If you need to write to files you could mount a tmpfs volatile filesystem.

brabel 4y ago

I've been playing with home automation and I agree. This guy is creating a mini AWS at his place while I am using a small Pi to run my Lua server[1] that takes less than 2MB of RAM and can run even on a microcontroller.... if anything the Pi is totally overkill already, but it's nice to be on GNU/Linux and have access to so many utilities, even a browser. [1] https://realtimelogic.com/ba/doc/ https://realtimelogic.com/ba/doc/

deleted 4y ago

[deleted]