Automations with time period like "Midnight to Sunrise" in new app?

Is this possible to do, if so how… I don’t see any obvious way in the current time period specification options, but might have missed it.

This is one limitation preventing me from converting several of my existing SmartLighting apps over to automations.

I would also like to be able to start a period at a specific time and end it at Sunrise/Sunset, e.g. 2am to “Sunrise”. That flexibility would cover the midnight case in a more general manner.

I’m not an expert like a lot here, but I see what you mean. Only thing I see is Period of Time and that seems to be limited to 60 minutes before/after sunrise/sunset.

With that said, I know you can do it in webCoRE.

1 Like

Yeah, but that would be too easy :grin:

I’d like to convert all existing SmartLighting apps over to the new automations if possible, else just leave them in SmartLighting. The fewer WC dependencies I add during this migration should reduce the effort on the next big one.

1 Like

I dont know if you can do it in a single automations logic but you could potentially use pairs of automations. One to kick things off at say sunrise and the other to stop at sunset. Similar for 2am to sunrise etc. Clunkly but should work (and may need virtual switches to help if its a very complicated automation).

I would guess that he’s trying to use the time period in the IF condition, such as “IF the time is between midnight and sunrise, and a motion sensor trips, THEN turn on a security light and send a notification” or something to that effect. Not sure that you could accomplish that with two routines.

The UI sucks because it looks like you can choose “Period of time”, then select Start Time and set it to midnight (on the Time tab) and then select End Time and set it to Sunrise (on the Day Tab), but if you click on the Day or Night tabs it automatically switches both the Start and End Time to be of the same type: Time, Day, or Night.

For a period of time, the Start Time and End Time should be independent types. You should be able to start at midnight and end at sunrise; but you cannot mix and match.

That UI is buggy for other reasons too… like it shows Day is sunset to sunset (instead of sunrise to sunset) and it shows Night is sunrise to sunrise (instead of sunset to sunrise).

@blake.arnold @Lars

2 Likes

A virtual switch would work for this scenario. An automation to set the virtual switch to true for the time period. Then an automation for “if motion AND virtual switch = TRUE then action”.

The scenarios need to be thought-through though.

As @jamesdvb guessed above, I am using the period to look for motion events within the period to trigger actions. I also agree with all the comments on the UI sucking for these settings, and being buggy if not unnecessarily confusing. If only you could select “specific time”/“day”/“night” independently for start and end times for the period that would allow what I want to accompish.

I can now see how to solve this with a virtual switch. That means using IDE to create the switch, then two automations to set/clear, and then a 3rd automation for the motion trigger/action – leave it to Samsung developers to take something possible with a single automation (in SmartLighting) before and move that to 3 automatons + more effort in the new app. I wonder if virtual switches will even be supported after the groovy sunset… oh well that’s a concern for another day. For now I think I’ll just leave these few “period” based automations in SmartLighting, since that still works fine.

Thanks everyone for the hints!

1 Like

Are these not locally operating devices? Because for such devices Smart Lighting runs locally. Automations do not.

There’s a mix of device types. I wasn’t aware automations were only cloud based though, good to know. For some reason I had the impression automations were preferred given its native to the new app, but I don’t recall where I got that from. Most of my automations are fine being cloud-based, but I’ll review the list for any I might want to move back.

Yes, we all thought that a new mechanism might deliver on the “more will run locally in the future” promise from 5 years ago.