Global constants & dictionaries: addressed like "secrets" - but safe to expose

Feature Requests
1

Assume there is some constant which is used for different sensors, automation, …
If these things are defined in same yaml file, it is possible to define a constant on the top of the file and then used by a yaml anchor:

xxxxxxxxxx: &ref_const 1234
...
some_option_1: *ref_constant
...
some_option_2: *ref_constant
...

But if the constant is used in different yaml files - then a possible way is using secrets:

global_constant: 1234

some_option: !secret global_constant

Similarly dictionaries may be available globally as secrets:

settings_for_input_number:
  min: 0
  max: 100
  step: 1
  mode: slider

input_number:
  number_1: !secret settings_for_input_number

Storing global constants & dicts in “secrets.yaml” (either a global file or placed on some tree level of a config dir) may declutter the “secrets.yaml”.

Another way is using “!include”.
In some way it is more preferable than secrets - global definitions may be shared for other people when exposing the HA setup on Github.
But you need to create a separate file for each definition! (could be weird if a definition is ONE value)
Also, each “!include” directive should contain a full path to the included file - which may be cumbersome.

Means - we need to have a possibility to keep several definitions in ONE file (like secrets) but this file should be safe to expose.

Question - is it possible to add a NEW directive which may be used like

some_option: !const global_constant
...
input_number:
  number_1: !const settings_for_input_number

and these “global_constant” & “settings_for_input_number” definitions can be stored in ONE file?
Probably with same logic as “secrets.yaml”: if some requested definition is not found in the same folder → go to an upper level and so on.

2

I second this idea. Using secrets.yaml looks like a hack for values that don’t need to remain hidden, so I would like to avoid it.
!include may not work in all situations. Depending on your use of !include_dir_list, !include_dir_named and the like to build your config filesystem, the structure of the targeted yaml file may differ. Some contain lists, others contain dictionaries. Attempting to !include the same file within a list-like file and a dict-like file would not work because the syntax differ. At least, I could not make it work.

Another option that I am considering is the use of !env_var. Not as appealing as the !const suggested above which would allow to place constant files in subfolders to keep the config neat. But that may do the trick for now.

After having a look at the code, I believe the mechanism used to resolve secrets could very well work for other constants. Instead of just scanning secrets.yaml files, if this mechanism was also scanning constants.yaml, we would be able to consume values from any of those files with the same !const or !secret construct. I mean, when consuming a value (with !const or !secret or whatever), you don’t really care where this value comes from and if it is sensitive or not. You just would like to store secrets and public constants in separate files to keep your config tidy. If you manage your config with git, secret files should be in .gitignore while public constant files should not. But that’s the only difference I see.

If we were to implement two YAML constructors for secrets and constants, I guess that would be to:

  • avoid the removal of !secret which would be a pain
  • mark values as safe or sensitive where they are used in the config, so that the reader could tell “ah, this one is a secret, okay”.
3

Why not voted then ? )