Using MQTT to control remote devices on another openHAB system


(Nick Bair) #1

Do you want to control devices in a secondary location? MQTT is perfect for this. But it took me a while to figure out exactly how to set this up, so here’s an example configuration.

This example assumes the following:

  • an MQTT broker configured with the name mosquitto.
  • a working openHAB system at each location.
  • let’s call our two locations Home and Vacation, to keep things simple.

Concepts

The hardest concept for me to grasp here, was that each device actually has two separate MQTT topics–the state, and the command. If you try and use a single topic, you’ll end up with infinite loop issues.

Say you have a light switch in your vacation property. You need to define that light switch as an item on both openHAB systems.

  • On the home system, the item acts as a proxy.
  • On the vacation system, the item represents the actual switch.

But each item communicates differently via MQTT:

Inbound Topic Inbound Trigger Outbound Topic Outbound Trigger
Home state state command command
Vacation command command state state

Because the home item is a proxy, it doesn’t receive commands. Instead, we configure it to listen for state updates from the physical switch, and update its state accordingly. Meanwhile, the vacation item only listens for commands, since it doesn’t care about any state other than that of the physical switch it represents. Likewise, any command received by the vacation item is sent out via the state topic, since that’s what the home item is listening for.

I know this is confusing, but just remember this: the physical item sends status and receives commands; the proxy item sends commands and receives status.

As you go through and configure all your proxy items, this concept will start to click and you won’t have to think that hard about it.


Code Example

NOTE: This section has been edited from my original post to provide a simpler, more concise syntax relying on the defaults. If you prefer the original, more verbose syntax, see the optional section below.

First, assuming you’ve already defined your items on the Vacation system, let’s add our MQTT messaging configuration. In our example we’ll extend an existing Z-Wave switch.

On your Vacation system, edit the file items/default.items:

Switch  FrontLights_Switch  "Front Lights"  { channel="zwave:device:abcdef00:node1:switch_binary", mqtt=">[mosquitto:Vaca/FrontLights/state:state:*:default], <[mosquitto:Vaca/FrontLights/command:command:default]" }

Next, on your Home system, define a “proxy” item.

On your Home system, create the file items/vacation.items:

Switch  Vaca_FrontLights_Switch  "Front Lights"  { mqtt=">[mosquitto:Vaca/FrontLights/command:command:*:default], <[mosquitto:Vaca/FrontLights/state:state:default]" }

Optional: Verbose, Command-Specific Syntax

The above example is as simple as it gets. If you want to specify different commands and/or mappings, you can use these examples instead.

On the Vacation system, edit the file items/default.items:

Switch  FrontLights_Switch  "Front Lights"  { channel="zwave:device:abcdef00:node1:switch_binary", mqtt=">[mosquitto:Vaca/FrontLights/state:state:OFF:0], >[mosquitto:Vaca/FrontLights/state:state:ON:1], <[mosquitto:Vaca/FrontLights/command:command:MAP(binary.map)]" }

On the Home system, edit or create items/vacation.items:

Switch  Vaca_FrontLights_Switch  "Front Lights"  { mqtt=">[mosquitto:Vaca/FrontLights/command:command:OFF:0], >[mosquitto:Vaca/FrontLights/command:command:ON:1], <[mosquitto:Vaca/FrontLights/state:state:MAP(binary.map)]" }

If you’re going to follow my example, here’s the contents of transform/binary.map:

key=value
1=ON
0=OFF
ON=1
OFF=0

Some Helpful Links

Here are some links that helped me figure all of this out.


(Danny mullen) #2

Thanks looks pretty easy! Great write up!


(Rich Koshak) #3

Great posting and somewhat timely.

Another way to do this with the MQTT 1.x version binding is to use the MQTT event bus configuration. This will automatically publish and subscribe to topics freeing you from the need to put the MQTT binding config on each of the Items manually.

However, I don’t think the upcoming MQTT 2.x version binding supports an event bus mode so an approach like this will be required.


(Nick Bair) #4

Would this require unique and identical item names on both openHAB instances?

Why would they take that functionality away? Was it problematic?


(Rich Koshak) #5

Not necessarily but that would be the easiest.

MQTT 2.x is a complete rewrite of the binding to use OH 2.x architecture and concepts. It isn’t that they took it away. Either they didn’t think to implement it, it doesn’t fit with the OH 2.x architecture (this is why the MQTT Action won’t be supported with MQTT 2.X), or something like that. But the 2.x version comes with an embedded Broker (no more need for a separate Mosquitto server), automatic discovery, and Things.


(Maciej Eckstein) #6

Great article, I’m researching that subject now but in remote location I do not have OH instance.
I could install it but the problem is that hardware I control in my Vacation home (Shed in my case) does not have any binding. I control it directly from the python script. I was wondering anyone did what you did but with simple python script running on the remote end.