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.
Some RainMaker events could be useful for applications, either
to take some action, or trigger indicators. These are now
exposed using the ESP Events framework of ESP IDF.
