[HELP] Strange charge behehauvure, not charging at lowest rates

[Maumau82]

What do you need help with?

Automations or energy management

What are you trying to do?

Charge at lowest price

What is happening instead?

I charges in periods, starting at high prices. can charge to 100% before prices are low.

Your setup

Omnibattery version: 1.5.02b
Home Assistant version: 2026.9.0
Battery brand and exact model: Anker Solix E5000 4 pro + 7x Zendure Solar Flow 800 plus
Battery firmware version: na
Connection method or adapter: Anker Gen 2 CT meter, rest via wifi or LAN

What have you already tried?

... manually, pressing calculate many times.
Perhaps it has something to do that Omnibattery only has the Anker 10kWh in the main overview, even though I have 22kWh?
Or would someone have another idea?

config_entry-omnibattery-01M0J55M1DMPY342P5NSMDTN1N (1).json

Relevant logs or screenshots

No response

Confirmations

• I searched the documentation and existing discussions first.
• I removed passwords, tokens, API keys, complete serial numbers, and other sensitive information.
• I understand that this is community support and a response is not guaranteed or immediate.

[Maumau82]

config_entry-omnibattery-01M0J55M1DMPY342P5NSMDTN1N (2).json

Fixed that Omnibattery shows the correct kWh.
During the initial installation, Omnibattery recognizes the Anker Solix E5000 capacity, but not the Zendure Solar Flow 800 plus capacities.
Overlooked to add manually (perhaps to make a mandatory field to fill in)??

Still only the charging period is very strange. It wants only to have 30min to charge 10kWh. (i have 9kW of charging power, but still not enough) :) I use Tibber as operatior / sensor ... the price trigger seems to be working fine (message avoiding discharge in at the rate i set).

... Am i the only one where Omnibattery charges at very strange moments?

[ffunes]

Hi @Maumau82, thanks for the detailed screenshots.

Capacity: good catch. Since 1.5.0b1 the Zendure capacity field is mandatory in the setup flow. Your entry was created before that, which is why it stayed at 0.

Why it doesn't charge at the cheapest hours: in Dynamic Pricing mode, predictive charging only buys the deficit, meaning the energy your batteries are missing to cover the forecast consumption. It is not an arbitrage optimizer. In your screenshot from the 18th you had 12.7 kWh stored and roughly 8 kWh of forecast consumption left. With no deficit, it doesn't charge, even at 12.9 ct. The only other grid charging it does is opportunistic charging at negative prices.

"Fill up at the cheapest hours to cover the expensive ones" is a feature request, and it's already tracked in #435. Please add your 👍 there, because votes set the priority.

If you want more grid charging in the meantime, raise Safety margin (it enlarges the deficit) or the predictive min SOC with the SOC floor switched on. That makes it buy more at the cheapest slots it picks, though it's still not real arbitrage.

Two things to check:

1. Your second diagnostics file reports version 1.4.0, not 1.5.0b2. Can you check Settings → Integrations and update if needed?
2. The striped purple/blue intervals overnight mean a battery was charging and another was discharging within the same 15 minutes. You have no solar sensor configured, so any charge gets labelled "grid". Your minimum charge power is 420 W, so every small export turns into a 420 W charge pulse. Try lowering it (for example to 100 W) and tell me whether the stripes go away.

[Maumau82]

config_entry-omnibattery-01M0J55M1DMPY342P5NSMDTN1N (3).json

Version 1.5.0b2

config_entry-omnibattery-01M0J55M1DMPY342P5NSMDTN1N (4).json

Version 1.5.0b1

Thank you for the clear explanation—that helps a lot!
I've applied the tweaks you suggested. I performed a manual full charge, but I'll leave the settings as they are for now to monitor how it performs.

Regarding the version, I reverted from 1.5.0b2 to 1.4.0. With the latest beta, Omnibattery no longer covers the usage and only allows for a very limited discharge capacity.
It was working fine in version 1.5.0b1, but this seems to be broken in b2.

I have attached both JSON files for your reference. Even though they only cover a few minutes of usage, I can immediately see the difference in behavior.

[Maumau82]

Edit; also V 1.5.0b1 does show no discharge ... but when i look into my P1 meter on my phone, it does discharge.
The main view only shows the discharge rate of my first inital Anker battery, not the Zendure batteries.

So probably also Omnibattery does not see the Sensor of the Zendure batteries how they are discharging. (thought it did in V1.4 ... but will check.

[Maumau82]

But i was thinking ... If the energy rate is at €0,00 (excl taxes) on a day ... It would be perfect if the battery would full up to 100% (regular during weekends). Even though you would not need it all.
The next day (Monday), the prices are likely to be much higher.

... Is it possible to have it setup, to fully charge (estimated) when prices are below a certain amount .(Including expected sun, if any ( not much in the winter at least).

[Maumau82]

config_entry-omnibattery-01M0J55M1DMPY342P5NSMDTN1N (5).json

Hmmm, it is not charging ... perhaps try a fresh re-install? Or clearing is cache or something?

(I sometimes charge while the Anker Gen 2 CT kWh meter does not register data.
This because I have 2 meters (PAP and SAP) where i can switch between te meters.
When dynamic prices are high all day, i sometimes switch from dynamic to fixed, charging batteries manually. Then the Anker Gen 2 CT kWh meter sees no kWh movement). ... perhaps this would totally f*ck up Omnibattery smart planning? (so clearing cache would be needed or something)?

[ffunes]

There are three separate things in this thread, so let me split them.

1. Charging to full when the price is very low / zero — this is by design, not a bug.

The dynamic-pricing planner only buys the forecast deficit: the energy it predicts you'll need and that solar won't cover. When there's no deficit, it still builds a schedule, but only as an informational one — it won't charge.

The one exception is the opt-in "Enable negative-price opportunistic charging", which does fill up to your max SOC regardless of forecast. But it requires a strictly negative import price (price < 0.0, pricing/engine.py:1111), so a slot at exactly 0.00 does not trigger it. And "Maximum price threshold" only filters charging that is already needed by the deficit — it never creates charging on its own.

So "charge to max whenever the price is under X, to use it tomorrow" is a feature request, not a malfunction. It's the arbitrage case tracked in #435 — I'd rather design it once there than bolt it on here. If you want to push it forward, the open questions are: is the threshold on the final taxed price or the raw one, what SOC do you target, and how should it back off when the solar forecast already covers tomorrow?

2. Zendure capacity showing 0 — already fixed, but your entry is from before the fix.

The current setup flow requires battery_capacity_kwh for Zendure devices, and the coordinator publishes it as battery_total_energy so SOC and the planner can use it. Your entry predates that, so the field is empty.

Please reconfigure each Zendure and enter its nominal capacity, then confirm System Total Energy and System SOC show your real ~22 kWh. That matters before judging anything about the price plan: with capacity at 0 the deficit calculation is meaningless, which alone could explain "it never charges".

3. Zendure discharge not showing on the main view — I need data.

The underlying cause here was fixed in 1.5.0b2 (c144e7c, #453): the driver now derives the AC exchange from gridInputPower - outputHomePower and the aggregate prefers that over raw cell power. If you're still seeing the discrepancy on the current version, could you attach:

• the integration diagnostics download, and
• 15-30 min of history covering a discharge the panel doesn't reflect: System Discharge Power, the per-Zendure power, SOC, and your P1 meter reading.

With that I can compare gridInputPower vs outputHomePower and tell whether the SolarFlow 800 Plus reports them differently from the models already covered.

[Maumau82]

config_entry-omnibattery-01M0J55M1DMPY342P5NSMDTN1N (7).json

Hi find above the json with debug enabled.
Thank you very much for your time / help!

[Maumau82]

config_entry-omnibattery-01M3CJMQN6NWBP556QRP66ZWM5.json

Hi! FYI; i did a complete uninstall and fresh re-instsall of the latest beta. But this does not matter.

Also when i put off the PD controller, direct tracking. then the batteries do absolutly nothing.
On the 1.5.0b1 everything worked fine, but since 1.5.0b2 it does not anymore.

... what has changed in b2? This seems to mess things up.
will do a clean install for 1.5.0b1 in the meantime!

[ffunes]

Hi,

I need you to provide the debug from 1.5.0b4, what you have shared is the configuration json, which is not what I was asking, based on the file, your batteries are not delivering power and are being excluded from the pool but I can't see what is excluding them from the pool.

If it is really working for you in b1, I would need the debug and json file from this version too.

Best regards

[Maumau82]

config_entry-omnibattery-01M3CQKRYZTBE9B1A148F3ZEKQ.json

Hi, super thanks for your good help!

Ah sorry yes, i tought it was the JSON. I have a debug file for 1.5.0b1. It was 355mb large so uploaded it to my google drive!
https://drive.google.com/drive/folders/1L51XqKCywiL2ibJuhWxEmA1W_weriGy4?usp=sharing

I will now update to 1.5.0b4, and will provide the file tomorrow again!

[Maumau82]

config_entry-omnibattery-01M3CQKRYZTBE9B1A148F3ZEKQ (1).json

Hi! I uploaded the 1.5.0b4 config and debug file to my google drive!
https://drive.google.com/drive/folders/1L51XqKCywiL2ibJuhWxEmA1W_weriGy4?usp=sharing

I did not use the 1.5.0b4 that long as it as good as not decharges.

If you need something more or test please let me know!

[ffunes]

Thanks for the b4 debug log, it shows the cause.

Since b2 the integration reads the Anker's register 10012 as "power this battery is delivering or taking at its AC port". In your log it reads +1550 W while the E5000's pack and PV are both at 0. That's grid power passing through the Anker to loads behind it, not the battery charging. The integration took it as a 1550 W charge and decided most of the house load "wasn't the house's", so it capped the fleet discharge:

Discharge ceiling: trimming 819W to 411W -- the rest is not the house's load
grid=1879.0W

That's why you saw low or bursty discharge from b2 onward. b1 didn't use that register.

Fixed for the next beta: the Anker's AC contribution is now worked out from battery power minus PV, so grid passing through the unit is ignored.

Quick question to confirm: do you have loads connected to the E5000's AC output / backup port?

[Maumau82]

Hi, no i disabled the AC backup output.
This to try to lower power usage while idle.
(Anker standby (Internal) power consumption is a bit higher then other brands).

But super that you have found something, great!!

[ffunes]

Thanks, that narrows it down: with the backup output off, 10012 isn't passthrough. It's most likely your Anker CT meter's grid reading, which the integration took for the E5000's own AC power. Same fix either way: the Anker's contribution now comes from battery minus PV, so the CT reading no longer counts.

[Maumau82]

The new beta seems to be working very well! Thanks!!