At Lanware, we collaborate closely with clients to help them develop a range of IoT solutions. Customers frequently discuss the importance of managing power usage in the Internet of Things (IoT) properly. We'll talk about one of the ways to connect to AWS IoT Core while using less electricity in this blog article. We'll demonstrate just how the wireless transport method you choose can help you get more battery life. It is believed that communication will take place wirelessly, via LPWAN or Wi-Fi.

Powering a device isn't a problem in a lot of IoT projects, and line power can be employed. Other projects might not be able to supply power directly to the device due to building codes, the expense of running the power lines, or the requirement that the gadget is somewhat transportable. In such a case, the device's battery life will be taken into account. Any solution design will be constrained by the need to maximize battery life.

Although widely used and understood, Wi-Fi requires more power and has a higher transfer rate. A low-power wide area network, or LPWAN, utilizes less energy than regular Wi-Fi.
The next design will take into account the Wi-Fi mechanism and a potential design choice for that case.

Initial Concept

A device permanently stores its current state and event log onboard. It turns off the Wi-Fi radios to preserve battery life. The device cycles through the following actions, as shown in the diagram below:

• Switch on the Wi-Fi radio and establish a connection with the Wi-Fi gateway.  
  Link up with the endpoint.
• The event history should be published to a MQTT subject.
• Add the device's most recent configuration (state) to an AWS IoT device shadow.
• Download from an AWS IoT device shadow any updated required configuration settings (state).
• Depending on the desired state, update any setup settings.
• Disable the WiFi radio.
• You can think about extending the time between data transfers to increase battery life. 
• When it is predicted that the device won't be in use frequently, it can be set to a longer duration.

Groups of Devices

The initial idea can be expanded to incorporate groups of gadgets that are close to one another and need to periodically exchange information about their status and past events.

Not every gadget in this situation needs to transport data over an energy-intensive Wi-Fi connection. A combination BLE/Wi-Fi device in the cluster can receive data from the devices more efficiently by using Bluetooth low energy (BLE). On behalf of the actual devices, this BLE/Wi-Fi device establishes a connection to the network and sends data. The remainder of this post will refer to this gadget as a device gateway.

With the help of BLE, individual devices can promote themselves and offer more details about their status or available services. The specific devices may display data such as: 

• The interval since the event history was last retrieved.
• Significant occurrences in their past.
• Current battery level.
• The device gateway's activities are controlled by internal variables like the following: 
  • The amount of time an event history should stay on a particular device before being collected.
  • Whether the event history from a certain device that has a significant occurrence in its past should be instantly collected.
  • The following diagram illustrates how the device gateway regularly scans for BLE ads that meet the requirements.

The maximum interval between uploads has been surpassed by the first BLE device in the illustration. There are significant events that need to be uploaded on the final BLE device in the diagram.
The device gateway performs the following actions (for each device) if the event history for one or more specific devices needs to be uploaded:

• Uses BLE to connect to the device.
• Retrieving the device's data.
• These could be the MQTT topics themselves or the serial number used to determine which MQTT topic(s) should receive the device data.
• Activates the Wi-Fi radio and establishes a connection with the Wi-Fi gateway.
• The IoT endpoint is connected.
• Publishes the specific device history to the generated or provided MQTT topics.
• Notifies the independent device that the event history transmission was successful.
• Uploads the current configuration settings (state) of the independent device to an IoT device shadow.
• Downloads and sends to each individual device any updated configuration settings (state) from an AWS IoT device shadow.
• Synchronises the time on the device with the gateway.
• Disables the Wi-Fi radio.
• Turns off the BLE radio's active use.

By lowering the BLE radios' transmit power to an appropriate level for the cluster's distances and the BLE devices' advertising intervals, you can extend battery life even further. You can also disable the BLE radios for a while, depending on the necessary data transfer interval and the number of devices. (For instance, in the case where hourly or more frequent data gathering is required). There would still be at least a 10-minute overlap when the BLE radios are active even if they were turned off for 20 minutes per hour in both the independent devices and the device gateway. This can be a choice if there is sufficient time for all the devices to submit data through the gateway. It functions whether the times are accurate or not.

Conclusion
This blog post highlighted one of many power management options available for embedded software services in IoT applications. Combining BLE and Wi-Fi technologies, as well as selectively powering radios and transferring data in batches, can increase the life of the power source.

Lanware being an embedded software development company are skilled in delivering advanced firmware design and development services for consumer electronics, IoT, and other embedded software development services. Our deep-rooted experience in hardware, operating systems, low-level diagnostics, and performance tools is an enabler in building projects that combine speed and performance for cost-effectiveness. From a point of view of customization, we offer firmware development services for microcontrollers, from 8-bit to 64-bit.