with the forthcoming breaking changes to MQTT
No idea how to implement:
I separate each of my sensors into a different file.
e.g. temperature1.yaml
- platform: mqtt
#'acurite/temp'
name: "Indoor Humidity"
state_topic: "home/rtl_433"
the new format in the docs is:
mqtt:
sensor:
- name: "My sensor"
state_topic: "some-state-topic"
I can’t use the keyword sensor - its already in use in the config file
any ideas?
I don’t think the MQTT section is available until 2022.6, it does not deprecated the current way until 2022.9. At least that is how I read it.
You don’t say but this
Makes me assume you have something this in configuration.yaml right now right?
sensor: !include_dir_merge_list sensors
So just make subfolders I guess. Something like this could work:
And then add this to configuration.yaml:
mqtt:
sensor: !include_dir_merge_list sensors/mqtt
template:
- sensor: !include_dir_merge_list sensors/template
sensor: !include_dir_merge_list sensors/legacy_format
I assume you also needed to do something similar for template right? Or have you just been sticking with legacy format for that integration?
I never really understood the “one sensor per file” approach personally, always seemed too broken up to me. Plus it completely kills your ability to use yaml anchors. But to each their own.
Also this is true, you don’t have to rush.
This is a good opportunity to clean up your code. 
I found a lot of old stuff that i never need anymore.
Using packages, so a lot can be done with search and replace, but sometimes you need to add an additional keyword, and have to inspect before the replace.
It could be a mqtt trigger.
I look forward to tomorrow’s comments. 
Looking at the beta documentation for mqtt MQTT - Home Assistant I really miss having a list of links to the many specific mqtt subtopics.
There are at least 25 of these “secret” topics. They are not linked from mqtt and they are not linked from the individual integration pages either. The only way to find them is to search integrations from the integrations search page.
I really think this should be done in connection with this major breaking change
I have read the PRs and understand why the change is done. Your can do anything in code and this change could have been avoided and I do not find it logical that a cover sensor is no longer a cover integration but an mqtt integration. Mqtt is protocol and software geek. A cover is a physical thing. I do not understand this decision. Just another breaking change … too many of them.
Sorry, I should have been more complete in my query.
I have in my configuration.yaml:
sensor: !include_dir_merge_list sensors
in the directory config/sensors, there are 25 different yaml files.
10 of them contain MQTT statements, the others - not.
I have no template files.
The statement suggested above:
mqtt:
sensor: !include_dir_merge_list sensors/mqtt
won’t work - as I have other sensors that are not MQTT
The reason I broke up the files - If I introduce a new sensor, I only have to work on one file, instead of breaking everything.
How would you suggest I do this?
@Mike - yaml anchors???
I have the same problem. My HA system has 54 package files where each package contains the needed sensors and automations for a particular system in my home (ie. HVAC, locks, floor heat, shades, etc). With this change, for each package I would need to create a new package that contains only the MQTT sensors for the system and then include these yaml files under the mqtt integration. While it’s possible to do this, it unnecessarily breaks up the code into twice as many files and makes each package unreadable as I would then need to switch between files to lookup a sensor definition when working on the automation for it. I use package to easily allow me to drop in new capabilities and everything is self contained.
I will be holding off on upgrading to 2022.6 and hope that based on the feedback from this changes that things will stay the way they are.
you don’t need to make a new package. if your package contained…
<domain>:
- platform: mqtt
name: xyz
you change it to
mqtt:
<domain>:
- name: xyz
I’ll give it a try. I was thinking that having multiple mqtt declarations (one per package) would throw an error.
well, if you have multiple…
before:
sensor:
- platform: mqtt
name: xyz
- platform: mqtt
name: abc
binary_sensor:
- platform: mqtt
name: ijk
- platform: mqtt
name: lmn
after:
mqtt:
sensor:
- name: xyz
- name: abc
binary_sensor:
- name: ijk
- name: lmn
Basically, instead of being spread out across multiple domains (fields), they are now all inside the mqtt umbrella.
How can we !include your examples xyz and abc in individual files? I have 2022.6 working with a single mqtt.yaml file containing my sensors, binary_sensors and switches, but I’m not clear how to split these out with the “subdomains” under mqtt.
I guess we’d need something like:
mqtt:
sensor: !include_dir_merge_list mqtt/sensors
binary_sensor: !include_dir_merge_list mqtt/binary_sensors
with a file mqtt/sensors/xyz.yaml looking like:
- name: xyz
...
I’ll have to try that — feels like a new setup I’ve not come across before. UPDATE: yeah, that works fine.
What I have is:
hvac.yaml
sensor:
- platform: mqtt
name: heat_status
- platform: mqtt
name: heat_temp
- platform: mqtt
name: fan_speed
locks.yaml
sensor:
- platform: mqtt
name: front_door_lock_status
- platform: mqtt
name: back_door_lock_status
Can I change this to:
hvac.yaml
mqtt:
sensor:
- name: heat_status
- name: heat_temp
- name: fan_speed
locks.yaml
mqtt:
sensor:
- name: front_door_lock_status
- name: back_door_lock_status
The lazy way I did it was:
mqtt: !include_dir_merge_named mqtt/
and then I made an mqtt folder and placed my files into that. The names of the files don’t matter, but I named them what they were adding…
binary_sensor:
- name: xyz
- name: abc
EDIT: If you do it the way @CentralCommand is doing it, you can make it granular. I.e. you’d make separate folders in the mqtt folder for each type, then you can name the files humidiy.yaml and it wouldn’t care but you’d have organization.
I’m just lazy and wanted the fastest way to a working config without a lot of copy/paste
Yep, that’s all you needed
Except it was always mqtt integration and always said MQTT. I’m not really understanding, the config went from this:
sensor:
- platform: mqtt
name: My MQTT sensor
...
cover:
- platform: mqtt
name: My MQTT cover
...
To this:
mqtt:
sensor:
- name: My MQTT sensor
...
cover:
- name: My MQTT cover
...
If anything it says MQTT less times now since you don’t have to put platform: mqtt in everything.
But more importantly here is this was never the cover integration, it was always the mqtt integration. Why does that matter? In the first part what wasn’t obvious to people who aren’t deeply familiar with the config is that your MQTT sensors, covers, selects, etc. all shared the same MQTT connection to the broker. Because they were all part of the MQTT integration despite being spread out all over your config. A user would likely be quite confused why in the UI all these things appeared under MQTT instead of under cover, sensor, etc. in the settings menus.
Now everything is grouped right under MQTT showing that they are clearly all part of that integration. All these entities share the same connection details and are based on topics on the same broker.
I do not think one way is better than another. You can see it both ways.
It is just another breaking change that 10000s of users need to deal with - every month.
It is too much now!
While I tend to agree with you, the new yaml format for MQTT looks cleaner and more logical to me. The repeated platform key appearing for every sensor was weird. I have a lot of MQTT stuff, so I really notice the difference.
That said, I also think that making this a breaking change was unnecessary. Both formats could have been kept at only minimal maintenance overhead. They made it a breaking change simply because it would make the config handling code cleaner.
The curious part is that this is the opposite of how entities in Home Assistant have traditionally been configured/organized.
For countless versions, entities have been organized according to their domain such as light, switch, sensor, binary_sensor, lock, etc and not the underlying integration that supports the entity. It’s been the responsibility of the platform option to indicate which integration is used for a given entity.
It was the recently revised Template integration that (I believe) was first to diverge from this long-standing organizational model. Now the MQTT integration has followed suit.
Would you happen to know the rationale for this change of organizational structure?
FWIW, I am unaffected by this change because I use MQTT Discovery (via scripts) to define all MQTT entities in my system (sensors, locks, binary_sensors, lights, switches, etc). According to the documentation, the new method of defining MQTT entities still doesn’t allow you to define devices (whereas you can with MQTT Discovery).
I’m not 100% on all the reasons. I looked up the first or in the series of them that rearranged Mqtt config to see if the author said anything:
Sounds like config entry set up prefers it. I cant say requires because Mqtt was using config entries before this but perhaps it was given an exception.
I think it may also have performance benefits. In many of the integrations that have done this I’ve seen centralized coordinators appear in the code to manage communication with the external service and update many entities with one response.
I think this was possible before but I’m not sure it was possible to have a centralized coordinator that updated entities of many different types. Because I believe in the new model the integration is handed the entire config to set itself up with all at once. Whereas before it was asked to set up sensors, covers, selects, etc all independently.
I’m less sure about this though since I don’t have a clear source to point to. Just a pattern I noticed in more recent code.
FWIW, someone asked the same question elsewhere (Reddit) and frenck replied that’s it’s a long overdue effort to bring MQTT-based entities into compliance with this ADR: