I’m also having issues with the new changes. I’m getting the error “missing property platform” in sensor.yaml when I use a separate mqtt sensor file. How did you solve this?
It looks like it should work for light as long as you are using packages. If you aren’t using packages and you have a single configuration, then both light and switch need to be in 1 mqtt section.
It does not go in sensor.yaml or the sensor section. It goes in a new MQTT section. There are multiple ways to specify this, and it’s covered earlier in the thread.
Thanks. I’ve looked at those and structured my code accordingly. For some reason, the error actually went away. However, the sensor doesn’t show up as an entity when I search for it.
I spent a few hours this morning updating my configuration files based on the MQTT changes. While I did get everything working, I did have to restructure my yaml file such that its now not as well organized. Perhaps you can recommend a solution.
I was unable to include sensor and binary_sensor twice within the mqtt integration. I tried this both with and without the Unit1/Unit2 identifiers. I also tried including the mqtt integration twice with and without Unit1/Unit2 specified on the same line as was originally done with the sensor / binary_sensor.
I ended up having to reorganize my yaml file such that all the sensor are grouped together and the same for the binary_sensor. I would prefer keeping all of each Unit’s sensors grouped together. Short of creating a separate package file for each Unit, is there a way this can be done?
I really love Home Assistant!
But what is happening here about “Move MQTT config schemas and client to separate modules” makes me also heating HA as well.
Hundreds or probably thousands of users are forced to change their WORKING configuration manually.
No info why, no info what will be the benefit, nothing. It’s sad.
I know moth of the contributors are from Europe, but why nobody remember old, good, American proverb: “Don’t fix it if it ain’t broken”?
That’s generally the case for most Breaking Changes so it’s the status quo.
I linked to the reason in an earlier post. It’s part of an architectural decision made 2 years ago and its benefits are explained.
Home Assistant’s success can be attributed to its comprehensive support of IoT devices made by numerous contributors under the guidance of its founder and a small (but growing) team of salaried developers. The founder’s vision includes making the product more capable, flexible, robust, etc. Not all of these enhancements can simply be tacked on to the existing architecture so sometimes that means replacing old ways with news ways (“Breaking Changes”).
I too have been inconvenienced with breaking changes, mostly from not reading “breaking changes”. But overall, Home Assistant just keeps getting better and easier to use.
Eh. Matter of fact is, from a purely technical point of view, it is always possible to avoid user facing breaking changes on an evolving code base, as long as you control the code (ie. cloud dependencies are more complicated). It’s just more work for the developer. And more often than not, HA development is still guided by the devs and for the devs philosophy, the user usually comes second. That’s the nature of many open source projects and to an extent, that’s fine. But as HA progressively turns more and more commercial operation with paid staff, it becomes less acceptable to shift the burden of the work on the paying user base.
In the end the main issue here is that HA still hasn’t managed to stabilize the fundamental structure of the code. At some point within software life cycle management, a project reaches a point of maturity where the fundamental building blocks don’t change that much anymore. The communication APIs between these blocks stabilize and the foundations settle into a system that while staying extensible, stops moving. Breaking changes are mostly necessary while the foundations are still moving, but become much more uncommon once you reach that point of maturity. And being less common, they’re easier to manage.
HA has not yet reached this point. In fact, even though there were improvements on that front, it’s very far from it. The foundations move all the time, and as soon as things seem to head towards stabilization, some general strategic development decisions scramble things up again. This is not a technical necessity to stay cutting edge. It’s simply the way the project is managed. Sometimes it feels like the core devs don’t even want the code to mature because they like to keep this very flexible open sourcey type of approach where you can do far reaching changes on a whim. But at some point, especially when going commercial, you’ll have to stabilize your project or you will end up frustrating your users to a point they’ll just quit and look for something else.
