OpenSprinkler Forums OpenSprinkler Unified Firmware Announcing OpenSprinkler Unified Firmware 2.1.3 (for AVR/RPI/BBB/LINUX)

This topic contains 32 replies, has 8 voices, and was last updated by  Samer 4 years, 2 months ago.

Viewing 15 posts - 1 through 15 (of 33 total)
  • Author
  • #35736


    Hi All,

    A new OpenSprinkler firmware (number 2.1.3) is now available. This is the first unified firmware that can compile and run on all current OpenSprinkler hardware platforms, including

    • OpenSprinkler 2.x (sorry, 1.x is no longer supported)
    • OpenSprinkler Pi (OSPi) all versions
    • OpenSprinkler Beagle (OSBo) all versions

    The cross-platform idea was inspired by Rich Zimmerman’s sprinklers_pi program. The purpose of this is to make a fully consistent firmware for OS, OSPi and OSBo. The program is written in C++, so it’s not as modification-friendly compared to Dan’s Python-based interval_program. Also, there is no plugin architecture currently. However, as I said, the primary goal of this is to make OSPi and OSBo’s firmware maximally compatible with OS, so that any new features introduced in OS will also be simultaneously available to OSPi and OSBo.

    New Features:

    The main added new feature of this firmware is the support of using sunrise/sunset times in program settings. Specifically, the program’s first start time (and any of the additional start times) can be defined using sunrise/sunset time +/- an offset (in steps of minutes) up to 4 hours. The program preview will also take into account the sunrise/sunset time of a specific day.

    For OSPi/OSBo, this also means all features available on the OS, such as individual station water time, Zimmerman’s weather-based water adjustment, and support for radio frequency stations, are also available for OSPi/OSBo.

    MD5 hashed password:

    This firmware supports MD5 hashed password. The latest web UI and OpenSprinkler app have been updated to support this as well. To the end user, this should be transparent as the web UI and app will automatically detect the firmware version and upgrade any plain-text password to its MD5 hash.

    However, if you have a custom script that directly calls OpenSprinkler’s HTTP GET commands, keep in mind that the plain-text password is no longer accepted — you must use the MD5 hash of the password. For example, if you have been using GET command like http://x.x.x.x/jc?pw=opendoor, this needs to be changed to http://x.x.x.x/jc?pw=a6d82bced638de3def1e9bbb4983225c where the 32-byte hex code is the MD5 sum of ‘opendoor’. Similarly, if you have been using http://x.x.x.x/su to change the Javascript url, the password you input there must be the MD5 hash. You can easily calculate the md5 sum of any string using the md5sum command in Linux or md5 command in Mac.

    Upgrade OS 2.0/2.1/2.2 to Firmware 2.1.3:

    To upgrade OS 2.0/2.1/2.2 to firmware 2.1.3, please follow the Firmware Upgrade Instructions.

    Upgrade OSPi/OSBo to Firmware 2.1.3:

    Because this is the first unified firmware for OSPi and OSBo, we are currently releasing it for OSPi and OSBo as a beta test. Once any potential issues have been ironed out, we will make a new SD card image for each platform and set the unified firmware as the default firmware to run on startup. For now, the procedure to upgrade to firmware 2.1.3 is as follows:

    1. In command line, go to the home folder (cd ~) and run
    git clone
    to clone a fresh copy of the repository.

    2. Go to the folder (cd OpenSprinklerGen2), and run
    sudo sh ospi
    for OSPi. This will generate an executable program called OpenSprinkler, and also set up startup script for it to run automatically on booting.

    Similarly, on OSBo, run
    sudo sh osbo
    Please make sure you run the correct command for OSPi or OSBo, because they have completely different pin settings.

    3. Before you reboot, keep in mind that by default the OpenSprinkler program will use HTTP port 8080. If you have an existing program or service that’s already using port 8080, such as Dan’s or Rich’s sprinklers_pi, please stop these programs first, to avoid port conflict. Specifically:

    sudo /etc/init.d/ospi stop
    sudo update-rc.d ospi remove

    will stop the program. Similarly,

    sudo /etc/init.d/sprinklers_pi stop
    sudo update-rc.d sprinklers_pi remove

    will stop the sprinklers_pi program.

    Note: the new BeagleBone Debian image may be using 8080 internally for apache2. If this is the case, follow these instructions to change the apache2 port number to something other than 8080.

    4. Reboot RPi and BBB, and the firmware should be good to go.

    Keep in mind that there may be bugs and potential issues not discovered during internal testing. If you encounter any problems, please just report the facts. Don’t vent your frustrations or disappointments as they do nothing at helping us get your problems resolved quickly. Thank you.

    Run Software Simulation of firmware 2.1.3:

    Since the firmware uses standard socket, which is supported by most Linux systems, you can also compile and run a software simulation. The instructions are similar to OSPi and OSBo, but using -DLINUX macro define as opposed to -DOSPI or -DOSBO. Also, if you are compiling it in 64-bit Linux, you need to add command line parameter -m32 to force 32-bit compilation (and make sure you have 32-bit libraries ‘ia32-libs’ installed).
    gcc -o OpenSprinkler -m32 -DLINUX main.cpp OpenSprinkler.cpp program.cpp server.cpp utils.cpp weather.cpp gpio.cpp

    Technical Details

    The unified firmware is designed to share code between OS, OSPi and OSBo as much as possible. The major differences are that on OS, all non-volatile memory data (such as options, program settings) are stored in EEPROM, while for OSPi/OSBO, these are stored in a local file called nvm.dat. Also, OSPi/OSBo uses the standard socket to handle Ethernet communication, while OS uses JeeLab’s EtherCard library. Other than these, the code is largely shared between them, making it easy to extend in the future.

    Support for RF Stations on OSPi/OSBo

    Support for RF stations (e.g. remote power sockets) is also available for OSPi/OSBo. This feature leverages the RFToy, and details can be found in this blog post.

    Currently OSPi and OSBo do not have dedicated pin headers for RF transmitter. The firmware by default uses the relay pin as data pin for RF transmitter. Just wire 5V, GND, and data pin to an RF transmitter and that should make it work. The reason the relay pin is used by default for RF data is that the built-in relay will be retired (i.e. removed) on all future OpenSprinkler hardware. This is because the relay is rarely used feature, and it can be substituted by an external 24V AC relay (see my recent post about 24V AC relays). As a result, I don’t see any point keeping the built-in relay. This will free up the relay pin to be used for RF data pin instead. If you want to change it to use a different pin, you can easily modify the pin definition in defines.h.

    Hope this is good to get you started playing with firmware 2.1.3!

    • This topic was modified 4 years, 5 months ago by  Ray.
    • This topic was modified 4 years, 5 months ago by  Ray.
    • This topic was modified 4 years, 5 months ago by  Ray.
    • This topic was modified 4 years, 5 months ago by  Ray.
    • This topic was modified 4 years, 5 months ago by  Ray.
    • This topic was modified 4 years, 5 months ago by  Ray.
    • This topic was modified 4 years, 5 months ago by  Ray.
    • This topic was modified 4 years, 5 months ago by  Ray.
    • This topic was modified 4 years, 4 months ago by  Ray.
    • This topic was modified 4 years, 4 months ago by  Ray.
    • This topic was modified 4 years, 4 months ago by  Ray.


    I did a little testing, but I’m having a problem getting ospi stopped. (I’ve have my OSBo for about a month.)

    I get to these commands:

    sudo /etc/init.d/ospi stop<br style=”color: #000000; font-family: ‘Courier 10 Pitch’, Courier, monospace; font-size: 14px; line-height: 19px; white-space: pre-wrap; background-color: #fbfbfb;” /> sudo update-rc.d ospi remove

    and I get this error:

    update-rc.d: /etc/inti.d/ospi exists during rc.d purge (use -f to force)

    Am I missing something. I’d like to switch over to the new firmware to take advantage of the sunrise/sunset feature, but I can seem to stop ospi from restarting.



    The main purpose of removing is to make sure there is no port conflict on 8080. The error you encountered seems to suggest that ospi is not installed or not installed in the way officially documented. You can simply open a browser and type http://ospi:8080 where ospi is your Pi’s IP address. If nothing shows up, that means nothing is occupying port 8080, and you can just proceed to install the unified firmware.

    • This reply was modified 4 years, 5 months ago by  Ray.


    Alright, I was pretty excited at first about this release up until I installed it and went to configure the dusk to dawn feature for lighting. Maybe I missed a setting or something, but I see the option to start the program either at dusk or at dawn, but I must be missing the feature to the end program feature at dusk or dawn. For this to really be a practical feature for this device it really requires both start and end settings and not minutes for the station.

    Maybe I missed this somewhere which is possible and I really hope so.

    Anyhow, please let me know if I just missed this or if it is an upcoming firmware upgrade this week. Other wise I really do not see a purpose for half of a feature.




    What do you mean by ‘end program feature’ — the end time has already been removed since firmware 2.1.0. Can you clarify what you mean?



    Dusk to dawn, I want to create a program to turn my light relay on st dusk and then turn it off at dawn. Unless I missed something I cannot turn it off only on.



    OK, I see. Well, that’s not something the firmware supports currently — because it’s focused on sprinkler programs, it currently only supports ‘start a program at some specific time’, run for a specific amount of time, and then stop. It’s kind of like calendar events — each event has a start time, and fixed duration.

    What you want to achieve (turn lights on from dusk to dawn) is somewhat different in that the duration varies and it requires introducing an ‘end time’ . There is no reason why it can’t be supported, but it does require changing the program data structure. I will think about how to add this support.



    I appreciate that Ray, I manage a large (very large HOA) that has over 50 irrigation controllers with an avg of 18+ stations along with common area lights which currently run off analog timers which I have to have my crew manually adjust them every month to compensate for the dusk to dawn times, and so on. (These are spread out over 69 acres and each one are in a locked meter room which means a lot of labor time to accomplish an easy task.

    When I originally came across your controller and realized its capabilities, I began writing a control center for windows to manage these controllers with the intent on controlling every aspect from irrigation and light controller. Along with this I have began installing a wireless mesh with ubiquity radios, and installing IP Cams as well. All is coming along including your controllers. However with the changes that you have made your great firmware upgrades, I stopped developing my windows control center for them for now, because you guys were going in the right direction for full automation. (And you still are)

    I am not sure you need to adjust your programming much, I just need them to start at dusk which is now available, the program can dynamically change the run time for the light station automatically by calculate how many minutes it needs to stay on by comparing it to how many minutes there is from the current dusk to dawn times each time it runs. So a few lines of code will suffice. Keep in mind I am using the same controller for irrigation and lights and in the future maybe for more applications. This was made possible when the feature to run multiple programs and stations simultaneously by option was added a few months ago.

    With the new firmware release you mention making some upgrades and changes with V 3.0 hardware, I think you are continuing to go in the right direction with some great features. My crew already uses an android app I wrote for them to assist with logging stations, sprinkler types, gps locations and other features for our controllers to make it easier to mange them. I hope maybe, just maybe in the future information like this can be stored on the controller which with the addition to memory I think it will be. One of the other big things would be being able to upgrade the firmware remotely and retain the settings. But all in good time I am sure.

    You may in the future also want to consider renaming your product slightly.  Opensprinkler to many of my colleagues and customers means nothing more than an irrigation controller. It is much more.

    Lastly, I don’t know if you considered that someone would consider using your device in such a large scale (50 Devices or so), but you maybe surprised that I am sure there are some others. I do see a minor problem in the future for someone like me with using the weather reports. If I have 50 devices looking for weather reports I will exceed my max real quick without having to change my plan with weather bucket. I could understand this if I was pulling weather from different areas but i am not. Maybe one device or the controllers could be redirected to check my server and I could have my server check it for all. I have not looked in to this yet as it has not come to play yet, but it will. I am pretty sure it will effect others as well.

    Thanks for your time,






    Awesome work Ray,

    What about the cloud support to control OS through internet rather than using port forwarding as it has some issues with certain GSM providers,

    I hope we could see it soon in new firmware.




    @dun4cheap, thanks for your comments. Regarding renaming the product, I did think about it as I was indeed trying to make OpenSprinkler more general and be able to switch more devices other than sprinkler valves. If you think about, it’s fundamentally a web-connected, reasonably complex timer system. Controlling sprinkler valves is obviously one applications, but other types of appliances, and home (indoor or outdoor) lighting also often need time-based control and can certainly benefit from web-connectivity. My hesitation is that I’ve heard from many friends that it’s important to market a product with a dedicated purpose — advertise OpenSprinkler as a general-purpose control may have adverse effect. That’s why I’ve kept naming it OpenSprinkler, with extensions to other applications. Hope this makes sense.

    About weather feature with a large-scale installations — one solution is to reduce the call frequency — right now the firmware is sending a query to the weather script once every 15 minutes. In practice it probably doesn’t need to be called so frequently. So reducing it to once per hour can significantly reduce the total number of quires. The other solution is to upgrade wunderground account to a paid type, which gives you a higher quota. I realize that this is a burden on the consumer, and we have been thinking about purchasing a paid account ourselves so that the consumers will not need to apply for a separate wunderground key anymore. We haven’t figured out all the details yet, especially we don’t want third parties to take advantage of our script and drain the quota. So for the time being, the above two solutions should work for large-scale installations.



    I have a 1.1 (maybe 1.2/1.0) version of the OpenSprinkler Pi board – it doesn’t have the rain sensor header on it. With this new unified interface, what pins on the Pi should I be putting the rain sensor wires on? Is this even still possible? Thanks, rcb

    edit: added missing words for clarity 🙂

    • This reply was modified 4 years, 4 months ago by  rorycb.


    Yes, you can connect a rain sensor to your 1.1. Please check the OSPi user manual:
    page 10, RPi pin uses. According to the diagram, the firmware uses GPIO 14 as rain sensor. What you need to do in terms of connection is: VCC (3.3V) -> 30K (or 27K) resistor -> one wire of rain sensor, and the other wire of the rain sensor -> GND. This way, the pin is pulled high by default, and when rain sensor clicks it’s pulled to ground.

    The current version of OSPi also has a 4.7K resistor in series and a TVS in parallel to the rain sensor port, to protect it from transient voltages. These are optional, but can improve the reliability. For details, you can check the schematic:



    Thanks for the thorough details Ray – I knew I could connected (I did last summer customizing Dan’s script), it was the pin I didn’t know where to find in the source (and didn’t realize it was in the manual, should have looked there first.) The circuit information is very helpful, I put it straight in last year. I’ll get it wired up correctly this year.






    I would also like to see a feature that would allow a program to start and end at a time related to sunrise or sunset. Start time is already implemented and works great. I understand that the data structure uses ‘duration’ and not an ‘end time’ per se, but it would truly add great functionality to the system. It would be great if the end time could be specified not only in relation to sunrise/sunset, but also a particular time of the day.

    I forked Dan’s python program and wrote a plugin to achieve this functionality, but it is becoming a bear to update my fork and merge with the original. I appreciate your effort it making this a feature in the unified firmware!

    • This reply was modified 4 years, 4 months ago by  navy2x.
Viewing 15 posts - 1 through 15 (of 33 total)

You must be logged in to reply to this topic.

OpenSprinkler Forums OpenSprinkler Unified Firmware Announcing OpenSprinkler Unified Firmware 2.1.3 (for AVR/RPI/BBB/LINUX)