---
id: "VOLT-HOME-WP-096"
title: "What should a home-energy controller do when Voltcast or an upstream source is unavailable?"
slug: "what-should-a-home-energy-controller-do-when-voltcast-or-an-upstream-source-is-unavailable"
description: "A fail-closed controller pattern based on a declared 7.4 kW load and a deterministic 15-minute exposure calculation."
published: "2026-08-30"
cluster: "Reliable automation and machine-readable energy evidence"
status: "measured"
evidence: "/research-data/home-papers/what-should-a-home-energy-controller-do-when-voltcast-or-an-upstream-source-is-unavailable.json"
figure: "/research-media/home-papers/what-should-a-home-energy-controller-do-when-voltcast-or-an-upstream-source-is-unavailable.webp"
figure_alt: "Chart for What should a home-energy controller do when Voltcast or an upstream source is unavailable?: energy exposed during a 15-minute fail-closed timeout at 7.4 kW, shown as 1 min, 5 min, 15 min, 60 min."
source_ids:
  - "google-article"
  - "google-structured-data"
  - "google-scaled-content"
  - "entsoe-sdac"
  - "volt-architecture"
peer_reviewed: false
---

## Abstract

An unavailable API or upstream market source creates a control problem, not permission to guess. This paper evaluates a deterministic fail-closed timeout scenario for a declared 7.4 kW controllable load. At 15 minutes, the energy associated with continuing that state is 1.85 kWh. The public artifact reports four timeout scenarios, no uncertainty interval, and the assumption “no automatic unsafe retry.” The four values are deterministic exposure calculations rather than sampled outages.

The recommended controller state machine distinguishes fresh validated data, temporarily stale data, and unavailable data. It may hold the last demonstrably safe state for a short, declared grace period when device constraints permit. At the deadline it should stop optional optimization or fall back to a locally stored baseline tariff or comfort schedule. It must not synthesize missing prices, reuse a curve for the wrong delivery window, or retry a potentially accepted device command without reconciliation. This outcome is a deterministic fault-injection calculation. Although the research family also includes production-origin receipts, no production outage, customer network, repository test run, or device response was measured for this paper. The result grounds the magnitude of one declared timeout and provides integration guidance; it does not certify that 15 minutes is universally safe.

## Plain-language answer

Keep working only from a schedule that was already validated, and only for a short period that your appliance policy explicitly permits. If fresh market data do not return by the deadline, stop optional price optimization or switch to a conservative local schedule. Do not let a network retry create a second physical action.

For the paper’s declared example, a 7.4 kW controllable load continuing for 15 minutes corresponds to 1.85 kWh. That is a physical arithmetic scenario, not an observed household loss. Whether the load should continue for any part of those 15 minutes depends on the device. An EV charger can often pause. Heating may need a comfort-preserving thermostat fallback. A battery may need state-of-charge and export constraints. Those safety policies belong to the appliance domain.

The controller should show “data unavailable” rather than silently claiming that an old curve is current. Availability failure, stale data, invalid data, and device-command uncertainty are different states and should produce different recovery actions.

## Research question

The research question is what a home-energy controller should do when Voltcast, its upstream source, or the network path becomes unavailable during a price-driven decision. The supporting scenario asks how much energy remains exposed when a 7.4 kW controllable load holds its state during a declared timeout.

The phrase “fail closed” needs care. It does not always mean de-energize the appliance. It means deny a new data-dependent transition when the controller cannot prove that the inputs and current state are valid. The closed state can be “pause optional charging,” “continue a previously validated command until its natural end,” or “use a fixed comfort schedule,” depending on the hazard analysis.

The criterion is deterministic: after loss of validated data, the controller enters a bounded grace state, then moves to the configured safe fallback. It does not automatically retry an ambiguous external side effect, and it does not turn “unknown” into a price signal. The paper measures no outage probability, financial impact, or device safety outcome.

## Data and provenance

The evidence JSON identifies `VOLT-HOME-WP-096`, schema `volt-home-paper-evidence-v1`, status `measured`, and publication cutoff 2026-08-30T00:00:00Z. It declares a 7.4 kW controllable load and no automatic unsafe retry. The primary metric is “energy exposed during a 15-minute fail-closed timeout at 7.4 kW,” with value 1.85 kWh and sample size four.

The four deterministic timeout scenarios are 1, 5, 15, and 60 minutes. The analysis multiplies the fixed power by elapsed hours. They are analytical fixtures, not four observed outages. The evidence’s shared source contract lists auction publications, grid revisions, ingestion runs, public API schemas, and repository integration fixtures, but the primary value is generated from the declared power-time relationship rather than production receipt timing.

The corpus provenance remains hash-bound: snapshot SHA-256 `7e97489fc8528c8cc8c38830e05b48d949ce1f67b98575dff26f5d7c321e4c67`, analysis-code SHA-256 `57c57de79cdab2b5b6d6c54c485cb5162598c5ba0b0bfe995da40d75e6c52ba9`, protocol SHA-256 `adb36bf6b447af9f96339249b8becaefc20422499cca1977242866347a97bd4b`, paper-registry SHA-256 `7bcb91d7476d0a69fe9fa75a5c7782f8117e0153f82f9112b7e1d307d3943717`, and source-registry SHA-256 `07949550ac443ff673fda5c0209b99f137544f3ffecf6775f109bb9d09663bd6`. The evidence-manifest hashes are `558ec3d3f88eee94a13731fc5218951033f3c16c0e9d6f3b1c6af96746fdd3a7` for the JSON and `2054769e9dd08ce107c3dc04bab0e5f593eeba7d96bd0d718137d2a902c3f34e` for the WebP figure. The extraction transaction was read-only with a 180-second statement timeout.

No production unavailability event, recovery duration, customer appliance, local network, or device firmware response is included. No repository test execution is claimed.

## Method

The deterministic scenario uses energy equals power multiplied by time. The declared load is 7.4 kW. The analysis evaluates the four timeout durations and selects the 15-minute scenario as primary, yielding 1.85 kWh. It plots all four scenario values to show how exposure scales with timeout duration.

The regenerated evidence reports `bootstrap_95_interval: null` and `interval_method: "not reported for this estimand"`. It supplies no uncertainty interval from random outages or households. The primary 1.85 kWh value follows directly from the fixed inputs.

The control design adds a state machine around the calculation. `fresh` means the payload passes identity, completeness, freshness, and schema checks. `grace` means the previously authorized state remains within a bounded hold rule. `fallback` means local device-safe behavior replaces optimization. `uncertain-command` means a side effect may have been accepted but lacks acknowledgement; the controller reconciles before retrying. `recovered` requires a newly validated payload for the correct target window.

Several tradeoffs are explicit. Immediate shutdown minimizes continued optional energy but may violate comfort or device constraints. Indefinite last-value hold preserves continuity but converts stale data into hidden authority. A bounded hold followed by a declared local fallback limits data-driven exposure while respecting appliance policy. It costs implementation effort because the controller must persist state independently of the remote service.

## Results

The primary deterministic result is 1.85 kWh for a 15-minute timeout at 7.4 kW. The figure values are exactly 0.12333333333333334, 0.6166666666666667, 1.85, and 7.4 kWh for 1, 5, 15, and 60 minutes. The evidence reports no interval. The interpretation states that a controller can hold the last safe state briefly, then stop or fall back to a declared tariff schedule.

![Chart for What should a home-energy controller do when Voltcast or an upstream source is unavailable?: energy exposed during a 15-minute fail-closed timeout at 7.4 kW, shown as 1 min, 5 min, 15 min, 60 min.](/research-media/home-papers/what-should-a-home-energy-controller-do-when-voltcast-or-an-upstream-source-is-unavailable.webp)

The result is an energy quantity, not a cost, savings, emissions value, or harm estimate. The word “exposed” means energy controlled under the held state during the timeout. It does not imply that all such energy is wasted or unsafe. A continuing charger may still be following a valid previously authorized interval; the concern is bounded authority when new data cannot be verified.

No evidence determines that 15 minutes is the optimal or safe grace period for every appliance. The scenario makes the chosen timeout legible so operators can evaluate it rather than inheriting an indefinite retry loop.

## Robustness and placebo checks

The arithmetic result can be checked directly from the declared power and duration. A future controller test should then inject failures at distinct boundaries: before data fetch, after partial payload receipt, after validation but before persistence, after action persistence but before device call, and after device acceptance but before acknowledgement. These are recommended deterministic fixtures, not measured repository-test outcomes.

Useful placebos include an optional load already off, a fresh valid payload, and an unavailable endpoint outside any decision window. The controller should not manufacture an emergency action where none is required. Another placebo returns an old payload with a successful HTTP status; freshness validation should reject it even though transport availability appears healthy.

Recovery testing should prove that repeated fetches and callbacks converge on one action state. A restored connection must not replay every command that accumulated during the outage. A device-state readback, where supported, should resolve ambiguous acceptance before retry.

The family result is descriptive and scenario-based. No inferential claim or unadjusted significance test is made. The reported bootstrap bracket is not used to select the timeout.

## Limitations

The 7.4 kW load is a declared assumption. Actual power can vary, and many devices are not continuously controllable at their nameplate rating. The timeout scenarios omit state of charge, temperature, comfort, minimum run times, export limits, network tariffs, and user overrides.

No outage distribution is measured. The sample size of four is an assumption grid, not four independent production observations. No population-uncertainty interval is reported.

The evidence limitation states that repository contract tests and production receipts measure infrastructure behavior, not a customer’s local network or firmware. This paper’s primary result is even narrower: a deterministic physical calculation. It cannot certify a fallback for any specific EV charger, heat pump, battery, or Home Assistant installation.

The recommendation to hold a last safe state is conditional. Some appliance policies may require immediate fallback; others may safely finish an already armed interval. Device manufacturers, electrical constraints, and household requirements take precedence. This paper is not safety certification or trading advice.

## Practical implication

Cache the last complete validated schedule locally with its zone, target window, native intervals, source/revision identity, validation time, and content hash. Also store a baseline schedule that does not depend on the remote service. The runtime should know which appliance actions are optional, reversible, and bounded.

On failure, classify the event before acting. A transport timeout with a still-valid schedule may enter grace. An invalid schema, wrong delivery date, incomplete curve, or conflicting revision should fail immediately into the fallback path. When grace expires, disarm future optional optimization commands and activate the declared baseline. Preserve essential comfort and safety controls independently of market data.

Use durable idempotency records for external calls. If acknowledgement is missing, query device state or require manual reconciliation rather than retrying blindly. Emit observable states—fresh, grace, fallback, and recovered—with timestamps and reason codes. Recovery requires a complete current payload; a successful HTTP response alone is insufficient.

## Reproducibility

Verify the paper identity, evidence path, all five provenance hashes, and both evidence-manifest artifact hashes. Calculate energy for each declared timeout as 7.4 kW multiplied by minutes divided by 60. Confirm that the 15-minute entry is 1.85 kWh, that there are four scenario values, and that the evidence reports no interval for this estimand.

A follow-up production study should publish outage start and end receipts, stale-data decisions, fallback transitions, device acknowledgements, and unresolved commands. A separate fixture manifest should enumerate injected failure points and expected states. The two evidence classes must remain distinct.

Changing the load, timeout, or appliance policy creates a new scenario. It should disclose the new assumptions and must not be presented as a reproduction of this 7.4 kW, 15-minute result.

## Disclosure

Analysis and drafting were model-assisted. This is a public working paper. It is not peer reviewed. The scenario assumptions, code, evidence hashes, and limitations are disclosed. Voltcast publishes the cited architecture source and produced the evidence artifact.

No customer device, production outage, or repository-test pass was measured. Volt has no live traders or live capital; C0R is its only paper strategy, and production weather forecasting is non-trading. This paper is not trading advice, electrical-safety guidance, device certification, or a promise of savings.

## References

1. Google Search Central, [Article structured data](https://developers.google.com/search/docs/appearance/structured-data/article).
2. Google Search Central, [Introduction to structured data markup in Google Search](https://developers.google.com/search/docs/appearance/structured-data/intro-structured-data).
3. Google Search Central, [Spam Policies for Google Web Search — Scaled content abuse](https://developers.google.com/search/docs/essentials/spam-policies).
4. ENTSO-E, [Single Day-ahead Coupling (SDAC)](https://www.entsoe.eu/network_codes/cacm/implementation/sdac/).
5. Voltcast, [Voltcast Architecture](https://github.com/ossedk/voltcast/blob/main/docs/voltcast/ARCHITECTURE.md).