# X% of the time after sunset until sunrise

How can I set the lighting time of the plants to always be e.g. 10% of the time after sunset regardless of whether it is summer or winter?

do you have the attributes of ânext_risingâ & ânext_settingâ in your states for the sun.sun entity?

If you do (I think you shouldâŚ) then you can use the following to find out the time to turn off the lights:

``````{{ (as_timestamp(state_attr('sun.sun', 'next_setting')) + ((as_timestamp(state_attr('sun.sun', 'next_setting')) - as_timestamp(state_attr('sun.sun', 'next_rising')) ) / 10)) |timestamp_custom('%H:%M') }}
``````

you can improve the readability by breaking it up into chunks with setting variables:

``````{% set next_set_timestamp = as_timestamp(state_attr('sun.sun', 'next_setting')) %}
{% set next_rise_timestamp = as_timestamp(state_attr('sun.sun', 'next_rising')) %}
{% set time_diff_seconds = next_set_timestamp - next_rise_timestamp %}
{% set ten_percent_seconds = time_diff_seconds / 10 %}
{% set time_off = next_set_timestamp + ten_percent_seconds %}
{{ time_off | timestamp_custom('%H:%M') }}
``````

Given that procession changes the times day by day (and itâs why heâs calculating this)
You are calculating the length of the night but using sunrise today and sunset today
Ie they are not brackets for any given night, is that OK ?

Edit: You could get round this by doing the calculation at noon

Iâll have to look a bit deeper but I thought that the ânext_â sunrise or sunset changed after the one for today. So at noon the next sunset would be today and next sunrise would be for tomorrow. Unless thatâs what you are sayingâŚthenâŚnever mind.

But any time of the day you will always get a next sunrise that is after the next sunset. If itâs today or tomorrow it doesnât really matter since you are just trying to get ten percent of time between them. Even if sunrise or sunset changed by a couple of minutes then 10% of that will be insignificant. I donât think the plants will mind the lights being on or off a few seconds longer or shorter.

Unless Iâm misunderstanding somethingâŚ

In summer there is a longer day and in winter there is a shorter day, I want to provide the plants with reasonably stable lighting regardless of the length of the day, so they always have about the same amount of light.

The percentage is good because even though it is inaccurate, it is enough for this purpose.

I set it as a trigger for this template. Thank you.

Yes âŚ
And I know Iâm splitting hairs (the greatest time delta of sunrise, one day to the next for me has been about 2.5 minutes at 52 degrees latitude (it gets larger, the further from the equator))
But âŚ So say today the sunrise was at 09:00 (letâs make the numbers easy) so the sun rose at 09:00 and at 09:00:01 the ânext sunriseâ is shown as (say) 08:58 tommorow (to illustrate the point, here weâll be heading towards the winter solstice). This is the output of the standard sun component (sun2 or 'advanced sun (both courtesy of Phil) both maintain for the whole day)
So between sun rise and sun set you will have the period for the next night. As you are looking at todayâs sunset and tomorrowâs sunrise.
At night you will be looking at the the ânot day gapâ which is arbitrary. (not a real period)

@cyberlight I realise this may work for you and a couple of minutes is probably irrelevant but for someone as ocd as I appear to be itâs not an answer. (Sorry)
Iâm more interested in you use case however. We had a guy who (as I recall, but I am getting older ) wanted his chickens to have a minimum of 10 hours of âlightâ but he wanted his light to be off (save power) as long as possible so used actual daylight when he could. So if sunrise to sunset was < 10 hours, he wanted the light to come on at sunset and stay on till 10 hours after âthatâ morningâs sunrise.
But we also had another guy who did time lapse photography on his plants (a project with his daughters ) and thus to maintain light levels (both for plant growth and the photography) had the lights come on for 12 hours centered around solar midnight.
I guess I just donât understand how 10% into the night gives you a stable period of light ???

I think what youâre saying is you want the plants to get the same number of hours of light every day, regardless of season. I think youâre also saying that youâre only using artificial lights to augment the sun (i.e. the only turn on when the sun goes down).

If thatâs the case I think you just need 4 automations and none of this 10% business.

Make an input_boolean called plant_lights.

Make an automation that turns the input_boolean on at sunrise.

Make another automation that turns the input_boolean off after it has been on for 10 hours (or however many hours you want light for the plants).

Make another automation that turns on the lights at sunset if the input_boolean is on.

Make another automation that turns off the lights when the input_boolean turns off.

1 Like
``````{% set night_length = as_timestamp(state_attr('sun.sun', 'next_setting')) - as_timestamp(state_attr('sun.sun', 'next_rising')) %}
{% set range = 1.0 - ((night_length - as_timestamp('7:47:43')) / (as_timestamp('16:46:39')-as_timestamp('7:47:43'))) %}
{% set time_off = as_timestamp(state_attr('sun.sun', 'next_setting')) + (0.25 * as_timestamp('7:47:43')) * range %}
{{ time_off | timestamp_custom('%H:%M') }}
``````

I try this way, calculate the length of the night, count the current fraction in the range from 0 to 1 for the duration of the night, then add a maximum of about 2 hours until sunset.

I was thinking something similar, but yours is better.

You could combine the âboolean offâ and âlights offâ automation into one, for a total of three automations. You could combine them all with some fancy templating/choose blocks etc. but that strikes me as more complex and error prone.

I always assume that the person has determined what the use case is and has worked out that the question to be answered is what they actually want.

Of course if the parameters of the question change then the answer will (probablyâŚ) change.

And of course we could be more exact in calculating the â10%â time but the template is already a bit complicated and itâs âclose enoughâ.

If we assume that the exact â10% of timeâ is what is needed then the only other way to get better precision is to create another sensor that stores the exact time based on todayâs sun data (calculated before todayâs sunset as you mentioned) then use that sensor to trigger the lights off automation.

It really depends on the OPâs needs.

All of that saidâŚI did find an error in the template.

That template above works as is if you are calculating it based on todays sunset and sunrise (IOW, where sunrise is after sunset). But if you try to use it after sunset then the calculation is off.

Here is a better working template (i thinkâŚ):

``````{% set next_set_timestamp = as_timestamp(state_attr('sun.sun', 'next_setting')) %}
{% set next_rise_timestamp = as_timestamp(state_attr('sun.sun', 'next_rising')) %}
{% set time_diff_seconds = (24* 3600) - (next_set_timestamp - next_rise_timestamp) %}
{% set ten_percent_seconds = time_diff_seconds / 10 %}
{% set time_off = next_set_timestamp + ten_percent_seconds %}
{{ time_off | timestamp_custom('%H:%M') }}
``````

EDIT: copy error from my testingâŚ

But that one will only work as a trigger to turn off the lights at a certain time after todays sunset.

1 Like

Weâll soon have you as ocd as I am

OR

You could just make it into a template trigger : -

``````{% set next_set_timestamp = as_timestamp(state_attr('sun.sun', 'next_setting')) %}
{% set next_rise_timestamp = as_timestamp(state_attr('sun.sun', 'next_rising')) %}
{% set time_diff_seconds = (24* 3600) - (next_set_timestamp - next_rise_timestamp) %}
{% set ten_percent_seconds = time_diff_seconds / 10 %}
{% set time_off = next_set_timestamp + ten_percent_seconds %}
{{ (time_off | timestamp_custom('%H:%M', false) == states('sensor.time') }}
``````
1 Like