Tuya Zigbee Scene Switch - always double executing

🛎️ Get Help Devices
1

I have a weird behavior of my Tuya 2-gang zigbee switch. I press a button once (or double click, or hold it) and the log shows that it received the command twice, a few milliseconds apart. I tried both the included drive and one from "kkosev" - same results.

Any ideas?

dev:8872023-07-29 07:27:15.409 PMinfoBedroom Switch button 1 was pushed
dev:8872023-07-29 07:27:15.407 PMdebugBedroom Switch catchall descMap: [raw:catchall: 0104 0006 01 01 0040 00 444E 01 00 0000 FD 00 00, profileId:0104, clusterId:0006, clusterInt:6, sourceEndpoint:01, destinationEndpoint:01, options:0040, messageType:00, dni:444E, isClusterSpecific:true, isManufacturerSpecific:false, manufacturerId:0000, command:FD, direction:00, data:[00]]
dev:8872023-07-29 07:27:15.404 PMdebugBedroom Switch description is catchall: 0104 0006 01 01 0040 00 444E 01 00 0000 FD 00 00
dev:8872023-07-29 07:27:14.289 PMinfoBedroom Switch button 1 was pushed
dev:8872023-07-29 07:27:14.287 PMdebugBedroom Switch catchall descMap: [raw:catchall: 0104 0006 01 01 0040 00 444E 01 00 0000 FD 00 00, profileId:0104, clusterId:0006, clusterInt:6, sourceEndpoint:01, destinationEndpoint:01, options:0040, messageType:00, dni:444E, isClusterSpecific:true, isManufacturerSpecific:false, manufacturerId:0000, command:FD, direction:00, data:[00]]
dev:8872023-07-29 07:27:14.284 PMdebugBedroom Switch description is catchall: 0104 0006 01 01 0040 00 444E 01 00 0000 FD 00 00
dev:8872023-07-29 07:27:09.976 PMinfoBedroom Switch button 2 was pushed
dev:8872023-07-29 07:27:09.973 PMdebugBedroom Switch catchall descMap: [raw:catchall: 0104 0006 02 01 0040 00 444E 01 00 0000 FD 00 00, profileId:0104, clusterId:0006, clusterInt:6, sourceEndpoint:02, destinationEndpoint:01, options:0040, messageType:00, dni:444E, isClusterSpecific:true, isManufacturerSpecific:false, manufacturerId:0000, command:FD, direction:00, data:[00]]
dev:8872023-07-29 07:27:09.970 PMdebugBedroom Switch description is catchall: 0104 0006 02 01 0040 00 444E 01 00 0000 FD 00 00
dev:8872023-07-29 07:27:09.142 PMinfoBedroom Switch button 2 was pushed
dev:8872023-07-29 07:27:09.140 PMdebugBedroom Switch catchall descMap: [raw:catchall: 0104 0006 02 01 0040 00 444E 01 00 0000 FD 00 00, profileId:0104, clusterId:0006, clusterInt:6, sourceEndpoint:02, destinationEndpoint:01, options:0040, messageType:00, dni:444E, isClusterSpecific:true, isManufacturerSpecific:false, manufacturerId:0000, command:FD, direction:00, data:[00]]
dev:8872023-07-29 07:27:09.137 PMdebugBedroom Switch description is catchall: 0104 0006 02 01 0040 00 444E 01 00 0000 FD 00 00
2

@kkossev has debouncing logic for that exact scenario but the time window may need to be tweaked.

1 Like
3

I think it may have been a drained (new) battery - replaced it with a different one and it seems to be fixed. Weird behavior...

4

I’ve had that drained battery behavior (about a week). To make it go away I had to rejoin the device and leave the driver at defaults.

1 Like
6

What Garyjmilne is saying is the known workaround to prevent battery drains for some (not all!) Tuys scene switches - make sure you are using the latest Tuya TS004F driver and pair the device again to the hub.

Is the debouncing working at the moment? If not, let me know what is your device model and manufacturer.

7

In the file that I downloaded from github, debouncing was still listed as a todo item. But the new battery fixed it for now as well, so I'm good.

1 Like
8

kkossev: I looked at your code and the model in my case is "TS0042" and you don't seem to have that in the debounce device query - I simply removed the model query and enabled the debounce with that for all devices and now it is working as intended. Not sure what the driver for your if-clause was, but maybe reconsider adding the TS0042 to the devices that need debouncing. 1000 ms worked for me.

  • manufacturer: _TZ3000_ur5fpg7p
  • model: TS0042
1 Like
9

Thank you Thomas - your TS0042 manufacturer _TZ3000_ur5fpg7p is now included in the list of the devices that need debouncing. Note, that it is not the TS0042 model in general, but only particular manufacturers need this debouncing.

The changes are in the dev. branch version 2.6.10.

10

Thanks! I found that the debouncing as a general function did not hurt the functionality of any of my Tuya switches at all ( * manufacturer: _TZ3000_u3nv1jwk * model: TS0044 is the other one I use), so I just changed the code in my Hubitat to do the debouncing around line 420 for every model...

11

The debouncing adds a delay of 1 second between two consecutive presses, so it must be avoided when not absolutely necessary... My last attempt to make it configurable failed, hope will have the time to try again in the next month.

1 Like
12

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.