adaptive-lighting icon indicating copy to clipboard operation
adaptive-lighting copied to clipboard

Allow sunrise_time/sunset_time to be set programmatically

Open dchawisher opened this issue 4 years ago • 6 comments

@basnijholt, thanks for making this great add-on. I have one feature request that we've discussed on the forum; at your suggestion, I'm bringing it here.

Because sunrise_time is an option of the adaptive_lighting component, rather than a value stored in an entity, and because it accepts only strings, not templates, it is impossible to set sunrise_time automatically. Setting sunrise_time automatically is important for several reasons. One reason, discussed in this Hassio forum thread, is that adaptive_lighting and wake-up lighting don't work well together.

Another, which I believe was discussed in a feature request for the circadian_lighting addon, is that people who live at certain extreme latitudes may wish to set maximum sunrise_time or minimum sunset_time values to ensure that they get at least a certain amount of simulated sunlight each day, even when their real day is very short.

I see three ways of accomplishing this:

  • Allow sunrise_time and sunset_time to accept template values.
  • Move sunrise_time and sunset_time into an entity, which would let them be set programmatically.
  • Create a set_schedule service that, when called, sets sunrise_time or sunset_time.

dchawisher avatar Dec 19 '20 15:12 dchawisher

I've started to look into allowing sunrise_time and sunset_time to be templates but realized this is harder than I thought.

For example, because a template value might change at any moment, we have to watch for it and be prepared to reset the entire switch once it changes. I don't think this will be worth my effort because it requires a pretty large rewrite.

On the other hand, I have an issue with setting the sunrise time using a service call if the value is also defined in your YAML config. Because then you'll have two different definitions of your times. Upon a Home Assistant restart it would not always be obvious which ones to choose. I see two options:

  1. Removing YAML support and have a service to set the sunrise_time and sunset_time
  2. Removing the sunrise_time and sunset_time options and only allowing it to be set through a service

If others can chime in and argue whether one option is better than the other, that is appreciated!

basnijholt avatar Dec 19 '20 19:12 basnijholt

I agree with the need to programmatically change these values. Right now, sunset occurs at 4:30pm in my location, and as a result, this component dims my rooms very early in my day. During the winter months, I'd like to move that time later, and during the summer months, I'm happy to use the actual sunset time. I was also thinking that templates for these values would be helpful, but appreciate the concerns that were raised. To that end, I actually like the suggestion of optionally providing an entity name in the config, whose value would rue used as input. For example, I could provide the ID of a sensor entity that contains a datetime string, or an integer for an offset value.

I suspect the core devs would frown on this, as it would likely bypass schema validations. But it seems simpler to me. If it has to be service calls, I suppose I could just wrap those in automations that periodically change the values. Either way, any method for providing this capability is much appreciated!

MizterB avatar Jan 14 '21 20:01 MizterB

Hey @MizterB,

the limiting of shifts in winter/summer has been discussed in https://github.com/basnijholt/adaptive-lighting/issues/97, so you might want to join the discussion there :)

RubenKelevra avatar Aug 01 '21 21:08 RubenKelevra

I agree @dchawisher I like to combine adaptive lighting with Sleep As Android to wake me up. This needs a way to programmatically owerwrite the next sunrise time by a service call to the component.

The same goes for sunsets, where you might want to overwrite them programmatically as well for one day, without going into the settings of adaptive lighting.

RubenKelevra avatar Aug 01 '21 21:08 RubenKelevra

Just throwing in my two cents, I would also like this or some semblance of this, I am actually using this for automating my greenhouse lighting as well, and having the ability to flexibly adjust the numbers via templating would be awesome.

I can see the problems that might add though, so if some easier solution pops up I am all for it.

Not that I know anything, but would it be possible to only check the sunrise_time and sunset_time at a specified time of day? That way its not something that has to be actively listened for?

FedgarLurch avatar Jan 07 '22 23:01 FedgarLurch

@FedgarLurch that's quite a funny application I haven't even thought about. Version 2 will be a big rewrite of what most of the program is doing and it will take a while until it's finished - so stuff might change a little.

Not that I know anything, but would it be possible to only check the sunrise_time and sunset_time at a specified time of day? That way its not something that has to be actively listened for?

That's not how this works. You would use a timer for such events. Those will just fire at those two times and call a function you've linked to it. So you really have to check for those times only on startup of the component, as every change will be "pushed" rather than need to be checked or pulled all the time.

RubenKelevra avatar Jan 08 '22 08:01 RubenKelevra

This is now kind of fixed thanks to the work of @Hypfer in #358.

It does not allow you to programmatically set the times but in the config instead.

Considering we now have that feature, we almost certainly won't implement what was suggested.

I have released Adaptive Lighting https://github.com/basnijholt/adaptive-lighting/releases/tag/1.2.0 which includes the change 😄

basnijholt avatar Nov 08 '22 17:11 basnijholt