Did a hub firmware update break IKEA buttons binding?

Devices & Integrations
1

Hi @nayelyz !

I’ve been seeing some error logs when pairing IKEA buttons that were not there before (can’t say when they started). The last button I paired recently (a Symfonisk Gen2 with my custom driver) threw the error but works fine so I didn’t care much about it. But now I believe there’s actually an issue worth investigating.

To remove my custom driver from the equation I tested re-pairing (without deleting) an old 5-button with the stock driver and the exact same error is there too. Even worse: buttons did no longer send events when they worked before pairing again.

This log is with hub firmware 57.14 and the stock Zigbee Button driver:

2025-06-17T18:20:48.464075592Z WARN Zigbee Button  Error encountered parsing Zigbee message defaulting to generic body: [string "st/zigbee/zdo/mgmt_bind_response.lua"]:60: Unexpected destination address type 0 in binding table response
2025-06-17T18:20:48.466100759Z INFO Zigbee Button  <ZigbeeDevice: 451cf75a-db76-42bb-8851-53b258d8a932 [0x00F2] (TRADFRI Round)> received Zigbee message: < ZigbeeMessageRx || type: 0x00, < AddressHeader || src_addr: 0x00F2, src_endpoint: 0x00, dest_addr: 0x0000, dest_endpoint: 0x00, profile: 0x0000, cluster: 0x8033 >, lqi: 0xD2, rssi: -31, body_length: 0x003D, GenericBody:  0F 00 00 03 00 03 F4 C5 D9 FE FF 57 0B 00 01 00 00 01 4C 13 F4 C5 D9 FE FF 57 0B 00 01 01 00 03 21 F5 07 02 00 97 6D 28 01 F4 C5 D9 FE FF 57 0B 00 01 06 00 03 21 F5 07 02 00 97 6D 28 >
2025-06-17T18:20:48.472086967Z TRACE Zigbee Button  Found ZigbeeMessageDispatcher handler in zigbee_button -> ZigBee multi button -> IKEA Sweden
2025-06-17T18:20:48.474197259Z INFO Zigbee Button  Executing ZdoHandler
2025-06-17T18:20:48.477375884Z ERROR Zigbee Button  TRADFRI Round thread encountered error: [string "st/dispatcher.lua"]:270: Error encountered while processing event for <ZigbeeDevice: 451cf75a-db76-42bb-8851-53b258d8a932 [0x00F2] (TRADFRI Round)>:
    arg1: {address_header={cluster={byte_length=2, field_name="cluster", value=32819}, dest_addr={byte_length=2, field_name="dest_addr", value=0}, dest_endpoint={byte_length=1, field_name="dest_endpoint", value=0}, profile={byte_length=2, field_name="profile", value=0}, src_addr={byte_length=2, field_name="src_addr", value=242}, src_endpoint={byte_length=1, field_name="src_endpoint", value=0}}, body={body_bytes="\x0F\x00\x00\x03\x00\x03\xF4\xC5\xD9\xFE\xFF\x57\x0B\x00\x01\x00\x00\x01\x4C\x13\xF4\xC5\xD9\xFE\xFF\x57\x0B\x00\x01\x01\x00\x03\x21\xF5\x07\x02\x00\x97\x6D\x28\x01\xF4\xC5\xD9\xFE\xFF\x57\x0B\x00\x01\x06\x00\x03\x21\xF5\x07\x02\x00\x97\x6D\x28"}, body_length={byte_length=2, field_name="body_length", value=61}, lqi={byte_length=1, field_name="lqi", value=210}, rssi={byte_length=1, field_name="rssi", value=-31}, type={byte_length=1, field_name="type", value=0}}
"[string "st/dispatcher.lua"]:270: Error encountered while processing event for <ZigbeeDevice: 451cf75a-db76-42bb-8851-53b258d8a932 [0x00F2] (TRADFRI Round)>:
    arg1: {address_header={cluster={byte_length=2, field_name="cluster", value=32819}, dest_addr={byte_length=2, field_name="dest_addr", value=0}, dest_endpoint={byte_length=1, field_name="dest_endpoint", value=0}, profile={byte_length=2, field_name="profile", value=0}, src_addr={byte_length=2, field_name="src_addr", value=242}, src_endpoint={byte_length=1, field_name="src_endpoint", value=0}}, body={body_bytes="\x0F\x00\x00\x03\x00\x03\xF4\xC5\xD9\xFE\xFF\x57\x0B\x00\x01\x00\x00\x01\x4C\x13\xF4\xC5\xD9\xFE\xFF\x57\x0B\x00\x01\x01\x00\x03\x21\xF5\x07\x02\x00\x97\x6D\x28\x01\xF4\xC5\xD9\xFE\xFF\x57\x0B\x00\x01\x06\x00\x03\x21\xF5\x07\x02\x00\x97\x6D\x28"}, body_length={byte_length=2, field_name="body_length", value=61}, lqi={byte_length=1, field_name="lqi", value=210}, rssi={byte_length=1, field_name="rssi", value=-31}, type={byte_length=1, field_name="type", value=0}}
"[string "st/dispatcher.lua"]:270: Error encountered while processing event for <ZigbeeDevice: 451cf75a-db76-42bb-8851-53b258d8a932 [0x00F2] (TRADFRI Round)>:
    arg1: {address_header={cluster={byte_length=2, field_name="cluster", value=32819}, dest_addr={byte_length=2, field_name="dest_addr", value=0}, dest_endpoint={byte_length=1, field_name="dest_endpoint", value=0}, profile={byte_length=2, field_name="profile", value=0}, src_addr={byte_length=2, field_name="src_addr", value=242}, src_endpoint={byte_length=1, field_name="src_endpoint", value=0}}, body={body_bytes="\x0F\x00\x00\x03\x00\x03\xF4\xC5\xD9\xFE\xFF\x57\x0B\x00\x01\x00\x00\x01\x4C\x13\xF4\xC5\xD9\xFE\xFF\x57\x0B\x00\x01\x01\x00\x03\x21\xF5\x07\x02\x00\x97\x6D\x28\x01\xF4\xC5\xD9\xFE\xFF\x57\x0B\x00\x01\x06\x00\x03\x21\xF5\x07\x02\x00\x97\x6D\x28"}, body_length={byte_length=2, field_name="body_length", value=61}, lqi={byte_length=1, field_name="lqi", value=210}, rssi={byte_length=1, field_name="rssi", value=-31}, type={byte_length=1, field_name="type", value=0}}
"[string "zigbee-multi-button/ikea/init.lua"]:87: attempt to index a nil value (field 'zdo_body')"""

It’s easy to replicate because the error happens every time you pair a IKEA button and looks like the model or driver doesn’t matter, be it an old 5-button remote with stock driver or modern buttons like rodret or symfonisk with my custom driver.

Edit: All the buttons, old and new, are with out-of-the-box firmware by the way, so it’s not a change of behaviour in the buttons or the drivers, it’s something internal when setting the bindings in the configure lifecycle.

2

Turns out it all starts with this “read binding table” code that sends the binding request. I have these lines in my custom driver too but I’ve just realized they are not needed for new devices like RODRET and other modern buttons, that’s why the new buttons work fine even with the response to that binding request failing.

But those are needed for old buttons, the ones supported by stock drivers like the TRADFRI 5-button remote. At least for old firmwares that had this weird binding procedure.

New firmwares for TRADFRI buttons like 24.x do not require that type of binding for them to work and send the events. Maybe it would be nice that SmartThings could update them, although not automatically by default or it would break a lot of things for existing users.

4

Hi, @mocelet

Can you open support access to your account, please?
I remember someone reported an issue with IKEA TRADFRI 5 devices:

To investigate further, can you please open support access to your account? I just tried and got an error saying the access isn’t enabled.

5

Thanks, access granted.

Actually I linked to that post in the previous comment because it explains how the pairing works in old buttons like the 5-button TRADFRI, although that was an issue with the hub not being able to add itself to more groups because of the 32 limit.

In this case, the code to add the hub to the group doesn’t even get to run because the response handler crashes before due to a nil reference. But the problem is not the response or the driver crashing, that’s the consequence of, I believe, a bad request to read the binding table that makes the button respond with something different than before. The code to read the binding table worked before but not now.

Coincidentally, @steven.green mentioned in that comment that the Zigbee library was receiving an overhaul and I believe that’s the reason the same code from stock drivers to read the binding table have been working forever and now, apparently, sends a bad request to the button or somehow doesn’t handle the response correctly.

6

Hi @mocelet,

Thanks for bringing this to our attention. It led to us discovering a bug that was shipped with 0.57 firmware where the ZDO message body payloads that a driver is receiving from the hub are not formatted correctly. The bug is an off by 1 error where the last byte is missing and there is an extra byte at the start of the payload. We will include this in the next production firmware release. For now, we will be patching our drivers with a fix that will allow for de-serialization of the ZDO messages and thus setup the correct hub groups when joining these devices. Adding that file and directory structure to your driver should allow these devices to be joined and function again. Sorry for the inconvenience.

1 Like
7

Hi @carter.swedal , thanks for the insights! Just copied the mitigation file provided in the PR and I can confirm old buttons pair correctly now and work fine.

As other temporary workarounds for specific hub firmware versions, is there a way to know when that won’t be necessary because all the hubs have been updated?

2 Likes
8

The way to know if the workaround is necessary is by checking the version.rpc == 8. We will increase that value reported by the hub when the fix is present. I cant say a date when we know all hubs and hub platforms will get firmware with a fix for the root cause.

1 Like
9

Thanks, had to make the question more generic, I meant if there’s a website or document to know what is the current minimum version that a driver has to support.

I’ve seen stock drivers with checks for, let’s say, rpc version 5, and sometimes I wonder if that’s just old code where the condition is not needed or if somewhere there is an old hub still running that old version.

Asking because some really nice features like modular profiles started in rpc version 8, granted it’s quite new, but would be nice to eventually be able to check a site where it said “all hubs currently support rpc version 8 or later” so developers know they can just use modular profiles instead of the old workarounds with multiple profile combinations.

10

I’ve seen stock drivers with checks for, let’s say, rpc version 5, and sometimes I wonder if that’s just old code where the condition is not needed or if somewhere there is an old hub still running that old version.

We are not great about removing these version checks as all hubs get new firmware. So sometimes they shouldn’t be necessary, but there are cases where hubs are offline for a long time, and then come online with old firmware; if these checks are removed its possible (although unlikely in most cases) that a user would experience issues until their hub gets a firmware update. I would suggest leaving them in there.

would be nice to eventually be able to check a site where it said “all hubs currently support rpc version 8 or later” so developers know they can just use modular profiles instead of the old workarounds with multiple profile combinations.

I will bring this up internally. I agree it would be nice to have the information about all hub platforms and what firmware versions are currently present in the field, but currently that doesn’t exist afaik.

3 Likes