# Mixed Cluster between AC-only and hybrid ESS

**URL:** <https://community.openems.io/t/mixed-cluster-between-ac-only-and-hybrid-ess/10889>\
**Category:** English Forum\
**Created:** [June 30, 2026, 9:29am UTC](https://community.openems.io/t/mixed-cluster-between-ac-only-and-hybrid-ess/10889 "2026-06-30T09:29:46Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![klinki](https://community.openems.io/letter_avatar_proxy/v4/letter/k/858c86/32.png) [@klinki](https://community.openems.io/u/klinki)\
**Post date:** [June 30, 2026, 9:29am UTC](https://community.openems.io/t/mixed-cluster-between-ac-only-and-hybrid-ess/10889/1 "2026-06-30T09:29:47Z")

</div>

We are testing an ESS Cluster consisting of

- one HybridEss (SolarEdge)

- one AC-coupled battery ESS

The HybridEss follows the same semantics as GoodWe:

- ACTIVE\_POWER = AC hybrid power (PV + battery)

- DC\_DISCHARGE\_POWER = battery power

- applyPower() expects an AC setpoint

The ESS Cluster / PowerDistribution solver appears to operate only on ManagedSymmetricEss semantics and does not seem to distinguish HybridEss from regular ESS.

As a consequence, ACTIVE\_POWER has different meanings inside the same cluster:

- HybridEss → PV + battery

- AC-coupled ESS → battery only

This can lead to situations where one ESS charges while the other discharges.

Is the intended OpenEMS architecture:

1. HybridEss should not be combined with AC-coupled ESS in a standard Ess.Cluster?

2. HybridEss should expose battery power on ACTIVE\_POWER when used in a cluster?

3. PowerDistribution should become HybridEss-aware and use DC\_DISCHARGE\_POWER internally?

Has anybody already solved this use case?

regards,  
Klinki

---

<div class="post-metadata">

**Author:** ![MrT](https://community.openems.io/user_avatar/community.openems.io/mrt/32/1617_2.png) [@MrT](https://community.openems.io/u/MrT)\
**Post date:** [July 1, 2026, 9:06pm UTC](https://community.openems.io/t/mixed-cluster-between-ac-only-and-hybrid-ess/10889/2 "2026-07-01T21:06:52Z")

</div>

Hi Klinki,

I developed a **PreferDcPower** optimizer that is specifically designed for HybridEss systems and also supports **a mixed ESS-Cluster** consisting of both HybridEss and AC-coupled ESS.

You might find the discussion and implementation useful for your use case:

- Forum discussion: [Neuer Optimizer/Logik für mehrere Hybrid ESSes - #54 by MrT](https://community.openems.io/t/neuer-optimizer-logik-fur-mehrere-hybrid-esses/10138/54)
- PR: [PreferDcPowerOptimizer for improved multi-ESS hybrid coordination by timo-schlegel · Pull Request #3661 · OpenEMS/openems · GitHub](https://github.com/OpenEMS/openems/pull/3661)

Maybe this already solves (or at least addresses) the issue you’re seeing.

---

<div class="post-metadata">

**Author:** ![klinki](https://community.openems.io/letter_avatar_proxy/v4/letter/k/858c86/32.png) [@klinki](https://community.openems.io/u/klinki)\
**Post date:** [July 29, 2026, 6:21am UTC](https://community.openems.io/t/mixed-cluster-between-ac-only-and-hybrid-ess/10889/3 "2026-07-29T06:21:51Z")

</div>

Hi MrT,  
Thanks for the information!  
Yes, I came across that thread as well. Since the combination of Cluster + OptimizedCharge + Scheduler V2 doesn’t really work properly, I also switched back to V1. So I’m going to give your module a try. In theory, it should solve my problem and allow me to finally use your SolarEdge implementation. I’ll report back.  
How far along are you with adapting it to V2?

regards,  
klinki

---

<div class="post-metadata">

**Author:** ![MrT](https://community.openems.io/user_avatar/community.openems.io/mrt/32/1617_2.png) [@MrT](https://community.openems.io/u/MrT)\
**Post date:** [August 10, 2026, 6:28pm UTC](https://community.openems.io/t/mixed-cluster-between-ac-only-and-hybrid-ess/10889/4 "2026-08-10T18:28:10Z")

</div>

Hi Klinki,

sorry for the late response.

I haven’t put any effort into migrating the implementation from V1 to V2 yet. As far as I understand, though, the migration should be fairly straightforward. My understanding is that the basic logic can remain the same, while the way the calculated values are passed to the optimizer needs to be adapted to the V2 architecture.

What I haven’t fully understood yet is how exactly V2 expects these calculated values to be provided. However, I also haven’t spent much time looking into the V2 optimizer architecture so far.

If you already have a better understanding of how the V2 optimizer architecture works and how the values need to be passed, I’d be happy to support the migration to V2.

You mentioned that you wanted to test the current implementation — did you get a chance to do so? Any feedback would be appreciated.

Best regards,  
MrT