zigpy Multiple frames with the same ZCL counter trigger multiples events

I just bought the IKEA Tradfri shortcut button and when using it, it produces 6 to 7 frames with the same ZCL counter : this has the effect to produce the same amount of events in HA as well. Is this a normal behaviour?

According to this thread, not everyone has their remote doing it.

Here’s the device signature : IKEA Tradfri Shortcut button signature.

Here’s the log : HA log.

Also here’s a network capture showing the behaviour : network capture.

I am running HA 2021.2.0 and tried this quirk with a HUSBZB-1.

Thank you for your guidance!

Feb 21 '21 18:02 mguaylam

Its looks like one "normal" group command that is being sent from the normal 2 button switch but send with unicat instead broadcast thta is expected then its dont sending to one light group.

Broadcast shall being sent 3 times without default response from the "reviser". All "ZCL" unicast shall being replayed with one default response. All unicast that is not "ZCL" shall being acked from the app (its app <-> app communication not ZCL). (= manufacture specific clusters like tuya cluster)

You need showing all possible fields in your capture (excluding "zigbee security header" that showing your network key) also the IEEE 802.15.4 Data. And then looking for the ...0 .... = Disable Default Response: False and also all Sequence Number and Counter in one frame and comparing if its the same in the other frames.

Capture from one broadcast log = not 100% the same:

Frame 96: 113 bytes on wire (904 bits), 113 bytes captured (904 bits) on interface \Device\NPF_Loopback, id 0
Null/Loopback
Internet Protocol Version 4, Src: 127.0.0.1, Dst: 127.0.0.1
User Datagram Protocol, Src Port: 17754, Dst Port: 17754
ZigBee Encapsulation Protocol, Channel: 20, Length: 49
IEEE 802.15.4 Data, Dst: Broadcast, Src: 0xd502
    Frame Control Field: 0x8841, Frame Type: Data, PAN ID Compression, Destination Addressing Mode: Short/16-bit, Frame Version: IEEE Std 802.15.4-2003, Source Addressing Mode: Short/16-bit
>>>    Sequence Number: 154
    Destination PAN: 0xe758
    Destination: 0xffff
    Source: 0xd502
    [Extended Source: SiliconL_ff:fe:2a:d4:39 (90:fd:9f:ff:fe:2a:d4:39)]
    [Origin: 1]
    TI CC24xx-format metadata: FCS OK
ZigBee Network Layer Data, Dst: Broadcast, Src: 0xd29a
    Frame Control Field: 0x0248, Frame Type: Data, Discover Route: Enable, Security Data
    Destination: 0xfffd
    Source: 0xd29a
    Radius: 10
>>>    Sequence Number: 220
    [Extended Source: Ember_ff:fe:bc:cc:e0 (00:0d:6f:ff:fe:bc:cc:e0)]
    [Origin: 29]
    ZigBee Security Header
ZigBee Application Support Layer Data, Group: 0x0006, Src Endpt: 1
    Frame Control Field: Data (0x0c)
        .... ..00 = Frame Type: Data (0x0)
        .... 11.. = Delivery Mode: Group (0x3)
        ..0. .... = Security: False
<<<        .0.. .... = Acknowledgement Request: False
        0... .... = Extended Header: False
    Group: 0x0006
    Cluster: On/Off (0x0006)
    Profile: Home Automation (0x0104)
    Source Endpoint: 1
>>>    Counter: 241
ZigBee Cluster Library Frame
    Frame Control Field: Cluster-specific (0x01)
        .... ..01 = Frame Type: Cluster-specific (0x1)
>>>        .... .0.. = Manufacturer Specific: False
        .... 0... = Direction: Client to Server
<<<        ...0 .... = Disable Default Response: False
>>>    Sequence Number: 86
    Command: Off (0x00)

>>> = compare with other frames if is the same or changes. <<< = If shall being acked or not.

Feb 21 '21 18:02 MattWestb

In your HA log:

2021-02-21 11:36:55 DEBUG (MainThread) [zigpy.zcl] [0xeb19:1:0x0006] ZCL deserialize: <ZCLHeader frame_control=<FrameControl frame_type=CLUSTER_COMMAND manufacturer_specific=False is_reply=False disable_default_response=False> manufacturer=None tsn=47 command_id=1>

All command that is sensed from the the device is heaving the same transaction sequence number (tsn) tsn=47 and disable_default_response=False and its one ZCL command (not one manufacture cluster command) so the stack shall sending one default response if ZHA not have disabling it (in the quirk?) on the first received command and the devices is then not sending more "repeated " command.

Feb 21 '21 19:02 MattWestb

Need to see the IEEE 802.15.4 Ack:s sended after all commands from the device from the wireshark.

Feb 21 '21 19:02 MattWestb

If you like to see all Zigbee and IEEE 802.15.4 frames sensed and received from one device put one filter like this:(wpan.src64 == 00:0d:6f:ff:fe:bc:cc:e0) || (wpan.dst64 == 00:0d:6f:ff:fe:bc:cc:e0) || (wpan.src16 == 0xd29a) || (wpan.dst16 == 0xd29a) || (zbee_nwk.src == 0xd29a) || (zbee_nwk.dst == 0xd29a) and put the devices nwk and IEEE and you don't getting "other notice".

Feb 21 '21 19:02 MattWestb

Copy the filter string and pasting it in the filter box and then "enter" for activating it: Sniff01

Feb 21 '21 19:02 MattWestb

I have reading that de(f)CONZ have problem with SYMFONISK Sound Controller is spamming the network. Do some having the device and some good HA debug log or sniff ? Im interesting if its sending group commands or unicast and if sending the same tsn.

Feb 21 '21 20:02 MattWestb

I was doing one raid to IKEA earlier to day and was "finding" one Silverglans (then new LED drive) in the recycling corner for 15€ the shorcut one Symfonisk (BLACK) and the last new GU10 CWS3 (RGBW) in Wien.

The short is sending multiple then looking in ZHA events (also after long press the stop is multiple) so shall sniffing it little than i have time and the sniffer is free (from the batters draining... 24+ hours passes).

By the way great teem work getting the short up and running so fast !!!

And thanks both for doing the quirk !!!!

Mar 05 '21 13:03 MattWestb

By the way i was also finding the old wireless dimmer in the in the recycling corner for 4€ and its retro for my and @TheJulianJES have making it working working 110% in ZHA :-)))

Mar 05 '21 13:03 MattWestb

someone needs to experiment and send a default response to symfonisc and check the behavior

Mar 05 '21 15:03 Adminiuga

@Adminiuga is 110% correct !!

My new "Shorty" is sending in ZHA log:

2021-03-05 19:43:53 DEBUG (MainThread) [bellows.ezsp.protocol] Application frame 69 (incomingMessageHandler) received: b'0004010600010100010000b474b9fec4ffff03010b0102'
2021-03-05 19:43:53 DEBUG (MainThread) [bellows.zigbee.application] Received incomingMessageHandler frame with [<EmberIncomingMessageType.INCOMING_UNICAST: 0>, EmberApsFrame(profileId=260, clusterId=6, sourceEndpoint=1, destinationEndpoint=1, options=<EmberApsOption.APS_OPTION_ENABLE_ROUTE_DISCOVERY: 256>, groupId=0, sequence=180), 116, -71, 0xc4fe, 255, 255, b'\x01\x0b\x01']
2021-03-05 19:43:53 DEBUG (MainThread) [zigpy.zcl] [0xc4fe:1:0x0006] ZCL deserialize: <ZCLHeader frame_control=<FrameControl frame_type=CLUSTER_COMMAND manufacturer_specific=False is_reply=False disable_default_response=False> manufacturer=None tsn=11 command_id=1>
2021-03-05 19:43:53 DEBUG (MainThread) [zigpy.zcl] [0xc4fe:1:0x0006] ZCL request 0x0001: []
2021-03-05 19:43:53 DEBUG (MainThread) [zigpy.zcl] [0xc4fe:1:0x0006] No handler for cluster command 1
2021-03-05 19:43:53 DEBUG (MainThread) [bellows.ezsp.protocol] Application frame 69 (incomingMessageHandler) received: b'0004010600010100010000b574b9fec4ffff03010b0102'
2021-03-05 19:43:53 DEBUG (MainThread) [bellows.zigbee.application] Received incomingMessageHandler frame with [<EmberIncomingMessageType.INCOMING_UNICAST: 0>, EmberApsFrame(profileId=260, clusterId=6, sourceEndpoint=1, destinationEndpoint=1, options=<EmberApsOption.APS_OPTION_ENABLE_ROUTE_DISCOVERY: 256>, groupId=0, sequence=181), 116, -71, 0xc4fe, 255, 255, b'\x01\x0b\x01']
2021-03-05 19:43:53 DEBUG (MainThread) [zigpy.zcl] [0xc4fe:1:0x0006] ZCL deserialize: <ZCLHeader frame_control=<FrameControl frame_type=CLUSTER_COMMAND manufacturer_specific=False is_reply=False disable_default_response=False> manufacturer=None tsn=11 command_id=1>
2021-03-05 19:43:53 DEBUG (MainThread) [zigpy.zcl] [0xc4fe:1:0x0006] ZCL request 0x0001: []
2021-03-05 19:43:53 DEBUG (MainThread) [zigpy.zcl] [0xc4fe:1:0x0006] No handler for cluster command 1
2021-03-05 19:43:53 DEBUG (MainThread) [bellows.ezsp.protocol] Application frame 69 (incomingMessageHandler) received: b'0004010600010100010000b674b9fec4ffff03010b0102'
2021-03-05 19:43:53 DEBUG (MainThread) [bellows.zigbee.application] Received incomingMessageHandler frame with [<EmberIncomingMessageType.INCOMING_UNICAST: 0>, EmberApsFrame(profileId=260, clusterId=6, sourceEndpoint=1, destinationEndpoint=1, options=<EmberApsOption.APS_OPTION_ENABLE_ROUTE_DISCOVERY: 256>, groupId=0, sequence=182), 116, -71, 0xc4fe, 255, 255, b'\x01\x0b\x01']
2021-03-05 19:43:53 DEBUG (MainThread) [zigpy.zcl] [0xc4fe:1:0x0006] ZCL deserialize: <ZCLHeader frame_control=<FrameControl frame_type=CLUSTER_COMMAND manufacturer_specific=False is_reply=False disable_default_response=False> manufacturer=None tsn=11 command_id=1>
2021-03-05 19:43:53 DEBUG (MainThread) [zigpy.zcl] [0xc4fe:1:0x0006] ZCL request 0x0001: []
2021-03-05 19:43:53 DEBUG (MainThread) [zigpy.zcl] [0xc4fe:1:0x0006] No handler for cluster command 1
2021-03-05 19:43:53 DEBUG (MainThread) [bellows.ezsp.protocol] Application frame 69 (incomingMessageHandler) received: b'0004010600010100010000b774b9fec4ffff03010b0102'
2021-03-05 19:43:53 DEBUG (MainThread) [bellows.zigbee.application] Received incomingMessageHandler frame with [<EmberIncomingMessageType.INCOMING_UNICAST: 0>, EmberApsFrame(profileId=260, clusterId=6, sourceEndpoint=1, destinationEndpoint=1, options=<EmberApsOption.APS_OPTION_ENABLE_ROUTE_DISCOVERY: 256>, groupId=0, sequence=183), 116, -71, 0xc4fe, 255, 255, b'\x01\x0b\x01']
2021-03-05 19:43:53 DEBUG (MainThread) [zigpy.zcl] [0xc4fe:1:0x0006] ZCL deserialize: <ZCLHeader frame_control=<FrameControl frame_type=CLUSTER_COMMAND manufacturer_specific=False is_reply=False disable_default_response=False> manufacturer=None tsn=11 command_id=1>
2021-03-05 19:43:53 DEBUG (MainThread) [zigpy.zcl] [0xc4fe:1:0x0006] ZCL request 0x0001: []
2021-03-05 19:43:53 DEBUG (MainThread) [zigpy.zcl] [0xc4fe:1:0x0006] No handler for cluster command 1
2021-03-05 19:43:53 DEBUG (MainThread) [bellows.ezsp.protocol] Application frame 69 (incomingMessageHandler) received: b'0004010600010100010000b874b9fec4ffff03010b0102'
2021-03-05 19:43:53 DEBUG (MainThread) [bellows.zigbee.application] Received incomingMessageHandler frame with [<EmberIncomingMessageType.INCOMING_UNICAST: 0>, EmberApsFrame(profileId=260, clusterId=6, sourceEndpoint=1, destinationEndpoint=1, options=<EmberApsOption.APS_OPTION_ENABLE_ROUTE_DISCOVERY: 256>, groupId=0, sequence=184), 116, -71, 0xc4fe, 255, 255, b'\x01\x0b\x01']
2021-03-05 19:43:53 DEBUG (MainThread) [zigpy.zcl] [0xc4fe:1:0x0006] ZCL deserialize: <ZCLHeader frame_control=<FrameControl frame_type=CLUSTER_COMMAND manufacturer_specific=False is_reply=False disable_default_response=False> manufacturer=None tsn=11 command_id=1>
2021-03-05 19:43:53 DEBUG (MainThread) [zigpy.zcl] [0xc4fe:1:0x0006] ZCL request 0x0001: []
2021-03-05 19:43:53 DEBUG (MainThread) [zigpy.zcl] [0xc4fe:1:0x0006] No handler for cluster command 1
2021-03-05 19:43:53 DEBUG (MainThread) [bellows.ezsp.protocol] Application frame 69 (incomingMessageHandler) received: b'0004010600010100010000b970b8fec4ffff03010b0102'
2021-03-05 19:43:53 DEBUG (MainThread) [bellows.zigbee.application] Received incomingMessageHandler frame with [<EmberIncomingMessageType.INCOMING_UNICAST: 0>, EmberApsFrame(profileId=260, clusterId=6, sourceEndpoint=1, destinationEndpoint=1, options=<EmberApsOption.APS_OPTION_ENABLE_ROUTE_DISCOVERY: 256>, groupId=0, sequence=185), 112, -72, 0xc4fe, 255, 255, b'\x01\x0b\x01']
2021-03-05 19:43:53 DEBUG (MainThread) [zigpy.zcl] [0xc4fe:1:0x0006] ZCL deserialize: <ZCLHeader frame_control=<FrameControl frame_type=CLUSTER_COMMAND manufacturer_specific=False is_reply=False disable_default_response=False> manufacturer=None tsn=11 command_id=1>
2021-03-05 19:43:53 DEBUG (MainThread) [zigpy.zcl] [0xc4fe:1:0x0006] ZCL request 0x0001: []
2021-03-05 19:43:53 DEBUG (MainThread) [zigpy.zcl] [0xc4fe:1:0x0006] No handler for cluster command 1
2021-03-05 19:43:53 DEBUG (MainThread) [bellows.ezsp.protocol] Application frame 69 (incomingMessageHandler) received: b'0004010600010100010000ba70b8fec4ffff03010b0102'
2021-03-05 19:43:53 DEBUG (MainThread) [bellows.zigbee.application] Received incomingMessageHandler frame with [<EmberIncomingMessageType.INCOMING_UNICAST: 0>, EmberApsFrame(profileId=260, clusterId=6, sourceEndpoint=1, destinationEndpoint=1, options=<EmberApsOption.APS_OPTION_ENABLE_ROUTE_DISCOVERY: 256>, groupId=0, sequence=186), 112, -72, 0xc4fe, 255, 255, b'\x01\x0b\x01']
2021-03-05 19:43:53 DEBUG (MainThread) [zigpy.zcl] [0xc4fe:1:0x0006] ZCL deserialize: <ZCLHeader frame_control=<FrameControl frame_type=CLUSTER_COMMAND manufacturer_specific=False is_reply=False disable_default_response=False> manufacturer=None tsn=11 command_id=1>
2021-03-05 19:43:53 DEBUG (MainThread) [zigpy.zcl] [0xc4fe:1:0x0006] ZCL request 0x0001: []
2021-03-05 19:43:53 DEBUG (MainThread) [zigpy.zcl] [0xc4fe:1:0x0006] No handler for cluster command 1
2021-03-05 19:43:53 DEBUG (MainThread) [bellows.ezsp.protocol] Application frame 69 (incomingMessageHandler) received: b'0004010600010100010000b474b9fec4ffff03010b0102'
2021-03-05 19:43:53 DEBUG (MainThread) [bellows.zigbee.application] Received incomingMessageHandler frame with [<EmberIncomingMessageType.INCOMING_UNICAST: 0>, EmberApsFrame(profileId=260, clusterId=6, sourceEndpoint=1, destinationEndpoint=1, options=<EmberApsOption.APS_OPTION_ENABLE_ROUTE_DISCOVERY: 256>, groupId=0, sequence=180), 116, -71, 0xc4fe, 255, 255, b'\x01\x0b\x01']
2021-03-05 19:43:53 DEBUG (MainThread) [zigpy.zcl] [0xc4fe:1:0x0006] ZCL deserialize: <ZCLHeader frame_control=<FrameControl frame_type=CLUSTER_COMMAND manufacturer_specific=False is_reply=False disable_default_response=False> manufacturer=None tsn=11 command_id=1>
2021-03-05 19:43:53 DEBUG (MainThread) [zigpy.zcl] [0xc4fe:1:0x0006] ZCL request 0x0001: []
2021-03-05 19:43:53 DEBUG (MainThread) [zigpy.zcl] [0xc4fe:1:0x0006] No handler for cluster command 1
2021-03-05 19:43:53 DEBUG (MainThread) [bellows.ezsp.protocol] Application frame 69 (incomingMessageHandler) received: b'0004010600010100010000b574b9fec4ffff03010b0102'
2021-03-05 19:43:53 DEBUG (MainThread) [bellows.zigbee.application] Received incomingMessageHandler frame with [<EmberIncomingMessageType.INCOMING_UNICAST: 0>, EmberApsFrame(profileId=260, clusterId=6, sourceEndpoint=1, destinationEndpoint=1, options=<EmberApsOption.APS_OPTION_ENABLE_ROUTE_DISCOVERY: 256>, groupId=0, sequence=181), 116, -71, 0xc4fe, 255, 255, b'\x01\x0b\x01']
2021-03-05 19:43:53 DEBUG (MainThread) [zigpy.zcl] [0xc4fe:1:0x0006] ZCL deserialize: <ZCLHeader frame_control=<FrameControl frame_type=CLUSTER_COMMAND manufacturer_specific=False is_reply=False disable_default_response=False> manufacturer=None tsn=11 command_id=1>
2021-03-05 19:43:53 DEBUG (MainThread) [zigpy.zcl] [0xc4fe:1:0x0006] ZCL request 0x0001: []
2021-03-05 19:43:53 DEBUG (MainThread) [zigpy.zcl] [0xc4fe:1:0x0006] No handler for cluster command 1
2021-03-05 19:43:53 DEBUG (MainThread) [bellows.ezsp.protocol] Application frame 69 (incomingMessageHandler) received: b'0004010600010100010000b674b9fec4ffff03010b0102'
2021-03-05 19:43:53 DEBUG (MainThread) [bellows.zigbee.application] Received incomingMessageHandler frame with [<EmberIncomingMessageType.INCOMING_UNICAST: 0>, EmberApsFrame(profileId=260, clusterId=6, sourceEndpoint=1, destinationEndpoint=1, options=<EmberApsOption.APS_OPTION_ENABLE_ROUTE_DISCOVERY: 256>, groupId=0, sequence=182), 116, -71, 0xc4fe, 255, 255, b'\x01\x0b\x01']
2021-03-05 19:43:53 DEBUG (MainThread) [zigpy.zcl] [0xc4fe:1:0x0006] ZCL deserialize: <ZCLHeader frame_control=<FrameControl frame_type=CLUSTER_COMMAND manufacturer_specific=False is_reply=False disable_default_response=False> manufacturer=None tsn=11 command_id=1>
2021-03-05 19:43:53 DEBUG (MainThread) [zigpy.zcl] [0xc4fe:1:0x0006] ZCL request 0x0001: []
2021-03-05 19:43:53 DEBUG (MainThread) [zigpy.zcl] [0xc4fe:1:0x0006] No handler for cluster command 1
2021-03-05 19:43:53 DEBUG (MainThread) [bellows.ezsp.protocol] Application frame 69 (incomingMessageHandler) received: b'0004010600010100010000b774b9fec4ffff03010b0102'
2021-03-05 19:43:53 DEBUG (MainThread) [bellows.zigbee.application] Received incomingMessageHandler frame with [<EmberIncomingMessageType.INCOMING_UNICAST: 0>, EmberApsFrame(profileId=260, clusterId=6, sourceEndpoint=1, destinationEndpoint=1, options=<EmberApsOption.APS_OPTION_ENABLE_ROUTE_DISCOVERY: 256>, groupId=0, sequence=183), 116, -71, 0xc4fe, 255, 255, b'\x01\x0b\x01']
2021-03-05 19:43:53 DEBUG (MainThread) [zigpy.zcl] [0xc4fe:1:0x0006] ZCL deserialize: <ZCLHeader frame_control=<FrameControl frame_type=CLUSTER_COMMAND manufacturer_specific=False is_reply=False disable_default_response=False> manufacturer=None tsn=11 command_id=1>
2021-03-05 19:43:53 DEBUG (MainThread) [zigpy.zcl] [0xc4fe:1:0x0006] ZCL request 0x0001: []
2021-03-05 19:43:53 DEBUG (MainThread) [zigpy.zcl] [0xc4fe:1:0x0006] No handler for cluster command 1
2021-03-05 19:43:53 DEBUG (MainThread) [bellows.ezsp.protocol] Application frame 69 (incomingMessageHandler) received: b'0004010600010100010000b874b9fec4ffff03010b0102'
2021-03-05 19:43:53 DEBUG (MainThread) [bellows.zigbee.application] Received incomingMessageHandler frame with [<EmberIncomingMessageType.INCOMING_UNICAST: 0>, EmberApsFrame(profileId=260, clusterId=6, sourceEndpoint=1, destinationEndpoint=1, options=<EmberApsOption.APS_OPTION_ENABLE_ROUTE_DISCOVERY: 256>, groupId=0, sequence=184), 116, -71, 0xc4fe, 255, 255, b'\x01\x0b\x01']
2021-03-05 19:43:53 DEBUG (MainThread) [zigpy.zcl] [0xc4fe:1:0x0006] ZCL deserialize: <ZCLHeader frame_control=<FrameControl frame_type=CLUSTER_COMMAND manufacturer_specific=False is_reply=False disable_default_response=False> manufacturer=None tsn=11 command_id=1>
2021-03-05 19:43:53 DEBUG (MainThread) [zigpy.zcl] [0xc4fe:1:0x0006] ZCL request 0x0001: []
2021-03-05 19:43:53 DEBUG (MainThread) [zigpy.zcl] [0xc4fe:1:0x0006] No handler for cluster command 1
2021-03-05 19:43:53 DEBUG (MainThread) [bellows.ezsp.protocol] Application frame 69 (incomingMessageHandler) received: b'0004010600010100010000b970b8fec4ffff03010b0102'
2021-03-05 19:43:53 DEBUG (MainThread) [bellows.zigbee.application] Received incomingMessageHandler frame with [<EmberIncomingMessageType.INCOMING_UNICAST: 0>, EmberApsFrame(profileId=260, clusterId=6, sourceEndpoint=1, destinationEndpoint=1, options=<EmberApsOption.APS_OPTION_ENABLE_ROUTE_DISCOVERY: 256>, groupId=0, sequence=185), 112, -72, 0xc4fe, 255, 255, b'\x01\x0b\x01']
2021-03-05 19:43:53 DEBUG (MainThread) [zigpy.zcl] [0xc4fe:1:0x0006] ZCL deserialize: <ZCLHeader frame_control=<FrameControl frame_type=CLUSTER_COMMAND manufacturer_specific=False is_reply=False disable_default_response=False> manufacturer=None tsn=11 command_id=1>
2021-03-05 19:43:53 DEBUG (MainThread) [zigpy.zcl] [0xc4fe:1:0x0006] ZCL request 0x0001: []
2021-03-05 19:43:53 DEBUG (MainThread) [zigpy.zcl] [0xc4fe:1:0x0006] No handler for cluster command 1
2021-03-05 19:43:53 DEBUG (MainThread) [bellows.ezsp.protocol] Application frame 69 (incomingMessageHandler) received: b'0004010600010100010000ba70b8fec4ffff03010b0102'
2021-03-05 19:43:53 DEBUG (MainThread) [bellows.zigbee.application] Received incomingMessageHandler frame with [<EmberIncomingMessageType.INCOMING_UNICAST: 0>, EmberApsFrame(profileId=260, clusterId=6, sourceEndpoint=1, destinationEndpoint=1, options=<EmberApsOption.APS_OPTION_ENABLE_ROUTE_DISCOVERY: 256>, groupId=0, sequence=186), 112, -72, 0xc4fe, 255, 255, b'\x01\x0b\x01']
2021-03-05 19:43:53 DEBUG (MainThread) [zigpy.zcl] [0xc4fe:1:0x0006] ZCL deserialize: <ZCLHeader frame_control=<FrameControl frame_type=CLUSTER_COMMAND manufacturer_specific=False is_reply=False disable_default_response=False> manufacturer=None tsn=11 command_id=1>
2021-03-05 19:43:53 DEBUG (MainThread) [zigpy.zcl] [0xc4fe:1:0x0006] ZCL request 0x0001: []
2021-03-05 19:43:53 DEBUG (MainThread) [zigpy.zcl] [0xc4fe:1:0x0006] No handler for cluster command 1

And all is with the same tsn=11

And in wireshark one other frame:

Frame 1101: 112 bytes on wire (896 bits), 112 bytes captured (896 bits) on interface \Device\NPF_Loopback, id 0
Null/Loopback
Internet Protocol Version 4, Src: 127.0.0.1, Dst: 127.0.0.1
User Datagram Protocol, Src Port: 17754, Dst Port: 17754
ZigBee Encapsulation Protocol, Channel: 15, Length: 48
IEEE 802.15.4 Data, Dst: 0x0000, Src: 0xc4fe
    Frame Control Field: 0x8861, Frame Type: Data, Acknowledge Request, PAN ID Compression, Destination Addressing Mode: Short/16-bit, Frame Version: IEEE Std 802.15.4-2003, Source Addressing Mode: Short/16-bit
    Sequence Number: 105
    Destination PAN: 0xd337
    Destination: 0x0000
    Source: 0xc4fe
    [Extended Source: SiliconL_ff:fe:d0:9f:82 (ec:1b:bd:ff:fe:d0:9f:82)]
    [Origin: 54]
    TI CC24xx-format metadata: FCS OK
ZigBee Network Layer Data, Dst: 0x0000, Src: 0xc4fe
    Frame Control Field: 0x2248, Frame Type: Data, Discover Route: Enable, Security, End Device Initiator Data
        .... .... .... ..00 = Frame Type: Data (0x0)
        .... .... ..00 10.. = Protocol Version: 2
        .... .... 01.. .... = Discover Route: Enable (0x1)
        .... ...0 .... .... = Multicast: False
        .... ..1. .... .... = Security: True
        .... .0.. .... .... = Source Route: False
        .... 0... .... .... = Destination: False
        ...0 .... .... .... = Extended Source: False
        ..1. .... .... .... = End Device Initiator: True
    Destination: 0x0000
    Source: 0xc4fe
    Radius: 30
    Sequence Number: 196
    [Extended Source: SiliconL_ff:fe:d0:9f:82 (ec:1b:bd:ff:fe:d0:9f:82)]
    [Origin: 54]
    ZigBee Security Header
ZigBee Application Support Layer Data, Dst Endpt: 1, Src Endpt: 1
    Frame Control Field: Data (0x00)
        .... ..00 = Frame Type: Data (0x0)
        .... 00.. = Delivery Mode: Unicast (0x0)
        ..0. .... = Security: False
        .0.. .... = Acknowledgement Request: False
        0... .... = Extended Header: False
    Destination Endpoint: 1
    Cluster: On/Off (0x0006)
    Profile: Home Automation (0x0104)
    Source Endpoint: 1
    Counter: 180
ZigBee Cluster Library Frame
    Frame Control Field: Cluster-specific (0x01)
        .... ..01 = Frame Type: Cluster-specific (0x1)
        .... .0.. = Manufacturer Specific: False
        .... 0... = Direction: Client to Server
        ...0 .... = Disable Default Response: False
    Sequence Number: 11
    Command: On (0x01)

Its in the IEEE 802.15.4 the frame with sequence number 105.

Frame 1102: 69 bytes on wire (552 bits), 69 bytes captured (552 bits) on interface \Device\NPF_Loopback, id 0
Null/Loopback
Internet Protocol Version 4, Src: 127.0.0.1, Dst: 127.0.0.1
User Datagram Protocol, Src Port: 17754, Dst Port: 17754
ZigBee Encapsulation Protocol, Channel: 15, Length: 5
IEEE 802.15.4 Ack, Sequence Number: 105
    Frame Control Field: 0x0002, Frame Type: Ack, Destination Addressing Mode: None, Frame Version: IEEE Std 802.15.4-2003, Source Addressing Mode: None
    Sequence Number: 105
    TI CC24xx-format metadata: FCS OK

An the IEEE 802.15.4 layer is acking its have getting the frame with sequence number 105.

So the IEEE 802.15.4 layer is doing all OK but the Zigbee layer is not sending one default response and its one OK ZCL command wot i can see that the zigbee stack shall doing it with ZCL commands.

The funny thing is that the SYMFONISK is doing exactly the same.

I was thinking its little strange binding the On/Off and Level cluster to the coordinator IEEE that is making the device doing unicasts to (nwk=0X000) and not the coordinator group (0X0000) that is the normal broadcasts then most (if not all) IKEA controllers is not accepting device binding and can only being bonded to one group.

I was deleting the cordinator 0X000 binding and binding the On/Off and light level cluster to the group 0X0000 and then both devices (Shorty and symfonisk) was sending both one "set" of the command in unicast to nmk 0X000 and one set in broadcast to the group 0X0000.

Is the device binding to the coordinator with IEEE braking the default response ?? Is it possible making the default binding then pairing the device and also then doing reconfigurating the device to the default group and not to the IEEE ??

The "normal" 5 button remote is not sending commands to nmk 0x000 its sending it to group 0X0000 and ala zigbee 3 times then its one broadcast.

Mar 05 '21 20:03 MattWestb

Then bonded to group 0X000:

No.	Time	Source	Destination	Protocol	Length	Info
1293	18:45:43,677119	0xc4fe	0x0000	ZigBee HA	112	ZCL OnOff: On, Seq: 15
1295	18:45:43,685269	0xc4fe	0x0000	ZigBee HA	112	ZCL OnOff: On, Seq: 15
1297	18:45:43,696472	0xc4fe	0x0000	ZigBee HA	112	ZCL OnOff: On, Seq: 15
1299	18:45:43,707291	0xc4fe	0x0000	ZigBee HA	112	ZCL OnOff: On, Seq: 15
1301	18:45:43,719505	0xc4fe	0x0000	ZigBee HA	112	ZCL OnOff: On, Seq: 15
1303	18:45:43,731844	0xc4fe	0x0000	ZigBee HA	112	ZCL OnOff: On, Seq: 15
1305	18:45:43,738823	0xc4fe	0x0000	ZigBee HA	112	ZCL OnOff: On, Seq: 15
1307	18:45:43,750723	0xc4fe	Broadcast	ZigBee HA	113	ZCL OnOff: On, Seq: 15
1309	18:45:43,763577	0xc4fe	Broadcast	ZigBee HA	113	ZCL OnOff: On, Seq: 15
1311	18:45:43,770785	0xc4fe	Broadcast	ZigBee HA	113	ZCL OnOff: On, Seq: 15
1312	18:45:43,786408	0xc4fe	Broadcast	ZigBee HA	113	ZCL OnOff: On, Seq: 15
1314	18:45:43,791075	0xc4fe	Broadcast	ZigBee HA	113	ZCL OnOff: On, Seq: 15
1315	18:45:43,798685	0xc4fe	Broadcast	ZigBee HA	113	ZCL OnOff: On, Seq: 15

Its fitted with (wpan.src64 == ec:1b:bd:ff:fe:d0:9f:82) || (wpan.dst64 == ec:1b:bd:ff:fe:d0:9f:82) || (wpan.src16 == 0xc4fe) || (wpan.dst16 == 0xc4fe) || (zbee_nwk.src == 0xc4fe) || (zbee_nwk.dst == 0xc4fe) so IEEE 802.15.4 layer is not shown.

All with the same sequence number 15.

@Adminiuga is it one easy way putting default response in the quirk ? I running them in my test setup without routers on EZSP 6.7.8.0 and the "french patch" for IKEA devices but have not updating the the last release so "Shorty" is working without quirk.

I was sniffing in my production network and its behaving the same with updated ZHA.

Mar 05 '21 20:03 MattWestb

@mguaylambert and @TheJulianJES I have looking one more time and the Shortcut button and symphonic is sending the commands in usincast to one ZCL cluster (normal for ZLL commands is broadcast / group) and the coordinator is not sending one default response in the zigbee layer (that shall being done on ZCL clusters as long its not flagged manufacture specific commands) but the IEEE 802.15.4 layer is acking every command OK. My sniffing is done with one Billy EZSP coordinator so my question is is other Zigbee stacks doing the same or is the TI NCPs zigbee stacks sending default response ?

Mar 20 '21 18:03 MattWestb

I have sniffing pairing Shortcut and symphonicsk witth my IKEA GW. I have not looking thru the paring sequence then its one chatty production network but after being sett up its sending one broadcast to its parent (ZBA Seq 223) that is acking it (IEEE layer)(Nwk Seq 203) and then the parent is re sending it as one broad cast one time and the controller is not sending more broadcasts commands to its parent. Then its sending one unicast (ZBA Seq 224) to its parent that is acking it (IEEE layer)(Nwk Seq 204) and then its over and out no more chatting.

No.		Time			Protocol 	Zigbee Src	Zigbee Dst	IEEE Src IEEE Dst Group Nr ZBN Seq	ZBA Seq	Nwk Seq	Info						Comment
1246	11:43:58,373985	ZigBee HA	0xab77		Broadcast	0xab77	0x0304	0x002d		0		223		203		ZCL OnOff: Toggle, Seq: 12 	(Remote sending broadcaast to its parent)
1247	11:43:58,375642	IEEE 802.15.4 N/A		N/A														203		Ack							(IEEE ack)
1248	11:43:58,384974	ZigBee HA	0xab77		0x0304		0xab77	0x0304				2		224		204		ZCL OnOff: Toggle, Seq: 12	(Remote sending unicast to its parent)
1249	11:43:58,386815	IEEE 802.15.4 N/A		N/A														204		Ack							(IEEE ack)
1250	11:43:58,395870	ZigBee HA	0xab77		Broadcast	0x0304	0xffff	0x002d		0		223		168		ZCL OnOff: Toggle, Seq: 12	(Pairent resending the broadcast to 0xffff)
1251	11:43:58,403289	ZigBee HA	0xab77		Broadcast	0x12a8	0xffff	0x002d		0		223		126		ZCL OnOff: Toggle, Seq: 12	(Routers is rebroaadcasting)
1252	11:43:58,411546	ZigBee HA	0xab77		Broadcast	0xbf0b	0xffff	0x002d		0		223		251		ZCL OnOff: Toggle, Seq: 12	(Routers is rebroaadcasting)
1253	11:43:58,420922	ZigBee HA	0xab77		Broadcast	0x5134	0xffff	0x002d		0		223		226		ZCL OnOff: Toggle, Seq: 12	(Routers is rebroaadcasting)
1254	11:43:58,429125	ZigBee HA	0xab77		Broadcast	0xd87c	0xffff	0x002d		0		223		167		ZCL OnOff: Toggle, Seq: 12	(Routers is rebroaadcasting)
1255	11:43:58,437043	ZigBee HA	0xab77		Broadcast	0x05d5	0xffff	0x002d		0		223		8		ZCL OnOff: Toggle, Seq: 12	(Routers is rebroaadcasting)
1256	11:43:58,445638	ZigBee HA	0xab77		Broadcast	0xd502	0xffff	0x002d		0		223		202		ZCL OnOff: Toggle, Seq: 12	(Routers is rebroaadcasting)
1257	11:43:58,453595	ZigBee HA	0xab77		Broadcast	0x0f39	0xffff	0x002d		0		223		155		ZCL OnOff: Toggle, Seq: 12	(Routers is rebroaadcasting)
1260	11:43:58,925045	ZigBee HA	0xab77		Broadcast	0x0f39	0xffff	0x002d		0		223		156		ZCL OnOff: Toggle, Seq: 12	(Routers is rebroaadcasting)
1269	11:43:59,376941	ZigBee HA	0xab77		Broadcast	0x0f39	0xffff	0x002d		0		223		157		ZCL OnOff: Toggle, Seq: 12	(Routers is rebroaadcasting)

(copy the text to one better editor for viewing the sniff for getting the columns working OK)

The SYMFONISK is doing the same in ZHA and in IKEA GW = Siblings with very similar firmware.

I think IKEA is not binding any clusters (they dont need to do then all is configured with TL and is sending all to its "parent" = IKEA GW) but need reading the sniffs for knowing that for sure and if doing it they getting in some kind off lommbo. Thinking trying unbinding all clusters and see wot is happening.

Perhaps not binding to one group and sending default response is doing the trick ?

Mar 21 '21 14:03 MattWestb

Have doing little more sniffing and testings. Both Shortcut and SYMFONISK like sending both unicast and bradcast then its being configured in ZHA if binding them to one group.

If pairing on of them and not binding one group and instead doing one unbinding from the coordinator its looks much better: SYMFONISK is then only sending one unicast toggle command to 0X0000 and no double commands and not group broadcast = OK

The Shortcut button is normally sending 2 on commands with unicast to 0X0000 with the same ZCL sequence number and no group broad cast on one button pressing.

If doing one reconfigure of the shortcut its starting sending 7 on commands with the same ZCL sequence number to 0X0000.

My concoction is that is sending one unicast for every bonded cluster, and as i can see that IKEA GW is not sending any default response or other acks then the IEEE 802.15.4 that is OK and IKEA dont setting up bindings than its getting all then pairing with touch link and is sending all commands to its "children" / slaves.

So if like have battery reporting working its need implanting one "denounce" with the ZCL sequence number than all is being OK if sending unicast or group broadcasts and is getting the all attribute reporting and check ins to working OK that its not working if unbinding all (un)possible clusters from the coordinator and not have one bounded group.

Then doing one reconfigure of the SYMFONISK is sending 6 toggle commends with the same ZCL sequence number sent to 0X0000 = need denounce.

Both are sending more commands with the same ZCL sequence number (as the unicast one to 0x0000 that still being sent) if being bonded to one group so its possible doing that but not recommended then its not bringing any thing only more traffic in the network (perhaps if using one SYMFONISK as one ZLL on/off dimmer but its not likely).

Shortcut reconfigured:

No.	Time	Protocol	Zigbee Src	Zigbee Dst	IEEE Src	IEEE Dst	Group Nr	ZBN Seq	ZBA Seq	ZDP Seq	Nwk Seq	Info
21787	15:23:57,592705	ZigBee HA	0x6ddc	0x0000	0x6ddc	0xf7e4		237	105		165	ZCL OnOff: On, Seq: 25
21791	15:23:57,614200	ZigBee HA	0x6ddc	0x0000	0x6ddc	0xf7e4		239	106		166	ZCL OnOff: On, Seq: 25
21793	15:23:57,624996	ZigBee HA	0x6ddc	0x0000	0x6ddc	0xf7e4		241	107		167	ZCL OnOff: On, Seq: 25
21796	15:23:57,645226	ZigBee HA	0x6ddc	0x0000	0x6ddc	0xf7e4		241	107		167	ZCL OnOff: On, Seq: 25
21800	15:23:57,667882	ZigBee HA	0x6ddc	0x0000	0x6ddc	0xf7e4		243	108		168	ZCL OnOff: On, Seq: 25
21802	15:23:57,678589	ZigBee HA	0x6ddc	0x0000	0x6ddc	0xf7e4		245	109		169	ZCL OnOff: On, Seq: 25
21805	15:23:57,700487	ZigBee HA	0x6ddc	0x0000	0x6ddc	0xf7e4		245	109		169	ZCL OnOff: On, Seq: 25
21813	15:23:57,742155	ZigBee HA	0x6ddc	0x0000	0x6ddc	0xf7e4		247	110		170	ZCL OnOff: On, Seq: 25
21815	15:23:57,753008	ZigBee HA	0x6ddc	0x0000	0x6ddc	0xf7e4		249	111		171	ZCL OnOff: On, Seq: 25

SYMFONISK reconfigured:

No.	Time	Protocol	Zigbee Src	Zigbee Dst	IEEE Src	IEEE Dst	Group Nr	ZBN Seq	ZBA Seq	ZDP Seq	Nwk Seq	Info
21956	15:26:47,255844	ZigBee HA	0xaf47	0x0000	0xaf47	0xf7e4		11	2		194	ZCL OnOff: Toggle, Seq: 46
21960	15:26:47,277871	ZigBee HA	0xaf47	0x0000	0xaf47	0xf7e4		13	3		195	ZCL OnOff: Toggle, Seq: 46
21962	15:26:47,288526	ZigBee HA	0xaf47	0x0000	0xaf47	0xf7e4		15	4		196	ZCL OnOff: Toggle, Seq: 46
21963	15:26:47,297239	ZigBee HA	0xaf47	0x0000	0xaf47	0xf7e4		15	4		196	ZCL OnOff: Toggle, Seq: 46
21966	15:26:47,310367	ZigBee HA	0xaf47	0x0000	0xaf47	0xf7e4		17	5		197	ZCL OnOff: Toggle, Seq: 46
21968	15:26:47,320805	ZigBee HA	0xaf47	0x0000	0xaf47	0xf7e4		19	6		198	ZCL OnOff: Toggle, Seq: 46
21972	15:26:47,343646	ZigBee HA	0xaf47	0x0000	0xaf47	0xf7e4		21	7		199	ZCL OnOff: Toggle, Seq: 46

Its little funny then IKEA have cooking both devices very well and working well in there ZB3 system with ZLL controller bridge but they have not debugging the devices in one ZB3 system with coordinator / trust center (that is not there primary thing only having OK capabilities with other ZB3 system and putting the money on there own).

I think i cant bringing more in these issue then the rest is coding things that is not my strong side after learning wot BASIC was standing for in the high degree school and was getting more interest for pure machine code for my MC6809 ;-))

Mar 22 '21 16:03 MattWestb

Some more interesting info of old and new IKEA controllers deCONZ have digging up: https://github.com/dresden-elektronik/deconz-rest-plugin/pull/4627 https://github.com/dresden-elektronik/deconz-rest-plugin/wiki/IKEA-controllers

They have not finding how getting the network key from the IKEA GW (its done by pairing one light by pushing the pairing button under the hod and doing classic pairing and sniffing the key) but they have doing great work sniffing and analyzing the device behaviors.

Interesting that most new controllers is not needing binding then there is sending sending reports to 0x0000 or to one group if being bonded to one group.

Z2M is starting sending default response to group commands !!! https://github.com/Koenkk/zigbee2mqtt/issues/6296#issuecomment-808486149

Mar 27 '21 09:03 MattWestb

Huh you were right @MattWestb ! Altaught, I am not sure how this will be implemented in ZHA or if it is part of the standard.

Mar 27 '21 20:03 mguaylam

I think best is that @Adminiuga is taking on look and and perhaps doing one solution for shortcut, Symponisk and the upcoming Styrbar than all is behaving very similar.

I dont knowing if all is released in the US but its easier if the devs is having one device and can trying different approach and sniffing the traffic if needed.

I hope the Styrbar is coming in stock in Austria so i can sniffing one and see how its working.

Great work done !!! IKEA is trying very hard getting there devices working well in there system and also getting them working OK in open systems but its not the highest priority.

By the way you was getting all function the device is supporting in the quirk !!

Mar 27 '21 20:03 MattWestb

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates. Please make sure to update to the latest version and check if that solves the issue. Let us know if that works for you by adding a comment 👍 This issue has now been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.

Sep 23 '21 20:09 github-actions[bot]

Its still one problem with the 2.5 and 3 gen controllers that is spamming the network and some coordinators is not filtering the events with the same tsn out (EZSP) and some other looks doing it OK it in the coordinator firmware (IT).

Perhaps the firmware update that is in the pipe but not released can fixing the extreme spamming (group broadcast plus unicast for every bonded cluster / configurated attribute reporting) but they is not released in the test feed so its only speculations from my side.

Sep 23 '21 20:09 MattWestb

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates. Please make sure to update to the latest version and check if that solves the issue. Let us know if that works for you by adding a comment 👍 This issue has now been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.

Mar 22 '22 21:03 github-actions[bot]

I think it shall being good implanting it general the some tuya device (TS004X a gen) is reseeding commands also then we is sending default response from the quirk to them.

Mar 23 '22 05:03 MattWestb

I having this issue, just when you are starting to load the network, or you have interferences. In that case you get duplicate. I would have expect this is done by the firmware itself. Right now, this has been reached with SonOff Dongle

May 11 '22 20:05 pipiche38

Yes and no. If one ZCL frame its is logic being filtered but no ZCL frames shall being made of the app layer = the host application. Some user is saying that TI stack is filtering ZCL frames but i have not testing and EZSP is not doing it.

IKEA shortcut and SYMPHONISK is fixed in the last firmware but the STYRBAR is still spamming the network (one frame for every bond cluster all with the same TSN plus group cast).

May 12 '22 04:05 MattWestb

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates. Please make sure to update to the latest version and check if that solves the issue. Let us know if that works for you by adding a comment 👍 This issue has now been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.

Nov 08 '22 05:11 github-actions[bot]

Its still making problems for normal user making automatons and getting it triggered more time then only one button was pressed.

Nov 08 '22 05:11 MattWestb

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates. Please make sure to update to the latest version and check if that solves the issue. Let us know if that works for you by adding a comment 👍 This issue has now been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.

May 07 '23 07:05 github-actions[bot]

Still one problem.

May 07 '23 07:05 MattWestb

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates. Please make sure to update to the latest version and check if that solves the issue. Let us know if that works for you by adding a comment 👍 This issue has now been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.

Nov 03 '23 08:11 github-actions[bot]

Still one large problem with bellows and perhaps other radio libs under ZHA.

Nov 03 '23 08:11 MattWestb