MQTT2 and Tasmota, contact transformations don't seem to work

I’m configuring MQTT Things using a Things File and have a problem with translations when using a contact type. Both of these below don’t work.

 Type contact : Contact5 "My Door" [stateTopic="cmnd/MyDevice/POWER5", open="ON", closed="OFF"]
 Type contact : Contact5Status "My Door Status" [stateTopic="tele/MyDevice/SENSOR", transformationPattern="JSONPATH:$.Switch5", open="ON", closed="OFF"]

I’ve checked on the broker and I am getting “ON” and “OFF” as messages, and the topics are correct. In the log I get

 Command 'OFF' not supported by type 'OpenCloseValue': No enum constant org.eclipse.smarthome.core.library.types.OpenClosedType.OFF

I could just ignore the contact item, rewrite all my contact related rules, and only use switches, but it makes more sense that a door or window is either “open” or “closed” instead of “on” or “off”. The first item did work with a simple MQTT1 map file defined in the items file.

There are no such options described in the documentation

For both switch and contact channel types, on= off= apply.

That makes sense, although these still don’t work

 Type contact : Contact1Status "Door Status"       [stateTopic="tele/MyDevice/SENSOR", transformationPattern="JSONPATH:$..Switch1", on="ON", off="OFF"]
 Type contact : Contact1Status "Door Status"       [stateTopic="tele/MyDevice/SENSOR", transformationPattern="JSONPATH:$..Switch1"

I get this in the log

 Command 'ON' not supported by type 'OpenCloseValue': No enum constant org.eclipse.smarthome.core.library.types.OpenClosedType.ON

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. :expressionless: One day I’ll not be in a hurry and post a proper tutorial.

  1. Create an example Generic Thing in PaperUI with all the channels
  2. Use the REST API Docs to query for the Thing.
  3. Copy the JSON into a text editor
  4. Make all the changes for a new Thing.
  5. 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.