it should
Can you show me an example?
like the ecowitt weather station above has 4 actual devices a wind sensor , outdoor temp sensor, outdoor rain sensor indoor temp all reporting under one device handler.. others too like lightening but that is a separate handler.
that is why i added custom attributes windLastUpdate , rainLastUpdate, etc. that get set with last time that type of data came through the handler. I can goto the dashbaord above and see based on the last time whether i am still getting reports.
im thinking maybe i can use your custom attribute code but the rain etc may not change value even though the report came in that rain is 0. I could que the custom attribute code in it on the lastupdate times but hard to specify what the value should be.
or maybe just write 5 or 6 rules that do a time difference comparision if that is possible and report if value is > x hours?
For this I don't think I have an easy way to handle it.
Looks like you would need to add code to that driver to do the time comparison. Then have it send a notification if over x days.
thanks and no way to do a time difference between current time and an attribute value with time in either rule machine or event engine? if convert to seconds maybe compare the two?
RM, I don't know... haven't used it in a long while, ver 2 was the last time I think. 
EE, not yet. I've been thinking on that one. Right now I do something like this behind the scenes but it would be tough to expose it. Working with time is tricky! How it's formatted is everything.
Let me think on this some more.
1 Like
ya as soon as you start mucking with time you have local time, with and without am/pm, gmt time, utc time, time past midnight 1970 in secs etc. lol
@bptworld - I have had a couple of instances of the red piano light not going out when all things are shut/locked. The light turns from red to white, but doesn't finish going out. When this type of issue came up a while back IRRC you resolved it via timing - increased the delay from .5 to 1s as far as I remember. Could that timing have gotten pushed back to .5s again? If you don't see anything obvious let me know and I'll grab logs tonight.
I think I may have discovered a minor bug in the reverse handling, unless it is a misunderstanding on my part on how it works.
I have a motion sensor lighting rule that should not be active during certain modes, like night. When night mode is initiated by the hub, the cog will run through (seems to be triggered by the mode change) and it will recognize this rule as having mode conditions. It correctly sees that the motion sensor is inactive, but then it plays to the end and as I have a reverse action set up, it will actually initiate that action and turn on the lights at a certain level.
I would have thought, that since the previous condition of the rule were not met, that the reverse action should not be initiated ?
Can this be considered a bug or is this my lack of understanding ? As a workaround I could turn on a virtual switch in night mode to disable the rule, but not sure it it would work.
Here is the cog
Here is the log
New version...
2.2.0 - 10/25/20 - Added Adjustable time delay between device Actions
Thanks, I'll take a look at this later today.
Turn on the 'By Mode as Restriction' switch and see if this solves your problem. If not, I'll keep digging. 
1 Like
Any chance this could be added to the wish list?
I have an app for IR, Send IP2IR. It's made to control Global Cache products but may work with others as well.
Oooooooooooooooo!
Thanks! I noticed something after I posted that was odd, last night. When the final door I shut and locked was the slider in our family room (and the "lock" is really just a contact sensor on the lock lever that I named a "lock"), the light went out normally. When the final door I shut and locked was the front door (w/an actual lock) the light went white and then stopped.
I'll play around w/the timings that you've provided - thanks very much for doing that!
1 Like
Ok, so I updated to 2.2.0 and enabled "By Mode as Restriction", but then my lights started to come on and change color temp, one by one, and each change following the last, instead of all at once.
As I noticed you had also added a delay option, I though perhaps that was causing the change, but changing it from 1000 ms to 0, did not change the behavior.
If possible, i potentially could roll back to 2.1.9 to see if that will change back to the previous ?
Behaviour on 2.2.0:
Not sure if it works, but for comparison I guess one of my previous logs would work.
It can be quick but it has never been all at once. Unless your using a group, devices can only turn on/off and set, one by one.
Nope, it wouldn't. If it is set to 0, it will default back to 1000. Try using 1 or 5.
Sure, all version are available on GitHub, click on History.
But try the delay set to a low number first (just not 0).
Thanks
New version:
2.2.1 - 10/25/20 - Adjustments to Special Action Option
Dropped default down to 250 ms and also added a range of 1 to 4000.
1 Like
I tried first to change the delay to 1 ms, but that did not do anything significant. I then went back to 2.1.9 and it performed better. You are of course right, they do not all turn on at the same time, but close enough so that i felt 2.2.0 to be slower. I then went back to the latest version and got 2.2.1, which now seems to be similar to 2.1.9.
So it looks like the problem is solved 
Here are my logs to show the differences:
2.1.9 logs
2.2.0 logs (the slow one. You can see the difference in times. Basically it looks like it is adding 1000 ms)
2.2.1 logs (back in business)
2 Likes
Great detective work, thanks!
1 Like
I set the delay to 1.5s and the infamous piano light turns off completely, doesn't get stuck at white setting. I guess either my mesh, or the Sengled bulbs, is a little lazy. I'm going to play w/it a bit to see how close I can get to 1s delay. Thanks very much!
1 Like
