JN-SW-4170: Incoming message corrupts outgoing message

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

JN-SW-4170: Incoming message corrupts outgoing message

1,559 Views
grafalex
Contributor II

I am working on a smart switch. It has a 'Client' mode, when this switch act only like a controller to a bound light device. When user presses a button my device generates 2 type of events:

1) Multistate input cluster attribute report, indicating number of button presses (e.g. single/double/tripple press). This is sent using eZCL_ReportAttribute() call, network mode E_ZCL_AM_SHORT.

2) OnOff toggle command to the bound device (sent using eCLD_OnOffCommandSend() function, E_ZCL_AM_BOUND addressing mode)

These 2 events are generated one after another, without any other network/SDK calls in between.

In 95% cases everything works normally: attribute is reported to the coordinator, and coordinator responds with ACK first, and then with default response. The command is also sent normally (in my test coordinator is the target bound device)

grafalex_0-1706211877962.png

 

Unfortunately in remaining 5% cases the On/Off Toggle command is corrupted, and just received Default response message is sent instead.

grafalex_1-1706211928378.png

See line 3838 - this message is sent FROM the device, its content is almost identical to the message received in the previous line, but has a few fields changed (cluster is On/Off while the received default response was for multistate input).

Is there a way to get things more stable? 

0 Kudos
Reply
2 Replies

1,388 Views
grafalex
Contributor II

Thank you for suggestion regarding using JN5189. Unfortunately I cannot do this, as the board I am using is JN5169-based.

In the meantime I managed to fix (work around?) the problem by using E_ZCL_AM_BOUND_NON_BLOCKING instead of E_ZCL_AM_BOUND mode for sending On/Off commands. Unfortunately the documentation does not explain the difference between these 2 modes, but this seems to fix my issue (or at least significantly reduce its probability).

I would really appreciate if you could point me to the description about E_ZCL_AM_BOUND_NON_BLOCKING vs E_ZCL_AM_BOUND modes.

0 Kudos
Reply

1,520 Views
EduardoZamora
NXP TechSupport
NXP TechSupport

Hello @grafalex

Hope you are doing well.

Please, consider that JN5189/88T is preferred for any new Zigbee®, Thread design.

Could you please help me with a few more details about your development?

Is your project based on any of the Application Notes available for this device? Application Notes are listed in JN516x/7x Zigbee 3.0. If that is the case, which one are you using?

By any chance, are you using a custom board?

Any additional information is really appreciated.

Regards,
Eduardo.

0 Kudos
Reply