That can be due to the copy paste on the board. The following never shows any errors
sudo -u homeassistant /srv/homeassistant/homeassistant_venv/bin/hass --script check_config
Testing configuration at /home/homeassistant/.homeassistantok, it just looked suspicious.
It has just triggered. The only i idea i have now - is that it is saturday which is not included in the rules. And i’m running on a different than english locale for the system. Wonder how can i check for the day naming in the system? Guess it is not
- mon
- tueI like this topic a lot. I added a feature request here:
I think a simple way to input time would be a great addition and simplification for all these configurations posted here…
Edit:
And another related automation using the sunset event time, if someone is interested:
So I’ve been struggling madly to be able to set a custom time for turning on a device. I’ve tried every method so for I found, and even made some new approaches myself. Still I’ve not been able to get it to work.
#This is the sensor I store the time on (it shows up in correct format in the UI):
sensor:
- platform: template
sensors:
car_heat_time:
friendly_name: Tid bilvärme
value_template: '{{ "%0.02d:%0.02d" | format(states("input_slider.timmar") | int, states("input_slider.minuter") | int) }}'
#Three examples
#Does trigger, but time is not editable by user, which I do not want.
automation:
- alias: 'Bilvärme timer'
trigger:
platform: time
hours: 17
minutes: 30
action:
service: switch.turn_on
entity_id: switch.aeotec_dsc18103_micro_smart_switch_2nd_edition_switch_5_0
#Does not trigger
automation:
- alias: 'Bilvärme timer'
trigger:
platform: template
value_template: '{{ (now().strftime("%s") | int | timestamp_custom("%H:%M")) == states.sensor.car_heat_time.state }}'
action:
service: switch.turn_on
entity_id: switch.aeotec_dsc18103_micro_smart_switch_2nd_edition_switch_5_0
#Does not trigger (error in format, not sure why)
automation:
- alias: 'Bilvärme timer'
trigger:
platform: time
after: '{{states.sensor.car_heat_time.state }}'
action:
service: switch.turn_on
entity_id: switch.aeotec_dsc18103_micro_smart_switch_2nd_edition_switch_5_0
#Does not trigger
automation:
- alias: 'Bilvärme timer'
trigger:
platform: template
value_template: '{{ (now().strftime("%s") | int | timestamp_custom("%H:%M")) == states.sensor.car_heat_time.state
}}'
action:
service: switch.turn_on
entity_id: switch.aeotec_dsc18103_micro_smart_switch_2nd_edition_switch_5_0
Even in a condition when comparing current time with ‘car_heat_time’ does not work. I would guess it is something with the formatting, but everything gets so hard when I don’t know how to troubleshoot and debug YAML.
I know C++ very well, but I just cannot grasp Python and YAML.
Hi,
check my config on the link the post above.
You are looking for:
automation:
- alias: 'auto_heat_on'
initial_state: True
trigger:
- platform: time
minutes: '/5'
seconds: 14
condition:
- condition: template
value_template: '{{ (now().strftime("%s") | int | timestamp_custom("%H:%M")) == states.sensor.auto_heat_time.state }}'
action:
- service: climate.set_temperature
data:
entity_id: climate.ethermostaat
temperature: 19
- alias: 'auto_heat_off'
initial_state: True
trigger:
- platform: time
minutes: '/5'
seconds: 14
condition:
- condition: template
value_template: '{{ ((now().strftime("%s") | int - (states("input_slider.auto_heat_duration") | int) * 60) | timestamp_custom("%H:%M")) == states.sensor.auto_heat_time.state }}'
action:
- service: climate.set_away_mode
data:
entity_id: climate.ethermostaat
away_mode: True
The trigger can be adapted to ‘/1’ minutes depending on the resolution of your minutes input.
EDIT: if you are handy in programming, AppDeamon might be easier to wrap your head around. See for example this project: Appdaemon lightschedule it uses a csv file as input for a complete light schedule.
Hey Danny, thanks for your help!
But I forgot to mention I tried this approach too, and it also did not work. I think I reached a dead end.
Can you share the rest of the config? Did you load the time component?
sensor:
- platform: time_date
display_options:
- 'time'You know it struck me as I was reading this, that a couple of input_select controls could work well to select the alarm clock time. Does anyone know off hand if they can be positioned next to each other instead of on top of each other in the display?
Can you try the following automation rule? And check also in the logbook (left side) if the automation ruled triggered.
automation:
- alias: 'Bilvärme timer'
initial_state: True
trigger:
- platform: time
minutes: '/1'
seconds: 0
condition:
- condition: template
value_template: '{{ (now().strftime("%s") | int | timestamp_custom("%H:%M")) == states.car_heat_time.state }}'
action:
- service: switch.turn_on
data:
entity_id: switch.aeotec_dsc18103_micro_smart_switch_2nd_edition_switch_5_0
- service: notify.notify
data:
message: 'I triggered.'
1 Like
The rule is to break the failure which is in a current quantum state (hence everything is the fault).
How do you break this rule and opening the cats box? You do this by posting a message for help in a forum.
The problem is the timezone, actually I’ve tested it but in the wrong direction. I did turn on the timer just to see if works after night. I did set the time to 06:16, and the timezone I’m living in is Europe/Stockholm. The timer triggered one hour too early, in the logbook the switch was turned on at 05:16.
I did try it again, and the trigger is activated 1 hour too early.
So it seems even though I’ve the timezone setup correctly in configuration file, it still is wrong.
Update:
I did add a field showing the current time (this is the time I do compare with in the conditions when triggering the action). The strange thing is that this field is showing current local time correctly, even though the trigger is activated one hour too early:
- platform: template
sensors:
current_time:
friendly_name: Nuvarande tid
value_template: '{{ "%0.02d:%0.02d" | format(now().strftime("%-H") | int, now().strftime("%-M") | int) }}'
Update 2:
I solved the problem, though I’m not sure if this is a bug I have avoided in homeassistant.
What I did was to compare the values of. current_time with car_heat_time. It seems if compare the values from now() directly does not work (hence UTC is returned). If setting a value in homeassistant from now(), homeassistant will then, in a later state, convert this value to local time.
These two configuration files now works, but I’m unsure which ones is the most reliable approach.
Which is most reliable of setting trigger to:
- poll every minute and then compare the times and button states
or - activate from a value_template comparison, and then check condition of button states.
The second method feels cleaner code-wise.
config.yaml (3.6 KB)
config2.yaml (3.5 KB)
1 Like
Nice that you found your issue. Good catch with showing the current time as custom sensor. But weird I am also on the same non UTC timezone and I last time I checked, it worked for me…
On which version are you?
You do not need the extra switch actually. You can directly switch the automation rule itself on and off. So the additional switch is just duplicating this behaviour. Then the second option is even cleaner in the configuration file. It gets triggered just as often I think (every time the sensor for the time changes, so every minute).
Did you also try using the timestamp_custom function? Can you check what a sensor with the template
'{{ (now().strftime("%s") | int | timestamp_custom("%H:%M")) }}'
shows? If that is the correct time, then the automated rule should work. Otherwise it’s a bug…
By the way a good way to test and debug your rules quickly is using the template developers feature, left side second last icon.
There you can add your code to test and see what it would show. I also tested my rules this way.
And I still think that the timestamp_custom should just work :P. As you can see it shows 14:46, while it was 13:46 UTC time.
Thanks for your tips @daenny.
Tried running the command:
‘{{ (now().strftime("%s") | int | timestamp_custom("%H:%M")) }}’
in the template developers UI.
It was giving me a time of: 23:20
While the local time was: 22:20
UTC time was : 21:20
Going in via ssh to the server and typing ‘date’ in the terminal gave me an UTC time of: 21:20.
So there is something strange going on for sure. Maybe homeassistant is using two different timezones?
Edit:
Version of homeassistant I’m using is: 0.35.3
Version of python3 is: 3.4.2
Yeah that is indeed weird. That would mean that somewhere your timezone settings are messed up.
You can verify your timezone:
'{{ (now().strftime("%s") | int | timestamp_custom("%H:%M %z%Z")) }}'
'{{ (now().strftime("%s") | int | timestamp_local }}'
'{{ (now().strftime("%Z") ) }}'
But I guess these would show for you +0200 as your timezone. Which is incorrect. Did you try setting a different timezone, with the same time, i.e. Europe/Amsterdam?
And can you run the date command with showing the timezone on your server via ssh:
date +'%T %z %Z'Your code in the UI shows:
‘14:25 +0100CET’
‘2017-01-08 14:25:58’
‘CET’
While the code in ssh shows:
12:26:02 +0000 UTC
Weird indeed.
This is really weird indeed. So the timezone is set correctly, and the UTC time is correct on your server machine. But the time is still wrong…
But you say that:
now().strftime("%H:%M")
shows the correct time? So I assume that the Homeassistant internal UTC clock is off by one hour.
You can confirm my suspicion by running:
{{ now().strftime("%s") | int | timestamp_utc }}Yeah, these two lines do show the correct time:
{{ now().strftime("%H:%M") }}
{{ now().strftime("%s") | int | timestamp_utc }}
Edit:
Summing it up again:
1. '{{ (now().strftime("%s") | int | timestamp_custom("%H:%M %z%Z")) }}'
2. '{{ (now().strftime("%s") | int | timestamp_local()) }}'
3. '{{ (now().strftime("%Z") ) }}'
4. {{ now().strftime("%s") | int | timestamp_utc }}
5. {{now().strftime("%H:%M")}}
6. $ TZ='Europe/Stockholm' date //SSH terminal
7. $ date //SSH terminal
1. '13:38 +0100CET'
2. '2017-01-11 13:38:45'
3. 'CET'
4. 2017-01-11 12:38:46
5. 12:38
6. Wed 11 Jan 12:38:49 CET 2017
7. Wed 11 Jan 11:38:51 UTC 2017