@Nathan: Yes, many tradeoffs. Part of me wants to go off into advanced futuristic projects with autonomous drones supervising the sprinklers, robotic sprinklers, computer vision of the landscape, smart sprinkler heads and valves, three dimensional hydraulic modeling of the irrigation area, rain barrel/gray water/reverse osmosis water recovery, smart pool and pond management, and stuff like that. Another part of me has a very real irrigation need that has to be 100% reliable or I could do a lot of damage to my yard (and my marriage 🙂
There’s a huge move towards Internet of Things, smart sensors, home automation, of course. I’ve played with Thingspeak (to which I give a A- rating), Node-Red (B+), Initial State (C+), and a couple of others that were too complicated to even install. I’ve also toyed with the idea of using ROS (Robot operating system), treating all of my home sensing and control as a robot. In any case, all the interesting stuff for the future will be in working with all the sensors and controls in an ever smarter, integrated platform.
One approach would be to use an API to control things. The current OSPI API is a baby step in this direction, and may point the way to allowing these systems to all play in the same sandbox.
But a word of warning: suppose you want to create a “Anticipate Rainfall” REACT control in Thingspeak. If you try to set the OS Sprinkler weather level with their HTTPSpeak, you would discover that setting the Weather level also requires that you read the DHCP variable and reset it at the same time that you set the weather level (it is a so-called “binary” option that gets reset every time you set the weather, whether or not you explicitly include it in the HTTP command). If you miss this subtlety, or send a malformed command, you run the risk of bricking your Arduino controller, requiring a reinstall of the software. (I know, because I spend an anxious evening reinstalling the software when trying to adjust the weather remotely). I’m not sure why they designed the API this way, but I’m sure that the fact that they were trying to squeeze a lot of logic into an Arduino played a huge role.
In any case, the unified OS Firmware is constrained to the lowest common denominator – the Arduino’s capabilities. Moving to a Linux architecture opens up pretty much unlimited capabilities, far beyond what can be squeezed into today’s Arduinos.
It seems to me that the way forward is to define (or find) multiple abstraction layers. The bottom layer is the logic to monitor, actuate, and log the water flows. The next layer would be responsible for scheduling and coordinating the flows. The next layer would integrate with other services, such as home automation, anticipation, etc…