MQTT light: Order of packets: command_topic and brightness_command_topic #9330

lukie80 · 2017-09-08T00:04:10Z

Circumstances
I'm using auto-discovered MQTT lights (HA -> ESP8266+IR-Diode -> IR-controlled LED bulbs) and I am aware of the reasonable paradigm that the ON payload is sent alongside any other non-OFF command.

Description of problem:
The "ON" packet (command_topic) is sent after a brightness or color temperature change. For lights which ignore state changes during the OFF-state (which shouldn't be uncommon) this is a big problem.

Turning light on via brightness slider sets the brightness and then turns on the device resulting in ignoring the new brightness
Changing brightness and receiving the "ON" packet afterwards may reset brightness
Changing color temperature and receiving the "ON" packet afterwards may reset brightness

Expected:
The "ON" packet should be sent before any other command to preserve "backwards compatibility" with dumb devices.

EDIT
I was convinced by @TD22057 that reversing the packets is ideally not a good idea (it is better for devices which accept commands during OFF state). Having an option of the order would be better.

watahboy · 2017-09-09T17:28:54Z

I'm experiencing the same.

On another note upon setting full brightness makes the light stick to red and become unresponsive.

The only workaround I found was to turn down the brightness while the light is offline then to boot the light and adjust the brightness again to restore control.

esp8266+ws2812b (64 leds) fastled

TD22057 · 2017-09-14T17:35:33Z

Since different lights behavior differently, I think this should be a config flag to control when the on command is sent. If a light can handle on last, it probably works better because then the brightness and color are set correctly before it's turned on. I looked at the code and think it should be pretty easy to have either option supported.

lukie80 · 2017-09-14T18:43:14Z

@TD22057 I see your point. First send desired settings and then activate. Reasonable. Otherwise "Set course to Earth, warp 9, engage." would be dangerous. I suppose Philips Hue accepts settings during the OFF state.

Should also all settings (Color temperature, RGB, Effects) be also visible in Hassio even if the light is OFF?

TD22057 · 2017-09-14T19:45:33Z

@lukie80 No idea. I don't actually own any of these lights - this just seemed like a bug I could help with. It's easy enough to make the sending code handle either style (on before settings or on after after settings). If you still want that let me know and I'll work on putting it in.

lukie80 · 2017-09-14T21:17:42Z

@TD22057 Thank you very much for the offer. I think it could help others having this option #2161, HA forum in particular because implementing the option to not always send the ON packet was rejected (#2161, pre-last comment). In the meantime I've expanded my program on the ESP8266 to ignore command_topic=ON if the state of the light is already ON, so I'm fine now. So maybe waiting for more feedback on this topic?

PianSom · 2017-09-25T07:50:51Z

@TD22057 It would really help to have this option. The same issue has been raised on #7810

It would be great if you can work to add a config flag to send the state before the option.

TD22057 · 2017-10-06T03:36:48Z

FYI - I have an initial cut at this implemented. You can grab the file here: https://github.com/TD22057/home-assistant/blob/mqtt_light/homeassistant/components/light/mqtt.py

I added a new configuration option to the mqtt light (not the template or json version):
send_on_with_change: 'AFTER' / 'BEFORE' / 'NONE'

Here's the scenarios:

1) click on:  
   send ON
2) click off: 
   send OFF
3) change brightness (or color)
   if config is BEFORE:
       send ON, send BRIGHTNESS
   else if config is AFTER:
       send BRIGHTNESS, send ON
   else if config is NONE:
       send BRIGHTNESS

So here is a question for you: If you have a light that's off, and you click the on button, what should happen? Currently, the way the MQTT light works, it just send an ON command. But what if you adjusted the brightness to 50% and turned it off? When you click on, HASS assumes the light is turned on to 50% and doesn't send a brightness command, it just sends the on command.

If I understand your hardware correctly, sending ON is like saying "set brightness to 100%, turn on". In that case, it seems like if the input config is NONE, turning the light on should actually just send a brightness command, not an on command. Does that sound right?

PianSom · 2017-10-06T06:23:17Z

@TD22057 - thanks for your work here!

The best way to understand my hardware is to consider that sending "ON" is functionally identical to sending "set brightness 100%", and sending "OFF" is functionally identical to sending "set brightness to 0%". They're just shortcuts, if you like. (This makes it clear why the current code doesn't work for me.)

If one adopts that paradigm, then the answers to your questions become obvious: in the first case HASS need make no assumption about the existing state since adjusting to 50% then turning off is the equivalent of adjusting to 0%. Sending an ON command at that point will set the brightness to 100%.

And in the second case, there is no difference between sending a "brightness 100%" and an "ON" command.

However, that's just my hardware. :)

I can live with the BEFORE case, since the hardware reaction time is quick/slow enough that "ON, brightness 1%" will just give me a very dim light without a noticeable bright flash. Though the NONE is better for me, of course.

TD22057 · 2017-10-07T02:58:41Z

OK - I reworked it a little bit - try this one: https://github.com/TD22057/home-assistant/blob/mqtt_light/homeassistant/components/light/mqtt.py

I changed the configuration input - it's now:

on_command_type: 'FIRST' or 'LAST' or 'BRIGHTNESS'

If on_command_type is 'FIRST', the on command is sent before the style (brightness, color) commands. If on_command_type is 'LAST', it's sent after (the current behavior) the style commands. If on_command_type is 'BRIGHTNESS', then the brightness command is used to turn the light on (the "ON" packet is never sent at all). It will still send the brightness command along w/ the colors but it should be the same value as before so I think that's ok.

I think that's what you want. But - one last question: if it never needs to send the ON command because it's using brightness, should it still send an OFF command? Or should that be sent as a brightness = 0 command?

PianSom · 2017-10-07T11:02:22Z

Hi

For my configuration, sending a brightness of 0 exactly equates to turning off, so I am ambivalent.

(Just for completeness, if from an off position I - via mosquitto_pub - set a brightness of 1 (% in this case) then I see status messages posted confirming the new brightness and the status being "on". If I publish a request to set brightness to 0 then I get both the new brightness of 0 and an "off" status. If - instead of the latter - I publish an "off" then exactly the same statuses (0/off) are returned.)

Philosophically, I guess I would prefer an OFF command to mean OFF rather than brightness zero - it just feels a bit safer!

I haven't yet had a chance to try your code, having been away. I'm back now and will try over the weekend. I am a hassbian user - my guess is I need to replace
/srv/homeassistant/lib/python3.4/site-packages/homeassistant/components/light/mqtt.py
and change DEFAULT_ON_COMMAND_TYPE on line 62 to "BRIGHTNESS"

is that right?

TD22057 · 2017-10-07T14:41:36Z

Note quite. Make sure you're on the latest version, copy down the updated light/mqtt.py file and replace it (keep a copy of the original though). Then edit your config file to add on_command_type = 'BRIGHTNESS' to any light you want to control that way and restart hass.

Once I get the unit tests updated, I'll send a push request to include this and close the issue.

PianSom · 2017-10-07T15:26:31Z

OK, I'm on 0.52.1 at the mo, so will update this weekend.

PS I'm assuming you mean
on_command_type: 'BRIGHTNESS
to the light config. Shout if not! :)

PianSom · 2017-10-08T11:58:18Z

Hi - so I updated to the latest version (which has just changed to 0.55), replaced mqtt.py, and added BRIGHTNESS to one of my lights.

It works perfectly - thanks so much! :)

PianSom · 2017-10-08T12:30:55Z

Can I ask a cheeky follow-up question, now that I can control brightness - I see that the Light module supports 'transition' - a time in seconds to make the transition to a new state. Does your mqtt code support this?

For my particular setup (using https://github.com/the1laz/cgateweb), I can pass two arguments to my mqtt brightness publication - brightness, time - where brightness is an integer (0-100 in percent), and time is a string eg 4s, 5m

I am guessing that there are too many varieties of implementation to make this an easy coding exercise.

TD22057 · 2017-10-08T22:38:49Z

I see that the docs say it supports transitions but the code has no mention of that work anywhere so I don't know what it means. I think you can implement that using the MQTT template light by saying something like {{brightness}},5s.

I actually think your original problem should have been solvable w/ the template light. But I think there is also a bug in the MQTT template light in that it only fills in the brightness value if brightness is being changed, not when it's just clicked on. It looks to me like the MQTT template light has some problems - it passes a dictionary of the values to fill in the templates but it only fills the keywords that are being modified. So when I said:

  - platform: mqtt_template
    command_topic: "test/light2/bright"
    command_on_template: "{{ brightness|d }}"
    command_off_template: "0"
    brightness_command_topic: "test/light2/result/bright"
    brightness_template: "{{ value }}"

I think it should have sent a test/light2/bright = X message to turn the light on and a test/light2/bright = 0 message to turn the light off. But since I wasn't changing brightness, the on message is blank. I made a quick mod to mqtt_template.py to fix that and it works perfectly. But - you must have the input topics defined - for example if you don't define the input brightness command topics, it won't allow brightness as an output at all (also not described in the docs). But if you do define them (and have my mod), then it will send the brightness as the command_on topic as you want.

TD22057 · 2017-10-08T22:46:59Z

Actually - someone on the forum already did this. See the answer here - you can just use mqtt template light as a brightness controller already with this additional logic:
https://community.home-assistant.io/t/bug-in-mqtt-light/18810/3
If you use this logic, you don't need my update to mqtt_template.py except for the fact that it doesn't remember what the last brightness was, it always turns on at 255. So I think my mod is still necessary to be really useful.

  - platform: mqtt_template
    command_topic: "test/light2/bright"
    command_off_template: "0"
    brightness_command_topic: "test/light2/result/bright"
    brightness_template: "{{ value }}"  
    command_on_template: >
      {%- if brightness is defined -%} 
      {{ (brightness ) | int }}
      {% else %} 
      255
      {%- endif -%}

TD22057 · 2017-10-09T04:10:43Z

For any on that cares, I posted an MQTT template question on the forum to see if anyone cares if I make the fix to the template code as well. That would be another, more flexible way to achieve a similar result.

PianSom · 2017-10-09T08:12:33Z

Oh wow. mqtt-template - who knew?

I do see on the page that the table states that transition is not supported by mqtt, which I suppose explains why you can't see it in the code. Documentation error, I guess.

Are you still planning on releasing the changes you have made to mqtt? I think it would be useful and I would certainly use it. (At least for now - the transition thing is hard; I'd like to use it in certain circumstances (eg lights out in evening) but not all the time. One to think further about.)

PianSom · 2017-10-22T11:14:42Z

Hi @TD22057 - it doesn't look to me like your changes have been incorporated into 0.56. Are you planning on releasing them?

TD22057 · 2017-10-22T21:43:21Z

See: #9829. It's been submitted as a pull request - the HASS owners have to decide to merge it or not. You can always download the modified file from my repo to use until then.

* Added ability to control when the on command is sent. * Changed to allow only brightness command * Code cleanup * Added test cases for on command mode. * Added addition test * Changed brightness options to lower case. * Fixed case of default value * Remove default

PianSom mentioned this issue Oct 7, 2017

MQTT Light - error in publication on brightness setting #7810

Closed

This was referenced Oct 12, 2017

Updated MQTT light docs for new option home-assistant/home-assistant.io#3595

Merged

Mqtt light options to fix #9330 and #7810 #9829

Merged

fabaff closed this as completed in #9829 Oct 31, 2017

balloob mentioned this issue Nov 2, 2017

0.57 #10293

Merged

home-assistant locked and limited conversation to collaborators Mar 3, 2018

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Uh oh!

MQTT light: Order of packets: command_topic and brightness_command_topic #9330

MQTT light: Order of packets: command_topic and brightness_command_topic #9330

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

MQTT light: Order of packets: command_topic and brightness_command_topic #9330

MQTT light: Order of packets: command_topic and brightness_command_topic #9330

Comments

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!