Repository navigation
Potential issue with events in bellows for IKEA Bilresa 2 button remote? #708
Description
Activity
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
0x0415and sending one unicast to its parent0x91f8and the parent is sending the command with broadcast to the group0x549athat 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: 0x549aWith 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.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..
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.
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".I think the group shall being defined with dec so must using
21658for getting the hex0x549Aas the controller is using.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
We also patch the firmware to get rid of the SDK packet filtering:
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?Reacted by TheJulianJESReacted by MattWestbReacted by MattWestbThanks 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 ?????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 representation21658in 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)?
Reacted by MattWestbI 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.
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?
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 ID21658and 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.Reacted by Rick ElrodOk 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?
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.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?Silabs SDK is needed putting one list if witch groups (in Zigbee network its broadcast addresses) the device shall listening on like you was doing with the 2 plugs was getting the 21658 group added to its group table so the device is listening to it.
Then compiling one NCP (coordinator firmware) its use the standard implantation silabs have doing so need do the same for getting the messages from groups (0x0000 is being added as Zigbee standard).
TI have the same approach but Z2M have patching the firmware so its not filtering and the host is getting all broadcast from the network. Dresten have there own implementation for Rasp/Cornbee that we is not knowing so much of but they is listening to all groups as default.With later patched EZSP it shell working without adding separate groups but is i have saying not all firmware have implementing the work around like my still going strong "IKEA Billy NCP" but its working with by adding the needed group.
Probably need a dev to weigh in here, but I think once the custom group is added to ZHA, going into the remote and pairing to the coordinator might be the way to go here.
From the remote device page -> manage zigbee device -> bindings -> select the coordinator from bindable devices -> check off
Groups,IkeaBilresaLevelControl,OnOff, andScenesCluster(or maybe all of them?) -> click Bind Group. Then maybe restart HA.When I follow those steps the only option is to Unbind or Bind the coordinator. Bind Group is greyed out.
We are talking of Zigbee groups (managed from the coordinator panel) that configure lights and plugs to listened to commands sent to groups.
Controllers (by standard = not all tuyas) is being bonded to devices or groups and is managed from the controllers card >. . ."Manage Zigbee device" and the "bindings".
As the new IKEA controllers is "light" Zigbee they is accepting all binding commands but is not honor them and is only using the default group we are taking about so its one deda end (sniffed with wireshark and verified).Sadly we cant changing that so only possible working around with the default group.
Any progress on this?
We await a firmware update from Ikea to use a standard approach to zigbee group configuration rather than their default config.
Reacted by MaxOk 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?
I was able to change a zigbee plug on off with the trick of the group 21658. Any workaround to use it with another device in homeassistant?
We await a firmware update from Ikea to use a standard approach to zigbee group configuration rather than their default config.
is it confirmed that this update is coming in the near future or doesn't ikea know about this?
This is an issue with ZHA specifically. I have a Sonoff dongle-E and had all issues mentioned in this thread, tried all sorts of different firmwares and tricks using the groups and nothing caused ZHA to observe the button presses. Then I switched to Z2M and everything worked out of the box.
Reacted by Tor SeldénSo all started working nicely for me once I manually added the coordinator to group 21658 in the zigbee.db. Now I get events and all. 2 items in the group were not enough somehow.
Reacted by andrewsweet4Reacted by MattWestb@TheJulianJES and @puddly Is it possible hard coding the IKEA scene group in Bellows and or Zigpy so user with "no extended" coordinator firmware dont need adding extra groups and adding real devices in it ?
I think it can being good then many users is running on more standard or older firmware and having problems plus dont getting devices reacting on the controller then dont want it then being used for automatons and not string lights.@sorgfresser How did you add the coordinator to the 21658 group? In the group edit section in my installation, i can only choose some IKEA lamps to add to the group, but not the coordinator. Did you manually edit the zigbee.db file with an SQLite editor?
For users with EZSP devices running older still OK working firmware is little work being done for fixing the group problem for this and some other devices, Look in the linked PR above.
If / then its merged it shall not being needed adding devices to the group (or doing the group at all) then it being added to the system in one quirk for the device. Also its bringing support for scroll wheel.Another EFR32MG24 data point — SONOFF Dongle Max, BILRESA, no zha_event
Adding a non-NabuCasa Silabs coordinator to the list, in case it helps prioritize
extending the firmware patch beyond ZBT devices (re: @TheJulianJES's last comment).Coordinator: SONOFF Dongle Max (Dongle-M), Silicon Labs EFR32MG24,
stock SONOFF EmberZNet firmware V1.0.0 (SDK 7.4.5), bellows/EZSP over network.
Host: Home Assistant OS 18.1 / Core 2026.7.2 (ZHA).
Device: IKEA BILRESA 2-button (E2489, 09B9), quirk zhaquirks.ikea.bilresa2btn
loaded and recognized. Good link (LQI 136, RSSI -66), battery 100%.Symptom: No zha_event for any of the six actions. LED keeps slow-blinking.
Tried: re-pairing (near coordinator and near mains routers); binding to the
coordinator (reported successful, no effect); creating ZHA group 0x549A (21658)
with no members + full restart. None produced events — consistent with the
stock SONOFF firmware still doing SDK-level group packet filtering.Since this stock firmware isn't one of the patched NabuCasa builds, is there a
recommended path for EFR32MG24 sticks like this one — or is a coordinator swap
to patched firmware currently the only option? Happy to provide logs.- added a commit that references this issue
on Jul 19, 2026
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.