transition attribute to light calls leads to an unexpected beaviour

[xaviml]

Bug report

Description

When using deCONZ integration and group of lights, then when toggling the light (or turning it on/off) it leads to unexpected behaviour. It does not go back to the previous brightness. Even though all lights support transition, it does not work as expected.

To solve this problem, I will create a new attribute (TBD) that will remove the transition attribute from light calls when the lights are turned on/off or toggle.

In the meantime, the flag add_transition: false can be used, but this will remove the transition to all calls and it will cause a not very good smooth transition when changing the brightness or color.

Additional information

• Devices involved:
  • Model: E1810
  • Ikea lights
• Integration: deconz (maybe with others as well)
• AppDaemon version: -
• ControllerX version: v2.7.0
• HACS version (if installed from there): -
• Home Assistant Core version: -

[hutchx86]

I'm having the same issue without deconz, just using z2m with a cc2531 coordinator. Controller is IKEA E1743 and the lights are the ikea zigbee 30w driver

[xaviml]

Hi @hutchinsane,

Are both light aggregated with Group integration? Or just the lights separately?

[hutchx86]

I apologise, it's just one light driver, but with multiple individual spotlights connected to the driver, I should have made that clearer 😅
It's one ikea E1743 button connected to home-assistant via z2m, then the light driver is connected to home-assistant through my hue bridge. Until recently, it all worked like expected i.e. turning the light on after turning it off reverts the brightness to normal, but now it goes to minimum brightness.

I did some testing around and it seems that is the turning-off action that sets the light to minimum brightness, if I turn it off via the HA frontend and then use the button to turn it on, it reverts to the previous brightness, as you would expect.

If I now turn the light off via the button and turn it on via the frontend, it's on the lowest brightness again.

[htvekov]

Hi' @hutchinsane

Have only a selection of different Ikea bulbs, but no driver. So unfortunately I can't help with tests 😕
But unless driver is using a different zigbee-herdsman converter than bulbs are (don't believe so), then the 'toggle with transition brightness' issue have been solved by Koenkk some weeks back.

1. What zigbee2mqtt version are you on ? (Has to be newer than v1.12.0 (free from memory) or edge version)
2. I assume that when you write 'has worked earlier' it was with a previous version of ControllerX that didn't toggle lights with a transition attribute ?
3. Have you tested that lights toggle to correct brightness if add_transition: false is added to controller in apps.yaml file ?

[hutchx86]

1. I'm on 1.13.0
2. Yes, with a previous version of controllerx, the lights behaved as expected and didn't set the brightness to minimum before turning off when pressing the off button
3. not yet I think, I will try that first thing in the morning and report back, thank you for the suggestion :)

[htvekov]

OK @hutchinsane

I'm pretty sure that brightness will be set correctly, if you apply the add_transition: false to your controller in apps.yaml

Have googled some, but was unable to find definite answers on whether this device (both 10- and 30w version) actually supports transitions at all ?
What does entity's supported_features show in HA dev tools ?

If transition, flash and brightness are supported (like Ikea white GU10's eg.), then value should be 41 (dec).

[hutchx86]

That did indeed do the trick, everything is back to normal 😅 Thank you very much!

[htvekov]

@hutchinsane

Glad to hear 👍😊
Do the driver actually support transitions (supported_features in HA) ?

[hutchx86]

I don't think so as they're purely dimmer-drivers, the leds (spotlights in my case) connect only via power and ground
but as a tip: if you ever get those ikea drivers and want the corresponding spotlights, don't get the expensive omlopp ones (they say you "need" those for the drivers) that sell for 10€ for 1 spotlight, get the vaxmyra ones where you get 2 spotlights for the same price. They connect the exact same way and from what I can tell are the exact same product lol just different branding

[htvekov]

@hutchinsane
Thanks for the info regarding Ikea drivers and cheaper spotlight alternatives. You never know when that info will come in handy 👍😉

Even though this is not an issue in your use case, this brightness error should not occur and transition attributes send should be ignored by zigbee converter.
I would call this a bug that should be reported to Koenkk. But he would most likely ask for expanded zigbee logs to be able to correct the error.

These problems that 'pop up' with brightness and transition, across the platforms, surely should be adressed at lower level, perhaps Xavi should consider adapting ControllerX code to 'filter out' some of these problems anyway ? In this case a check of entity/groups transition capabilities could be done before issuing any calls with transition and strip that attribute completely.

But then again, that's exactly what the add_transition: false app setting already does 😉😁

Ciao !

[xaviml]

Hi guys!

Sorry for being MIA, I have been quite busy lately and I might not be able to tackle some of these issues for the moment.

Thank you @htvekov for the explanation. Basically, the problem it does not come from ControllerX since what ControllerX does is to communicate with HA via service calls. If you check AppDaemon logs, you will see a lot of logs from this app and some of them will be the calls that request to HA. You can take the service and you will be able to reproduce the same issues if you go to "Developer Tools > Services".

This being said, I would like to create a flag to remove the transition attribute to just the on/off and toggle actions. Because if you mark add_transition: false, it will not send any transition when changing the brightness which causes a not good smooth effect in the brightness change.

Therefore, I will update this issue accordingly and I will add in the FAQ this so people is aware of this problem and they will be able to solve by adding a flag.

[htvekov]

No worries, Xavi 😎

It will be here, when you have the time for it.

It will probably be helpful to have that sort of a flag in ControllerX.
As the change of getting all the different light platforms low level HA implementation code bugfixed and corrected, is probably very close to 0%

As much as the bugs have nothing to do with ControllerX, it will be nice to have some means to navigate around these bugs.

With this specific driver I expect that a flag wont have any effect though, as it apparently doesn't support transition at all.

Ciao !

[xaviml]

Hi guys, I just released v2.7.1 with a new attribute add_transition_turn_toggle. If set to false it will not add any transition attribute when turning on/off or toggling, however, the transition will be present when changing brightness or color if transition is supported.

[htvekov]

Hi' Xavi

I'll test this feature here on my z2m and Hue Bridge integration and let you know if I experience any issues.

Looking forward to the 'dimmer direction' improvement for my tasmotized wall switches 😁

Ciao, Xavi !

[xaviml]

Hi @htvekov,

I think we have discussed this before, but I will change the default for add_transition_turn_toggle to false instead of true. The reason behind is that there is less people using transition attribute for on/off calls than people having problems with this and having to explicitly add the add_transition_turn_toggle: false to all ControllerX configurations. I first thought that this will get fix for the third parties soon, but seeing that this still happens for Hue and deCONZ, I will consider this.

I just wanted to let you know in case you are using it.

Thanks :)

[htvekov]

Hi' Xavi

I've just returned from my summer holiday (cottage by the sea here in Denmark - Completely covid-19 safe 😷🙂)
Can see that you've been busy - as usual 😉
Will update to newest ControllerX version tomorrow.
Thanks for the warning about add_transition_turn_toggle issue. Fully understand that you won't wait any longer for Hue/deconz integrations to get bug fixed.

I'm been puzzling with a display add-on (using ESPHome) for my Sonos media player setup. Felt the need for some visual feedback, when using my ControllerX remote all the time 😎
Almost done with initial version, so I can add to existing documentation if you want it ?

Anyway, I've one annoying issue that I can't figure out how to solve. I need to get the friendly names of all the active speakers in a sensor, so I can display them. Not even sure that it's possible to 'template' my way out of this issue ?
I've issued the template question in the HA community, but haven't recieved anything yet. Do you have any idea on how to get started solving this issue ?
https://community.home-assistant.io/t/read-friendly-names-from-sonos-group-attribute-to-new-sensors/202466

Ciao ! 🙋‍♂️

[xaviml]

Hi @htvekov,

I've just returned from my summer holiday (cottage by the sea here in Denmark - Completely covid-19 safe)

I hope vacations went well. I bet you passed a really nice and peaceful holiday then 😎

I'm been puzzling with a display add-on (using ESPHome) for my Sonos media player setup. Felt the need for some visual feedback, when using my ControllerX remote all the time. Almost done with initial version, so I can add to existing documentation if you want it?

Sounds good! In fact, the switchmode 11 can be updated to be used with MQTT instead of the state integration if you want too.

Anyway, I've one annoying issue that I can't figure out how to solve. I need to get the friendly names of all the active speakers in a sensor, so I can display them. Not even sure that it's possible to 'template' my way out of this issue ?
I've issued the template question in the HA community, but haven't recieved anything yet. Do you have any idea on how to get started solving this issue ?

I am not an expert templater, but I might be able to help you. I will answer you on the topic you linked 👍

[htvekov]

Hi' @xaviml

Yes, it was probably THE most relaxed vacation I've had in years 🙂
Not much to do apart from walking the dog in the woods and by the sea, reading books when it was raining and make a few trips to local museums/attractions and Aarhus city.

Yes, I actually thought about updatating swithcmode11 documentation as well. Can't really figure out why appdeamon is notisable slower than HA itself to toggle lights using MQTT topics ? Appdeamon should be able to handle a MQTT event as fast as HA I believe. And a direct HA service call from appdeamon should in my opinion not be that slower, compared to HA's internal call on identical MQTT topic ? Don't really know if some speed improvement could be made somewhere in the code, if I raised an (appdeamon) issue on the subject ? Nevertheless, I'll update the documentation and point out that a toggle speed improvement can be achieved using direct HA MQTT handling for toggle and let ControllerX handle all other events (my setup today)

I'll refine the display code a bit (nothing fancy really) and will add your nice templates as well, to make first version ready for upload. Some documentation will have to be made as well.

Once again, thank you for the Sonos friendly names templates ! 😎
I'm learning every day, but templates are a bit hard to find any usefull documentation on.
Not so much the syntax (it's quite fucked up already 😉🤣), but more what commands/filters actually are available for loops (for/next for).

Ciao !

[htvekov]

Hi' @xaviml

Still 'polishing' initial Sonos display version layout, so I'm not dead (yet) 😉
Have added some icons as well, so it's not all text on the display.

Have to tidy up sensors/entities involved, though. It's quite messy with all the hardcoded master speaker entities throughout the ESPHome/HA config YAML. 🙄 Need to template my way out of this...

Also found an HA core issue with media_text/media_title when playing from source.
home-assistant/core#37893 (comment)

For now I've templated my way out of this small bug 🙂

I'll get back when I'm done with the final ESPHome code, documentation and some pictures.

Ciao !

[xaviml]

Hi @htvekov,

No worries, what you are doing doesn't seem something that can be done in hours, but when you finish, it will be worth it! So no rush, you take your time to update the documentation, no worries :)

Xavi M.

[htvekov]

Hi' Xavi

Still writing in this old, closed and completely irrelevant issue regarding Tasmota Switchmode 11/12. Bad habit, but the initial talk was in this issue, so I'll finish it here 🙂

@RemiDing has improved the current Tasmota switchmode 11/12 with an additional double press detection - without compromising the crusial instant toggle and clear command (no wait for xx milliseconds to distinguish between single or double click). So toggle will still fire first on a double click. But MQTT/ControllerX is fast enough to catch and execute both commands, that it's seldom visible that lights are beginning turning off before issuing on_full_brightness from ControllerX 👍

arendst/Tasmota#7603 (comment)

I'll update documentation with the MQTT integration option and include some example on this new feature as well 🙂

Ciao !

[xaviml]

That is great Henning! Thank you for letting me know. Just like you did for Sonos Display, you can create a PR modifying the existing file or just paste it here and I will update!

Thanks! :D

[htvekov]

Hi' Xavi.

I'll update documentation when PR is done and implemented in Tasmota dev version.
I'll update as well regarding the MQTT part 🙂

Ciao !

[RemiDing]

I finished all my tests and start a pull request for this changes tomorrow

[htvekov]

Hi' @RemiDing

Perfect! 👍

I'll update my documentation here at Xavi's ControllerX github.
Feel free to link to it as example of 'real life' implementation, if you update Tasmota switchmode documentation 🙂
If I can assist with Tasmota documentation, just give me a call.

Thank you for this addition for your existing Tasmota switchmodes 👏😃

Ciao !

[RemiDing]

pull request is done
it would be great if you can update the switch mode doc with the additional double press feature.
I am running out of time lately.........
https://tasmota.github.io/docs/Buttons-and-Switches/#switchmode

[htvekov]

Hi' @RemiDing & @xaviml

Sorry about the late reply, guys.
Summer suddenly came to Denmark and my birthday also came a bit in the way 😉

I'll update the documentation on Tasmota site with just the basics - written in same simple style as for the previous switch states. Or do you wish for something more elaborate than that, Remi ?
Should I add reference to my extensive Tasmota/ControllerX example documentation or is that a 'no go' ? (I'm not in to genereal Github 'politics' 😁)

I'll have to revise documentation on Xavi's ControllerX Github page as well, with a bit more than just adding the double click possibility. As Xavi's latest beta has announced deprecation of custom controllers and MQTT implementation in future will depend on JSON objects and not just 'simple' payload commands.
As I understand Tasmota documentation, it should not be a problem issuing MQTT commands with JSON payloads directly from rules. But I'll have to test first and check whether or not I'll have to escape the double quote marks in the JSON objects or not. HA and NodeRED needs escaped payloads AFAIK.
I'm probably one of the very few that right now actually uses ControllerX with simple MQTT structure as it is today. But it's certainly not a 'Minor change does not contain breaking changes' beta, Xavi 😉😁🤣

Ciao !

Edit: Initial test OK - All working with new ControllerX MQTT setup. Escaped payload as trigger for toggle (HA automation) also works. Actually Tasmota revise entered rule and 'auto add' escape signs for all double quotes in rule. Clever thing 😊

@xaviml: This old bug seems to have been reintroduced with latest beta v3.4.0b1 #81
I have to hold button down twice after a double click (on_full_brightness) is issued) ?

[htvekov]

Hi' @RemiDing & @xaviml

Pull request done for step 1 (revision of Tasmota switchmode 11/12 commands)
tasmota/docs#416

Ciao !

[htvekov]

Hi' @RemiDing & @xaviml

And pull request done for step 2 as well (revised use case documentation of Tasmota switchmode 11/12 in conjunction with ControllerX
#114

Ciao !