Skip to content

[UI] New energy flow monitor and PV forecast in live view - #4050

Open
JonasE99 wants to merge 2 commits into
OpenEMS:developfrom
JonasE99:feature/ui-energyflow-monitor
Open

JonasE99 wants to merge 2 commits into
OpenEMS:developfrom
JonasE99:feature/ui-energyflow-monitor

Conversation

@JonasE99

@JonasE99 JonasE99 commented Oct 13, 2026 •

Copy link
Copy Markdown
Contributor

This replaces the ring-shaped energy monitor in the live view (new navigation only) with a node-based energy flow view.

energyflow-monitor (Screenshot taken with fixed daytime values, default theme.)

I found the ring hard to read when several flows happen at the same time, e.g. PV charging the battery and feeding into the grid. I also wanted to see consumers and today's grid cost directly on the start page.

What's in it:

  • Nodes for production, grid, consumption and storage. Lines are only drawn for active flows, and their width and speed follow the power. The storage node shows the SoC as a ring. It also shows when the storage will be full or empty, based on the predicted SoC from the _energy schedule.
  • Consumers (EVCS and consumption meters, same selection as the consumption widget) are attached to the consumption node, together with "other". With more than six entries, consumers of the same category share a row, up to three side by side.
  • Daily tiles for production, consumption, grid buy and sell, autarchy, and grid cost today.
  • A compact layout below 560 px component width (switched via ResizeObserver).

A few implementation notes:

  • Grid cost: with dynamic tariffs the price changes every 15 minutes, so I take today's metered GridBuyActiveEnergy and split it over the quarter hours according to the average grid buy power (queryHistoricTimeseriesData, 15 min). Each share is then multiplied by the GridBuyPrice of that quarter hour. I first tried queryHistoricTimeseriesEnergyPerPeriod, but the backend I tested against returned one value per day for a 15-minute resolution.
  • getSchedule returns only one day if from is exactly 00:00, otherwise two days. The schedule is requested from 12:00 today, so that the SoC prediction also covers tomorrow.
  • Icons inside the SVG are inlined from ionicons/icons instead of <ion-icon> in a foreignObject, because Safari on iOS placed them in the wrong position.
  • Colours can be overridden per theme via --oe-energyflow-*. Neutral backgrounds use color-mix() on --ion-text-color, because the default theme's dark mode doesn't set --ion-text-color-rgb.

It also fixes two small issues in the old ring monitor, which is still used without the new navigation. The grid price overlapped the grid icon, and the ring could be taller than the visible area.

Tested on my own FEMS system (dynamic tariff, one EVCS, three consumption meters) in Chrome and iOS Safari, in light and dark mode. Unit tests for the component are included. Lint, the full UI test suite and the production build pass.

The consumer category is currently guessed from the alias (e.g. "heat", "wärme"). If there's a better way to get the device type for generic meters, I'd be glad for a hint.

@codecov

codecov Bot commented Oct 13, 2026 •

Copy link
Copy Markdown

Codecov Report

❌ Patch coverage is 77.88779% with 67 lines in your changes missing coverage. Please review.

Additional details and impacted files
@@              Coverage Diff              @@
##             develop    #4050      +/-   ##
=============================================
+ Coverage      55.46%   55.51%   +0.05%     
- Complexity     19909    19913       +4     
=============================================
  Files           3931     3932       +1     
  Lines         180769   181070     +301     
  Branches       15078    15157      +79     
=============================================
+ Hits          100253   100495     +242     
- Misses         76541    76580      +39     
- Partials        3975     3995      +20     
🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
  • 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

@JonasE99
JonasE99 force-pushed the feature/ui-energyflow-monitor branch from bc390b9 to c2a6830 Compare October 13, 2026 20:18
}

/** Estimated time until the storage is full (charging) or empty (discharging) */
private calculateStorageEstimate(capacity: number | null): string | null {

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we have Predictors in OpenEMS - why not use this ?

Image

Sorry for the messy Sceenshot :)

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good point, thanks! The full/empty estimate now uses the predicted SoC from the energy schedule instead of the linear extrapolation.

@Sn0w3y Sn0w3y left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

just wanted to note one thing :)

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Image

We already have this aswell in the new UI

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, you’re right. I removed the PV forecast box from this PR to keep it focused on the energy flow.

…V forecast box

Addresses review feedback: the full/empty time now comes from the predicted state of charge of
the energy schedule instead of a linear extrapolation, and the PV forecast box is removed because
the forecast is already shown in the new UI.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants