[franzstein]

I’ve compiled the Firmware for OpenSprinkler 3.x according to the article Compile the OpenSprinkler Firmware. I was only wondering for the compilation warnings and the error received. However, using the resulting firmware.bin file to update my OpenSprinkler works perfect. Thanks for the update and the new features available now.

[franzstein]

Changed the file ending to txt

Attachments:

1. Compilationlog.txt

[franzstein]

Hello Ray,
I’ve compiled the OpenSprinkler Unified Firmware 2.2.1(0) but got some warnings and an UnknownPackageError: Could not find the package with ‘greiman/SdFat @ 1.0.7’ requirements for your system ‘windows_amd64’ at the end of the complilation. However, the firmware.bin file was created successfully.

Can you please have a look at the attached logfile and tell me if I can use the firmware.bin file to update my Opensprinkler DC 3.1?

Thanks and regards

Franz

[franzstein]

Hello Ray,
I’ve updated my OpenSprinkler Hardware Version 3.1 – DC to Firmware 2.1.9 (11). The weather updates are working now for both Dark Sky and Weather Underground. I haven’t tested it with with my Raspberry Pi Weather Server installation yet, as my Raspberry Pi is currently not working.
Thanks a lot.
Franz.

[franzstein]

You have to update the server URL to reflect port 3000 rather than port 80. The availability of your Weather service can be checked with http://10.0.0.49:3000. Hopefully that will fix it.

Regards

Franz

[franzstein]

Hi Steve,
I’m a little bit unsure if I understand this correctly? Do you have installed a local instance of the Weather Service on your Raspberry Pi? You will find all associated details in the OpenSprinkler Github, Credits and License section.
Regards
Franz

[franzstein]

@bekesizl: It’s still freezing at night times in Germany and I’m not running OpenSprinkler right now to water the garden. It might be interesting, if the issue still exists with a wired Ethernet connection. Unfortunately, my OpenSprinkler V3.0 hardware model doesn‘t allow to attach an Ethernet module.

I‘ve also a backup system consisting of an ESP32 module, using Weather Underground weather reports to calculate the water level according to the Zimmerman method. The calculating result is send to the OpenSprinkler, running in manual mode. So, it’s a good idea to use such a workaround.

What I can think about is, that the “Empty Response”- issue is caused by some timing problem within the Arduino WiFi library function. I don’t know if this is the case and how to continue with the investigation?

However, for the time being my Local Weather Service runs with three or four data losses per day and can be well used to control the OpenSprinkler garden watering.

[franzstein]

I’ve continued troubleshooting my OpenSprinkler setup. The OpenSprinkler App uses the Get Controller Variables /jc?pw=xxx command to receive the OpenSprinkler information. Please see Firmware 2.1.9 API Document for details. Executing it within a web browser results in:

{“devt”:1642771880,”nbrd”:1,”en”:1,”sn1″:0,”sn2″:0,”rd”:1,”rdst”:1642778976,”sunrise”:483,”sunset”:1014,”eip”:1469124457,”lwc”:1642771835,”lswc”:1642771835,”lupt”:1642771832,”lrbtc”:99,”lrun”:[0,0,0,0],”RSSI”:-49,”mac”:”60:01:94:70:87:60″,”loc”:”49.47432,10.94365″,”jsp”:”https://ui.opensprinkler.com/js”,”wsp”:”weather.opensprinkler.com”,”wto”:{“h”:100,”t”:100,”r”:100,”bh”:65,”bt”:69.8,”br”:0,”pws”:”IFRTH65″,”key”:””},”ifkey”:”bu9J7THcINuUAoUYzayc77″,”mqtt”:{},”wtdata”:{“wp”:”DS”,”h”:82,”p”:0.1,”t”:34.8,”raining”:1},”wterr”:0,”curr”:0,”sbits”:[0,0],”ps”:[[0,0,0],[0,0,0],[0,0,0],[0,0,0],[0,0,0],[0,0,0],[0,0,0],[0,0,0]]}

if running the Fritz!Box capture feature.

or in:

{“devt”:1642760267,”nbrd”:1,”en”:0,”sn1″:0,”sn2″:0,”rd”:0,”rdst”:0,”sunrise”:483,”sunset”:1014,”eip”:3232281121,”lwc”:1642760237,”lswc”:0,”lupt”:1642760239,”lrbtc”:99,”lrun”:[0,0,0,0],”RSSI”:-45,”mac”:”60:01:94:70:87:60″,”loc”:”49.47432,10.94365″,”jsp”:”https://ui.opensprinkler.com/js”,”wsp”:”weather.opensprinkler.com”,”wto”:{“h”:100,”t”:100,”r”:100,”bh”:65,”bt”:69.8,”br”:0,”pws”:”IFRTH65″,”key”:””},”ifkey”:”bu9J7THcINuUAoUYzayc77″,”mqtt”:{},”wtdata”:{},”wterr”:-4,”curr”:0,”sbits”:[0,0],”ps”:[[0,0,0],[0,0,0],[0,0,0],[0,0,0],[0,0,0],[0,0,0],[0,0,0],[0,0,0]]}

if not running the Fritz!Box 7590 capture feature.

The error code of the last response from the weather server “wterr”: -4 describes the network problem as “received empty return”. The “wtdata”: {} is not populated if compared to the successful result. However, there are also cases where the “wtdata”: {} is populated correctly and the last response from the weather server is “wterr”: -4, especially if interfacing my Local PWS weather server!

{“devt”:1642833002,”nbrd”:1,”en”:1,”sn1″:0,”sn2″:0,”rd”:1,”rdst”:1642843770,”sunrise”:481,”sunset”:1015,”eip”:3232281121,”lwc”:1642830714,”lswc”:1642827112,”lupt”:1642791088,”lrbtc”:4,”lrun”:[0,0,0,0],”RSSI”:-52,”mac”:”60:01:94:70:87:60″,”loc”:”49.47432,10.94365″,”jsp”:”https://ui.opensprinkler.com/js”,”wsp”:”192.168.178.39:3000″,”wto”:{“h”:100,”t”:100,”r”:100,”bh”:65,”bt”:69.8,”br”:0,”pws”:”IFRTH65″,”key”:””},”ifkey”:”bu9J7THcINuUAoUYzayc77″,”mqtt”:{},”wtdata”:{“wp”:”local”,”h”:97.26,”p”:0.05,”t”:32.1,”raining”:0},”wterr”:-4,”curr”:0,”sbits”:[0,0],”ps”:[[0,0,0],[0,0,0],[0,0,0],[0,0,0],[0,0,0],[0,0,0],[0,0,0],[0,0,0]]}

This is somehow strange and not understandable? I have also performed a factory reset of the OpenSprinkler and the Fritz!Box router without any success in solving the issue.

Any ideas what went wrong or how to go on with the investgation?

[franzstein]

I don’t need to water the garden during the winter season, so I started the “Empty Response” investigations again.

As I described already, I have a Fritz!Box 7590 router with the latest FRITZ!OS: 07.29 in use. My OpenSprinkler is a v3.0 hardware model. The “About” feature of the OpenSprinkler App reports: App Version: 2.2.4, Firmware: 2.1.9(9), Hardware Version:3.1-DC. This means everything is updated to the newest releases!

I have temporarily installed the OpenSprinkler indoors with a direct WiFi connection to the Fritz!Box 7590 router. No repeaters or powerlines are in use for the WiFi connection. I’ve also switched off my local PWS weather server installation using the default OpenSprinler Weather Service: http://weather.opensprinkler.com.

Unfortunately the OpenSprinkler doesn’t receive the requested Weather Service Details from the OpenSprinkler Weather Service. The answer listed is “Empty Response” and the Weather Service is marked as “Offline” after power on. The weather forecast given by the OpenSprinkler App works and lists “Dark Sky” as the weather provider.

The strange thing is that if I’m monitoring the intranet and internet traffic via the build in Fritz!Box capture feature and analyzing it via WireShark everything works fine. The Weather Service is marked “Online”, the last answer listed is “Success” and the Weather Provider is given as “Dark Sky”.

I really don’t know what went wrong? Is there a possibility to debug the OpenSrinkler request/response messages exchanged with the Weather Service? I think OpenSprinkler receives an error message and it might be worth to look at the error code. If it isn’t a WiFi issue, is it possible to attach an ethernet module to my OpenSprinkler v3.0 hardware model and use a wired connection, instead. Any help would be appreciated.

Thank and regards

Franz

Attachments:

1. 

   OpenSprinkler.jpg
   

2. 

   Empty-Response-20220120.jpg
   

3. 

   Success-20220120.jpg
   

[franzstein]

bekesizl: Compiling the OpenSprinkler isn’t to complicated. You have to follow the instructions given in the OpenSprinkler Support section. Some hints are also given in the forum thread: Error building firmware from source.

If you change the CHECK_WEATHER_TIMEOUT parameter in main.cpp to 1 hour as described above there is a good chance that you see the “Empty Response” answer only once or twice per day. In this way you can probably use your own local weather service for the OpenSprinkler Water% calculation.

I’m not sure what causes the issue. I’s maybe some timing problem due to the longer data travel time if WiFi repeaters are in use. Maybe the OpenSprinkler team can give some hints on what causes the “Empty Response” in detail.

[franzstein]

Some additional information. For the above investigation I used a value of about 20 minutes (1201 seconds) for the CHECK_WEATHER_TIMEOUT parameter. With the OpenSprinkler firmware update to 2.1.9 (9) I’m using a value of about 60 minutes (3601 seconds) polling the weather service every hour.

With firmware version 2.1.9 (9) the issue with the “Empty Response” occurs once twice sometimes three times a day. Please see the attached system status report. Looking at the Fritz!Box or Fritz!Repeater status reports there are no outages or other problems reported for the given weather service request times.

Attachments:

1. 

   Empty_Response_-with_firmware_2199.jpg
   

[franzstein]

@bekesizl: If you haven’t had any issues with your old WiFi setup, it’s maybe worth to use your previous WiFi setup again. Maybe everything is working with the old setup? It might be interesting to know if this solves the issue!

[franzstein]

I encountered the same issue with often getting the OpenSprinkler “Empty Response” from my local weather service installed on a Raspberry PI. I encountered this issue with OpenSprinkler Firmware 2.1.9 (4), 2.1.9 (7) and actual with 2.1.9 (9). I think it’s not caused by the recent firmware update. The “Empty Response” isn’t always reported. Most of the time the weather service is requested successfully.

I’ve done some investigations in June with OpenSprinkler Firmware 2.1.9 (4), and it is maybe worth to share my findings. My WiFi setup consists of a Fritz!Box 7590, a WiFi Repeater Fritz!WLANRepeater 310 and two PowerLines Fritz!PowerLine 1240E, Fritz!Powerline 1260E; all organized as a Mesh System. The Fritz!Box allows for monitoring and analyzing the intranet and internet traffic via WireShark. The OpenSprinkler installed in my garage connects to the WiFi Repeater as this is the nearest local network access. What I can see from the WireShark reports is, that there is no response data missing at all. Please have a look at the attached log files.

Please note that I used a private firmware compilation that requests the weather service every 20 minutes to get this log files. I only changed the CHECK_WEATHER_TIMEOUT parameter in this compilation. Everything remains unattached.

However, I’m not sure if the Fritz!Box capture feature really monitors the intranet traffic between the WiFi repeater and the OpenSprinkler? The data traffic logged is more likely what is captured in or close to the Fritz!Box? It might be interesting to move the OpenSprinkler next to the Fritz!Box, to see if the issue still exists, if no WiFi repeater is involved. I think I will investigate this during the winter season. I don’t need the OpenSprinkler garage installation during this time of the year.

I can still think of let’s say an OpenSprinkler runtime error or some overload problem causing this “Empty Response” – issue. Let’s see if the OpenSprinkler team has some ideas what to do?

Attachments:

1. 

   Empty_Response_at_2048.jpg
   

2. 

   Successful_Response_at_2128.jpg
   

3. 

   WireShark_Screenshot.jpg
   

1. Request_Response_log_data.txt

[franzstein]

I’ve modified the script given above in order to compile the OpenSprinkler firmware 2.1.9(9). Unfortunately the compilation fails with the following error message:

Can’t open perl script “/home/bluetang/OpenSprinkler-Firmware/tools/board_op.pl”: No such file or directory
makeEspArduino.mk:124: *** Invalid board: generic. Stop.

The modifications made to the script are very simple substituting the old Ethernet library:

wget https://github.com/OpenSprinkler/UIPEthernet/archive/fixes/dhcp.zip
unzip dhcp.zip
mv ~/Arduino/libraries/UIPEthernet-fixes-dhcp ~/Arduino/libraries/UIPEthernet

by the new one:

git clone https://github.com/jandrassy/EthernetENC

Following the instructions given in How to compile OS firmware results in the same error.

Any help will be appreciated.

[franzstein]

I’ve compiled the OpenSprinkler firmware 2.1.9(7) using the build instructions given in https://openthings.freshdesk.com/support/solutions/articles/5000165132-how-to-compile-opensprinkler-firmware.

Besides using the modified UIPEthernet library, available in the OpenSprinkler github repository: https://github.com/OpenSprinkler/UIPEthernet/archive/fixes/dhcp.zip, some changes described by the script given above need to be made:

– Rename the library “UIPEthernet-fixes-dhcp” to “UIPEthernet”
– Get the library for the OLED display from https://github.com/ThingPulse/esp8266-oled-ssd1306.git, but backup to 4.1.0 as the latest version of the OLED code isn’t compatible:
cd ~/Arduino/libraries/esp8266-oled-ssd1306, git checkout tags/4.1.0
– Rename the library “esp8266-oled-ssd1306” to “SSD1306”.
– Get the library for the MQTT Arduino Client for MQTT from: https://github.com/knolleary/pubsubclient.git and remove the tests directory as it will not compile but is unnecessary: rm -rf ~/Arduino/libraries/pubsubclient/tests

With these changes the compilation was successful. The Ubuntu based Linux-Distribution Linux Mint 20.1 (Codename Ulyssa) with its Cinnamon Edition was used to perform the compilation. VirtualBox 6.1.22 was installed to run Linux.

[franzstein]

It is my understanding that the OpenSprinkler team only pays for weather queries to DarkSky right now. There might be additional costs for hosting the weather service itself at Amazon Elastic Beanstalk (AWS EB). However, this should be better confirmed by Ray to be on the safe side!

[franzstein]

I’ve found some time to look at the OpenSprinkler firmware in more detail.

Opensprinkler firmware 2.1.9(7) periodically polls the weather service every 6 hours. The corresponding code can be found on GitHub in OpenSprinkler/OpneSprinkler-Firmware /main.cpp, line 59:

#define CHECK_WEATHER_TIMEOUT 21613L // Weather check interval (in seconds)

Looking up older firmware releases shows that the weather service check interval was increased from 1 hour to 2 hours with firmware release 2.19(4) and thereafter from 2 to 6 hours with firmware release 2.19(5).

Reason for this increased weather check interval is to reduce jamming the weather service as this will produce additional costs in regards to using costly weather providers. However, there are some problems if the sprinkler activity is planned to start at sunrise time or earlier than 6am in the morning:

• Common weather changes, like early morning rainfalls remain probably be unrecognized by OpenSprinkler and lead to wasted water.
• In regards to using weather adjustment methods like Zimmerman, the calculated water level polled by OpenSprinkler may be outdated or not based on yesterday’s
weather data.

To avoid these problems I used a programmable power timer to restart OpenSprinkler every Sunday at 0:45am. This leads to a weather service update for the whole week at about 6:45am in the morning well before my 7 am sprinkler watering.

Another possibility might be to shorten the service check interval to 1 hour again. This might be done by updating OpenSprinkler with a private compilation of the OpenSprinkler firmware. As already mentioned the OpenSprinkler team has to pay for all weather queries. For this reason a local weather service installation accessing a personal weather station will be mandatory to avoid any expenses for the OpenSprinkler team.

I’m currently using this updated OpenSprinkler together with a local Netatmo PWS and a Raspberry Pi weather service installation. This allows me to go back to sunrise garden watering again. However, there might be other ideas to avoid the disadvantages described above. Maybe introducing a more controlled weather service polling right before any scheduled watering program will do the job?

Regards

Franz

[franzstein]

Hi Ray,

How I interpret the weather service script caching of the watering percentage will only be performed for Dark Sky. Maybe I’m wrong, but there is no consistent watering percentage across a day for the other weather providers, especially in case of a local PWS.

Can you please give me a hint where I can found the weather service call in Opensprinkler firmware 2.1.9(7) and how I can change it to be executed more often in case of interfacing a local installation of the weather service?

Thanks and regards

Franz

[franzstein]

Above comparison of weather sources (providers) indicates a Netatmo/WeeWX driver issue of reporting incorrect rain data (https://github.com/matthewwall/weewx-netatmo/issues/18). This issue of reporting incorrect WeeWX rain summaries for the Netatmo local PWS is solved now.

Thanks to J. Krasinger there exists an updated version of the WeeWX/Netatmo driver. Please have a look at: https://github.com/jkrasinger/weewx-netatmo/. The updated driver code works with Python 2.7 und 3.x (running with versions WeeWX < 4 and WeeWX = 4.x). It can be easily installed by following the given installation instructions. First tests were performed within an existing Raspberry PI setup running WeeWX version 3.9.2. As expected, the WeeWX rain summaries correspond to the Netatmo statistics. At the end of the day the same total amount of rain is displayed on the Netatmo, Weather Underground and WeeWX web interfaces.

[franzstein]

Please find below the results of my comparison. The results are based on German weather conditions and may differ for other climate regions.

Zimmerman Local PWS:
I’m hosting an own weather server consisting of a Raspberry PI connected to my local WiFi network. A WeeWX installation running on this Raspberry PI retrieves the Netatmo PWS weather data every 5 minutes from the Netatmo cloud service. The OpenSprinkler weather service runs on the same Raspberry PI and uses this weather data as input for the Zimmerman watering scale calculation. The weather data needed for the OpenSprinkler watering scale calculation reflect local weather conditions. However, there exists an issue with short rainfall periods. The precipitation amount isn’t correctly summed up by WeeWX. The total precipitation listed by WeeWX is less than actually summarized by Netatmo. Therefore a negligible chance of watering the garden a little bit more than needed exists.

Zimmerman WU:
Additionally, I`m using the Meteoware Service to retrieve the Netatmo PWS weather data every 10 minutes from the Netatmo cloud service and forward the data to Weather Underground. Weather Underground can be interfaced by the OpenSprinkler weather service if a PWS station name and a valid API key is acquired by Weather Underground. The official weather service provided by OpenSprinkler, as well as a local copy of this weather service running on my Raspberry Pi can be used for weather adjustments. The weather data needed for the OpenSprinkler watering scale calculation perfectly reflect local weather conditions, including correct precipitation measurements.

Zimmerman DarkSky:
The official OpenSprinkler weather service by default uses the DarkSky API. At my hometown DarkSky provides only weather reports for the whole Nuremberg area. Especially the amount of rain differs a lot from the actual situation at my home. This means weather data delivered by DarkSky does not reliable reflect local weather conditions. It makes little sense for me to use DarkSky for my OpenSprinkler installation. It will lead for most of the time to insufficient watering of my garden.

The Evapotranspiration (ET) Method:
The ET Method sticks to DarkSky as weather provider for reason that Local PWS and Weather Underground data lacks the ‘solar radiation’ parameter. As already mentioned, DarkSky provides untrustworthy local weather data for my home location, which results in insufficient garden watering. Without having access to a local weather station the ET Method will still be nice to have but isn’t usable for my OpenSprinkler installation.

In summary the Zimmerman method in conjunction with my Private Weather Station (PWS) is the best suitable weather adjustment method for me. Both weather sources, Weather Underground and WeeWX provide acceptable weather data for the OpenSprinkler Weather Service. Hosting an own weather server isn’t always needed. At least for Netatmo Personal Weather Stations cloud services like Meteoware can be used to fill the missing link between Netatmo and Weather Underground.

The official OpenSprinkler weather server uses caching so the watering percentage during a day does not vary. Hosting an own weather server or using Weather Underground relies on the last 24 hour’s data for the Zimmerman calculation. The calculated watering scale will be updated during the day in accordance with the ongoing weather changes. My experience shows that this isn’t an issue in regards to the garden watering needs. It is more important to have access to a trustworthy nearby weather data source or a Private Weather Station.

[franzstein]

I found the solution by capturing the the weather service request with WireShark:

Zimmerman WU - http://weather.opensprinkler.com/weather1.py?loc=49.47432,10.94365&wto="h":100,"t":100,"r":100,"bh":65,"bt":70,"br":0,"pws":"IFRTH65","key":"Wunderground newAPI Key"

My current understandig is that DarkSky uses Yesterday’s weather data, whereas Local PWS and Wunderground use the last 24 hour weather data for the Zimmerman calculation. Please correct me if I’m wrong?

[franzstein]

I would be careful with the rain parameter and leave it as is 0mm = 100%. It is maybe better to find out if there is enough watering in sunny conditions? If there is a certain amount of rain it’s maybe not necessary to water at all? You can also play with the Excel Sheet to see what will happen.

[franzstein]

I have redone the screenshot. It contains all information now.

In regards to Zimmerman, please have a look at this older post discussing the Zimmerman Method: https://opensprinkler.com/forums/topic/do-people-use-zimmerman/. There are more details on how to find proper baseline values.

Attachments:

1. 

   Configuration-1.jpg
   

[franzstein]

The missing value in the screenshot. I was not able to provide the screenshot with this value!

[franzstein]

Sorry. Temperature value is 21 C.

[Author]

Posts