I see that Nerves is starting to gain some real traction lately which is absolutely great (congrats to core team for their effort!), it made me want to revisit it for a more serious investigation. Thinking about potential projects, I realized that I have no idea where Nerves is used for real-world projects.
It would be great to hear on what kind of fields there are already existing solutions?
It would also be interesting to know what is the most widely used hardware in production, because while Nerves seems to support all RPIs, I have my doubts that a lot of businesses would use their chips in production, as they are not very flexible with their supply costs and quantity.
And at last, the most important question would be where a Nerves solution would be superior from the ones already existent on the market? I have a feeling that ingesting sensor data and transforming it into a server-side protocol like JSON would be very powerful, but it would be nice to see a concrete use-case.
IIRC “ingesting sensor data” is an accurate description for part of their system; they collect temperature / humidity / etc data at customer sites and analyze it to do realtime demand response and track down excessive usage.
By public information it is 96% thermostats, power meters and door control. The rest is growing things.
I kid.
SmartRent (thermostats and access)
GridPoint (thermostats and power)
Bowery Farms used to, may still be
SparkMeter (power management?)
Alloy (boat startup, paused bc funding)
Rosepoint (navigation)
FarmBot (probably defunct?)
There are more. Industrial usage is rarely public. I have clients that are secretive.
It fits where embedded Linux fits. Hubs and gateways are popular. Kiosks, “edge” “machine” “learning” like object detection or whatever.
The RPi CM4 series is a fine starting point bit many have also used BeagleBone Black and friends.
I’ve heard people use a variety of NXP iMX, Allwinners, some Nvidia Jetsons and I currently have a TI AM625 dev board on my desk. Adding new boards is easiest if they are supported in Buildroot but overall requires some know-how regardless.
The Pi boards are currently the most approachable, BBB second and that has a more professional featureset.
I don’t know any embedded linux that offer quite the end-to-end story of Nerves.
Supervision, easy high-level coordination of tasks, trivial concurrency, standard tools (Buildroot) with great anstractions over C (BEAM/OTP), fleet management with NervesHub, easy firmware dev cycle, firmware updates via NervesHub, firmware binary deltas, easy access to capable web frameworks with the same easy coordination, robust runtime, granular failure and recovery, blessed path for device auth via NervesKey.
Some of these are just “BEAM”. Erlang was pretty much for big honking embedded devices back in the day. Nerves toes together the OS, BEAM, Elixir and provides abstractions for the necessary services.
Honestly, this industrial classified information is getting tiring lately, telecom world was the same and it’s now all in shambles after the investments stopped, lots of extremely well made and polished protocols and technologies are useless for the general public because of these “industrial secrets”.
I guess it’s no wonder almost all of them get vendor locked then milked or run on prehistoric solutions that they can’t upgrade easily.
My experience is mostly hobby (not meaning non-involved though) projects (and also the occasionnal freelance gig !), so consider my post with a grain of salt as I don’t experience the scaling and fleet management aspects of Nerves… yet ?
My experience with creating devices previously meant cobbling together a raspi clone, a few atmegas if precise timing was important, a bunch of python scripts, some C, a system image, and bash scripts to glue everything together.
I guess that you have seen Sasa’s canonical slide with the table, where the right column is all Erlang ?
(https://i.redd.it/tke2stni7l051.jpg)
My experience with Nerves is exactly that. You have an (almost) all-elixir system, access to all of Hex, access to the hardware from Elixir, and the system building part is handled by Buildroot, which makes building your system mostly deterministic. You want to control your hardware from a smartphone ? Sure, just add a Liveview app to your project and configure (in Elixir) the system to create an ad-hoc wifi AP.
The number of moving parts is smashed to an absolute low. It’s a joy working with Nerves, and Nerves also acts as a gateway to learn about building Linux systems, device trees, etc, and go deeper.
I experienced that kind of deep joy when I went all-in on Elixir, and how it reduced the software complexity in my work. But what absolutely blew my hat off was discovering that a similar experience can exist for hardware projects.
I can only encourage every Elixir enthusiast who likes to fiddle to try it — it’s that good.
I cannot really apples to apples compare this to other solutions, which I’ve never deployed in practise. But having worked with nerves at sparkmeter there’s a few observations I can share:
Working on both the nerves embedded device as well as the cloud service it communicated with felt less like two independent projects talking to each other and more like one coherent service, which happens to include a lot of inconsistently available members. There’s not just the “same VM” argument, but there’s a library implementing the protocol (once) used by both sides, there’s a library with shared internal data (again not duplicated) – no real context switch needed. We even considered sharing significant parts of business logic to overcome latency constraints at some point. Elixir makes working with binary data a breeze, which is useful when you need to be mindful of how much data you send, but also for a lot of the communication to other hardware locally.
I can also attest do @Lucassifoni’s points. Nerves takes a bunch of the (one-off) decision making out of the equation, which you’d need to have if you create something just of individual pieces you picked out. It has a path of how you setup the linux system beneigh the elixir service, it brings a tool to keep the system alive (erlinit), it brings a build pipeline, it brings a tool to apply (delta-)updates (fwup).
I’d also add that I don’t think the individual pieces of nerves are particularly special. Most parts or subsets of parts you can find elsewhere as well. But nerves brought them all to elixir (and the beam) and made the pieces work as one complete package.
This is my experience, very much. And it is paying dividends all over the place. I think Nerves can on-ramp Elixir to embedded Linux and the wider embedded world. I also think Nerves could serve embedded devs as a good end-to-end tool that gives abstractions and capabilities that are a pain to roll yourself in C. The BEAM. The C was written for you
Not only that. Having the embedded stuff and the rest in different languages (maybe many, like our current production system) is not only just complicated and cumbersome, it also leads to a fragmentation of the dev-team, right now for us that is one or two people handling their own silo. But it is an Elixir “feature” to be capable to cover many different things, Nerves is not needed for this.
Nerves is great if you want to use hardware that is already supported.
If you have to build the system yourself for random hardware, you need deep Linux knowledge or this may become a very expensive task. (depends very much on the hardware). That’s why we decided against nerves and run a erlang release on a yocto system the hardware manufacturer provides (and is responsible for).
We loved nerves when we evaluated it, but maintaining a buildroot system for different boards is just not feasible for us, at least we are quite certain that it is more and harder work than doing the nice stuff nerves does ourselves.
I was a bit lost as to why a non-supported system would be so hard/expensive. I don’t think it is more expensive under Nerves than any other Buildroot. Then you mentioned Yocto and it makes sense. Using the Yocto one gets you direct vendor support. I haven’t tried Yocto but haven’t heard the most positive things.
Sorry to hear you couldn’t use Nerves but glad you found it desirable
Yes. If you do it yourself with 0 experience in the field buildroot would be easier than yocto. But a yocto-toolchain you get from all serious manufacturers. And getting the system up and running is not the main point, it also needs to be maintained. Which in our case, is also the responsibility of the manufacturer.
A wallmounted touchpanel and a custom railmount-server.
If you use any board like raspi or such, buildroot/nerves should be relatively easy.
We manufacture communications equipment, satellite and troposcatter modems. The appeal of Nerves/Elixir was the fault tolerance and small footprint (based on buildroot) compared to the Debian/Yocto type embedded Linux distros. We are not webapp people, we design hardware. The Elixir ecosystem lets us spend more time doing the signal processing and hardware dev and less time working on the various UIs (web/REST/SNMP, etc).
For a specific use case, if you ever fly on Southwest airlines, there’s a 99% chance that your in-flight connectivity is provided by a Nerves-powered modem.
