Issue: Deconz Docker becomes unresponsive with Tuya TS011F Plugs DDF

iisworks · January 30, 2022, 2:01pm

This has been going on for a while (2.13.3 - 2.14), seems to be related to DDF for Tuya plugs. I managed to collect some clues and a bit of logging.

Deconz is running fine with 5 existing BW-SHP15 plugs (they report every few seconds), as long as I stay away from DDF. I have this DDF setting and no custom DDF files in use or loaded:

As soon as I enable Silver, the built-in NEO DDF is picked up and something happens that slows down deconz. I also see that the existing BW-SHP15 plugs do not update as often any more in Homey (my third party app).

From the log:
13:37:44:523 DEV found DDF for 0x84FD27FFFECE99DC, path: /usr/share/deCONZ/devices/neo/NAS-WR01B.json

Note that 0x84xxxx devices are BW-SHP15 plugs (_TZ3000_mraovvmm), not a Neo plug (the same TS011F family, but a different manufacturer code).

I also noticed that RAM usage keeps increasing for the Docker container (normally it’s rock solid at <150MB and <2% CPU for weeks):

When this happens, the api doesn’t seem to update power consumption etc any more, and n the log I see a lot of these:
14:16:35:247 No power sensor found for 0x84FD27FFFECE7BEA, endpoint: 0x01
In the end I had to restore yesterday’s database and all was well again.

Is there a thorougly tested Tuya Plug DDF available? Can someone with Tuya Plugs else please check if they are seeing similar? Or maybe one of the devs has a clue what could cause this behavior? Maybe @manup or @Smanar?

I managed to copy some Info L1 + L2 log from vnc.

13:37:44:523 DEV found DDF for 0x84FD27FFFECE99DC, path: /usr/share/deCONZ/devices/neo/NAS-WR01B.json
13:37:44:670 DEV found DDF for 0x588E81FFFEFF604D, path: 
13:37:47:025 ZCL attribute report 0x84FD27FFFECE7C45 for cluster: 0x0B04, ep: 0x01, frame control: 0x18, mfcode: 0x0000 
13:37:47:041 ZCL attribute report 0x84FD27FFFED24544 for cluster: 0x0006, ep: 0x01, frame control: 0x18, mfcode: 0x0000 
13:37:47:042 SC tick --> StateRead
13:37:47:043 SC state change failed: 84:fd:27:ff:fe:d2:45:44-01
13:37:48:042 ZCL attribute report 0x84FD27FFFED245B2 for cluster: 0x0B04, ep: 0x01, frame control: 0x18, mfcode: 0x0000 
13:37:48:070 ZCL attribute report 0x84FD27FFFED24544 for cluster: 0x0B04, ep: 0x01, frame control: 0x18, mfcode: 0x0000 
13:37:48:099 Skip idle timer callback, too early: elapsed 54 msec
13:37:48:132 DEV found DDF for 0xBC33ACFFFE2BF652, path: 
13:37:49:493 ZCL attribute report 0x84FD27FFFECE7C45 for cluster: 0x0B04, ep: 0x01, frame control: 0x18, mfcode: 0x0000 
13:37:50:442 ZCL attribute report 0x84FD27FFFECE7BEA for cluster: 0x0B04, ep: 0x01, frame control: 0x18, mfcode: 0x0000 
13:37:50:443 Skip idle timer callback, too early: elapsed 946 msec
13:37:50:452 DEV found DDF for 0x00158D000520F443, path: 
13:37:50:600 DEV found DDF for 0x00158D000520E453, path: 
13:37:50:732 ZCL attribute report 0x00158D0004AB3C58 for cluster: 0x0406, ep: 0x01, frame control: 0x18, mfcode: 0x0000 
13:37:51:294 ZCL attribute report 0x84FD27FFFECE99DC for cluster: 0x0B04, ep: 0x01, frame control: 0x18, mfcode: 0x0000 
13:37:52:410 ZCL attribute report 0x84FD27FFFECE7C45 for cluster: 0x0B04, ep: 0x01, frame control: 0x18, mfcode: 0x0000 
13:37:53:429 ZCL attribute report 0x84FD27FFFECE7BEA for cluster: 0x0B04, ep: 0x01, frame control: 0x18, mfcode: 0x0000 
13:37:53:430 DEV found DDF for 0x5C0272FFFE741651, path: 
13:37:53:432 Skip idle timer callback, too early: elapsed 646 msec
13:37:53:512 DEV found DDF for 0x00158D000520ABA2, path: 
13:37:54:815 ZCL attribute report 0x84FD27FFFECE99DC for cluster: 0x0B04, ep: 0x01, frame control: 0x18, mfcode: 0x0000 
13:37:54:829 ZCL attribute report 0x00158D00058A29AD for cluster: 0x0402, ep: 0x01, frame control: 0x18, mfcode: 0x0000 
13:37:54:843 ZCL attribute report 0x00158D00058A29AD for cluster: 0x0405, ep: 0x01, frame control: 0x18, mfcode: 0x0000 
13:37:54:848 ZCL attribute report 0x00158D00058A29AD for cluster: 0x0403, ep: 0x01, frame control: 0x18, mfcode: 0x0000 
13:37:54:868 DEV found DDF for 0x00158D000520E7C9, path: 
13:37:55:099 Skip idle timer callback, too early: elapsed 282 msec
13:37:55:818 DEV found DDF for 0x00158D000520A838, path: 
13:37:56:768 DEV found DDF for 0x00158D000530371F, path: 
13:37:58:058 ZCL attribute report 0x84FD27FFFECE99DC for cluster: 0x0B04, ep: 0x01, frame control: 0x18, mfcode: 0x0000 
13:37:58:746 ZCL attribute report 0x04CF8CDF3C7D1330 for cluster: 0x0400, ep: 0x01, frame control: 0x18, mfcode: 0x0000 
13:37:58:748 Skip idle timer callback, too early: elapsed 687 msec
13:37:58:760 DEV found DDF for 0x00158D000520AB43, path: 
13:37:59:325 ZCL attribute report 0x84FD27FFFED245B2 for cluster: 0x0B04, ep: 0x01, frame control: 0x18, mfcode: 0x0000 
13:37:59:381 DEV found DDF for 0x00158D000520A8A7, path: 
13:38:00:101 Skip idle timer callback, too early: elapsed 773 msec
13:38:00:331 DEV found DDF for 0x00158D000520E69E, path: 
13:38:00:919 ZCL attribute report 0x84FD27FFFECE7C45 for cluster: 0x0B04, ep: 0x01, frame control: 0x18, mfcode: 0x0000 
13:38:02:572 ZCL attribute report 0x84FD27FFFECE7BEA for cluster: 0x0B04, ep: 0x01, frame control: 0x18, mfcode: 0x0000 
13:38:02:583 ZCL read attr 0x84FD27FFFECE979C, ep: 0x01, cl: 0x0006, attr: 0x0000, mfcode: 0x0000, aps.id: 198, zcl.seq: 150
13:38:02:584 ZCL attribute report 0xBC33ACFFFE2BF652 for cluster: 0x0008, ep: 0x01, frame control: 0x08, mfcode: 0x0000 
13:38:02:615 Device TTL 1137 s flags: 0x7
13:38:02:941 ZCL attribute report 0x04CF8CDF3C7D1330 for cluster: 0x0400, ep: 0x01, frame control: 0x18, mfcode: 0x0000 
13:38:03:233 ZCL attribute report 0x04CF8CDF3C7D199E for cluster: 0x0400, ep: 0x01, frame control: 0x18, mfcode: 0x0000 
13:38:03:395 ZCL read report config, ep: 0x01, cl: 0x0006, mfcode: 0x0000, aps.id: 209, zcl.seq: 151
13:38:04:717 ZCL attribute report 0x84FD27FFFECE7C45 for cluster: 0x0B04, ep: 0x01, frame control: 0x18, mfcode: 0x0000 
13:38:04:737 ZCL configure reporting ep: 0x01, cl: 0x0006, mfcode: 0x0000, aps.id: 213, zcl.seq: 152
13:38:04:807 ZCL read report config, ep: 0x01, cl: 0x0702, mfcode: 0x0000, aps.id: 215, zcl.seq: 153
13:38:04:871 ZCL read report config, ep: 0x01, cl: 0x0B04, mfcode: 0x0000, aps.id: 217, zcl.seq: 154
13:38:04:977 ZCL attribute report 0xBC33ACFFFE2BF652 for cluster: 0x0006, ep: 0x01, frame control: 0x08, mfcode: 0x0000 
13:38:05:185 ZCL read attr 0x84FD27FFFECE979C, ep: 0x01, cl: 0x0006, attr: 0x0000, mfcode: 0x0000, aps.id: 224, zcl.seq: 155
13:38:05:222 ZCL read attr 0x84FD27FFFECE979C, ep: 0x01, cl: 0x0000, attr: 0x4000, mfcode: 0x0000, aps.id: 227, zcl.seq: 156
13:38:05:667 Skip idle timer callback, too early: elapsed 948 msec
13:38:05:671 ZCL read attr 0x84FD27FFFED24544, ep: 0x01, cl: 0x0006, attr: 0x0000, mfcode: 0x0000, aps.id: 233, zcl.seq: 158
13:38:05:729 ZCL read attr 0x84FD27FFFED24544, ep: 0x01, cl: 0x0000, attr: 0x4000, mfcode: 0x0000, aps.id: 236, zcl.seq: 159
13:38:05:806 ZCL read report config, ep: 0x01, cl: 0x0006, mfcode: 0x0000, aps.id: 238, zcl.seq: 160
13:38:05:854 ZCL configure reporting ep: 0x01, cl: 0x0006, mfcode: 0x0000, aps.id: 241, zcl.seq: 161
13:38:05:893 ZCL read report config, ep: 0x01, cl: 0x0702, mfcode: 0x0000, aps.id: 243, zcl.seq: 162
13:38:05:930 ZCL read report config, ep: 0x01, cl: 0x0B04, mfcode: 0x0000, aps.id: 246, zcl.seq: 163
13:38:07:290 ZCL attribute report 0x84FD27FFFECE7C45 for cluster: 0x0B04, ep: 0x01, frame control: 0x18, mfcode: 0x0000 
13:38:07:599 Skip idle timer callback, too early: elapsed 306 msec
13:38:10:287 ZCL attribute report 0x84FD27FFFECE7C45 for cluster: 0x0B04, ep: 0x01, frame control: 0x18, mfcode: 0x0000 
13:38:11:385 ZCL attribute report 0x84FD27FFFECE7BEA for cluster: 0x0B04, ep: 0x01, frame control: 0x18, mfcode: 0x0000 
13:38:11:600 Skip idle timer callback, too early: elapsed 211 msec
13:38:12:144 ZCL attribute report 0x04CF8CDF3C7D1330 for cluster: 0x0400, ep: 0x01, frame control: 0x18, mfcode: 0x0000 
13:38:13:420 ZCL attribute report 0x84FD27FFFECE7BEA for cluster: 0x0B04, ep: 0x01, frame control: 0x18, mfcode: 0x0000 
13:38:14:567 ZCL attribute report 0x00158D000466638E for cluster: 0x0400, ep: 0x01, frame control: 0x18, mfcode: 0x0000 
13:38:14:587 ZCL attribute report 0x00158D000466638E for cluster: 0x0406, ep: 0x01, frame control: 0x18, mfcode: 0x0000 
13:38:16:292 ZCL attribute report 0x84FD27FFFECE7C45 for cluster: 0x0B04, ep: 0x01, frame control: 0x18, mfcode: 0x0000 
13:38:17:859 ZCL attribute report 0x84FD27FFFECE7BEA for cluster: 0x0B04, ep: 0x01, frame control: 0x18, mfcode: 0x0000 
13:38:18:555 [INFO] - No button map for: TS011F, unicast to: 0x0000, endpoint: 0x01, cluster: 0x0B04, command: 0x0A, payload: 0805212D01, zclSeq: 69
13:38:18:556 ZCL attribute report 0x84FD27FFFED245B2 for cluster: 0x0B04, ep: 0x01, frame control: 0x18, mfcode: 0x0000 
13:38:18:556 	payload: 0805212d01
13:38:18:561 Websocket 172.17.0.1:41940 send message: {"e":"changed","id":"277","r":"sensors","state":{"current":301,"lastupdated":"2022-01-30T13:38:17.878","power":53,"voltage":229},"t":"event","uniqueid":"84:fd:27:ff:fe:d2:45:b2-01-0b04"} (ret = 186)
13:38:21:529 [INFO] - No button map for: TS011F, unicast to: 0x0000, endpoint: 0x01, cluster: 0x0B04, command: 0x0A, payload: 080521FA000B05292800, zclSeq: 59
13:38:21:530 ZCL attribute report 0x84FD27FFFECE7C45 for cluster: 0x0B04, ep: 0x01, frame control: 0x18, mfcode: 0x0000 
13:38:21:530 	payload: 080521fa000b05292800
13:38:21:538 Websocket 172.17.0.1:41940 send message: {"e":"changed","id":"268","r":"sensors","state":{"current":250,"lastupdated":"2022-01-30T13:38:19.440","power":40,"voltage":234},"t":"event","uniqueid":"84:fd:27:ff:fe:ce:7c:45-01-0b04"} (ret = 186)
13:38:21:540 Websocket 172.17.0.1:41940 send message: {"e":"changed","id":"267","r":"sensors","state":{"consumption":20970,"lastupdated":"2022-01-30T13:38:19.874","power":40},"t":"event","uniqueid":"84:fd:27:ff:fe:ce:7c:45-01-0702"} (ret = 178)
13:38:23:127 [INFO] - No button map for: TS011F, unicast to: 0x0000, endpoint: 0x01, cluster: 0x0B04, command: 0x0A, payload: 0B05292100, zclSeq: 122
13:38:23:128 ZCL attribute report 0x84FD27FFFECE7BEA for cluster: 0x0B04, ep: 0x01, frame control: 0x18, mfcode: 0x0000 
13:38:23:128 	payload: 0b05292100
13:38:23:129 Websocket 172.17.0.1:41940 send message: {"e":"changed","id":"270","r":"sensors","state":{"current":339,"lastupdated":"2022-01-30T13:38:21.618","power":33,"voltage":232},"t":"event","uniqueid":"84:fd:27:ff:fe:ce:7b:ea-01-0b04"} (ret = 186)
13:38:23:130 Websocket 172.17.0.1:41940 send message: {"e":"changed","id":"269","r":"sensors","state":{"consumption":23980,"lastupdated":"2022-01-30T13:38:22.742","power":33},"t":"event","uniqueid":"84:fd:27:ff:fe:ce:7b:ea-01-0702"} (ret = 178)
13:38:23:133 Daylight now: solarNoon, status: 170, daylight: 1, dark: 0
13:38:24:740 [INFO] - No button map for: TS011F, unicast to: 0x0000, endpoint: 0x01, cluster: 0x0B04, command: 0x0A, payload: 0B05293100, zclSeq: 70
13:38:24:740 ZCL attribute report 0x84FD27FFFED245B2 for cluster: 0x0B04, ep: 0x01, frame control: 0x18, mfcode: 0x0000 
13:38:24:741 	payload: 0b05293100
13:38:25:940 [INFO] - No button map for: TS011F, unicast to: 0x0000, endpoint: 0x01, cluster: 0x0B04, command: 0x0A, payload: 050521EA000B05292A00, zclSeq: 60
13:38:25:941 ZCL attribute report 0x84FD27FFFECE7C45 for cluster: 0x0B04, ep: 0x01, frame control: 0x18, mfcode: 0x0000 
13:38:25:941 	payload: 050521ea000b05292a00
13:38:25:942 Websocket 172.17.0.1:41940 send message: {"e":"changed","id":"277","r":"sensors","state":{"current":301,"lastupdated":"2022-01-30T13:38:23.149","power":49,"voltage":229},"t":"event","uniqueid":"84:fd:27:ff:fe:d2:45:b2-01-0b04"} (ret = 186)
13:38:25:943 Websocket 172.17.0.1:41940 send message: {"e":"changed","id":"276","r":"sensors","state":{"consumption":17360,"lastupdated":"2022-01-30T13:38:24.299","power":49},"t":"event","uniqueid":"84:fd:27:ff:fe:d2:45:b2-01-0702"} (ret = 178)
13:38:25:945 Websocket 172.17.0.1:41940 send message: {"e":"changed","id":"268","r":"sensors","state":{"current":250,"lastupdated":"2022-01-30T13:38:25.670","power":42,"voltage":234},"t":"event","uniqueid":"84:fd:27:ff:fe:ce:7c:45-01-0b04"} (ret = 186)
13:38:25:947 Websocket 172.17.0.1:41940 send message: {"e":"changed","id":"267","r":"sensors","state":{"consumption":20970,"lastupdated":"2022-01-30T13:38:25.672","power":42},"t":"event","uniqueid":"84:fd:27:ff:fe:ce:7c:45-01-0702"} (ret = 178)
13:38:26:400 [INFO] - No button map for: lumi.sen_ill.mgl01, unicast to: 0x0000, endpoint: 0x01, cluster: 0x0400, command: 0x0A, payload: 000021986D, zclSeq: 87
13:38:26:401 ZCL attribute report 0x04CF8CDF3C7D1330 for cluster: 0x0400, ep: 0x01, frame control: 0x18, mfcode: 0x0000 
13:38:26:402 	payload: 000021986d
13:38:26:402 Websocket 172.17.0.1:41940 send message: {"e":"changed","id":"260","r":"sensors","state":{"dark":false,"daylight":true,"lastupdated":"2022-01-30T13:38:26.073","lightlevel":28056,"lux":639},"t":"event","uniqueid":"04:cf:8c:df:3c:7d:13:30-01-0400"} (ret = 205)
13:38:30:383 [INFO] - No button map for: TS011F, unicast to: 0x0000, endpoint: 0x01, cluster: 0x0B04, command: 0x0A, payload: 0B05292800, zclSeq: 61
13:38:30:383 ZCL attribute report 0x84FD27FFFECE7C45 for cluster: 0x0B04, ep: 0x01, frame control: 0x18, mfcode: 0x0000 
13:38:30:384 	payload: 0b05292800
13:38:30:394 [INFO] - No button map for: TS011F, unicast to: 0x0000, endpoint: 0x01, cluster: 0x0B04, command: 0x0A, payload: 0B05292100, zclSeq: 125
13:38:30:395 ZCL attribute report 0x84FD27FFFECE7BEA for cluster: 0x0B04, ep: 0x01, frame control: 0x18, mfcode: 0x0000 
13:38:30:396 	payload: 0b05292100
13:38:30:396 Websocket 172.17.0.1:41940 send message: {"e":"changed","id":"268","r":"sensors","state":{"current":250,"lastupdated":"2022-01-30T13:38:26.430","power":40,"voltage":234},"t":"event","uniqueid":"84:fd:27:ff:fe:ce:7c:45-01-0b04"} (ret = 186)
13:38:30:398 Websocket 172.17.0.1:41940 send message: {"e":"changed","id":"267","r":"sensors","state":{"consumption":20970,"lastupdated":"2022-01-30T13:38:28.298","power":40},"t":"event","uniqueid":"84:fd:27:ff:fe:ce:7c:45-01-0702"} (ret = 178)
13:38:30:399 Websocket 172.17.0.1:41940 send message: {"e":"changed","id":"270","r":"sensors","state":{"current":339,"lastupdated":"2022-01-30T13:38:30.392","power":33,"voltage":232},"t":"event","uniqueid":"84:fd:27:ff:fe:ce:7b:ea-01-0b04"} (ret = 186)
13:38:30:400 Websocket 172.17.0.1:41940 send message: {"e":"changed","id":"269","r":"sensors","state":{"consumption":23980,"lastupdated":"2022-01-30T13:38:30.393","power":33},"t":"event","uniqueid":"84:fd:27:ff:fe:ce:7b:ea-01-0702"} (ret = 178)
13:38:30:401 poll node 5c:02:72:ff:fe:74:16:51-01
13:38:30:402 Poll light node Keuken Spot 1
13:38:30:404 Idle timer triggered
13:38:30:405 Force read attributes for ZHAConsumption SensorNode Consumption 161
13:38:30:405 Force binding of attribute reporting for node Consumption 161
13:38:30:491 Node data 0x588e81fffed38ebc profileId: 0x0104, clusterId: 0x0702
13:38:30:493 0x588E81FFFED38EBC: update ZCL value 0x01/0x0702/0x0000 after 0 s
13:38:30:494 [INFO] - No button map for: TS0121, unicast to: 0x0000, endpoint: 0x01, cluster: 0x0702, command: 0x0A, payload: 000025130100000000, zclSeq: 57
13:38:30:495 ZCL attribute report 0x588E81FFFED38EBC for cluster: 0x0702, ep: 0x01, frame control: 0x08, mfcode: 0x0000 
13:38:30:495 	payload: 000025130100000000
13:38:30:496 binding for attribute reporting of ep: 0x01 cluster 0x0702 seems to be active
13:38:30:496 0x588E81FFFED38EBC (TS0121) create binding for attribute reporting of cluster 0x0B04 on endpoint 0x01
13:38:30:496 queue binding task for 0x588E81FFFED38EBC, cluster 0x0B04
13:38:30:498 Websocket 172.17.0.1:41940 send message: {"e":"changed","id":"163","r":"sensors","state":{"consumption":2750,"lastupdated":"2022-01-30T13:38:30.493"},"t":"event","uniqueid":"58:8e:81:ff:fe:d3:8e:bc-01-0702"} (ret = 166)
13:38:30:499 ZCL read attr 0x84FD27FFFECE7C45, ep: 0x01, cl: 0x0006, attr: 0x0000, mfcode: 0x0000, aps.id: 60, zcl.seq: 168
13:38:30:500 Poll APS request to 0x5C0272FFFE741651 cluster: 0x0006 dropped, values are fresh enough
13:38:31:780 [INFO] - No button map for: TS011F, unicast to: 0x0000, endpoint: 0x01, cluster: 0x0B04, command: 0x0A, payload: 050521E900, zclSeq: 62
13:38:31:780 ZCL attribute report 0x84FD27FFFECE7C45 for cluster: 0x0B04, ep: 0x01, frame control: 0x18, mfcode: 0x0000 
13:38:31:781 	payload: 050521e900
13:38:31:782 Websocket 172.17.0.1:41940 send message: {"e":"changed","id":"268","r":"sensors","state":{"current":250,"lastupdated":"2022-01-30T13:38:30.516","power":40,"voltage":233},"t":"event","uniqueid":"84:fd:27:ff:fe:ce:7c:45-01-0b04"} (ret = 186)
13:38:35:414 [INFO] - No button map for: TS011F, unicast to: 0x0000, endpoint: 0x01, cluster: 0x0B04, command: 0x0A, payload: 080521FE00, zclSeq: 63
13:38:35:415 ZCL attribute report 0x84FD27FFFECE7C45 for cluster: 0x0B04, ep: 0x01, frame control: 0x18, mfcode: 0x0000 
13:38:35:415 	payload: 080521fe00
13:38:49:060 [INFO] - No button map for: TS011F, unicast to: 0x0000, endpoint: 0x01, cluster: 0x0B04, command: 0x0A, payload: 0B05292D00, zclSeq: 126
13:38:49:060 ZCL attribute report 0x84FD27FFFECE7BEA for cluster: 0x0B04, ep: 0x01, frame control: 0x18, mfcode: 0x0000 
13:38:49:061 	payload: 0b05292d00
13:38:49:062 Websocket 172.17.0.1:41940 send message: {"e":"changed","id":"268","r":"sensors","state":{"current":254,"lastupdated":"2022-01-30T13:38:31.811","power":40,"voltage":233},"t":"event","uniqueid":"84:fd:27:ff:fe:ce:7c:45-01-0b04"} (ret = 186)
13:38:49:063 Websocket 172.17.0.1:41940 send message: {"e":"changed","id":"270","r":"sensors","state":{"current":339,"lastupdated":"2022-01-30T13:38:35.444","power":45,"voltage":232},"t":"event","uniqueid":"84:fd:27:ff:fe:ce:7b:ea-01-0b04"} (ret = 186)
13:38:49:064 Websocket 172.17.0.1:41940 send message: {"attr":{"id":"269","lastannounced":null,"lastseen":"2022-01-30T13:38Z","manufacturername":"_TZ3000_mraovvmm","modelid":"TS011F","name":"Consumption 269","swversion":null,"type":"ZHAConsumption","uniqueid":"84:fd:27:ff:fe:ce:7b:ea-01-0702"},"e":"changed","id":"269","r":"sensors","t":"event","uniqueid":"84:fd:27:ff:fe:ce:7b:ea-01-0702"} (ret = 337)
13:38:49:066 Websocket 172.17.0.1:41940 send message: {"e":"changed","id":"269","r":"sensors","state":{"consumption":23980,"lastupdated":"2022-01-30T13:38:47.286","power":45},"t":"event","uniqueid":"84:fd:27:ff:fe:ce:7b:ea-01-0702"} (ret = 178)
13:38:49:067 ZCL read attr 0x84FD27FFFECE7BEA, ep: 0x01, cl: 0x0006, attr: 0x0000, mfcode: 0x0000, aps.id: 66, zcl.seq: 169
13:38:49:071 Daylight now: solarNoon, status: 170, daylight: 1, dark: 0
13:38:49:098 ZCL attribute report 0x84FD27FFFECE979C for cluster: 0x0B04, ep: 0x01, frame control: 0x18, mfcode: 0x0000 
13:38:49:098 	payload: 08052100000b05290000
13:38:49:109 Websocket 172.17.0.1:41940 send message: {"attr":{"id":"49","lastannounced":"2022-01-16T15:16:09Z","lastseen":"2022-01-30T13:38Z","manufacturername":"_TZ3000_mraovvmm","modelid":"TS011F","name":"Bed","swversion":"67","type":"On/Off plug-in unit","uniqueid":"84:fd:27:ff:fe:ce:97:9c-01"},"e":"changed","id":"49","r":"lights","t":"event","uniqueid":"84:fd:27:ff:fe:ce:97:9c-01"} (ret = 335)
13:38:50:731 [INFO] - No button map for: TS011F, unicast to: 0x0000, endpoint: 0x01, cluster: 0x0B04, command: 0x0A, payload: 050521EA00, zclSeq: 64
13:38:50:731 ZCL attribute report 0x84FD27FFFECE7C45 for cluster: 0x0B04, ep: 0x01, frame control: 0x18, mfcode: 0x0000 
13:38:50:732 	payload: 050521ea00
13:38:52:180 ZCL attribute report 0x84FD27FFFED24544 for cluster: 0x0702, ep: 0x01, frame control: 0x18, mfcode: 0x0000 
13:38:52:180 	payload: 000025830300000000
13:38:52:181 Websocket 172.17.0.1:41940 send message: {"attr":{"id":"162","lastannounced":"2022-01-16T15:16:09Z","lastseen":"2022-01-30T13:38Z","manufacturername":"_TZ3000_mraovvmm","modelid":"TS011F","name":"Power 162","swversion":null,"type":"ZHAPower","uniqueid":"84:fd:27:ff:fe:ce:97:9c-ff-0b04"},"e":"changed","id":"162","r":"sensors","t":"event","uniqueid":"84:fd:27:ff:fe:ce:97:9c-ff-0b04"} (ret = 343)
13:38:52:183 Websocket 172.17.0.1:41940 send message: {"e":"changed","id":"162","r":"sensors","state":{"current":0,"lastupdated":"2022-01-16T13:21:15.750","power":0,"voltage":227},"t":"event","uniqueid":"84:fd:27:ff:fe:ce:97:9c-ff-0b04"} (ret = 183)
13:38:52:185 Websocket 172.17.0.1:41940 send message: {"attr":{"id":"161","lastannounced":"2022-01-16T15:16:09Z","lastseen":"2022-01-30T13:38Z","manufacturername":"_TZ3000_mraovvmm","modelid":"TS011F","name":"Consumption 161","swversion":null,"type":"ZHAConsumption","uniqueid":"84:fd:27:ff:fe:ce:97:9c-ff-0702"},"e":"changed","id":"161","r":"sensors","t":"event","uniqueid":"84:fd:27:ff:fe:ce:97:9c-ff-0702"} (ret = 355)
13:38:52:186 ZCL read attr 0x84FD27FFFED245B2, ep: 0x01, cl: 0x0006, attr: 0x0000, mfcode: 0x0000, aps.id: 72, zcl.seq: 170
13:38:52:187 Websocket 172.17.0.1:41940 send message: {"attr":{"id":"14","lastannounced":"2022-01-15T19:30:01Z","lastseen":"2022-01-30T13:38Z","manufacturername":"_TZ3000_mraovvmm","modelid":"TS011F","name":"PC JH","swversion":"67","type":"On/Off plug-in unit","uniqueid":"84:fd:27:ff:fe:ce:7c:45-01"},"e":"changed","id":"14","r":"lights","t":"event","uniqueid":"84:fd:27:ff:fe:ce:7c:45-01"} (ret = 337)
13:38:52:188 Websocket 172.17.0.1:41940 send message: {"attr":{"id":"268","lastannounced":"2022-01-15T19:30:01Z","lastseen":"2022-01-30T13:38Z","manufacturername":"_TZ3000_mraovvmm","modelid":"TS011F","name":"Power 268","swversion":null,"type":"ZHAPower","uniqueid":"84:fd:27:ff:fe:ce:7c:45-01-0b04"},"e":"changed","id":"268","r":"sensors","t":"event","uniqueid":"84:fd:27:ff:fe:ce:7c:45-01-0b04"} (ret = 343)
13:38:52:189 Websocket 172.17.0.1:41940 send message: {"e":"changed","id":"268","r":"sensors","state":{"current":254,"lastupdated":"2022-01-30T13:38:49.177","power":40,"voltage":234},"t":"event","uniqueid":"84:fd:27:ff:fe:ce:7c:45-01-0b04"} (ret = 186)
13:38:52:221 Websocket 172.17.0.1:41940 send message: {"attr":{"id":"267","lastannounced":"2022-01-15T19:30:01Z","lastseen":"2022-01-30T13:38Z","manufacturername":"_TZ3000_mraovvmm","modelid":"TS011F","name":"Consumption 267","swversion":null,"type":"ZHAConsumption","uniqueid":"84:fd:27:ff:fe:ce:7c:45-01-0702"},"e":"changed","id":"267","r":"sensors","t":"event","uniqueid":"84:fd:27:ff:fe:ce:7c:45-01-0702"} (ret = 355)
13:38:52:222 Websocket 172.17.0.1:41940 send message: {"attr":{"id":"4","lastannounced":"2022-01-17T18:07:24Z","lastseen":"2022-01-30T13:38Z","manufacturername":"_TZ3000_mraovvmm","modelid":"TS011F","name":"Lamp Woonkamer 1","swversion":"67","type":"On/Off plug-in unit","uniqueid":"84:fd:27:ff:fe:d2:45:44-01"},"e":"changed","id":"4","r":"lights","t":"event","uniqueid":"84:fd:27:ff:fe:d2:45:44-01"} (ret = 346)
13:38:52:229 Websocket 172.17.0.1:41940 send message: {"attr":{"id":"171","lastannounced":"2022-01-17T18:07:24Z","lastseen":"2022-01-30T13:38Z","manufacturername":"_TZ3000_mraovvmm","modelid":"TS011F","name":"Power 171","swversion":null,"type":"ZHAPower","uniqueid":"84:fd:27:ff:fe:d2:45:44-ff-0b04"},"e":"changed","id":"171","r":"sensors","t":"event","uniqueid":"84:fd:27:ff:fe:d2:45:44-ff-0b04"} (ret = 343)
13:38:52:230 Websocket 172.17.0.1:41940 send message: {"attr":{"id":"170","lastannounced":"2022-01-17T18:07:24Z","lastseen":"2022-01-30T13:38Z","manufacturername":"_TZ3000_mraovvmm","modelid":"TS011F","name":"Consumption 170","swversion":null,"type":"ZHAConsumption","uniqueid":"84:fd:27:ff:fe:d2:45:44-ff-0702"},"e":"changed","id":"170","r":"sensors","t":"event","uniqueid":"84:fd:27:ff:fe:d2:45:44-ff-0702"} (ret = 355)
13:38:57:997 [INFO] - No button map for: TS011F, unicast to: 0x0000, endpoint: 0x01, cluster: 0x0B04, command: 0x0A, payload: 0B05293300, zclSeq: 75
13:38:57:998 ZCL attribute report 0x84FD27FFFED245B2 for cluster: 0x0B04, ep: 0x01, frame control: 0x18, mfcode: 0x0000 
13:38:57:999 	payload: 0b05293300
13:38:57:999 Websocket 172.17.0.1:41940 send message: {"e":"changed","id":"170","r":"sensors","state":{"consumption":766,"lastupdated":"2022-01-16T13:21:00.948"},"t":"event","uniqueid":"84:fd:27:ff:fe:d2:45:44-ff-0702"} (ret = 165)
13:38:58:001 ZCL read attr 0x84FD27FFFECE7C45, ep: 0x01, cl: 0x0006, attr: 0x0000, mfcode: 0x0000, aps.id: 76, zcl.seq: 171
13:38:58:002 Websocket 172.17.0.1:41940 send message: {"attr":{"id":"19","lastannounced":"2022-01-17T19:21:03Z","lastseen":"2022-01-30T13:38Z","manufacturername":"_TZ3000_mraovvmm","modelid":"TS011F","name":"PC Dasha","swversion":"67","type":"On/Off plug-in unit","uniqueid":"84:fd:27:ff:fe:d2:45:b2-01"},"e":"changed","id":"19","r":"lights","t":"event","uniqueid":"84:fd:27:ff:fe:d2:45:b2-01"} (ret = 340)
13:38:58:003 Websocket 172.17.0.1:41940 send message: {"attr":{"id":"277","lastannounced":"2022-01-17T19:21:03Z","lastseen":"2022-01-30T13:38Z","manufacturername":"_TZ3000_mraovvmm","modelid":"TS011F","name":"Power 277","swversion":null,"type":"ZHAPower","uniqueid":"84:fd:27:ff:fe:d2:45:b2-01-0b04"},"e":"changed","id":"277","r":"sensors","t":"event","uniqueid":"84:fd:27:ff:fe:d2:45:b2-01-0b04"} (ret = 343)
13:38:58:004 Websocket 172.17.0.1:41940 send message: {"e":"changed","id":"277","r":"sensors","state":{"current":301,"lastupdated":"2022-01-30T13:38:52.313","power":51,"voltage":229},"t":"event","uniqueid":"84:fd:27:ff:fe:d2:45:b2-01-0b04"} (ret = 186)
13:38:58:006 Websocket 172.17.0.1:41940 send message: {"attr":{"id":"276","lastannounced":"2022-01-17T19:21:03Z","lastseen":"2022-01-30T13:38Z","manufacturername":"_TZ3000_mraovvmm","modelid":"TS011F","name":"Consumption 276","swversion":null,"type":"ZHAConsumption","uniqueid":"84:fd:27:ff:fe:d2:45:b2-01-0702"},"e":"changed","id":"276","r":"sensors","t":"event","uniqueid":"84:fd:27:ff:fe:d2:45:b2-01-0702"} (ret = 355)
13:38:58:007 Websocket 172.17.0.1:41940 send message: {"e":"changed","id":"276","r":"sensors","state":{"consumption":17360,"lastupdated":"2022-01-30T13:38:55.940","power":51},"t":"event","uniqueid":"84:fd:27:ff:fe:d2:45:b2-01-0702"} (ret = 178)
13:38:58:008 ZCL read attr 0x84FD27FFFECE99DC, ep: 0x01, cl: 0x0006, attr: 0x0000, mfcode: 0x0000, aps.id: 77, zcl.seq: 172
13:38:58:011 DB save zll database items 0x00000081
13:38:58:012 DB sql exec REPLACE INTO nodes (id, state, mac, name, groups, endpoint, modelid, manufacturername, swbuildid, ritems) VALUES ('14', 'normal', '84:fd:27:ff:fe:ce:7c:45-01', 'PC JH', '65520', '1', 'TS011F', '_TZ3000_mraovvmm', '67', '{"attr/id":"14","attr/lastannounced":"2022-01-15T19:30:01Z","attr/lastseen":"2022-01-30T13:38Z","attr/manufacturername":"_TZ3000_mraovvmm","attr/modelid":"TS011F","attr/name":"PC JH","attr/swversion":"67","attr/type":"On/Off plug-in unit","attr/uniqueid":"84:fd:27:ff:fe:ce:7c:45-01","state/alert":"none","state/on":true,"state/reachable":true}')
13:38:58:013 DB sql exec REPLACE INTO nodes (id, state, mac, name, groups, endpoint, modelid, manufacturername, swbuildid, ritems) VALUES ('24', 'normal', 'bc:33:ac:ff:fe:2b:f6:52-01', 'Keuken Spot 2', '65520,16', '1', 'TRADFRI bulb GU10 WW 400lm', 'IKEA of Sweden', '2.1.022', '{"attr/id":"24","attr/lastannounced":"2022-01-30T07:37:56Z","attr/lastseen":"2022-01-30T13:38Z","attr/manufacturername":"IKEA of Sweden","attr/modelid":"TRADFRI bulb GU10 WW 400lm","attr/name":"Keuken Spot 2","attr/swversion":"2.1.022","attr/type":"Dimmable light","attr/uniqueid":"bc:33:ac:ff:fe:2b:f6:52-01","state/alert":"none","state/bri":254,"state/on":false,"state/reachable":true}')
13:38:58:014 DB sql exec REPLACE INTO nodes (id, state, mac, name, groups, endpoint, modelid, manufacturername, swbuildid, ritems) VALUES ('28', 'normal', '00:15:8d:00:05:20:f4:43-01', 'Lamp JH', '65520,11', '1', 'lumi.light.aqcn02', 'LUMI', '11-22-2018', '{"attr/id":"28","attr/lastannounced":"2022-01-21T06:04:18Z","attr/lastseen":"2022-01-30T13:38Z","attr/manufacturername":"LUMI","attr/modelid":"lumi.light.aqcn02","attr/name":"Lamp JH","attr/swversion":"11-22-2018","attr/type":"Color temperature light","attr/uniqueid":"00:15:8d:00:05:20:f4:43-01","config/colorcapabilities":16,"config/ctmax":65279,"config/ctmin":null,"state/alert":"none","state/bri":null,"state/colormode":"ct","state/ct":327,"state/on":false,"state/reachable":true}')
13:38:58:016 DB sql exec REPLACE INTO nodes (id, state, mac, name, groups, endpoint, modelid, manufacturername, swbuildid, ritems) VALUES ('49', 'normal', '84:fd:27:ff:fe:ce:97:9c-01', 'Bed', '65520', '1', 'TS011F', '_TZ3000_mraovvmm', '67', '{"attr/id":"49","attr/lastannounced":"2022-01-16T15:16:09Z","attr/lastseen":"2022-01-30T13:38Z","attr/manufacturername":"_TZ3000_mraovvmm","attr/modelid":"TS011F","attr/name":"Bed","attr/swversion":"67","attr/type":"On/Off plug-in unit","attr/uniqueid":"84:fd:27:ff:fe:ce:97:9c-01","state/alert":"none","state/on":false,"state/reachable":true}')
13:38:58:017 DB sql exec REPLACE INTO nodes (id, state, mac, name, groups, endpoint, modelid, manufacturername, swbuildid, ritems) VALUES ('19', 'normal', '84:fd:27:ff:fe:d2:45:b2-01', 'PC Dasha', '65520', '1', 'TS011F', '_TZ3000_mraovvmm', '67', '{"attr/id":"19","attr/lastannounced":"2022-01-

iisworks · February 6, 2022, 5:50pm

Some more hours of testing today, and eventualy with a custom DDF I can get the plugs reporting in Deconz. But somehow these updates do not make it to the api.

I did find out one thing though: “Manufacturer name” is really ignored when you pair any of the TS011F series. So any of these will use the built-in DDF (/usr/share/deCONZ/devices/neo/NAS-WR01B.json):

Tested with:
_TZ3000_mraovvmm (BW-SHP15)
_TZ3000_w0qqde0g (Compact orange plug , Updated 74 FW)
_TZ3000_gjnozsaz (Compact orange plug - New model, Updated 74 FW)

I tried creating 3 separate DDF files with a different manufacturer, but only the first one was selected and used for all plugs. I wonder if that is expected bahavior?

Does anyone have a 100% working example of a TS011F DDF file (reporting and correctly updating in the api)?

Smanar · February 6, 2022, 7:04pm

Are you sure of that ? It’s visible on log, you have something like
``DBG_Printf(DBG_INFO, “DEV found DDF for 0x%016llX, path: %s\n”, event.deviceKey(), qPrintable(ddf.path));

With “info” flag.

Or you are making test with the “edit node” command on right clic on the node ?

iisworks · February 6, 2022, 7:18pm

I don’t have a copy of the log right now, but I am 99% sure I saw “DEV found DDF for …” with only one DDF file for all 3 types of plugs!

[Update] I removed all SHP15 this afternoon, but I found 2 examples of different manufacturer codes:
_TZ3000_w0qqde0g:
19:16:46:794 DEV found DDF for 0xA4C138078C31329F, path: /opt/deCONZ/devices/TS011F.json

_TZ3000_gjnozsaz:
19:16:46:807 DEV found DDF for 0xA4C138B388AA7353, path: /opt/deCONZ/devices/TS011F.json

Swoop · February 6, 2022, 10:54pm

From my perspective, I’d acknowledge this as a bug.

tldr:
I did some tests today, as I was always wondering why I haven’t seen any queries of the manufacturer name in the sniffer logs over the weeks. Long story short: if deconz knows about it (has been previously read or it is already part of a sensor/light, it apparently reuses it). Pretty much all devices I played with in terms of DDF, I had previously paired as well (so there were already lights/sensors) and so this would explain the missing query.

Now to the point I want to make: the device I made the tests with today had the manufacturer name hardcoded and bound to be set on the manufacturer code. I then remove the respective code passages, removed all remnants of the device inside the DB and did a fresh pair. The DDF was chosen, before the manufacturer name was known. Furthermore, the manufacturer name was automatically queried, but only 1 minute after the device has been successfully paired.

Next test to make would be to create 2 fake DDFs with random manufacturer names, name the files so that the correct one is ordered in the middle and re-pair. I’d expect to see the very same behavior as described above.

However, I’d say this can be resolved by reading the basic cluster attributes of all affected devices, wait like 5 mins and then restart deconz. Reading the attributes should in principle set the manufacturer name straight to allow deconz to chose the correct file at next load.

Swoop · February 6, 2022, 11:19pm

Et voilà: The fake file “alumi.plug.mmeu01” was chosen, containing the manufacturer name “RANDOM”.

The manufacturer name was actually read at 23:59:59 (checked with running sniffer) and correctly updated roughly 1 min later for the device

Interestingly, the assumped resolution did not stand to be correct, the wrong DDF is still used after deconz restart.

iisworks · February 7, 2022, 6:19am

Thanks for the update! Could this somehow explain my deconz slowless issues? Because I think all my plugs should/could use the same DDF? By now things look a bit better performance wise though, since I removed the SHP15 plugs though. My remaining issue now is that I have no working DDF which correctly includes the sensors in the api, I tried for hours to change settings in the DDF by trial & error but nothing worked reliably so far.

How does this work for similar devices with different Manufacturer Names (I guess Tuya is notorious for that) that could use the same DDF config, for example Tuya TS011F Reporting or Polling Plugs? Problem with them is that a combination of manufacturername + FW determines if they are Reporting or Polling. For example SHP15 (_TZ3000_mraovvmm) with latest FW has no reporting any more, older ones did, with _TZ3000_w0qqde0g the other way around. I know for example zigbee2mqtt has several configs for TS011F + FW level (polling/reporting): https://github.com/Koenkk/zigbee2mqtt
Is it possible to use 1 DDF for multiple manufacturername + FW levels, or an attempt to fallback on modelid when no manufacturername was found?
Does “path” actually matter?
“manufacturername”: “_TZ3000_xxxxxxxx”,
“modelid”: “TS011F”,
“path”: “/devices/TS011F.json”,
Is there a working sample for Tuya reporting plugssomewhere?

[Update] These is still an issue with my plugs in combination with DDF, some kind of memory leak (normally around 200MB):

Not sure if it’s somehow related to the same issue, but I’ll restore a backup without the new plugs that require DDF…
Note: Apparently the BW-SHP15’s also already use NEO DDF after the restore (without any issues):
DEV found DDF for 0x84FD27FFFECE7BEA, path: /usr/share/deCONZ/devices/neo/NAS-WR01B.json

iisworks · February 8, 2022, 10:00am

I just upgraded to 2.14.1 and re-added the new plugs again (Hybrid mode). That kind of works. I can see them updating just fine when I look at the measurement cluster - Power in vnc, but somehow the updates don’t alsays seem to be reflected in the api. Switching On/off does work fine, also in the api. I had to configure Reporting timing manually on each cluster though?

Any idea:

Does the fact that changes are visible on the cluster mean that the DDF itself is valid?
Why is the reporting (as defined in the DDF, e.g. 3-300-1) not set on plugs?
Why are changes I see on the cluster from vnc not reflected in the api?

Can someone explain what could cause this?

Mimiix · February 8, 2022, 10:27am

Great to see some progress here guys:)!

Smanar · February 8, 2022, 6:56pm

Why is the reporting (as defined in the DDF, e.g. 3-300-1) not set on plugs?

You have checked them using the GUI ? select a cluster, select an attribute, double click then “read config”

Why are changes I see on the cluster from vnc not reflected in the api?

Not sure the DDF is working for me. Perhaps it s the GUI that is not refreshed ?

iisworks · February 8, 2022, 7:10pm

Thanks, this should be configured from the DDF and not have to be set manually, right? It seems the “Reporting config” eventually got set on all plugs as configured in the DDF after I toggled Hybride mode, disconnected the plugs from power and restarted deconz and waited for things to settle a while (so not entirely sure what helped).

Now the plugs do report well to the api 95% of the time, but I still feel there is a bug + memory leak somewhere. Because as soon as I added 4 of these new Tuya plugs, deconz feels less snappy than before. Usually there is no delay at all, but now sometimes when I try to click somewhere or drag a window it seems as if the system freezes up for a few seconds. If I look at the debug window, I also see no logs being added for a bit. And exactly at that same time, the api also seems to be delayed for a few seconds (no updates in my 3rd party app).
It looks a lot better than 2.14.0 though, and it seems to at least keep running now. Memory usage on the container still seems higher than usual (now 350MB instead of normally <200MB), so I will keep an eye on it overnight.

iisworks · February 9, 2022, 6:52am

Memory usage of the docker container seemed to be still low this morning (140MB) and the plugs do respond, although sluggish.

I managed to capture L2 logging while toggling On/Off on a plug a few times. It responds with a delay, deconz seemed to freeze for 1-2s (log windows also stopped).

Hopefully that gives someting to the devs to look into?

[Update] Unfortunately when the zigbee network getws used more during the day, the extreme slowness & memory leak occurred again. Eventually deconz became unresponsive and I had to restart the container.

iisworks · February 9, 2022, 3:26pm

Small update. I ordered a separate Conbee II stick and pugged it in to my Windows 11 PC.
I then added a new _TZ3000_w0qqde0g + _TZ3000_gjnozsaz plug and this is the L2 log (no 3rd party app installed).

I don’t see the plug “Active Power” updating in the clusters with the built-in NEO DDF (pressing “Read” works)? Could someone check if this all looks normal?

[Update] When I enable “Silver”, they start reporting.
L2 logging in that case:

Smanar · February 9, 2022, 3:55pm

I don’t understand it works with “silver” ? What was your setting when it haven’t worked ?

iisworks · February 9, 2022, 4:45pm

I mean the DDF setting, it was on “Gold” before and then the cluster did not seem to update automatically. After I set it to Silver, the NEO ddf was picked u0p/applied and it started working.

Note that on the “real” live network I am having issues in Silver mode (L2 Logs in post before the previous one). Can you please check both logs to see if they look normal?

I also noticed I have a DB of 33MB now!

I just can’t get 2.14.1 stable with the new TS011F plugs.

Smanar · February 10, 2022, 5:45pm

This is normal, on the DDF (if you are uysing the same) you can see

  "status": "Silver",
  "path": "/devices/ts011f.json",

So if you set only “gold” the DDF is not used.

And I don’t see what the DDF core can write on the DB to increase the size …
You have some SQL knowledge to check the file ? I don’t know the normal size, but 33 Mb seem a lot for me, how many device you have on this network ?
Check if deconz don’t create “ghost” device.

iisworks · February 10, 2022, 6:21pm

Yeah, I just meant to indicate that there is something very wrong in my setup with about 60 devices and after I added the new plugs.

Can someone who knows what to look for please take a look at the L2 logs I pasted in the last few posts (especialy the one in the home setup Post 13)? I would really like to know if something looks wrong?

Swoop · February 10, 2022, 9:41pm

You apparently got interference issues based on the 2nd log. There’s 4 0xA7 errors and more than 20 0xE9 errors in there.

Regarding your previous questions, it should absolutely be doable to create one DDF fitting multiple devices either deviating in manufacturer name or in firware version (or both). However, this is also limited to a certain extend on identical clusters, attirbutes and resource items being used accross the devices.

Check out the DDF cheat sheet https://github.com/dresden-elektronik/deconz-rest-plugin/wiki/DDF-cheat-sheet#readwriteparse-functions

If you scroll down a little bit, there’s some insights on what you can use within JS. What you probably need would go into this direction:

if (R.item('attr/manufacturername').val === "ABC" && R.item('attr/swversion').val === "123")
{
    Item.val = Attr.val;
}
else if (R.item('attr/manufacturername').val === "XYZ" && R.item('attr/swversion').val === "789")
{
    Item.val = Attr.val / 10;
}

manup · February 11, 2022, 12:57am

I think we need more options to match a DDF to a specific firmware version, or more generic to specific item values. I’ve talked with Smanar a while ago about this there is already an idea for it.

To be frank I’m strongly against having this logic in the item handlers, as this would bring the mess we had in C++ land to DDFs Comparing strings like manufacturer name, modelid, swversion should be done once and only once to select the right DDF for a device.

iisworks · February 11, 2022, 6:24am

@Swoop Sorry for the confusion, but the 2nd set of logs is from another Conbee II stick with the same plugs, but the Conbee was plugged directly in a Win11 laptop. So maybe that’s why the interference comes from. These logs were just meant to provide some clean L2 logging of the plug DDF pairing process.

Can you please also take a look at the logs from the “production” network where the real issues are
(running 2.14.1 in Docker on my NAS, about 60 devices, no interference there, just DDF issues related to the Tuya plugs):