Anyone having this issue? Woke up to the notice saying the HA 2026.5 was ready... as well as an Ikea update for the Bilresa two button remotes, from the current 1.8.5 to 1.9.15.
Warning box given that it may take a long time. But what I see is failure after it initiate downloading. Usually fails before 10%.
My buttons are actually quite stable now, so this isn't an emergency. Still.....
3 Likes
Mine has been stuck at Installing (1%) for 30 minutes now.
My matter app logs look like this:
2026-05-08 01:32:57.386 (MainThread) INFO [matter_server.server.device_controller] <Node:1> Setting up attributes and events subscription.
2026-05-08 01:33:08.098 (MainThread) INFO [matter_server.server.device_controller] <Node:1> Subscription succeeded with report interval [0, 900]
2026-05-08 01:34:02.658 (MainThread) INFO [matter_server.server.device_controller] <Node:1> Update to software version 17367055
2026-05-08 01:34:02.767 (MainThread) INFO [matter_server.server.device_controller] <Node:1> Software update found: 1.9.15 (17367055) from UpdateSource.MAIN_NET_DCL, current 1.8.5 (17301509)).
2026-05-08 01:34:02.768 (MainThread) INFO [matter_server.server.device_controller] <Node:1> Downloading update from 'https://ota.matter.ikea.com/files/4476_32769_17367055_db0c1797-0391-46ff-bf43-602b29c2eed2.ota'
2026-05-08 01:34:02.980 (MainThread) INFO [matter_server.server.ota.provider] Update file '4476_32769_17367055_db0c1797-0391-46ff-bf43-602b29c2eed2.ota' downloaded to '/config/updates/1'
2026-05-08 01:34:02.980 (MainThread) INFO [matter_server.server.device_controller] <Node:1> Starting update using OTA Provider.
2026-05-08 01:34:02.981 (MainThread) INFO [matter_server.server.ota.provider] Starting OTA Provider
2026-05-08 01:34:02.984 (MainThread) INFO [matter_server.server.ota.provider] Commission and initialize OTA Provider
2026-05-08 01:34:03.095 (Dummy-2) INFO [chip.ChipDeviceCtrl] Established secure session with Device
2026-05-08 01:34:03.419 (Dummy-2) INFO [chip.ChipDeviceCtrl] Commissioning complete
2026-05-08 01:34:03.420 (MainThread) INFO [matter_server.server.ota.provider] OTA Provider App commissioned with node id 990001.
2026-05-08 01:34:03.762 (MainThread) INFO [matter_server.server.ota.provider] Waiting for target node update state change
2026-05-08 01:34:03.982 (MainThread) INFO [matter_server.server.ota.provider] Update state changed from <UpdateStateEnum.kIdle: 1> to <UpdateStateEnum.kQuerying: 2>
2026-05-08 01:34:06.704 (MainThread) INFO [matter_server.server.ota.provider] Update state changed from <UpdateStateEnum.kQuerying: 2> to <UpdateStateEnum.kDownloading: 4>
2026-05-08 01:37:10.500 (Dummy-2) CHIP_ERROR [chip.native.EM] <<5 [E:2507i with Node: <0000000000000001, 1> S:34123 M:137358815] (S) Msg Retransmission to 1:0000000000000001 failure (max retries:4)
2026-05-08 01:37:36.444 (Dummy-2) CHIP_ERROR [chip.native.DMG] Time out! failed to receive report data from Exchange: 2507i with Node: <0000000000000001, 1>
2026-05-08 01:37:36.445 (MainThread) ERROR [matter_server.server.client_handler] [140486418542336] Error while handling: read_attribute (node 1): src/app/ReadClient.cpp:745: CHIP Error 0x00000032: Timeout
2026-05-08 01:39:41.210 (Dummy-2) CHIP_ERROR [chip.native.EM] <<5 [E:2508i with Node: <0000000000000000, 0> S:0 M:84088486] (U) Msg Retransmission to 0:0000000000000000 failure (max retries:4)
2026-05-08 01:39:56.797 (Dummy-2) CHIP_ERROR [chip.native.SC] CASESession timed out while waiting for a response from peer <0000000000000001, 1>. Current state was 4
2026-05-08 01:39:56.797 (MainThread) ERROR [matter_server.server.client_handler] [140486418542336] Error while handling: read_attribute (node 1): src/protocols/secure_channel/CASESession.cpp:594: CHIP Error 0x00000032: Timeout
2026-05-08 01:50:32.109 (Dummy-2) CHIP_ERROR [chip.native.DMG] Subscription Liveness timeout with SubscriptionID = 0xd7fc91fe, Peer = 01:0000000000000001
2026-05-08 01:50:32.111 (MainThread) INFO [matter_server.server.device_controller] <Node:1> Subscription failed with CHIP Error 0x00000032: Timeout, resubscription attempt 0
I was able to update one Bilresa after several tries but no luck with the second one yet. Maybe their servers are overloaded?
1 Like
Same problem here, been trying all morning without luck, 4 units, none will update
mine failing at 33%
My 3 Bilresas upgraded successfully yesterday, although they also restarted the upgrade around the 10% mark - maybe a timeout somewhere in the chain. One other thing - if you have set a custom node name from the beta Matter Server GUI (Node xx @1:x | Endpoint 0 | Cluster xx (BasicInformation) | Node Label ), that gets reset after the upgrade and I had to go back in to add it back (so the thread diagram displays the custom node names).
I had updated several types of Ikea devices a few weeks ago (from Test-DCL), and if I recall correctly, it is the Bilresa that has a strange behavior....it was mentioned by someone that there are actually 3 separate firmwares in the download file, and each one requires a reset. So what you'll see is the first attempt will fail at around 10% (but it just loaded the first piece and rebooted), then the second attempt to download will fail somewhere oh around 20-30% (as it gets the second piece and reboots) and then the third attempt goes all the way to 100%.
2 Likes
I attempted about 5 times yesterday to update Bilresa button #1 and the furthest I ever got was about 59%. This morning I tried the Bilresa #2 and it succeeded and fairly quickly at that. I'm back to trying yesterday's problem Bilresa #1 and it's taking a looooong time. It's physically closer to the Thread border router than the #2 is, but do I need to move it close to another node regardless of where the border router is?
I'm getting the following message:
Error updating: target node did not process the update file.
Is anyone else seeing this?
It will be hard to say without knowing what parent node it's attached to. If you have a way of getting the Thread topology then one should be able to see which node it is attached to and then move it closer to that node.
If you don't have a Thread topology map, then one suggestion would be to move it close to the TBR, pull the batteries out for about 10sec and put them back in. Hopefully it will attach to the TBR. Then after the device has come back up, start the download which will hopefully make the download quicker. After it has finished, then when you move it back to its desired location, do the battery re-insert again to make it join a nearby node.
1 Like
However, please note there is a caution in the upgrade instructions to not remove the power while the updated is in progress!
I first moved my devices next to the antenna with no effect. But when I moved them next to the node through which their network connection is made, they updated pretty quickly.
The position of my problem Bilresa #1 didn't seem to make a difference, whether near the border router or near its nearest usual neighbor. Also when I took out the batteries and then re-inserted them after 10 seconds I got nowhere.
But things improved once I replaced the original batteries with a new set, hit Update, and walked away. Partly this is the time-honored "a watched pot never boils" theory of device repair.
The fact that the original batteries claimed a 100% level during my failed update attempts now seems suspect since they were installed ~4 months ago. In retrospect the other Bilresa (the one which updated a lot more easily) seems to be more realistic about its reported battery level.
My bilresa switches are updated to 1.9.15 since that I’m able to allocate the switch to the Home Assistant but I can’t allocate anything to the buttons anymore. I have 6 switches with the same issue. Added one to Apple HomeKit directly, same issue. Device added but all buttons are dead.
Thanks all for sharing their own experiences.
Finally got the Bilresas (5) updated. Just kept at it despite the failures.
Not sure if the rationale is related to the suggestion that multiple components have to be updated & each requires a new restart of the download procedure... But I did see that after a set of complete dud update initiations each Bilresa generally would get farther along in the process before the update crashed out.
Average number of update attempts per device before success would be around 6, I'd estimate.
Slooooowwww download speeds and ac lot of variation. Curiously, the one that was particularly sloth-like was right next to another Bilresa that was probably the fastest. Hard for me to blame that on the Thread network, though I'm sure a lot of the variation was due to that.
This comment helped me. I had to initiate the update four times. The first three went to 10 % or similar, but the version stayed the same.
The fourth time it went up to 100 % and the version changed. No other modifications, only updating until it succeeded.
After a couple of days of trying this update, even sitting with the switch in hand pressing a button regularly to try and keep the device awake, no luck. Managed to get to 20 % on a couple of occasions.
Finally got it to work this morning, by removing a battery, after replacing the battery then leaving it alone for a minute and then starting the upgrade. First time successful!
I know this means a manual intervention, but at least it worked!!!
2 Likes
Reading the comments here does reveal how unreliable this device (and Matter?) is.
I'm sure it is not a deterministic path that will work for all, but here is what I believe it made a difference for me:
- Upgrade Matter Server to matterjs latest version (Package matterjs-server · GitHub)
- Remove batteries from the device for more than 30 seconds
- Leave alone for some time, make sure that it is back up communicating
- Move it next to your main TBR
- Push the upgrade button and leave the device alone for the rest of the day if needed
Hth,
anthonws.
Thank you very much! On some devices, the update had to be started three or four times, and on others, five or six times. However, all devices have now received the updates.
What a pain to update my 3 Bilresa! The updates would constantly fail at varying degrees of completion - no pattern. Batteries were fresh, and remotes were close to the Thread stick and a couple routing devices I had just added given my Thread mesh is brand new. I found that the updates worked best if done immediately after adding the remote. Interestingly, mine came with 1.8.7 and I was only offered an update to 1.9.11 (beta matter server & test firmware enabled).
I wonder if part of the issue was interference. I use all 3 WIFI 1-6-11 channels in my home (6 APs), and have a Zigbee network on ch 20. The Thread mesh is on ch 15. The updates, done immediately after resetting the device (in some cases it was just dead - no LEDs - so I had to reset it by holding the back button until it flashed red), were done when the Zigbee and WIFI activity was at its lowest (wife & kids in bed). In other words, I don't know whether the trick was less interference, being freshly added, luck, or a combination.
I did not have all these issues with the Ikea KLIPPBOK leak sensors (adding and updating was free of issues once I configured my ipv6).
Thread is not designed for high data throughput, so yeah it takes awfully long. I just started the updates one at a time and left it alone. All Bilresas updated successfully without further interventions by me. I had the impression that some needed longer or possibly restarted the update process themselves. I just let them do and everything is fne now.
Does anybody have a changelog for the new update? Obviously the Bilresas are now on Matter Version 1.4 , but apart from that any known changes?