Some questions about the Weather integration

[Rondal]

Hi,

I’m fairly new to OpenSprinkler, but I do like it very much. I’ve installed it on a Raspi and connected and set up a relay board to play a little with some valves (24V AC).

Right now I’m testing the weather integration and the Zimmermann method. I think I understood the calculations in the method but I’ve a hard time finding out why it is setting water levels the way it does. The only location where I do find _some_ information about the weather data is within “System Diagnostics” but those values seem strange to me. The so called ‘Mean Temp” seems to reflect the current temperature. Precip Today changed from 3mm (yep metric 😉 to 0mm during the day, which makes no sense to me.

Also the Zimmermann method should also use average/mean values from yesterday. But I have no clue which data it is using. I’m not able to find something in the logfiles or somewhere else. There is also no notion of ‘Zimmermann’ in the sourcecode.

Brings me to a ‘side-question’: The Web-UI is loaded from ui.opensprinkler.com. I do understand why this is necessary with some of the supported hardwares. But is it possible to change it to local ressources?

Thanks a lot!

[Peter]

Sorry if duplicate posting, browser acting up.
———————————————-

@Rondal, so the change in service provided by Weather Underground has resulted in moving to a new weather service provider, OWM. This required a change to the zimmerman logic as OWM provides forecast data rather than historical data. So the Zimmerman calculation is now based on the average Temp and Humidity for the next 24 hours as well as the sum of forecast precipitation over the next 24 hours. This is different to WU. In essence, the new logic looks to ensure watering is sufficient for the forecast weather rather than replenishing based on yesterday’s weather.

But there are still some piece that need to be updated based on these changes and the Diagnostic popup in the App is one such area. Currently the Mean Temp, Humidity and Precip values are not those being used by the zimmerman calcualtion. Recognize that this causes some confusion and will be addressed soon. If you do want to see what the underlying inputs to the zimmerman calc are then you can call the service directly from a browser. The format is below but you need to update the loc to represent your lat,long and wto options to reflect what you have configures in the Zimmerman setup, i.e. replace the h,t,r with the % values and the bh,bt,bp with the baseline values (in imperial):

http://weather.opensprinkler.com/weather1.py?loc=51.5,-0.1&wto="h":100,"t":100,"r":100,"bh":70,"bt":59,"br":0

This should give a response as below where scale is the water level and rawData is the average temp and humidity as well as total precipitation over the next 24 hours. raining is an indicator of whether OWM believe it will rain in the next 3 hours.

&scale=20&rd=-1&tz=48&sunrise=268&sunset=1167&eip=3232235787&rawData={"h":47,"p":0,"t":54.4,"raining":0}

If you are seeing metric values in the UI when you expect to see imperial then make sure you have your location configured correctly in the Map page of the App as the locale is driven from that information (i.e. generally metric unless location is US and a few other countries).

The UI assets can be hosted locally and instructions are on the OS Support site here

[Rondal]

Hi Peter,

thanks for your answer, that helps out a lot. I could not find the information that the new method uses forecasted data instead of yesterdays data. But with that in mind everything makes more sense.

But I still have a strange effect when trying to confirm what I’m seeing.

My Baseline (configured in OS) are: Hum 65%, Rain 0mm, Temp 21°C
So I called:

http://weather.opensprinkler.com/weather1.py?loc=49.45564,10.92549&wto="h":50,"t":50,"r":100,"bh":65,"bt":70,"br":0

The location is taken from /ja API call the other values from my config and converted to imperial.

The result I got was:

&scale=0&rd=-1&tz=56&sunrise=329&sunset=1259&eip=3166926217&rawData={"h":81.2,"p":0.39,"t":60.5,"raining":0}

So it wants to reduce to 0% water level.

Humidity: 65% baseline – 81.2% actual = -16,2% * 50% weighting = -8,1%
Temp: 70°F baseline – 60,5°F actual = 9,5°F colder than baseline = 9,5 * 4% * 50% weighting = -19%
Rain: 0.39 difference to baseline (0) = 39 * 2% = -78%

Overall 100% – 78% Rain – 19% Temp – 8,1% Hum = -5,1% watering which obviously bounds to 0%.

That does make sense to me. But that’s not what I’m seeing in the interface. If I do system diagnostics (and I guess that the values just reflect the returns from what weather call and that just the captions are wrong) I see the following:

Hum 55%, Temp 18.9°C, Precip 3mm (beware of the unit change) and it wants to water 21%.
If I do the same calculation as above:
Hum: 65% – 55% = 10% * 50% = +5%
Temp: 70°F – 66°F = 4°F colder = 4 * 4% * 50% = -8%
Rain: 0.12 inch = 12 * 2% = -24%
Total: 73% watering

So I do have two problems here. 1. I’m not sure why I get other values when calling the weather service than my OS. Granted my call was half an hour after the last successful call of OS, but that should not have such an impact with a weather forecast? 2. My calculations seem off. They are based on the explainations in the forum but might be wrong.

Every input is greatly appreciated. I’ll dig into the source of the weather service in the meantime.

As for the local UI assets: Thanks. Just was to stupid to find that article in the docs 😉

[Peter]

Rondal, the first set of calculations look correct and match what I can calculate here. The precipitation is what is driving most of the impact. The scale,i.e. 0%, should match the Water Level presented in the UI via the App unless the OWM forecast has changed materially. This might occur if the precip forecast by OWM has increased in the last half hour. You can “force” the App to update the Water Level by going into the Map and slightly changing the location and then saving/submitting. This might make it easier to get two similarly timed calls (one via App and one direct to Weather Service) to compare.

Note that the Diagnostic page is not about miss-labeling. The actual values are not what is used in the Zimmerman calc. The values shown are the “current” temp, humidity etc rather than the forecast values. So using those to try any diagnose will not help. If you are going to go into the source then note that “master” is a good many commits beyond the live production service.

[Author]

Posts