GridFusion energy management features

Features with a clearly stated development status

GridFusion combines live measurement, a local energy model, history, external price data and solar forecasts. It distinguishes implemented system components, current pilot validation and planned extensions. “Implemented” means the software and interface exist and have been tested. It does not automatically mean that every combination of devices has already been approved on real hardware.

Live dashboard for solar, battery, home and grid

The local dashboard presents the current energy flow on the 800 × 480 pixel Control 7 display. Solar production, household consumption, battery storage and the grid appear as one connected state. Price, forecast, phase readings and connectivity can also be displayed when their required data is current and valid.

The interface distinguishes a real value from a simulated value, missing data and an impaired device. A placeholder such as “–” is therefore not merely a visual gap; it may be an important indication that no valid reading exists yet. Diagnostic views help identify the affected driver, endpoint or data stream.

Solar self-consumption and battery planning

The Energy Engine is designed to combine local surplus and grid import with battery state. Instead of addressing a brand directly, it works with generic metering and battery properties. Rules for state of charge, available power and data freshness therefore remain independent of the specific vendor.

The controlled write path for Solakon ONE is implemented, but remains a pilot and commissioning topic. Normal firmware does not make it automatically available, and every write must pass the central solakon_write_enabled Safety Gate. Stale or invalid grid metering always means no new battery command.

Dynamic electricity prices without a fixed hourly grid

GridFusion processes price intervals of variable length. This matters because electricity prices do not necessarily apply for a full hour. Negative prices remain valid values, while wholesale data and the relevant retail price are modelled separately. A central service retrieves approved providers, validates and normalises the data, and supplies Control 7 through a versioned contract.

Local control never waits synchronously for a price provider. A cheap interval is not considered in isolation either: battery efficiency, state of charge, expected consumption, solar forecast and data age all matter. The feature therefore remains part of a complete energy management process instead of becoming a simplistic “charge when cheap” automation.

Weather, solar and consumption forecasts

The forecast architecture is provider-neutral and can represent multiple physical solar arrays. Expected production becomes a generic forecast state with time intervals, quality and freshness. Control 7 can display and safely assess that state locally. If no dependable forecast is available, the system continues without aggressive assumptions.

The central platform also provides device-specific baselines and an Observe mode. They support analysis and comparison, not a direct control channel. AI training, model selection and inference do not run on Control 7. Even a central forecast result must pass local quality and safety checks.

Local history, analysis and diagnostics

Measurements, prices, forecasts and diagnostic records are stored through a non-blocking storage boundary. With a healthy SD card, SQLite is intended for long-term history. Without an SD card, the system remains operational and uses a bounded, CRC-protected LittleFS fallback. Migrations are resumable and verified before local segments are deleted.

History is intended to do more than draw charts. It provides the basis for comparing forecasts with actual production, decisions with outcomes, or connectivity faults with installation state over time. Drop and error metrics expose situations in which not every historical record could be retained permanently.

Local operation, configuration and web interface

Control 7 provides both the on-device interface and a local authenticated web backend. Network and device settings are managed there within clearly defined authority. The central platform can present fleet, service and diagnostic data, but receives no direct route to a local device driver.

Firmware can be delivered as a signed, managed OTA update. Download, integrity verification, installation state and rollback must follow the documented security contract. An update must never create an implicit control approval; the Solakon Safety Gate remains closed whenever its explicit conditions are not satisfied.

Today, pilot phase and the next stages

Implemented in the system

• Local Control 7 interface, energy flow and system diagnostics
• Vendor-neutral device and capability abstraction
• Reference drivers for Shelly Pro 3EM and Solakon ONE
• Local storage architecture that operates without an SD card
• Central price, weather, forecast, telemetry and OTA contracts

In pilot and hardware validation

• Additional real installations and different device combinations
• Supervised and tightly bounded Solakon write tests
• Long-running, router, storage, outage and update scenarios
• Comparison of forecasts and optimisation decisions with actual histories

Planned

• Additional meter, battery and inverter drivers after source verification
• Room temperature and further local environmental sensors
• Flexible loads such as EV chargers and heat pumps
• Deeper MQTT and Home Assistant integration

See compatibility for model and interface details. Owners who would like to offer another installation type for the pilot can find the required information under contact.