MQTT items vs. topics

Setup, Configuration and Use Beginners
1

Hi,
I did read de MQTT documentation and a lot of the MQTT related forums topics. I have a working MQTT server (Openhab log:

2018-01-10 18:55:16.492 [INFO ] [penhab.io.transport.mqtt.MqttService] - MQTT Service initialization completed.
2018-01-10 18:55:16.497 [INFO ] [t.mqtt.internal.MqttBrokerConnection] - Starting MQTT broker connection 'mymqtt'

However I still don’t grasp the concept of “topic” in relation to “item”. I see a lot of examples where topic is a string with several elements, separated by “/”. E.g.:

myhome/bedroom/switch2:...

Are these references to existing Openhab items, groups etc? Or just a structure in the MQTT-context?
My goal: sending a physical switch On/Off command (COCO) through MQTT to a z-wave wall plug. This works fine without MQTT, but now I want to speed up the respons by using MQTT.

Any clarification is welcome!

2

at first, MQTT and items are two different concepts.

I guess, you’re familiar with items in openHAB and what they represent. So, with MQTT you can transport the items’ states to either another - or you can trigger your items from some external device, which can send/receive MQTT messages.

So, with that in mind, openHAB knows three different means for MQTT:

  1. mqtt-binding for items
  2. mqtt-eventbus for all itmes
  3. mqtt-action for rule-based communication

ad 1)
you can simply add MQTT-Input or MQTT-Output to an openHAB-item:

Item itemName { mqtt="<direction>[<broker>:<topic>:<type>:<trigger>:<transformation>]" }

ad 2)
you can send/receive all item states/commands from let’s say one openHAB instance to another - or use it to have a sort of persistence

ad 3)
you can send a MQTT-message depending on some rule:

publish(String brokerName, String topic, String message)

now. With the “Topic” you define the “envelope” or the “adress” to which the message will be sent. So
myhome/bedroom/switch2 could be z-wave plug you want to adress. If your z-wave plug (or gateway) understands MQTT, you should have it configured to subscribe to the Topic (again: myhome/bedroom/switch2) and it will listen to the message (e.g. ON/OFF). If your openHAB item is configured to send its state to the respective topic you plug will toggle with the commands. The other way round, if you press the physical switch and your gateway sends an MQTT message, to which topic openHAB subscribed - openHAB will change the item’s state to have both in sync.

(but I’m wondering, why you don’t just use the zwave-binding?)

3

Many thanks for your quick and clear explanation: this wil definitely help me to configure MQTT in my items! I have only one question left: what is the meaning of the slash (/) in a topic name? It clearly seperates elements in the name of the topic. Is it a kind of tree-structure, a hierarchy of topics?

My use case for MQTT is speeding things up. My z-wave lights have a delay of multiple seconds (up to 8-10) when I switch on the lights in the room. My configuration:

  • Openhab 2 on Raspberry Pi 2B (OpenHabian)
  • Razberry to communicate with z-wave devices (wall plugs are items in OH2)
  • Hue bridge + lights and tap switch (connected to OH2 and Apple Home)
  • Apple Home (without automation hub) connected to OH2 and Hue
  • The delay is when using the Hue Tap Switch. Since I don’t have an Apple Home automation hub, the Hue switch can only control Hue lights. In OH I have a rule that switches the z-wave wall plugs when a certain Hue lights is switched on/off. This works fine, except for the delay: the z-wave lights respond after a delay up to 8 seconds, sometimes more.

My assumption is that using MQTT to communicate between the Hue- en z-wave items in OH, the delay will decrease. Is that possible?
Another solution would be to control both Hue and Z-wave in OpenHab by creating a virtual switch that responds to the Hue Tap Switch.
Any recommendations in this? Your help is greatly appreciated!

4

I don’t have z-wave devices or have an apple home integrated, so I can’t say something on speed. I never heard of such long delays here in the forum… and I would imagine MQTT won’t solve fundamental network issues.
So first of all I think, you have to see the real reason behind those lags: What happens, if you trigger the zwave lights without the rule within OH2 - does it have the same delay?

5

After some testing I found out that all the lights (Philips Hue and Z-wave) respond instantaniously when switched from PaperUI: no delay. When using the Philips tap switch the Hue lights are switched directly via the Hue bridge. The delay is therefore in the chain from transmitting the new state of the HUE lights to OpenHAB and the processing of the rule (incl. communication with the z-wave controller and devices).
I read some topics about using Philips API and JSON to capture the Tap Switch actions directly into OpenHab, but they also mention delays as a result of the polling nature of that process. So my way to go is to wait for my Apple TV: that device will enabe capturing of the Tap Switch in the Home app through the automation feature: then there is no difference between Hue lights and z-wave: they all respond to the Home rules or to OpenHAB (depending on how I am going to configure the control).
Thanks for helping me on this!