Battery · Coming soon

Know your ESP32 battery life before you ship

Check-ins that ride the wake your device already makes, schedules built around deep sleep, and months of battery simulated in minutes, your new code against your old, before a single device gets it.
Low-power check-ins

One small datagram, not a handshake.

On a battery ESP32, radio time is the cost. A check-in is one CoAP exchange over UDP, encrypted end to end with OSCORE, sent on a wake your device already makes, then straight back to deep sleep.
In development
A few hundred bytes per check-in, with no TLS handshake
Rides a wake where Wi-Fi is already up: otalite never wakes the device
A small native MicroPython module written in Rust, installed with mip

Bytes on the air per check-in

Estimated, once Wi-Fi is connected. To be measured on hardware before launch.
HTTPS
~6 KB
MQTT over TLS
~5 KB
CoAP over DTLS
~2.5 KB
otalite (CoAP + OSCORE)
a few hundred bytes
Battery-aware scheduling

Your schedule. Their battery.

Update windows and deep sleep, working together: devices check in rarely, more often only while a release can install, and install only when the battery can take it.

Check-in intervals per group

Set how often each product or device group checks in, and see when each device will next check in.
In development

Update windows

Devices check in more often only inside a release's window, and fall back to long intervals outside it.
In development

Install conditions

Install only when conditions you set are met, such as battery above a threshold.
In development
Later, smarter update windows (Planned) suggest a window from your fleet's real check-in and battery patterns.
Battery reporting

You choose how often battery is reported

On every check-in, every Nth, or only when it changes by a set amount: even reading the battery costs power.
Planned
Event checks

Update checks on your events

Your code can ask for a check when something happens: a button, a charger, power returning. Installs can wait for power.
Planned
Recommended
Event checks still respect the minimum check-in interval and a daily cap.
Lighter option
A higher daily cap, if you understand the risk: anyone who can press the button could drain the battery, and we offer no protection against that.
Battery-life targets

Know before a single device gets it.

Set how long your devices must last, in months: for example, devices must last 12 months on a 2,000 mAh battery. If a release would miss it, or comes close, you're alerted as soon as its projection is ready.
Planned
12 months
Your target, on 2,000 mAh
11 months
Projected for 1.4.2: 1 month short, held back
If a release would miss your battery target, you're alerted the moment the projection is ready, in the dashboard, Discord, email or your CI, before a single device gets it. Then you fix it, adjust the target, or knowingly force it. A release that comes close gets an early warning.
A release that falls short is held back, with the code responsible for the shortfall. otalite also shows its own share of the budget (check-ins and updates) and suggests a check-in interval and update windows that still meet your target.
Example data. Projections are estimates.
Accelerated battery-life simulation

Run your battery flat, in minutes.

Your current release and your new one each run against a virtual battery until it's empty, fast-forwarding through every sleep, so months or years of device life take minutes. It includes your daily, weekly and monthly patterns, self-discharge and usable capacity. You get the day the battery would run out for each, side by side, and where the energy went: CPU, radio, sleep or sensors.
Planned
By default the simulation replays your fleet's real check-in and signal patterns. You can describe your own, such as "a sensor event every 10 minutes".
Code power analysis

Find what keeps your device awake.

After you upload a package, otalite works out how busy your code is, then turns that into energy per day and a projected battery life, compared with your previous release.
Planned
Loops that never sleep
Polling that is too frequent
Wi-Fi reconnects inside loops
Functions that keep the CPU or radio awake, with file and line
Hot spots · thermo 1.4.2 vs 1.4.1
Example
main.py:48
Loop never sleeps
sensors/upload.py:22
Wi-Fi reconnect inside a loop
drivers/poll.py:14
Polls every 200 ms
Suggestion
Batch uploads every 10 minutes: about +3 months
The numbers come from profiling and simulation; AI only explains them and suggests fixes.
Simulated, not measured: simulators can't measure real power, so every figure here is an estimate until it's calibrated on real boards. The comparison between the two releases is the reliable part.
Before and after each release

What an update costs, and what it changed.

An estimate of the energy each device will spend installing an update, before it ships; then each release compared with the one before, on the same kind of devices.

Update cost estimates

Planned
≈0.3 mAh
per device, per update: about 1–2 hours of battery life at 4–6 mAh a day · Example estimate
The download is sized by the exact update or delta and each device's recent signal and connection times; then the flash write, the signature check and the reboot.
"≈0.3 mAh per device; 40 devices on weak signal ≈3 mAh." It feeds install conditions: a minimum battery level, preferring delta updates, and holding weak-signal devices until they're charging. After the install, the device's counters measure what it really cost, so the next estimate is sharper.

Release impact reports

Planned
+18%
energy per day · Example: thermo 1.4.2 vs 1.4.1
"1.4.2 uses 18% more energy per day than 1.4.1, mostly radio time: reconnects doubled."
Battery
Drain per day, from battery voltage when the board measures it; otherwise estimated from awake time and radio-on time.
CPU
Time awake versus asleep, main-loop duration, free memory and garbage-collection pressure.
Network
Bytes sent and received, radio-on time, and check-ins and reconnects per day.
The device keeps a few small counters and sends them with its existing check-in: a handful of encrypted bytes, so measuring costs next to no battery.
Recommended
Compact counters only.
Lighter option
Detailed per-function profiling. More precise, but it costs the device CPU, memory and battery while it runs: use it on a few test devices, not the whole fleet.
How long will your ESP32 last today?
A free calculator on this site: battery size, wakes per day, Wi-Fi time and deep-sleep current. An estimate, not a measurement.
ESP32 battery life calculator ›
Package change reports

Every package change, and what it costs.

See exactly which packages a release changes on your devices, old → new, and what each change does to battery life: before rollout from the battery simulation, after it from real devices. And when a package you use publishes a new version, get its security and battery report before you decide.
Example · Planned

Packages in 1.4.2

Compared with 1.4.1, the release it replaces, with how many devices run each version as the rollout goes.
urequests 0.9 → 0.10
+6% radio · ≈ −3 weeks
ssd1306 1.0 → 1.1
no measurable change
MicroPython 1.28 → 1.29
−2% CPU · ≈ +1 week
Attribution is an estimate; when several packages change together, effects can't always be separated.
Example card · Planned

umqtt.simple 1.3.4 → 1.4.0 is out

A report for your product as soon as a package you use publishes a new version. Nothing ships without your approval.
Breaking changes
1 · main.py:48: keepalive default 120 → 60 s; pass keepalive=120
Security
1 advisory fixed (CVE-2026-00000, Example) · your code calls the affected connect(); update recommended
In your code
MQTT without TLS · net.py:12; use ssl=True on port 8883
Battery
+11% radio · ≈ −6 weeks
Known issues
2 open reports against 1.4.0 (reconnect loop) · fix merged, not yet released
Recommendation
Wait for 1.4.1, or update with keepalive=120
Accept
Skip this version
Pin
Static checks catch common issues; they don't prove your code is secure.
The upstream report covers advisories fixed or introduced, supply-chain signals worth a look (a new maintainer, new network hosts in the code, an unexplained jump in size), the battery impact of swapping in just that package, and a recommendation: update, update with care, or hold. It also compares the package's API between the two versions (removed or renamed functions, new required parameters, changed defaults) and shows the exact lines of your code to change, with a suggested fix. It lists the issues reported upstream against the new version and, opt-in and aggregated, how that version is behaving on other otalite fleets. It comes with a draft release, or a pull request that bumps the version. You decide per update: accept, skip this version, snooze, pin, or ignore the package; high and critical security advisories can't be silenced.
Recommended
A person reviews every update, and a rollout still needs your passkey.
Lighter option
Auto-start a canary wave when the report is clean. The danger: a compromised upstream release reaches real devices without anyone looking, and we offer no protection against that.
Status

Where each piece stands.

Nothing here is available yet. In development is being built for the first release; Planned is on the plan, not started; Exploring is still being researched.
Delivery

Low-power check-ins

CoAP and OSCORE: a few hundred encrypted bytes per check-in, and no TLS handshake.
In development
Battery-aware scheduling

Check-in intervals per group

Set intervals per product or device group, and see when each device checks in next.
In development
Battery-aware scheduling

Update windows

Devices check in often only inside a release's window, and rarely outside it.
In development
Battery-aware scheduling

Install conditions

Install only when your conditions are met, such as battery above a threshold.
In development
Energy

Set how long your devices must last

Set a battery life in months; a release that would miss it is flagged before any device gets it.
Planned
Testing

Accelerated battery-life simulation

Old and new code run against a virtual battery until it's empty, in minutes.
Planned
Testing

Code power analysis

Finds what keeps the CPU or radio awake, with file and line, and its cost in battery life.
Planned
Energy

Update cost estimates

The energy each device will spend on an update, estimated before rollout and refined after.
Planned
AI-assisted rollouts

Release impact reports

Each release compared with the one before, for battery, CPU and network use.
Planned
Energy

Package change reports

Which packages a release changes, old → new, and what each change does to battery life.
Planned
Energy and security

Upstream update watch

A security and battery report for every new version of a package you use, with a draft release.
Planned
See the whole roadmap ›
Related

Keep exploring.

Rollouts

Rollouts that stop themselves.

Waves that widen only when it's safe, and pause on failures.
Learn more ›
Insights

Your fleet, explained.

Crash reports from devices, and rollouts that report back.
Learn more ›
Security

Signed. Verified. Or not installed.

Devices install only what your key signed, and check it themselves.
Learn more ›
Community

Follow the build.

otalite isn't available yet. Register your interest to hear first, or join the Discord to see what we're building and tell us what your fleet needs.
Register interest
Join the Discord
See the roadmap
© 2026 otalite · Coming soon
FeaturesBatterySecurityRolloutsInsightsWorkflowRoadmapMicroPython OTA optionsBattery life calculatorCyber Resilience ActAboutRegister interestDiscordGitHub