Once the MQTT broker is installed and tested, it is time to integrate the protocol into Domoticz. The first step is to add the hardware in the usual fashion:

If everything is ok, the new hardware should appear at the top of the table of installed hardware and a message saying that the connection with the broker was established should flash momentarily near the bottom of the window.

Publishing Messages

What does the MQTT hardware do? It only does two things from what I can figure out. One of them is to publish messages to the MQTT broker... lots of messages.

Check it out. Open a terminal window and subscribe to all topics "#". Then turn a lamp on and off with Domoticz:

michel@hp:~$ mosquitto_sub -h -v -t "#" domoticz/out { "Battery" : 255, "RSSI" : 12, "dtype" : "Light/Switch", "id" : "0001406C", "idx" : 28, "name" : "Dresser lamp", "nvalue" : 1, "stype" : "Switch", "svalue1" : "0", "switchType" : "On/Off", "unit" : 1 } domoticz/out { "Battery" : 255, "RSSI" : 12, "dtype" : "Light/Switch", "id" : "0001406C", "idx" : 28, "name" : "Dresser lamp", "nvalue" : 0, "stype" : "Switch", "svalue1" : "0", "switchType" : "On/Off", "unit" : 1 }

Try with other switches. If you have a weather information installed, then lots of other messages will appear periodically.

Not unexpectedly, the message topic is domoticz/out and the message itself is JSON formatted key and value pairs. Presumably, an MQTT device, will subscribe to domoticz/out, will parse all incoming messages, and when it finds the correct information, it will act on it. That doesn't sound like much fun, but lets leave that for tomorrow.

Subscribing and Receiving MQTT Messages

The second thing that the MQTT hardware does is to subscribe to domoticz/in messages and process these as they come in. And how that works, we know pretty well.

Pick up the idx of a switch in the Devices table (remember how? click on the Setup tab and then on the Devices menu item.) and open a terminal window to publish an MQTT message:

michel@hp:~$ mosquitto_pub -h -t "domoticz/in" -m '{ "idx" : 28, "nvalue" : 1 }'

The icon for the Dresser lamp should reflect that it has been turned on. Furthermore, the lamp should in fact be lit and if the Subscribe terminal is still open, the following should have been received:

domoticz/in { "idx" : 28, "nvalue" : 1 } domoticz/out { "Battery" : 255, "RSSI" : 12, "dtype" : "Light/Switch", "id" : "0001406C", "idx" : 28, "name" : "Dresser lamp", "nvalue" : 1, "stype" : "Switch", "switchType" : "On/Off", "unit" : 1 }

Lets do this again, first turn off the Dresser lamp and then turn it on at 25% brightness:

michel@hp:~$ mosquitto_pub -h -t "domoticz/in" -m '{ "idx" : 28, "nvalue" : 0 }' michel@hp:~$ mosquitto_pub -h -t "domoticz/in" -m '{ "idx" : 28, "nvalue" : 1, "svalue" : "25" }'
Here is what is shown in the Subscribe terminal
domoticz/in { "idx" : 8, "nvalue" : 1, "svalue": "25" } domoticz/out { "Battery" : 255, "RSSI" : 12, "dtype" : "Light/Switch", "id" : "00014058", "idx" : 8, "name" : "Lampe sur pied", "nvalue" : 1, "stype" : "Switch", "svalue1" : "25", "switchType" : "Dimmer", "unit" : 1 }

Less Prolixity

I feel for our little Wifi modules that will have to process all these messages from Domoticz most of which will have nothing to do with a single module. How to cut down on the traffic?

One way is to change Publish Topic from "out" (called Flat) to "/" (meaning Hierarchical) in the MQTT Client Gateway... Try it (don't forget to click on the Update under the table of installed hardware). You may be surprised to see that nothing is published. The reason is that a message will be published only if the device has been placed on a floor plan.

If all the devices are not placed on floor plans then it is possible to change Publish Topic to "out + /" (called Combined) which will accomplish our goal while paradoxically increasing the total number of published messages. With this choice all messages will be published under the topic domotics/out and all messages pertaining to devices placed on a floor plan will be published again under the topic domoticz/out/${floorplan name}/${plan name} as in the following example:

domoticz/out/Top Floor/Master Bedroom { "Battery" : 255, "RSSI" : 12, "dtype" : "Light/Switch", "id" : "0001405B", "idx" : 8, "name" : "Dresser lamp, "nvalue" : 0, "stype" : "Switch", "svalue1" : "0", "switchType" : "Dimmer", "unit" : 1 }
The MQTT device in the Dresser lamp should then subscribe to the domoticz/out/Top Floor/Master Bedroom topic which will considerable diminish the number of messages it will get

If all MQTT devices are placed on floor plans then setting the Publish Topic to "/" (Hierarchical). In that case, duplication is removed, there will be no messages posted to the top level domoticz/out topic.

I find the floor plan capabilities of Domoticz a bit flaky. That is probably because of a combination of the somewhat underpowered Raspberry Pi running the server and my own impatience. Right now, I wish it would be possible to have yet another Publish Topic choice: domoticz/out/${roomplan}.

Another drastic possibility is to disable publishing by MQTT Client Gateway altogether and to use a script file. It will be possible to considerably simplify the output in that case because it will not be necessary to publish a universal JSON record.

Here is an example of a possible bash script for switches

#!/bin/sh # bash script to publish MQTT message to a switch from Domoticz # # usage: # mqtt_switches.sh idx nvalue # # examples # turn lamp with idx 28 off: mqtt_switches.sh 28 0 # turn lamp with idx 12 on: mqtt_switches.sh 12 1 DEBUG=1 if [ "$DEBUG" = "1" ] then if [ "$1" = "" ] then curl "" exit 1 fi if [ "$2" = "" ] then curl "" exit 2 fi if [ "$2" != "0" -a "$2" != "1" ] then curl "" exit 3 fi fi top="domoticz/out/switch" msg="{ \"idx\" : $1, \"nvalue\" : $2 }" mosquitto_pub -h -t "$top" -m "$msg"

The On Action and Off Action for the corresponding switch should contain something like
script:///home/pi/domoticz/scripts/bash/mqtt_switches.sh 28 1
script:///home/pi/domoticz/scripts/bash/mqtt_switches.sh 28 0
where the first parameter is the device idx number and the second is the nvalue 1 (for on) or 0 (for off).

This subject requires more thought and I will return to it as I install real MQTT hardware and decide how to go about it.

Food for Thought

While not positive, I think I read somewhere that MQTT messages are processed more quickly than HTTP requests by the Domoticz server. It might be worth investigating and if the difference is appreciable, the bash scripts used by the Heyu bridge and the Away button could be rewritten.