This feature is intended for mapping already-provisioned nodes to user
accounts without re-provisioning.
Common features (both implementations):
- mDNS service: _esp_rmaker_chal_resp._tcp
- TXT records: node_id, port, sec_version, pop_required
- Optional instance name support (NULL uses node_id as default)
- Supports Security 0, 1 (with/without PoP), and 2 (SRP6a)
- Both use the same mDNS service type, simplifying CLI discovery
1. Standalone HTTP protocomm based challenge-response service.
- Config: CONFIG_ESP_RMAKER_ON_NETWORK_CHAL_RESP_ENABLE
- Endpoint: ch_resp (on protocomm HTTP server, default port 80)
- Instance name via config.mdns_instance_name
APIs:
- esp_rmaker_on_network_chal_resp_start()
- esp_rmaker_on_network_chal_resp_stop()
- esp_rmaker_on_network_chal_resp_is_running()
Note: Mutually exclusive with Local Control
2. Challenge-response support on local control.
- Config: CONFIG_ESP_RMAKER_LOCAL_CTRL_CHAL_RESP_ENABLE
- Endpoint: ch_resp (via esp_local_ctrl_set_handler)
- Instance name via parameter to enable function
APIs:
- esp_rmaker_local_ctrl_enable_chal_resp(instance_name)
- esp_rmaker_local_ctrl_disable_chal_resp()
3. CLI and console improvements.
- CLI simplified to discover only _esp_rmaker_chal_resp._tcp service
- Console command supports optional instance name: chal-resp-enable [instance_name]
- Device discovery output shows instance name column
Clients can choose to disable the challenge-response endpoint after
usage to avoid potential misuse by other entities on the network.
commit
This change allows adding a RainMaker service on which phone apps can
set id of the parent group (group_id) in which the node is added.
Once set, all local params will be reported on
node/<node_id>/params/local/<group_id> instead of node/<node_id>/params/local/
Additionally, application code can use the esp_rmaker_publish_direct()
API to publish any message on node/<node_id>/direct/params/local/<group_id>
Phone apps can subscribe to these topics to get these messages directly
from the MQTT broker
node/+/params/local/<group_id>
node/+/direct/params/local/<group_id>
For local params update, this change just helps to improve the latency
of param reporting.
The direct reporting allows to bypass the cloud side processing to send
messages directly to phone apps at very low cost
Phone apps can also publish param updates directly to node/<node_id>/params/remote/<group_id>
instead of using the set params API.
- Two APIs added: get_aws_region and get_security_token
- Useful, if an application needs to get credentials for a role
- Also, added the facility to set MQTT_CRED_HOST
Adds support for triggering parameter updates through the command-response
framework using the special command id 1. The feature is controlled by the new
CONFIG_ESP_RMAKER_PARAM_CMD_RESP_ENABLE option and is enabled by default
when command-response is enabled.
The status and updated params are returned in the response data
Sample command payload: {"params":{"Light":{"Power":false}}}
Sample response payload: {"status":"success","params":{"Light":{"Power":false}}}
This will also update the values in the params DB returned via the
regular get params APIs like GET /user/nodes/params
The regular OTA upgrades with ESP RainMaker required an additional https
connection to fetch the OTA image, which has a significant impact on
heap usage.
With MQTT OTA, the same MQTT channel used for rest of the RainMaker
communication is used to fetch the OTA image, thereby saving on RAM.
This could be slightly slower and may odd some cost. but the overall
impact would be low enough when compared against the advantages.
Signed-off-by: sanket.wadekar <sanket.wadekar@espressif.com>
Co-authored-by: Piyush Shah <piyush.shah@espressif.com>
This allows users to avoid the double reporting that happens when using
esp_rmaker_param_update_and_report(), once for regular param update and
once for time series update. This can help reduce cost, especially when
the apps are using values only from the simple time series API.
This will ensure that the size of simple time series data in backend
does not keep growing and gets deleted after the configured time.
Typically, 30-60 days would be enough for most use cases.
- Added signature generation for RSA signature in addition to ECDSA
- Bugfix: use inlen, instead of doing strlen on input data
- Bugfix: outlen should be `2 * slen` and not `slen` as we convert this to HEX
- Also added a sign-data console command
- component manager: Updated patch version for rainmaker component
A callback of type esp_rmaker_device_bulk_write_cb_t can be registered
using esp_rmaker_device_add_bulk_cb() to handle multiple param writes in
a single callback. This is especially useful for devices like lightbulb,
wherein a scene/schedule may have a combination of brightness, hue, saturation,
all of which should change together.
Additionally to optimise parameter reporting, internal logic has been changed such
that if the callbacks use esp_rmaker_param_update() instead of
esp_rmaker_param_update_and_report(), all updated parameters for a
device or service will get reported together instead of one parameter in
one message.
This is a simpler variant of time series data, which allows fetching
only raw values and not any aggregates like average, min, max, etc.
This option is cost efficient and is recommended if the application
requires only raw values.
Use PROP_FLAG_SIMPLE_TIME_SERIES instead of PROP_FLAG_TIME_SERIES in the
parameter properties flags to enable this.
If local control is enabled via config option (CONFIG_ESP_RMAKER_LOCAL_CTRL_AUTO_ENABLE),
the enabling/disabling will happen internally and the behaviour will be
unchanged. However, if the config option is disabled, applications can
still call esp_rmaker_local_ctrl_enable/disable at runtime as and when
required, if CONFIG_ESP_RMAKER_LOCAL_CTRL_FEATURE_ENABLE option is enabled.
Note that the older config option CONFIG_ESP_RMAKER_LOCAL_CTRL_ENABLE
has been renamed to CONFIG_ESP_RMAKER_LOCAL_CTRL_AUTO_ENABLE. However,
CONFIG_ESP_RMAKER_LOCAL_CTRL_ENABLE will also continue to work and
ensure backward compatibility
Cause: A vicious cycle:
MQTT budget exceed error print getting logged into ESP-Insights.
When the RTC memory is full, this causes it to drop the message and
raise memory full event, which then taken action as reporting Insights
data immediately. This again causes MQTT budget exceed error!
The fix: Do not try to send message when budget is not available
Signed-off-by: Vikram <vikram.dattu@espressif.com>
- OTA using topics is now enabled in all examples
- esp_rmaker_ota_enable_default() is the simplified API that enables
OTA using Topics with the default server certificates
- Expose some internal APIs
- External OTA callbacks can now call the internal function to manage OTA
- Applications can explicitly send the OTA fetch publish message to check
if OTA is available in case of OTA using Topics
- Handle network connectivity loss using keep-alive
- Send "rejected" as OTA status for project/version mismatch, instead of
"failed".
Node info:
- project_name: The name of the project as configured in CMakeLists.txt.
"model" was earlier being used for this and will continue to be used
for backward compatibility, but now it would be ok to override model
using the esp_rmaker_node_add_model() API.
- platformm: Read from CONFIG_IDF_TARGET, tells the platform being used
(esp32, esp32s2, esp32c3,....)
Device
- model (optional)
Even when an explicit user reset was triggered by the firmware,
the RMAKER_EVENT_USER_NODE_MAPPING_DONE event was getting generated,
which was misleading and causing issues while integrating other
frameworks. A new event RMAKER_EVENT_USER_NODE_MAPPING_RESET has
been added to distinguish this event.
The esp_rmaker_user_node_mapping_get_state() has also been exposed
for applications to use. Note that the CONFIG_ESP_RMAKER_USER_ID_CHECK
config option should be enabled to get correct state.
