Predictika · home energy assistant

A home energy assistant's settings change, checked before it reaches the battery

An AI home energy assistant proposes one settings change at a customer's home battery system, such as a backup reserve, an operating mode, an EV charger current, a grid-services event or a firmware update, and states its own figures. Before anything is applied, the assistant sends the change to Predictika, which checks it against a declarative model of the home energy policy and the home's own data, recomputes the assistant's figures, and returns a verdict (allow, needs the owner, or block) with every reason at once.

Scope: Settings changes at four fictional homes: reserve, export limit, operating mode, EV charger current, grid-services events, firmware and grid profile. See everything this validator covers

This validator models one assistant-proposed change against the home energy policy, not just the scenarios shown below.

  • Reserve and storm rules — the backup reserve must not fall below the home's minimum (higher for a medical-baseline home) and must not be lowered while a storm alert is active.
  • Modes, limits and circuits — export priority needs a battery, a time-of-use plan and no storm alert; the export limit stays within the utility approval; the EV charger stays within 80 percent of the circuit; the grid profile is installer-only.
  • Firmware and grid events — firmware must not be beta, must support the home's hardware generation and is not scheduled in a storm alert; a grid-services event needs consent and enough battery energy above the reserve.
  • Who and how often — at most four settings changes in 24 hours; owner-only changes from a household member need the owner's confirmation; and the backup time and event energy the assistant states are checked against what the validator computes.

Any change that touches these rules is in scope — not only the scenarios pictured here. Not covered: more than one change per request, other device settings, and real homes or devices; the company, homes, utility approvals and devices are fictional. The validator returns a verdict and findings, not a price or a line-item table.

The home energy assistantReads the home's current settings, proposes one change, states the figures it expects, and says it is ready to apply.
Predictika validatorChecks every rule at once and returns the verdict, each finding, and the computed figures.

6 scenarios in 2 groups · each group runs from the agent’s first attempt to the outcome · click one to switch

What the agent proposes

The home energy assistant says

Illustrative agent statement. The validator receives the structured request below.

Proposing agent: home energy assistant (scripted)

Before sending, the agent must call Recorded run

Predictika validator


      
Waiting for the call.

Where rules-based automation gets it wrong

Click to expand

Our assessment of what typical rules-based home-energy automation (schedules, thresholds and per-device settings in a vendor app or a general automation tool) does with the same cases. It is a judgment about effort and reliability, not a claim that nothing can be built.

What the validator caughtTypical rules-based automationPredictika
One firmware choice that breaks several rulesOnly with care
Beta status, hardware generation and the storm alert are three separate checks on different tables, so each needs its own rule, and picking a stable release fixes two of them while the third remains.
The firmware and the home are fields of the request; beta status, hardware support and storm timing are checked together and each reports its own finding.
A stated figure that changes when the setting changesOnly with workarounds
Backup time depends on the battery size, the critical load and the reserve being requested, so raising the reserve makes the assistant's earlier figure stale; automation usually accepts the figure the assistant sent.
The backup time is recomputed from the requested reserve on every call and compared with the stated figure, so a corrected reserve with an old figure is held.
Storm rules that depend on directionOnly with care
A storm flag can block a setting, but raising the reserve is fine and lowering it is not, and mode and firmware rules differ.
Each action is checked against the storm state and, for the reserve, the direction of the change.
A floor that differs by homeOnly with care
A medical-baseline home needs a higher minimum reserve than another home, so the floor is per-home data that every reserve rule must read.
The home's minimum is data in the model; the reserve is compared with it on every call.
Every problem returned in one answerOnly with workarounds
Rules tend to stop at the first failing check, so reasons surface one resubmission at a time.
All findings come back together, whatever order the choices arrived in.

What this validator catches: findings from its test cases

Click to expand

Every rule is checked on every call, in any order the choices arrive; one problem never hides another. Blocking findings stop the change; approval findings need a person to sign off; everything else is computed.

1Backup reserve floor: the request sets a 20.0 percent reserve; the minimum for this home is 60.0 percent.
2Reserve lowered during a storm alert: the reserve would drop from 60.0 to 20.0 percent while a storm alert is active.
3Stated backup time does not match: the agent stated 12.5 hours of backup; the validator computes 2.5 hours.
4Not enough battery energy above the reserve: the event needs 15.0 kWh; the battery has 5.0 kWh above the 30.0 percent reserve.
5Stated event energy does not match: the agent stated 6.0 kWh for the event; the validator computes 15.0 kWh.
6Owner confirmation needed: this change can be made only by the account owner; the request came from a household member.
7Grid profile is installer-only: grid-protection and interconnection settings cannot be changed by the assistant.
8Firmware does not support this hardware: Firmware 9.0 needs hardware generation 3 or newer; this home has generation 1.
9EV charger current above the circuit limit: 48.0 A requested; at most 80.0 percent of the 50 A circuit is allowed.
10No battery at this home: this action needs a battery and Chen residence has none.
11Export priority needs a time-of-use plan: this home is on a Flat rate plan, so exporting battery energy earns nothing extra.
12Export limit above the utility approval: the request sets 6.5 kW; the utility-approved export limit for this home is 5.0 kW.
13Too many settings changes: 4 changes are already recorded in the last 24 hours; this would be one more, and the limit is 4.
14No grid-services consent: Bhatt residence has not agreed to join grid-services events.
15Beta firmware: Firmware 9.1 beta is a beta release and is not offered to homes.
16Firmware update during a storm alert: updates are not scheduled while a storm alert is active.
17Export priority during a storm alert: this mode sends battery energy to the grid while a storm alert is active.
18Backup reserve floor: the request sets a 15.0 percent reserve; the minimum for this home is 20.0 percent.

Scenarios and results

Click to expand

The recorded result of the validator for each scenario on this page: the request the AI agent sent, the verdict, and every finding, in the order they appear above.

1. Firmware update at the Dalton home: A household member asks for firmware 9.1 beta during a storm alert

The agent's request. I am the home energy assistant. At the Dalton residence, a household member asked me to install firmware 9.1 beta. A storm alert is active. 4 settings changes are already recorded in the last 24 hours. I state 6 hours of backup. It is ready to apply.

Verdict: Blocked.

  • Beta firmware. Beta firmware: Firmware 9.1 beta is a beta release and is not offered to homes.
  • Firmware does not support the hardware. Firmware does not support this hardware: Firmware 9.1 beta needs hardware generation 2 or newer; this home has generation 1.
  • Firmware update during a storm alert. Firmware update during a storm alert: updates are not scheduled while a storm alert is active.
  • Too many settings changes in 24 hours. Too many settings changes: 4 changes are already recorded in the last 24 hours; this would be one more, and the limit is 4.
  • Stated backup time does not match. Stated backup time does not match: the agent stated 6.0 hours of backup; the validator computes 2.0 hours.
  • Owner confirmation needed. Owner confirmation needed: this change can be made only by the account owner; the request came from a household member.

2. Firmware update at the Dalton home: The owner asks for stable firmware 8.2 and the assistant restates its figure

The agent's request. I am the home energy assistant. At the Dalton residence, the owner asked me to install firmware 8.2. A storm alert is active. 4 settings changes are already recorded in the last 24 hours. I state 2 hours of backup. It is ready to apply.

Verdict: Blocked.

  • Firmware update during a storm alert. Firmware update during a storm alert: updates are not scheduled while a storm alert is active.
  • Too many settings changes in 24 hours. Too many settings changes: 4 changes are already recorded in the last 24 hours; this would be one more, and the limit is 4.

3. Firmware update at the Dalton home: The assistant resubmits after fixing the errors once the storm alert has ended

The agent's request. I am the home energy assistant. At the Dalton residence, the owner asked me to install firmware 8.2. A storm alert is not active. 3 settings changes are already recorded in the last 24 hours. I state 2 hours of backup. It is ready to apply.

Verdict: Allowed.

  • Computed figures. Reserve in force 20.0 percent; backup time 2.0 hours; event energy needed 0.0 kWh; battery energy above the reserve 0.0 kWh.

4. Reserve cut at the Bhatt home: The assistant cuts the reserve to 20 percent at a medical-baseline home

The agent's request. I am the home energy assistant. At the Bhatt residence, the owner asked me to set the backup reserve to 20 percent. A storm alert is active. 4 settings changes are already recorded in the last 24 hours. I state 12.5 hours of backup. It is ready to apply.

Verdict: Blocked.

  • Reserve below the home minimum. Backup reserve floor: the request sets a 20.0 percent reserve; the minimum for this home is 60.0 percent.
  • Reserve lowered during a storm alert. Reserve lowered during a storm alert: the reserve would drop from 60.0 to 20.0 percent while a storm alert is active.
  • Too many settings changes in 24 hours. Too many settings changes: 4 changes are already recorded in the last 24 hours; this would be one more, and the limit is 4.
  • Stated backup time does not match. Stated backup time does not match: the agent stated 12.5 hours of backup; the validator computes 2.5 hours.

5. Reserve cut at the Bhatt home: The assistant raises the reserve to 80 percent but keeps the old backup time

The agent's request. I am the home energy assistant. At the Bhatt residence, the owner asked me to set the backup reserve to 80 percent. A storm alert is active. 4 settings changes are already recorded in the last 24 hours. I state 12.5 hours of backup. It is ready to apply.

Verdict: Blocked.

  • Too many settings changes in 24 hours. Too many settings changes: 4 changes are already recorded in the last 24 hours; this would be one more, and the limit is 4.
  • Stated backup time does not match. Stated backup time does not match: the agent stated 12.5 hours of backup; the validator computes 10.0 hours.

6. Reserve cut at the Bhatt home: The assistant resubmits after fixing the errors

The agent's request. I am the home energy assistant. At the Bhatt residence, the owner asked me to set the backup reserve to 80 percent. A storm alert is active. 3 settings changes are already recorded in the last 24 hours. I state 10 hours of backup. It is ready to apply.

Verdict: Allowed.

  • Computed figures. Reserve in force 80.0 percent; backup time 10.0 hours; event energy needed 0.0 kWh; battery energy above the reserve 0.0 kWh.

Narration transcript

Click to expand

The text of the narrated walkthrough, step by step.

  1. Welcome to a demo of Predictika's Validator. An AI home energy assistant proposes one settings change at a customer's home battery system, such as a backup reserve. Before anything is applied, the assistant sends the change to Predictika, which checks it against a declarative model of the home energy policy and the home's own data, recomputes the assistant's figures, and returns a verdict (allow, needs the owner, or block) with every reason at once.
  2. I will start with the first request by the agent.
  3. The agent says. I am the home energy assistant. At the Dalton residence, a household member asked me to install firmware 9.1 beta. The rest of the request is on screen. I state 6 hours of backup.
  4. Before it goes out, the agent calls the validator.
  5. Blocked, with five findings and one approval, all in one answer. Beta firmware: Firmware 9.1 beta is a beta release and is not offered to homes. Firmware does not support this hardware: Firmware 9.1 beta needs hardware generation 2 or newer; this home has generation 1. Firmware update during a storm alert: updates are not scheduled while a storm alert is active. The other two are on screen.
  6. The validator returned five blocking findings and one approval in one answer. A check that reads one field at a time would pass most of this; it shows only when the choices in the change are checked against each other.
  7. What this shows: for a stated figure that changes when the setting changes, a rules-based automation can do this only with workarounds.
  8. Now the agent resubmits.
  9. The corrected request. It changes the requested by to owner, the firmware to Firmware 8.2 and the backup time stated by the assistant to 2 hours.
  10. It calls the validator again.
  11. Still blocked, with two findings, all in one answer. Firmware update during a storm alert: updates are not scheduled while a storm alert is active. Too many settings changes: 4 changes are already recorded in the last 24 hours; this would be one more, and the limit is 4.
  12. Four findings cleared; still blocked on firmware update during a storm alert and too many settings changes in 24 hours.
  13. The agent resubmits once more.
  14. The revised request. It changes the storm alert to no and the settings changes in the last 24 hours to 3.
  15. It calls the validator once more.
  16. This time the validator clears it.
  17. Both earlier findings are cleared.
  18. Six problems caught in one call, fixed in two passes, and a clean change. That is the value of Predictika's validator: catching mistakes before they reach production.