Automation State Trigger Being Ignored

I have this simple automation set up which was created in the UI.

- id: '1678730240643'
  alias: Airlock Light
  description: ''
  trigger:
  - platform: state
    entity_id:
    - camera.airlock
    attribute: detected
    to: 'true'
    enabled: true
    for:
      hours: 0
      minutes: 0
      seconds: 0
    from: 'false'
  condition: []
  action:
  - service: light.turn_on
    data: {}
    target:
      entity_id: light.airlock
  mode: single

I have checked in the states tab and the “detected” attribute is changing to and from “true” and “false” as expected, yet the automation simply isn’t getting triggered. I’ve spend two hours trying to troubleshoot and I’m stumped. Would appreciate some help.

Thanks

Which integration are you using for this camera?

Could you please go to Developer Tools, select the tab States and then filter for camera.airlock and then share the attributes just like is there?

You can also go to Developer Tools, select the tab Templates and paste the following and then share the results?

{{ state_attr('camera.airlock', 'detected') }}
'true': {{ state_attr('camera.airlock', 'detected') == 'true' }}
true: {{ state_attr('camera.airlock', 'detected') == true }}
True: {{ state_attr('camera.airlock', 'detected') == True }}
'false': {{ state_attr('camera.airlock', 'detected') == 'false' }}
false: {{ state_attr('camera.airlock', 'detected') == false }}
False: {{ state_attr('camera.airlock', 'detected') == False }}

Hi Edward, thanks for replying.

Here are the attributes for the camera.airlock:

motion_detection: true
editable: false
enabled: true
connected: true
detected: false
alerted: false
has_ptz: false
alerts_enabled: false
attribution: Data provided by ispyconnect.com
icon: mdi:camcorder
friendly_name: Airlock
supported_features: 1

As previously mentioned, when I walk in front of the camera, the detected attribute DOES change to “true”. So the integration is working correctly. But for interest, this camera is connected through the Agent DVR integration.

What about this?

Here’s the results.

False
'true': False
true: False
True: False
'false': False
false: True
False: True

So, please try this:

- id: '1678730240643'
  alias: Airlock Light
  description: ''
  trigger:
  - platform: state
    entity_id:
    - camera.airlock
    attribute: detected
    to: 
      - True
    enabled: true
    for:
      hours: 0
      minutes: 0
      seconds: 0
    from: 
      - False
  condition: []
  action:
  - service: light.turn_on
    data: {}
    target:
      entity_id: light.airlock
  mode: single

Hi Edward. Thanks, but sadly no luck.

I noticed that after changing the code to this, the visual editor is showing this:

https://ibb.co/QrFNpZb

I did put capital letters at the start of “True” and “False” in the automation code. For some reason it shows it as lower case in this error message.

Not sure if that’s relevant.

Billy

What about this as trigger?

trigger:
  - platform: template
    value_template: "{{ \"true\" in state_attr('camera.airlock', 'detected') | string | lower }}"

No luck…

It’s almost as if the automation engine simply cannot see the state change even though I can see it happening before my eyes in the states tab.

Scrap that… I rebooted HA and now it’s working with your trigger!

Thank you. So bizarre that it didn’t want to work with it’s own code generated by the visual editor!?

There could be a hidden character or space

I’ve found that the automation only ever works when using a value template to check the attribute status. It never works using the regular state change. Weird!

Again. It can be a hidden character or a space. These kind of things can mess up coding

I understand syntax errors, but what I’m saying is that it doesn’t even work when setting up an automation from scratch using the visual editor. HA is unlikely to make a syntax error by itself.

It’s about the string in the attribute. The developer could be copying it from the device, or using an API something and there could be a character that is not visible.

see here:

This is not unusual when dealing with external sources

Ah I think I understand. Is this what Edward was checking for above? It still didn’t work with his code though after checking the return.

Exactly. Edwards test showed that true is not possible. There is something blocking true from being true.
However false is true. So we could use a not_to: false in normal automation and it would work unless there are more states that is possible.
Since I didn’t know if there is a “maybe” state then it was easier to just use the template.

I see! Much more complicated than I thought haha! Thank you so much for your help though guys.

After alll the comments, I feel a bit lost here…

What is your current sensor configuration and how you see the problems you have?