Woohoo! I really love the Nerves project. I have been slowly working on a project to build a rpi4 powered motorcycle racing timer. The goal was to use sensor fusion to get high accuracy. A friend of mine is a semi-pro motorcycle racer and didn't want to pony up for an Aim Solo device. I bit off a lot more than I could chew: learning elixir, i2c and embedded device programming simultaneously. I didn't see any libraries for interacting with Ublox GPS devices so I started writing my own. Learning how to read a datasheet, how to read/parse/construct binary messages and control the state of the various devices. I made the gradient too steep for myself and ended up kinda abandoning everything. Friend ended up buying the Aim Solo :(
I eventually did get the API to a stable enough point where I could power on the device, configure it as needed, and then read a constant stream of positioning/time data. My next steps are probably the easy part (sending the data up to an API, or collecting it internally for the sensor fusion bits), but I am kinda burned out. I am probably over thinking it - I shouldn't hold myself to such a high standard since I am learning so many new concepts at once.
I'm definitely going to grab this book. I have been in software for a long time but have never done low-level driver/device programming so I don't know the "idomatic" way to do things. For instance, a lot of devices need to warm up, then get configured to operate a certain way, and then you can read data from them. But I am used to request/response style programming, not dealing with a shared memory space that the you and the device are both reading/writing from together. I'm also completely in love with the actor model, but coming from a more traditional background struggle here with intuition on how to structure supervisors and such.
I started putting together a parts list on sparkfun but many of the authors' recommended components were listed as out of stock with no known return date. I tried to do similar at adafruit but some components would have to be substituted. I don't know enough about electrical engineering and component picking to make the right substitution choice here, and wasn't prepared to commit too much free time to trial and error. My guess is people who do know what to substitute and how to work around any necessary changes here are already too advanced to be an audience for this book.
Seems like bad luck on the timing for the release of this book that components would just be unavailable, or maybe its just bad luck with the worldwide chip shortage.
If a separate manifest of usable parts appears I'd likely dig into this title.
Depending on what you want to do you can get away with a RPi and RTL-SDR which are pretty widely available.
Most wireless weather stations use ISM bands, I used RTL_433[1] to pull the raw data and quite a few popular stations already have the format documented.
Combine with InfluxDB+Grafana+simple polling script/program and you can do a bunch of fun stuff with it. Have the whole thing wrapped with docker compose and just runs in the backgound.
Would you be willing to throw your docker file up somewhere? I have a RTL-SDR and an underutilized pi4 that this sounds perfect for. I've even seen some of the weather stations in the vineyards near my house.
“Elixir is a dynamic, functional language for building scalable and maintainable applications.” [1]
“Nerves is the open-source platform and infrastructure you need to build, deploy, and securely manage your fleet of IoT devices at speed and scale.” [2]
I haven't read the book yet but I was perusing the code and two big things struck me. It's possible I missed something, so please correct me if I'm errant.
1. There is no Phoenix UI. The Phoenix app has no views and only one endpoint, and API for recording "weather conditions". That said there is a Grafana dashboard that seems like it would be great, so I don't think you really need a Phoenix UI.
2. There are no tests, so if you (like me) were hoping to also see how testing is done in Nerves (and even Phoenix though this isn't a book to teach you Phoenix) you will be a bit disappointed.
An exciting title though, and as soon as the components are back in stock I'm excited to build it.
Why all these software tools for publishing and managing the data. Why not just put the data in a csv file from a python script, then use gnuplot to plot it when requested from a web server running on the pi.
I'm the exact target market for a book like this, and the goal is build something cool and useful while deepening my elixir skills at the same time. You could of course hack something together much quicker/easier/cheaper but in the process you don't learn Nerves, don't get to exercise your Phoenix and general Elixir skills. You don't get to play with TimescaleDB, and you don't get the supreme enjoyment that comes from stepping back to view/use a magnificent piece of art that you built yourself.
This is the world I want to live in, one in which I spend more time than is needed to craft a beautiful product (inside/code and outside/ui), where I don't have to sacrifice quality for time and accumulate tech debt so I can rush to market. I've accepted that I'll probably never have a professional job where quality is more important than speed, and where beauty is more important than scrum ceremony, so books and projects like this are where I satisfy the innate need for elegance, while also building something I've wanted for a long time (a very hackable and very open weather station).
Also without a doubt the skills learned here will make me a much better developer for the day job and side gigs (where I use Elixir/Phoenix quite a bit). If I use python and GNU plot, there's no deepening or broadening of the skillset and knowledge that I want to use.
This post is already pretty long but I wanted to add that the "stop the madness" post actually resonated with me a lot (even if I disagree with some of the conclusions). If you want the madness to stop, learning Elixir/Phoenix is actually a great way to do that. You can crank out simple solutions very easily. The JS world is finally coming back around to the idea that there's great value in SSR, and Phoenix makes that easy and a joy, and with LiveView you really can replace a lot of SPAs, especially those where realtime interactivity is needed (such as chat apps). There's still an important place for a SPA for PWAs and/or offline functionality, but so few applications have that anyway.
You're being little too quick to judge here. This project represents software running on an embedded device to collect, process, store and display measurement data in realtime from the real world. Like something you could connect to a solar panel or a small battery pack and put outside in your greenhouse.
Nerves is an incredibly powerful tool. It will burn a firmware image to an SD card for you that you can just insert into your device and boot. It's almost like magic. There is also an elegant OTA (over-the-air) update process so that you can update your device remotely, where it deals with managing disk partitions so that the system can pull the new image and boot into it without the need to remove the SD card. You also get the benefits of lots of community work for supporting a big number of devices. And when what the community has created isn't working for you, it's all just open-source buildroot goodness so you can do your own thing. In a project I was working on I needed an external wifi adapter vs. the onboard one and was able to recompile a custom kernel to enable the right drivers. It was a lot easier than I ever imagined.
You also get Elixir - which is pretty rad in and of itself to have such a powerful runtime on a tiny little device.
So sure, you can do as you describe but you are only considering about 1% of this project: rendering data for the user to see. You are missing out on the fact that in order to gather that data you need to be able to communicate with some kind of embedded chip that is actually collecting those measurements, often via a very low-level communication protocol like i2c or spi. You need to parse the measurements, which are often not in a human-friendy format, then you need to get the data out/off the device so you need a network stack, your network might go down so you need a system to capture data and replay it once the network is restored, etc. It's really sophisticated! Seeing a book like this is incredible.
An excel spreadsheet would require an entire computer! This just requires household objects. And a calculator includes so many unnecessary features like division, it’s a lot of scope creep.
I would guess that by involving Elixir the intention may not be so much about learning how to set up a single home weather station, but on development foundations scalable beyond a single device/data source and client.
Interesting book. I got it ordered to check it out.
Does anyone have any interesting examples of Nerves or Elixir Circuits being used in industry and not by the developers of Nerves? I tried using Elixir Circuits a while back for a simple project but found it a little non-standard and got the impression it's only used by the few people developing it.
I’ve just finished an rpi based device that would be going into mass production if it wasn’t for the parts shortage, with some digital IO and I2C. It took me about a year calendar time to convert the software stack to elixir+nerves as a side project, with many improvements just because of the good infrastructure support for remote deployment. Circuits wasn’t particularly weird, though it had only limited support for some advanced GPIO functions.
I eventually did get the API to a stable enough point where I could power on the device, configure it as needed, and then read a constant stream of positioning/time data. My next steps are probably the easy part (sending the data up to an API, or collecting it internally for the sensor fusion bits), but I am kinda burned out. I am probably over thinking it - I shouldn't hold myself to such a high standard since I am learning so many new concepts at once.
I'm definitely going to grab this book. I have been in software for a long time but have never done low-level driver/device programming so I don't know the "idomatic" way to do things. For instance, a lot of devices need to warm up, then get configured to operate a certain way, and then you can read data from them. But I am used to request/response style programming, not dealing with a shared memory space that the you and the device are both reading/writing from together. I'm also completely in love with the actor model, but coming from a more traditional background struggle here with intuition on how to structure supervisors and such.