How come this group config (without 'entities:' ) is correct?

Configuration
#1

Suddenly I notice I have 2 groups in my configuration which are defined incorrectly, or at least according to the documentation, ie, without the variable entities: .

like:

group:
  github_repos_in_use:
    - sensor.github_home_assistant
# Custom Components
    - sensor.github_afvalwijzer
    - sensor.github_browser_mod
    - sensor.github_card_tools
    - sensor.github_composite_tracker
    - sensor.github_eventsensor
    - sensor.github_fav_icon
    - sensor.github_sun_2
    - sensor.github_weatherbit

I’ve never noticed anything in the behavior, and all templates in which this group is used function properly:

Schermafbeelding 2020-10-01 om 12.17.56
Schermafbeelding 2020-10-01 om 12.17.562442×810 147 KB

Isn’t entities: required after all? In which case the documentation would be incorrect? Or is this a system fluke…

Schermafbeelding 2020-10-01 om 12.21.43
Schermafbeelding 2020-10-01 om 12.21.43780×232 9.4 KB

#2

It’s not required, but the vsc addon throws an error if you don’t use it. It also throws errors on templates in some fields (where the documents state that the key must be a float or int, for example) when in fact they are also valid (so long as the template output is valid, of course).

#3

yes, so it appears…
still the documentation says the configuration variable is required:

Schermafbeelding 2020-10-01 om 12.34.39
Schermafbeelding 2020-10-01 om 12.34.39864×444 23.7 KB

unless that only says the list itself is required, not the variable…
in which case I find that rather confusingly formulated. I mean, it could wel be possible in any integration… a variable listed as ‘required’ is expected to be ‘required’. not?

btw, not using the vsc add-on because that wont run on the Rpi, using the simple BBEdit…

1 Like
#4

Yeah, I think it’s more of a carry-over that it’s not required, before the other keys were there. For example if you use any of the other keys, like name, then you do need the entities key otherwise the yaml itself would be invalid.

#5

yes that must be it. suppose reading
Better documentation or
Beginner friendly documentation

we might have a go at making this a bit less ambiguous :wink:

@frenck, please forgive the tag, but would this require an edit on the current documentation taking out the word ‘Required’, or is it a bug, requiring an issue in the repo Core.

#6

I think it’s probably easiest to leave the documentation as is. If you follow the documentation everything is correct and works perfectly.

The fact we know there to be a shortcut leftover from before that still currently works (most likely unintentionally so), doesn’t need to be documented and is more likely to add confusion than reducing it.

1 Like
#7

ah well, you’re probably right.
for one that is keen on trying to cut on as much unnecessary yaml lines as possible (which is where 115 helped a lot), this shorthand as Frenck called it, is ‘good to know’. Cut another 41 lines :wink:

Schermafbeelding 2020-10-01 om 14.26.55
Schermafbeelding 2020-10-01 om 14.26.55768×176 5.18 KB

Maybe we could add the shorthand itself to the doc’s. I’ll await the dev’s response.

or even twice that, since the name: key isn’t required either (which I had for all groups… duh), and writing that with a capital ensures a correct friendly_name:

group:

  Broadcast:
#    name: Broadcast
#    entities:
      - media_player.googlehome_woonkamer
      - media_player.googlehome_hub
      - media_player.googlehome_library

btw, I do think this only applies when no other key is configured. trying this with an icon: key errors

#8

That would make more sense, but would need to be in a non-confusing way. Although if there’s a chance this ‘loophole’ will be closed at any point, then may as well leave it as-is.

Groups are one of very few (if any other) components left that allow the use of uppercase characters and spaces in their keys, so I can imagine that being changed at some point to make it consistent with all the others.

#9

added a bit to the post above. we need to proceed cautiously indeed :wink:

#10

Yeah, as I said, the yaml itself would be invalid if you used the shortcut and tried to add any other key.

#11

I never knew it wasn’t required. LOL I’ve been using the name key in every one of my groups since I first started with HA. Every one of my groups has it. Derp.

#12

This is the problem though. We’re muddying the waters now because the likelihood is that the ability to use uppercase and spaces in the keys will eventually be brought into line with the other components (for which this has been removed) for consistency, so if the general userbase start going against the documents for the purpose of shortcut, then there will be undocumented breaking changes for them eventually, causing all sorts of problems.

1 Like
#13

ok. sorry I brought it up…shh