[solved] Issues with automation as with recent releases

What I’m trying to do is fairly straight forward (i.e. turn on the lights if someone is home). However, sometime in the last few versions, this automation broke.

The automation looks like this:

- id: xxx
  alias: Morning
  trigger:
  - at: 08:30
    platform: time
  condition:
  - condition: and
    conditions:
    - condition: state
      entity_id: group.presence_detection
      state: home
    - condition: state
      entity_id: binary_sensor.workday_sensor
      state: 'off'
  action:
  - service: script.ikea_focus

After scratching my heads with no indicators in the logs, I finally got an error in the latest stable release (0.99.1) from the automation editor. There I get the following error:

Unsupported condition: and

{
  "condition": "and",
  "conditions": [
    {
      "condition": "state",
      "entity_id": "group.presence_detection",
      "state": "home"
    },
    {
      "condition": "state",
      "entity_id": "binary_sensor.workday_sensor",
      "state": "off"
    }
  ]
}

Apparently 'and` is an unsupported condition? Yet my config looks very similar to the example automations.

Any pointers would be appreciated.

There’s nothing wrong with the automation. Apparently, though, the Automation Editor doesn’t support it. So, don’t use the Automation Editor on this automation. :slight_smile:

Sorry but shouldn’t platform: come before at:

Well, something is wrong because the automation is not triggering :frowning:

I’ve been banging my head against the wall for ages now trying to find the root cause.

No, doesn’t matter. It’s perfectly legal YAML. I even copied and pasted into my test system verbatim. No problems.

One thing I would change, though, is I would put quotes around the time:

  - at: '08:30'

YAML can be a bit fussy about times like these.

The indenting just looks off to me (read: it’s just not the way I’d write it) but Phil knows yaml (much better than I) so…

Also, are you sure the automation is turned on?

Yep, I’d write it differently, too. But again, legal YAML.

BTW, if you enter more than one condition they “and” by default. So, you could write the condition part this way, too:

  condition:
  - condition: state
    entity_id: group.presence_detection
    state: home
  - condition: state
    entity_id: binary_sensor.workday_sensor
    state: 'off'

On the plus side, it should then be compatible with the Automation Editor. :slight_smile:

The automation editor always seems to include the superfluous ‘and’ and usually puts a blank condition in as condition: [] too

Thanks guys, we might be zooming in on the problem now.

@pnbruckner Also, are you sure the automation is turned on?

I would think so, but is there any way to double check that?

@pnbruckner If you enter more than one condition they “and” by default. So, you could write the condition part this way, too:

I wasn’t aware that the ‘and’ condition was now standard. I’ve now refactored it and the editor is no longer complaining at least.

In any case, I’ve now refactored it (removed the explicit ‘and’ as well as quoted the time. Despite all this, it isn’t triggered and nothing in the logs. The only thing that I can see is this:

[...]
2019-09-24 08:34:43 INFO (MainThread) [homeassistant.components.automation] Initialized trigger Morning
[...]

Here’s the new snippet:

[...]
- id: e517f4916aa34396a0df825c6b91083c
  alias: Morning
  trigger:
  - at: '08:30:00'
    platform: time
  condition:
  - condition: state
    entity_id: group.presence_detection
    state: home
  - condition: state
    entity_id: binary_sensor.workday_sensor
    state: 'on'
  action:
  - service: script.ikea_focus
[...]

(I also noticed that binary_sensor.workday_sensor was inverted for this script from some testing, and I fixed that too.)

Look at it on the States page of the Developer Tools.

AFAIK, it’s always been. Nothing new here.

Well, the log shows that the trigger was initialized at 8:34, so it just missed the chance to trigger (since it wasn’t initialized until 4 minutes after the trigger time.) Maybe temporarily change the trigger time to 10 minutes after the current time and restart to test it???

Also, have you checked (again, on the States page), that the state of group.presence_detection is home, and binary_sensor.workday_sensor is on?

Well, the log shows that the trigger was initialized at 8:34, so it just missed the chance to trigger (since it wasn’t initialized until 4 minutes after the trigger time.) Maybe temporarily change the trigger time to 10 minutes after the current time and restart to test it???

Oh at the time, I had changed it to “8:40:00”. Also, 8:40 AM passed today, and

Look at it on the States page of the Developer Tools.

Checking the state of automation.morning, it is set to on and the State Attribute is reported as:

{
  "last_triggered": "2019-09-07T10:56:06.091284+00:00",
  "id": "e517f4916aa34396a0df825c6b91083c",
  "friendly_name": "Morning"
}

Note the last_triggered time.

I also verified from the States page that binary_sensor.workday_sensor is in the state on.

Here’s the full log snippet from this morning (covering the time interval):

2019-09-25 07:25:44 INFO (MainThread) [coap] Duplicate CON received, sending old response again
2019-09-25 07:25:45 INFO (MainThread) [coap] Duplicate CON received, sending old response again
2019-09-25 07:25:45 INFO (MainThread) [coap] Duplicate CON received, sending old response again
2019-09-25 07:25:46 INFO (MainThread) [coap] Duplicate CON received, sending old response again
[...]
]2019-09-25 07:25:50 WARNING (MainThread) [homeassistant.components.websocket_api.http.connection.140472735666384] Disconnected: Did not receive auth message within 10 seconds
2019-09-25 07:26:05 WARNING (MainThread) [homeassistant.components.websocket_api.http.connection.140472717297296] Disconnected: Did not receive auth message within 10 seconds
2019-09-25 07:26:21 WARNING (MainThread) [homeassistant.components.websocket_api.http.connection.140472736062992] Disconnected: Did not receive auth message within 10 seconds
2019-09-25 07:26:36 WARNING (MainThread) [homeassistant.components.websocket_api.http.connection.140472735638864] Disconnected: Did not receive auth message within 10 seconds
[...]
]2019-09-25 08:34:55 INFO (MainThread) [coap] Duplicate CON received, sending old response again
2019-09-25 08:35:02 INFO (MainThread) [coap] Duplicate CON received, sending old response again
[...]
2019-09-25 08:50:39 INFO (MainThread) [coap] Duplicate CON received, sending old response again
2019-09-25 09:00:00 INFO (MainThread) [homeassistant.components.automation] Executing Turn off bedroom lights in the morning
2019-09-25 09:00:00 INFO (MainThread) [homeassistant.helpers.script] Script Turn off bedroom lights in the morning: Running script
2019-09-25 09:00:00 INFO (MainThread) [homeassistant.helpers.script] Script Turn off bedroom lights in the morning: Executing step call service
2019-09-25 09:05:36 INFO (MainThread) [homeassistant.components.websocket_api.http.connection.140472658413968] Connection closed by client
2019-09-25 09:05:43 INFO (MainThread) [homeassistant.components.websocket_api.http.connection.140472717872336] Connection closed by client

Note the absent of the “morning” automation in the logs.

What about the second condition? Did you also check that the state of group.presence_detection was home?

If the automation is on, and the conditions are all true, but the automation is not triggering, then that would lead me to believe there’s something wrong with your clock / time zone settings. What do you get if you enter the following in the Template Editor?

{{ utcnow() }}
{{ now() }}
{{ utcnow().astimezone() }}
{{ now().astimezone() }}
{{ utcnow().tzinfo }}
{{ now().tzinfo }}
{{ now().astimezone().tzinfo }}

The first line should show the current time in UTC.
The next three lines should all show the current time in the local time zone.
The fifth line should say UTC.
And the six and seventh lines should show the local time zone, probably in different formats (but they should be equivalent.)

Also, do you have any other automations with a time trigger, and if so, are they working (i.e., triggering at the correct time)?

This can be closed. It turns out it was a combination of factors (including the Unifi component upgrade) and some configuration issues caused by that.