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.
I just hope all this researching results find it’s way to the official versions of deconz/Phoscon so the versions beyon 2.23.02 getting usable again
This is on the Raspberry Pi I. The model id is SML001, quite old, guess it is from 2015/2016
ZHAPresence
**************************** Object info *****************************
{
“config”: {
“alert”: “lselect”,
“battery”: 76,
“delay”: 60,
“ledindication”: true,
“on”: true,
“reachable”: true,
“sensitivity”: 2,
“sensitivitymax”: 2,
“usertest”: false
},
“ep”: 2,
“etag”: “6d897bd1a4f271c1ac3b426058008c27”,
“lastannounced”: “2024-02-06T20:06:53Z”,
“lastseen”: “2024-02-06T20:46Z”,
“manufacturername”: “Philips”,
“modelid”: “SML001”,
“name”: “Sensor slaapkamer Motion”,
“productname”: “Hue motion sensor”,
“state”: {
“lastupdated”: “2024-02-06T20:46:50.392”,
“presence”: false
},
“swversion”: “6.1.1.27575”,
“type”: “ZHAPresence”,
“uniqueid”: “00:17:88:01:08:64:0f:43-02-0406”
}
************************* End Object info *******************
Also 20190219 here. Here is an image of the sensor showing a lights section:
This particular sensor is hardly changing to motion, has been rescanned over and over. Others are just staight slow in updating their state, that is why I assumed it was the same issue as discussed in this thread?
Wim
@manup
I don’t want to be nitpicky, but here are my observations from the last few days:
The pre-release version posted in this thread has only half the CPU load compared to the official beta version. Regarding the CPU load, it’s peanuts, but what surprises me is what generates the additional load. With the overhead caused by the CPU load, there are certainly no delays, but what concerns me more is whether this load is not caused by unnecessary actions on the network. I can’t see any apparent differences in the device switches; nevertheless, I think it would be important to determine what the difference between the two versions is regarding CPU load and potential network traffic.
that is why I assumed it was the same issue as discussed in this thread?
Hmm not so sure, the problem seems to be mitigated or less noticeable on faster machines and newer Raspberry Pi versions.
I have now moved my home network also to a Raspberry Pi 1 from 2011 to make some tests. First impressions, the system is really slow compared to Raspberry Pi 4 and 3. For example the logs show average processing of 1-2 milliseconds per incoming command on the RPi 4 vs. 40 milliseconds and sometimes over a second on the RPi 1, which quite bad. But even with slower processing my network works quite well, reacting with switches and motions sensors happens in under a second.
Now I need to figure out where this time is spend, could be DDF / Javascript related or database writes.
oww… maybe we should go the easy way then… my raspberry is from 2014 or so, so maybe I should take the jump and move to a more current raspberry, or move everything to the conbee II. I was holding both the raspbee I and Windows conbee here to be able to test with both for the plugin… but to be honest lately I was only testing the raspberry… I will think on the best option here…Having only one deCONZ gateway will definitly make things easier
You may also try v2.25.3 which is currently compiling, I could identify database writes as heavy hitters on the RP1 and the new version has a small fix to prevent that if possible. At least on my setup this looks much smoother now.
But yeah for now I wouldn’t recommend RP1 for realistic networks and a smooth experience. While the CPU isn’t that bad, the sd-card writes will always be super slow and blocking.
Will version 2.25.3 accessible for everyone? Does this version solve the issues @lukicsl made this thread for?
I’m still waiting for an amd64 version of the docker to test that does not have this lags and responsive issues i get when i update to a version above 2.23.02.
Adding more bandwidth fixes a lot of network issues.
Adding more CPU cycles fixes a lot of other issues.
Looks like it has been released as stable. Not sure why, as we aren’t even remotely close to being sure it is fixed.
I tested the 2.25.3 today. It makes the response better, but still the motion sensors are missing to report their correct status @manup I will move to my conbee II and windows this weekend. So I would suggest that my PI 1 and RaspBee1 are no longer an issue.Eiter one could be just dying at the moment. Probably better to focus on the future for now 
I probably will still add the PI 5 later on, just to still have two environments for testing with my plugin.
Thanks!
@w.vuyk Those are Hue sensors, right?
This might relate to this: deconz V2.25.3 - Signify LTW012 show ON (in phoscon) even though it is OFF · Issue #7579 · dresden-elektronik/deconz-rest-plugin · GitHub
@Mimiix The issue on github is pointing to lights, where my issue is with motion sensors not updating their status. Majority of the sensors are Hue motion sensors (SML001) which are now also showing a lights entry on the deCONZ map when rescanned (see my earlier post). But other motion sensors, like the Aqara lumi.sensor_motion.aq2 sensor are also missing updates… I am slowly getting the feeling that the radio of the RaspBee1 is giving up on me here.
I’m wondering because there were changes to a Hue specific part, and you are having issues with a hue device.
If we see issues with lights, i’m confident that it could also apply to motion sensors as lights are often rock solid in terms on them working.
It doesn’t work like that, the Hue lights and sensors are running on complete different DDFs.
1 Like
For me 2.24.2 => 2.25.3 same CPU usage or even a little les (good work !). The maj is represented by the load of consumption this morning
1 Like
Tested the new amd64 version but makes no difference. The spikes on version 2.25.3 going up to 25% total cpu usage in idle. while the max usage of version 2.23.02 is around 2% in idle. What is the main difference between 2.23.02 and the versions above. Something must have changed drastically to trigger this kind of issues. For now I’ll stay on 2.23.02 and wait for the next version and otherwise i’ll send my Conbee III back.
Do you notice any other undesirable effects besides the 25% CPU usage? I highlighted the CPU usage as it may indicate the underlying issue causing delayed reactions to events. However, I am generally content with the CPU load as long as everything functions as expected.
On a positive note, I have observed significant improvements with versions 2.25.2 and 2.25.3 in terms of both responsiveness and CPU performance in my setup.
It seems that each configuration may encounter its own set of challenges. After exporting a comprehensive log dump and receiving assistance from @manup, he was able to identify and address my specific issue. Your experience may vary, as the Zigbee ecosystem encompasses a wide variety of devices and configurations.
Over the past six years of using Zigbee technology, I’ve witnessed substantial advancements, albeit with occasional setbacks.
I deeply appreciate the dedication of those involved in this project. While Dresden Elektronik is a company, it feels more like a community of passionate enthusiasts dedicated to improving the Zigbee ecosystem.
Stay patient, and your expectations will be met.
4 Likes
Most of us are the community 
2 Likes
The first time i installed version 2.25.3 it took 10 seconds again from input on the switch to turning on and off the light/group (I let the whole system settle for 15 minutes after the update)
the second time i updated because i want to see if the cpu usage of the docker is higher on 2.25.3 then it was on 2.23.02 i tested functions instantly - seem to work but also not as reliable and with a delay here and there - i couldn’t say how its behaved after an amount of time passing because i went back to check on the idle cpu usage. what i also noticed is there are moments that single cores of the peak at 100% and my whole system consumption increases from 49 watts to 54 watts average with short peaks showing up to 70 watt. i think this is sth. not to be neglected cause nothing on the setup was changed
i have to say i highly appreciate the work thats been done in this whole project too. I Bought an Conbee II in April 2020 and bought a Conbee III in November 2023 just because i trust in this whole deconz thing. could have bought a simple zigbee usb device and take it for zigbee2mqtt or sth. but i haven’t because of the dedication of the people and the whole idea behind it. For me it worked that good and reliable that the whole three stories of my house got nearly no classical light left in it. Even my Shelly Shutter Relais are switched with Senic FOH Switches using the deconz adapter in Iobroker - because it works quite as good as a wired switch would. But on the other hand i’m also a customer that want to use a product that requires a specific version of a software thats not working properly in my case. i waited because i know with every release of new hardware (and even software) there will be problems and things that have to be solved…but its quite stressful if its not only a single light or device that is not working like it should if you do testing its your whole house that does not work as it should.
Specially when you got persons living in it that don’t understand at all why you need to troubleshoot your lights.