nathanmarlor
H3 Pro: Register 37636 can't be read
The following error message shows up everytime I restart the machine:
"Inverter (friendly name: "foxess_modbus") has some registers which we expect to read, but can't. Details: [(37636, 64)]."
My Equipment:
FoxESS inverter H3 Pro: Master: 1.58 Slave: 1.06 ARM: 1.33
foxess_Modbus Version: 1.13.5b7
Your firmware is ok and up to date - can you provide a bit more information please:
is this a new install ?, what RS485 adaptor are you using to connect to the inverter ?, when you look at Devices & Services, 'Foxess - Modbus', in the list of sensors are any/many unknown or are they showing data ?. what version of HA core / Super visor are you running (Settings, About)
Hi Fozzie,
Installation: Yes, a quite new installation from last month.
RS-485 Adapter Using the Waveshare Industrial USB TO RS485 Bidirectional Converter (B)
Entities connected to this one device: It numbers 139 activated and 20 deactivated entitities. 90 % of those activated entities are with valid values - all looking ok (beside the fact that I had to manually adjust some of the scalings as described in another post of you).
Home Assistant Core: 2025.4.4 Supervisor: 2025.04.1 Operating System: 15.2
Thanks for your effort and support - Jens -
ok thanks, it might be worth while dropping the max reads slightly, as it was trying to read 64 entities when it failed at startup, also if it is slightly lower if there is an invalid register being read we might see more precisely which one it is.
In HA go to Settings, Devices & Services, click on the '>' to the right of Foxess - Modbus, click CONFIGURE, Advanced Settings and reduce the Max Read value to 40 - submit and it will be actioned.
Then see if you get any errors at startup.
Just wanted to add I had the same issue on ARM version 1.34 (new install) - it tried to read 92 by default.
37636 fails, but I also see these in the logs: 37637 37638 37639 37640 37650
I tested a bunch of others and everything in between 37640 and 37650 also fails, as well as beyond that (until i got bored testing one at a time).
To be honest I am not sure why it is reading these registers or what they are supposed to do, I see no reference to them in the code (except 37636 which is listed as a H3 Smart individual register).
I also get some validation errors:
Value (39220: 3922.0) for entity 'sensor.h3_pro_load_energy_today' address(es) '[39632, 39631]' failed validation against rule (Range : {'_min': -1000, '_max': 1000})
Value (10690: 1069.0) for entity 'sensor.h3_pro_feed_in_energy_today' address(es) '[39616, 39615]' failed validation against rule (Range : {'_min': 0, '_max': 1000})
Value (1390: 139.0) for entity 'sensor.h3_pro_total_yield_today' address(es) '[39624, 39623]' failed validation against rule (Range : {'_min': -100, '_max': 100})
Though I don't recognise these values TBH if they're supposed to be in kWh.
Looking at a lot of the related entities like yield total, load energy total and solar today/total they all seem to be out by a factor of 10.
@andyjenkinson The integration isn't reading anything above 37632, until it gets to 37700 - I can't tell without seeing your logs but it's likely the split and the attempt to read 92 registers is causing the problems. As the H3 Pro has been developed more and more registers have been added and that seems to have taken some of the adapters over a tipping point with Max Reads - I would recommend a value of 40 to start and if that is stable, you can try 50 but tbh it won't make much (any) difference to polling speeds and probably be less likely to mis-read at 40.
On the validation errors, the H3 Pro latest firmware has uniquely changed the scale multiplier on all of the total registers (it's mentioned here along with a temporary fix https://github.com/nathanmarlor/foxess_modbus/issues/724#issuecomment-2586922485)
We're not entirely sure whether this was deliberate but the latest spec confirms the new multiplier (100) however every spec and inverter prior to this has 10 as it's multiplier... it won't be the first time they have made a change and then changed back or it may become the new norm after a bit of time for the change to ripple through other inverters.
I've put in a tentative fix, which will be in the next pre-release. Please re-open if this doesn't fix the issue.