- This topic has 27 replies, 9 voices, and was last updated 3 months, 2 weeks ago by
.
-
Posts
-
I’m running OS 3.2 – DC with v2.2.0(1) FW.
I’ve updated my 3rd party app (for Crestron) for this FW version. No significant issues to far, though I’ve got more testing to do.
I have noticed a potential issue with weather server calls.
My app captures the weather server call info: last call time, last response time and return code. I last rebooted the controller on May 3rd. The weather calls were successful for 2-3 days after the reboot. Since then, for the last 6-7 days, they appear to fail with wterr = 1 (Bad Weather Data). I cannot tell if there were any successful calls during this time. Each time I look, I see wterr = 1, but that is not conclusive.
In looking at this, I’m wondering what the value of ‘lswc’ is . If ‘lswc’ is 0 when the response is not successful, then ‘lswc’ will be 0 whenever ‘wterr’ is not 0. When ‘wterr’ is 0 then ‘lwc’ and ‘lswc’ are approximately the same time (i.e. the time difference between when the call is made and when the server responds). It would be useful to know when the last successful call occurred. In that case you could see when the last call was made and the last time you got usable data. Please correct my understanding of this if I’m not looking at it correctly.
In order to see when calls fail and for how long the failure persists, I am going change my app to store the time of the last successful call. I will watch it for a few days. If there are no successful calls during this time, I’ll reboot to start the progression again. I will post what I observe
DaveUpdate
I gathered weather call statistics for the last 10 days. The call failure rate is 85%. The failure cause is always “BadWeatherData”
The description of this code is: /** The watering scale could not be calculated due to a problem with the weather information. */
It appears that weather calls are made every 6 hours. The longest continuous string of failures is 12.
Ray, I assume this behavior is not what you would expect. I’m not asking you to do anything. I’m just providing my observations in case it is useful to you. Let me know if there is other info you would like to see.
I’m located in southeast NH, USA. The OS is connected to my network via Ethernet. My app polls the device every minute or so with no connection issues. I have a reliable connection to my ISP.
I will update again after I reboot the OS and gather more stats.
DaveI rebooted OS and gathered statistics for another 10 days. After the reboot, weather calls were successful 100% of the time for 2 and a half days (10 calls). After the first call failure, the failure rate was 86%. The longest continuous string of failures was 12.
The return code on the call failures is always BadWeatherData. My limited understanding of this is that the call to the weather server was successful in that the server responded and provided information, but OS could not calculate a weather scale from the data. Either the server is not providing good data or OS is not dealing with the data correctly, but it is not an issue with connectivity to the server.The weather scale is never calculated on the OpenSprinkler controller itself. It is always calculated on the server. As you said, the server call itself was successful as it returned information, but BadWeatherData means parts of the weather data for your location is missing. For example, if it needs 24 hours of data and the weather data contains less than 24 then it will trigger such error. You can try to change your location slightly and try again.
Thanks for info about how the weather calls work, Ray. I find it interesting that calls are successful for about the first 10 calls after a reboot and they then fail at a fairly consistent rate (85%). I’m going to continue the run I’m on to see if I get similar behavior to the last 2. After that I will change my location and see how that affects the weather call responses.
Follow-up to the last exchange with Ray on June 11th:
I had already rebooted OS. Location was still my home location. I continued this run.
24 consecutive successful calls
After the first failure, there was only 1 successful call out of 21 calls (95% failure rate)I then changed to a location 1 town away. I hope that this is what was meant by “slightly”.
I did NOT reboot OS. Changing the location caused OS to start a new weather call sequence.
There was no continuous successful call sequence at the start.
The failure rate was 92% (25 calls, 2 Successful)I then rebooted OS and changed to a location 2 towns away.
23 consecutive successful calls
After the first failure, the failure rate was 90% (31 calls, 3 Successes)I have no more testing/data collection planned, but I will do some if there is another suggestion to try.
I’m also facing this issue recently on 3 of my OSPi running latest 2.2.0(2) firmware. I thought it might be due to fact of poor wifi but even at home with FTTH and perfect wifi connection over 5 GHz to my RPi running OSPi I have to change location dozen of times to finally pool data. I’m using PWS and both of them have 3+ years of data so there’s something odd during data poll from weather.opensprinkler.com.
@Ray – do you have any idea what can cause that? You can access logs on weather service to check if there’s anything in logs? I’ve got public IP at home so that should be easy one to track and see what’s up.What’s the error message? If you check System Diagnostics it should show Last Response, there should be an error message there. It’s possible Apple changed some API we can figure that out.
It’s Bad Weather Data – as I said fails to get weather data no matter if it’s via Apple or mine PWS running on site. I see those issues for past weeks now – OSPi reboot resolved problems but recently it does not help so I have to try manually sometimes 10+ time to finally get data from weather service and get Zimmermann calculations updated but then few more calls and issue occurs again.
It turns out this isn’t actually due to invalid weather data. Instead, it’s due to the firmware not receiving any response from the server. The firmware is supposed to tag this as error -1, but I think there is a bug that it did not prefix it with the negative sign. If you take a look at the API document:
https://raysfiles.com/os_compiled_firmware/docs/2.2.0/OSAPI2.2.0(1).pdf
at the very last page, it says any error code that has a negative value indicates network related issues such as the response not received, failing to connect to the weather server etc. Because it didn’t prefix it with the negative sign, the error code becomes positive 1 and the UI interprets it as bad weather data.Now, why there was no response from the server, that I am not sure. We rebooted the weather server and it looks like things are ok at the moment. Will monitor it over the next few days and see if the problem still exists.
@Ray something is still odd – I’m running 3 x OSPi in different locations – at home after 3rd attempt I got data from PWS, the rest of my systems cannnot fetch data – I’ve tried 10+ times now swapping between PWS and Apple provided weather without luck – I’ve got Weather Data Error all the time but I can see current weather without any problems.
I’ve restarted OSPi service, tried PWS and locations from different countries.Attachments:
I can confirm I’m seeing the same result as @cpu.
Brand new OSPi running latest FW. Current weather on the home screen looks correct but the System diagnostics show “Weather Service = Error” and “Last response = Weather Data Error”.Hi Ray,
Independent of the reason for the unsuccessful server calls (Bad Data OR No Response), the data pattern I was seeing does not align with the error only being in the server. I collected data over ~2 months. Each time I rebooted my OS, the server calls were always 100% successful for a few days and then started failing at a high rate.
Re: rebooting the weather server
I’m not currently collecting granular data, but I keep track of the last successful call. Looking at it right now (Aug 18, 2023 7:12AM), I see:
Last Server Call: Fri, Aug 18, 2023 3:09:57AM
Last Successful Call: Mon, Aug 14, 2023 9:07:00
Rebooting the server did not seem to effect whatever problem I’m seeing.Let me know if there is anything I can try to collect data. If you change the FW to address the possible error return issue and want me to test it, I will.
Dave
I’m running an OS3 and having the same issue which started a few days ago. Weather Service shows Error and last response says Weather Data Error. I’ve had only one or two successful calls in the last few days.
No wifi issues or network issues.
As I said, the weather data error is actually misleading, it’s not due to bad weather data, but it’s due to the weather server not responding with the correct output. We are trying to figure out why. It seems to have to do with either cloudflare or nginx configuration on the weather server. The error has nothing to do with the firmware or Apple WeatherKit. We are working on it.
In the meantime, you could try to use the weather server hosted by our German distributor Stefan. He has generously agreed to give me his weather service url:
opensprinklershop.de:3336
To use this, you can go to:
http://your_os_ip/su
where your_os_ip is your OpenSprinkler’s IP address, this should show a page where you can change the Weather url (note: Weather, not UI) to:
opensprinklershop.de:3336
once we figure out the issue with our weather server, I will post it here and you can change it back.Thanks Ray – swapped to Stefan weather service and all 3 OSPi working good with my PWS. I just recently bought another 2 x zone extender from Stefan shop – good to know he’s helping users when needed.
Will report in day or two after few updates. Cheers!OS 2.1 and 2.2 are failing because their firmwares can no longer be updated to the latest. The weather service API has changed due to change imposed by weather data providers. Firmwares on OS 2.1 and 2.2 do not send enough data required by the API.
Ray,
I understand they no longer are being updated via firmware, but are they now EOL all together. These controllers are unable to complete the simple task of getting the correct dusk to dawn settings? I can understand that they are not capable of utilizing new features but they should at least maintain their intended functionality. If they are indeed EOL then this should be posted somewhere. Thanks for any info.
They can still be made to work, by changing the firmware code to send the complete information required by the current weather API. I honestly don’t even remember that firmware 2.1.5 supported dusk to dawn setting (that firmware was from 8 years ago), I thought that was a much later feature.
I was affected by the same error and switched to Stefans weather server, which solved the problems! As a very welcome side effect, this server implements ETo for Wunderground just perfect! @Ray: Maybe it’s time to merge Stefans commit into your main branch?
Any news – I’ve got two stations that have to be rebooted periodically ~ 7 days as I’ve got errors mentioned in this thread – although I’ve changed the service url.
I had been having similar weather service call failures after I downgraded from 2.2.0 back to 2.1.7 with my hardware version 2.3 open sprinkler. I figured out what the problem was and wrote it up here.
https://opensprinkler.com/forums/topic/controller-lockups-crashes/page/7/#post-77396
I’ve been running the fix on my hardware version 2.3 without any problems for a month now. I don’t have access to any other hardware versions to test, but I suspect it has the same solution. So I have made my fix available with a number of builds for the various older hardware versions on my fork of the source on GitHub
https://github.com/darian-au/open-sprinkler-firmware/releases/tag/2.1.7(1)-weather
I would be interested to know if it helps with your problems.
- You must be logged in to reply to this topic.