Working an multi battery feature, feedback wanted on how to handle bi-directional ev charging

[scruysberghs]

I've been working on a feature to allow multiple batteries to be defined in emhass (comparable with how multipe deferrable loads are handled)

A feature I would like to add while I'm working on this is support for bi-directional ev charging. Basicly for emhass this is just another battery with a start soc and a charging goal (end soc). The only difference I see is that the car won't always be there. I was thinking this could be handled by using start_timesteps_of_each_battery and end_timesteps_of_each_battery (comparable with the comparable settings for each deferrable load start_timesteps_of_each_deferrable_load).
By default it will be from now until the end of the planning horizon for fixed batteries but it will allow you to set the period your bi-directional car will be connected and when it will leave beforehand.

Anyone here with a bi-directional car or an opinion on this?

[purcell-lab]

I'm very interested in this capability and would like to work with you on this.

I have a hybrid SigEnergy bidirectional charger and 2xEVs which I'm currently controlling using EMHASS.

My fixed battery is 40 kWh and can discharge at 21 kW, when a vehicle is plugged in I then have +60 kWh and can discharge at 40 kW.

To work with EMHASS I dynamically increase battery capacity to 160 kW (2x EV + fixed) and discharge rate to 30 kW when the vehicle is plugged in and both are at home.

If the vehicles are not at home then I reduce to 40 kWh/ 21 kW.

For vehicle charging I add a delay start_timestep of 2 hours if they are not home, so they get scheduled to charge, just not immediately.

An end time step would be useful for battery performance and I would often like to force 100% SOC by sunset each day.

https://v2g-liberty.eu/ provides a useful framework for bidirectional charging but I haven't implemented it yet.

[scruysberghs]

For vehicle charging I add a delay start_timestep of 2 hours if they are not home, so they get scheduled to charge, just not immediately.

EV charging defined as a deferrable load then?

Creative thinking to increase battery capacity and battery power on the fly when connecting a V2G capable EV. Being able to set it as a separate battery should give you better results.

Had a look at the https://v2g-liberty.eu/ link you sent. They use home assistant UI in combination with Flexmeasures (open source optimisation engine and alternative to emhass) .

Using multiple batteries in combination with a schedule when the V2H device will be connected will allow us to do the same thing with emhass. You would need to create a translation from for example a calender schedule when the car will at home (or autodetect it or have a model predict it) and set the battery parameters in emhass.

If i think about it some more, if you have multiple at home/away periods during your emhass optimisation window merely using using a start and end timestep wont cut it. A battery connected true/false list per optimisation step might be a better solution. Or only plan the next period the car will be connected.. (thinking out loud here)

[purcell-lab]

For vehicle charging I add a delay start_timestep of 2 hours if they are not home, so they get scheduled to charge, just not immediately.

EV charging defined as a deferrable load then?

Yes I defined by EVs as deferrable loads, that was a hangover from when I didn't have a bidi charger.

Creative thinking to increase battery capacity and battery power on the fly when connecting a V2G capable EV. Being able to set it as a separate battery should give you better results.

Now with the bidi charger I just tend to treat them as one virtual battery which goes up and down in capability dynamically, so the EV deferrable load isn't as relevant, except for scheduling the load into the future when the EVs aren't home.

Using multiple batteries in combination with a schedule when the V2H device will be connected will allow us to do the same thing with emhass. You would need to create a translation from for example a calender schedule when the car will at home (or autodetect it or have a model predict it) and set the battery parameters in emhass.

There have been some other use cases for multiple batteries (non EV) so I think it will be useful for a number of uses.

If i think about it some more, if you have multiple at home/away periods during your emhass optimisation window merely using a start and end timestep wont cut it. A battery connected true/false list per optimisation step might be a better solution. Or only plan the next period the car will be connected.. (thinking out loud here)

I wouldn't try at this stage to accommodate multiple at home/ away periods, it becomes quite complex and the vehicles don't comply and plug in exactly when they need to.

Another strategy I have used for a vehicle that is mainly away during the day is to schedule start_timestep for 8pm or now if the vehicle is plugged in and then the end_timestep for 8am the next morning. Both the start & end timesteps are dynamic input variables that can be set by the user.

If the vehicle has multiple home/ away periods the schedule will update dynamically and charge during opportunistic at home periods (if plugged in), but it will schedule that overnight charge if still required,

[scruysberghs]

I tought I would have had some time to work on this this week but sadly things got in the way...

I've checked in the multi battery feature I already made https://github.com/smartenergycontrol-be/emhass/tree/feature/multiple-batteries
Have not made a PR out of it but you can test by checking out the feature branch. I see it is a couple of commits behind master but should be fine to test.
This is just multiple batteries code, no start or end timesteps for V2G/H yet (so the existing battery config but multiple times). Feel free to test it out

[purcell-lab]

I've checked in the multi battery feature I already made https://github.com/smartenergycontrol-be/emhass/tree/feature/multiple-batteries

What is the easiest way to test?

Can I download this branch as a custom addon and switch between EMHASS versions?

I couldn't infer the right address to use Manage add-on repositories.

[scruysberghs]

I found the most flexible way for me to run code during development is using the devcontainer in vscode. You have to add the details of your home assistant setup to the secrets.yaml file and transfer the config.json over from your add-on in home assistant.

I also created a small docker-compose.yaml file to build and run the container directly without vscode:

version: '3.8'

services:
  emhass:
    build:
      context: .
      dockerfile: Dockerfile
      args:
        TARGETARCH: amd64  # Change to aarch64 for ARM64
    image: emhass:local
    container_name: emhass
    restart: unless-stopped
    ports:
      - "5001:5000"
    volumes:
      - ./config.json:/share/config.json
      - ./secrets_emhass_test.yaml:/app/secrets_emhass.yaml
      - ./data:/data
      - ./share:/share/emhass
    environment:
      - TZ=Europe/Brussels
    networks:
      - emhass-network

networks:
  emhass-network:
    driver: bridge

[JoshC1994]

How did you guys get on with this one?

I noticed the recent 0.17.9 addition by @LesIT1 and thought it would be great to build on this with bring multiple batteries to life.
I also made mention #870

[LesIT1]

@JoshC1994 thanks for the ping. For clarity, my 0.17.9 changes were all single-battery work, so this would be a fresh build rather than a continuation of anything, but I'm keen. Before writing code I'd want to agree the shape with @davidusb-geek, so here's what I'd build.

Phase 1: N stationary batteries

Follow the deferrable-loads pattern: a number_of_batteries (default 1), and the existing battery params become arrays (capacity, charge/discharge power limits, efficiencies, SOC min/max/target, stress and SOC deficit/surplus costs). Scalars stay accepted and broadcast, so existing configs need no changes, and with one battery the model is mathematically unchanged, pinned by regression tests. One param needs care: weight_battery_charge/weight_battery_discharge can already be time-varying lists, so per-battery values there have to be nested (one entry per battery, each a scalar or a series) rather than a flat list.

Each battery gets its own charge/discharge variables and SOC trajectory, and the power balance sums over batteries. soc_init/soc_final accept lists at runtime. sensor.p_batt_forecast stays as the fleet total with per-battery variants added; SOC publishes per battery, since an aggregate SOC across packs of different sizes isn't meaningful.

Two model-level points:

1. No new gate machinery. Each battery replicates the per-timestep charge/discharge direction binary the single battery already has, and that's it: no mode or ordering binaries. Dispatch order should fall out of per-battery efficiencies and costs. The battery-first feature is the cautionary tale here: its hard gate made day-ahead infeasible (Bug: set_battery_first_priority makes dayahead-optim infeasible even on trivial inputs (works in naive-mpc-optim) #1002, fixed in Make set_battery_first_priority a soft penalty so it cannot cause infeasibility (#1002) #1014 by softening it to a penalty), and enabling it still rebuilds the problem on every MPC tick (set_battery_first_priority: true invalidates OptimizationCache on every MPC tick (10-20x slowdown) #1009, open). Ordering modes would add more of exactly that kind of machinery. Battery-first itself carries over by gating on aggregate stored energy above aggregate minimum.
2. Symmetry breaking from day one. Two identical batteries leave the solver free to pick either at equal cost, so plans flap between runs (the same degeneracy family as the variability in Is it normal for MPC optimization results to differ so dramatically even when it's run often? #1005). A tiny per-battery epsilon tilt, same trick as the curtailment tie-break in feat: schedule PV curtailment as late as possible (closes #342) #968, pins a deterministic preference: battery 0 first when costs tie. It's a tie-break, not an ordering mode, and any real cost or efficiency difference still wins.

Phase 2, separately: intermittently connected batteries (V2G/V2H). @scruysberghs already had the right primitive earlier in this thread: a per-timestep connected true/false list per battery, which also covers multiple plug/unplug cycles where start/end pairs can't. The genuinely hard part is SOC continuity. SOC is currently one cumulative chain from a single soc_init, and while a car is away its SOC changes outside the model, so each reconnection needs the chain re-anchored (a runtime soc_on_return, or a driving-consumption delta). That touches the terminal-SOC equality and the SOC-recovery logic, so it's a real formulation change that deserves its own design round. It also makes a per-battery SOC target at departure necessary rather than nice-to-have, which is @purcell-lab's "100% by sunset" case. None of this needs to be in phase 1.

Phase 3, later and over in #870: battery-to-inverter association for real multi-inverter setups. Out of scope here.

@scruysberghs your feature/multiple-batteries branch proved out the constraint replication, and I'd lean on it as the reference. Master has moved a lot since November though (stress model, SOC deficit/surplus costs, battery-first, self-identification, all assuming one battery), so it probably needs rebuilding against current master rather than rebasing. Are you still planning to take it forward, or happy for me to pick it up? Either way I'd want your and @purcell-lab's eyes on the result.

@davidusb-geek no urgency, but if a phase-1 PR in roughly this shape would be welcome, I'll build it. Equally happy to adjust or drop it.

[scruysberghs]

@LesIT1 feel free to pick it up. My time and antropic tokens are directed at some other, non emhass, problems at the moment...

See my comment on the other multi device discussion, it think batteries and inverter will have to go multi device at the same time (a hybrid inverter wil need to be linked to a specific battery). It will be a major architectural overhaul that would need real world testing on different setups and you'd have to be very carefull not to break things for existing setups with just one battery and inverter...

[LesIT1]

An update since the last round of comments here: ffrog8 closed #1020 rather than run a competing design. The site-level direction lock in his proposal turned out to be a shortcut he was fine dropping, so there's no conflict left between the two shapes. His R1-R6 findings and the SOC-balance idea fold into phase 3, and he's asked to be tagged as this progresses.

@davidusb-geek with that settled, phase 1 just needs your call on the shape: N stationary batteries via the same list pattern as the deferrables, scalars broadcast, nested battery weights, per-battery direction binary, no mode or ordering binaries, and single-battery configs mathematically unchanged with regression tests to pin that. If that works for you I'll build it as the next PR. If you want a different cut, cheaper to tell me now than after the code exists.

[scruysberghs]

multiple batteries will probably also need some sort of prioritisation or strategy. Split load evenly, charge/discharge one by one/charge hybrid batteries with higher priority when there is solar...
For example is you have 2,5kW batteries and you want to discharge 2kW, will you take 2kW out of one or 1kW out of each (with higher inverter losses).

So priorities or a way to make the optimiser do "the right thing"....

[davidusb-geek]

Ok @LesIT1, let's greenlight Phase 1 exactly as you've described it.
The approach of mirroring the deferrable-loads array pattern for N stationary batteries is the perfect trade-off I think.
This gives us the foundational multi-battery capability necessary for future EV/V2G integrations without fundamentally altering the core MILP architecture.

I strongly agree with your two model-level constraints:

• Let the dispatch order naturally emerge from per-battery efficiencies and costs. We definitely want to avoid the computational overhead of hard gates and conditions.
• Symmetry breaking: Using the epsilon tilt for tie-breaking is mathematically elegant and keeps the solver fast and deterministic.

Keeping the power balance as a simple sum across batteries, very much like how we handle multiple PV plants, keeps things clean.
We will strictly leave the dynamic SOC continuity (Phase 2) and battery-to-inverter topology (Phase 3) out of scope for this PR.

[LesIT1]

Thanks David, building it to that exact shape: array pattern like the deferrables, dispatch left to emerge from per-battery efficiencies and costs, epsilon tilt for tie-breaking only, power balance as a plain sum, and phases 2 and 3 firmly out of scope. Single-battery configs stay mathematically unchanged, with regression tests to pin that.

@scruysberghs your prioritisation question is answered by David's second bullet: no priority knobs or ordering gates. Dispatch falls out of the per-battery efficiencies and weights, and if you want one-by-one behaviour in practice you can get it by giving batteries slightly different weights. The epsilon tilt only breaks exact ties so the solver stays deterministic.

@ffrog8 tagging you as promised, the phase 1 schema will be in the PR for your review.

[JoshC1994]

@LesIT1 I have been running this recent PR off my own fork and noticed it doesnt allow for a N batteries sensor_power_battery & sensor_battery_state_of_charge. Thus cant calculate individual efficiencies etc. #963

[LesIT1]

@JoshC1994 yes, that's the one deliberately excluded piece. The identification estimator assumes a single power meter and a single SOC signal, so at N>1 it skips with a logged warning rather than fit garbage. It's called out in the PR notes under behaviour notes.

The good news is that per-battery sensor pairs actually make the problem easier, not harder. Right now a single AC-side meter can only ever identify the fleet round-trip product. If each battery has its own sensor_power_battery_<k> and sensor_battery_state_of_charge_<k>, the estimator can run per battery and learn genuinely individual capacities and efficiencies, which is more than the current single-battery feature can even do.

I'd treat it as a follow-up PR: per-battery sensor keys in the config (list pattern, same as the rest of #1032), run the existing estimator once per battery, publish per-battery identified sensors. Since you're already running a multi-battery fleet with the sensors in HA, you'd be the ideal real-world test case. Can you share what your battery sensor entities look like?

[JoshC1994]

After I posted, I thought to check the logs and noticed the warning comment
[2026-07-27 10:30:39,581] WARNING in command_line: Battery identification supports a single battery only; skipping (number_of_batteries=2).
then found where you had called it out the behaviour notes. Apologies it was late when I was writing.

I guess its not only the estimator but also the SOC starting point, it seems to tie the second battery to the first battery SOC for the optim. #585

Happy to share and take it to another Issue/PR, Is there anything your looking for exactly?
I have 3x Batteries, 1 is offline at the moment as I have some house renovations in progress.
I have also stopped control from EMHASS and havent had the time to look at getting my automations back up and running.
But happy to get this back going.

[LesIT1]

@JoshC1994 no apology needed, the notes are long.

Good news on the SOC point: that one you can fix today. soc_init accepts a per-battery list at runtime. A scalar broadcasts to every battery, and if you omit it entirely it falls back to the configured target SOC, which is uniform unless you configured per-battery values. Either of those produces exactly what your second chart shows: both forecasts starting from one shared value. Passing a list, order matching your configured battery lists, splits the starting points. One trap to avoid: soc_init is a fraction, not percent, so divide the sensor values by 100 in your template ("soc_init": [0.30, 0.19], not [30, 19]). Out-of-range values only log a warning, they don't error, so the percent form would silently give the optimizer a battery at 3000%. Same list handling applies to soc_final.

One honest caveat: that splits where the forecasts start, not necessarily how they move. Your two packs are configured identically, so the solver is free to split the plan evenly between them, and the forecast won't reproduce the asymmetric behaviour your real packs show. Getting the model to know the packs are actually different is what per-battery identification is for, which brings us back to your original point. The #585 idea of EMHASS reading measured SOC itself is a separate feature, and per-battery SOC sensors would be the enabler for it.

Your sensor layout is ideal for the identification follow-up: one signed power + one SOC sensor per battery is exactly what the estimator needs, and your overnight data already shows genuinely different behaviour per pack. Worth noting for later: each of your batteries sits behind its own GW5048D-ES, so your site is also the phase 3 shape (battery-inverter association, #870). Identification doesn't need to wait for that though.

I'll write up the follow-up as a feature issue with the proposed schema (per-battery sensor keys following the #1032 list pattern, estimator run per battery, per-battery identified sensors) and tag you on it so David can call the shape. If you can hang onto your HA history in the meantime, weeks of that divergent cycling data is the validation set this needs.