No matter what, and including post soft reboot and full power reboot, this rule always evaluates to true as if RM is using the Sunrise time as a pure value and seeing that its between 05:50 today and .
System clock, TZ and location/sunrise information for the hub have been verified.
Adding an extra check, this seems to happen whenever sunrise-X is before of the condition... question then becomes how to write a Rule that correctly acts only when the time is actually between X and some sunrise-15 that is and works all year round...
Time now 14:55
Sunrise is at 6:30
I get the following:
There must be some logic in there, somewhere 
The condition will be true if you're after the first time, but before the first sunrise following the first time...
You could add an AND condition: Time between Sunset and Sunrise - 15 minutes
I'll give that a go, thanks
Hiā¦. My apologies, maybe Iām just not understanding the use case but why create a trigger for your hub every 5 minutes?
Have you tried just starting over with a simpler approach and just making sunrise your trigger?
Assuming I am not completely misunderstanding what youāre trying to do, once you can confirm a simple sunrise trigger fires off correctly and consistently first then you could apply additional layers of complexity/logic as needed one piece at a time so if anything breaks you know itās whatever the latest addition was.
I want my lights on from 5:50 until sunrise-15 and from sunset+15 until midnight, unless overridden. If sunrise-15 is <= 5:50, then itās bright enough outside that I donāt want them on.
If the trigger is sunrise, then the sun is already up, and thatās after I need/want my lights on
Nice that makes perfect sense. Thanks.
I do something similar except I use an outdoor motion sensor that reads lux instead of the systems default sunrise/sunset values but extensively itās the same idea.
You do bring up an interesting condition though since technically your sunrise + 15 or whatever could occur before 530 am.
Iām sure someone on here will beat me to it but let me think about it for a momentā¦
For reference, here is the whole of my use case:
Set global variable sunrise_time at 00:01:
Override rule:
Actual light control rule:
I think that last iteration of my use case actually "solves" the problem, just inelegantly.
What we would "need" is a way to reference sunrise today. I tried setting a global datetime variable, but the variable compare in RM ignores the date portion of it.
Oh yea this is 100% how I had mine set up originally. I like where your head is at.
Was fine at first but started to become too cumbersome to scale so I broke it out into multiple rules to give me more control and make tweaks faster.
I have 1 rule I use to determine day/night mostly triggered by the lux sensor I mentioned previously that flips a variable (switch) on when itās bright out and off when itās dark out.
That variable /virtual switch is used in all kinds of ways across tons of my rules at this point but to stay on topicā¦
A second rule is only triggered when the switch turns onā¦ (if between 6am and 8am turn off porch lightsā¦ elseā¦)
And the third rule is triggered when the switch turns offā¦ (if after 5pm turn on porch lights, close the blinds, blah blah night stuff)
Donāt know if you want to get that elaborate but itās made the process of updating or adding sooo much easier than the beast of logic that was my old rule where I was cramming everything in one spot
Cancel that celebration lol. I got ahead of myself. That will still trigger after sunrise-15 once sunrise-15 is after 5:50 and mode is day... meaning my lights would stay on all day.
Ok, so I added a new mode, Sunrise, which starts approximately at the earliest listed sunrise for my location:
and updated the rule to only trigger in that mode. Assuming the Mode Manager correctly set mode to Day @ sunrise-15, then that will escape the rule at that point:
Nice. You able to confirm if works already or you have to wait until 550?
I canāt seem to get more than 2-3 hours sleep for some reason so please excuse me if this doesnāt make sense but I was also going to suggest trying some variation ofā¦
Predicate:
Current time ā sunrise +15
Trigger
When time is 5:50 am
Actions:
If Current time ā sunrise +15
AND light = off
Then turn light on.
Wait for event (sunrise +15)
Turn light off.
Else
Turn light off.
Probably donāt need that predicate but it might eliminate the need to use the conditional
With the new mode, I can probably have the mode start at 5:50 and reduce the condition to two checks:
"If variable >= 5:50" AND "If Mode is Sunrise"
I think using Wait for actions, even if cancelable, removes the ability to override the current condition of the lights in a way that returns them to their scheduled mode.
The override switch I'm flipping is tied to the other app that resets the switch for 15 mins; this has two net effects:
First, anyone changing the lights will only override them for 15 minutes, and second, even the main rule can only affect their state once every 15 minutes - to prevent them coming on at 5:50 and turning off at 5:51 or some such variation
I wanted to use modes when I rewrote all my rules upgrading to RM5 but i had to abandon it and now canāt remember why.
Want to say it was something minor like I couldnāt trigger a mode from lux without adding a bunch of extra overhead or something like that.
Yep makes sense.
I try to eliminate the need for maintaining overrides whenever possible by just adding an extra condition or predicate so the logic only runs if the light is already off or whatever but given the multiple value states youāre juggling itās probably easier to just do an override.
Download the Hubitat app
