I believe there is an issue with Z-stack 20240710 FW #518
Comments
|
Please post the debug log from starting z2m until this error. See this on how to enable debug logging. |
|
I need to do some work as they will total more than 100Mb in size. Hopefully in a few hrs from now will submit. |
|
Unfortunately I cannot post debug info yet as I downgraded FW last night and only had the log at info level. Today I will upgrade again to 20240716 and will update once I have the first failure. |
|
I have updated my Sonoff USB Dongle with 20240710 FW, ZigBee2MQTT and Home Assistant, need to reboot everyd ay because of loose all devices. Version de Zigbee2MQTT I change config to debug log I send beforce next reboot |
|
i'm having issues as well, CC2652RB with 20240710 FW, with ZigBee2MQTT and HomeAssistant. my devices were working smooth for almost 2 years until i updated. i flashed 20221226 back and will continue monitoring but so far so good. EDIT: woke up with the zigbee network down again, at this point i regret updating so bad |
|
I have done some deeper digging. For some reason the SLZB-06P7 coordinator decided not to join the network following power off and replaced it with a UZG-01 flashed with 20240710. Trying different coordinator FW versions I have observed routing is wildly different. Earlier versions to 20240710 do not cluster well around routers. 20240710 seems to elect the key routers properly, and all routers seem to connect to the coordinator as expected. Images with the map and the errors are provided below. All of the routers even if they are really close (<5m no obstacles) to the coordinator seem to have low LQI (<99); if I re-pair they seem they go triple digit LQI, but eventually they settle on low double digit LQI, and therefore concluded re-pairing is not useful.
Although the battery powered devices are not connected they all seem to work flawlessly. Possibly some improvements required to get the map right. It seems to take a couple of hours for connection routing to settle.
It takes close to 20 mins for the above map to be generated. One last thought. It would be a great addition if we have an option to clear all error messages displayed. Sometimes it takes more than 2 mins to manually clear error messages, which obscure action buttons. |
|
Good news is the map does eventually generate an accurate connection layout. The following map is after 2 days of operation. Additionally it now takes less than 4 mins to produce the map using 20240710 UZG-01 combo.
|
|
After of almost 2 days of operation Z2M lost connection to UZG, but automatically recovered. I timed map generation to just 2.5 mins.
This zip file has all the debug logs. Logs dated 2024-09-05 were created using SLZB-06P7. Logs dated 2024-09-06 were created using UZG-01/20240710. The logs also include the instance where connection to UZG was reset by something. |
|
I see a (0xc7: NWK_TABLE_FULL) error in the debug logs, if this is of any assistance. |
|
20240315 allowed more devices to connect to the coordinator, 20240710 less and thus relies more on routers to improve stability of the coordinator. If those routers are crap, you will get very poor performance. I would suggest to first power of some spammy devices, e.g. |
I have already done this twice, powered off the entire section of 00901, waited a few mins and power on the entire section again. I will try once more and provide feedback. |
|
Do/Can we have any tools which allows us to influence affinity to certain routers. For SLZB which router FW version works better with coordinator FW 20240710. I was thinking of a tool which allows us to group routers and let the system automatically balance between them, therefore being able to avoid certain routers during pairing. |
|
I have a question for Koenkk. The below device will re-interview successfully with no errors or warnings. How come it still shows offline with a 2 week last seen status.
|
|
I suggest an option to set the line colours in the map. The dark blue on the dark theme is difficult to visualise on a busy map.
|
|
I am wondering if it is possible to save the map in a nice format. |
|
I have 20240710 working for some weeks now. Thanks for the good jobs ! |
|
Oops, I forgot to better explained what I did. |
|
I confirm there is an issue with FW20240710. The coordinator resets sometimes after 20 mins, sometimes after hours, but it resets nevertheless. I will keep FW20240710 to assist in troubleshooting and because, since v1.40.0, Z2M automatically reconnects. My experience is that I completely lose Ethernet connectivity and I know it is not a network issue as there are hundreds of devices on the network (Ethernet and WiFi) with no issues. Please let me know how I can assist debug this issue.
Log file attached. The crash debug is at the top of the log. |
|
This info might be useful to some. I have lots of Tuya QS relay devices which in theory can act as routers. When the UZG-01 was directly connected to some of them I had constant communication errors, although everything seemed to work with no issues, but with delays, sometimes considerable. Once I paired a SLZB-06P7 router to the UZG-01 coordinator most of the communication issues between QS routers and coordinator vanished. I get the occasional error now, but the errors are not show stoppers. The SLZB-06P7 router (00902-Router) is configured as follows:
Since I introduced the SLZB-06P7 router everything seems to have smoothed out. However, because I have issues with the UZG-01 (the coordinator) restarting at random intervals, I will upgrade to the latest SLZB-06P7 router FW and give an update if the UZG-01 issues have been eliminated or some other gremlins were introduced.
|
|
For those interested to know the SLZB-06P7 router FW differences here they are:
|
|
Zigbee2mqtt has the latest update: 1.40.1-1 Again last night total adapter crash... (Adapter Web GUI is working, and Zigbee reset does not help). After PoE reset, and I let it for 1 hour to stabilize, network was a mess.. Ikea bulbs were reporting no network route. had to reset all router devices with appartment elec. braker. Yesterday befor the crash I noticed that everything is very laggy. And it is like this every 1-2 weeks from the day this firmvare version is released. Already rejoined all devices. Are there any ongoing actions about this as reports like this were posted from first day it was released as beta? |
|
So I updated SLZG-06P7 router FW to 20240716 from 20240315. The device goes offline. To get it back online follow this:
Will update once I am confident of any positive/negative/neutral changes to the Zigbee network.
|
|
@Koenkk my logs are posted here: Koenkk/zigbee2mqtt#23869 (comment) |
|
Running Zigbee2MQTT Edge Where to start? I updated a week or so ago. The update went well. I noticed Aqara devices dropped off a day later. Repaired. No issue. I then started seeing a few devices drop off. I then started to get complete network crashes. Fast forward to now and my network is struggling to stay up. Update I tried to find any device with these numbers and I get nothing Update |
That is the weirdest thing here.. rolling back is not fixing problems.. its like updated coordinator pushed somethint to router devices and network is not stable with older firwares any more... |
|
having the same thoughts as @cloudbr34k84 and @dankocrnkovic. |
i seem to have stabilised for now, but I flashed the last 3 firmware on the device retarded the device each time, then I flashed the latest and it seems to be stable again. i have 2 devices offline but that's because they are bulbs which my wife switch the lamps off manually |
Give it time. I thought that also, but then in 5-10 days router devices start to die again, bring the network down. I will never again update firmware once (and if) its stable again with some fix. |
Have programmed it, will see the behaviour in the coming days and probably a couple of weeks. 
|
|
@Koenkk Edit:
Is this a typo? Do you mean CC2652P7 ? |
|
@raveit65 its not a typo, the firmware works on both cc2652p7 and cc1352p7 |
|
@Koenkk
|
|
I don't have experience with this interface, but you need to flash the zigbee firmware not the ESP32 one. |
|
Np, i was able to use a windows box and using zigstar tool.
Let see how it works. I use the the uzg-01 only for one room with 20 devices. I will post here again in some weeks. |
|
After 5 days the system crashed (Z2M restarted and reconnected to UZG-01 with no issues automatically). Unfortunately I forgot to enable debug log. So next time it crashes will update with debug log. I wonder if this is because https://www.zigbee2mqtt.io/devices/TS0502B.html#tuya-ts0502b is reporting frequently (see below). Will add the same device on my SLZB test networks to see it this device indeed creates issues.
|
|
Here the uzg-01 with testing firmware stops at night and watchdog stops restarting it after a while. The adapter was 6 hours offline until i restarted the device in the morning. Sadly i forgot to enable debug too :-/ But maybe it was a LAN issue because device is connected via ethernet-->powerline -->ethernet. Well, i enabled debug now. |
|
After almost a week of usage, in my situation the testing fw is much more stable than the 20240710, I think it is the same or better than the 20230507 fw on CC2652R. Additional info: I am running a network of 89 devices, where 37 of them are battery powered end devices. |
|
@t-liu93 could you see if it is better/worse/same with |
Flashed, will try for a couple of days. 
|
|
After about a week (no changes were made) the Z2M disconnected from UZG, however it automatically restarted. The strange thing is that following the error nothing was logged until about 5 hours later. See log below (note the debug entries repeat twice every second (a one minute debug in the log has approx. 500 debug lines). [2025-02-22 02:30:27] info: z2m:mqtt: MQTT publish: topic 'uzg01/uzg01-sd0', payload '{"brightness":25,"color_mode":"color_temp","color_temp":500,"do_not_disturb":true,"effect":null,"last_seen":"2025-02-22T02:30:27+04:00","linkquality":91,"state":"OFF"}' next log was at [2025-02-22 07:39:57]: (I think this is the time I checked the UZG and Z2M in the browser - however I am not 100% certain so will check next time it crashes) [2025-02-22 07:39:57] debug: zh:zstack:unpi:parser: <-- [254,30,68,129,0,0,0,3,87,172,1,1,0,91,0,36,169,178,0,0,10,8,204,10,10,240,72,3,0,3,0,87,172,29,215]
|
This means z2m could not connect to the socket of your adapter, I don't think this is related to the coordinator firmware. Likely the ESP32 side of your adapter crashed or your network dropped. This cannot be solved from Z2M (see similar issues with SLZB adapters here: Koenkk/zigbee2mqtt#24154 (comment)) |
|
Yes I gathered that. Most likely ESP32 crash as network solid if logs are to be believed. Have updated ESP FW to 20241001 from 20240914 and will update when some drama takes place, or hopefully no drama. |
@Koenkk After almost a week of usage I feel it is similar/slightly better than the 99240915 fw. I have observed the following:
|
|
@t-liu93, did you also tried to reboot your coordinator 2 or 3 times? |
|
On Friday devices like switches and lights and automation's in uzg-01 network with 99240915 do not proper react anymore. For me this is the same issue which i did observed in the last half year. First i thought the firmware works better but after a while the network becomes more slowly.
Good tip, it seems the solution mentioned in this topic fixes socket errors with slzb-06 adapter. |
|
@t-liu93 could you try this one now? |
Have flashed, will observe the behavior. |
When I was using 20230507, I rebooted a few times. I didn't experience the situation to be honest. For 99250217, I only rebooted once after flashing. |
|
@Koenkk |
|
@raveit65 did you already try https://github.com/user-attachments/files/18726142/CC1352P7_coordinator_99240915.hex.zip ? This is the settings of 20221226 with a newer SDK. |
|
Yes, firmware is CC1352P7_coordinator_99240915.hex downloaded from https://github.com/user-attachments/files/18726142/CC1352P7_coordinator_99240915.hex.zip It happens again this evening. Whole devices like switches, motion detectors and bulbs do no longer respond. In logs i found lot of errors like this. (example is from a Ledvance bulb) Full logs from today are here: I am sure the firmware doesn't work with my uzg-01. But maybe the device itself has a hardware error now. |
Hi @Koenkk I have used this version for a week now, it works seamlessly. |
|
@raveit65 can you try CC1352P7_coordinator_99250223.hex.zip |
|
With origin fw 20230507 i observed same problems after 3 days for uzg-01with CC1352P7 chip. I decided to replace the adapter with another slbz-06. Some people mentioned same weird behavior with origin fw after testing 20240710 like i did. |
|
All devices went offline after about a week using 99240915 and 20241001 (in the past when using 20240914 the adapter would crash, now with 20241001 devices went offline; this might be a coincidence or an indication of something else that requires attention). The pattern is that the system will experience an issue within about a week. I have attached the state of the system prior to manual Z2M reboot, which fixed the problem. I think within a week the same issue will rear its head. Will keep you posted, unless something else can be tested instead.
|
|
Uzg-01 is running with CC1352P7_coordinator_99250223.hex, zdm-2.1.3-1and 20 devices (bulbs, plugs, scene switches and motion detectors). I will report how it works. |
and others
Flashed SLZB-06P7 with 20240710 FW a couple of weeks ago. Since the new FW was applied the device randomly stops receiving updates from devices, while Zigbee2MQTT reports no issues except communication errors.
Restarting ESP32 or Zigbee (the last time I restarted Zigbee, was not enough, I had to restart ESP32 for the device to start responding; it could have been I did not give enough time for the devices to start reporting - gave it a couple of minutes which was my prior experience with the failure) the SLZB-06P7 starts processing packets again.
Time between failures, one took 2 days, and another 6 days. The last 2 weeks the device failed with the same issue 3 times.
Initially I thought it was an isolated incident, but now I am more confident is a FW issue.
Are these type of issues related to TI chipsets only?
The text was updated successfully, but these errors were encountered: