Hi, I’m very new to HA and any coding to be honest (apart from PLC ladder logic) and I’ve been trying to get a repeat automation working for a while now, but to no luck.
Firstly, I made the automation I wanted in the UI tool, which works fine, I think went into automations.yaml to try and modify it to the notes about repeat. I’ve played about with the while function in desperation but no luck either. My Code is as follows
- id: '1596207397810'
alias: fridge door alarm test
description: ''
trigger:
- entity_id: binary_sensor.garage_fridge_door_sensor
for: 00:00:03
platform: state
to: 'on'
condition: []
action:
repeat:
sequence:
- data:
entity_id: media_player.dan_cave_speaker
message: fridge still open
service: tts.google_translate_say
- delay:
seconds: 3
until:
- condition: state
entity_id: binary_sensor.garage_fridge_door_sensor
state: 'off'
The automation will work for 1 loop, and 1 loop only. I’ve also attached the config errors I get when I try to use the repeat. The errors are only there when I try to add in the repeat sequence, otherwise it’s a valid configuration. Can anybody please point to what I might be doing wrong?
I know the error message is a bit cryptic, but it tells you exactly where the problem is. It’s in the first action (indices start at 0), in the repeat action’s sequence section, the first action, in the data section. The real problem is you didn’t indent entity_id & message enough. It should be:
- data:
entity_id: media_player.dan_cave_speaker
message: fridge still open
service: tts.google_translate_say
And, FYI, for a service call, entity_id is treated specially. It can be aligned with “service” or be indented under “data” (or “data_template”.) It’s kind of a shortcut, because ultimately it really belongs under the data section. So if you do this:
- service: SERVICE
entity_id: ENTITY_ID
Internally it gets changed to:
- service: SERVICE
data:
entity_id: ENTITY_ID
The shortcut allows you to save one line, which adds up because calling a service is very common.
Thank you for that! That’s got rid of the configuration errors, I’m still learning about exactly how and when I need to index from what, I think I was thrown off from the fact the action will still fire so it didn’t raise any flags.
The code still doesn’t repeat, just fires the once, and I’m very unsure why now, as to me it looks in the same layout at the notes. But again, I’m a baby at coding so very possible I’ve missed something.
Code now:
- id: '1596207397810'
alias: fridge door alarm test
description: ''
trigger:
- entity_id: binary_sensor.garage_fridge_door_sensor
for: 00:00:03
platform: state
to: 'on'
condition: []
action:
repeat:
sequence:
- data:
entity_id: media_player.dan_cave_speaker
message: fridge still open
service: tts.google_translate_say
- delay:
seconds: 3
until:
- condition: state
entity_id: binary_sensor.garage_fridge_door_sensor
state: 'off'
I will go back and digest what you said about condensing the action for the service (thanks for the tip), but I don’t want to change too much while I’m still struggling with this. Any ideas why it won’t repeat? I’m on 0.113.2
The only thing that should cause it to stop is when binary_sensor.garage_fridge_door_sensor changes back to off. Looks like the automation triggers when the sensor has been on for 3 seconds, and it delays 3 seconds before the first time it gets to the until tests. Is it possible the sensor changed to off by that time? You should be able to look at the history of the sensor by looking at its “more info” window.
I’m not sure where to find the “more info”, but I can watch the states in developer tools as I’ve got it in my hand (it’s an Aqara magnetic door switch, connected via deconz). If you’re referring to the timeline thing, I can see there that it’s been open (as expected) for over 5 minutes now, and that’s right with what has physically happened with the switch.
State changes can be very fast and hard to see in the timeline if you’re not familiar with it. Maybe look in the Logbook to see if the sensor changed quickly to off and back to on???
I’ll try a test and get back to you. What version are you on? Never mind, you said 0.113.2.
Well, I just did a test using your automation (although I substituted a different action for the service call because I don’t have that media player.) I faked the sensor using the Developer Tools STATES page. When I set the sensor to on the automation triggered three seconds later and ran until I set the sensor to off. It did the same every time I changed the sensor accordingly.
Are you getting any errors that is causing the automation run to abort?
Well changing the state that way of a real entity will be overwritten the next time it updates itself.
If you don’t mind trying another experiment, change the automation to trigger on, and check, a non-existent binary_sensor. (Maybe just remove a letter on the end or something, or use binary_sensor.test.) Make sure you change it in both the trigger and until parts. Then reload the automation, and then go back to the STATES page, enter that entity_id at the top (manually), enter on for the state, then click SET STATE. Wait to see if the automation triggers and whether or not it continues to run.
If it does stop, then change the state of that fake entity to off, and then back to on. Does it run once again? Or do you get a warning about the automation already running?
That runs how I’d expect! Apart from the the speaker adding % in a few times (which I’ve seen is known issue somewhere) I can toggle it back and to with no issues! Is that pointing to a problem with the sensor? Or debounce i.e door needs to be closed for 1 second to make the until true? As I’m typing I realize it’s certainly worth trying.
No problem. So, yes, it does seem to point to an issue with that sensor. FWIW, in cases like these, it’s helpful to have a way to see the nitty gritty details of what’s going on. One way to do that is to look in home-assistant.log. Adding the following (at least temporarily) to configuration.yaml can help:
logger:
default: info
logs:
homeassistant.core: debug
That will cause a lot more messages to be written to the log file. Of particular help in this type of scenario are the state_changed events. If you had the above you could see exactly what was happening to the state of that sensor between the time the automation was triggered and it got to the until part.
Brilliant, I will get that added in, you’re right, if I saw it changing as it did, even a half wit like me would have figured it out. Thanks again for your help, I’ve learnt a lot today!
