Looked at deconz-community/deconz-docker and once the package is there shouldn’t be any problem creating the image for my own.
Hi @manup ,
to try to unblock the HA addon release:
do you think this problem has been introduced in the recent releases (note that based on this thread the CPU problem does not happen with previous versions) and so HA addon release is better to wait for a fix, or this is a problem that has been always there?
Thanks
Good question, I did lots of profiling and tests the recent days and there are multiple issues shown in the result which can impact CPU usage, and some of these have been around for a long time. While the first internal testing versions fixed a couple of these it didn’t fix the problems for in the developers setup.
Yesterday I found one one regression which does fit in above mentioned time frame and is quite drastic, a timer could be firing constantly trying to process the outgoing commands queue (even if empty), this regression could be pointed to a change from 2023-09-28. In my local tests the profiler shows a much healthier picture now but that needs to be confirmed with other setups.
I’ve created two test versions for ARM and ARM64 if you like to give it a go.
deconz_2.25.1_72175c-debian_armhf.deb
deconz_2.25.1_72175c-debian_arm64.deb
This can be installed via sudo dpkg -i <filename.deb>
After initial build up of the node graph with lines the CPU usage should drop down to 2–5 %
It is for sure cpu load-wise better:
but what’s more, it looks like the main problem “slow response after a time” seems for now as fixed.
I would like to wait overnight but it is promising as things went always wrong much earlier.
if someone needs a docker image :
docker pull lukics/deconz:2.25.17
Now it’s for sure, the changes are more than beneficial.
The CPU load in the previous versions, and even 2.23.2, piked at every action done on the system (light switch, sensor), and the base load was rather high, without anything going on (night-time).
As seen in the snapshot of the 3 CPU load curve sections (2.24.3, 2.25.17 rebuilding the network, and 2.25.17 settled) things improved a lot.
Regarding the responsiveness, I am knocking on wood, the stuff is lightyears away from it as it was.
I have also the feeling that the reliability improved. In the past, I always had some particular lights that were temporarily unreachable. The network seems also much healthier.
I want to thank here all the engaged (@manup, @Mimiix) for the great support.
Thanks a lot for testing, this looks promising so far. I’m gonna make some more tests on a Raspberry Pi 3B 32-bit version, as there seems to be some differences. Then push out a new beta version following a new stable version a couple of days later which can be pushed into HA add-on.
I just updated a raspberry pi 1 to test this release. No big issues before, some FoH commands that did not occurred. Will see if that still append.
Here the response is completely unacceptable. Sometimes the motion sensors seem to send a signal, or try to, but it is recording with large delays on deCONZ, sometimes the response is just not arriving. If my plugin receives the update, it tries to switch on a light, but the command never reaches the light… at other times it is just fine… Just looks like the graphs posted by @manup , moments of looping and moments of running fine.
I cannot wait to see the beta arrive on this one as the WAF here is going down rapidly at this point… I am running on a Raspbee1 BTW here
Thanks for making this topic - i bought a conbee3 on November 18th and was close to send it back because i had to update to a version above 2.23.02 and sadly i was facing that problems with lags and lost commands since then. Because i use Unraid for doickers it is not possible to use the docker that lukicsl built it just supports linux/amd64. Can someone tell me when this changes will be implemented in the Community Docker or is it not planned? Its hard to tell my wife a plausible Reason why the lights turn on 30- 40 seconds after she pressed the button and why i bought a device for 40€ i couldn’t use for two month.
Try this one:
lukics/deconz-1-25-17:armhf
Always the wifes
does it also take 30-40s when you activate the light directly in the Phoscon App. Otherwise, it could be something else. I had delays but these were rather 2-3s. And the 2.23.2 was running fine.
can’t use this version of the docker because it’s also not compatible requested amd64.
version 2.23.2 is working pretty good, above i can use the gui to switch the lights and that works but there are always a little desync between the bulbs in the groups. it i want to switch the status with a FOPH Switch and i take a look at Gui i can clearly see there is already a delay in that input command. I press the button an it takes about 2-5 seconds just to register that input, and than the output is also delayed randomly. I dont know why just afew people are facing this issues, i think it depens on how big your network is. In Phoscon
i got 75 Lights, 25 Sockets, 16 Switches, 31 Sensors listed, i think that quite decent and could be one of the reasons i face this problems too.
*The Issues are with Conbee II and Conbee III - Today i tried to update to the latest version of the Community-Docker with the hope the issuses could be fix and first i thought i works but after a short amout of time that delay were back again just like you discribe it in your posts *
Sorry was not reading precise enough. if @manup posts the amd/64 version I could build the docker image too.
I had a lot o problems before with conbee being too near to the raspberry. You are using a NAS, but you for sure need to use a USB extension cord.
Since my raspberry days i alway use an 2.0 extention cord. after i migrate my Phoscon/deconz Raspberry pi config to my Unraid server i changed it to an active powered usb 2.0 extension that connects the conbee II from the first floor to my server in the basement and sofar i never got into trouble with it. Things started getting laggy with all versions beyond 2.23.02 so after every update i try i just revert it back. It also means that i’m stuck with Conbee II atm because there ist no way getting the conbee III working with 2.23.02. Pretty frustrating
BTW:
I am running the conbee II stable version 0x26720700.
The 0x26780700 is since 2022 beta and has promising improvements for a lot of my devices.
Does here apply “never change a winning team” as currently I do not have to complain about anything.
I can confirm the release seems to improve responsiveness of some devices. I have two Osram Smart+ switch mini that was not working very well since a long time (command very slow or that didn’t occur), I suspected that was device specific since other switch was working quite well, but since upgrade I didn’t see any situation were a command didn’t happen, they are still a bit slower than other switch but acceptable (< 2sec).
Still no improvement with the new beta. Philips motion sensors do not register changes to motion, FP1 sensors to not change states, lights do not turn on when needed. A rescan of devices does not work correctly. When I do a rescan of my Philips motion sensor, it reports a lights cluster? This is no good at this point really…
strange, is this on the Windows setup or the Raspberry Pi? Which modelid has your Philips sensor?
I have only one Hue motion sensor (version 1 with firmware 20190219) in my setup, here it reacts instantly.
Till yesterday I was running the unofficial beta which was posted in the thread (1)
When the official 2.25.2 beta I replaced the container (2)
There is some difference in the CPU load. At the moment I do not see any other effects
This is how the unofficial beta (2.25.17) was reacting after restart:
(1) start-up and
(2) calm period
The graphs are pretty nice for comparison and debugging
Note the scaling on y-axis due the 20% spike in second graph.
The average CPU usage still looks ok to me, could be better but roughly 5% is the max it should be when idling.
What makes me wonder what the difference is between 2.25.17 and 2.25.2 is that these behave differently in the means of CPU load.
Btw I also switched to Raspberry Pi 5.