Forum Replies Created
-
Posts
-
I came here to post this same problem, with my last successful weather call being on May 27th. A reboot fixed the problem though. I attached before and after reboot screenshots for debug purposes.
Attachments:
Sorry for the long post, I had a lot of ideas. Not sure if they are helpful but here goes…
I see how that could get tricky with multiple overlapping stations that are sequential. I think the solution, at least part of it, would have to rely on some level of user common sense. Your example, for example, doesn’t seem to make any practical sense to me. I don’t see why anyone would set up two programs this way. But at the same time you want a clean and straightforward user interface where there is as little room for user error as possible.
All of my sprinkler stations are sequential except for my two backyard light stations. Maybe you could restrict the end time feature to non-sequential stations only? Theoretically, if you want a particular station to end at the same time every day, then you have a specific time in mind when you want that station to stop. Therefore, the sequential option wouldn’t make much sense. So the end time option would have to be enabled only for non-sequential stations, or take precedence over the sequential option.
I think the same thing can be said about weather adjustments. I’m not at all concerned with weather adjusting the duration of my backyard lights. They need to turn on at sunset and off at 11:00pm every night. Any program with a specific end time should also not be concerned with weather adjustments as it just doesn’t make sense. Similar to above, the end time could take precedence over the weather adjustment.
The way I now see this playing out in the UI is something like this:
Below the Start Time on the Add Program page, a new option for End Time is available but not selected. If a user selects this option and enters an end time, the Use Weather Adjustment is disabled. The user can then select which stations for this program to apply to via checkboxes, not a station specific duration (kinda like how the old firmware worked). The only stations available to check would be those that are non-sequential (alternatively, this program could take precedence and disregard the sequential option for a particular station if checked).You should definitely update. There are many new features. Also, the firmware is now unified, meaning the OSPi, OSBo, and original OS all use the same code making new updates easier and available for all types at the same time. To update follow this tutorial:
In order to connect to your raspberry pi you’ll need to use Putty (windows) or Terminal (osx).
These are the official instructions if you need more info:
https://opensprinkler.com/forums/topic/announcing-opensprinkler-unified-firmware-2-1-4/
Yes you can use any installation with opensprinkler. Each valve has two wires, one ground and one positive. You hook up all the ground wires together and plug that into the COM on any controller (including opensprinkler). You then plug each positive wire into each station as you see fit. You can choose to combine a few valves if you have enough water pressure. This determines your “zones.”
You get web access by connecting the raspberry pi to your home wifi, and then by installing the opensprinkler program.
If you already have a system in place all you would need to do is disconnect the existing wires and plug them into the opensprinkler.
Thanks for your response. If I may, here is a suggestion how to implement this without completely reorganizing the programs data structure:
When a user clicks on the duration setting for a station, add a section for selecting the end time below the sunrise and sunset area. The duration well be greyed out when the user starts entering info about end time. When submitted, the program calculates the duration based on when the station will start and the selected end time (I’m assuming this is how the current sunset to sunrise option works). This duration can then be saved in a similar manner as if the user selected the duration explicitly. This duration will have to be recalculated once every day as the sunrise and sunset times will change, but I’m assuming this must already occur for the sunrise to sunset option to work.
I can see not wanting to go this route as the pop-up duration screen might get a little busy, but I’d be curious to know your thoughts on this method. Thanks!
Depending on how big of a yard you have this can be quite involved, but also very rewarding. There are many tutorials online how to do this yourself. I suggesting reading a few of them to get a understanding of what they process will entail. A quick Google search of “sprinkler installation diy” yielded many good results. This looks like a good one to start with: http://www.diynetwork.com/how-to/outdoors/landscaping/how-to-install-a-sprinkler-system
If you need detailed help with a specific part you can always post it here. Reddit is always a good resource for help with specific questions, you just have to find the right subreddit. This would probably be the one to go to for help with a diy sprinkler install: https://m.reddit.com/r/Irrigation/
Ray, if I understand you correctly, the next update will allow for the ‘duration’ to be the time between sunrise and sunset (or vice versa), but not a specific time of the day? If so, I think I there are many users who would like to have a specific stop time implemented, eg turn lights on at sunset and off at 11:00pm every night. I personally don’t want my backyard lights on all night while sleeping. If this is already the case with the new update then please forgive me for this wasted post.
Thank you as always for your hard work on this project, it is truly enjoyable seeing OpenSprinkler grow and evolve.
Awesome, thanks! Am I able to get this update right now with a git pull, or do I need to wait for an official release?
Just wanted to give you some debug info for trying to fix the ‘Network Error’ issue. I modified your script a bit to output the time when it has to restart the OpenSprinkler program. Also, for some reason unknown to me, I was unable to login to the web interface after a restart with your script, but I was able to if I restarted it with the following command:
sudo /etc/init.d/OpenSprinkler.sh startSo I created the following script and made a cronjob to run it once a minute:
#!/bin/bash while ! ps ax | grep -v grep | grep OpenSprinkler > /dev/null do echo "OpenSprinkler not running...restarting... $(date)" /etc/init.d/OpenSprinkler.sh start sleep 1 doneHere is my log file:
OpenSprinkler not running...restarting... Thu Apr 23 08:44:01 EDT 2015 OpenSprinkler not running...restarting... Thu Apr 23 11:31:01 EDT 2015 OpenSprinkler not running...restarting... Thu Apr 23 18:53:02 EDT 2015 OpenSprinkler not running...restarting... Thu Apr 23 19:34:02 EDT 2015 OpenSprinkler not running...restarting... Fri Apr 24 02:04:01 EDT 2015 OpenSprinkler not running...restarting... Fri Apr 24 08:57:01 EDT 2015 OpenSprinkler not running...restarting... Fri Apr 24 16:12:02 EDT 2015Please keep in mind I had to manually restart the program at the ‘Thu Apr 23 19:34:02 EDT 2015’ timepoint.
Hope this helps.
That makes sense, thanks for the explanation.
You are correct in that this discrepancy does not occur when using specific start times.
Ok I figured this one out. Station blocks show up 5 mins early on the Preview Programs screen. That is, the display block for a program will show up 5 mins earlier on the timeline than it should. I created a 5 min long run of one of my stations to confirm this and watched the time bar on the Preview Program screen. The station did in fact turn on at the very end of the 5 min time block.
Just checked, the sunrise and sunset times are accurate. The preview page shows the appropriate timing, but the station doesn’t actually turn on.
I have a similar problem on my OSPi (Model B) as @JohnC running the new unified hardware. I will get the “Network Error” message after a couple of hours of the pi being on. This happens on both the local and remote connections. I have correctly set up port forwarding. After it happened, I logged in the the pi via ssh and checked to see if the OpenSprinkler executable was running with:
gprep OpenSprinkler
but it wasn’t running. As soon as I ran the program again with:
cd /usr/local/OpenSprinkler
./OpenSprinklerthe app connected and the “Network Error” message went away. It seems the app is shutting down on its own? Is there is a log file that I could find to give clues as the why this is happening?
Wow that’s fantastic! I commend you for being so prompt in responding to your community and adding requests. Thanks! Looking forward to the release.
I would also like to see a feature that would allow a program to start and end at a time related to sunrise or sunset. Start time is already implemented and works great. I understand that the data structure uses ‘duration’ and not an ‘end time’ per se, but it would truly add great functionality to the system. It would be great if the end time could be specified not only in relation to sunrise/sunset, but also a particular time of the day.
I forked Dan’s python program and wrote a plugin to achieve this functionality, but it is becoming a bear to update my fork and merge with the original. I appreciate your effort it making this a feature in the unified firmware!
You might find this helpful: https://opensprinkler.com/forums/topic/new-plugin-and-fork-to-support-sunrise-and-sunset-program-timing/
Looks interesting. Would you mind sharing your pulseway configuration file (without your account info of course). I would like to try this.
Thanks!
Edited to add:
If anyone else is interested, this is the line I used to monitor the ospi service:
<Service Name=”ospi” DisplayName=”Open Sprinkler Pi” path=”” IsDaemon=”true” DaemonType=”SYSVINIT” Path=”” StartParameters=”” CanBeStopped=”true” Enabled=”true” />
Ray, thank you for your assistance. In my online quest for a solution I came across this neat toy, the PowerSwitch Tail II.
The input takes anywhere from 3-12V to trigger the device, so if I use a voltage divider to lower the output voltage from the OSPi, I should be able to control this nicely from the OSPi. Do you see any problem in my logic?
Looks like that worked for me too! At least I no longer get an error. For those who are getting similar issues, this seems to be a temporary patch. On the Options page, go to the Location text field and instead of your zip, put “pws:” (for personal weather station) and enter the Station ID of the closest weather station to you.
