I have a temperature sensor that I need to be reliable, and that is usually quite chatty. I wanted to set up a notification if it has not spoken for more than a few hours.
I am aware of Device Activity Check and Device Watchdog. Activity Check only reports once daily. Watchdog might do, but it's quite complicated to install.
So my request is for an extra Trigger in RM for when a device has not evented for a user-defined time. I'd guess the rule would prime on each event, then wait the time. Seem like it might be a little hard on the hub, but it's a choice.
What you could do is in the rule that handles sensor events:
-> set/update a variable to "last event timestamp".
-> cancel all delayed actions this rule
-> wait 1 hour (or however long you want to get notified if it hasn't pushed an event)
-> IF "last even timestamp" > 59 minutes ago THEN notify me that the sensor isn't updating
Because each new event sent cancels the timer on the previously called instance of the rule, you'll only ever have one instance of the rule waiting. I don't think this is a particularly resource intensive thing to do. Your request is basically to have the above baked into rule machine itself..just adding to the rule machine bloat. Why not just do it like this?
What I am doing for now is pretty similar - each temperature changed event for one particular device (fortunately I only have two devices I need this for) is updating a time/date hub variable. Then I will make a rule that runs once per hour and compares Now to the time stored in the variable and notify if more than 4 or 6 hours (to be decided) difference.
The problem is again, in RM, you can only choose a comparison, or increased or decreased or changed. If the temperature is reported again just in the device's general over-chattiness, and it's not changed, it won't trigger the rule.
So in conclusion I think I'd still like a trigger based on "any event" for a device. I don't know if events have UIDs but maybe that could be captured in a variable if so. So there are a few different ways of doing this, but obviously first they have to be available in RM. I could probably write an app if necessary but it would be very specific and I think making some way to do this available in RM would be more flexible in use.
Ah, I apologize. I misunderstood.
I checked out the trigger events for Motion Machine and indeed they don't allow you to set a trigger for "new temperature report received, regardless of whether the temperature has changed".. or at least that's how I interpret the wording.
I agree with you it would be nice to set a trigger based on the "device sent a report for attribute X" event, rather than only being able to compare the result of said report to the previous value of the attribute (or a variable or whatever?).
I wonder if Rule Machine is triggered on "value of attribute X changed" or on "device report for attribute X". If it's the latter you could just compare the temperature to '9999' in the trigger, which would ALWAYS cause the rule to fire whenever the attribute report is sent.
Might be worth investigating?
Actually... I think RM does have the solution after all. Not as a trigger but as a conditional. I have discovered I can run this rule on an hourly schedule, and use "Time Since Event: Any Attribute" to decide if it's been too long hearing from it. I hope. Shall test now
sweet, so that means you could just compare it to an impossible value to always have it trigger when the device sends an attribute report. That's very good to know, ty.
Yeah that wouldn't have helped me, since the temperature might not have changed since last event - something else might have changed. Then it sends the whole lot again. So really for me it needed to be any message at all from the device would do, not just a change in an attribute
I am sure that you know this already - all things are event driven, so you have to be able to start the clock somewhere. Absence of an event cannot be the trigger.
Yeah, so I had been thinking of something really complex like the rule starts upon a change event, then does a "stays that way" or something. Went off the idea when I realised just how many times this rule would trigger when the device was behaving nominally and the toll on the hub. Anyway I am happy with what I have now, using the conditional action.
Well, if the device pushes like 6 different types of events in rapid succession whenever it does an update, you could prevent the rule being triggered 6 times by setting a small global boolean to 'true' to indicate it's already received an event from the machine (which you then reset to false after 5 seconds or something.. and you use the boolean = false as a condition to fire the rule to begin with).
There's many ways to prevent excessive rule firing.
