opensprinklerpi versus opensprinkler

[[email protected]]

im weighing the differences between the standard version of the sprinkler controller and the raspberry pi version. im a software engineer with arduino experience and i love tinkering but i dont want to miss out on features that might be available with the standard version, but not the pi.

so my questions are:

are there major differences between the two versions out of the box software?
what does it take to modify the provided sprinkler software on either platform, can i just ssh into either and modify files with a text editor?
will the IOS app work with the pi version?

i also want to say that i think this project is amazing, its exactly what i look for in something like this. it seems to comes ready to perform but is still highly customizable and you have a GITHUB repo! well done and thank you!

[tom]

I installed an Arduino version for half my yard, and just installed the PI version in the other half of my yard. I also installed a PI version in my wife’s raised bed vegetable gardens (one zone per bed). My wife (more interested in gardening than geek stuff) really likes it. I also tested Dan’s Python version (Now called SID).

My reactions to all three:

If all I wanted was to plug in a controller and use it without modifications, I’d use the Arduino version. It is much more self-contained, doesn’t have to boot an operating system, boots faster, and is probably much more reliable than the PI, not being dependent on an SD card. But modifying the controller is much more difficult, if not impossible for certain tasks. There is no SSH shell available, you have to upload an entire new program to change anything.

If I wanted a reliable (and compatible) controller that I could run as a “production” controller but still run other programs, I would go with the PI or Beaglebone version of the unified firmware. This takes more setup time, but provides far greater expandability and customization. But it also requires more geek work to set up. I’m currently in a geeky mood, so this fits my current interests very well. I love being able to SSH into the controller and look at things, add a CPU temperature channel on ThingSpeak (see https://thingspeak.com/channels/41518 ) and monitor the status of my system with a simple Unix command (“watch curl http://osbedroom.local:8080/js” shows which zones, if any, are activated – replace osbedroom.local with your local IP address, turn off passwords on the site )

If I wanted to explore even more leading-edge PI technology, I would go back to Dan’s Python program. I really liked the openness and the overall general architecture and plug-in approach. But it wasn’t compatible with my previous Arduino system, and I wanted to have a reliable production controller that I could use as a foundation for my own techie adventures. It sure would be nice to have the best of both worlds… a solid core system that will run across Arduino and PI platforms compatibly, but also a plug-in (and REST API interface) capability to mod it as well.

All in all, I am delighted with the technology. It’s running well (fingers crossed), and I’m having fun analyzing flows and logs.

[Dan in CA]

@ Tom,
Nice comparison of the various options.
And thanks for the tip on the Orbit outdoor timer box. That looks like it should work for a lot of different configurations. I’m going to pick one up on my next trip to Home Depot.

@ Nathan,
I have been running a Pi based system for ~2 years without any reliability problems.
The GitHub web page for the Python program (now SIP) has an overview of the program.
http://dan-in-ca.github.io/OSPi/

Note: as of today (June 11 2015) I am in the process of updating documentation and renaming things. If the instructions don’t work for SIP, Try the old name (OSPi) instead.

Dan

[[email protected]]

thanks Tom and Dan, that is exactly the kind of feedback i was looking for. i suspected that the PI would be the more appealing choice, and its good to know that there is no SSH’ing into the arduino version and that the update process requires uploading a new sketch.

i absolutely LOVE the idea of being able to hook this up to an api like thingspeak, also its interesting to consider a logging as a service approach rather than storing them on the card. Great feedback, thanks again all!

[tom]

@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…

[Author]

Posts