Firmware
Before you finalise your firmware, please take care of the following.
Creating a Project
Even if the standard examples are good starting points for your projects, please create a copy of an example suitable for your use case and then maintain it seperately so that there are no conflicts when you try to pull the latest esp-rainmaker code. Tracking your project specific changes using a version control system like git is recommended.
Claiming
As mentioned elsewhere in the docs, claiming is not available on private RainMaker Deployments. Please use the RainMaker Admin CLI to generate the credentials to be flashed in the fctry partition. Additionally, disable these config options in your projects's sdkconfig.defaults to save some flash footprint:
CONFIG_ESP_RMAKER_ASSISTED_CLAIM
CONFIG_ESP_RMAKER_SELF_CLAIM
Provisioning QR Code
In the developer use case, the provisioning QR code is shown on the serial terminal. However, in production environment, the QR code needs to be generated outside the device. The RainMaker Admin CLI provides a facility to generate these QR codes.
Over the Air (OTA) Firmware Updates
OTA FW Updates are enabled by default in the switch and led_light examples. Here is a snippet of the code:
esp_rmaker_ota_config_t ota_config = {
.server_cert = ESP_RMAKER_OTA_DEFAULT_SERVER_CERT,
};
esp_rmaker_ota_enable(&ota_config, OTA_USING_PARAMS);
This is configured to work for OTA using parameters, which is meant for makers' use cases. For the dashboard driven upgrades, change the OTA_USING_PARAMS to OTA_USING_TOPICS.
esp_rmaker_ota_enable(&ota_config, OTA_USING_TOPICS);
Please check here for more details on OTA. Note that only the "super admin" user can access the dashboard and perform OTA operations via the dashboard.
Timezones
If you plan to use scheduling, please ensure that a timezone is set in your firmware or the timezone service is added for run-time timezone configuration. More information on this can be found here. Most examples have the timezone service added by default.
Scheduling
If you want scheduling to be available in your firmware, it has to be added explicitly, using the appropriate API. Check here for more information. Note that timezones are mandatory for scheduling to work correctly. Most examples have the scheduling service added by default.
Max supported schedules
The maximum number of schedules supported can be configured by using the CONFIG_ESP_RMAKER_SCHEDULING_MAX_SCHEDULES config option (idf.py menuconfig -> ESP RainMaker Config -> ESP RainMaker Scheduling -> Maximum Schedules). The default value was 5 earlier, but is now 10. If this is not sufficient for your use case, you may increase the value. However, note that since all scheduling information is reported as a RainMaker "parameter", there is hard limit of 8KB on the total size of all the parameters combined since we use AWS IoT Shadow to maintain the parameter values in cloud.
Local Control
ESP RainMaker offers a local control facility which helps in two ways:
- Faster response
- Lower cost (since REST API calls are avoided)
Please check here for instructions to enable this. However, please also check the security considerations before you enable this.