Alexa Identify Cluster

[J.P. Hutchins]

nRF Connect SDK v1.8.0, Zephyr, Zigbee, ZBOSS

I have an issue with Alexa Echo Gen 4 Zigbee Discovery and  a malformed packet when modifying the nrf/samples/zigbee/light_bulb to be a Door Lock instead of a Light Bulb.

I am using the nRF Zigbee sniffer to analyze the transactions during device discovery.  Once Alexa discovers the Lock, it sends

Alexa:

Command: Identify (0x00)

Payload:

    Identify Time: 3 seconds

Lock replies:

Command: Default Response (0x0b)

Response to Command: 0x00

Status: Success (0x00)

... about 2 seconds go by ...

Alexa:

Command: Read Attributes (0x00)

Attribute: Identify Time (0x0000)

Lock replies [Malformed Packet]

Command: Read Attributes Response (0x01)

Status Record:

    Attribute: Identify Time (0x0000)

    Status: Success (0x00)

    Data Type: 8-bit Bitmap (0x18)

I believe that this is the cause of the main problem which is that the Alexa app won’t interact with the Lock because “Device doesn’t support requested value”.  There are no other transactions that indicate problems, e.g. Alexa is mostly polling for Lock state which the Lock is happily replying to.

To further isolate the problem, I have built the application with the light bulb example only slightly modified to fit in the wider Zephyr application framework (and I don’t have any buttons or lights on my HW).

Alexa:

Command: Identify (0x00)

Payload:

    Identify Time: 3 seconds

Lock replies:

Command: Default Response (0x0b)

Response to Command: 0x00

Status: Success (0x00)

... about 2 seconds go by ...

Alexa:

Command: Read Attributes (0x00)

Attribute: Identify Time (0x0000)

Lock replies:

Command: Read Attributes Response (0x01)
    Attribute: Identify Time (0x0000)
    Status: Success (0x00)
    Data Type: 16-bit Unsigned Integer (0x21)
    Identify Time: 1 seconds

So here we see the expected response provided by the light bulb example returns the correct type according to the Zigbee specification.  I will continue digging into this but I am stumped.  I would LOVE to be able to intercept the Read Attribute to the Identify Cluster so that I can respond correctly but I cannot figure out how to hook into it.

J.P.

[J.P. Hutchins]

I can get past the malformed packet by hardcoding the 8bit field type to be 0x21 (identifying itself as uint16). Obviously that’s terrible. It causes the Lock to respond with a well formed packet containing the value 3, the same value that Alexa sends for the identify time. The problem with this is that it will identify forever because they keep saying 3 to one another without one saying 0 meaning the identification has ended.

So, I restarted the lock which ended the identify loop but I still have the same issue with Alexa saying "Device does not support the requested value."

I have tickets in with Amazon.

Do you have any ideas?  Could it be WWAHu?

[Marte Myrvold]

Hi,

I am not sure if it is related to WWAHu, as the issue is that the data type in the read attribute response is incorrect. What I find strange is that the data type is 8-bit bitmap, even though it is clearly set to uint16 in zb_zcl_identify.h, as you can see here. Can you verify that this is correct in your SDK as well?

Do you have multiple DKs? If so, can you test by programming the Zigbee shell sample on one of them, and then send read attribute command (zcl attr read) to the lock device and see if the data type is still incorrect? Have you checked with other versions of nRF Connect SDK?

Is it possible for you to upload the sniffer logs as pcap file?

Best regards,

Marte

[J.P. Hutchins]

Thank you for your assistance!  Confirmed that the macro at line 401 of zb_zcl_identify.h matches:

#define ZB_SET_ATTR_DESCR_WITH_ZB_ZCL_ATTR_IDENTIFY_IDENTIFY_TIME_ID(data_ptr)  \
{                                                               \
  ZB_ZCL_ATTR_IDENTIFY_IDENTIFY_TIME_ID,                               \
  ZB_ZCL_ATTR_TYPE_U16,                                         \
  ZB_ZCL_ATTR_ACCESS_READ_WRITE,                                \
  (void*) data_ptr                                         \
}

I will look around the lab for another DK.  At the same time I will also load the sample on the DK (instead of using DK as sniffer) - to be clear, so far the Lock is running on a revision of a released product.

I have not tried different versions of the nRF Connect SDK.  Perhaps I can stub it and give this a shot.

I have recorded a fresh PCAP that shows Alexa begin the discovery, Lock gets bound, and malformed packet.  The example ends with inspecting the lock in the Alexa app to show that the lock is responding to polling (even though the Alexa app says "Device doesn't support requested value" and "There is a problem with First lock" "Please check on your lock".)  I hope I missed some request it is sending!

It would be great if NRF could try with an Amazon Alexa Echo Gen4 as Zigbee coordinator to see if anything needs to be address with Amazon's Zigbee implementation.  They do not respond to my inquiries 

Thanks again,
J.P. Hutchinspcap-for-nrf-support-1.pcap

[J.P. Hutchins]

Small update: I have put the sniffer on a USB DK dongle and tested the samples/zigbee/light_bulb example "modified to be a lock" on the 52840 DK confirming the same interaction with Alexa.  I will proceed to put the Zigbee shell example on the DK as Marte has recommended: 

"""
If so, can you test by programming the Zigbee shell sample on one of them, and then send read attribute command (zcl attr read) to the lock device and see if the data type is still incorrect?
"""

[J.P. Hutchins]

Good progress, Marte!  I have setup the shell example on 52840 DK, set its role as coordinator, the production Lock joins, and we can read the identify attribute like so:

uart:~$ zcl attr read 0x9d8c 10 0x0003 0x0104 0x00
ID: 0 Type: 18 Value: 0
Done
[00:15:42.676,940] <inf> zigbee.eprxzcl: Received ZCL command (4): src_addr=0x9d8c(short) src_ep=10 dst_ep=64 cluster_id=0x0003 profile_id=0x0104 cmd_dir=1 common_cmd=1 cmd_id=0x01 cmd_seq=6 disable_def_resp=1 manuf_code=void payload=[0000001800] (4)
[00:15:43.734,985] <inf> zigbee_app_utils: Unimplemented signal (signal: 50, status: 0)

If I have executed correctly, I believe we are seeing the same error?  Very strange!  I will look into updating the SDK.  Is there another lock example (albeit from another SDK) that I should refer to?  It would be interesting to see if NRF can recreate this.

Thanks,
J.P.