37 Device Power: Sources and Boundaries

37.1 Start With the Decision

the primary power source and any backup source. what is inside the measured device boundary.

37.2 Route Overview

This is part 2 of 2. Review Device Power: Energy Budgets for the preceding evidence.

37.3 Learning Objectives

• Measure power source and boundary from current, time, and transition evidence.
• Validate worked review: interactive device with a concrete scenario and pass criteria.

37.4 Chapter Roadmap

• Power Source And Boundary
• Measured Power States
• Duty Cycle Review
• Connectivity Energy
• Battery, Charging, And Service
• Power And User Experience
• Update-Energy Gate
• Power Readiness Record
• Worked Review: Battery Sensor Endpoint
• Worked Review: Interactive Device
• Common Findings
• Review Checklist
• Knowledge Check
• Matching Quiz
• Ordering Quiz
• Summary
• Key Takeaway
• Concept Relationships
• What’s Next

37.5 Power Source And Boundary

Start with the power boundary. A device may look battery powered but depend on a gateway, phone, charger, solar panel, vehicle bus, or maintenance visit.

Review:

the primary power source and any backup source. what is inside the measured device boundary. whether cables, chargers, gateways, batteries, or replaceable packs are part of the product. whether a user, installer, technician, or operator can reach the power source. what state survives battery removal, brownout, reset, or charger loss. what must be shown to users or operators before the device becomes unreliable.

If the power boundary is unclear, battery-life claims and service claims will also be unclear.

Before deciding how Solar + Battery shapes power source and boundary, inspect Figure 37.1 beside YES. Together, Solar + Battery and YES frame the power source and boundary claim: iot power source decision tree for choosing ac/dc adapter, rechargeable or primary battery, solar plus battery, or energy harvesting.

Read Solar + Battery alongside YES in Figure 37.1; their named relationship makes iot power source decision tree for choosing ac/dc adapter, rechargeable or primary battery, solar plus battery, or energy harvesting concrete. For power source and boundary, Solar + Battery supplies visible evidence; YES constrains the decision. In Figure 37.1, retain Solar + Battery beside YES so power source and boundary remains explicit.

Energy harvesting is not only solar. A kinetic switch converts the mechanical energy of a button press into the small burst of charge a radio needs to send one packet, which is why some wireless light switches have no battery to replace at all: pressing the switch is what powers the transmission. The tradeoff is the mirror image of a battery device’s low-power sleep budget — instead of budgeting average current against a stored charge, the design has to budget a single generated pulse against the energy one radio transmission costs, with no reserve for retries. Reviewing a kinetic-harvested device should confirm what happens when a press is too light or too fast to generate a full charge, whether the device gives feedback when a command silently failed to send, and whether the product still needs a battery-backed receiver on the other end of the link.

37.6 Measured Power States

A power budget should be based on measured states, not only datasheet values.

Common states to measure:

Deep sleep: timer, interrupt, retention memory, leak paths, and powered peripherals. Idle connected: radio association, keepalive, receive windows, status lights, and background tasks. Sensing: sensor warm-up, sampling, filtering, calibration, and stabilization time. Compute: processing, local decisions, encryption, compression, and inference. Transmit and receive: connection setup, payload send, acknowledgement, retry, and disconnect. Actuation: motors, relays, locks, valves, haptics, lights, and safety interlocks. Display and feedback: screen, LEDs, audio, vibration, and user-facing status. Update: download, verify, write, reboot, rollback, and post-update health check.

Record the measurement setup. The same board can draw different current depending on firmware build, pull-ups, regulator choice, sensor mode, antenna placement, debug headers, and sleep configuration.

Before deciding how TIME shapes measured power states, inspect Figure 37.2 beside 120 mA. Together, TIME and 120 mA frame the measured power states claim: annotated iot power profile: current consumption over time across deep sleep (about 10 microamps), wake-up, sensor read (about 5 ma), processing (about 15 ma), and radio transmission (about 120 ma).

Trace Figure 37.2 from TIME toward 120 mA; that hand-off expresses annotated iot power profile: current consumption over time across deep sleep (about 10 microamps), wake-up, sensor read (about 5 ma), processing (about 15 ma), and radio transmission (about 120 ma). For measured power states, TIME supplies visible evidence; 120 mA constrains the decision. In Figure 37.2, retain TIME beside 120 mA so measured power states remains explicit.

37.7 Duty Cycle Review

Duty cycle is the schedule of how long the device spends in each state.

Review:

wake source: timer, event, user input, interrupt, gateway command, or schedule. active work: measure, compute, store, transmit, listen, display, or actuate. sleep or idle duration between active periods. retry rules after failure. heartbeat or last-seen reporting. behavior when readings are unchanged. behavior when readings are urgent.

The average current is a time-weighted result. A short high-power state may matter less than a long idle state, while a small sleep leak may dominate a device that sleeps almost all the time.

Use a simple evidence statement:

measured current for each state. duration of each state. expected frequency. deployment derating. service interval target. change condition.

Before deciding how Low shapes duty cycle review, inspect Figure 37.3 beside Duty Cycling Concept. Together, Low and Duty Cycling Concept frame the duty cycle review claim: duty cycling concept showing active and sleep intervals, active time, sleep time, cycle time, and duty-cycle formula.

Read Low alongside Duty Cycling Concept in Figure 37.3; their named relationship makes duty cycling concept showing active and sleep intervals, active time, sleep time, cycle time, and duty-cycle formula concrete. For duty cycle review, Low supplies visible evidence; Duty Cycling Concept constrains the decision. In Figure 37.3, retain Low beside Duty Cycling Concept so duty cycle review remains explicit.

37.8 Connectivity Energy

Radio power cannot be reviewed from protocol labels alone.

Review:

• whether the device must scan, join, associate, authenticate, or reconnect
• how long it listens before or after sending
• how retries and acknowledgements work
• whether the gateway buffers or wakes the endpoint
• payload size and send frequency
• link behavior after installation, not only on the bench
• fallback behavior when the link is weak

Do not accept broad claims such as “low-power protocol” or “Wi-Fi is too power hungry” without the actual workload, installed signal path, and measured state evidence. The same radio can be reasonable or unreasonable depending on connection schedule, payload, retry policy, and power source.

37.9 Battery, Charging, And Service

Battery and charging decisions are also UX and maintenance decisions.

Review:

capacity, usable energy, voltage range, cutoff behavior, and aging assumption. temperature effect in the intended environment. self-discharge or standby drain over the expected storage and deployment period. charger availability, charging time, connector access, and indicator behavior. replacement path, tool requirements, sealing, labels, and safe disposal. service interval and what happens when service is missed. how low-power states are communicated before failure.

Power management should prevent surprise failure. A device that dies silently creates more support burden than a device that warns early, preserves core function, and records why it degraded.

Before deciding how aging shapes battery, charging, and service, inspect Figure 37.4 beside Reserve. Together, aging and Reserve frame the battery, charging, and service claim: usable energy budget from average current through raw need, derating, reserve margin, and selected source.

Read aging alongside Reserve in Figure 37.4; their named relationship makes usable energy budget from average current through raw need, derating, reserve margin, and selected source concrete. For battery, charging, and service, aging and Reserve make the next battery, charging, and service decision depend on visible evidence. In Figure 37.4, preserve aging as evidence for battery, charging, and service; omitting Reserve would hide the battery, charging, and service boundary stated explicitly.

37.10 Power And User Experience

Power behavior is part of the product experience.

Review:

whether users can understand charge, battery, or service state. whether low-power behavior degrades gracefully. which function remains available when power is limited. whether notifications are timely and actionable. whether frequent charging or replacement conflicts with the deployment context. whether power-saving settings change data quality, safety, or reliability. whether the device recovers cleanly after charging, replacement, or brownout.

The review should distinguish hidden power savings from user-visible tradeoffs. Reducing sample frequency, disabling live status, delaying uploads, or limiting actuation can be valid, but those changes must be visible in the power record.

37.11 Update-Energy Gate

OTA and configuration changes require extra power evidence.

Before an update, review:

current battery, charging, or external power state. expected energy for download, verify, write, reboot, and rollback. storage available for package and fallback state. whether the device can defer updates during low-power or critical operation. whether a failed update leaves the previous firmware usable. post-update health evidence.

An update path that works on a charger may not be acceptable for a sealed field device. The update gate should make the difference explicit.

37.12 Power Readiness Record

Before deciding how 8. Decision Record shapes power readiness record, inspect Figure 37.5 beside 2. Measured States. Together, 8. Decision Record and 2. Measured States frame the power readiness record claim: connected device power management readiness record.

In the diagram, check 8. Decision Record and 2. Measured States separately in Figure 37.5; together they make connected device power management readiness record auditable. For power readiness record, 8. Decision Record supplies visible evidence; 2. Measured States constrains the decision. In Figure 37.5, retain 8. Decision Record beside 2. Measured States so power readiness record remains explicit.

Power source: battery, mains, charging, harvesting, backup, or mixed source. Measured states: current and duration for sleep, idle, sensing, compute, transmit, receive, display, actuation, and update. Duty cycle: wake sources, frequency, duration, retry rules, heartbeat, and exception behavior. Connectivity energy: join, listen, send, acknowledge, retry, gateway, and installed signal evidence. Battery and service: usable capacity, temperature, aging, self-discharge, charge or replacement, and access. Low-power UX: warning, degraded function, user control, support state, and recovery. Update gate: energy, storage, compatibility, rollback, deferral, and post-update health. Decision and change condition: accepted tradeoff, owner, known limit, open issue, and condition requiring another review.

The record should remain short enough to update when firmware, schedule, radio, enclosure, or deployment changes.

37.13 Worked Review: Battery Sensor Endpoint

A battery endpoint measures a slowly changing condition and reports through a gateway.

Power evidence to request

• Measured sleep current with the final firmware and peripheral configuration.
• Measured wake, sensor, compute, transmit, receive, and return-to-sleep durations.
• Reporting schedule, heartbeat rule, and retry behavior.
• Gateway dependence and installed link evidence.
• Battery usable-capacity assumption in the intended temperature range.
• Low-battery notification and service path.
• Update deferral rule when battery is low.
• Change condition after sensor, radio, battery, firmware, enclosure, or gateway changes.

Likely review action

Hold the decision if the record says “multi-year battery life” but shows only a nominal battery capacity and a datasheet sleep value. The design needs measured state evidence and a service assumption.

Change condition

Rerun the review when wake frequency, radio retry policy, gateway distance, sensor mode, firmware build, battery chemistry, enclosure temperature, service interval, or update policy changes.

37.14 Worked Review: Interactive Device

An interactive connected device has a display, local controls, and an actuator.

Power evidence to request

• Idle connected behavior and display or indicator policy.
• User interaction frequency and time spent in high-power states.
• Actuator load, safe-state behavior, and brownout recovery.
• Charging or replacement workflow that users can complete.
• Low-power behavior that preserves the most important function.
• Logs that distinguish low power from network failure or mechanical failure.
• Update gate that avoids disrupting critical use.

Likely review action

Ask for a user-facing power record if the device depends on frequent charging, warning banners, reduced features, or manual recovery. Those are UX decisions, not only engineering details.

Change condition

Rerun the review when display behavior, actuator load, notification policy, charging hardware, user workflow, firmware update policy, or low-power threshold changes.

37.15 Common Findings

Battery life is claimed from nominal capacity instead of measured state evidence. The power boundary ignores a gateway, charger, battery pack, cable, or maintenance dependency. Sleep current was not measured with the final firmware and peripherals. Connectivity energy ignores join time, listening, acknowledgements, retries, or weak-signal behavior. The power budget excludes displays, indicators, actuators, sensors, regulators, or debug hardware. Low-battery behavior is not visible to users or support staff. OTA updates can start without enough energy or a rollback path. Service interval depends on access, tools, or user behavior that is not recorded. Temperature, storage, aging, or self-discharge assumptions are missing. The record lacks an owner, known limit, open issue, or change condition.

37.16 Review Checklist

Before accepting a connected-device power decision, confirm that the record includes:

power source, backup source, power boundary, and service access. measured current and duration for all relevant power states. duty cycle, wake source, heartbeat, retry, and exception behavior. radio or wired connectivity energy in the installed context. battery, charging, temperature, aging, storage, and self-discharge assumptions. display, indicator, actuator, sensor, regulator, and peripheral loads. low-power user experience, degraded function, support state, and recovery. update-energy gate, deferral rule, rollback, and post-update health check. accepted tradeoff, owner, known limit, open issue, and change condition.

37.17 Knowledge Check

37.18 Matching Quiz

37.19 Ordering Quiz

37.20 Summary

Connected-device power management is an evidence problem. The review ties measured power states, duty cycle, connectivity energy, battery or charging assumptions, service access, low-power UX, and update gates to the claimed service interval.

The strongest power records avoid generic claims. They show what was measured, what was assumed, what users or technicians must do, what happens at low power, who owns the tradeoff, and what change requires another review.

37.21 Key Takeaway

Power management is a UX constraint: battery life, charging, sleep behavior, and low-power feedback shape whether users trust the device.

37.22 Concept Relationships

Connected Device Fundamentals defines the device role and boundary that power evidence must match. Device Form Factors constrains battery volume, charging access, heat, sealing, and serviceability. Device Lifecycle Management connects power evidence to updates, maintenance, transfer, and retirement. Energy Aware Considerations expands power review into system-level energy design.

37.23 What’s Next

Continue to Connecting Together to review how connected devices join networks, gateways, and ecosystems without hiding power, setup, or maintenance tradeoffs.

37.24 Continue Your Route

This final part closes the route from Power Source And Boundary through What’s Next. Return to Device Power: Energy Budgets or continue from the ux-design module index.