Thanks for the explanation. My problem is though that I can’t use brightness as the trigger, as explained in my original post. Using location mode and sunrise and sunset is a proxy for darkness. I noticed this morning everything was working as intended, so disabling that routine was the answer, by the way.
You could still use a virtual switch and turn it off and on based on time alone, will work that way too.
Yes of course. Why stick with the simple solution when there’s a way to overcomplicate it?
When you add a time period to a Routine it acts as a pre-condition, so the Routine is not triggered at the start or end of the period. So the Routine only executes if one of the triggering conditions becomes true during the time period and handling conditions that were already true at the start of the time period required another time period.
A number of users elected to use virtual switches (or even real ones) to represent time periods, especially ones common to multiple Routines. One Routine would turn on the switch at the start time and another would turn it off at the end time. Using the switch as a condition instead of the time period added the missing start and end triggers, although without else conditions using the end trigger would need another Routine.
A option to run the Routine at the start time was added to time periods but the benefit of the virtual switch remained in being able to change the time period independently of Routines and to be able to do stuff at the end of the time period, or indeed to flip the active time period by testing for off instead of on.
You can, of course, do exactly the same thing with the Location Mode, though there is only one mode active at a time. You can add and delete modes but if you do you may need to revisit all the Routines that use Location Mode to make sure they will still work.
You can also use a variety of other virtual or real devices in a similar way.
None of which changes your problem of not having a usable illuminance measurement.
Thanks. I understand a bit more how virtual switches could be used. Effectively, they function like a physical switch, but are turned on and off by automation functions rather than physically. I can see the uses for those, and it may be as I expand the devices I have and what I use them for that it will make sense in the future to do this with a virtual switch. At the moment though, it works pretty well with the routines as they are.
Are you suggesting a virtual switch over complicates it? I’d say it is a cleaner approach and allows movement routine to execute locally, which won’t happen with a time component in the routine itself which would force cloud execution.