How about a test for "Unchanged" as well as "Changed"?

I think I have to do something else for a while.
My limited capacity brain is starting to fry.
Thanks for trying to help.

If you need help with this when you come back, sharing a screenshot of the complete rule would be best so someone can see exactly what you're talking about. Good luck!

4 Likes

I tried two other approaches.

One, following @JasonJoel 's example, and another I dreamed up using variables. They both seem to work when I disable Z-Wave and have them notify me via Pushover.

@JasonJoel's example used less time: 31,562 ms vs. 57,902 ms for my variable method. I think the first method is more responsive with less time.

But, @JasonJoel , I still don't understand why anything gets acted upon when the trigger isn't pulled? Wouldn't that knock out all the actions? I guess I'm not understanding the canceling.

I haven't revisited @bertabcd1234 's Time Since Event method. The many events of the HEM reporting every 5 seconds did in my first attempt. with the huge time.

Thanks for helping me guys.

Hopefully Z-Wave won't crap out on me again tonight after a failed cloud backup.
If so, this rule just might shutdown and power cycle the hub while I'm still in bed.

edit: This is what I'm going with tonight:

When the value updates, the rule will create a timer to do the delayed action after the specified delay period.

So as long as the value updates once, then the delayed action will happen at the end of the delay because of the time it sets for itself to do so.

However, if the value changes again, it kills off the old timer (via the cancel delayed actions step) and then in the very next action creates a new timer - thus effectively resetting the timeout period.

If the value keeps changing, it will keep resetting the delay action timer.

If the value stops changing, then the delayed action will run at the end of the delay window.

3 Likes

Well, it went to number 1, ms-wise. Can't say I'm crazy about that.

Pick a zwave sensor variable that changes less often? I would guess that power one changes a lot, so the rule will run a lot...

1 Like

I don't have any power reporting plug set up for that, or any other periodic reporting Z-Wave device, far as I can think of. I'll look into this.
edit: I changed kWh to 10 minute intervals and will use that.

Is the Home Energy Monitor device not Z-Wave?

That's reporting power every 5 seconds.
I think it's doing kWh at 2 minute intervals, so I could use that instead.

So it is Z-Wave?

Yes, it is.

Ok, then the screenshot you posted earlier should do the job I guess?

Except I'm going with the 5 second power interval reporting to 2 minute kWh interval to lessen app time.

I'm not sure I quite follow, you do have a 5 minute delay in the rule... But you are across your setup more than me, so I'm sure you'll work it out.

I think he is concerned about the CPU usage being excessive if the trigger fires every 5 seconds, so he is using a 5 or 10 minute report for the trigger.

No z-wave outage after cloud backup, so no real world test.

I made the reporting interval for kWh on the HEM 30 minutes-I don't use it for real time stuff anyway. I then changed the delay in the rule to 32 minutes (has to be greater than event interval).

I also added an action to notify, via Pushover. Wasn't sure that would work, but it seems to have worked after disabling Z-Wave. I'm waiting on a second consecutive 32 minute cycle before declaring success.

Here's what the rule looks like now:

Here's what Pushover looked like:

edit: Success, I hope.

Now you have to determine why your Z wave drops in the first place! :flushed:

1 Like

They're working on it. :slight_smile:

1 Like

After running 8 hours time is only 8,016 ms. Respectable. A potential half hour delay in notice isn't bad, in this case.