Physical switch does not update my MQTT topic. Trying to connect openHAB & Home Assistant using MQTT

Hi, I’ve been experimenting with the Razberry Pro 7 on Home Assistant (HA) seeing as it’s not supported yet on openHAB. I’m also using this opportunity to have a play with the HA UI.

That being said I’m trying to bring my current openHAB zwave lights into HA and my new Razberry Pro test lights from HA to openHAB. This means I can slowly build and test a new zwave network without messing up my whole house.

I have read the following in detail but I’m getting a bit confused MQTT - How can I control devices on openHAB via Home Assistant? - #26 by InTheDark

I’m trying to do 3 things and so far I can only do 2 and I’m not sure where to go next.

  1. Control a light using the openHAB UI which updates HA :white_check_mark:
  2. Control a light using the HA UI which updates openHAB :white_check_mark:
  3. Have my physical switch update both UI’s :x:

Progress so far:

  1. I already use MQTT so I’m trying to use that to connect the instances. I have a broker thing in openhab which is connected to my local Mosquito.
  2. I then created a Generic MQTT thing for the openHAB zwave device that I wanted to control
Thing mqtt:topic:ccc "MQTT CCC" (mqtt:broker:mqtt) 
    {
        Channels:
            Type switch : state       "State"       [ stateTopic = "openhab/out/DimmerCCC/state", commandTopic ="openhab/out/DimmerCCC/command", postCommand ="true" ]
            Type dimmer : brightness  "Brightness"  [ stateTopic = "openhab/out/DimmerCCC/brightness/state", commandTopic ="openhab/out/DimmerCCC/brightness/command", postCommand ="true"]         
    }
  1. I then created the following items:
Switch SwitchCCC "CCC" (gDebug)  { channel="zwave:device:zwave:node26:switch_dimmer",
                                              channel="mqtt:topic:ccc:state" }
                                              
Dimmer DimmerCCC "CCC" (gDebug)  { channel="zwave:device:zwave:node26:switch_dimmer",
                                              channel="mqtt:topic:ccc:brightness"  }
  1. In HA I added the following configuration:
  light:
    - unique_id: 'CCC_Light'
      name: 'CCC_Light'
      state_topic: 'openhab/out/DimmerCCC/command' #received state from OH bus
      command_topic: 'openhab/out/DimmerCCC/state'
      payload_on: "ON"
      payload_off: "OFF"
      brightness_state_topic: openhab/out/DimmerCCC/brightness/command
      brightness_command_topic: openhab/out/DimmerCCC/brightness/state
      brightness_scale: '100'
      optimistic: true

My thoughts on the issue

I think it is to do with the fact that when I use the openHAB UI it publishes to the broker but when I use the physical switch it does not… if anyone could point me in the right direction I would really appreciate it as my head hurts :confused:

Try linking the openHAB zwave item to the MQTT switch channel.

If the switch is “owned” by HA, it’s HA’s job to publish the update caused by physically flipping the switch so OH can know about it. We can’t help with that here on this forum likely.

If the switch is “owned” by openHAB, it’s openHAB’s job to publish state updates it receives from the device to the MQTT state topic.

By default, MQTT will only publish when the Item receives a command. To you might need to create a rule to command the Item or separately publish the state update using the MQTT Action when Zwave updates the Item.

You could use the MQTT Event Bus Publication [3.2.0;3.4.9] and MQTT Event Bus Subscription [3.2.0;3.4.9] (merged into one rule templale for OH 4 MQTT Event Bus [4.0.0.0;4.1.0.0)). If you follow the topic patterns you’ve already established you don’t need to mess with the MQTT stuff at all and can just add your Items to one or two Groups.

For example, since the device is “owned” by OH, add SwitchCCC and DimmerCCC to both the MQTTCommand and MQTTUpdate (choose what ever names for the Groups works for you) and the publish rule will make sure both updates and commands get published. Going the other direction if HA follows the same pattern for MQTT topics the subscribe will automatically command or update the Item which matches the name in the topic.

Understood thanks. For now I’m mainly trying to get some of my openHAB connected zwave switches into HA.

The switch above is owned my openHAB. When I toggle the physical it updates the OH UI but does not appear to send the state to a topic but when I use the UI it does. That’s one thing that confuses me.

I did try this but was getting infinite loops etc so I decided to try a “simple” method on a single item first. I would of course prefer it if I did not have to create all my items as Generic MQTT things as that will be quite a job as I have over 100.

I would love to try OH4 but I’m a bit nervous as if I mess my whole house up my wife will kill me! That said suppose I could test on a spare computer.

Hi, thanks for taking the time to reply. I thought I already did this as my item posts to both the zwave channel and mqtt channel

Switch SwitchCCC "CCC"
{ channel="zwave:device:zwave:node26:switch_dimmer",
  channel="mqtt:topic:ccc:state" }

I see it now. So as long as the physical switch is updating the openHAB item, then it should be publishing to MQTT (verified using MQTT Explorer?), and HA can subscribe to the topic. You might need a rule (automation) on HA side to react to the change in topic. I run OH and HA like this for various integrations, and I use rules (and automations) frequently.

Well, even with the “simple” approach you need to understand why the infinite loop happened. As explained in Marketplace MQTT Event Bus, you need to be careful to avoid a situation where a command is published which generates an update which generates a command and so on.

One way to avoid this is the device that owns the device only publishes updates and only subscribes to commands.

  • If HA publishes an update for some reason (it shouldn’t since it doesn’t own the device, it can’t know what state it’s in) OH will ignore it.
  • If HA publishes a command, OH will receive it, command the corresponding Item which goes to the device and eventually the Item get’s updated with a new state that OH publishes to the state topic. HA receives that state update and changes it’s state for that Item.
  • If the device changes state outside of either OH or HA, OH gets that update, publishes to the state topic, and HA updates.

So OH, as the owner, only publishes updates. HA as the partner only publishes commands, never state updates.
OH, as the owner, only subscribes to commands, HA as the partner only subscribes for updates, never commands.

That prevents the infinite loop.

I’m not pushing OH 4. Just pointing out that using the event bus is a little easier in OH 4 as I was able to merge the three separate rule templates into one. But the behavior is exactly the same.

This is what is strange, I’ve used MQTT explorer to test and although the physical updates the openHAB UI switch it does not send anything via MQTT.

I then toggle in the UI and it pops up in explorer.

It’s not strange because state updates do not get forwarded to the binding. The Zwave binding updates the OH Item with a new state because you flipped the switch. But because it’s an update, the MQTT binding never sees it. MQTT will only see commands. That’s why you need a rule to trigger on the update and publish the new state to MQTT.

You could probably use the follow profile for this, but I’m not certain that will prevent infinite loops.

I see opposite behavior. A physical change at the switch to an OH zwave item (linked to an MQTT switch channel) publishes to command topic without a rule. Maybe my wires are crossed in the conversation…

I do use this in profile on item linked to MQTT channel, so maybe that impacts results:

Right, as I mentioned, the follow profile is what is converting the update to a command in this case. But that profile just does that one thing with little to no configuration options. I fear its too difficult to avoid infinite loops using it. Also, you need to configure every Item individually where the MQTT Event Bus requires less individual config.

As Rich mentioned, there could be risks associated with loops, but try using follow profile. Should make a physical change to switch publish to MQTT.

Ah ok, I understand now, that makes sense. The communication was perfect between UI’s it was just the physical switch that was throwing me.

Using the follow profile has worked! Thanks both for your input, it was driving me nuts!

@rlkoshak I’ll have another go with the Event Bus method. Many thanks for clarifying.