import_limit setting requirement #2449

Activity

1. springfall2008

   added

   enhancementNew feature or requestNew feature or request

   on Jun 14, 2025
2. steve-daedilus commented on Apr 24, 2026

   

   steve-daedilus

   on Apr 24, 2026

   More actions

   This is potentially about to be an issue for me as well. I've got a 63A DNO fuse, and with an addition of a 7kW charger for an EV, my window based charging demand will be around 14kW without the house.

   This means that unless the DNO upgrades the fuse, I'm at risk of blowing it on a nightly basis.
3. Noodleyman commented on Apr 24, 2026

   

   Noodleyman

   on Apr 24, 2026

   Author

   More actions

   My issue evolved a bit since I originally shared this ask, although the base requirement still exists.

   In the SolarEdge inverter, we can set a grid import limit. the inverter will then monitor grid usage and will adjust its charging rates as needed, to keep the overall grid usage below the configured limit. It's built for these use cases.

   But, predBat has no awareness of the variable charge rate, so it's calculations, especially those for estimated SOC after X time can be wildly wrong. this can then result in a battery not charged by the time you would expect or similar.

   For me, I've simply set solaredge_i1_storage_charge_limit to be a lower value, which lets PredBat become aware of the charge limit. It takes longer to charge overall, but it's predictable. The downside is, that on pretty decent sunny days, my ability to charge the battery based on the PV generation can be impacted. I am not automating changes to that charge limit in case it goes wrong as I cannot have it revert to the higher limit safely,

   My issue goes away in 3 weeks anyway as we're rewiring everything, although it's an interesting little puzzle. If Predbat had awareness of the variance it would likely solve the issues.
4. gcoan commented on Apr 24, 2026

   

   gcoan

   on Apr 24, 2026

   Collaborator

   More actions

   This is potentially about to be an issue for me as well. I've got a 63A DNO fuse, and with an addition of a 7kW charger for an EV, my window based charging demand will be around 14kW without the house.

   This means that unless the DNO upgrades the fuse, I'm at risk of blowing it on a nightly basis.

   Steve

   You should be able to get your DNO to upgrade the fuse to an 80A which is the new standard.

   Its not as simple as any current over the fuse limit will blow it, its a slow blow fuse and so (depending on what power being drawn) it takes an extended period of time at the higher power draw before the fuse goes. This is why DNOs now fit 80A fuses not 100A which many houses (mine included) have, because (can't remember the figures) with a 100A I could be drawing 120A for something like 8 hours without the fuse blowing.

   You can find an article on this and why fuses are now 80A.

   But do get the DNO to upgrade your fuse, raise it as an electrical safety issue and they should be quite quick at responding.

   As a workaround you could set predbat's inverter limit charge via the manual API to a lower figure overnight to throttle the battery charge rate back.
5. arturonaredo commented on Oct 11, 2026

   

   arturonaredo

   on Oct 11, 2026

   More actions

   Adding a concrete use case for this request, also relevant to #1199's proposed first step of a flat site-import limit.

   Environment and observed limitation

   • Predbat v9.3.7 (303d592bd5f1b707201c4da70b9ab3308fd10758).
   • Deye hardware configured as inverter_type: SK, through local Solarman. Not Deye Cloud.
   • Native Predbat-led EV planning; a single Home Assistant automation follows its charging-slot signal and applies physical safety guards. No external battery/EV optimiser.
   • Whole-site import ceiling: 6,000 W.
   • Inverter limit: 16,000 W; battery charge/discharge model limits: 3,000/8,192 W.
   • Battery capacity: 32.1536 kWh, with a 10% reserve (3.21536 kWh, not 0.1 kWh).
   • EV input is approximately 6.77 kW at a fixed rate; there is no validated current-control interface. Lowering the configured prediction rate would not throttle the actual charger.
   • EV load is inside the house CT and car_charging_from_battery is enabled. Export compensation is zero.

   I observed a native forecast, not a measured overload, with five future grid-power points above 6 kW and a peak of 6.333 kW. The installed Python prediction path accumulates residual grid demand without a whole-site import constraint: v9.3.7 prediction.py, lines 1359–1394.

   The separate inverter_limit_charge, inverter_limit_discharge and battery_rate_max settings are not a joint grid-import cap. Hardware peak shaving or a relay cutoff may prevent execution, but that does not make the forecast or its advertised EV completion feasible.

   There was also a separate household-history quality problem in this installation. I have removed its contaminated ML forecast from active planning and selected recent measured native history. The observed forecast above is therefore supporting context, not a controlled quantitative reproduction of this feature in isolation. Correcting load history does not introduce the missing constraint. This report also makes no claim about the cause of an inverter backup/communication fault.

   Expected configurable behaviour

   An optional, whole-site parameter such as import_limit: 6000 (W; disabled by default) should model the combined demand of the house, EV and battery charging, after PV and physically available battery support:

   1. Preserve energy balance. Do not simply clip the displayed import curve or silently discard EV/house demand.
   2. Respect battery charge/discharge rates, losses and reserve. Curtailing battery grid charging must not unnecessarily reduce otherwise available PV charging.
   3. Prefer a feasible battery/EV plan over a cheaper infeasible one; prepare battery energy automatically where possible, without a fixed arbitrary reserve or manual SoC override.
   4. Do not assume the battery always supplies only the portion above the grid limit: dispatch/hold behaviour must match the inverter control model.
   5. For fixed-rate EV charging, move or defer executable slots as necessary. If the connection, power, stored energy or deadline makes the request impossible, report an explicit shortfall/infeasibility rather than promising completion.
   6. Keep Python and C++ predictions consistent, or explicitly disable an unsupported kernel path when the feature is enabled. An enabled setting must never be silently ignored.

   For example, with no PV and the battery at its reserve, 1 kW of household demand plus a fixed 6.77 kW EV requires 7.77 kW of import: it cannot fit within 6 kW. This is a simple feasibility bound, not a claimed simulator test result. A viable alternative needs earlier battery preparation, a different EV slot or an explicit unmet request.

   A first-stage draft can expose configuration and truthful feasibility diagnostics, but should be labelled as such: diagnostics alone do not enforce the limit, optimise EV slots, account for an executor's 15%/25% pause/restart hysteresis, or provide real-time electrical protection. The draft must not close this request until its stated scope is actually implemented and verified.

   I am testing the proposal in an isolated fork; it is not installed on the live inverter controller. Tests use synthetic data, not private HA dumps, and no load, battery-disconnection or outage experiments are involved.
6. arturonaredo commented on Oct 11, 2026

   

   arturonaredo

   on Oct 11, 2026

   More actions

   Draft follow-up: #5486 — configurable whole-site import diagnostics (no enforcement).

   The initial implementation adds a scalar import_limit threshold in W and reports
   the best forecast's raw peak import, excess energy and violating duration. It does
   not alter battery dispatch, fixed EV demand, costs or candidate ordering, and it
   does not hide an over-limit plan by clipping the grid graph.

   The draft includes synthetic reserve/energy-balance and EV tests, real cache/kernel
   checks, mocked HA publication tests and a proposal for the later joint constraint.
   The focused tests and full quick suite passed locally; four slow tests were skipped.

   This is not a complete solution to #2449 or #1199, is not a real-time protective
   limit and has not been deployed to live hardware. Native EV rescheduling, feasible
   battery preparation and executable grid-charge curtailment remain follow-up work.
   Both issues should remain open. Feedback on the diagnostics-first split is welcome.
7. gcoan commented on Oct 11, 2026

   

   gcoan

   on Oct 11, 2026

   Collaborator

   More actions

   Just one comment on the original ask

   Describe the solution you'd like
   A setting to explicitly define import_limit, to work like th export_limit setting, but for imports as the grid import limit may vary from inverter charge limits.

   I think the solution being asked for is not like export_limit. Predbat relies on the inverter to enforce export_limit and the configuration in Predbat is so that Predbat can model this behaviour and include it in the plan.

   Ideally an inverter would deliver similar import side behaviour because to do this properly requires dynamic control, throttling battery and/or solar in response to changing house load. Predbat with its 5 minute cycle time would simply not be able to do this.

   @arturonaredo thanks for the work so far on this, the above provided as food for thought as to how accurate and time-responsive Predbat can be in managing import load.
   Adding such an enhancement does make sense, its just that a Predbat-based solution is going to have limitations and not be able to totally constrain import energy to the defined limit