I have a device which "availability" status can go from "online" to "offline" and I created a rule to alert me if it stays offline for more than 10 minutes. However, it seems that the following happened:
6:05:30.326 : device availability goes to offline
6:05:30:405: device availability goes back to online - 79ms later
6:15 the notification goes out reporting Triggered: Garage Door reported availability(online) offline and stayed that way for: 0:10:00
So it seems that the rules engine is triggering on stay that way even though within milliseconds, it reverted to online.
Rule looks ok. Looks like a bug to me. I have rules using the Stays that way and they work fine, so I assume it's something with the driver for your device.
I remember many moons ago (probably 18 months or more) there was a bug like this where the 'stays that way' timer would continue to run when the condition that triggered it was removed during the time period. On that occasion, I think the bug only occurred when using a custom attribute from a device (in my instance I was using a 'contact' custom attribute from my LG Fridge driver when I discovered the bug). So it could be something in the driver.
I suspect this is the crux of your issue. While it's possible something could be done at the app (rule) level to address this issue, this seems like a better problem to address at the driver level. Surely it was not truly offline for only milliseconds?
In general, it's best to avoid events for the same attribute coming in within mere milliseconds of each other. Apps with a subscription to that event will wake, for both if that is what they are subscribed to, and it's possible the first instance won't have finished running before the second starts. What state you end up in, then, may not always be predictable (depending on how the app stores anything it might need to related to this data -- things like state or atomicState, for example -- and which one actually finishes first). Anything you can do in the driver to avoid this is likely to make most apps work better.
Looking at the device events they are actually more than 2 seconds apart, it's the time between them registering with the rule that is short for some reason. The offline log from the rule is a "long* time after the device event compared to the same difference for the online event / log.
All good advice & suggestions. Following @pseudonym post, I'll add a delay within the actions of the rules to see if I can give it a bit more time to bounce back. Not sure how I would fix this in the driver and whether I'd want to. The device went offline for 2 seconds, that's the reality of things. While I don't think it went "Wifi" offline, its connection to the MQTT server did from the point of view of the latter.
I'm not suggesting a delay as I don't think you can force a delay between events. I'm just showing that a longer time between events worked where quicker didn't.
I guess you could add a few second Wait and see if it's still offline then start a Wait for Expression using a 10 minute duration to send your notification.
As mentioned above, this won't work. That actions aren't the problem; it's the trigger of this rule.
Did you write the driver? If so, there are likely ways you can handle this. If you are using one written by someone else, I would make this suggestion to the author. Many are amenable to reasonable ideas.
@bertabcd1234 I did write the driver, I welcome suggestions. Not sure whether that's the right thing to do though as it reflects reality (went offline for 2 seconds)
In many of my drivers, where I have added a feature to determine if the actual device is working or not, I add a user setting that determines how long a device needs to be 'offline' (or unresponsive, or whatever one wants to call it) before I change the custom attribute status. This way, if the device does respond during that brief outage, it is as if nothing happened. By doing so, I avoid getting notified for every reboot of a device. It also improves the reliability within Apps, as most are not really capable of handling events in rapid succession. The platform is running on a JVM, not a Real-Time Operating System (which is what I have spent most of my 32 profoessional years working on.)
If it were a Real-Time OS C/C++ based platform, then it would have no problem handling this type of timing. But alas, this is a consumer-grade platform built on Java/Groovy. One has to work with the limitations and tools provided.
Well, that is a very good question... I have looked through my code to find what I would hope is an 'Ideal' example of what I described above... Looks like the closest one I found is in my HubDuino Parent Driver code. For whatever reason, it appears that I simply use a repeating scheduled job to check every 5 minutes if the time since parse() last ran exceeds the user specified threshold.
Knowing what I know these days, I might choose to write this slightly differently, but this has worked well for years.
look for the checkHubDuinoPresence() routine, which is called every five minutes due to the following code in the updated() routine.
runEvery5Minutes("checkHubDuinoPresence")
Instead of using a custom attribute, I chose to overload the meaning of the 'presence' standard attribute. It implies whether or not the device in question is 'present' on the network and communicating with the HE hub. At least, that is how I justified to myself using that particular attribute many years ago.
For your use case, it might make more sense to simply start scheduled routine if MQTT reports the device as being offline. If you receive another MQTT status update stating the device is back, before the timer expires to run the routine, then simply cancel the scheduled routine. If the scheduled routine fires, change the attribute to indicate the device is not available.
