& No, I'm not cursing 
As I moved from Wink to Hubitat & started re-creating the rules in Hubitat, I realized that there were a ton of my rules (robots in Wink) which were time dependent. More specifically actions dependent on sunrise or sunset triggers. There was that small, almost imperceptible lag in the motion sensors triggering associated lights and dimmers. Way way faster than how Wink was processing them - it would check the cloud for any sunrise/sunset related triggers - for every single event! This would account for a generous lag in Wink.
The community in Wink was very helpful. Someone had suggested back then, to remove the sunrise/sunset dependency on the triggers and leave them on all the time. Use a second robot (rule) to turn or (un-pause) or stop (pause) all the robots (rules) which had the sunrise/sunset dependencies! This removed the need each one of the trigger events from checking for the sunrise/sunset time dependency for each motion triggered. This also reduced the chatter back & forth for time check, to probably a few times a day!
Yes, I did poke around and noticed that the Hubitat maintains the sunrise/sunset information locally on the box - checked once a day! Still, using this ass backward kind of logic, removed the need for each motion trigger to check for the time dependency! I'm using a secondary rule to either un-pause or pause the required rules! Yes, this does increase the number of rules on the box, but the motion triggers do not have that extra condition that they have to check for, every single time!
This is most likely a futile exercise. Show an example of a rule that has the sunrise/sunset logic in it. Checking against sunrise/sunset is a database lookup and math comparison. It takes a minuscule amount of time.
1 Like
