[dkkim]

@Ray thanks for the response to both of us.
It seems like (to clarify for me, and for anyone else wondering about a “monitoring only” application), one could create programs that run at the desired monitoring interval. E.g. every 4 hrs, every day, etc, that don’t connect to any valves. That would create a “logging window” that would tie to the observed overall flow rate. I.e. for keeping track off bills, etc.

And if one knew the existing the program on another controller, one could match the windows to see what those zones were actually running, too.

Thanks,
David

[dkkim]

Hi Evan,

Actually I am wondering the same thing. I just wired in a RainBird in place of my OSPi as we are renting the place and it will be more familiar to contractors. I did a dual-box installation where I am interested in leaving a RasPi in place for flow monitoring and wondering if I can just use OSPi vs. a custom solution.

Curious if anyone’s done any mods or observation in this area?

FWIW from my prior experience when the zones are running you can see deviations from prior usage.

Thanks,
David

[dkkim]

Thank you @DaveC for the quick reply!

I thought about a hard mechanical switchover. I found a number of items searching for “phoenix connector” and “phoenix connector switchable”. Did you use a multi-bank type connector like this and run jumpers manually? https://www.phoenixcontact.com/en-us/products/terminal-blocks

Some further searching yesterday found this product also:
https://easyirrigationrepair.com/isolator
with some videos showing how to place it to isolate either a master valve or the common lead of a set of solenoids.
It *seems* as if I might be able to do both (with two units) in this application, as the isolator would likely interrupt flow back through the 2nd controller, but I’ll have to sit down with some paper and circuit diagrams and think a bit further first.

Ray’s answer in that other thread makes sense, from general principles. Still would give me the willies… if there were a programming error, I’d guess you’d get either 0 or 48VAC depending on whether the two sources were in or out of phase (assuming two separate transformers on the same AC main).

David

[dkkim]

@Ray thanks for the reply. If the intent of that routine is for slowly-varying parameters, and the UI implicitly reflects this, that makes sense.

I am a bit puzzled in that I chose a dry-contact reed switch for the flow sensor, as recommended, and I think these generally have lower click rates…? But I realize some people are also using Hall effect sensors and other sensors that might have different intrinsic scales, some much faster.
In your opinion, does it make more sense to log the flcrt (os.flowcount_rt, I think) every interval, or perhaps log the total counts, or perhaps even a rate with a wider window? I would image a different MQTT topic at some reasonable granularity… or maybe even have it be a switchable parameter or conditional compilation setting (if you think this is a low-frequency use case).

I’m essentially trying to create a raw-ish data stream to do analytics on usage and also detect small mainline and pre-valve fitting leaks. Logging flow only for scheduled runs hides these flows amidst the much larger flows. Also a leak can be subtle as the absolute amounts vary with rain adjustments. Having access to a background “stream” (albeit at a reasonable rate) can facilitate these analyses.

@Samer thank you! I will look further into the UI, to understand, though might be moot given what Ray says about the implicit UI design.

Traveling for a week, so will read/experiment thereafter. Thanks again for the quick help!

David

[dkkim]

A follow-up.
The simple change I made in OpenSprinkler::detect_binarysensor_status above (https://opensprinkler.com/forums/topic/announcing-opensprinkler-unified-firmware-2-1-94/#post-67771)
solved the lack of MQTT event sending but unfortunately results in multiple spurious-appearing entries in the visual Log (see tick marks under “Rain Sensor” below).
So it looks like something in the UI layer (which appears abstracted into .js and .css on ui.opensprinkler.com rather than in Github) treats sensor1 and sensor2 events as representing Rain.
It’s hard to tell why this happens, but it doesn’t seem correct as this routine is trigger by flow, soil, and rain sensors.

Any thoughts?

Thanks,
David

Attachments:

1. 

   Screen-Shot-2020-08-07-at-7.16.19-PM.png
   

[dkkim]

Thanks Ray, I was wondering if the thinking were something like that.
Since I get 1 cycle/gallon, it’s not too much IoT network overhead, esp. if I’m on a local network. And it also helps give me real-time alerts if a mainline hose pops loose, etc.
However, I can imagine some much higher-rate sensor being problematic.

Does a good method suggest itself to you to elegantly support both cases? I can maintain a side-branch for my own purposes, but I would imaginee it could be useful to others, and it’s more convenient to not keep re-basing my own branch on releases.

Would it make sense to add an additional MQTT channel something like /opensprinkler/sensor/rawflow or flow-ticks?
And/or maybe have the message send conditional on a configuration setting that defaults to off?
That way we could add this reporting option to the regular firmware without overwhelming folks with high-rate sensors.

Thanks for your quick and expert response, and the cool OpenSprinkler effort!

David

[dkkim]

Hello All,

Thanks to Ray (see: https://opensprinkler.com/forums/topic/easy-debug-setup/#post-67770) I was able to get some more debugging info. Also looked at code further.

I figured out that raw events for sensor1 (used for flow in the OSPi 1.4) are not actually logged via MQTT since the logic does not check for a SENSOR_TYPE_FLOW, only for RAIN or SOIL types. If I make the following patch, then it works:

 /** Read rain sensor status */
 void OpenSprinkler::detect_binarysensor_status(ulong curr_time) {
        // sensor_type: 0 if normally closed, 1 if normally open
-       if(iopts[IOPT_SENSOR1_TYPE]==SENSOR_TYPE_RAIN || iopts[IOPT_SENSOR1_TYPE]==SENSOR_TYPE_SOIL) {
+       if(iopts[IOPT_SENSOR1_TYPE]==SENSOR_TYPE_RAIN ||
+               iopts[IOPT_SENSOR1_TYPE]==SENSOR_TYPE_SOIL ||
+               iopts[IOPT_SENSOR1_TYPE]==SENSOR_TYPE_FLOW) {
                pinModeExt(PIN_SENSOR1, INPUT_PULLUP); // this seems necessary for OS 3.2
                byte val = digitalReadExt(PIN_SENSOR1);

Note that the reason I want to do this is to read raw flow sensor events for fine-grained water use tracking and leak detection in my hybrid surface/buried drip system. I have a 1 gallon/cycle reed switch flow meter, so events aren’t too frequent. MQTT seems a great way to glue all this together.

Question for Ray and the other devs:
Was the intention to omit flow sensor raw events from MQTT? Or is that an oversight? I.e. Is there any reason not to enable these as I did?
If you are amenable, I will prepare a pull request…

Thanks,
David

[dkkim]

Thanks for the quick reply, Ray!

That was helpful in two ways:
1. I can see the debug prints

2. Was also able to launch that executable via “sudo gdbserver localhost:8899 ./OpenSprinkler” and attach via a network GDB connection.
Note for anyone else doing this you have to add a “-g” flag to the g++ command in ./build.sh (or run it manually) to generate the symbol stubs.
Obviously a maneuver for debugging.

I did figure out why flow-sensor related sensor1 changes weren’t getting logged to MQTT. I’ll follow up to my comment in the 2.1.9(4) release thread.

Thanks!
David

[dkkim]

Hello All,

Has anyone seen sensor events actually logged individually to MQTT?
ie. opensprinkler/sensor1
and opensprinkler/sensor2

I’ve got 2.1.9(4) running on an OSPi, commit SHA f0b800, and I’m seeing other events but not these.

Looking at the source, it’s a bit hard for me to follow with all the enums and such, but it looks plausible and I don’t see anything commented out.

Thanks,
David

[dkkim]

@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,
David

[dkkim]

Hello,

I am trying to do something similar as @JohnGalt and would very much like @Ray’s opinion on where to start debugging:

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.

Thanks!
David

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.

[dkkim]

Thank you @Ray for the thorough answer! (and sorry for the delayed thanks)
That makes perfect sense… I tend to be a belt-and-suspenders guy, so the extra 4.7k resistor makes sense.
BTW I did actually switch to a plan where the flow sensor goes into a stock OSPi and the ESP32 acts as an extender only. This way I get a nice solid platform with the OSPi and also a faster platform to run any monitoring scripts, etc.
It’s a nice product.

Cheers,
David

[dkkim]

Thanks! This was really helpful. Ordered one of these…

[Author]

Posts