Bug in Routine with Period of Time based on Sunset?

OldPro · June 7, 2023, 8:10pm

I want to turn on lights in the afternoon if it is dark in the house. I am using an Aeotec Multisensor 6 Lux meter. I had this working in “Smart lighting” but cannot get it to work in Routines using “Period of Time.” (I am migrating all automation in “Smart lighting” to routines because times based on sunset and sunrise don’t work now).

I want the lights to go on if Lux <=250 AND Time Between 1 PM and Sunset.

When I create a Routine and select “Period of Time,” I can specify a “Start Time” as a specific time just fine (first pic below). The initial Start Time is the current iPad clock time. The default End Time is the Start Time plus one hour. I can adjust the Start Time just fine (in this case, I set it to 1:00 pm).

When I click “End Time” to change it, I get the time selector and the Start Time stays at 1:00 PM (second pic below). So far, so good!

BUT, every time I try to change “End Time” to a time based on Sunset, it changes the Start Time, too (third pic below). My expectation is that Start Time should stay at the 1:00 PM and I can change End Time to a time based on Sunset. But, no matter what I try, the app always changes the Start Time to either Sunset or Sunrise.

Is this a bug or normal behavior? How can I program ST to turn on house lights on a dark day between 1 PM and Sunset?

I thought maybe I could have TWO separate Time conditions, one for Start 1:00 PM and a second for End Sunset, but the app only allows you to have one Time condition.

I previously solved this by splitting the logic into three Routines and a virtual switch (vSwitch). In Routine 1, I set the vSwitch to Off at 12:01 AM every night.

In Routine 2, if Lux went low after 1:00 pm, vSwitch was set to On.

In Routine 3, I checked (IF vSwitch state = ON) AND (IF Time < Sunset) THEN turn on lights.

This was a real kludgy work-around, but it worked reliably. I was hoping “Period of Time” in Routines would eliminate this kludge solution.

h0ckeysk8er · June 7, 2023, 8:38pm

Nope, it’s not a bug, it’s a short coming. You can’t have a time period with a specific and relative time.

You’re on the right track with virtual devices. I would approach it a little differently than you. Your time period is the constraint (pre-condition) and lux <=250 is your trigger condition. So, for the time period, I would create a virtual device to represent the state (time period), let’s call it Afternoon. Then in the device Routine panel, I would set the on/off times (which automatically creates two Routines for you). I would then have a Routine that says:

If Afternoon is on (pre-condition)
Lux <=250
Then
Turn lights on

I haven’t played around with Rules at all, but you might be able to do specific and relative times in a Rule, but I think having to play around with a bunch of JSON is hassle personally.

OldPro · June 7, 2023, 9:40pm

Thanks for the clarification. “Shortcoming” indeed. The least the UI designers could do is put up an alert explaining what you explained. That would have saved me a LOT of aggravation.

Your approach is simpler than mine requiring only one virtual device.

I was just setting up my approach and will switch to yours. I’m using TAustin’s “vEdge Creator,” but I’m on v2.7 and I see he is at v2.9, so I need to upgrade that, too.

h0ckeysk8er · June 7, 2023, 9:49pm

Yeah, 2.9 has some better features including the Alexa switch with separate contact sensor.

Your approach would have worked too. It’s just the method I suggested eliminates the extra virtual switch. I did a big writeup one time on pre-conditions vs triggers but I don’t recall in which topic. I thought it might be a good thing to pin in the Automations topic because once it’s clear that state changes (triggers) are what activate a Routine and that pre-conditions are bounding conditions to be evaluated, it makes it much easier to think through the logic of new Routines.

The UI designers could have taken page out of Sharptools rules implementation where it’s quite clear “that when something happens, evaluate some set of conditions to decide what to do”.

OldPro · June 8, 2023, 3:36am

@h0ckeysk8er After more reflection and thought, I realized your approach is identical to mine. We both have one virtual switch and three routines. You are using the two Routines (created in the Device) plus a third Routine whereas I just created three separate Routines. But they do the exact same things:

Routine 1: resets virtual switch to Off just after midnight.
Routine 2: sets virtual switch to On at 1 pm.
Routine 3: If (vSwitch is On) and (Lux <=250) Then turn lights on.

We both arrived at the same solution. The only difference is how Routine 1 and Routine 2 are created.

I now have one virtual switch and three Routines. Will this work?

This Routine 1 resets the vSwitch to Off at 12:05 am:

This Routine 2 sets the vSwitch to On at 1:00 pm:

This Routine 3 executes a scene if Lux is low and vSwitch is On (have I reversed the order of the Condition and the Pre-Condition?):

csstup · June 8, 2023, 3:42am

Keep in mind that by being subscribed to his channel with that driver, you’ll get updates automatically. His driver is copying a version number to the virtual device controller’s name when its first created, but its not updated when the driver itself is updated. You can remove the controller and then rescan for devices and it will be recreated (although this will delete any existing virtuals too)

OldPro · June 8, 2023, 4:05am

Good to know. Thanks. Is there any way to determine if I’m actually using the latest version?

csstup · June 8, 2023, 4:20am

Driver tab under the menu option of the main device.

OldPro · June 8, 2023, 4:34am

How do you differentiate between 2.7 and 2.9? That isn’t obvious.

h0ckeysk8er · June 8, 2023, 7:03am

Well, not exactly. Your original Routines are not the same as the ones in your follow on post.

Your original Routine 2 was “if Lux went low after 1:00 pm, vSwitch was set to On.” That’s not the same as “sets virtual switch to On at 1 pm”.

Your original Routine 3 was “checked (IF vSwitch state = ON) AND (IF Time < Sunset) THEN turn on lights.” That’s not the same as " If (vSwitch is On) and (Lux <=250) Then turn lights on"

Not sure if you ever implemented the Routines you mentioned in your first post, but there are some things that don’t make sense to me.

In your original Routine 2, I’m not sure how you would specify “…after 1:00pm”?

In your original Routine 3, it would only work if “Time < Sunset” is a pre-condition, but I don’t know how you would specify a time period of “< Sunset”. And if it’s not a pre-condition, then there will never be an event generated for “Time < Sunset” so both conditions would not be satisfied to trigger the Routine.

In the rewritten Routines above (which differ from your original post), the approach is the same as long as you mean for “vSwitch is On” to be a pre-condition. It goes to my earlier comment about being clear about which parts of your If statement are triggering events and which are meant to be bounding constraint pre-conditions.

Sorry to be a bit pendantic I’ve just spent too many years in the business of troubleshooting technology issues and know it’s important to understand the precise scenario.

h0ckeysk8er · June 8, 2023, 7:16am

It’s not obvious from the ST tooling since 2.7 and 2.9 are designators that the author has applied.

You can compare your installed version of the driver to the most recent version using the ST CLI using the command “smartthings edge:channels:drivers” to see the most current version.

bep@debian10:~$ st edge:channels:drivers
───────────────────────────────────────────────────────────────────────────────────
 #   Name                                     Channel Id                           
───────────────────────────────────────────────────────────────────────────────────
 1   Aeotec Group                             2423da55-101c-4b21-af58-0903656b85ca 
 2   GE/Jasco Devices - philh30               479886db-f6f5-41dd-979c-9c5f9366f070 
 3   HomeSeer Group (Unofficial)              c408fa0b-438f-4d00-bf36-efe7343c66b7 
 4   Mariano Shared Beta Driver               c8bb99e1-04a3-426b-9d94-2d260134d624 
 5   personal-drivers                         bf1a769b-135a-478b-a1fc-f5c64adfbeb4 
───────────────────────────────────────────────────────────────────────────────────
 6   RBOYAPPS (beta)                          85fe2f3f-aacd-438c-a3bf-7d7d0821eb1d 
 7   Schwark Edge Drivers                     34ee1d5a-c580-47f8-a88a-0d193b4f382d 
 8   skyEdgeDriver                            1149cc62-e352-424c-a297-e63a4375978d 
 9   SmartThings Drivers (Beta)               b1373fea-da9b-434b-b674-6694ce5d08cc 
 10  TAustin Driver Tests                     42512f35-e905-416d-8696-479587f23fe2 
───────────────────────────────────────────────────────────────────────────────────
 11  TAustin Shared Projects                  e6e29aeb-2793-4ebf-b8f6-e37b69e32c61 
 12  Yakov's SmartThings Edge Drivers (Beta)  14bcc056-f80d-416b-9445-467b0db325e3 
 13  Z-Wave Drivers - philh30                 c09d2a68-e32c-4366-a4fc-ea4731b96ec3 
 14  Zooz Edge Drivers                        f8900c5e-d591-4979-9826-75a867e9e0bd 
───────────────────────────────────────────────────────────────────────────────────
? Select a channel. 11
────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
 Name                           Driver Id                             Version                        Created Date                    Last Modified Date             
────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
 Edge Counter Utility V1.1      e67c842f-49a5-4083-95f0-c8137ae3c2f6  2023-04-24T00:20:33.095683352  2022-09-02T23:21:47.158979990Z  2023-04-25T17:00:54.540269516Z 
 Envisalink 2.1                 252d4a5f-d8a4-484b-a15e-7f713737aa31  2022-06-16T21:27:36.587540491  2022-02-18T01:41:35.937830Z     2022-07-07T22:18:08.821524949Z 
 LAN Contact Device Driver V1   947a8c5a-47d1-4138-aca3-18109ad024de  2023-01-20T02:32:05.857988899  2022-11-21T20:01:08.563748462Z  2023-01-20T04:08:31.158447829Z 
 LAN Device Monitor V1.3b       606efcfe-9ad2-4dd5-9f33-554da3fd5fca  2023-01-18T01:17:18.191320741  2022-06-18T18:42:07.075366011Z  2023-01-18T01:32:25.711372815Z 
 LAN Device Trigger V2b         b09bb17a-0645-40e8-914f-b30b0db52e51  2023-01-20T02:34:21.891553353  2022-07-26T18:35:02.447802095Z  2023-01-20T04:10:11.156086651Z 
────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
 LAN Motion Device Driver 1.5   e8a1a0b7-32e4-4882-8d38-45a96ead543d  2023-01-20T03:47:56.851493131  2021-12-22T04:14:29.027114Z     2023-01-20T04:09:08.801052874Z 
 LAN Presence Device Driver V1  568a53b6-64a3-456f-a61b-693c26c9f544  2023-01-20T02:33:08.995070848  2022-08-24T20:13:22.995373416Z  2023-01-20T04:09:31.965613889Z 
 Online Status Monitor V1g      b973fd1e-52a8-4bcf-a2b8-1f3f5216891f  2022-08-31T00:36:18.813625803  2022-09-02T23:01:55.358802626Z  2022-09-02T23:01:55.358802920Z 
 Roku Driver v1.0               3c9378c1-79ab-4534-b8c3-4502bc0257b2  2023-04-08T17:18:59.143203289  2022-02-28T17:52:57.025823Z     2023-04-08T17:20:32.621887324Z 
 Virtual Devices V2             0fd9a9a4-8863-4a83-97a7-5a288ff0f5a6  2023-05-17T04:17:21.217313249  2021-10-15T20:41:46.042186Z     2023-05-17T04:23:25.208384244Z 
────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
 Virtual Energy Meter           206918b4-c049-4225-91db-808b943b8041  2023-01-16T23:25:50.100559237  2022-02-22T00:16:11.668379Z     2023-01-16T23:42:22.035171517Z 
 Virtual WOL Switch V1          66bbcf7e-a12d-468e-96d4-049be22be595  2022-05-20T03:33:34.580493     2022-05-26T17:20:05.250409055Z  2022-05-26T17:20:05.250409293Z 
 Web Requestor Multi v1.2       a7d4ff68-2e8b-41f7-9be7-62bbe70f88f8  2023-01-17T16:50:07.623400032  2021-12-03T21:53:56.134725Z     2023-01-17T17:11:58.900205344Z 
 WLED Driver                    d462e24c-97dc-42d0-b843-59f85c7d9346  2021-12-30T19:15:00.68113      2022-01-01T17:35:29.590231Z     2022-01-01T17:35:29.590231Z    
────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────

h0ckeysk8er · June 8, 2023, 7:31am

Here’s what I think you’ve created, “Between 1:00pm and 12:05am, if Lux <=250, then execute your scene”. That will work if that’s what you want.

The scenario in your original post was “I want the lights to go on if Lux <=250 AND Time Between 1 PM and Sunset.” That set of Routines won’t do that. To achieve the original use case, you need:

#1 Turn on vSwitch at 1:00pm
#2 Turn off vSwitch at Sunset
#3 If vSwitch is on (pre-condition)
Lux <=250 (trigger event)
Then “do something”

To answer your other question, you can’t reverse the order of triggers and pre-conditions. The triggers are “when the event happens” and the pre-conditions are “and this set of states/conditions is true”.

Also note, if you want local execution, don’t use Scenes. They are still executed in the cloud. If the devices you want to control support local execution, it’s better to explicitly list them in the Actions section of a Routine.

OldPro · June 8, 2023, 12:55pm

Thanks again.

That’s helpful info about Scenes still being run in the cloud (I didn’t know that). The Aeotec Multisensor nominally reports the Lux reading every hour (actual is 59 mins), so there is no need for immediate execution. That means I can use a scene. But, per your suggestion, I just changed the routine to control four lights directly rather than use a scene.
When I first set the system up five years ago, I vaguely recall there was some reason I had to set vSwitch to off just after midnight. But your idea to turn it off at sunset makes sense — it is only on during the time window 1 pm-sunset.

I have another routine that turns on living room lights everyday at sunset -55 min (before sunset). I want to avoid a change of light level at sunset -55 if the Low Lux routine has already turned the lights on. To assure that, I just set the LR lights to “turn on” in both routines rather than use a dimmer setting and the low lux time window ends at sunset -57 minutes (so it expires just before the every-day routine turns the LR lights on).

Does “turn on” mean “turn on to the last used brightness level” or “turn on to 100%”?

csstup · June 8, 2023, 1:09pm

You don’t. Notice the version date, its recent. There’s only one driver channel (not one for 2.7, a different one for 2.9, etc) so whatever is the last version distributed, all subscribed hubs should get within 12 hours.

@TAustin, you might want to consider not using the version in the device label. It can be confusing.

OldPro · June 8, 2023, 4:12pm

No need to apologize for being pedantic. I don’t consider your responses pedantic at all. I’m a mechanical engineer and used to be a developer, so being precise was my career. I appreciate your time and precision!

I apologize if I seemed to have changed the requirements during our discussion. If they appear to have changed, then it’s my fault for not communicating properly. I sometimes find it hard to communicate precisely over event-initiated programs, especially because I don’t live with ST every day, but touch it only occasionally. You’ve helped my understanding of triggering events and bounding constraint pre-conditions a lot.

You understand the general requirement: I want the living room lights to go on if the living room gets dark in the afternoon.

I have a routine that turns the LR lights on every day 55 minutes before sunset regardless of lux. So I want LR lights to go on if the room gets dark between 1 pm and 57 minutes before sunset. I ended that requirement at 57 minutes before sunset so I don’t overlap with the every day routine that turns the lights on 55 minutes before sunset.

(Also note I just changed from 250 lux to 100 lux after reviewing the lux sensor illuminance history data)

So I have the virtual switch (vSw) and three routines (R1, R2, R3):
• R1 turns vSw on at 1 pm.
• R2 turns vSw off at 57 minutes before sunset.

Together, R1 plus R2 create the time window 1:00 pm to 57 minutes before sunset.

• R3 is shown below. “vSwitch is On” is the pre-condition. The Illuminance trigger happens only once per hour when the Multisensor reports illuminance, but that’s fine. I don’t need to turn the lights on the instant the room goes below 100 lux.

h0ckeysk8er · June 8, 2023, 4:58pm

OldPro:

Thanks again.

That’s helpful info about Scenes still being run in the cloud (I didn’t know that). The Aeotec Multisensor nominally reports the Lux reading every hour (actual is 59 mins), so there is no need for immediate execution. That means I can use a scene. But, per your suggestion, I just changed the routine to control four lights directly rather than use a scene.

When I first set the system up five years ago, I vaguely recall there was some reason I had to set vSwitch to off just after midnight. But your idea to turn it off at sunset makes sense — it is only on during the time window 1 pm-sunset.

I have another routine that turns on living room lights everyday at sunset -55 min (before sunset). I want to avoid a change of light level at sunset -55 if the Low Lux routine has already turned the lights on. To assure that, I just set the LR lights to “turn on” in both routines rather than use a dimmer setting and the low lux time window ends at sunset -57 minutes (so it expires just before the every-day routine turns the LR lights on).

Does “turn on” mean “turn on to the last used brightness level” or “turn on to 100%”?

“Turn on” can mean different things depending on how the driver for a device is written and what settings are available for the device. In general in the new architecture, simply setting the dimmer level will turn it on at whatever level you choose. In some drivers, you can deselect the On action and just set the dim level and that will cause the light to come on. Again, depending on the device and driver, selecting On and setting a dim level will cause the light to come on at the last (or in some cased default) level and then adjust to the new dim level. That can be somewhat jarring to have a light come on at 100% and then immediately dim down.

The GE/Jasco driver I’m using for my dimmers has the ability to set a default dim level which I adjust depending on the time or day/night. At night, I have a few that come on at 1% for motion and 100% if you push the button. During the day, motion is disabled and the default dim level is 100%.

h0ckeysk8er · June 8, 2023, 5:02pm

OldPro:

No need to apologize for being pedantic. I don’t consider your responses pedantic at all. I’m a mechanical engineer and used to be a developer, so being precise was my career. I appreciate your time and precision!

I apologize if I seemed to have changed the requirements during our discussion. If they appear to have changed, then it’s my fault for not communicating properly. I sometimes find it hard to communicate precisely over event-initiated programs, especially because I don’t live with ST every day, but touch it only occasionally. You’ve helped my understanding of triggering events and bounding constraint pre-conditions a lot.

You understand the general requirement: I want the living room lights to go on if the living room gets dark in the afternoon.

I have a routine that turns the LR lights on every day 55 minutes before sunset regardless of lux. So I want LR lights to go on if the room gets dark between 1 pm and 57 minutes before sunset. I ended that requirement at 57 minutes before sunset so I don’t overlap with the every day routine that turns the lights on 55 minutes before sunset.

(Also note I just changed from 250 lux to 100 lux after reviewing the lux sensor illuminance history data)

So I have the virtual switch (vSw) and three routines (R1, R2, R3):
• R1 turns vSw on at 1 pm.
• R2 turns vSw off at 57 minutes before sunset.

Together, R1 plus R2 create the time window 1:00 pm to 57 minutes before sunset.

• R3 is shown below. “vSwitch is On” is the pre-condition. The Illuminance trigger happens only once per hour when the Multisensor reports illuminance, but that’s fine. I don’t need to turn the lights on the instant the room goes below 100 lux.

Another option instead of turning the vSwitch off at -57 before sunset would be to check if the light(s) is already on as a pre-condition in your “Turn on the lights -57 before sunset” Routine. Basically, if the lights are already on, then they don’t need to be turned on again. Conversely, you could have a check in your Lux <100 Routine to check for the light(s) being off as a pre-condition.

OldPro · June 8, 2023, 8:48pm

Yes, I’ve had that problem and it’s really annoying. I’m using all Jasco products manufactured by GE or Honeywell. The LR lights are plugged into Jasco/Honeywell plug-in dimmer switch modules and it doesn’t look like they have been upgraded to Edge drivers yet (if the IDE is still accurate). Should I continue waiting for the driver upgrade or do it myself?

h0ckeysk8er · June 8, 2023, 9:12pm

Whether you want to migrate them yourselves is really a question of how many you have and how many Routines would be affected. I ended up doing all of them myself back in Dec or Jan and I have over 40 switches/dimmers/motion dimmers/outlets.

I’m also using community developed drivers from @philh30 that offer more settings and capabilities than the stock Edge drivers.

[ST Edge] Driver for GE/Jasco Z-Wave Motion Switches and Dimmers - 24770, 26931, 26932, 26933

[ST Edge] Driver for GE/Jasco/Honeywell Z-Wave Switches, Dimmers, Fans, Outlets, and Plug-Ins

OldPro · June 13, 2023, 5:19pm

Bruce, the Low-Lux routine works, BUT I discovered that the transition to low lux (15 lux) must occur AFTER 1 pm. If I enter the 1 pm to sunset period with illuminance (lux) already BELOW the 15 lux threshold, the lights will not go on.

I started off with a low lux threshold around 40 and found the lights would not turn on during cloudy, dark days because the daytime high lux value was always below the 40 lux threshold. To get the routine to reliably turn on every day when the room got dark, I had to set the low lux threshold at a low enough point to ensure I would enter the 1 pm to sunset period with lux higher than the threshold. But, by setting such a low threshold, on sunny days, the lights turn on later in the day than I like.

Is there a way to create logic such that:

When the 1 pm to sunset period starts (at 1 pm) AND lux level is already <= threshold, turn lights on immediately at 1 pm.
OR
When the 1 pm to sunset period starts (at 1 pm) AND lux level goes <= threshold during that time period, turn lights on.

The second #2 part of that logic works fine. But the first #1 part does not work.

Here’s the routine:

Here are the daily high values of illuminance in the living room:

And here is a chart of illuminance reading (in lux) from June 4 to June 12 (red line ~15 lux):

Topic		Replies	Views
Automations with time period like "Midnight to Sunrise" in new app? SmartThings (Samsung Connect) migration2020	11	1980	November 11, 2020
Period choices Features & Feedback	14	562	October 11, 2023
IFTTT Period of Time? Automation Ideas	6	603	August 3, 2019
Sunset to Sunrise Automation SmartApps & Automations	1	533	October 1, 2020
New App Automation Periods Day/Night Sunrise / Sunset iOS	1	369	December 5, 2020

Bug in Routine with Period of Time based on Sunset?

Related topics