Automation doesnt work with all attributes

[maddi67]

Hello, i try do discharge my alarmsystem wit unlocking YALE LINUS 2 with keypad.
When unlocking with Remote, the automation works. If “Keypad” instead of “Remote” is placed in the automation below it doesnt work.
Automation:

alias: Alarmanlage_durch_Keypad_SEITENTÜR_ausschalten
  description: ''
  triggers:
  - trigger: state
    entity_id:
    - lock.seitentuer
    to:
    - opening
    - unlocking
  conditions:
  - condition: template
    value_template: '{{states.lock.seitentuer.attributes.changed_by == "Remote" }}'
  actions:
  - type: turn_off
    device_id: 513c5bb25dee55611ca6f1569d803c36
    entity_id: 7043e052e571122f27140aeac218c6b4
    domain: switch
  mode: single
- id: '1764784811606'

Does anybody know why ?

Thank you !!!

[Hellis81]

Did you write this automation yourself?
It seems you have indentation errors.

Make sure you use the GUI until you are comfortable with the yaml

[maddi67]

Oh, ok, sorry i didn´t take care here with indentation, think it is ok in the sourcecode…
Thank you ! So that isn´t the reason for malfunction…
any other ideas ?

[Hellis81]

Then you need to look in the trace what is happening.

[maddi67]

The problem seems to be located in the missing translation of the trigger states.
All triggers listed in German language work properly when selected for Automation. In case you choose a trigger listed in english the Automation won’t start, and activities of the lock are declared as never happend, what is definately wrong.

The pulldown menu of selectable triggers looks like this:

• locking
• opening
• unlocking
• sobald HAUSTUER geöffnet ist
• sobald HAUSTUER aufgeschlossen ist
• jammed
• sobald HAUSTUER abgeschlossen ist

How can this be fixed ?

Thank you for help me.

[Edwin_D]

Locking and opening are intermediate states between open and closed. Your lock may not have them, or may not always use them. It may also be why your lock integration has chosen not to translate them.

[maddi67]

Thanks for reply so fast.

The lock uses all of them and show each of it in
Status of attributes. I think the problem is the missed translation in integration.
Is it possible to fix it or is this only possible to be done by yale ?

[Edwin_D]

Automations only use untranslated values in yaml. The translations are only shown in the GUI but never actually used as such. So what you say, only the translated ones work, will not be true if the translation is in your yaml. It could apear so in the automation editor though.

How are you sure the values are used? Do you see them come by when the lock is operated? the only safe way to see what values can be in the yaml is in developer tools, on the states tab. Those are the “real” values.

If your automation does not work, the first step is to look at the automation trace after it should have worked. Can you show us what is there, or are there noe at the times they should have been?

[maddi67]

Hello Edwin,

if i insert the following:

{{states.lock.seitentuer }}

in the Template-Editor, the result is:

<template TemplateState(<state lock.seitentuer=locked; changed_by=Manual, friendly_name=SEITENTUER, supported_features=1 @ 2025-12-07T16:39:07.061720+01:00>)>

When driving the lock the string behind lock.seitentür=

displays what the lock is doing, for example when it is locked and i unlock it the string changes from

locked → unlocking → unlocked

or when it is unlocked and i open the
the door by pulling the lock latch via the app the string changes from

unlocked → opening → open

for example.

In order to use this for my automation i need access to the strings “unlocking” and “opening”, but i dont know how to extract them to use as entity for example. That is my problem…

[Edwin_D]

Those are the exact strings you need to put in the automation. That means your trigger is fine. Which brings me back to one of the first questions: What does the automation trace say?

It is on the top right of the automation, and it shows you what happened when the automation triggered. Most likely the condition failed, but you will be able to see why. Though not the problem here, In templates it is best to use functions like:

value_template: "{{ is_state_attr('lock.seitentuer', 'changed_by', 'Remote') }}"

Or your acrion is broken, but that is hard to tell from device actions. It is best you avoid them:

Why and how to avoid device_ids in automations and scripts

Background When you start writing automations, a device trigger seems the obvious choice. Everybody knows what a device is and it comes at the top of the UI dropdown list. [Screenshot from 2025-11-20 18-37-55] It works… but it is not a the best way to start because it is storing up problems for the future. Far better to use an entity, with state or numeric_state. This topic is part of the community-driven cookbook where you can find other topics you might be interested in or might like to …

[maddi67]

Hi Edwin,

the following is what brings the solution:

value_template: “{{ is_state(‘lock.seitentuer’, ‘unlocking’) }}”

In all Traces befor the trigger has never been avtivated. Dont know why. The way with the GUI never worked…

Thank you very much !!!

[Edwin_D]

Doing so would reduce the automation to the equivalent of this:

alias: Alarmanlage_durch_Keypad_SEITENTÜR_ausschalten
  description: ''
  triggers:
  - trigger: state
    entity_id:
    - lock.seitentuer
    to:
    - unlocking
  conditions: []
  actions:
  - type: turn_off
    device_id: 513c5bb25dee55611ca6f1569d803c36
    entity_id: 7043e052e571122f27140aeac218c6b4
    domain: switch
  mode: single
- id: '1764784811606'

[maddi67]

@Edwin_D

value_template: "{{ is_state_attr('lock.seitentuer', 'changed_by', 'Remote') }}"

Hi Edwin,

that would be the solution ! Thank you very much for help me !
Now only the condition “changed by Keypad” is missing in the automation…
But i´ll try to complete it…

You made my happy for a day

[Edwin_D]

The condition is fine, just as yours was. This is just better protected against errors. The problem is the trigger still. Looking at my matter lock, the attribute changed_by is only set when the final state is reached, not while the lock is in transition. So if your lock is like mine, then the trigger should be “open”, ‘locked’ or ‘unlocked’ because only then changed_by is set to what caused it. Not when the state is locking, unlocking or opening.

[maddi67]

:)) oh my god…you’re right…
Next problem…

I’ll have to find out how to handle my question
“If the lock is unlocking or opening if it is triggered by Keypad”. Only inbthis case the Alarmsystem shoud be shut down.

It will work some day…

[Edwin_D]

Unless hou can look into the future, you can’t. What you can do is trigger op open, locked or unlocked. You are thinking too hard, because the trigger only fires on change.

If you want to protect against locks being unavailable, what you need as the trigger is:

  - trigger: state
    entity_id:
    - lock.seitentuer
    from:
    - 'opening'
    - 'unlocking'
    to:
    - 'open'
    - 'unlockied'

For the condition you do not need a te plate by the way:

  - condition: state
    entity_id: lock.seitentuer
    attribute: changed_by
    state: Remote