When I change Control to “Hybrid” mode in 2.13.3, my Xiaomi light sensors (lumi.sen_ill.mgl01) do not update any more, not even in deconz (vnc). When I change back to "Basic"mode they start reporting again.
BTW: I had to change to Hybrid mode for new Tuya Smart plugs to display power measurements on pairing.
forwarded to @manup to see if we need a github bug report.
Not sure what happened, but after testing a bit with a Tuya plug DDF, none of the 5 light sensors update any more on 2.13.3! Not even when I switch between Hybrid and basic.
During these issues no data is read/updated:
Update: restoring a backup of the data folder from this morning fixes things again (docker).
Since most of our lighting triggers on light sensors measuring outdoors light level, this was a bit of a problem. No lights turned on because this sensor got stuck thinking it was still day. 
If it re happen can you show the uniqueid of not working device ? To check the endpoint used in it.
I have a similar issue with uniqueid used with a 0xFF instead of the real endpoint.
Happened again to all Lumi sensors today, after having played with Tuya plug DDF yesterday.
So that’s a nasty bug still present in 2.13.4. 
Can you check the uniqueid of not working device in the API ?
Can you try to set the status to “gold”.
Not entirely sure how it works with, but it looks like the built-in ddf breaks the lumi sensor:
Because I don’t see any bindings for luminance?
When trying to create ddf and saving it to the docker mount drive, deconz became extremely sloggish and unresponsive. Had to reset the docker image. Seems like some loading conflict with the existing ddf.
Is there an easy way to remove the ddf from the docker image to force deconz to use legacy mode?
I really think the one that comes with 2.13.4 is not correct because of the missing binding (no measurement was reported). In any case there are no luminance measurements updated for GZCGQ01LM devices added on 2.13.4.
Created a ddf and it seems to work after playing with inclusion/hot reload etc.
And after a deconz docker restart it is no longer working.
I also noticed deconz becomes extremely sluggish in vnc (takes 5-10s before it responds to a mouse click for example, sometimes I have to reset the container and/or it crashes).
The whole ddf thing seems very buggy, and it’s very annoying that a device does not work with a built-in ddf.
This more or less sounds like an performance issue in docker.
I doubt it, and container CPU is 5-10% max. I have narrowed it down to when I try pairing a Lumi sensor. All of a sudden deconz in vnc becomes unresponsive, Phoscon as well, and the container hangs. I am using Basic mode - Gold only (hoping to prevent the built-in ddf that breaks existing light sensors, which is in silver status). If/once pairing mode expires after 60s, deconz becomes a bit more responsive, but not quite back to normal. It’s all very strange…
Can someone else try pairing a GZCGQ01LM in 2.13.4 to see if they see the same?
Any logs?
Unfortunately not, because when it happens there is nothing I can do any more.
Plus getting a log bundle from deconz is a pain even when it’s running fine… 
And I was hoping that somewhone who actually knows what they are doing and understand how DDF should work could reproduce the issue…
I am just trying to get things up and running before it gets dark and the rest of the family starts complaining about the lights not turning on. 
I’ll rest my case.
I have 60+ devices running fine (including the new Tuya plug with the custom DDF, Aqara motion sensors, Vibration sensors, different plugs, Ikea and Aqara lights), it’s just these light sensors that are causing weird issues in 2.13.3 and 2.13.4. If I restore an old DB existing Light sensors work fine, it’s just when I want to add a new one it causes all kinds of seemingly unrelated issues as described.
So hopefully that gives one of the devs enough pointers to test with a Lumi sensor and see if there is indeed anything wrong with it, or if it’s just in my setup somewhere.
Xiaomi generaly don’t use binding/reporting. But yes It’s something you have tried when you have make a new DDF ?
Created a ddf and it seems to work after playing with inclusion/hot reload etc.
Have you deleted the built-in one ? (for conflict)
Can someone else try pairing a GZCGQ01LM in 2.13.4 to see if they see the same?
Yeah, strange you are the only one …
Plus getting a log bundle from deconz is a pain even when it’s running fine
Only on dockers ^^.
The final conclusion (for now) was that using the DDF causes serious issues, at least for me. Not sure why. I hope someone else can test the GZCGQ01LM, to see if it works for them (with existing sensors + add new one with the Silver built-in DDF)?
I haven’t deleted the DDF, I just use Basic mode + Gold during pairing, which should bypass the Silver built-in DDF. A lot of trial and error (and crashes) was involved, but in the end that seems to work for me. I deleted and reset all existing light sensors (press 10s for reset) and then re-added them. So at least the lights automation was fixed just in time before it got dark.
Not sure how it holds up over time though, because I thought several times the issue was fixed at on epoint, and then all of a sudden (or after restart) the light sensors stopped reporting again. Before 2.13.3 I had no issues, but they might have been there from 2.13.0 because I hadn’t added any light sensors in months.
Off-Topic: I still feel creating + downloading a log bundle should be made easy, e.g. from Phoscon.
[Update] Unfortunately again hanging deconz + container just now (container RAM usage crept up to 1.5GB, CPU <2%). I was not even while adding devices or anything, just a spontaneous crash. So unfortunately no logging. Next step: remove all new Light sensors to see if everything stays running.
This kills the WAF for home automation.
I removed all light sensors except for 2 essential ones. But it looks like they are generating a lot of reports somehow? It’s currently dark, so I would not expect them to keep reporting the same value of 0 Lux every few seconds or so? How is reporting frequency and change configured for these sensors, or is that hardcoded in the device? Could this be flooding deconz to the point of becoming unresponsive or does that look normal?Argh… deconz just hung again.
19:18:38:772 0a Parent NWK 0 (0x0000)
19:18:40:051 ZCL attribute report 0x84FD27FFFED24544 for cluster: 0x0B04, ep: 0x01, frame control: 0x18, mfcode: 0x0000
19:18:40:065 ZCL attribute report 0x84FD27FFFECE979C for cluster: 0x0B04, ep: 0x01, frame control: 0x18, mfcode: 0x0000
19:18:40:870 Skip idle timer callback, too early: elapsed 814 msec
19:18:40:886 ZCL attribute report 0x04CF8CDF3C7B50D0 for cluster: 0x0400, ep: 0x01, frame control: 0x18, mfcode: 0x0000
19:18:40:932 ZCL attribute report 0x04CF8CDF3C7B50D0 for cluster: 0x0400, ep: 0x01, frame control: 0x18, mfcode: 0x0000
19:18:42:528 ZCL attribute report 0x04CF8CDF3C78B5DC for cluster: 0x0400, ep: 0x01, frame control: 0x18, mfcode: 0x0000
19:18:42:536 ZCL attribute report 0x04CF8CDF3C78B5DC for cluster: 0x0400, ep: 0x01, frame control: 0x18, mfcode: 0x0000
19:18:46:012 ZCL attribute report 0x84FD27FFFED24544 for cluster: 0x0B04, ep: 0x01, frame control: 0x18, mfcode: 0x0000
19:18:46:022 ZCL attribute report 0x04CF8CDF3C7B50D0 for cluster: 0x0400, ep: 0x01, frame control: 0x18, mfcode: 0x0000
19:18:46:075 ZCL attribute report 0x04CF8CDF3C7B50D0 for cluster: 0x0400, ep: 0x01, frame control: 0x18, mfcode: 0x0000
19:18:46:870 Skip idle timer callback, too early: elapsed 852 msec
19:18:47:341 ZCL attribute report 0x84FD27FFFECE979C for cluster: 0x0B04, ep: 0x01, frame control: 0x18, mfcode: 0x0000
19:18:47:517 ZCL attribute report 0x04CF8CDF3C78B5DC for cluster: 0x0400, ep: 0x01, frame control: 0x18, mfcode: 0x0000
19:18:49:130 ZCL attribute report 0x84FD27FFFED24544 for cluster: 0x0B04, ep: 0x01, frame control: 0x18, mfcode: 0x0000
19:18:49:871 Skip idle timer callback, too early: elapsed 736 msec
19:18:50:825 ZCL attribute report 0x04CF8CDF3C7B50D0 for cluster: 0x0400, ep: 0x01, frame control: 0x18, mfcode: 0x0000
19:18:50:844 ZCL attribute report 0x04CF8CDF3C7B50D0 for cluster: 0x0400, ep: 0x01, frame control: 0x18, mfcode: 0x0000
19:18:51:870 Skip idle timer callback, too early: elapsed 463 msec
19:18:52:508 ZCL attribute report 0x04CF8CDF3C78B5DC for cluster: 0x0400, ep: 0x01, frame control: 0x18, mfcode: 0x0000
19:18:52:532 ZCL attribute report 0x04CF8CDF3C78B5DC for cluster: 0x0400, ep: 0x01, frame control: 0x18, mfcode: 0x0000
19:18:54:271 ZCL attribute report 0x84FD27FFFECE979C for cluster: 0x0B04, ep: 0x01, frame control: 0x18, mfcode: 0x0000
19:18:54:870 Skip idle timer callback, too early: elapsed 593 msec
19:18:55:327 ZCL read attr 0x84FD27FFFECE979C, ep: 0x01, cl: 0x0006, attr: 0x0000, mfcode: 0x0000, aps.id: 144, zcl.seq: 214
19:18:55:365 ZCL read attr 0x84FD27FFFECE979C, ep: 0x01, cl: 0x0000, attr: 0x4000, mfcode: 0x0000, aps.id: 147, zcl.seq: 215
19:18:55:420 ZCL read attr 0x84FD27FFFECE979C, ep: 0x01, cl: 0x0000, attr: 0x4000, mfcode: 0x0000, aps.id: 149, zcl.seq: 216
19:18:55:816 ZCL attribute report 0x04CF8CDF3C7B50D0 for cluster: 0x0400, ep: 0x01, frame control: 0x18, mfcode: 0x0000
19:18:57:372 ZCL read attr 0x84FD27FFFED24544, ep: 0x01, cl: 0x0006, attr: 0x0000, mfcode: 0x0000, aps.id: 164, zcl.seq: 219
19:18:57:396 ZCL read attr 0x84FD27FFFED24544, ep: 0x01, cl: 0x0000, attr: 0x4000, mfcode: 0x0000, aps.id: 166, zcl.seq: 220
19:18:57:425 ZCL read attr 0x84FD27FFFED24544, ep: 0x01, cl: 0x0000, attr: 0x4000, mfcode: 0x0000, aps.id: 168, zcl.seq: 221
19:18:57:516 ZCL attribute report 0x04CF8CDF3C78B5DC for cluster: 0x0400, ep: 0x01, frame control: 0x18, mfcode: 0x0000
19:18:57:524 ZCL attribute report 0x04CF8CDF3C78B5DC for cluster: 0x0400, ep: 0x01, frame control: 0x18, mfcode: 0x0000
19:18:58:571 sensor 117 (lumi.sensor_motion): disable presence
19:19:01:244 ZCL attribute report 0x84FD27FFFECE979C for cluster: 0x0B04, ep: 0x01, frame control: 0x18, mfcode: 0x0000
19:19:01:258 ZCL attribute report 0x84FD27FFFED24544 for cluster: 0x0B04, ep: 0x01, frame control: 0x18, mfcode: 0x0000
19:19:01:530 ZCL attribute report 0x84FD27FFFED24544 for cluster: 0x0B04, ep: 0x01, frame control: 0x18, mfcode: 0x0000
19:19:01:536 ZCL attribute report 0x04CF8CDF3C7B50D0 for cluster: 0x0400, ep: 0x01, frame control: 0x18, mfcode: 0x0000
19:19:01:954 Set sensor check interval to 1000 milliseconds
19:19:02:515 ZCL attribute report 0x04CF8CDF3C78B5DC for cluster: 0x0400, ep: 0x01, frame control: 0x18, mfcode: 0x0000
19:19:02:524 ZCL attribute report 0x04CF8CDF3C78B5DC for cluster: 0x0400, ep: 0x01, frame control: 0x18, mfcode: 0x0000
19:19:04:677 ZCL attribute report 0x84FD27FFFED24544 for cluster: 0x0B04, ep: 0x01, frame control: 0x18, mfcode: 0x0000
19:19:04:901 Device TTL 1505 s flags: 0x7
19:19:05:371 Skip idle timer callback, too early: elapsed 688 msec
19:19:05:743 ZCL attribute report 0x04CF8CDF3C7B50D0 for cluster: 0x0400, ep: 0x01, frame control: 0x18, mfcode: 0x0000
19:19:05:751 ZCL attribute report 0x04CF8CDF3C7B50D0 for cluster: 0x0400, ep: 0x01, frame control: 0x18, mfcode: 0x0000
19:19:07:184 ZCL attribute report 0x84FD27FFFED24544 for cluster: 0x0B04, ep: 0x01, frame control: 0x18, mfcode: 0x0000
19:19:07:510 ZCL attribute report 0x04CF8CDF3C78B5DC for cluster: 0x0400, ep: 0x01, frame control: 0x18, mfcode: 0x0000
19:19:09:599 ZCL attribute report 0x84FD27FFFECE979C for cluster: 0x0B04, ep: 0x01, frame control: 0x18, mfcode: 0x0000
19:19:10:212 ZCL attribute report 0x84FD27FFFED24544 for cluster: 0x0B04, ep: 0x01, frame control: 0x18, mfcode: 0x0000
19:19:10:705 ZCL attribute report 0x04CF8CDF3C7B50D0 for cluster: 0x0400, ep: 0x01, frame control: 0x18, mfcode: 0x0000
19:19:12:520 ZCL attribute report 0x04CF8CDF3C78B5DC for cluster: 0x0400, ep: 0x01, frame control: 0x18, mfcode: 0x0000
19:19:12:530 ZCL attribute report 0x04CF8CDF3C78B5DC for cluster: 0x0400, ep: 0x01, frame control: 0x18, mfcode: 0x0000
19:19:12:947 ZCL attribute report 0x84FD27FFFED24544 for cluster: 0x0B04, ep: 0x01, frame control: 0x18, mfcode: 0x0000
19:19:15:702 ZCL attribute report 0x04CF8CDF3C7B50D0 for cluster: 0x0400, ep: 0x01, frame control: 0x18, mfcode: 0x0000
19:19:16:242 ZCL attribute report 0x84FD27FFFED24544 for cluster: 0x0B04, ep: 0x01, frame control: 0x18, mfcode: 0x0000
19:19:16:249 ZCL attribute report 0x04CF8CDF3C7B50D0 for cluster: 0x0400, ep: 0x01, frame control: 0x18, mfcode: 0x0000
19:19:17:522 ZCL attribute report 0x04CF8CDF3C78B5DC for cluster: 0x0400, ep: 0x01, frame control: 0x18, mfcode: 0x0000
19:19:17:534 ZCL attribute report 0x04CF8CDF3C78B5DC for cluster: 0x0400, ep: 0x01, frame control: 0x18, mfcode: 0x0000
19:19:20:662 ZCL attribute report 0x04CF8CDF3C7B50D0 for cluster: 0x0400, ep: 0x01, frame control: 0x18, mfcode: 0x0000
19:19:20:671 ZCL attribute report 0x04CF8CDF3C7B50D0 for cluster: 0x0400, ep: 0x01, frame control: 0x18, mfcode: 0x0000
19:19:22:695 ZCL attribute report 0x84FD27FFFED24544 for cluster: 0x0B04, ep: 0x01, frame control: 0x18, mfcode: 0x0000
19:19:22:718 ZCL attribute report 0x04CF8CDF3C78B5DC for cluster: 0x0400, ep: 0x01, frame control: 0x18, mfcode: 0x0000
19:19:23:370 Skip idle timer callback, too early: elapsed 668 msec
19:19:25:022 ZCL attribute report 0x84FD27FFFED24544 for cluster: 0x0B04, ep: 0x01, frame control: 0x18, mfcode: 0x0000
19:19:25:634 ZCL attribute report 0x04CF8CDF3C7B50D0 for cluster: 0x0400, ep: 0x01, frame control: 0x18, mfcode: 0x0000
19:19:27:490 ZCL attribute report 0x04CF8CDF3C78B5DC for cluster: 0x0400, ep: 0x01, frame control: 0x18, mfcode: 0x0000
19:19:27:504 ZCL attribute report 0x04CF8CDF3C78B5DC for cluster: 0x0400, ep: 0x01, frame control: 0x18, mfcode: 0x0000
19:19:28:178 ZCL attribute report 0x84FD27FFFED24544 for cluster: 0x0B04, ep: 0x01, frame control: 0x18, mfcode: 0x0000
19:19:28:876 ZCL attribute report 0x588E81FFFEFF604D for cluster: 0x0702, ep: 0x01, frame control: 0x08, mfcode: 0x0000
19:19:30:595 ZCL attribute report 0x04CF8CDF3C7B50D0 for cluster: 0x0400, ep: 0x01, frame control: 0x18, mfcode: 0x0000
19:19:30:611 ZCL attribute report 0x04CF8CDF3C7B50D0 for cluster: 0x0400, ep: 0x01, frame control: 0x18, mfcode: 0x0000
19:19:32:487 ZCL attribute report 0x04CF8CDF3C78B5DC for cluster: 0x0400, ep: 0x01, frame control: 0x18, mfcode: 0x0000
19:19:32:498 ZCL attribute report 0x04CF8CDF3C78B5DC for cluster: 0x0400, ep: 0x01, frame control: 0x18, mfcode: 0x0000
19:19:34:089 ZCL attribute report 0x84FD27FFFED24544 for cluster: 0x0B04, ep: 0x01, frame control: 0x18, mfcode: 0x0000
19:19:35:569 ZCL attribute report 0x04CF8CDF3C7B50D0 for cluster: 0x0400, ep: 0x01, frame control: 0x18, mfcode: 0x0000
19:19:35:594 ZCL attribute report 0x04CF8CDF3C7B50D0 for cluster: 0x0400, ep: 0x01, frame control: 0x18, mfcode: 0x0000
19:19:37:089 ZCL attribute report 0x84FD27FFFED24544 for cluster: 0x0B04, ep: 0x01, frame control: 0x18, mfcode: 0x0000
19:19:37:473 ZCL attribute report 0x04CF8CDF3C78B5DC for cluster: 0x0400, ep: 0x01, frame control: 0x18, mfcode: 0x0000
19:19:39:608 ZCL attribute report 0x84FD27FFFECE979C for cluster: 0x0B04, ep: 0x01, frame control: 0x18, mfcode: 0x0000
19:19:40:813 ZCL attribute report 0x84FD27FFFED24544 for cluster: 0x0B04, ep: 0x01, frame control: 0x18, mfcode: 0x0000
19:19:40:824 ZCL attribute report 0x04CF8CDF3C7B50D0 for cluster: 0x0400, ep: 0x01, frame control: 0x18, mfcode: 0x0000
19:19:40:847 ZCL attribute report 0x04CF8CDF3C7B50D0 for cluster: 0x0400, ep: 0x01, frame control: 0x18, mfcode: 0x0000
Another update: when I choose “Edit DDF” on the sensor and pick “Hot reload”, the session becomes unresponsive right away. So that again indicates that it is related to DDF (note that the built-in Silver DDF was not loaded when I started deconz initially). Hopefully someone can reproduce this issue.
Update: Resetting these existing 2 devices (press pairing button 10s) and re-adding them seems to solve the excessive reporting issue for them. Again: not sure what caused them to report that frequently, this was never an issue in the past. So far no hangs.
I don’t know this Xiaomi sensor, but for most of them, the report is hardcoded and you can’t set it, the device send report every X minuts or if the value change.
Could this be flooding deconz to the point of becoming unresponsive
No, a battery sensor can’t do that, a plug or a philip bulb send lot of more report than a battery sensor.
But deconz can have an issue in the code that slow down the code itself.
But I m agree, I think too you have so much report for a simple light sensor, On my side Xiomi sensors send more report after the inclusion, and become more lazy with time.
But have you tried to change the reporting setting ? At least Check if the reporting is editable on this sensor ?
@Smanar Thanks for confirming that! I assumed the device chooses reporting by itself, but I don’t know why those 2 were reporing every few seconds, even when the luminance did not change. But I definitely saw this happening in deconz from vnc: those 2 sensors kept blinking blue every second or so, and looking at the logs they were actually reporting values all the time.
To solve this:
Do you maybe have a GZCGQ01LM or reporting Tuya Plug (SHP15) to test the DDF issue with? Just try to add it with DDF.
NOTE: I also ended up removing all _TZ3000_w0qqde0g plugs that were using using a custom DDF, because they triggered similar issues. The devices reported fine for a while, but slowly deconz (and updates) started to get less responsive and eventually (almost) hang. The more plugs I used, the faster it happened. I used them for 3 PC’s (so a lot of changing measurements).
