So even with the modified DDF you have the battery drain ?
For me it’s a poll issue (but it’s solved using the DDF for some others devices) it’s visible on deconz log in deconz/debug view with “info” and “info_l2”
Sorry took me a little while to get back.
I’m not sure how to check if the new DDF actually works, but here is what I did:
created new File: tz3000_4gang.json in /home/pi/.local/share/dresden-elektronik/deCONZ/devices
(using the Raspberry PI Image from dresden-elektronik).
For the File contents, used the linked github, added the _TZ3000_wkai4ga5 device under “manufacturername”.
Could anyone confirm me if I’m on the right track + how exactly I can check if the file is being used?
Battery shows 0% on a fresh battery in Home Assistant, but Idk. if that ever worked.
Actually it just killed a fresh CR2025 - checking with smaller batteries to test. Within an hour… So I think something changed, but not for better.
Yes
There is very much output when Info_I2 is activated. Are I can’t copy the output, I look with VNC in the App. What is the best solution to filter.
What I see the light in the switch are flashing all couple of minutes. And the Indikator in the App flashes all couple of Minutes blue, green and red.
Some exemple of spam you can found
Visible with flag “ZCL”
18:54:27:088 ZCL read report config, ep: 0x05, cl: 0x0102, mfcode: 0x0000, aps.id: 196, zcl.seq: 205
18:54:29:047 ZCL read report config, ep: 0x05, cl: 0x0102, mfcode: 0x0000, aps.id: 213, zcl.seq: 208
18:54:31:056 ZCL read report config, ep: 0x05, cl: 0x0102, mfcode: 0x0000, aps.id: 229, zcl.seq: 210
18:54:27:013 ZCL read attr 0xD0CF5EFFFE47429B, ep: 0x01, cl: 0x0102, attr: 0x0008, mfcode: 0x0000, aps.id: 193, zcl.seq: 20
18:54:29:025 ZCL read attr 0xD0CF5EFFFE47429B, ep: 0x01, cl: 0x0102, attr: 0x0008, mfcode: 0x0000, aps.id: 211, zcl.seq: 207
18:54:31:056 ZCL read attr 0xD0CF5EFFFE47429B, ep: 0x01, cl: 0x0102, attr: 0x0008, mfcode: 0x0000, aps.id: 230, zcl.seq: 211
Visible with flag “info_l2”
18:54:22:009 Force read attributes for ZHASwitch SensorNode Switch 5
With “ZCL” you can found too bind spam.
Having this kind of line is normal, can happen if deconz try without success to configure something, but on sensor that are realy lazy, not normal having them every 2 minutes.
As “filter” just try to see the device MAC adress, it’s lazy device that make few zigbee request, if you see one that happen every 2 mn, it’s suspect.
Do you mean lines like that?
10:15:49:794 ZCL read attr 0xCC86ECFFFE9A5457, ep: 0x01, cl: 0x0000, attr: 0x0001, mfcode: 0x0000, aps.id: 112, zcl.seq: 95
10:18:49:226 ZCL read attr 0xCC86ECFFFE9A5457, ep: 0x01, cl: 0x0000, attr: 0x0001, mfcode: 0x0000, aps.id: 177, zcl.seq: 125
10:21:48:675 ZCL read attr 0xCC86ECFFFE9A5457, ep: 0x01, cl: 0x0000, attr: 0x0001, mfcode: 0x0000, aps.id: 1, zcl.seq: 146
10:21:52:163 ZCL read attr 0xCC86ECFFFE9A5457, ep: 0x01, cl: 0x0000, attr: 0x0001, mfcode: 0x0000, aps.id: 19, zcl.seq: 147
10:24:48:109 ZCL read attr 0xCC86ECFFFE9A5457, ep: 0x01, cl: 0x0000, attr: 0x0001, mfcode: 0x0000, aps.id: 26, zcl.seq: 152
10:30:46:970 DeviceAnnce of SensorNode: 0xCC86ECFFFE9A5457 [1]
10:33:46:396 DeviceAnnce of SensorNode: 0xCC86ECFFFE9A5457 [1]
10:36:45:901 DeviceAnnce of SensorNode: 0xCC86ECFFFE9A5457 [1]
@Smanar
Could you please let me know how I can check the output as you posted?
Visible with flag “ZCL”
18:54:27:088 ZCL read report config, ep: 0x05, cl: 0x0102, mfcode: 0x0000, aps.id: 196, zcl.seq: 205
18:54:29:047 ZCL read report config, ep: 0x05, cl: 0x0102, mfcode: 0x0000, aps.id: 213, zcl.seq: 208
18:54:31:056 ZCL read report config, ep: 0x05, cl: 0x0102, mfcode: 0x0000, aps.id: 229, zcl.seq: 210
Thanks.
I don’t have such ZCL messages:
pi@phoscon:~ $ /usr/bin/deCONZ -platform minimal --dbg-aps=2 --dbg-info=2 --dbg-error=2 | grep ZCL
libpng warning: iCCP: known incorrect sRGB profile
This plugin does not support propagateSizeHints()
This plugin does not support propagateSizeHints()
18:12:16:449 ZCLDB init file /home/pi/.local/share/dresden-elektronik/deCONZ/zcldb.txt
This plugin does not support propagateSizeHints()
18:20:21:751 0x680AE2FFFE8DE86E: added ZCL value 0x01/0x0001/0x0021
18:20:21:751 ZCL attribute report 0x680AE2FFFE8DE86E for cluster: 0x0001, ep: 0x01, frame control: 0x08, mfcode: 0x0000
18:31:17:420 0x70AC08FFFE6FD65F: added ZCL value 0x04/0x0001/0x0021
18:31:18:720 0x70AC08FFFE6FD65F: added ZCL value 0x02/0x0001/0x0021
18:31:19:831 ZCL configure reporting rsp seq: 136 0x70AC08FFFE6FD65F for ep: 0x04 cluster: 0x0001 attr: 0x0021 status: 0x00
18:31:21:860 0x70AC08FFFE6FD65F: added ZCL value 0x01/0x0001/0x0021
18:38:16:401 0x70AC08FFFE6FD65F: added ZCL value 0x03/0x0001/0x0021
18:39:01:440 0x70AC08FFFE77F178: added ZCL value 0x01/0x0001/0x0021
18:39:02:110 ZCL configure reporting rsp seq: 140 0x70AC08FFFE77F178 for ep: 0x01 cluster: 0x0001 attr: 0x0021 status: 0x00
19:06:48:280 0x680AE2FFFE8DE86E: update ZCL value 0x01/0x0001/0x0021 after 0 s
19:06:48:281 ZCL attribute report 0x680AE2FFFE8DE86E for cluster: 0x0001, ep: 0x01, frame control: 0x08, mfcode: 0x000
If I don’t filter the output, it just repeats the following:
19:24:23:270 asdu: 0f00030201a6b108ffff2e210078f177feff08ac707f4c120001d4
19:24:23:270 APS-DATA.indication request id: 33 -> finished
19:24:23:270 APS-DATA.request id: 33 erase from queue
19:24:23:272 New websocket 192.168.250.250:64389 (state: 3)
19:24:24:490 Daylight now: nightStart, status: 230, daylight: 0, dark: 1
19:24:24:490 apsUseExtPanid is 0x00212EFFFF08B1A6 but should be 0, start reconfiguration
19:24:24:490 Skip automatic channel change, TODO warn user
19:24:26:990 sql exec SELECT conf FROM zbconf ORDER BY rowid desc limit 1
19:24:26:990 Wait 1s till query finished
19:24:27:286 APS-DATA.request id: 35, addrmode: 0x03, addr: 0x00212effff08b1a6, profile: 0x0000, cluster: 0x0031, ep: 0x00 -> 0x00 queue: 0 len: 2 tx.options 0x04
19:24:27:286 asdu (length: 2): 1000
19:24:27:380 APS-DATA.confirm id: 35, status: 0x00 SUCCESS
19:24:27:380 APS-DATA.confirm request id: 35 -> confirmed, timeout 0
19:24:27:410 APS-DATA.indication srcAddr: 0x0000, srcEp: 0x00 dstAddrMode: 2, profile: 0x0000, cluster: 0x8031, lqi: 221, rssi: 30
19:24:27:410 asdu: 1000030001a6b108ffff2e21006ee88dfeffe20a684ba0120001f4
19:24:27:410 APS-DATA.indication request id: 35 -> finished
19:24:27:410 APS-DATA.request id: 35 erase from queue
19:24:27:410 APS-DATA.request id: 37, addrmode: 0x03, addr: 0x00212effff08b1a6, profile: 0x0000, cluster: 0x0031, ep: 0x00 -> 0x00 queue: 0 len: 2 tx.options 0x04
19:24:27:410 asdu (length: 2): 1101
19:24:27:471 APS-DATA.confirm id: 37, status: 0x00 SUCCESS
19:24:27:471 APS-DATA.confirm request id: 37 -> confirmed, timeout 0
19:24:27:501 APS-DATA.indication srcAddr: 0x0000, srcEp: 0x00 dstAddrMode: 2, profile: 0x0000, cluster: 0x8031, lqi: 221, rssi: 30
19:24:27:501 asdu: 1100030101a6b108ffff2e21005fd66ffeff08ac70d7ea120001eb
19:24:27:501 APS-DATA.indication request id: 37 -> finished
19:24:27:501 APS-DATA.request id: 37 erase from queue
19:24:27:501 APS-DATA.request id: 39, addrmode: 0x03, addr: 0x00212effff08b1a6, profile: 0x0000, cluster: 0x0031, ep: 0x00 -> 0x00 queue: 0 len: 2 tx.options 0x04
19:24:27:501 asdu (length: 2): 1202
19:24:27:560 APS-DATA.confirm id: 39, status: 0x00 SUCCESS
19:24:27:560 APS-DATA.confirm request id: 39 -> confirmed, timeout 0
19:24:27:590 APS-DATA.indication srcAddr: 0x0000, srcEp: 0x00 dstAddrMode: 2, profile: 0x0000, cluster: 0x8031, lqi: 221, rssi: 30
19:24:27:590 asdu: 1200030201a6b108ffff2e210078f177feff08ac707f4c120001d4
19:24:27:590 APS-DATA.indication request id: 39 -> finished
19:24:27:590 APS-DATA.request id: 39 erase from queue
19:24:27:990 Idle timer triggered
19:24:27:990 Force read attributes for ZHASwitch SensorNode SceneSwitch3
I suspect this is as expected.
But Energy cunsumption remains high.
Finally have some time today. Seems like we’re not the only ones:
No “solution”, in the thread, apart from moving to Zigbee2MQTT
And have just see this one [FIX] Update and rename _TZ3000_ygvf9xzp_4gang_remote.json to _TZ3000_TS044… by BabaIsYou · Pull Request #6774 · dresden-elektronik/deconz-rest-plugin · GitHub
Can you try this DDF, it mix both PR for the "_TZ3000_wkai4ga5 " (It can remove battery report too, so to check check the battery level, you need to use the GUI, if you can ? Else need to wait for the first poll after 86400s )
{
"schema": "devcap1.schema.json",
"manufacturername": ["_TZ3000_ygvf9xzp", "_TZ3000_ee8nrt2l", "_TZ3000_dziaict4", "_TZ3000_mh9px7cq", "_TZ3000_b7bxojrg", "_TZ3000_ufhtxr59", "_TZ3000_wkai4ga5"],
"modelid": ["TS0044", "TS0044", "TS0044", "TS0044", "TS0044", "TS0044", "TS0044"],
"product": "Tuya remote 4 gangs",
"sleeper": true,
"status": "Gold",
"subdevices": [
{
"type": "$TYPE_SWITCH",
"restapi": "/sensors",
"uuid": [
"$address.ext",
"0x01",
"0x0006"
],
"items": [
{
"name": "attr/id"
},
{
"name": "attr/lastannounced"
},
{
"name": "attr/lastseen"
},
{
"name": "attr/manufacturername"
},
{
"name": "attr/modelid"
},
{
"name": "attr/name"
},
{
"name": "attr/swversion",
"parse": {"fn": "zcl", "ep": 1, "cl": "0x0000", "at": "0x0001", "script": "tuya_swversion.js"},
"read": {"fn": "zcl", "ep": 1, "cl": "0x0000", "at": "0x0001"}
},
{
"name": "attr/type"
},
{
"name": "attr/uniqueid"
},
{
"name": "config/battery",
"refresh.interval": 86400,
"awake": true,
"parse": {
"at": "0x0021",
"cl": "0x0001",
"ep": 1,
"eval": "Item.val = Attr.val / 2;",
"fn": "zcl"
}
},
{
"name": "config/on"
},
{
"name": "config/reachable"
},
{
"name": "state/buttonevent"
},
{
"name": "state/lastupdated"
}
]
}
],
"bindings": [
{
"bind": "unicast",
"src.ep": 1,
"dst.ep": 1,
"cl": "0x0006"
},
{
"bind": "unicast",
"src.ep": 2,
"dst.ep": 1,
"cl": "0x0006"
},
{
"bind": "unicast",
"src.ep": 3,
"dst.ep": 1,
"cl": "0x0006"
},
{
"bind": "unicast",
"src.ep": 4,
"dst.ep": 1,
"cl": "0x0006"
}
]
}
Can need to re-include the device to reset previous bind.
@Smanar Sorry for the late reply. I was sick.
The new settings work the battery now lasts two weeks until it runs out. Is there another trick to disable the flashing? Every few minutes or so the LEDs on the four switches blink.
It mean it works for you ? Or I haven’t understand correclty ? 2 weeks is not good for me
If I m right the flashing mean problem from the z2m post (so battery leak for you), what is your deconz version ATM ?
You are speaking about the _TZ3000_wkai4ga5 ?
I am using 2.22.00 / 19.9.2022. _TZ3000_wkai4ga5 is right.
This one https://github.com/Koenkk/zigbee2mqtt/issues/8072
2.22 have the corrective, you have re-included the device ? (to reset previous bind/report)
Te remove previous bind/report, that is the battery leak cause if you have read, you can reset the device, so you need to re-include it too.
Or you can wait for deconz make a new one, but not sure it will remove the old one.
Do I have a change to check if it works or do I have to wait until the battery should be dead again?
I have deleted the switch to the version 2.22.01 and paired the switch again.