[mqtt.homeassistant] Crash when discovery topic updates with slightly different payload

[ssalonen]

Similar to #9711 #12295, perhaps same root cause.

Expected Behavior

No errors in logs

Current Behavior

When discovery topic updates with slightly different JSON payload, the existing homeassistant thing crashes.

openhab.log uncatched error, potentially with bad side-effects

java.lang.IllegalArgumentException: Duplicate channels mqtt:homeassistant_REDACTED:MQTTBroker:Ruuvi_REDACTED:REDACTED_2Dmov#sensor
        at org.openhab.core.thing.util.ThingHelper.ensureUniqueChannels(ThingHelper.java:152) ~[?:?]
        at org.openhab.core.thing.util.ThingHelper.ensureUniqueChannels(ThingHelper.java:144) ~[?:?]
        at org.openhab.core.thing.util.ThingHelper.addChannelsToThing(ThingHelper.java:105) ~[?:?]
        at org.openhab.binding.mqtt.homeassistant.internal.handler.HomeAssistantThingHandler.accept(HomeAssistantThingHandler.java:292) ~[?:?]

Potential side effect is unsubscribe of channels

This is done at

openhab-addons/bundles/org.openhab.binding.mqtt.homeassistant/src/main/java/org/openhab/binding/mqtt/homeassistant/internal/handler/HomeAssistantThingHandler.java

Lines 271 to 274 in a4781b4

	if (discovered.getConfigHash() != known.getConfigHash()) {
	// Don't wait for the future to complete. We are also not interested in failures.
	// The component will be replaced in a moment.
	known.stop();

openhab-addons/bundles/org.openhab.binding.mqtt.homeassistant/src/main/java/org/openhab/binding/mqtt/homeassistant/internal/component/AbstractComponent.java

Lines 127 to 135 in a4781b4

	/**
	* Unsubscribes from all state channels of the component.
	*
	* @return A future that completes as soon as all subscriptions removals have been performed. Completes
	* exceptionally on errors.
	*/
	public CompletableFuture<@Nullable Void> stop() {
	return channels.values().parallelStream().map(ComponentChannel::stop).collect(FutureCollector.allOf());
	}

since the crash happens after that, at

openhab-addons/bundles/org.openhab.binding.mqtt.homeassistant/src/main/java/org/openhab/binding/mqtt/homeassistant/internal/handler/HomeAssistantThingHandler.java

Line 293 in a4781b4

ThingHelper.addChannelsToThing(thing, channels);

And indeed,

• [mqtt.homeassistant] Thing status of ESPHome devices not working after OH restart. #12295 says "my devices are reporting the state correctly in the designated MQTT topic, but for some reason the state is not updated in OpenHab anymore. Only when I delete the Thing and re-add it, the Thing state works but only until I restart OpenHab."
• [mqtt.homeassistant] ESPHome "Duplicate channels" warning in log #9711 similarly reports "The MQTT binding also sometimes have problems subscribing to some topics after startup on my system. I've reported that in [mqtt] Topics not subscribed after OpenHab 3.0 restart on generic MQTT Thing #9715 issue."

Possible Solution

PR to follow

Steps to Reproduce (for Bugs)

1. Set up bluetooth sensor, e.g. ruuvi tag, https://ruuvi.com/
2. Set up two instances of OpenMQTTGateway, listening in bluetooth advertisements and publishing data to MQTT. Have different gateway names for the Gateways.
3. Reboot the first OpenMQTTGateway , then the second
4. Observe errors in the logs

openhab.log error

java.lang.IllegalArgumentException: Duplicate channels mqtt:homeassistant_SNIP
        at org.openhab.core.thing.util.ThingHelper.ensureUniqueChannels(ThingHelper.java:152) ~[?:?]
        at org.openhab.core.thing.util.ThingHelper.ensureUniqueChannels(ThingHelper.java:144) ~[?:?]
        at org.openhab.core.thing.util.ThingHelper.addChannelsToThing(ThingHelper.java:105) ~[?:?]

OpenMQTTGateway publishes discovery information similar to below

{
  "stat_t": "+/+/BTtoMQTT/REDACTED",
  "name": "RuuviTag_RAWv2-mov",
  "uniq_id": "REDACTED-mov",
  "val_tpl": "{{ value_json.mov}}",
  "state_class": "measurement",
  "device": {
    "identifiers": [
      "REDACTED"
    ],
    "connections": [
      [
        "mac",
        "REDACTED"
      ]
    ],
    "manufacturer": "Ruuvi",
    "model": "RuuviTag_RAWv2",
    "name": "RuuviTag",
    "via_device": "OpenMQTTGateway_1"
  }
}

NOTE: Depending which sensor was restarted last, the via_device contains different value. This field is not even affecting discovery process, it is purely additional metadata!

This change of value causes the binding to crash.

Context

I am listening bluetooth sensors using multiple ESP32's (with OpenMQTTGateway) around my house. Some bluetooth sensors are in the coverage of two ESP32s.

This setup is causing error on openHAB side.

Your Environment

openHAB 3.3.0 stable release