Frequently asked questions¶

These are the questions that have actually come up in the issue tracker, with the answers collected in one place.

Modes and scheduling¶

My inverter cannot export to the grid. Should I use Zero Grid or Hybrid?¶

Hybrid.

Zero-grid only does real-time self-consumption. It never charges from the grid in cheap hours — so you would lose the arbitrage that is usually the whole reason for switching to a dynamic contract. Hybrid does both: the DP charges from the grid in cheap hours, and zero-grid handles self-consumption the rest of the time.

For a no-export setup:

Set Max grid power to your contractual limit (e.g. 7 kW).
Keep the feed-in price at or near 0, so the DP never plans an export.
Leave Power production sensors empty.
If your PV is on the inverter's DC bus, add the arrays as subentries and tick DC-coupled — the forecast then plans grid charging around your own production.

Does `discharging` mean "export to the grid"?¶

No. This is the most common misreading of the mode sensor.

discharging means the DP wants the battery to deliver power during an expensive period. In a house that consumes anything at all, that power serves your own loads and displaces expensive import. Export only happens if the battery delivers more than the house is using and your system is allowed to export.

The four modes:

Mode	Meaning
`idle`	The battery neither charges nor discharges; loads are served from grid and PV
`charging`	The battery is being charged (from cheap grid power, PV surplus, or both)
`discharging`	The battery delivers power in an expensive period — normally into your own loads
`zero_grid`	Real-time control has taken over: the battery is regulating grid exchange toward zero

Will it hurt the predictions if I charge at max power instead of following the setpoint?¶

No. The optimizer re-solves from the actual SoC on every run, and its feedback comes from the SoC sensor, not from the battery power sensor. Charge faster and the next run simply re-plans from the higher SoC.

The cost is purely economic: charging flat-out can run into the pricier minutes of a window and overshoot the target SoC. Starting on optimal_mode = charging and stopping when it leaves that mode keeps the loss small. For a fully optimal result, drive charge power from sensor.battery_controller_battery_setpoint, which is already capped to your Max grid power.

Why does the schedule change between two runs a few minutes apart?¶

Because every run re-solves the entire 24–36 hour horizon from scratch, rather than patching the previous plan. A small change in the price forecast, PV forecast or actual SoC can shift how much capacity gets allocated to the current window versus a later one.

This is expected rolling-horizon DP behaviour. See the learning period.

The optimizer stopped charging during what looked like the most profitable window¶

Usually one of three things:

The SoC ceiling was reached — check Max SoC in the battery subentry.
The DP found a better window later in the horizon and is reserving capacity for it. Capacity is finite; the cheapest hour is not always the one worth using.
The spread no longer cleared the profitability bar after degradation cost and efficiency losses — see runtime tuning.

Upload your diagnostics to the analyzer; it explains every individual charge and discharge decision, including the ones it declined to make.

Sensors and forecasts¶

What is the difference between "Energy consumption sensors" and "Power consumption sensors"?¶

They take different kinds of sensor, and this is the source of most configuration confusion.

Field	Unit	What it must measure	What it is used for
Energy consumption sensors	kWh, cumulative	Gross household load — everything the house draws, from any source	Learning the consumption pattern
Power consumption sensors	W, live	Grid import, positive = import	Real-time zero-grid control only

flowchart LR
    GRID(["Grid"]) ---|"B — grid meter<br/><i>Power consumption sensors (W)</i>"| INV
    PV(["PV"]) --> INV
    INV["Inverter<br/>+ battery"] ---|"A — gross load<br/><i>Energy consumption sensors (kWh)</i>"| HOUSE(["House"])

    style INV fill:#0f766e22,stroke:#0f766e

The optimizer computes net_load = consumption − PV itself. If you feed grid import into the kWh field, PV is subtracted twice: once by physics (it never passed the meter) and once by the optimizer.

A sensor between the inverter and the house is the right pick for the kWh field. Your grid meter is the right pick for the W field.

My consumption forecast is far too low¶

Almost always this means no consumption pattern has been learned yet, so the forecast is still the built-in cold-start curve (~0.4–0.6 kW, shaped for a ≈3500 kWh/year household). It is not a scaling problem.

See the troubleshooting entry for how to diagnose it. Note in particular that waiting does not help — the pattern is learned from the past 14 days of your sensor's recorder history, not from how long the integration has been running.

My PV Forecast sensor shows a flat zero, but I do have solar¶

If all your arrays are DC-coupled, this is expected. The PV Forecast sensor reports the AC-coupled series; DC-coupled production is forecast separately because it takes a different efficiency path (~97 % via MPPT, versus ~85 % through a separate inverter).

The analyzer reports the DC total explicitly and accounts for it in the net line. If both series are zero across the whole horizon, that points at array configuration or the weather coordinator instead.

What does "Net Grid Forecast" actually mean?¶

Expected grid exchange without the battery: consumption − PV. Negative means you would be exporting. It is the baseline the optimizer compares its plan against, which is also how Estimated Savings is computed.

My prices are in €/MWh, do I need a template sensor to convert them?¶

No. The integration reads the sensor's unit_of_measurement and converts to €/kWh automatically, and the self-learning price model applies the same conversion to historical recorder data. Point the price sensor field straight at your source sensor.

This is the case for OMIE (Spain/Portugal), whose quarter-hourly data is also detected and used at its native 15-minute resolution.

The forecast coordinator finished in 0.001 s — did it skip something?¶

No. The forecast coordinator is arithmetic over arrays, so milliseconds are normal. The expensive step is the optimization coordinator, which runs the DP itself and typically takes seconds. Look for the Finished fetching Battery Controller Optimization data line in the debug log to see that timing.

Control and hardware¶

Which sensor should my automation read?¶

sensor.battery_controller_battery_setpoint. Not optimal_power — that is the optimizer's diagnostic recommendation, and it can legitimately differ from what should actually be sent to the inverter. See connecting your inverter.

The battery setpoint stayed positive all night while the mode said discharging¶

Positive is discharge, for every power sensor the integration creates. The configured input sensor uses the opposite convention. That mismatch is deliberate but confusing enough that it deserves checking twice — see sign conventions.

The mode flips rapidly between idle, charging and zero_grid¶

Hysteresis around the zero-crossing and surplus-coverage decisions was added after #81. If you still see churn on a current version, raise the Zero Grid Deadband so ordinary sensor noise no longer crosses the threshold, and check that your grid power sensor is not itself noisy.

Can I run this with multiple inverters and one big battery bank?¶

Yes. Add one battery subentry per physical battery. The optimizer aggregates them into a single virtual battery for planning and splits the resulting setpoint proportionally — by available headroom when charging, by stored energy when discharging.

Still stuck?¶

Download diagnostics via Settings → Devices & Services → Battery Controller → three-dot menu → Download diagnostics and upload the file to the analyzer. It re-runs the optimizer on your own data and flags configuration problems — an empty consumption pattern, an all-DC PV setup, an SoC ceiling that blocked a trade — directly in the report.

If that does not answer it, open an issue and attach the diagnostics file.