Automation #2 doesn’t work because you can’t use a template within a time trigger. You could consider using a template trigger instead, or use a different trigger and use the trigger above as a condition.
Can I change that into condition:time trigger?
Or I make another input boelan as state trigger (ON/OFF) and use the trigger in the condition: time after (but first I compare to now.time() to my trigger? So I’m still get “time” trigger
I’ve changed code to this, but at certain time, message not appeared.
I must have a comparison between sensor.alarm_time.state and current time, if it same then do the action.
But how to tell this?
Your condition state can’t have to: on statement. Also it has to be condition: state too
The whole other automation seems right to me. Just let the entire minute of your alarm_time to expire to check if automation triggers.
With your automation, It will trigger only when you change your input_boolean to ‘on’, and will check the condition only for one time.
Also, in your value_template, if you are using single quotes inside template, use double quotes on the outside part of the template.
"{% if is_state('sensor.alarm_time', 'now.time().strftime('%H:%M')') %} true {% endif %}"
Thanks for your correction, I will try that
Actually I want make a timer for light that can switch on & switch off at user defined time.
So maybe I will add condition for “before” time.
Is it enough for that to check only one time like your said? Or I must add another condition?
I am exactly interested in this trigger but have problem with now.time().strftime("%H:%M"). For debugging when I use it as sensor it show time when hass is started BUT then it is not updated anymore.
sensor:
- platform: template
sensors:
time_current:
friendly_name: Current time
value_template: “{{now.time().strftime(’%H:%M’) }}”
So that trigger is fired when I set sliders to time when hass started BUT I would like it to check continuously if current time is equal to time set by sliders.
Yes, it depends on slider changes because the platform is “template”.
So the solution for me is to keep that platform in time, checking every certain moment and do the action.
@MatoKafkac it’s probably not updating for some other reason, I had the same feeling until all my sensors were fixed. AFAIK there shouldn’t be a need to check every state change, you could either use a template as a trigger, which will eat your CPU by checking every state change (cc @cyber.mocca), or you could enable the logger and set it to DEBUG, which will print out in STDOUT more infos about the components/sensors, so not only state changes from the core. If your shell is configured for colors, you’ll see it in blue. An easy way is to try fish – the friendly interactive shell, which will enable colors by default, among other good stuff for noobs (%
Also didn’t want to rework my input_sliders that are using seconds, so using:
@thefrenchmatt I like your 2 input slider solution much better than what I came up:)
#value_template: "{% if states.input_slider.time_lamp_off_hour.state | int < 10 %}0{% endif %}{{ states.input_slider.time_lamp_off_hour.state | int }}:{% if states.input_slider.time_lamp_off_minute.state | int < 10 %}0{% endif %}{{ states.input_slider.time_lamp_off_minute.state | int }}"
According my automation problem with time triggering this is one solution
As for your turn_on timing: you could add a condition that your sensor is not to its defaults, and/or use another automation to turn_on ‘automation.lamp_turn_on_timing’…
I’m insisting on not using template triggers because each state change will be checked against it… To translate it into my own experience: since I removed many of those triggers, hass got more responsive and before I just couldn’t understood why adding sensor templates was slowing everything wayyy down.
I’m also stuck on finding a flexible ‘state trigger’ automation with input_slider, it was working for me a while back but I then had to resort to scenes (~30 for each group of lights) so that I could simply use the to_state as a part of my scene name… it worked quite well, especially using the same input_slider set low states (I used values 10->100 to set brightness 1->9, and the rest to go up to 254~255, all in increments of 10).
But having that many scenes just seemed silly.
I have to mention I tried AppDaemon but I would have to modify the examples (as I’m mainly interested in using the motion sensors I have, and maybe later BLE triangulation) to move away from using constants as an off delay.
AppDaemon is nice because you can easily define and reproduce automations, but to get it to be flexible, you do have to learn python the hard way.
If I find something working, I’ll sure report back here.
EDIT
Well, reporting back and it was just a matter of using |int instead of |int|round() !