So many intertwined topics… let me respond to some of them raised on this thread:
Dan: re: “My original goal when I started working with Python and OpenSprinkler was to develop a platform for experimenting, and something that can be easily customized.” Wonderful idea, and thank you for acting on it. Hopefully, I can build on your platform – and use my own home as a experimental site. I have a huge water bill and am in the middle of California’s drought (San Diego), so this is quite timely for me.
Ian: re: “I haven’t had much of a look at gv.py yet. I assume your modifications will create data items that can be input via the Opensprinkler web interface?” And thank you Ian for pointing out these neat new technologies. I’ll let Dan comment on this, but my understanding is that gv.py is the home for establishing the global variables used by the other OSPI.py software and plugins.
I want the capability to track ALL state changes in my sprinkler system(s). I want to know when a program changes, when the rain sensor comes on and goes off, when someone changes the minutes per station within a program, how long a valve has been actuated, how much water flowed through my irrigation meter during the actuation, if there were any unexpectedly fast flows (a gusher), or low flows (bad valve). I would like to add micro-climate sensors to adjust my zones (the north side of my home is much cooler than the south side, for example, and varies with the season, leaves on or off the trees, etc.) Obviously, I don’t intend to do all of this at the onset, but my design style is to design for the general and then narrow down to the specific. I would like to design for the general framework, and then populate it with one instance. It’s a bit like creating a wiki (which is really a very simple technology) and letting Wikipedia emerge rather than collecting standards committees and experts to write the “correct” encyclopedia. So, what are the simple initial conditions we can create to allow other innovation to emerge?
It seems to me that we need to trigger the messages at the time of the state change in the main program. I was thinking of the mpay global variable as a string that would control which messages to be published. Maybe others have a better idea, but my first thought was to assign character codes to each type of messaging: “s” would represent sprinkler state, “p” would be program state, “r” would be rain state, for example. mpay=”srp” would cause OSPI to publish all events, mpay=”s” would publish only sprinkler events, etc.