Your leaking thatched hut during the restoration of a pre-Enlightenment state.

 

Hello, my name is Judas Gutenberg and this is my blaag (pronounced as you would the vomit noise "hyroop-bleuach").



links

decay & ruin
Biosphere II
Chernobyl
dead malls
Detroit
Irving housing

got that wrong
Paleofuture.com

appropriate tech
Arduino μcontrollers
Backwoods Home
Fractal antenna

fun social media stuff


Like asecular.com
(nobody does!)

Like my brownhouse:
   dynamic allocation of database-specified sensors on an Arduino
Thursday, June 6 2024
The trash trailer left by the roofers remained at our house all day today, and Gretchen coerced me into putting more stuff from the garage into it. But I also fished a few things out that I'd humored her by putting in it, including a fuel pump from an oil-fueled boiler.
By this evening, I had my mechanism for adding additional sensors to my remote control system working. As I may have hinted, this system treats additional sensors as device_features, much like the pins that turn relays on and off. Instead of being outputs, though, they're inputs. They can be any sensor the system has code to support (which at this point includes most DHT sensors, BMP180, BMP280, BME680, BMP085, and LM75), with the information in the device_type_feature table telling the ESP8266 what pin it is on (if it's a DHT) or what I2C address it is on. Some of the code had to be migrated from a scenario where such information is specified at object creation (which in the Arduino environment seems to have to happen at startup) to specifying it after object creation, but ChatGPT helped me come up with the code to do this when I couldn't figure out how. (I don't have a good intuitive grasp of how C++ works under the hood and all my Arduino knowledge comes from examples, but I'd never seen an examples of, say, Arduino code spinning up a new DHT object with the particulars of what pin to send data on pulled from a database.) All these individual sensors are treated as programming objects by the code, and to keep track of what object is what, the remote control software starts up with a generous twelve-object array of each kind of sensor it supports. (I feared this might be a wasteful thing to do given the limited memory available, but it's not.) It then allocates the objects in a deterministic way based on a query performed on the backend of the device_feature records that are actually sensors. Then, every time it needs to read weather data from the sensors, it goes through them in the order they were allocated, incrementing an object index for the correct array of sensor objects appropriately. Meanwhile, all ESP8266 data has always been sent back to the backend as a delimited string. To handle the additional sensors, I added a new delimiter in the "weather data" section of that string. Now there can be several weather data sections, one for each sensor, each delimited by an exclamation mark. The backend just loops through those using its existing code, keeping track of which is which with a device_feature_id (which is null for the one default config-specified sensor that was all I used to support).


For linking purposes this article's URL is:
http://asecular.com/blog.php?240606

feedback
previous | next