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.
- 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.
If network connection fails even once, the firmware reports so to
clients (like phone apps) and the clients declare failure and abort
immediately, even if the firmware eventually connects. With this
change, a failure will be reported only after a few retries (whise
number is configurable)
- Use led_indicator component from component manager for ws2812 and RGB
LEDs
- Add other components from examples/common via idf_component.yml
instead of adding as EXTRA_COMPONENT_DIRS in CMakeLists.txt
