Create a map file and add
on=“4215121”
off=“4215124”
Then refer to this transformation on your associated items. I can post an example if you like.
My item:
Switch ESP_Easy_Door "Garage Door" <door>
{ mqtt="<[pibroker:/Esp1/Door/Switch:state:MAP(ONOFF.map)]" }
My map file ( located in etc/openhab2/transform) named ONOFF.map
GPIO,13,1=ON
GPIO,13,0=OFF
1=ON
0=OFF
Or use the PaperUI thing config, no mistakes possible there. Or many less…
@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:
@vzorglub As the thing itself works fine, i don’t think its an “configuration error” 
and the paper UI has many disadvanteges imho
Correct, I think if you were to upgrade from 2.4 to 2.5M4 your current configuration may work with no warnings but you can always test both to verify.
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" ]
}
}
Items:
Switch LivingRoom_Light "Living Room Light" <light> ["Lighting"] { channel="mqtt:topic:pibroker:sonoff11:power" }
Number LivingRoom_Light_Temp "Temperature [%.1f °F]" <temp> { channel="mqtt:topic:pibroker:sonoff11:temperature" }
Number LivingRoom_Light_Humidity "Humidity [%.1f %%]" <humidity> { channel="mqtt:topic:pibroker:sonoff11:humidity" }
Switch CouchLight "Couch Light" <light> ["Lighting"] { channel="mqtt:topic:pibroker:sonoff2:power" }
Switch OfficeLight "Office Light" <light> ["Lighting"] { channel="mqtt:topic:pibroker:sonoff55:power", expire="180m,command=OFF" }
Switch FrontPorch_Light "Front Porch Lights" <light> ["Lighting"] { channel="mqtt:topic:pibroker:sonoff-7CB10D:power" }
Something I noticed with your things file, not sure how it affects OH but (mqtt:broker:flomqtt) is listed on every line.
There are (at least) two possible Thing structures
Yours -
Bridge mqtt:broker:pibroker ... {
Thing topic sonoff11 ... {
Channels:
Type switch ...
}
Your topics implicitly “belong” to that broker Bridge by being nested in it’s curly brackets.
But these topic things
Thing mqtt:topic:flomqtt:MQTT_FSD_A "FSD 'A'" (mqtt:broker:flomqtt) {
Channels:
Type switch : ...
}
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. 
Thank you for your examples - actually I started with my Sonoff-devices first and they work fine with no obvious problems:
Thing mqtt:topic:flomqtt:MQTT_POW_WZ "POW WZ" (mqtt:broker:flomqtt) @ "Wohnzimmer" {
Channels:
Type switch : state [ stateTopic="stat/pow_tv_wozi/POWER", commandTopic="cmnd/pow_tv_wozi/POWER", on="ON", off="OFF" ]
Type number : power [ stateTopic="tele/pow_tv_wozi/SENSOR", transformationPattern="JSONPATH:$.ENERGY.Power" ]
Type number : poweryesterday [ stateTopic="tele/pow_tv_wozi/SENSOR", transformationPattern="JSONPATH:$.ENERGY.Yesterday" ]
}
Thing mqtt:topic:flomqtt:MQTT_POW_WaMa "POW WaMa" (mqtt:broker:flomqtt) @ "Keller" {
Channels:
Type switch : state [ stateTopic="stat/pow_waschmaschine/POWER", commandTopic="cmnd/pow_waschmaschine/POWER", on="ON", off="OFF" ]
Type number : power [ stateTopic="tele/pow_waschmaschine/SENSOR", transformationPattern="JSONPATH:$.ENERGY.Power" ]
Type number : poweryesterday [ stateTopic="tele/pow_waschmaschine/SENSOR", transformationPattern="JSONPATH:$.ENERGY.Yesterday" ]
}
Thing mqtt:topic:flomqtt:MQTT_POW_Trockner "POW Trockner" (mqtt:broker:flomqtt) @ "Keller" {
Channels:
Type switch : state [ stateTopic="stat/pow_trockner/POWER", commandTopic="cmnd/pow_trockner/POWER", on="ON", off="OFF" ]
Type number : power [ stateTopic="tele/pow_trockner/SENSOR", transformationPattern="JSONPATH:$.ENERGY.Power" ]
Type number : poweryesterday [ stateTopic="tele/pow_trockner/SENSOR", transformationPattern="JSONPATH:$.ENERGY.Yesterday" ]
}
Thing mqtt:topic:flomqtt:MQTT_POW_Spuelen "POW Spuelen" (mqtt:broker:flomqtt) @ "Küche" {
Channels:
Type switch : state [ stateTopic="stat/pow_spuelen/POWER", commandTopic="cmnd/pow_spuelen/POWER", on="ON", off="OFF" ]
Type number : power [ stateTopic="tele/pow_spuelen/SENSOR", transformationPattern="JSONPATH:$.ENERGY.Power" ]
Type number : poweryesterday [ stateTopic="tele/pow_spuelen/SENSOR", transformationPattern="JSONPATH:$.ENERGY.Yesterday" ]
}
I decided to put my broker definition into a seperate *.things file because I didn’t want all my MQTT-things in only one file.
So i guess I have a specific problem with my RF-Bridge as I have the same state- and command-topic for multiple things.
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:
Switch SW_FSD_WoZi "Licht Wohnzimmer A" <light> (gLicht) [Switchable] {mqtt=">[esp8266: home/OpenMQTTGateway/commands/MQTTto433:command:ON:1394001], >[esp8266:home/OpenMQTTGateway/commands/MQTTto433:command:OFF:1394004], <[esp8266: home/OpenMQTTGateway/433toMQTT:state:ON:1394001], <[esp8266: home/OpenMQTTGateway/433toMQTT:state:OFF:1394004]", autoupdate="false"}
in the MQTT 2.x world I tried this - which is much more elegant…
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" ]
}
I use the state-topic to update the OH Switch even if the RF-remote is used to switch on/off a RF-outlet.
I know I could do this with rules but want to work without rules as often es possible.
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. 
Mhm, REGEX, right… love it… not! 
Thank you for your idea, maybe I need to go down that road or use rules instead of things…
What makes me wonder is that it is no problem with MQTT-1 to deal with multiple items reading and writing to the same topic but for MQTT-2.
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.
This sounds like a good idea - I’ll try that as soon as possible.
The general setup is that my RF-Brige (OpenMQTTGateway) has only two topics to work wir RF-Codes. The payload contains the received/sent RF-Code and (currently with MQTT 1.x) my items react on that payload. MQTT 2.x seems to do things differently or even have a bug when more than one things listens/writes to the same topic.
You are correct with your assumption - depending on the payload only one of my things has the correct on= or off= statement, the warning is thrown from the other things that don’t match the payload.
But I have not only the warnings but also interconnection between the things - if I send the payload for thing A it also triggers thing B which listens to a different payload. Only the thing, that was defined first works without triggering the other things.
However, I like the idea of different channels in the same thing and will see whether this brings me to my goal! I’ll report back as soon as I tried this.
I rebuilt my things-file for my RF-devices and now have semi-success. Functionality looks good, but still warnings in the log.
Current things-file:
Thing mqtt:topic:flomqtt:MQTT_FSD "FSDs" (mqtt:broker:flomqtt) {
Channels:
Type switch : fsd_a [ stateTopic="home/OpenMQTTGateway/433toMQTT", commandTopic="home/OpenMQTTGateway/commands/MQTTto433", on="1394001", off="1394004" ]
Type switch : fsd_c [ stateTopic="home/OpenMQTTGateway/433toMQTT", commandTopic="home/OpenMQTTGateway/commands/MQTTto433", on="1397841", off="1397844" ]
Type switch : fsd_d [ stateTopic="home/OpenMQTTGateway/433toMQTT", commandTopic="home/OpenMQTTGateway/commands/MQTTto433", on="1398033", off="1398036" ]
Type string : fsd_all [ stateTopic="home/OpenMQTTGateway/433toMQTT" ]
}
the corresponding items are defined as follows:
String SW_FSD_RC "RC Eingabe" { channel="mqtt:topic:flomqtt:MQTT_FSD:fsd_all" }
Switch SW_FSD_WoZi "Licht Wohnzimmer A" <light> (gLicht) [Switchable] { channel="mqtt:topic:flomqtt:MQTT_FSD:fsd_a" }
Switch SW_FSD_Lichterkette "FSD Lichterkette ('C')" { channel="mqtt:topic:flomqtt:MQTT_FSD:fsd_c" }
Switch SW_FSD_LK_Kinder "FSD Lichterkette ('D')" { channel="mqtt:topic:flomqtt:MQTT_FSD:fsd_d" }
and the warnings in the log look like this:
2020-01-09 11:50:43.507 [WARN ] [ab.binding.mqtt.generic.ChannelState] - Command '1394004' not supported by type 'OnOffValue': No enum constant org.eclipse.smarthome.core.library.types.OnOffType.1394004
2020-01-09 11:50:43.507 [WARN ] [ab.binding.mqtt.generic.ChannelState] - Command '1394004' not supported by type 'OnOffValue': No enum constant org.eclipse.smarthome.core.library.types.OnOffType.1394004
So for each defined switch-channel which listens to the command-topic I get a warning if the received payload does not match the on/off statement.
Not surprised really. Many things or many channels, same issue. Each tries to process incoming payload and warn about mis-matches.
Note it’s only a warn - I assume it does not incorrectly set your Item to UNDEF - so it’s only a nuisance.
The REGEX method I believe overcomes all that by stopping processing of payload when there is a no-match.
Well, yes. This will be a natural consequence of everything on the same topic.
The strange thing was - the first defined thing worked as I expected, could switch ON and OFF without interfering with the other things. Then, when I added more things to the same file the behaviour got wild. And the beaviour even changed slightly after I restarted OH…
Nevertheless - I guess I can live with that now, the use of channels instead of things even tidied my files further. 
As you seem to be a REGEX-expert, do you have advice for me on how to solve my problem?
Wallplug A switches ON with payload 1394001 and switches OFF with 1394004 
I am not. I merely observe how it’s been used with MQTT, with the quirky but useful feature of silently suppressing no-match.
I guess you want a REGEX for “this OR that”.