跳到主要内容

Local Control

ESP RainMaker was primary built to offer remote connectivity to ESP Devices. However, if the phone and the device are connected to the same Wi-Fi network, controlling the device directly on the local network is much faster and reliable.

ESP IDF already provides a component called ESP Local Control which uses mDNS based discovery and HTTP based control. This has now been integrated into ESP RainMaker. Since the cloud is no more in picture here, it can work even when there is no Internet.

At the component config level, this feature has been kept disabled by default, because originally, the local control support relied only on the Wi-Fi level security. Any client on the same Wi-Fi network could discover and control the devices over HTTP (even though the phone apps will only show the devices actually linked to the user). However, we now support secure local control (called as security level 1, or simply sec1), which is much safer to use. So, it is recommended to keep this feature enabled in your project's sdkconfig.

To enable local control in your project, please set CONFIG_ESP_RMAKER_LOCAL_CTRL_ENABLE=y and then set the security mode to 1 using CONFIG_ESP_RMAKER_LOCAL_CTRL_SECURITY_1=y (or idf.py menuconfig -> ESP RainMaker Config -> ESP RainMaker Local Control).

Note: Secure local control can currently work with esp-idf release/v4.2 (later than release v4.2.2), release/v4.3 (release v4.3.2 onwards) and all the other newer release branches.

Please ensure that you have the latest phone apps and you are good to go. Whenever a device is available to control on the local network, it will show as Reachable on WLAN in the phone apps. If it is a "secure" session, it will also show a lock icon alongside.

Note that you still need Internet connectivity while adding a new device. A device will be shown as available on local network only if the user-node association process was successful.

For more information on how security is managed in local control, please refer the local control service documentation.

Why not HTTPS?​

Using HTTPS in itself isn't sufficient without mutual authentication. This requires unique certificates to be provisioned on the devices and the users (phone-apps).

  • For the users, the same certificate should be propagated across all the phones/clients corresponding to the same user
  • Some phone operating systems (iOS) do not allow self-signed server certificates. This makes provisioning device certificates more complex.