Status topic of dimmer command

[lobradov]

It would make sense to create a separate status topic for a Dimmer/Color command.

Currently, this is what happens:

cmnd/sonoff/POWER OFF
--> stat/sonoff/RESULT {"POWER":"OFF"}            -- generic result of a command
--> stat/sonoff/POWER OFF                         -- power status

but in Dimmer case, we only get back a generic result of a command containing all the necessary details.

cmnd/sonoff/Dimmer = 56
--> stat/sonoff/RESULT = {"POWER":"ON", "Dimmer":56, "Color":"1A0B048E"}

Apart from being inconsistent, it creates problems for parsing, as some platforms (Home Assistant) don't have conditional parsing (if topic content is in format XYZ, than consider it as status change for light object ABC), or at least I haven't been able to make it work. Best I could do is to force Home Assistant to parse every RESULT, which leads to a lot of error messages in the logfile, as most of the RESULTs don't have Dimmer and Color fields.

Additional problem is that RESULT can't be retained, which means that every restart/failover looses a last known state (RESULTs shouldn't be retained with a good reason, btw, but we need another indication of status).

I can provide a patch for Dimmer/Color only, but am wondering if there are other cases that I'm personally not using, that have similar inconsistency problem?
@arendst - what's your take?

[arendst]

This is the result of a long discussion about multiple replies after doing a power on, changing color or dimmer values.

The result of these commands always lead to multiple changes like changing dimmer will also change color value and might change power if it was on or off.

[lobradov]

Why not have have a

cmnd/sonoff/POWER = ON | OFF
--> stat/sonoff/RESULT = { POWER: ON | OFF } 

cmnd/sonoff/Dimmer = <int>
--> stat/sonoff/RESULT = { Dimmer: <int> } 

cmnd/sonoff/color = 4xHEX
--> stat/sonoff/RESULT = { Color: 4xHEX } 

As commands take a single value, RESULT would provide a result to that particular command only, making it consistent with rest of the command set.

However, each change would also generate a message to another topic that can be retained and saves a value of overall light object:

stat/cmnd/Light = { POWER: ON | OFF, Dimmer: <int>, Color: 4xHEX } 

Would that make sense?

[lobradov]

So, I got it working with the PR I submitted and following Home Assistant configuration:

platform: mqtt
name:                       "Magic Home LED controller"
command_topic:              "cmnd/magic_home/POWER"
state_topic:                "stat/magic_home/POWER"
brightness_command_topic:   "cmnd/magic_home/Dimmer"
brightness_state_topic:     "stat/magic_home/LIGHT"
on_command_type:            "brightness"
brightness_value_template:  "{{ value_json.Dimmer }}"
payload_on:                 "ON"
payload_off:                "OFF"
brightness_scale:           100
qos:                        1
retain:                     true

To get on/off status, you can also use:

state_topic:            "stat/magic_home/LIGHT"
state_value_template:   "{{ value_json.POWER }}" 

Matter of taste, I guess ;)

[bensuffolk]

I was looking at this and to me it would make more sense for the RESULT to show the other status its updated, so for instance a change to DIMMER, POWER, COLOUR or CT would always return this:

stat/sonoff/RESULT = {"POWER":"ON", "Dimmer":56, "Color":"1A0B048E", "CT":"500"}

I have made this change, and implemented it in such a way that any driver interface can pass a full set of data to the RESULT for a POWER command, so it extensible in the future if other drivers want to do the same.

Happy to submit a PR for @arendst to merge, or I can make some changes to it if this is not liked. My copy is at https://github.com/bensuffolk/Sonoff-Tasmota.

BTW I only came across this after my implementation, and I saw nothing about LIGHT command in the wiki.

Regards

Ben

[arendst]

I'm looking at hass these days and I donlt know why people have that many problems with it...

I've currently the mqtt discovery running for switch and light with functional dimmer and no additional light fix. Just make sure tasmota always replies with RESULT (setoption4 0) and let hass check json responses.

Main problem with discovery is the enormous amount of mqtt data to send resulting in almost 2k ram loss only to send an initiall discovery message. Ram loss will be fatal over time. Currently in testing.

[bensuffolk]

I admit to only just installing HASS last week, so don't pretend to know loads about it, but did notice that when you use a template to read the brightness values in from a state, because the POWER sends back on the same topic and does not include the brightness there is an error in parsing the template.

Thats why I thought it would be a good idea to make sure all states could be updated via a single MQTT payload when something changes. After all they are all interlinked. So if you change a CT it affects the COLOUR, if you change COLOUR it can affect both DIMMER and CT. So it good for HASS (or whatever you use) to know the correct state of all the attributes of the light.

EDIT: Just looked at the MQTT Discovery in HASS, and I see you would have to send quiet a lot in the payload to set it up because of all the settings that need overriding for the topic states etc. I can see discovery being quiet nice for some users long term to have a plug and play type device, but it would not feature on my must have list.

[arendst]

I've extended the color information with the CT value as it was missing and noted by @bensuffolk. I've also redesigned the MQTT message size problem by allowing up to almost 900 characters in a message enough for Hass discovery to notice something ;-). For Hass I had to make some changes to the color command too (needs decimals values which were there but not advertised as it's a bit tricky). These are the current discovery messages:

For a two color cold/warm led:

homeassistant/light/led1/config {"name":"Led1","command_topic":"cmnd/led1/POWER","state_topic":"stat/led1/RESULT","value_template":"{{value_json.POWER}}","payload_off":"OFF","payload_on":"ON","availability_topic":"tele/led1/LWT","payload_available":"Online","payload_not_available":"Offline","brightness_command_topic":"cmnd/led1/Dimmer","brightness_state_topic":"stat/led1/RESULT","brightness_scale":100,"on_command_type":"brightness","brightness_value_template":"{{value_json.Dimmer}}","color_temp_command_topic":"cmnd/led1/CT","color_temp_state_topic":"stat/led1/RESULT","color_temp_value_template":"{{value_json.CT}}"}

For a RGB led:

homeassistant/light/wemos6_2/config {"name":"Wemos6b","command_topic":"cmnd/wemos6/POWER2","state_topic":"stat/wemos6/RESULT","value_template":"{{value_json.POWER2}}","payload_off":"OFF","payload_on":"ON","availability_topic":"tele/wemos6/LWT","payload_available":"Online","payload_not_available":"Offline","brightness_command_topic":"cmnd/wemos6/Dimmer","brightness_state_topic":"stat/wemos6/RESULT","brightness_scale":100,"on_command_type":"brightness","brightness_value_template":"{{value_json.Dimmer}}","rgb_command_topic":"cmnd/wemos6/Color","rgb_state_topic":"stat/wemos6/RESULT","rgb_value_template":"{{value_json.Color}}"}

I'll release the (experimental) Hass driver soon. It's experimental as Hass keeps on logging error messages regarding color values which I currently cannot explain.

[bensuffolk]

Some of those commands like payload_off etc are optional and tasmota uses the defaults so if you needed to save some space in the message / code you could miss them out.

[Zixim]

@arendst , in both discovery messages you mention :
"value_template":"{{value_json.POWER2}}"
shouldn't that be
"state_value_template":"{{value_json.POWER2}}"

I am a total noob at this, so chances are that i'm mistaken 😸

[siege801]

Hi everyone,

I know this is an old issue, but I lost of track of how it ended up being resolved. I have a number of flashed sonoff bulbs that I can turn on and off in hass, but I'm trying to figure out how to interface with the brightness level. When I change the brightness on the bulb's web interface, the console just produces a RESULT line with all of the attributes listed. This seems to be what was being discussed above. Is there a solution?

Thanks in advance.