Forum Replies Created
-
Posts
-
Some additional remarks: The current implementation of the OpenSprinkler-Weather script doesn’t set the watering percentage to 0 if it starts raining. This is due to the bad weather forecasts in regards to rain prediction. At least for Netatmo PWS there is a workaround to stop watering if it starts raining.
A single IFTTT applet: Rain detected – Stop sprinkler operation is used to stop any sprinkler activity if it starts raining.
The corresponding API command is: /cp?pw=xxx&pid=0&rd=3 (Set a 3-hour rain delay)
In general the rain detection depends on how fast the rain gauge will be filled with rain and how fast the IFTTT applet is reacting. This can take some time, if e.g. there is no remarkable rain falling. In worst case scenarios there is always a chance of running the sprinkler in parallel to the rainfall. However, my experience shows that using weather forecasts for stopping the sprinkler are not conducive. Especially in Germany weather forecasts sometimes predict rain during the day, which never results in any rainfall at all.
Ok. I have looked in more detail at the OpenSprinkler-Weather script. I’m not a Node.js expert. However, there seems to be a bug in the local.ts file. If we change the sequence in the getLocalWateringData function to first using today’s weather and second using yesterday’s weather as watering data everything works fine. Yesterday’s weather summary is captured every midnight and used to calculate the watering percentage of the ongoing day. There are no fluctuations at all in the watering percentage. In case of rain during the ongoing day the watering percentage is adapted as expected.
I can only speak for local PWS users who host the weather script on their own local server. With the above adaptations the weather script provides the same functionality as known from the “old Wunderground days”.
@Ray Is there a schedule for realizing the plan to smooth out the watering percentage? Will it be an update of the OpenSprinkler-Firmware or the Opensprinkler-Weather script? It would be nice to get some more information on future OpenSprinkler changes or improvements.
I have an OpenSprinkler DC 3.0, Firmware 2.1.8 in an AVM Fritz!Box 3590 Mesh configuration running. The OpenSprinkler is installed in the Garage and most of the time connected to the WiFI AP FRITZ!Powerline 1240E installed nearby. It is running for months now without any issues. Please be aware that older Fritz!Repeater, like the FRITZ!WLAN Repeater 300 may be part of your problem.
@peter I’m more than happy to describe the necessary steps taken for including Netatmo Weather Stations.
Netatmo Weather Stations are not automatically supported by the drivers that come with WeeWX. However, there exists a Netatmo/WeeWX driver written by Matthew Wall that can be added to WeeWX. The procedure to install the driver is straightforward and best described at his github repository.
Before following these installation instructions it is necessary to obtain a Client id and a Client secret via the netatmo.com web site. For this purpose a Netatmo Connect project has to be started and an APP has to be created in addition to the username and password already available for the existing Netatmo account.
Whilst creating the APP there is a form showing up and the fields to fill in are at least <Name>, <Description>, <Data Protection Officer name> and <Data Protection Officer email>. I have filled in WeeWX Interface, WeeWX Interface to Netatmo cloud data, my Name and my Email Address. The Email Address should be the same as used for logging in to the Netatmo account, all the other text may vary. After saving this form the so called “Technical Parameters” Client id and Client secret can be obtained.
These credentials together with the username (Email Address) and password are needed in Step 3 of the Installation Instructions outlined by Matthew Wall, wich can now be performed.
I have had the problem that the “sudo wee_config –reconfigure” command didn’t change the /etc/weewx/weewx.conf file as expected. So it is best to have a closer look at this WeeWX configuration file, which should contain:
…
# Set to type of station hardware. There must be a corresponding stanza
# in this file with a ‘driver’ parameter indicating the driver to be used.
station_type = netatmo
…##############################################################################
[netatmo]
username = <Email Address as used for Netatmo login>
client_secret = <Client secret as obtained from the Netatmo Connect website>
password = <Password as used for Netatmo login>
driver = user.netatmo
client_id = <Client id as obtained from the Netatmo Connect website>
mode = cloud
##############################################################################…
If not the corresponding changes can be made with: sudo nano /etc/weewx/weewx.conf.
It is also necessary to stop and start WeeWX whenever there are changes made to the /etc/weewx/weewx.conf file.
Commands to use are: sudo /etc/init.d/weewx stop and sudo /etc/init.d/weewx start.Remark: As you already described, if WeeWX and the OS Weather Service should run on the same Raspberry PI it is also necessary to specify the local Weather Service IP in theWeeWX configuration file as follows:
..
[[Wunderground]]
enable = true
station = anyText
password = anyText
server_url = http://127.0.0.1:80/weatherstation/updateweatherstation.php
rapidfire = False…
Hope to be some help.
It’s a little bit tricky. After entering only the IP address 192.168.178.39, without the PORT number everything is working now!
Am I right that the OpenSprinkler System Diagnostics shows the current temperature, humidity and precipitation values as retrieved from OWM? The precipitation value shown is multiplied by 10, which seems to be an error. However, these values were not used for %Watering calculations and have nothing to do with the values retrieved from the Local Weather Service?
Attachments:
@peter, thanks for your detailed answer. It makes the decision for me easy to opt for the local Weather Service with my WU compatible PWS (Netatmo).
In the meantime I have WeeWX and the OpenSprinkler-Weather service running on the same Raspberry PI. It is definitely not needed, but I have chosen the Rasbperry Pi 3 Model B+ to be up to date with dual-band 2.4 GHz and 5 GHz wireless LAN.
Testing the OpenSprinkler Weather Service shows that the service is running correctly:
http://192.168.178.39:80/weather1.py?loc=49.47369,10.94380&wto=”h”:100,”t”:100,”r”:100,”bh”:70,”bt”:65,””br”:0
results in:
&scale=66&rd=-1&tz=56&sunrise=310&sunset=1283&eip=3232281125&rawData={“h”:81.33,”p”:0,”t”:59.5,”raining”:0}One last thing: To configure the OpenSprinkler DC 3.0 to use the Local Weather Service I have to set the Weather Service IP and PORT (Default: weather.opensprinkler.com) to 192.168.178.39:80? TheJavaScript for the UI (default: https://ui.opensprinkler.com/js) remains unchanged? Is the OpenSprinkler System Diagnostics thereafter showing the data received from the Local Weather Service?
Realized that I have to use PORT 80 to answer requests coming from OpenSprinkler. Unfortunately the OpenSprinkler System Diagnostics still shows no Last Succesful Weather Call.
@peter, some more questions that you can maybe answer?
According to Ray’s update on the current state of the weather script the OpenSprinkler-Weather Service implements a ‘rolling window’ approach. It also offers the selection of OWM, DarkSky or a local PWS as weather service providers.
My current understanding is that OWM is based on forecast data for the next 24 hours. DarkSky provides weather data from today and yesterday. Does this result in the use of historical data, if DarkSky is selected? How about the PWS selection? Does it also result in the use of historical data?
Or the more general question does the selection of a local PWS lead to an OpenSprinkler weather calculation similar to the old WeatherUnderground layout? I have looked at the github OpenSprinkler-Weather Service repository for details. However, I still have no complete understanding of the calculations. A more descriptive explanation is highly appreciated.
@Peter, thanks for offering your help. It’s great, that both services can be run on the same Raspberry PI. I will give it a try, but it will take some time to get everything in place.
OK. Just found out that I have to use the idx parameter names in the API call. The correct call is: http://ipadress/co?pw=mypassword&o2=1&o3=1&o32=1&o23=77. The API Document isn’t so easy to understand? However, looking at it after some time again provides the solution for me.
I hope that this is at least an example for others on how to change the water level via the OS API call without any side effects.
I still have some problems with the API Change Options call. To change the water level I used the simple API call http://ipadress/co?pw=mypassword&o23=77. It is working, the water level changed accordingly and results in {“result”:1}!
I now noticed that this command will also set the items NTP, DHCP and Logging to off. An important note in the OS Firmware 2.1.8 API Document describes this behaviour. I changed the API call to http://ipadress/co?pw=mypassword&ntp=1&dhcp=1&lg=1&o23=77 and thought this will solve the problem, but no success!
The issue is also described in thread API – Change Options Command. According to Samer it should be solved with firmware 2.1.6, but it seems to be still or again present in firmware 2.1.8.
I gave it several trials. However, the items NTP, DHCP and Logging are always set to off after running the API call.
I don’t use the items Sensor 1 type, Sensor 1 option, Ignore Password or Special auto refresh, but probably they are also affected.
Maybe I do something wrong? Help would be highly appreciated.
Sorry. Just get told that there are no night and day variations anymore using the OWM weather adjustment feature. No worries!
Great news. I did not realize that the night and day variations are completely fixed. I still hesitate with the use of forecast weather data. However, time will show!
@Peter I’m still using historical weather data from WU as a weather source forwarded by my Netatmo PWS to WU. My OpenSprinkler runs in Manual Mode and will be updated via the OS API interface. My ESP32 NodeMCU program does the Zimmerman calculation based on empirical weather data retrieved from WU. My base parameters are 70°F, 65% humidity and 0.0 inch precipitation. My geo coordinates are 49.47369, 10.94380. My WU station name is IFRTH65. The location name shown in OpenSprinkler is Burgfarnbach a suburb of Fuerth, Germany. This seems to be the location of the nearby OWM weather station.
I don’t know how the actual OWM based OS weather adjustments are working in detail. Reading forum comments I thought that there are still variations during night and day not caused by any rainfall.
It would be nice if you can provide more details or run a comparison.
@fennsen Very interesting. How often are you updating the watering results for OpenSprinkler? I think the ‘floating’ updates of the official OWM weather adjustments cause the problem that there are water% variations during the day.
@samer It is maybe worth to think about updating the water% only once per day, e.g. at midnight or before sunrise and only change it during the day in case of rain occurence or rain forecasts?@fennsen Interesting approach. In regards to using forecast weather data, especially rain prediction I see some problems. I’m using Zimmerman since last year and don’t see any bigger issues. The parameters can be easily adjusted. For example I use a humidity base of 65%, which I found more suitable for German weather conditions. There is a chance of watering the garden in the morning and not taking the afternoon rainfall into account. Happened last Wednesday! But this situation is very rare and I can live with that. I see a bigger problem if rain is forecasted and never took place for consecutive days. This happened very often during our hot summer last year. With the Zimmerman Method using only historical data my garden green survived.
Nevertheless, it’s good to see some other approach and I’m well interested in your scripts.@Peter Perfect analysis, explaining the differences between OS historical and forecasted weather data usage.
In my opinion only historical weather data is acceptable as OS Zimmerman Method input. Temperature forecasts may be acceptable and not be the problem. However, in regards to rain and especially the amount of rain, weather forecasts are often far away from reality. I can’t speak for all countries, but at least for Germany rain prediction is not always trustworthy.
I started last year with an OSBee and a selfmade IFTTT, apilio.io weather algorithm based on weather forecasts. My program often failed for garden watering as there was rain announced, which never happened during the ongoing day. This causes me to change to an OpenSprinkler 3.0 and the accompanied Zimmerman method. Based on historical WU data, forwarded by my own weather station, this worked and still works perfect for me.
I also believe that it is much preferable to have an own rain gauge. There is sometimes rain forecasted for the ongoing day, but there will be no remarkable rainfall at all at my backyard. With an own rain gauge and the use of historical weather data it is possible to avoid these uncertainties.
In regards to free access to historical weather data, there is a possibility to provide and collect weather data by an own weather station. This still works for me in conjunction with WU. However, I’m also depending on cloud services like Meteoware to forward the data from my Netatmo weather station to WU.
There are already some solutions like private weather servers or my ESP32 Node MCU program that controls the OS Watering via API commands discussed at this forum. Unfortunately, these solutions need some programming knowledge and additional HW efforts.The majority of OS users will still depend on the OWM weather adjustment feature provided at no extra costs by OpenSprinkler. I’m not sure if this will work out at the end for weather controlled garden watering. Forecasted weather data will always have uncertainties. With the current implementation it changes during night and day, which makes it difficult to perform sufficient early morning garden watering.
@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.
@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.
I’m not familiar with cron jobs and have never used it. However, what I have found by web search is that you can use lynx for urls with parameters:
lynx -dump “http://ipadress/co?pw=mypassword&o23=77”
It is stated that lynx is available on all systems by default. The OS “mypassword” has to be entered MD5 hashed, see OS API Documents for details. The Weather Adjustment Method has to be set to “Manual”.
Regards
Franz
@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:
Sorry! Actually used the wrong API call “Change Controller Variables [Keyword /cv]” instead of “Change Options [Keyword /co]”. Unfortunately http://ipadress/cv?pw=mypassword&o23=77 gives no errror. The API call http://ipadress/co?pw=mypassword&o23=77 is working!
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?
It is my understanding that Weather Underground will provide free Replacement APIs for Personal Weather Station Contributors in the near future. They are not fee-based and contain:
– Current observations from the PWS network
– 5 day daily forecast
– PWS historical data
– PWS lookup by geocode, zip code and location
– Call volume: 1500/day, 30/minuteDetails can be found here.
This will e.g. allow Netatmo Weather Station owners who send their data to WU to continue to use WU as a weather source for OpenSprinkler. However, some adaptations will be needed to the OpenSprinkler Weather Service script to retrieve the weather information. I hope that Ray or Samer will provide some information, if they will update their OpenSprinkler product accordingly?
From what I know OpenWeatherMap will not provide historical weather data for free, which makes it difficult to use the Zimmerman method in it’s original way. Please correct me if I’m wrong?
Regards
Franz
@mcmuller: Bad news! Thanks for the notice.
WUnderground officials describe some exceptions for Personal Weather Station owners or developers who use WU API data for non-commercial purposes. I am not sure if this works out for OpenSprinkler owners who like to use the Zimmerman method to control the garden watering. There might be as well some software/firmware adaptations needed for OpenSprinkler to stick with the new WUnderground service, if possible at all?
I hope that we can get some information from Ray or Samer which weather service they like to use in the future? The current OWM interface implementation isn’t really as good as the WUnderground interface for OpenSprinkler.
Regards
Franz
