[Device Support Request] _TZE200_wunufsil TS0601 (Tuya 2 gang touch switch)

Is your feature request related to a problem? Please describe.
Tuya Zigbee touch switch 2 gang is discoverable without any entities
Describe the solution you'd like
It would be great to craft a quirk for this device and integrate it to next release.
Device signature - this can be acquired by removing the device from ZHA and pairing it again from the add devices screen. Be sure to add the entire content of the log panel after pairing the device to a code block below this line.
{
  "node_descriptor": "NodeDescriptor(logical_type=<LogicalType.Router: 1>, complex_descriptor_available=0, user_descriptor_available=0, reserved=0, aps_flags=0, frequency_band=<FrequencyBand.Freq2400MHz: 8>, mac_capability_flags=<MACCapabilityFlags.AllocateAddress|RxOnWhenIdle|MainsPowered|FullFunctionDevice: 142>, manufacturer_code=4098, maximum_buffer_size=82, maximum_incoming_transfer_size=82, server_mask=11264, maximum_outgoing_transfer_size=82, descriptor_capability_field=<DescriptorCapability.0: 0>, *allocate_address=True, *is_alternate_pan_coordinator=False, *is_coordinator=False, *is_end_device=False, *is_full_function_device=True, *is_mains_powered=True, *is_receiver_on_when_idle=True, *is_router=True, *is_security_capable=False)",
  "endpoints": {
    "1": {
      "profile_id": 260,
      "device_type": "0x0051",
      "in_clusters": [
        "0x0000",
        "0x0004",
        "0x0005",
        "0xef00"
      ],
      "out_clusters": [
        "0x000a",
        "0x0019"
      ]
    }
  },
  "manufacturer": "_TZE200_wunufsil",
  "model": "TS0601",
  "class": "zigpy.device.Device"
}

ZHA logs during pairing:
[0x0000:zdo] ZDO request ZDOCmd.Mgmt_Permit_Joining_req: [60, <Bool.false: 0>]
New device 0xd8ba (84:2e:14:ff:fe:3a:53:9c) joined the network
[0xd8ba] Scheduling initialization
Tries remaining: 3
[0xd8ba] Requesting 'Node Descriptor'
Tries remaining: 2
[0xd8ba] Extending timeout for 0x41 request
Device 0xd8ba (84:2e:14:ff:fe:3a:53:9c) joined the network
[0xd8ba] Scheduling initialization
[0xd8ba] Canceling old initialize call
Received frame on uninitialized device <Device model=None manuf=None nwk=0xD8BA ieee=84:2e:14:ff:fe:3a:53:9c is_initialized=False> from ep 0 to ep 0, cluster 19: b'\xae\xba\xd8\x9cS:\xfe\xff\x14.\x84\x8e'
[0xd8ba:zdo] ZDO request ZDOCmd.Device_annce: [0xD8BA, 84:2e:14:ff:fe:3a:53:9c, 142]
Tries remaining: 3
[0xd8ba] Requesting 'Node Descriptor'
Tries remaining: 2
[0xd8ba] Extending timeout for 0x43 request
Received frame on uninitialized device <Device model=None manuf=None nwk=0xD8BA ieee=84:2e:14:ff:fe:3a:53:9c is_initialized=False> from ep 0 to ep 0, cluster 32770: b'A\x00\xba\xd8\x01@\x8e\x02\x10RR\x00\x00,R\x00\x00'
[0xd8ba:zdo] ZDO request ZDOCmd.Node_Desc_rsp: [<Status.SUCCESS: 0>, 0xD8BA, NodeDescriptor(logical_type=<LogicalType.Router: 1>, complex_descriptor_available=0, user_descriptor_available=0, reserved=0, aps_flags=0, frequency_band=<FrequencyBand.Freq2400MHz: 8>, mac_capability_flags=<MACCapabilityFlags.AllocateAddress|RxOnWhenIdle|MainsPowered|FullFunctionDevice: 142>, manufacturer_code=4098, maximum_buffer_size=82, maximum_incoming_transfer_size=82, server_mask=11264, maximum_outgoing_transfer_size=82, descriptor_capability_field=<DescriptorCapability.0: 0>, *allocate_address=True, *is_alternate_pan_coordinator=False, *is_coordinator=False, *is_end_device=False, *is_full_function_device=True, *is_mains_powered=True, *is_receiver_on_when_idle=True, *is_router=True, *is_security_capable=False)]
[0xd8ba:zdo] Unsupported ZDO request:ZDOCmd.Node_Desc_rsp
Received frame on uninitialized device <Device model=None manuf=None nwk=0xD8BA ieee=84:2e:14:ff:fe:3a:53:9c is_initialized=False> from ep 0 to ep 0, cluster 32770: b'C\x00\xba\xd8\x01@\x8e\x02\x10RR\x00\x00,R\x00\x00'
[0xd8ba] Got Node Descriptor: NodeDescriptor(logical_type=<LogicalType.Router: 1>, complex_descriptor_available=0, user_descriptor_available=0, reserved=0, aps_flags=0, frequency_band=<FrequencyBand.Freq2400MHz: 8>, mac_capability_flags=<MACCapabilityFlags.AllocateAddress|RxOnWhenIdle|MainsPowered|FullFunctionDevice: 142>, manufacturer_code=4098, maximum_buffer_size=82, maximum_incoming_transfer_size=82, server_mask=11264, maximum_outgoing_transfer_size=82, descriptor_capability_field=<DescriptorCapability.0: 0>, *allocate_address=True, *is_alternate_pan_coordinator=False, *is_coordinator=False, *is_end_device=False, *is_full_function_device=True, *is_mains_powered=True, *is_receiver_on_when_idle=True, *is_router=True, *is_security_capable=False)
[0xd8ba] Discovering endpoints
Tries remaining: 3
Received frame on uninitialized device <Device model=None manuf=None nwk=0xD8BA ieee=84:2e:14:ff:fe:3a:53:9c is_initialized=False> from ep 0 to ep 0, cluster 32773: b'E\x00\xba\xd8\x01\x01'
[0xd8ba] Discovered endpoints: [1]
[0xd8ba] Initializing endpoints [<Endpoint id=1 in=[] out=[] status=<Status.NEW: 0>>]
[0xd8ba:1] Discovering endpoint information
Tries remaining: 3
Received frame on uninitialized device <Device model=None manuf=None nwk=0xD8BA ieee=84:2e:14:ff:fe:3a:53:9c is_initialized=False> from ep 0 to ep 0, cluster 32772: b'G\x00\xba\xd8\x14\x01\x04\x01Q\x00\x01\x04\x00\x00\x04\x00\x05\x00\x00\xef\x02\x19\x00\n\x00'
[0xd8ba:1] Discovered endpoint information: SizePrefixedSimpleDescriptor(endpoint=1, profile=260, device_type=81, device_version=1, input_clusters=[0, 4, 5, 61184], output_clusters=[25, 10])
Unknown cluster 61184
[0xd8ba:1:0x0000] ZCL deserialize: <ZCLHeader frame_control=<FrameControl frame_type=GLOBAL_COMMAND manufacturer_specific=False is_reply=True disable_default_response=True> manufacturer=None tsn=73 command_id=Command.Read_Attributes_rsp>
[0xd8ba] Read model 'TS0601' and manufacturer '_TZE200_wunufsil' from <Endpoint id=1 in=[basic:0x0000, groups:0x0004, scenes:0x0005, None:0xEF00] out=[ota:0x0019, time:0x000A] status=<Status.ZDO_INIT: 1>>
[0xd8ba] Discovered basic device information for <Device model='TS0601' manuf='_TZE200_wunufsil' nwk=0xD8BA ieee=84:2e:14:ff:fe:3a:53:9c is_initialized=True>
Device is initialized <Device model='TS0601' manuf='_TZE200_wunufsil' nwk=0xD8BA ieee=84:2e:14:ff:fe:3a:53:9c is_initialized=True>
Checking quirks for _TZE200_wunufsil TS0601 (84:2e:14:ff:fe:3a:53:9c)
Considering <class 'zhaquirks.xbee.xbee_io.XBeeSensor'>
Fail because endpoint list mismatch: {232, 230} {1}
Considering <class 'zhaquirks.xbee.xbee3_io.XBee3Sensor'>
Fail because endpoint list mismatch: {232, 230} {1}
Considering <class 'zhaquirks.smartthings.tag_v4.SmartThingsTagV4'>
Fail because device_type mismatch on at least one endpoint
Considering <class 'zhaquirks.smartthings.multi.SmartthingsMultiPurposeSensor'>
Fail because device_type mismatch on at least one endpoint
Considering <class 'zhaquirks.netvox.z308e3ed.Z308E3ED'>
Fail because device_type mismatch on at least one endpoint
Considering <class 'zhaquirks.gledopto.soposhgu10.SoposhGU10'>
Fail because endpoint list mismatch: {11, 13} {1}
Considering <class 'bellows.zigbee.application.EZSPCoordinator'>
Fail because device_type mismatch on at least one endpoint
device - 0xD8BA:84:2e:14:ff:fe:3a:53:9c entering async_device_initialized - is_new_join: True
device - 0xD8BA:84:2e:14:ff:fe:3a:53:9c has joined the ZHA zigbee network
[0xD8BA](TS0601): started configuration
[0xD8BA:ZDO](TS0601): 'async_configure' stage succeeded
[0xD8BA:1:0x0000]: finished channel configuration
[0xD8BA:1:0x0019]: finished channel configuration
Error handling '_save_attribute' event with (84:2e:14:ff:fe:3a:53:9c, 1, 0, 4, '_TZE200_wunufsil') params: FOREIGN KEY constraint failed
[0xD8BA:1:0x0000]: 'async_configure' stage succeeded
[0xD8BA:1:0x0019]: 'async_configure' stage succeeded
Error handling '_save_attribute' event with (84:2e:14:ff:fe:3a:53:9c, 1, 0, 5, 'TS0601') params: FOREIGN KEY constraint failed
[0xD8BA](TS0601): completed configuration
[0xD8BA](TS0601): stored in registry: ZhaDeviceEntry(name='_TZE200_wunufsil TS0601', ieee='84:2e:14:ff:fe:3a:53:9c', last_seen=1627123462.9471736)
[0xD8BA](TS0601): started initialization
[0xD8BA:ZDO](TS0601): 'async_initialize' stage succeeded
[0xD8BA:1:0x0000]: initializing channel: from_cache: False
[0xD8BA:1:0x0000]: finished channel configuration
[0xD8BA:1:0x0019]: initializing channel: from_cache: False
[0xD8BA:1:0x0019]: finished channel configuration
[0xD8BA:1:0x0000]: 'async_initialize' stage succeeded
[0xD8BA:1:0x0019]: 'async_initialize' stage succeeded
[0xD8BA](TS0601): power source: Mains
[0xD8BA](TS0601): completed initialization
[0xd8ba:zdo] ZDO request ZDOCmd.Node_Desc_req: [0x0000]
[0xd8ba:zdo] Unsupported ZDO request:ZDOCmd.Node_Desc_req
[0xd8ba:1:0x000a] ZCL deserialize: <ZCLHeader frame_control=<FrameControl frame_type=GLOBAL_COMMAND manufacturer_specific=False is_reply=False disable_default_response=False> manufacturer=None tsn=69 command_id=Command.Read_Attributes>
[0xd8ba:1:0x000a] ZCL request 0x0000: [[7]]
[0xd8ba:1:0xef00] ZCL deserialize: <ZCLHeader frame_control=<FrameControl frame_type=CLUSTER_COMMAND manufacturer_specific=False is_reply=True disable_default_response=False> manufacturer=None tsn=70 command_id=2>
[0xd8ba:1:0xef00] Unknown cluster-specific command 2
[0xd8ba:1:0xef00] ZCL request 0x0002: b'\x00%\x10\x01\x00\x01\x01'
[0xd8ba:1:0xef00] No handler for cluster command 2
[0xd8ba:1:0xef00] ZCL deserialize: <ZCLHeader frame_control=<FrameControl frame_type=CLUSTER_COMMAND manufacturer_specific=False is_reply=True disable_default_response=False> manufacturer=None tsn=70 command_id=2>
[0xd8ba:1:0xef00] Unknown cluster-specific command 2
[0xd8ba:1:0xef00] ZCL request 0x0002: b'\x00%\x10\x01\x00\x01\x01'
[0xd8ba:1:0xef00] No handler for cluster command 2
[0xd8ba:1:0xef00] ZCL deserialize: <ZCLHeader frame_control=<FrameControl frame_type=CLUSTER_COMMAND manufacturer_specific=False is_reply=True disable_default_response=False> manufacturer=None tsn=70 command_id=2>
[0xd8ba:1:0xef00] Unknown cluster-specific command 2
[0xd8ba:1:0xef00] ZCL request 0x0002: b'\x00%\x10\x01\x00\x01\x01'
[0xd8ba:1:0xef00] No handler for cluster command 2
[0xd8ba:1:0xef00] ZCL deserialize: <ZCLHeader frame_control=<FrameControl frame_type=CLUSTER_COMMAND manufacturer_specific=False is_reply=True disable_default_response=False> manufacturer=None tsn=70 command_id=2>
[0xd8ba:1:0xef00] Unknown cluster-specific command 2
[0xd8ba:1:0xef00] ZCL request 0x0002: b'\x00%\x10\x01\x00\x01\x01'
[0xd8ba:1:0xef00] No handler for cluster command 2
[0xd8ba:1:0xef00] ZCL deserialize: <ZCLHeader frame_control=<FrameControl frame_type=CLUSTER_COMMAND manufacturer_specific=False is_reply=True disable_default_response=False> manufacturer=None tsn=70 command_id=2>
[0xd8ba:1:0xef00] Unknown cluster-specific command 2
[0xd8ba:1:0xef00] ZCL request 0x0002: b'\x00%\x10\x01\x00\x01\x01'
[0xd8ba:1:0xef00] No handler for cluster command 2
[0xd8ba:1:0xef00] ZCL deserialize: <ZCLHeader frame_control=<FrameControl frame_type=CLUSTER_COMMAND manufacturer_specific=False is_reply=True disable_default_response=False> manufacturer=None tsn=70 command_id=2>
[0xd8ba:1:0xef00] Unknown cluster-specific command 2
[0xd8ba:1:0xef00] ZCL request 0x0002: b'\x00%\x10\x01\x00\x01\x01'
[0xd8ba:1:0xef00] No handler for cluster command 2
[0xd8ba:1:0xef00] ZCL deserialize: <ZCLHeader frame_control=<FrameControl frame_type=CLUSTER_COMMAND manufacturer_specific=False is_reply=True disable_default_response=False> manufacturer=None tsn=70 command_id=2>
[0xd8ba:1:0xef00] Unknown cluster-specific command 2
[0xd8ba:1:0xef00] ZCL request 0x0002: b'\x00%\x10\x01\x00\x01\x01'
[0xd8ba:1:0xef00] No handler for cluster command 2
[0xd8ba:1:0xef00] ZCL deserialize: <ZCLHeader frame_control=<FrameControl frame_type=CLUSTER_COMMAND manufacturer_specific=False is_reply=True disable_default_response=False> manufacturer=None tsn=70 command_id=2>
[0xd8ba:1:0xef00] Unknown cluster-specific command 2
[0xd8ba:1:0xef00] ZCL request 0x0002: b'\x00%\x10\x01\x00\x01\x01'
[0xd8ba:1:0xef00] No handler for cluster command 2
[0xd8ba:1:0xef00] ZCL deserialize: <ZCLHeader frame_control=<FrameControl frame_type=CLUSTER_COMMAND manufacturer_specific=False is_reply=True disable_default_response=False> manufacturer=None tsn=70 command_id=2>
[0xd8ba:1:0xef00] Unknown cluster-specific command 2
[0xd8ba:1:0xef00] ZCL request 0x0002: b'\x00%\x10\x01\x00\x01\x01'
[0xd8ba:1:0xef00] No handler for cluster command 2
[0xd8ba:1:0xef00] ZCL deserialize: <ZCLHeader frame_control=<FrameControl frame_type=CLUSTER_COMMAND manufacturer_specific=False is_reply=True disable_default_response=False> manufacturer=None tsn=70 command_id=2>
[0xd8ba:1:0xef00] Unknown cluster-specific command 2
[0xd8ba:1:0xef00] ZCL request 0x0002: b'\x00%\x10\x01\x00\x01\x01'
[0xd8ba:1:0xef00] No handler for cluster command 2
[0xd8ba:1:0xef00] ZCL deserialize: <ZCLHeader frame_control=<FrameControl frame_type=CLUSTER_COMMAND manufacturer_specific=False is_reply=True disable_default_response=False> manufacturer=None tsn=70 command_id=2>
[0xd8ba:1:0xef00] Unknown cluster-specific command 2
[0xd8ba:1:0xef00] ZCL request 0x0002: b'\x00%\x10\x01\x00\x01\x01'
[0xd8ba:1:0xef00] No handler for cluster command 2
[0xd8ba:1:0xef00] ZCL deserialize: <ZCLHeader frame_control=<FrameControl frame_type=CLUSTER_COMMAND manufacturer_specific=False is_reply=True disable_default_response=False> manufacturer=None tsn=70 command_id=2>
[0xd8ba:1:0xef00] Unknown cluster-specific command 2
[0xd8ba:1:0xef00] ZCL request 0x0002: b'\x00%\x10\x01\x00\x01\x01'
[0xd8ba:1:0xef00] No handler for cluster command 2
[0xd8ba:1:0xef00] ZCL deserialize: <ZCLHeader frame_control=<FrameControl frame_type=CLUSTER_COMMAND manufacturer_specific=False is_reply=True disable_default_response=False> manufacturer=None tsn=70 command_id=2>
[0xd8ba:1:0xef00] Unknown cluster-specific command 2
[0xd8ba:1:0xef00] ZCL request 0x0002: b'\x00%\x10\x01\x00\x01\x01'
[0xd8ba:1:0xef00] No handler for cluster command 2
[0xd8ba:1:0xef00] ZCL deserialize: <ZCLHeader frame_control=<FrameControl frame_type=CLUSTER_COMMAND manufacturer_specific=False is_reply=True disable_default_response=False> manufacturer=None tsn=70 command_id=2>
[0xd8ba:1:0xef00] Unknown cluster-specific command 2
[0xd8ba:1:0xef00] ZCL request 0x0002: b'\x00%\x10\x01\x00\x01\x01'
[0xd8ba:1:0xef00] No handler for cluster command 2
[0xd8ba:1:0xef00] ZCL deserialize: <ZCLHeader frame_control=<FrameControl frame_type=CLUSTER_COMMAND manufacturer_specific=False is_reply=True disable_default_response=False> manufacturer=None tsn=70 command_id=2>
[0xd8ba:1:0xef00] Unknown cluster-specific command 2
[0xd8ba:1:0xef00] ZCL request 0x0002: b'\x00%\x10\x01\x00\x01\x01'
[0xd8ba:1:0xef00] No handler for cluster command 2
[0xd8ba:1:0xef00] ZCL deserialize: <ZCLHeader frame_control=<FrameControl frame_type=CLUSTER_COMMAND manufacturer_specific=False is_reply=True disable_default_response=False> manufacturer=None tsn=70 command_id=2>
[0xd8ba:1:0xef00] Unknown cluster-specific command 2
[0xd8ba:1:0xef00] ZCL request 0x0002: b'\x00%\x10\x01\x00\x01\x01'
[0xd8ba:1:0xef00] No handler for cluster command 2
[0xd8ba:1:0xef00] ZCL deserialize: <ZCLHeader frame_control=<FrameControl frame_type=CLUSTER_COMMAND manufacturer_specific=False is_reply=True disable_default_response=False> manufacturer=None tsn=70 command_id=2>
[0xd8ba:1:0xef00] Unknown cluster-specific command 2
[0xd8ba:1:0xef00] ZCL request 0x0002: b'\x00%\x10\x01\x00\x01\x01'
[0xd8ba:1:0xef00] No handler for cluster command 2
[0xd8ba:1:0xef00] ZCL deserialize: <ZCLHeader frame_control=<FrameControl frame_type=CLUSTER_COMMAND manufacturer_specific=False is_reply=True disable_default_response=False> manufacturer=None tsn=70 command_id=2>
[0xd8ba:1:0xef00] Unknown cluster-specific command 2
[0xd8ba:1:0xef00] ZCL request 0x0002: b'\x00%\x10\x01\x00\x01\x01'
[0xd8ba:1:0xef00] No handler for cluster command 2
[0xd8ba:1:0xef00] ZCL deserialize: <ZCLHeader frame_control=<FrameControl frame_type=CLUSTER_COMMAND manufacturer_specific=False is_reply=True disable_default_response=False> manufacturer=None tsn=70 command_id=2>
[0xd8ba:1:0xef00] Unknown cluster-specific command 2
[0xd8ba:1:0xef00] ZCL request 0x0002: b'\x00%\x10\x01\x00\x01\x01'
[0xd8ba:1:0xef00] No handler for cluster command 2
[0xd8ba:1:0xef00] ZCL deserialize: <ZCLHeader frame_control=<FrameControl frame_type=CLUSTER_COMMAND manufacturer_specific=False is_reply=True disable_default_response=False> manufacturer=None tsn=70 command_id=2>
[0xd8ba:1:0xef00] Unknown cluster-specific command 2
[0xd8ba:1:0xef00] ZCL request 0x0002: b'\x00%\x10\x01\x00\x01\x01'
[0xd8ba:1:0xef00] No handler for cluster command 2
[0xd8ba:1:0xef00] ZCL deserialize: <ZCLHeader frame_control=<FrameControl frame_type=CLUSTER_COMMAND manufacturer_specific=False is_reply=True disable_default_response=False> manufacturer=None tsn=70 command_id=2>
[0xd8ba:1:0xef00] Unknown cluster-specific command 2
[0xd8ba:1:0xef00] ZCL request 0x0002: b'\x00%\x10\x01\x00\x01\x01'
[0xd8ba:1:0xef00] No handler for cluster command 2
[0xd8ba:1:0xef00] ZCL deserialize: <ZCLHeader frame_control=<FrameControl frame_type=CLUSTER_COMMAND manufacturer_specific=False is_reply=True disable_default_response=False> manufacturer=None tsn=70 command_id=2>
[0xd8ba:1:0xef00] Unknown cluster-specific command 2
[0xd8ba:1:0xef00] ZCL request 0x0002: b'\x00%\x10\x01\x00\x01\x01'
[0xd8ba:1:0xef00] No handler for cluster command 2
[0xd8ba:1:0xef00] ZCL deserialize: <ZCLHeader frame_control=<FrameControl frame_type=CLUSTER_COMMAND manufacturer_specific=False is_reply=True disable_default_response=False> manufacturer=None tsn=70 command_id=2>
[0xd8ba:1:0xef00] Unknown cluster-specific command 2
[0xd8ba:1:0xef00] ZCL request 0x0002: b'\x00%\x10\x01\x00\x01\x01'
[0xd8ba:1:0xef00] No handler for cluster command 2
[0xd8ba:1:0xef00] ZCL deserialize: <ZCLHeader frame_control=<FrameControl frame_type=CLUSTER_COMMAND manufacturer_specific=False is_reply=True disable_default_response=False> manufacturer=None tsn=70 command_id=2>
[0xd8ba:1:0xef00] Unknown cluster-specific command 2
[0xd8ba:1:0xef00] ZCL request 0x0002: b'\x00%\x10\x01\x00\x01\x01'
[0xd8ba:1:0xef00] No handler for cluster command 2
[0xd8ba:1:0xef00] ZCL deserialize: <ZCLHeader frame_control=<FrameControl frame_type=CLUSTER_COMMAND manufacturer_specific=False is_reply=True disable_default_response=False> manufacturer=None tsn=70 command_id=2>
[0xd8ba:1:0xef00] Unknown cluster-specific command 2
[0xd8ba:1:0xef00] ZCL request 0x0002: b'\x00%\x10\x01\x00\x01\x01'
[0xd8ba:1:0xef00] No handler for cluster command 2
[0xd8ba:1:0xef00] ZCL deserialize: <ZCLHeader frame_control=<FrameControl frame_type=CLUSTER_COMMAND manufacturer_specific=False is_reply=True disable_default_response=False> manufacturer=None tsn=71 command_id=2>
[0xd8ba:1:0xef00] Unknown cluster-specific command 2
[0xd8ba:1:0xef00] ZCL request 0x0002: b'\x00&\x01\x01\x00\x01\x00'
[0xd8ba:1:0xef00] No handler for cluster command 2
[0xd8ba:1:0xef00] ZCL deserialize: <ZCLHeader frame_control=<FrameControl frame_type=CLUSTER_COMMAND manufacturer_specific=False is_reply=True disable_default_response=False> manufacturer=None tsn=72 command_id=2>
[0xd8ba:1:0xef00] Unknown cluster-specific command 2
[0xd8ba:1:0xef00] ZCL request 0x0002: b"\x00'\x02\x01\x00\x01\x00"
[0xd8ba:1:0xef00] No handler for cluster command 2
[0xd8ba:1:0xef00] ZCL deserialize: <ZCLHeader frame_control=<FrameControl frame_type=CLUSTER_COMMAND manufacturer_specific=False is_reply=True disable_default_response=True> manufacturer=None tsn=73 command_id=36>
[0xd8ba:1:0xef00] Unknown cluster-specific command 36
[0xd8ba:1:0xef00] ZCL request 0x0024: b'\x00e'
[0xd8ba:1:0xef00] No handler for cluster command 36
[0xd8ba:1:0xef00] ZCL deserialize: <ZCLHeader frame_control=<FrameControl frame_type=CLUSTER_COMMAND manufacturer_specific=False is_reply=True disable_default_response=False> manufacturer=None tsn=74 command_id=17>
[0xd8ba:1:0xef00] Unknown cluster-specific command 17
[0xd8ba:1:0xef00] ZCL request 0x0011: b'\x00f\xc0'
[0xd8ba:1:0xef00] No handler for cluster command 17
[0xd8ba:1:0xef00] ZCL deserialize: <ZCLHeader frame_control=<FrameControl frame_type=CLUSTER_COMMAND manufacturer_specific=False is_reply=True disable_default_response=False> manufacturer=None tsn=74 command_id=17>
[0xd8ba:1:0xef00] Unknown cluster-specific command 17
[0xd8ba:1:0xef00] ZCL request 0x0011: b'\x00f\xc0'
[0xd8ba:1:0xef00] No handler for cluster command 17
[0xd8ba:1:0xef00] ZCL deserialize: <ZCLHeader frame_control=<FrameControl frame_type=CLUSTER_COMMAND manufacturer_specific=False is_reply=True disable_default_response=False> manufacturer=None tsn=74 command_id=17>
[0xd8ba:1:0xef00] Unknown cluster-specific command 17
[0xd8ba:1:0xef00] ZCL request 0x0011: b'\x00f\xc0'
[0xd8ba:1:0xef00] No handler for cluster command 17
[0xd8ba:1:0xef00] ZCL deserialize: <ZCLHeader frame_control=<FrameControl frame_type=CLUSTER_COMMAND manufacturer_specific=False is_reply=True disable_default_response=False> manufacturer=None tsn=74 command_id=17>
[0xd8ba:1:0xef00] Unknown cluster-specific command 17
[0xd8ba:1:0xef00] ZCL request 0x0011: b'\x00f\xc0'
[0xd8ba:1:0xef00] No handler for cluster command 17
[0xd8ba:1:0xef00] ZCL deserialize: <ZCLHeader frame_control=<FrameControl frame_type=CLUSTER_COMMAND manufacturer_specific=False is_reply=True disable_default_response=False> manufacturer=None tsn=74 command_id=17>
[0xd8ba:1:0xef00] Unknown cluster-specific command 17
[0xd8ba:1:0xef00] ZCL request 0x0011: b'\x00f\xc0'
[0xd8ba:1:0xef00] No handler for cluster command 17

Additional context
Purchased at https://aliexpress.ru/item/4001096045589.html

I have adding one new switch in the quirk that one user was requesting and was putting in more known working IDs and your was one of them. https://github.com/zigpy/zha-device-handlers/issues/966.
Configure local quirks and putting the unziped ts0601.py file in the directory and restarting HA.
The quirk is supporting only one gang and some must adding support for multi gangs but
I dont have the device and im not one code worrier so i cant fixing the last problem with the quirk but you is likely getting the first key working on them.

I put the file ts0601.py in the /usr/local/lib/python3.9/site-packages/zigpy/quirks/ directory into HA container, restarted HA, removed and re-added the device - and nothing changed, alas.

If using local quirks you must putting the cofig for it in HA config (the new method).
You is using the "classical / old method" and was putting the quirk in the quirk root folder in the container so it cant finding its init /usr/local/lib/python3.9/site-packages/zigpy/quirks/ts0601.py.
You need putting it like this: /usr/local/lib/python3.9/site-packages/zigpy/quirks/tuya/ts0501.py  (in the tuya follder) then it can finding the init from the tuya folder, and then deleting the __pycache__ in the /usr/local/lib/python3.9/site-packages/zigpy/quirks/tuya folder and restarting HA.
Normally you shall not needing repairing the device for the quirk to loading then ZHA is doing it the starting. But if the quirk is loading and the device is still not playing well it can being good resetting and adding it a gen so it dont have bad configuration stored.

About the new method (put in the HA configuration) - where can I read more? It seems to me more beautiful to work with the HA configuration than to climb inside the container ...

https://github.com/zigpy/zha-device-handlers/discussions/693#discussioncomment-857274 is  how to configuring it in HA.
The local quirks is staying also if you is updating HA so if the quirk is added in HA you shall deleting it in the local quirk folder.
And you dont need "diving" in the HA container with CLI all the time :-))
Its have one limitation you cant putting more nested quirks in it then its reading all nested quirks from the container and not from the local folder but shall not being any problem for your  device quirk.

If going for the local quirk its best you is deleting the "modded" ts0601.py you was adding in the container (not the original in the tuya folder) so you is not getting dependency problems.

I reset everything to its original state (inside the container in /usr/local/lib/python3.9/site-packages/zigpy/quirks/ removed tuya / ts0601.py, removed pycache), added path to local quirks in HA config, restart HA. As a result, one switch appeared, it even works in both directions, but with a delay of one to several seconds.

Great then the quirk is being loaded :-))
I think the delay is coming from that the quirk have not implanted more gang switches and its not knowing wot to do with the "strange" commands from the switch 2.
Im not one code worrier so i cant fixing the quirk but i hope some with right knowledge can doing it in the near future so all user can using all functions on there device.
I like the design of this switches (the black ones) but they cant being bonded to light groups if having more light that you like searing from the switch or from other remotes but its working "locally" if HA is off line.
Is it working enough for putting the changes in one PR and trying getting the devs accepting it so other user can using it ??
I think its better one gang working then not at all and the device is useless and the other gangs is working "local" but not from ZHA i hope.

I think yes. A device with one running entity is better than a device with no entities at all :)

I agree for 110% !!
I doing one PR for adding the new device IDs and writing its working OK for the first gang but not for 2 and higher ones and the devs can decide if adding it or not and if not users can using the PR for adding it in local quirk.

Can I try to add the TuyaDoubleSwitch(TuyaSwitch) class in this file and describe the signature and replacement for two endpoints in it?
I looked at the README of the project, in general, there is nothing particularly complicated there ...

You can trying all you like in your local quirk and see if its working.
Only remember deleting the __pycache__ in the local quirk folder after doing changes and restarting HA. I think its not nervelessly repairing the device then its only sending and receiving commands from the device and ZHA is applying the new quirk then loading the device on start
If you is getting it working do one new class in the quirk for multiple gang devices so not braking the single ones :-))
One thing if your is bad it can happen ZHA is not starting but you see that  in the log.

Did I understand correctly that it is necessary to clean up __pycache__ even if quirk is placed in the HA config?

I think its nervelessly so not old things is being used of the system.
Normally doing one rm -r __pycache__ is working OK (if being in the right directory).
I have posting  one PR for the new IDs.

Thanks for your help.
If I succeed, I'll post the result here.

That is great !!
You can looking on how Z2M have doing it but i dont understand the java (for my is for drinking not doing technical things) but its decoding the endpoints from the DP and connecting them to one new cluster on one new end point i think (without knowing as normal).
Hope you is getting it  working !!!

By the way, I noticed one bug in the existing implementation. If the switch port is physically turned on and HA restart is performed, then the entity of this port starts in the off state, i.e. at startup, HA does not read the current original status of the device port.

"Normal" zigbeee devices is saved the last seen and state in zigbee.db  and ZHA is repopulating the last seen and state from it but for the moment its much work being done then upgrading the zigbee.db and many users (most deCONZ) is rolling back then they is having problems and the devs have doing much things for fixing it but im not 110% sure its stable (last fixes was merged in the night).
But i dont knowing if its the same with the "tuya commands" devices.
I think the status shall being updated in some minutes if the device is reporting OK to the coordinator but i dont knowing if its the same with tuya.
I think its the same with normal zigbee device if changing the status then the coordinator is off line then ZHA is using the "old" status until the device is reporting the new or ZHA is pulling (for not zigbee good behaving devices like Philips  HUE) the new status from the device.

The status of an entity in HA is updated whenever the device is active.
In my case, the status of the entity of the first port of the device is updated when clicking on any sensor of the device - it doesn't matter the first or the second one.
Probably this is not even a bug, but a feature :)

Last seen shall being updated from all status report from the device so it looks OK then ZHA have only one device for the switch.
"Undocumented futures" is one nice name for bugs ;-)))

Unfortunately I can't make a working solution.
When trying to add endpoints to signature and replacement quirk stops working. Apparently everything is not as simple as it seemed :)

I was looking in the init for the tuya quirks and its some debug logging in it that  shall showing the events being received from the device.
Try putting little debug logging in your HA config like this:
    zhaquirks: info
    zhaquirks.tuya: debug

and look if ZHA is receiving some events from the device.
I dont being on programmer but i think one part of the quirk is listening for the events with DP and is sending them to the event bus = HA but i dont understanding how it working.
https://github.com/zigpy/zha-device-handlers/blob/21af0860992021c39b26260b6e2ae4f9c1af75d1/zhaquirks/tuya/__init__.py#L392
and https://github.com/zigpy/zha-device-handlers/blob/21af0860992021c39b26260b6e2ae4f9c1af75d1/zhaquirks/tuya/init.py#L435
I have not finding any reference that is limiting the commands received to endpoint 1 or somthing but it can being som other place in the code that i dont knowing.
ZHA have one converter from some commands so they is in there range but i still not knowing how its working.
Perhaps the second gang is using one different index here:
https://github.com/zigpy/zha-device-handlers/blob/21af0860992021c39b26260b6e2ae4f9c1af75d1/zhaquirks/tuya/__init__.py#L93.

Unfortunately, as a result of multiple pairings / disconnections, the switch stopped entering pairing mode. I don’t know, the fact is that my ZHA installation has deteriorated (although the other 17 devices are connected and working), or the switch itself has gone crazy - but right now I cannot check your thoughts.
I completely cleaned the installation (removed all devices, removed ZHA, reflash the zigbee bridge, cleaned the HA service files, put everything back in - the switch does not want to pair)
I'm sorry...
PS: If I can get it to work properly, I will write here.

Very sad !!!
Is the switch having one reset / pairing button or is it one of the "normal" ones used for reset ?
And is you getting any feedback (LED blinking or somthing) then getting it retested ?
If you have mounted it in one wall box it can being that the antenna is not working so good then its much metal around it.

The switch lies on the table in front of me, one meter from the zigbee bridge and three meters from the Wi-Fi.
The switch does not have a reset button. Tuya write that to reset, you need to turn on / off the power of the switch several times in a row - and I have done this many times.
Therefore, there are only two options - either the switch has gone crazy, or HA + Zigbee Bridge + ZHA. Moreover, HA + Zigbee Bridge + ZHA works normally in all other respects.

HA logs during try to pair this switch:
2021-07-28 00:28:04 DEBUG (MainThread) [bellows.ezsp.protocol] Send command sendBroadcast: (<BroadcastAddress.ALL_ROUTERS_AND_COORDINATOR: 65532>, EmberApsFrame(profileId=0, clusterId=54, sourceEndpoint=0, destinationEndpoint=0, options=<EmberApsOption.APS_OPTION_NONE: 0>, groupId=0, sequence=121), 0, 122, b'y<\x00') 2021-07-28 00:28:04 DEBUG (MainThread) [bellows.ezsp.protocol] Send command addTransientLinkKey: (ff:ff:ff:ff:ff:ff:ff:ff, [90, 105, 103, 66, 101, 101, 65, 108, 108, 105, 97, 110, 99, 101, 48, 57]) 2021-07-28 00:28:04 DEBUG (bellows.thread_0) [bellows.uart] Sending: b'562621a9622ae94d59947c25aa5592499c4e5eab97cd1eb7fd42637e' 2021-07-28 00:28:05 DEBUG (bellows.thread_0) [bellows.uart] Data frame: b'6626a1a9622a15adb8727e' 2021-07-28 00:28:05 DEBUG (bellows.thread_0) [bellows.uart] Sending: b'87009f7e' 2021-07-28 00:28:05 DEBUG (MainThread) [bellows.ezsp.protocol] Application frame 54 (sendBroadcast) received: b'001f' 2021-07-28 00:28:05 DEBUG (bellows.thread_0) [bellows.uart] Sending: b'672721a9fb2aea4da66bb5da55aac820fb0c42ceaca20be29ca800eccc47879d7e' 2021-07-28 00:28:05 DEBUG (bellows.thread_0) [bellows.uart] Data frame: b'7626b1a9112a10b259a24a25aa5592499c51d8abedce9874febf5f89294c7e' 2021-07-28 00:28:05 DEBUG (bellows.thread_0) [bellows.uart] Sending: b'8070787e' 2021-07-28 00:28:05 DEBUG (MainThread) [bellows.ezsp.protocol] Application frame 69 (incomingMessageHandler) received: b'05000036000000000000001fff000000ffff03793c00' 2021-07-28 00:28:05 DEBUG (MainThread) [bellows.zigbee.application] Received incomingMessageHandler frame with [<EmberIncomingMessageType.INCOMING_BROADCAST_LOOPBACK: 5>, EmberApsFrame(profileId=0, clusterId=54, sourceEndpoint=0, destinationEndpoint=0, options=<EmberApsOption.APS_OPTION_NONE: 0>, groupId=0, sequence=31), 255, 0, 0x0000, 255, 255, b'y<\x00'] 2021-07-28 00:28:05 DEBUG (MainThread) [zigpy.zdo] [0x0000:zdo] ZDO request ZDOCmd.Mgmt_Permit_Joining_req: [60, <Bool.false: 0>] 2021-07-28 00:28:05 DEBUG (bellows.thread_0) [bellows.uart] Data frame: b'0727a1a9fb2a1534ed7e' 2021-07-28 00:28:05 DEBUG (bellows.thread_0) [bellows.uart] Sending: b'8160597e' 2021-07-28 00:28:05 DEBUG (MainThread) [bellows.ezsp.protocol] Application frame 175 (addTransientLinkKey) received: b'00' 2021-07-28 00:28:05 DEBUG (MainThread) [bellows.ezsp.protocol] Send command setPolicy: (<EzspPolicyId.TRUST_CENTER_POLICY: 0>, <EzspDecisionBitmask.ALLOW_UNSECURED_REJOINS|ALLOW_JOINS: 3>) 2021-07-28 00:28:05 DEBUG (bellows.thread_0) [bellows.uart] Sending: b'712421a9012a15b159e8157e' 2021-07-28 00:28:05 DEBUG (bellows.thread_0) [bellows.uart] Data frame: b'1024a1a9012a15f0a17e' 2021-07-28 00:28:05 DEBUG (bellows.thread_0) [bellows.uart] Sending: b'82503a7e' 2021-07-28 00:28:05 DEBUG (MainThread) [bellows.ezsp.protocol] Application frame 85 (setPolicy) received: b'00' 2021-07-28 00:28:05 DEBUG (bellows.thread_0) [bellows.uart] Data frame: b'2024b1a96b2a134ea6944a13aa5592499c4e27b497ce6744d77e' 2021-07-28 00:28:05 DEBUG (bellows.thread_0) [bellows.uart] Sending: b'83401b7e' 2021-07-28 00:28:05 DEBUG (MainThread) [bellows.ezsp.protocol] Application frame 63 (messageSentHandler) received: b'06fcff000036000000000000001f7a0000' 2021-07-28 00:28:05 DEBUG (MainThread) [bellows.zigbee.application] Received messageSentHandler frame with [<EmberOutgoingMessageType.OUTGOING_BROADCAST: 6>, 65532, EmberApsFrame(profileId=0, clusterId=54, sourceEndpoint=0, destinationEndpoint=0, options=<EmberApsOption.APS_OPTION_NONE: 0>, groupId=0, sequence=31), 122, <EmberStatus.SUCCESS: 0>, b''] 2021-07-28 00:28:05 DEBUG (MainThread) [bellows.ezsp.protocol] Send command permitJoining: (60,) 2021-07-28 00:28:05 DEBUG (bellows.thread_0) [bellows.uart] Sending: b'032521a9762a29d26f7e' 2021-07-28 00:28:06 DEBUG (bellows.thread_0) [bellows.uart] Data frame: b'3125a1a9762a153e0e7e' 2021-07-28 00:28:06 DEBUG (bellows.thread_0) [bellows.uart] Sending: b'8430fc7e' 2021-07-28 00:28:06 DEBUG (MainThread) [bellows.ezsp.protocol] Application frame 34 (permitJoining) received: b'00' 2021-07-28 00:28:12 DEBUG (MainThread) [bellows.ezsp.protocol] Send command nop: () 2021-07-28 00:28:12 DEBUG (bellows.thread_0) [bellows.uart] Sending: b'142a21a9512a867d5e7e' 2021-07-28 00:28:12 DEBUG (bellows.thread_0) [bellows.uart] Data frame: b'422aa1a9512aa6337e' 2021-07-28 00:28:12 DEBUG (bellows.thread_0) [bellows.uart] Sending: b'8520dd7e' 2021-07-28 00:28:12 DEBUG (MainThread) [bellows.ezsp.protocol] Application frame 5 (nop) received: b'' 2021-07-28 00:28:22 DEBUG (MainThread) [bellows.ezsp.protocol] Send command nop: () 2021-07-28 00:28:22 DEBUG (bellows.thread_0) [bellows.uart] Sending: b'252b21a9512a46037e' 2021-07-28 00:28:22 DEBUG (bellows.thread_0) [bellows.uart] Data frame: b'532ba1a9512a53467e' 2021-07-28 00:28:22 DEBUG (bellows.thread_0) [bellows.uart] Sending: b'8610be7e' 2021-07-28 00:28:22 DEBUG (MainThread) [bellows.ezsp.protocol] Application frame 5 (nop) received: b'' 2021-07-28 00:28:32 DEBUG (MainThread) [bellows.ezsp.protocol] Send command nop: () 2021-07-28 00:28:32 DEBUG (bellows.thread_0) [bellows.uart] Sending: b'362821a9512a7cb57e' 2021-07-28 00:28:32 DEBUG (bellows.thread_0) [bellows.uart] Data frame: b'6428a1a9512a5a597e' 2021-07-28 00:28:32 DEBUG (bellows.thread_0) [bellows.uart] Sending: b'87009f7e' 2021-07-28 00:28:32 DEBUG (MainThread) [bellows.ezsp.protocol] Application frame 5 (nop) received: b'' 2021-07-28 00:28:42 DEBUG (MainThread) [bellows.ezsp.protocol] Send command nop: () 2021-07-28 00:28:42 DEBUG (bellows.thread_0) [bellows.uart] Sending: b'472921a9512ad6d87e' 2021-07-28 00:28:42 DEBUG (bellows.thread_0) [bellows.uart] Data frame: b'7529a1a9512aaf2c7e' 2021-07-28 00:28:42 DEBUG (bellows.thread_0) [bellows.uart] Sending: b'8070787e' 2021-07-28 00:28:42 DEBUG (MainThread) [bellows.ezsp.protocol] Application frame 5 (nop) received: b'' 2021-07-28 00:28:52 DEBUG (MainThread) [bellows.ezsp.protocol] Send command nop: () 2021-07-28 00:28:52 DEBUG (bellows.thread_0) [bellows.uart] Sending: b'502e21a9512a63c97e' 2021-07-28 00:28:52 DEBUG (bellows.thread_0) [bellows.uart] Data frame: b'062ea1a9512a43847e' 2021-07-28 00:28:52 DEBUG (bellows.thread_0) [bellows.uart] Sending: b'8160597e' 2021-07-28 00:28:52 DEBUG (MainThread) [bellows.ezsp.protocol] Application frame 5 (nop) received: b'' 2021-07-28 00:28:55 DEBUG (bellows.thread_0) [bellows.uart] Data frame: b'162eb1a9112a15b658964e24ab5593499cd3af150af69874f5de2783fc7e1689e1cf5ee17e' 2021-07-28 00:28:55 DEBUG (bellows.thread_0) [bellows.uart] Sending: b'82503a7e' 2021-07-28 00:28:55 DEBUG (MainThread) [bellows.ezsp.protocol] Application frame 69 (incomingMessageHandler) received: b'00040102040101000100009d88bee738ffff0818440a0000292e0a02' 2021-07-28 00:28:55 DEBUG (MainThread) [bellows.zigbee.application] Received incomingMessageHandler frame with [<EmberIncomingMessageType.INCOMING_UNICAST: 0>, EmberApsFrame(profileId=260, clusterId=1026, sourceEndpoint=1, destinationEndpoint=1, options=<EmberApsOption.APS_OPTION_ENABLE_ROUTE_DISCOVERY: 256>, groupId=0, sequence=157), 136, -66, 0x38e7, 255, 255, b'\x18D\n\x00\x00).\n'] 2021-07-28 00:28:55 DEBUG (MainThread) [zigpy.zcl] [0x38e7:1:0x0402] ZCL deserialize: <ZCLHeader frame_control=<FrameControl frame_type=GLOBAL_COMMAND manufacturer_specific=False is_reply=True disable_default_response=True> manufacturer=None tsn=68 command_id=Command.Report_Attributes> 2021-07-28 00:28:55 DEBUG (MainThread) [zigpy.zcl] [0x38e7:1:0x0402] ZCL request 0x000a: [[Attribute(attrid=0, value=<TypeValue type=int16s, value=2606>)]] 2021-07-28 00:28:55 DEBUG (MainThread) [zigpy.zcl] [0x38e7:1:0x0402] Attribute report received: measured_value=2606

Only 26.06 °C reported (0.2 °C lesser then my) and no sign of trying joining devices ;-))
Normally its one fuse on the PCB for the power to the Zigbee module it can being one 0 ohm resistor or one real fuse that can have being burned or its the power supply broken.
Can you measuring if you is having 3.3 V to the zigbee module (dont frying your fingers !!!!) ?
If need pinout for the module search for the model and tuya is having manuals for (most) them.

Probably not today - I already have a deep night, and tomorrow is a hard day ...

Can't get it to pair. I will try to find Tuya zigbee coordinator to reset it by Tuya app. There will be information - I will write. Thanks for your help. :)

Is the switch still killed ?
I only asking because ZHA is rouing one updated quirks for the next release and i wondering if i shall making one PR for it.

Hi Matt!
Switch is alive again.
After updating HA to 2021.9 and removing local_quirks, the switch is paired with one entity, i.e. this quirk is already in zha.
Zigbee info
IEEE: 84:2e:14:ff:fe:3a:53:9c
Nwk: 0x512f
Device Type: Router
LQI: 240
RSSI: -40
Last Seen: 2021-09-05T09:22:53
Power Source: Mains
Quirk: zhaquirks.tuya.ts0601.TuyaSingleSwitch

Great then you is having one half switch working as expected :-))
That is much better then one not working switch !!
Do you have trying if you is getting some tuya debug prints from the second gang ?
Put this log setting in HA:
    zhaquirks: info
    zhaquirks.tuya: debug

and restart HA and trigger some commands from the 2 gang and looking in the log.
Also development tools > Event > Listening to event and putting in zha_event and clicking start listening you shall getting the events from the first gang.

logger:
logs:
zhaquirks: info
zhaquirks.tuya: debug
Logs are too big and contain of a lot of not Zigbee related info...
What pattern to grep in logs?

Nothing in Listening of zha_event. Absolutely.
One button press or another - silence...

My tuya TRV is sending data and its looks like this:
2021-09-05 11:00:39 DEBUG (MainThread) [zhaquirks.tuya] [0x7f8b:1:0xef00] Received value [0, 0, 0, 253] for attribute 0x0203 (command 0x0001)
2021-09-05 11:06:35 DEBUG (MainThread) [zhaquirks.tuya] [0x5ce2:1:0xef00] Received value [0, 0, 0, 237] for attribute 0x0203 (command 0x0001)

So only logs from [zhaquirks.tuya] is interesting for see wot the "tuya magic" is doing or not.
If the switch is sending somthing you shall getting some tuya DP commands / attribute received in the log.
You can also grep on the Nwk: 0x512f and you shall see all communication with the switch.

2021-09-05 12:47:49 DEBUG (MainThread) [zhaquirks.tuya] 84:2e:14:ff:fe:3a:53:9c - Received switch event message, channel: 1, state: 1
2021-09-05 12:47:50 DEBUG (MainThread) [zhaquirks.tuya] 84:2e:14:ff:fe:3a:53:9c - Received switch event message, channel: 1, state: 1
2021-09-05 12:47:50 DEBUG (MainThread) [zhaquirks.tuya] 84:2e:14:ff:fe:3a:53:9c - Received switch event message, channel: 1, state: 1
2021-09-05 12:47:50 DEBUG (MainThread) [zhaquirks.tuya] 84:2e:14:ff:fe:3a:53:9c - Received switch event message, channel: 1, state: 1
2021-09-05 12:47:50 DEBUG (MainThread) [zhaquirks.tuya] 84:2e:14:ff:fe:3a:53:9c - Received switch event message, channel: 1, state: 1
2021-09-05 12:47:50 DEBUG (MainThread) [zhaquirks.tuya] 84:2e:14:ff:fe:3a:53:9c - Received switch event message, channel: 1, state: 1
2021-09-05 12:47:51 DEBUG (MainThread) [zhaquirks.tuya] 84:2e:14:ff:fe:3a:53:9c - Received switch event message, channel: 1, state: 1
2021-09-05 12:47:51 DEBUG (MainThread) [zhaquirks.tuya] 84:2e:14:ff:fe:3a:53:9c - Received switch event message, channel: 1, state: 1
2021-09-05 12:47:51 DEBUG (MainThread) [zhaquirks.tuya] 84:2e:14:ff:fe:3a:53:9c - Received switch event message, channel: 1, state: 1
2021-09-05 12:47:51 DEBUG (MainThread) [zhaquirks.tuya] 84:2e:14:ff:fe:3a:53:9c - Received switch event message, channel: 1, state: 1
2021-09-05 12:47:51 DEBUG (MainThread) [zhaquirks.tuya] 84:2e:14:ff:fe:3a:53:9c - Received switch event message, channel: 1, state: 1
2021-09-05 12:47:52 DEBUG (MainThread) [zhaquirks.tuya] 84:2e:14:ff:fe:3a:53:9c - Received switch event message, channel: 1, state: 1
2021-09-05 12:47:52 DEBUG (MainThread) [zhaquirks.tuya] 84:2e:14:ff:fe:3a:53:9c - Received switch event message, channel: 1, state: 1
2021-09-05 12:47:52 DEBUG (MainThread) [zhaquirks.tuya] 84:2e:14:ff:fe:3a:53:9c - Received switch event message, channel: 1, state: 1
2021-09-05 12:47:52 DEBUG (MainThread) [zhaquirks.tuya] 84:2e:14:ff:fe:3a:53:9c - Received switch event message, channel: 1, state: 1
2021-09-05 12:47:52 DEBUG (MainThread) [zhaquirks.tuya] 84:2e:14:ff:fe:3a:53:9c - Received switch event message, channel: 1, state: 1
2021-09-05 12:47:53 DEBUG (MainThread) [zhaquirks.tuya] 84:2e:14:ff:fe:3a:53:9c - Received switch event message, channel: 1, state: 1
2021-09-05 12:47:53 DEBUG (MainThread) [zhaquirks.tuya] 84:2e:14:ff:fe:3a:53:9c - Received switch event message, channel: 1, state: 1
2021-09-05 12:47:53 DEBUG (MainThread) [zhaquirks.tuya] 84:2e:14:ff:fe:3a:53:9c - Received switch event message, channel: 1, state: 1
2021-09-05 12:47:53 DEBUG (MainThread) [zhaquirks.tuya] 84:2e:14:ff:fe:3a:53:9c - Received switch event message, channel: 1, state: 1
2021-09-05 12:47:53 DEBUG (MainThread) [zhaquirks.tuya] 84:2e:14:ff:fe:3a:53:9c - Received switch event message, channel: 1, state: 1
2021-09-05 12:47:54 DEBUG (MainThread) [zhaquirks.tuya] 84:2e:14:ff:fe:3a:53:9c - Received switch event message, channel: 1, state: 1
2021-09-05 12:47:54 DEBUG (MainThread) [zhaquirks.tuya] 84:2e:14:ff:fe:3a:53:9c - Received switch event message, channel: 1, state: 1
2021-09-05 12:48:12 DEBUG (MainThread) [zhaquirks.tuya] 84:2e:14:ff:fe:3a:53:9c - Received switch event message, channel: 1, state: 0
2021-09-05 12:48:12 DEBUG (MainThread) [zhaquirks.tuya] 84:2e:14:ff:fe:3a:53:9c - Received switch event message, channel: 1, state: 0
2021-09-05 12:48:12 DEBUG (MainThread) [zhaquirks.tuya] 84:2e:14:ff:fe:3a:53:9c - Received switch event message, channel: 1, state: 0
2021-09-05 12:48:13 DEBUG (MainThread) [zhaquirks.tuya] 84:2e:14:ff:fe:3a:53:9c - Received switch event message, channel: 1, state: 0
2021-09-05 12:48:13 DEBUG (MainThread) [zhaquirks.tuya] 84:2e:14:ff:fe:3a:53:9c - Received switch event message, channel: 1, state: 0
2021-09-05 12:48:13 DEBUG (MainThread) [zhaquirks.tuya] 84:2e:14:ff:fe:3a:53:9c - Received switch event message, channel: 1, state: 0
2021-09-05 12:48:13 DEBUG (MainThread) [zhaquirks.tuya] 84:2e:14:ff:fe:3a:53:9c - Received switch event message, channel: 1, state: 0
2021-09-05 12:48:13 DEBUG (MainThread) [zhaquirks.tuya] 84:2e:14:ff:fe:3a:53:9c - Received switch event message, channel: 1, state: 0
2021-09-05 12:48:14 DEBUG (MainThread) [zhaquirks.tuya] 84:2e:14:ff:fe:3a:53:9c - Received switch event message, channel: 1, state: 0
2021-09-05 12:48:14 DEBUG (MainThread) [zhaquirks.tuya] 84:2e:14:ff:fe:3a:53:9c - Received switch event message, channel: 1, state: 0
2021-09-05 12:48:14 DEBUG (MainThread) [zhaquirks.tuya] 84:2e:14:ff:fe:3a:53:9c - Received switch event message, channel: 1, state: 0
2021-09-05 12:48:14 DEBUG (MainThread) [zhaquirks.tuya] 84:2e:14:ff:fe:3a:53:9c - Received switch event message, channel: 1, state: 0
2021-09-05 12:48:14 DEBUG (MainThread) [zhaquirks.tuya] 84:2e:14:ff:fe:3a:53:9c - Received switch event message, channel: 1, state: 0
2021-09-05 12:48:15 DEBUG (MainThread) [zhaquirks.tuya] 84:2e:14:ff:fe:3a:53:9c - Received switch event message, channel: 1, state: 0
2021-09-05 12:48:15 DEBUG (MainThread) [zhaquirks.tuya] 84:2e:14:ff:fe:3a:53:9c - Received switch event message, channel: 1, state: 0
2021-09-05 12:48:15 DEBUG (MainThread) [zhaquirks.tuya] 84:2e:14:ff:fe:3a:53:9c - Received switch event message, channel: 1, state: 0
2021-09-05 12:48:15 DEBUG (MainThread) [zhaquirks.tuya] 84:2e:14:ff:fe:3a:53:9c - Received switch event message, channel: 1, state: 0
2021-09-05 12:48:15 DEBUG (MainThread) [zhaquirks.tuya] 84:2e:14:ff:fe:3a:53:9c - Received switch event message, channel: 1, state: 0
2021-09-05 12:48:16 DEBUG (MainThread) [zhaquirks.tuya] 84:2e:14:ff:fe:3a:53:9c - Received switch event message, channel: 1, state: 0
2021-09-05 12:48:16 DEBUG (MainThread) [zhaquirks.tuya] 84:2e:14:ff:fe:3a:53:9c - Received switch event message, channel: 1, state: 0
2021-09-05 12:48:16 DEBUG (MainThread) [zhaquirks.tuya] 84:2e:14:ff:fe:3a:53:9c - Received switch event message, channel: 1, state: 0
2021-09-05 12:48:16 DEBUG (MainThread) [zhaquirks.tuya] 84:2e:14:ff:fe:3a:53:9c - Received switch event message, channel: 1, state: 0
2021-09-05 12:48:16 DEBUG (MainThread) [zhaquirks.tuya] 84:2e:14:ff:fe:3a:53:9c - Received switch event message, channel: 1, state: 0
2021-09-05 12:48:17 DEBUG (MainThread) [zhaquirks.tuya] 84:2e:14:ff:fe:3a:53:9c - Received switch event message, channel: 1, state: 0
2021-09-05 12:48:17 DEBUG (MainThread) [zhaquirks.tuya] 84:2e:14:ff:fe:3a:53:9c - Received switch event message, channel: 1, state: 0
2021-09-05 12:48:42 DEBUG (MainThread) [zhaquirks.tuya] 84:2e:14:ff:fe:3a:53:9c - Received switch event message, channel: 2, state: 1
2021-09-05 12:48:42 DEBUG (MainThread) [zhaquirks.tuya] 84:2e:14:ff:fe:3a:53:9c - Received switch event message, channel: 2, state: 1
2021-09-05 12:48:42 DEBUG (MainThread) [zhaquirks.tuya] 84:2e:14:ff:fe:3a:53:9c - Received switch event message, channel: 2, state: 1
2021-09-05 12:48:42 DEBUG (MainThread) [zhaquirks.tuya] 84:2e:14:ff:fe:3a:53:9c - Received switch event message, channel: 2, state: 1
2021-09-05 12:48:42 DEBUG (MainThread) [zhaquirks.tuya] 84:2e:14:ff:fe:3a:53:9c - Received switch event message, channel: 2, state: 1
2021-09-05 12:48:43 DEBUG (MainThread) [zhaquirks.tuya] 84:2e:14:ff:fe:3a:53:9c - Received switch event message, channel: 2, state: 1
2021-09-05 12:48:43 DEBUG (MainThread) [zhaquirks.tuya] 84:2e:14:ff:fe:3a:53:9c - Received switch event message, channel: 2, state: 1
2021-09-05 12:48:43 DEBUG (MainThread) [zhaquirks.tuya] 84:2e:14:ff:fe:3a:53:9c - Received switch event message, channel: 2, state: 1
2021-09-05 12:48:43 DEBUG (MainThread) [zhaquirks.tuya] 84:2e:14:ff:fe:3a:53:9c - Received switch event message, channel: 2, state: 1
2021-09-05 12:48:43 DEBUG (MainThread) [zhaquirks.tuya] 84:2e:14:ff:fe:3a:53:9c - Received switch event message, channel: 2, state: 1
2021-09-05 12:48:44 DEBUG (MainThread) [zhaquirks.tuya] 84:2e:14:ff:fe:3a:53:9c - Received switch event message, channel: 2, state: 1
2021-09-05 12:48:44 DEBUG (MainThread) [zhaquirks.tuya] 84:2e:14:ff:fe:3a:53:9c - Received switch event message, channel: 2, state: 1
2021-09-05 12:48:44 DEBUG (MainThread) [zhaquirks.tuya] 84:2e:14:ff:fe:3a:53:9c - Received switch event message, channel: 2, state: 1
2021-09-05 12:48:44 DEBUG (MainThread) [zhaquirks.tuya] 84:2e:14:ff:fe:3a:53:9c - Received switch event message, channel: 2, state: 1
2021-09-05 12:48:44 DEBUG (MainThread) [zhaquirks.tuya] 84:2e:14:ff:fe:3a:53:9c - Received switch event message, channel: 2, state: 1
2021-09-05 12:48:45 DEBUG (MainThread) [zhaquirks.tuya] 84:2e:14:ff:fe:3a:53:9c - Received switch event message, channel: 2, state: 1
2021-09-05 12:48:45 DEBUG (MainThread) [zhaquirks.tuya] 84:2e:14:ff:fe:3a:53:9c - Received switch event message, channel: 2, state: 1
2021-09-05 12:48:45 DEBUG (MainThread) [zhaquirks.tuya] 84:2e:14:ff:fe:3a:53:9c - Received switch event message, channel: 2, state: 1
2021-09-05 12:48:45 DEBUG (MainThread) [zhaquirks.tuya] 84:2e:14:ff:fe:3a:53:9c - Received switch event message, channel: 2, state: 1
2021-09-05 12:48:45 DEBUG (MainThread) [zhaquirks.tuya] 84:2e:14:ff:fe:3a:53:9c - Received switch event message, channel: 2, state: 1
2021-09-05 12:48:46 DEBUG (MainThread) [zhaquirks.tuya] 84:2e:14:ff:fe:3a:53:9c - Received switch event message, channel: 2, state: 1
2021-09-05 12:48:46 DEBUG (MainThread) [zhaquirks.tuya] 84:2e:14:ff:fe:3a:53:9c - Received switch event message, channel: 2, state: 1
2021-09-05 12:48:46 DEBUG (MainThread) [zhaquirks.tuya] 84:2e:14:ff:fe:3a:53:9c - Received switch event message, channel: 2, state: 1
2021-09-05 12:48:46 DEBUG (MainThread) [zhaquirks.tuya] 84:2e:14:ff:fe:3a:53:9c - Received switch event message, channel: 2, state: 1
2021-09-05 12:48:46 DEBUG (MainThread) [zhaquirks.tuya] 84:2e:14:ff:fe:3a:53:9c - Received switch event message, channel: 2, state: 1
2021-09-05 12:48:47 DEBUG (MainThread) [zhaquirks.tuya] 84:2e:14:ff:fe:3a:53:9c - Received switch event message, channel: 2, state: 0
2021-09-05 12:48:47 DEBUG (MainThread) [zhaquirks.tuya] 84:2e:14:ff:fe:3a:53:9c - Received switch event message, channel: 2, state: 0
2021-09-05 12:48:47 DEBUG (MainThread) [zhaquirks.tuya] 84:2e:14:ff:fe:3a:53:9c - Received switch event message, channel: 2, state: 0
2021-09-05 12:48:47 DEBUG (MainThread) [zhaquirks.tuya] 84:2e:14:ff:fe:3a:53:9c - Received switch event message, channel: 2, state: 0
2021-09-05 12:48:48 DEBUG (MainThread) [zhaquirks.tuya] 84:2e:14:ff:fe:3a:53:9c - Received switch event message, channel: 2, state: 0
2021-09-05 12:48:48 DEBUG (MainThread) [zhaquirks.tuya] 84:2e:14:ff:fe:3a:53:9c - Received switch event message, channel: 2, state: 0
2021-09-05 12:48:48 DEBUG (MainThread) [zhaquirks.tuya] 84:2e:14:ff:fe:3a:53:9c - Received switch event message, channel: 2, state: 0
2021-09-05 12:48:48 DEBUG (MainThread) [zhaquirks.tuya] 84:2e:14:ff:fe:3a:53:9c - Received switch event message, channel: 2, state: 0
2021-09-05 12:48:48 DEBUG (MainThread) [zhaquirks.tuya] 84:2e:14:ff:fe:3a:53:9c - Received switch event message, channel: 2, state: 0
2021-09-05 12:48:49 DEBUG (MainThread) [zhaquirks.tuya] 84:2e:14:ff:fe:3a:53:9c - Received switch event message, channel: 2, state: 0
2021-09-05 12:48:49 DEBUG (MainThread) [zhaquirks.tuya] 84:2e:14:ff:fe:3a:53:9c - Received switch event message, channel: 2, state: 0
2021-09-05 12:48:49 DEBUG (MainThread) [zhaquirks.tuya] 84:2e:14:ff:fe:3a:53:9c - Received switch event message, channel: 2, state: 0
2021-09-05 12:48:49 DEBUG (MainThread) [zhaquirks.tuya] 84:2e:14:ff:fe:3a:53:9c - Received switch event message, channel: 2, state: 0
2021-09-05 12:48:49 DEBUG (MainThread) [zhaquirks.tuya] 84:2e:14:ff:fe:3a:53:9c - Received switch event message, channel: 2, state: 0
2021-09-05 12:48:50 DEBUG (MainThread) [zhaquirks.tuya] 84:2e:14:ff:fe:3a:53:9c - Received switch event message, channel: 2, state: 0
2021-09-05 12:48:50 DEBUG (MainThread) [zhaquirks.tuya] 84:2e:14:ff:fe:3a:53:9c - Received switch event message, channel: 2, state: 0
2021-09-05 12:48:50 DEBUG (MainThread) [zhaquirks.tuya] 84:2e:14:ff:fe:3a:53:9c - Received switch event message, channel: 2, state: 0
2021-09-05 12:48:50 DEBUG (MainThread) [zhaquirks.tuya] 84:2e:14:ff:fe:3a:53:9c - Received switch event message, channel: 2, state: 0
2021-09-05 12:48:50 DEBUG (MainThread) [zhaquirks.tuya] 84:2e:14:ff:fe:3a:53:9c - Received switch event message, channel: 2, state: 0
2021-09-05 12:48:51 DEBUG (MainThread) [zhaquirks.tuya] 84:2e:14:ff:fe:3a:53:9c - Received switch event message, channel: 2, state: 0
2021-09-05 12:48:51 DEBUG (MainThread) [zhaquirks.tuya] 84:2e:14:ff:fe:3a:53:9c - Received switch event message, channel: 2, state: 0
~ $

Is it normal for a switch to spam the system with status messages? One click comes a couple of dozen identical messages
PS: Sorry for unformatted messages, cannot remind keys :)

AFK, sorry
Will return tonight or tomorrow morning.

Put ```before and after the code and its being treated as one code block and can being easier to read.

The good thing you is getting command 0 and 1 from channel 1 and 2 = from both switches :-))
Strange that tuya quirk is getting the commands with IEEEE address and not Nwk address.
Is zigpy also using the IEEE or the Mwk address for this device then receiving and sending commands to this device ?
For multiple command you need look in the ZHA receiving commands if they is having the same tsn (transaction number). ZHA is sending default response for all ZCL commands if its flagged as needed but tuya is using no ZCL cluster so it need one manual action in the quirk for sending it or the device is reseeding the same command with the same tsn then not getting and ack for it.
One example of attribute reporting (from one light):
2021-09-05 12:10:15 DEBUG (MainThread) [zigpy.zcl] [0xefd5:1:0x0300] ZCL deserialize: <ZCLHeader frame_control=<FrameControl frame_type=GLOBAL_COMMAND manufacturer_specific=False is_reply=True disable_default_response=False> manufacturer=None tsn=70 command_id=Command.Report_Attributes>
2021-09-05 12:10:15 DEBUG (MainThread) [zigpy.zcl] [0xefd5:1:0x0300] ZCL request 0x000a: [[Attribute(attrid=3, value=<TypeValue type=uint16_t, value=32768>), Attribute(attrid=4, value=<TypeValue type=uint16_t, value=15729>)]]
2021-09-05 12:10:15 DEBUG (MainThread) [zigpy.zcl] [0xefd5:1:0x0300] Attribute report received: current_x=32768, current_y=15729
2021-09-05 12:10:15 DEBUG (MainThread) [bellows.zigbee.application] Set source route for 0xEFD5 to []: EmberStatus.SUCCESS

The tsn=70 is the interesting and then its one ZCL command its getting default response from the Zigbee stack but for tuya it can being is not being sent (then its not one ZCL cluster command its one custom command alla tuya) then the devices is reseeding the same command after some milliseconds with the same tsn.

The problem i cant see the default response part its implanted in the on/off part in the tuya quirk only for the Remote OnOff switches :-((

If ZHA already has quirk for ("_TZE200_wunufsil", "TS0601") and I make my file and put it in custom_zha_quirks, which of the quirks should be applied?

As I see, ZHA ignores custom quirk and uses internal one.

I have not testing but the devs have saying that the file in the custom quirk shall being used of the system if the system is having both.

I left my model in /config/custom_zha_quirks/ts0601.py and added an endpoint for the second port. After rebooting HA and removing / adding the switch, I see that the internal quirk is being used
Zigbee info
IEEE: 84:2e:14:ff:fe:3a:53:9c
Nwk: 0x74d3
Device Type: Router
LQI: 240
RSSI: -40
Last Seen: 2021-09-05T17:52:20
Power Source: Mains
Quirk: zhaquirks.tuya.ts0601.TuyaSingleSwitch

My quirk file content is:
"""Tuya based touch switch."""
from zigpy.profiles import zha
from zigpy.zcl.clusters.general import Basic, Groups, Ota, Scenes, Time

from zhaquirks.const import (
    DEVICE_TYPE,
    ENDPOINTS,
    INPUT_CLUSTERS,
    MODELS_INFO,
    OUTPUT_CLUSTERS,
    PROFILE_ID,
)
from zhaquirks.tuya import (
    TuyaManufacturerClusterOnOff,
    TuyaManufCluster,
    TuyaOnOff,
    TuyaSwitch
)

class TuyaMySwitch(TuyaSwitch):
    """Tuya touch switch device."""

    signature = {
        # "node_descriptor": "<NodeDescriptor byte1=1 byte2=64 mac_capability_flags=142 manufacturer_code=4098
        #                       maximum_buffer_size=82 maximum_incoming_transfer_size=82 server_mask=11264
        #                       maximum_outgoing_transfer_size=82 descriptor_capability_field=0>",
        # device_version=1
        # input_clusters=[0x0000, 0x0004, 0x0005, 0xef00]
        # output_clusters=[0x000a, 0x0019]
        # <SimpleDescriptor endpoint=1 profile=260 device_type=51 device_version=1 input_clusters=[0, 4, 5, 61184] output_clusters=[10, 25]>
        MODELS_INFO: [
            ("_TZE200_wunufsil", "TS0601")
        ],
        ENDPOINTS: {
            1: {
                PROFILE_ID: zha.PROFILE_ID,
                DEVICE_TYPE: zha.DeviceType.SMART_PLUG,
                INPUT_CLUSTERS: [
                    Basic.cluster_id,
                    Groups.cluster_id,
                    Scenes.cluster_id,
                    TuyaManufCluster.cluster_id,
                ],
                OUTPUT_CLUSTERS: [Time.cluster_id, Ota.cluster_id],
            },
            2: {
                PROFILE_ID: zha.PROFILE_ID,
                DEVICE_TYPE: zha.DeviceType.SMART_PLUG,
                INPUT_CLUSTERS: [
                    Basic.cluster_id,
                    Groups.cluster_id,
                    Scenes.cluster_id,
                    TuyaManufCluster.cluster_id,
                ],
                OUTPUT_CLUSTERS: [Time.cluster_id, Ota.cluster_id],
            }
        },
    }

    replacement = {
        ENDPOINTS: {
            1: {
                DEVICE_TYPE: zha.DeviceType.ON_OFF_LIGHT,
                INPUT_CLUSTERS: [
                    Basic.cluster_id,
                    Groups.cluster_id,
                    Scenes.cluster_id,
                    TuyaManufacturerClusterOnOff,
                    TuyaOnOff,
                ],
                OUTPUT_CLUSTERS: [Time.cluster_id, Ota.cluster_id],
            },
            2: {
                DEVICE_TYPE: zha.DeviceType.ON_OFF_LIGHT,
                INPUT_CLUSTERS: [
                    Basic.cluster_id,
                    Groups.cluster_id,
                    Scenes.cluster_id,
                    TuyaManufacturerClusterOnOff,
                    TuyaOnOff,
                ],
                OUTPUT_CLUSTERS: [Time.cluster_id, Ota.cluster_id],
            }
        }
    }

Maybe TuyaSwitch class contains only one port switch signatures? And for two port switch another parent class must be used?

I think it can not being triggered then the signature is not being the switch is only having endpoint 1.
Look wot the "Zigbee device signature" from the device card if its have only EP1 or if its loaded also EP2.
In the log you was getting tuya DP commands from 2 channels 1 and 2 that is the 2 switches you is having on your device.

{
  "node_descriptor": "NodeDescriptor(logical_type=<LogicalType.Router: 1>, complex_descriptor_available=0, user_descriptor_available=0, reserved=0, aps_flags=0, frequency_band=<FrequencyBand.Freq2400MHz: 8>, mac_capability_flags=<MACCapabilityFlags.AllocateAddress|RxOnWhenIdle|MainsPowered|FullFunctionDevice: 142>, manufacturer_code=4098, maximum_buffer_size=82, maximum_incoming_transfer_size=82, server_mask=11264, maximum_outgoing_transfer_size=82, descriptor_capability_field=<DescriptorCapability.NONE: 0>, *allocate_address=True, *is_alternate_pan_coordinator=False, *is_coordinator=False, *is_end_device=False, *is_full_function_device=True, *is_mains_powered=True, *is_receiver_on_when_idle=True, *is_router=True, *is_security_capable=False)",
  "endpoints": {
    "1": {
      "profile_id": 260,
      "device_type": "0x0100",
      "in_clusters": [
        "0x0000",
        "0x0004",
        "0x0005",
        "0x0006",
        "0xef00"
      ],
      "out_clusters": [
        "0x000a",
        "0x0019"
      ]
    }
  },
  "manufacturer": "_TZE200_wunufsil",
  "model": "TS0601",
  "class": "zhaquirks.tuya.ts0601.TuyaSingleSwitch"
}

The single switch quirk  is made for single switches but no one have doing one quirk for multi gang tuya switches so that logic need being added for the second gang to working OK :-((
The device is using the internal quirk in ZHA then its only having EP1 (your quirk shall have showing EP 2 and 2).

The device is using the internal quirk in ZHA then its only having EP1 (your quirk shall have showing EP 2 and 2).

I see. But WHY internal quirk is used? There is definition for "manufacturer": "_TZE200_wunufsil",
"model": "TS0601" in custom_zha_quirks/ts0601.py, and this file must override internal definitions, isn't it?

In addition to simple overrides, does quirk assume some kind of processing logic in parent classes that cannot be defined in quirk for a particular model, if there is no corresponding processing part above?

First this part must matching the quirk signature for it shall being loaded:
{
  "node_descriptor": "NodeDescriptor(logical_type=<LogicalType.Router: 1>, complex_descriptor_available=0, user_descriptor_available=0, reserved=0, aps_flags=0, frequency_band=<FrequencyBand.Freq2400MHz: 8>, mac_capability_flags=<MACCapabilityFlags.AllocateAddress|RxOnWhenIdle|MainsPowered|FullFunctionDevice: 142>, manufacturer_code=4098, maximum_buffer_size=82, maximum_incoming_transfer_size=82, server_mask=11264, maximum_outgoing_transfer_size=82, descriptor_capability_field=<DescriptorCapability.NONE: 0>, *allocate_address=True, *is_alternate_pan_coordinator=False, *is_coordinator=False, *is_end_device=False, *is_full_function_device=True, *is_mains_powered=True, *is_receiver_on_when_idle=True, *is_router=True, *is_security_capable=False)",
  "endpoints": {
    "1": {
      "profile_id": 260,
      "device_type": "0x0100",
      "in_clusters": [
        "0x0000",
        "0x0004",
        "0x0005",
        "0x0006",
        "0xef00"
      ],
      "out_clusters": [
        "0x000a",
        "0x0019"
      ]
    }
  },
  "manufacturer": "_TZE200_wunufsil",
  "model": "TS0601",
  "class": "zhaquirks.tuya.ts0601.TuyaSingleSwitch"
}

If its not ZHA is not using the quirk (miss match error in the log).
The logic i cant telling then i dont knowing it in real but the devs have saying custom quirks is taking over internal ones if the signature is OK.
The limiting is all custom quirks is using its import from the internal ones so can having 2 custom quirks that is depending of etch other then one or both need being patched in the HA container.
You can trying editing the quirk in the container as https://github.com/zigpy/zha-device-handlers/discussions/693#discussion-1237451.

021-09-05 18:57:17 DEBUG (MainThread) [zigpy.application] Device is initialized <Device model='TS0601' manuf='_TZE200_wunufsil' nwk=0xD933 ieee=84:2e:14:ff:fe:3a:53:9c is_initialized=True>
2021-09-05 18:57:17 DEBUG (MainThread) [zigpy.quirks.registry] Checking quirks for _TZE200_wunufsil TS0601 (84:2e:14:ff:fe:3a:53:9c)
2021-09-05 18:57:17 DEBUG (MainThread) [zigpy.quirks.registry] Considering <class 'ts0601.TuyaDoubleSwitch'>
2021-09-05 18:57:17 DEBUG (MainThread) [zigpy.quirks.registry] Fail because endpoint list mismatch: {1, 2} {1}
2021-09-05 18:57:17 DEBUG (MainThread) [zigpy.quirks.registry] Considering <class 'zhaquirks.tuya.ts0601.TuyaSingleSwitch'>

Fail because endpoint list mismatch: {1, 2} {1}
Thus, without access to the logic of the parent classes, we will not solve anything.
Alas

Use the signature from the original 1 button and only changing the "replace" part.
The parent is defined in the https://github.com/zigpy/zha-device-handlers/blob/dev/zhaquirks/tuya/init.py.
But if you can doing changes in both in the custom quirk folder then both is "reading" from ther parents in the internal (the HA container) and then must doing the changed in it (at last the __init__.py) in the container.

This must being unchaged or the quirk is not being loaded (the "name" is OK to changing).
class TuyaSingleSwitch(TuyaSwitch):
    """Tuya touch switch device."""

    signature = {
        # "node_descriptor": "<NodeDescriptor byte1=1 byte2=64 mac_capability_flags=142 manufacturer_code=4098
        #                       maximum_buffer_size=82 maximum_incoming_transfer_size=82 server_mask=11264
        #                       maximum_outgoing_transfer_size=82 descriptor_capability_field=0>",
        # device_version=1
        # input_clusters=[0x0000, 0x0004, 0x0005, 0xef00]
        # output_clusters=[0x000a, 0x0019]
        # <SimpleDescriptor endpoint=1 profile=260 device_type=51 device_version=1 input_clusters=[0, 4, 5, 61184] output_clusters=[10, 25]>
        MODELS_INFO: [
            ("_TZE200_oisqyl4o", "TS0601"),
            ("_TZE200_wunufsil", "TS0601"),
            ("_TZE200_vhy3iakz", "TS0601"),
            ("_TZ3000_uim07oem", "TS0601"),
            ("_TZE200_tz32mtza", "TS0601"),
        ],
        ENDPOINTS: {
            1: {
                PROFILE_ID: zha.PROFILE_ID,
                DEVICE_TYPE: zha.DeviceType.SMART_PLUG,
                INPUT_CLUSTERS: [
                    Basic.cluster_id,
                    Groups.cluster_id,
                    Scenes.cluster_id,
                    TuyaManufCluster.cluster_id,
                ],
                OUTPUT_CLUSTERS: [Time.cluster_id, Ota.cluster_id],
            }
        },
    }

Do editing after the replace that is here:
    replacement = {
        ENDPOINTS: {
            1: {
                DEVICE_TYPE: zha.DeviceType.ON_OFF_LIGHT,
                INPUT_CLUSTERS: [
                    Basic.cluster_id,
                    Groups.cluster_id,
                    Scenes.cluster_id,
                    TuyaManufacturerClusterOnOff,
                    TuyaOnOff,
                ],
                OUTPUT_CLUSTERS: [Time.cluster_id, Ota.cluster_id],
            }
        }
    }
```

If I leave the signature with one endpoint, and describe two endpoints in replacement, then zha does not start at all

Its one tuya device quirk that is adding EP2 but i dont knowing how its working doing it https://github.com/zigpy/zha-device-handlers/pull/926.

OK. Will try to read parent classes and understand the logic. Tomorrow...

I'v got two entities for now.
Added cluster_id and PROFILE_ID in replacement section.
PS: Sometimes whiskey is not only harmful, but also useful)

THAT i believe !!!!
Great :-))
Then you need catching the channel: 2, state: 1 from the tuya DP decoding.

Second button press ON:
[0xc471:1:0xef00] ZCL request 0x0002: [Command(status=0, tsn=132, command_id=258, function=0, data=[1, 1])]
[0xc471:1:0xef00] ZCL deserialize: <ZCLHeader frame_control=<FrameControl frame_type=CLUSTER_COMMAND manufacturer_specific=False is_reply=True disable_default_response=False> manufacturer=None tsn=7 command_id=2>
[0xc471:1:0xef00] ZCL request 0x0002: [Command(status=0, tsn=132, command_id=258, function=0, data=[1, 1])]
[0xc471:1:0xef00] ZCL deserialize: <ZCLHeader frame_control=<FrameControl frame_type=CLUSTER_COMMAND manufacturer_specific=False is_reply=True disable_default_response=False> manufacturer=None tsn=7 command_id=2>
[0xc471:1:0xef00] ZCL request 0x0002: [Command(status=0, tsn=132, command_id=258, function=0, data=[1, 1])]
[0xc471:1:0xef00] ZCL deserialize: <ZCLHeader frame_control=<FrameControl frame_type=CLUSTER_COMMAND manufacturer_specific=False is_reply=True disable_default_response=False> manufacturer=None tsn=7 command_id=2>
[0xc471:1:0xef00] ZCL request 0x0002: [Command(status=0, tsn=132, command_id=258, function=0, data=[1, 1])]
[0xc471:1:0xef00] ZCL deserialize: <ZCLHeader frame_control=<FrameControl frame_type=CLUSTER_COMMAND manufacturer_specific=False is_reply=True disable_default_response=False> manufacturer=None tsn=7 command_id=2>
[0xc471:1:0xef00] ZCL request 0x0002: [Command(status=0, tsn=132, command_id=258, function=0, data=[1, 1])]

Second button press OFF:
[0xc471:1:0xef00] ZCL request 0x0002: [Command(status=0, tsn=133, command_id=258, function=0, data=[1, 0])]
[0xc471:1:0xef00] ZCL deserialize: <ZCLHeader frame_control=<FrameControl frame_type=CLUSTER_COMMAND manufacturer_specific=False is_reply=True disable_default_response=False> manufacturer=None tsn=8 command_id=2>
[0xc471:1:0xef00] ZCL request 0x0002: [Command(status=0, tsn=133, command_id=258, function=0, data=[1, 0])]
[0xc471:1:0xef00] ZCL deserialize: <ZCLHeader frame_control=<FrameControl frame_type=CLUSTER_COMMAND manufacturer_specific=False is_reply=True disable_default_response=False> manufacturer=None tsn=8 command_id=2>
[0xc471:1:0xef00] ZCL request 0x0002: [Command(status=0, tsn=133, command_id=258, function=0, data=[1, 0])]
[0xc471:1:0xef00] ZCL deserialize: <ZCLHeader frame_control=<FrameControl frame_type=CLUSTER_COMMAND manufacturer_specific=False is_reply=True disable_default_response=False> manufacturer=None tsn=8 command_id=2>
[0xc471:1:0xef00] ZCL request 0x0002: [Command(status=0, tsn=133, command_id=258, function=0, data=[1, 0])]
[0xc471:1:0xef00] ZCL deserialize: <ZCLHeader frame_control=<FrameControl frame_type=CLUSTER_COMMAND manufacturer_specific=False is_reply=True disable_default_response=False> manufacturer=None tsn=8 command_id=2>
[0xc471:1:0xef00] ZCL request 0x0002: [Command(status=0, tsn=133, command_id=258, function=0, data=[1, 0])]

What I must change in quirk?

The quirk file is:
"""Tuya based touch switch."""
from zigpy.profiles import zha
from zigpy.zcl.clusters.general import Basic, Groups, Ota, Scenes, Time

from zhaquirks.const import (
    DEVICE_TYPE,
    ENDPOINTS,
    INPUT_CLUSTERS,
    MODELS_INFO,
    OUTPUT_CLUSTERS,
    PROFILE_ID,
)
from zhaquirks.tuya import (
    TuyaManufacturerClusterOnOff,
    TuyaManufCluster,
    TuyaOnOff,
    TuyaSwitch
)

class TuyaMySwitch(TuyaSwitch):
    """Tuya touch switch device."""

    signature = {
        # "node_descriptor": "<NodeDescriptor byte1=1 byte2=64 mac_capability_flags=142 manufacturer_code=4098
        #                       maximum_buffer_size=82 maximum_incoming_transfer_size=82 server_mask=11264
        #                       maximum_outgoing_transfer_size=82 descriptor_capability_field=0>",
        # device_version=1
        # input_clusters=[0x0000, 0x0004, 0x0005, 0xef00]
        # output_clusters=[0x000a, 0x0019]
        # <SimpleDescriptor endpoint=1 profile=260 device_type=51 device_version=1 input_clusters=[0, 4, 5, 61184] output_clusters=[10, 25]>
        MODELS_INFO: [
            ("_TZE200_wunufsil", "TS0601")
        ],
        ENDPOINTS: {
            1: {
                PROFILE_ID: zha.PROFILE_ID,
                DEVICE_TYPE: zha.DeviceType.SMART_PLUG,
                INPUT_CLUSTERS: [
                    Basic.cluster_id,
                    Groups.cluster_id,
                    Scenes.cluster_id,
                    TuyaManufCluster.cluster_id,
                ],
                OUTPUT_CLUSTERS: [Time.cluster_id, Ota.cluster_id],
            },
        },
    }

    replacement = {
        ENDPOINTS: {
            1: {
                PROFILE_ID: zha.PROFILE_ID,
                DEVICE_TYPE: zha.DeviceType.ON_OFF_LIGHT,
                INPUT_CLUSTERS: [
                    Basic.cluster_id,
                    Groups.cluster_id,
                    Scenes.cluster_id,
                    TuyaManufacturerClusterOnOff,
                    TuyaOnOff,
                ],
                OUTPUT_CLUSTERS: [Time.cluster_id, Ota.cluster_id],
            },
            2: {
                PROFILE_ID: zha.PROFILE_ID,
                DEVICE_TYPE: zha.DeviceType.ON_OFF_LIGHT,
                INPUT_CLUSTERS: [
                    Basic.cluster_id,
                    Groups.cluster_id,
                    Scenes.cluster_id,
                    TuyaManufacturerClusterOnOff,
                    TuyaOnOff,
                ],
                OUTPUT_CLUSTERS: [Time.cluster_id, Ota.cluster_id],
            },
        },
    }

Device signature:
{
  "node_descriptor": "NodeDescriptor(logical_type=<LogicalType.Router: 1>, complex_descriptor_available=0, user_descriptor_available=0, reserved=0, aps_flags=0, frequency_band=<FrequencyBand.Freq2400MHz: 8>, mac_capability_flags=<MACCapabilityFlags.AllocateAddress|RxOnWhenIdle|MainsPowered|FullFunctionDevice: 142>, manufacturer_code=4098, maximum_buffer_size=82, maximum_incoming_transfer_size=82, server_mask=11264, maximum_outgoing_transfer_size=82, descriptor_capability_field=<DescriptorCapability.NONE: 0>, *allocate_address=True, *is_alternate_pan_coordinator=False, *is_coordinator=False, *is_end_device=False, *is_full_function_device=True, *is_mains_powered=True, *is_receiver_on_when_idle=True, *is_router=True, *is_security_capable=False)",
  "endpoints": {
    "1": {
      "profile_id": 260,
      "device_type": "0x0100",
      "in_clusters": [
        "0x0000",
        "0x0004",
        "0x0005",
        "0x0006",
        "0xef00"
      ],
      "out_clusters": [
        "0x000a",
        "0x0019"
      ]
    },
    "2": {
      "profile_id": 260,
      "device_type": "0x0100",
      "in_clusters": [
        "0x0000",
        "0x0004",
        "0x0005",
        "0x0006",
        "0xef00"
      ],
      "out_clusters": [
        "0x000a",
        "0x0019"
      ]
    }
  },
  "manufacturer": "_TZE200_wunufsil",
  "model": "TS0601",
  "class": "ts0601.TuyaMySwitch"
}

Pressing on any button on switch results changing state of both entities in HA
Something is missing in this solution :))

Switching the second entity state do not change state of second button on physical device

You dont need most of the clusters on the second end point basic can being good but group and scene is no use and the out clusters is not needed.
You must "catching" the commands from the tuya decoder and sending them to the cluster on the right end point for both EP1 and 2.
Look how things is made on other tuya quirks and see if you can find some clue how to do it.
For the spamming is the TS004X implanting logic for fixing it:
https://github.com/zigpy/zha-device-handlers/blob/28bd89a2f34da9a15dd37370734af4e222850316/zhaquirks/tuya/__init__.py#L661

One more thing: both entities of this device have the same name.

You must "catching" the commands from the tuya decoder and sending them to the cluster on the right end point for both EP1 and 2.

How can I do it? What to do?

For the spamming is the TS004X implanting logic for fixing it

As I can see in container - string 601 is already the same as in https://github.com/zigpy/zha-device-handlers/blob/28bd89a2f34da9a15dd37370734af4e222850316/zhaquirks/tuya/init.py#L661

If you is getting zha_event you can see that the ID is different from EP1 and the events from EP2.
For the tuya DP thing i dont knowing at all but some have doing some magic with other tuya devices so look if you can finding some that ts transforming events to one new cluster (TRV, Dimmer and clovers and so on).

HA->Developer Tools->Events->zha_event->Start Listening catches nothing
I can see come traffic in ZHA in adding mode.

I dont knowing how to do that  :-(((

Maybe You've got the person to ask a question? :)

Adminiuga is 110% knowing but its looks like hi is not having time digging in this for the moment.

any progress here? also have few devices with more than one EndPoint

We are waiting for Adminiuga to try to do what only he can do.

If this device really is a switch with 2 states (on/off), I think it could be removed from the MODELS_INFO of the TuyaSingleSwitchTO and be added to the TuyaDoubleSwitchTO.
Removed from here
https://github.com/zigpy/zha-device-handlers/blob/4682b810447efd95e4d4a62bb0f9b4a642b2e23c/zhaquirks/tuya/ts0601_switch.py#L78-L85
Added here:
https://github.com/zigpy/zha-device-handlers/blob/4682b810447efd95e4d4a62bb0f9b4a642b2e23c/zhaquirks/tuya/ts0601_switch.py#L129-L131
Would someone be kind enough to validate it before generating the PR?

I have adding some of them but i need looking with is 2 and 3 gangs switches.
I shall doing little more debug on my TRVs and then i trying getting all checked if being 1, 2 or 3 gangs and reporting back !!

I believe that On/Off type devices can be arranged with the same quirk (using TuyaOnOff cluster).
Dimmer type devices (such as # 1033) and scene triggering devices will need to be adjusted.
Unfortunately, I don't have any of this kind of device to test myself, but I can try to help where I can.

I have getting 100% match for one 1G, 2G and 3G but 3 is shoeing up as different configuration.
     ("_TZE200_oisqyl4o", "TS0601"), 1G OK / 3G ?
     ("_TZE200_wunufsil", "TS0601"), 2G OK
     ("_TZE200_vhy3iakz", "TS0601"), 1-4G ?
     ("_TZ3000_uim07oem", "TS0601"), 1-4G ?
     ("_TZE200_tz32mtza", "TS0601"), 3G OK
     ("_TZE200_amp6tsvy", "TS0601"), 1G OK

For the verified move to the new right G types.
For the insecure leave them and we can moving / adding them later /better then braking devices for users).

Whats happen if putting the "_TZE200_oisqyl4o" in the 3 gang class ?
For receiving  events shall not being any problem but then sending commands for configuring gangs it can being problems.
If its working OK perhaps putting all with more then one gang i 4 (or 6 gang) class ?

N gangs --> N endpoints --> N entities in HA

I think that for users it might be strange that appear in HA more entities than the device has.
In addition, is not the objective of the quirk to adjust the operation to the reality of the device?
IMHO putting all the devices, despite the gang number, in a single 'N gang' class shouldn't be the way to go.

I think the same but i hoping tuya have not doing switches with the same ID with different gangs then we have problems but if its only some it can being added in one 4 gang class but normally all shall being i the right class for the number of gangs for making it more secure in the future.

i hoping tuya have not doing switches with the same ID with different gangs

I was not aware of that.
In that case, using a device with N gang would be the "lesser evil". But somehow Tuya gateway must have to differentiate the devices even in this case, right?
It is clear that trying to understand how Tuya devices work is an impossible task.

tuya can reading the version of the MCU firmware and getting information from its cloud (we cant for the moment).
And tuya "DP" devices can only working with cloud connection then being added the the DP is more or less MQTT commands tunneled thru Zigbee from the device MCU to the cloud that is manager the device and the tuya ZBGW is only sending commands to the cloud and tunneling the command to the device back to it.
Also many tuya MCU is used with different RF chips like WiFi and 433Mhz.
If the user can not providing correct information = no adding in the quirk is the only way and documenting the model added in the PR.
I have trying doing this was tuya TRVs that was one complete mess after user have adding wrong device in the wrong class and braking many TRVs.
So i think the 3 devices with perhaps 2 or more gangs staying in 1 gang class and if user have more gangs adding it in the higher gang (and deleting it in the lower) but doing one note in the PR for future problems.

tuya can reading the version of the MCU firmware and getting information from its cloud (we cant for the moment).
And tuya "DP" devices can only working with cloud connection then being added the the DP is more or less MQTT commands tunneled thru Zigbee from the device MCU to the cloud that is manager the device and the tuya ZBGW is only sending commands to the cloud and tunneling the command to the device back to it. Also many tuya MCU is used with different RF chips like WiFi and 433Mhz.
If the user can not providing correct information = no adding in the quirk is the only way and documenting the model added in the PR.
I have trying doing this was tuya TRVs that was one complete mess after user have adding wrong device in the wrong class and braking many TRVs.
So i think the 3 devices with perhaps 2 or more gangs staying in 1 gang class and if user have more gangs adding it in the higher gang (and deleting it in the lower) but doing one note in the PR for future problems.

I agree that it is the safest option. Keep devices at 1G version until some user opens an issue.
I think it is a good option to add a comment in the code to prevent from being reported in the opposite direction by other user and the change being undone again.

Then you have getting all in place i can looking around in issues and posting questions to user if they can trying adding there devices in local quirk and getting it working before adding / changing devices.
First round is the devices we have adding before that is making problems now.

PR created: #1166
Except devices _TZE200_vhy3iakz and _TZ3000_uim07oem, all the others have been reported somewhere.


feat($log): add console.table method

useful method to get a table representation in console

The methods $log provides are not meant to mirror every method console provides. $log only writes by default to console, but if you have another implementation, for example writing to a remote log service, methods like table etc. would not really make a lot of sense. On the other hand, log, info, warn, error and debug are common error levels. I suggest you use a decorator to add the missing methods if you use them often.


rework long-term authentication

The current architecture is inherently insecure, because you can construct the 'secret' cookie value with values that are available in the database. Thus provides zero protection when a database is dumped/leaked.
This patch implements a new architecture that's inspired from: Paragonie Initiative.
Integration testing is added to ensure the new mechanism works.
Removes a setting, because it's not used anymore.

Refs: https://codeberg.org/forgejo/forgejo/pulls/1562

I just would like to mention what I ever saw:

The request that I remove the Forgejo copyright header is:
* not a technical blocker
* not a legal requirement
* not a requirement of the contributing guidelines

I have always consistently respected the Gitea guidelines in all my pull requests.

Please be realistic, and do not try to catch every chance to create friction.
The contributing guideline has had this since 7 years ago: https://github.com/go-gitea/gitea/commit/a90b25226a4dae41c439f4d4919ef07e21b2ad43?short_path=eca12c0#diff-eca12c0a30e25b4b46522ebf89465a03ba72a03f540796c979137931d8f92055

And it has been updated to use SPDX format: https://github.com/go-gitea/gitea/blame/16a766cba10dcaf53cc413cee62a952031bef5bc/CONTRIBUTING.md#L430

techknowlogick in your capacity as TOC member and Gitea Ltd. shareholder (sole owner of the domain and the trademark) you inform me that this is a hard requirement for the first time. You have authority to do so and I do not dispute this.

This is an open-source community, please do not try to attack Gitea by your "company" speech.

However, please understand this is news to me and do not claim that I acted in bad faith or that I could have been informed of this requirement in the past.

This is not the first time. I also consider that's your bad action. Have you forgotten your PR " add Upload URL to release API #26663 " ?
Some soft-fork people have created too many lies to Gitea and Gitea's contributors and really harmed Gitea.

Temporarily locked the thread to prevent escalation.


VDC: Add capacity check before showing payment for extending kubernetes with an extra node

After paying for an extra node, got not enough resources error

Please verify and close if solved.  Otherwise, push back to "in progress"

Branch: development
Commit: c19232ed8b78a03fb1765664afdeb120e8b48f2d
Verified


Support for deployment.scale.capacity

Is there an existing issue for this?

[X] I have searched the existing issues

Description
The capacity value is required to define the tokens per minute value.
It would be amazing if we could adjust that value.
New or Affected Resource(s)/Data Source(s)
terraform-azurerm-openai
Potential Terraform Configuration
module "openai" {
  source                        = "../.."
  resource_group_name           = azurerm_resource_group.this.name
  location                      = azurerm_resource_group.this.location
  public_network_access_enabled = true
  deployment = {
    "text-davinci-003" = {
      name          = "text-davinci-003"
      model_format  = "OpenAI"
      model_name    = "text-davinci-003"
      model_version = "1"
      scale_type    = "Standard"
      # 10 = 10k token per minute
      capacity      = 10
    },
  }
  depends_on = [
    azurerm_resource_group.this
  ]
}

References
No response

Hello @joecks ,
I see the provider supports capacity:
https://registry.terraform.io/providers/hashicorp/azurerm/latest/docs/resources/cognitive_deployment#capacity
do you want to propose a PR for review ?
you need to add the capacity to the object in the deployment variable:
https://github.com/Azure/terraform-azurerm-openai/blob/8843bb4b07a595dd96d83457ac00988fd568fb81/variables.tf#L50-L76
and use it accordingly in the azurerm_cognitive_deployment resource:
https://github.com/Azure/terraform-azurerm-openai/blob/8843bb4b07a595dd96d83457ac00988fd568fb81/main.tf#L74-L89
please let us know if you want to submit a PR for review.
thanks

Yes, done.

Completed via #45


Upgrade from 4.11 -> 4.14 results in 'Decimal' constructor name changing to 'i'

Bug description
We have a backend function that processes Decimals and converts them to floats on Prisma 4.11 that no longer works after upgrading to Prisma 4.14. Using recent Node + NextJS 12 + PostgreSQL.
Our code checks for this condition on a value returned by Prisma:
if (typeof val == 'object' && val?.constructor?.name == 'Decimal') {
Just attempted to upgrade to Prisma 4.14, and the constructor name for Decimals now shows as i rather than 'Decimal':

This looks like a bug to me, as other constructors still return proper type names rather than letters of the alphabet.
How to reproduce

Write a Prisma 4.11 client with a DB with 'Decimal' values, using Prisma @db.decimal in your schema and a PSQL database
Upgrade to Prisma 4.14.
Query a Decimal record from Prisma.
Check that value's constructor's name (result: 'i')

Expected behavior
Expecting 'Decimal' constructor name when checking a Decimal value returned from Prisma
Prisma information

model SomeModel {
    decimalValue      Decimal? @db.Decimal
}```

```ts
const record = await prisma.someModel... // query by id: ID, you get the idea

Environment & setup

OS: Every environment
Database: PostgreSQL
Node.js version: Every node version

Prisma Version
prisma 4.14 after upgrade from 4.11 and full yarn rebuild etc

Hi @n-glaz.
While I acknowledge the bug and we'll fix it at some point, better way to check for decimal is Prisma.Decimal.isDecimal(value).  I'd suggest to use that instead of constructor name.

Hey @SevInf,
Do you have any news about the fix? Thanks


Reorganize docs content

Here's a preliminary outline/proposal (started implementation with v0.9.0 -- see PR #639 ):
Install
Run
  - backups, with or without schedule
  - everything
      - specific objects/etc
  -  restore
     -  everything
     -  specific objects/etc -- can you restore only bits from an everything restore?
Customize
    - build from source
    - extend
Reference
Tutorials (based on solid use cases -- see issue #372 and linked PR #346 )

Not accounted for: restic integation. Two possible approaches:

keep separate (what we have now, but separate how it works into separate topic/file)
interleave with non-restic instructions (still want separate topic for how restic works)

N.B. This is a proposal only. Please feel free to suggest changes, or submit docs PRs that reflect a different approach.

can you restore only bits from an everything restore?

Yes

duplicate


feat: add functionality to check spf includes a domain

:tada: This PR is included in version 1.0.0-beta.1 :tada:
The release is available on:

npm package (@beta dist-tag)
GitHub release

Your semantic-release bot :package::rocket:

:tada: This PR is included in version 1.0.0 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


Shapely Buffering, not working as expected

SO Question
Why does buffering one of my geometries have an unexpected hole in it?
from shapely import LineString
from geopandas import GeoDataFrame

l = LineString([
  (250,447),
  (319,446),
  (325,387),
  (290,374),
  (259,378),
  (254,385),
  (240,409),
  (244,440),
  (250,447),
])

assert l.is_valid
assert l.is_simple

GeoDataFrame({'geometry': [
  l,
  l.buffer(80),
]}).plot(column='geometry')

This is uncommon, and by removing a pair of coordinates it doesn't have a hole.
When using Sedona's ST_Buffer this happened in more cases.
My hack to avoid this is:  tol=1e-3, l.buffer(tol).buffer(80-tol).
Serge's hack is:  tol=1e-3, l.simplify(tol).buffer(80)

This is an upstream bug: https://github.com/locationtech/jts/issues/876


Use of Wrong Operator in String Comparison

In ViewVisitor class String checking with '==' operator which cause problematic to security engine.
 if (getEventName() == eventName) {}

Fixed in v5.9.0. Thanks @wasir59 for bringing it up.


Cannot set Select to an empty value.

Maybe this is something very obvious that I'm not understanding, but I've checked out the shadcn-ui and the radix/primitives docs and I can't figure this out.
Here's my code:
const SelectField: React.FunctionComponent<SelectFieldProps> = ({
  helper,
  id,
  label,
  name,
  onChange,
  options,
  placeholder,
  ...props
}) => {
  const formContext = useFormContext();
  const { control } = formContext;

  return (
    <Control helper={helper} id={id} label={label} name={name}>
      <Controller
        control={control}
        name={name}
        render={({ field }) => {
          const { onChange: setValue, value, ...rest } = field;

          return (
            <Select
              onValueChange={(value) => {
                setValue(value);
                onChange && onChange(value);
              }}
              value={value}
              {...props}
              {...rest}
            >
              <SelectTrigger id={id}>
                <SelectValue placeholder={placeholder} />
              </SelectTrigger>

              <SelectContent>
                <SelectGroup>
                  {options.map((option) => (
                    <SelectItem key={option.id} value={option.value}>
                      {option.label}
                    </SelectItem>
                  ))}
                </SelectGroup>
              </SelectContent>
            </Select>
          );
        }}
      />
    </Control>
  );
};

For more context, I've created an abstraction on top of remix-hook-form for my own personal Form component, which takes all of the form context you create in RHF and transmits it to any descendant node within the tree.
Here's an example of my implementation in a form:
export default function Index() {
  const defaultValues = {
    input: "This is a `useForm` field!",
    select: "",
    switch: SwitchValues.On,
  };

  const schema = z.object({
    input: z.string().min(1, "Please enter a value."),
    select: z.string().min(1, "Please select a value."),
    switch: z.enum(["off", "on"]).optional(),
  });

  const { Form } = useForm({ defaultValues, schema });

  return (
    <Form action="/storybook" method="post">
      <InputField id="input" label="Input" name="input" />
      <SelectField
        id="select"
        label="Select"
        name="select"
        options={[
          { id: v4(), label: "Option 1", value: "this is option 1" },
          { id: v4(), label: "Option 2", value: "this is option 2" },
        ]}
        placeholder="Please select an option"
      />
      <SwitchField id="switch" label="Switch" name="switch" />
      <button type="submit">Submit</button>
    </Form>
  );
}

When I submit this form, the value for select returns as this is option 1, regardless of whether I've picked it or not. After looking at the MDN and playing with the native <select> tag a bit, this is actually the correct behavior. To create a blank <option> within the <select>, you need to add something like <option value="">Please select an option.</option>
I gave this a try by adding a new object to options, { id: v4(), label: "Please select an option.", value: "" }, however this explicitly didn't work. A <SelectItem> can't have a value of ''.
What am I missing here? Is there something I'm not doing to control the value of the <Select> right?

This issue has been automatically closed because it received no activity for a while. If you think it was closed by accident, please leave a comment. Thank you.

I have the same issue. I have no idea how to de-select this select input without tracking everything into a state.

To preface this, I've have an abstracted component around the Select component that takes an onChange function that I'm using to keep the state of the selected option. You can achieve this like with something like this.
<SelectItem
    value="null"
    onSelect={() => {
      onChange && onChange(null)
    }}>
    No Category
  </SelectItem>

@shadcn I think this issue should be reopened.
<SelectItem value={null}>All Colors</SelectItem>
This works for me. It clears the selected value, even though TS complains

Hi! I got the same problem and set default as null solve this. Well, TS complains about it due type, but it works. I don't know if it is a problem with zod (that's what I'm using).
import { z } from "zod";

export const genders = {female: "Female", male: "Male"} as const
type Gender = keyof typeof genders

export const formSchema = z.object({
	gender: z.enum(Object.keys(genders) as [Gender, ...Gender[]]).default(null),
})

export type FormSchema = typeof formSchema

<Form.Field {form} name="gender">
  <Form.Control let:attrs>
      <Form.Label>{$t("default.Gender")}</Form.Label>
      <Select.Root
      selected={selectedGender}
      onSelectedChange={(s) => {
	      s && ($formData.gender = s.value);
      }}
      >
      <Select.Input name={attrs.name} />
      <Select.Trigger {...attrs}>
	      <Select.Value placeholder="Select a gender" />
      </Select.Trigger>
      <Select.Content>
	      {#each Object.entries(genders) as [value, label]}
		      <Select.Item {value} {label} />
	      {/each}
      </Select.Content>
      </Select.Root>
  </Form.Control>
  <Form.FieldErrors />
</Form.Field>

Result

Hi everyone! Just use null! and when using zod add a .nullable() to field validation.
<SelectItem value={null!}>Other</SelectItem>

any update please?


Tweak how source paths are passed to the compiler

All paths printed will now be absolute paths unless the path is a descendant of
the current directory. This should keep error messages and warnings of a
reasonable length when working with the local project while still allowing
errors in registry/git dependencies to be tracked down.
Special care is taken in these situations to ensure that the error message from
the compiler prints a reasonable path.


Introduction should mention default keyboard shortcut

The Motivation
I was surprised to learn that the possibility to open the menu with a keyboard shortcut was not mentioned in the introduction, nor was the default shortcut for the example menu.
I assume many people want to test fly pie first without necessarily creating their own menu or checking the menu editor. The example menu is already very useful. So i think the introduction should mention and encourage the functionality to use the shortcut (and mention the option to change it e.g. to a special mouse key if possible).
The Solution
Add a paragraph that talks about keyboard shortcuts. Or add an exercise to open the menu with the keyboard.
I really like how the extension developed. The badges and exercises are fun and motivating. The editor is nice to look up.

That is a great idea. I'll do this for the next version!

I was coming to report the same thing!
The keyboard shortcut could be added in various places, because as a new user, I need to discover it easily :

at the beginning of the extension description "A marking menu which can be used to launch applications, simulate hotkeys ..." could be re-writed as "A marking menu. Press  [shortcut here] to launch applications, simulate hotkeys ..."
from the config window, in the About popup
from the config window, in the parameters, possibly on the left of the Preview button
at the very first part of the tutorial "You can use Fly-Pie to launch applications etc. (press [shortcut here]. This interactive tutorial etc."


Put in correct module name for BorutaPyPlus

Fixes import error because boruta_py2.py doesn't exist anymore.

Thanks a lot!