Tagged: flow rate bug
June 18, 2019 at 8:46 am #61124
I have been diving into the flow rate to try to create some better diagnostics for my irrigation system. For example clogged head, cut line, etc.
I can pull the log data using the API. The api document says “if flow sensor is enabled, there will be an additional field recording the flow rate during the station.”
Can I assume correctly that this is the average flow rate and not the starting flow rate, ending flow rate, etc.? How is this value calculated? Do you take the total amount of pulses during the duration that the station was running and do the math? Or does it take the average flow rate by averaging the values that are updated every 30 seconds?June 27, 2019 at 10:03 am #61389
Yes, that’s the average flow rate during the station run, it’s calculated by recording the pulse count at the beginning of the station run, and at the end, then the difference between them multiplied by the flow rate. So if there are multiple zones running at the same time, this will only show the total flow rate, not individual zone (for the obvious reason that it doesn’t know the distribution of the flow rate among simultaneous zones).
There is also the real-time flow rate which you can poll. The real-time flow rate uses a (by default) 30-seconds window to calculate flow rate. This is different from how the station run log is calculated, as described above.June 30, 2019 at 5:51 pm #61448
I started simply intermittently querying OpenSprinkler (via the RESTful interface with a python logger), then later simply by watching a vanilla installation on OSPi. I am seeing some occasional completely unphysical flow rates (e.g. 500gal/min), both from shorter test runs and longer normal runs, interspersed among normal results. Earlier today I watched a 50gal/min reading where I physically checked the dial and saw closer to 1gal/min. We are using an Assured Automation reed switch device with a 1 gal/pulse conversion.
Any hints on where to start troubleshooting?
I’ve tried empirically increasing the debounce window to 100ms (the pulse rate is low with drip irrigation-type flows so I wonder if the reed switch is stuttering?) and also increasing the sampling window to 120 sec.
ETA: I have seen spurious flow rates with *both* instantaneous (via the Android app, web interface, and REST calls) and also via the logged values.July 9, 2019 at 2:49 pm #61565
What kind of flow sensor do you have? Generally speaking only dry contact switch sensors are supported. Some powered sensors can also be used but it varies on a case to case basis.August 11, 2019 at 3:26 pm #62095
@Ray sorry to miss your earlier reply! I’ll have to check my notification settings.
I’m using the Assured Automation WM-PC-075 with the factory dry contact reed switch, based on a helpful rec in a previous forum post:
Info page: https://assuredautomation.com/WM-PC/index.php
Comparative listing: https://assuredautomation.com/WM-PC/index.php?p=buy
It works very well in terms of manually reading it and confirming function by checking the switch with an ohmmeter or running a simple Python counting script on the RPi to watch the GPIO 14 pinout. I *do* notice that sampling quickly overcounts, which I attribute to a need to debounce.
Another note: I incorrectly stated I was able to recompile the OpenSprinkler firmware to try a longer debounce window. That was incorrect, I had actually just re-installed the original FW. Sorry for the incorrect info. In fact, I am trying to get it to compile again today… 🙂
Thanks for any tips,
- You must be logged in to reply to this topic.