Cody Cutrer

Ditto JRuby - we have extensive wrappers and monkey patching of similar convenience methods. If some of these get added to core, we'll just delegate to them instead of implementing...

> I am not finding where is the code triggering a thing configuration update when a new result is discovered ! https://github.com/openhab/openhab-core/blob/f26c542429d4c8409bae3aca7f870fa15cac54ff/bundles/org.openhab.core.config.discovery/src/main/java/org/openhab/core/config/discovery/internal/PersistentInbox.java#L294

The Home Assistant binding in particular definitely relies on discovery updating existing things in order to update what channels are available when a device changes. I'll admit when I first...

> I don't have the overview over how MQTT works, but is that really they way it should be done? 🤷 I didn't do the original implementation, and I've never...

I'll need to rebase this if https://github.com/openhab/openhab-addons/pull/17618 is merged first (and possibly vice versa).

> I'll need to rebase this if #17618 is merged first (and possibly vice versa). Nevermind, I just removed JSON attributes from this PR; they'll merge cleanly in either order...

I'm sorry I haven't had time to get back to this. Other projects have taken priority. I still plan on getting back to it, but don't have a specific estimate...

@Nerivec: were you planning on getting back to finishing this sometime soon?

I'm not sure I fully understand what the next steps are. The logic and fatal flaw... in this PR as-is... is too convoluted? Or you just don't think this feature...

Indeed. In this case, the Inovelli switch has manuSpecificInovelli cluster as an _input_ on endpoint 1, and an _output_ on endpoints 2 and 3 (and not present on endpoint 242).