but when I go to the Configuration validation button in Server control I get this message:
Invalid config for [group]: value should be a string for dictionary value @ data['group']['light']['entities']. Got None. (See /config/configuration.yaml, line 8).
I just went about setting this up myself this morning! I put all of my light groups into a dedicated âlight groupsâ file. Below is an example for my bedroom lights.
Thatâs how I separate the automations I create manually from the ones created via the Automation Editor. Notice the space between the two words. The first word matches a domain (automation) and the second one is userâs choice. Although I have never tried that technique with anything else, it probably works for other domains.
Although in this case, the problem is simply the data is in the wrong file. It doesnât necessarily need its own file, just needs to go wherever all existing light entities are defined.
I copied that syntax exactly from the Home Assistant documentation for separating the configuration file into multiple configuration files. Hereâs the code snippet from that document:
light:
- platform: group
name: Bedside Lights
entities:
- light.left_bedside_light
- light.right_bedside_light
# define more light groups in a separate file
light groups: !include light-groups.yaml
# define some light switch mappings in a different file
light switches: !include light-switches.yaml
Tom is misunderstanding yaml fields and how they work. Itâs 100% valid to have 2 light sections if you add a tag to the field:
light:
....
light mysuperlightsection:
^
tag
...
EDIT: I should clarify that this method doesnât work for every section. Some sections in the configuration are âspecialâ. However 95% of them will work with this method. Only one off the top of my head that doesnât work with this method is scripts.
@123, can you expand on what the second word accomplishes? If I had to guess, youâre not allowed to have multiple âautomationâ entries. By adding the second word, youâre telling Home Assistant that this is an âautomationâ type, but not the same as the previous one youâve done. The second word acts almost like a comment.
petro has already explained that the second word is an identifier that serves to distinguish one key from another.
BTW, the post you marked as Solution doesnât explain why you encountered the problem. In fact, it proposes a solution that is designed to serve an entirely different purpose (organizing your systemâs configuration by splitting it into separate files).
For the third time, the reason why you got the âInvalid configâ message was because you put the light group configuration into the wrong file.
Light Group is the name of the integration but the entities it creates are members of the light domain. Look at the first line in your configuration and youâll see it contains the word light: . Thatâs the domain for everything that follows it and you put it all into a file designed to hold groups (group is a different domain).
The easiest fix was to simply move it wherever you currently define light entities which may very well be configuration.yaml. Moving all light entities them to a separate file is completely optional and not mandatory to solve the core problem.