What actually drains an IoT device battery

A practical configuration guide for engineers and integrators

Key takeaways

• Battery life depends on the device's entire power profile, not just battery capacity in mAh.
• Reading frequency and transmission frequency are two separate decisions. Batching lets data be stored locally and sent less often without losing granularity upstream.
• Idle consumption should be assessed for the whole device, not just the processor, since active peripherals or a modem can keep drawing power during sleep.
• For NB-IoT, PSM and eDRX trade consumption against network reachability. For LoRaWAN, the choice between confirmed and unconfirmed uplinks and the use of ADR affect consumption directly.
• Real installation conditions, radio signal quality and temperature, change the power profile compared with lab or bench testing.
• Error states such as failed readings or retransmissions extend active time and must be included in the power budget, not just the happy path.

‍

A ten-year battery life rating does not mean a device will run for ten years under any configuration. The same hardware can show very different consumption depending on how often it reads data, how often it sends it, how long it stays active, how it handles connected interfaces, and what it does when communication fails.

For this reason, integration should not focus solely on battery capacity but on the device's overall power profile. That is where energy-inefficient activities tend to hide, and their impact can often be reduced through configuration alone.

What makes up a device's power profile

A battery-powered IoT device rarely runs in a single constant state. Operation consists of short active phases and, typically, much longer periods of sleep. A typical cycle for a remote reading converter looks roughly like this: sleep, wake up, activate the interface, read the meter, process the data, transmit over radio, return to sleep.

Each part has a different consumption level and a different duration. Situations where something does not go smoothly the first time also need to be accounted for, such as a meter not responding or a device failing to connect to the network. Battery capacity in mAh alone is therefore not enough, since estimating battery life also requires knowing how often and for how long each part of the cycle runs.

Reading frequency is not the same as transmission frequency

Needing a consumption value every 15 minutes does not automatically mean the device must establish radio communication and send that value separately each time. Where the device and the application allow it, readings can be taken more frequently, stored locally, and sent in batches. The result can be the same data granularity in the upstream system, but fewer communication cycles, which can have a significant effect on overall consumption.

At the design stage, it is worth separating two questions: how often a value needs to be obtained, and how often it needs to reach the upstream system. The answer is not always the same. Choosing the right frequency is covered in more detail in 15 minute versus daily meter readings explained.

Consumption is not just about the radio module

When estimating consumption, attention often goes straight to the NB-IoT or LoRaWAN modem, but the radio transmission is not the only active component of the device. The converter first needs to obtain data from the meter, and depending on the specific solution, it may communicate with the meter over M-Bus or RS-485, receive wM-Bus telegrams, monitor a pulse input (S0), or use an optical interface. If the device also powers a connected peripheral, that consumption counts towards the power budget.

The difference is created not only by how often the device transmits, but also by how often the meter is read, how long a single reading takes, which interfaces need to be activated during it, whether and for how long it powers an external peripheral, and what happens if the reading fails. The power profile therefore needs to be built for the whole cycle, not just the radio part.

Sleep mode should be assessed at the level of the whole device

For a battery-powered device to run for many years, it typically needs to spend most of that time in a very low-power state. Knowing that the processor supports deep sleep is not enough; what matters is the device's overall idle consumption.

The processor can be asleep while other parts of the electronics remain active, such as the communication interface, the modem, or a powered peripheral. Because a device can spend a large majority of its operating time asleep, even a small difference in continuous idle consumption adds up over a long energy budget.

During integration, it is therefore more useful to establish what actually stays powered between cycles than to ask whether a device supports deep sleep.

For NB-IoT and LoRaWAN, message count is not the only factor

The same number of messages sent does not always mean the same consumption.

For NB-IoT, the full course of network communication needs to be accounted for, not just the payload transmission itself. The resulting consumption is affected by radio link conditions, how long the modem must remain active, any retransmissions, and the configuration of the network's power-saving features.

For battery-powered applications, PSM (Power Saving Mode) and eDRX (extended Discontinuous Reception) matter in particular, and their configuration represents a trade-off between power consumption and the device's reachability for network-initiated communication.

In PSM, the device significantly reduces consumption but is not normally reachable for downlink, while eDRX extends the intervals between checks for incoming communication. A requirement for immediate device availability can therefore conflict with a requirement for the lowest possible consumption, and downlink reachability is part of the power profile design.

For LoRaWAN, consumption is affected, among other things, by transmission time, which depends on the data rate, spreading factor, and payload size. The choice between confirmed and unconfirmed uplinks also matters.

Where the application does not require acknowledgement of every routine telemetry message, using confirmed uplinks by default is not worthwhile, since confirmed communication adds a downlink and can lead to further transmissions if the acknowledgement is not received. For stationary devices with stable radio conditions, ADR (Adaptive Data Rate) can be useful, helping optimise data rate and transmit power.

The aim, then, is not to set a blanket "lowest possible power" or "fastest possible communication", configuration needs to match the specific conditions of the installation and the requirements of the application.

Real installation conditions change the power profile

Consumption measured during development does not necessarily match the device's consumption after installation. Metering equipment commonly sits in basements, shafts, technical rooms, or metal cabinets, where radio conditions can differ substantially from those in laboratory testing.

Worse link conditions can mean longer or repeated communication; LoRaWAN data rate and airtime may change, and NB-IoT networks may rely on retransmissions to maintain reliable communication. Signal quality is therefore not only a question of whether data is delivered; it is also an input to the power design.

The same applies to temperature. Low and high temperatures both affect battery properties and available power. The power calculation should be based on the environment in which the device will actually operate. Battery behaviour, temperature effects, current spikes, and the challenge of estimating remaining capacity are covered in more detail in Battery life in IoT: beyond the datasheet number.

Error states belong in the power budget too

This part of the power budget is easy to overlook. A standard scenario can be very efficient: read, transmit, sleep. Real operation, however, also includes error states: a meter that does not respond, an NB-IoT modem that fails to connect to the network, a LoRaWAN device that does not receive the expected acknowledgement, or data that fails to be sent. Every additional attempt extends the device's active time, so poorly configured retry logic can change the power profile exactly when conditions are already at their worst.

The power budget should therefore account not only for normal operation, but also for how the device behaves when something fails. A well-designed device should have defined:

• how many times an attempt is retried
• how long the timeouts are
• what interval separates further attempts
• when further attempts are deferred
• whether data can be stored and sent later
• when the device returns to power-saving mode

‍

It is not enough to optimise only for the happy path, where everything works the first time. For battery life, it matters just as much how the device behaves during prolonged outages or in degraded conditions.

Battery life comes from the operating scenario, not the datasheet

Only once the individual operating states are known can a realistic power budget be built. For a basic estimate of consumed capacity, each state requires knowing the current draw, the duration, and the frequency of repetition, and the values for each state are then added together:

• sleep: idle current multiplied by time asleep
• reading: current during the reading multiplied by its length multiplied by the number of readings
• processing: consumption of the active electronics multiplied by processing time
• communication: consumption of the communication module multiplied by duration multiplied by the number of transmissions
• peripheral: its consumption multiplied by the powered duration
• error states: consumption of a single attempt multiplied by the expected number of repetitions

‍

The result is not a universal battery life figure but an estimate for a specific configuration and a specific operating scenario. A margin also needs to be built into the calculation, since nominal battery capacity is not fully usable under all conditions, and the resulting battery life is affected, among other things, by temperature, battery ageing, and the nature of the load.

Battery-powered ACRIOS converters use battery packs such as D (19,000 mAh) and D2 (38,000 mAh), depending on the specific device and configuration. These figures serve as reference input for the calculation, not as a guaranteed battery life regardless of configuration.

A figure such as "up to 10 years" should therefore always prompt a follow-up question: under what configuration and operating conditions? In applications where the actual charge drawn needs to be tracked during operation, coulomb counting can be used; its principles and applications are covered in more detail in Coulomb meter: everything you need to know.

Checklist: what to verify before deploying a battery-powered IoT device

Before finalising a project's configuration, it is worth having answers to the following questions:

1. How often does the meter actually need to be read?
2. How often does data need to be sent?
3. Can multiple readings be sent together?
4. What does the device activate or power during a reading?
5. What is the idle consumption of the whole device between readings?
6. Is acknowledgement of every message required?
7. How quickly does the device need to be reachable for downlink?
8. What are the real radio and temperature conditions at the installation site?
9. What does the device do after a failed reading or transmission?
10. What margin does the battery life estimate allow for?

‍

If any of these answers is missing, the expected battery life figure is still based on an incomplete operating scenario.

Battery life is the outcome of configuring the whole system

A single setting does not determine the battery life of an IoT device; it is the result of hundreds or thousands of repeated operating cycles. Saving a few seconds of active time may not seem significant for a single reading, but if the same cycle repeats several times an hour over many years, the difference multiplies. The same applies to idle consumption, unnecessary retransmissions, or poorly configured timeouts.

A more useful question than "how big is the device's battery" is therefore how its power profile looks under the actual operating conditions of a given installation. That question should serve as the basis for both the battery-life calculation and the device configuration before deployment.

Glossary of terms used

• ‍Power profile: an overview of a device's operating states, their consumption, duration, and frequency, used as the basis for estimating long-term consumption.‍
• Deep sleep: a low power operating state in which non-essential parts of the device are switched off or reduced, and the device waits for the next event or a scheduled wake-up.‍
• PSM (Power Saving Mode): a power saving mode in mobile IoT networks in which the device significantly reduces consumption but is not normally reachable for network communication.‍
• eDRX (extended Discontinuous Reception): a mobile network mechanism that extends the intervals at which a device checks for incoming communication.‍
• ADR (Adaptive Data Rate): a LoRaWAN mechanism for optimising data rate and transmit power according to link conditions.‍
• Confirmed uplink: a LoRaWAN uplink for which the device expects acknowledgement of receipt from the network, suitable where the application genuinely requires it rather than as a default for every telemetry message.‍
• Retry/retransmission: repeating a failed reading or communication attempt, the frequency and timing of which can significantly affect overall consumption.‍
• Coulomb counting: a method based on continuously measuring and integrating current, used to track the amount of charge drawn from a battery. For batteries where voltage alone does not reliably indicate remaining capacity, it can serve as a basis for estimating it.‍
• Battery pack D / D2: standard battery capacities used in battery-powered ACRIOS converters, 19,000 mAh and 38,000 mAh respectively.