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
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
Pull Request Summary: Fix Invalid Pointer Usage in esp_rmaker_report_info
Issue
Compilation failed due to incorrect pointer usage in snprintf and json_gen_obj_set_* calls. The function incorrectly passed &key_name (a char (*)[3] type) instead of key_name (a char *), causing type mismatch errors.
Fix
Corrected snprintf usage: Passed key_name instead of &key_name.
Fixed json_gen_obj_set_* calls: Removed unnecessary address-of operator (&key_name).
Ensured correct string formatting: snprintf now correctly assigns key_name values without an explicit null termination.
Impact
Resolves compilation errors for ESP32-C3 builds.
Maintains intended functionality with proper string handling.
No functional changes, just type correctness fixes.
This fix ensures successful builds and prevents runtime issues due to incorrect pointer usage
If the new bulk write callback is registered for a device/service instead of regular
callback, it was getting skipped for persistent params during initialisation.
