Announcing OpenSprinkler Unified Firmware 2.1.6

[Ray]

Hi All,

OpenSprinkler Unified Firmware 2.1.6 has just been released. This firmware features an improved scheduling algorithm, support for flow sensor, remote stations, improved RF station support, and bug fixes. See the list below for details. Thanks!

Major Changes:

• Improved scheduling algorithm. This version uses a queue structure, which allows the same station to appear more than once in the queue. This solves the previous issue that the same station cannot be scheduled if it’s already running or waiting to run. Programs/stations can now overlap and queue up arbitrarily, as long as the queue has space to fit them.
• Added support to allow program’s repeating start times to go over to the next day. Previously, repeating start times that go over to the next day were ignored.
• Added flow sensor support. At the moment, only dry contact flow sensors (two wires) are supported; those with analog output (three or more wires) are NOT supported, or require modifications to get supported.
  [Details: to use a flow sensor, wire it up to the rain sensor port, and in Edit Options -> Weather and Sensors, select the sensor type to ‘Flow’. Then specify the flow pulse rate (i.e. volume per click, check your flow sensor’s datasheet). If you don’t know, just leave it as 1. Once flow sensor is enabled, the UI/app will display real-time flow rate, and the flow count will be logged at the end of every program run. The LCD will display a FL icon to indicate flow sensor is activated.]
• Added support for ‘remote stations’. A remote station is a station on a different OpenSprinkler controller.
  [Details: this feature allows a master controller to send commands to one or more remote controllers to turn on their valves. Each remote station is specified by the IP, port number, and station index on the remote controller. The master controller and remote controllers must have the same password. Remote controller should be set in ‘remote extension’ mode (the UI/app will automatically prompt you to enable this mode when adding a remote station).]
• Fine tuned RF station signal timing, and improved its support on OSPi/OSBo (by optimizing the digital pin operations).
• Remote and RF stations are now part of Special Station Data attributes, which are stored onto the microSD card. For OpenSprinkler 2.x, to use remote and RF stations you must have a microSD card installed. OpenSprinkler 2.3 already has a pre-installed microSD card. The firmware also periodically re-send remote and RF signals to make sure they are in sync with the master controller.
• Support for longer names, more stations and programs on OpenSprinkler 2.3, OSPi and OSBo.
  • Maximum number of stations: 56 (previously 48)
  • Maximum station name length: 24 (previously 16)
  • Maximum program name length: 20 (previously 12)
  • Maximum number of programs: 28 (previously 14)
  • For OpenSprinkler 2.0/2.1/2.2, these numbers remain the same as previously.
• Added support to change weather script URL in /su page. This is useful for hosting or customizing weather script yourself.
• Added HTTP GET command /ja, which returns the combined JSON data of /jc, /jn, /jp, /js, /jo. This allows the UI/app to get all JSON data with one request instead of 5 separate requests.
• Fixed negative duration time in some log records.
• Added support for DC controllers that have current sensors. If a DC controller has current sensor, the UI/app will display real-time current draw of the sprinkler solenoids.

OSPi/OSBo/Linux:

• Added support for auto-update, which allows updating the firmware through the UI/app.
• Added support to store all data files in the executable program’s path.

---

Special Notes for OpenSprinkler 2.1

For OpenSprinkler 2.1, this firmware can no longer be uploaded through the USB port, due to the size of the USBasp bootloader. To use this firmware on OpenSprinkler 2.1, you will have to use an external AVR ISP programmer (e.g. USBasp, USBtiny etc.), and upload the firmware through the on-board ISP pin headers. Because this requires advanced technical skills, we have decided to exclude the precompiled firmware for OS 2.1 from the updater program. You can compile the firmware from the source code, and if you need help to upgrade your OpenSprinkler 2.1, please contact us directly.

I understand that OpenSprinkler 2.1 has caused much frustrations due to its bootloader design. It was never my intention to leave it that way, had I known its limitations when it was designed. It’s a learning process for myself. In any case, if you are interested in upgrading your OpenSprinkler 2.1 to the latest hardware version 2.3, we are happy to provide discounted price for upgrading. Feel free to contact us about it.

---

Upgrade OS 2.0/2.2/2.3 to Firmware 2.1.6:

Please follow the OS Firmware Upgrade Instructions.

---

Upgrade OSPi/OSBo to Firmware 2.1.6:

Please follow the OSPi/OSBo Firmware Upgrade Instructions.

---

[tom]

Thanks, Ray and Samer (and whoever else may have contributed). This is an impressive bit of engineering 🙂

Is the flow rate available through a API? This would be great to have.

What happens to the flow sensor when a valve is not active? Since I want to see other activities (e.g. a pool autofill valve, leak detection, etc.) I would like the information to be constantly available. Perhaps you could accumulate any flows that happen when no known zone is active to a zone named “Unknown”, that would also be logged.

By the way, I highly recommend going with a gauge with a .1 gal resolution. Even at 30 GPM, that is only 5 ticks per second for the controller to handle, so it’s not overloading the controller, but gives much better real time flow information.

[Ray]

@tom: we are working on updating the firmware API document to get it up-to-date with firmware 2.1.6. As a quick note, when flow sensor is enabled,

• The /jc (controller variables) page outputs variables flcrt and flwrt, referring to real-time flow count and window (https://github.com/OpenSprinkler/OpenSprinkler-Firmware/blob/master/server.cpp#L832). It basically means ‘flcrt’ number of clicks are detected during the past ‘flwrt’ seconds.
• The /jo (options) page outputs two variables fpr0 and fpr1. To use them: fpr = ((fpr1*256)+fpr0)/100.0 is the actual flow pulse rate (i.e. volume per click). This can be set through the app/UI. So if you multiply flow count with fpr, that gives you the actual volume.
• At the end of each program run, the total flow count during the program run will be recorded in the log file. The log record’s format is: [flow_count, “fl”, duration, end_time], meaning flow_count number of clicks are received during the past duration seconds, and the time stamp of this record is end_time.

The firmware uses interrupts to handle flow sensor reading, so it’s relatively efficient. I have a test flow sensor that’s 0.1 gal per click (I think this is the 0.1 gal resolution you are referring to). I did check a number of other types of flow sensors, and found various pulse ratings, such as 0.25, 0.5, 1.0 etc. That’s why the fpr variable described above has a precision of 0.01, to accommodate a variety of different flow sensors.

[Author]

Posts