HomeAssistant MQTT Discovery losing channels

[Homer-Sim]

Hello everyone,

I’m experiencing an issue with the HomeAssistant MQTT Discovery binding and would like to know whether this is a known problem or if anyone has experienced something similar.

Environment

• openHAB 5.2.0

• Mosquitto MQTT broker

• Devices are integrated using HomeAssistant MQTT Discovery

• Most of the affected devices are provided by Marstek via hm2mqtt

Problem

Occasionally, channels of automatically discovered Things disappear completely/partly. As a result, existing Item links become orphan links.

The observed effects are:

• Items lose their channel links.

• Values are no longer updated.

• Orphan links appear in the UI.

• Rediscovering or recreating the affected Things restores functionality temporarily, but the problem eventually reoccurs.

The issue does not affect all discovered Things, onlythe four marstek things

Question

Is this a known issue with the HomeAssistant MQTT Discovery binding in openHAB 5.2.0?

If so:

• Is there a recommended workaround?

• Are there any debug logs I should enable to help identify the root cause?

• Is it recommended to use manually configured MQTT Generic Things instead of HomeAssistant Discovery for better long-term stability?

Any advice or pointers would be greatly appreciated.

Thank you!

[rlkoshak (Rich Koshak)]

@Homer-Sim

Is this a known issue with the HomeAssistant MQTT Discovery binding in openHAB 5.2.0?

No, it’s not one I’m seeing nor one I’ve seen reported. I’m using Home Assistant with Theengs Gateway, Zigbee2MQTT, and NetAlertX.

@Homer-Sim

• Are there any debug logs I should enable to help identify the root cause?

Look at the JSON posted to the config topics before and after the Channels disappear. You can find the list of config topics under the Thing Configuration with the MQTT Base Prefix prepended. For example the MQTT Base Prefix is “homeassistant” and one of the config topics is “binary_sensor/0x282c02bfffe7c35a/battery_low” the config topic will be “homeassistant/binary_sensor/0x282c02bfffe7c35a/battery_low”.

Are those topics disappearing that configure the missing Channels? Is the JSON posted there valid? An example:

{
  "availability": [
    {
      "topic": "zigbee2mqtt/bridge/state",
      "value_template": "{{ value_json.state }}"
    },
    {
      "topic": "zigbee2mqtt/Kitchen Water Leak Sensor/availability",
      "value_template": "{{ value_json.state }}"
    }
  ],
  "availability_mode": "all",
  "default_entity_id": "binary_sensor.kitchen_water_leak_sensor_battery_low",
  "device": {
    "hw_version": 0,
    "identifiers": [
      "zigbee2mqtt_0x282c02bfffe726cd"
    ],
    "manufacturer": "Third Reality",
    "model": "Water sensor",
    "model_id": "3RWS18BZ",
    "name": "Kitchen Water Leak Sensor",
    "sw_version": "v1.00.23",
    "via_device": "zigbee2mqtt_bridge_0xc02cedfffee9b626"
  },
  "device_class": "battery",
  "entity_category": "diagnostic",
  "object_id": "kitchen_water_leak_sensor_battery_low",
  "origin": {
    "name": "Zigbee2MQTT",
    "sw": "2.12.1",
    "url": "https://www.zigbee2mqtt.io"
  },
  "payload_off": false,
  "payload_on": true,
  "state_topic": "zigbee2mqtt/Kitchen Water Leak Sensor",
  "unique_id": "0x282c02bfffe726cd_battery_low_zigbee2mqtt",
  "value_template": "{{ value_json[\"battery_low\"] }}"
}

[Homer-Sim]

@rlkoshak

Thanks for your reply.

A very strange behavior today.
When i had to leave the house I had a lot (30+) health issues in OH.
Some minutes ago I checked the requested yaml thing and there were only 2 orphan link issues

The topic config in yaml is still present

But the channel definition is gone for these two channels.

And I know, when I had the issues with much more missing channels these were not in the yaml too.

I have 4 of these batteries and I had the behavior with all but always one at the same time.

[rlkoshak (Rich Koshak)]

What’s the JSON posted to those two destinations?

[Homer-Sim]

If they are gone? Or before and after restoring?

calibration_discharge:
        type: number
        label: Calibration Discharge
        config:
          component: sensor
          nodeid: HMJ-2_009b08a
          objectid:
            - calibration_discharge
          config:
            - "{\"name\":\"Calibration Discharge\",\"state_topic\":\"hm2mqtt/HMJ-2/device/009b08a/calibration\",\"value_template\":\"{{ value_json.discharge }}\",\"unit_of_measurement\":\"mAh\",\"availability\":[{\"topic\":\"hm2mqtt/availability\",\"payload_available\":\"online\",\"payload_not_available\":\"offline\"},{\"topic\":\"hm2mqtt/HMJ-2/availability/009b08a\",\"payload_available\":\"online\",\"payload_not_available\":\"offline\"}],\"unique_id\":\"009b08a56a51_calibration_discharge\",\"device\":{\"ids\":[\"hame_energy_009b08a\"],\"name\":\"HAME Energy HMJ-2 009b08a\",\"model_id\":\"HMJ-2\",\"manufacturer\":\"HAME Energy\",\"sw_version\":\"116.6\"},\"origin\":{\"name\":\"hm2mqtt\",\"url\":\"https://github.com/tomquist/hm2mqtt\"}}"

[rlkoshak (Rich Koshak)]

All of the above. If what ever is populating that configuration posts an empty message, invalid JSON, or otherwise corrupted configuration I would expect the Home Assistant binding to remove that Channel.

But you need to see what’s actually published to the MQTT topic. You can’t use OH for this. By then it’s too late. You need to use mosquitto_sub or MQTT Explorer or something to watch the MQTT traffic.

[Homer-Sim]

In the last days it appeared not so often. And today i found some time to try an deeper analysis.
This is the error in Openhab:

In the channel this entry (as described above) is missing and the linked item is showing this error.

This is the missing code for the channel:

input1_charging:
type: switch
label: Input 1 Charging
config:
component: binary_sensor
nodeid: HMJ-2_009b08a5
objectid:
- input1_charging
config:
- "{\"name\":\"Input 1 Charging\",\"device_class\":\"power\",\"state_topic\":\"hm2mqtt/HMJ-2/device/009b08a5/data\",\"value_template\":\"{{ value_json.solarInputStatus.input1Charging }}\",\"payload_on\":true,\"payload_off\":false,\"availability\":[{\"topic\":\"hm2mqtt/availability\",\"payload_available\":\"online\",\"payload_not_available\":\"offline\"},{\"topic\":\"hm2mqtt/HMJ-2/availability/009b08a5\",\"payload_available\":\"online\",\"payload_not_available\":\"offline\"}],\"unique_id\":\"009b08a5_input1_charging\",\"device\":{\"ids\":[\"hame_energy_009b08a5\"],\"name\":\"HAME Energy HMJ-2 009b08a5\",\"model_id\":\"HMJ-2\",\"manufacturer\":\"HAME Energy\",\"sw_version\":\"116.6\"},\"origin\":{\"name\":\"hm2mqtt\",\"url\":\"``https://github.com/tomquist/hm2mqtt\"}}"

A look into MQTT Explorer shows this:

But I do not understand where on this way openhab is deleting existing channel code?
Is it possible, as a work around, to copy the code into a things file in config/things folder?
Or ist it a different syntax?

Thanks for your help.

[rlkoshak (Rich Koshak)]

You need to find the corresponding discovery topics for the device under the “homeassistant” topic. That’s where the binding gets all the information to create the Thing.

The most likely cause of the problem is this discovery information is changing and leaving out “channels”. If the discovery JSON published there, the OH Thing will change so if a “channel” is removed there, the channel is removed from the Things.

There will be multiple topics for each device under homeassistant for each device.

@Homer-Sim

Is it possible, as a work around, to copy the code into a things file in config/things folder?

There are two different syntaxes, DSL or YAML. You can choose use either in a file. But if the device is changing the discovery and topic stuff on the fly, you’ll likely just change the error or the Channels will just silently stop reporting anything.

You can also create a Generic MQTT Thing and define all the channels. Again, if the device changes what it publishes OH will just silently fail to update.

[Hans_Lree (DigiH)]

Also make sure that all the relevant homeassistant discovery messages are marked as RETAINED when viewing them in MQTT Explorer.

[Homer-Sim]

Hello all,

I am feeling quite lost.

In MQTT Explorer I can see the homeassistant entries

But the retained sign is not there and the error message is also very present.
For my understanding.
The Things definition via homeassistant MQTT message is there.
If I copy the original complete code into the existing thing everything is fine.

After a undefined time the thing channel definition ist partly gone. some are still existing

I am really desperate.

EDIT:
in OH GUI Things config I can see under MQTT Config Topic
all switches/sensors etc.
But some channels are not existing. Maybe this will help?

EDIT 2:
I recognized recently that the thing is for a short time marked as offline in OH.
Should there be in the homeassitant mqtt definition under each sensor/button/etc config a kind of retained=true setting?

[rlkoshak (Rich Koshak)]

First, click on the actual message (the config line). That is where you should see the retained flag.

The retained flag is set by the publisher of the message. There is nothing you can do from the OH side to enable it.

But this confirms what I suspected. Whatever is publishing the config message is changing it. OH is going to change the Thing’s configuration based on what ever it finds there.

I suspect the retained flag is there, but you are reporting that the message is changing. This config message should not change. So the root of the problem is what ever is publishing this message and is nothing that can be addressed from the openHAB side. OH is doing exactly what it’s told to do.

The only ways to address this is to fix it in what ever is publishing these messages, or use the Generic MQTT Thing manually configured to subscribe, publish and transform the messages as necessary.

However, beware of the latter approach as it will mask the root problem, not solve it. Your orphaned links will go away, but when those Channels go away in the config message I suspect whatever is publishing the config messages will stop publishing to those missing topics when they are removed from the config message.

[Homer-Sim]

I investigated the logs for the period 13:54–15:47.

In this time frame the error happend again.

openHAB findings:

At 14:19:55:

Dispatching event to subscriber
'org.openhab.core.config.discovery.internal.AutomaticInboxProcessor'
takes more than 5000ms.

At 14:21:51:

[ERROR] [core.thing.internal.ThingManagerImpl]
Exception occurred during notification about bridge status change
on thing 'mqtt:homeassistant:mymosquitto:hame_5Fenergy_5F1480cc': null

The exception originates from:

org.openhab.binding.mqtt.generic.AbstractMQTTThingHandler.bridgeStatusChanged

At 14:23:06 another:

AutomaticInboxProcessor ... takes more than 5000ms

There are further AutomaticInboxProcessor delays later (15:42, 16:32).

hm2mqtt side:

I also compared the Home Assistant MQTT Discovery payloads. hm2mqtt republishes the discovery information, but I could not find any content changes: the discovery objects remain identical (same number and contents of the 348 discovery objects). I therefore currently have no evidence that hm2mqtt is publishing an incomplete or changed discovery configuration.

My current suspicion:

The problem may be on the openHAB side, around MQTT bridge status handling / Home Assistant MQTT Discovery processing. The timing of the bridgeStatusChanged exception and the long-running AutomaticInboxProcessor events is suspicious and may be related to the disappearing channels.

I am now checking events.log around 14:19–14:23 to determine whether any Things or Channels were actually removed or modified at that exact time.

[Homer-Sim]

Another “funny thing”

I have 4 things acc. to the 4 Batteries.
All of them were created by autodiscovery from HA a long time ago (1 year)

B,C and D were in the meanwhile (looking for a solution of the error) deleted and rediscovered.

B,C,D (is like B/C) are more often the ones losing channels, but A is also involved, but more rarely.

[Hans_Lree (DigiH)]

I’m also starting to look at hm2mqtt for some new Marstek devices I’ll be installing.

t looks to me like you have several Marstek B2500 v2 storage batteries. Do they all have the same firmware version, and have you meticulously followed the detailed instructions given on the repo’s page about setting up multiple B2500 v2 batteries?

GitHub - tomquist/hm2mqtt

EDIT: OK, I see you have also already opened an issue for the repo

[Homer-Sim]

All are on the same firmware. And yes, I followed the instruction.
The only way I am doing different is that I do not use Toms “fake energy meter”
I am adjust the output level with a handwritten OK rule.

And as I wrote, it worked for approx a year without issues. And then they started the described issue.

[Hans_Lree (DigiH)]

I hope you eventually find what is causing this issue, and somehow think it likely has to do with the republishing of the homeassistant discovery messages – something you could look up in the history of these discovery messages, to also see if and how the republishing differs from the previously published discovery message.

I haven’t looked into hm2mqtt closely enough yet, to see if its is possible to turn off the homeassistant discovery at all, because once the discovery messages are retained in your MQTT broker there should be no need to republish them at all; very similar to what I’ll be doing by defining everything manually in textual config files, as I do with all my other numerous MQTT devices/

I think turning off the discovery message publishing is definitely something to look into for your issue … obviously once everything has been correctly discovered once

And are you restarting hm2mqtt every now and then by any chance?

[Homer-Sim]

I hardly dare to write the following lines, but since yesterday evening the error did not appear so far.
Maybe the mosquitto setting is effective?

[Homer-Sim]

I knew it — I celebrated too early and jinxed it.

Storage D has lost many channels again, and B has lost two or three.

Where else can I look now for clues as to what is causing this?