Generic MQTT Thing throws warning in logs

Hello
I have the following thing:

Thing topic EG_WZ_plug4 {
Channels:
   Type switch : light "some description" [
     commandTopic="home/commands/MQTTto433",
     stateTopic="home/433toMQTT", 
     on="4215121",
     off="4215124"
   ]
}

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

Is there some mistake in my thing config?

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.

Using capital On or Off breaks the things. They don’t react anymore to the topic as soon as there gets a number pushed

What version of OH are you on and do you have MAP transformation installed?

latest stable (2.4.0-1) and yes, map transformation seems to be installed:

openhab> bundle:list |grep -i transform
111 │ Active   │  80 │ 0.10.0.oh240           │ Eclipse SmartHome Transformation Service
214 │ Active   │  75 │ 0.10.0.oh240           │ Eclipse SmartHome Exec Transformation Service
215 │ Active   │  75 │ 0.10.0.oh240           │ Eclipse SmartHome JavaScript Transformation Service
216 │ Active   │  75 │ 0.10.0.oh240           │ Eclipse SmartHome JSonPath Transformation Service
217 │ Active   │  75 │ 0.10.0.oh240           │ Eclipse SmartHome Map Transformation Service
218 │ Active   │  75 │ 0.10.0.oh240           │ Eclipse SmartHome RegEx Transformation Service
219 │ Active   │  75 │ 0.10.0.oh240           │ Eclipse SmartHome Scale Transformation Service
220 │ Active   │  75 │ 0.10.0.oh240           │ Eclipse SmartHome XPath Transformation Service
221 │ Active   │  75 │ 0.10.0.oh240           │ Eclipse SmartHome Xslt Transformation Service

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:

  • 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” :wink: 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.:wink:

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)

2 Likes

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. :grinning:

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… :wink:

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. :laughing: 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. :upside_down_face:

Mhm, REGEX, right… love it… not! :smiley:

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.