Hi,
Greetings!
I wish to understand that esp_rmaker_param_bounds_t, esp_rmaker_param_valid_str_list_t are not accessible at application level and on other side application has to take care of validation of new values to get updated to esp_rmaker_param_t.
Also if the bounds and/or valid string list also get updated by means of some mechanism at application level then application has to maintain another copy of same data.
Can anyone please share any particular reason for the same? Actually I am trying to avoid changes in Rainmaker framework while developing our application software.
Thanks in advance.
Regards,
Dinesh
esp_rmaker_param_bounds_t and esp_rmaker_param_valid_str_list_t
-
- Posts: 308
- Joined: Wed Feb 20, 2019 7:02 am
Re: esp_rmaker_param_bounds_t and esp_rmaker_param_valid_str_list_t
Hi Dinesh,
ESP RainMaker is not really a specification for device types, like how it is for HomeKit, Matter or Zigbee devices. It is a lower layer framework on top of which you can define any device types that you want with your own limits as per what is supported by your hardware. The bounds and valid strings are more like inputs for the phone app to draw appropriate UI (slider limits, dropdown list, etc.) rather than to restrict the values that can be accepted by the firmware. The default bounds for the standard params are generally accepted values which we think would be valid for most cases, but can be over-ridden by your application logic. It is expected that the application will provide the limits and manage them in the callbacks. Even then, we do understand that it would help to read the values of these bounds and we may provide an API soon.
You may consider adding a feature request via Github Issues.
ESP RainMaker is not really a specification for device types, like how it is for HomeKit, Matter or Zigbee devices. It is a lower layer framework on top of which you can define any device types that you want with your own limits as per what is supported by your hardware. The bounds and valid strings are more like inputs for the phone app to draw appropriate UI (slider limits, dropdown list, etc.) rather than to restrict the values that can be accepted by the firmware. The default bounds for the standard params are generally accepted values which we think would be valid for most cases, but can be over-ridden by your application logic. It is expected that the application will provide the limits and manage them in the callbacks. Even then, we do understand that it would help to read the values of these bounds and we may provide an API soon.
You may consider adding a feature request via Github Issues.
Who is online
Users browsing this forum: No registered users and 12 guests