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
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 
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?
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 too early, i just tried to switch to the conbeeIII and the result was that after a short time the delays are back, commands got 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.
Perhaps something similar here Deconz is not working anymore or only with enorm delays after repluging the hardware - #14 by helipus
No problem on 2.23.02
Cpu load on later versions.
I have an issue that may or may not be related. Happy to break it into another thread if need be.
I am using the device - Home Assistant Green. I had a Conbee II for some time without either issue below. I’ve been with the Conbee III for around a month and the issues have been consistent/regular.
-
A portion of my sensors are Aqara window/door sensors to detect open/closed states. They didn’t disconnect a single time from the Conbee II. However, the Conbee III is another story. I have to re-sync the Aqara devices randomly every few days by resetting them (pull battery and then 5 seconds power button to re-connect).
-
The Conbee III response time becomes very laggy after a couple of days requiring either a rebooting of the deCONZ add-on -or- a power cycle of the Home Assistant Green. Laggy means that it can take up to two minutes for a door opening, motion sensor detecting movement, etc., for the activity to register on the Conbee III and pass to Home Assistant as an activity to act upon.
Gateway version: 2.25.3
Firmware: 26500900
Installed via HA official add-on
Graphs showing these regular connectivity drops until I reboot:
@Mimiix @manup is there a timeline for a release version of the fix? The Beta is available for over three weeks now, but betas won’t be published as an home assistant add-on.
In my case, most of the hue switches and motion sensors are not working correctly most of the time!
My whole family is annoyed cause of it.
So please publish a release of the fix.
Thanks
1 Like