Announcing OpenSprinkler Unified Firmware 2.1.9

[Ray]

Announcing OpenSprinkler Unified Firmware 2.1.9

First of all, apologies for taking so long to release this firmware. Several technical issues occurred during the last couple of weeks that slowed down the progress. Good thing is that they have been ironed out so today we are ready to release the new firmware 2.1.9. While this version isn’t a breakthrough and left many features to be desired for, it does involve some fundamental changes to the storage structures which will make it easy to expand features in the future.

Eligible Hardware

Firmware 2.1.9 is available for OS 2.3, 3.x, and OSPi. Unfortunately it’s not available for legacy OS any more (e.g. version 1.x, 2.0, 2.1, 2.2) due to the firmware size. If you are interested in upgrading your legacy OS, please submit a support ticket and in many cases we are happy to provide upgrade discounts.

OS 3.x and OSPi can be directly upgraded to this firmware. For OS 2.3, a microSD card is required by this firmware. Most OS 2.3 units already have microSD card, except some very early batches. If your OS 2.3 does not have a microSD card or if there is corruption, you will see a 0x2D error at booting. If you encounter this error, you can install a microSD card of any capacity (4GB and 8GB are the most common ones) formatted to FAT32.

What’s New in this firmware?

• Controller settings, zones settings, and program data are now stored as separate files in flash or SD card. This paves the way to significantly expand program and zone data in the future. It can also eliminate the need to factory reset all settings when upgrading to future firmwares.
• The number of programs is increased to 40. Maximum length of station and program names is increased to 32. For OSPi (or Linux-based system), maximum number of zones is increased to 200. For other OS, maximum number of zones is still 72 as before.
• For OS 3.x, support for the second sensor has been added. Each sensor can be independently set as any of rain sensor, soil sensor, or program switch. Sensor1 can additionally be configured as flow sensor (as before). Note that for soil sensor, the only supported type is one that outputs binary signal (similar to how rain sensor works).
• For rain and soil sensors, this firmware supports ‘Delayed On Time’ and ‘Delayed Off Time’ parameters, which provide flexible control on when the sensor is treated as activated or deactivated.
• Zone attributes now have three separate options: ‘Ignore Sensor1’, ‘Ignore Sensor2’, and ‘Ignore Rain Delay’ (previously there was only one ‘Ignore Rain’ option). For each zone, you can individually set the three options.
• Support for ET (evapotranspiration) algorithm has been added (this has been announced a while back). In addition, this firmware supports using WUnderground PWS station as weather data source.
• For OS 3.x, this firmware has switched to use ESP8266 core 2.5.2 (the latest version).
• This firmware tracks the weather data used for watering percentage calculation as received from the weather server, as well as the most recent reboot cause. These are also displayed in the UI/app under ‘Diagnostics’.
• Several bug fixes, and documentations (including firmware update, user manual, API doc, compilation instructions) have been updated to the latest.

Before you upgrade

• Save a copy of your configurations before you update firmware.
• If you use the OpenSprinkler mobile app or desktop app, make sure to update your app to the latest version (2.1.1 at the time of this writing), otherwise some new features of this firmware will be invisible. If you access the controller directly via a web browser, you are all set, the web UI is already updated.
• There is always a risk of updated firmware breaking some functionality that you are used to. If problems occur, please be patient and submit a support ticket for help.

How to upgrade?

Please follow the instructions here to update:
https://openthings.freshdesk.com/support/solutions/articles/5000381694

We strongly recommend you to take a look at the firmware user manual to understand the details:
https://openthings.freshdesk.com/support/solutions/articles/5000716364

There are some limitations / quirks that are good to keep in mind, such as:

• Flow sensor is only supported on the first sensor port (sensor1) but not the second (sensor2).
• For soil sensor, the only supported type is one that outputs binary signals (e.g. Hunter’s Soil Clik) — analog soil sensors are not supported at this time (though a work-around is to use a analog to digital threshold converter)
• When configured as Program Switch, sensor1 triggers program 1, and sensor2 triggers program 2.
• To use PWS station as weather data source, you need to set the Wunderground API key first (in Advanced tab), save, then you can go to Location and select a PWS station.
• When using PWS station, ET algorithm will not work as it requires data (specifically solar radiation) that’s not available through the WU API.

Firmware API

Those who make use of the firmware API should take a careful look at the new API document:
https://openthings.freshdesk.com/support/solutions/articles/5000716363
as there have been several major changes from previous firmware versions, particularly in the way ‘change options’ (/co) is handled. For example, it only accept option’s json name and no longer accept option’s index. Also, due to the support of two sensors, some variable names (e.g. urs, rso) have been changed to accommodate two sensors.

Support questions

While we’ve done our best at testing the firmware internally, there may be bugs that we didn’t discover, particularly those that require long-term testing. If there are technical issues, please don’t freak out. You can always submit a support ticket and we will promptly help.

[ruimarinho]

Hi Ray,

This is great! Already looking forward for 2.2.0 with MQTT support 😉

Are these soil sensors an improvement over rain sensors? Are they generally worth it?

[Ray]

Technically soil sensors should be more preferable because they sense the moisture content in the soil, so they are more accurate at telling how much water the plants need. But soil sensors are generally more complex, more expensive, less reliable and lacking common standard compared to rain sensors. While rain sensors give you a simple binary value, soil sensors usually output analog values that can be all over the place, That require calibration, and temperature compensation if you really care about accuracy.

Since OpenSprinkler’s sensor ports are digital only, it can’t read analog signals anyways, so the work-around is to use a threshold converter. Our German distributor has identified one:
https://opensprinklershop.de/product/zpr-21-schwellwertschalter-0-10v-dc-als-zweipunktregler/
basically it takes an analog input, provides an adjustable threshold, and outputs a binary signal.

Looking into the future, I’ve kept my eyes on ESP32, which has a lot more GPIO pins and analog pins. If we update OpenSprinkler hardware to use ESP32, that can open up the possibility of reading analog sensors directly.

[ruimarinho]

Thank you very much for the explanation. So in this situation, Hunter’s Soil Clik probably comes with a built-in threshold converter.

I agree, the ESP32 would be a tremendous option.

[Mike]

I didn’t see a threshold converter on here, but this site has soil moisture sensors and accessories for sale. https://www.vegetronix.com/
I’m using the analog output from one of their sensors in my own home-brew solution and it’s been working reliably for a few years. You can see data from the past few days from my system here https://thingspeak.com/channels/239044

Mike

[Ray]

Vegetronix also sells these relay boards:
https://www.vegetronix.com/Products/VG-RELAY-DC/
which take the soil sensor as input, and output digital binary signal (through its relay). I haven’t looked carefully but I see a potentiometer on the circuit board which I assume is used to set the threshold.

[jnissen]

Thanks to you all who have been working on this. Just updated OTA to 2.1.9 and it’s working. I am one of the few who have a Weatherunderground API key that actually works. I have a backyard weather station that is uploading data to WU so they allow us up-loaders to have a key free of charge (yeah big spenders). I put in the key and it verifies with a green box. I selected Zimmerman as the weather algorithm. Only unknown was the device ID section. I left that blank and did not put anything in there. Was the correct and what is that used for?

I did a reboot and checked the system diagnostics screen. Says the system reboot, weather calls, response, and sucess(0). IT then gives me a mean Temp, Humidity, Precip, and % watering. What I didn’t expect was a link to Powered by Dark Sky. I thought since I installed the WU API it would have a link there. I believe it’s still Dark Sky data since the temp reported is about 1.5 degrees higher than my present backyard weather center is reporting to WU.

How can I tell where the weather data is being pulled from?

[Ray]

-“I am one of the few who have a Weatherunderground API key that actually works”
As we described in this support article:
https://openthings.freshdesk.com/support/solutions/articles/5000017485
currently there is still a way to obtain a WU key even if you don’t own a physical PWS device.

-“device ID section”
This doesn’t matter, you can ignore it. This is for OS 2.x.

-Please note that to use WU PWS, you must select a PWS. To do so, go to Edit Options->System and click on Location, it should show you PWS stations near you in blue dots. You need to select one of them. If you don’t select a PWS (blue dot), it will still use DarkSky. This is because WU API only works if the location is in the form of a PWS name. GPS coord does not work with WU API.

[mistral77]

Hello
I just followed the instructions to upgrade my ospi , built with no error, reboot raspberry and i’m not seeing any difference i’m still seeing 2.1.8 (1) version in the about section and no need to import the settings backup !
I thing that the upgrade is not installed!
Any help is appreciated!
Thank u for your help!

Attachments:

1. 

   Screenshot_2019-10-08-14-41-08-538_com.albahra.sprinklers.jpg
   

[jnissen]

If I try to select one of the PWS dots in my neighborhood it shows like this:

The problem is that when I select ANY blue dot the same info is capturted for the generic area and the specific PWS is not selected. Is it possible to change the app to allow us to enter the PWS code in directly? For example pws:KTXAUSTI234 which is a specific WU station? Right now I can see the dots but it still does not actually select the unique station. Only the generic area and then Dark Sky seems to take over.

[Ray]

When you select a blue dot, the ‘Location’ will still show the GPS coord. The PWS name is recorded into a field called ‘wto’ (weather options). The reason is that the GPS coord is needed for certain calculations like the time zone. So GPS coord is always shown in the ‘Location’ field.

If you want to verify that the PWS name is indeed recorded, you can export your configurations into a file, open it in a text editor, and see a variable called ‘wto’. It should have the PWS name there.

Also, as we explained in other posts, when you use PWS, you need to select ‘Zimmerman’ as the weather adjustment method. ET algorithm is NOT supported when you use PWS.

[dun4cheap]

Two questions.

What is the difference between FW2.19 and FW 2.19 rev 2

2nd Question I have quite a few OS3 but I have 1 OS3 with lan. When I goto to the x.x.x.x/upodate I get result 2 on it. This is not covered in the FW guide.

Thanks,

Ed

[Ray]

1: minor rev(2) fixes a minor issue where when the log is empty (i.e. no data at all), it gives a ‘error retrieving log’ error.
2: the address is x.x.x.x/update, not x.x.x.x/upodate. Also, OTA update is ONLY supported when the controller is in WiFi mode, it’s not supported if you are using wired Ethernet module. This is already explained in the firmware update instruction:
https://openthings.freshdesk.com/support/solutions/articles/5000832310

[leeelson]

This firmware shows “reboot reason” and a number. Where can we find the interpretation?

[Ray]

The reboot reasons are documented on the last page of the firmware API document:
https://openthings.freshdesk.com/helpdesk/attachments/5114870617

[mmavrof]

Hi,
I have an OS H/W v. 2.3 DC device and upgraded the firmware from v. 2.1.7 to 2.1.9 a week ago.
Since then, I faced the following problems:
1. Long delays in connecting the app (web and mobile) with the OS device, either on LAN or WAN.
2. Unexpected (very often) reboots of the OS device (Last reboot reason = 99 [i.e., ‘power-on’, which, obviously, was not the case]).
As a result of the above (constant) behavior and since I have not read for any bugs of v. 2.1.9, I thought that it was a H/W failure of the OS device. Therefore, I replaced it with a brand new one device (OS H/W v.2.3 DC, which I have bought as a backup) and installed firmware v. 2.1.9. To my surprise, I noticed exactly the same malfunctioning behavior.
As a consequence, I downgraded to v. 2.1.7 and the device is running smoothly.
Has this behavior been reported by anyone else? Should we expect a (minor) revision to v. 2.1.9, addressing these errors and when?
Thanks in advance,
MM

[Ray]

@mmavrof: We’ve tested OS 2.3 DC for a long time on FW 2.1.9 and didn’t observe the issues you reported. It has been connected to our test network through a WiFi adapter for days and there was no reboots.

Reboot reason 99 just means the controller experienced a complete reboot sequence, it didn’t mean you manually switched it on/off, it means something else is causing it to reboot, could be a power adapter issue, or something else.

The only reason I could think of, that would explain why 2.1.7 works fine but not 2.1.9 in your case is that 2.1.9 uses the UIPEthernet library, which is a popular open-source library for managing Ethernet connections. This might be causing issue on your particular network, but as I said, we have a test OS 2.3 DC on our network for days without any issue.

One thing to check is: does your controller exhibit the issues reported under factory default settings, or after you have imported your previous configurations? If it’s the latter, it could be that some configurations are causing the issue, which we are not aware of.

[mmavrof]

@Ray: Thanks for the immediate response!
In replying to your question, I imported previous configurations. However, in order to overcome the issues, I have tried all ‘Reset’ options, i.e., ‘Clear Log Data’, ‘Reset All Options’, ‘Reset All Station Data’; after the last options, I have imported previous configuration.
Regarding the Ethernet case (hoping that this information would help in resolving the issue), I am using the TL-MR200 4G Router.

[Ray]

I would recommend doing a factory reset (when you upgraded from 2.1.7 to 2.1.9 it will automatically trigger a factory reset, or you can manually do a factory reset — not using the Clear Log, Reset All Options etc, but using the buttons, as described in the user manual, to trigger a factory reset). Test, see if the symptoms exist, before you import any configurations.

[mmavrof]

@ray: Thanks for the recommendations!
I upgraded to 2.1.9 and then did a factory reset (without configuring anything else). I noticed again network delays and connection issues.
After approx. 10 hours, I imported the production configuration. The network problems continued. Actually, I experienced total (permanent) loss of connection and therefore I had to restart (power-off and on) the controller. Therefore, I returned back to 2.1.7.
It seems that there may be an issue with the Ethernet library. Could be a compatibility issue of the library Ethernet implementations with the router’s one(?)
Awaiting for any further news/suggestions.

[Ray]

I don’t have this particular router to test so unfortunately I can’t diagnose the issue. The library used in firmware 2.1.9 is UIPEthernet, which is a pretty popular library and should be compatible with most routers. One thing you may try is to set a static IP (we recommend doing so on the router, using DHCP reservation, but you can also try it on the OpenSprinkler controller, by settings the static IP, gateway (i.e. router) IP, subnet mask, DNS IP correctly. Not sure if this makes any difference.

[oldmate32]

Hi, I notice in the app the master on and off delay setpoint limits are 60sec, whereas the manual says the range should be 600sec. Was this changed for 2.1.9? Is it possible to change it back to 600sec?

The longer time of 600sec would be good for my application. I’ve got an air intake on the manifold to prevent siphoning into dripper line. I turn the master off and leave the zone open for an extended period to allow the line to drain via the air intake, rather than sucking dirt into the higher drippers as the line empties via gravity.
Cheers

[Ray]

@oldmate32: I will check with Samer about this in the app. I am pretty sure the firmware accepts the range to 600. In the meantime, you can adjust option values on the controller directly using buttons. Specifically, power off the controller, right after powering it back on, press and hold the third pushbutton B3 and continue holding it until the display says ‘Setup Options?’. Click B3 as many times as you need until you see the Master On Delay or Master Off Delay option. Use B1 and B2 to adjust the numbers. When you are all set, press and hold B3 until the controller reboots itself. The values are now saved.

[oldmate32]

Thanks Ray, I will adjust the values using the buttons to get me up and running.

[mmavrof]

@Ray: Thanks for the (new) suggestions and information!
I am (and always was) using static IP for the OS controller. However, I ‘ll try to experiment more with the network configuration.

[Author]

Posts