Alexa Identify Cluster

RE: Alexa Identify Cluster

J.P. Hutchins — Thu, 08 Sep 2022 22:18:46 GMT

Hi Marte,

I'm afraid that I had nasty error in my door lock cluster list declaration - fixing it resolved the Identify Time issue:

I had:

ZB_HA_DECLARE_DOOR_LOCK_CLUSTER_LIST(
	door_lock_clusters,
	basic_attr_list,
	identify_attr_list,
	groups_attr_list,
	scenes_attr_list,
	door_lock_attr_list);

Instead of:

ZB_HA_DECLARE_DOOR_LOCK_CLUSTER_LIST(
	door_lock_clusters,
    door_lock_attr_list,
	basic_attr_list,
	identify_attr_list,
	groups_attr_list,
	scenes_attr_list);

I hope that this can resolve your investigation.

J.P.

RE: Alexa Identify Cluster

Marte Myrvold — Thu, 08 Sep 2022 13:10:48 GMT

Hi J.P,

Good to hear that you seem to be close to a resolution. So you are able to connect to the Echo as long as the door lock state is not undefined?

This still does not explain why the data type of identify time is incorrect when using the door lock cluster.

Best regards,

Marte

RE: Alexa Identify Cluster

J.P. Hutchins — Wed, 07 Sep 2022 21:17:43 GMT

Hi Marte,

Important update: "got em"

After fixing the syntax error in the door lock cluster list I realized that Alexa is just raising error when it receives LOCK_STATE_DEFAULT AKA LOCK_STATE_UNDEFINED 0xff. So this is very very close to a resolution. I'd like to leave the ticket open for the time being but hope to close it soon after a bit more testing.

Sorry for any bug hunt just over a typo in a macro...

J.P.

RE: Alexa Identify Cluster

J.P. Hutchins — Wed, 07 Sep 2022 20:58:40 GMT

Thanks Marte! Important update - I had a mistake in my Door Lock Cluster List declaration that was causing the malformed packet (and likely lots of other problems 😬).

I had the door lock attr list in the wrong position!

Error:

ZB_HA_DECLARE_DOOR_LOCK_CLUSTER_LIST(
	door_lock_clusters,
	basic_attr_list,
	identify_attr_list,
	groups_attr_list,
	scenes_attr_list,
	door_lock_attr_list);

Fixed:

ZB_HA_DECLARE_DOOR_LOCK_CLUSTER_LIST(
	door_lock_clusters,
    door_lock_attr_list,
	basic_attr_list,
	identify_attr_list,
	groups_attr_list,
	scenes_attr_list);

This fixes the malformed packet in the identify responses.

However, the primary problem remains, that is that Alexa App says "Device doesn't support the requested value." It would be HUGE if NRF could set this up with an Echo Gen 4 as Zigbee coordinator and/or work with Amazon directly to understand what they are looking for!

I have attached a new PCAP that shows the correct identify response - I will be analyzing it to see if the Echo is requesting something that I'm not replying to but so far I just don't see it. It is titled "pcap-for-nrf-support-2.pcap".

Thanks again,
J.P.

devzone.nordicsemi.com/.../pcap_2D00_for_2D00_nrf_2D00_support_2D00_2.pcap

RE: Alexa Identify Cluster

Marte Myrvold — Wed, 07 Sep 2022 14:01:33 GMT

Hi J.P.,

I tested this on my side and was able to reproduce the issue, both in v1.8.0 and v2.0.2. And as you said, I only saw the issue when the device was a door lock, not light bulb. I will investigate some more and check with the development team if this is a bug.

Best regards,

Marte

RE: Alexa Identify Cluster

J.P. Hutchins — Tue, 06 Sep 2022 20:16:31 GMT

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.

RE: Alexa Identify Cluster

J.P. Hutchins — Tue, 06 Sep 2022 19:01:30 GMT

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?
"""

RE: Alexa Identify Cluster

J.P. Hutchins — Tue, 06 Sep 2022 18:00:58 GMT

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. Hutchinsdevzone.nordicsemi.com/.../pcap_2D00_for_2D00_nrf_2D00_support_2D00_1.pcap

RE: Alexa Identify Cluster

Marte Myrvold — Mon, 05 Sep 2022 14:39:28 GMT

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

RE: Alexa Identify Cluster

J.P. Hutchins — Fri, 02 Sep 2022 17:06:29 GMT

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?