I would like some of my automations to be prevented during a period while I am most likely asleep.
Some should just not happen, like my hall light should not scwitch on automatically when modtoin is detected.
Some should be delayed like my blinds opening after sun rise, these should still rise, for example in summer I do not want the light flooding in at 4am.
i have tried date time helpers which set a time but the templating to compare dates and times is not simple by any stretch of the imagination, I have in fact not yet succeeded.
Also a card in Lovelace that lets me set a time period (sometimes I want to change the start or end time) would be great, a clockface with two handles that let me drag the time period out to cover some of the 24 hour period would be great.
Any suggestions for this are much appreciated.
Thank you and regards,
Chris.
Create a Template Binary Sensor that reports on during the hours when you wish to receive notifications and off during quiet hours. Let’s say it’s called binary_sensor.awake.
All of your automations can use a condition to check the state of binary_sensor.awake to determine if they should, or should not, send a notification.
EDIT
Here’s a simple example that reports on when the current hour is between 07:00 and 23:00, inclusively.
# binary_sensor:
- platform: template
sensors:
awake:
friendly_name: 'Awake'
value_template: "{{ 7 <= now().hour <= 23 }}"
You can make that fancier by creating two input_datetime entities, one to represent start time and the other for the end time. The template would use the two input_datetime entities to determine the time range as opposed to hard-coded values.
Thank you, that does give me part of what I want.
I still need to work out the “trigger on the later event of sunrise or wake up” feature.
Also I am trying to use input_datetime entities and can not use >= against them as I can not quite work out how to get at the hour value. And if I set a time to 06:30 the comparison against .hour becomes an issue.
This seems very complex for something that an event driven system should do out of the box.
For the Do Not Disturb feature, you could create an input_boolean called “Do Not Disturb”. Use this input_boolean as a condition in your automations and scripts (ie condition would be “false”, as in, Do Not Disturb is not enabled). You can use input_datetimes and additional automations to automatically start and stop the Do Not Disturb period, but you also have the option of manually enabling and disabling in the UI (mid afternoon nap!) or with other automations (eg “do not enable Do Not Disturb if a movie is playing in the evening”). You could even create a logging system that instead of sending an alert during Do Not Disturb, you can record these events to the Logbook and receive a summary later on when Do Not Disturb is disabled. And your automation for your hallway light can have a condition that the Do Not Disturb input_boolean is “false”.
As for the issue of “trigger on the later event of sunrise or wake up”, there are a few ways of doing this. I have my blinds in my kitchen set to open on motion in the morning, but only after sunrise. The way I’ve chosen to implement this is to use motion as the trigger (which happens frequently), and then to decide whether to open the blinds based on various conditions:
- alias: "Open blinds on motion in the morning"
action:
- service: cover.open_cover
data:
entity_id: cover.kitchen
trigger:
platform: state
entity_id: binary_sensor.motion_kitchen
to: 'on'
condition:
condition: and
conditions:
- condition: time
after: '05:00:00'
before: '16:00:00'
- condition: state
entity_id: cover.kitchen
state: 'closed'
- condition: state
entity_id: group.all_devices
state: 'home'
- condition: state
entity_id: sun.sun
state: 'above_horizon'
You could of course include the Do Not Disturb input_boolean as a condition here instead of the time condition.
If you don’t want motion as a trigger, you could instead have a time_pattern trigger that triggers every say 5 minutes and uses the conditions of (1) Do Not Disturb input_boolean is false, and (2) entity sun.sun is “above_horizon”.
I think there are a number of ways of reliably getting what you want, but personally I would avoid using the input_datetimes as direct triggers themselves as it can get complicated and triggers can be missed in some scenarios.
Thank you for that very detailed response. I like those ideas and will likely use something like that.
Is there a document that explains the issues with input.datetime resulting in possible missed triggers etc? I want to make sure I do not fall into any traps.
Thank you,
Chris.
I don’t think there’s any documentation etc, and of course you can use input.datetime as a trigger in your automations. I use it frequently, for example when I want to trigger the heating system.
The issue for me is that an input.datetime is a “single trigger” that only happens once in the day, and if for some reason it doesn’t trigger, perhaps because one of the conditions wasn’t satisfied (like in my example above; someone being home, the blinds already being closed etc) then it will never trigger again. There might be an unexpected scenario where the wifi is being spotty, and therefore our phones are not detected, and group.all_devices changes to not_home, and therefore the automation doesn’t trigger. It’s probably because I don’t have a background in coding so the automation isn’t “robust”; it doesn’t catch all of the possible scenarios.
It may end up being more reliable to have the trigger based on a motion sensor; instead of just triggering once in the morning, the automation now has a trigger every time someone passes the sensor - there are now far more opportunities for the intended action to occur, in case one of the conditions has a momentary blip or you have unexpectedly conflicting conditions.
A good example; I used to have a nighttime automation that would attempt to automatically set the alarm when we go to bed. Initially I tried a trigger and set of conditions that when there was no movement in the downstairs binary sensors after a certain time, it would set the alarm. This actually worked very well. However, we would occasionally need to unset the alarm in the middle of the night if we needed to open an upstairs window and check on the cars below, but the design of this automation meant that the alarm would not again automatically set because there was no change to the motion sensors downstairs. So I modified the trigger to be a 15 minute time_pattern that checked these conditions throughout the night, and now the alarm would automatically set again even if we manually disarmed it at an unusual time (which is definitely what we want). This may not be the best way of doing it, but it makes the automation more reliable.
Understood, that makes sense to me.
Thank you.
The only reason a Template Trigger employing an input_datetime would fail to trigger at the appointed time is if Home Assistant isn’t running at that time (it’s off or in the middle of a restart). Every other reason you described has nothing to do with the trigger but with flaws in the conditional logic.
That’s not necessarily due to “don’t have a background in coding” but that we often underestimate the complexity of a given challenge and our automation logic requires more sophistication than we initially assumed. Various real-world quirks reveal themselves and the automation logic must evolve to adapt to them.
FWIW, I avoid the Time Pattern Trigger. It has its uses but more often than not l see people employing it like a blunt instrument. A more efficient technique is to determine the distinct events that occur and base the triggers on their state-changes.
Yep, better explained than I could myself!
I use time_pattern as a fix for issues that arise over time; like the odd time when the hot water timer somehow gets cleared but the switch remains on. time_pattern allows me to check for anomalies like “the hot water switch is on but there’s no timer running”. It’s rare that it would happen, but it’s a way of catching the “bugs” in my implementation.