Logic for rule not working as intended

Feedback
#1

Any idea what I'm missing here? The iotawatt gets polled every 30 seconds and basically I get a notification that it is defrosting, then 30s later that it's done (it's not), then 30s later that it started again, then 30s later that it's done until it truly is done.

The IoTaWatt is an electricity monitor and I'm using a community driver that exposes the the various inputs/outputs but the input 5 I am using is the channel monitoring the air handler of my heat pump. That thing pulls 115-250w depending which speed the fan is in UNLESS the outside unit is defrosting in which case the outside unit calls for the aux heat which is currently 10kW of electric heat strips. So that's why my threshold is just 500+ watts, In reality anything over about 260, but whatever...

If it's not obvious I wanted to trigger one notification when it started >500w and then another when it went back down below 500 but I get the ping-pong back and forth until it's done.

Anyway, here's the rule:

image
image1120×738 29.2 KB

The power does NOT drop below 500w while it's defrosting (it's ~10250 watts total). I assume I'm missing something really stupid here.

I technically don't need the rule anymore because I decided to just disconnect the W wire from the outside unit to the air handler so it won't kick on the aux heat when it's defrosting (personal choice, I know that means it blows cold for a few mins) since I wrote the rule but for future reference I'm just curious what I did wrong.

#2

While something is running the power usage will rarely stay constant, so you’ll continually get a power change event, and if the amount is > 500 you’ll just keep flipping the defrosting variable.

#3

May I suggest that you change the trigger, rather than changed to be is > 500 so that you get a single trigger when crossing that threshold, then, within the rule, wait on the level becoming, say, < 490 or some such. Take out the conditionals on < or > 500 in the rule. You won’t need the defrosting variable or conditional tests because the rule will only trigger when defrosting starts, then wait within the rule until it stops (by < 490).

2 Likes
#4

That makes sense and is a lot simpler...but I think the problem is it keeps getting triggered because the the energy meter is polled every 30s and each time it's polled as long as the # is different from the time before it will report the new # and that triggers the rule.

image
image1129×233 11.6 KB

so I think I still need it to be a little more complex (to avoid the re-triggers), trying this now, appears to be working for a few mins...at least it stopped spamming me on/off

image
image1178×374 16.4 KB

Just saw this somewhere else: ". Otherwise, you could take advantage of the fact that a "Wait" in a rule gets cancelled by any trigger event (by which I mean that gets cancelled and nothing after it runs), so something like this may do what you want:"

So basically...this won't work either I guess? cause every time it retriggers...it will cancel the wait so I'll get running but never get "done".

#5

So, this is an out of the box idea..... but, what you are trying to do is almost EXACLTY the same logic as monitoring dryer power (Look up "Better Laundry Monitor" which is also available on hubitat package manager)
So, you might try that and use the IoTaWatt as an input for the "Dryer" and just change the custom message to whatever you want.

The biggest issue is finding the actual thresholds for when it is "off" or "done" vs when it is idling at a moderate power. If they are the same value, then you are going to need to know the max length of time that it idles during a defrost cycle, and set a wait for some length of time a little bit longer than that. So, basically, you are going to have to watch a complete defrost cycle, or check in the logs for those values from a previous one.

The thing with the better laundry monitor is that the logic is already there for you and all you have to do is adjust the triggers/thresholds: Cycle on power threshold, Cycle off power threshold, cycle off power minimum time (For dryers, they can read low power for up to 4 minutes while they idle even though the complete cycle isn't done), etc.

#6

No. You misunderstand triggering. The trigger … > 100 means becomes > 100. As long as the value stays > 100, no retrigger occurs.

Triggers are events, not conditions.

#7

I don't think that's right, from my trials with my fridge lux sensor, if an event occurs on the trigger device and that event matches the criterion (>x) then that triggers the rule again. I am going to have to use a virtual device as a gobetween, so that every time the real device is over a certain amount it will turn the virtual switch On (and as long as it stays On it won't retrigger) then every time the real device is less than the trigger amount it will turn the virtual switch Off - and again that won't trigger an event as long as it keeps getting set to Off.

#8

image
According to the logs, the rule is triggering every 30s (the polling freq for the iotawatt)

#9

Ok, then that’s a mistake in the driver, in that it is forcing an event on each poll, which it shouldn’t.

The approach, then, would be to use something like the Better Laundry Monitor, as suggested above.

#10

I don't think it's a problem because the # is different each time:

power 2520.0 DEVICE 2022-01-17 09:36:42.568 AM EST
power 2534.0 DEVICE 2022-01-17 09:36:12.543 AM EST
power 2539.0 DEVICE 2022-01-17 09:35:42.539 AM EST
power 2538.0 DEVICE 2022-01-17 09:35:12.455 AM EST
power 2546.0 DEVICE 2022-01-17 09:34:42.426 AM EST
power 2535.0 DEVICE 2022-01-17 09:34:12.407 AM EST
1 Like
#11

When I searched a bit it seems that people often end up resorting to a virtual go-between to handle similar situations

#12

I'll take a look at the app, as you say, name aside, it probably does exactly what I wanted, I just wanted to know how to make it work in RM.

#13

It’s not a driver issue, as I am the author. The driver reports each status update, and it is up to the Hubitat platform to de-duplicate identical events. Since we’re talking about a floating point power value, it would be almost impossible for two duplicate values to be reported by the IoTaWatt in a row, except when the power is 0.

3 Likes
#14

In Rule Machine you should be able to use a predicate condition to create a single trigger as it goes above the value you want.

See this thread for a full explanation and a sample:
https://community.hubitat.com/t/new-app-features-in-2-2-8/74236

I haven’t tried this, but based on the info and the sample Bruce gave, this should work:

Predicate condition:
Power level of IoTaWatt <= 100

Trigger:
Power level of IoTaWatt > 100

Actions:
Notify ‘Heat pump fan is on @ %now%’
Wait for event Power level of IoTaWatt is < 10
Notify ‘Heat pump fan is off @ %now%’

Predicate Conditions are based on the state of the selected conditions before an event triggers the rule.
So if the predicate is <100 and the trigger is >=100, it will only trigger once when it goes past 100, then no more triggers. You won’t need the variable or the IF statement. (Assuming this works.)

1 Like
#15

I'd be very interested to know if that close encounter between trigger and predicate works reliably... I watch this thread with interest :slight_smile:

#16

Assuming the case where power is coming on, and rising from < 100, and then reports > 100: this rule will work. Prior to the first report of power > 100, the Required Expression is true, and the trigger is enabled. Upon the first report > 100, app events happen in this order: the trigger (enabled) is true, the rule fires, runs its actions, then the Required Expression is evaluated, which becomes false and disables the trigger by removing its event subscription. So, net, the rule will run once and then not again until power has returned to below or equal 100.

1 Like
#17

Thanks, this makes a lot of sense. And I must admit it took me longer than it probably should have to figure out how to add a "Predicate Condition" since they changed the name to Required Expression for 5.1 :joy:. This is also nice and simple. I had sort of given up because of the frequent polling of the iotawatt was causing frequent triggers which overrode the delays and such, but this is way cleaner. So thank you and Bruce very much. I'll test and report back.

1 Like
#18

Please do :slight_smile: Cos I've got a rule that could benefit by being similarly simplified if it works

#19

Screenshot_20220123-164850

Looks like it worked. I kicked it on then off a few later. Thank you very much guys. I used that logic to update a couple others to watch our voltage. The power company was giving us over 130V last week and it makes my solar inverter shut down, so now I'll send notification before it gets that bad to keep an eye on it and call power company if I need to.

2 Likes

Download the Hubitat app