I've kind of re-architected my systems design for all this. Instead of having a raspberry pi at each node, I decided to use the somewhat more powerful ESP8266s as nodes, and aggregate all of them with a single pi. Eventually this single pi will be an access point (working that one separately) and all these nodes won't even show up on my lan - just the master pi...somewhat reduced insecurity, but also just plain cleaner.
Since nodes will often be going into places I'd rather avoid having to go into frequently myself (nasty crawl spaces with spiders and snakes, oh my), it'd be super nice not to have to go there even if I discover the likely need for the odd update. So I manage to get OTA updates going on with these ESPs along with my usual WiFi use for data and control exchanges.
The one I'm doing first is located in my living quarters, which used to be called "the office trailer" - hence the name of the sketch - OTLotOTA.ino.
For initial testing I'm using a program called Packet Sender which is really nice, and available for all the usual platforms.
I'm using UDP to talk to these as the usual operation isn't super critical, and in general things will either try again...error or not...and it's faster and stateless, which is an advantage when things might be going up and down with a power surge or lightning strike. Even in my super reliable world with a whole-campus UPS...things that are on 24/7/365 really want those 9's of reliability to save me work.
So, this guy does a few things. It looks at inside, outside, basement weather stuff, and also looks at water flow, water amount in the cistern, and can be commanded to control inlet and outlet valves for the cistern (in from rain barrel, out to dump water on the ground in case the stuff in the rain barrel is nasty). I wanted basement weather as you can tell if things are going to freeze by the temperature, and if there's a plumbing leak by the humidity. Those used to be more of an issue when I lived next door and this place wasn't heated...but still nice.
Every time I do this I save a pi worth of power, and that can be more than the usual 5w if it has a lot of USB storage on it, a display, whatever...
The other advantage is that for some of what I'm planning to do - it is kind of necessary for the program making automation decisions to know things from more than one node at a time. The old way I was doing that was just not going to scale well.
In general the info from each node is going into an SQL database table in the master pi, for later plotting by a webserver on that pi. That pi also runs some CGI programs to allow manual setting of things and various other control functions. But really, even a pi is loafing here, and even with a few nodes on it it's really not working up a sweat, so using several (with more sysadmin maintenance required) didn't make a lot of sense. It's just easier to back up one than a multitude, and without adding a few different generations of pi hardware to the confusion.
Hence some work on this while I ruminate on how to make the next step on fusor.
Here's the node hardware, more or less. This runs off the same DC supply that runs the house water pump, and uses some external logic to drive solenoid valves, and obviously some external sensors, but this is the fun part.
And here's the code as it now sits:
There is also substantial pi code associated with this, a work in progress to be sure. There's a lot of sysadmin involved there, from having a SQL server and db setup, to a web server, fastcgi and so on - and it's very specific to this use. If anyone wants more info on that, ping me...it'd be a really long treatise to put here right now.
Here's a screenshot of one of the web pages the pi emits as a result of the data from this thing. You can sure see the propane heater that's right under this test jig cycling...And that there's no sensor hooked up to the water level pins, so random data there.
At any rate, the current milestone is getting the over-the air update going and verifying that it doesn't interfere with my other wifi usage on this thing. It's about ready to install, but certainly there will be some changes required - I already know my back-of-envelope water valve control stuff won't cut it, and will likely become a state machine vs a few if() statements. There are issues in the real world that any control system has to deal with. For example, if there's no water flow monitored after a valve is open for awhile, it needs to be closed as the solenoid is wasting power and perhaps getting too hot. But what if the water flow sensor eats an insect and is temporarily jammed? I can't get water without an override, or perhaps I could just create a water-hammer with the two valves opening and closing a few times at the right rate, then try again? But not forever, remembering solenoid temperatures or the likelyhood that there's simply no water in the rain barrel?
Obviously the easiest way to get this really working is going to be trying some things and making the appropriate changes as required..
Here's the tutorial I used for OTA updates to an ESP sketch. https://randomnerdtutorials.com/esp8266 ... r-the-air/
That last is why all this is happening. There WILL be a sensor in the rain barrel, but it'll be 60 yards from here...so there has to be a way to aggregate the information to make a smart control system.