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.
- unique_id: 'CCC_Light'
state_topic: 'openhab/out/DimmerCCC/command' #received state from OH bus
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
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.
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.
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.
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.