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.
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.
The JSON generator and JSON parser being used in ESP RainMaker were
taken from third party repos. In order to ensure that they are
better in sync with the upstream repos, they have now been included
as submodules.
Please run `git submodule update --init --recursive` once to pull in
these submodules.
- In claiming, change the 4 byte random number to 64 byte and store it
as binary data instead of hex representation.
- Instead of reading PoP as hex string from NVS, read it as binary data
(because of above change) and then convert to hex representation.
- Instead of using mac address, use last 3 bytes of the above random number
number as suffix for SSID.
The last change was made so as to allow generating the QR code completely outside
the device, without knowing its mac address.
The RainMaker core has special handling for the "name" type of parameter
and so, it does not call the application registered callback for this
parameter. However, the internal check was erroneous and the callback
was getting skipped even when the param type was NULL. The check has
now been fixed.
Earlier, it was the application code's responsibility to call the
esp_rmaker_user_mapping_endpoint_create() and esp_rmaker_user_mapping_endpoint_register()
APIs at appropriate places in Wi-Fi provisioning code to enable user node mapping
functionality. To simplify this, the logic has been moved to RainMaker Core, so that
this happens automatically.
For some reason, if you want to retain the older logic in your application code
and do not want RainMaker_core to enable this, please set the
CONFIG_ESP_RMAKER_DISABLE_USER_MAPPING_PROV config option.
Default parameter names like name, power, etc. have been changed to Name, Power, etc.
respectively, so that they look better in the phone app UIs.
Note that, with this change, any user configured device name (the name set from phone apps),
or any other persistent parameter for which a default name was used (Eg. power)
will be affected, as the values will no more be found in the NVS storage. Please edit your
application code accordingly if you want to stick with the old names.
Please check CHANGES.md for guidelines.
Abstracted out the get node config and get/set node params functions so
that they just act upon the JSON data, irrespective of the source of the
requests.
This is specifically for simplifying ESP32 claiming workflow,
wherein the phone apps will assist the node for claiming during
Wi-Fi provisioning. There would be no need of using CLI for claiming.
This will work only for BLE provisioning, as internet connectivity
will be required for claiming, and it may not be possible with
SoftAP.
Examples:
tz-set posix CST-8
I (25752) esp_rmaker_time_sync: The current time is: Tue Sep 1 21:48:13 2020 +0800[CST], DST: No.
tz-set America/Los_Angeles
I (70892) esp_rmaker_time_sync: The current time is: Tue Sep 1 06:48:58 2020 -0700[PDT], DST: Yes.
local-time
esp_rmaker_commands: Current local time: Tue Sep 1 06:49:21 2020 -0700[PDT], DST: Yes
Raw APIs as well as a RainMaker service have been provided to manage timezones.
Timezone information is stored in NVS so that it stays even across reboots.
A config option CONFIG_ESP_RMAKER_DEF_TIMEZONE has also been added to set the
default timezone.
If IDF version being used is 4.0, following changes will happen:
- tcpip_adapter will be used, instead of esp_netif.
- MQTT port 8883 will be used, even if 443 is chosen, because
443 requires ALPN options in MQTT, which aren't supported in IDF 4.0
The common code for WS2812 RGB LED has been moved to a component ws2812_led.
The WS2812 LED is available only on ESP32-S2-Saola-1 boards and hence
it will be enabled only if IDF target is set to ESP32S2. It can
be disabled by disabling the CONFIG_WS2812_LED_ENABLE config option.
led_strip component files have also been moved to ws2812_led
