Monitoring for excessive cycling on power sensors (or other devices)

Hi - I'm trying to monitor a device for excessive cycling. Easiest example is a sump pump, but there are many other applications for this. My sump pump is considered running when it's power level exceeds 200W. It normally only runs for 1-2 minutes at a time, and during normal rains it only cycles 3-4x per hour. I'd like to, for example, send notification if it cycles more than 5 times per hour.

First thing is to detect a cycle. If I set trigger as power > 200W, I would then need to wait for power to go <10W to count as a cycle? But what if it runs continuously? A condition I am already monitoring for in another basic rule, but I would need to accommodate here Would be nice to consolidate that functionality here if able to.

Any suggestions on approach to get me started? Admittedly the timers/countdowns/resets in RM are not in my strong suit.

Thanks in advance for your time and wisdom!

You could set something up like the below. It'll get you most of the way there for monitoring and counting cycles. You'd just set the rule for notification to run hourly instead of weekly. I think the monitoring for continuous running would need to stay in another (third) rule.

2 Likes

That's a good starting point, thanks! Critical flaw is that if an excess of cycles occurs over the time reset boundary, it will potentially miss an excess cycling event. The fix, I believe, on each trigger, after accumulating your maximum cycle count, to somehow look back at the time of the trigger six cycles back... As I started typing this I thought this would be just a single time variable, but thinking about it you'd almost need to maintain an array of the last six event times [and shift the array with each new cycle, pushing latest onto the stack]... Maybe not so straight forward...

I really need to get up to speed with app programming...

You can get rid of the "wait for event" line in the sample rule. I think that was just required in his case because of how his washer uses power.

My rule for the washer is below. Note, that instead of waiting a time interval, I'm just looking for power to drop to 0W. My washer turns off after a cycle and isn't smart, so there's no power draw at that point.

I would think you could update the rules a little to get what you want.

Rule 1:
Monitor power usage to count cycles. Something like

Trigger: Power >200W
Actions: Turn on virtual switch (indicates cycle is running)
Wait for event - power <=10W (cycle has ended)
Add 1 to count
Turn off virtual switch

You only need the private boolean depending on how power is consumed during a cycle. If the pump just ramps to, say, 300w and stays there until it finishes, you won't need it. If the power crosses the power level of the trigger multiple times during a cycle, you want it. This keeps the rule from being constantly triggered during the cycle.

Rule 2
Reset your cycle count each hour.

Rule 3
Notification rule.

Trigger: Virtual switch turned on
Action:

While VS turned on, repeat every 10 seconds
If ( time since last event 'virtual switch turned on' greater than 2 min)
Send notification.
End repeat

Rule 3 may need some tweaking since I'm just going off the top of my head.

1 Like

This is an effective means of counting how many cycles occured within each hour, but does not give instantaneous rate. For example if my alert threshold is >6 cycles per hour, this approach will not properly capture the below example, it's only seen as three cycles from 12-1, and four from 1-2pm

(1200)

-1240 run
-1245 run
-1250 run

(1300)

-1301 run
-1311 run
-1320 run
-1335 run

(1400)

I'm not sure what you mean. With the modifications I provided above you would get:

Rule #1: Maintains the count. There are no thresholds. Every time the pump runs, the count would increment by 1.
Rule #2: At the top of the hour, send the current count for the hour (again, there's no threshold, so you'll the count no matter what) and reset the count back to 0.
Rule #3: Notification if the pump runs for more than 2 minutes (with an, up to, 10 second delay).

If you also wanted an immediate notification when the count hits 6, you would update Rule #1 by adding another action at the end that says: if ( count >=6) send notification.

If you only wanted a notification each hour if the cycle count was 6 or higher, you would remove the notification line from Rule #2 and still add the line to Rule #1 from above.

Refer to the example runtimes. Between 1240 and 1335 (less than an hour) it ran seven times, over my example threshold of 6/hr. However if we're resetting the count at the top of each hour, that only appears as 3runs per hour, then 4runs per hour.

With you now. Yeah, I think that would be more along the lines of app territory so that you could maintain an array of triggered times to reference off of. Maybe someone more skilled than I with RM can think of a solution. I will still poke around to see if I can come up with something...gotta solve the puzzle box.

All good, I very much appreciate your insight and help this far. I didn't realize this was an issue until I started hashing it out here.

Even in app territory, I think maintaining something like 20ish events per hour would be no problem resource wise. However if someone wanted to monitor for, for example, a case of >100events/minute, that's a lot of array shifting and could be hub taxing.

I wonder how the Hubitat system does it for monitoring excessive log events...

According to my washing machine, pretty well :smile:. I think the threshold is set per device. I had my washing machine plug sending power reports with every 50W change. That turned into getting several hundred events during an hour and a half wash cycle. I triggered the alert more than once while dialing it back.

You will need another rule (or app routing) to monitor the pump for 100% on.

To start could you simply send a message if the pump runs "again" within 10 minutes?

John

Yep this was my next thought - I created a hub date/time variable for 'WellLastRun', and a local for 'TimeNow'. However for the life of me I can't figure out how, as an action, to compute (and conditionally act on) the difference between the two in RM5.1.

That was one idea I perused last night and came to the same conclusion. The only action I could find that would let you natively do a "time since" operation was checking the last event of a device. Hence the recommendation for a virtual switch to measure the run time.