Hi there, I share the same problem. I connected a Tuya WiFi plug to the power supply so I can reset the SLZB from where ever I am.
I am on the latest firmware. What I see in the logs of my router is that de connection is lost and restored several times a day. The problems with the zigbee network seem to occur after one of such resets.
Why the connection is lost, I don’t know. I switched ports, cables, etc. Any ideas? I did set a fixed IP address for the SLZB to be sure HA can find it.
Same problems on SLZB-MR1 and SLZB-MR1U. This probems I have more, than year 
As someone wrote, sometimes only power unpug help. I have some Tuya devices too (1 phase and 3 phase power meter). But, I mean, tnat this must be solved in SLZB adapters, it is something like “overload”, “overflow”), or so. I can accept, that sometimes will be ignored some device data, but not, that whole network fall because of one device.
Been having the same issue for about 2,3 weeks . At first I thought the issue was the switches , I changed them . But the same problem with socket keep happening every 2-3 days .
I don’t have tuya clamps or anything that’s spamming the network .
Really don’t know what to do , not sure if I should enable ADVANCED: Socket connection options.
The problem is solved if I reboot the slzb 06 , sometimes I have to reboot the entire homeassitant VM.
Any solution so far ?
What Channel do you use?
Any interference with wifi?
So, here is, what I receive from Smlight support:
This is usually caused by excessive traffic on the zigbee network, this causes the zigbee chip to freeze after a while, then it either freezes or reboots (for reboot case it rejects requests because it is not initialized).
Usually it is not a problem of the number of devices, even one device that generates a lot of traffic all the time is enough to it, more traffic the faster it will happen.
Currently there is only one known way to fix this - remove the problematic devices from the network.
How to find them? For Z2M, you can try checking the network map, such a device will constantly "pulse", showing that it is constantly sending messages.
You can also check the Z2M log for the device that is most often found there (several times per second)
Then:
This problem cannot be solved from our side because it is a problem in the Texas Instruments SDK and is present on all Zigbee chips of this company.
Then I start using EFR32MG21 instead of CC2652P7 and probem is solved.
Guess support need to update their info.
To find if you have spammy devices:
Go to Settings > Health inside the Z2M interface and sort by “Messages per sec”. Anything below 1 should be fine, though I’d keep an eye out if any device shows values greater than 0.5 on my network.
I found the problem in my network! I use Omada, and because I have multiple VLANs, Omada automatically defines all switchports to Trunk, instead of Access. SLZB most probably gets confused by all the VLAN information.
Unfortunately I already switched to the new Home Assistant Connect ZBT-2, and repair-ed all my devices. So I have to find a spare time to try and connect the SLZB again. It must be easy because you can set de EEsomewhat code in de SLZB.
I hope this helps for some of you! Check if the switchport is not set on Trunk but on Access.
I have some update from smlight support:
There is a known problem with radio modules from Texas Instruments, its radio modules freeze at high load, usually the more load the sooner it will happen. This can happen both in an hour and in a week, depending on the amount of traffic.
This problem is present on absolutely all CC radio modules, which is why you can find so many messages about it. By the way, you can also find messages about the same problems with sonoff zbdongle-p, which only confirms that these radio modules have problems.
Most likely, the problem is software, but since this is a problem of the closed SDK of Texas Instruments, we can only wait for it to be solved by the manufacturer of the radio module.
There are two known solutions:
Posting this here because this thread comes up first in my Google searches on similar issues I have been having.
In the SLZB-06 configuration under ‘security’, try enabling the option ‘disable web server when socket connected’.
For details see my explanation in the following thread: