MQTT binding for updates from Tuya dimmer

Setup, Configuration and Use Installation
1

I have a Tuya dimmer with Tasmota firmware.

Binding the Power ON/OFF works fine. As response to some command changing the power I receive messages on two topics:

22:58:39 MQT: stat/tuya-1/RESULT = {"POWER":"ON"}
22:58:39 MQT: stat/tuya-1/POWER = ON

So when I bind the power, I use “cmnd/tuya-1/POWER” as the command topic and “stat/tuya-1/POWER” as the status topic. All fine.

But with the dimmer value, that is a bit different; when I change the value by sending e.g. “42” to “cmnd/tuya-1/DIMMER” topic, it responds with:

23:02:40 MQT: stat/tuya-1/RESULT = {"POWER":"ON","Dimmer":42}

This uses the same topic as seen above in the power example, it just has a different additional “Dimmer” tag in the JSON (!) message body.

For clarity: I do NOT receive something on a topic like

23:02:40 MQT: stat/tuya-1/DIMMER = 42

So I have to live with the JSON for the time being.

For other numeric values I have already successfully used the JSONPath transformation (e.g. the RSSI value in the general status topic). But here it is different, because the Dimmer tag is not present in all messages comming on this topic; some have power and dimmer values, some only have the power value.

As a consequence I get exceptions from the transformer when the MQTT broker deliveres the messages without dimmer value.

(And, by the way, it very much seems to me that when I change a thing definition to use a different json path, the openhab.log tells me that it has read that thing-file without problems, but the changes do not come into effect until I restart openhab service. Is that expected/known behaviour?)

Anyhow: do you have any proposals how you typically would bind the result messages I listed above with the current MQTT-Binding 2.4.0? Is it okay to use JSONPath transformers in a read/write binding with a command topic and a status topic, but the transformation only applies to the status, not to the command? Or is it standard that a transformer is only applied for incoming messages?

Any help appreciated, cheers, Michael

2

It is for now, transformations for outgoing messages are coming in a future update

You could use a JAVASCRIPT transformation instead:
dimmer.js in the transformation folder

(function(payload) {
    var data = JSON.parse(payload);
    if (data.hasOwnProperty("Dimmer")) {
        return data.Dimmer;
    }
})(input)

And use JS:dimmer.js in the transformation pattern in the MQTT channel

1 Like
3

OK, the JS transformation immediately worked, when changing the dimmer value.
In that case the JsonPath transformation worked as well.

But when I only switch the power on/off and the payload does not contain a “Dimmer” value, both transformations somehow “fail”.
With “faiI” I mean I get one or more warnings to the openhab.log; they do not touch/harm the item value somehow.

The JsonPath trafo leads to two warnings, one from the transformer, one from the binding:

2019-01-16 14:15:26.882 [WARN ] [l.generic.ChannelStateTransformation] - Executing the JSONPATH-transformation failed: Invalid path '$.Dimmer' in '{"POWER":"ON"}'
2019-01-16 14:15:26.887 [WARN ] [eneric.internal.generic.ChannelState] - Incoming payload '{"POWER":"ON"}' not supported by type 'NumberValue'

And the JavaScript transformation itself is fine (returns null), it leads to only one warning from the binding:

2019-01-16 14:07:21.423 [WARN ] [eneric.internal.generic.ChannelState] - Incoming payload 'null' not supported by type 'NumberValue'

Not updating the NumberValue is important, when there is no “Dimmer” tag in the payload. It is not desirable to transform to “Undef” in a way that the numerical dimmer value is overwritten with “Undef” just because an MQTT message arrived, which wasn’t meant to update state of the dimmer anyhow. So with this respect I am fine.

My conclusion is that it cannot be solved on level of transformation, unless there was a hypothetical return value (like “DISCARD”, where the MQTT binding simply discards the message without either updating the item or logging a warning.

So is this a topic for the MQTT binding in general?

I am really eager to not pollute the openhab.log with warnings and errors in case of normal operation.

Cheers, Michael

4

Hi,

I have a similar situation, and I have installed JS Transformation and followed your instructions. when you say " use JS:dimmer.js in the transformation pattern in the MQTT channel", where in the PaperUI would I do this?

image
image1168×285 16.9 KB

thanks

5

You don’t need to do this: you can use the REGEX transformation AND the JSONpath transformation to filter out messages which don’t include the word dimmer.

Install the REGEX transformation in paperUI, then use the following for incoming:

REGEX:(.*Dimmer.*)∩JSONPATH:$.Dimmer

This prevents the transformation warnings in the logs.

1 Like
6

This seemed to work on 2.x. but not 3.0.

The Dimmer part works. but it then ignore the POWER ON/OFF and turning the switch off from the unit will not cause the OH Item to turn off.

How do you get this working on 3?

7

The Dimmer part is doing exactly what you told it to do - ignore any message that does not contain “Dimmer”.

You could make a custom transformation that parses the JSON itself, and if it finds no Dimmer payload uses the Power value to create an update. This would be a modification of @vzorglub example earlier.