Problem with Group and Color Temp

[UweLoyal]

Changing Color Temp generates a Warning: unread colortemp change for group members ["0xXXXXXX1","0xXXXXXX2","0xXXXXXX3","0xXXXXXX4","0xXXXXXX5"] The Lanps in Group are Lidl HG06106A

I think the numberrage of Color Temp is not identical. Group 200-9000 Lamp 150-500

[asgothian]

This warning is generated as the lidl lamps do not allow for the color temp to be read, so the group cannot upgrade the ct value for the lamp itself.

the number-range is immaterial.

A.

[UweLoyal]

Color Temp is Readable! I do it also with my scripts! With Goupe Slider I can also change Color Temp!

{ "type": "state", "common": { "name": "Color temperature", "type": "number", "read": true, "write": true, "role": "level.color.temperature" }, "native": {}, "from": "system.adapter.zigbee.0", "user": "system.user.admin", "ts": 1644311892117, "_id": "zigbee.0.588e81fffef66572.colortemp", "acl": { "object": 1636, "state": 1636, "owner": "system.user.admin", "ownerGroup": "system.group.administrator" } }

[asgothian]

You are reading the iobroker state. The adapter is requesting to read the color temp from the device but the device does not respond.

A.

[UweLoyal]

Is it possible to fix that Problem? The adapter ist part of ioBroker and if ioBroker can communicate with Lidl Lam, so it must work! When I remember back, I didn't see error messages, I think they suddenly came up. What I know, the Slider of Group (ct) worked at the beginning, now he doesn't!

[asgothian]

This is not something the adapter can change. A bit of background:

• The state changes are sent to the "group", not to the individual device by the zigbee adapter.
• The group is defined on the coordinator, and the changes are then sent to the members. The system relies on the group members to inform the coordinator about value changes.
• Since most devices do not report changes made through the group system, the zigbee adapter generates a "value query" as defined by the zigbee-herdsman-converters. It is this subsystem which generates the warning messages.
• You can test this subsystem yourself by activating the "device query" state. The logic which data to query is taken from the zigbee converter definitions. Only states which advertise that they can be read are actually attempted. If you check the log you will see that the converters advertise readability for several objects which actually cannot be read. Most notable offenders are color_temp and color.

For the adapter, there are 2 options:

• Discard the attempt to query states, and with it, give up on keeping the lamps own states updated to the actual values on the lamp if set by the group
• Retain the read attempt and accept the warning message.

On a side note - the slider should still work and change the colortemp of the bulbs. It does for all my groups which support color. If it does not, this is not linked to the warning message but an internal error of the lidl bulb which warrants further testing. As i do not have said lamps i will not be able to perform those tests myself.

A.

[UweLoyal]

Is it possibel, that a Hosts update generate that problen, today I had the 2nd Udate. New error are now generated

and

after runnig this script

const Licht_Decke_extern_node_root = "zigbee.0.group_1"; const dot = '.'; setState(Licht_Decke_extern_node_root + dot + 'colortemp',200); log(getState(Licht_Decke_extern_node_root + dot + 'colortemp').val); setState(Licht_Decke_extern_node_root + dot + 'colortemp',300); log(getState(Licht_Decke_extern_node_root + dot + 'colortemp').val);

witch generte a flash of on/off of all Lamps in Groupe. Bevore the last update this was not generated by the script.

Actual Version 4.0.18

You reopend the report, you done this because found somethig?

Rgds UweLoyal

[asgothian]

No. I reopened the report so you would not create additional duplicate issues.

The original assessment stays. The adapter is working as extended.

The first log you posted (btw - logs should never be posted as screenshots) have nothing to do with this issue. This is an issue which hints at a problem with your zigbee network as you are flooding the zigbee buffer with requests which cannot be handled in a timely manner.

The getState commands do not read the value from the hardware, but only from the iobroker state database.

The script itself seems normal, but this can be a mistake as it is only a script stub. As a rule of thumb, it should be avoided to set the same zigbee state to different values without at least 20 to 50 ms delay between the operations.

Lastly, there is no 4.0.18 version of the zigbee Adapter.

A.

[UweLoyal]

4.0.18 Actual Version of Hosts

[asgothian]

The host version has nothing to do with any of the errors posted.

• The warnings are generated by the zigbee adapter as explained above.
• The error messages are generated by the zigbee-herdsman due to the message buffer on the zigbee coordinator to be full. This is an indication of either wireless issues or too many commands sent in too short a time.

A.

I did another check on the log you posted. It seems that you sent at least 6 pairs of colortemp changes within 200 ms. I am not surprised that your zigbee network is overloaded with this. It seems that you sent a lot more commands to the group than visible in the script stub pasted above. It is possible that a previous adapter version would not report the errors back to the iobroker log, but rest assured that this kind of burst communication has never worked. If you are (still) using a triggered "repeat send a small offset" approach towards dimming and changing colortemp via a button or remote you should retire such scripts and swap over to the more modern use of "brightness_move" and "colortemp_move"

[UweLoyal]

I's realy funny, asgothian (https://github.com/ioBroker/ioBroker.zigbee/issues/1390) say ask the hardware producer, slaesh (https://slae.sh/projects/cc2652/#). slaesh say, ask Koenkk (https://github.com/Koenkk/zigbee2mqtt/issues/11875) and Koenkk, sais ask asgothian.

Who can now help me after staying again at the beginning?

In hope for Help!

Rgds Uwe Loyal

[asgothian]

You may want to read what i wrote above. You have been sending commands to the zigbee network (to the same device) in a flood with (only in your log section) 6 messages in 200 ms. As these are just the messages which result in "BUFFER_FULL" errors there have to be a lot more messages in short time right before.

When i wrote that the hardware does not respond to a read request of the color_temp this was targeted to the tint bulbs, which do not respond to a read request for the color temp. This has nothing to do with the coordinator. A.

p.s. You should also be a bit more precise as to which issue you are referring. The group response and the BUFFER FULL error messages are not related.

[UweLoyal]

I whant to ask you in another way: Who has to fix the Bug, that the Groupslider of color temperature will not generates this error? Everybody say, thats not my problem, but thats not the way to fix that bug! So please coordinate this with all known developer and help me and all other user to get a with no errors working system.

The same slider of Lamp works fine with no errors!

Rgds Uwe Loyal

[asgothian]

The answer to that question depends on a number of things.

Option 1: There is a fix within iobroker, one which i can do with a simple edit. Doing that would mean that a change of any value in the group will not ever update the value on the group members themselves unless the group members report the changed value.

This is an easy fix, but it removes requested functionality, which is why i do not intend to follow this route.

Option 2: Figure out why the lamp does not respond as expected when queried for the color temperature. This can have one of two reasons:

1. There is a bug in the zigbee-herdsman-converters implementation of the colortemp state in a way that the read request is handled.
2. The lamp itself may simply not respond to a request to read the colortemp - in this case, the documentation on zigbee2mqtt.io is not correct. This can only be fixed on the lamp by a firmware update.

Option 3: Rewrite the entire group function to not rely on zigbee network group objects but zigbee adapter group objects instead where the separate entities are switched by the adapter rather than issuing a single group command. This is

• a lot of work
• stupid, as it increases the load on the configurator significantly and bypasses a core zigbee function.

The only viable option in my eyes is option 2. I have made an attempt at it several times, but never made any real headway. The code used to read the colortemp is identical to the code used to read the on/off state and brightness value - it works flawlessly in both cases.

A.

[UweLoyal]

Anouther thing is also not logical for me: Changing Color temperature directly on your Zigbee adapter slider for th Lamp generates no errror. Using Groupe Color temperature slider generates an error. Do you can explain me this effect, for me its is not logical, because all ends in the same Lamp. Logical for me is would be: both generates an error or both genaerates no error.

I would be happy, if you could explain it for me.

Rgds Uwe Loyal

[asgothian]

I already explained it above:

When you talk with the lamp directly, the value is written into the color_temp state for the lamp and then sent to the lamp. The lamp confirms that it has received it so we can confirm the value.

When you talk with the group the value is sent to the group, which internally sends it to all members, bypassing the lamps own iobroker states. The group does not confirm the success of the change, so we cannot confirm the state change. We cannot update the lamps color_temp values unless the lamps report it, which they mostly don't. This is why we attempt to query it - without an answer.

A.

[asgothian]

A Test branch exists at https://github.com/asgothian/ioBroker.zigbee/tarball/H459

Please note that this branch may have additional changes which may or may not cause additional effects.

A.