Inconsistent status messages for tuya dimmer

[michael-bartmann]

When changing dimmer value explicitly (e.g. command "Dimmer 42"), the result message is:

stat/sonoff/RESULT = {"POWER":"ON","Dimmer":42}

When changing the power only (e.,g. "Power ON", the same topic is used for the result, but there is no dimmer tag in the Json message:

stat/sonoff/RESULT = {"POWER":"ON"}

This is inconsistent and confuses binding the dimmer value to that topic in openHAB, because independent from the specific transformation the result message without the dimmer value triggers an update of the dimmer, but does not have a value, which results in a WARN-logging in the best case. (Worst case would be to overwrite the last dimmer value).

My expectation is that there was a Dimmer tag with the current dimmer value in every message on that topic.

Used hardware: Tuya-compatible EU clone (works more or less, fading issues are already mentioned in another thread).

Used firmware: 6.3.0/2.3.0, 6.4.1/2.3.0, 6.4.1/2.4.x, 6.4.1.8/2.5.0beta2

[ascillato2]

Hi,

Moving your issue to the already open issue.

Thanks

[digiblur]

@ascillato2 would a setoption pull request be appropriate for this? I had this issue when doing another dimmer and modified my fork to always push the power state and dimmer state after any state change of the light to fix the various issues associated with this.

[arendst]

The goal of JSON responses is that the receiver checks the names for the values and acts accordingly. If a name is missing the receiver has to handle it and should never expect a JSON message with all names provided.

This is the main advantage of JSON; it allows for sending only info which is related to the change. If power is changed the Dimmer value should have stayed the same. (Unless the owner of the driver thought otherwise and has to re-think his solution).

[digiblur]

@arendst thanks for the explanation and I do agree with how JSON should be used, but it must be one of those Home Assistant "things you don't understand" (not you literally btw). It flips out if it doesn't see the various power state topics and/or dimmer values at any light change. It's no biggie as the changes are only a few lines of code in the fork I use for the various dimmers I have plus I don't see the Martin Jerry dimmer really fitting in line with a typical Tasmota templated device with its multiple button action requirements and many status LEDs.

[chaosmaster]

@digiblur, could you explain the exact issue you're having with homeassistant?
I am using the Touch EU Tuya dimmer together with homeassistant autodiscovery and don't see any issues.

[digiblur]

@chaosmaster I don't use autodiscovery as it doesn't fit my use cases for things with the mix of HA and NodeRed, not wanting every sensor/relay in HA combined with testing stuff too much. From what I remember, if the dimmer value caused the light to change on/off states it wouldn't send the power state. Then if the switch was powered on manually, it would report the power state but not the dimming value. I also noticed the same thing with a simple PWM LED, so I changed a few lines to push the power topic and dimmer value result on any change. Works great now and simple template in HA and NodeRed.

[chaosmaster]

@digiblur just did another test in my setup:

• Turned off the dimmer using HASS
• Turned on the dimmer using Dimmer 50 in Webconsole
• HASS correctly switched back to on.

[digiblur]

Not sure if that is one of the direct scenarios but I do remember it was two of them that were specific that I had to fix for myself and a few others that were looking at the issue. I do know the dimming turning on was one of them as I changed the light driver from POWER_ON_NO_STATE to POWER_ON to correct it. Easy fix, then the other was to report the dimming value at all times.

[michael-bartmann]

I accept the explanation about the JSON semantics.

Unfortunately, this might mean I cannot bind the dimmer value with the current openHAB MQTT binding semantics in a clean way (i.e. without generating exceptions). An item is bound to a specific topic driving its state; you can provide an arbitrary transformation, but the binding tries to be updated on every message read from that topic.

If I map a non-existing JSON tag to anything, which fits the type of the item (integer in this case), it updated the item, else it throws an exception and logs it.

Maybe the openHAB binding could be enhanced to produce a kind of "MISSING_VALUE" result, where the binding engine would then silently skip the update.

My current solution uses "SetOption59 1" to generate a more-complete "tele" message on each state change. This was suggested by Philip on the SonoffUsers mailing list. This works for me with openHAB, as all the resulting JSON tele-messages have both the dimmer and the power value every time. But it "smells bad" as well; you should not be forced to use tele as state.

[digiblur]

@michael-bartmann you can try my mod I use for the dimmers I have. Look in my github repo for the Tasmota fork.

[michael-bartmann]

@digiblur I have 6.3.0.16(digiDIMv2) 2_3_0/1.5.3(aec24ac9) up and running on my tuya.
It delivers both power and dimmer values in the result.
It provides immediate tele/.. message as well (works with my current binding); maybe I change it now to use the result message instead.

[digiblur]

Yes, I use the result topic to determine the dimming level in my home automation software.