Touchlink doesnt work for Silicon Labs controllers (EFR32MG21 like ZBDongle-E)

[awawa-dev]

What happened?

As we already talked on Discord @Nerivec, I'm reporting a problem: touchlink feature does not find any device when the controller is a ZBDongle-E or other device based on Silicon Labs controllers (tested on 3 different units). For comparison, I am attaching also the log from cc2651p (zstack) which finds the lamp and the positioning is almost identical as in the case of the ZBDongle-E.

What did you expect to happen?

Without Touchlink feature we are unable to reset Philips Hue lamps and join them to Z2M network. The lamp reset feature by turning it on and off seems to work only for bulbs

How to reproduce it (minimal and precise)

Open Z2M frontend and start touchlink-ing discovery.

Zigbee2MQTT version

2.0.0

Adapter firmware version

8.0.2

Adapter

ZBDongle-E

Setup

RPi4

Debug log

Not working touchlink ZBDongle-E 8.0.2 logs: https://pastebin.com/Xg0LVXkQ
Working touchlink cc2651p logs: https://pastebin.com/TkWfeSuL

[Nerivec]

Could you get debug logs with a 7.4.x firmware? Silabs changed the handler in 8.0.x, just want to confirm what you're seeing with previous version.

[awawa-dev]

Sure, here they are: https://pastebin.com/8TxQ2jQk

[awawa-dev]

Hmm...zh:ember:ezsp: Received network/route error ROUTE_ERROR_ADDRESS_CONFLICT for "0". Something is trying to talk?

[Nerivec]

Looks like something is reporting itself as a "coordinator" (network address 0) on channel 15 when the scan triggers, which conflicts with the coordinator that does the scan. Does that make any sense? At least it means something on 15 is being detected, which makes sense since zstack found a match on 15.
As far as I can tell, the payloads look fine though.
Any chance you can sniff the process with both zstack and ember so we can see the other side of the conversation?

[awawa-dev]

@Nerivec this time I get this error only once or twice just after resetting Philips Hue lamp.
But I managed to succesfully sniff transmission both for ember(not working) and zstack(working) and there are some differences
cc2651p https://pastebin.com/51XBHtTP
ZBDongle-E https://pastebin.com/KP65cfEn
The response came after 12 sec in case of zstack.

[Nerivec]

Strange, as far as I can tell, both got a response, and the exact same one (apart from counters ofc)...

IEEE 802.15.4 Data, Src: PhilipsLight_01:06:d4:c6:54, Dst: SiliconLabor_ff:fe:16:a2:aa
    Frame Control Field: 0xcc21, Frame Type: Data, Acknowledge Request, Destination Addressing Mode: Long/64-bit, Frame Version: IEEE Std 802.15.4-2003, Source Addressing Mode: Long/64-bit
        .... .... .... .001 = Frame Type: Data (0x1)
        .... .... .... 0... = Security Enabled: False
        .... .... ...0 .... = Frame Pending: False
        .... .... ..1. .... = Acknowledge Request: True
        .... .... .0.. .... = PAN ID Compression: False
        .... .... 0... .... = Reserved: False
        .... ...0 .... .... = Sequence Number Suppression: False
        .... ..0. .... .... = Information Elements Present: False
        .... 11.. .... .... = Destination Addressing Mode: Long/64-bit (0x3)
        ..00 .... .... .... = Frame Version: IEEE Std 802.15.4-2003 (0)
        11.. .... .... .... = Source Addressing Mode: Long/64-bit (0x3)
    Sequence Number: 42
    Destination PAN: 0xffff
    Destination: SiliconLabor_ff:fe:16:a2:aa (e4:06:bf:ff:fe:16:a2:aa)
    Source PAN: 0x1a62
    Extended Source: PhilipsLight_01:06:d4:c6:54 (00:17:88:01:06:d4:c6:54)
ZigBee Network Layer Interpan
    Frame Control Field: 0x000b, Frame Type: Interpan, Discover Route: Suppress Interpan
        .... .... .... ..11 = Frame Type: Interpan (0x3)
        .... .... ..00 10.. = Protocol Version: 2
        .... .... 00.. .... = Discover Route: Suppress (0x0)
        .... ...0 .... .... = Multicast: False
        .... ..0. .... .... = Security: False
        .... .0.. .... .... = Source Route: False
        .... 0... .... .... = Destination: False
        ...0 .... .... .... = Extended Source: False
        ..0. .... .... .... = End Device Initiator: False
ZigBee Application Support Layer Interpan
    Frame Control Field: Interpan (0x03)
        .... ..11 = Frame Type: Interpan (0x3)
        .... 00.. = Delivery Mode: Unicast (0x0)
        ..0. .... = Security: False
        .0.. .... = Acknowledgement Request: False
        0... .... = Extended Header: False
    Cluster: ZLL Commissioning (0x1000)
    Profile: ZLL (0xc05e)
ZigBee Cluster Library Frame
    Frame Control Field: Cluster-specific (0x19)
        .... ..01 = Frame Type: Cluster-specific (0x1)
        .... .0.. = Manufacturer Specific: False
        .... 1... = Direction: Server to Client
        ...1 .... = Disable Default Response: True
    Sequence Number: 0
    Command: Scan Response (0x01)
    Transaction ID: 0x6fdb8265
    RSSI Correction: 10
    ZigBee Information: 0x05, Logical type: router, Rx on when idle
        .... ..01 = Logical type: router (0x1)
        .... .1.. = Rx on when idle: Yes
    Touchlink Information: 0x00, Profile Interop: ZLL
        .... ...0 = Factory new: No
        .... ..0. = Address assignment: No
        ...0 .... = Link initiator: No
        ..0. .... = Undefined: False
        0... .... = Profile Interop: ZLL (0x0)
    Key Bitmask: 0x0012, Master Key
        .... .... .... ...0 = Development Key: No
        .... .... ...1 .... = Master Key: Yes
        0... .... .... .... = Certification Key: No
    Response ID: 0x6f33bc5c
    Extended PAN ID: TexasInstrum_00:1c:dc:b7:8f (00:12:4b:00:1c:dc:b7:8f)
    Network Update ID: 0
    Logical Channel: 15
    PAN ID: 0x1a62
    Network Address: 43699
    Sub-devices: 1
    Total Group Identifiers: 0
    Endpoint: 11
    Profile ID: ZLL (0xc05e)
    Device ID: 0x0210
    Version: 0x02
    Group ID Count: 0

IEEE 802.15.4 Data, Src: PhilipsLight_01:06:d4:c6:54, Dst: TexasInstrum_00:29:e7:cb:4c
    Frame Control Field: 0xcc21, Frame Type: Data, Acknowledge Request, Destination Addressing Mode: Long/64-bit, Frame Version: IEEE Std 802.15.4-2003, Source Addressing Mode: Long/64-bit
        .... .... .... .001 = Frame Type: Data (0x1)
        .... .... .... 0... = Security Enabled: False
        .... .... ...0 .... = Frame Pending: False
        .... .... ..1. .... = Acknowledge Request: True
        .... .... .0.. .... = PAN ID Compression: False
        .... .... 0... .... = Reserved: False
        .... ...0 .... .... = Sequence Number Suppression: False
        .... ..0. .... .... = Information Elements Present: False
        .... 11.. .... .... = Destination Addressing Mode: Long/64-bit (0x3)
        ..00 .... .... .... = Frame Version: IEEE Std 802.15.4-2003 (0)
        11.. .... .... .... = Source Addressing Mode: Long/64-bit (0x3)
    Sequence Number: 75
    Destination PAN: 0xffff
    Destination: TexasInstrum_00:29:e7:cb:4c (00:12:4b:00:29:e7:cb:4c)
    Source PAN: 0x1a62
    Extended Source: PhilipsLight_01:06:d4:c6:54 (00:17:88:01:06:d4:c6:54)
ZigBee Network Layer Interpan
    Frame Control Field: 0x000b, Frame Type: Interpan, Discover Route: Suppress Interpan
        .... .... .... ..11 = Frame Type: Interpan (0x3)
        .... .... ..00 10.. = Protocol Version: 2
        .... .... 00.. .... = Discover Route: Suppress (0x0)
        .... ...0 .... .... = Multicast: False
        .... ..0. .... .... = Security: False
        .... .0.. .... .... = Source Route: False
        .... 0... .... .... = Destination: False
        ...0 .... .... .... = Extended Source: False
        ..0. .... .... .... = End Device Initiator: False
ZigBee Application Support Layer Interpan
    Frame Control Field: Interpan (0x03)
        .... ..11 = Frame Type: Interpan (0x3)
        .... 00.. = Delivery Mode: Unicast (0x0)
        ..0. .... = Security: False
        .0.. .... = Acknowledgement Request: False
        0... .... = Extended Header: False
    Cluster: ZLL Commissioning (0x1000)
    Profile: ZLL (0xc05e)
ZigBee Cluster Library Frame
    Frame Control Field: Cluster-specific (0x19)
        .... ..01 = Frame Type: Cluster-specific (0x1)
        .... .0.. = Manufacturer Specific: False
        .... 1... = Direction: Server to Client
        ...1 .... = Disable Default Response: True
    Sequence Number: 0
    Command: Scan Response (0x01)
    Transaction ID: 0xf76d0269
    RSSI Correction: 10
    ZigBee Information: 0x05, Logical type: router, Rx on when idle
        .... ..01 = Logical type: router (0x1)
        .... .1.. = Rx on when idle: Yes
    Touchlink Information: 0x00, Profile Interop: ZLL
        .... ...0 = Factory new: No
        .... ..0. = Address assignment: No
        ...0 .... = Link initiator: No
        ..0. .... = Undefined: False
        0... .... = Profile Interop: ZLL (0x0)
    Key Bitmask: 0x0012, Master Key
        .... .... .... ...0 = Development Key: No
        .... .... ...1 .... = Master Key: Yes
        0... .... .... .... = Certification Key: No
    Response ID: 0x737f01b5
    Extended PAN ID: TexasInstrum_00:1c:dc:b7:8f (00:12:4b:00:1c:dc:b7:8f)
    Network Update ID: 0
    Logical Channel: 15
    PAN ID: 0x1a62
    Network Address: 43699
    Sub-devices: 1
    Total Group Identifiers: 0
    Endpoint: 11
    Profile ID: ZLL (0xc05e)
    Device ID: 0x0210
    Version: 0x02
    Group ID Count: 0

Do you have the debug logs for ember from the scan where you did the sniff? It should show the message coming in.

PS: for future reference, the pcap format is preferred when sharing sniffs, it's easier to load up 😉

[awawa-dev]

New logs from ember: https://pastebin.com/WfcpRSFw and corresponding pcap is here: sniff.zip

[Nerivec]

Well, indeed, seems the device sends the response, but the firmware is not passing it over to Z2M, so it times out.
I find it strange that I have not seen reports of this before though, since 7.4.x has been around for almost a year now.
Any chance you have another device model (another brand?) to test it with? I'm wondering if this device is getting filtered out for some reason.

[awawa-dev]

I tested it on 3 different silicone controllers, the effect is the same. Link: awawa-dev/HyperHDR#1024 (comment) it doesn't work also for our users. Only Texas controllers and zstack have working touchlink.

[awawa-dev]

Does Koenkk/zigbee-herdsman#1300 should fix it? How can I switch z2m to this PR plugin and test it?

[awawa-dev]

Ezsp 7.3.3 seems something is happening on channel 15 but it timeouts out anyway: https://pastebin.com/nYnW5Khq

[Nerivec]

should fix it

No it's just general maintenance.

Ezsp 7.3.3 seems something is happening

Nothing Touchlink related.

I tested it on 3 different silicone controllers

I meant another Touchlink device model/brand, not another controller. Just trying to eliminate possibilities, since I can't see anything wrong with the raw frames sent (identical to TI), nor with the firmware (Touchlink is enabled by default).

@kirovilya I think you did some experimentation with Touchlink in the past, do you still have a device to test this with (7.4.x or 8.0.x firmware)?

[kirovilya]

Hi. My testing was a simple case:

• a scan was done on all channels and the response of the devices was listened to in order to detect them.
• then, a reset was sent to the device so that it could pair with the network.
• sometimes can send an identification to indicate the found device.

I checked mainly on the light bulbs.

I'll check the operation of the touchlink, but later, maybe on the weekend.

[kirovilya]

@Nerivec
I looked through my old research... I found a mention that there were many efr32-firmwares in which the touchlink was not enabled... One of the working firmwares 7.1.1 was taken here - I loaded it into the E stick - the touchlink works with the ezsp adapter (z2m 2.0.0) - found an Ikea light bulb on scan.
then I download a more modern firmware from here 7.4.3 - doesn't find the bulb. firmware 8.0.2 with ember adapter - doesn't find the bulb

[awawa-dev]

I can confirm: touchlink works with the mentioned firmware version 7.1.1 and finds my lamp.

[Nerivec]

@kirovilya is it the same problem of not seeing the response message come in at all in Z2M (but visible when sniffing) in all non-working cases?
Touchlink is enabled by default in firmware projects, so I don't think that's the problem (hasn't changed since 4.0 from what I can tell with the old gecko_sdk).
We're sending raw MAC messages for InterPAN in Z2M (not using firmware-specific ZLL functions), so, my guess is, it's hitting a filter somewhere that may not have been configured the same in the past versions, and messages don't get outputted to the EZSP layer. All that stuff is closed source though 😢 I'll see if we can get something from Silabs...

@xsp1989 any chance you still have the old config you used for that 7.1.1 firmware that works (compared to the 7.4.3 that doesn't)?

[awawa-dev]

@Nerivec logs from firmware 7.1.1 (touchlink is working) https://pastebin.com/kKz6BZD6

[kirovilya]

is it the same problem of not seeing the response message come in at all in Z2M (but visible when sniffing) in all non-working cases?

yes. sniff shows the correct answer, but stick does not give it.
sniff.zip

[xsp1989]

@kirovilya is it the same problem of not seeing the response message come in at all in Z2M (but visible when sniffing) in all non-working cases? Touchlink is enabled by default in firmware projects, so I don't think that's the problem (hasn't changed since 4.0 from what I can tell with the old gecko_sdk). We're sending raw MAC messages for InterPAN in Z2M (not using firmware-specific ZLL functions), so, my guess is, it's hitting a filter somewhere that may not have been configured the same in the past versions, and messages don't get outputted to the EZSP layer. All that stuff is closed source though 😢 I'll see if we can get something from Silabs...

@xsp1989 any chance you still have the old config you used for that 7.1.1 firmware that works (compared to the 7.4.3 that doesn't)?

I have only built 7.1.4 for ZB-GW04, not 7.1.1. You can download it from my firmware repository. You need to check the historical version. I deleted this firmware a few days ago, and I did not keep the previous build configuration.

[awawa-dev]

Previously it was a false alarm. I had to reset the lamps and now touchlink detects the lamp on 7.1.4. So the firmware is good.

[awawa-dev]

On the https://github.com/itead/Sonoff_Zigbee_Dongle_Firmware/tree/master/Dongle-E/NCP_7.3.3 I see they do not support touchlink in the release note. Also 7.4.3 does not support it. Nothing about 7.4.4 introduces it,