H3-Pro Modbus Connection Issues #685
Replies: 7 comments 15 replies
|
Hi, it looks like you are on the very latest H3Pro firmware - has it ever worked for you (but a firmware upgrade stopped it), or is this the first time you've been trying to set it up?. Can I just ask what your inverter config is - single battery or dual battery system (since 37609 is a BMS register) If you are on v1.12.1 (or .2) Can you go to Settings, Devices & Services, and click on the > to the side of Foxess - Modbus, then click on 'Enable Debug Logging' Restart your home assistant and let it start up, wait a minute or 2 and then go back to Device again as above but this time click on 'Disable Debug Logging' and it will download the logfile - if you can then copy and paste all Foxess modbus.modbus controller event logs below please. |
|
The integration has never worked fully; I first tried v1.12.1 when the inverter was installed (the latest version at that time) and the initial connection failed with this 'IllegalAddress' issue. I tried an older beta version that successfully connected the controls, but didn't return any sensor information. I then worked my way up to v1.12.0 which is the latest version I can currently use (again, controls working, sensors not). I have a dual-battery installation. From a secondary HA instance I have running with v1.12.2, I get the following debug information: 2024-10-01 15:40:42.215 DEBUG (MainThread) [custom_components.foxess_modbus.modbus_controller] Reading addresses on tcp://192.168.68.222:502 247: (36001, 3) |
|
Ok, thanks It's difficult to work out where it is going wrong in that last reading registers as it's trying to read 92 registers when it fails. Can you try reducing the read registers value to 10, it's possible that might narrow down where it is failing. If you got to Foxess Modbus in Devices&Services again, click on that > and select 'CONFIGURE', choose the Advanced Settings and change Max Read to 10 then submit. Then if you could repeat to get the same logs as above please. |
|
Ah, we have progress! With Max Read set to 10, the connection appears to be stable and sensor values are flowing correctly. Debug information as below: 2024-10-01 16:05:13.765 DEBUG (MainThread) [custom_components.foxess_modbus.modbus_controller] Reading addresses on tcp://192.168.68.222:502 247: (36001, 3) |
|
Interesting, it's actually your adaptor that couldn't handle the max reads and not an invalid register mapping. The default for that adaptor is 100, and as far as I know we haven't seen a problem before - but the H3 Pro has so many 'extra' registers for its PV strings and second battery we may have just found it's limit. Would you mind trying that again but set the max read to 50 and check the logs - i'm hoping it should cope with that. N.B. There's also a problem being reported by a validatoin fail in 39235,39236 (inverter battery power 2) - i'll take a look at that. |
|
I see - thanks so much Dave. Sensors appear to be working other than 'Inverter Battery 2 Power' (as you pointed out) and 'Battery 2 Discharge'. Debug info @ 50 max read, all appears to be working: 2024-10-01 16:45:43.097 DEBUG (MainThread) [custom_components.foxess_modbus.modbus_controller] Reading addresses on tcp://192.168.68.222:502 247: (36001, 3) |
|
Thanks, looks like the max read for the TCP232-410 adaptor needs to default to 50 On the [39235,39236] validation fail - i've just been looking at the code, and found a comment that refers to this post #516 (reply in thread) So i'm wondering if that means that as you are on the very latest firmware that Fox have now fixed this bug in the inverter firmware that reversed those addresses to bring it back in line with the protocol spec?. It's easily tested - can you go to 'developer tools', click on Actions (or Services as it was), start typing in the Action box 'Foxess - modbus' and pick the Read Registers item, in the drop down inverter box select your Inverter, in the Start address box enter 39235, count should be '2' and select 'holding' then click 'Perform Action' - would you mind screenshotting the result and post it here. |
|
Sure... 
|
|
Hmmm, ok yes it's been flipped back the correct way again 🙄 If you don't mind making a manual change to your code we can let your system run with a modified version and if you can report back in 24 hours to show the results - basically you should see invbatpower2 and battery charge2/discharge2 sensors (which are derived from it) behaving normally. If you are on v1.12.2 edit line 1200 in this file and change the code as follows from
to
i.e. reverse the 2 addresses Once you've done that you need to restart home assistant and it should be reporting normally. BTW: you can turn debug off if you haven't already |
|
Edited and values are now showing as expected. Will post results tomorrow. Thanks Dave, much appreciated. |
|
The modified integration has been running perfectly for over 24 hours, with Inverter Battery 2 and Battery 2 Discharge numbers appearing to be correct. If there are any specific numbers you'd like to see, let me know. |
|
ok, thanks - can you also check that Battery 2 Charge is indicating correctly and that should be that. |
|
Battery 2 Charge looks fine also. My battery is fully charged at the moment so I can't check live values, but the history graph is in line with what I'd expect to see |
|
FWIW I had success reading well above 50 registers when I tested my 410s last year. However for the purposes of this integration doing it in one, two or three reads doesn't make much different given each one is completed in few hundred milliseconds! |
|
Whether having looked at the logs in too much detail, this might well be a caused by an unreadable register, which the 100-register read happens to span, but the 50-register read doesn't. If that's the case, the solution is to add that to our range of registers to not read. |
|
I'd like to test excluding those registers between BMS1 and BMS2 (and probably between BMS2 and the stuff which follows), see if that fixes things as well. I suspect the max read is just a sticking plaster which happens to work around the real issue. Yes please, let's get a fix for invbatpower2 in. |
|
I have a similar problem to the original poster. I have a H3-Pro-15. There is no physical problem with the modbus. I can read individual registers (for example, the battery SoC) no problem, if I use the "Read Registers" action. However, the device itself has all sensors unavailable and all controls grayed out. The Connection Status sensor starts off as "Connected", but after a while I get an Exception Response(131, 3, IllegalAddress) error. I have tried to add the illegal address to the list of invalid_register_ranges for H3_REGISTERS, and every time I do this, I then get the same error but for a different address. Should I just persevere and keep doing this until I no longer get this complaint, or is there something else I should be doing? (I've already tried the suggestion of reducing the number of reads from the default 100 down to 10. I've also tried 50 but neither has helped). |
|
OK, so to answer my own question, it seems that perseverance was what was needed. When I added some more exclusions, suddenly the system sprang into life and I started receiving data. For those interested, I ended up with the following exclusions: It seems not all H3-Pros are created alike. I have a H3-Pro-15 with a single stack of batteries (hence no battery 2), versions manager 1.03, master 1.21, slave 1.21. I don't have a second battery and that might be causing some issues with invalid registers. So in my case, the process to get it working was to
Not all is perfect yet though. I number of sensors are still listed as unknown or unavailable. Specifically: Aside from that all there and values looking reasonable, though I haven't checked all of them. The exception is PV4 values. I only have 3 strings, so PV4 was a surprise. PV4 power is currently being reported as 16515 kW and the PV4 Power Total is currently 12183 kWh. Obviously not right. I can get my battery SoC by a "Read Registers" action on address 37612 |
|
Just a final comment. Reading through the code in entity_descriptions.py I note that 37002 is listed as the BMS connection, 37609 as the battery voltage, and 37610 as the battery current for the H3-Pro. However, on my H3-Pro, attempting to read these addresses results in an error, hence the need for me to put these in the invalid_register_ranges, but then of course I lose the BMS values and also the current, voltage etc as noted above. So it appears that on my version of the H3-Pro some registers have probably been moved. Annoying. Does anyone have a spec for the modbus registers? |
|
It turns out that all of my problems were down to dodgy and out-of-date Fox firmware. I've only just had my inverter installed so assumed it would be up-to-date, but no. Also, you can't update the inverter yourself, you have to ask Fox to do it. But anyway, once I updated to Manager 1.22, Master 3.39, Slave 3.39 all my problems appear to have gone away and I can use the integration without having to hack the source code with exclusions etc. |
Uh oh!
There was an error while loading. Please reload this page.
Hi all,
I've had an H3-Pro-20 installed and connected via Modbus on a USR-TCP232-410s. Using v1.12.1 and v1.12.2 a connection is initially made, but it times out after a minute or so with the error:
Error reading registers. Type: RegisterType.HOLDING; start: 37609; count: 92; slave: 247 from tcp://192.168.68.222:502: Exception Response(131, 3, IllegalAddress)
I can connect using v1.12.0, but all of the sensors are unavailable. The controls section is however operational. Happy to help fix this if there's anything I can do. My firmware versions are:
H3-Pro-20.0
Master: 1.53
Slave: 1.06
ARM: 1.22
All reactions