|
|
|
logging prerequisiste
Tuesday, May 7 2024
After a somewhat brisk morning, the day turned into a glorious spring day, with absolutely cloudless skies and warmish (but not too warm) temperatures. The absence of humidity made the air seem clean and maybe even cleansing.
I spent much of the day indoors, working on the prerequisites for the automation part of my remote control project. As mentioned previously, an essential component of this will be a logging system, since I will likely have to debug strange and perhaps unwanted changes of state of equipment. Whenever you assign something to a robot, it's probably best to keep a careful eye on its behavior so you can catch it before it goes too rogue. In the parts of my system that can already be controlled, there's already a potential for mischief: using too much electricity and depleting the cabin battery when the electricity needs to be conserved for other uses, running the boiler and perhaps burning too much propane, or even overheating the basement (though that's unlikely to happen very quickly). In the near future, it will be possible to do things like power up the generator, which can quickly burn through precious propane if a glitch isn't caught and corrected. One day I might also depend on the system to take proactive steps to, for example, ensure that pipes in the cabin do not freeze. So I implemented a robust logging system that I carefully honed so that it wouldn't log excessively. I only wanted it to log transitions of state so I could have a concise record of things that had happened. I also wanted to be able to distinguish in the log whether or not a change of state had happened because of my interaction with a UI, the server control page, or automatically as a consequence of the time of day or information from the solar inverter. Fortunately, all the information I needed for such logging is available on the data.php page that the microcontrollers regularly poll. Since I'm tracking the flow of state-change all the way to the microcontrollers, I can even catch cases of state change that aren't happening via data.php (that is, changes made via the backend administrative tool) and log them accordingly. The logic where this happens looks like this:
The database is essential to this project, since the state of microcontroller pins is reflected in data in database tables. But it's been a very simple one, basically just being an expansion of the single-table "weathertron" database (that table was weather_data, which was just a log of weather data from multiple sensors). There hadn't been a single many-to-many relationship. But that is changing with my new management_rule table, which will store the logic to perform automated changes. I'm thinking that every device_feature should be able to have multiple management_rules (to, for example, be turned on when the cabin battery is at 100% capacity and turned off when battery capacity falls to 60%). But those same management_rules should be able to apply to other device_features as well. This means I now have to build some user interface to create and remove these relationships. (I had a pretty good tool for this in Tableform, which ended up being a comprehensive database tool and visualizer, but the homebrewed zero-dependency framework I am now using is much simpler and requires strict conformance to a particular naming convention, among other things.)
Gretchen spaced out about her prison poetry class and might have missed the whole thing had I not asked her at 5:00pm, "Don't you have a poetry class tonight?" "Oh shit!" she yelled, flying upstairs and putting on going-out clothes in seconds flat. I was worried she might have an accident as she sped down Dug Hill Road, but nothing bad happened and she made it to the Coxsackie prison on time.
After Gretchen left, I took the dogs on a walk on the escarpment west of the Farm Road. Charlotte and I made it all the way to the abandoned go-cart track, though I think Neville decided to head home well before we made it that far.
Later this evening there must've been another incident with Bridget, one of Crazy Dave's dogs, because Charlotte started barking like crazy and them came flying into the house so fast that she tore the magic screen draped in front of the door (it automatically closes due to the presence of magnets). She also involuntarily sprayed the front of the house and the tiles just inside the door with urine. Gretchen says that on one occasion Bridget freaked Charlotte out so much that she shit herself.
For linking purposes this article's URL is:
http://asecular.com/blog.php?240507 feedback
previous | the future |
