I still use openHAB 2.5.12-1 on an Ubuntu 18.04 virtual machine and on 8 Raspberry Pi`s with openHABian. Of course I have a look at this. This first thing I was not sure is if the Remote openHAB binding could be used as an alternative to MQTT. We are using MQTT because of different robots and two Microsoft Hololens VR glasses. Also other external self written software are using MQTT. As far as I understand the remote openHAB binding would work to use multiple openHAB instances but it does not use MQTT. With the old MQTT 1.14 binding we have also both. Multiple openHAB instances work together and different devices and software can communicate with openHAB.
Sadly the old binding does not installed again. I dont know why because I have disabled that new addons should be installed. Maybe its a problem with sudo apt-get update or other typical linux things because I thought the if the openHAB addons will not change, it should reinstall also the legacy bindings from the cache because it should not look on the remote for new updates. Since this doesn’t work that way and somehow causes problems, I was forced, willy-nilly, to update the MQTT. Unfortunately, it was a bit unsuccessful.
I hope you can help me to rebuild the same topology as before. Thanks in advance.
The old MQTT 1.X configuration
On the VM I have this mqtt.cfg:
#
# Define your MQTT broker connections here for use in the MQTT Binding or MQTT
# Persistence bundles. Replace <broker> with an ID you choose.
#
# URL to the MQTT broker, e.g. tcp://localhost:1883 or ssl://localhost:8883
MQTTBroker.url=tcp://localhost:1883
# Optional. Client id (max 23 chars) to use when connecting to the broker.
# If not provided a random default is generated.
#<broker>.clientId=<clientId>
# Optional. True or false. If set to true, allows the use of clientId values
# up to 65535 characters long. Defaults to false.
# NOTE: clientId values longer than 23 characters may not be supported by all
# MQTT servers. Check the server documentation.
#<broker>.allowLongerClientIds=false
# Optional. User id to authenticate with the broker.
#MQTTBroker.user=openhabvm
# Optional. Password to authenticate with the broker.
#MQTTBroker.pwd=Ghj%57fD
# Optional. Set the quality of service level for sending messages to this broker.
# Possible values are 0 (Deliver at most once),1 (Deliver at least once) or 2
# (Deliver exactly once). Defaults to 0.
MQTTBroker.qos=0
# Optional. True or false. Defines if the broker should retain the messages sent to
# it. Defaults to false.
#<broker>.retain=<retain>
# Optional. True or false. Defines if messages are published asynchronously or
# synchronously. Defaults to true.
MQTTBroker.async=false
# Optional. Defines the last will and testament that is sent when this client goes offline
# Format: topic:message:qos:retained <br/>
#<broker>.lwt=<last will definition>
And this is the eventbus:
# Name of the broker as it is defined in the openhab.cfg. If this property is not available, no event bus MQTT binding will be created.
broker=MQTTBroker
# When available, all status updates which occur on the openHAB event bus are published to the provided topic. The message content will
# be the status. The variable ${item} will be replaced during publishing with the item name for which the state was received.
statePublishTopic=/messages/states/${item}
# When available, all commands which occur on the openHAB event bus are published to the provided topic. The message content will be the
# command. The variable ${item} will be replaced during publishing with the item name for which the command was received.
#commandPublishTopic=
# When available, all status updates received on this topic will be posted to the openHAB event bus. The message content is assumed to be
# a string representation of the status. The topic should include the variable ${item} to indicate which part of the topic contains the
# item name which can be used for posting the received value to the event bus.
#stateSubscribeTopic=
# When available, all commands received on this topic will be posted to the openHAB event bus. The message content is assumed to be a
# string representation of the command. The topic should include the variable ${item} to indicate which part of the topic contains the
# item name which can be used for posting the received value to the event bus.
commandSubscribeTopic=/messages/commands/${item}
On the Raspberry Pis I have this mqtt.cfg`:
#
# Define your MQTT broker connections here for use in the MQTT Binding or MQTT
# Persistence bundles. Replace <broker> with an ID you choose.
#
# URL to the MQTT broker, e.g. tcp://localhost:1883 or ssl://localhost:8883
MQTTBroker.url=tcp://192.168.0.5:1883
# Optional. Client id (max 23 chars) to use when connecting to the broker.
# If not provided a default one is generated.
#<broker>.clientId=<clientId>
# Optional. User id to authenticate with the broker.
#MQTTBroker.user=openhabvm
# Optional. Password to authenticate with the broker.
#MQTTBroker.pwd=Ghj%57fD
# Optional. Set the quality of service level for sending messages to this broker.
# Possible values are 0 (Deliver at most once),1 (Deliver at least once) or 2
# (Deliver exactly once). Defaults to 0.
#<broker>.qos=<qos>
# Optional. True or false. Defines if the broker should retain the messages sent to
# it. Defaults to false.
#MQTTBroker.retain=false
# Optional. True or false. Defines if messages are published asynchronously or
# synchronously. Defaults to true.
MQTTBroker.async=false
# Optional. Defines the last will and testament that is sent when this client goes offline
# Format: topic:message:qos:retained <br/>
#<broker>.lwt=<last will definition>
The mqtt-eventbus.cfg looks like following:
# Name of the broker as it is defined in the openhab.cfg. If this property is not available, no event bus MQTT binding will be created.
broker=MQTTBroker
# When available, all status updates which occur on the openHAB event bus are published to the provided topic. The message content will
# be the status. The variable ${item} will be replaced during publishing with the item name for which the state was received.
#statePublishTopic=
# When available, all commands which occur on the openHAB event bus are published to the provided topic. The message content will be the
# command. The variable ${item} will be replaced during publishing with the item name for which the command was received.
commandPublishTopic=/messages/commands/${item}
# When available, all status updates received on this topic will be posted to the openHAB event bus. The message content is assumed to be
# a string representation of the status. The topic should include the variable ${item} to indicate which part of the topic contains the
# item name which can be used for posting the received value to the event bus.
stateSubscribeTopic=/messages/states/${item}
# When available, all commands received on this topic will be posted to the openHAB event bus. The message content is assumed to be a
# string representation of the command. The topic should include the variable ${item} to indicate which part of the topic contains the
# item name which can be used for posting the received value to the event bus.
#commandSubscribeTopic=
So in short this means that the MQTT-Broker runs on the VM and all devices use the same broker. And of course:
|Instance|Pub/Sub|Topic|
|VM|statePublishTopic|/messages/states/${item}|
|VM|commandSubscribeTopic|/messages/commands/${item}|
|Raspberry X|stateSubscribeTopic|/messages/states/${item}|
|Raspberry X|commandPublishTopic|/messages/commands/${item}|
So the subscribe and publish topics for command or for state are the same. No in or out to distinguish. The VM does update or publish the state and the Raspberry Pi`s will subscribe it. Then a command will be executed and published and the VM will subscribe it.
MQTT 2.5.12 Setup and Configuration
On the VM I have installed mosquitto and the mosquitto clients with following command:
sudo apt install mosquitto mosquitto-clients
On the Raspberry Pi`s I only installed the mosquitto clients:
sudo apt install mosquitto-clients
I will skip the installation of the binding.
On the VM I have created a thing with this configuration:
And on the Raspberry Pi`s as example a thing with this configuration:
What works is that it is online:
You can check it if you will disable or uninstall the mqtt-clients. So it is possible that you only have to use one MQTT-Broker (not the MQTT Broker things) and multiple mqtt-clients. But on each device you should have to create a thing to connect to the MQTT-Broker, as you can see above, with the external address to this one.
So if this would work, what`s my problem? My problem is that I have simply said not topics. With this configuration, one could say okay, then maybe it won’t work to connect to an external MQTT broker after all. That will probably not be the point, because the VM, where the MQTT broker runs locally, does not publish anything. Otherwise, one could have narrowed down the error and said that you would have to install an MQTT broker locally on each device and that the clients are not sufficient.
But this is actually not the normal way to build MQTT. One broker, several clients. Otherwise, you would have to create a bridge between the different brokers. Or you can create as example a mosquitto cluster.
Of course I cloned and “installed” richs [openhab-rules-tools](https://github.com/rkoshak/openhab-rules-tools) and copied it to the $OH_CONF`-folder:
cp -r rules_utils/automation $OH_CONF
cp -r mqtt_eb/automation $OH_CONF
Also I used sudo chown -R openhab:openhab automation so that the openhab user could run it:
ls -la
total 84
drwxrwxrwx 18 openhab openhab 4096 Jun 11 13:16 .
drwxr-xr-x 147 root root 12288 Jun 8 09:35 ..
drwxrwxrwx 4 openhab openhab 4096 Jun 11 13:16 automation
drwxr-xr-x 8 root root 4096 Dez 11 2020 .git
drwxrwxrwx 6 openhab openhab 4096 Jun 14 09:32 html
drwxrwxrwx 3 openhab openhab 4096 Apr 23 2020 icons
drwxrwxrwx 2 openhab openhab 4096 Jun 14 08:53 items
drwxrwxrwx 2 openhab openhab 4096 Apr 23 2020 misc
drwxrwxrwx 2 openhab openhab 4096 Apr 28 11:24 persistence
-rwxrwxrwx 1 root root 1395 Dez 11 2020 Readme.md
drwxrwxrwx 2 openhab openhab 4096 Jun 14 08:53 rules
drwxrwxrwx 2 openhab openhab 4096 Jun 1 13:28 scripts
drwxrwxrwx 2 openhab openhab 4096 Jun 2 10:40 services
drwxrwxrwx 2 openhab openhab 4096 Jun 14 08:53 sitemaps
drwxrwxrwx 2 openhab openhab 4096 Apr 28 11:24 sounds
drwxrwxrwx 2 openhab openhab 4096 Jun 14 08:53 things
drwxrwxrwx 2 openhab openhab 4096 Mai 28 14:11 transform
drwxrwxrwx 2 openhab openhab 4096 Dez 8 2020 .vs
drwxrwxrwx 2 openhab openhab 4096 Dez 7 2020 .vscode
Next, we have look in this configuration:
cat $OH_CONF/automation/lib/python/configuration.py
# The Channel ID of the MQTT Event Bus subscription channel
mqtt_eb_in_chan = "mqtt:broker:broker:eventbus"
# The name to use for this instance of openHAB, forms the root of the MQTT topic
# hierarchy.
mqtt_eb_name = "remote-openhab"
# Thing ID for the MQTT broker Thing.
mqtt_eb_broker = "mqtt:broker:mosquitto"
# Optional flag, when True all Item commands and updates are published.
# Defaults to True.
mqtt_eb_puball = True
# If the mqtt_eb_puball variable is left out or set to False,
# the next step is to add the following tags to only those Items
# that should publish to the event bus.
# eb_update Items tagged with this will have all their updates published to the event bus.
# eb_command Items tagged with this will have all ther command published to the event bus.
# Switch Foo [eb_command] // publishes only commands to the event bus
# String Bar [eb_update] // publishes only updates to the event bus
# Number Baz [eb_command,eb_update] // publishes both command and updates to the event bus
Okay, maybe mqtt_eb_in_chan is wrong.
Unfortunately, I didn’t know what to do with the items. There was the following hint in the tutorial:
Switch Foo [eb_command] // publishes only commands to the event bus
String Bar [eb_update] // publishes only updates to the event bus
Number Baz [eb_command,eb_update] // publishes both command and updates to the event bu
So of course I thought I could use [eb_update] and [eb_command] separately to rebuild my old topology. But if I use one of this inside an .items file the items (better the complete group of an item) will not shown in the sitemap. So there are any errors.
Okay, I thought I can go on and later have a check what causes the error. Then I can read in the tutorial that you have to do something like this:
Group:String PubItems_CMD
Group:String PubItems_UPD
So I have done following:
Group:String PubItems_CMD
Group:String PubItems_UPD
Group gSmartHome "Smart-Home (Fakultaet IN)" <house> (PubItems_UPD)
I hoped this would be enough. Sadly not.
Then I have created this rule for publishing:
val eb_br = "mqtt:broker:mosquitto" // Thing ID of the broker connection
val eb_name = "OpenHABVM" // <client ID>
rule "Publish commands to the event bus"
when
Member of PubItems_CMD received command // eb_cmd_gr
then
val mqttActions = getActions("mqtt",eb_br)
mqttActions.publishMQTT(eb_name+"/out/"+triggeringItem.name+"/command",receivedCommand.toString)
end
rule "Publish updates to the event bus"
when
Member of PubItems_UPD received update // eb_upd_gr
then
val mqttActions = getActions("mqtt",eb_br)
mqttActions.publishMQTT(eb_name+"/out/"+triggeringItem.name+"/state",triggeringItem.state.toString)
end
Okay at least I know that I have to remove /out/ and so on that I can use the same topic like in the old binding. At this point, however, we can dispense with subscribing for the time being and leave it out. Using the tool MQTT.fx, I have noticed that not a single topic is published. Subscribing could only work at the earliest when I would also publish something. I mean, I could be wrong, but with MQTT.fx I can scan all topics of the broker. This means that even if I have not yet adjusted the address of the Topics in the rule, I should definitely have had some Topics displayed. Unfortunately, this was not the case.
I hope I haven’t forgotten any important information. It should be detailed. Many thanks in advance.
Maybe post the full config… after reading and applying what I’ve said above.