[BitCloud] How do I find out if "Attribute Discovery" is supported?

[rfleming]

Hi Alex,

I have come across a device that appears like it doesn't support me doing an ZCL Attribute Discovery command at all. As in it simply doesn't respond to the query at all even if I have default response enabled. I am fine if the device doesn't support the attribute discovery, though I need to find some way that guarantee to let me know that it doesn't support it. Does this exist in ZigBee?

This is the sniffer packet of the frame I am sending over the device:

Code: [Select]

Frame 94: 60 bytes on wire (480 bits), 58 bytes captured (464 bits) on interface 0
    Interface id: 0 (\\.\pipe\wireshark)
    Encapsulation type: IEEE 802.15.4 Wireless PAN (104)
    Arrival Time: Jan  1, 1970 11:02:15.811525000 AUS Eastern Daylight Time
    [Time shift for this packet: 0.000000000 seconds]
    Epoch Time: 135.811525000 seconds
    [Time delta from previous captured frame: 4.380419000 seconds]
    [Time delta from previous displayed frame: 4.380419000 seconds]
    [Time since reference or first frame: 135.538343000 seconds]
    Frame Number: 94
    Frame Length: 60 bytes (480 bits)
    Capture Length: 58 bytes (464 bits)
    [Frame is marked: False]
    [Frame is ignored: False]
    [Protocols in frame: wpan:zbee_nwk:zbee_aps:zbee_zcl]
IEEE 802.15.4 Data, Dst: 0x21a1, Src: 0x0000
    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
        .... .... .... .001 = Frame Type: Data (0x1)
        .... .... .... 0... = Security Enabled: False
        .... .... ...0 .... = Frame Pending: False
        .... .... ..1. .... = Acknowledge Request: True
        .... .... .1.. .... = PAN ID Compression: True
        .... ...0 .... .... = Sequence Number Suppression: False
        .... ..0. .... .... = Information Elements Present: False
        .... 10.. .... .... = Destination Addressing Mode: Short/16-bit (0x2)
        ..00 .... .... .... = Frame Version: IEEE Std 802.15.4-2003 (0)
        10.. .... .... .... = Source Addressing Mode: Short/16-bit (0x2)
    Sequence Number: 58
    Destination PAN: 0x2cac
    Destination: 0x21a1
    Source: 0x0000
    [Extended Source: 2f:2e:34:0c:c5:ef:dd:0f (2f:2e:34:0c:c5:ef:dd:0f)]
    [Origin: 1]
ZigBee Network Layer Data, Dst: 0x21a1, Src: 0x0000
    Frame Control Field: 0x0248, Frame Type: Data, Discover Route: Enable, Security 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
        ..0. .... .... .... = End Device Initiator: False
    Destination: 0x21a1
    Source: 0x0000
    Radius: 10
    Sequence Number: 84
    [Extended Source: 2f:2e:34:0c:c5:ef:dd:0f (2f:2e:34:0c:c5:ef:dd:0f)]
    [Origin: 1]
    ZigBee Security Header
        Security Control Field: 0x28, Key Id: Network Key, Extended Nonce
            ...0 1... = Key Id: Network Key (0x1)
            ..1. .... = Extended Nonce: True
        Frame Counter: 50
        Extended Source: 2f:2e:34:0c:c5:ef:dd:0f (2f:2e:34:0c:c5:ef:dd:0f)
        Key Sequence Number: 0
        Message Integrity Code: 446e80cb
        [Key: 97fc175c6d57441cb3d7bd11fea57b4c]
        [Key Origin: 13]
ZigBee Application Support Layer Data, Dst Endpt: 1, Src Endpt: 1
    Frame Control Field: Data (0x20)
        .... ..00 = Frame Type: Data (0x0)
        .... 00.. = Delivery Mode: Unicast (0x0)
        ..1. .... = Security: True
        .0.. .... = Acknowledgement Request: False
        0... .... = Extended Header: False
    Destination Endpoint: 1
    Cluster: Simple Metering (0x0702)
    Profile: Home Automation (0x0104)
    Source Endpoint: 1
    Counter: 60
    ZigBee Security Header
        Security Control Field: 0x00, Key Id: Link Key
            ...0 0... = Key Id: Link Key (0x0)
            ..0. .... = Extended Nonce: False
        Frame Counter: 25
        Message Integrity Code: 1e6e6e64
        [Key: 5a6967426565416c6c69616e63653039]
        [Key Label: ]
ZigBee Cluster Library Frame, Command: Discover Attributes, Seq: 47
    Frame Control Field: Profile-wide (0x00)
        .... ..00 = Frame Type: Profile-wide (0x0)
        .... .0.. = Manufacturer Specific: False
        .... 0... = Direction: Server
        ...0 .... = Disable Default Response: False
    Sequence Number: 47
    Command: Discover Attributes (0x0c)
    Start Attribute: 0x0000
    Maximum Number: 5

Hope you have a few suggestions for me Alex

Cheers,
Ryan.

[ataradov]

And you are absolutely sure that this device has ZCL on endpoint 1? Does it respond to any other ZCL requests on this endpoint?

[rfleming]

Yep.

Just before I do an attribute discovery I do a Simple descriptor request, it replied back fine:

Code: [Select]

Frame 67: 72 bytes on wire (576 bits), 70 bytes captured (560 bits) on interface 0
    Interface id: 0 (\\.\pipe\wireshark)
    Encapsulation type: IEEE 802.15.4 Wireless PAN (104)
    Arrival Time: Jan  1, 1970 11:07:22.586726000 AUS Eastern Daylight Time
    [Time shift for this packet: 0.000000000 seconds]
    Epoch Time: 442.586726000 seconds
    [Time delta from previous captured frame: 0.014011000 seconds]
    [Time delta from previous displayed frame: 0.014011000 seconds]
    [Time since reference or first frame: 442.488656000 seconds]
    Frame Number: 67
    Frame Length: 72 bytes (576 bits)
    Capture Length: 70 bytes (560 bits)
    [Frame is marked: False]
    [Frame is ignored: False]
    [Protocols in frame: wpan:zbee_nwk:zbee_aps:zbee_zdp]
IEEE 802.15.4 Data, Dst: 0x0000, Src: 0x2d05
    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
        .... .... .... .001 = Frame Type: Data (0x1)
        .... .... .... 0... = Security Enabled: False
        .... .... ...0 .... = Frame Pending: False
        .... .... ..1. .... = Acknowledge Request: True
        .... .... .1.. .... = PAN ID Compression: True
        .... ...0 .... .... = Sequence Number Suppression: False
        .... ..0. .... .... = Information Elements Present: False
        .... 10.. .... .... = Destination Addressing Mode: Short/16-bit (0x2)
        ..00 .... .... .... = Frame Version: IEEE Std 802.15.4-2003 (0)
        10.. .... .... .... = Source Addressing Mode: Short/16-bit (0x2)
    Sequence Number: 141
    Destination PAN: 0x6725
    Destination: 0x0000
    Source: 0x2d05
    [Extended Source: TexasIns_00:08:e9:07:81 (00:12:4b:00:08:e9:07:81)]
    [Origin: 48]
ZigBee Network Layer Data, Dst: 0x0000, Src: 0x2d05
    Frame Control Field: 0x0248, Frame Type: Data, Discover Route: Enable, Security 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
        ..0. .... .... .... = End Device Initiator: False
    Destination: 0x0000
    Source: 0x2d05
    Radius: 30
    Sequence Number: 254
    [Extended Source: TexasIns_00:08:e9:07:81 (00:12:4b:00:08:e9:07:81)]
    [Origin: 48]
    ZigBee Security Header
        Security Control Field: 0x28, Key Id: Network Key, Extended Nonce
            ...0 1... = Key Id: Network Key (0x1)
            ..1. .... = Extended Nonce: True
        Frame Counter: 3
        Extended Source: TexasIns_00:08:e9:07:81 (00:12:4b:00:08:e9:07:81)
        Key Sequence Number: 0
        Message Integrity Code: 1c8d6620
        [Key: 97fc175c6d57441cb3d7bd11fea57b4c]
        [Key Origin: 46]
ZigBee Application Support Layer Data, Dst Endpt: 0, Src Endpt: 0
    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: 0
    Simple Descriptor Response (Cluster ID: 0x8004)
    Profile: ZigBee Device Profile (0x0000)
    Source Endpoint: 0
    Counter: 4
ZigBee Device Profile, Simple Descriptor Response, Device: 0x2d05, Status: Success
    Sequence Number: 6
    Status: Success (0)
    Device: 0x2d05
    Simple Descriptor Length: 22
    Simple Descriptor
        Endpoint: 1
        Profile: 0x0104
        Application Device: 0x0051
        Application Version: 0x0000
        Input Cluster Count: 6
        Input Cluster List
            Input Cluster: 0
            Input Cluster: 3
            Input Cluster: 4
            Input Cluster: 5
            Input Cluster: 6
            Input Cluster: 1794
        Output Cluster Count: 1
        Output Cluster List
            Output Cluster: 0

As you can see from the sniffer packets in the image below, everything responds fine except Attribute Discovery


Cheers,
Ryan.

[ataradov]

You are asking it to enumerate attributes in the Simple Metering (0x0702) cluster, which is not present according to the simple descriptor.
I'm not sure if default response or any kind of response is appropriate here. You can only ask about clusters in the the simple descriptor.

Never mind, my hex math is off this morning. Let me think about this for a second.

[ataradov]

I'm not finding Simple Metering cluster in any public documents. But some internal stuff suggests that it has at least one mandatory attribute, so it must support Discover Attributes command.

This looks like a bug and the only way to figure out what is supported is to read all of them and analyze the returns.

[rfleming]

Simple metering cluster 0x0702 is actually found in the Simple Metering Profile Zigbee Specs. It is technically "borrowed" from SE profile for home automation metering devices such as smart plugs

This looks like a bug and the only way to figure out what is supported is to read all of them and analyze the returns.

Bugger.

I actually have a doco that tells me exactly what is supported, so i am more than happy when adding devices like this to have it query an external server for the attributes I require (easy peasy)...but...I am unsure how to do some sort of query that can accurately tell me if a attribute discovery is actually supported on the device or not. The best bet I have is to assume if I try 10 times and it timesout and I try another query that works fine, I can assume it isn't supported.

Oh well. Cheers alex

Might have to contact the developer and tell them to fix their shit

[ataradov]

The best bet I have is to assume if I try 10 times and it timesout and I try another query that works fine, I can assume it isn't supported.

Yep, that appear to be the bets solution.  10 times may be an overkill.

Might have to contact the developer and tell them to fix their shit

Good luck with that. There is a lot of buggy hardware out there with close to zero hope of it ever being fixed.

Being a generic IoT hub developer is a nightmare.

[rfleming]

Hi Alex,

I got reply from the guys about their product, they said I have to turn "security enabled" option off in the Frame Control in the APS layer.

Turns out I was using the default Simple Metering Cluster created by the Atmel team that was created for the SE profile. As such it had the extra security option enabled on the APS layer. Thus their product "couldn't read the packet at all" as they put it.

Cheers,
Ryan.

[ataradov]

I got reply from the guys about their product, they said I have to turn "security enabled" option off in the Frame Control in the APS layer.

I guess that makes sense for HA product.