Skip to content

Add mFRR activation sensor/event and total revenue; test in real Home Assistant - #11

Merged
andreasthell merged 8 commits into
mainfrom
claude/quirky-gates-vo0djf
Oct 8, 2026
Merged

andreasthell merged 8 commits into
mainfrom
claude/quirky-gates-vo0djf

Conversation

@andreasthell

Copy link
Copy Markdown
Owner

Based on a HAR export of the EnergyInBalance dashboard from 2026-10-08.

New entities

  • mFRR Activation Active (binary sensor): on while the battery is activated for mFRR. /ems/ActivationSchedule now lists the site's actual activations (MfrrUpActivation/MfrrDownActivation: start, end, power, ramp times). The list is fetched every 5 minutes, and the on/off state is re-evaluated every 60-second cycle so it turns off at the end time. Attributes describe the ongoing activation, or the latest one when off.
  • mFRR Activation (event): fires up or down for each activation that appears after HA starts. Activations already listed at startup do not fire. An activation missing from a single response does not fire again when it reappears (seen activations are kept for 7 days).
  • Total Revenue (sensor): the sum of /revenue?resolution=month since 2023-01-01, the same query the dashboard makes, with a per-service breakdown in by_service. If a response comes back empty, the sensor keeps its previous value.

activations is added to the slow updates shown on the Last API Poll sensor. Version is bumped to 1.6.0 (v1.6.0b1 is already published as a pre-release from this branch).

Docs

  • docs/api.md is updated with all changes found in the export, marked 2026-10:
    • mFRR activations in ActivationSchedule; the hourly SpotPrice array is removed
    • the new mFRR EAM revenue service and resolution=month
    • Day/Month/Period resolutions and the new savings data types in SiteMeasurements
    • new fields in the site, energyflow, Statuses, CustomerDetail and diagnostics responses
  • The README describes the new entities, explains that event entities show Unknown until they first fire, and documents both test suites.

Tests and CI

  • tests_ha/ sets the integration up in Home Assistant 2026.10.0 (via pytest-homeassistant-custom-component, pinned in requirements_test_ha.txt) with a fake API client. It checks:
    • setup logs no errors, and unload works
    • events stay unknown until something happens, then fire with their attributes, and the last event survives a reload
    • the same activation in the next response is not a new event
    • the binary sensor and the total revenue sensor show the right values
  • A new CI job, Tests (Home Assistant), runs tests_ha/ on Python 3.14, and releases now wait for it. It is a separate job because the stubs in tests/ replace homeassistant in sys.modules.

Local results: 115 stubbed tests pass, 6 real-HA tests pass on 2026.10.0, and ruff check/format are clean. As a check that the tests catch real failures, temporarily disabling the mFRR event made test_events_fire fail.

🤖 Generated with Claude Code

https://claude.ai/code/session_01UwYSvzP667Y5pkhzfs8obW


Generated by Claude Code

claude added 6 commits October 8, 2026 14:08
The 2026-10 web app's /ems/ActivationSchedule lists the site's actual
mFRR activations (MfrrUpActivation/MfrrDownActivation). A new binary
sensor is on while one is ongoing, and a new event entity fires "up" or
"down" for each activation that appears after HA starts. Activations
are fetched every 5 minutes; the on/off state is re-evaluated every
cycle.

A new Total Revenue sensor sums /revenue with resolution=month since
2023-01-01, as the dashboard does, with a per-service breakdown.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01UwYSvzP667Y5pkhzfs8obW
Update docs/api.md from a 2026-10-08 dashboard HAR: mFRR activations
in ActivationSchedule (hourly SpotPrice removed), the mFRR EAM revenue
service and monthly revenue, Day/Month/Period resolutions and savings
data types in SiteMeasurements, and new fields in site, energyflow,
Statuses, CustomerDetail and diagnostics responses. Describe the new
sensors and event in the README.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01UwYSvzP667Y5pkhzfs8obW
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01UwYSvzP667Y5pkhzfs8obW
Also correct the entity id in the automation example: in a real Home
Assistant the event entity gets event.mfrr_activation.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01UwYSvzP667Y5pkhzfs8obW
Home Assistant 2026.10 prefixes the event entity id with the device
(site) name, e.g. event.<site>_mfrr_activation.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01UwYSvzP667Y5pkhzfs8obW
The existing tests run against simplified HA stubs. tests_ha/ sets the
integration up in Home Assistant 2026.10.0 via
pytest-homeassistant-custom-component, with a fake API client, and
checks that setup logs no errors, that the event entities stay unknown
until something happens and then fire with their attributes, that the
last event survives a reload, the mFRR binary sensor, the total revenue
sensor, and unload.

The stubs replace homeassistant in sys.modules, so the suites run
separately: a new CI job runs tests_ha on Python 3.14, and releases now
wait for it.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01UwYSvzP667Y5pkhzfs8obW
claude added 2 commits October 8, 2026 14:24
Matches the action updates in #12, so the workflow is
consistent whichever pull request merges first.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01UwYSvzP667Y5pkhzfs8obW
@andreasthell
andreasthell merged commit df63d28 into main Oct 8, 2026
4 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants