How To Reduce the Power Consumption of Smart Home Projects

2023-02-27 | By Maker.io Staff

As mentioned in the general overview of smart home systems, overcoming the problems caused by power-hungry components and communication protocols is one key consideration when designing smart devices. As these devices are active 24/7, they should naturally not use lots of energy to fulfill their task, especially when they’re entirely battery-operated, as changing or charging batteries is likely not something most users would want to do frequently.

With that in mind, this article discusses a few ideas that may help cut the power consumption of DIY smart devices.

Use Energy-Efficient Hardware in Smart Home Devices

How To Reduce the Power Consumption of Smart Home Projects We can choose from a wide range of platforms when planning projects. Make sure to select one that’s efficient and still fulfills all project requirements.

An obvious option when optimizing the power consumption of any electronic device is utilizing components and hardware that suit the requirements of the application and are as energy efficient as possible. Most IoT and smart home applications don’t require excessive processing power, so we can opt for more streamlined processors that typically draw less current even when put under full load. In the context of smart home projects powered by ESPHome, for example, choosing an ESP8266 over an ESP32 could drastically reduce power usage when both devices are often in their full operating mode, as the ESP8266 draws around 120mA. In contrast, the ESP32 requires around 180mA when transmitting data over WiFi. The ESP32 may even draw up to 240mA in its full-power mode, depending on the signal strength.

Use Adequate Communication Protocols for the Target Application

Choosing more efficient hardware is only sometimes an option, though. As demonstrated above, signal strength and the communication protocol and method often cause dramatic power usage differences. WiFi is a fantastic option for many use cases requiring reliable and fast data transmission (such as full-HD video streaming), which transmits many data packets. However, reading sensor values and sharing the data, which is often only a few bytes in size, doesn’t justify the high-power demands of WiFi.

With all this in mind, look into alternative low-rate wireless protocols - such as Thread or Zigbee - when WiFi isn’t required for a design. In addition, always consider the application context you are developing. If, for example, a device doesn’t need to continuously transmit data over Bluetooth, choosing BLE (Bluetooth Low Energy) over conventional Bluetooth communication can drastically reduce a device's power usage.

Avoid Constant Polling and Busy-Waiting

It’s important to also consider how helpful constant updates are in a given setting. For example, many applications don’t require polling sensor data every second or every few hundred milliseconds, as environmental parameters don’t change that frequently under normal circumstances. The light intensity outdoors, for example, doesn’t typically change dramatically every minute – maybe not even once every 15 minutes! Therefore, such an application would waste energy constantly polling sensors and transmitting the results to a base station if it were to generate updates every minute.

You should also let the board’s kernel decide what to do when an application stalls, either due to busy resources or because it’s waiting for some time to pass. In that case, avoid busy waiting, for example, by polling a flag that determines whether the program may access a file. Instead, use kernel-specific file handle methods for accessing resources and when forking/joining multi-threaded programs. Similarly, avoid using sleep methods, and utilize hardware interrupts, if possible.

Utilize MCU Sleep Modes and Interrupts

Finally, as mentioned, many consumer-grade connected applications don’t require deterministic real-time responses. Therefore, acting on older data and taking a few extra seconds to respond to requests is typically not a problem, especially when it comes to environmental sensor readings.

For example, it would be a massive waste of energy to let the MCU operate at full speed while it waits for the time to pass before sending the subsequent sensor reading result to the base station. Luckily, most (if not all) modern MCUs incorporate multiple sleep modes that disable certain functions that require lots of energy. The ESP32, for example, supports five different power modes ranging from full speed and unrestricted features to a hibernation mode that results in the device only drawing around five micro-Amperes of current (compared to 240 milliamperes under full load). However, in hibernation mode, most devices will not retain data stored in RAM. The only thing that remains active is typically some timer or real-time clock that can wake up the device periodically or when interrupts occur.

In the case of the ESP32 and ESP8266, ESPHome contains a module that lets makers configure these deep sleep modes to conserve energy in a battery-operated IoT application. A good strategy would be to assign the device a static IP so it can quickly re-connect upon waking up. Next, you should put the device in hibernation mode for a set period (e.g., 15 minutes) and wake it up periodically to read sensor values and transmit the results to the base station.

When receiving data, other power modes exist that only disable the wireless modules and periodically re-activate them, for example, once every second. This approach would be a good compromise between conserving energy and having predictable response times.

Summary

Sometimes, the most effortless way of conserving energy is by utilizing efficient hardware. Choose hardware that fulfills the requirements of the given application but doesn’t go over the top. For example, most IoT applications don’t require sophisticated processing devices, and often, streamlined approaches are more than capable enough while drawing less current.

Next, use state-of-the-art communication protocols that fit the application. For example, WiFi is fast, reliable, secure, and can transmit lots of data effortlessly. Still, it’s often unnecessary and requires lots of power, which might render it unsuitable for battery-operated devices.

Finally, avoid busy waiting in programs. Instead, let the device’s OS handle blocking calls, as it might internally shut down some parts of the MCU that are not required or put the device in some low-power sleep mode. In addition, consider using sleep modes typical of modern hardware, as most smart home applications don’t require constant polling and deterministic real-time response times.