When doing a Matter update, the server starts a separate OTA Provider. It’s log are not reflected in the Matter Server logs, however, the add-on specific config directory has a an update directory with directories for each node.
I’ve tested the Eve Weather update here, and it seems that retransmission fails 4 times in a row, then the OTA Provider gives up.:
[1746303124.068037][454:454] CHIP:EM: >>> [E:27017r S:5728 M:209871542 (Ack:162649340)] (S) Msg RX from 1:00000000000000A9 [6DB7] --- Type 0002:10 (BDX:BlockQuery)
[1746303124.068074][454:454] CHIP:EM: Found matching exchange: 27017r, Delegate: 0x5555a64580
[1746303124.068088][454:454] CHIP:EM: Rxd Ack; Removing MessageCounter:162649340 from Retrans Table on exchange 27017r
[1746303124.068097][454:454] CHIP:BDX: OnMessageReceived: message 0x10 protocol (0, 2)
[1746303124.068102][454:454] CHIP:ATM: Handling received BDX Message
[1746303124.068106][454:454] CHIP:ATM: BlockQuery
[1746303124.068109][454:454] CHIP:ATM: Block Counter: 177
[1746303124.074194][454:454] CHIP:BDX: OutputEvent type: QueryReceived
[1746303124.074293][454:454] CHIP:ATM: Sending BDX Message
[1746303124.074298][454:454] CHIP:ATM: Block
[1746303124.074301][454:454] CHIP:ATM: Block Counter: 177
[1746303124.074303][454:454] CHIP:ATM: Data Length: 1024
[1746303124.124408][454:454] CHIP:BDX: OutputEvent type: MsgToSend
[1746303124.125530][454:454] CHIP:EM: <<< [E:27017r S:5728 M:162649341 (Ack:209871542)] (S) Msg TX to 1:00000000000000A9 [6DB7] [UDP:[fd82:4325:bafa:1:df62:9f24:7a1:383f]:5540] --- Type 0002:11 (BDX:Block)
[1746303125.604308][454:454] CHIP:EM: Retransmitting MessageCounter:162649341 on exchange 27017r Send Cnt 1
[1746303127.023572][454:454] CHIP:EM: Retransmitting MessageCounter:162649341 on exchange 27017r Send Cnt 2
[1746303129.239121][454:454] CHIP:EM: Retransmitting MessageCounter:162649341 on exchange 27017r Send Cnt 3
[1746303132.653976][454:454] CHIP:DIS: SRV record already actively processed.
This might be related to RF interference and/or potentially made worse the fact that this is a battery device connecting through Thread routers.
I was finally able to update my Eve Weather to version 3.5.0. Unfortunately, I was unable to do this in Home Assistant until the end - even with the solutions suggested here.
Of my 5 Eve Weather, I had to
delete all 5 from Home Assistant and update them via Apple HomeKit,
first reset 3 out of 5 devices and reintegrate them into HomeKit,
in 4 out of 5 cases, several attempts to download and install until it finally worked.
I’ve never had such a disastrously difficult update with any of my numerous smart home devices - and not even with Eve Weather. Hopefully this won’t happen again.
Yes it sounds like the “trick” is to get the firmware update successfully transmitted to the device, and for some reason this fails more often than not.
Well, if Eve Weather really does go to sleep during an OTA firmware upload/update this is completely illogical and therefore an undesirable behavior. However, devs are currently investigating the root cause - which is not a user error.
Why is it illogical.
Many servers support a continue download function and it would make sense to have it as part of the standard in a network that is not high bandwidth.
So I did some more investigation, and written previously, this doesn’t seem to be a Matter Server/OTA Provider problem. I was able to reproduce the problem in my production network as well, and started to investigate some more. My Thread network is quite heterogeneous, with device from Aqara, Eve, Google, Nanoleaf and ONVIS all on the same Thread network. Now since Eve Weather is an end device in the Thread network, the device relies on the parent router to transmit messages. I repeated the update at least 10 times, but never succeeded. Only when I took the routers the device was connected through (I used some ot-cli commands to determine that, but it is complicated and not very reliable to write it down here), and the Eve Weather was directly a child of the OTBR, the update worked. So: Taking all Thread routers temporarily offline and update the device might be a solution. Or setup a dedicated temporary Thread network for the update.
I am not entirly sure why many messages make it to the device, and suddenly a couple in a row don’t. It doesn’t seem RF related, I rather belive that the router or end device might just temporarily be busy and dropping messages.
Do you have updated your Onvis?
There is an important update for it, which will fix an issue that will make your device go unavailable and I can also cripple your Thread mesh network.
I’m only using the ZBT-1, so I have just one Thread border router. Even when I put the Eve Weather devices right next to the stick, the OTA updates still fail. I’ve tried everything, no chance … :/.
Wait for the Matter server update. Although it doesn’t seem to finally solve the problem (which seems to be with the older firmware of Eve Weather), some users had success with the beta of the new version of Matter server - and its updated OTA provider service. Fingers crossed.
Bummer. What have you already done to rule out signal interference besides putting the devices next to ZBT-1? If you have any other Thread hubs, try to put them next to a hub that is least likely to be close to a source of signal interference. Try to deactivate 2.4 GHz WiFi before starting the update. That’s what I have done. Additionally, you could change the Thread channel. I didn’t need to do that.
