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

[Ray]

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 https://github.com/OpenSprinkler/OpenSprinklerGen2.git
to clone a fresh copy of the repository.

2. Go to the folder (cd OpenSprinklerGen2), and run
sudo sh build.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 build.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 ospi.py 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 ospi.py 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!

[nystrom]

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.

[Ray]

The main purpose of removing ospi.py 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.

[dun4cheap]

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.

 

[Ray]

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?

[dun4cheap]

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.

[Ray]

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.

[dun4cheap]

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,

Ed

 

 

[abdoz]

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.

BR,

[Ray]

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

[rorycb]

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 🙂

[Ray]

Yes, you can connect a rain sensor to your 1.1. Please check the OSPi user manual:
http://rayshobby.net/docs/ospi14_manual.pdf
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:
https://raw.githubusercontent.com/rayshobby/opensprinkler/master/OpenSprinkler%20Pi/hardware/ospi_v14%2B_sch.png

[rorycb]

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.

 

[navy2x]

@dun4cheap

You might find this helpful: https://opensprinkler.com/forums/topic/new-plugin-and-fork-to-support-sunrise-and-sunset-program-timing/

[navy2x]

@ray

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!

[Samer]

This is already written and will be released in the next update, 2.1.4. The mobile app has added supported and will be released in 1.4.2 to change these settings. Expect this to be released soon with full details from Ray.

[navy2x]

Wow that’s fantastic! I commend you for being so prompt in responding to your community and adding requests. Thanks! Looking forward to the release.

[JohnC]

This is my first go at OpenSprinkler. I loaded the latest Raspbian image onto my Model B Raspeberry Pi. Then loaded this unified firmware 2.1.3 (actually it reports as being 2.1.4). all appears to work except;

1. How do I change the Station names? even the official 2.1.3 User Manual shows stations as ‘S01″ then on another page it shows actual meaning names like “Front Yard”

2. I keep getting “Network Error” displayed in red at bottom of web-page and on the mobile app after some period of time which replaces the “Idle” message. The unit is hardwired to my router and I can happily http into it and SSH into the Raspberry Pi and all looks good. What is the network error?

 

 

[Samer]

Hello,

The version number is wrong because some upcoming changes for 2.1.4 got accidently pushed to the master branch and since the instructions tell you to clone master branch, you ended up with the latest working copy of 2.1.4.

1) On the home page, each station is listed with a gear icon on the right hand side. As the manual explains, if you tap this gear icon it opens a popup with some settings for the station selected. Currently, the app won’t let you rename master stations but this will be changed in the next version but every other station can be named without issues. The work around for master station naming, is to remove the master station, rename the station, and set it back to master station.

2) The app is constantly polling the controller and if it cannot reach it, it will show a network error banner across the bottom. Is the app or web page device on a remote connection or local? The web-page has no timeout period, so it is quite odd so see a network error however the app has a 6 second timeout on attempts to poll the controller (and retries 3 times before considering the attempt failed) hence why you might see the error.

Thanks

[navy2x]

I have a similar problem on my OSPi (Model B) as @JohnC running the new unified hardware. I will get the “Network Error” message after a couple of hours of the pi being on. This happens on both the local and remote connections. I have correctly set up port forwarding. After it happened, I logged in the the pi via ssh and checked to see if the OpenSprinkler executable was running with:

gprep OpenSprinkler 

but it wasn’t running. As soon as I ran the program again with:

cd /usr/local/OpenSprinkler
./OpenSprinkler

the app connected and the “Network Error” message went away. It seems the app is shutting down on its own? Is there is a log file that I could find to give clues as the why this is happening?

[Samer]

This is actually something that has been happening with the demo we host: http://demo.opensprinkler.com. In order to keep the process running I had to wrap it in a small script:

#!/bin/bash
while ! ./OS-Demo/OpenSprinkler
do
  sleep 1
  echo "Restarting program..."
done

This isn’t ideal and I will talk to Ray to figure out why this is occurring.

[JohnC]

Samer, Thanks for your promptness. I should go see my optometrist I think.

FYI, I have been ‘bench testing’ and pre-configuring the OSPi while I await the deliver of my OpenSprinkler Controller hardware – so there is no controller connected. Perhaps this is why the software is misbehaving?

Also some of the options for the stations are missing – like ‘Relay contact closure’ – perhaps this again is because no controller hardware.

Also the system has been running Ok overnight with no ‘Network Error’ banner. Also I saw the issue previously on both local (web browser via local LAN), and remote (iPhone App via 3G Cellular to my local router/gateway configured with port forwarding and no port number translation).

Question, how long does it take for the remote App to re-sync with the OpenSprinkler? I make changes locally and find that the remote App doesn’t reflect these immediately – i’ve had to kill and restart the App on iPhone and then changes are shown.

 

[Ray]

@JohnC, the software doesn’t depend on the existence of OSPi hardware. So it shouldn’t make a difference whether you have OSPi plugged in or not.

Support for relay has been dropped because since a few months ago we’ve removed the built-in relay from OSPi circuit boards — it’s a rarely used feature so we’ve decided to remove it.

[navy2x]

@Samer

Just wanted to give you some debug info for trying to fix the ‘Network Error’ issue. I modified your script a bit to output the time when it has to restart the OpenSprinkler program. Also, for some reason unknown to me, I was unable to login to the web interface after a restart with your script, but I was able to if I restarted it with the following command:

sudo /etc/init.d/OpenSprinkler.sh start

So I created the following script and made a cronjob to run it once a minute:

#!/bin/bash
while ! ps ax | grep -v grep | grep OpenSprinkler > /dev/null
do
  echo "OpenSprinkler not running...restarting...     $(date)"
  /etc/init.d/OpenSprinkler.sh start
sleep 1
done

Here is my log file:

OpenSprinkler not running...restarting...     Thu Apr 23 08:44:01 EDT 2015
OpenSprinkler not running...restarting...     Thu Apr 23 11:31:01 EDT 2015
OpenSprinkler not running...restarting...     Thu Apr 23 18:53:02 EDT 2015
OpenSprinkler not running...restarting...     Thu Apr 23 19:34:02 EDT 2015
OpenSprinkler not running...restarting...     Fri Apr 24 02:04:01 EDT 2015
OpenSprinkler not running...restarting...     Fri Apr 24 08:57:01 EDT 2015
OpenSprinkler not running...restarting...     Fri Apr 24 16:12:02 EDT 2015

Please keep in mind I had to manually restart the program at the ‘Thu Apr 23 19:34:02 EDT 2015’ timepoint.

Hope this helps.

[Samer]

Ray got this bug fixed and it will be released in 2.1.4.

Thanks for the information!

[Author]

Posts