Battery power in IoT devices: what to monitor before communication is lost

An IoT device can work normally until the moment it stops transmitting. When the cause is power, operations often discover the problem only after the interruption.

This behavior is especially relevant for sensors installed in remote locations, equipment powered by batteries, and controllers that depend on a main supply with backup battery. Replacement or inspection may require travel, access authorization, a compatible part, and coordination with the local team.

Energy monitoring helps anticipate some of these situations, but it must respect an important limitation: not every device offers the same indicators, and no isolated value explains the full condition of the battery.

Planning maintenance requires combining available telemetry, consumption history, and operating context.

The percentage shown may not tell the whole story

Many devices display a charge indicator as a percentage. That number looks simple, but it may be calculated in different ways by the manufacturer.

Some devices estimate charge from voltage. Others use accumulated current, electrochemical models, or dedicated measurement circuits. Accuracy varies with battery chemistry, temperature, applied load, aging, and the quality of the model used.

It is also necessary to distinguish concepts.

State of charge

State of charge, known as SoC, represents an estimate of the energy available at that moment relative to usable capacity.

State of health

State of health, known as SoH, seeks to represent battery degradation compared with its initial condition. A battery may show high charge and still have lower total capacity because of aging.

Estimated autonomy

Autonomy tries to answer how long the device will keep operating. This forecast depends on available energy and future consumption, which can change with signal, transmissions, processing, temperature, and operating mode.

Texas Instruments highlights SoC and SoH as distinct parameters in battery monitoring systems [1]. For an IoT operation, this means a charge percentage should not automatically be interpreted as a health measure or as precise remaining time.

The first question is which data the equipment actually provides

Before creating rules, the team needs to consult the manufacturer documentation and identify available indicators.

Among the data that may exist are:

1. Battery voltage.
2. Charge or discharge current.
3. State of charge.
4. State of health.
5. Remaining capacity.
6. Temperature.
7. Cycle count.
8. Main supply status.
9. Battery-on-discharge event.
10. Undervoltage or disconnect alarm.

Not every device offers this list. Some send only voltage. Others report a discrete state, such as normal or low battery. Some equipment provides no energy telemetry at all.

The monitoring strategy must start from existing data, without creating a precision the device does not provide.

Voltage, current, and temperature must be interpreted together

Voltage can help identify drops, undervoltage, and loss of main supply. However, its meaning depends on chemistry, load, and equipment state.

Current shows whether the battery is charging or discharging and helps understand device consumption. A sustained increase may indicate a behavior change, repeated communication attempts, or a component running longer.

Temperature influences performance, safety, and aging. It can also indicate inadequate installation conditions. The correct limit must come from equipment and battery documentation, not a generic value applied to all assets.

These indicators gain usefulness when analyzed over time. A point reading reports a condition. A trend shows whether that condition is deteriorating.

Communication also consumes energy

Constrained devices operate with combined limits on processing, memory, communication, and energy. Internet Engineering Task Force (IETF) RFC 7228 describes node classes with limited energy and recognizes equipment that depends on recharge periods, replacement, or intermittent sources [2].

In an IoT solution, consumption does not depend only on measurement. Transmitting data, searching for a network, authenticating, retransmitting packets, and keeping communication interfaces active also uses energy.

A device installed in an area with poor signal may make more connection attempts. A change in publication frequency may increase the number of transmissions. A firmware update may change how long the radio stays active.

Therefore, a reduction in autonomy should not immediately be attributed to the battery. Investigation must consider connectivity, configuration, firmware, and usage pattern.

Low-power modes change how availability is interpreted

Many devices save energy by staying inactive part of the time. They wake to measure, transmit, or respond to an event and then return to low-power mode.

RFC 8352 collects energy-efficiency mechanisms used by Internet of Things protocols and discusses support for sleeping nodes [3]. This behavior reduces consumption but changes monitoring.

A temporary disconnection may be normal. A longer interval between messages may result from an energy-saving policy. The platform must know the expected cycle so it does not turn every inactive period into an incident.

There is also an operational trade-off. Transmitting more frequently offers fresher data but can raise consumption. Transmitting less frequently preserves energy but increases the time to notice a failure.

This decision should be made according to application criticality.

Fixed thresholds help, but they do not solve everything

A low-battery alert is useful when the equipment provides a reliable indicator and the threshold aligns with its documentation.

However, a single threshold can fail in important situations.

Voltage may drop during a consumption peak and recover. Temperature may temporarily change behavior. An aged battery may discharge faster after crossing a certain point. Equipment of the same model may show different histories because of installation conditions.

A more consistent approach combines three types of rule.

Immediate condition

Signals an event that requires quick attention, such as undervoltage, temperature outside limits, or loss of main supply when the backup battery is sustaining operation.

Trend

Tracks evolution over days or weeks. A faster drop than the historical pattern may indicate a consumption change or degradation.

Planning

Relates battery history with maintenance cycles, asset criticality, location, and time needed for replacement.

These rules have different objectives. Immediate condition responds to current risk. Trend seeks to recognize deterioration. Planning organizes intervention before interruption.

An alert must provide context for maintenance

Reporting only that the battery is low shifts the entire diagnosis to the team.

A more useful record can include:

1. Device identification and location.
2. Equipment model and battery type.
3. Current value and unit.
4. Recent trend.
5. Time of last measurement.
6. Main supply status.
7. Signal quality and reconnection history.
8. Current transmission frequency.
9. Last recorded replacement or maintenance.
10. Criticality of the information produced by the asset.

This set helps decide whether the problem requires an immediate response, monitoring, or inclusion in a scheduled route.

It also reduces the risk of replacing the battery when the real cause lies in another component. A charger, regulator, cable, connector, or environmental condition can produce similar symptoms.

Autonomy must be presented as an estimate

Predicting remaining operating time is a task subject to uncertainty.

An estimate depends on usable capacity and expected consumption. Both can vary. Capacity changes with aging and temperature. Consumption changes with communication, processing, active sensors, and environmental events.

When the equipment provides only voltage, converting that value directly into remaining hours can produce false precision. Even when a dedicated measurement circuit exists, the estimate remains conditioned on the model and usage profile.

Therefore, the interface should present the origin of the estimate, its observation period, and its limitations. In many cases, a trend and an attention band are more useful than an apparently exact countdown.

History helps build an operational reference

After accumulating enough data, the organization can compare devices of the same model under similar conditions.

This comparison can reveal equipment that discharges faster, locations with more reconnections, changes after an update, or differences linked to temperature.

It is important to keep comparable groups. Mixing models, chemistries, configurations, and different environments can lead to incorrect conclusions.

History also allows reviewing thresholds. A rule defined during the project may prove too sensitive or too slow when confronted with real operation. Adjusting monitoring is part of the solution lifecycle.

When there is no battery telemetry

Some equipment does not report voltage, charge, or energy health. In that situation, the platform should not pretend to know battery condition.

It is still possible to work with indirect evidence:

1. Time since installation or last replacement.
2. Number of transmissions.
3. Reconnection frequency.
4. Signal quality.
5. Ambient temperature.
6. Usage profile.
7. Previous occurrences for the same model.

These signals help plan inspections but do not replace direct measurement. Operations should record this limitation and avoid classifying a forecast as confirmed state.

Monitoring battery means monitoring an operational condition

Power is part of the reliability of an IoT solution. A battery can lose capacity, discharge faster because of connectivity, operate outside expected temperature, or fail to sustain the equipment after loss of main supply.

A consistent strategy starts with device documentation. Then it combines voltage, current, temperature, states provided by the equipment, history, and operating context.

This article expands on one of the points presented in IoT device monitoring: why is connecting not enough?. It also relates to handling devices with no data, because energy degradation can end in silence but needs to be investigated as its own domain.

For managers in IT, telecommunications, infrastructure, and operations, the more useful question is not only how much battery remains. It is necessary to understand which evidence supports that information, how the condition evolves, and how much time the team needs to act.

Maintenance becomes more predictable when energy condition is tracked before communication is lost.

About Target Solutions

Target Solutions has spent more than 15 years helping organizations evolve their infrastructure, monitoring, observability, automation, and operational intelligence operations. Across that journey, it has participated in projects in complex environments in telecom, technology, government, energy, and large enterprises, contributing to higher operational efficiency and service reliability.

That experience includes Internet of Things projects in which devices, power, connectivity, and maintenance processes need to be observed in an integrated way.

About the author

Paulo Florêncio de Menezes is cofounder of Target Solutions and has spent more than 15 years on projects related to infrastructure, monitoring, observability, automation, and IT and telecom operations.

He holds a degree in data processing from the Federal University of Amazonas (UFAM), an MBA in business management from Fundação Dom Cabral (FDC), and a professional master’s in economics from Fundação Getulio Vargas (FGV).

In his master’s research, he developed the IBEOP-IA (Brazilian Index of Occupational Exposure Potential to Artificial Intelligence), studying the potential exposure of Brazilian occupations to AI capabilities through a combination of occupational data, artificial intelligence patents, and natural language processing techniques.

References

[1] TEXAS INSTRUMENTS. Next-Generation Battery Monitoring With Electrochemical Impedance Spectroscopy. 2026.

[2] BORMANN, Carsten; ERSUE, Mehmet; KERANEN, Ari. Terminology for Constrained-Node Networks. RFC 7228. Internet Engineering Task Force, May 2014.

[3] GOMEZ, Carles; CROWCROFT, Jon; SCHULZRINNE, Henning. Energy-Efficient Features of Internet of Things Protocols. RFC 8352. Internet Engineering Task Force, Apr. 2018.