OpenSprinkler Forums OpenSprinkler Unified Firmware Current State of the Weather Script

Viewing 9 posts - 1 through 9 (of 9 total)
  • Author
  • #60952


    On behalf of the OpenSprinkler development team, I would like to update users on the current state of the weather script. I acknowledge that due to the recent transition from WeatherUnderground (WU) to OpenWeatherMap (OWM), the weather data quality decreased and the weather calculation became unreliable or even un-usable for some users, and there were several program bugs that were only fixed fairly recently. This has caused a number of complaints and I would like to sincerely apologize for the issues. Below I briefly summarize what are the challenges with using OWM data, what we have been doing to address these issues, and some further thoughts.

    1. Due to WU discontinuing their service at the end of last year, we had to quickly switch to use OWM. Some key weather data, such as the average temperature of the previous day, average humidity of the previous day, the precipitation of the previous day etc, are suddenly not available any more. As a result we had to adapt the script to use the average forecast temperature / humidity / precipitation of the day instead of the measured data of the previous day. This caused some discrepancies in the calculated watering percentage, which were quickly noticed by many users.

    In addition, OWM only provides temperature / humidity of the next 24 hours (from the time of query), instead of on a calendar day basis. This led to the calculated watering percentage fluctuating during a day, instead of remaining a fixed number during the day. We refer to this as the ‘rolling window’ approach. There are pros and cons of the rolling window. The main advantage is that the calculated watering percentage is more closely tied to the dynamic weather changes. For example, if there is any real-time update on rain forecast or temperature changes, these will be more quickly reflected in the calculation. The main downside is that this is not what we used to do in the past, so some customers noticed this change and dislike the rolling window method. Some are concerned that the fluctuation causes the same program, if it runs multiple times during a day, to have varying water times, which is not ideal.

    We understand these concerns but feel that the rolling window approach just takes some time to get used to. We don’t think either fixed or rolling window is obviously correct or wrong, they are just two different methods. We’ve done extensive experimental studies of the rolling window for many sampled locations and found that the fluctuations are generally pretty smooth for all the sampled locations thus shouldn’t be of a major concern. At any rate, due to the availability of data provided by OWM, there isn’t much we can do about it, so for now we have to just stick with the rolling window.

    2. Some users reported that the quality of data provided by OWM is inferior to WU. For example, the rain forecast by OWM for some locations are rubbish; and there is a notorious bug where the rain data returned by OWN is always in units of mm, regardless of what units have been requested. We’ve identified these issues and have already addressed them in the current script. One related issue is that back when we had WU, we used to have a logic where if it’s raining outside right now, we set the watering percentage to 0%. But because OWM rain data is sometimes un-reliable, this caused the watering percentage to be stuck to 0% unexpectedly. Some users thought this is the consequence of using the rolling window, but it’s actually not related at all. We’ve now removed this logic so the chance of watering percentage stuck to 0% is minimized. The OWM bug with rain unit has also been addressed a while back.

    If you notice that the weather data for your specific location is far from accurate, please try to change your location slightly and see if it makes any difference. Our calculation is only as good as the data OWM provides, so if their data is not good, there isn’t much we can do about it. But we believe for most locations their data is sufficiently accurate. For some users this may take a bit of trial and error to find the perfect location around you.

    3. There have been numerous recent efforts to improve the weather script in various directions, as shown by the active commits in the Github recently:
    A lot of features have been added or are under development, such as adding support for additional weather service providers. In particular, for users who have personal weather station (PWS), you can now host the weather script on your own local server and direct OpenSprinkler to use your own script. This will generally provide more reliable data, and the ability to further customize the script if you want.

    In addition, we have an initial ET (evapotranspiration) implementation that is close to being finished and hopefully that will be released very soon.

    So in quick summary, many issues caused by the transitioning from WU to OWM have already been or are currently being ironed out, and the project is under active development. I hope this post addresses some of the major problems recently raised on the forum.



    Hi Ray,

    I appreciate the update, hard work and humbleness in your response. I’m fairly new to OpenSprinkler, having only been a user for about a year. Unfortunately, my timing coincided with the weather adjustment changes.

    What I noticed when setting a sprinkler run time early in the morning with weather adjustment, the watering times were very close to zero. Even when the day may have been very hot and humid. I found that the weather adjustment would really only provide ample adjustment (up and down) if run time was at or near the highest heat portion of the day.

    What can we expect moving forward with this new “rolling window” method? Can you outline an example of how to set watering times so that watering is actually adjusted up and down when needed? Thanks!



    We plan to add an option in the firmware to smooth out the watering percentage (basically keeping track of the call results of the previous day and take the average of all of them). This will make sure it gives a single number per day.

    At the moment if you notice significant fluctuation in the watering percentage (like more than 30% in the morning vs. evening) that’s likely due to predicted rain — as I said, the rain prediction by OWM can be quite unreliable so that can result in large changes. One solution is to suitably reduce the weight of ‘rain’ which you can adjust in the weather options.

    Temperature and humidity is unlikely to result in significant fluctuations because the rolling window is already taking the average of temp/humidity of the next 24 hours. Even if they vary across a day, the average over the next 24 hours usually does not change very much. So as I said, any large variations is likely caused by incorrect rain prediction.

    You can submit a support ticket with your specific location, and we have a script to track the watering percentage for your location for a couple of days, which can show where the fluctuation is coming from.



    @Ray Is there a schedule for realizing the plan to smooth out the watering percentage? Will it be an update of the OpenSprinkler-Firmware or the Opensprinkler-Weather script? It would be nice to get some more information on future OpenSprinkler changes or improvements.



    I don’t think the smoothing is necessary any more: for one, we’ve done a bit more study on the rolling window and found that the resulting watering percentage is already quite smooth, so I don’t think additional smoothing is necessary; also, we’ve been making a lot of changes to the weather script and several new additions will be available soon, including additional weather service providers (such as darksky) that provides daily average weather data (so no rolling window is needed any more), and also an implementation of ET algorithm will be available soon. These will be made available without having to upgrade firmware.



    Ok. I have looked in more detail at the OpenSprinkler-Weather script. I’m not a Node.js expert. However, there seems to be a bug in the local.ts file. If we change the sequence in the getLocalWateringData function to first using today’s weather and second using yesterday’s weather as watering data everything works fine. Yesterday’s weather summary is captured every midnight and used to calculate the watering percentage of the ongoing day. There are no fluctuations at all in the watering percentage. In case of rain during the ongoing day the watering percentage is adapted as expected.

    I can only speak for local PWS users who host the weather script on their own local server. With the above adaptations the weather script provides the same functionality as known from the “old Wunderground days”.



    Some additional remarks: The current implementation of the OpenSprinkler-Weather script doesn’t set the watering percentage to 0 if it starts raining. This is due to the bad weather forecasts in regards to rain prediction. At least for Netatmo PWS there is a workaround to stop watering if it starts raining.

    A single IFTTT applet: Rain detected – Stop sprinkler operation is used to stop any sprinkler activity if it starts raining.

    The corresponding API command is: /cp?pw=xxx&pid=0&rd=3 (Set a 3-hour rain delay)

    In general the rain detection depends on how fast the rain gauge will be filled with rain and how fast the IFTTT applet is reacting. This can take some time, if e.g. there is no remarkable rain falling. In worst case scenarios there is always a chance of running the sprinkler in parallel to the rainfall. However, my experience shows that using weather forecasts for stopping the sprinkler are not conducive. Especially in Germany weather forecasts sometimes predict rain during the day, which never results in any rainfall at all.



    I have also found that since moving to OWM.
    The high temperatures for Sweden is completely off the mark most of the time. When I look in the OpenSprinkler app, it looks more like the average temperature than the high.
    During nice summer days here we often have 15C during the night and 25C during the day, but typically see 15C as the low and 17C as the high.
    I have looked at other areas in the vicinity, but it makes no difference.

    To some extent this can probably be blamed on OWM, but it might not be the whole story.
    I wrote to OWM here, but did not get much of a response:



    If you find the average temperature reported is consistently underestimated, you can adjust the temperature baseline number (the default is 70 degree F). You can lower it accordingly.

Viewing 9 posts - 1 through 9 (of 9 total)
  • You must be logged in to reply to this topic.

OpenSprinkler Forums OpenSprinkler Unified Firmware Current State of the Weather Script