Light group delayed response to scene change

[TC1]

Either I'm doing something wrong or discovered a new quirk....

I've successfully made local scenes in the PI, when I trigger them they execute properly against the lights assigned to the group they are in. Each one of these scenes had the Brightness level set to 50%.

The quirk is with the Light Group device created in HS4. If I trigger a scene assigned to the light group it executes perfectly... except the dim level value for the group device indicates Off. Again the lights are physically lit and at the right level.





Then almost exactly 42 to 43 seconds later the dim value jumps to 50%. Again, the actual light level of the lights remain unchanged.



The problem is during that delay of 42 seconds I am unable to change the dim level of the group programmatically from another event. Once the Dim setting corrects itself in the group device then my other dim events work perfectly.

Thoughts?

[w.vuyk]

There is a challenge in the group updates that I probably will not overcome. Gateway's do not hold extended information on the status of their groups. In fact all they contain is a list of lights involved in the group and an "any_on" and a "all_on" status.
There is no shared brightness or color settings available.

So when a gateway sends a group command the groups "any_on" and "all_on" status updates once the lights have reported back on their status.Once this has been updated, the plugin gets a notification on these two attributes. Only when a "all_on" is reported, the plugin will do a check on all lights involved in the group on their status for brightness.

The issue here is that the deCONZ gateway is very fast in sending the webhooks. Very regular the webhooks come in a sort of storm. Imagine the group being addressed. This will send webhooks on every light updating and also the group itself. Very often here the groups update is the first one as this is the originator of the command. The plugin starts its update for the group device, but lights are not updated yet. The group info holds no information on the brightness being set. So the check finds all lights still off, or only one light set if we are lucky, which will not update the group device.

So this webhook call will not update the groupdevice, but the next polling (max 45 seconds, soon 90 seconds) will find the change and set the brightness.
This is an issue where I have no ready made solution for at this point....

Thanks,

Wim

[w.vuyk]

Update:

As a test I will include a change in the plugin where the groupupdates coming from the webhook will be delayed one second, hoping this will not interfere with the rest. Maybe this helps getting the right state.

Wim

[TC1]

Thanks for the explanation, Wim. I was once again mistaken in my understanding of how the plugin works... I assumed the virtual device created in HS by the PI was local in nature in terms of values it holds, not realizing it had to wait for the round-trip info from the devices themselves.

Question: since the scene is created locally in JowiHue, and contains the brightness level, why not just send that value to the virtual device in HS the same time the scene settings are sent to deconz and the light bulbs themselves? In theory there should be no discrepancies, but if there are, they would be corrected when the group poll finishes in that 45 second time span you spoke of.

Of course I may be overlooking a race condition that is created by doing that....

Unfortunately this the last piece in the WAF I'm trying to solve before I introduce these lights into the household... it won't go over well if I show her that she can change scenes, then explain she has to count to 45 before she can change the brightness level in the room.

[w.vuyk]

I guess you mean the group device and features with the virtual device here?
When the plugin does this (I did in the past) the value will be reset the next round of check the plugin does if the update did not come in. This would make the device flip regulary.
I am running a test here now (it is evening here, so lights are feasting) and it seems the update I did might just work.
If you are interested I can PM you later this weekend for a (beta!) test?

Thanks,

Wim

[TC1]

I guess you mean the group device and features with the virtual device here?
When the plugin does this (I did in the past) the value will be reset the next round of check the plugin does if the update did not come in. This would make the device flip regulary.
I am running a test here now (it is evening here, so lights are feasting) and it seems the update I did might just work.
If you are interested I can PM you later this weekend for a (beta!) test?

Thanks,

Wim

Sure, sounds like a plan. The sooner I can get these lights into the living room the sooner I can brag in front of the wife "Look at the pretty colors you can change the room into!"

[w.vuyk]

I have released a beta just now that includes the update for the groups. Let me know if this one works for you?

Short overview of the changes in the plugin here:

• Updated group device handling, trying to minimize delays
• optimized internal administration for better device handling
• Corrected issues with moving a bridge to a different IP address.
• Corrected the call for access through scripting, which inadvertently was changed in the last release

Thanks

Wim

[TC1]

Extremely unstable now, it keeps crashing and restarting. Here is the error message I get in Windows:

Problem signature:
Problem Event Name: APPCRASH
Application Name: HSPI_JowiHue.exe
Application Version: 4.0.2.6
Application Timestamp: b04441d0
Fault Module Name: ntdll.dll
Fault Module Version: 6.1.7601.24545
Fault Module Timestamp: 5e0eb751
Exception Code: c00000fd
Exception Offset: 0002e11e
OS Version: 6.1.7601.2.1.0.256.4
Locale ID: 1033
Additional Information 1: fa12
Additional Information 2: fa127d2f58b09fd1f9f83b71507c40d9
Additional Information 3: d75e
Additional Information 4: d75ecd07842b4baa93bc39228b002b17


And HS4 logs are now flooding with the following errors:

The device 'Right Rear' is one of my Hue bulbs (the only one powered on at the moment).

Let me know if there's anything else you need, for now I have to uninstall it unless there's something quick you want me to try. My environmental sensors are all Zigbee and I need them up and running.

[w.vuyk]

Do you know if the color temperature device and color features were already present before trying the beta version? I wonder why it would not have been present before the beta?

Wim

[TC1]

Oh wow... I didn't bother to look until you mentioned it... I just looked at my Device listing and it's a mess... the PI ended up looping and creating a long list of duplicate child devices....

Here are the original child devices:



...And here are the additional child devices (it keeps going down the page, since the PI kept crashing and restarting)




Should I just delete the device in HS4 and let it recreate? Fortunately most of my events to control this light reference the Group setting it's part of.

[w.vuyk]

You might want to let the device be recreated. if you do not have any device events on it, it should not create issues.

Wim

[TC1]

Same results, here's the steps I took:

Deleted the device in HS4.
Stopped and started JowiHue PI 4.0.2.5
Device recreated, all looks good, no issue in logs.
Upgraded to 4.0.2.6
PI crashes almost immediately (according to Windows pop-up) but my HS4 logs are being flooded with device recreation errors, same as before.

[TC1]

I could try to delete the device and then upgrade to 4.0.2.6 and let it recreate it... but that would just be hiding the issue. I'm sure there are plenty of folks with existing Hue light devices.

[TC1]

So I deleted the device and let PI version 4.0.2.6 recreate it... and it worked without crashing and flooding the logs. Not sure if that helps you.

[TC1]

And unfortunately the Group update delay has gotten worse, use to be 42-45 seconds in my environment, now up to 1 minute 4 seconds when I change scenes.