MQTT Switch State: Command '1' not supported by type 'OnOffValue'

I have the following Thing configuration:

Bridge mqtt:broker:mosquitto "MQTT Broker" [
    Thing topic fireplace "Fireplace" @ "Living Room" {
            Type switch : power "Power" [

I have confirmed that the message payload being delivered to the devices/4f0a116f/state topic is:


And yet whenever the topic is updated, I see the following in openhab.log:

[WARN ] [ab.binding.mqtt.generic.ChannelState] - Command '1' not supported by type 'OnOffValue': No enum constant org.eclipse.smarthome.core.library.types.OnOffType.1

I’m confused why this is happening – I explicitly added on=1, off=0 to the Thing configuration, so I would expect that it would “just work”.

You can try with the MAP transformation.

transformationPattern="" ]

and file


Have you tried configuring through the paperUI instead?

These are string params e.g. on=“1”

I get the same warning whether I specify these as strings or numbers

Any ideas how this would work in conjunction with JSONPath? I need the JSONPath transformation in order to extract just the power field; other fields may be present and will not be static, so I can’t hard-code them in a Map.

Sure. But one way is correct and ought to work, one way is not and will never work.
You’re not the only one struggling with this feature, maybe it is broken in some versions - what version is involved here?

A caution when editing Things files, seems especially relevant for minor edits. Some bindings are better than others at managing in-flight thing changes.
I’d restart the binding after edits, to pick up new settings.

Chaining transforms is described in the binding docs. It’s a rather clever feature that only MQTT binding has, so far.

Maybe a bit OFFTOPIC but does your device react on the posted commands via openHAB? You don’t have a commandTopic in your setup!

1 Like

I think (from other similar posts) the word ‘command’ is a bit misleading in the binding’s message, and should be interpreted more like ‘payload’

To my present understanding(!) stateTopics were to be received by MQTT Things, commandTopics are to be sent.


If I think I’ve screwed up on the topic or payload type for mqtt, I run it through mqttfx where it’s easy to change both the topic and payload to see where I’ve gone wrong.

Yes. What I’m saying is that the OPs error message is produced in response to processing an incoming topic, just as he as configured, and the word ‘command’ in the error message refers in this case to the incoming payload and is a misnomer in openHABs usual terms.
There is no openHAB command involved.
Have I got it right, @ssmall ?

My question is standing, does the device react at all when the openHAB switch is triggered?
In my understanding that warning is caused by a state message sent by the device, which COULD have been triggered by…?

uhh, the device sends that. It doesn’t matter why, all the poor fellow wants to do is turn that into ON

I have encountered same problem in a similar but very common configuration. I’m using Sonoff RF Bridge to switch items. I try to define a read only channel that receives input from RF senders like Intertechno or cheap contact sensors for windows and doors.
I have configured the channel as proposed by @H102 with transformationPattern JSONPATH and MAP chained, but no working solution was found in this thread so far. Also I’m struggling to implement the MAP transformation (MAP transformation 2.5.4 is installed). My channel is:

Type switch : TestReceiver "TestReceiver (2)" [
    transformationPattern="JSONPATH:$.RfReceived.Data ∩" ]

I also tried swapping JSONPATH and MAP transformation with the same result:

[WARN ] [t.generic.ChannelStateTransformation] - Transformation service  MAP for pattern not found!
[WARN ] [ab.binding.mqtt.generic.ChannelState] - Command 'F27322' not supported by type 'OnOffValue': No enum constant org.eclipse.smarthome.core.library.types.OnOffType.F27322 is present in folder transform:


What am I missing here?

MAP , like JSONPATH, is an installable add-on

Thanks for the hint, but I checked this before.

For the sensors, I found a solution in another thread: [SOLVED] Rule to show window as open or closed when wifi contact sensor sends RF data

Now it works as:

Type contact : TestReceiver1 "TestReceiver (2)" [
        on="F27322", off="F27324" ]

without having to define a separate Map or JS transformation for each channel. So @ssmall, you should try again with your first approach. Maybe there was a handling problem or a bug in the binding, when you tried it first.

However, the warning still shows, if a code is received which is not covered by the two switch states. This will clutter my log, when I will have all sensors configured for MQTT2. So I am still open for an even better solution.

My next step will be to find a way to have a momentary button to trigger ON and OFF states, but I did not find yet a way to use system channel types with MQTT binding.

You’d be interested in REGEX with JSONPATH

(REGEX is an installable add-on as well)

not sure if you mean channel trigger option?

I had been experimenting with REGEX before so I thought it would be easy to incorporate like in the appended post. But I struggled with the channel not updating if I only change strings. Now I have created a dummy channel for which I change the name each time I want to try out a new transformation string. That way, the thing is updated every time.

I was in fact thinking about creating a channel with type system.rawbutton and [profile="rawbutton-toggle-switch"] because I wanted to avoid a rule. But after you gave me the hint, I think, it will be much easier to just create one rule, where all codes for the buttons are located and they can switch the items via sendCommand. That way I will avoid even to have items for the wall switches. But I’m getting off topic.

My working configuration for the channel now looks this:

Type contact : TestReceiver1 "TestReceiver (2-1)" [
    on="F27322", off="F27324" ]

I’m always amazed at the lengths people go to in order to avoid creating Items or rules. They don’t cost much.