[Feature] Battery calibration time and voltage warning

[Horstexplorer]

Describe the feature

Would it be possible to add a configurable warning for low battery cell voltage, as well as one for extended periods without calibration (a full 100% charge [+ standby])?
After a few days, the SOC often drifts noticeably, and eventually the battery voltage can drop to concerning levels.
While newer grid-connected devices are partially protected by automatic battery recharging, it may be a good idea to keep the health of those batteries in check so no surprises happen.
Manually tracking these values through template sensors and automations becomes tedious when managing multiple batteries. It would be ideal if the integration could create these metrics and handle the alerts internally.

What device is this for?

Hyper2000

Other Information

No response

[harrymayr]

In prinziple I aggree, but which reaction exactly should happen? We can load the device but which amount of power should be used and to which target? Easier is the second point: Do a manual 100% load every xy days/weeks, but also which amount of power? But like some request asking to allow a seperate loading/controlling of multiple devices. Should the charge transparent to the P1 sensor, means does not change him?
In general, if you load i.e. 200W, the P1 sensor will add this 200W. And other devices may be discharged to charge the low voltage / calibrating device.
And what about devices like the HUB family, which does not have the capability to charge via AC?

[Horstexplorer]

The requested feature has nothing to do with how charging a battery works

[harrymayr]

handle the alerts internally

What should be done with the alert?

[Horstexplorer]

Nothing needs to be done with the alert once dispatched. It enables the user to recognize and acknowledge a condition he previously designated as critical and set to trigger an alert for.

[Kieft-C]

The problem is a little bit more complex.
The SoC is like u mentioned nothing for a good specific evulation of the real rest capacity.
Zendure sadly not calculate the power consumption from the devices and the drift happens very fast, depending of the personal use case.

But apart from the zendure problem, the LiFePO4 is special.
The curve of voltage is very flat with steep ends. So u can't really get a feedback from the voltage how empty/full the batterie is. - and also explain the need of the loading of the battery until reaching end-charge-voltage (3,65V) and define 100% = batterie capacity.
Plus the voltage is lower when u discharge, neutral when standby, higher when charge.
And with higher power (charge/discharge) also the voltage kicks (up/down).
This brings the problem, that a real evulation only could happen in standby, what u mostly not have.

So your wish with a "standard alert" at a certain voltage level is not possible in a standard use case.

[harrymayr]

So your wish with a "standard alert" at a certain voltage level is not possible in a standard use case.

This depends on minSoC and the voltage level for the alert. Assuming 20% minSoc, then typically the minVoltage may reach 3.18V and then go up for some mV. If you have the alert level at 3.10V it will work, because the device is empty and will slowly and then faster get lower voltage levels (if not charged inbetween). And for this the alert is OK and useful. Ofcourse you can set values which trigger "false" alerts.

I see a notify similar to the notify the integration triggers, if you change from local to cloud or vice versa.
I've setup an automation which trigger a charging sequence, if the minVoltage reaches a certain level for 5 or 10 minutes. This is also possible in the integration. However, this needs several additional user defined thresholds which may overload some users ;-)

[Kieft-C]

This is it, what I mean. There is no standard for every user.
Plus temperature infects the batteries and resulting voltage - specially on the discharge end part.

So the threshold could only observed from everybody personally and make automations for it.
A automation for a voltage level with an alert is quite easy, after the last HA major updates more easy.

[Horstexplorer]

For the voltage check, neither the state of the system nor the temperature actually matters for what I am asking. The only distinction is that the reported voltage reflects a different amount of energy remaining within those conditions. This isn’t meant to be treated as an assumption of a state of charge; it’s purely a value-triggered alert to indicate a low voltage condition. Wether or not this happens in standby or under load is quite irrelevant to me.

[Kieft-C]

U ask for an alert system for certain voltage levels. Right?

So for example:
1.Standby - SoC 30% = ~3,25V
2.Discharge with 800W - SoC 29% = V3,0V
3.Then again standby - SoC 28% = 3,20V

Where u wanna put an alert? For 3,0V where in standby the batterie got ~10%? But it's not a real 3,0V because of the physic voltage drop while discharging ?

Maybe u not read what I say, because it's an anwser to your question even when u want it easier.
But there is no way easier.
Or I misunderstand something ?

[Horstexplorer]

I asked for two things as I stated in my feature request:

1. A sensor reporting when was the last time a battery has been presumably fully charged. A simple soc = 100 I would assume to be accurately enough. If for whatever edge case this is not to be trusted, the voltage being reported at over 3.6V may very well be an additional condition.
   A configurable alert for when this condition hasnt been met within a extended timespan.

2. A configurable alert for when voltage levels of a battery fall below a configured threshold. It doesnt matter to me wether the battery is idle when this configurable threshold is being violated or wether this happens during charging or discharging it. The "actual" amount of energy remaining is irrelevant to this observation.

[Kieft-C]

Part 1: ok. That makes sense.

Part 2:
I recommend to build these both in automations lokal in your HA.

Because that I not want this in the official integration. Without more knowledge and understanding it makes inexperience user maybe more nervous, open more questions and is technically not right.

[CWILDMOUNTAIN]

I've setup an automation which trigger a charging sequence, if the minVoltage reaches a certain level for 5 or 10 minutes.

.. very similar approach here with the battery level below x for 10 minutes (in my case 3.05V).

As I'd like to charge the battery when energy prices are low I've set two automations - one which rises the min_soc of the device (so it does not get discharged any further) and another waiting for the energy prices dropping below a certain threshold to start charging.

In general, if you load i.e. 200W, the P1 sensor will add this 200W. And other devices may be discharged to charge the low voltage / calibrating device.

This is indeed an issue which took me quite a while to come over.
My solution for this: An automation will set the fuse group of the devices I don't want to charge to "no fuse group". The low-battery device will be charged setting the Zendure Manager to manual mode (vice versa when charging is finished).
It's a bit tricky to set up, but it seems to work quite well.

Would be interesting to know if you guys have smarter ideas :)

[wurbar]

Surfer1264 has put up Node-Red routines for these problems. See github/surfer

[surfer1264]

Part 1: ok. That makes sense.

Part 2:
I recommend to build these both in automations lokal in your HA.

Because that I not want this in the official integration. Without more knowledge and understanding it makes inexperience user maybe more nervous, open more questions and is technically not right.

Both requirements can be build with simple aids in Home Assistent for yourself. Its been running in my machine since 12 month before Z-HA was born.

Sure these requests can also be a part in Z-HA.

BUT

The last Release was released 4 month ago. There must be some reasons for that.

I am more interested in a stable next release version at the moment than putting new things in the upcoming release.

[surfer1264]

Surfer1264 has put up Node-Red routines for these problems. See github/surfer

https://github.com/surfer1264/Zendure-Stuff/wiki/AB2000-Überwachung-mit-HA-und-NodeRed

Danke