Is 3Kw correct value for max charge from grid value?

[JohnMcLear]

I have 2x Luna2000 batteries on each inverter and my max charge is 3Kw. For some reason I thought it was 5Kw and I'm a little bit confused to why it isn't.

The following screen doesn't really provide clarity but it would seem to suggest 5Kw from grid is doable but the max set by this integration is 3Kw..

Do you need 3x Luna2000 battery off each 6K L1 to reach the 5Kw or is 3Kw a hard limit for each inverter?

[wlcrs]

The integration reads the following register to determine what the maximum charge power is:

The dataset suggests that 5kW is the correct value when you have 2 battery unit (assuming maximum charge power is equal to maximum discharge power):

I have only one battery unit, and this register correctly returns 2500W for my installation.

[JohnMcLear]

Heya @wlcrs , thanks again for all your hard work on this integration.

You are correct, I do have two battery units so my limit should be 5Kw and this does look like a bug in the integration.

Would you like me to make a new issue or can we convert this to an issue?

Happy to try beta branches etc. or make changes to lines of code to test things etc. :)

[wlcrs]

Feel free to open an issue, but make sure to include debug logs. After enabling the debug logs you should restart the integration to make sure it contains all calls that the integration makes on startup to define the valid range of every config entity.

This will allow me to validate what my current assumption is: I expect the issue to be the inverter returning the wrong maximum value, not the integration doing something wrong.

[JohnMcLear]

wlcrs.txt

output of

cat home-assistant_huawei_solar_2023-10-09T14-59-28.425Z.log | grep pymodbus > wlcrs.txt

I have problems getting logs as if I do a reload it doesn't reconnect properly so I have to do a reboot..

[wlcrs]

What parameter are your trying to set?

A.

this one should be limited to 5000W according to your logs

B.

this one should be limited to 3000W according to your logs. It uses the following register to determine this:

[JohnMcLear]

On each battery I have this option:

I set the value to 5 here, just to show an value change, I'm attempting to set it to 5000.

Does that answer your question?

[wlcrs]

Yes. The integration correctly uses the "maximum power of charge from grid" which the inverter advertises. Note that the difference between the two is (according to me) that A is about the maximum charge power from solar, and B the maximum charge power from grid.

I'm quite surprised to see that that upper bound value is writable according to the documentation, and I honestly don't understand why this is the case. The integration does check every 5 minutes if that maximum value has changed.

To summary: B allows you to set the following register, which is limited by the register below it in the specs:

[JohnMcLear]

err yea writable sounds dangerous without bounds.

I wonder if that's the case so they could use X model with Y battery config and not have to write the logic internally to harwdare.

Given that it's writable I tried to modify the value in fusionsolar and see what behaviour I experience in HA/on the device.

Note to self: I set all max charge powers to 5K & SoC 2%>100%.

I'll report back tomorrow with the charge rate that I experience from the inverters.

[JohnMcLear]

I got fed up again trying to debug this half between this integration and half between fusion so I removed the dongle and switched over to RS485 over an EW11.

I noticed again that for some reason that all energy is fed to the grid instead of batteries... I can't tell exactly what's going on here and I need to collect more data.

I think the experience I'm having is similar and related to #272 (comment) and #272 (comment)

[JohnMcLear]

I have disabled remote management and rebooted the devices then connected using the EW11. Comms seem more stable immediately.

I have set the batteries to forced charge (3kw each) and waited 10 minutes.

I cleared the "Abnormal battery" warning on each inverter, this was probably caused by me hard turning the battery off while the inverter was still operating.

I'm still not seeing any extra Grid consumption or any additional charge hitting the batteries.

I looked at the logs and I see

2023-10-11 14:25:18.133 DEBUG (MainThread) [pymodbus.logging] handle: [b'\x00\x00', b'\x02g']
2023-10-11 14:25:25.960 DEBUG (MainThread) [pymodbus.logging] Connecting to SDongleA-HV2170115623.lan:502.
2023-10-11 14:25:25.960 DEBUG (MainThread) [pymodbus.logging] Connecting comm

This shouldn't be happening as I deleted this host and connect to ew11.lan so that's really weird..

I'm going to restart HA and see if I get any message about SDongle.

@wlcrs

1. When I call the service to start charging nothing shows up in the battery or inverter log book. I feel like something should appear there? Would you agree? If no, where should I be looking?
2. All three of the inverters are showing "[Minor] 2068: Battery abnormal" -- this wasn't showing as an error when I had connection to the management system and was using the SDongle. I wonder if it's related to RS485 and which pins to use for battery when you have an EW11?
3. See hostname issue above. I restarted HA and it stopped trying to connect to the old host. It might be that a hostname is being stored as a constant or some such. Integrations shouldn't require a restart of HA IMHO.

I do have the battery now charging, tbh I'm not sure exactly what I changed other than a restart and shift from SDongle to EW11 -_-

It's currently charging at 9Kw,. I'm going to leave it to test that it charges to the expected % then tomorrow I'll check it charged @ 15Kw. Fingers crossed 9Kw works. Note to self: it's set to charge to 100%.

[wlcrs]

1. I don't think that HA logs anything in the logbook when you call a service. The API for implementing services does not provide handles for this.
2. No idea. At the end of the day I'm just the guy who implemented a library to read the Modbus registers documented by Huawei. I don't know anything more than what is in the documentation. I fried the RS485 ports of my inverter during development of this integration, so I'm definitely not the right guy to ask much questions about how to properly use them 🙃
3. That should indeed not happen. The integration contains so many retry-loops nowadays that it's hard to verify if everything stops when requested to. I'm particularly not very confident in the retry-logic implemented by pyModbus. In the past I've already upstreamed a patch fixing a race condition when a connection is being closed, but there could be more gotchas like that hidden in the pymodbus codebase 😑