MQTT Binding - txt based configuration issues

Add-ons Bindings
1

Hm, right now i try to migrate my 2.5.12 installation from MQTT1 to MQTT2. More or less the work to do is clear. but i have several issues.

1.) I configured three bridges…but only one is shown in the logs. Why?
but all three are shown ONLINE in paperUI.

2.) I’m lost regarding the structure thing-channel-type
- sometimes Channel: is part of the structure, sometimes not,

  • sometimes its Thing topic XXX, but sometimes its mqtt:topic:xxx

in the end right now bridge cloudmqtt and venusgx seem to work, but whatever i do the Tradfri switch does not work as required…

at the moment with all the different styles i tried, the following error is shown - reason seems to be the Thing…structure.

2021-04-22 15:55:51.265 [INFO ] [el.core.internal.ModelRepositoryImpl] - Validation issues found in configuration model 'mqtt.things', using it anyway:
Provide a thing type ID and a thing ID in this format:
 <thingTypeId> <thingId>

Bridge mqtt:broker:mosquitto [ host="192.168.1.xxx",port=xxxx,secure=false,clientID="openhab" ] {
    Thing mqtt:topic:z2m {
    Channels:
        Type string : TradfriSwitch02 "TradfriSwitch#02 [%s]" [ stateTopic="/z2m/Tradfri_Switch02/action" ]
    }
}

Bridge mqtt:broker:cloudmqtt [ host="farmer.cloudmqtt.com",port=asdf,secure=true,username="xxxxx",password="xxxxxx",clientID="openhab0815" ] {
    Thing topic ev {
    Channels:
        Type number : EVchargePower "Charging Power [%.1f W]" [ stateTopic="/MyMiEV/SENSOR", transformationPattern="JSONPATH:$.ENERGY.Power" ]
        Type number : EVchargeVolts "Voltage [%.1f V]" [ stateTopic="/MyMiEV/SENSOR", transformationPattern="JSONPATH:$.ENERGY.Voltage" ]
    }
}

Bridge mqtt:broker:mivenusgx [ host="192.168.1.98",port=34543,secure=false,clientID="openhab" ] {
    Thing topic victron {
    Channels:
        Type number : PowerTotal "Power total [%.1f W]" [ stateTopic="N/0c1c57111e38/grid/30/Ac/Power", transformationPattern="JSONPATH:$.value" ]
        Type number : VeBatSoc "LiFePo4 SoC [%d %%]" [ stateTopic="N/0c1c57111e38/system/0/Dc/Battery/Soc", transformationPattern="JSONPATH:$.value" ]
        Type number : VeBatSocLimit "LiFePo4 SoC Limit [%d %%]" [ stateTopic="N/0c1c57111e38/settings/0/Settings/CGwacs/BatteryLife/SocLimit", transformationPattern="JSONPATH:$.value" ]
        Type number : VeBatState "LiFePo4 State [%d]" [ stateTopic="N/0c1c57111e38/settings/0/Settings/CGwacs/BatteryLife/State", transformationPattern="JSONPATH:$.value" ]

    }
}
2

I link this for anyone upgrading from v1 to v2 - there’s a specific migration guide:

1 Like
3

This Thing “belongs” to the Bridge whose braces { } it is inside. That auto assigns a uid like mqtt:topic:cloudmqtt:ev

You can assign your own uid, for example if this Thing is not defined in the braces { } of a Bridge, say in a different file. (But then you must spell out the “owning” Bridge of course)

I don’t know what happens if you do both at once, bad things probably.

4

You might have an easier time of it configuring it though the UI. That will eliminate all possibility of syntax errors and the like. Then, if necessary, you can look at the code tab of the Thing and transfer the definition to a .things file.

1 Like
5

OK thanks - i now get it. so if its in the broker area its already pre-selected and can be Thing Topic …
which of course is the way how the things-file is accepted in the logs.

However, still my simple TradfriSwitch does not work at all. from all the discussions here in the community ot should look like this. MQTT delivers the following messages:

/z2m/Tradfri_Switch02 {"action":"on","battery":74,"click":"on","linkquality":0,"update":{"state":"available"},"update_available":true}

Thing+Channel looks like this:

    Thing topic z2m "zigbee2mqtt" {
    Channels:
        Type string : TradfriSwitch02 "TradfriSwitch#02 [%s]" [ stateTopic="/z2m/Tradfri_Switch02/action" ]
    }

and the item itself looks like this:
String TradfriSwitch02 "TradfriSwitch#02 [%s]" <remote> { channel="mqtt:topic:mosquitto:z2m:TradfriSwitch02" }

I hope that someone sees the mistake i make when defining. In PaperUI it looks like as it should be from the linking’s point of view…so thing has channel, channel is linked to an item…

Kind Regards, and many thanks…

Update - in the meantime tried this - also without success:
String TradfriSwitch02 "TradfriSwitch#02 [%s]" <remote> { channel="mqtt:topic:z2m:TradfriSwitch02:action" }

6

Update2 - looks like i fixed it by:


        Type string : TradfriSwitch02 "TradfriSwitch#02 [%s]" [ stateTopic="/z2m/Tradfri_Switch02", transformationPattern="JSONPATH:$.action" ]

What i do not get is how others are successful with the syntax written above and in my case this does not work at all.

7

What syntax? You mean
stateTopic="/z2m/Tradfri_Switch02/action"
That’s pretty straightforward. That would listen to topic /z2m/Tradfri_Switch02/action, and whatever came as payload to that topic gets passed down the channel.
Messages on topic /z2m/Tradfri_Switch02 will be ignored, no topic match.

8

No, what i mean is that i have two switches zigbee Tradfri - via zigbee2mqtt that provide the following MQTT publishs:


topic '/z2m/Tradfri_Switch02', payload '{\"action\":\"on\",\"battery\":87,\"click\":\"on\",\"linkquality\":15,\"update\":{\"state\":\"available\"},\"update_available\":true}'"} /z2m/Tradfri_Switch02 {"action":"on","battery":87,"click":"on","linkquality":15,"update":{"state":"available"},"update_available":true}

topic '/z2m/Tradfri_Remote05', payload '{\"action\":\"toggle\",\"battery\":60,\"linkquality\":3,\"update\":{\"state\":\"idle\"},\"update_available\":false}'"}
/z2m/Tradfri_Remote05 {"action":"toggle","battery":60,"linkquality":3,"update":{"state":"idle"},"update_available":false}

The first one (02) works perfectly with the following channel:

Type string : TradfriSwitch02 "TradfriSwitch#02 [%s]" [ stateTopic="/z2m/Tradfri_Switch02",
 transformationPattern="JSONPATH:$.action" ]

The second one not…

Type string : TradfriRemote05 "TradfriRemote#05 [%s]" [ stateTopic="/z2m/Tradfri_Remote05", transformationPattern="JSONPATH:$.action" ]

…and after so many tries i do not see what goes wrong as the message structure is completely the same.

SideNote - in MQTT1 it looked like this and of course worked:

String TradfriSwitch02 "TradfriSwitch#02 [%s]" <remote> { mqtt="<[mosquitto:/z2m/Tradfri_Switch02:state:JSONPATH($.action)]" }


String TradfriRemote05 "TradfriRemote#05 [%s]" <remote> { mqtt="<[mosquitto:/z2m/Tradfri_Remote05:state:JSONPATH($.action)]" }
9

Thought you said you’d fixed it, or are we on a new problem?

Is probably the clue. Many of the bindings have trouble picking up small edits in xxx.things files.
If you think you now have a thing definition correct, restart the binding to be sure only that is in use.

10

Thanks a lot, I finally fixed it.

I did a mistake in the item declaration to add again the attribute like “battery” in the item. but its already coverred in the channel definition…so not required at all in the item.

I now try to transfer the following item:
Switch LockON "NG5 Lock Close" <"lock-closed"> (SmartLOCK) {mqtt=">[mosquitto:/smartlock/lockaction:command:ON:1]"}

I’ve looked in the community but only can see variants that use a seperate map file. But i believe that there should be a more efficient way to not require an additional mapping file, similar to what i did before in MQTT1.

Can you please help me to transform this item?
Thanks a lot
Norbert

11

This is version 1 syntax, and will not work with the current Things & channels based bindings. Do take context into account when copy/pasting from old posts.

12

Thanks, of course i know its MQTT1, but i try to bring it into MQTT2 without the need to use a mapping file. right now all searches here are using map files, which i guess is overkill and not required, i only do not know how to rewrite the listed example into MQTT2.

I right now try this syntax… Type switch : LockON “NG5 Lock Close” [ commandTopic="/smartlock/lockaction", on=“1” ]

13

Ah, I misunderstood. If you look at the binding documentation you will see that it also includes what you might call “mini transformations” for certain channel types, like on="1"

14

seems to work, thanks. commandTopic obviously does the “publish” part…
I really start to like to MQTT2 binding.