Closed Koenkk closed 1 year ago
Ok Thanks ! you want some specific tests ? Do you need that i repair or just flash and see?
when using plain z2m install and not ZHA Addon you could flash and test without issue
Upgrade from CC2652R_coordinator_20220219.hex to 20230401 without issues.
End devices: 28 Router: 9
Uptime (only) 30 minutes, but did check if all sensors and actors are OK... and they are doing just fine.
just updated from 20221226 to 20230401
End devices: 35
Router: 17
update went smooth with cc2538-bsl.py Script
I'm not sure if it's related, and I'm using ZHA, but since I upgraded to previous version my slaesh dongle, the Ikea button devices aren't firing events anymore.
I can pair them and they immediately disappear (they are marked as unavailable) and no event is fired.
Upgrade done 6 hours ago. At first the network was a little 'laggy'. But so far so good it seems better now. Devices stays online and no more table full msg. I still keep an eye on it.
Regards
During the evening, i got some table full message and one router get offline. I also feel latency in the network. It may be because all my lights are motion triggered when the luminosity is low ? So more messages on the network ? Thank you
Something is happening. 3 routers down. (on the log don"t use jardin_arrière_lampe it is a device i've disconnected physicely.)
`` zigbee2mqtt | Zigbee2MQTT:error 2023-04-01 20:25:13: Publish 'set' 'state' to 'salon-salleamanger-inter-plafonnier' failed: 'Error: Command 0x5c0272fffe16b298/2 genOnOff.on({}, {"sendWhen":"immediate","timeout":10000,"disableResponse":false,"disableRecovery":false,"disableDefaultResponse":false,"direction":0,"srcEndpoint":null,"reservedBits":0,"manufacturerCode":null,"transactionSequenceNumber":null,"writeUndiv":false}) failed (SREQ '--> ZDO - extRouteDisc - {"dstAddr":3077,"options":0,"radius":30}' failed with status '(0xc7: NWK_TABLE_FULL)' (expected '(0x00: SUCCESS)'))' zigbee2mqtt | Zigbee2MQTT:error 2023-04-01 20:26:03: Publish 'set' 'state' to 'salon-salleamanger-inter-plafonnier' failed: 'Error: Command 0x5c0272fffe16b298/2 genOnOff.on({}, {"sendWhen":"immediate","timeout":10000,"disableResponse":false,"disableRecovery":false,"disableDefaultResponse":false,"direction":0,"srcEndpoint":null,"reservedBits":0,"manufacturerCode":null,"transactionSequenceNumber":null,"writeUndiv":false}) failed (SREQ '--> ZDO - extRouteDisc - {"dstAddr":3077,"options":0,"radius":30}' failed with status '(0xc7: NWK_TABLE_FULL)' (expected '(0x00: SUCCESS)'))' zigbee2mqtt | Zigbee2MQTT:error 2023-04-01 20:26:43: Publish 'set' 'color_temp' to 'salon-ampoule-plafond' failed: 'Error: Command 0xa4c13819c3ce7ca2/1 lightingColorCtrl.moveToColorTemp({"colortemp":350,"transtime":10}, {"sendWhen":"immediate","timeout":10000,"disableResponse":false,"disableRecovery":false,"disableDefaultResponse":false,"direction":0,"srcEndpoint":null,"reservedBits":0,"manufacturerCode":null,"transactionSequenceNumber":null,"writeUndiv":false}) failed (SREQ '--> ZDO - extRouteDisc - {"dstAddr":7587,"options":0,"radius":30}' failed with status '(0xc7: NWK_TABLE_FULL)' (expected '(0x00: SUCCESS)'))' zigbee2mqtt | Zigbee2MQTT:warn 2023-04-01 20:26:54: Failed to ping 'jardin_arrière_lampe' (attempt 1/2, Read 0x00124b0023441baa/1 genBasic(["zclVersion"], {"sendWhen":"immediate","timeout":10000,"disableResponse":false,"disableRecovery":true,"disableDefaultResponse":true,"direction":0,"srcEndpoint":null,"reservedBits":0,"manufacturerCode":null,"transactionSequenceNumber":null,"writeUndiv":false}) failed (Data request failed with error: 'MAC no ack' (233))) zigbee2mqtt | Zigbee2MQTT:warn 2023-04-01 20:27:16: Failed to ping 'jardin_arrière_lampe' (attempt 2/2, Read 0x00124b0023441baa/1 genBasic(["zclVersion"], {"sendWhen":"immediate","timeout":10000,"disableResponse":false,"disableRecovery":false,"disableDefaultResponse":true,"direction":0,"srcEndpoint":null,"reservedBits":0,"manufacturerCode":null,"transactionSequenceNumber":null,"writeUndiv":false}) failed (Data request failed with error: 'MAC no ack' (233))) zigbee2mqtt | Zigbee2MQTT:warn 2023-04-01 20:27:33: Failed to ping 'wc_haut_inter' (attempt 1/2, Read 0x60a423fffeaae633/1 genBasic(["zclVersion"], {"sendWhen":"immediate","timeout":10000,"disableResponse":false,"disableRecovery":true,"disableDefaultResponse":true,"direction":0,"srcEndpoint":null,"reservedBits":0,"manufacturerCode":null,"transactionSequenceNumber":null,"writeUndiv":false}) failed (Timeout - 62666 - 1 - 8 - 0 - 1 after 10000ms)) zigbee2mqtt | Zigbee2MQTT:warn 2023-04-01 20:27:46: Failed to ping 'wc_haut_inter' (attempt 2/2, Read 0x60a423fffeaae633/1 genBasic(["zclVersion"], {"sendWhen":"immediate","timeout":10000,"disableResponse":false,"disableRecovery":false,"disableDefaultResponse":true,"direction":0,"srcEndpoint":null,"reservedBits":0,"manufacturerCode":null,"transactionSequenceNumber":null,"writeUndiv":false}) failed (SREQ '--> ZDO - extRouteDisc - {"dstAddr":62666,"options":0,"radius":30}' failed with status '(0xc7: NWK_TABLE_FULL)' (expected '(0x00: SUCCESS)'))) zigbee2mqtt | Zigbee2MQTT:error 2023-04-01 20:32:03: Publish 'set' 'state' to 'salon-salleamanger-inter-plafonnier' failed: 'Error: Command 0x5c0272fffe16b298/2 genOnOff.on({}, {"sendWhen":"immediate","timeout":10000,"disableResponse":false,"disableRecovery":false,"disableDefaultResponse":false,"direction":0,"srcEndpoint":null,"reservedBits":0,"manufacturerCode":null,"transactionSequenceNumber":null,"writeUndiv":false}) failed (SREQ '--> ZDO - extRouteDisc - {"dstAddr":3077,"options":0,"radius":30}' failed with status '(0xc7: NWK_TABLE_FULL)' (expected '(0x00: SUCCESS)'))' zigbee2mqtt | Zigbee2MQTT:warn 2023-04-01 20:33:11: Failed to ping 'sdb_bas_inter' (attempt 1/2, Read 0x60a423fffeaaf15a/1 genBasic(["zclVersion"], {"sendWhen":"immediate","timeout":10000,"disableResponse":false,"disableRecovery":true,"disableDefaultResponse":true,"direction":0,"srcEndpoint":null,"reservedBits":0,"manufacturerCode":null,"transactionSequenceNumber":null,"writeUndiv":false}) failed (Data request failed with error: 'No network route' (205))) zigbee2mqtt | Zigbee2MQTT:warn 2023-04-01 20:33:38: Failed to ping 'sdb_bas_inter' (attempt 2/2, Read 0x60a423fffeaaf15a/1 genBasic(["zclVersion"], {"sendWhen":"immediate","timeout":10000,"disableResponse":false,"disableRecovery":false,"disableDefaultResponse":true,"direction":0,"srcEndpoint":null,"reservedBits":0,"manufacturerCode":null,"transactionSequenceNumber":null,"writeUndiv":false}) failed (Data request failed with error: 'No network route' (205))) zigbee2mqtt | Zigbee2MQTT:warn 2023-04-01 20:35:04: Failed to ping 'parents_inter_plafonniers' (attempt 1/2, Read 0x60a423fffee2a71b/1 genBasic(["zclVersion"], {"sendWhen":"immediate","timeout":10000,"disableResponse":false,"disableRecovery":true,"disableDefaultResponse":true,"direction":0,"srcEndpoint":null,"reservedBits":0,"manufacturerCode":null,"transactionSequenceNumber":null,"writeUndiv":false}) failed (Data request failed with error: 'No network route' (205))) zigbee2mqtt | Zigbee2MQTT:warn 2023-04-01 20:35:35: Failed to ping 'parents_inter_plafonniers' (attempt 2/2, Read 0x60a423fffee2a71b/1 genBasic(["zclVersion"], {"sendWhen":"immediate","timeout":10000,"disableResponse":false,"disableRecovery":false,"disableDefaultResponse":true,"direction":0,"srcEndpoint":null,"reservedBits":0,"manufacturerCode":null,"transactionSequenceNumber":null,"writeUndiv":false}) failed (Data request failed with error: 'No network route' (205)))
``
Been running for a few hours now, no offline/dropped devices yet, however it does feel slow to react at times. This seems to usually co-inside after all my lights reported there color change for my adaptive lighting group. It seems to recover a bit afterwards, not a big issues though.
Total: 92
Router: 50
End devices: 42
Been running for a few hours now, no offline/dropped devices yet, however it does feel slow to react at times. This seems to usually co-inside after all my lights reported there color change for my adaptive lighting group. It seems to recover a bit afterwards, not a big issues though.
Total: 92 Router: 50 End devices: 42
I got the same feeling that issues appear when traffic is high.
I got the same feeling that issues appear when traffic is high.
In this case there are 27 lights in the group that post a colorTemperature attributeReport. I guess some memory table will be full of those device entries that slowly age out making things faster again until the next report batch.
I'm guessing if a lot of end devices send an update at the same time it will be a similar effect, It's not really an issue (yet) just noticable if you are paying attention to any funkyness/change.
Little update. Situation is better but not perfect : 2 routers offline. One of them get back onine clicking on reconfigure. The other not. Some end device (online) which don"t send information (presence detector). (but some are ok). @Koenkk could you do a little more magic ? :)
for me nothing changed with this FW Update - all my Devices staying online & reliable, anything is nice such as FW 20221226 was
Coordinator CC2652RB (slaesh)
@guillaume042 let's wait for some feedback from more people first.
Sonoff Zigbee 3.0 Plus I had two eWeLink MS01 motions sensors stop sending events. Restart HA or reboot Yellow did not re-activate the motion sensors. Reinstalled 20220219 and one of them came back. The last one required reset and re-add to get it working.
@guillaume042 let's wait for some feedback from more people first.
No problem. I still experiment NWK full, router disconnection and end device 'muted' but it is better than previously. Waiting for next step and i can give you whatever log you need.
I am getting a lot of NWK_TABLE_FULL listings in my logs, 154 today. I never really looked into it before this firmware update but they are there. I am also still getting a lot of the coordinator disconnects, 2,601.
2023-04-03 13:23:43.727 DEBUG (MainThread) [zigpy_znp.api] Received command: ZDO.ExtRouteDisc.Rsp(Status=<Status.NWK_TABLE_FULL: 199>)
2023-04-03 03:20:28.332 WARNING (MainThread) [homeassistant.components.zha.core.channels.base] [0x9B47:1:0x0702]: async_initialize: all attempts have failed: [DeliveryError('Coordinator is disconnected, cannot send request'), DeliveryError('Coordinator is disconnected, cannot send request'), DeliveryError('Coordinator is disconnected, cannot send request'), DeliveryError('Coordinator is disconnected, cannot send request')]
Let me know if I can help provide anymore. I use ZHA on Home Assistant and have a fair amount of devices.
I tried flashing with the Flash Programmer 2 ver 1.8.0 and im getting the following errors and nothing flashes,
Overlapping flash area in page: 0, offset address 0x0000 Reset target ... Reset of target successful.
not sure why this is happening :-(
not sure why this is happening :-(
I think firmware file is bigger than flash - for me it is impossible to flash CC2652P (Egony v4) with CC1352P2_CC2652P_other_coordinator_20230401.hex
@guillaume042 let's wait for some feedback from more people first.
No problem. I still experiment NWK full, router disconnection and end device 'muted' but it is better than previously. Waiting for next step and i can give you whatever log you need.
i don"t know if it is revelant, but it is not always the same 2/3 routers offline. Sometimes one get back while another one get off. Same for end device it is not always the same 5/6 which stop sending infos.
I think firmware file is bigger than flash - for me it is impossible to flash CC2652P (Egony v4) with
CC1352P2_CC2652P_other_coordinator_20230401.hex
Ahh right, yeah this new FW is about 100kb bigger than the 20221226 hex file. Aww man :-( so does this mean we can never get anything newer than coordinator FW 20221226?
Im using the zzh (CC2652R Stick), whats the best zigbee stick to use then going forward?
Im going to try and flash with cc2538-bsl.py and see if that makes any difference.
@Venom84 It doesn't matter how would you flash - file can't be bigger than flash size (and even with exception for protected areas it could not be so big). There are some TI chipsets with bigger flash size - eg. CC1352P7 (but I haven't seen any Zigbee dongle based on this chipset).
CC2652R, CC2652P, CC1352P2 have 352kB available for user program.
BTW date of publication 20230401 looks like April Fools' Day
@Koenkk for me (CC2652P Egony v4) 20230405 firmware flash still impossible file size is 493 KB (505 284 bytes) exactly equal as 20230401 version comparing to latest stable (and working) it is really bigger
last stable 20221226 has 400 KB (409 630 B), 20221220 (working for me old dev) the same size older stable 20220219 has 388 KB (397 940B)
TI Flash Programmer log (I've renamed hex file, as all my archival hex files are in the same folder)
>Initiate access to target: COM4 using 2-pin cJTAG.
>Reading file: D:/zigbee/egony_v4_ebyte_koenkk/CC1352P2_CC2652P_other_coordinator_20230405alfa2.hex.
>Unknown record type: 3.
>Reset target ...
>Reset of target successful.
BTW Log from successful flashing 20221226 looks like in reality there is plenty of free space in flash (I've checked Verify by readback), so maybe file format isn't so simple I thought.
>Reading file: D:/zigbee/egony_v4_ebyte_koenkk/CC1352P2_CC2652P_other_coordinator_20221226.hex.
>Start flash erase ...
>Erase finished successfully.
>Start flash programming ...
>Programming finished successfully.
>Start flash verify ...
>Page: 0 verified OK.
>Page: 1 verified OK.
>Page: 2 verified OK.
>Page: 3 verified OK.
>Page: 4 verified OK.
>Page: 5 verified OK.
>Page: 6 verified OK.
>Page: 7 verified OK.
>Page: 8 verified OK.
>Page: 9 verified OK.
>Page: 10 verified OK.
>Page: 11 verified OK.
>Page: 12 verified OK.
>Page: 13 verified OK.
>Page: 14 verified OK.
>Page: 15 verified OK.
>Page: 16 verified OK.
>Page: 17 verified OK.
>Page: 18 verified OK.
>Page: 19 verified OK.
>Page: 20 verified OK.
>Page: 21 verified OK.
>Skip verification of unassigned page: 22.
>Skip verification of unassigned page: 23.
>Skip verification of unassigned page: 24.
>Skip verification of unassigned page: 25.
>Skip verification of unassigned page: 26.
>Skip verification of unassigned page: 27.
>Skip verification of unassigned page: 28.
>Skip verification of unassigned page: 29.
>Skip verification of unassigned page: 30.
>Skip verification of unassigned page: 31.
>Skip verification of unassigned page: 32.
>Skip verification of unassigned page: 33.
>Skip verification of unassigned page: 34.
>Skip verification of unassigned page: 35.
>Skip verification of unassigned page: 36.
>Skip verification of unassigned page: 37.
>Skip verification of unassigned page: 38.
>Skip verification of unassigned page: 39.
>Skip verification of unassigned page: 40.
>Skip verification of unassigned page: 41.
>Skip verification of unassigned page: 42.
>Page: 43 verified OK.
>Verification finished successfully.
>Reset target ...
>Reset of target successful.
@Venom84 can you check if
20230405
fixes this?
Thanks @Koenkk ill give this a go using Flash Programmer 2 when i get home today but if it doesnt work ill just use cc2538-bsl.py. I had some issues getting the cc2538-bsl.py python script to work but my brother was able to flash 20230401 firmware using cc2538-bsl.py and he had no issues at all.
I guess going forward we should rather be using cc2538-bsl.py to flash firmware as it seems to have less/no issues compared to the Flash Programmer 2.
I'm having issues with pretty much all of my light switches after flashing, https://www.zigbee2mqtt.io/devices/41E2PBSWMZ_356PB2MBTZ.html and https://www.zigbee2mqtt.io/devices/41EPBDWCLMZ_354PBDMBTZ.html. It retrieves state change info if I manually toggle them but I cannot change the state.
It is really weird, that official TI tool does not work.
On windows laptop I do not have Python environment needed to run script, BUT I can confirm success in flashing using alternate tool https://github.com/xyzroe/ZigStarGW-MT/releases/tag/v0.3.5
It is really weird, that official TI tool does not work.
Yeah TI really need to update their tool but at least we can test this new FW for Koenkk now :-)
@Venom84 can you check if
20230405
fixes this?
@Koenkk Flashed my coordinator with 20230405 using cc2538-bsl.py with no issues at all. All my devices came back and so far so good. I will monitor for any "NWK_TABLE_FULL" and report back but looking good so far!
@Venom84 does 20230401 also work? If yes, use that instead of 20230405.
@Koenkk Yes 20230401 works so i have now re-flashed my coordinator to this version. All looking good so far, all devices connected without any issues. I will monitor for any "NWK_TABLE_FULL" or other issues and report back.
It looks like the Flash Programmer 2 from TI doesnt work anymore so i would suggest that anyone reading this to rather use the "cc2538-bsl.py" or another method of flashing :-)
20230410
is available now. Big thanks to @slugzero for most of the improvements.
Change log compared to 20230401
:
- Enable child aging to fix issues like #13478 (but not for older Xiaomi devices as they do not implement child aging correctly which gets them kicked out of the network)
- Increase message timeout from 7 to 8 seconds to increase message delivery success rate for devices using a 7.5 seconds poll interval (#13478)
- Increase
stack_size
from1024
to4048
in an attempt to improve stability with larger networks
Upgrade from CC2652R_coordinator_20230401.hex to CC2652R_coordinator_20230410.hex without issues.
End devices: 28 Router: 9
zzh stick
Uptime (only) 30 minutes, network is "just fine".
I do have a few of these RTCGQ11LM aka "old Xiaomi" - I'll find out soon if they drop off.
Hello Still got NWK tables full errors. ([20230410]) End devices: 42 Router: 33 I also observe battery end device online but no informations updated (Xiaomi and Sonoff presence sensor).
Installed 20230410 yesterday afternoon. It was running stable until this morning, causing z2m addon reboots and the interval of those is increasing by the hour. Any data needed ?
@lvanjaarsveld what was the latest known working fw version?
20230401 and 20230410 have both been pretty good, slowness i was seeing on 01 seems fixed on 10
@lvanjaarsveld what was the latest known working fw version?
20220219, from there I switched to the current release ... due to addon stability issues I ran into this test request hoping to resolve both addon stability and the nwk full issue.
On a SONOFF 3.0 stick, I am seeing a lot of coordinator disconnects with the stick being unavailable on CC1352P2_CC2652P_launchpad_coordinator_20230410.hex. Running ZHA on 2023.3.4. I have ~166 devices.
I have to restart the coordinator (i.e. unplug) and reload ZHA to get it back.
I only have 1 NWK_TABLE_FULL in my logs for this firmware (20230410) and am down to about 154 disconnects. This seems to be getting better. The network does appear to be more laggy though when turning lights on and off. I have 158 devices.
John Miles Lento Jr. | - gpg public key: https://lento.io/08EB5F22.txt | - Sent via RFC 1149...
From: Peter @.> Sent: Tuesday, April 11, 2023 9:34 PM To: @.> Cc: @.>; @.> Subject: Re: [Koenkk/Z-Stack-firmware] Z-Stack_3.x.0 coordinator 20230410 feedback (Issue #439)
On a SONOFF 3.0 stick, I am seeing a lot of coordinator disconnects with the stick being unavailable on CC1352P2_CC2652P_launchpad_coordinator_20230410.hex. Running ZHA on 2023.3.4. I have ~166 devices.
— Reply to this email directly, view it on GitHubhttps://github.com/Koenkk/Z-Stack-firmware/issues/439#issuecomment-1504396257, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AGHSRT5VJQNPMY7VIYEMMLLXAYBBHANCNFSM6AAAAAAWPPN23Q. You are receiving this because you commented.Message ID: @.***>
After about four hours, it seems the Zigbee coordinator is stable and I have not had to plug/unplug it after updating the firmware. But I notice commands are still slow on some lights and switches about 16 hours later.
Edit: Over 3 switches: difficulty pairing Inovelli VZM31-SN switches, it is taking >5 attempts to pair them.
With 20230410 the coordinator crashed randomly (wasn't powering off any devices), no USB disconnect and I had to unplug/restart the machine for the coordinator to come back. ZHA was not able to reconnect.
Edit:
2023-04-12 17:32:08.988 DEBUG (MainThread) [zigpy_znp.api] Received command: ZDO.ExtRouteDisc.Rsp(Status=<Status.NWK_TABLE_FULL: 199>)
2023-04-12 17:32:09.905 DEBUG (MainThread) [zigpy_znp.api] Received command: ZDO.ExtRouteDisc.Rsp(Status=<Status.NWK_TABLE_FULL: 199>)
2023-04-12 18:28:08.812 DEBUG (MainThread) [zigpy_znp.api] Received command: ZDO.ExtRouteDisc.Rsp(Status=<Status.NWK_TABLE_FULL: 199>)
2023-04-12 18:46:51.507 DEBUG (MainThread) [zigpy_znp.api] Received command: ZDO.ExtRouteDisc.Rsp(Status=<Status.NWK_TABLE_FULL: 199>)
2023-04-12 19:29:10.768 DEBUG (MainThread) [zigpy_znp.api] Received command: ZDO.ExtRouteDisc.Rsp(Status=<Status.NWK_TABLE_FULL: 199>)
2023-04-12 19:53:52.168 DEBUG (MainThread) [zigpy_znp.api] Received command: ZDO.ExtRouteDisc.Rsp(Status=<Status.NWK_TABLE_FULL: 199>)
2023-04-12 20:15:28.449 DEBUG (MainThread) [zigpy_znp.api] Received command: ZDO.ExtRouteDisc.Rsp(Status=<Status.NWK_TABLE_FULL: 199>)
2023-04-12 20:21:09.291 DEBUG (MainThread) [zigpy_znp.api] Received command: ZDO.ExtRouteDisc.Rsp(Status=<Status.NWK_TABLE_FULL: 199>)
2023-04-12 20:21:15.732 DEBUG (MainThread) [zigpy_znp.api] Received command: ZDO.ExtRouteDisc.Rsp(Status=<Status.NWK_TABLE_FULL: 199>)
2023-04-12 20:25:30.603 DEBUG (MainThread) [zigpy_znp.api] Received command: ZDO.ExtRouteDisc.Rsp(Status=<Status.NWK_TABLE_FULL: 199>)
2023-04-12 20:34:26.806 DEBUG (MainThread) [zigpy_znp.api] Received command: ZDO.ExtRouteDisc.Rsp(Status=<Status.NWK_TABLE_FULL: 199>)
2023-04-12 21:40:00.288 DEBUG (MainThread) [zigpy_znp.api] Received command: ZDO.ExtRouteDisc.Rsp(Status=<Status.NWK_TABLE_FULL: 199>)
2023-04-12 21:40:06.523 DEBUG (MainThread) [zigpy_znp.api] Received command: ZDO.ExtRouteDisc.Rsp(Status=<Status.NWK_TABLE_FULL: 199>)
2023-04-12 21:40:43.262 DEBUG (MainThread) [zigpy_znp.api] Received command: ZDO.ExtRouteDisc.Rsp(Status=<Status.NWK_TABLE_FULL: 199>)
2023-04-12 21:41:58.190 DEBUG (MainThread) [zigpy_znp.api] Received command: ZDO.ExtRouteDisc.Rsp(Status=<Status.NWK_TABLE_FULL: 199>)
Downgraded to 20221102 and the network immediately came back up. When on 20230410 it took ~2 hours for the network to be 'responsive', and that was after power cycling the USB coordinator stick multiple times.
20230410 have been solid on my 3 networks for 2 days now. Was running 20221226 before that with no issues either.
Just installed 20230410 over 20230401 and all went well. All network devices came back on their own within about 5min. So far so good. Ill monitor closely and update if i see any issues :-)
Have had four devices "leave the network" over the last 5 days. Just rolled back to 20221226 to see if it stops. Running 1.30.3 stable. I have a persistent notification rule that leaves me a message when one leaves and one joins. Two devices also left and came back, but those other four I had to repair them.
Centralite, Iris and Keen Home are the manufacturers, so its not limited to one device model.
So I’ve been trying to update my inovelli blue switches with the latest firmware and I get a watchdog check failed and a coordinator disconnect which kills the update. I reboot my HA and unplug the dongle and back in and can usually get one to upgrade before a watch dog check hits be again and a disconnect. Not sure why but the disconnects are killing me.
@johnlento I also cannot update my Inovelli VZM31-SN (Blue) using 20230410. After downgrading to 20221226 it was successful with 9 switches upgraded in under an hour. With 20230410 it tried for hours and failed.
@pfak good tip. I reverted and now things are working again.
Have had four devices "leave the network" over the last 5 days. Just rolled back to 20221226 to see if it stops. Running 1.30.3 stable. I have a persistent notification rule that leaves me a message when one leaves and one joins. Two devices also left and came back, but those other four I had to repair them.
Centralite, Iris and Keen Home are the manufacturers, so its not limited to one device model.
@tsspmq thank you for the feedback. I suspect that all three of them are "white label" Xiaomi devices from different vendors. The product range (temperature & humidity, water leak, contact sensors, motion sensor) and their respective Exposes are exactly the same. The Keen Home RS-THP-MP even comes in the same housing.
Which devices exactly are you using? And could you provide the IEEE addresses of the affected devices (at least the first 6 digits, one address from each vendor)? Thanks!
Edit: Oh, and could you please also post the "Firmware Version" and "Firmware Date" values from the respective device's overview page?
Please provide your feedback to the Z-Stack_3.x.0 coordinator 20230507 firmware here.
I hope this solves the
NWK_TABLE_FULL
many people were experiencing.Changelog
Download
20230401
~20230410
~20230507