Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Keep manual lights manual when changing sleep mode #1060

Open
rhtenhove opened this issue Oct 24, 2024 · 4 comments
Open

Keep manual lights manual when changing sleep mode #1060

rhtenhove opened this issue Oct 24, 2024 · 4 comments

Comments

@rhtenhove
Copy link

rhtenhove commented Oct 24, 2024

self.manager.reset(*self.lights)

This line here causes my wake-up light transition to fail after 5 minutes because it starts at 6:55 and I've set the sleep mode to turn off at 7:00.

Undesired alternatives

You could say I should then move the wake-up light or sleep mode time, however this time may change at some point, causing overlap once more. More so as I have a housemate with a different routine. Finally because the wake-up light starts before I stopped my own "sleep mode" :-)

Another option would be to not disable sleep mode when in a wake-up transition, but that's more complexity and management to make sure sleep mode gets disabled later.

A better way

My main point is I find it counterintuitive to reset manual mode when toggling sleep mode, as to me those two are unrelated. Sleep mode I assume to be part of adapting lights, so if light adaptation is disabled for some reason, there should also not be any sleep adaptation.

Furthermore, it's quite a lot easier to do this yourself in an automation, as there's a service call to reset manual mode for all switches whenever some automation enables or disables sleep mode. It's much more complex to manage the state of manual mode when sleep mode switches, and having to reset it yourself, more so after the sleep mode has already sent some command to transition the light to sleep colors.

Making everybody happy would probably be to have some configuration switch for this.

WDYT?

@djurny
Copy link

djurny commented Oct 24, 2024

Hi there,
Just to understand your situation:

  1. Do you have a wake-up routine for light X while it is in sleep mode? And during the wake-up routine for light X, you disable sleep mode on light X?
  2. Or. you have a wake-up light X and a light Y in sleep mode. During wake-up routine of light X you disable sleep mode on light Y?
  3. Or perhaps something else?

In case of 1 it might be difficult to retain manual mode after going into sleep mode for a light. It would have to save the light settings of before it went into sleep mode? Or retain the setting of sleep mode itself? Also, how would you control the light while it's in sleep mode?
Thanks,
Groetjes,

@rhtenhove
Copy link
Author

rhtenhove commented Oct 25, 2024

Hello 👋

In my case my bedroom light is set to Adapting, so whenever I turn it on, it will have the ideal color and brightness. It is also set to the default take_over_control: true, so when I change it manually it stays there, until I turn it off.

When my wake-up routine starts, it sends a command to transition from 1% red to 100% 4000K over 900 seconds. This works perfectly fine, and is seen as control being taken over, so AL does not interfere.

However, if during that time the sleep mode of the AL switch where my bedroom light changes (in this case goes off), the control that was taken over is reset and it starts adapting the light again, canceling the transition.

This does not make sense to me, as manual control means manual control, whatever AL decides it should be because it's noon, evening, sleep time, whatever, I've "taken over control", leave it be, as explained in the docs.

I can circumvent this by disabling the AL switch before the wake-up routine, but then I would need to turn it on again at some point in the future. Not after the routine, as the wake up light needs to stay bright until I decide to roll out of bed.
Perhaps when I switch the light off again, but that would need an extra step for each light switch where this problem applies.

Another example is if one room decides to stay up later with a "taken over" reading light setting, but sleep mode is turned on because it's, well, sleep time. Then that light would need to be turned to sleep mode after being turned off, requiring more logic for that button as well.

What would make much more sense to me is that sleep mode does not interfere with manual mode. If someone does need sleep mode to reset manual control, that just takes a single action call, in that single sleep-mode enabler routine, which targets all AL switches and removes sleep mode.

Groetjes terug

@djurny
Copy link

djurny commented Oct 25, 2024

Hi there,
So to recap:

  1. You have light X.
  2. All AL switches are enabled so it's adapting brightness & colour.
  3. At some point in time - before H:M - sleep_mode is turned on.
  4. At time H:M you start controlling light X outside of AL, which add light X to the manual_control list (and generates a manual_control event).
  5. At some point in time - after H:M but before H:M + 00:15 - sleep_mode is turned off.
  6. Turning off sleep_mode also defeats manual_control and AL starts adapting as if nothing happened.

Does that capture your case?

If so, you could consider setting the sleep_transition to 00:15. This would effectively make (disabling) sleep_mode your wake up routine. Not sure how AL does this internally though, if this is fed straight to light X, this might not work. Not all lights accept or do what you expect with a large transition time.
You could also consider - as you mention - to listen to the manual_control event, and disable AL upon reception. Your wake up routine can simply check if AL is disabled and enable it if needed.

Other route would be to change AL and have it not leave sleep_mode or 'reset'ing the logic as you showed.

Not sure if this helps?
Groetjes,

@rhtenhove
Copy link
Author

I realize I've not been clear in that I've already implemented a workaround, but that is far from satisfactory as it adds lots of complication. As you may notice in your proposals is that these are all quite complicated and if circumstances change, would need more maintenance.

So for now I've just removed the mentioned line from my installation, and things are working beautifully and simple now.

As I still find the behavior strange (and undocumented) I've created a PR in #1063

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants