Allow users to specify start and end time between which the schedule
will be active. A new object "validity" has been introduced for this.
Eg.
{
"Schedule": {
"Schedules": [
{
"name": "Evening",
"id": "8D37",
"operation": "add",
"validity": {
"start": 1698839416,
"end": 1698840916
},
"triggers": [
{
"m": 1053,
"d": 31
}
],
"action": {
"Light": {
"Power": true
}
}
}
]
}
}
This will allow providing a range between which the schedule should be active.
Eg. Turn on the light at 6:00pm everyday, only between 1-Nov-2023 to
30-Nov-2023. The ranges are to be specified as UTC epoch time.
This will make the code cleaner since timing related logic is linked
only to the trigger object and not the entire schedule object and
additionally, this can allow us to have multiple triggers per schedule
in future.
- Do not allow schedules with invalid trigger type
- For existing schedules with invalid trigger type, add handling so that they
expire after triggering once, similar to one time schedules.
After a schedule with "relative seconds" executed, the esp_rmaker_schedule
logic was disabling it. However, this was causing incorrect checks in
esp_schedule component logic, causing the schedule to get re-enabled.
Added a check similar to other schedules to prevent this.
When device is already provisioned, `wifi_prov_mgr_configure_sta` API call fails.
This happens because, provisioning manager is in uninitialized state.
We set Wi-Fi credetials directly using `esp_wifi_set_config` in that case.
Also removed error check on `wifi_prov_mgr_is_provisioned` API call, as for
IDF 4.x APIs return `ESP_ERR_INVALID_STATE`
- qrcode, ws2812_led and gpio_button moved to examples/common
- esp-insights and rmaker_common submodules updated
- json_generator and json_parser components copied from component
manager so that they can be used for component overrides
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
Now that we allow reading private key and certificate from secure cert
partition too, the node may not have MQTT host in nvs even in production
cases wherein claiming is disabled. This was causing errors in MQTT
init. This new config option forces firmware to use it from NVS.
This also helps in cases where the same node is to be connected to a
different server after an OTA.
- Updated partitions.csv in all examples to use final
esp_secure_cert partition format.
- This option can only be enabled if claiming is disabled.
- The Rainmaker app will fall back to using NVS if it
fails to fetch from the `esp_secure_cert` partition.
This has been done to allow a common firmware to be built that
can run on both kinds of devices, i.e. ones that use NVS
and ones that use the `esp_secure_cert` partition.
This will help ensure that OTA can be performed within specific dates
and within specific times within those dates.
Eg. Perform OTA between 1 Dec 2022 and 10 Dec 2022 that too only between
2:00am and 5:00am
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>
If the secure version of the OTA image is less than the one stored in efuse, the update will be rejected. This is useful when anti-rollback is enabled.
