Current deconz (2.24.3 & 2.25.1) slow in response after time

I just tested 2.25.3 And the same problem persists, unfortunately. At first it seemed fine, but after 15 minutes or so, high CPU usage again (around 20%) and motion sensors (mostly Phillips SML001) seemingly missing their service calls. I saved my logs if anyone wants to take a look. I’ve reverted to 2.23.02 for now.

2 Likes

same here. After I upgraded to 2.25.3 (Home Assistant Addon), I got the same issues.
Philips motion sensors are getting red lights, same for hue dimming switches v1. Some of my aquara open close sensors are not reachable anymore.
Same for one of my two ikea fyrtur blinds.
Maybe its because most of my hue bulbs don’t have DDF’s?
The old version was so much more stable than this one is!

Just to share my experience: I’ve got many Hue motion sensors and Aqara open close sensors, they all work for me with 2.25.3/HA addon, like they used to work also with previous versions. I saw no differences.

Can you please share some debug logs via “deCONZ > Help > Debug view” and here enable INFO, APS, DEV, DDF, JS.

Currently it’s hard to figure out what is different in the setups which still show the issues, while others seem to to be fixed. Perhaps we have some devices / DDFs not playing well yet. With the logs I hope to figure out which devices are extra loud.

Also just sharing my experience: started with a Raspbee I on a Raspberry Pi Zero and running a lot more than deconz on the Pi. Always worked like a charm, no slowness in using zigbee devices. However, there was something like 2 years ago driving the CPU usage on my weak machine quite high, but that was resolved back then.

Meanwhile, moved over to a Pi Zero 2 and still amazed that the CPU seems to be bored all the time considering what’s all running on it.

how long should the logs be? would it help to have logs of 2.23.02 and 2.25.3 for a side by side comparison?
could it be that the amd64 base have something to do with the system not working properly or could it be the size of the network or number of sensors updating the same time?

how long should the logs be?

Ideally like 10–20 minutes from the point where the issues can be seen.

For now the v2.25.3 logs are enough, the difference to v2.23.2 might not be that useful since much has changed and converted to DDF handling.

Since all this seems to be very related to specific networks and devices I think we need to figure out which devices may cause lots of processing and then check the related code and DDFs.

could it be that the amd64 base have something to do with the system not working properly or could it be the size of the network or number of sensors updating the same time?

AMD64 should be fine and is mostly smoother and faster then the Raspberry Pi versions to to faster CPUs and non SD-card drives.

But if something goes rogue and keeps spinning on the CPU it can cause troubles on any platform. The recent versions have fixed a bunch of these, but I guess there are more corners which can cause these and need be fixed.

I try to save some logs on 2.25.3 at the weekend.
Could the connection to the the deconz iobroker adapter also be affected by the changes made in version beyond v2.23.02?

@manup Sorry for the delay - today i upgrade to 2.26.0 (hope thats also fine for logging) and saved 20 minutes of log with the mentioned options checked:

most of the time the system was in idle mode - just my standard communication between deconz and the iobroker deconz adapter was happening here.

I also waited some time before i start the logging and reconnected all sensors that were disconnected because of the update.

sometime after the start of the system and before i saved the logs i recognized that a Hue Motion Sensor kept presence state on true for about 5 minutes twice. the whole system felt a little better than 2.25.3 but the reactiontime button pushed —> light switched still does not come close to 2.23.2 and sometimes the commands got lost or delayed. While sitting and checking the docker stats the system peaked at a max of 25% usage of the CPU in idle and was not leaving the double digits very often. Back at 2.23.02 the docker peaks at max of 4% usage in idle and average i think is about 1,8% usage . Same Setup same communication with the iobroker adapter and no lights that were switched.

Hope this will get some answers

Deconz 2.26.0 Log ConbeeII AMD64

1 Like

Thanks a lot, I’ll check the logs asap. We already found some issues to fix for specific devices which might come into play here. These keep the whole machinery busy while preventing outgoing control commands to be delivered.

1 Like

Not the real problem here, but you may check the battery of the Hue motion sensor :wink:

Address: 00:17:88:01:08:65:08:e9
Battery level: 16.5 %

Sometimes sensors act a bit weird on low power.

Hmm that’s curious, can you please read the 0406 Occupancy sensing cluster in the UI (double click on the node and then double click on the 0406 cluster and click the read button).

Here the attribute with id 0x0010 is the configurable delay the sensor stays in the occupied state.
On a freshly joined sensor this is 0 but it could also be different value than the sensor was joined before DDF for it existed or was configured via Phoscon App sensor control.

Mine is 2 minutes, I’ve set this then tinkering around.

The Hue light with address 00178801028753A0 looks suspicious. The binding table is queried non stop for some reason. It doesn’t seem to be a DDF controlled light yet, so controlled by the legacy code.

Which model ID does it have?

Hello @manup
thanks for the fast resonse and looking at my log

The sensor is powered by rechargeable Batteries i’ll replace them soon - but till now it always worked as it should.

I set the the value to all of my motionsensors to 0 because i want to react it as responsive as they could. All of my delays switching off lights are done by iobroker so its best to have it that way.

i think in that case the command of the sensor saying “no presence detected” could have got lost again in the communication with deconz

Model Identifier is: LWB010
I looked at the data of bulbs next to it and i couldn’t tell any difference seems that they are quite similar.

all screenshots and data above were taken from deconz with version 2.23.02 running but i just switched to 2.26.0 again and couldn’t see any difference in data and noticed that DDF tag some lights, sockets and sensors have and some don’t have. Would it help to list all lights, sockets and sensors with model ID and sw version that don’t thave that DDF tag?

Screenshot 2024-02-21 083647

Since i flashed 2.26.0 yesterday for the second time i let it settle and gave it a try till now, even with the spikes of the cpu usage. i have to say it feels quite better this time than the other versions above 2.23.02. it happens sometimes that the system does not recognize a command or loses it so we have to press a button again here and then but not quite as often as before. So i think i’ll use this version to test in our dailly life till the next release.

I think i was Happy a little to early, i just tried to switch to the conbeeIII and the result was that after a short time the delays are back, commands go lost and it’s not responsive at all.

Captured some Logs (+15 Minutes) after the Problems started hope this helps, i try to restart an let it settle again but if it behaves the same as before i switch back to conbeeII again.

Deconz log 2.26.0 ConbeeIII AMD64 22.02.2024