no more free Wunderground API key?

[ottorino]

I made some experiments during the night.
Two programs unattended plus one attended
1) start 2 hours before sunrise, no climatic correction, unknown water level. Executed and logged
2) start 1 hours before sunrise, climatic correction, unknown water level. Not executed (no water on the dry soil this morning) and not logged
3) start 3 hours after sunrise, climatic correction, 133 % water level. Executed with correction and logged

I presume that during the night the water level drops to zero and this inhibit the execution of the programs.

Attachments:

1. 

   Schermata-del-2018-06-18-11-35-22.png
   

[Jemba]

Hello otorino, I’m having exactly the same issue. all programs that are in the night are getting a 0% water level and will not be activated. water level is going up in the morning highest at noon and going down in the evening and night. even that we have very hot weather here in Germany the last weeks.
Please @opensprinkler team fix this, my green is getting brown.

[ottorino]

Hi Jemba.
In the meantime just unselect the climatic control from the programs you use.

[Jemba]

Thanks ottorino, did that already

[franzstein]

I have found a temporary workaround in regards to Netatmo stations not visible on WU anymore. The weather service MeteoWare Plus can be used to send the Netatmo weather data to public weather networks like “Weather Underground” or “wetter.com”. Please refer to MeteoWare Plus for your Netatmo Weather Station. There are no extra costs for this service as long as there are no deeper weather analytics requested from Meteoware.

However, the Netatmo data will be send only every 20 minutes to WU. From what I have seen this delay of 20 minutes is still sufficient for the Zimmerman method and will not cause any issues for controlling the OpenSprinkler by weather data.

From WU officials it is known that for the time being, existing free WU keys will continue to work unless otherwise noted. I know that using the Meteoware service is no final solution, but it may be some help for OpenSprinkler users that also own a Netatmo weather station and have a free Wunderground API key.

[franzstein]

My workaround using the Meteoware Plus service to send my Netatmo weather data to Weather Underground is working with interruptions. However, my free WU API key is working as I can connect my OpenSprinkler system as well to a nearby non-Netatmo WU PWS. I hope that this will be possible at least for the remaining garden season.

Operating the OpenSprinkler with the Zimmerman method works best, if yesterdays mean temperature, total precipitation and mean humidity are available and can be used as a stable input. In my opinion it makes no sense to e.g. use the current temperature as input for the Zimmerman calculation. It is also a problem if any forecasted precipitation for today is added. There are very often rainfalls forecasted, which will never take place during the ongoing day.

[ncunningham]

Are there plans to switch to the OpenWeatherMap.com API or have the option to choose it? I would like to see the weather data for the open sprinkler OSPI system I bought for my mother. I realize this is not possible right now because we are essentially all using your API key.

Thanks in advance,

Norm

[franzstein]

The Meteoware Plus workaround I’m using is still working with interruptions. My Netatmo PWS is not always visible at the Weather Underground Map and the WU Current Conditions are often not periodically updated in time. I don’t know why. Maybe only a temporary malfunction at the WU side? However, the historical data is always valid and I can use it for my OpenSprinkler watering system.

By the way. It started raining later this morning and the OpenSprinkler water level changed to 0 for one hour, back to 115% thereafter and again to 0 for about 3 hours thereafter. Unfortunately, this happened after my watering program runs early morning. I have no rain sensor installed. Is this behaviour described somewhere? I know that details can be found in the github repository. It seems to be an additonal feature to stop the watering, if it starts raining?

Thanks and regards

Franz

[Samer]

@Pat I am looking into DarkSky now and the API seems very easy to use and the data seems very rich. The perfect alternative it looks like as OpenWeatherMaps is missing historical data in the normal API and requires seperate billing and API call for historical data. There website clearly says do not direct customers to generate their own keys, each company should use one key.

Their pricing seems very reasonable so I think I will discuss this with Ray and hopefully get this solution setup. This will stabilize the scale values currently being seen with OpenWeatherMaps as the source.

[Jemba]

@Samer great thanks a lot for the update 🙂

[Pat]

@samer I hope it works out. As mentioned I moved all my FOSS stuff to Dark Sky and it was quick and (mostly) painless. And with 1,000 free calls a day, that’s *almost* 1 call a minute (ok maybe 1 call every 2 minutes). Plenty of wiggle room though depending on how often it’s used per user/station

[HIL Tennis]

Opensprinkler PI noob here. Does this mean that without a working weather integration I will have to manually set a rain delay if there is rain? Also thinking about purchasing https://www.amazon.com/Orbit-57069-Sprinkler-System-Freeze/dp/B000A7SPPU linked in the user manual to make sure there is no irrigation when it rains.

[ottorino]

As far as I can understand the weather integration regulate only the amount of water. In my system, even before the zimmerman algorithm came into play, I’ve always had the orbit device you are planning to buy. I suppose that the orbit device is the only one capable to trigger the irrigation on and off. When on, the zimmerman algorithm calculate the amount of water.
Hope this helps

[HIL Tennis]

@ottorino it does. Thank’s for taking the time to answer my questions!

[tekhedd]

Clearly the current OWM-based code is using the current temperature and humidity (and rain level? uncertain) when calculating the watering level. This caused me some confusion, and is of course suboptimal. However, at least once I know what is happening, it is possible to, for example, turn off temperature-based adjustment, cut the humidity adjustment down, or just turn it off entirely and buy a rain sensor. 🙂

1) I would suggest adding information about this behavior to the documentation until a fix is released?

Obvious solutions include using a different API or provider, or letting the system average temperatures over the course of a day (fails if system power is lost but quite doable and also makes support of weather stations that do not report averages possible). Etc.

2) Is there a ticket number for this issue, and any sort of semi-official plan? I guess it’s time to clone again. :{ [edit] I see from the discussion that there is a plan to support paid OWM, which is fine. Is there a ticket number and a timeline?

If there’s one thing in life I don’t need, it’s yet another project, but I *do* want forecast-based watering adjustments, so there you go.

[franzstein]

Thanks to the team from MeteoWare, their MeteoWare Plus service is working without producing interruptions of the Wunderground Current Conditions anymore. With my existing free WU Key I can use my own Netatmo PWS as input source for the OpenSprinkler watering adjustments. This allows for perfect local temperature, humidity and precipitation measurements.

I hope that WUnderground is not cancelling the API service for existing free API key owners in the near future?

What I can say is, that the Zimmerman method with its adjustments for OpenSprinkler is quite efficient in regards to calculating the watering times needed for a sprinkler system. It incorporates historical weather data from the day before and actual precipitation data for today. This results in predictable watering times for the ongoing day. If an acceptable access to local weather data can be provided, there is also no really need for the installation of an additional rain sensor. The water level is automatically set to 0% if it is raining.

I like to mention that any alternative to WUnderground should take care for using the Zimmerman method with OpenSprinkler in the way it is implemented right now – preferably with the same functionality.

Thanks and regards

Franz

[wifi75]

@ottorino I’m italian can you send me your email i need to write you to ask something..

thank you

[ottorino]

Hi there. It seems that I cannot send private messages to you, therefore I do not know how to send you my e-mail address

[wifi75]

@ottorino
nessun problema, volevo.solo chiederti alcune info su opensprinkler.
grazie noi stesso

[ottorino]

Please note that my previous answer was neither a no or a polite negative answer. We can possibly try to exchange our mail addresses in some other way. I’m currently writing from my mobile and it’s not comfortable. As soon as I will lay my hands on a true keyboard I will try to arrange something

[Anonymous]

Hi,
I have just tried to erase the Wunderground API key from my Opensprinkler configuration due to the changes on the API service (I already had an API key when there was the announcement of the changes, so Wunderground is someway and sometimes still working for my system, but I would like to change to follow the next default OS weather adjustment configuration), but since when I did it I’ve experienced the behavior described by Ottorino and Jamba in replies #50739 and #50895.

So, I intend that now the default behavior of the Zimmerman weather adjustment method is to stop all the programs running in the nighttime, when the water level is always 0%.
Is it a desirable behavior? I’ve always made my irrigation during the nighttime but now, with these system limitations, I have to choose between this two choices:
– using the Zimmerman weather adjustment method (and program the irrigation just in the daytime);
– keeping on irrigating during the nighttime (but without the useful adjustments of the Zimmerman method).

Is it planned any action to avoid this situation and this choice?

Bye

[victoria.gardner]

Just so that you know: API keys for PWS non-commercial users are going to continue to allow the PWS owner access to all their data. There may be another gating mechanism (rather than keys) in the future, but there is no plan to discontinue PWS access.

The latest information may be found on https://apicommunity.wunderground.com/weatherapi

Lack of a key should not limit anyone from adding a new PWS as well. See https://www.wunderground.com/personal-weather-station/signup?new=1

Thank you!

Victoria Gardner
[email protected]
Weather Underground API customer service

[GregoryNeefs]

Can someone please post an instruction what to do?

Is removing the API key enough to get weatherdata from OWM?
The field in OpenSprinkler is saying: We use OpenWeatherMap normally however with a user provided API key the weather source will switch to Weather Underground

How can my unit see where it is located if I remove this API key? Because the API key now contains the location via Wunderground.
Or am I wrong? I’m scared of deleting the API key… 🙂

[Anonymous]

@GregoryNeefs In my experience, removing the Wunderground API key is enough to get weather data from OWM, anyway I keep on having the same problems described by Ottorino and Jamba in replies #50739 and #50895. The settings about the location of the Opensprinkler unit are in the “Edit Option” page, in the “System” section. I erased the Wunderground API key some time ago and I get weather data and forecast information related to the location I configured in this section.
Bye.

Marco

[Ray]

“removing the Wunderground API key is enough to get weather data from OWM” — correct. Just remove the WU API key and the weather service will automatically switch to us OWM data.

[Author]

Posts