Need for support for multiple solar inverters and batteries ?

[scruysberghs]

Now that 0.17.3 is out with great additions to the thermal loads there is this one thing left in emhass architecture I feel is missing.
emhass now has support for many deferrable loads, be it thermal, thermal battery or whatever but currently only support for 1 solar inverter and 1 battery.
Use cases like 2 solar inverters, one hybrid and one not for example. One you can curtail and the other not. One with a differtent grid injection rewards , different power ratings, inverter efficiency etc. So all the pv paramters but 1 per device and allow for many, with their specific solar forecast.

Same for batteries. I come across setups with multiple batteries, solar inverter connected, plug in, etc all behind the same meter and with the availability of V2X chargers more and more "batteries" will start to pop up...

So this is just a check if this (probably drastic) architectural overhaul is seen as must have for others.

[JoshC1994]

I agree with this, the addition of multiple batteries and then have muliple desired SOC_Forecasts based on the battery variables would be a great addition. It would allow management of different battery propertites and setting them with independent charge & discharge rates weightings etc.

I noticed this great addition by @LesIT1 for 0.17.9 and wondered if we can continue those efforts by bring this to life!

A few thoughts/additions would also be options on how the batteries are then scheduled. i.e.

• Have them all discharge/charge in sync.
• Have them operate in waterfall (so one discharges and then then next)
• Ability to set the order (or randomise/cyclic/based on discharge and charge count)
• Ablity to assign the battery to the inverter i think is nessasary to link the two together (But also ability to de-couple from the inverter is important)

I think with the mass of waste im seeing of older batteries being replaced for large systems, being able to manage sepearte system types to act as a swarm/whole is important for keeping these legacy units viable.

[LesIT1]

@JoshC1994 I've put a full proposed shape over in #610, since that thread has the multi-battery history. Short version: phase 1 is N stationary batteries on the deferrable-loads array pattern, scalars still accepted so existing configs don't change; intermittent connection for V2G/V2H comes after as its own design round; and the multi-inverter side would be a third step once batteries land. @scruysberghs the inverter modelling you describe is real, I just think batteries have to go first or this becomes exactly the kind of big-bang overhaul that's hard to review and merge.

On the modes idea: the drain order you want from waterfall falls out of a small deterministic per-battery cost tilt whenever costs tie (any real efficiency or price difference still decides), and per-battery charge and discharge rates are plain arrays in phase 1, so those two come almost free. I'd avoid hardcoded mode logic inside the optimizer though. The battery-first feature is the warning there: its hard gate made day-ahead infeasible (#1002, fixed in #1014 by softening it) and it still rebuilds the problem on every MPC tick (#1009, open). Synchronized dispatch and cycle-count balancing are the genuinely hard ones and a cost tilt doesn't cover them, so I'd park those two rather than pretend it does.

[scruysberghs]

When I think about it some more, not sure if keeping the multi battery and multi inverter as sepperate tracks is a good idea. There is a link when setting the "inverter is hybrid" option you would have to link a specific battery and intverter. So inverters can have a battery or not (hybrid) and AC limits would apply to the inverter/battery combination. That would mean both inverter and battery should switched to a multi device setup at the same time...

[LesIT1]

Fair point on the hybrid coupling, and I agree the battery-inverter link belongs in the data model from day one. Where I'd push back is on the conclusion that the solver has to go multi-inverter at the same time.

Worth being clear about what the model does today: inverter_is_hybrid is a single plant-level flag, and if you give pv_inverter_model a list it just sums the capacities into one virtual inverter. One DC bus, one aggregate AC cap. So a two-inverter household today can already get a plan that overloads one inverter while the sum looks fine. Phase 1 with N batteries behind that same aggregate model doesn't widen that gap, but it doesn't fix it either, and fixing it is real optimizer surgery: per-inverter DC buses, plus assigning PV arrays to inverters, which needs its own forecast split. That's exactly why I'd contain it in its own phase rather than blocking N batteries on it.

So for phase 1 I'd shape the per-battery entries so an inverter link can be added later without a config migration, and the phase 3 default would be all batteries on the one aggregate inverter, so existing configs shouldn't need to change. If you're up for it I'd value your review of the phase 1 schema for exactly that forward compatibility, since you've already been down this road with your branch.