evcc-io
Huawei: allow battery charge from PV in hold mode
Based on this discussion. Also see LUNA2000 battery control registers.
Changelog
- default max. charge/discharge power set to 2500 W (supported by all SUN2000/LUNA2000 configurations)
- updated documentation
- battery can charge from PV in
holdmode
Test Cases
- [x]
normal: charging from PV, discharging to home (no charging from grid/discharging to grid) - [x]
charge: forced charging from grid - [x]
hold: no discharging (to either home or grid) and no charging from grid - [x]
hold: charging from PV - [x] Each state transition
Tested by @CiNcH83 & ~~@mucki12~~ & @LotharWoman
Considerations
Since active battery control has been handled via force registers so far (which do not allow PV charging in hold mode), the default maximum discharge power setting has remained unaffected during normal operation. Starting with this PR, the maximum discharging power will by default be set to 2200 W (a value supported by all battery configurations), even if a larger LUNA is installed, as those registers are bounds-checked and cannot be set higher than supported by the given configuration. To utilize higher charge and discharge power, the maximum charge/discharge power must now explicitly be configured via the evcc.yaml file to match the specific setup.
(Force registers are not bounds-checked. So they can be set to the highest possible charge/discharge power even for smaller LUNA configurations. Hence the high default value that has been used before.)
With respect to ease-of-use, the best solution would probably be to read the capabilities from the inverter/battery, see #24926.
We also lose the watchdog for hold. So if the controller (evcc) goes boom or register writes fail while leaving this mode, the battery may remain at 0 W discharge power.
Open Questions
- [ ] How shall we deal with defaults for
maxchargepower/maxdischargepower?
PR closed, see here.
[EDIT] The wrong register values after mode change are due to #25179. Fixed by #25232.
Even though the concurrency problem has been fixed (#25232), I will keep this PR closed. The watchdog functionality IMHO weighs more than the ability to charge the battery from PV in hold mode.
@CiNcH83 there's no point dragging me into every discussion where I cannot contribute. PR needs testing to be confirmed.
The watchdog functionality IMHO weighs more than the ability to charge the battery from PV in
holdmode.
I completly agree. If evcc chrashes while in hold mode, the battery will remain at 0 discharge power, as Huawei‘s previously used fallback automatic won‘t kick in.
Personally, i never charged in hold mode and this would be a step backwards.
If evcc chrashes while in hold mode
It doesn't. Right now, hold mode doesn't work as expected. That's a bug.
Okay, so it's currently a basic requirement of evcc that the battery must be able to be charged in hold mode. Okay, I didn't know that.
However, if evcc should ever crash (it really NEVER crashes?), the current method has a fallback, the new one doesn't.
the current method has a fallback, the new one doesn't.
Worst case one can still use
evcc meter --battery-mode normal
Or trigger external mode switch via api. evcc does indeed never crash for me and if we see crashes we fix them immediately.
I definitely didn’t mean to imply that evcc tends to crash :-)
But even if you pull the plug from the evcc serveer, the current template would have its own Huawei fallback. I just see that as an advantage — though of course, others might see it differently.
Since this PR has been tested and confirmed, I'd like to merge if we can get rid of the only half-correct defaults.
As I said — if that’s what’s wanted. Luckily, you can also integrate the battery as a custom device. That way, you get the more stable implementation.
BTW: my test was negative
As I said — if that’s what’s wanted. Luckily, you can also integrate the battery as a custom device. That way, you get the more stable implementation.
BTW: my test was negative
Then the PR is misleading:
Tested by @CiNcH83 & @mucki12 & @LotharWoman
Your test has been negative because of this. I re-opened this PR because the issue has been fixed by now.
Your test has been negative because of this.
Sorry, then I must have misunderstood the linked PR. I was having issues even though I didn’t make any external changes to the mode, and I thought the PR was intended to handle incorrect behavior caused by additional external switching via the API. But it doesn’t really matter — I’ll just integrate the LUNA as a custom battery, since, as I mentioned, the Huawei fallback in case of malfunction is much more important to me.
As already mentioned in the discussion, the bug also affected internal affairs.
Ok, but with this PR you still lose the Huawei fallback, right? Or did I miss something?
Yes. If switching from hold to normal fails (write maxdischargepower to register 47077 fails), Max. Discharge Power will stay 0 on inverter/battery side.
So, is this now supposed to become an optional second template, or have you changed your mind?
Even though the concurrency problem has been fixed (#25232), I will keep this PR closed. The watchdog functionality IMHO weighs more than the ability to charge the battery from PV in
holdmode.
In fact I am not even charging from AC. I am just trying to find a good solution for people. So I can be pretty objective about it. Charging from PV while on hold is for sure a thing you would want to have. But we also know from the past that communication via SDongleA-05 can be flaky for certain HW/FW combos. There it is pretty calming to have a watchdog in place...
@CiNcH83 Then please remove my username as a positive tester from the original post, since I haven’t tested it in this combination with the other PR and also don’t support it content-wise. Thanks.
@mucki12 we got it, thank you. What specific problem did you see in the test?
The problem has been that Maximum discharge power remained 0 after switching from hold to normal.
During a test with the planned hold mode, the battery discharge power was once at 0, even though evcc was already back in normal mode. I can no longer trace how this happened. As a result, no battery lock was shown in evcc, but it was still effectively active. Possibly, the Huawei system “swallowed” the Modbus change when switching from hold to normal. That can happen, but as mentioned, it wouldn’t have been an issue with the old template.
I just tried another approach for hold... activating Forcible Charge and setting Charge from AC to false. It unfortunately used all DC power for battery charging and used grid power for the loads. Was to be expected though. So not the best solution either.
@CiNcH83
Thanks for testing. I’ll list the three options I’m aware of to stop the discharge of the Huawei battery:
- Force discharge / 0 W – current implementation
- Discharge power 0 W – as proposed here
- Via ToU
Regarding 1: Advantage: simple and absolutely stable / Disadvantage: unfortunately, the battery cannot be charged in hold mode Regarding 2: Advantage: the battery can be charged in hold mode / Disadvantages: the user has to adjust more settings (otherwise the PV system will no longer work as desired), and it’s less stable because the Huawei fallback is lost Regarding 3: Similar to 2, but the user must configure settings in FusionSolar (which wouldn’t be my preferred option)
Beyond that, Huawei could offer force charge / force discharge based on SoC, but I don’t see any benefit for this use case.
I’m also completely neutral here. And @CiNcH83 - you’re right, it should be the best solution for everyone (personally, I’m perfectly fine integrating the LUNA as a custom battery).
Personally, I don’t need to be able to charge the battery in hold mode. However, if more and more users come with a §14a requirement, I can fully understand the demand for charging in hold mode (I myself am currently not subject to §14a).
However, since the hold-mode approach seems to be the chosen direction, the “§14a users” should decide what's the best way for mode hold.
Regarding 2: Advantage: the battery can be charged in hold mode / Disadvantages: the user has to adjust more settings (otherwise the PV system will no longer work as desired)
Which settings does THE USER have to adjust?
Which settings does THE USER have to adjust?
Maybe i'm confused, but the correct discharge power? Else it would default to 2500 or - newest idea - to 2200?