OpenSprinkler Forums OpenSprinkler Unified Firmware Free Weather Underground API keys for PWS non-commercial users

Viewing 16 posts - 1 through 16 (of 16 total)
  • Author
    Posts
  • #53976

    franzstein
    Participant

    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.

    #54073

    RottenMutt
    Participant

    I see the weather api link at the bottom of their page, but that appears to be the old system.

    https://www.wunderground.com/weather/api

    #54165

    franzstein
    Participant

    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?

    #54171

    Samer
    Keymaster

    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.

    #54199

    steveb
    Participant

    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.

    #54201

    Samer
    Keymaster

    @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.

    #59364

    franzstein
    Participant

    @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.

    Attachments:
    #59636

    Wokkeltje
    Participant

    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
    https://www.wunderground.com/weather/bx/staden/ISTADEN2
    https://openweathermap.org/city/2786227

    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.

    #59640

    franzstein
    Participant

    @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.

    I understand the reasons outlined by Samer for not using Weather Underground anymore. However, I’m also not happy with the current situation and OWM is definitely not easily useable for me. I don’t know how many OpenSprinkler PWS Owners are out there and I’m not familiar with Javascript for Node.JS programming. The newAPI is well described by Weather Underground and it’s weather service is reliable as it was before the changes. It’s maybe not such a big deal to make the relevant changes in “OpenSprinkler-Weather. This would be the best solution for OpenSprinkler PWS Owners as it fulfills all the needs requested by the Zimmerman method.

    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.

    #60060

    Samer
    Keymaster

    @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!

    #60158

    fennsen
    Participant

    @samer
    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!

    #60161

    Peter
    Participant

    @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.

    #60168

    fennsen
    Participant

    @samer
    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…
    Cheers

    #60170

    fennsen
    Participant

    @franzstein
    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?

    #60172

    franzstein
    Participant

    @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.

    #60173

    fennsen
    Participant

    @franzstein
    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
    #include <WiFi.h>
    #include <HTTPClient.h>

    (as idiot…) I tried to use
    #include <ESP8266WiFi.h>
    #include <ESP8266HTTPClient.h>

    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…

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

OpenSprinkler Forums OpenSprinkler Unified Firmware Free Weather Underground API keys for PWS non-commercial users