Could not determine a constructor for the tag

Configuration
1

Hi all,

What am I doing wrong here? This is a somewhat fresh install and everything is working quite well aside from the warning I get in the log about there is an error:

image
image1010×285 14.3 KB

Tested out on the yaml validator and it gave me the attached output. Since it is a fresh install i haven’t even modified those lines, which makes it even more weird. Found a post that might suggest that the cache in the docker container was to blame, so they are pruned, but that didn’t help.

Version: 2020.12.1
Type: Supervised

Host OS: Raspbian Buster

2

You can’t use a YAML parser to validate this. !include is not known to YAML and is part of home assistant code.

If you go to Configuration -> Logs, what error do you get there? Are you able to restart HA? If HA restarts, then your YAML is correct as HA does a check of your configuration before reatarting and it only restarts if the config is valid.

1 Like
3

Good feedback. Yes it restarts perfectly and everything works fine. But it just annoys me that i get the error when nothing is wrong.

The full log says: 2020-12-25 12:08:25 ERROR (MainThread) [homeassistant.config] Invalid config for [automation]: (See /config/configuration.yaml, line 9).

Line 9 being the above line starting with group:

4

If you start counting the lines with 0, the error points to your automation.yaml.
The config parser cannot deal with includes and shows only the line in configuration.yaml.
Check your automations for errors.

5

Thanks, yes I did that. But since I have only used the GUI for creating them that also somewhat reduces the margin of error (i would assume).

Regardless here is the automation.yaml and i have even checked the indentation. And the automations are working.

- id: '1608817237693'
  alias: Turn off light in freefall
  description: ''
  trigger:
  - device_id: 8deb598ccf43183b9051e2846517699e
    domain: deconz
    platform: device
    type: remote_falling
    subtype: ''
  condition: []
  action:
  - type: turn_off
    device_id: 857e4c1bda0f846e949f88ced3675ddb
    entity_id: light.living_room_bulb_1
    domain: light
  mode: single
- id: '1608893087989'
  alias: Turn OFF lights in Living Room, Dining Room and Kitchen
  description: Using free fall from Aqara
  trigger:
  - platform: event
    event_type: deconz_event
    event_data:
      id: mi_magic_cube
      event: 7008
  condition: []
  action:
  - service: light.turn_off
    data: {}
    entity_id: light.living_room_corner
  - service: light.turn_off
    data: {}
    entity_id: light.living_room
  - service: light.turn_off
    data: {}
    entity_id: light.dining_room
  - service: light.turn_off
    data: {}
    entity_id: light.kitchen
  mode: single
- id: '1608893556868'
  alias: Turn ON lights in Living Room, Dining Room and Kitchen
  description: Using free fall from Aqara
  trigger:
  - platform: event
    event_type: deconz_event
    event_data:
      id: mi_magic_cube
      event: 7007
  condition: []
  action:
  - service: light.turn_on
    data: {}
    entity_id: light.living_room_corner
  - service: light.turn_on
    data: {}
    entity_id: light.living_room
  - service: light.turn_on
    data: {}
    entity_id: light.dining_room
  - service: light.turn_on
    data: {}
    entity_id: light.kitchen
  mode: single
6

I do believe I solved it. The first automation: id: ‘1608817237693’ is an orphan automation due to the device_id being wrong (somehow it must use friendly name: mi_magic_cube). I didn’t notice that since i thought deleting automation from the GUI also would remove them from automations.yaml. But that doens’t seem to be the case when they are orphan? After cleaning that up and restarting it’s all good.