OpenSprinkler › Forums › OpenSprinkler Unified Firmware › Wunderground, CA Water Restrictions Reliability
Tagged: California percent
- This topic has 22 replies, 4 voices, and was last updated 7 years, 5 months ago by DaveC.
November 22, 2015 at 7:58 pm #40797
I really need to find some peace of mind and solution. I have 3 controllers right now and it is my intention to eventually deploy about 30 of these units but I need some reliability and peace of mind. I currently have 1 2.1 hw version and 2 2.2 hw. I am running 2.14 FW on one 2.1 and one 2.2 hw versions and I am running 2.16 on one 2.2 hw versions. My wunderground key is correct, and when I log in to the wunderground site I see I am pulling json updates. My controllers are showing the correctly forecast info, but pressing the weather test button on any of my 3 devices they are unable to pull date. The 2.14 fw versions were showing 200% watering percentage and the 2.16 was showing 0% with a water delay out to January 2016. They are all set to CA water restrictions. The 2.14 were on manual but I moved them to zimmermar, but than that debunks the CA restrictions based on my shrub heads. The 2.16 is set to CA restrictions with AutoRain Delay.
I really need some help here, I don’t have a problem with giving you remote access to them. Give me some guidance. Also, is there any way to add an indication as to what fails when pressing the weather diagnostic test. Is it unable to look up the address, does it reach the wu website, I mean there is nothing to go off of.
Your assistance is greatly appreciated.
edNovember 25, 2015 at 12:56 am #40819
Sorry to hear about the issues. To make sure we are on the same page:
1. You said one controller is set to use auto rain delay, and that set a rain delay to January 2016, is that correct? I assume the other two are on Zimmerman’s algorithm?
2. Check ‘Weather Diagnostics’, which you can access the sidebar menu. Check ‘Last Successful Weather Call’ (there is also an item called ‘Last Weather Call’, which indicates when the last call was sent out, but it’s the successful call time stamp that indicates the correctly received call). Is it up to date? If this is not up to date, that means it’s not getting the returns of the weather query.
3. If the last successful weather calls are up to date, then there is probably some issue with the weather script that causes incorrect calculations. We’ve received one previous report of the auto rain delay setting a overly large delay time, so it may be due to a bug in the script and we will check immediately. For the Zimmerman algorithm, however, the issues we received were mostly due to unsuccessful weather calls, and were due to a bug in firmware 2.1.4. The latest firmware 2.1.6 has fixed the bugs and should be pretty reliable in getting weather query results.November 25, 2015 at 1:19 am #40821
Just a quick update: regarding the extremely long rain delay issue, I have found a potential bug in the weather script that is likely the cause. It’s triggered when the ‘delay duration’ parameter is undefined (which you can set using the Tap to Configure button underneath the Weather Adjustment method). Basically when this parameter is undefined, the script uses a default of 1 day of delay time. However, the default value assumes units of minutes while the firmware assume units of hours, so once triggered, it leads to a delay time of 60 days instead of 24 hours, and this seems consistent with the issue you reported (that the delay time is till Jan 2016).
We should be able to fix this immediately. In the mean time, the work-around is to click on that ‘Tap to Configure’ button, adjust the delay time as you need, and submit. This way it should avoid the bug from being triggered.November 25, 2015 at 12:10 pm #40825
Here are some pics of the 3 controllers from today. I am not able to pull data. I also included a snap shot of the wunderground stats showing I am pulling data.
The controller pics show that my wunderground key is verified, and also the forecast is up to date. But when I press the weather dignostic button on any of the three it sais it failed.
I have 2 units deployed one 2.2 and one 2.1 hw versions with the 2.14 fw. They are about a 1/2 mile away but connected to my wireless mesh and assigned an ip from my buffalo router running which is running dd-wrt. I have the third unit with 2.16 FW hw 2.2 running as a test unit on my desk with direct lan to my network.
Attachments:November 25, 2015 at 12:16 pm #40830
I am not seeing this in my firmwares. Can you let me know where to find this?
‘Last Successful Weather Call’ (there is also an item called ‘Last Weather Call’,November 30, 2015 at 3:38 pm #40869
So the controller running 2.16 is at 0% watering. It rained here on Thursday last week. The other 2 controllers are at 100%. I really need to get to the bottom of this.November 30, 2015 at 5:38 pm #40871
So I made a little headway, maybe you guys can help me diagnose this. I Reset the controller options and Station Names on the 2.16. After which I was able to start to pull weather information. I then re-imported my settings and it would fail. So I reset it again. Interesting when you do the reset it keeps your wunderground key but not location. It also keeps your programs. So I re-entered my station names and setup the controller and it is not pulling weather diagnostics.
So I tried this on my 2.1 HW version with FW 2.14 and it fixed it as well. I did the same tests importing the json file and then the weather would fail. So I reset it and reprogrammed it again and it seems to working as well.
I saved my json files, I will attempt to export my current setup and then re-import to see if it works or maybe this could be the source of the problem.December 2, 2015 at 12:46 pm #40897
Ray, I can confirm what dun4cheap is saying. I am running version 2.16 and I stuck on 0% after our usual California 0.01″ useless drizzle. I have to manually re-up it to 100% 48hrs+ later.
So the controller running 2.16 is at 0% watering. It rained here on Thursday last week. The other 2 controllers are at 100%. I really need to get to the bottom of this.December 6, 2015 at 11:38 am #40930
About last successful weather call timestamp, there are two ways to find it:
1. In the app/UI, open the sidebar, and click on ‘Weather Diagnostics’. It should show ‘Last Successful Weather Call’.
2. You can also find it on the controller using buttons: B2+B3 (i.e. press B2 first, then while holding B2, press B3, similar to how you would do Ctrl+A). This will show the last successful weather call time stamp.
If the last successful call timestamp is outdated (more than several hours compared to current time), that means the controller is not getting weather results. One common cause is if you are using static IP, make sure the gateway (i.e. router’s IP) is also set correctly otherwise the controller cannot get incoming packets. If the last successful call timestamp is up-to-date (within one hour of the current time), that means either the weather data reported by Wunderground has an issue, or the weather script is not calculating the percentage correctly, which we can investigate further.December 6, 2015 at 12:22 pm #40936
Although my ‘Last Successful Weather Call’ was not likely to be a part of my ‘California restrictions problem’ I checked it anyway. No problem. Looks like it is updating hourly. For reference, California restriction initiates okay but after several days watering is still 0% and must be returned to 100% manually. If also set in Zimmerman, I am not sure if the problem occurs. We have had so little rain I can not test much.
BillDecember 7, 2015 at 2:13 pm #40941
Giving this more thought, I am only using the california restrictions with Auto Rain Delay, so this should not adjust the watering percentage at all. Only delay it.
I will continue monitoring my systems for frequently to make sure they are functioning as intended.
My other problem with pulling weather data from all three, seems to have been solved my re-updating my location. GPS coordinates. I am not sure why but I will continue to monitor this as well.December 7, 2015 at 3:13 pm #40942
Good point dun4cheap. I assumed that watering % was used to implement an inhibition of watering. That may not be the case. There has been so little rain I can barely test.December 15, 2015 at 7:12 pm #40991
So, I am anxiously waiting to see if the water percentage goes back to 100%. My water delay is set to expire today at 22:00 hours. How are you doing with your devices William?
Ray, since I am running lights on my devices from dusk to dawn, I am not able to see what the rain delay has been auto set to on 2 of my devices. Is there away to make this information available from the web interface? Of for that matter any way to get it at all, there is a different alert on the bottom? This option would be very usefull. Maybe there is already an option and I am just not seeing it. Any info would be appreciated.December 15, 2015 at 9:03 pm #40992
I have more hours to wait before I see if the watering % moves up from zero. I can report day after tomorrow
This is the water station in the backyard.December 16, 2015 at 12:23 pm #41011
I have submitted another ticket to Ray, the California Water Restrictions definitely is not working correctly. It appears to be applying the water delay, but it sets the water percentage to 0%, so after the delay has gone and past, the water percentage stays at 0%. Personally the percentage should only be controlled by the zimmerman or other programs. The current California restriction should be a rain delay.
William I look forward to seeing what you have to report from OC.
My location is San Diego, CA in the 92126 zip code. So our last day of Rain was late Sunday…December 16, 2015 at 6:48 pm #41021
Alright, so here is a picture of my CA Water Restrictions settings. The water percentage was at 100% but then we got rain. Which set the controller on to a water delay of 48 Hours and set the water percentage to 0% for some reason. The water delay expired on December 15 at 22:27. Yet the water percentage remained at 0%. I am not sure why the water percentage would have changed with my settings, as the CA Water Restriction is not based on watering percentage.
Also, note on the bottom of the screen the alert which shows the last run station which in this case are Area Lights that run from dusk to dawn. So I can only get one alert, so the rain delay alert was not accessible on this device. There needs to be a way to view multiple alerts, whether it is a button or we click on the status alert below to display more. Maybe there is a way an I am just not seeing it.December 16, 2015 at 6:49 pm #41022
Yup, I am still sitting at 0%. The problem confirmed. Since you already have multiple tickets submitted, I will not pile on just yet. I assume ray reads these posts.
BillDecember 17, 2015 at 9:46 am #41028
I don’t live in CA but I’ve been following this thread. I’ve integrated OS into an automation app so I’m interested in the reliability of the device and getting info that helps users know when something is not working as expected. I don’t have a solution but here’s some info on how to get current rain delay info (and a suggestion for Ray).
Relative to seeing rain delay events, I assume you know that you can see historical ‘Rain Delay End Events’ in the log file which show what the duration was. I know this works for manually created rain delays. I would think it would be true for auto set delays too but have not tested. Have you’ve seen some expected auto rain delay events in the log file? For troubleshooting problems like this it would be good of the log file contained an event for when the delay started and what the duration will be (Suggestion).
Current rain delay info is available from the API. You can issue API commands from a web browser. The command would look like:
http://192.168.1.80/jc?/pw=%5Bwhatever your MD5 hashed pwd is], replacing 192.168.1.80 with you OS’s IP address
The response will contain info that tells you if rain delay is in effect and when it will end (described in the API doc).
For Rain Delay;
“rd”:1 means rain delay in effect (0 would be no rain delay)
Rdst”: 1450380976 is the stop time. It’s in epoch format. There are converters in excel or you can subtract the value in “devt” from it. The result will be the number of seconds left in the current delay (devt = the current time).
DaveDecember 17, 2015 at 11:03 am #41030
Interesting enough my background is hardware and software engineer. When I first bought my first opensource controller it had just hit the 2.1 hardware version. The webgui was very primitive and there was no android app. My hopes for the controller was to roll it out in a large HOA as an affordable weather base controlled device that I could control centrally from my computer. So I started writing control software to do just that. The API was very effective. It was almost complete and then Samer came aboard with Ray, and the controller now had a more robust web gui and android app.
So I busted out my code last night and began to update it to the new api which changed quite a bit since 2.04 but it is almost done. I will be keeping it updated to diagnose my controllers. Samer, contacted me yesterday so I know he is working on the current problem, and hopefully adding the ability to check the alert history from the web gui and android app as well. Both Ray and Samer have something really good here and it really has come a long way in a short period.
EdDecember 17, 2015 at 11:22 am #41031
Yup, as we probably both expected I am stuck at 0%.
Here’s my log:
Rain delay is off but watering % remains zero.
BillDecember 18, 2015 at 11:26 am #41039
Seems like a nice application for OS. I’d be interested to know what you see as the key features from a central control/monitoring perspective and if you find ways to know when something is wrong, without visual inspection.
The model I have for integration with automation systems (in this case Crestron) is to provide simple controls (enable/disable, manual run, etc.), quick visual monitoring (zone/program activity), and notifications, particularly when something is wrong. I let OS and the supplied Web UI and Mobile App do what they do best: configure, program, schedule. Of course, you can still use the supplied tools for any purpose.
Determining when something is wrong is the most difficult. Having to regularly monitor the OS log or noticing that plants are drying out are not the best ways find to find out. People want automatic weather based adjustment and everything to just work as they expect, but in the case of some failure they want to be notified of a problem before they incur landscaping damage and cost.
Personally I don’t use the auto adjustments because I don’t think they reliable enough yet (not just with OS) and I don’t have good enough ways to spot problems ahead of time. Knowing that server calls are not working is a simple check but knowing over time if the weather based adjustments are correct and if they are what you need across your various irrigation zones is a bit harder.
DaveDecember 18, 2015 at 1:17 pm #41040
I manage a very large HOA community is about 69 acres. I have over 40 controllers with an average of 24-40 irrigation stations on each one. Along with this I have common area lights that are controlled on Intermatic Timers/Dusk to dawn sensors which control these.
So when I first came across Rays Hobby project when it was just at FW 2.1 it had a very primitive web interface. I had communicated with Ray during this early process. So for me the control center would allow me to monitor all of these controllers all in one central point. I was also going to add the dusk to done features for the lighting as well and possibly some electro-magnetic dead bolts as well.
The design of my control software would be 2 options, to let the timers run in auto mode, or in manual mode and let the control center actually be the controller, the os units take direct command from a central control point.
Then Samer came aboard and the web interface had a complete overhaul and dusk to dawn features were implemented. So I stopped working on my control center. But the other night I busted it open and updated the api calls to the 2.14 and above and at minimal will get it going to be a diagnostic tool. Also, since I have monitors (security) with smart phones that monitor gps detex, parking monitoring, and area cameras, I will be able to give them access to the common area lighting controls and any other controls I choose to without giving them full access.
So I am using Ubiquity AP’s in conjunction with Open Sprinkler devices, 24vac Relays and Hikvision cameras which are all tied in together to give an affordable option for Weather based irrigation control, lighting controls and in one swoop create a wireless wifi mesh for our security cameras.
In any event probably more info than you wanted to here, but overall the systems work well. The OS devices have been reliable, and with Samer and Ray on the job of ironing out the little quirks of the FW, the web gui interface will work.
What would be nice in the webgui is to have more pertinent status information on the main page always.
Here are a couple pictures to see this in action.
Attachments:December 18, 2015 at 4:41 pm #41045
Very cool. And not more than I wanted hear. I like seeing how people solve problems using control and automation technologies There’s sooooo many different kinds of solutions possible.
Re: main page of the webgui
I think its difficult to design a single UI to cover such a broad range of users, from an expert user managing 40+ controllers to a single non-technical resi user. Your control app allows you to custom design a UI and the underlying functions to fit your needs. The web and mobile apps can still be used when appropriate. You can focus your app on the things that make managing a big installation easy for you and modify it over time as you refine what’s needed.
Providing a status-at glance dashboard and diagnostic functions seem like items that would be useful to you but difficult/time consuming with the supplied UIs.
Thanks for sharing
- You must be logged in to reply to this topic.
OpenSprinkler › Forums › OpenSprinkler Unified Firmware › Wunderground, CA Water Restrictions Reliability