Meross MQTT architectural question

[mherwege]

I am considering creating a binding for Meross devices.

Meross devices normally work with a cloud, but can be controlled locally using a combination of MQTT and REST.

For the MQTT comunication, the device has to be provisioned to talk to a local MQTT broker. This can be a locally installed Mosquitto server. The binding should then connect to this broker and handle the Meross specific communication.

The architecture in openHAB so far for this kind of communication has been to create a specific MQTT binding that leverages the main MQTT binding. Once you do that, it always gets installed as part of the main MQTT addon, and thing types defined for that binding also get listed under the MQTT binding. As a consequence, the list of thing types under the MQTT binding gets longer. Sloppy naming makes it even harder to know what it is about (try adding thing for mqtt binding, and see several Milight thing types in the list and an FPP thing type that is meaningless without further clarification).

If I build an mqtt Meross binding, I may ultimately have:

• 10's of extra thing types in this mqtt binding list.
• A lot of extra code that has little to do with MQTT that gets added whenever the mqtt binding is installed.

To avoid that, I would have to recreate the functionality of the mqtt bridge thing type in a separate Meross binding, which is far from ideal. Other bindings that use mqtt internally without leveraging a mqtt bridge thing typically talk to a broker inside the system we integrate with (e.g. nikohomecontrol which I wrote myself). So it does not need all the bridge configurability. Here I would want the configurability to be able to talk to the broker that may already be in place and can be used for this.

What is your opinion? What would the recommended way forward be? Is it maybe a solution to move the mqtt bridge type functionality to core, so the bindings become really independent? I know this is a big change, but I don't see how to overcome the architectural limitations.

[ccutrer]

I've pondered the same questions, especially as more sub-bindings get added for MQTT. I think ideally installing one of the specific bindings (Home Assistant, Homie, Milight, FPP, Meross) would automatically install the generic binding as well. I don't know if that's possible with the OSGi feature specifications. Maybe? It seems like it works automatically to install the core components that support MQTT. @openhab/core-maintainers: are there any of you familiar enough with OSGi to comment on if this is viable?