Thank you ❤

[stefanvictora]

Thank you ❤

[stefanvictora]

Thank you for your feedback on the new version, I appreciate it. And I'm glad that most of the new behavior is useful for your use cases. If you find any other problems, feel free to create a new issue or continue in this thread.

Regarding fast turn offs and ons using dumb wall switches: I also observed this behavior in my tests, and this seems to be a limitation of the current Philips Hue bridges, as it does not send any turned-on events until it first detects the light being turned-off or becoming unreachable. While the bridge can detect a light becoming physically available rather quickly (~4 seconds), it takes up to 2 minutes for the bridge to detect lights becoming physically unreachable. This is why fast turn offs and ons are unfortunately not recognized by the bridge and in consequence by the scheduler.

This 2 minute delay was also the reason why Hue Scheduler originally had the confirm logic implemented, as in those minutes the light still appears to the bridge as reachable, which caused some state updates from the scheduler to be lost.

While it's possible to still use the old version for potentially faster updates, I can also think of a way to include better support for such cases in future versions. As the scheduler could easily detect which lights are regularly turned-off physically (there is a special zigbee_connectivity event with status disconnected sent by the bridge after those 2 minutes), and maybe adapt the scheduling logic for those lights in some way.

And thanks for opening a new issue regarding Ikea Tradfri bulbs! Let's continue the discussion about their support over there.

[stefanvictora]

Thank you very much for your kind message! It means a lot to hear that my little side project is just as useful to others as it is for myself. I was in the same shoes when I looked for some automations that would support my use cases, especially for dumb wall switches.

The current implementation still has some limitations and sometimes causes a bit of delay when physically turning lights back on, but I'm still quite happy with it in my current day to day usage. What I read is that v2 of the Hue API now supports event-based notifications of e.g. lights turning on, which could maybe fix some of the issues, but I didn't find time yet to play with it, as it introduced some major changes on how it works.

And you are right, I haven't really promoted this project anywhere yet, as I originally wanted to add some features first, like a GUI, but then work got the best of me -- but I'm happy to hear that it's already useful as it is :-)

Regarding the idea of conditional states: Since it's been some time that I wrote that road map, how would you imagine working those in your use cases? After some quick brainstorming, this is how I would implement this feature right now:

Office  sunrise  ct:5000
Office  sunset  ct:3000
Office  sunset+90  ct:2000  conditional:true

In this not yet supported example the conditional property (name not final) would cause the last state to only be active if the light or group is still in the same state as in the second state. This means it would only change to 2000K if and only if it currently still has a color temperature of 3000K, meaning it has not been manually changed yet.

I would most likely set the global default value for this property to false (while also making it configurable). So in this example the lights would still be set to 5000 in the next morning, even if they have been manually adjusted the night before. This would prevent the schedule to get out of sync indefinitely, but still allow for scenarios where the tool does not override manual adjustments.

Is this how you would use such feature? Or are there some different use cases you have in mind?

[cswrd]

I appreciate talking about this feature together. Your approach is very flexible and fits into the configuration concept quite well. I have some notes on that:

1. What would happen if the light gets turned off after state 1 with a dumb wall switch and turned back on after state 3? It seems like it would skip this state because the previous 2nd state was not applied (still in state 1 when turned on), even though no manual light change was made (besides turning on/off the light which shouldn't interfer with the feature, right?). If so, it wouldn't work as I would like it to behave.
2. Quite similarly: could this interfer with the per bulb setting in the hue app where you can define the power on behaviour, e.g. use a specific brightness or keep the previous state?
3. Personally, I'd expect manual changes to be considered superior over automated schedules by default. But I do understand that a conditional attribute that defaults to true would cause out of sync issues. Some workarounds to have true as default with improved reliability: require at least 1 schedule entry to be "unconditional" or one is just choosen to be unconditional automatically as a fall back.

I haven't take a look into any technical details like a hue API and the source code, yet. So my alternative approach might be hard or impossible to achieve. But my favorite solution from a sole usage perspective would be that manual changes would be kept up until the light is turned off (completly or standby with a smart switch/app). So it would really be based only on the recognition of a manual change (scheduling disabled) and the power off recognition (scheduling re-enabled).

Even if I would set the same light state during manual changes it would get applied at that point in time if it had been scheduled coincidentally, thus fulfilling the conditional criteria for the next schedule entry as suggested in your approach it'd be still ignored in this approach. Turning the lights back on would yield to getting in sync with the scheduler like it does now by default all the time.

From the little information I read so far I could image that recognizing the on/off changes in a sufficient reliable way is not possible (e.g. when turned off/on too fast). As long as the scheduler could be re-enabled within a couple of minutes and especially over night everything would be fine for me.

What I do like about this power off/on approach is that one doesn't need to remember when manual changes would be overwritten and when not. Instead of scheduling this behaviour statically, it would become triggerable at any time for everyone. I assume that family members and guests that change the light states would experience this as very intuitive, as their settings would never be changed after they made some manual changes as long as the light is still on. Otherwise, it might happen their controlled lights would change its state for no reason at random times from their perspective depending on the configuration.

[stefanvictora]

Thank you very much for your insightful comment, I also appreciate this exchange and your point of views. And I have to say I really like your dynamic approach, as it doesn't require any additional configuration and should be easy to understand even for other members of the household. I looked into this approach over the last couple of days and already managed to get a version of this feature running. This required the integration of the new v2 API, which allows us to get almost instantly notified of any changes including powering lights off and on. Some notes on dumb wall switches later.

Right now the changed approach works like this:

1. When a light is turned on (detected via the new event stream) the scheduler now always enforces the currently expected state of the light
2. Before each further state changes, the scheduler compares the current light state with the state that was last successfully applied
3. Should such a change be detected, the scheduler is disabled for the current and all future states of this light (until an on-event is received, which implicitly requires that the light was turned off in-between)

This approach should solve the first note you mentioned, as the scheduler always enforces the current state when the light is turned on. So it doesn't matter if a state was skipped. The tracking of manual changes is only active if a light is continuously on over multiple defined states. I also added the new force:true state property, to selectively disable the modification tracking for a single state, and globally with the additional global command line property --disable-user-modification-tracking.

Regarding your second note: I'm not sure I full understand what your expected outcome would be when using a specific power on behavior. Would you expect that e.g. the predefined power on brightness is kept, or that it should also be overridden by the scheduler?

The new behavior of the scheduler will override any predefined properties with the one defined in the scheduled state, when the light is powered on. But if you e.g. just schedule a certain color, but no brightness, then the scheduler would keep the specified power on brightness, and just modify the color -- as it already did previously.

You can find the updated version and its full changelog here: https://github.com/stefanvictora/hue-scheduler/releases/tag/v0.8.0. I have been running multiple iterations of the new approach for a few days now inside my own home, and it works as I expect it to. But there might still be some issues with the new approach that I have not noticed yet, so any feedback is very welcome.

Regarding dumb wall switches:

While the new event stream allows us to almost instantly react to lights being turned on via the app or Hue switches, physically turned on lights are only detected by the bridge and therefore the scheduler with a short delay. In my tests it is around 3-4 seconds until the bridge notices the light being physically available again.

The previous logic of the scheduler handled unreachable lights by simply retying to send the same requests with a certain delay until the lights become reachable again. This at times caused rather quick updates to physically turned on lights, but often similarly suffered from at times even longer delays, as in bigger setups the large number of retries for multiple lights sometimes caused the rate limiter to become active.

So the decision to remove the old retry logic was made to not only simplify the overall scheduling logic but also keeps the overall resource consumption to a minimum. Furthermore, the reliability and adjustment speeds for lights controlled via smart switches also improved.

I hope this change in regards to dumb wall switches still suits your use cases.

[cswrd]

I just deployed the new version at home and it looks very good. I like the way of configuration and the added options.

Regarding the power on behaviour we talked about: it was just a note to think about. I was curious if it could interfer with each other (wasn't specific to the new behaviour). As the hue native light restart behaviour has no clue about being embedded into a hue scheduler system I think hue scheduler should always win. As far as I can see this is the case. So that's just fine.

btw a very nice side effect of the new behaviour is that one can change the light manually right after it has been scheduled. Manual changes won't be overwritten by the next schedule and additionally won't be by the retry behaviour anymore, too. yay :)

I can confirm the delay of 3-4 seconds for dumb wall switches. It's a good tradeoff compared to the added ability of changing light scenes, manually. Maybe they reduce the delay further with a new bridge firmware. At my home there is just one room where a fast reaction time is superior: the stairwell. None of us applies changes there. So maybe I run the previous hue scheduler version just for that room.

Other observations so far - none of them is a blocker in my setup:

1. It seems like fast turn offs and ons using dumb wall switches are not recognized resulting in the manual light change not being "cleared". Thus the current or upcoming schedules won't be applied. I didn't figure out how fast is too fast. Probably, these 2 minutes (?) it might take for hue to recognize a light as physically turned off. Good thing is it will work the next day or any other longer off time or a forced schedule.
2. I had been running 5 hue scheduler instances, concurrently. This doesn't seem possible, anymore due to too many request rejections. I optimized my setup to 3 schedulers (probably could also use just 2). fyi: I am running multiple hue scheduler instances to be compatible with Ikea Tradfri bulbs. I could open another issue to explain why if you're interested. edit: after some testing I've noticed the compatibility got worse. Created another issue for that.

Thank you so much!