Merry Christmas Eve! Playing with the Beaglebone sends me into another thought spiral.
Last weekend my order for a Beaglebone cape proto board and more DS18B20 temperature sensors arrived and I soldered up connectors on the board. This is a continuation of my pool sensor work (other posts here and here). I had a Beaglebone in my parts drawer left over from an old project. Good thing I didn’t need to buy one. The supply chain fiasco has driven their price WAY up.
The green USB adapter with a read LED is a Gearmo RS-422/RS-485 Adapter that will let me communicate with my pool pump. Some folks have reverse engineered their protocol but since I am not going to use python I won’t be using thier code.
Because the salt air and tropical temperatures play hell with electronics I am putting all of it into a waterproof cabinet. Early tests with the Netgear GS108E switch, Beaglebone, adapters and all don’t really produce much heat. I don’t think I will need active cooling. Remember that part of why I went towards to the Beaglebone was because it has a much higher allowed temperature range than the Raspberry Pi. And having a wired ethernet connection can’t be beat to remove one potential failure point (WiFi).
The essential goal of the project is to be able to read the pool temperature and periodically turn on the pumps and open a control valve that lets the hot water from the solar pool heater flush into the pool, the close the valve and let the solar heater refill, then turn off the pump. It’s not a diffucult control system.
Some Code Worries
Since I’m doing a lot of typescript and node development at my day job I started down that path. Wow. The Beablebone is pretty slow, really. Node is single threaded, and I can’t say it’s all that performant. Doing some development on the board was painfully slow. And since I’m readying from devices, it’s not something I can do on another linux box and move it over. And it’s so slow as I am developing that I’m really wondering if I’ll be jumping into debug hell if I use use node for the project.
So what’s a self-respecting geek to do? Go back to one’s roots. I pulled some very old C code I had for doing serial and played around with it and two of the RS-485 adapters. No problem. Tested that they worked with “screen” and then with code and that’s a happy path.
Reading The Temperature Sensors
Here is an excellent tutorial on how to get started reading the sensors. One or two sensors works great. But it’s REALLY unreliable if I use more than two. Check this out:
sudo ls /sys/bus/w1/devices
28-00000002864c 28-00000002c80d 28-00000003a931 28-000004d04033 w1_bus_master1
Four devices. Good.
beaglebone:~> sudo cat /sys/bus/w1/devices/28-00000002864c/w1_slave
ff ff ff ff ff ff ff ff ff : crc=c9 NO
00 00 00 00 00 00 00 00 00 t=-62
Good.
sudo ls /sys/bus/w1/devices/28-00000002864c
ls: cannot access '/sys/bus/w1/devices/28-00000002864c': No such file or directory
sudo ls /sys/bus/w1/devices/
28-00000002c80d 28-000000038289 28-000004d04033 w1_bus_master1
Not good. The device I just read from is no longer present. Nothing in syslog about it either. And it gets worse. Rebooting will sometimes then show one, or two devices. Reboot again and you may get three.
Bottom line: something is not right. If I am going down this path I need to plan on spending some time troubleshooting. I think the most common use case is one or two devices. I’m using four. That puts me several sigmas from the norm and lands me square in the land of experimentation again. Sigh. I could go towards an alternate 1-wire driver but now I’m in driver land on an ARM board. I could do that, but then I’m back down a rabbit hole of complexity again.
Complexity
Let’s revisit why I wanted to go down the embedded linux path: reducing complexity. I spent a lot of time with the ESP32 (here and here) and got myself into a place where the complexity of that path seemed larger than I wanted to deal with. Heading into embedded linux could let me potentially go faster by leveraging higher level languages and code libraries that would reduce my effort.
But maybe not. I’m a little pissed off at the moment. The abstractions that I hoped would help me go faster come at a price. On an ESP32 I can figure out what is happening pretty fast. I at least have my Oscope and the code is a single driver. The cognitive load required to understand the technology and find the problem is something tolerable. But with the Beaglebone I have the device overlay subsystem, the sysfs interface, then the 1Wire Driver, then the actual temperature driver. All of which is new to me. Suddenly the time to market gains I got from being able to set up an embedded system the same way I am accustomed to are gone, vanished into an unknown number of hours of troubleshooting. It almost feels like it did back in the day to get sound working on Linux. Sigh.
Other Good Stuff I Found
I stumbled on several active AWS C development efforts: IoT and a common lib. This rekindled my system thinking of “how to I take this past just my local network later.” I still cringe that maybe AWS Greengrass v2 is not really ready for prime time, but it has been size months since I looked at it. It gets me thinking.
Frequent readers will also recall that I have had some pains with MQTT, specifically with it being a single point of failure. But I came across keepalived that can easily take over an IP address if the other fails. Using an IP address outside my DHCP range I could easily set this up using linux IP alias. I can see a path to an easy active-active solution for the MQTT broker, and I bet the system could tolerate the loss of a few message during failover. It’s worth looking at, especially since EVERYTHING is moving in the direction of MQTT. Sure, I can hand code up a broadcast UDP solution but back to the “how to I expand this off my local network” problem… the universe is going MQTT.
Taking Some Time Away
Holiday breaks - especially the early morning hours - are usually when I actually have time for my own projects. But I think I’m going to set this aside and let my subconscious chew on it awhile. I went to an embedded linux board to be able to use higher-level languages like typescript, abstraction libraries that could make me go faster. And I found myself coming back to C. And now the advantages I thought I had in using the standard linux GPIO device layer is not an advantage but a potential huge time sink.
Should I just go back to an ESP32 and FreeRTOS? There’s a learning curve either way. I feel like I am in a spiral of decision making. So it’s time to reflect a bit rather than chasing a rabbit.
Holidays
I have sourdough rising in the kitchen, with plans to bake it fresh tomorrow morning. The sky is clear today after days of steady rain. Both my kids are home from college. It’s Christmas Eve. Life is good, and temperature probes and RS-485 is not the most important thing at the moment.
I wish you all a wonderful holiday season, and prosperity, health, and joy in the new year. We all deserve it!
