Issue with hue-scheduler taking over when triggering specific scene using smart switch.

[Sepetto]

Hello,

First off, big thanks for the application and the docker container, that you have recently released. Makes setting up a whole lot easier than working with Linux services etc.

I like the functionality a lot, along with the very granular configuration options and what not. My only issue is that when I am turning on e.g. my office "gaming" scene, hue-scheduler takes over after the light is turned on and changes the temperature and brightness according to the schedule. I understand that according to the documentation this is intended behaviour and I'm fine with triggering the scene twice at which point scheduler understands that I have "taken over control" and does not trigger any brightness/temperature changes for that particular light.

Now I don't know how the API works and what is possible, but my idea would be to try and recognize if a light was turned on due to a specific scene being triggered and at that point just ignore any schedules etc. Better yet, make that an attribute per room/light so that you could configure particular lights that you want to obey a schedule even when being part of a scene.

Again, I have no idea if this is even possible, but though I'd just throw this idea out there.

Thank you, Juha

[stefanvictora]

Hi, thank you for your kind words and for opening the issue. I wasn't aware of this behavior. While you are correct that Hue Scheduler behaves as intended in such cases, it is indeed annoying to have to trigger scenes twice. I agree it would be nice to ignore turn-on events for the affected lights in such situations.

I took a quick look at the available API events that could be used for this and found a possible solution. Unfortunately, it seems this is only possible when directly connecting to the Hue Bridge or when triggering scenes via Home Assistant. I was unable to detect scenes being activated when they were triggered via the Hue Bridge (i.e. smart switch or Hue app) while Hue Scheduler was connected to Home Assistant. This seems to be a limitation of the Hue integration in Home Assistant.

I will take a closer look over the next few days on how to implement this for the supported setups and keep you posted. Thanks again for the feedback and for suggesting this improvement - it really helps make the tool better.

[Sepetto]

Hey hey,

Sorry for the late reply. It was midsummer here in Finland and I was away from home. Another difficult time for sun-based lights, as the sun never goes down...

Anyway, as for the subject. Does the smart switch send out a "activate this scene" type of call and the scene is saved (and activated) on the bridge? If it is, I guess you could detect lights being turned on after X seconds after such a call was made and ignore those for scheduling. I do application architecture myself, so I know it sounds a bit bubblegum-ish of an approach to solving this issue though =/

The Kelvin application goes around this limitation by implementing a scene that you crate in your app. Be it "kelvin kitchen" or whatever. The app recognizes the kelvin keyword and constantly updates this scene with the scheduled values for each room and light. This way, when you turn on the lights using this scene, they are always at the right brightness and temperature from the get go.

Seems like the Hue API reference guide requires a developer account. If I have some free time, I might give it a look as well and see if I could maybe come up with some ideas to help out.

-Juha

[stefanvictora]

Hi, no worries! Sounds fascinating--I haven't yet personally experienced the sun never setting. Thank you for taking the time to share your thoughtful suggestions. The approach you suggested is exactly what I was working on (see #12), and I've successfully released an initial version of this logic in v0.11.0.

In summary, Hue Scheduler now listens for "scene activated" events from either the Hue Bridge or Home Assistant. It identifies any lights or groups affected by the scene and then ignores any subsequent turn-on events for the next 5 seconds for them. Given that our observations are limited to API events, I believe this is the best approach we can take.

As already mentioned, this does not work when Hue Scheduler is connected to Home Assistant and scenes are triggered by the Hue Bridge instead of HA directly. It seems that the relevant "scene activated" events are not forwarded to the HA event stream in such cases.

Please let me know if v0.11.0 works with your setup. I'm open to further ideas. I believe there a still many cool features to implement. Updating special scenes like Kelvin also sounds interesting. Similarly, I was thinking about using scenes to control the expected schedules, e.g., "Kitchen (sunrise)", "Kitchen (09:00)", etc.. I also like to focus on creating conditional states--states that are activated only when certain conditions are met, such as other lights or devices being on or off, or when they have specific states, like a temperature above a certain level (when using Home Assistant).

Best, Stefan

[Sepetto]

It works great.

Read you reply about the new version early in the morning and never got around testing it. Came back home late at night and figured the automatic update of running containers must have run on my home server and the scene should stay on when I just walk in to the office and press the scene button of my smart remote.

And it did.

I mean if it's stupid and it works, it's not that stupid.

Wonderful work and thanks a bunch for the update to the app. Keep up the good work!

My wife is gonna be amazed when I tell her that "oh, by the way, the reason the lights work like you want them to is because I talked to this guy online". God bless the internet =D

-Juha

[Sepetto]

One more idea, that might have some value if you plan on implementing constantly updating scenes like Kelvin.

The config yaml shoud have one optional extra attribute per line "scene: XYZ " that is a string match to a scene the user has set up on their bridge (think "scheduler-livingroom", "scheduler-kitchen"). If there is a change for that scene at that point in the scheduling update (be it a schedule for another room, or the one for "kitchen" itself), it will update it thustly.

Most of the time, I assume, people would just put in the scene they want to update on all the lines per room, if they want to use the functionality, but there might be some situation where you want a particular scene to update (so update your "scene" button on the smart remote according to associated "scene: something" schedule config lines), but your room "on" button to follow another schedule.

Havent thought it quite through, but might work.

-Juha

[Sepetto]

Unfortunately I have to come back to this. After some further testing, it would seem I am an idiot.

The functionality works great and it detects when a scene has been triggered and it will not activate scheduling in those cases. However, the issue is that from the smart switch, there is no "turn lights in room on" as you can do with the phone app. When you press the smart switch power on button, it always triggers some scene, which of course in turn disables scheduling.

The only workaround I have found is to use the "scene cycle" behaviour for the smart switch on -button and have the first option to be the "last on state". This way, when you press the power button the lights turn on at their previous state, which is not a scene and the scheduling can take over.

This is a bit of an inconvenience and I'm not sure if my suggestion for the solution was such a good one after all... I can get my home setup working with the workaround I mentioned, but other users that find your app might not realize that this is what you need to do to get it working as they wish.

-Juha

[stefanvictora]

Thank you for the updates and the additional thoughts on the scene sync feature -- I will come back to that later, I have some ideas and also some questions on that. But first I would like to better understand the situation regarding the smart switches.

I don't configure my switches through the official Hue app, but rather use iConnectHue, which features some more advanced configuration options. But I just had a look at the official app, and at first I was also a bit confused on how to simply turn on my lights, without setting a scene (the default seems to be now the new day-time dependent one). But after some trying, I figured out that I could just select the "Light off" setting for the "on" button. Which is not a great name, because it does not just turn-off your lights, but also turn them on again just fine. And in my tests, this works great with hue scheduler, as it takes over normally like it did before.

Is this something that would work in your case? I only have the v2 Hue smart switches, but I think this should also be possible for the first generation.

But I agree, it could be a bit confusing for new users of the app, since the default way for those buttons seems to be scene based now.

[Sepetto]

What you described would be perfect, so I could set all the "on" buttons on my switches to default to the scheduling and have the lower "hue" button trigger scenes that I have set up.

For whatever reason though, my v2 smart switches do not work as you described. If I define the "on" button behaviour to be turning lights off, it does that, of course, but never turns on the lights again, no matter how many times I press. I also tried it via a roundabout way of setting the "on" button behaviour to be single scene and that scene is "lights off". Same result.

I will try and google if there is some documentation about this functionality and if there is perhaps some bridge -related setting that defines how the "lights off" call is handled. For now, it would seem our switches and bridge work slightly differently with no good explanation as to why.

For the time being, my workaround is setting the "on" button to be scene cycle. The scenes in the cycle are "last off state" (which leads to scheduling like I want) and "lights off". So I press once -> I get scheduling. I press twice in a row -> lights turn off.

This works perfectly fine for me, but it would be a bit nicer if the "lights off" functionality worked as you described. Easier to document and understand as well for new users.

-Juha

[stefanvictora]

This is indeed rather strange; thanks for the follow-up. I can't explain why our smart switches are behaving differently here, but I'm glad you found a workaround.

Regarding the scene sync feature: I believe it could also solve those issues and improve the overall turn-on behavior of lights. To clarify your proposal: you want to add a new optional "scene:" attribute to the configuration lines. If this attribute is present, Hue Scheduler would regularly update the scene configuration with the expected light states in the background.

With such synced scenes, we could trigger the referenced scene via a smart switch or even a motion sensor, and the lights would immediately turn on with the correct light state according to the defined schedule, rather than Hue Scheduler updating the lights after a short delay. Hue Scheduler would, of course, disable its "ignore turn-on" feature for those synced scenes, ensuring the lights continue to be updated after being turned on this way. This way, you also wouldn't need to turn your lights off and on again for Hue Scheduler to take over.

This sounds like a great idea and would solve some of the issues I have with my motion sensor in combination with Hue Scheduler.

However, I'm still a bit unsure if I fully understand your example regarding multiple different schedules and the smart switch.

Intuitively, I would implement such a feature like this: For every room or scene with an associated schedule in the configuration file, Hue Scheduler would automatically create a scene (e.g. "hue-scheduler" or another predefined name) and update it regularly in the background. This way, you wouldn't have to add the "scene:" property to each configuration line or create those scenes manually.

What do you think?

[Sepetto]

Based on what you wrote earlier, I think we are on the same page about the core functionality and how it would work. Like you said, if there is a scene that is controlled by hue-scheduler, it could be triggered by whatever you want and it would always be at the correct state in scheduling right from the moment of the light(s) being turned on.

"For every room or scene with an associated schedule in the configuration file, Hue Scheduler would automatically create a scene (e.g. "hue-scheduler" or another predefined name) and update it regularly in the background. This way, you wouldn't have to add the "scene:" property to each configuration line or create those scenes manually."

^^ I like this idea. This way you don't have to create the scene in your bridge manually for a particular light or room, because it's being handled by scheduler. After that it's up to you if you want to associate that scene to some smart switch, movement sensor etc. actions in your app of choice. You could also make it a "create_scene: true/false" -attribute per room/light configuration for those people who really don't want anything to do with scenes.

I was already thinking of how to implement it in the config file on my own, so I'll post it here anyway, although I think your suggestion would work better. My idea was to have the config work as follows:

"" scene.living_room_scene sunrise bri:80% ct:6000 tr:10s scene.living_room_scene sunrise+60 bri:100% ct:5000 interpolate:true scene.living_room_scene sunset bri:60% ct:3000 tr-before:golden_hour-20 scene.living_room_scene 23:00 bri:40% color:#FE275D tr-before:1h ""

The functionality would be exactly the way it is with rooms and single lights, but you could distinguish updates to scenes with the scene. -prefix, followed by the name of the scene. If scheduler finds a scene with that name, it will update it accordingly.

Whichever way you decide to go, I'm sure people will be happy with the new options and I think both options should also be possible to be made to be backwards compatible, so that if you don't want to use the scene updating functionality, your old config file will work just fine.

-Juha