OpenSprinkler Forums OpenSprinkler Unified Firmware Announcing OpenSprinkler Unified Firmware 2.1.9

This topic contains 10 replies, has 5 voices, and was last updated by  Ray 1 day, 5 hours ago.

Viewing 11 posts - 1 through 11 (of 11 total)
  • Author
  • #62754


    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:

    We strongly recommend you to take a look at the firmware user manual to understand the details:

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

    • This topic was modified 2 weeks ago by  Ray.
    • This topic was modified 2 weeks ago by  Ray.
    • This topic was modified 2 weeks ago by  Ray.


    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?



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



    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.



    I didn’t see a threshold converter on here, but this site has soil moisture sensors and accessories for sale.
    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




    Vegetronix also sells these relay boards:
    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.



    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?

    • This reply was modified 1 week, 1 day ago by  jnissen.


    -“I am one of the few who have a Weatherunderground API key that actually works”
    As we described in this support article:
    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.



    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!

    • This reply was modified 5 days, 16 hours ago by  mistral77.


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

    PWS Capture

    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.



    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.

    • This reply was modified 1 day, 5 hours ago by  Ray.
Viewing 11 posts - 1 through 11 (of 11 total)

You must be logged in to reply to this topic.

OpenSprinkler Forums OpenSprinkler Unified Firmware Announcing OpenSprinkler Unified Firmware 2.1.9