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

Thanks. That gives me something to think about, using Boolean and use of the delay and cancel delay.

And to be fair, there may be an even easier way to do it in RM than using 2 rules. I admit I am not an RM guru.

Edit:
Even easier way to do it in 1 rule, now that I think about it.... Simply start the actions with "cancel delayed actions", the do an action with a cancellable delay.

  • If the sensor never changed, it is never triggered, and the action happens.
  • Sensor changes, delay gets cancelled, and a new one made.

(told you I wasn't an RM guru... Or I would have thought of that in the 1st place. lol)

4 Likes

Correct. But "changed and stays that way for a period of time" can be a trigger. Meaning something changes and remains unchanged after that for a period time can be used as a triggering event, as alluded to earlier by @Pantheon.

5 Likes

Depending on what you're looking for, a "sticky trigger" could be another option besides those described above. This is the "And stays?" option that is available for most trigger types that represent a particular state change (you will not find it on things like "changed").

Of course, this discussion would be easier and more focused if you could provide a specific, practical example of what you're actually trying to do. :smiley:

4 Likes

Because of Z-Wave crashing on me after a cloud update the last two mornings, with no mention of zwaveCrash in location events, I'm trying to test if Z-Wave is still operational. I think periodically turning on and off a switch would be too intrusive. I'm thinking a z-wave device that reports periodically could be tested, and I could be notified, or more. I have an Aeotec home energy monitor that reports every 5 seconds, but if I tap into that with a rule like @jasonjoel suggested, maybe it'll put it over the edge as far as bandwidth.

In that case, a "Time since event" condition in your actions coupled with whatever trigger you want (periodic and rarer than every five seconds like you'd get with the device event trigger, I'd suggest...) would probably work.

Or you could use an app written for this purpose (well, not that purpose, but same idea), like this one I wrote or a couple other abandoned options: [RELEASE] Device Activity Check - Get notifications for "inactive" devices

3 Likes

It's not looking that great for this concept.

It is unclear from your screenshot and the lack of information provided what "this" is.

2 Likes

The Time Since Event concept.
Test is the name of the rule.
It's more than 3x Dashboard as far as memory use.

The most important piece of context missing here, as I noted when suggesting this option, is how (really how often) the rule is triggered.

2 Likes

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?