-
-
Notifications
You must be signed in to change notification settings - Fork 1.8k
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
Brightness, color and transition with ikea light #1810
Comments
Can you provide the debug log when the MQTT commands are send? To enable debug logging set in advanced:
log_level: debug |
I will do it this evening when I get home.
Le sam. 3 août 2019 à 20:46, Koen Kanters <[email protected]> a
écrit :
… Can you provide the debug log when the MQTT commands are send?
To enable debug logging set in configuration.yaml:
advanced:
log_level: debug
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#1810?email_source=notifications&email_token=ABPCNOTAE52G5ERITMDG3XLQCXHALA5CNFSM4IJC3SU2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD3PTXRI#issuecomment-517946309>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ABPCNOTNI64XM2CUE3J65PTQCXHALANCNFSM4IJC3SUQ>
.
|
Hey! I found time to do the debug. Find here the 3 log extracts with color+brightness+transition, color+transition and brightness+transition: |
|
The case with brightness color and transition. The color and transition are
applied, but the brightness isn't, but it shows as if it were. (the actual
lamp doesn't change brightness but it is changed on the dashboard)
Le jeu. 8 août 2019 à 20:09, Koen Kanters <[email protected]> a
écrit :
…
- Which cases don't give expected behaviour?
- On line 17 I see brightness":200, on line 11 "brightness":20, what
happend in between? Do you see any pointers why the brightness did increase?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#1810?email_source=notifications&email_token=ABPCNOTP7NONFZY2AOYIF53QDROLXA5CNFSM4IJC3SU2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD34OMOY#issuecomment-519628347>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ABPCNOSAP2UAYY5CC6MS35TQDROLXANCNFSM4IJC3SUQ>
.
|
Oh, I didn't answer your second question. For the brightness change I have no idea. I don't remember changing it in-between and I had the other plug-ins off... |
Could you try to investigate that further? |
Hey, sorry for the delay, I hasn't got any time. So for the brightness change, it was me that changed it.
As I see in the log, the two commands are send one after another, and this could be the cause of that, the first "moveToLevelWithOnOff " is received, but just after, ignored by the bulb because it receives the "moveToColorTemp " which is applied. |
Can you also reproduce this manually? |
What do you mean by manually? |
By sending the mqtt commands via a client like mqtt.fx. It seems that the bulb discards the command, could you try to find a sequence when it doenst? Maybe e.g. first color temperature and then brightness? I will also investigate this after #1888 |
Sooooo, after multiple tries (don't have the logs). When you first set brightness and then color (during the transition interval) the brightness gets reset to original brightness and color is applied with transition. When doing it in reverse (color and THEN brightness) the brightness gets ignored. But, the next time the color is updated with the SAME value, the brightness is applied. TL;DR; The brightness is always ignored by the bulb if a color command is send in the transition interval. (before of after) |
Furthermore, if color_temp is send, before brightness, but the color is the same as alread set, the brightness is updated |
Thanks for your investigation, so it seems that a current transition is discarded when a new transition is started. |
only the brightness transition is discarded, the color isn't.... |
I'm also having the same issue and after reproducing it manually, the brightness is always the discarded one. Independently of it being the first or last one. |
So it seems this is just a software limitation of the bulb itself, not sure how we can work around it. |
Would it be possible to add a delay between the 2 orders (via config param or something similar)? |
I don't think a delay would work. Let's say you do a change to brightness and ct that should take 5 seconds. For it to work with a delay, it would have to send the ct change command 5 seconds after the brightness command, which would make the whole change take 10 seconds. |
Yeah, but at the moment, it just cancels the other command. That why I'm proposing a config, so you can activate or not the behavior. But at the moment, it just doesn't work at all with half of the integrations from HA. Making the correction at the level of z2m makes it easier for every integration. |
Yeah, you're right. I too prefer that it takes longer but gets there. If there's no other way, that is better than the current behavior. |
Any news on a possible implementation/correction? |
I was just thinking about this, what if we only pusblish the transition for the last published value? E.g. when sending Currently:
Proposed fix:
|
Didn't thought of that, seems a good idea. :)
Le mar. 24 sept. 2019 à 13:16, Koen Kanters <[email protected]> a
écrit :
… I was just thinking about this, what if we only pusblish the transition
for the last published value?
E.g. when sending {brightness: 100, color_temp: 200, transition: 5} :
Currently:
- brightness 100 with transition 5 <--- fails to apply
- color temp 200 with transition 5
Proposed fix:
- brightness 100 without transition
- color temp 200 with transition 5
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#1810?email_source=notifications&email_token=ABPCNOV54DWLDWYVRFNLBBDQLHZIHA5CNFSM4IJC3SU2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD7OAAQA#issuecomment-534511680>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ABPCNOR7WCU7OFW75OOEGTDQLHZIHANCNFSM4IJC3SUQ>
.
|
Good idea. I just suggest changing the order. I think brightness changing abruptly is worse than color temp. |
@irgusite can you confirm that it works? |
Nope it doesn't work. The brightness is still with transition (it is cut) I updated like this: Backup configurationcp -R data data-backup Updategit pull origin dev Restore configurationcp -R data-backup/* data Start zigbee2mqttsudo systemctl start zigbee2mqtt |
EDIT: nevermind I found the issue, should be fixed in the dev branch now. |
I installed the latest-dev docker yesterday, but it appears to still be having issues with adjusting brightness and temperature of my IKEA bulbs. |
@atxbyea do you control them via groups? |
Just tested, and it seems to work fine :) Thanks for your work 👍 |
…olor temperature for group containing TRADFRI bulb. Koenkk/zigbee2mqtt#1810
@irgusite thanks for confirming. I've also pushed a fix for TRADFRI devices in a group. Assuming this is fixed now. |
Hello @Koenkk , I am experimenting the same issue with Ikea Tradfri bulbs. |
@dgarciadonado in that case the transition will be only applied over the color, the brightness is set immediately (tradfri bulbs don't support transitioning on both properties). |
Thank you @Koenkk , and is there any way to force brightness transition instead of temperature transition (if using both at the same time) |
@dgarciadonado no at the moment not (and not very easy to change). |
This workaround can help in HA: So firstly set brightness and transition and after 1s delay set color_temp... action:
|
Thank you!! I will give a try! |
Hello @w3host, now is working! Thank you!
Now I have another problem: if the script is executing the final transition and I call another script which affects this light, the lights changes to be crazy and doesn`t reflect the real Brightness and Color. Thank you again! |
Bug Report
What happened
Related to : #341
I'm using circadian lighting and zigbee2mqtt with ikea lights.
When circadian is updating the light brightness and color, the bulb doesn't apply the new brightness.
What I saw, is that when updating the brightness and color, along with a transition time, only the color updates but not the brightness, and the z2m plugin reports the new brightness (but not applied)
After more observation, as long as the color transition is not over, the brightness is reset to it's precedent state but not communicated to the bulb.
What did you expect to happen
To have the brightness and color changed with a transition time
How to reproduce it (minimal and precise)
Debug Info
zigbee2mqtt version: 59a5c6b
CC253X firmware version: from july 2019
The text was updated successfully, but these errors were encountered: