This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Question) Connect zigbee End-device , Coordinator

I would like to confirm that the temperature measurement is sent from the end-device to the coordinator using the example zigbee temperature sensor.

I'm looking at Testing at "https://infocenter.nordicsemi.com/index.jsp?topic=%2Fsdk_tz_v3.1.0%2Fzigbee_multi_sensor_example.html", but it doesn't connect from the Multisensor(end-device) to the Coordinator after starting as shown in number 3.
Is there anything I'm missing?

And the ep=10 shown in the output in number 4 looks like an endpoint, so can I see it as an endpoint id?

               Zigbee CLI Agent example                                                      MultiSensor

Parents
  • Hi,

    From your text and the documentation you're referring to it seems like your goal is to use the Multi Sensor example. However, in the output from the sensor it seems like you're using the Multi Sensor with FreeRTOS example instead. Could you make sure that you're using the correct project file for your example, as well as the correct documentation for that example?

    Are you only issuing the "bdb role zc" and "bdb start" commands? If so, what happens if you try to issue the other ZCL commands stated in the documentation for the example? Could you please copy the commands you issue as well as the output you get and paste it here as text. If you're using PuTTY you can copy this by right clicking on the top of the window and selecting "Copy All to Clipboard"

    Best regards,

    Marte

  • Sorry for the late reply.
    I knew it wasn't connected using 'free_rtos' as you answered.
    Used as a basic 'multi_sensor' and functioning normally.
    Here are some questions.
    1. Use 'attr_type = 41' to execute 'subscribe' command. I looked up at '41'. ZB_ZCL_ATTR_TYPE_OCTET_STRING = 0x41, /*!!Actet string data type, */' Can you tell me why you use it?

      ZB_ZCL_ATTR_TYPE_OCTET_STRING   = 0x41, /*!< Octet string data type, */

    2. To reboot and reconnect the connection, the connection cannot be connected like the following logs. When you re-upload the 'multi_sensor', the connection is connected normally. Can you tell me why?

    3. When receiving 'temperature measurement' and 'pressure measurement' values, we could see that they received the following structure. Here, the measured value is attr_value[1] and can the 'temperature measurement' and 'pressure measurement' values be arranged in one array?

    typedef ZB_PACKED_PRE struct zb_zcl_report_attr_req_s
    {
      zb_uint16_t attr_id;       /*!< Attribute ID */
      zb_uint8_t  attr_type;     /*!< Attribute type */
      zb_uint8_t  attr_value[1]; /*!< Attribute value */
    } ZB_PACKED_STRUCT
    zb_zcl_report_attr_req_t;

Reply
  • Sorry for the late reply.
    I knew it wasn't connected using 'free_rtos' as you answered.
    Used as a basic 'multi_sensor' and functioning normally.
    Here are some questions.
    1. Use 'attr_type = 41' to execute 'subscribe' command. I looked up at '41'. ZB_ZCL_ATTR_TYPE_OCTET_STRING = 0x41, /*!!Actet string data type, */' Can you tell me why you use it?

      ZB_ZCL_ATTR_TYPE_OCTET_STRING   = 0x41, /*!< Octet string data type, */

    2. To reboot and reconnect the connection, the connection cannot be connected like the following logs. When you re-upload the 'multi_sensor', the connection is connected normally. Can you tell me why?

    3. When receiving 'temperature measurement' and 'pressure measurement' values, we could see that they received the following structure. Here, the measured value is attr_value[1] and can the 'temperature measurement' and 'pressure measurement' values be arranged in one array?

    typedef ZB_PACKED_PRE struct zb_zcl_report_attr_req_s
    {
      zb_uint16_t attr_id;       /*!< Attribute ID */
      zb_uint8_t  attr_type;     /*!< Attribute type */
      zb_uint8_t  attr_value[1]; /*!< Attribute value */
    } ZB_PACKED_STRUCT
    zb_zcl_report_attr_req_t;

Children
  • Hi,

    Q1:

    Do you mean why the value is 41 or why octet string is used? The reason ZB_ZCL_ATTR_TYPE_OCTET_STRING is 0x41 is because that's what it's specified as in the Zigbee Cluster Library (ZCL) specification, specifically chapter 2.6.2. In table 2-10 Data Types in the ZCL specs you can find this definition. The reason octet string is used is because that's the attribute type of the Report Attributes Command Frame, which you can see in ZCL spec ch. 2.5.11.1. An octet is data that consists of 8 bits, and an octet string is a variable-length sequence of octets (8 bits). In Zigbee, the octet string data type contains data in an application-defined format. You can read more about octet strings in the ZLC spec ch. 2.6.2.11

    Q2

    If I understand you correctly you're connecting as expected, and if you reboot or power-off the devices it doesn't behave as expected after powering on again, but if you flash the program to the board anew it will connect as normally until you reboot it again? The device is most likely saving network parameters to NVRAM after connecting, and as such the configuration will be in the memory of the device when it powers on the next time as well. If you erase the board when flashing the program to your board then this will also be deleted, which is why it acts as normal the first time you power it on after flashing. You can change this by setting #define ERASE_PERSISTENT_CONFIG ZB_TRUE in main.c. You can read more about NVRAM here.

    Q3

    attr_value[1] is Attribute Data Field and contain the actual value of the attribute being reported. In the ZCL spec you can read about attribute reporting for the different cluster libraries (ch. 4.4.2.5 for temperature measurement and ch 4.5.2.5 for pressure measurement), as well as read about Report Attributes Command (ch. 2.5.11). There you can find that MeasuredValue is one of the attributes that shall be reported for both temperature and pressure measurement. These values can be arranged in one array for both temperature and pressure after the values are received, as they're just values with the data type int16.

    Hope this answers your questions!

    Best regards,

    Marte

  • I have a company workshop this week, so my answer is late.

    First of all, thank you so much for your reply.

    I don't think I wrote the gist of the question for number 2, so I'm writing it again.

    I Uploaded and connected the 'zcl_cli_agent_router sdk' and 'end-device sdk' to the two flushed boards as shown below.

    zigbee_cli_agent_router log

    ↑ log

    <info> app : Production configureatrion is not present or invalid (status: - 1)

    <info> app: Zigbee stack initializd

    <info> app: Unable to join the network, start network steering

    <info> app: Started network rejoin procedure.

    <info> app: Joined network successfully on reboot signal (Extended PAN ID : f4ce36fcedb0c643, PAN ID :  0xD08C)

    <info> app: Network rejoin precedure stopped as NOT scheduled.

    Next, https://infocenter.nordicsemi.com/index.jsp topic=%2Fsdk_tz_v4.0.0%2Fzigbee_multi_sensor_example.html

    After executing steps 1 to 10 of the 'Testing' part of the document, the log output was made after receiving the temperature and pressure measurement values normally.

    After that, Coordinator pressed 'reset' button and did 'bdb role zc' and 'bdb start' as shown in the picture above, and then 'reset' the multisensor.

    At this time, it is not connected to the coordinator.

    As you told me, I put in #define ERASE_PERSISTENT_CONFIG ZB_TRUE, but it was the same result.

    I've put in both the multi-sensor and coordinator, but the connection is not as good as before, should I install additional parts or other parts?

    3. Can I send it in one array before receiving it? My question is as follows.
    - The current sending value is 'zb_uint8_t' (1byte), but can I increase the size of the sending value and receive it at once as much as the coordinator sent? If I can receive it, how many maximum bytes can I send and receive?
    ex)

    current

    //multisensor code
    
    static void zb_app_timer_handler(void * context)
    {
        zb_zcl_status_t zcl_status;
        static zb_int16_t new_temp_value, new_pres_value;
    
        /* Get new temperature measured value */
        
        // before
        new_temp_value = (zb_int16_t)sensorsim_measure(&m_temperature_sim_state, &m_temperature_sim_cfg);
        zcl_status = zb_zcl_set_attr_val(MULTI_SENSOR_ENDPOINT, 
                                         ZB_ZCL_CLUSTER_ID_TEMP_MEASUREMENT, 
                                         ZB_ZCL_CLUSTER_SERVER_ROLE, 
                                         ZB_ZCL_ATTR_TEMP_MEASUREMENT_VALUE_ID, 
                                         (zb_uint8_t *)&new_temp_value, 
                                         ZB_FALSE);
        if(zcl_status != ZB_ZCL_STATUS_SUCCESS)
        {
            NRF_LOG_INFO("Set temperature value fail. zcl_status: %d", zcl_status);
        }
        // end
    }

    after

    //multisensor code
    
    static void zb_app_timer_handler(void * context)
    {
        zb_zcl_status_t zcl_status;
        static zb_int8 test1, test2,test3[2];
    
        /* Get new temperature measured value */
        
        
        test1 = "0x12";
        test2 = "0x32";
        test3[0]=test1;
        test3[1]=test2;
        zcl_status = zb_zcl_set_attr_val(MULTI_SENSOR_ENDPOINT, 
                                         ZB_ZCL_CLUSTER_ID_TEMP_MEASUREMENT, 
                                         ZB_ZCL_CLUSTER_SERVER_ROLE, 
                                         ZB_ZCL_ATTR_TEMP_MEASUREMENT_VALUE_ID, 
                                         (zb_uint8_t *)&test3 , 
                                         ZB_FALSE);
        if(zcl_status != ZB_ZCL_STATUS_SUCCESS)
        {
            NRF_LOG_INFO("Set temperature value fail. zcl_status: %d", zcl_status);
        }
    
        //end
    }

  • Hi,

    Q2:

    I tested this myself using the CLI Agent example and Multi Sensor, both with and without FreeRTOS, and I see that my last response was wrong. It should be ERASE_PERSISTENT_CONFIG ZB_FALSE instead. I'm sorry for giving the wrong information. If you set this to true the network will form when both devices are reset, and if one device is turned off, then one device will have the old network settings, but the device that is reset doesn't have these settings anymore. I tested with both ZB_FALSE and ZB_TRUE, and when using ZB_FALSE in both projects I was able to successfully reconnect after reset by following what you did (connect as normally, reset CLI Agent, bdb role zc, bdb start, reset Multi Sensor).

    Q3:

    Do you want to send a value that is of a different type than zb_uint8_t? If so, you would have to change the zb_zcl_set_attr_val() function, as that function is implemented such that the value is of the type zb_uint8_t. This function is part of the Zigbee stack, that is ZBOSS, so you're not able to see nor change the implementation of that function, as it's not available. If you were to change the type of the value, you would have to implement a function to set attribute value yourself, which I don't recommend doing.

    However, if your goal is to send something other than new_temp_value, but which is of type zb_uint8_t, then you should be able to do that without problem. new_temp_value, which you get by calling the function sensorsim_measure(), is simply a simulated temperature measurement.

    Best regards,

    Marte

Related