-
Automatic discovery of devices following the Homie or Home Assistant standard.
-
The ability to create, edit, and manage Things through the REST API.
-
Chaining transformations.
-
Proper behavior when the broker goes offline (i.e. if the broker goes offline all of the Things that go through that broker get set to UNDEF).
-
Will continue to have support going forward; 1.x binding support in OH 3 is in doubt.
-
Support for Profiles.
-
Presentation and management more inline with the rest of the OH 2.x bindings.
-
Support for the embedded broker.
-
The Action does not need to be separately installed.
But yes, in this one small use case that is frankly not really used all that much, MQTT 2.x is a tiny amount of extra work compared to the MQTT 1.x event bus configuration. But part of that has to do with the fact that the MQTT 1.x binding implements the event bus in a way that is not allowed for MQTT 2.x bindings.
And it is under discussion that OH 3 there will be native support for federation between OH instances.
Personally, I like the fact that we need to define each Item we want to be put on the MQTT event bus. It is not always the case that one would want all their Items synchronized but the MQTT 1.x binding only allowed all or nothing.
And, at least for the time being, there is nothing stopping you from using the MQTT 1.x binding for this.
This is one of the most common and powerful uses of Groups.
- Design Pattern: Group Based Persistence
- Design Pattern: Associated Items
- Design Pattern: State Machine Driven Groups
- Design Pattern: Sensor Aggregation
- [Deprecated] Design Patterns: Generic Is Alive
- Design Pattern: DRY, How Not to Repeat Yourself in Rules DSL
I could go on. All of these and many more require specifically creating a Group and put all the Items you want to control the behavior of into that Group. If the prospect of doing this is a problem, I have to wonder how many missed opportunities you have to simplify your Rules and make them more generic, shorter, and more maintainable.