Potential issue with events in bellows for IKEA Bilresa 2 button remote?

[iamjoshk]

Not sure where to bring this up and happy to move the conversation somewhere else if desired. Or close it if there already discussion happening amongst the devs.

Anyway, I submitted the PR for the quirk v2 for IKEA Bilresa 2 button remote and I started a post on the community forums about it working with ZHA. A number of commenters in the post have mentioned that they are not seeing any events from the remote before or after using the quirk. I was rereading through the post and noticed that all of the affected users seem to be using coordinators with EFR32MG24 and EFR32MG21 based radios, including the ZBT-2.

I am personally using a Sonoff Dongle P with 20211217 firmware and don't have a second coordinator, let alone one with EFR32MG24 or EFR32MG21 radios to test this out.

I am wondering if there is something in bellows that is blocking or not generating the zha_event on the event bus for the Bilresa 2 button remote (and possibly other devices). The data set from the post is obviously very small, but the coordinator radio stood out as a common theme.

[MattWestb]

Its expected then Z2M have patched the TI coordinator firmware for listening on all group broadcast so no need defining Zigbee groups for getting the commands sent from the device.
Bellows must defining the groups it shall listing on and its done by making Zigbee groups in ZHA (ZHA is doing group 0x0000 that many devices is using as default also normal ZLL devices).
Normal its no problems if the device is supporting binding and reporting that is moderate.
But Bilresorna is certificated and have written its supported device and group binding (verified by sniffing) but the devices is not honoring the setting and only using the "IKEA default group" for sending commands and reports.
From fresh sniffing:

IEEE 802.15.4 Data, Src: 0x0415, Dst: 0x91f8
ZigBee Network Layer Data, Dst: Broadcast, Src: 0x0415
ZigBee Application Support Layer Data, Group: 0x549a, Src Endpt: 1
    Frame Control Field: Data (0x0c)
    Group: 0x549a
    Cluster: On/Off (0x0006)
    Profile: Home Automation (0x0104)
    Source Endpoint: 1
    Counter: 21
ZigBee Cluster Library Frame
    Frame Control Field: Cluster-specific (0x01)
    Sequence Number: 17
    Command: On (0x01)

The remote is 0x0415 and sending one unicast to its parent 0x91f8 and the parent is sending the command with broadcast to the group 0x549a that all routers is rebroadcasting thru the mesh.
I was doing the first tests with Coornbee II and then moving my controllers to my test setup with ZBT-2 and its working OK for my then i have defining one group for the new Kajplats like this:

Group information
Name: Gen4
Group Id: 0x549a

With the 2 Kajplats and some older IKEA lights. ZHA is adding the coordinator to the group if its more then i device in the group after next restart and its working OK
This is the bad side then IKEA have not putting time / money for doing one full implementation that is making the device no being useful for open system but have going well in for matter and ZLL implantation.
We need working binding and reporting for the controller in Zigbee mode and also implantation of binding in Matter so controller can sending commands to lights also if the matter controller is offline or part of the thread network is not working OK for getting autonomous function like old TF and ZHA can do if configuring the system OK.

[TheJulianJES]

I think we should have an EZSP firmware patch in-place (for ZBT devices and more), so all groups are listened to, without needing the coordinator to explicitly join them? Or was that disabled at some point? I'll check..

[MattWestb]

That can being god but we still have some X000 user with old devices that not getting updates and is not easy / impossible patching like old EM35X coordinator (one was in the community thread) that we have getting EZSP 6.3.X update from Gary but we cant getting updates to EZSP 7.X then its not supported in newer SDKs.

[MattWestb]

By the was i think it can being good getting one function getting Bellows listening to groups without adding devices then most user is using this controller for automatons and not searing lights (that is not working good then can only using one group).
Perhaps "Zigbee listening groups".

[MattWestb]

I think the group shall being defined with dec so must using 21658 for getting the hex 0x549A as the controller is using.

[MattWestb]

Also one patch can being adding the Group cluster as in so it can being used in groups as dummy but still need one more device for getting it working OK.
(I still have one pending PR for only 11 mouths for fixing Somrig #3840 )

[puddly]

We explicitly support the old method of manually registering known groups in addition to the new method with firmware support:

bellows/bellows/zigbee/application.py

Lines 248 to 260 in 0d5b1b7

	if FirmwareFeatures.MEMBER_OF_ALL_GROUPS in self._ezsp._xncp_features:
	# If the firmware passes through all incoming group messages, do nothing
	endpoint_cls = EZSPEndpoint
	else:
	endpoint_cls = EZSPGroupEndpoint
	try:
	db_device = self.get_device(ieee=self.state.node_info.ieee)
	except KeyError:
	pass
	else:
	if 1 in db_device.endpoints:
	group_membership = db_device.endpoints[1].member_of

We also patch the firmware to get rid of the SDK packet filtering:

https://github.com/NabuCasa/silabs-firmware-builder/blob/8cc94e4f569c3cd7df7bf27c736037ad5c142e03/src/zigbee_ncp/extension/xncp_common_extension/src/xncp_common_commands.c#L91-L96

I picked one of these remotes up last week and can confirm that on the ZBT-2 (or the Yellow or the ZBT-1) running recent firmware, the group packets are picked up correctly (this is a double click):

2026-01-14 14:15:32.279 DEBUG (MainThread) [zigpy.application] Received a packet: ZigbeePacket(timestamp=datetime.datetime(2026, 1, 14, 19, 15, 32, 279030, tzinfo=datetime.timezone.utc), priority=None, src=AddrModeAddress(addr_mode=<AddrMode.NWK: 2>, address=0x83D3), src_ep=1, dst=AddrModeAddress(addr_mode=<AddrMode.Group: 1>, address=0x549A), dst_ep=255, source_route=None, extended_timeout=False, tsn=67, profile_id=260, cluster_id=5, data=Serialized[b'\x05|\x11\x17\x07\x00\x01\r\x00'], tx_options=<TransmitOptions.NONE: 0>, radius=0, non_member_radius=0, lqi=252, rssi=-37)
2026-01-14 14:15:32.279 DEBUG (MainThread) [zigpy.zcl] [0x83D3:1:0x0005] Received ZCL frame: '05 7c 11 17 07 00 01 0d 00'
2026-01-14 14:15:32.280 DEBUG (MainThread) [zigpy.zcl] [0x83D3:1:0x0005] Decoded ZCL frame header: ZCLHeader(frame_control=FrameControl<0x05>(frame_type=<FrameType.CLUSTER_COMMAND: 1>, is_manufacturer_specific=1, direction=<Direction.Client_to_Server: 0>, disable_default_response=0, reserved=0, *is_cluster=True, *is_general=False), manufacturer=4476, tsn=23, command_id=7, *direction=<Direction.Client_to_Server: 0>)
2026-01-14 14:15:32.280 DEBUG (MainThread) [zigpy.zcl] [0x83D3:1:0x0005] Unknown cluster command 7 '00 01 0d 00'

For old fimrwares, the coordinator needs to be part of group 0x549A, as @MattWestb said. I think we can add a new quirks V2 API to list these groups?

[MattWestb]

Thanks Puddly
IKEA have used other groups before for its custom scene commands to its WS and CWS lights but the controllers was honer the bind and reporting commands so was no problems. Only that the sepcial scene commands must being tagged with the group for working then sending scene change commands (if have defined scene in the light with the right group).
But if i remember right the old simple OSRAM remote was having some strange locked group and perhaps some Aqara and tuya devices but i have not all in mind.

If adding possibility for "default / hard coded group" in quirks V2 its being very flexible and can easy being used if more strange device need it in the future.

By the was was you getting one BILRESA scroll wheel (32768) and some Köttbullar by your IKEA trip Puddly ?????

[iamjoshk]

For my own clarification and to help others having this issue, until there is a more permanent solution (like puddly's suggestion about a quirks V2 API for listing groups) are we talking about manually adding group 0549A (actually the decimal representation 21658 in the Group ID below) and then selecting at least two devices for that group? Do the devices need to actually be IKEA devices (for those who may only have a single IKEA device that is causing them problems)?

[MattWestb]

I can being wrong then im not one code worrier but before one group must being 2 devices for bellows adding it self to the group. But then i looking im my production system that was having many groups before IKEA was taking away group binding on most controllers i still have some groups with only one device and one with only the coordinator.
Now its possible adding the coordinator as one light in the group and it working but i have not testing if its working.
The device must have group as in cluster and most of good devices (lights / plugs) is doing that OK.

Test how its working then i dont do drastically think in production system and the large test system is running with latest ZBT-2 so shall have the group patch.

[carryonrewardless]

I am also interested in getting this device working with my SONOFF Zigbee 3.0 USB Dongle Plus V2 (EFR32MG21 radio) coordinator using ZHA. Is there a way to help with testing of this?

[MattWestb]

For the moment if having patched firmware on the EZSP coordinator all shall working OK.
If using standard (not Open Home Foundation ones) you need adding one Zigbee group with ID 21658 and name of your choice and i think also need adding 2 devices (lights or plugs or the coordinator) so the system is start listening to the group.

[carryonrewardless]

Ok I have added the zigbee group with ID 21658 and the devices I want to switch on and off (Circ pump switches) were available to be added and so I added them both to this group.
The Bilresa buttons were not available to add to this group.
See screenshots.

So with this arrangement pressing buttons on either Bilresa will switch on both of the Circ pump switches.
No events are triggered in zha_event but the buttons do trigger actions.
How do I configure so the the kitchen Bilresa button only triggers the kitchen Circ Pump switch?

Does this help get these Bilresa button devices ready for general use?

[MattWestb]

Im not one code worrier so i dont knowing how the code is working.
In some groups i have the coordinator being added (also without any other devices) and other is not in and cant being added so i cant grabbing the logic here then its being changed more times.
If like only one plug being controlled delete the other from the group.
The Bilresa is hard coded to that group so if adding more of then all is sending the commands that group and cant being changed.

[carryonrewardless]

Thanks to both of you guys for what you are doing to make this device work.
Do we have any idea as to the differences between a ConbeeII (working) and a EFR32MG21 radio device (not working) in how they each handle the hard-coded 21658 group?