Double check your JSONPATH
The item works if I change the channel into a switch, so presumably its not a JSONPATH problem?
Binding version in use?
However - your original examples had no JSONPATH. It’s not clear - are/did those work now?
It is possible that ON and OFF are sneaking through the transforn process as magic words, where “apple” and “orange” would not.
I have a bigger suspicion though that the order of processing the various transforms in the binding is going to cause problems.
Bit worried about that; maybe the code author just used odd wording, but … you’re not sending your Item commands, are you? I would expect a command to a Contact Item to blow up before the binding ever saw it, anyway.
I have a contact item in my setup but use MAP transformation to display the correct Open/Closed state. In mqtt2.5 could the JSONPATH be used like on=“OPEN”, off=“CLOSED” ??
If your incoming payload were in fact “OPEN” or “CLOSED” you wouldn’t mess with the on/off= at all, it’s not needed.
No, JSONPATH is used to extract a value from a JSON formatted String. The on=/off= setting on the Thing is a shortcut that makes it so you don’t have to use the Map transformation to map binary incoming values (1/0, true/false, on/off, open/closed, armed/disarmed, etc) to ON/OFF or OPEN/CLOSED for Switch Items and Contact Items.
1 Like
To clarify I’m using V2.5.0 Release Build and transitioning from MQTT1 to MQTT2. I have 2 channels that I want to use as contact items, one channel uses JSONPATH to extract the value from the Telemetry JSON which Tasmota broadcasts periodically and the other channel takes the untranslated value from the status topic. In both cases the received value is either “ON” or “OFF” This value works in both cases if I define a switch channel but NOT if I define a contact channel. I am successfully using a proxy item linked to the switch and then firing a rule as a workaround which confirms this works to a switch channel.
Assuming I’ve not missed anything It seems that sending “ON” or “OFF” to a MQTT Contact channel causes the error in the log and doesn’t work.
Correct. You cannot send ON/OFF to a Contact. You can only send OPEN/CLOSED. You need to transform the “ON”/“OFF” you are receiving to OPEN/CLOSED. I could show you in a second how to do it in PaperUI. Can’t help with .things files.
Please show me the PaperUI Method, I’ll can then experiment. I already have to use it with one of my other things due to translations not working with text files.
Choose “Open/Closed Contact” as the Channel type.
Fill in those two fields with the value you get from the message that you want to correspond with OPEN and CLOSED. So if you receive “ON”, put “ON” in the “Custom On/Open Value”
That works, thanks @rlkoshak, so the problem is translation doesn’t seem to work with a things file?
I don’t know, but there might be clues in the posts above:
There are no such options described in the documentation … For both switch and contact channel types,
on= off=apply.
And the docs
- on : An optional number (like 1, 10) or a string (like “ON”/“Open”) that is recognized as on/open state.
- off : An optional number (like 0, -10) or a string (like “OFF”/“Close”) that is recognized as off/closed state.
So did you ever try on="ON" off="OFF"?
So did you ever try
on="ON" off="OFF"?
Yes, and with a switch Item I already have on="Offline", off="Online" working.
I’m guessing the results of PaperUI and config files are amalgamated somewhere in human readable form? Maybe what is in there will give a clue?
I was thinking about that. REST API should allow you inspect the Things.
They are merged in memory. I’m pretty certain they never hit disk merged together. You can get the JSON by querying the Thing using the REST API Docs but the JSON is radically different from the .things file syntax. I don’t know how helpful it will be.
For future readers, this is why I and so many others always recommend against .things files. OP got it to work in minutes using PaperUI. I wonder how many hours have been spent so far trying to get it to work with .things files. I know we can count at least a few hours of time spent by all the people who have offered help on this thread so far.
What it needs is a means to import things files and then edit the result in PaperUI. I have a LOT of MQTT things - 48 so far and I’m nowhere near finished - I switched to config files as PaperUI was taking too long. Most of my devices are ESP’s running Tasmota so I can copy and paste a lot of it.
You can do that.
I’ve written it like four times now and I can’t find a one of them. 
One day I’ll not be in a hurry and post a proper tutorial.
- Create an example Generic Thing in PaperUI with all the channels
- Use the REST API Docs to query for the Thing.
- Copy the JSON into a text editor
- Make all the changes for a new Thing.
- Create the new Thing by submitting the edited JSON through the REST API Docs.
I created 20-30 MQTT thing like this in < 20 minutes once using the above. It works quite well and you never have syntax errors unless you mess up your edits.
PaperUI is being replaced in OH 3. I believe you will be able to do stuff like this in the UI natively without needing to resort to the REST API Docs to do it.
I don’t think you will find anyone that says you must use PaperUI for everything. But it’s not your only option.
Thanks, I must have a play with the REST API, I haven’t explored it yet.
I just took a quick look at the REST APi, looks very promising! Do you think any duff information from a config file won’t be returned by the REST APi, even if it doesn’t cause an error in the log? For that matter could I export things generated by a config file, delete the file, edit the JSON from the APi and then reimport them?
I don’t really know. I think the JSON would be returned by the REST API whether the Thing is defined using .things files or not. The Thing shows up in PaperUI and the REST API is where it get’s all the information it presents. I think you could query for the Things, delete the file, and re-import them through the REST API.
There are some gotchas to watch out for. Make double sure the Things are created with the same IDs. If not, make sure to delete all the Links on the Items prior to deleting the Things if you’ve created any Links through PaperUI. With .items files you are probably OK but I’ve seen some odd problems when Links become orphaned.
I would probably restart OH after deleting the .things files too just to make sure that everything get’s cleared out of memory. This is most likely unnecessary but it doesn’t cost much time and lets you be sure.
And for the record, the replacement for PaperUI has built in the ability to import Items from .items files natively and in some limited testing I’ve done it works very well. I would not be surprised if there is a similar capability to import Things from .things files built into that new UI as well.
2 Likes