Huawei SUN2000-17K-MB0 + LUNA2000 compatibility with v1.4.0 Huawei driver?

[maic-de]

Hi,

I'm planning to migrate my Huawei setup from the Huawei Solar Integration to Omnibattery v1.4.0 using the new native Huawei SUN2000 + LUNA2000 driver.

My hardware:
Inverter: Huawei SUN2000-17K-MB0
Battery: Huawei LUNA2000, 10 kWh total
Already running: 2× Marstek Venus via Omnibattery (working great!)

The release notes mention the driver was validated on a SUN2000-8K-MAP0. My inverter is the MB0 series, which has a slightly different hardware revision.

My questions:
Is the SUN2000-17K-MB0 compatible with the Omnibattery Huawei driver?
Are there any known issues or register differences with the MB0 series compared to the MAP0?
Since the SUN2000 SDongle only allows one Modbus TCP connection, I plan to fully replace the Huawei Solar Integration with Omnibattery. Any caveats I should be aware of?

Thanks in advance!

[maic-de]

Quick follow-up on my own question — I went ahead and tested it.

The good news: the Omnibattery Huawei driver works with the SUN2000-17K-MB0. Setup completed successfully, all telemetry comes through correctly (SOC, battery power, PV production per MPPT string, AC output, temperatures).

The problem: my setup toggles between charging and discharging every few seconds when Omnibattery has active control over the LUNA2000.

The root cause is that the SUN2000-17K-MB0 has a built-in power meter (Huawei DTSU666-H) directly at the grid connection point. The inverter uses this to regulate itself autonomously and in real time (Self-Use mode). When Omnibattery sends charge/discharge commands via Modbus at the same time, both controllers fight each other — resulting in rapid toggling.

My current workaround: I enabled "Manual Battery Control" in Omnibattery for the Huawei entry, which stops Omnibattery from sending commands. The LUNA2000 then self-regulates again without toggling. I also reverted to the Huawei Solar Integration for telemetry, as it provides more detail.

My question for the community / @sphings79: Does it make sense to include a Huawei system with a built-in power meter in Omnibattery at all? What would be the actual benefit compared to just leaving the Huawei to self-regulate and only controlling the Marstek batteries via Omnibattery?

My current setup that works stably:
Huawei LUNA2000 (10 kWh): self-regulates via its own power meter, monitored via Huawei Solar Integration
2× Marstek Venus (5.12 kWh each): fully controlled by Omnibattery
Two HA automations coordinate discharge priority between the two systems (Huawei first, Marstek as fallback)

Thanks for any insight!

[sphings79]

That settles it, and the answer is duller than my theory — thank you for the daylight detail, that was the key piece.

Your numbers add up exactly: 1200 W of PV plus 2000 W out of the battery minus 500 W of house is 2700 W, which is the export you saw. So that was a real forcible discharge — a command from Omnibattery, not the inverter doing something of its own. And the driver's 20 s write throttle is why it cycled "several times" rather than continuously.

The cause is the version, not your meter. You are on v1.4.0, and the Huawei driver in that release has no daylight gate at all — there is no refusal path in it. It will send the hybrid a forcible command in full sun, and a forcible command on a DC hybrid is a ceiling on production, so it fights the inverter's own regulation exactly as you describe.

That was fixed in #381 ("release instead of commanding while the strings are lit"), which merged after 1.4.0 went out and ships in 1.5.0 — currently available only as the v1.5.0b2 pre-release. 1.5.0 also carries #335, which refuses a discharge into a surplus in the first place. Between them, your morning should not happen.

So please drop my 47087 theory for this symptom. It described a night-time grid charge, and what you saw was daylight. It may still be worth checking on your installation for a different reason — see below.

What I would do now: either stay on Manual Battery Control until 1.5.0 is released, or move to v1.5.0b2 (HACS shows it once beta versions are enabled) and hand control back. That is a pre-release, so it is your call whether you want it on a working system.

If you do test tomorrow morning, your list is right — add the PV string voltage. What you should see with 1.5.0b2 is the driver sending nothing but releases while the sun is up: 47100 sitting at 0, no forcible command standing, and the inverter regulating on its own the way it did before you added it.

The driver says so in the log as well. On a lit day you should see, at INFO:

Huawei driver: releasing instead of commanding <n>W — a forcible command caps
this inverter's own production while the sun is on the panels

and, every couple of minutes, Huawei driver: releasing briefly to re-read the roof. Those two lines are the gate working. If the oscillation comes back on 1.5.0b2 and neither line appears, the gate is not engaging on your hardware and that is a genuine bug — most likely in how it reads your strings, since the thresholds behind it (100 V, 150 W) were measured on a single ~374 V array and a smaller string can legitimately sit below them.

In that case, two things would let me find it:

1. Debug logging — the "Enable debug logging" button in the Omnibattery integration settings. Turn it on before sunrise, leave it through the oscillation, turn it off again; Home Assistant then hands you the log file.
2. Download diagnostics for the Omnibattery config entry (Settings → Devices & Services → Omnibattery → ⋯ → Download diagnostics). It carries the driver capabilities and connection health, with identifiers redacted.

Together with the register values you already listed, that is everything needed — no guessing required.

The question that is still open for your installation is the night. Yours has no energy manager, so grid charging is governed by register 47087 on the inverter itself, and the driver never writes it. If a night-time charge window clamps to 0 or oscillates on 1.5.0, that is where to look — and that would be a real gap for every Huawei installation without an EMMA, which is most of them.

[maic-de]

Thank you for all the information.I will wait for version 1.5.0.
In the meantime I will set my Huawei battery to Manual Battery Control — that stops the toggling.

[maic-de]

One more question:Is it possible to prioritise the batteries in Omnibattery?The background is that the Huawei battery has a higher efficiency due to fewer conversion losses compared to the Marstek batteries.

[sphings79]

Sensible call, and Manual Battery Control is the right place to park it until then.

Yes — in 1.5.0. Not in 1.4.0, where there is no priority control at all. The ordering module that makes it possible does not exist in that release.

1.5.0 adds two selects, and they are separate because charging and discharging are separate decisions:

• Charge priority — which battery is filled first.
• Primary battery — which battery serves the house first. Discharge normally goes to the fullest battery; nominating a primary puts that one ahead of the ladder.

But for your case you will probably not need to set either. Left on automatic, the charge order already follows your reasoning: with enough sun to fill everything, the battery needing the most hours goes first; on a thin day, the one that loses the least to conversion — which is your DC-coupled Huawei. Your efficiency argument is not just accepted, it is the rule. It is worth roughly 10 % on the kilowatt-hours that go in without an AC conversion, which is close to your own estimate.

The Charge priority entity also shows its work in its attributes: order is the order in force, hours_to_full per battery, and thin_solar_day is the verdict that decided which rule applied. Worth a look before overriding anything — you can see what it chose and why.

One caveat on the discharge side, specific to a DC hybrid. While the strings are lit the driver refuses a discharge from the Huawei and reports a discharge ceiling of 0 to the allocator, so the share moves to a Marstek. Nominating the Huawei as primary battery therefore only takes effect after dark. In daylight, Charge priority is the one that does anything — and that is the side your efficiency argument applies to anyway.

[maic-de]

This morning I encountered the following problem:

The Huawei storage system was empty at around 4:15 a.m. (at 12%, as configured in the OmniBattery settings).

Suddenly, the Huawei battery power reading showed more than 2,100,000 watts of charging power.
At 7:11 a.m., the Huawei SOC showed more than 6,500%.

How can these values occur?

Because of these unusual readings, the Marstek storage units did not discharge, resulting in approximately two hours of power being drawn from the grid.

One additional note: I can only set the minimum SOC for the Huawei storage system to 12%. However, Huawei’s default minimum value is 5%.

[sphings79]

Thanks — that is two distinct bugs in one report, and the first one has a data-loss consequence. Both reproduce on my side, so neither needs guesswork. I have filed them: #494 and #495.

The values are not readings. They are Huawei's "value not available" markers.

The live block is decoded like this (drivers/huawei.py):

_BLOCK_LIVE = (37000, 5, "high", {
    "inverter_state":  (0, "u16", 1),
    "battery_power":   (1, "i32", 1),
    "battery_voltage": (3, "u16", 0.1),
    "battery_soc":     (4, "u16", 0.1),
})

SOC is an unsigned 16-bit register scaled by 0.1. Huawei's invalid marker for u16 is 0xFFFF = 65535, and 65535 × 0.1 = 6553.5 %. That is your "more than 6,500%", to the decimal.

battery_power is signed 32-bit, where the same marker is 0x7FFFFFFF = 2,147,483,647. Read off a kW axis that is ~2.15 million, which would match your figure — but unlike the SOC I cannot derive it exactly from what you posted. If you still have the history, the precise peak would settle it.

Why they reach the control layer. The decode loop only discards a block that fails to read:

regs = await self._client.async_read_holding_block(start, count)
if regs is None:
    continue          # keys omitted — correct

A block that reads successfully and contains the marker is published verbatim. Downstream, the coordinator's only plausibility check is is_untrusted_energy_reading, and it is gated on state_class == "total_increasing" — energy counters. battery_soc and battery_power are measurement, so nothing looks at them. There is no upper bound on SOC anywhere between the register and the allocator.

Worth noting that the guard already exists in the codebase, just on the other brand's path — control/pack_soc.py filters per-pack SOC with 0 <= value <= 100 and the comment "an out-of-range reading here would move a charge or discharge limit". That is exactly what happened to you, one driver over.

That is also why your Marstek units sat idle. A SOC of 6553 % puts the Huawei far above every floor and cutoff, and a battery power of 2.1 GW poisons the derived house-consumption balance, which is computed from battery power, grid and solar. The allocator had no usable picture of the fleet for those two hours. The grid import was the consequence, not a second fault.

One thing you should know before you upgrade: this is not fixed in 1.5.0. I checked against release/v1.5.0, not 1.4.0 — the code above is current. The daylight gate you are waiting for solves the toggling; it does nothing for this. So the upgrade is still worth doing for the other problem, but do not expect it to cover this one.

On the 12 % minimum — you are right, and it is a Marstek limit leaking into your Huawei.

The entity comes from a class written for Marstek batteries that have no hardware cutoff registers (number.py):

class MarstekSoftSocLimitNumber(CoordinatorEntity, NumberEntity):
    """Software-enforced SOC limit for batteries that don't expose hardware
    cutoff registers (v3/vA/vD)."""
    ...
    self._attr_native_min_value = 12

12 % is the Venus D's hardware floor. On my own installation the contradiction is visible directly: the Huawei's discharge cutoff entity reads 5.0, taken from the inverter, while its slider will not go below 12 — the displayed value is below the minimum the control offers.

Looking into it turned up something wider that affects you too. The Huawei driver declares its own register ranges:

_CHARGE_CUTOFF_RANGE    = (90.0, 100.0)   # register 47081
_DISCHARGE_CUTOFF_RANGE = (0.0, 20.0)     # register 47082

	entity offers	driver accepts	usable
discharge cutoff	12 – 50 %	0 – 20 %	12 – 20 %
charge cutoff	50 – 100 %	90 – 100 %	90 – 100 %

Outside the driver's range the write is skipped, not clamped, and only logged at debug level. So if you ever set the discharge cutoff above 20 %, or the charge cutoff below 90 %, the entity shows your new value while the hardware backstop never moves — silently. Worth knowing before you go looking for a setting that appears to have no effect.

Do we need anything more from you? No. Both fixes are determined by the code, and I would rather not have you chasing a 4 a.m. event again. One thing would still be useful if it is no trouble: the exact peak values rather than the rounded ones. If SOC tops out at precisely 6553.5, that closes the last gap between inference and proof — and it would tell us whether the trigger is the battery sleeping at its cutoff overnight, which decides whether dropping the value is enough or whether the driver should also report the battery as temporarily unavailable. That is a refinement, not a blocker.

I will put up a pull request for both.

[maic-de]

Yes, the SOC value was exactly 6,553.5% for me.

[maic-de]

When will version 1.5.0 be released?

[sphings79]

Thanks — exactly 6553.5 closes it. 0xFFFF × 0.1 to the decimal, so there is no scaling, sign or offset theory left to consider: that is Huawei's "value not available" marker reaching the control layer verbatim. Both pull requests are up, #496 for the markers and #497 for the cutoff range.

One thing your own report answers, which I missed when I wrote the last one. You switched the Huawei to Manual Battery Control on the 17th, and the event happened on the 20th — so it happened with the workaround active. Manual control stops the driver writing to the inverter, but it does not stop the readings entering the fleet: the derived house-consumption balance has no control-mode filter, and the SOC is still read by every floor and cutoff. So those two hours were not something you could have prevented by parking it, and there is no setting that would have. I have recorded that on #494.

Would v1.5.0b2 help you? For one of your two problems, yes.

	in v1.5.0b2
Morning toggling (the daylight gate, #381)	fixed
Charge priority / Primary battery selects (#335)	present — the answer to your efficiency question
The surplus bound, so a charge command cannot exceed the real uncovered surplus (#335)	present
Invalid-value markers (#494)	not fixed — #496 is open, not merged
The 12 % minimum on the Huawei cutoff (#495)	not fixed — #497 is open, not merged

What matters for your decision is the comparison with where you are now, not with a perfect version. The 4 a.m. marker bug is in 1.4.0 too, and as we just established your workaround does not shield you from it. So b2 does not add that risk — it simply does not remove it yet. What it does remove is the reason you had to switch the workaround on in the first place, and it gives you the charge ordering you asked about.

On that basis I would say b2 is worth it for you, with two caveats:

• It is a pre-release on a working system. That call stays yours.
• b2 was tagged on 13 September and release/v1.5.0 has moved 11 commits since. One of them may matter to you: fix: judge grid-meter liveness on the meter's own clock #480 fixes a false "dead grid meter" alarm on meters that report very frequently — and you are reading yours optically. Not control-affecting, but you might see the notification on b2.

Installing it through HACS

1. HACS → Omnibattery → three-dot menu → Redownload.
2. In the dialog, expand "Need a different version?".
3. Pick v1.5.0b2 from the Release list — pre-releases are listed there and marked as such, so no beta setting is needed for this.
4. Download, then restart Home Assistant.

If the release list looks stale, use Update information on the same menu first — that re-reads it from GitHub.

Two things worth knowing. HACS advises against using that same dropdown to go back and says to restore a backup instead, so take one before you upgrade. (For what it is worth, the config entry schema is version 12 in both releases, so nothing migrates in either direction; the two new selects would simply stop appearing.) And this pins the one version only: if you want HACS to offer you the next beta as an update, enable the Pre-release switch it creates for the Omnibattery repository — a diagnostic entity, disabled by default.

After the restart, hand control back to the Huawei and watch the log on the first lit morning. The two lines I quoted earlier — releasing instead of commanding <n>W and releasing briefly to re-read the roof — are the gate doing its job. If the oscillation returns and neither line appears, that is a genuine bug on your hardware, and the debug log plus diagnostics would let me find it.

On the release date: I cannot give you one, and I would rather say so than invent a week. I am not the maintainer of this integration — that is @ffunes. I contribute the driver work; release timing is not mine to decide. What I can tell you is the state of the branch: b2 is from 13 September, release/v1.5.0 is 11 commits ahead of it, and seven pull requests are still open against it, including #496 and #497 — the two fixes for your reports. Read that how you like, but another beta before the final looks more likely than the final landing next.

[maic-de]

Thank you very much for your detailed and candid response.

I’ll stay on version 1.4.0 and wait for the final new release.

For now, I’m working around the issue by setting the Marstek batteries to manual mode with a fixed discharge value. Huawei then takes care of the rest.
This way, none of the batteries is empty in the morning.

That worked well last night.