Problem with new MQTT/Home Assistent channel naming

Add-ons Bindings
,
1

Unfortunately there is an issue with OH 4.3.1 in the new MQTT/Home Assistent channel naming. I like the new format, this is much cleaner, and some of my issues are fixed, but:

If the node is added first time, switches and covers become “…:switch_1_switch” instead of “…:switch_1”.

Same for “…:position_1_cover” instead of “…:position_1”, and one gets errors.

A restart does fix this.

But if one updates the Thing, e.g. changing the label, the _switch/cover is added again.

This is reproducible and should be fix.

2

I’ve noticed this myself while testing some new software that publishes Home Assistant discovery. I’m fairly certain that it has to do with multiple publishings of the discovery info (either when the publishing software restarts, or in response to openHAB requesting discovery). Does the publishing software you’re using support a “retain” setting (for example, Zigbee2MQTT has such a setting). I believe that mostly works around the issue for now, until I can get a fix done. I don’t know when that will be, though - winter vacation is all but over, and I may not have much hobby time for a bit.

3

Hi Cody, thanks for the fast reply, much appreciated. Sorry for not detailing my setup, it is Zwave JS + MQTT. I do use the retain discovery feature of Zwave JS, also before that was needed to run stable.

Since this is reproducible, maybe put a note into the doc that if people observe the problem with their configuration, they should restart OH, until this is fixed ? I do run fine now after the restart.

4

Hi, unfortunately there seem to be more issues. The channels are set to a default (on/off, or rollershutter position) after startup. Only sending a "refresh values " via mqttActions after the startup completes fixes the issue. I see that 4.3.2 doesn’t fix the issues. Any hope this gets fixed ?

5

Hi,

maybe I have the same problem:

I use an esp to read out my heating (openHAB - EMS-ESP), which supports HA Discovery. openHAB (4.3.2) also recognizes this without any problems, but creates duplicate channels:

mqtt:homeassistant:mosquittoLokal:ems_2Desp_2Dthermostat:thermostat_building_select
mqtt:homeassistant:mosquittoLokal:ems_2Desp_2Dthermostat:thermostat_building

mqtt:homeassistant:mosquittoLokal:ems_2Desp_2Dthermostat:thermostat_dampedoutdoortemp_sensor
mqtt:homeassistant:mosquittoLokal:ems_2Desp_2Dthermostat:thermostat_dampedoutdoortemp

mqtt:homeassistant:mosquittoLokal:ems_2Desp_2Dthermostat:thermostat_damping
mqtt:homeassistant:mosquittoLokal:ems_2Desp_2Dthermostat:thermostat_damping_switch

And the thing is always offline, but changes values!
This only happens with one of the things, two of three work without problems…

6

Hi, is there any progress on this ? I still see this in OH 4.3.x.

7

I am worried here, the OH native ZWave binding has issues with some types of nodes (see other report, it is corrupting the lifeline), and now the MQTT discovery for the fallback ZWave JS UI + MQTT is not fixed since 4 months. Note, the problem is still there, and nodes keep getting wrong channels if on the ZWave JS UI there is a reboot of the node or a refresh. For all of us using ZWave, is there some hope to get this fixed ?

8

For what it’s worth, it seems to only be an issue my zigbee2mqtt things and not my zwavejs things. I’m not 100% sure why that seems to be the case - I suspect the “Retained Discovery” bit but for what it’s worth, these are my settings in zwavejs:

MQTT:
Retain: On
Clean: On
Store: On
Auth: On, valid username and password for my MQTT broker. (optional)

Gateway:
Topic type: ValueID topics
Payload type: JSON Time-Value
Use nodes name instead of numeric nodeIDs: On
Send Z-Wave events: On
Include Node Info: On
Ignore location: Off
Ignore status updates: Off
Publish node details: On

Home Assistant:
WS Server: Off
MQTT Discovery: On
Retained Discovery: On (this is probably the reason?)

I do have retain turned on globally on my zigbee2mqtt config but that doesn’t seem to fix it for my zigbee stuff.

9

See also here https://github.com/openhab/openhab-addons/issues/18494

10

Hi, thanks for the update.

11

I only used the HA configs on a couple of things in Zwave-js (just for testing) so probably not representative but haven’t observed. I do have the HA configs in manual mode, so after they were pushed to MQTT they don’t get updated, but they are retained. One question, when the OH channel changes are there any changes in the HA configs in MQTT using Explorer?

12

My openhabian is still 32 bit, I think that the explorer requires 64 bit, so I have not installed it. Do you happen to know if there is a 32 bit version ?

13

I don’t know, but I use MQTT explorer from my PC and monitor MQTT in my Rpi’s across the network.

14

Hi, I shall look into this, I am running all locally so far. I also don’t understand what the mechanism is that the discovery result is changing sometimes, it might be new versions being installed for the ZWave JS UI with SNAP updates, I don’t fully understand this either. It is a definite problem for the first discovery and in principle I retain the information afterwards (well, not quite it seems, falling into the same issue with adding _switch or _cover to changes).

15

I have followed some of the posts regarding this issue. I do think it is an OH issue since there were a lot of HA MQTT config changes in OH4.3 (mostly good). My suggestion to check the HA MQTT messages via Explorer was just to confirm, so not critical. It is a good tool, however.

What I think is happening is during some OH or Z2M event, OH thinks there is a duplicate channel, so it adds _switch (or whatever). Then during the next event it switches back to the original. I saw one workaround that just linked both channels to one item. There will always be orphans, but if you can live with that there should be no gaps in your charts, issues with rules, etc. To confirm the guess (and that is all it is) some debug logs (probably of both the core and MQTT HA addons) capturing the events are going to be needed. Also, I suspect I don’t have the knowledge to analyze the logs, but hopefully the code owner will.

1 Like
16

I finally had time to look at this today. I believe I have a fix, but want to run it in my production system for a few days to ensure it doesn’t cause other problems, before sending in a PR. I don’t know that I’d feel comfortable back porting the fix to 4.3.x though.

3 Likes
17

I’m using zigbee2mqtt and esphome devices reporting directly to an mqtt broker (mosquitto).
I looked in zigbee2mqtt and only found this “disable force retain” in mqtt, is this what you meant?

IMG_2770
IMG_27701170×1960 188 KB

18

@ccutrer would you also be in a position to check the home assistant auto discovery processing of the climate type messages? I see some errors /misconfigurations i believe.

19

No, I’m referring to the device settings:

Screenshot 2025-04-22 at 8.52.13 AM
Screenshot 2025-04-22 at 8.52.13 AM870×796 40.7 KB

If you edit configuration.yaml directly, you can set it for all devices at once, with the device_options top level key:

device_options:
  qos: 1
  retain: true
  optimistic: true

Yes. Just post the discovery JSON, and any errors or warnings logged by openHAB.

1 Like
20

Will do. Is there a simple action I can take to retrigger the discovery? Disable / reamble the thing perhaps?

edit: oh, is this it @ccutrer ?

Summary 
{
  "curr_temp_t": "duarte-air-conditioner-b02037/climate/duartes_air_conditioner/current_temperature/state",
  "mode_cmd_t": "duarte-air-conditioner-b02037/climate/duartes_air_conditioner/mode/command",
  "mode_stat_t": "duarte-air-conditioner-b02037/climate/duartes_air_conditioner/mode/state",
  "modes": [
    "off",
    "cool",
    "heat",
    "fan_only",
    "dry",
    "heat_cool"
  ],
  "temp_cmd_t": "duarte-air-conditioner-b02037/climate/duartes_air_conditioner/target_temperature/command",
  "temp_stat_t": "duarte-air-conditioner-b02037/climate/duartes_air_conditioner/target_temperature/state",
  "min_temp": 16,
  "max_temp": 30,
  "temp_step": 0.5,
  "precision": 0.5,
  "temp_unit": "C",
  "min_hum": 30,
  "max_hum": 99,
  "pr_mode_cmd_t": "duarte-air-conditioner-b02037/climate/duartes_air_conditioner/preset/command",
  "pr_mode_stat_t": "duarte-air-conditioner-b02037/climate/duartes_air_conditioner/preset/state",
  "preset_modes": [
    "boost",
    "eco",
    "sleep",
    "freeze protection"
  ],
  "fan_mode_cmd_t": "duarte-air-conditioner-b02037/climate/duartes_air_conditioner/fan_mode/command",
  "fan_mode_stat_t": "duarte-air-conditioner-b02037/climate/duartes_air_conditioner/fan_mode/state",
  "fan_modes": [
    "auto",
    "low",
    "medium",
    "high",
    "silent",
    "turbo"
  ],
  "swing_mode_cmd_t": "duarte-air-conditioner-b02037/climate/duartes_air_conditioner/swing_mode/command",
  "swing_mode_stat_t": "duarte-air-conditioner-b02037/climate/duartes_air_conditioner/swing_mode/state",
  "swing_modes": [
    "off",
    "both",
    "vertical",
    "horizontal"
  ],
  "name": "Duartes Air Conditioner",
  "avty_t": "duarte-air-conditioner/status",
  "uniq_id": "ESPclimateduartes_air_conditioner",
  "dev": {
    "ids": "d8bc38b02037",
    "name": "Duartes Air Conditioner b02037",
    "sw": "2025.3.1 (Apr  3 2025, 14:22:09)",
    "mdl": "esp12e",
    "mf": "Espressif",
    "cns": [
      [
        "mac",
        "dabcabcb0037"
      ]
    ]
  }
}

In openhab auto discovery I see a Swing_step instead of swing_mode for example.

And the “Preset Mode” there’s also some weird behavior there, because there’s no “off” option.
If I turn on boost, I can’t switch it off afterwards, I’m stuck between those four modes and I can’t turn them off.
“boost”,
“eco”,
“sleep”,
“freeze protection”

With the esphome binding if I sent the command again, iirc, it would turn it off, but it’s not working the same way. I added a command option, and send “off” but I get this error:
[ERROR] [nal.common.AbstractInvocationHandler] - An error occurred while calling method ‘ThingHandler.handleCommand()’ on ‘org.openhab.binding.mqtt.homeassistant.internal.handler.HomeAssistantThingHandler@2ec4cc2f’: Value Off not within range

So I’m a bit confused. With esphome, I was using this component and it functionally works very well, maybe there’s an explanation there?