Sensor and config.yaml

[mcoulton (Michael)]

Hello
I recently added some code to my config.yaml file and I get this error message: “duplicated mapping key (137:1)”

On line 22 I have an existing line of “sensor: !include wunderground.yaml”
On line 137 I have added “sensor:” plus some code underneath it (LG Appliance integration). Should I be adding all the LG Appliance integration to a separate lg.yaml file and then reference that file in the config.yaml? That would allow me to get rid of line 137. If so, what is the line of code I need to add in config.yaml to reference the newly created lg.yaml file?

Is this a critical error and how can I correct it? Also any sensors in the “wunderground.yaml” file aren’t working.

Thanks in advance for any help that can be provided.

[vingerha]

Copying your yaml might help more than your textual explanation …donot forget to format it between ```

[Stiltjack]

Don’t forget that HA starts counting lines from zero (in spite of what file editor says) - have you got the right ones?

[finity]

The problem is you can’t have two “sensor:” definitions.

You can put the new LG sensor stuff in a package file that starts with “sensor:” there (you need to reference packages in your config).

Or you can change the second “sensor:” to something like “sensor lg:” and I believe it should work.

[aceindy]

wrong:

sensor:
  - platform: template
    name: sensor1
    ~~
sensor:
  - platform: template
    name: sensor2
    ~~

right:

sensor:
  - platform: template
    name: sensor1
    ~~
  - platform: template
    name: sensor2
    ~~

Now, if you use something like this:
sensor: !include wunderground.yaml
it would already count as a ‘sensor’ section, and you cannot add another.

2 options here:

• rename wunderground.yaml to sensors.yaml and change
  sensor: !include wunderground.yaml to sensor: !include sensors.yaml
  and add you new sensor to sensors.yaml file
• add a sensors folder, and move wunderground.yaml to it
  change sensor: !include wunderground.yaml to sensor: !include_dir_merge_list sensors/
  and add a new file mynewsensor.yaml to the folder

You can check @Tinkerer’s config on Github and use it as an examlpe

Oh, I just realized you have a third option:

• Copy everything from wunderground.yaml into the configuration.yaml under a section called sensor:
• Add your own sensor under the sensor: section
• Delete wunderground.yaml and sensor: !include wunderground.yaml

[Deckoz2302 (Brad)]

@aceindy that’s the old way putting it all in configuration.yaml. as well the old method for template sensors.

This is how I do mine with individual yamls for different sensors to keep the file structure clean.

configuration.yaml

sensor: !include_dir_list sensors/

Example car_count.yaml

platform: statistics
name: 'Car Count'
entity_id: sensor.front_left_lp_all_count
state_characteristic: count
max_age:
  days: 30

Same can be done for template sensors

configuration.yaml

template: !include_dir_list templates/

Except the file format for templates is slightly different

sensor:
  - name: Derp
    state: >-
                 {{ Template dood }}

[aceindy]

@Deckoz2302

that’s the old way putting it all in configuration.yaml

that is why i forgot

@Deckoz2302

as well the old method for template sensors.

I don’t think there is a old nor new way; I think it comes down to how one prefers it; I’de rather have my sensors in one file (or folder), then having some sensors (f.e. platform: systemmonitor, snmp) in one file and some other sensors in a template file; doesn’t make sense to me, i like to keep things sorted by device

And please, use proper indentation in your example (and refrain from using screenshot’s too)

[finity]

@Deckoz2302

that’s the old way putting it all in configuration.yaml

there is no “old way” or “new way” when adding things into configuration.yaml.

I don’t think there is anything referenced in the docs that would tell someone to not put everything directly into configuration.yaml.

packages and !includes have been around pretty much since I started using HA 6 years ago. So those are nothing new.

It all comes down to how the user wants to organize their code.

[Deckoz2302 (Brad)]

@aceindy

And please, use proper indentation in your example (and refrain from using screenshot’s too)

The indentation is correct for the files. So, try again. I literally typed it exactly how it is in those files and my yamls run through Lint… Indentation lol

Screen shots are a double, of what I typed. As a visual aid to someone who obviously isn’t familiar with this.

I’ll use screen shots to convey the point as I feel.

@finity

there is no “old way” or “new way” when adding things into configuration.yaml

You contradict yourself

Migrating from legacy templates

It sounds to me like you are still trying to mix up the two configs. the old way: sensor: - platform: template binary_sensors: some_template_sensor: friendly_name: ...... value_template: "{{the template}}" some_other_template_sensor: friendly_name: ...... value_template: "{{ the other template }}" the new way: template: - binary_sensor: - name: some template sensor state: "{{ the template }}" - name: some other template …

There is an old template style and. New template style, as I said, and as you have said. aceindy posted the old template style…

If you all want to add everything to configuration.yaml and have an monster document you can’t find anything in. Be my guests. But why continue using the old template sensor style

[finity]

@Deckoz2302

There is an old template style and. New template style, as I said, and as you have said.

I didn’t say anything about templates in that reply.

YOU said:

@Deckoz2302

that’s the old way putting it all in configuration.yaml. as well the old method for template sensors.

And in your quoted line YOU even differentiated between “putting it all into configuration.yaml” and “old method for template sensors”.

I was responding to the first part of that as I quoted you in your post above in my reply.

Of course I already acknowledged that there was a new and old template config. I was only talking about adding things to configuration.yaml. As I noted.

@Deckoz2302

But why continue using the old template sensor style

Because there are things you can do with the old style that you can’t easily do with the new style. You have to jump thru hoops to change the friendly name without changing the entity_id for one.

Almost all of my template sensors still use the old style and they work perfectly fine.

And yes, before you say it, there are things you can do with the new style that you can’t with the old style too (state_class being one).

I typically don’t find the need to use that info in my config very often if at all. So I continue to use the old style.

[Deckoz2302 (Brad)]

To each their own. My configuration.yaml, as well as all of my yamls are under 100 lines each. Named with directory structure to easily find, edit, or remove.

It seems silly to continue to suggest someone put everything into configuration.yaml when they start out, as their system is going to grow to something unwieldy eventually. If I put all my code into configuration.yaml it would be over 10000 lines long. How would you ever find anything.

yaml was designed to be modular with includes, little snippets, to make code management easy. A long configuration file isn’t doing anyone any favors for readability, as well the documentation doesn’t even touch on expanding out from default_config:

@finity

You have to jump thru hoops to change the friendly name without changing the entity_id for one.

Or you just start off with what you want by using unique_id which sets the entity_Id and name becomes the display name.

unique_id: whats_one_extra_parameter_to_type
name: 'Blowing fake smoke'
state: blahblahblah

One extra parameter isn’t jumping through hoops.

[finity]

@Deckoz2302

It seems silly to continue to suggest someone put everything into configuration.yaml

I don’t think I ever suggested that someone should do that.

I’m pretty sure all my suggestions were in my first reply here. And in that reply my first suggestion was to put it in a package.

I put almost everything in packages and !includes in my config myself too. But not everything. There are some things that it just makes more sense to put them in configuration.yaml.

I was just saying that putting everything in configuration.yaml is still completely valid and not an “old way”. It’s just different.

@Deckoz2302

Or you just start off with what you want by using unique_id which sets the entity_Id

I still thought the entity_id was set from the “name:” and that if you wanted to change the display name you needed to change it through customization.

unless that’s changed. It could be true tho since I don’t really follow the configs for the “modern format” (which is what the docs officially call the old way).

but the docs don’t say anything about the unique_id becoming the entity_id. It just says this:

unique_id string (optional)

An ID that uniquely identifies this entity. Will be combined with the unique ID of the configuration block if available. This allows changing the name, icon and entity_id from the web interface.

and from the way I read it, it can’t be the entity_id since it says it “allows changing the name, icon and entity_id from the web interface.” unless of course that’s just poorly worded which I concede could be true.

But either or any way the legacy format for template sensors is still valid if someone wants to use it.

and adding everything to configuration.yaml is also still valid (and not an “old way” unlike the way you were saying it is) if someone wants to do that too.

[mcoulton (Michael)]

Hello
Thank you for all your input.
I have created a new folder “sensors” and added the wunderground.yaml and the lg.yaml files to it. I then change the “sensor: !include wunderground.yaml” to “sensor: !include_dir_merge_list sensors”.

Once that was done I went to “Developer Tools” on the side panel, in the “Check and Restart” box I selected “Check Configuration” and then pressed “RESTART”. All is working now. Thanks.