When CONFIG_ESP_RMAKER_OTA_ROLLBACK_REPORT_FAILED is enabled, rolled-back
firmware reports 'failed' instead of 'rejected' when rollback occurs due
to MQTT connection timeout. Ensures backward compatibility by preventing
older firmware from reporting incorrect status.
Useful while testing on-network challenge-response based user node
mapping, either via standalone protocomm service or via local control.
Appropriate function gets called based on the Kconfig options selected.
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
If assisted claiming was already performed before calling
esp_rmaker_start(), the firmware was stalling with an incorrect print
saying that the Node connected to network without claiming.
This gets handled correctly now.
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.
- Assisted claiming is now the default so that the same firmware can
work with global as well as China RainMaker deployment.
- Challenge-Response based user-node mapping is now the default because
it is recommended workflow as it is faster and prevents sending Wi-Fi
credentials to invalid devices
- Build camera examples on IDF release/v5.5 for applicable targets
- Also updated the rainmaker component version
- Updated mdns component version to from 1.2.0 --> ^1.9.0
- Add set-param command to set device parameter values, invoke respective callbacks and report to cloud
Usage: set-param <device_name> <param_name> <value>
- Add update-param command to just report param value to cloud, without invoking callbacks
Usage: update-param <device_name> <param_name> <value>
- Add get-param command to get device parameter values
Usage: get-param <device_name> <param_name>
- Support all parameter types: boolean, integer, float, string
This enables easy interaction with ESP RainMaker devices through console interface.
- 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
Can be enabled using CONFIG_ESP_RMAKER_SCHEDULE_ENABLE_DAYLIGHT, which
depends on CONFIG_ESP_SCHEDULE_ENABLE_DAYLIGHT=y.
These can be more reliable compared to the cloud driven daylight
automations as the calculations happen locally on the device and
schedules can take effect even when the device is offline.
This also supports offset so that you can schedule actions before/after
sunrise/sunset.
Together, these have a binary size impact of about 12,250 bytes.
CONFIG_ESP_SCHEDULE_ENABLE_DAYLIGHT contributes 11,500 bytes
CONFIG_ESP_RMAKER_SCHEDULE_ENABLE_DAYLIGHT contributes additional 750
bytes.
Also removed CONFIG_ESP_RMAKER_USING_NETWORK_PROV
Made network prov as default since it is supported for esp-idf v5.1
onwards and esp-idf v5.0 has reached end of life.
This will make the code more readable
This is a synchronous user-node mapping method that is performed during
provisioning, but even before sending Wi-Fi credentials and does not require
any communication from the node to the cloud. Check the esp_rainmaker
component CHANGELOG for details.
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>
Triggering a new otafetch while one was already in progress was causing
crashes due to incorrect setting/clearing of data.
This happened specifically on rebooting into new firmware after an OTA
when both, CONFIG_BOOTLOADER_APP_ROLLBACK_ENABLE and CONFIG_ESP_RMAKER_OTA_AUTOFETCH
are enabled.
- Try OTA multiple times (as per `CONFIG_ESP_RMAKER_OTA_MAX_RETRIES`, set to 3 by default) if it fails
- Schedule an OTA fetch as per `CONFIG_ESP_RMAKER_OTA_RETRY_DELAY_MINUTES` if all retries fail
