-
Notifications
You must be signed in to change notification settings - Fork 29
Setting HUE value is taken much too delayed / not directly and as unconfirmed #552
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
Comments
@foxriver76 : Hi foxriver76! Do you see a chance to implement this soon? Many thanks!! |
I don’t get it tbh what this issue is about? API is polled, you can configure the polling interval down to e.g. 2 seconds |
Hie extended used only polling so I don’t know what the difference should be |
The issue is that a value that is written for steering shall be there, just unconfirmed. So e.g. current value is 50 confirmed. Then I write to 60 unconfirmed. After the next polling the 60 will be written again confirmed. But what happens is that current value is e.g. 50 confirmed. When I write 60 it will be written directly back to 50 confirmed and only after next polling it will be 60 confirmed. |
I unfortunately cannot replicate the described behavior. Are you sure, that hue sets it back? |
I checked it again... it is working fine and fast for a light. The problem comes when doing the same for a group. There it is not working correct |
okay, I can replicate it for a Zone indeed. |
3.10.2 should fix this. |
I installed 3.10.2 but unfortunately it does not help. In the app it is a zone |
Let me know in case I can help somehow. For sure I can retest on my side :-) |
Then no idea for me it worked with the change |
I can re check tomorrow or maybe tonight |
could not replicate but please try GitHub version. This should also avoid some additional requests, maybe also helps with your other problems. Downside: The immediate poll after setting the state is no longer working, but Push Update should bring most important states immediately anyway. |
I tried with the GitHub version, compare my screenshot |
I played a little bit around... it seems to be a timing issue. I was able to set a new target value and it was taken for 1 second but then written back again with the old value, even the light in reality has changed already to the correct new target color. Waiting longer for some seconds will result in the correct target value. But his jumping back to the old value is bad. |
hm what is your current polling interval? |
What do you mean with compare your screenshot? I have changed something a few minutes ago, so you of course need to reinstall from GitHub + restart the adapter instance. |
Minimum, which means 2 seconds |
Ahhh, so another new version... just a second... |
I installed already the newer version (as I would like to be sure)... so this is the behavior |
does this happen with higher polling interval too? |
because the immediate updates are no longer there on GH version so either it is from the normal polling or something strange is going on |
Yes, just the timing is slower. I tried with 2 and 10 seconds |
hm okay, then only possiblity to get a state update from adapter is the push API, you could set adapter to debug and check for log lines like |
but then better log also who changed the value + ack |
How can I do this? |
I see in the log ""color":{"xy":{"x":0.3218,"y":0.5827}" but it is not hue, it is xy, so not sure how to compare |
if you currently log |
okay, yes than it comes from hue adapter. But then please check log on debug level of hue, where the state comes from. |
How can I compare the xy with hue value? |
for what is it important? |
I might have misunderstood... but how can I check otherwise from where the state comes from, when not searching for the "buggy" hue value? |
the polled values are in the large config json after |
It works still as well with 20 seconds, but not with 15 seconds... |
And additionally... it works fine when I do not use the group but the single lamp (in this case technically it is the same as the group is 1 to 1 the lamp) |
so the problem only occurs with |
Yes |
And only for the group |
lol okay, thats a mess, that the dps and the adapter both are called |
Ahhhh, 🙈 |
I have to go to sleep for now but can recheck again tomorrow. I hope you can find the root-cause 😃 |
please check whats transmitted in the json after There should be a simple entry which already delivers the hue value, and normally adapter just sets what is coming from API looks eg like this for a zone
|
I checked, and yes the old value is there inside... what is strange additionally... even once the value is changed finally in direction of the target value it is NOT the target value. E.g. when I set 100 it will be at the end e.g. 92 |
I checked as well with the single light, instead the group (even beeing a 1to1 relation) and there this is not happening. It works fine |
@foxriver76 : One thing that I see... Hue-Extended Adapter as well as Hue Adapter with single light has color mode "hs". BUT Hue Adapter with group has color mode "xy". Can you please check also if the adapter send the correct command? |
@foxriver76 : Moin! I wish you a happy new year first!! :-) Anything new here or something that I can do? Greetings! |
Describe the bug
A clear and concise description of what the bug is.
Setting HUE value is taken much too delayed. This is bad when using e.g. in JARVIS as the light selector will first jump back, even that the color is changed at the lamp
To Reproduce
Steps to reproduce the behavior:
Expected behavior
A clear and concise description of what you expected to happen.
Screenshots & Logfiles
If applicable, add screenshots and logfiles to help explain your problem.
Versions:
Additional context
Add any other context about the problem here.
The text was updated successfully, but these errors were encountered: