Setting HUE value is taken much too delayed / not directly and as unconfirmed

[RkcCorian]

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:

1. Set hue.0.-GroupLightName-.hue to any value
2. Value is written back to value before + r g b and sat is changed as well
3. Wait for several seconds
4. Value is taken confirmed BUT not exact the same as triggered

Expected behavior A clear and concise description of what you expected to happen.

1. Set hue.0.-GroupLightName-.hue to any value
2. Value is taken unconfirmed, no other value will be changed
3. Value is taken confirmed after next poll

Screenshots & Logfiles If applicable, add screenshots and logfiles to help explain your problem.

Versions:

• Adapter version: 3.10.1
• JS-Controller version: 5.0.16
• Node version: v18.17.1
• Operating system: Docker
• Bridge model:

Additional context Add any other context about the problem here.

[RkcCorian]

@foxriver76 : Hi foxriver76! Do you see a chance to implement this soon? Many thanks!!

[foxriver76]

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

[foxriver76]

Hie extended used only polling so I don’t know what the difference should be

[RkcCorian]

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.

[foxriver76]

I unfortunately cannot replicate the described behavior. Are you sure, that hue sets it back?

[RkcCorian]

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

[foxriver76]

okay, I can replicate it for a Zone indeed.

[foxriver76]

3.10.2 should fix this.

[RkcCorian]

I installed 3.10.2 but unfortunately it does not help. In the app it is a zone

[RkcCorian]

Let me know in case I can help somehow. For sure I can retest on my side :-)

[foxriver76]

Then no idea for me it worked with the change

[RkcCorian]

Some chance that your change is not in 3.10.2 or I made something wrong? I restarted even ioBroker but does not work...

I installed via..

[foxriver76]

I can re check tomorrow or maybe tonight

[foxriver76]

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.

[RkcCorian]

I tried with the GitHub version, compare my screenshot

[RkcCorian]

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.

[foxriver76]

hm what is your current polling interval?

[foxriver76]

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.

[RkcCorian]

hm what is your current polling interval?

Minimum, which means 2 seconds

[RkcCorian]

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.

Ahhh, so another new version... just a second...

[RkcCorian]

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.

I installed already the newer version (as I would like to be sure)... so this is the behavior

[foxriver76]

does this happen with higher polling interval too?

[foxriver76]

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

[RkcCorian]

Member

Yes, just the timing is slower. I tried with 2 and 10 seconds

[foxriver76]

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 New push connection update... if wrong values are coming from here, but this would be pretty weird tbh

[RkcCorian]

I will try.... in the meantime I created a small script which shows me the changes on this DP... 109 is the original value and I try to change to 200 which will result finally at 171

[foxriver76]

but then better log also who changed the value + ack

[RkcCorian]

but then better log also who changed the value + ack

How can I do this?

[RkcCorian]

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

[foxriver76]

if you currently log obj.state.val simply log JSON.stringify(obj.state)

[RkcCorian]

Not sure how to do... it looks currently like this...

[foxriver76]

okay, yes than it comes from hue adapter. But then please check log on debug level of hue, where the state comes from.

[RkcCorian]

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?

[foxriver76]

for what is it important?

[RkcCorian]

I did now another experiment... I changed the polling rate to 100 seconds... with this it is working as expected...

[RkcCorian]

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?

[foxriver76]

the polled values are in the large config json after Polled config, it seems like there are old values returned at your bridge when polling too often. But would still be weird, if you say it worked with hue-extended.

[RkcCorian]

the polled values are in the large config json after Polled config, it seems like there are old values returned at your bridge when polling too often. But would still be weird, if you say it worked with hue-extended.

It works still as well with 20 seconds, but not with 15 seconds... With Hue-Extended Adapter I set the HEX value in the past, never the HUE Additionall with Hue Adapter... I do not see this wrong behavior with xy or rgb, even with polling rate of 2 seconds

[RkcCorian]

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)

[foxriver76]

so the problem only occurs with .hue values?

[RkcCorian]

so the problem only occurs with .hue values?

Yes

[RkcCorian]

And only for the group

[foxriver76]

lol okay, thats a mess, that the dps and the adapter both are called hue, did not get that it is only about hue values until now ^^

[RkcCorian]

Ahhhh, 🙈

[RkcCorian]

I have to go to sleep for now but can recheck again tomorrow. I hope you can find the root-cause 😃

[foxriver76]

please check whats transmitted in the json after Polled config on debug log.

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

   "10": {
      "name": "Dunstabzugslicht",
      "lights": [
        "39",
        "40"
      ],
      "sensors": [],
      "type": "Zone",
      "state": {
        "all_on": true,
        "any_on": true
      },
      "recycle": false,
      "class": "Kitchen",
      "action": {
        "on": true,
        "bri": 130,
        "hue": 8417,
        "sat": 140,
        "effect": "none",
        "xy": [
          0.4573,
          0.41
        ],
        "ct": 366,
        "alert": "select",
        "colormode": "ct"
      }
    },

[RkcCorian]

please check whats transmitted in the json after Polled config on debug log.

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

   "10": {
      "name": "Dunstabzugslicht",
      "lights": [
        "39",
        "40"
      ],
      "sensors": [],
      "type": "Zone",
      "state": {
        "all_on": true,
        "any_on": true
      },
      "recycle": false,
      "class": "Kitchen",
      "action": {
        "on": true,
        "bri": 130,
        "hue": 8417,
        "sat": 140,
        "effect": "none",
        "xy": [
          0.4573,
          0.41
        ],
        "ct": 366,
        "alert": "select",
        "colormode": "ct"
      }
    },

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 When I change any other value of the group (which is 1to1 the light itself) or even the light values, incl. hue, it is always the excact same value as I set as target value. Might there be a side effect somewhere when setting the hue value of a group?

[RkcCorian]

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

[RkcCorian]

I checked as well with Hue-Extended (without log) and there I do not see this bad behaviour (incl. the change of other values when writting the hue value of the group). I do not know what @Zefau is doing different...

@Zefau: Do you have any hint? Many thanks!

[RkcCorian]

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