- This topic has 7 replies, 3 voices, and was last updated 7 years, 10 months ago by
.
-
Posts
-
I’ve started to notice that for my installation (Zimmerman enabled, CA restrictions enabled, no customer Zimmerman ref) the main screen of the web app and mobile apps display a 200% watering percentage. I see this typically when I look at night. While I have not tested the specific bounds, I am suspicious that it would only occur after 21:00 PDT. The situation is typically resolved after midnight and certainly before my regular schedule starts. It is weird, however, and would be a problem if I wanted to schedule activity late at night.
Inspection of the weather diagnostics shows:
Note the hugely negative precip for today. This is what causes a huge watering percentage, which is then clamped at 200%. I checked by manually calling the wunderground API for my station and it returns:"precip_today_string":"-9999.00 in (-253975 mm)", "precip_today_in":"-9999.00", "precip_today_metric":"--",We cannot fix wunderground, but we could add some code to clamp precip values at 0 so this would not cause problems down the line. So that is the fix I am requesting.
I will check the weather script shortly, but I think if the weather data contains invalid values, the weather script will by default returns -1 and when the firmware sees -1 it simply does not change the watering percentage, and retains whatever it had from the last weather call. Is it possible for you to find a different weather station that does not return invalid data?
The particular weather station is not the problem. Wunderground is messing up during the interval where California (my location) is still in one day, and the wunderground servers are already in the next day. I am simply asking to make the weather script more robust so that negative precip values are turned into 0. That doesn’t fix wunderground, but makes OS more robust in the face of such issues and helps keep things watered properly. Sine negative precip cannot exist, this fix can do no harm.
I actually have a function to validate the input but I see now that Weather Underground also does -9999.00 (I was checking for -999). https://github.com/OpenSprinkler/OpenSprinkler-Weather/blob/master/routes/weather.js#L566
I will update the code to correctly address this ASAP.
Thank you
Update: I do attempt to convert negative values to 0 as it stands here: https://github.com/OpenSprinkler/OpenSprinkler-Weather/blob/master/routes/weather.js#L85 but testing shows it doesn’t work.
Update 2: This should be fixed now and was due to type casting the value to boolean which makes any number true. Commit: https://github.com/OpenSprinkler/OpenSprinkler-Weather/commit/58e5db163c039798790e03d30ee88b791709e85c
Unfortunately there is yet another problem (which I discovered tonight). When you use parseFloat to convert yesterday’s precip to a float there will be a problem if the string was empty (which does happen with wunderground apparently). This then results in NaN and when you attempt to clamp against 0 for both today and yesterday and add them together, the result of the addition is then also NaN. This in turn results in 100% in Zimmerman. It makes sense to interpret an empty value as 0.
I suggest adding
if (isNan(currentPrecip)) currentPrecip = 0.0 if (isNan(yesterdayPrecip)) yesterdayPrecip = 0.0alternatively
precip: ( (currentPrecip < 0) || isNan(currentPrecip)) ? 0 : currentPrecip ) + (( yesterdayPrecip < 0 || isNan(yesterdayPrecip)) ? 0 : yesterdayPrecip ),Attachments:
You are totally right: I just found this independently a couple days ago, and the fix is to simply flip the conditional operator:
https://github.com/OpenSprinkler/OpenSprinkler-Weather/commit/bf538ab0854a85ce6461772be1ef4e1d5a16f0bf
because NaN compared to anything would return false, the fixed code will assign 0 to the precipitation data if it’s NaN. The code has already been deployed. Let me know if you’ve observed any changes on the watering percentage on your side.
- You must be logged in to reply to this topic.