- This topic has 13 replies, 7 voices, and was last updated 2 years, 11 months ago by
.
-
Posts
-
Hi All,
There have been several new additions, improvements, and changes to the OpenSprinkler weather service recently, which I would like to announce in this post. These are due to the excellent work by Samer, Matt, and Pete.
1. A new weather adjustment method, ET (Evapotransporation), is now available (in addition to Manual, Zimmerman, and Auto Rain Delay). ET is a more sophisticated algorithm than Zimmerman, and is a widely used industry standard. We have updated our support article below:
https://openthings.freshdesk.com/support/solutions/articles/5000823370-using-weather-adjustments
to describe the ET, its comparisons to Zimmerman, and precautions when transitioning from Zimmerman to ET.Using this method does NOT require any firmware update: when you go to Edit Options -> Weather and Sensors, it will show up in the dropdown list of ‘Weather Adjustment Method’. When choosing this method, you must provide a baseline ETo value. You can open the ‘Adjustment Method Options’ dialog and have it automatically detect baseline value using your geo-location. Later if you decide the auto-detected value is consistently too high or too low you can make manual changes to the baseline. Essentially the baseline value gives you a way to scale the watering percentage up or down based on your preference.
Because ET and Zimmerman use very different formula, the watering percentages calculated by the two may differ significantly. This is expected. Please take a look at the support article above for suggestions when transitioning from one to another.
2. The OpenSprinkler weather code now supports multiple weather service providers: DarkSky (DS), OpenWeatherMap (OWM), Wunderground (WU), and also local weather server. The official weather service, at weather.opensprinkler.com, has switched to use DS as the default provider. This is based on user feedback that OWM’s data quality is rather poor. One main reason to support multiple providers is to have a backup plan: in case one provider goes offline or becomes unavailable (like what WU did recently), we can quickly switch to another provider to avoid disruption.
3. We have added back the support for WU because there are still users who want to use their WU API key and their personally owned PWS as data source. The weather code will automatically choose WU if you 1) provide a valid WU API key, and 2) select a specific PWS. Selecting a PWS is required because WU’s current API only works with specific PWS name, and it does NOT work with a location name or GPS coord anymore.
However, due to the way the WU key is stored in the firmware, this option will only become available in firmware 2.1.9 which we have not released yet. So unfortunately you won’t be able to use WU at the moment until firmware 2.1.9 is released. In addition, because WU API does not provide average solar radiation (a required parameter by ET), if you choose to use WU, the ET algorithm will become unavailable.
Perhaps a bit surprisingly, there is currently a way to obtain a WU API key even if you don’t own a physical PWS device. We have described this in our support article here:
https://openthings.freshdesk.com/support/solutions/articles/5000017485-getting-a-weather-underground-wu-api-key
Please note that this is very much gray area: given WU’s recent fiasco, we won’t be surprised if they suddenly pull the plug all together, so if you plan to use WU in the future, please use it as your own risk.4. There have also been several UI improvements / changes over the past couple of weeks. Most notably, due to switching weather service from OWM to DS, the way UI detects and selects unit (metric or imperial) had to be changed, which caused some issues. This has been sorted out. In addition to the auto-detection, we’ve also provided an explicit way for users to choose their preference. In UI/app version 2.0.1, under Edit Options -> System, there is now a new checkbox ‘Use Metric’ for you to switch between metric and imperial units. So if the auto-detect unit is not your preference, you can use this option to explicit set your preference.
UI/app 2.0.1 is now available through direct browser access, Android, and Amazon; we are still waiting for Apple to approve it so it should be available in iOS soon.
Thanks!
Thats great! Configured the ET values (Baseline and elev), but I am not sure if the program is recording the values, seems to default back to 0 baseline, elev 183m?
John
Hello and thanks for your great work on this; especially the weather app data. How do I get my “direct browser access” to update to Version 2.0.1? When I browse to my Raspberry Pi on my local network (behind my NAT firewall), I see App Version: 2.0.0, Firmware 2.1.8(1) and Hardware Version: OSPi. Is the App Version on this web page somehow related to the App Version that I use on my mobile device to access the OSPi when I’m not at my computer or does some other update to the software on the Raspberry Pie need to happen to get to App Version 2.0.1?
Because we use fairly aggressive caching, if you are still seeing 2.0.0, you can either open a private browsing window, or, you can trigger a hard refresh to force the web browser to retrieve the current javascript files. Depending on what browser and what operating system you use, the ‘hard refresh’ works slightly differently. For example, if you use Chrome, you can press Ctrl while clicking on refresh (or in Mac, it’s Shift + refresh).
Generally the web version is updated the first (hence direct browser access usually gets the update immediately). Android and iOS apps both need approval so that take a bit more time.
Upgraded to the latest 1.8.4 firmware. Seems to be working for me. Any ETA on the 1.9 version that will enable those few of us with backyard weather stations that update to Weather Underground? I have a WU API Key that works and hopefully your code will work with that API now. I believe the default is the Dark Sky site. I presently do not upload to Dark Sky. Thanks in advance.
Probably in a couple of weeks? I am returning from vacation and the bulk of FW 2.1.9 has been done. Right now finishing UI implementation and doing final testing.
I’d love to request the possibility in a future update (for Australian users) the ability to get weather data from BOM (Bureau of Meteorology) which in Australia is the most accurate source of weather data. More so than Dark Sky, WU or OWM. Perhaps such an update might also give other countries the ability to select their local weather data provider?
Hi Ray,
Did you open the Adjustment Method Options dialog and click ‘Detect Baseline ETo’?
I’ve getting a error (Unable to detect baseline ETo: ETo data is not available for this location.(404)) when doing that here (Adelaide, South Australia).
Not sure where else to find baseline data from – I can access current data from http://www.bom.gov.au/watl/eto/tables/sa/adelaide_airport/adelaide_airport.shtml
First, you may want to change your location a bit to see if you can obtain baseline. The query is based on some data extracted from a big map, it’s possible that your location just falls on the edge of some region but if you move around slightly it should get the baseline value.
Hi Ray,
First, you may want to change your location a bit to see if you can obtain baseline. The query is based on some data extracted from a big map, it’s possible that your location just falls on the edge of some region but if you move around slightly it should get the baseline value.
Edit: I fixed this. I changed location slightly, hit submit to save the new location, then hit detect and it worked.
I am having the same issue: Unable to detect baseline ETo: ETo data is not available for this location.(404). I tried setting a bunch of different locations e.g San Francisco, San Jose etc. no luck. Is there any other hint anyone could give me to get a baseline?
Any help is really appreciated.
Marcello
- You must be logged in to reply to this topic.