On 23 October 2026 two pull requests were merged into zigpy/zha, the library behind the ZHA integration in Home Assistant. They change how new Zigbee groups get their addresses and make group creation fail with a clear error instead of quietly doing something else. Neither is in a zha release yet (the latest is 2.3.1 from 9 October), so they will reach Home Assistant when a newer version of the library is pulled in.

A lamp that never left the old group

Until now ZHA gave a new group the lowest free ID, starting at 2, and it deliberately filled the gaps left by deleted groups. That caused two problems.

Removing a device from a group is done on a best-effort basis. If a bulb was offline when you deleted the group, the RemoveGroup command never reached it, ZHA logged that only at debug level and dropped the group anyway. The bulb kept the old ID in its memory. Once ZHA handed the same ID to a new group, that bulb started reacting to the new group's commands without being a member.

The second problem was in Home Assistant itself. A ZHA group entity's unique ID is built only from the group ID, so a new group with a freed ID inherited the deleted group's entity ID, name, labels and area from the entity registry. In issue #187377, filed on 19 October, a newly created group showed up under the deleted group's name and was targeted through that group's labels.

Random IDs from a narrower range

New groups now get a random unused ID between 0x0100 and 0xfeff. The lower bound keeps clear of touchlink, which hands out group IDs upward from 0x0001, and of IDs set by hand, such as 0x30, which the zhaquirks library uses for some devices. IDs from 0xff00 up are reserved. Existing groups keep their IDs. If you type an ID yourself in the "Add group" form, ZHA still accepts any valid one, including a low or previously used number.

The author notes that this makes reuse unlikely but not impossible, because a freed ID is still one of about 65,000 candidates. Cleaning old group data out of Home Assistant's registry needs a separate fix.

Errors instead of silent failures

The second pull request covers five situations where group creation did not do what was asked:

  • a name that was already taken created nothing, and Home Assistant showed "Unknown error";
  • group IDs outside the valid range of 0x0001 to 0xfff7, such as 0, were accepted although no device would ever join them;
  • an ID that was already in use added the new members to the existing group;
  • a member that cannot join a group, for example an endpoint without the Groups cluster, left the group without it while reporting success;
  • a group deleted while it was still being created was returned as if it existed.

Each of these now raises an error with the reason. The Home Assistant interface still shows "Unknown error" for now, and displaying the actual message needs a follow-up change in Core. A member that could join but does not answer, such as a switched-off bulb, still does not cause an error.