Open diazmanuel opened 1 month ago
@diazmanuel,
It is a bug, please add \0
to the end of crono_temeperature
to fix it.
@xieqinan , hello, okey thanks we will try it, but will this be fixed in the incoming updates?
hello @xieqinan, We tried to add the /0 to the end of the string but this ended up crashing the program, I think the problem may be affecting other points, please let me know when you can solve it
The string used to write to the attribute should follow the format in ZCL spec, that is the first octect in the string should contains the character length. For example, you want to write ESPRESSIF\0
, the string should use "\x0A""ESPRESSIF"
.
Please tell me if this resolves your issue.
hello @lpy4105 @xieqinan, Yes, we respected the correct format as indicated in the Zigbee documentation, at first this worked without problems but after the change that was made to support long strings there began to be problems, but in subsequent versions we verified that it worked correctly. Therefore there must be another internal problem that is causing this probably related to increasing string length
hello @lpy4105 @xieqinan, Do you have any update regarding this issue? It is something that is slowing down our development because it causes us to crash. If you need anything to help you identify the problem, please let me know.
@diazmanuel ,
Could you please show me the value of uint8_t crono_temperature[MAX_ZIGBEE_CRONO_LEN];
before you call esp_zb_custom_cluster_add_custom_attr()
to add it to the cluster?
Hello @xieqinan , I work with @diazmanuel , currently with version 1.3.1 we continue to have problems that have worsened even more.
To declare the attribute we do the following
esp_zb_ep_list_t *esp_zb_ep_list;
esp_zb_cluster_list_t *esp_zb_cluster_list;
esp_zb_attribute_list_t *esp_zb_attribute_list;
esp_zb_endpoint_config_t esp_zb_endpoint_config;
esp_zb_endpoint_config.app_profile_id=ESP_ZB_AF_HA_PROFILE_ID;
esp_zb_endpoint_config.app_device_id=ESP_ZB_HA_CUSTOM_ATTR_DEVICE_ID;
esp_zb_ep_list = esp_zb_ep_list_create();
esp_zb_cluster_list = esp_zb_zcl_cluster_list_create();
esp_zb_attribute_list = esp_zb_zcl_attr_list_create(CUSTOM_THERMOSTAT_CLUSTER_ID);
esp_zb_custom_cluster_add_custom_attr(esp_zb_attribute_list, CUSTOM_THERMOSTAT_CLUSTER_ATTR_LOCAL_TEMPERATURE, ESP_ZB_ZCL_ATTR_TYPE_S16,ESP_ZB_ZCL_ATTR_ACCESS_READ_ONLY | ESP_ZB_ZCL_ATTR_ACCESS_REPORTING, (void *)&datos_task_zigbee_handler.cluster_data.thermostat.local_temperature);
esp_zb_custom_cluster_add_custom_attr(esp_zb_attribute_list, CUSTOM_THERMOSTAT_CLUSTER_ATTR_HUMIDITY, ESP_ZB_ZCL_ATTR_TYPE_S16,ESP_ZB_ZCL_ATTR_ACCESS_READ_ONLY | ESP_ZB_ZCL_ATTR_ACCESS_REPORTING, (void *)&datos_task_zigbee_handler.cluster_data.thermostat.humidity);
esp_zb_custom_cluster_add_custom_attr(esp_zb_attribute_list, CUSTOM_THERMOSTAT_CLUSTER_ATTR_LOCAL_TEMPERATURE_OFFSET, ESP_ZB_ZCL_ATTR_TYPE_S16, ESP_ZB_ZCL_ATTR_ACCESS_READ_WRITE | ESP_ZB_ZCL_ATTR_ACCESS_REPORTING,(void *)&datos_task_zigbee_handler.cluster_data.thermostat.local_temperature_offset);
esp_zb_custom_cluster_add_custom_attr(esp_zb_attribute_list, CUSTOM_THERMOSTAT_CLUSTER_ATTR_AWAY_TEMPERATURE, ESP_ZB_ZCL_ATTR_TYPE_S16,ESP_ZB_ZCL_ATTR_ACCESS_READ_WRITE | ESP_ZB_ZCL_ATTR_ACCESS_REPORTING, (void *)&datos_task_zigbee_handler.cluster_data.thermostat.away_temperature);
esp_zb_custom_cluster_add_custom_attr(esp_zb_attribute_list, CUSTOM_THERMOSTAT_CLUSTER_ATTR_TARGET_TEMPERATURE, ESP_ZB_ZCL_ATTR_TYPE_S16,ESP_ZB_ZCL_ATTR_ACCESS_READ_WRITE | ESP_ZB_ZCL_ATTR_ACCESS_REPORTING, (void *)&datos_task_zigbee_handler.cluster_data.thermostat.target_temperature);
esp_zb_custom_cluster_add_custom_attr(esp_zb_attribute_list, CUSTOM_THERMOSTAT_CLUSTER_ATTR_MODE, ESP_ZB_ZCL_ATTR_TYPE_S16,ESP_ZB_ZCL_ATTR_ACCESS_READ_WRITE | ESP_ZB_ZCL_ATTR_ACCESS_REPORTING, (void *)&datos_task_zigbee_handler.cluster_data.thermostat.mode);
esp_zb_custom_cluster_add_custom_attr(esp_zb_attribute_list, CUSTOM_THERMOSTAT_CLUSTER_ATTR_CHILD_LOCK, ESP_ZB_ZCL_ATTR_TYPE_S16,ESP_ZB_ZCL_ATTR_ACCESS_READ_WRITE | ESP_ZB_ZCL_ATTR_ACCESS_REPORTING, (void *)&datos_task_zigbee_handler.cluster_data.thermostat.child_lock);
esp_zb_custom_cluster_add_custom_attr(esp_zb_attribute_list, CUSTOM_THERMOSTAT_CLUSTER_ATTR_BATERRY, ESP_ZB_ZCL_ATTR_TYPE_S16,ESP_ZB_ZCL_ATTR_ACCESS_READ_ONLY | ESP_ZB_ZCL_ATTR_ACCESS_REPORTING, (void *)&datos_task_zigbee_handler.cluster_data.thermostat.baterryPorcentage);
esp_zb_custom_cluster_add_custom_attr(esp_zb_attribute_list, CUSTOM_THERMOSTAT_CLUSTER_ATTR_ERROR, ESP_ZB_ZCL_ATTR_TYPE_S16,ESP_ZB_ZCL_ATTR_ACCESS_READ_ONLY | ESP_ZB_ZCL_ATTR_ACCESS_REPORTING, (void *)&datos_task_zigbee_handler.cluster_data.thermostat.error);
esp_zb_custom_cluster_add_custom_attr(esp_zb_attribute_list, CUSTOM_THERMOSTAT_CLUSTER_ATTR_ON_OFF, ESP_ZB_ZCL_ATTR_TYPE_S16,ESP_ZB_ZCL_ATTR_ACCESS_READ_ONLY | ESP_ZB_ZCL_ATTR_ACCESS_REPORTING, (void *)&datos_task_zigbee_handler.cluster_data.thermostat.on_off);
esp_zb_custom_cluster_add_custom_attr(esp_zb_attribute_list, CUSTOM_THERMOSTAT_CLUSTER_ATTR_CRONO_TEMPERATURE, ESP_ZB_ZCL_ATTR_TYPE_CHAR_STRING,ESP_ZB_ZCL_ATTR_ACCESS_READ_WRITE, datos_task_zigbee_handler.cluster_data.thermostat.crono_temeperature);
esp_zb_cluster_list_add_custom_cluster(esp_zb_cluster_list, esp_zb_attribute_list, ESP_ZB_ZCL_CLUSTER_CLIENT_ROLE );
esp_zb_cluster_list_add_custom_cluster(esp_zb_cluster_list, esp_zb_attribute_list, ESP_ZB_ZCL_CLUSTER_SERVER_ROLE );
esp_zb_endpoint_config.endpoint=ZIGBEE_THERMOSTAT_ENDPOINT;
esp_zb_ep_list_add_ep(esp_zb_ep_list, esp_zb_cluster_list, esp_zb_endpoint_config);
esp_zb_device_register(esp_zb_ep_list);
Then we initialize the string data as follows
const char *aux_crono = "1420287F0058247F0030287F003C297F00402B7F00382C7F002C207F00492D7F0001377F003E287F004B2B7F0024287F0004287F0050287F0042287F001F3C7F0022287F0017287F000A287F0026287F00";
uint8_t aux_crono2[250] = {0};
memset(aux_crono2,'\0',250); memcpy(aux_crono2,aux_crono,strlen(aux_crono)); ZB_ZCL_SET_STRING_VAL(datos_task_zigbee_handler.cluster_data.thermostat.crono_temeperature,aux_crono2,strlen((const char *)aux_crono2));
And when trying to make a read from the network coordinator to the end device that has the attribute with the aforementioned string, the reading fails and the following callback ESP_ZB_CORE_CMD_DEFAULT_RESP_CB_ID occurs on the end device in static esp_err_t zb_action_handler(esp_zb_core_action_callback_id_t callback_id, const void *message)
hello @xieqinan, @lpy4105 , do you have any update about this issue ? are you working on it ? we really need to solve this one to continue with our project
Hi @diazmanuel, We have been aware of this issue. You could try the following workarround to unblock you development before we finish the fix.
When adding attribute:
#define BUFFER_SIZE 0xFF
uint8_t buffer[BUFFER_SIZE] = {0};
buffer[0] = BUFFER_SIZE - 1;
esp_zb_custom_cluster_add_custom_attr(esp_zb_attribute_list, CUSTOM_THERMOSTAT_CLUSTER_ATTR_CRONO_TEMPERATURE, ESP_ZB_ZCL_ATTR_TYPE_CHAR_STRING,ESP_ZB_ZCL_ATTR_ACCESS_READ_WRITE, buffer);
...
esp_zb_device_register(esp_zb_ep_list);
This could ensure the SDK allocate enough memory for string type attributes. Also, please note that the SDK allocates memory for attributes inside itself, so change the contents in buffer
(or in your example, datos_task_zigbee_handler.cluster_data.thermostat.crono_temeperature
) wouldn't really change the value of the attribute, please use esp_zb_zcl_set_attribute_val
to do so.
Hello @lpy4105 , when carrying out the tests with what you tell me, after initialization, the same error continues to occur. the reading response never arrives from the coordinator.
The code used after initializing is the following:
char *long_str = "1420287F0058247F0030287F003C297F00402B7F00382C7F002C207F00492D7F0001377F003E287F004B2B7F0024287F0004287F0050287F0042287F001F3C7F0022287F0017287F000A287F0026287F00";
char aux_crono_clean[250] = {0};
memset(aux_crono_clean,'\0',250);
ZB_ZCL_SET_STRING_VAL(aux_crono_clean,long_str,strlen((const char *)long_str));
esp_zb_zcl_set_attribute_val(1,65513,ESP_ZB_ZCL_CLUSTER_SERVER_ROLE,4,aux_crono_clean,false);
I am waiting for any questions that will help resolve this bug.
Hi @lpy4105 , I'm sorry to be insistent on this, but the solutions you proposed failed to resolve or patch the problem. Currently this prevents us from performing several necessary actions when it comes to writing and reading string attributes. Were you able to identify the problem? Is there anything we can help you with to speed up the resolution of this issue? In case you manage to find the problem, do you have an estimated date of when it will be resolved? Are you actively working on this issue? I know there are many questions but I wanted to be able to organize the development of these products depending on the status of this issue
Answers checklist.
IDF version.
5.1.3
esp-zigbee-lib version.
1..2.3
esp-zboss-lib version.
1.2.3
Espressif SoC revision.
ESP32-H2 & ESP32-C6
What is the expected behavior?
The expected behavior is for it to work as it should.
What is the actual behavior?
I am trying to write an attribute of type string locally using the esp_zb_zcl_set_attribute_val function. When doing so, it happens to me that other data from the same cluster is deleted and it depends on the order in which the cluster is defined if it works or not, I understand that it would be overflowing. This happens with long strings (about 100 characters)
The case shown below is declaring the attribute to be written (CUSTOM_THERMOSTAT_CLUSTER_ATTR_CRONO_TEMPERATURE) almost at the end of the cluster declaration. In this case, the device works without problems, the value is written correctly and does not damage the rest of the cluster data.
On the other hand, in this case the declaration of the attribute (CUSTOM_THERMOSTAT_CLUSTER_ATTR_CRONO_TEMPERATURE) is done at the beginning, although the writing ends without problems, the rest of the attributes of this cluster are damaged. In some cases your data is deleted or modified.
Steps to reproduce.
More Information.
No response