[Custom Integration] Omnibattery - One integration for pluggable solar batteries

[ffunes (Funes)]

Omnibattery — one integration for pluggable solar batteries (Marstek, Zendure, and more)

Repo: GitHub - ffunes/Omnibattery: Custom integration to monitor and control Marstek Venus and Zendure batteries in Home Assistant. · GitHub
Docs: Omnibattery

Omnibattery is the continuation of Marstek Venus Energy Manager. Same author, same
codebase lineage, now multi-brand — so the name had to go. Everything the old integration
did, it still does; it just isn’t Marstek-only anymore.

Supported hardware

• Marstek Venus E (v2/v3), Venus C, Venus D, Venus A — Modbus TCP, Modbus RTU/serial,
  or via the LilyGo RS485 / ESPHome bridge
• Zendure SolarFlow 2400 AC+ / 2400 Pro — local HTTP API, no cloud

You can mix brands in the same install and they share one control loop, one dashboard
and one set of sensors.

What it does

• Zero import/export PD controller — keeps grid exchange near zero. One-click tuning
  profiles (very smooth → very aggressive) plus a control-quality sensor that tells you if
  it’s stable, oscillating or sluggish, so you don’t have to hand-tune gains.
• Integrated dashboard — its own sidebar panel: all controls, graphs and a power-flow
  diagram. No YAML, no card hunting.
• Multi-battery — up to 6, with SOC-based priority and load sharing.
• Predictive grid charging — charges from the grid only when tomorrow’s forecast +
  current SOC won’t cover your consumption. Fixed slots, dynamic pricing, or real-time
  pricing (Nordpool, Tibber via service call, and other price sensors).
• Time slots — per-battery windows with independent charge/discharge, SOC and power
  overrides, and a manual fixed-power mode.
• Peak shaving, load exclusion (mask your EV charger so the battery doesn’t chase
  it), weekly full charge for LFP balancing, solar-aware charge delay, and
  temperature-based charge derating.

Everything is local polling. No cloud for either brand.

Install

HACS → Custom repositories → https://github.com/ffunes/omnibattery (type: Integration),
install, restart.

Coming from Marstek Venus Energy Manager?

Nothing is lost. Configuration, entity IDs (they stay marstek_venus_*), recorder
history, long-term statistics, dashboards and automations all survive the move.

HACS cannot rename an integration’s domain in place, so this is a migrate-across, not an
in-place update. The important part:

Update the old integration to v2.0.6 FIRST, and restart. That release writes a
recovery snapshot of your whole configuration to .storage that survives the domain
switch. Skip it and you may have to reconfigure from scratch.

Then install Omnibattery, restart, and go to Settings → Devices & Services → Add
Integration → Omnibattery. It detects your old config and offers to migrate it — confirm,
then Ctrl+F5 to reload the panel. Full step-by-step (including recovery if you already
deleted the old integration) is in the README.

Take a Home Assistant backup before you start anyway.

Support is on GitHub, not here

Please open an issue: Issues · ffunes/Omnibattery · GitHub

I’m not being unfriendly — the forum is simply a bad support tool. Threads interleave,
posts get buried, there’s no state, no labels, no “is this fixed yet”, and I have no
reliable way to tell an open bug from one that was answered 200 posts ago. Bug reports and
feature requests posted here will get lost, and that’s worse for you than being told
where to go.

An issue gets tracked, labelled, linked to the commit that fixes it, and closed. It also
means the next person with your problem can find the answer.

• Bug? → GitHub issue, with diagnostics + debug logs attached
• Feature idea? → GitHub discussion
• “Does it support X?” / general chat → the forum is fine for that

Disclaimer: this software talks to Modbus registers on high-voltage battery systems and
is provided as-is, no warranty. Use at your own risk — see the README.

[jepperHA]

Great job ffunes! Migration worked without any issues! Best integration on HA!
Thank you and syphernl for the temperature control!

[joldrack (Sim On)]

Hi @ffunes, thanks for this excellent integration! My Marstek Venus E 3.0 works great in combination with my Solar System’s Smart Meter, and the migration to Omnibattery was seamless.

My setup:

• 10 kWp PV system with Smart Meter control
• Wallbox for EV charging (power managed by PV Smart Meter, 1.5–10 kW depending on household load and solar surplus)
• Marstek Venus E 3.0
• Goal: always prioritize EV charging over Marstek battery charging when solar surplus is available

My challenge:
I’ve experimented with Excluded Devices to achieve this, but I suspect the PD controller and the solar surplus charging logic conflict with each other. The Omnibattery PD controller doesn’t know what the maximum EV charging demand might be, so both systems try to react independently to the available solar surplus—sometimes resulting in suboptimal power distribution (e.g., battery charging 1.4 kW while wallbox charges 3.6 kW, when solar provides 5 kW total).

Questions:

1. Is there a combination of Excluded Devices + Solar Surplus settings that would solve this cleanly?
2. Or would it be better to disable Omnibattery’s “Allow Charge” setting while the EV is plugged in, leaving all solar surplus to the wallbox?
3. Other approaches welcome—what do you recommend?

Appreciate any guidance!

[ffunes (Funes)]

Hi!

Thanks for your words. I have included a new functionality in a beta version (v1.0.1b6) based on your comments.

• Dynamic power control for telemetry excluded devices: a new per-device setup option and runtime switch lets flexible loads such as self-regulating wallboxes claim changing PV surplus before battery charging. It uses the existing device power sensor, yields battery charge on startup and meaningful solar rises, holds short device pauses for five minutes, and then lets the battery absorb genuine residual export. A shared device-active / EV-charging state sensor closes the cold-start gap before measured demand appears and also serves new no-telemetry EV setups; legacy no-telemetry setups that stored their state sensor in the old device-sensor field remain fully compatible. The existing Cover Home setting is now also available in both the initial and options flows.

Would you mind testing it and see if this works in your setup?

Best regards

[ffunes (Funes)]

Version 1.1.0 is out, now with support for Anker SOLIX Solarbank Max AC and Solarbank 4 E5000 Pro via Modbus TCP!!

[Networx666]

Hi my Venus A just stops at 100%? No discharging…
Also my delta is at 230mV is this a Problem?

[tkarsk]

Great piece of work @ffunes !
I tried before 2 different API integrations and they both blew up my setup sooner or later - Battery reverted to factory settings.
Hope this will work better because of different architecture.

Before I will try to configure Omnibattery to completely manage my battery, I would like only test the monitoring functions. Is there a way to set your integration in “read-only” mode?

Thanks & regards,
Tomasz

[ffunes (Funes)]

Hi,

If you are using Marstek Venus batteries you can disable RS485 control and it will keep them in read only.

Best regards

[ffunes (Funes)]

Hello!

New version is out (1.2.0)

New batteries are supported now, the total list:

• Marstek Venus E and C (v2 and v3), Venus D and Venus A via Modbus TCP
• Zendure Solarflow 2400 AC+, 2400 AC 2400 Pro, 1600 AC+, 800 Pro, 800 Plus and 800 (Local API)
• Anker SOLIX Solarbank Max AC and Solarbank 4 E5000 Pro via Modbus TCP
• Sessy Home Battery (Looking for testers!!!)
• Hoymiles MS-A2

[ffunes (Funes)]

Hi,

Just noticed this message. As stated in the open post, if you still need assistance, please open a github issue or discussion if you are seeking for help with the integration. As you can see… messages get lost in the forum.

Best regards

[tkarsk]

Hello,
Thank you for the answer:

@ffunes

If you are using Marstek Venus batteries you can disable RS485 control and it will keep them in read only.

However I don’t know If I am using this integration in the right way.
I have configured CT002 meter also. You wrote somewhere just to ignore it. OK…
I upgraded to 1.2.0.
When I turned on the RS-485 switch today I noticed that it is flapping:

Is it normal behavior?

BR,
Tomasz

[ffunes (Funes)]

No, that is not normal. Do you have any other modbus integration installed or using the app for managing the battery?

[tkarsk]

I have Marstek app, and my battery can see CT002 meter. Shall I factory reset the battery and do not pair it with the CT002? What mode to set in the app?

[ffunes (Funes)]

Maybe I am mistaken by your message, but this integration does not use CT002. I don’t know if you have been able to add that meter to home assistant. Also, there is no mode to set in the app. This is an standalone integration, you can’t use the app and the integration at the same time.

[tkarsk]

I have another meter connected to Home Assistant.
What do you mean by “use the app” - if I run the app from time to time to check something, but do not change any setting is it ok, or it collides with your integration?

[ffunes (Funes)]

That is fine. But if you make any adjustment in the app, the RS485 switch will be turned off.

[tkarsk]

Hmmm, this sounds good, but unfortunately the integration does not behave this way.

I exited Marstek app to be sure it is not working in background.

I went to settings → apps and forced the app to stop.

Disabled the integration and reenabled it.

Pls see the log of the RS485 switch:

Last action was manual. Unavailable was when the integration was disabled.

[Braat (R)]

Hi everyone,

I’m using an Anker Solix Max AC with Omnibattery in Home Assistant.

I would like the battery to export to the grid at its maximum discharge power during the most expensive electricity price hours. However, I’m not sure which setting in Omnibattery controls the maximum grid export power.

My questions are:

Which Omnibattery setting determines the maximum power exported to the grid?

Is it possible to configure the battery to always discharge at its maximum AC power?

Is there a specific operating mode or automation required for this?

Does anyone with an Anker Solix Max AC have this working and could share their configuration?

Any advice or examples would be greatly appreciated.
Thank you!

[voordeh (Johannes Adriaan van de Voorde)]

Super integration thank you for this. Do you have any plans to extend this to car chargers (both just charging and 2 way battery use) ? would be great.

[joldrack (Sim On)]

Hi @ffunes,

Thanks for the quick response and the beta implementation! I’ve tested “Device has dynamic power control” over the past few days. Here’s my feedback:

Setup:
I created a binary sensor helper for the wallbox (set to off when offline or when EV battery is fully charged). The original wallbox status sensor didn’t work well—it has ~7 different states, and the integration couldn’t reliably map all of them.

Observation 1 – Stable solar, single-phase charging:
With stable solar output (~3.7 kW), the wallbox charges single-phase and should have priority over battery charging. However, I notice the battery still charges slightly during this time, taking a small portion of available surplus that the wallbox could use. The wallbox’s single-phase max capacity is 3.6 kW, so ideally all surplus should go there first.

Observation 2 – Fluctuating solar, phase-switching:
When clouds pass and solar output fluctuates, the wallbox takes 3–4 minutes to switch from single-phase to three-phase charging. During these short windows, should the battery attempt to charge the surplus, or would it be better to have a longer “hold” period to wait for the wallbox to complete its phase-switch? Currently, the rapid switching causes some minor inefficiency.

Overall: The feature works well and is much better than before. I hope this feedback might also help other users optimize their setups.

Thanks again!