Please help with first steps using anchors

Configuration
1

HI,

having several input_selects like:

  media_player:
    name: 'Select Media player:'
#    icon: mdi:speaker-wireless
    options: 
      - Woonkamer
      - Hall
      - Master bedroom
      - Hobbykamer
      - Gym
      - Office
      - Dorm Marte
      - Broadcast (all)
#    initial: Woonkamer

(and many other repeated yaml bits for that matter) made me try yaml anchors and try to set these in a package, so I can use them across the configuration.

I created a package_achors.yaml and have this in it:

anchors:
  select_player: &select_player
    - Woonkamer
    - Hall
    - Master bedroom
    - Hobbykamer
    - Gym
    - Office
    - Dorm Marte
    - Broadcast (all)

changed the original input_select to:

  media_player:
    name: 'Select Media player:'
    options: 
      <<: *select_player

but get this in config check:

2019-04-24 08:27:23 ERROR (SyncWorker_9) [homeassistant.util.yaml] found undefined alias 'select_player'
  in "/config/packages/package_radio.yaml", line 216, column 11

which is the line with the anchor <<: *select_player

What am I doing wrong here?
thanks for your help.

realize anchors: is not a component, so took that out, made no difference though. Ive tried to set the anchor in a package along side the media_player, but that won’t work either. That wouldn’t be very useful though, since I need to be able to use these config globally, and not in a per package setting.

tried this too:

  select_player: &select_player
    options:
      - Woonkamer
      - Hall
      - Master bedroom
      - Hobbykamer
      - Gym
      - Office
      - Dorm Marte
      - Broadcast (all)

changed the original input_select to:

  media_player:
    name: 'Select Media player:'
      <<: *select_player
2

The second one is correct, but your spacing is wrong. Remember, this follows normal yaml rules. You are replacing options, so the << should have the same spacing as what options would have had.

  select_player: &select_player
    options:
      - Woonkamer
      - Hall
      - Master bedroom
      - Hobbykamer
      - Gym
      - Office
      - Dorm Marte
      - Broadcast (all)

  media_player:
    name: 'Select Media player:'
    <<: *select_player
3

ok thanks.
Can I do this in a package_anchors.yaml which has this:

  select_player: &select_player
    options:
      - Woonkamer
      - Hall
      - Master bedroom
      - Hobbykamer
      - Gym
      - Office
      - Dorm Marte
      - Broadcast (all)

as contents, and use the

  media_player:
    name: 'Select Media player:'
    <<: *select_player

or

    <<: *select_player

for that matter in other configuration files?
I hope to collect all anchors in that file, so I can easily maintain it all.

I keep getting this:

Error loading /config/configuration.yaml: found undefined alias ‘select_player’
in “/config/packages/package_radio.yaml”, line 214, column 9

4

I don’t know if you can do that.

5

ok, well, let me put it differently: where do you define the aliases? Ive seen you do it with
anchors: in another thread, but when I do that, it errors out with ‘no component anchors available’.

If I try to do in in place, with this:

  media_player:
    name: 'Select Media player:'
    options: &select_player
      - Woonkamer
      - Hall
      - Master bedroom
      - Hobbykamer
      - Gym
      - Office
      - Dorm Marte
      - Broadcast (all)
#    initial: Woonkamer

  spotify_player:
    name: 'Select Spotify player:'
    <<: *select_player

this is the outcome:
Error loading /config/configuration.yaml: while constructing a mapping
in “/config/packages/package_radio.yaml”, line 226, column 5
expected a mapping for merging, but found scalar
in “/config/packages/package_radio.yaml”, line 215, column 9

6

The anchor, and where it is used, must both be in the same file.

In your example above I think it should actually be

media_player:
    name: 'Select Media player:'
    options: &select_player
      - Woonkamer
      - Hall
      - Master bedroom
      - Hobbykamer
      - Gym
      - Office
      - Dorm Marte
      - Broadcast (all)
#    initial: Woonkamer

  spotify_player:
    name: 'Select Spotify player:'
    options:
      <<: *select_player

Off the top of my head, but I’ve found using an online yaml to json converter to be the quickest way out of errors for anchors.

7

HI, thanks, that’s is what I have been trying to do, resulting in this error now unfortunately:

Error loading /config/configuration.yaml: while constructing a mapping
  in "/config/packages/package_radio.yaml", line 228, column 7
expected a mapping for merging, but found scalar
  in "/config/packages/package_radio.yaml", line 215, column 9
8

I believe you can only merge dictionaries. I don’t think you can merge a list, that means you’d need the keyword options: inside your anchor.

9

testing this now:

  media_player: &select_player
    options:
      - Woonkamer
      - Hall
      - Master bedroom
      - Hobbykamer
      - Gym
      - Office
      - Dorm Marte
      - Broadcast (all)
    name: 'Select Media player:'
#    initial: Woonkamer

  spotify_player:
    <<: *select_player
    name: 'Select Spotify player:'

still, @thomasloven mentions about saving the anchors at the bottom of this http://www.thomasloven.com/blog/2018/08/YAML-For-Nonprogrammers/ and I think it is done in the battery_alert package too.

Since I have media_players in other packages, it would really be of use to do so, and be able to call that anchors globally… Fear @anon43302295 is right, since I can’t use this anchor in another package file without getting the undefined actor error again.

10

Marius,
Just did some browsing / reading and came across this particular thread on anchors.
Very relevant to me as you use packages too.
Did you manage to find a way to share anchors across packages ?

11

You can’t.

Ideally you should generate your packages around functions, then you won’t need to.

1 Like
12

Marc,
Thanks for that but…
Packages are a major departure for HA you can have multiple definitions of input_booleans, binary_sensors, automations, scripts, customisations etc. etc. etc. So when you reload scripts or automations HA goes through all the locations, gathers them together and loads them.
On a restart it does the same with the rest (we need buttons to ‘reload’ input_boolean, binary_sensor and the rest). So why not with anchors.???
Oh well maybe by version 2 :rofl:

13

Because you can’t guarantee the order in which the items will be merged, so you may have a reference to an anchor that hasn’t been declared yet and everything breaks.

14

So config check needs to reflect that requirement :man_shrugging:

15

No. As @anon43302295 says: you can’t

16

But how would you do it? Alphabetical order by filename?

What if you have an anchor in your ‘conservatory’ package that you suddenly realise you could use in your ‘air quality’ package?

What happens when you decide to call your conservatory a sun house instead?

It’s just not feasible tbh.

1 Like
17

I genuinely don’t see the issue.
I have an input_boolean in one package that I can use in any.
Ditto sensors, binary_sensors, input_number etc.
As long as I’m careful about naming I can use them anywhere.
I also have notepad++ - I’ve used it many times to do search and replace across “all open files” so name changes aren’t even an inconvenience, merely a confirmation step.

18

Input_booleans and yaml anchors are completely different things. That’s like saying I don’t see the problem, I got paid yesterday so why isn’t there two moons in the sky tonight.

1 Like
19

Eh! No, mine was an analogy not some extended metaphor.
My statement was to set a scene where the anchors become listed elements which can be processed and applied in a similar manner.
If you are saying its a yaml limitation and HA is all about strict compliance with the yaml standard then I agree it’s a lost cause. But I can apply a line to request that the interpreter go look up a section of text in secrets so why not in an anchors file ?

20

Because secrets, packages, input_booleans, etc are a homeassistant construct, yaml anchors are part of the actual yaml specification.

As I said, the anchor has to be higher up the file than the usage of that anchor, there’s no way you could guarantee that after merge of homeassistant split configurations without a complicated set of rules that people would accidentally not stick to causing their configuration to break in all sorts of weird and wonderful ways. Valid yaml on its own does not a successful homeassistant configuration make :smile:

1 Like