[Custom Integration] Marstek Venus Energy Manager

[timseebeck]

Below all my entries that contain soc:

number.marstek_venus_a_cargar_hasta_soc 85
number.marstek_venus_a_soc_maximo_de_carga 90.0
number.marstek_venus_a_soc_minimo_de_descarga 12.0
number.marstek_venus_system_reduccion_de_picos_umbral_soc 30.0
sensor.marstek_venus_a_soc_de_la_bateria 58
sensor.marstek_venus_system_red_al_min_soc 0.0
sensor.marstek_venus_system_soc_del_sistema 58.0

EDIT
Just in case these notifications are relevant...

And here you can see that at 14:00 the electricity price was already very low:

[voordeh (Johannes Adriaan van de Voorde)]

Hi,
Thank you for the awsome work, great documentation also.
I have 3 Marstek venus e3 with the RS485 dongle of CBT Systems (https://cbt-solutions.fr/produit/marstek-venus-e-3-0-module-domotique-home-assistant-rs485-esphome-sans-cloud/) Do you know if i would be able to use these? Or do I have to re-flash them?

[ffunes (Funes)]

ESPHome is currently not supported sorry. I am using an Elfin EW11A with my v3 battery just fine by the way.

[ffunes (Funes)]

Hi,

This will be added in the next release of Omnibattery: - LilyGo RS485 / ESPHome driver: support for Marstek batteries bridged by the marstek-lilygo-rs485 firmware — telemetry and control go through the ESPHome device's HA entities (the battery's RS485 port is occupied by the ESP32). New brand in the config flow; same register semantics as the direct Modbus driver. drivers/esphome.py.

I am pushing a new beta today in omnibattery repo (GitHub - ffunes/Omnibattery: Custom integration to monitor and control Marstek Venus and Zendure batteries in Home Assistant. · GitHub), however I am going on holidays, so if this doesn't work on the first try, you will need to wait a week before I can do any changes.

[rscheurw1973]

@ffunes

When i first installed the 2.04B pre-release version of MVEM the batteries where charged everytime to 100% with enough unused solar power.

Since i have upgraded to the latest version 2.0.6 i have noticed that on some day's not alle batterijes are charged till 100%, mostly there is one battery charged till 94% and the others till 100%. For example on battery was at 94% and there still a lot of solar power available and was exporting to the grid.

I have checked in HA about the flow and have included a graph.

I found it strange that the charging is not always evenly done. What can be the cause of this issue ?

Then i saw in the blog that you have introduced the omnibattery integration, what is the difference with the MVEM integration just for my curiosity

[rscheurw1973]

I have solved this. I made a timeslot from 00:00:00 till 23:59:59 for discharging at 2000W. This will created a switch entity. In a seperate automation, when the prices between lowest and highest price is >= 0.40 cent i dump my energy until the soc level reached at 35%. This in my case a best threshold d on my needs from evening until the morning. When the expensive hour is reaching i just enable the timeslot swith entity and it will discharge until the SOC limit is reached. Then i will switch off the entity and normal operation is continued.

I hope this will help you

[rscheurw1973]

@ffunes , i was checking today and saw that charging is no longer continued. The status is Battery limited and the batteries are unevenly charged.

Just restarted the integration, changed max charge speed to 2000W and now the batteries are charging only with 96W, and there is now 3.3Kwh solar power available

After putting the MVEM to manual mode and enabled in the marstek app the mode to self consumption, the status went all to 100%. It seems to be something in reading the correct data from the marstek batteries about the current state.

[Enno24 (Enrico)]

Hallöchen,

Wie wird eigentlich der aktiven Zellenabgleich geregelt

[peletonduwer]

Hi, You can use this to connect with modbus. Connect the TP link AC750 to the battery (lan port) and put the TP link in to the wifi network.

[Frankie-deV (Frank de Vries)]

@ffunes,

I have the exact same problem with my Venus D! I have 4 packs. If i use the Marstek app and manually charge for a while, all 4 packs reach 100% and are balanced.

If i stop the manual profile and let Omnibattery do the charging i reach max 92% SOC. If i check the 4 packs, top pack is 100% and the packs below are somewhere arround 89%. Battery status is “Battery Limited”. All Solar panel power goes into the grid and does not charge the rest of the battery! During a few days the Balance of the battery is getting worse.

I was reading in another topic : Answer from other topic, [BUG] Soc never reaching 100%

What about unbalance in battery? And pack (from bottom to top) 1,2,3 never reach 100%? Thats where the weekly charge is for?

Added pictures of Manual 100% SOC charge with Marstek App.

[ffunes (Funes)]

Are you using voltage tapper?

[Frankie-deV (Frank de Vries)]

ffunes, thanks for your help and you amazing integration. I am new to this.
How can i check?

[ffunes (Funes)]

This integration has moved — Marstek Venus Energy Manager is now Omnibattery

New repo: GitHub - ffunes/Omnibattery: Custom integration to monitor and control Marstek Venus and Zendure batteries in Home Assistant. · GitHub
New thread: [Custom Integration] Omnibattery - One integration for pluggable solar batteries

Development continues under a new name. It’s the same integration and the same author — but
it now also drives Zendure SolarFlow (2400 AC+ / Pro) alongside Marstek, and can run
both brands in the same install, so a Marstek-only name no longer made sense.

Nothing is lost when you move. Your configuration, entity IDs (they stay
marstek_venus_*), recorder history, long-term statistics, dashboards and automations are
all preserved.

How to migrate

HACS can’t rename an integration’s domain in place, so this isn’t an in-place update — you
install the new repo and migrate across. One step matters more than the rest:

Update this integration to v2.0.6 and restart BEFORE anything else.

That release silently writes a recovery snapshot of your full configuration to
.storage, and that snapshot is what survives the domain change. If you skip it and HACS
removes the old entries, you may have to reconfigure everything from scratch.

Then:

1. HACS → Custom repositories → add https://github.com/ffunes/omnibattery
   (type: Integration) and install it. Leave the old repo in place for now.
2. Restart Home Assistant.
3. Settings → Devices & Services → Add Integration → Omnibattery. It detects your
   existing config and shows a confirmation screen — confirm to run the migration. It
   recreates your entries on the new domain, repoints every entity without changing its ID,
   and copies the stored data (daily energy totals, accumulators, balance history).
4. Once Omnibattery is running, remove the old integration and repository from HACS.
5. Ctrl+F5 so the renamed sidebar panel loads.

Take a full HA backup first (Settings → System → Backups). And if you already deleted
the old integration: the snapshot from step 0 still survives — the setup flow will find it
and offer to restore from it.

Support moves too

The old repo is now archived / read-only for issues. From here on:

Issues · ffunes/Omnibattery · GitHub

Please don’t post bugs in this thread (or the new one) — forum threads have no tracking, no
state and no way to tell an open bug from a fixed one, so reports posted here get buried and
lost. A GitHub issue gets labelled, linked to its fix, and closed where the next person can
find it. Attach diagnostics + debug logs and I’ll actually see it.

Thanks to everyone who tested, reported and contributed here. See you in the new thread.

[Frankie-deV (Frank de Vries)]

Do you want me to put the post here?

ffunes Omnibattery · Discussions

Or here,

Issues · ffunes/Omnibattery

[ffunes (Funes)]

The sensor should be called something like: switch.marstek_venus_1_full_charge_voltage_taper

If that is on, the system will prevent the battery from reaching dangerous voltages (3.6XV) and stop the charge when the max cell voltage reaches 3.58V, however, this will cause that the Marstek BMS won’t report 100% SOC, since the BMS needs to “see” a 3.64V to declare a 100% SOC.

So prevent this from happening too often, in Omnibattery, if the reported SOC is less than 99% the system will allow the charge to continue until the BMS stops the charge, so the SOC can recalibrate.

[ffunes (Funes)]

Please test with Omnibattery first. If the issue persist after running a full charge cycle then open an issue.

[Frankie-deV (Frank de Vries)]

Yes, it’s on. So this means it’s intended to work this way?

[Frankie-deV (Frank de Vries)]

@ffunes

If that is on, the system will prevent the battery from reaching dangerous voltages (3.6XV) and stop the charge when the max cell voltage reaches 3.58V, however, this will cause that the Marstek BMS won’t report 100% SOC, since the BMS needs to “see” a 3.64V to declare a 100% SOC.

This i understand i think. It’s a safety messure for the batteries.

@ffunes

So prevent this from happening too often, in Omnibattery, if the reported SOC is less than 99% the system will allow the charge to continue until the BMS stops the charge, so the SOC can recalibrate.

This i do not understand? At my batteries the BMS stops the charge for safety because tapering is on. But what happens next i do not understand You say SOC can recalibrate, what does that mean? Now every day the BMS stops the charging and goes to “Battery Limited” and does nothing and all solar power goes into the grid. And the batteries get completely out of Balance.

[ffunes (Funes)]

Are you using Omnibattery or the Marstek Venus Energy Manager? If you’re still on the latter, I don’t think that behavior will show up yet. I can’t quite remember when it was introduced—there have been way too many versions and commits!

[Frankie-deV (Frank de Vries)]

I made a bug rapport here:

[BUG] SOC never reach 100%, always stuck 92% ; "Battery Limited" and Solar PWR goed to Grid

I use Omnibattery, i migrated 2 weeks ago if i am correct. Migration worked fine, i only had to restore a number of entity id’s afterwards.