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
Some string parameters may want to have a set of valid values which
it wants the client (phone apps primarily) to show in a dropdown.
A new API esp_rmaker_param_add_valid_str_list() has been added for that.
MAC address is a public information and can also be sniffed easily. Creating the proof of
possession pin from that is not secure enough. Instead, a random stream of bytes is now generated
and stored in the fctry partition during claiming and that is used for the PoP.
Using MQTT persistent session improves the reliability as the broker can then deliver any
pending QOS1 messages even after the node disconnects and then re-connects (within max 1hr).
However, it has a side-effect that messages can be received at unexpected times.
Please check the MQTT specs to understand persistent sessions.
Support for port 443 for MQTT has been enabled since it is generally open on most networks,
whereas port 8883 (default MQTT) could be blocked.
Validating the JSON arrays and objects would be the application's responsibility.
The RainMaker core will just treat them as strings (without the quotes, ofcourse).
Eg. Add a pre-generated JSON object, say {"name":"val"} into another object, giving
a result {"pregen":{"name":"val"}}
Similarly allow to read entire object string during parsing.
- APIs and data structures changed to a more object oriented approach.
- Some internal files split into multiple files to separate out functionality
of node, device and parameter.
- A new doc file CHANGES.md added to help understand the changes.
- Modified all the examples as per these changes in the RainMaker APIs.
