February 9, 2019 at 12:55 pm #53976
According to information from Victoria Gardner, Weather Underground the gateway for obtaining keys on the new API for PWS non-commercial users is planned to open on February 15, 2019. All current WU API keys that are linked to a PWS will stay open through Friday, March 1, 2019. Links to documentation and details about data can be found at Weather Underground API Update. That gives only two full weeks to sign up for a new key and change the calls.
I’m not an expert in programming, but I think there need to be some changes made to the OpenSprinkler Weather Service and probably the OpenSprinkler App. Are there plans for OpenSprinkler to update the interface to WU that it can still be used by PWS owners?
The Zimmerman Method in conjunction with my own PWS reporting to WU was working perfect for me and it would be very nice to have this feature still working.February 22, 2019 at 1:28 pm #54073
I see the weather api link at the bottom of their page, but that appears to be the old system.March 3, 2019 at 5:24 pm #54165
Weather Underground has opened the gateway for obtaining keys on the new API for PWS non-commercial users. It is now possible for PWS owners to obtain the NEW API key. The documentation for the NEW API’s commands can be found here.
The big question now: Will there still be an OpenSprinkler interface to Weather Underground? What are the plans for the OpenSprinkler Weather Service? It would be very nice to get some answers?March 3, 2019 at 5:33 pm #54171
Honestly Weather Underground has gone down for too long for most customers with no recourse plan. Unfortunately, this left us focusing on OpenWeatherMaps as an alternative. We are going to be focusing our efforts there and no longer going to be accepting a Weather Underground API key from the app nor using it in the Weather API side.
We have also dropped Yahoo weather service in the app as the API is also gone. We added an endpoint to our API to grab the weather data from OWM and provide it for the app.
The weather API is written in JS/node and is easy to contribute to if anyone would like to add in support for this new weather API however I do not think we will be putting the effort to adopt this new API, especially when I do not own a PWS and won’t have a key to test off of.March 5, 2019 at 6:05 am #54199
Similar issue for me. My sprinklers haven’t run for 2 days and when I check it thinks I have had 12cm of rain (no way – maybe 1mm if lucky).
I have my own weather station which used to feed weather underground but whatever opensprinkler is using at the moment is way off and stopping all watering.March 5, 2019 at 11:08 am #54201
@franzstein I agree with you there is a discrepancy in the quality of data we have now versus with WUnderground. We just upgraded our OWM account to provide better forecast data and we are planning on implementing a caching system so we can lower the number of redundant calls to the API (both the app and the device are querying the same location for the same data now). Once we have this caching system in place, we will add historical API to our Weather API and allow it to properly get the data needed when it’s missing or use the cached data when appropriate.
This isn’t a small undertaking but the problem before was the large array of weather APIs we interfaced with caused me not to truly focus on any single one. I am hoping my choosing just OWM, we can continue to refine and improve this service for everyone. I agree with you the current state is not very usable for Zimmerman calculation and we are hoping to improve that.
For the record, @peter added a PR to the Weather API we provide which allows you to query a local weather station directly and allow OpenSprinkler to directly use this data. There is more information on this post here: https://opensprinkler.com/forums/topic/cutting-the-weather-underground-cord-homebrew-solution/. I am reviewing this and hoping to include it in our master branch moving forward to assist people with weather stations that would allow local polling.March 15, 2019 at 1:10 pm #59364
@samer: Netatmo weather stations and the accompanied Netatmo or Meteoware Plus weather services don’t provide any means to connect to OpenWeatherMap. For this reason I don’t think that the change to OWM will be a solution for me in the near future?
Looking for an alternative to OWM, I have programmed a ESP32 NodeMCU to retrieve weather data from WeatherUnderground’s new API, perform the Zimmerman calculation and update the OpenSprinkler’s water level. Details are available at my GitHub repository.
The hardware used are a ESP32 NodeMCU Board and a USB power supply. There is some understanding of installing the ESP32 on the Arduino IDE and some programming effort needed to get the ESP32 working. However, it is a low-cost solution providing mainly the same functionality in regards to garden watering as the “old” OpenSprinkler WU Interface.
- This reply was modified 6 months, 1 week ago by franzstein. Reason: Clarification that the new WU API is used
Attachments:April 8, 2019 at 12:30 pm #59636
I bought OpenSprinkler only because of the link with a PWS using Wunerground. I also bought a Netatmo weather station because of the link with Wunderground. All is still working perfectly except OpenSprinkler decided to start using OpenWeathermap. I understand the possible issues with Wunderground for people not having a PWS.
1 big problem, Openweathermap is useless and providing wrong data. That data is the only reason why we use a weather service.
No rain until now and OWM reporting 34mm
I don’t understant OS is removing Wunderground. Why not leaving the code so who want to use it, just can. The code is already written, so no effort to leave it.
Or why not providing a easy to use procedure for the OSPi users so we can run a weather service on the RPi to connect to Wunderground.April 8, 2019 at 2:57 pm #59640
@Wokkeltje: Please be aware that the newAPI to retrieve weather information from Weather Underground is different to the old API. This means the code used in “OpenSprinkler-Weather” and probably in “OpenSprinkler-App” needs to be adapted or rewritten to use the newAPI. The newAPI is no solution for non-PWS owners. It is at no costs only available for PWS Owners who send their data to Weather Underground.
All I can say for now is that my low-cost ESP32 workaround works perfect for me and provides the same results as the old OpenSprinkler Weather Underground Interface. Nevertheless, it isn’t a general solution and it needs some programming effort to get it working.
May 1, 2019 at 1:20 pm #60060
- This reply was modified 5 months, 2 weeks ago by franzstein. Reason: Added some additional remarks in regards to PWS owners
@franzstein Just to let you know, another customer @PeteBa has provided a PR to allow the weather service to be run locally and interface with your PWS allowing you to use the data you were used to with WUnderground. We should be merging this in soon hopefully and add some documentation for using it.
Thank you!May 6, 2019 at 5:58 am #60158
Hi, is there any progress with this locally service solution from @PeteBa or additional information/doc?
I tried to migrate the existing script to the new WU API structure but struggled (as I’m not a programmer).
Thanks in advice!May 6, 2019 at 10:43 am #60161
@fennsen , you can follow the link here for progress GitHub. Note that there are some pre-requisities to be able to use this. Firstly, you need an “always on” server that can run OpenSprinkler Weather Service locally. You also need a PWS that generates Weather Underground format messages (or can build a man-in-the-middle solution). Happy to explore options via the github link above as I’m looking for a tester or two. Cheers.May 6, 2019 at 1:37 pm #60168
Thanks for the hint. moving to github now..
pre-requisites are given (more than 1 24/7 server and different raspi’s for weewx, ospi, home-automation…
CheersMay 6, 2019 at 5:21 pm #60170
I agree with your wish to ‘only’ adopt the weather-adjustment plugin to the new API structure, but also struggeling with coding skills. BTW: the new API is based on JSON data returns, the old one (or the plugin) uses XML structures which drives things for me not easier trying to ‘rewrite’ the code.
Nevertheless: I tried your ESP8266 solution but struggled to compile the code. An error occurs within the “RTC_DATA_ATTR int raindelayCount = 0;” data definitions. I tried to include the RTC libraries in Arduino IDE but without success. My platform would be an ESP8266 NodeMCU 1.0 (ESP-12E) module. Do U use a special ESP module here which has other RTC capabilities or definitions?May 7, 2019 at 3:40 am #60172
@fennsen I used an ESP32 WROOM NodeMCU. So it is most likely that the RTC capabilities differ to that of the SP8266 NodeMCU 1.0 (ESP-12E). Unfortunately I am currently on vacation until mid of next week and not able to do any further investigations. By the end of next week, I can provide more details. Hope to be at least some help. Please note that my use of OS rain delay differs to the original weather.py usage.May 7, 2019 at 8:06 am #60173
thanks for the feedback and hints. Seems that Node MCU / a normal ESP8266 doesn’t have a RTC (only software emulated). Then it’s clear that the statement runs into errors.
Which means that I’ve to order this ESP32 module… sig…
After downloading the ESP32 board definitions and used the ‘ESP32 Wrover Module’ as board for a test run, compiling suceeded without any errors! GBY… 🙂
The second issue while compiling before was also related to that:
,,OS_WU_WeatherService_V2:121:26: error: ‘esp_deep_sleep_start’ was not declared in this scope”
After reading the article about deep sleep on ESP32 it’s clear that this must be included in the ESP32 board definitions. Hey joe 😉
Furthermore it also resolved the issue with errors from
(as idiot…) I tried to use
Just for information to others who might also struggle with this.
enyou your vacation! Will come with an update when the module arrives and set up…
You must be logged in to reply to this topic.