JSONPATH returning wrong type for thing with channel Type "dimmer"

Setup, Configuration and Use Beginners
, ,
1

Hi there! I’m on openHAB 2.5.1. There’s something i need to understand and I wonder if someone is willing to explain what I’m doing wrong.

On my MQTT bridge thing, I’m defining an OH Item with the channel type dimmer

    /////////////////////////////////////////
    // ZMNHDA2 Flush Dimmer (Qubino (Goap) //
    /////////////////////////////////////////
    Thing topic Rum3_Takbelysning "Z-Wave Node 005: ZMNHDA2 Flush Dimmer (Qubino (Goap)" @ "Rum 3" {
    Channels:
        Type dimmer : Dimlevel      "Level (38-1-0)"              [ stateTopic="zwave/rum-3/takbelysning/level", transformationPattern="JSONPATH:$.value", commandTopic="zwave/rum-3/takbelysning/level/set", min=3, max=100, step=1 ]
        Type switch : SensorBinary1 "Instance 1: Sensor (48-1-0)" [ stateTopic="zwave/rum-3/takbelysning/sensor_binary1", transformationPattern="JSONPATH:$.value∩MAP:bool2onoff.map"]
        Type switch : SensorBinary2 "Instance 2: Sensor (48-1-0)" [ stateTopic="zwave/rum-3/takbelysning/sensor_binary2", transformationPattern="JSONPATH:$.value∩MAP:bool2onoff.map"]
    }

When I save the things file I get the error message:

Command '0' not supported by type 'PercentageValue': Value must be between 0 and 100

If I change the channel type to number, the error won’t show.

It feels that JSONPATH is returning a string value for a dimmer type channel.

My Json data looks like this:

zwave/rum-3/takbelysning/level {"time":1583054505111,"value":0}

I have tried to chain the transformation like:

Type dimmer : Dimlevel      "Level (38-1-0)"              [ stateTopic="zwave/rum-3/takbelysning/level", transformationPattern="JSONPATH:$.value∩JS:parseInt.js", commandTopic="zwave/rum-3/takbelysning/level/set", min=3, max=100, step=1 ]

That doesn’t help though … same error message.

parseInt.js:

(function(b) {
    return parseInt(b);
})(input)

Any ideas? :blush:

2

Auto discover Things through HABmin UI using the Z-Wave binding? That is what I do and is the recommended practice for Z-Wave Things.

4

There is an issue when saving the things file. I have to rename the thing prior to saving the file to make OH recognize the changes. That made me think that I had solved the problem but I had not. I still don’t have a working solution.

Anyway, I’m really interested to learn what I’m doing wrong. (I’m aware of the Z-Wave binding, this is actually not a specific Z-wave question but MQTT) :grinning:

5

That’s what all the transformations do. It’s up to the binding if it needs to parse the string into something else - like a number for a Dimmer channel.

I’d guess it’s a binding limitation, perhaps interacting with the min/max/step parameters.

6

Thanks! Good to know.

I thought I had tried to remove the min/max/step parameters. Maybe I did but I didn’t rename the thing so the code change made no effect. Now when I tried it seems to work, e.g. I get no error message when saving the file which feels good. :grinning:

Working:

Type dimmer : Dimlevel      "Level (38-1-0)"              [ stateTopic="zwave/rum-3/takbelysning/level", transformationPattern="JSONPATH:$.value", commandTopic="zwave/rum-3/takbelysning/level/set" ]

NOT Working:

Type dimmer : Dimlevel      "Level (38-1-0)"              [ stateTopic="zwave/rum-3/takbelysning/level", transformationPattern="JSONPATH:$.value", commandTopic="zwave/rum-3/takbelysning/level/set", min=3, max=100, step=1 ]
7

An observation that many bindings do not pick up edits to Things in-flight very reliably. (“Changing the name” creates a new Thing.)
Rather than restart openHAB to force a Thing reconstruction, you can restart just the binding in question.

One the difficulties with the multiple transformation options for MQTT channels - which includes the on=/off= min=/max= etc. options - is that it’s not really clear what order they get applied in. Particularly when, as with min=/max=. they apply to both in and outbound payloads. Does it do JSON and then min/max going out? How about coming in?

I think with your clear example you should raise a github bug.
I suspect it may be an inherent limitation mixing general transforms and the “baked in” min/max etc. that cannot be resolved. In which case it should be documented.

The actual problems can always be resolved with a multi-function javascript transform (where you can do all the JSON, scaling, etc. you want in one transform)

8

Hi RRoe, thanks for the post and sorry for reviving it, but I’m getting the same error for months. It hasn’t affected stability of the system and everything seems to work but I wanted to understand it better.

As an aside, this warning is only coming when the lights are turned off. To turn them off I use the switch.sendCommand(OFF) syntax in rules and don’t use the dimmer channel to turn lights off.

You mentioned that removing the min/max/step parameters removed the warning message, but aren’t these parameters necessary to correctly interpret/set the dim value on the device? For example most zigbee bulbs expect a value between 0 and 255, so in my case the thing is defined as

Thing topic L_Hall1 @ "Wohnung" {
        Channels:
            Type switch : onoff "Birne Flur 1" [stateTopic="zigbee2mqtt/L_Hall1", transformationPattern="JSONPATH:$.state", commandTopic="zigbee2mqtt/L_Hall1/set", transformationPatternOut="JS:setLampState.js"]
            Type dimmer : dim "Helligkeit Flur 1" [stateTopic="zigbee2mqtt/L_Hall1", transformationPattern="JSONPATH:$.brightness", commandTopic="zigbee2mqtt/L_Hall1/set", min=0, max=254, step=1, formatBeforePublish="{ \"brightness\" : %s }"]
    }