Using the MQTT Event Bus for driving another OpenHAB or Home Assistant

For a number of reasons I also run a Home Assistant Instance. Personally I prefer how it deals with the IOS HomeKit. I also think it’s interesting as a platform. But my primary system is OpenHAB, where I think the community support, and all of the rules/grouping is far superior.

So while most of my devices are MQTT based, ie sensors, my alarm bridge, broadlink devices, which means I can read values in both systems simultaneously (one of the main advantages of having a mosquitto server on your network, I cannot recommend this more). But for discovered items, or hardware dependant options like xiaomi and zwave, these are tied to the physical server.

Here’s where OpenHABs MQTT Event bus comes in.

The event bus exposes every item as a state topic, and where they support interaction, command topics.

As every item is sent to the MQTT (Mosquitto) service, they can be read by Home Assistant (or something else), and equally Home Assistant can operate on items within OpenHAB.

The issue I found though, is Home Assistant requires frequent system restarts…for any configuration change, for any UI changes etc. And in doing so Home Assistant would lose the status of items posted from OpenHAB. The solution is to set the retained flag for the MQTT service.

System Setup

The MQTT Event bus is a service that is part of the MQTT v1 Binding that is currently shipping with OpenHAB 2.0 - 2.3. (I put it this way as I have seen some talk that this service may not be available with a rewritten MQTT binding, that might ship with 2.4).

It’s configuration is controlled by the configuration file mqtt-eventbus.cfg in the conf/services folder.

It has options for setting the structure of topics for all items that are controled via OpenHAB.


broker=<the name of your broker from the mqtt.cfg file>

I like to have all event bus items on an openhab topic, it makes it easy to see all the events being updated. Once set up running the following command (normally on the machine that hosts your mosquitto server will be the tools ‘mosquitto_sub’ and ‘mosquitto_pub’

Use the following command to view all of the OpenHAB items being updated:

mosquitto_sub -v -h <mqtt server> -t openhab/#
openhab/out/coffee_machine_proxy/state ON
openhab/out/coffee_machine_proxy/command OFF
openhab/out/zwave_switch_carport_lights/state OFF
openhab/out/zwave_switch_carport_lights/command OFF
openhab/out/network_raspups_online/state ON
openhab/out/network_raspups_lastseen/state 2018-12-06T08:04:42
openhab/out/zwave_serial_zstick_a5365e91_serial_sof/state 390046
openhab/out/network_playstation_online/state ON
openhab/out/network_playstation_lastseen/state 2018-12-06T08:04:45
openhab/out/alarm_connection_heartbeat/state OPEN
openhab/out/gpsgate_longitude/state 174.90318599999998
openhab/out/d1mini_garage_signal/state 72
openhab/out/d1mini_garage_uptime/state 12413153
openhab/out/zwave_switch_welcome_kwh/state 25.22
openhab/out/gf_cupboard1_uptime/state 43570
openhab/out/gpsgate_latitude/state -41.216531166666663
openhab/out/gpsgate_last_online/state 2018-12-05T03:16:38
openhab/out/br_master_uptime/state 4449780
openhab/out/cc_dr_Chromecast_Volume/state 100
openhab/out/chromecast_audio_7cf71a960cc620ff79365b5f8b581956_volume/state 100
openhab/out/network_camnvr_online/state ON
openhab/out/smsgateway_message_id/state 555
openhab/out/gpsgate_user/state 9
openhab/out/zwave_switch_central_heating_watts/state 0

As you can see, any item where the state changes, it is posted to this event bus…and if you look through these items you can see some of my zwave items (item naming standard helps here a lot)

So lets look at one item.

openhab/out/zwave_switch_coffee_machine/command ON

This is my Aeotec Zwave Smart Switch controlling my coffee machine to turn it on in the mornings.

To set this up in Home Assistant as an mqtt switch the following yaml is needed (I must say this aspect of OpenHAB is so much easier than Home Assistant…items/things and groups configuration is much simpler and logical).

# Coffeee Machine Proxy Switch for Homekit
- platform: mqtt
  name: 'Rocket'
  command_topic: "openhab/in/zwave_switch_coffee_machine/command"
  payload_on: "ON"
  payload_off: "OFF"
  state_topic: "openhab/out/zwave_switch_coffee_machine/state"
  icon: mdi:coffee

The Zwave switch status is published on the openhab/out/zwave_switch_coffee_machine/state' topic, and the device can be controlled viaopenhab/in/zwave_switch_coffee_machine/command`. And in the HA config you can see that my message for turning the switch on/off is ON and OFF.

Explosed to Homekit this item looks liek the following - something that is possible in OpenHAB I might say

But what is not currently possible is an alarm system, so this was one of the first reasons why I wanted Home Assistant to be my Homekit controller…it also just seems a little more mature/stable. I also have issues with the OpenHAB addon when my system restarts (I am docker based).

So now you have access to a zwave item that a remote system, either another OpenHAB instance, or Home Assistant instance, or any other mqtt based system can access hardware dependant zwave items.

Setting the retained flag is a broker wide setting. So for whatever reason you may want to keep existing retention system where the messages are retains or discarded as per the sending system…but you still want retention for your external OpenHAB or Home Assistant system that is fed by the event bus.

@rlkoshak Came up with a perfect solution: MQTT Eventbus and retain

The solution is to add another mqtt broker to your mqtt.cfg.

My existing broker setup is:


and now I’ve added a 2nd instance to the same broker:


Note: Both of these mqtt servers are local to my network.

The other difference is the client id and the retain flag. Then in the mqtt-eventbus.cfg I change the name of the mqtt broker to openhab-ret as per the mqtt.cfg.

Now everything on the event bus is retained. But the instances actually used by openhab from devices continue to respect their retain settings which are sent on a per message/per client basis.