@manup / @de_employees please respond.
Is this still the case with current version v2.27.6 / v2.28.0-beta?
We had some devices fixed which showed more traffic / CPU usage due heavy polling.
I don’t notice delays for controlling lights in my setups after (re)starting deCONZ. But if other devices are heavily polled this could be an indicator why controlling messages take longer. If this is still the case with current versions we need to figure out which devices are affected and adjust the DDFs of them.
So probably a test setup would help if it’s possible for you.
Where you make a clean new network and joining devices each after another and testing after every few integrated devices.
Or the other way round, remove some devices and see if it helps.
You can make a backup from your current network to switch back fastly to your old network.
In our company we have most of the devices that you listed. Aqara, Hue, IKEA and Tuya.
I’m not aware of any problems as you experience from my colleagues.
So perhaps I would first try to remove the smart relays and then try the Tuya devices.
I finally gave it another try today with the hope to fix the delay problem.
I did upgrade to 2.28.1 today.
The first thing I noticed was that after the startup was finished and I rejoined all devices by using them, the cpu load was again always higher then 15% and the used RAM > 439 MB.
I also recognized the CPU load slowly kept on raising.
Also I again had from the beginning a long delay. For example simple turning on a light in the Phoscon GUI took around 5 seconds to show it in the gui and around 5-15 seconds in real life.
My experience was this will get a lot worth if I keep it running for longer.
So I deleted all relays. This did not change anything.
Next I deleted all 7x _TZE200_bjawzodf temperature, humidity sensors and restarted the docker container because I still did not see any change in the CPU load.
After the restart I had 11% CPU usage and only 150 MB RAM. The light had only a 1second delay.
Reminder: Before on deconz:2.23.02 I had a CPU-load of 1-2% in general so I kept on trying:
Next I deleted the * 8x dimmer relays HK-LN-DIM-A and did another restart.
After a restart it had around 9% CPU-load and 137 MB RAM but the most important devices are missing now.
No big delays directly after the restart.
But it seems that the CPU load is linear to the amount of devices. The more I delete the more it goes done. Anyway I need all the devices and the system is to slow when all are added with all versions after 2.23.02.
So I keep asking myself, what did change after 2.23.02 so that the same setup takes 15-20 times more perfomance of my CPU and causes these delays?
What can we do next to debug this problem?
Now I wanted to return to my old setup which did work though… 
I imported my backup again from the phoscon gui and the gui was not reachable afterwards.
So I did restart the docker container. I was able to see my old configuration and devices but could not control the lights I deleted. So I did another restart. Same problem.
I deleted the new 2.28.1 container and reloaded the former 2.23.02 docker container.
I still can’t controll my 8x dimmer relays HK-LN-DIM-A. I looks like they lost the connection to the conbee II stick. After reconnecting them I can now control them via the GUI but not with the switches.
So if I press the light in the phoscon gui it toggles on off.
If I use the light switch it toggles in the gui but not in real life.
What is different now between a activation in the gui and a switch if the gui both time shows the light state change?
Now I remember why I did want to try to change this for a long time.
Never touch a working system. I will spend my time now trying to rebuild the former version so we can user our home again.
Any ideas how to procceed folks so me and @deadmedusa will be able to update in the future?
1 Like
okay I found the difference. The Switch is calling a Scene. Scenes don’t seem to work anymore for the lights now. So it looks like I have to delete all scenes and create them all from start, also reconnecting them to the switches.
So never delete lights for test which are used in scenes…
1 Like
Thank you for doing this research in your setup.
I think something in the whole system changed so it gets kind of flooded with something that causes the whole System to be busy. Once the system starts to show taht delay its done…and not getting any better. Its a dance between bad and worse sometimes it takes 5 seconds to react and sometimes it takes 30 seconds to handle the commands.
Comparison:
Deconz Response 2.29.0
Deconz Response 2.23.02
what can we do to get this solved? I think my two comparison videos show the difference quiet well and that the delay above 2.23.02 is far far from useable.
I can do a list of devices in my network to - that way we can check if we got any devices in common
I can do more logs if needed. it would be nice to have a stable version so we can use recently released devices.
After moving half to zigbee2mqtt with my devices and not got this to work stable in the first try (i think if i had more time it could have been not that worse) i reverted everything back to deconz and started my docker again.
i had 60 devices i had to re-pair and the hole network after that process was behaving like a complete mess for almost 2 days. with lights switching randomly, lights i could not control, motionsensors not working and so on - i rebooted several times and also had to re-pair some lights multiple times to get this whole network stable again.
This is why i hate to test in my daily surroundings - on the other side it is nearly impossible for a normal user to build a testsetup because going back to af unctional network is sometimes as difficult as it is to find the failure. there is alway component X in that equation that makes reverting unpredictable
Hope you get this sorted out soon thanks again for the effort with your testing - hope we get this whole issue fixed in near future.
I spend the last 24 hours testing the 2.28.1 from scratch. I did delete all my sensors in the all version and started a fresh installation on my DS716+ with docker and 2.28.1.
I did first create all the groups, then the lights, then the switches, next the motion sensors. the CPU was less then 1% and everything was running smooth.
So I added the motion sensors and started to have troubles with a few of them which I just added and shortly afterwards the seemed were disconnected.
After I added the 7x _TZE200_bjawzodf temperature, humidity sensors first everything was fine, but after a short while the whole sensors got disconnected. (Lights and switches still there) I deleted _TZE200_bjawzodf then restarted and a few of the sensors came back after I used them.
Since this moment I started recoupling the sensors just so they get lost after a while again and the network never got stable again. The CPU though was just at 1% or so.
I’m not professional enough to say which sensor is the reason for this problem.
I just experienced the whole setup is not running at all on 2.28.1.
The 2.23.02. was running without any problems.
When I update it I have massive delays and CPU problems.
No when I have a fresh install I have the problem with dropping out devices.
I did look in the VNC Gui but this did not help me much:
Some of the sensors shown here as connected are not working.
And sensors which are here shown as not connected at all (I put them on the top-left corner in the GUI) are shown as connected in the phoscon App:
If Iook at the details though I see last updated 16 hours ago even if I used it many times…
So this is all completly messed up and I can’t debug it like this.
Speaking about Debugging here are a few minutes of my debug view during the running system:
@Mimiix @manup @ChrisHae @deadmedusa @Smanar Anyone has no quick ideas how to keep testing as my installation is messed up anyway in the moment? It took me 2 days now and I won’t be able to to this very often again.
Please help and get in contact to find a solution. Thanks a lot.
I recognized something even more weird. As my aqara door sensor wasn’t working I deleted in phoscon. then I added the sensor fresh again and it is in the moment working in phoscon and openhab.
But at the same time it looks in the GUI like disconnected:
What is going on here?
So I’m not able to see which sensors are really connected in the gui or in phoscon in version 2.28.1.
One hour later. I did not change anything. The same sensor is not working anymore.
It is open in the moment. The information is wrong and it is still not in grey font. The network just breaks…
Did you try to reconnect it with the workaround to start the light search and put it in pairing mode or just press the button several times to wake it up and get it to reconnect?`Most of the times this works for me.
I got this “not connected” status in the overview too sometimes with versions above 2.23.02 but most of the devices were nevertheless working.
I just got big Problems with some Motion Sensors that were did not detect motion but the light and battery worked. With this devices i removed the battery for 24 hours and restarted my docker to get this working again. there were no other way even if i deleted that devices the motion detection would not come to life, even if its paired as a new device.
I won’t be of help, so tagging me doesn’t work 
This makes me wonder tho: are you sure there is only running one instance of deconz instead of 2?
The reason I ask is that if not connected is shown, it is not able to send or receive ZigBee messages. If you have both deconz Gui and headless running, they both try to start and that might be causing your issue.
You have issue with the _TZE200_bjawzodf ?
On the DDF, replace the
"read": {"fn": "tuya"},
by
"read": {"fn": "none"},
There is only one.
This is something that can freeze deconz, long story.
1 Like
So I did load my Synology Backup from the day before the update and did recouple all sensors, switches and lights once again. Now I’m again backon the holy 2.23.02. And as expected everything is just running fine.
I don’t know what the problem is with the versions above but there just been so much strange behaviours that ths must be some more bugs in charge of this.
I guess I will have to look into zigbee2mqtt in the future if updating deconz is since many version not an option for me and many other Synology NAS users.
yes I spended a whole day connecting, reconnecting and so on. It never really worked for more then a few hours… And I have a lot experience since 4 years of use with deconz and all the versions before. All above 2.23.02 just have strange behaviours… Even with the clean install I did yesterday which I also lost a full day with.
I also had this idea and double checked. I always had only one docker container at the time running. Never 2 in parallel… So sadly this is not the solution. Would have been so easy. 
Yeah I had one line lile this in the DDF and changed it according you post now.
Sadly I was not able to try this in the later versions now and I’m not keen on going this path again for the next time. It was just to much work to get everything running again.
@helipus is your version of the docker amd64 too? maybe it has something to do with that base and it could be that people using the arm versions so not have the same problems as we do.
I’m using a Synology NAS DS716+ with an Intel Celeron N3150 1,6GHz and 8 GB RAM. I run deconz in docker.
The version the autoinstall is using when I pick the version is not shown to me and in the exported configuration is also just stated this:
"id" : "249d8abe9773c206c56ed5ce9421490c47348f61658a797b6d8ccd30a317cfa2",
"image" : "deconzcommunity/deconz:2.23.02",
So I’m not sure. I guess I read somewhere that you are right and I’m also using amd64 but I don’t know where to look it up. But all the postings I found with similar problems have been from Synology NAS users. So this must be connected.
Did you check my reply regarding double runs
Yes I did. See me detailed answer to this 3 post before.
I dont have that problem atm, but i’m pretty sure there are no double runs that time because i only have one docker instance.
And by the way i’m also back on 2.23.02 again because as seen in my comparisons it is a pain in the butt to live with that delays.
But lets get to that architecture thing again, could it be possible that just the amd64 port has a bug in it the other versions are not affected by?
I mean @helipus and i are affected in the same way with starting at the same updated version.
We have different hardware since i use a i5 6500 4cores 4 threads with 32 gb ram running the dockers of ssd which should be enough speed to handle deconz (like version 2.23.02 always shows). we Could compare the devices we use… but in first place i think the lowest common denominator should be the architecture the docker runs. As mentioned of Helipus the usage of cpu and i guess of the whole system rises equal to the number of devices. Maybe its just that we are facing that problems because not many people use amd64 with 100+ devices daily or had given up and switched to z2m or something cause there is no way to get new versions running as good as old ones.
In the other thread i was posting the issues got better in the ARM version that were build by manup. the focus there was just on that ARM architecture
Is there a test setup of the devs running amd64 higher than version 2.23.02?
So i just had an idea…i got an raspberry pi4 as backup laying somewhere around. At the end of the month i get 4 days off from work so i’ll be able to fix things with no time pressure,
so the hypothesis is: if i’ll setup a fresh ARM version of deconz (2.29.0 or a stable version below) and import a backup of my current setup it will show the same behaviour as the 2.29.0 amd64 docker did.
If this is not the case it has nothing to do with the devices i’m using rather than the architecture deconz is running on.
@helipus do you own a raspberry too?
No I don’t I always prefered having important services on my NAS which has raid, backups, double lan connection and so on… So I never bought a raspery which I guess would be way to slow for my system anyway. I would be happy if you test it out.
The system here is still running perfectly here with the 2.23.02. No delays or dropouts at all.