- This topic has 4 replies, 2 voices, and was last updated 8 years, 7 months ago by
.
-
Posts
-
I stumbled upon this a few days ago: http://rayshobby.net/mediawiki/index.php/OpenSprinkler_Pi/Shell
I had trouble getting it to work at first until I figured out that OpenSprinkler running in the background was immediately killing any changes I made to the zones. I don’t know if it’s constantly writing out values to the board or if it’s monitoring for changes and then changing it back to how it thinks things should be. I had anticipated it would ignore things as long as there wasn’t a zone change of some sort happening inside of the OpenSprinkler software (time to turn this valve on/off, etc.) and was planning to do my tweaking during a time period where no programs would be running.
I suppose I could stop the OpenSprinkler software, run what I want, and then start it back up, but it would be nice if I didn’t have to as well.
Anyone have thoughts/suggestions here? Also, even though I didn’t write the bash script, I wanted a link here to it under the “Third-Party Software” section as I’ve found it quite useful and a quick browse of the code makes it pretty clear how you could hack together about anything to turn valves on and off (what bits to shove where).
The OpenSprinkler firmware sends out GPIO command to shift register every second (i.e. refreshes) to make sure the valve status remains in sync with the controller. If you want manual control through script, you will need to stop the firmware from running in the first place. Instructions are provided here:
https://opensprinkler.freshdesk.com/solution/articles/5000631599-installing-and-updating-the-unified-firmware#stopallThat link provides removal instructions which seem a bit like a sledgehammer. Maybe I’ll hack on the code. Worst case, I can just stop it, run my program (cobbled together some perl (calls the bash script rather than doing it myself because I was lazy…) for what I wanted), and then start OpenSprinkler back up. I’d prefer to not stop it at all though as that provides some insurance that should something go wrong with my other program, it’s still running.
I had considered doing API calls to OpenSprinkler, but the combo of fooling with things like the password hash for a local program and dealing with the fact that I was uncertain whether the call would trigger only the valves I wanted or also trigger the master attached to them (not wanted), I decided I wanted a little more direct interface to the valves.
Thanks for the confirmation on the OpenSprinkler behavior though.
You said “I had considered doing API calls to OpenSprinkler, but the combo of fooling with things like the password hash for a local program and dealing with the fact that I was uncertain whether the call would trigger only the valves I wanted or also trigger the master attached to them (not wanted), I decided I wanted a little more direct interface to the valves.”
I am honestly very confused by your statements: first of all, the password is md5 hashed but it’s static. For example, if plain text password is ‘opendoor’, the md5 hash is ‘a6d82bced638de3def1e9bbb4983225c’. It won’t change unless if you change your password. So I don’t know what you mean by ‘fooling with password hash’.
Second, if you don’t want a valve to trigger the master attached to it, then you can set that valve to not activate master. This can be easily set in the web UI / mobile app for each individual station.
Yes, I realize the hash is static. The call in general was just more work that writing a few values out.
The problem with the master is that 95% of the time I want everything attached to a particular master – and I like being able to hit the main menu and manually launch one of them with no fuss. This means I leave them associated with that master. My problem is the 5% of the time when I need a different master. I don’t want to be constantly reconfiguring the master to make it work, or running without a master (running valves in parallel) to get around the master issue because while the parallel approach works well in a program, it doesn’t work well when I want to just manually fire one off. Through and API could reprogram the master just so I could turn around and call the valve and get it to work the way I want, and then reprogram the master when I’m done, but that’s a lot of hassle for something that should be fairly simple. For the moment, I’ve got a quick and dirty script that simply stops OpenSprinkler, does it’s deal (for the fertigation unit), and then fires OpenSprinkler back up when it’s done. I don’t like stopping OpenSprinkler, but it works. I may consider modifying OpenSprinkler to get something closer to what I want. It’s been about 20 years since I’ve done serious coding in C, but I think I can get back up to speed fairly quickly if I decide I want to do it.
I do very much appreciate your Open Source approach 🙂
- You must be logged in to reply to this topic.