I have completed, tested, and am running a set of time sensors that let me do various automations based on the current length of day, length of night, evening hours, etc. This approach will self adjust to the seasonal lengthening/shortening of the day/night cycle.
I feel like this would be useful for the community, but don’t know where to post them. Can someone tell me if where they would best be posted? Maybe as examples in the documentation?
In these I have used the following assumptions (easily modified) to achieve the “fuzzy time”:
Evening is the time between sunset and “night”
“Night” is the next sunrise (following day) minus 8 hours - this is basically sleep hours
Evening is split in halves - early evening and late evening
I use these to allow a group of brighter lighting during early evening and dimmer during late evening. Also I have outside lights on during evening and turn them off at bed time (“night”). It then turns on the night lights.
# Time to sunrise - will adjust for "rollover" at the time of sunrise
# in other words, not affected by the current day vs next sunrise day
hrs_to_sunrise:
friendly_name: "Hours to Sunrise"
value_template: "{{ ((as_timestamp(state_attr('sun.sun','next_rising')) - as_timestamp(now()))/3600) | round(3) }}"
# Calculate the length of night from next sunset to next sunrise. This will possibly be a few seconds
# off for the current day due to the difference in sunset between two days, but for most purposes
# this will be "lost in the round-off".
# first the if statement looks at the day for the next sunrise and the next sunset. If they are not the same, it must be before sunset
# So take the next rising and subtract the next setting.
# Otherwise they are the same day so do the same calculation but subtract 24 hrs to adjust the day.
hrs_of_night:
friendly_name: "Hours of night"
value_template: "{% if (as_timestamp(state_attr('sun.sun','next_setting')) > (as_timestamp(state_attr('sun.sun','next_rising')))) -%}
{{ (((as_timestamp(state_attr('sun.sun','next_rising')) - as_timestamp(state_attr('sun.sun','next_setting')))/3600) + 24) | round(3) }}
{%- else -%}
{{ ((as_timestamp(state_attr('sun.sun','next_rising')) - as_timestamp(state_attr('sun.sun','next_setting')))/3600) | round(3) }}
{%- endif %}"
# By extension the hours of daylight is 24 minus night
hrs_of_daylight:
friendly_name: "Hours of daylight"
value_template: "{{ 24 - (states('sensor.hrs_of_night') | float) }}"
# Use 8 hrs until sunrise as "Night" flag and calculate mid-point of sunset until night as "late_eve"
# This will be in hours, not a specific time since the ending time is the same as the start of late_eve
# and the starting time is sunset.
early_eve:
friendly_name: "Hours of early evening"
value_template: "{{ (((states('sensor.hrs_of_night') | float) - 8) / 2) | round(3) }}"
# Time of next "start of late evening". This is used as a value trigger in automations.
late_eve_time:
friendly_name: "Time of late evening"
value_template: "{{ ((as_timestamp(states.sun.sun.attributes.next_setting) | float ) + ((states('sensor.early_eve')) | float) * 3600) | timestamp_custom('%m/%d %I:%M %p') }}"
# Time of next "start of night". This is used as a value trigger in automations.
night_time:
friendly_name: "Time of bedtime"
value_template: "{{ ((as_timestamp(states.sun.sun.attributes.next_setting) | float ) + ((states('sensor.early_eve')) | float) * 7200) | timestamp_custom('%m/%d %I:%M %p') }}"
The above sensor code works fine, but is a bit less than pretty. If there is a better way to accomplish the same thing or to code in a more Home Assistant format, please add any helpful suggestions.
I also modified a couple of the stock template sensors to have a date-time format I prefer:
No reason. I wish I could say there was some grand overriding plan, but it was that these functions (sensors) just evolved with my needs and existing automations. Plus, since I wanted the values to be dependent on sunset and sunrise I needed to develop some intermediate values to get to the end result.
I also did not want to mess with my existing automations much because I am not running a test instance plus a production one. Some of these expressions have weird “logic traps” due to having different values for sunset twice a day and sunrise twice a day. Testing it piecemeal was just easier for me.
If I were doing it in Python, I would have more likely done it the way you suggest. However I am a total noob with jinja2 syntax and it was much easier to test each calculation as I developed the various independent pieces.
not here, I’ve been using these template sensors (have a few other versions) and never understood why this tod sensor got accepted in the first place, especially considering the efforts @pnbruckner did to get his enhanced sun component accepted and was rejected/ignored, and that is of true added value to core HA
Ignore this post! I have a strange copy/paste issue with my computer ; ! Apologies to @Mariusthvdb
…
Your code has a typo at the beginning of part_of_day - it needs one space indentation and something else in icon_template but fixed it by chance so I don’t know… This works in my sensors.yaml. Thanks! Deleted Code to avoid people using the wrong one
well, though this post is well over a year old, it is still correct… dont know what you mean by the one space indentation? the original seems completely fine as it is. Also the icon_template is without an error…
only thing you could do is take out the quotes on the friendly_name, they are not needed
