Super simple automation that turns off the Patio Lights at Sunrise. The Trace Timeline logs show a runtime from 10-20 seconds every morning.
When I manually run the automation, the average is under 1 second.
While the automation happens regardless and the delay means absolutely nothing, I’m just curious why this happens when the system runs the automation vs when I manually run it.
on trigger
You have some oddness with your automation, post it please.
you should not see <unknown entity>
The trace timeline reports that the first thing the automation attempts to do is turn off an unknown entity. In other words, it’s referencing an entity that no longer exists.
I suggest you fix that by replacing the reference to a non-existent entity with one that does exist.
If you need more help, post the automation in YAML format.
I took waaaay too long to type this; petro has already said the same thing with fewer words.
Thanks for the quick response. The automation was created in the GUI
Automation in yaml format.
alias: Patio Lights off at Sunrise
description: ""
trigger:
- platform: sun
event: sunrise
offset: 0
condition: []
action:
- type: turn_off
device_id: ded0c90ae5a499830cd2aa1ef5a0bd87
entity_id: 2feb7e665cb131207c6f36d5e2cdee87
domain: light
- type: turn_off
device_id: fc266ee9dcc359f0e32cdcacd450b369
entity_id: d86d59d19291db0673b5256c7196db8f
domain: light
mode: single
Change it to this:
alias: Patio Lights off at Sunrise
description: ""
trigger:
- platform: sun
event: sunrise
offset: 0
condition: []
action:
- service: light.turn_off
target:
entity_id:
- light.patio_center_lights_2
- light.in_wall_toggle_dimmer_qfsw_500s
mode: single
I changed the info and set the automation to run at a specific time. (assuming “sunrise” wasn’t part of the issue)
It ran faster for sure, and I don’t see an unknown entities.
Now the questions lol, Why would the GUI use device/entities ID’s over the name? (Besides the obvious of automations not breaking when you change a name.) Is this a known bug or something I can fix on my side?
Because you (unknowingly) asked it to. You chose a Device action; you could have chosen the entity-based Light > Turn Off service call.
Glad to hear it fixed the problem.
Please consider marking my post above with the Solution tag. It will automatically place a check-mark next to the topic’s title which signals to other users that this topic has been resolved. This helps users find answers to similar questions.
For more information about the Solution tag, refer to guideline 21 in the FAQ.
As for your question, when choosing an action in the Automation Editor it defaults to highlighting a Device Action. This type of action was created to solve a problem with a service call action. If you rename an entity’s entity_id existing service calls in your automations continue to refer to the entity by its old entity_id. Naturally this causes existing service calls to fail.
A Device Action is supposed to avoid this problem by assigning an unchangeable device_id to a physical device. You can freely change its entity_id but it won’t break existing Device Actions because they continue to use the unchangeable device_id.
That’s the theory but in practice something went wrong on your system and your Device Actions failed by referencing a non-existent entity.
Thank you all, this helped me understand a bit more regarding the issues. and the fact that I need to be more diligent in my naming conventions to make more sense to the grouping and organization of the devices…
Thanks again!
automations are happening so much faster and uniform after changing everything from device/entity_id to entity name, and here I thought it was a ZigBee issue with the delays…
example: the original automations took 37 seconds to complete; the shades would all move in random times. With the change, it’s all running under 5 seconds with the shades moving simultaneously
alias: Shut it down
sequence:
- device_id: 65f1d0a7e5fd6315be6f6a5550eea9e9
domain: cover
entity_id: c70114f8517fb79e4920647d7312b3bc
type: close
- device_id: 2c0c6de8e761d98c966ac5ea409e072e
domain: cover
entity_id: 8df9daa3be4a9e44c554c58a04d7cb37
type: close
- device_id: 320a49a951e12c7ca890daa367e644f3
domain: cover
entity_id: 196ab2b66efb9a127039b205a620299f
type: close
- device_id: 728fd3f6326c689adf1a5405209ffc61
domain: cover
entity_id: b0104d1b81ae2d04a19b9dd269300c2f
type: close
- device_id: f466fd6ad72c1636d7d2d9b2287446cb
domain: cover
entity_id: cc297033febd3c643b4f3b93543c5814
type: close
- device_id: 9ad68ae7ba858f0b64566f9d9be92c63
domain: cover
entity_id: 1f8fa95f4ee4895bb613135cc91ec748
type: close
- device_id: fb2a3e98f755deded3672da3b0003550
domain: cover
entity_id: 988a24d5bcac70f6167c920d20cde7ef
type: close
- device_id: 77912ecb751a00abf800870264e316cf
domain: cover
entity_id: a62fc02dcb837a2b25f3e7c62e97c4f8
type: close
mode: parallel
icon: mdi:roller-shade
max: 10
is now
alias: Shut it down
sequence:
- service: cover.close_cover
metadata: {}
data: {}
target:
entity_id:
- cover.kitchen_shades_cover
- cover.sink_shades_cover
- cover.family_room_right_shades_cover
- cover.family_room_left_shades_cover
- cover.dinning_room_shades_cover
- cover.office_shade_cover
- cover.master_shades_left_cover
- cover.master_shades_right_cover
mode: parallel
max: 10
icon: mdi:roller-shade
Well that’s just because you’re using 1 service call, which performs the action for all entities at the same time. Where as a list of service calls or device actions, performs them in sequence.
I’m starting to understand lol. It’s a learning curve for sure in regards to getting started.
When you create a new automation from GUI, the first thing you see in the list is Device. Naturally that’s what someone is going to click… but after the discussion here and the numerous issues with “unknown entity” on searches; you would think someone would remove that option or at least not give it a description of “Great way to start”
anyways, I’m rambling on. Thanks again!
