Have you considered a general state-change detector that looks at the whole Export JSON? That could log everything that changes in the controller, kind of like the Recent Changes log in a wiki page. At each interval it would compare the current JSON to the one from the past, and then note the differences. This wouldn’t have to run so frequently, but it would be more general. It would also allow a user to roll back to a previous setting, say to settings of the same month from the previous year. I guess a simple version of this would be a simple cron job that would Export to a file each night. Get the data recorded, and let the future figure out how to detect the changes, if they want to 🙂 In any case, this could be valuable information for going back to try to figure out what was happening/when.
re: “If the OSPi goes down (or the service stops and doesn’t restart), then you would get no messages. I will look at a mechanism for detecting this, as I am concerned that my sprinklers may not go on if the OSPi doesn’t recover properly say from a power failure.” Yes, this is a critical problem. For starters, maybe each controller could publish a “heartbeat” message, saying “I’m alive” with various parameters, e.g. Time since reboot, CPU temperature, voltage, battery status, etc. Maybe this could be every hour. The first time after reboot it could publish another “wake up” message.
p.s. I’m planning to run at least two OSPI controllers, and may adapt one to control my pool, as well. Maybe the publishing topics should be based on the assigned name of the controller, not just “OSPI”
I’m playing with some ideas about using “Promise/Futures” logic for this. Basically, a controller has a set of promises that it has made and is working to fulfill. (“Deliver program
of watering by dawn,” “publish a <Heartbeat> message every hour,” “export the all of the controller’s variables at midnight”), etc. When it boots up, it publish a
For a more general solution, I’ve been looking at Promises/A http://wiki.commonjs.org/wiki/Promises/A and Twisted Twisted: http://twistedmatrix.com/documents/current/core/howto/defer-intro.html. A controller would publish (or commit to) a promise, which the network would then see as a future event. (e.g. running a program by dawn). The controller would then flag the promise as completed when done, or the network could detect that the promise was never completed (or the controller could admit failure). I think, (but am not sure 🙂 that this could simplify the scheduling process when it comes to rain detection, exception days due to drought restrictions, microclimate sensors tweaking a zone, etc. It also builds a foundation for doing alerts when things don’t happen as expected. We can’t expect the failed task to announce that it didn’t work, so there has to be some external promise/completion process to drive this.
I’ve got to get my sprinklers installed and running. I haven’t been able to get the SSH key pair generation to work right… I’ll probably set up two OSPI controllers, an XMBC (or two), and and MQTT/Emoncms machine, too.
Ian: what metering hardware/communication system are you using for your Emoncms setup?