Announcing OpenSprinkler Unified Firmware 2.2.1(1)

[Ray]

Hi All, we have just released OpenSprinkler Unified Firmware 2.2.1(1). This is a minor revision from the previous 2.2.1(0). The release notes are on github:
https://github.com/OpenSprinkler/OpenSprinkler-Firmware/releases/tag/221(1)

Associated firmware user manual, API document, and support articles that explain the new features are all available at our support website:
https://support.opensprinkler.com

• If your controller is already on firmware 2.2.1(0), updating to this firmware will preserve all settings and programs. No re-configuration is needed.
• If your controller has an older firmware, like 2.1.9 or 2.2.0, updating to this firmware will trigger a factory reset. So make sure to export a copy of your current configurations before proceeding, to restore the settings and programs after the firmware update.

If you have any comments / suggestions / bug reports, feel free to post them here, or submit a support ticket at the support website above. Thanks!

[jillelaine01]

I did submit a support ticket for this. On Hardware v3.0 – AC, before the FW update from 2.2.0(3) to 2.2.1(1), I exported the current config and saved it. I then installed the FW update that I had downloaded from here: https://raysfiles.com/os_compiled_firmware/v3.x/ I installed over the air, the OS rebooted, and went back to factory settings as expected. I logged into the OS and reset the OS to my local wifi with no issues. I am able to log into the OS, but, when I try to restore my original config, it says “Unable to import configuration”. I have also tried a previous config backup with the same result. I will wait to update my 2nd OS controller until this issue is resolved.

Attachments:

1. 

   Screenshot_20250423_124652.png
   

[jillelaine01]

UPDATE: Thanks very much to Ray for working with me on this issue. Today I updated the firmware on my 2nd controller. The firmware loaded without issue. I had no problems connecting to the controller’s default AP mode & resetting the controller to my home wireless. All of that worked flawlessly.

In the last week, I had made several full backups of this controller in preparation for the firmware update reset. NONE of these backups could be uploaded to the controller: all recent backups threw the error – “Unable to import configuration”. Weirdly, I WAS able to import a backup that was over a year old…same as with the previous controller where I could restore an older backup but NOT the current backup.

What I tried: reinstalled the firmware (made no difference), rebooted the controller (made no difference), waited 15 minutes in case the controller was ‘busy’ (made no difference). Ray had suggested that perhaps the problem was the browser: I am on a desktop, Kubuntu 24.04.2 LTS and was using Mozilla Firefox v138.0 with Adblock and Privacy Badger extensions installed.

So I tried opening my controller on Google Chrome v136.0.7103.59. To my amazement, the most recent backup uploaded to the controller perfectly fine. SO, RAY WAS RIGHT: IT’S THE BROWSER, specifically Firefox apparently. I hope this information is helpful. Original helpdesk ticket here: https://openthings.freshdesk.com/support/tickets/15424

[Underpaid1349]

I noticed that in my last few runs, the flow rate alert that was added in the most recent update will trigger an alert for one station per program run. I think that might be a bug?

I’ve been trying to dial in my flow rate alerts for all of my stations, so I have them set slightly under what I think they should be at. But when my program ends, it will only send an alert for _one_ of the stations at a time (always favoring the stations that have run last).

It also doesn’t send the flow rate alert until the entire program has finished. So if station 1 finishes and a leak was detected, I won’t find out until the last station in my program completes. (which should be fine since the first station isn’t running anymore, but I was expecting the alert to be sent as soon as the first station finished).

Also, it’s difficult to know what flow rate was used in the calculation for each station since I can’t seem to find any log with that information on the controller. I can see the flow rate changes over time if I use the API, but there doesn’t seem to be a logged average flow rate recorded on-board rate. I’ve had to use the API and calculate it myself.

EDIT: If I look at my /jl endpoint, it isn’t recording the flow (5th element) for many of the other zones and instead logging most of them as 0. It appears to really only be saving it for 1 stations at a time (sometimes 2) for each of the &hist=# results.

[Ray]

The flow alert should send alert as soon as a zone finishes running and the flow rate is above the set flow threshold. There are several things that may contribute to not receiving the flow alert:
1. The flow threshold annotation in the zone name MUST be 5 characters long. Even if it’s something like 0, it needs to be written as ‘0.000’ otherwise the firmware may not detect it as a number.
2. The zone must run for at least 2 and half minutes or more, otherwise the flow rate is unreliable and it will not send flow alert at all.
3. The flow pulse rate in Edit Options needs to be set appropriately. For example, if it happens to be very very small, then the calculated flow rate will be too small to reach the threshold.
4. Make sure your flow meter can generate sufficient number of pulses. We’ve seen some customers use flow meters that generate 1 pulse per several minutes, if the zone runs less than that amount of time, it won’t even click once.

As in the original pull request, you can easily test if it’s working by simply setting a flow threshold to 0.000 (i.e. for the zones that you want to test, edit their zone names to have 0.000 at the end). This way, as long as the flow meter clicks at least once during the run time (at least 2.5 minutes long), it should send an alert.

[Underpaid1349]

Thanks for the reply.

1. I did double check. I am using 5 characters for the threshold in each zone as mentioned in the docs.

2. That’s good to know. Each of my zones runs anywhere from 24 – 60 minutes. So this shouldn’t be an issue.

3. This should be set up correctly. I have it as 3.78 L/Pulse (or 1 gallon per pulse)

4. My flow meter should definitely be generating sufficient number of pulses. When I hit the OpenSprinkler API directly to log the flow rate, I can see that OpenSprinkler is recording anywhere between 22 – 30 L/Min at a given time. So I know the controller is seeing this information.

I currently having the alert event sent via both email and MQTT as I wanted to make sure one alerting channel wasn’t the problem over the other. But that doesn’t seem to be the case.

Good idea about setting each zone to 0.000. I’ll try that for my next run on Thursday and report back. I wonder if there is a conversion problem internally with the code. I noticed when I hit the /jl API endpoint it _seems_ to return the flow rate in gallons (the preferred unit set on the controller). But when I get the alert (and seemingly set the flow rate alert threshold), it _looks_ like it’s using liters.

Either way, I should be able to find out for sure during my next run on Thursday.

Thanks for the helpful information.

[Ray]

The conversion between L and Gallon can be confusing and I suspect the UI may have a bug in the conversion, especially if the Use Metric checkbox is toggled. So I strongly suggest you ignore the unit, don’t change it. If it shows Liter by default, just keep it as liter, don’t change to gallon, or just treat L as Gallon. If your flow pulse rate is 1 Gallon per pulse, just put the number 1 there, don’t change the unit, even if the unit displayed is L/pulse. In the end, only the number matters, because the firmware doesn’t record the unit. The unit is what the UI attached to the display. If you see X Liter per minute, just treat it as X gallon per minute. Or think of is as X ‘units’ per minute.

[bena]

“EDIT: If I look at my /jl endpoint, it isn’t recording the flow (5th element) for many of the other zones and instead logging most of them as 0. It appears to really only be saving it for 1 stations at a time (sometimes 2) for each of the &hist=# results.”

If you are seeings 0’s for Flow Rates using the /jl query, then the Flow Alerts are not going to work for those stations.

Is it always the same stations missing flow rates or is it random?

What other notifications events do you have enabled if any?

Based on your screenshot it appears your stations are configured to run sequentially, correct?

And to confirm, the flow rate shown in the email alert is the raw pulses per minute multiplied by the Flow Pulse Rate Factor. So the email flow rate number has been adjusted for units of measure and you should base your setpoint on that flow rate number shown. So after setting all setpoints to 0.000, I always rely on the emails to show the actual values that are being compared for the alerts.

And as Ray mentioned, adjusting the Flow Rate Factor to 1 and leaving units as L/pulse and just assuming gallons may help simplify things. Of course, you’ll then need to convert your setpoint values to gallons\min as well.

[Underpaid1349]

> Is it always the same stations missing flow rates or is it random?

I’ve only had 3 data points so far, but if more than one station violates its flow rate, only the last station to violate it will send me an alert (but this might be a bug that I theorize further below)

When I set all zones to 0.000, I get this results from the jl endpoint for today’s run. This shows only the last zone had a recorded flow rate (when in reality, all of them should have had something).

`json
[
[
2,
0,
3600,
1747894501,
0.00
],
[
2,
1,
1440,
1747895936,
0.00
],
[
2,
2,
1440,
1747897371,
0.00
],
[
2,
3,
1440,
1747898806,
0.00
],
[
2,
5,
3600,
1747902401,
0.00
],
[
2,
6,
720,
1747903116,
0.00
],
[
2,
7,
1440,
1747904551,
7.66
]
]
`

I’ll double check this on my next run, but I seem to recall that the last station to run will always have its flow rate recorded (by chance). However (this next the part is what I need to continue testing), I seem to remember that if my last station (call it Station Z) did _not_ violate the flow rate, then the station that came _before_ it (Station Y) would properly record _its_ flow rate. But only if station Z _did not_ violate the flow rate.

I will update my Station Z flow rate and post back my results next Monday when it runs again to confirm if this theory is correct.

I can see from the API that the flow rate is being properly recorded for all stations during the entire run. And because I used a flow rate alert threshold of 0.000 for each station, I _think_ we can rule out any issue with the gallons/liters/pulse rate factor?

> What other notifications events do you have enabled if any?

The only notification events I have enabled are the flow rate alerts. I have them set up to send over MQTT and emails.

> Based on your screenshot it appears your stations are configured to run sequentially, correct?

That is correct. 6 out of the 7 stations are configured to run in 1 program, while the other station runs on a different program. (The programs never overlap and there are few hours between when they run). All set sequentially.

> And to confirm, the flow rate shown in the email alert is the raw pulses per minute multiplied by the Flow Pulse Rate Factor. So the email flow rate number has been adjusted for units of measure and you should base your setpoint on that flow rate number shown. So after setting all setpoints to 0.000, I always rely on the emails to show the actual values that are being compared for the alerts.

Thank you for that clarification. My latest run (this morning) had all of the setpoints set to 0.000 for each zone.

[Ray]

I will double check in the code, but I believe the log only records flow data on a per-program level, it does NOT log on a per zone level. That’s probably what you were observing as only the last zone records flow data. It’s not recorded for the zone, it’s recorded for the program run.

The flow alert feature is different: the alert is checked and calculated after each zone finishes running.

[bena]

Do the flow rates get stored properly if you run the 2nd or 3rd station manually for 3 minutes?

If it only fails to store a flow rate when stations run sequentially in a program, I would try creating a program with 2 stations that run for 3 min each. Then run it with the setpoint on the stations at 0.000, 99.00 and with no alert setpoint at all.

The flow alert process is separate from the logging, so it should always store the flow rate for all of the tests above.

If it still happens in the program, you can try using the delay between stations feature to add a 1 minute delay. This should not make a difference, but its worth a try.
Edit Options -> Station Handling -> Station Delay

How far back does your data go before you enabled flow alerts? Can you see if flow rates were stored reliably in the past or has it always done this even before Flow Alerts were enabled?

Finally what hardware are you using? OpenSprinkler or a Raspberry Pi running OS?

[Underpaid1349]

> Do the flow rates get stored properly if you run the 2nd or 3rd station manually for 3 minutes?

When I run station 2 in isolation for 3 minutes, it stores the flow rate properly:

`
[
99,
1,
180,
1747913322,
7.74
]
`

Here is the program with station 2 and 3 (sequentially) running for 3 minutes each. Only the last zone shows the log.

`
[
254,
1,
180,
1747913525,
0.00
],
[
254,
2,
180,
1747913700,
8.70
]
`

> If it still happens in the program, you can try using the delay between stations feature to add a 1 minute delay. This should not make a difference, but its worth a try.

I changed my station delay from -5s -> 60s

That actually allowed it to work! I received alerts for both zones. I’m wondering if having my negative delay is causing the station to think it’s one continuous run and then not breaking them up properly? Unfortunately, I can’t really keep my programs like that because I need the zones to overlap slightly to prevent a water hammer. So this might be a bug or I’m not using the feature as intended?

`
[
254,
1,
180,
1747914022,
7.80
],
[
254,
2,
180,
1747914262,
8.64
]
`

> How far back does your data go before you enabled flow alerts? Can you see if flow rates were stored reliably in the past or has it always done this even before Flow Alerts were enabled?

Good question. I found a run on the controller’s history from back in September 29, 2024. That was before I had done any of the flow-rate alerting. I was running a shorter overseeding program, but it should still be long enough to record something. It looks like every zone again only recorded a 0.00 flow rate except the last one.

`
[
3,
0,
900,
1727626501,
0.00
],
[
3,
1,
300,
1727626796,
0.00
],
[
3,
2,
300,
1727627091,
0.00
],
[
3,
3,
300,
1727627386,
0.00
],
[
3,
5,
720,
1727628101,
0.00
],
[
3,
6,
300,
1727628396,
0.00
],
[
3,
7,
300,
1727628691,
7.82
],
`

> Finally what hardware are you using? OpenSprinkler or a Raspberry Pi running OS?

OpenSprinkler controller
Firmware: 2.2.1 (1)
Hardware Version: 3.3 – AC
(using the Ethernet adapter as well)

tl;dr the negative delay between stations was causing the flow rate to not be recorded properly for each zone.

[bena]

Ok, I call it solved!

I think the -5 sec delay is the cause. I can look through the code and find exactly why that prevents it from logging the flow rate correctly, but I’m sure its an edge case that wasn’t expected in the flow rate logging logic.

OpenSprinkler uses a built in 1 second delay between stations, can you try shortening your delay to -1?
See if it logs the flow rate correctly and also see if that is enough to prevent your water hammer.

[bena]

And finally, a github pull request was just merged with the OpenSprinkler Web App to display station level flow rate in the UI. Not sure when it will be pushed to production, but there is a dev link that can be used for the next few days if your OpenSprinkler is connected to the OpenThings Cloud (OTC).

Github:
https://github.com/OpenSprinkler/OpenSprinkler-App/pull/233

Attachments:

1. 

   Untitled-3.jpg
   

[bena]

I just tested the -1 second delay and it also causes a 0 flow rate to be recorded. Actually, when saved, it changes it to -5. That must be the closest to 0 it can go.

So a negative number is technically stations running in parallel, so during that 5 or even 1 second, it doesn’t know how do divide up the flow across both stations.

[bena]

Also, to help clarify, there are 3 different types of flow data when calling the API.

The first one is the real-time count of pulses in the last 30 seconds.

(Note there is no flow data in the demo system, so these urls are just examples and will not show any flow data)
http://demo.opensprinkler.com/jc?pw=a6d82bced638de3def1e9bbb4983225c
Look for flcrt

The second data type counts the total pulses at the end of an entire program or after a single manual station run which is a virtual program:
https://demo.opensprinkler.com/jl?pw=a6d82bced638de3def1e9bbb4983225c&hist=1&type=fl
[counts, “fl”, dur, end]
[0,”fl”,181,1747915006]

Flow Alerts do not use this data program level data.

The third type is stored at the end of each station run regardless if it is run manually or in a program. It is the flow rate that is calculated by the total pulses divided by total minutes for the station.
https://demo.opensprinkler.com/jl?pw=a6d82bced638de3def1e9bbb4983225c&hist=1
[pid, sid, dur, end, flow rate in pulses]
[99,0,180,1747915006, 0.00]

Flow Alerts use this station level flow rate only after the OpenSprinkler is called to log it. So unless there is an issue with writing a value to the log, both the log and the flow alerts should be using the same value.

[Underpaid1349]

Thanks so much for helping me troubleshoot and figure out the root cause for this. I also appreciate the additional API information.

I’m going to try to leave the station delay at 0 and see if I can get away with it for now.

[Author]

Posts