Added various options to AC charger settings

[eu-gh]

In addition to my (now obsolete) PR #449, I made the following changes to the AC charger settings page:

• Added verbose logging toggle (since b1164d6 the loop function became pretty chatty on the console)
• Replaced my newly created "reduce power" with a more generic "use SoC data" switch
• Added a stop charging SoC threshold so the battery won't charge to 100% all the time
• Added enclosing div to AcChargerAdminView so all options disappear it the charger is disabled

[helgeerbe]

I don't own a Huawei charger. Who can test this PR?

[eu-gh]

@indie89 @Phantomias2006 @CaCu15 any volunteers? In case you don't want to clone the whole repo, I uploaded precompiled binaries here

These build also include the new CAN bus latency fix from @MalteSchm (which is working incredibly well btw, nice work 👍)

[indie89]

As I perform the whole control part over iobroker and use on battery mainly as a universal interface between hardware and mqtt, I am probably not much of a help.

But honestly I haven't checked the "automatic power Control" section yet. Do I have to turn on the option in order to profit from your improvements or is it also possible to just have my iobroker control "overwritten"/limited by the "soc limits"?

[CaCu15]

Thx, EU-GH for your work!

It's a little complicated for me to test this as I don't have a relay connected to the ESP to switch the pre-charge pins of the AC charger currently. My charger keeps the fan spinning even if I disconnect the pre-charge pins. Additionally the charger has quite a high idle power consumption, thus I'm currently switching the charger on the AC side using a Shelly.

Thus this test would require me to keep the charger switched on for the complete duration of the test. Despite that I'm going to do this test, but I've to run it on the next weekend (currently not enough time).

For me it would be a valuable addition to have the option to configure REST calls or MQTT messages to a switch on the AC side of the charger (preferably REST instead of MQTT as I'm trying to eliminate all additional server processes required to run the solution)

My thinking is:
I would like to switch of the charger on the AC side completely during longer interruptions of the charging process or if the battery is fully charged. But I would like to avoid switching the charger on/off frequently as I think this will increase wear on the charger.
Thus I would like to use pre-carge pins to switch charger to idle during short interruptions e.g. due to drop of solar production (i.e. power export < minimum output power). If interruption duration > configurable duration than switch of charger completely.

[eu-gh]

But honestly I haven't checked the "automatic power Control" section yet. Do I have to turn on the option in order to profit from your improvements or is it also possible to just have my iobroker control "overwritten"/limited by the "soc limits"?

This function will automatically calculate the power supply's output parameters directly on the ESP, based on a power meter reading, I believe that this is the lowest latency option we currently have, also it's really simple to use. In my setup, a Node Red flow is sending the data. To disable the charger, I'll simply set the power meter value to 0.

But no, if you don't use that function at all, there is no point in flashing my build. Thanks for your reply anyway!

It's a little complicated for me to test this as I don't have a relay connected to the ESP to switch the pre-charge pins of the AC charger currently. My charger keeps the fan spinning even if I disconnect the pre-charge pins. Additionally the charger has quite a high idle power consumption, thus I'm currently switching the charger on the AC side using a Shelly.

I stumbled upon the same observations and to be honest, I never got the internal slot detection power switching mechanism to work. My solution is also an externally controlled Tasmota switch, which turns the AC power on if the solar yield exceeds 350W and off after 7pm (and the output power is 0/output temp is below 40°C). I don't see why this would do any harm to the unit, as long as you don't disconnect it under full load (or after a lot of heat had accumulated, which is unlikely to happen in this scenario, as the power output decreases gradually with the sun setting).

Disconnecting the DC side, however, seems stressful (fan spinning like crazy, I suppose to dissipate as much heat as possible in preparation for an upcoming shutdown?)

[indie89]

I stumbled upon the same observations and to be honest, I never got the internal slot detection power switching mechanism to work. My solution is also an externally controlled Tasmota switch, which turns the AC power on if the solar yield exceeds 350W and off after 7pm (and the output power is 0/output temp is below 40°C). I don't see why this would do any harm to the unit, as long as you don't disconnect it under full load (or after a lot of heat had accumulated, which is unlikely to happen in this scenario, as the power output decreases gradually with the sun setting).

Disconnecting the DC side, however, seems stressful (fan spinning like crazy, I suppose to dissipate as much heat as possible in preparation for an upcoming shutdown?)

If you need a hint for convenient application of the slot detect relais, just let me know (a bit off-topic, sorry). If you speak German or want to use an online translator, you can also have a look at my project presentation in this forum. I most recently added an update, how I put the slot detect relais to good use (similar to your AC-disconnect): https://www.akkudoktor.net/forum/postid/156717/

[CaCu15]

OK, I will run this test starting today. For the test I can control the Shelly for the charger manually. . If the test is successful, I will implement a similar logic to switch the AC side of the charger (i.e. based on solar production & soc).

Than I only need to keep my absorption logic outside of OpenDTU on Battery. I still like to have the possibility to run absorption phases in case the battery cells get out of balance. But that can be accomplished by disabling the OpenDTU logic temporarily and control the absorption by external logic.

[CaCu15]

@eu-gh @helgeerbe

Running this version (used the binaries linked in the message #480 (comment) above ) since yesterday and first impression is very good.

• upgrade from release 24/07 ran smoothly
• manually switched the AC side of the charger (using my Shelly) in the morning & in the evening (will replace that with a custom logic later)
• I don't have a VE.Direct or any other solar charger, I'm only using the HUAWEI currently. Thus I can't say anything concerning interoperability with solar chargers
  - communication to the Huawei seems stable, no drop-outs so far. Huawei data never get older than 3s in the UI. Thus Malte's fix seems to work really good.
• the charger power follows the available power export quite closely, quick reaction time. I had a really bad day (with concern to solar radiation, a lot of rain) yesterday, but still the charger managed to charge my US5000 to 62%.
• will keep this running to observe in different conditions

Some "wishes" for improvement:

• Currently the charger fully exploits all the available power export up to the configured MAX. I would like to have the possibility to configure a buffer of X watts that is not used by the charger in order to account for changes in the power usage or drops in solar production. Currently this changes lead to short phases of power import.
• why do I need to configure a SOC and power for reduced charging power? The Pylontech communicates the MAX charging power, thus the logic could use the feedback from the battery directly? At least that is what I did in my own Node Red based flow
• the "icing on the cake" would be: possibility to configure an "absorbtion phase" of X minutes after reaching the target voltage. Here the charger keeps supplying power at the target voltage but with very low current (i.e. 1A) to allow for top balancing of the cells. Maybe with a schedule (i.e. a CRON string) to plan execution of this phase

[CaCu15]

Der Branch läuft jetzt seit 3 Tagen ohne Probleme bei mir. Einschließlich Test der REST API zum Lesen und Schreiben der Huawei Konfiguration.
Habe jetzt in ESPHome einen Flow zum Schalten des Shelly vor dem Huawei abhängig von der Stromabforderung zu schalten.

Jetzt muss der Branch nur noch in ein Release gemerged werden.

[schlimmchen]

This conflicts with #500. I am happy to rebase onto your work in case helgeerbe merges your work first. If not, you will need to rebase onto #500.

Also, some remarks:

• The settings in the WebUI should use an InputElement (source code). This would not only remove code duplication, and make the source more readable, but also would add space between the input elements, which is missing in the current implementation.
• The toggle switches at the top use attribute wide which makes the label use 4 columns rather than 2. However, the labels of all the other inputs use only two. Fix this by using InputElement with the wide attribute or adjust the classes accordingly.
• For whatever reason, the CardElements are nested in this page. As far as I can tell, that is done nowhere else. So it should not be done. Maybe this happened in error. Please close the first CardElement after "Use SoC data...".

[CaCu15]

One last comment concerning this PR:

I noticed, that this causes some "flapping" between charging (via Huawei) and discharging (via inverter) when the power export is just a little bit higher than the configured minimum power to be used for charging. I configured a minimum power of 150W (which equals 3A current roughly). But at least at this low setting my Huawei does provide a little bit more current (4 - 4.5 A) which causes the overall power usage to be so high, that the DPL switches on the inverter and starts providing power. This in turn stops the Huawei from charging causing the power draw to drop again thus the inverter stops providing power and the loop to start again from the beginning.

This loop stops as soon as power export is significantly higher (approx. 250W in my case) than the configured minimum charging power.

Thus I propose to think of some kind of hysteresis to avoid flapping between the dynamic power control of the inverter and the charger when the charging power is near the minimum.
Maybe the following could work: When switching from charging power of 0 to something >0 we should not jump directly to the computed power, but implement a short "ramp up phase", e.g. start with 50% of the computed current and increase power request over the next cycles.

[helgeerbe]

@eu-gh can you check the remarks from @CaCu15 and @schlimmchen

[MalteSchm]

@CaCu15
So you're saying when the minimum power of the PSU is set to 150W the actual minimum power is higher?
I thought about this a few minutes and believe this is expected on startup as the efficiency is unknown. I used 100% but it could be better to change this to 80 or 85%.
float efficiency = (_rp.efficiency > 0.5 ? _rp.efficiency : 1.0);

Apart from that. The DPL is locked and should not start as long as the PSU is on and vice versa.

[CaCu15]

So you're saying when the minimum power of the PSU is set to 150W the actual minimum power is higher?
Exactly, at least that's what I saw in the live-view.

I used 100% but it could be better to change this to 80 or 85%.
Yes, maybe that would be sufficient to solve that behaviour as it avoids to fully exploit the complete amount of available power right from the start of the charger and allows for a less rapid increase in power consumption.
I assumed the behaviour to be caused by less precise power control by the Huawei charger in low load scenario, but I wasn't aware that you are already considering the efficiency of the charger in your computation.
I think your proposed solution is worth a try (and seems to be easy to implement).

The DPL is locked and should not start as long as the PSU is on and vice versa.
In the live-view I saw the inverter and the charger active at the same time with both "Inverter Total Power" > 0 and "Huawei AC Power" > 0 at the same time. May be this is caused by delayed status updates to the live view and does not reflect the actual status.
But it seems as if this is not really true: Today I checked against the logs of my Shelly, that controls the inverter and the charger. The diagram below shows the power consumption/usage for both and according to this diagram:

• The inverter is NOT active while the charger is running. Thus this observation in the live-view seems to be wrong
• There seems to be a short peek in the power consumption of the charger directly when it is switched on. There is a similar peek to the one shown in the diagram below on the 3 days I checked

More detailed view or a time frame with very fast switches between inverter and charger. Caused by a microwave oven running while the charger was charging as well. NOt sure, whether this is really healthy?

[helgeerbe]

@eu-gh what is the state of this PR? Can you rebase it and solve the merge conflicts.

[schlimmchen]

@MalteSchm Can you help us and decide whether or not this is a useful improvement? Can people other than @eu-gh use these changes? Would you like to see them merged? I would be willing to rebase this, solve the conflicts as well as I can, but I would like to be sure that it is worth the efort. Otherwise, due to @eu-gh's silence, I would close this.

[CaCu15]

@schlimmchen : Even this question was not directed to me I would like to comment:

I think, that the most important change introduced with this change is no longer necessary, as Malte create #767. PR 767 already contains the logic to adapt the charge current to the limit communicated by the battery, thus it renders the setting "Reduced Output Power" and "Reduced output power at SoC" useless, at least for Pylontech batteries and any other battery types able to communicate a charge current limitation.

The only setting remaining than is the "Stop charging at SoC" setting, but this kind of conflicts with the current logic to stop the charging. You can either stop charging:

• if current drops below configured limit at given voltage (current implementation)
• if SoC reaches a target SoC (as proposed by this PR)

If either one (or both) of this two criteria is met, then charging needs to stop. But than the questions is: What's the added value of the SoC based control? You can determine the target SoC be means of the charge voltage already.

[MalteSchm]

If I take a step back I have implemented exactly the same functionality: Stop the AC charger when the battery reaches a SoC threshold. I use a RPI currently to turn the charger off when SoC goes above a certain value. So I realized this usecase in a different way and one could argue that this is functionality that could also be integrated in OpenDTU.
I guess when I first implemented support for the Huawei I did not consider the fact that the voltage curve of LiFePo does not really allow to stop charging at a certain SoC level (it stays constant for too long and rises too quickly at the end of the cycle). So it really makes sense to stop at a SoC level.

Regarding this power reduction I did not understand this back then when this PR was first introduced. The explanation from CaCu15 makes sense to me however and I'd also consider this as being addressed.

So I would support parts of the PR as being relevant and their inclusion into the project.

The thing to check with this PR is how the full solar pass-through of the power limiter and the SoC limitation of the AC charger would interact. I had to handle locking the PL while the AC charger was active on the RPI so this may also be something to take into account. I just skimmed through the changes and did not spot anything so maybe this is something to look into.

[schlimmchen]

Thanks both of you for your input!

So..... We drop Huawei_Auto_Power_Reduced_Upper_Power_Limit and Huawei_Auto_Power_Reduced_BatterySoC_Threshold and keep the rest?

[MalteSchm]

Yes I guess so. But we should take a look at the dependency with the full solar passthrough

[schlimmchen]

I forced-pushed to the wrong remote a couple of minutes ago, which I think I reverted by pushing the previous commit hash. Sorry about that.

@MalteSchm @CaCu15 Let's continue in #848.

[schlimmchen]

Superseded by #848.

[github-actions]

This pull request has been automatically locked since there has not been any recent activity after it was closed. Please open a new discussion or issue for related concerns.