the on/off numbers are the 433mhz codes sent/received by the 433mhz gateway. The thing iteself works fine, but I get a warning every time in the logfile:
2019-11-30 14:52:18.415 [WARN ] [eneric.internal.generic.ChannelState] - Command '4215121' not supported by type 'OnOffValue': No enum constant org.eclipse.smarthome.core.library.types.OnOffType.4215121
Try using uppercase “On” and “Off” in things file. If you are on OH 2.4 you may need to restart OH after making a file change to mqtt related stuff. This bug has been fixed in updated versions.
@H102 I will try the mapping as test later, but IF this fixes the warning, this is a bug imho.
For all my 433 devices (±20 things) i don’t think it’s a “planned feature” to manage the IDs in two different locations just in order to supress the warning. An the docs states clearly:
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.
@vzorglub As the thing itself works fine, i don’t think its an “configuration error” and the paper UI has many disadvanteges imho
Have you been successful with your config? I’m facing quite similar problems as I try to switch from MQTT 1.x to MQTT 2.5.
My 433-components behave strangely when used with MQTT 2.5 - I could live with the “OnOffValue” warnings in the logfile but my items interact with each other: when I switch on one RF-device at least one of the other devices also turns on (recieves the RF-code and acts on it), the same with switching off.
I’m unter the impression that only the first thing defined in the *.things file works correctly, all the others seem to behave strangely.
Here is my things-file, only the third thing (“MQTT_FSD_D”) works as expected (apart from the warnings in the Log), it was the first thing i created in the file:
Thing mqtt:topic:flomqtt:MQTT_FSD_A "FSD 'A'" (mqtt:broker:flomqtt) {
Channels:
Type switch : state [ stateTopic="home/OpenMQTTGateway/433toMQTT", commandTopic="home/OpenMQTTGateway/commands/MQTTto433", on="1394001", off="1394004" ]
}
Thing mqtt:topic:flomqtt:MQTT_FSD_C "FSD 'C'" (mqtt:broker:flomqtt) {
Channels:
Type switch : state [ stateTopic="home/OpenMQTTGateway/433toMQTT", commandTopic="home/OpenMQTTGateway/commands/MQTTto433", on="1397841", off="1397844" ]
}
Thing mqtt:topic:flomqtt:MQTT_FSD_D "FSD 'D'" (mqtt:broker:flomqtt) {
Channels:
Type switch : state [ stateTopic="home/OpenMQTTGateway/433toMQTT", commandTopic="home/OpenMQTTGateway/commands/MQTTto433", on="1398033", off="1398036" ]
}
Thing mqtt:topic:flomqtt:MQTT_FSD_RC "FSD Alle RC-Codes" (mqtt:broker:flomqtt) {
Channels:
Type switch : state [ stateTopic="home/OpenMQTTGateway/433toMQTT" ]
}
For now I rolled back to MQTT 1.x for my RF-devices - but I’d like to move completely to MQTT 2.x
@ElwoodSC: try removing your things and item from OH, stop OH clean the cache, then rediscover them and create the thing using PaperUI. Use files for your items only and you will get the correct tag to use from the things channel in PaperUI.
If you do not want to use PaperUI for things then you will need to work out the correct syntax for each device. I’m a but hardheaded and use files for everything and will post an example of a few things and items.
Things:
Bridge mqtt:broker:pibroker "pibroker" [ host="10.0.1.19", port=1883, secure=false, username="xxxxxx", password="xxxxxx" ]
{
// Sonoffs
Thing topic sonoff11 "Living Room Light" @ "Living Room" {
Channels:
Type switch : power "Power" [ stateTopic="stat/sonoff11/POWER", commandTopic="cmnd/sonoff11/POWER" ]
Type number : temperature "Temperature" [ stateTopic="tele/sonoff11/SENSOR", transformationPattern="JSONPATH:$.SI7021.Temperature" ]
Type number : humidity "Humidity" [ stateTopic="tele/sonoff11/SENSOR", transformationPattern="JSONPATH:$.SI7021.Humidity" ]
}
Thing topic sonoff2 "Couch Light" @ "Couch Light" {
Channels:
Type switch : power "Power" [ stateTopic="stat/sonoff2/POWER", commandTopic="cmnd/sonoff2/POWER" ]
}
Thing topic sonoff55 "Office Light" @ "Office" {
Channels:
Type switch : power "Power" [ stateTopic="stat/sonoff55/POWER", commandTopic="cmnd/sonoff55/POWER" ]
}
Thing topic sonoff-7CB10D "Front Porch Light" @ "Porch" {
Channels:
Type switch : power "Power" [ stateTopic="stat/sonoff-7CB10D/POWER", commandTopic="cmnd/sonoff-7CB10D/POWER" ]
}
}
This is not nested in the broker Bridge definition, it stands alone. (maybe the broker is defined in a different file, for example)
So it has to describe which broker it belongs to (you’re allowed more than one)
Thanks for pointing this out as I have always kept my mqtt things nested as it was recommended to be the best way. I’ve also read that using more than one broker can lead to issues unless you know exactly what your doing.
I do not use RF but is it possible to a different state and command topic for each thing? If not maybe a rule could be used as a workaround to ensure the correct device is being actuated?
Yep. MQTT is not well suited for using a single topic with multiple Items.
but…
It is possible. With the use of REGEX as a filter you can stop incoming payloads trying/failing to update all Items, and just do the target Item.
It’s also possible to stuff incoming payload in a String Item and have a rule sort out which Item it is meant for - but probably not necessary now with binding 2.5
The RF Gateway has only two topics (433toMQTT and MQTTto433) which send/receive the RF-codes for the different RF-outlets. In the MQTT 1.x world I have:
As @rossko57 mentioned give REGEX a try. Personally, I would write rules any day over trying to figure out REGEX. If you have issues there are some that are very good with REGEX, just not me. Maybe one day I’ll try and tackle it.
It’s different. There are things you can do with 2 but not 1.
I’ve made an assumption that you have several actual devices and OH Items, and presumably topic Things.
And assuming the warning you see comes from a Thing that is not targeted by current payload? Are we on the right lines?
Maybe you could restructure with one topic Thing with many channels, not sure if it helps.
and the paper UI has many disadvanteges imho
If you have issues there are some that are very good with REGEX, just not me. Maybe one day I’ll try and tackle it. 
