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
- Latest commits on release branch may break our camera example builds
- We can keep updating the tags once in a while instead of using release branches
- Done only for release/v5.5 images of camera example builds
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
Remove the retry logic for Wi-Fi disconnected events while in
provisioning mode because it is handled internally by the
network_provisioning component. Now, depending on the Kconfig options,
the firmeare will try Wi-Fi connection one or more time and then stop.
Phone apps can reset the state and retry provisioning on the same
session.
Also, reduced the default connection retry count from 5 to 3 so that
users would have to wait for lesser time for retrying
rmaker_app_network: Support asynchronous network connection and add MFG device type and subtype for AI Agent
See merge request app-frameworks/esp-rainmaker!604
- Tasks running SPIRAM when do flash access crash with cache issues
- WebRTC task which calls fetch credential is in SPIRAM
- Made fetch credential API safe by moving the execution to internal rmaker_work_q
- 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
- Example uses `esp_rmaker_get_aws_security_token` internally to get the token
- The credential callback is registered with webrtc SDK which it can call
- webrtc SDK uses NVS to cache the signaling info internally
HomeKit has its own logic for network provisioning, including support
for Apple WAC and so, uses its own app_network component.
Recent restructuring pulled in the common rmaker_app_network component
instead.
