Can anyone suggest a way to track the cumulative time a condition exists over a period of time?
My scenario:
Run the pool pump when:
Solar output > 2000 watts (tells me when the sun is out and shining on my solar pool heater)
Pool temp < 90 (wife likes a warm pool)
Run the chlorinator when:
Pool pump is on (Chlorinator can only initiate during pump startup so it has to be enabled when the pump starts)
Disable the chlorinator after a cumulative run time of 2 hours but leave the pump running (soak up that solar heat)
My problem is that I only want the chlorinator to run for a cumulative amount of 2 hours per day (24 hour) and the pump could turn off if it rains or gets really cloudy. This means that the chlorinator relay could be enabled but the pump isn’t running so no chlorine is being generated.
The Runtime variable on the Reactor group with a condition of pump=true and chlorinegenerator=true (when both are true then we are making chlorine) seemed to be what I was looking for but it doesn’t seem to reliably update how long a condition exists.
If I set the ‘Condition is sustained for’ bit for 7200 seconds will this track the cumulative time or only for that period of time if the condition flips from true to false and back to true?
Thanks!
JV
ReactorSensors have two state variables, TripCount and Runtime, that accumulate trip count and time in tripped state (in seconds) respectively. They can be reset by using the ResetRuntime action. The base time since the last reset is stored in the RuntimeSince state variable on the ReactorSensor.
These values are not stored per group, so the condition you want to accumulate needs to live by itself in a ReactorSensor of its own, but you can refer to that condition’s state in other ReactorSensors using the Group State condition (for true/false tests) and Device State condition (for testing the values of the measurements).
I don’t think anyone has ever used this feature. It’s been in Reactor since 1.x, but is probably untested and unloved since due to lack of attention/interest. If there’s been some kind of injection that is now causing it to malfunction, I’ll fix it, you can be sure. I’ll do some testing today. But that for sure is the way to go.
This will count only that period and reset every time. You can use this approach, but if your chlorinator/pump may cycle on and off during the measurement period (as you said: if it rains or gets really coudy), this would require an unbroken run of 7200 seconds, where using Runtime above would reflect the total accumulated runtime even if that happens in short bursts. You just need to do the ResetRuntime action at appropriate times (midnight in your case?) to re-zero the counters.
Depends on your use case, really.
Thanks for the validation, that’s exactly as I have it set up. I may just be inpatient because I expected to see the runtime counter increment in real time for each second the condition is true but I don’t. That’s not to say it isn’t incrementing but I just can’t see it via a page refresh (hard or soft) or via my watching sensor.
If this doesn’t work reliably then I can always fail back to just setting static durations.
Thanks for the PLEG alternative!
JV
I’ve been playing with it since my last reply/edit and it accumulates fine, right on time.
I am very resistant to having Reactor processing when it doesn’t need to, and I spend a good bit of time making sure that polling isn’t a part of its implementation to the greatest degree possible. The Runtime accumulator, therefore, only updates the state variable (Runtime) value when the ReactorSensor has reason to re-evaluate conditions. In the absence of any stimulus that causes re-evaluation of the sensor, that means the runtime will only update when the sensor untrips.
That works against your use case, but there’s a way around it: all you need to do is force a re-evaluation of the sensor periodically. If you add an Interval condition to your RS, it will cause the RS to re-evaluate on the interval, and that will update the runtime during that process. Since the interval drives a logic state, you just need to keep the interval condition’s logic transitions out of the way of your other condition logic, which you can do by putting it into its own subgroup and making the group operator NUL.
