Setting correct timezone is mandatory for scheduling to work correctly.
Earlier, the default timezone was set to "Asia/Shanghai" and a config
change was required for setting appropriate timezone.
However, now that the phone apps have support for setting the timezone
using the RainMaker timezone service, it has been enabled in all
examples that had scheduling enabled.
The node config and node params JSON were limited by the size specified
in config options, since the JSON generator required pre-allocated buffer.
Now that the JSON generator gives a facility of finding out the total length
required to create the JSON, this config based limitation could be removed.
ESP_RMAKER_MAX_NODE_CONFIG_SIZE has been removed and instead, the required
node config size is dynamically computed and allocated.
ESP_RMAKER_MAX_PARAM_DATA_SIZE has still been retained and used as the
default size of params JSON, since params sizes keep on changing and it is
best to not keep re-allocating buffers. However, if the required size
exceeds the current max size, the node params buffer is re-allocated.
Similar logic has also been used in schedules JSON and the default max
scheduled count has been increased from 5 to 10, since higher number of
schedules can no more cause buffer overflow issues.
Button event callbacks are executed in the context of FreeRTOS Timer task.
Reporting param updates from that causes stack overflow, specifically on ESP32-C3.
As a temporary workaround, the stack size for FreeRTOS Timer task has been increased.
esp_timer is generally recommended when high precision is required.
However, since that is not the case for periodic reporting of temperature
values, replaced it with freeRTOS Timer.
The following are now part of a separate repo (and included as git submodule):
- MQTT glue layer
- Work Queue
- Utilities (reset, reboot, time sync, timezone, etc.)
- Factory Storage
Even CLI is now a part of a seperate repo, included here as a git submodule.
The provisioning name (SSID/BLE device name) and PoP are generated from
the general purpose random bytes stored in the factory NVS partition.
If a node hasn't completed claiming, these random bytes was getting re-generated
on a reboot, thereby causing the name and pop to change, which is undesirable.
With this fix, the random bytes will be generated only if not done already.
Note that an erase_flash will erase these bytes as well and so,
the provisioning name and PoP will still change in that case.
Since only a single protocomm_httpd instance is allowed at a time, starting local
control before soft AP provisioning ends causes errors. So now, we wait for
provisioning to finish before starting local control.
Once the node connects to a Wi-Fi network, it would now be possible to
control it from a client in the same network. This will be useful when
the Internet connection is down. It will also reduce the cloud communication
in general and will be faster.
