Although pretty nice if you have a Linux host, I would say this isn't well suited to typical embedded IoT devices that would be used in large scale deployments. It would be cost prohibitive to blanket a city with temperature sensors if they all needed to use a $35 raspberry pi.
Many IoT devices run on very limited hardware mostly without an MMU, usually shared with the Radio like the Nordic NRF52 or Semtech's Lora modules. Often times with serious size, power, and cost constraints. This often rules out higher level languages like Erlang, Go, etc. These are great languages for different use cases, but really not well suited to any low level hardware. The runtime language has huge impact on cost and battery performance. More memory == more $$, more CPU cycles == more power.
To be fair, Pi Zero's are $5, which will happily run nerves. Outfitting with relevant hardware for the task at hand will of course increase the price (as would any hardware product), but the "$35 pi" is a little misleading. You are right that it will require larger hardware constraints, but there is a lot of nuance to the price discussion. Operationally, nerves grants you the ability to provision fleets and deploy updates in the field, rollback bad firmware pushes, etc. Value wise, this kind of feature set out of the box should factor in to life-time device cost considerations. I'm not aware of an equivalent offering on other platforms, but I'm admittedly just a spectator in this space.
True, but also consider you still need to add a radio and then run it all on batteries. There are much better solutions that still cost less. Not to mention, having to rely on Raspberry Pi of any kind for commercial use is tough in large quantities (speaking from direct experience).
As a hobbyist tool, this is great and nothing wrong with it. But in the traditional IoT sense, we are usually talking large volumes of cheap devices running on batteries.
While i agree that products shouldn't ship on raspberry pi, it's not as nonviable as you might think.
> Not to mention, having to rely on Raspberry Pi of any kind for commercial use is tough in large quantities
Maybe you weren't talking to the right people? I've shipped two products using raspberry pi and getting them in quantity was never a problem for me. we could easily get them in quantities of 500-1000 at a time for the RPI0W models and the RPI3B+ models.
> True, but also consider you still need to add a radio and then run it all on batteries
I don't think Nerves is a great fit for battery power, but RPI0W comes with a BLE and WiFi radio built in. It's also easy to add LORA or other sub ghz radios.
Didn't say Raspberry products aren't viable. I have shipped over 50k units with Raspberry Pi across three products. But the margins are terrible and many times a loss when you factor in user acquisition costs.
RPI0W is now double the price at $10. You still need to add power (lipo and/or charger), enclosure.
With Raspberry Pi stuff
1.) There is nearly 0 (max I have seen is $2 off) price break at volume.
2.) You have essentially one vendor (that uses distributors)
3.) When a new version launches, the older version inventory gets very constrained.
4.) You can't customize the PCB
5.) You can't get any support from Broadcom
I mean a lot IoT problems/solutions seems all about tiny things running on coin-cell batteries for years.
I guess the point is that there is a huge difference between hobbyist and commercial viability. It is a significant gap in terms of engineering effort and target BOM costs between the two. Have seen countless products fail because people with no commercial hardware experience tried to launch a product with hobbyist tools and components.
But, again, as a hobbyist it is fine. If you are considering commercializing your hobby project one day, then I would think about it differently. At least consider Rockchip. You can get a Raspi clone for less money and can work with them to customize if needed. If it runs on batteries in a small form factor, would reconsider using linux.
A recent episode of the Smartlogic podcast[^1] interviewed the Nerves team and discussed this a bit. Their example was something like: you wouldn't build a smart lightbulb with nerves, but you might build the smart bulb hub with it. I think that makes a lot of sense and still fits a very good use case: something low power, but internet connected and possibly serving a UI over a browser or an API to a mobile app. There are a great number of IOT or IOT-adjacent projects that are a good fit for something like this, even if it isn't necessarily appropriate for everything.
Yep, 10 out of 10 of those "IoT frameworks" unequivocally qualify as epic fails.
As of recently, I had to work on Microsoft Azur IOT. Their "embedded" library doesn't even load into memory if you are not plugging in an external ram on the most beefy MCU on the market. It takes 1mb+ to do a very, very basic HTTP+TLS+JSON parsing. And even this way, it often triggers watchdog on moderately long transfers.
-----
On a sidenote, had a conversation one time with an ex-webdev in the setting of developing for MCUs:
— "How did you get it to 1MB?"
— "I shortened the strings, and removed the dead code!"
— "No, I mean, how did you manage to get it past that 1MB?"
-----
It's quite hard finding experienced non-webdevs in general these days, but among those, the number of people who can do C for embedded (and under embedded I mean bare metal, not Linux on SBC) is so low that we can say that real embedded devs have pretty much went extinct.
I agree with you totally, these IOT frameworks mostly have clients that do not really work properly on the "edge". Als IOT frameworks based on "runtimes" always have way too much overhead that does not scale.
I have seen some technology that is amazing though, for example DDS, Zenoh, OPC UA.
I for once look at the side of, reliability and quality of the signals. Most IOT frameworks don't care about when or how the data arrives. What about QoS ?? What about Jitter of the signal?
If people use Managed languages in IOT, for example the hobby stuff like micropython on microcontrollers. It's fun for hobby. But nothing else. Waisting alot of resources etc.
A good IOT frameworks consists out of a Tweakable QoS for the data from hard-realtime with (TSN time sensitive networking) up to soft to no-realtime data. Network will balance things out regarding the QoS.
What if i need an IOT platform/framework and need hard-realtime data between a sensor somewhere and a robot with a control loop?
Reliability, scalability , adjustable QoS of signals, and also low on resources that can run on Microcontrollers with TCP stack that enables TSN.(Therefore an RTOS is best solution, but rather no RTOS if possible) (And two NIC's to make reliable hardware, when you have hardware failure)
For one project I've spent considerable time trying to get the Azure IoT SDK going on a low-cost Wifi chipset, only to find out that it ended up not working after all the platform glue was in place because of inexplicable decisions from both the host APIs (no source code access, of course) and the Azure SDK, making most of the built-in functionality (eg https/MQTT/encryption) useless for Azure, resulting in not only code bloat, but also running out of heap memory with fantastic silent crashes.
After spending weeks on trying to fit everything into ROM in the first place. The end-result was ditching the SDK and re-implenting most of MQTT and websockets before the project was ultimately canned for other reasons.
A pi zero w, otoh, costs about $20 (with a reasonable SD card) vs $5 for something like the ESP32, and makes life easier with unlimited storage and open source platform code, but it is impossible to mass-produce anything for under about $120 retail cost due to the high price of the rpi alone, which is a real bummer in a competitive IoT market.
At least in Sydney, I found that bare-metal jobs typically paid far less and required far more experience. Some of the best engineers I know are being paid peanuts but are just happy to be quietly amazing in their corner.
I was proper bare metal at one point (even wrote my own crappy rtos at one point) but couldn't resist the better pay and better treatment that you get up the stack.
oi, I'm not extinct, it's just many embedded programmers, especially bare metal programmers, tend to hang out in very different places, if they hang out anywhere on the net at all.
I work with a few! So may have to get our pod registered as endangered species, I could monetize it by selling sightseeing tours for web and backend devs to see what real engineers look like.
Generally wages there correlate to the amount of productivity of the field.
Embedded / firmware takes a lot more tedious work, often requiring more people and time and that's just for a single purpose device. Whereas a few Web developers can create a web service that runs an entire profitable company with tens of thousands or millions of users. Of course that's the generalization but I'd guess it's a 1:10 or at least a 1:5 ratio on the income/profit vs development time/effort required between web dev and embedded.
I strongly believe that projects like Nerves can help lower that ratio and make a lot of IoT type projects follow economics more similar to web development. Sure a RPi costs $35 per unit, but lets say you're making a veterinary monitoring system which costs $100k for the software it fits into the budget much easier if a couple of devs can implement it in weeks versus the months and/or large teams it used to take. There's a lot to be said for the long-tail of economics in areas where leveraging more productive tooling can increase productivity and profitability.
Unfortunately that only generally applies to roughly pre-canned hardware and commodity sensors, etc. You won't get that effect when building say a new Camera Sensor CCD chip.
> As of recently, I had to work on Microsoft Azure IOT: Their "embedded" library doesn't even load into memory if you are not plugging in an external ram on the most beefy MCU on the market.
AWS Greengrass has the same issue, it only runs on Raspberry Pi's and up, which is like using a semi-truck as your daily driver in a city where a good bicycle is all you need. At worst we need things to load into 0.5MB with room to spare for our own code too. At best we'd like things that could load into 32KiB with room left over for our own code too.
32KiB lets me get temperature/humidity monitoring over WiFi working at <$2 per sensor+wifi+mcu. So if you need 200 sensors to monitor a space, that's just $400 for bare minimum parts, not including enclosure or power supply.
0.5MB raises that price to $5/unit, but mcu's that can handle this can also generally handle generating/using enterprise-grade wifi certificates, which might be nice.
Using AWS Greengrass / Azure IOT means I need to use a raspberry pi, so $38 or so per unit. Now instead of $400 you're looking at $7,500 for baremetal parts. Put another way that would raise a hypothetical consumer-oriented device's MSRP by $100 vs whatever it would be if it could use the lightweight $1 mcu.
Many IoT devices run on very limited hardware mostly without an MMU, usually shared with the Radio like the Nordic NRF52 or Semtech's Lora modules. Often times with serious size, power, and cost constraints. This often rules out higher level languages like Erlang, Go, etc. These are great languages for different use cases, but really not well suited to any low level hardware. The runtime language has huge impact on cost and battery performance. More memory == more $$, more CPU cycles == more power.