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.

[Marte Myrvold]

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

[J.P. Hutchins]

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.

pcap-for-nrf-support-2.pcap

[J.P. Hutchins]

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.

[Marte Myrvold]

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

[J.P. Hutchins]

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.