13 Context-Aware Energy Management

13.1 Start With a Device That Notices Nothing Changed

Prove That Waiting Saves More Than Watching

Picture a soil sensor that wakes every minute even though the field changes slowly. A second signal might let it wait, but that extra watcher also consumes energy and can miss an urgent change.

Duty cycle means the share of time a device spends active instead of asleep. Latency means the delay between a real event and the system response. Both must be measured under the same conditions.

Record one fixed schedule, then one context-aware schedule. Force a sudden change, a stale watcher value, and a restart; compare energy, response delay, missed events, and recovery.

This runway does not prove that one rule suits every season or device. The deeper sections explain context sources, decision costs, cache limits, fallbacks, and full energy accounting.

A device that senses on a fixed clock spends energy even when the room, machine, or soil has not changed. Context-aware energy management asks whether another signal already proves it is safe to wait.

The simple idea is to spend energy only when context justifies it. The hard part is proving that the watcher, cache, rule, or fallback does not cost more than it saves.

Phoebe’s Field Notes: Why The Watcher Can Never Draw Zero Current

The mathematical gist. At 290 K, thermal noise density is about -174 dBm/Hz. A 200 kHz wake channel therefore contains about $8.01\times10^{-16}$ W, or -121.0 dBm, before the front end adds its own noise. Widening the channel to 1 MHz raises that floor by 7 dB. The chapter’s 50 microamp watcher at 3.3 V also consumes 165 microwatts, or 3.96 mWh each day, before it triggers anything.

Math Bridge · guided foundationsWhy does a watcher consume energy even when nothing changes?Let Battery Bruno connect thermal-noise bandwidth, standing bias current, and the policy's true energy floor. Learn the maths

13.2 Learning Objectives

By the end of this chapter, you will be able to:

• Explain how context signals change duty cycle, sensing, radio, and computation policies.
• Distinguish cache hits, rule inference, direct sensing, and policy actuation.
• Decide when an ACE-style cache-infer-sense strategy is appropriate for an IoT deployment.
• Set guardrails for context confidence, cache freshness, latency, safety, and battery reserve.
• Build a compact evidence record that proves the policy saved energy without hiding missed events.

13.3 Where This Chapter Fits

This page is the overview for the context-aware energy sequence. Use it to understand the control loop and review discipline, then move into the deeper chapters for calculations, ACE internals, offloading, and assessment.

13.8 The Core Loop

A context-aware policy is a control loop. It observes context, chooses the cheapest reliable way to answer a context request, applies an energy policy, and records whether the policy was correct.

The loop has five responsibilities:

1. Name the requested context: occupancy, motion, location zone, light level, network reachability, battery reserve, or activity state.
2. Reuse recent evidence: return a cached value only while its time-to-live still matches the volatility of that attribute.
3. Infer with guardrails: use a learned rule only when confidence is high enough for the consequence of being wrong.
4. Sense when required: fall back to direct sensing when cache freshness or inference confidence is weak.
5. Validate the policy: compare saved energy with missed events, retries, latency, and user-visible failures.

13.9 Context Signals and Energy Levers

Context-aware management is not one technique. It is a way to choose among several energy levers.

13.10 Cache, Infer, Sense

The most useful mental model is cache -> infer -> sense:

def choose_energy_policy(request, cache, rules, sensors, state):
    cached = cache.get(request.attribute)
    if cached and cached.age_s <= request.max_age_s:
        return PolicyDecision("use_cache", cached.value, evidence=cached)

    rule = rules.best_rule_for(request.attribute, state.context)
    if rule and rule.confidence >= request.min_confidence:
        inferred = rule.apply(state.context)
        return PolicyDecision("infer_context", inferred, evidence=rule)

    reading = sensors.read(request.attribute)
    cache.store(request.attribute, reading.value, ttl_s=request.max_age_s)
    return PolicyDecision("direct_sense", reading.value, evidence=reading)

The thresholds in this example are not universal. A temperature trend display can tolerate looser freshness than a lock, medical alarm, or industrial safety interlock.

13.11 Policy Gates

Do not promote a context-aware policy just because it reduces the number of samples. Promote it only when it passes the gates that match the deployment.

Why place Candidate evidence beside Hard priority here? The figure at Figure 13.1 answers that question and prepares the evidence needed for policy gates.

The diagram in Figure 13.1 opens with Candidate evidence, which states how the claim is checked. Its Hard priority checkpoint adds a distinct review condition, before EVIDENCE, NOT TRUTH states how the claim is checked. That sequence gives the visual its meaning: A candidate occupancy-gated policy saving 3,236 wakes per week versus a 10,080 baseline (67.9% fewer) must pass four gates before promotion. Gate 1 Freshness asks whether each context attribute is still valid, with a TTL per attribute since motion, location, and reachability expire faster than room temperature or scheduled occupancy. Gate 2 Confidence asks whether the rule is reliable enough for the consequence, since safety, security, billing, and access-control need higher confidence than a convenience feature. Gate 3 Energy asks whether savings beat the true cost measured across compute, wake-up, radio, retries, and re-sensing, not just fewer samples. Gate 4 Service asks whether event miss rate, latency, and user-visible failures stay acceptable. Only if all four gates pass is the policy promoted; otherwise it returns to Cache, Infer, Sense, and Act for rework. The same boundary now governs policy gates.

13.16 Worked Example: Office Motion Node

Scenario: A battery-powered office motion node currently wakes every 60 seconds. The office is normally occupied from 08:00 to 18:00 on weekdays and idle overnight and on weekends. The team wants to extend life without hiding occupancy events.

Baseline

Fixed policy:
- Wake every 60 seconds all week
- 168 hours/week * 60 wakes/hour = 10,080 wakes/week

Context-aware proposal

Occupied window:
- 10 hours/day * 5 weekdays * 60 wakes/hour = 3,000 wakes/week

Idle window:
- 118 hours/week * 2 wakes/hour = 236 wakes/week

Total proposed wakes:
- 3,236 wakes/week
- 67.9% fewer scheduled wakes than baseline

This is not yet proof that the policy is good. The review must also check:

• Were after-hours occupancy events missed?
• Did the first event after a long sleep arrive within acceptable latency?
• Was the occupancy schedule still valid during holidays, cleaning, and late work?
• Did the device enter a safer fallback when confidence dropped?
• Did measured current match the calculated wake reduction?

13.17 Evidence Record

Every promoted context-aware policy needs an evidence record. Keep the record short enough to audit and specific enough to reproduce.

A design can appear sound at Baseline and still fail at Proposed. The illustration in Figure 13.2 frames that exact concern for the chapter’s discussion of evidence record.

Trace the labelled evidence in Figure 13.2 beginning at Baseline, the element that establishes the starting condition. Pause at Proposed because it adds a distinct review condition; resolve the path at Schedule, idle interval, fallback, which sets the timing constraint. What the visual establishes is that no-panel context-aware energy evidence record showing baseline, proposed policy, gates, measured current, service result, and final decision. This is the bounded result needed for evidence record.

13.18 Common Pitfalls

13.25 Related Chapters

13.30 Knowledge Check

13.31 Knowledge Check: Cache or Sense?

13.32 Knowledge Check: Energy Claim Review

13.33 Matching Quiz: Strategy to Review Gate

13.34 Ordering Quiz: Cache-Infer-Sense Review

13.35 Label the Diagram: Context-Aware Energy Loop

13.36 What’s Next

13.41 Energy Follows Context, Not The Clock

A fixed-schedule sensor spends the same energy whether or not anything is happening. Context-aware energy management ties the duty cycle to a context signal - occupancy, motion, time of day, activity level, or event rate - so the node works hard only when the context justifies it and rests otherwise.

The number that decides the battery outcome is not the fastest reporting rate or the slowest one. It is the time-weighted blend of the average current in each context. If the device spends most of the day in a cheap, low-rate context, the blend sits near that cheap number. If the expensive context dominates the day, context-awareness saves very little.

For example, a meeting-room node might use a 30-second report cycle while people are present and a 10-minute cycle while the room is empty. If the active policy averages 300 uA, the empty-room policy averages 30 uA, and the room is active for 2 hours per day, the daily average is (2/24 x 300) + (22/24 x 30) = 52.5 uA. Running the 30-second policy all day would be 300 uA, so the context signal has real value. If the same room is active for 18 hours per day, the blend becomes (18/24 x 300) + (6/24 x 30) = 232.5 uA; the policy still helps, but the gain is much smaller because the node rarely enters the cheap context.

Before setting an adaptive duty cycle, inspect Figure 13.3. The loop shows that a context policy is only as sound as the cache, inference, sensing, and validation evidence feeding it.

Read Figure 13.3 from the context request to the cache decision. On a miss, follow inference and its confidence gate before the direct-sensing fallback; then trace the selected energy policy into validation. That return path is the control that reveals whether reduced sensing still supports the required service outcome.

13.42 The Context Loop

13.43 Beginner Vocabulary

• Context signal is the cheap input (like motion) used to decide how hard to work.
• Policy is the rule that maps a context to a reporting rate and sleep depth.
• Per-context average current is the average current the node draws while a single context holds.
• Blended average current is the time-weighted combination across all contexts over a day.
• Occupancy fraction is the share of the day spent in the busy context.

13.44 Overview Knowledge Check

13.45 Build A Context-Weighted Current Ledger

To size a context-aware node, compute an average current for each context, then blend them by time fraction. The per-context average current uses the same state math as any duty-cycled device: Iavg = (Iactive x tactive + Isleep x (Tcycle - tactive)) / Tcycle. The blend then applies Iblend = sum(f_context x Iavg_context), where the fractions sum to one.

13.46 Worked Example: Office Occupancy Node

Consider a battery node in an office. When motion marks the room occupied it reports every 30 s; when vacant it reports every 10 min (600 s). Each report is a 250 ms radio-and-sense burst at 40 mA; between reports the node deep-sleeps at 12 uA. Over a working day the room is occupied about 9 hours, so the occupancy fraction is 9/24 = 0.375 and the vacant fraction is 0.625.

• Occupied context: active charge per cycle = 40 mA x 0.25 s = 10 mA-s; sleep charge = 0.012 mA x 29.75 s = 0.357 mA-s; over 30 s that is Iavg = 10.357 / 30 = 0.345 mA (345 uA).
• Vacant context: active charge = 10 mA-s (same burst); sleep charge = 0.012 mA x 599.75 s = 7.197 mA-s; over 600 s that is Iavg = 17.197 / 600 = 0.0287 mA (28.7 uA).
• Blended day: 0.375 x 345 + 0.625 x 28.7 = 129.4 + 17.9 = 147 uA.

A naive fixed 30-second schedule would draw 345 uA all day. On a 2200 mAh usable pack the fixed schedule lasts 2200/0.345 = 6376 h (about 0.73 year), while the context-aware node lasts 2200/0.147 = 14966 h (about 1.7 years) - a 2.3x improvement - while still reporting every 30 seconds when the room is actually in use.

13.47 Context Current Ledger

13.48 Practitioner Knowledge Check

13.49 You Pay For The Watcher

Context-aware designs assume the context signal is free. It is not. The sensor that detects the context - a motion detector, an accelerometer in wake-on-motion mode, a microphone front-end, or a low-power radio listening for a trigger - usually stays powered in every context. Its standing current is added to each per-context average and can dominate the cheap context that the whole scheme depends on.

A continuously powered PIR occupancy sensor with its signal-conditioning stage draws a quiescent current that, depending on the part, ranges from a few microamps to a few hundred microamps. Suppose the watcher adds 50 uA. Every context inherits it: the occupied average rises from 345 to 395 uA, but the vacant average rises from 28.7 to 78.7 uA - it more than doubles. The blended day becomes 0.375 x 395 + 0.625 x 78.7 = 148 + 49 = 197 uA, wiping out a third of the earlier saving. The watcher hurts most exactly where the design was trying to be cheapest.

The decision rule is therefore: include the watcher before comparing policies. If the watcher were 150 uA instead of 50 uA, the occupied context would become 495 uA and the vacant context would become 178.7 uA. With the same 37.5% occupied fraction, the blend is 0.375 x 495 + 0.625 x 178.7 = 297 uA, close to the 345 uA fixed schedule. At that point the extra sensor, firmware complexity, and missed-event risk may not justify the policy. False positives matter too: if a noisy motion detector keeps the node in the occupied policy after cleaning crews, vibration, or HVAC movement, the measured occupancy fraction rises and the expected saving disappears.

13.50 Two Failure Modes To Watch

13.51 Under-the-Hood Knowledge Check

13.52 Summary

This chapter explains how context-aware energy management adapts sensing, computation, and communication to user, device, environment, and network context. The goal is to reduce wasted work without breaking freshness, reliability, or user expectations.

13.53 Key Takeaway

Context saves energy only when it changes a real decision. Track context freshness, sensing cost, confidence, fallback behavior, and measured current before claiming an adaptive policy improves battery life.