Configuration.yaml migration and cleanup - help with proper structure

I am having trouble with understanding the complete yaml file structure for the new format. For example does the template: platform now belong in a separate file? If so where does the data from the old sensor.yaml file belong? How does this effect sensors that use the - platform: statistics or the -platform: worldclock?

I have been using HA since 2015, in the 0.3x version times. As a result I now have an extensive set of yaml files that have grown organically as my system expanded and HA went through the various version upgrades. I have now decided I need to do a clean up and reformatting of my configuration to match the new format requirements. My searches of the documentation and via google give a structure view for some parts of the configuration, but I could not find a complete structure for the yaml.

I will gladly take any info I use and structure it into a pull request to update the docs if that is useful.
The amount of work the devs and document writers have done in the last 8 years has been phenomenal and I truly appreciate it. Hopefully I can get all my legacy yaml cleaned and migrated to fit their new directions.

I have been using Splitting up the configuration - Home Assistant as a guide but am getting confused without a list of current integrations and platforms as they relate to sensors and value template sensors

If you’re splitting things out into separate files, sure.

Other than new format template sensors… it stays there.

Because it’s personal preference on how you do that. I use individual files and the !include_dir_* commands to make it pretty compact, but I know others who use just !include and others who don’t use any form of inclde.

Easy… the docs for any integration tell you.

# example configuration.yaml entry
binary_sensor:
  - platform: towel
...

That’s a binary_sensor - when you’re splitting the file up that doesn’t change, it still goes under binary_sensor. Same goes for everything else - it’s that initial line that tells you what you need to know.

Great help, thanks!
I do prefer to split the files to keep them shorter and, to my mind, more organized. So I am thinking the structure that fits me would be something like:

# Configuration.yaml ...
group: !include groups.yaml
automation: !include automations.yaml
script: !include scripts.yaml
scene: !include scenes.yaml
sensor: !include sensors.yaml
template: !include template.yaml
mqtt: !include mqtt.yaml
secrets: !include secrets.yaml
...
#rest of config

Would sensors include the miscellaneous platforms? Like:

#### Weather
   - platform: statistics
     name: "Rain 24 hrs"
     entity_id: sensor.openweathermap_rain
     state_characteristic: total
     max_age:
       hours: 24
   - platform: statistics
     name: "Max24hr temp"
     entity_id: sensor.openweathermap_temperature
     state_characteristic: value_max
     max_age:
       hours: 24
   - platform: statistics
     name: "Rain month mm"
     entity_id: sensor.openweathermap_rain
     state_characteristic: total
     max_age:
       hours: 730
 #### Time/Date
   - platform: time_date
     display_options:
         - 'time'
         - 'date'
   - platform: worldclock
     time_zone: Etc/UTC
     name: 'UTC'
   - platform: worldclock
     time_zone: America/Chicago
     name: 'Houston'

Do I need to start the sensor.yaml file with a line for

sensors:

And also the same for the template file

template:

Or are those implicit in the file name?

And in the mqtt.yaml file would the following be the correct format? Do I need to repeat the sensor: line?

mqtt:
# DIY ESP sensor for lab    
  sensor: 
     name: "Lab Temperature"
     state_topic: "sensor/lab/json"
     unit_of_measurement: '°F'
     value_template: "{{ value_json.tempF }}"
  sensor:
     name: "Lab Humd."
     state_topic: "sensor/lab/json"
     unit_of_measurement: '%'
     value_template: "{{ value_json.humidity }}"

Thanks in advance for the help.

sensors.yaml is for anything that the docs show start with sensor:. If the YAML starts with sensor: then it can go in there. If it doesn’t then it can’t.

No, because you already have that line in configuration.yaml

No, because you already have mqtt: in configuration.yaml

1 Like

And lastly for template.yaml would this be the correct format?

template:
  - sensor:
    - name: "well_pump_energy"
      friendly_name: "well_pump_energy"
      unit_of_measurement: "kWh"
      state_class: total_increasing
      device_class: energy
      value_template: "{{ (states('sensor.well_pump_energy_raw') | float) * 2 }}"
# Solar Sensor
  - sensor:
        - name: Sun Angle
          friendly_name: "Sun angle"
          unit_of_measurement: 'degrees'
          value_template: "{{ states.sun.sun.attributes.elevation }}"

        - name: sunrise
          value_template: "{{ states.sun.sun.attributes.next_rising }}"

I just noticed the example in the docs would use

state:

Instead of:

value_template:

Do I need to change that as well?

Except that you’d need to remove template:, and the second -sensor line, and then fix your indenting and use of old style template language.

So… no

- sensor:
    - name: "well_pump_energy"
      friendly_name: "well_pump_energy"
      unit_of_measurement: "kWh"
      state_class: total_increasing
      device_class: energy
      state: "{{ (states('sensor.well_pump_energy_raw') | float) * 2 }}"
# Solar Sensor
    - name: Sun Angle
      friendly_name: "Sun angle"
      unit_of_measurement: 'degrees'
      state: "{{ state_attr('sun.sun','elevation') }}"
    - name: sunrise
      state: "{{ state_attr('sun.sun','next_rising') }}"