Zigbee Coordinator (Client) - IAS Zone Implementation

Question

SDK : nRF5_SDK_for_Thread_and_Zigbee_v4.1.0 Hardware : 2x nRF52840 (PCA10059) + 1x generic overflow sensor. This is an attempt to gather complete information regarding IAS Zone enrollment process implementation using ZBOSS Stack. The primary reference, as mentioned in previous post is Official Zigbee ZCL specification (chapter 8.2). Another interesting reference worth mentioning is HA API -> HA Devices -> IAS Zone sample , however, it is more related to IAS Zone server and incompatible with current SDK version. Another bit of information could be found in this post . It is based on relevant SDK version, but again, it is related to IAS Zone server and incomplete. That's all I have found for now. The rest, like IAS Zone cluster API is just pile of declarations wrapped into html, which does not help at all. Let's consider one mandatory enrollment method: 'Trip-to-Pair'. Below is the guiding algorithm from ZCL specification, as I understood it: (1) Perform service discovery. I assume, this could be achieved by a CLI command, or related function call TX < zdo simple_desc_req 0x9CC5 1 RX > src_addr=0x9CC5 ep=1 profile_id=0x0104 app_dev_id=0x402 app_dev_ver=0x1 in_clusters=0x0000,0x000A,0x0500,0x0001 out_clusters=0x0019 It is relatively easy to find how to use function zb_zdo_simple_desc_req() called from zigbee_cli_cmd_zdo.c Ok, now we see that sensor has 0x0500 (IAS Zone cluster), so the rest makes sense. (2) Send a Write Attribute command on the IAS Zone server’s IAS_CIE_Address attribute (0x0010) with its IEEE address. TX < zcl attr write 0x9CC5 1 0x0500 0x0104 0x0010 0xF0 0xF4CE36089BA25E4A RX > Done NOTE1: According to Wireshark, we received even more than expected: 0x0000 > 0xf230 | ZCL: Write Attributes, Seq: 4, Cmd: Write Attributes (0x02) 0xf230 > 0x0000 | ZCL: Write Attributes Response, Seq: 4, Cmd: Write Attributes Response (0x04), Status: Success (0x00) ... 0xf230 > 0x0000 | ZCL IAS Zone: Zone Status Change Notification, Seq: 81, Cmd: Zone Status Change Notification (0x00), Extended Status: 0x00 0x0000 > 0xf230 | ZCL: Default Response, Seq: 81, Cmd: Default Response (0x0b), Status: Unsupported Cluster (0xc3) ... 0xf230 > 0x0000 | ZCL IAS Zone: Zone Enroll Request, Seq: 82, Cmd: Zone Enroll Request (0x01), ZoneType: Water sensor (0x002a) 0x0000 > 0xf230 | ZCL: Default Response, Seq: 82, Cmd: Default Response (0x0b), Status: Unsupported Cluster (0xc3) NOTE2: reading/writing attributes is already quite tricky and not trivial to figure out how to use directly without CLI. Still not sure how, when and where to call it. (3) Receive confirmation from 'IAS Zone server' (sensor) (?) and start waiting for a 'Zone Status Change Notification' with ZoneState attribute equal to 0x00. Again, accoring to Wireshark the system did receive this packet, and even responded, but neither debug log, nor CLI interface reflected that. (4) Upon receipt of the above specified packet, send a 'Zone Enroll Response' command which assigns the IAS Zone server’s ZoneID attribute. I assume this is where we should respond with the following TX < zcl cmd 0xF230 1 0x0500 -p 0x0104 0x00 -l 0x0001 RX > Done NOTE1: Wireshark log: 0x0000 > 0xf230 | ZCL IAS Zone: Zone Enroll Response, Seq: 9, Cmd: Zone Enroll Resp(0x00), Enroll resp code: Success (0x00), Zone ID: 0x01 0xf230 > 0x0000 | APS: Ack, Dst Endpt: 1, Src Endpt: 1 NOTE2: Again, how to use it without CLI??? (5) Receive(?) confirmation from IAS Zone server (sensor). I guess, this might be either 'APS: Ack' mentioned above, or we might have to read related attribute manually TX < zcl attr read 0xF230 1 0x0500 0x0104 0x0000 RX > ID: 0x0000 Type: 0x30 Value: 1 The next step isn't mentioned, but I think it might be necessary to conduct at this stage in order to recevie (parse?) incoming async reports . (?) Bind. This might be achieved by the following command of related function call TX < zdo bind on 0x5C0272FFFEB9F593 1 0xF4CE36089BA25E4A1 0x0500 0x9CC5 RX > Done However, the fist problem, is that Responces to 'IAS Zone Report' and 'IAS Zone Enrollment Request' are 'unsupported cluster', so obvously someting else has to be done on the ZC side to instruct ZBOSS stack to to handle 'IAS Zone'-related packets. And the second problem is that system does receive 'Zone Status Change' reports, but never reflects that in log or CLI. Note that above communication resulted in after calling zb_zcl_ias_zone_init_client(), after calling zboss_start_no_autostart() . I find references to non-existent files/foldes with essential information, like " The complete set of IAS Zone samples can be found in /application/ias_zone_sensor " in the "documentation" at infocenter.nordicsemi.com and in source files/header and wonder why is it removed/hidden? It is among necessary algorithms, required by multiple types of standard sensors, yet unavailable wouthout any options. Finally, the general question is: how do you (Nordic Developers) expect us (users / 3d party developers) to figure out the sequence of variable decalarations, function calls and callbacks registrations without detaild documentation and examples? Trial-Error? I'm afraid reading headers with minimal comments like "This functions is for that." does not really help, since we still don't undestand what are the prerequisites for that function, what are the inputs/outputs, limitations, etc. Most probably, I am missing something, but I have already spent significant amount of time digging though all available sources of information, so I would really appreciate if you could direct me. Regards, - Nikita

Nik · Accepted Answer

Hi Marjeris, 
 Once again, thank you for your advices. 
 Alright, so here are the results: 
 First, as you have suggested, I attempted to declare IAS Zone CIE cluster. However, device was failing to start. After a ton of experiments I found that if I modify ZB_HA_DECLARE_IAS_CONTROL_INDICATING_EQUIPMENT_CLUSTER_LIST() macro by moving ZB_ZCL_CLUSTER_DESC() with ZB_ZCL_CLUSTER_ID_GROUPS and ZB_ZCL_CLUSTER_ID_SCENES above IAS_* related clusters, device starts up successfully and works properly. Don't ask how... Long term stability yet unknown. Please let me know I am doing something wrong, my code is below. 
 Another major breakthrough happened when I found zigbee_logger_eprxzcl_ep_handler() function inside zigbee_logger_eprxzcl.c file, which clearly demonstrated how to work with bufid . 
 I assume I should handle 'Zone Enroll Requests' inside ep_handler , and also call ZB_ZCL_IAS_ZONE_SEND_ZONE_ENROLL_RES(buffer, addr, dst_addr_mode, dst_ep, ep, prfl_id, def_resp, cb, code, zone_id) macro, is that correct? And, by the way, can I use callback's bufid as buffer, or should I create a new one with zb_buf_get_out() ? And, should I also return ZB_TRUE from ep_handler after calling that function macro to prevent default response? 
 Here is how it looks right now: 
 #define APP_DECLARE_IAS_CONTROL_INDICATING_EQUIPMENT_CLUSTER_LIST(cluster_list_name, basic_attr_list, identify_attr_list, ias_ace_attr_list) \ zb_zcl_cluster_desc_t cluster_list_name[] = { \ ZB_ZCL_CLUSTER_DESC(ZB_ZCL_CLUSTER_ID_BASIC, ZB_ZCL_ARRAY_SIZE(basic_attr_list, zb_zcl_attr_t), (basic_attr_list), ZB_ZCL_CLUSTER_SERVER_ROLE, ZB_ZCL_MANUF_CODE_INVALID), \ ZB_ZCL_CLUSTER_DESC(ZB_ZCL_CLUSTER_ID_IDENTIFY, 0, NULL, ZB_ZCL_CLUSTER_CLIENT_ROLE, ZB_ZCL_MANUF_CODE_INVALID ), \ ZB_ZCL_CLUSTER_DESC(ZB_ZCL_CLUSTER_ID_IDENTIFY, ZB_ZCL_ARRAY_SIZE(identify_attr_list, zb_zcl_attr_t), (identify_attr_list), ZB_ZCL_CLUSTER_SERVER_ROLE, ZB_ZCL_MANUF_CODE_INVALID), \ ZB_ZCL_CLUSTER_DESC(ZB_ZCL_CLUSTER_ID_GROUPS, 0, NULL, ZB_ZCL_CLUSTER_CLIENT_ROLE, ZB_ZCL_MANUF_CODE_INVALID ), \ ZB_ZCL_CLUSTER_DESC(ZB_ZCL_CLUSTER_ID_SCENES, 0, NULL, ZB_ZCL_CLUSTER_CLIENT_ROLE, ZB_ZCL_MANUF_CODE_INVALID ), \ ZB_ZCL_CLUSTER_DESC(ZB_ZCL_CLUSTER_ID_IAS_ZONE, 0, NULL, ZB_ZCL_CLUSTER_CLIENT_ROLE, ZB_ZCL_MANUF_CODE_INVALID ), \ ZB_ZCL_CLUSTER_DESC(ZB_ZCL_CLUSTER_ID_IAS_ACE, ZB_ZCL_ARRAY_SIZE(ias_ace_attr_list, zb_zcl_attr_t), (ias_ace_attr_list), ZB_ZCL_CLUSTER_SERVER_ROLE,ZB_ZCL_MANUF_CODE_INVALID), \ ZB_ZCL_CLUSTER_DESC(ZB_ZCL_CLUSTER_ID_IAS_WD, 0, NULL, ZB_ZCL_CLUSTER_CLIENT_ROLE, ZB_ZCL_MANUF_CODE_INVALID ), \ } typedef struct { zb_zcl_basic_attrs_t basic_attr; zb_zcl_identify_attrs_t identify_attr; struct { zb_uint8_t zone_state; zb_uint16_t zone_type; zb_uint16_t zone_status; zb_uint8_t ias_ace_zone_table_len; zb_zcl_ias_ace_zone_table_t table[10]; // max is [ZB_ZCL_IAS_ACE_ZONE_TABLE_LENGTH] and sizeof(table) = 3825 (!) } ias_zone_attr; } coord_attrs_t; static coord_attrs_t coord; ZB_ZCL_DECLARE_BASIC_ATTRIB_LIST(basic_attr_list, &coord.basic_attr.zcl_version, &coord.basic_attr.power_source); ZB_ZCL_DECLARE_IDENTIFY_ATTRIB_LIST(identify_attr_list, &coord.identify_attr.identify_time); ZB_ZCL_DECLARE_IAS_ACE_ATTRIB_LIST(ias_ace_attr_list, &coord.ias_zone_attr.ias_ace_zone_table_len, coord.ias_zone_attr.table); ZB_HA_DECLARE_CONFIGURATION_TOOL_CLUSTER_LIST(cli_agent_clusters, basic_attr_list, identify_attr_list); APP_DECLARE_IAS_CONTROL_INDICATING_EQUIPMENT_CLUSTER_LIST(ias_zone_cie_clusters, basic_attr_list, identify_attr_list, ias_ace_attr_list); // NK // rearranged ZB_HA_DECLARE_IAS_CONTROL_INDICATING_EQUIPMENT_CLUSTER_LIST(), otherwise hangs @ startup ZB_HA_DECLARE_CONFIGURATION_TOOL_EP(cli_agent_ep, ZIGBEE_CLI_ENDPOINT, cli_agent_clusters); ZB_HA_DECLARE_IAS_CONTROL_INDICATING_EQUIPMENT_EP(ias_zone_cie_ep, MAIN_ENDPOINT, ias_zone_cie_clusters); ZBOSS_DECLARE_DEVICE_CTX_2_EP(device_ctx, cli_agent_ep, ias_zone_cie_ep); //(...) zb_uint8_t coord_main_ep_handler(zb_bufid_t bufid) { zigbee_logger_eprxzcl_ep_handler(bufid); return ZB_FALSE; // continue packet processing inside default callback handler } int main () { //(...) ZB_AF_REGISTER_DEVICE_CTX(&device_ctx); ZB_AF_SET_ENDPOINT_HANDLER(ZIGBEE_CLI_ENDPOINT, cli_agent_ep_handler); ZB_AF_SET_ENDPOINT_HANDLER(MAIN_ENDPOINT, coord_main_ep_handler); //(...) } 
 It is also not quite clear how to use ZB_ZCL_DECLARE_IAS_ACE_ATTRIB_LIST() which requires 'pointer to variable to store IAS ACE Zone Table attribute'. Is ZBOSS core going to allocate memory inside persistent config sector? In RAM? Do I have to allocate manually dynamically / staticaly? Allocate one value or as much as I expect to use, or max possible size? 
 zb_uint8_t ias_ace_zone_table_len; // Option1 zb_zcl_ias_ace_zone_table_t *table; ZB_ZCL_DECLARE_IAS_ACE_ATTRIB_LIST(ias_ace_attr_list, &ias_ace_zone_table_len, &table); // Option2 zb_zcl_ias_ace_zone_table_t table; ZB_ZCL_DECLARE_IAS_ACE_ATTRIB_LIST(ias_ace_attr_list, &ias_ace_zone_table_len, &table); // Option3 zb_zcl_ias_ace_zone_table_t table[10]; ZB_ZCL_DECLARE_IAS_ACE_ATTRIB_LIST(ias_ace_attr_list, &ias_ace_zone_table_len, table); // Option4 zb_zcl_ias_ace_zone_table_t table[ZB_ZCL_IAS_ACE_ZONE_TABLE_LENGTH]; // LENGTH = 255, size()= almost 4KB ZB_ZCL_DECLARE_IAS_ACE_ATTRIB_LIST(ias_ace_attr_list, &ias_ace_zone_table_len, table); 
 Please advice, since all options compile and the device starts up successfully, but I cannot test actual functionality at this point. 
 I also found this line in the config 
 #define ZB_CONFIG_OVERALL_NETWORK_SIZE 200 // 2 <= x <= 200 
 So, I would like to know, what is the theoretical limit of the zigbee network if ZC is NRF52840? What if it is only a Router? Is it theoretically possible to connect, say, 2000 devices, or there is simply not enough memory to store routing table on NRF52840? 
 Regards, 
 Nikita

Zigbee Coordinator (Client) - IAS Zone Implementation

This is an attempt to gather complete information regarding IAS Zone enrollment process implementation using ZBOSS Stack.

Top Replies