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

deCONZ General Support
1

I am running my deconz as a docker container.
I am using openhab as a container too, which I use for my home automation.
I was running for a long time the deconz version 2.23.02 and things were functioning as expected.

At a certain point, I decided to update my home automation stack.

And then I got certain unpredicted sluggish behavior of all the attached zigbee endpoints.

I searched extensively to find the reason first blaming openhab’s new version.
Finally, I realized that even with the Phoscon app I can have a situation where lights react sometimes with a 1-3s delay.
My impression is that as if the light got to sleep and after being waked up, the light is responsive for some cycles.

e.g. Change light status (regardless of being on or off) after a long pause →
the light reacts with 1-3s →
immediately cycle multiple times the light state →
most of the cycles are executed immediately, but not all, some have delays.

Here I am talking about lights but I see the same behavior when pressing a switch and looking at the openhab’s channel events.

As next I stepped up from 2.24.2 to the latest 2.25.1. Immediately after the upgrade things seemed to be okay, but after a while the sluggish behavior picked up.

Now I stepped back to the earlier 2.23.02 version and things are working as expected, with no delay and stable

How can I debug this situation to create a case?
Anybody else has similar situation?

Summary:

More and more I am sure it is not a DDF issue but more something in the core.

For example, this issue cannot be a DDF problem:

I have some ceiling lamps which are containing each 8 individual E27 socket lamps. These individual devices are then bound to groups for each ceiling lamp. When I operate these groups, the lamps are not as fully synchronized as they should be.

2

Hi,

Can you share some logs?
How to get logs?

3

Thank you for the first hint.
I will do the logs tomorrow as right now we night time and my wife would not be amused if I now play with the lights.

I did some preparation and found a better option for the docker environment as described in “how to get logs”:

instead of copy-pasting from VNC, it is possible to after setting INFO , INFO_L2 , ERROR , ERROR_L2 , APS , APS_L2in VNC then connect to containers debug output by

docker logs <container name> -f | tee debug.txt

would be nice if you update the docu

4

Feel free to update the text and I’ll replace as I have no clue what you mean. I have no idea on docker.

5

I have uploaded the log files to google:
https://drive.google.com/drive/folders/1NqbN-nPeky9OWuCUZZj5OdhmKhOFxECg?usp=sharing

on the latest 2.24.2 I can reproduce the behavior right after the start.
I did not create a log on the current beta as the situation is the same as on the latest.

6

Could you please use pastebin or something similar?

7

I’ve been running deConz 2.25.1-beta in a Docker Container or a while now, without any such problems - for whatever it’s worth. :blush:

8

debug.2.24.2.log
debug.2.23.2.log

9

at a glance looking at both logs and searching for “failed”:

2.24.2 has 8x more failed messages
and such as:

07:31:14:922 SC state change failed: 00:0b:57:ff:fe:46:c3:17-01
07:31:14:922 SC state change failed: 00:0b:57:ff:fe:46:c3:17-01
07:31:14:922 SC state change failed: 00:0b:57:ff:fe:46:c3:17-01

such messages do not exist on 2.23.2

10

To just mention:
one of the nodes I switched on/of was: 00:0b:57:ff:fe:46:c3:17-01
this is one of the switches I used: 0x04cf8cdf3c77c3a2

11

I don’t the problem, but it have probably something to see with the field “config/color/execute_if_off”.
Have you try to remove them from the DDF ?

For exemple this one
07:31:07:859 DEV found DDF for 0x000B57FFFE46C317, path: /usr/share/deCONZ/devices/ikea/tradfri_bulb_e27_ws_opal_980lm.json

12

I hope I am understanding the hint the right way, but:
I for sure did not mess around with the DDF’s in the past. As I am using a docker container when switching between versions, the DDF’s are always coming fresh from the image.

That might be the problem here that between 2.23.2 and 2.24.2 some DDF’s entered the scene an now causing these troubles

13

I have compared the two log files and looked for the following log entries:
…DEV no DDF for…

the result is that between version 2.23.2 and 2.24.2 for these devices the DDF has been implemented and deployed:

< TRADFRI on/off switch
< TRADFRI motion sensor
< TRADFRI bulb E27 WS opal 980lm
< TRADFRI signal repeater

I am going to look further but I suspect that this is the root cause.
My guess is it has to be a repeater device that causes this trouble.
I have looked at the git and see that both DDF are implemented by @ebaauw . Could you please have a look at that issue or do I have to open a case at the github?

15

It’s not a DDF problem, but it seem there is perhaps a problem on the “config/color/execute_if_off” option, if you remove it from the DDF, all this part will be skipped.
It’s perhaps possible to try with DDF core disabled, but I m not sure it’s still possible ATM, perhaps with just setting the DDF to “Draft” status, this can be done with the editor without restarting deconz, so possible on docker.

16

I played around with setting DDF to draft, though only for TRADFRI signal repeater.
Tomorrow I will try it for the opal 980lm.

However, what I did was copy the IKEA directory from working 2.23.2 over to 2.24.3 (previously deleting the content). No luck.

17

They probably have both the field “config/color/execute_if_off”

But it’s just a way to explore, I don’t see why it can cause issue, it’s not something new, and you are not alone with thoses devices.

18

In 2.23.2 both of those do not have a DDF.

What I wrote in the case that was closed is also a strange behavior described of switching groups:
the members of the group act asynchronously up to 2s during on/off.

19

Ha ok, so bad luck, your procedure was fine. Have just take a look, you are right, the DDF is just 4 month old.
You have took a look to see if you still had without DDF or when you had set the “draft” Status ? (As there is no DDF without this field)

07:31:14:922 SC tick --> StateRead config/color/execute_if_off, 00:0b:57:ff:fe:46:c3:17-01
07:31:14:922 SC state change finished: 00:0b:57:ff:fe:46:c3:17-01
07:31:14:922 SC state change failed: 00:0b:57:ff:fe:46:c3:17-01
07:31:14:922 SC state change failed: 00:0b:57:ff:fe:46:c3:17-01
07:31:14:922 SC state change failed: 00:0b:57:ff:fe:46:c3:17-01
20

image
image787×244 91.8 KB

More and more I am sure it is not a DDF issue but more something in the core.

For example, this issue cannot be a DDF problem:

I have some ceiling lamps which are containing each 8 individual E27 socket lamps. These individual devices are then bound to groups for each ceiling lamp. When I operate these groups, the lamps are not as fully synchronized as they should be.

For me, it means I have to stay at 2.23.2 for the moment and hope that somebody else trips over this problem too.

21

Yeah effectively, now same issue but on other command, not a solution.