@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