[Solved] MQTT Command ‘0’ not supported by type ‘OnOffValue’

Hi Everyone,

I’m using OH 3.2 and external mosquitto to control my mqtt stuff…
this runs without errors my mqtt service is stable.

I have a device (rgb-bulb) with a switch channel for white mode.

it sends 0 or 1 for ON / OFF

This is the according Item:

Switch  LightWhite "White" <none>

in log I have this warning entry:

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

so I thought this should be easy to handle with a transformation in the mqtt.things configuration file:

            Type switch : white "White" [

but the problem remained

I thought maybe the logic of the conversion is inverted and tried

            Type switch : white "White" [

but the warning is still there…

I searched the forums for other solution but only found some older entries for OH 2.4 and UI-based stuff that wasn’t useful because the syntax differs - but nothing else…

maybe I’m blind and the solution is easy but I can’t find it :wink:

You have a different case for white ( in the item ) vs. White in the thing.
Or is that just a typo in your post ?

thanks Wolfgang but there is no difference… the "White" in the things definition is just the describing name while switch : white is is the channel type & name. but thanks anyway for your support :wink:

That is referring to incoming data, to narrow it down.
The channel has got a “0” and is trying to deal with it, so it looks like your JSONPATH is working.

You have not seen that documented anywhere - you can’t just go making up syntax for Thing definitions. It won’t complain, just ignore you.

Looks promising.

Reminder, small edits to xxx.things files are usually ignored by this binding until you restart it, or reboot OH.

maybe I tried this solution as second approach and my post is a bit misleading - not sure but both weren’t working, sorry - EDIT: I have corrected that in my first post now

thanks rossko maybe thats the problem… haven’t restarted during the approaches

I’ll see if this brings up a different behavior, thanks

Ok, after checking my config files several times, restarting openhab, even clearing the cache directory the warning remains :frowning:

So I had a little journey to the docs…

And I stumbled upon this example in the mqtt documentation :

Type switch : fancylamp "Fancy Lamp" [
    off="i-am-off" ]

to me this looks like if it is not converting the mqtt-string, but only changes what the item displaystate would look like?!??

If this is the case I should to find another workaround…

am I on the wrong track?? any help appreciated :wink:

I can’t help with the specific syntax on the .things file. But I can say that the on and off fields of the Channel config are intended to map the messages received to ON/OFF. So in that example, if the received message is “i-am-on” it will result in an ON update to the Item. If the message received is “i-am-off” it will result in an OFF update to the Item.

I’ve used this numerous times. One example of a working UI created MQTT Thing:

UID: mqtt:topic:mosquitto:basement_sensors
label: Basement Sensors
thingTypeUID: mqtt:topic
  payloadNotAvailable: Connection Lost
  availabilityTopic: basement-sensors/status/LWT
  payloadAvailable: Connected
bridgeUID: mqtt:broker:broker
location: Den
  - id: light
    channelTypeUID: mqtt:number
    label: Light Level
    description: null
      stateTopic: basement-sensors/light/light
  - id: temp
    channelTypeUID: mqtt:number
    label: Temperature
    description: null
      stateTopic: basement-sensors/climate/temperature
      unit: °F
  - id: humi
    channelTypeUID: mqtt:number
    label: Humidity
    description: null
      stateTopic: basement-sensors/climate/humidity
      unit: "%"
  - id: online
    channelTypeUID: mqtt:switch
    label: Online Status
    description: null
      stateTopic: basement-sensors/status/LWT
      off: Connection Lost
      on: Connected

Look at the Online Status Channel. When the device publishes “Connection Lost” as the message the Item is updated to OFF.

Ok then I’m definately on the wrong tracks - if this updates your switch state it should do the same in my case :weary:

I don’t get why I get this warning when using

            Type switch : white "White" [

I also tried to change it to a number instead of a string like:


but no changes to the warning in the log…

I think I should go to bed now :smirk:

If you haven’t gone to bed: could you share your full Things file?

And also a full sample of the JSON message sent over MQTT from the device?

Note that you cannot tell which channel is producing these warnings. Confident you are looking at the only channel that could try to process an incoming message “1” ?

Hi Guys,

first of all here’s the complete JSON


I don’t want to share the whole .things file because there are too many mqtt things in there and there was no warning before adding the new rgb-bulb thing…

this is the complete things declaration

// RGB-Bulb   
    Thing topic RGB-Bulb-01 "MQTT - RGB-Bulb-01" {
            Type switch : switch "Power Switch" [ 
            Type dimmer : dimmer "Dimmer" [
            Type string : color "Color" [
            Type colorHSB : hsbcolor "HSB Color" [
            Type string : channel "Channel" [
            Type dimmer : ct "Color Temperature" [
                min=153, max=500, step=10,
            Type switch : white "White" [

I know… but I think the bulb is new, the warning is new - it would be really mysterious if this occurs now without any other changes. I think if I would define these channels as string instead of switch the warning would be gone but that’s no solution for the problem. :thinking:

All the other Channels in this Thing definition work fine?

Yes, the ones that are in use work fine… I use
dimmer, hsbcolor, ct and switch

The parameters should be in lowercase:


Throw in a restart afterwards, or do this.


Hm, I have other working mqtt-things defined the same way (ON=“ON”) in uppercase this really shouldn’t be a problem - I also changed that twice yesterday, but I will give it another try…

thanks… I’ll be right back :wink:

The docs have the parameters in lowercase in any case.

But I can see from the previous posts you have tried this before, though do make sure the Things file is properly read each time.

I changed all my uppercase to lowercase, in the whole file now… just restarting OH…

by the way I use this mqtt.things file since OH 2.0 or 1.8 and the uppercase never was a problem… but maybe it’s deprecated now - but now the file is up to date :slight_smile:

Yes I initially struggled with these bulbs but got them to work without the “whitemode” but I would be glad to use a real white instead of a yellowish one through rgb/hsb :wink:

@hafniumzinc So, finally after restarting the warning is gone - maybe I haven’t restarted after every try yesterday… so seems to be deprecated to use uppercase for ON and OFF.

thanks a lot for all your help everyone!!

1 Like

As said before, the things file parser silently ignores made-up syntax. So it would ignore this, and default on= parameter - but by chance the payload is “ON” anyway, no error to report.
This config is broken, but the channel works despite that.

I don’t think ON= was ever supported.

1 Like