Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Status topic of dimmer command #1360

Closed
lobradov opened this issue Dec 14, 2017 · 10 comments

Comments

Projects
None yet
5 participants
@lobradov
Copy link

commented Dec 14, 2017

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 comment has been minimized.

Copy link
Owner

commented Dec 14, 2017

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

This comment has been minimized.

Copy link
Author

commented Dec 14, 2017

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

This comment has been minimized.

Copy link
Author

commented Dec 21, 2017

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

This comment has been minimized.

Copy link

commented Jan 15, 2018

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

This comment has been minimized.

Copy link
Owner

commented Jan 15, 2018

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

This comment has been minimized.

Copy link

commented Jan 15, 2018

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

This comment has been minimized.

Copy link
Owner

commented Jan 18, 2018

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

This comment has been minimized.

Copy link

commented Jan 18, 2018

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

This comment has been minimized.

Copy link

commented Feb 24, 2018

@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 😸

@lobradov lobradov closed this May 16, 2018

@siege801

This comment has been minimized.

Copy link

commented Jun 28, 2019

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.