MQTT binding not replacing {itemName}

Hi there, I am new to OpenHab community. I have installed OpenHab 2.2.0 (runtime) and Mosquitto 1.4.15 on a windows 10 desktop. mqtt binding and openhab are working fine. However the messages published are not replacing ${itemName} properly. Any suggestions ?

mqtt.cfg enteries:

localBroker.url=tcp://localhost:1883
localBroker.clientId=GH_OPENHAB
localBroker.qos=1

default.item enteries:
//GH Automation Items definitions
//itemtype itemname [“labeltext”] [] [(group1, group2, …)] [{bindingconfig}]

Group Home “GH AUTOMATION”
//Rooms
Group Garage “Garage” (Home)
Group Bonusroom “BonusRoom” (Home)
Group Hallwayoffice “HallwayOffice” (Home)

//Garage
String GH_GarageDoor_State “Door [%s]” (Garage) {mqtt="<[localBroker:GH/out/${itemName}:state:default]",autoupdate=“true”}
Switch GH_GarageDoor_Cmd “DoorCmd” (Garage) {mqtt=">[localBroker:GH/in/${itemName}:command:ON:Open],>[localBroker:GH/in/${itemName}:command:OFF:Close]"}

mosquito_sub -v -t “#” output:

GH/in/${itemName} Open
GH/out/GH_GarageDoor_Cmd/state ON
GH/out/GH_GarageDoor_Cmd/cmd ON
GH/in/${itemName} Close
GH/out/GH_GarageDoor_Cmd/state OFF
GH/out/GH_GarageDoor_Cmd/cmd OFF

(not sure… but…) I don’t think that you can use such variable in that part of the item definition…

You may have to hard code the topic like:

Switch GH_GarageDoor_Cmd	“DoorCmd” (Garage)	{mqtt=">[localBroker:GH/in/GH_GarageDoor_Cmd:command:ON:Open],>[localBroker:GH/in/GH_GarageDoor_Cmd:command:OFF:Close]"}

Hi Dim,
Thanks for quick response. I am following the documentation https://github.com/openhab/openhab1-addons/wiki/mqtt-binding
and example is using variables (3 in fact). Am I following wrong documentation ?

Example Outbound Configurations
Switch mySwitch {mqtt=">[mybroker:myhouse/office/light:command:ON:1],>[mybroker:myhouse/office/light:command:OFF:0]"}
Switch mySwitch {mqtt=">[mybroker:myhouse/office/light:command:ON:1],>[mybroker:myhouse/office/light:command:*:Switch ${itemName} was turned ${command}]"}

Event Bus Binding Configuration

I saw that, but in the example, the ${itemName} variable is being used in the transformation section of the item definition.

I have never seen this variable being used in the topic section… maybe it won’t work there (I am not sure)

[quote=“ykgoel, post:1, topic:45399”]
Hi Dim,
That will be interesting as another item defined for subscribe as follows:
String GH_GarageDoor_State “Door [%s]” (Garage) {mqtt="<[localBroker:GH/out/${itemName}:state:default]",autoupdate=“true”}"]
is able to get the message from the queue. So I doubt it will behave different for publish. I can definitely hardcode the item name here but eventually I would like to use mqtt event bus so not sure if its a limitation here.
Thanks for your suggestion and quick response.

yes, I saw that also… the variable works for inbound (sub) but doesn’t work for outbound (pub)… that’s strange :slight_smile:
maybe this case is worth a creation of an issue on github for the mqtt binding (to allow on both the use of the variables)

With Event Bus, the variable (${item}) works. Note that it is different than ${itemName}
https://docs.openhab.org/addons/bindings/mqtt1/readme.html#example-configurations-1

Thanks again Dim. Also if you can help me with one thing that’s puzzling.

I changed the variables to hardcoding as suggested in default.item file as follows:
String GarageDoor_State “Door [%s]” (Garage) {mqtt="<[localBroker:GH/out/GH_GarageDoor_State:state:default]",autoupdate=“true”}
Switch GarageDoor_Cmd “DoorCmd” (Garage) {mqtt=">[localBroker:GH/in/GH_GarageDoor_Cmd:command:ON:Open],>[localBroker:GH/in/GH_GarageDoor_Cmd:command:OFF:Close]"}

However I am not able to understand why two extra messages for topic “GH/out/GarageDoor_Cmd/State and cmd” are being getting generated ? Please see output from mosquitto - v - t “#” below. Is it expected ? Any thoughts.

GH/in/GH_GarageDoor_Cmd Close
GH/out/GarageDoor_Cmd/state OFF
GH/out/GarageDoor_Cmd/cmd OFF
GH/in/GH_GarageDoor_Cmd Open
GH/out/GarageDoor_Cmd/state ON
GH/out/GarageDoor_Cmd/cmd ON

Maybe? the remote device (the Garage Door thingy) is reporting these 2 messages to the broker after it receives the Close message?

Which device is publishing these 2 payloads to the MQTT Broker?
The first payload is obviously being published by openHAB (the “Close” message). The other 2… I am not sure.

I thought that too first but then I turned the IoT (Nodemcu with sensor) device completely off for trouble shooting. Currently only OpenHab runtime and Mosquitto broker are running and I still see these messages coming into the queue. So definitely Openhab is generating these messages but why that’s puzzling. Any pointers ?

have you configured anything in your (/etc/openhab2/services/)mqtt-eventbus.cfg ? (path on Linux… similar on Windows :slight_smile: )
this may? be the reason

No I haven’t configured anything yet in mqtt-eventbus.cfg but was planning to do that later. Right now trying to keep it simple to understand the concept.

The extra message generation is getting more and more interesting. It seems like for each item OpenHab is publishing one/two extra messages to report the state and cmd respectively.

I issued following two manual commands for mosquito and changed the switch position (openhab app on android)

C:\Program Files (x86)\mosquitto>mosquitto_pub -t “GH/out/GH_GarageDoor_State” -m “Close”

C:\Program Files (x86)\mosquitto>mosquitto_pub -t “GH/out/GH_GarageDoor_State” -m “Open”

and look at very interesting output from broker:

GH/out/GH_GarageDoor_State Close <-- Came from manual command
GH/out/GarageDoor_State/state Close <–Came from OpenHab. Topic is different
GH/out/GH_GarageDoor_State Open <–Came from manual command
GH/out/GarageDoor_State/state Open <–Came from OpenHab. Topic is different
GH/in/GH_GarageDoor_State Close <–Came from turning switch off from app
GH/out/GarageDoor_Cmd/state OFF <–Came from OpenHab. Topic is different
GH/out/GarageDoor_Cmd/cmd OFF <–Came from OpenHab. Topic is different
GH/in/GH_GarageDoor_Cmd Open <–Came from turning switch on from app
GH/out/GarageDoor_Cmd/state ON <–Came from OpenHab. Topic is different
GH/out/GarageDoor_Cmd/cmd ON <–Came from OpenHab. Topic is different

I decided to turn everything off and restart (openhab and mosquito servers) still same output. Puzzled ?

this seems like the default behavior of the MQTT-Event Bus “integration”

check the contents of the file: %OPENHAB_USERDATA%/config/org/openhab/mqtt-eventbus.config to see if anything is stored there

Thankyou so much. That did the trick.

It seems like the userdata file stored all the enteries that I was trying out with mqtt-event-bus file. Even when I commented out changes in original file this file still keeps everything. Is there a good way to cleanup userdata to reflect original entries. I just manual updated the userdata files.

Appreciated your prompt help and response. You are awesome!

1 Like

this story with the stale configs has been a pain in the @ss for many people :slight_smile:

stale configs: you edit/modify your regular config files in conf folder but some old settings remain stored in the userdata and they are not cleaned up / overwritten.

This issue has been solved recently in OH 2.

I will find the thread where Kai mentioned the fix and link it here
@rlkoshak had opened up the issue on github… i will find the link to it also

ok… here is what I remember:

There is a new setting that can be used in order to make sure that config options are updated correctly:

You should add the following within your *.cfg file that you are editing:

pid:<service.pid>

for example, for mqtt:
pid:org.openhab.mqtt

Read more here:

  1. Parameters removed from binding cfg files persist in userdata/config even after restart · Issue #396 · openhab/openhab-distro · GitHub
  2. Delete orphan configuration from ConfigAdmin by htreu · Pull Request #4216 · eclipse-archived/smarthome · GitHub
  3. MQTT config under OH2 - #50 by Kai
  4. Parameters removed from binding cfg files persist in userdata/config even after restart · Issue #396 · openhab/openhab-distro · GitHub
4 Likes

I totally missed this change. Thanks for posting! :slight_smile:

1 Like