H1-5.0-E-G2 Generation 2 not supported?

[jHamshaw]

Hi

New installation this week - I appear to have a G2 inverter - many functions missing when compared to G1 - most notably any form of forced discharge and the advanced scheduler functions. Fox support say new firmware will be released "very soon".

In the meantime I'm trying a ModBus connection with an Elfin-EW11 all connected and fired up. All cables meter-checked for continuity.

The Gen 2 user manual is identical to the Gen 1 in terms of RS485 connectivity.

However, when trying to configure the integration I get error message :

Error connecting to your adapter or inverter. Ensure the adapter is properly configured and is correctly wired to your inverter (see the setup link above), then try again. Details: Inverter model not supported: ''

The error message detail seems to suggest that my Gen 2 inverter won't work with this ModBus integration either? Is this really the case??

I'll be mightily pi33ed off if the latest Fox hardware is so firmware-crippled as not to be as useful as the Gen 1 - I had no idea that there even was a Gen 2 available when I had my install done....

[canton7]

Interesting! All other inverter models expose their model number (e.g. "H1-5.0-E"), and we use this to determine what sort of inverter we're talking to. It looks like your inverter is just telling us its model is "", which means we don't know what we're talking to.

Can you get yourself set up with modpoll, and take a look at holding registers 30000-30015:

modpoll.exe -m tcp -0 -1 -t 4 -a 247 -r 30000 -c 15 192.168.1.150

[canton7]

@TonyM1958 it looks like you started figuring out the G2 register map. Did you get far with it?

[TonyM1958]

Not really, I don't have access to a G2 model to do any testing. I use input registers instead of holding registers for my HA integration. Must admit, I assumed/hoped the registers map would be the same...!

One way to check might be to install my integration and see what sensors are available. You can just uninstall and install yours immediately after, if that helps?

[canton7]

@TonyM1958 I can see some registers labelled "G2" in your spreadsheet. Where did you get those from?

It looks like the G2 isn't responding to input registers at all (or at least, it didn't like reading input register 10016, but it was happy reading holding register 30000), so I suspect that won't help unfortunately!

[TonyM1958]

Looked back at the data I used. The file is here: https://github.com/TonyM1958/HA-FoxESS-Modbus/wiki/Data-Sheets,-Manuals-and-Videos#references

The Fox AIO H1 modbus 2023 is the one. These registers are highlighted in the file and the file is dated 2023. They don't exist on H1 and are different on KH, so I surmised that the highlighted registers are new and that they might relate to H1-G2. The addresses are shown in pink in the spread sheet as they have not been verified as I haven't come across a product where you can read these (yet). Equally, they could be related to a new version of firmware.

Worth noting the SoH and battery capacity are also included here, which are now popping up in the Fox App v2.0 so must originate somewhere. I haven't tried to track these down just yet.

[TonyM1958]

BTW - the file lists input and not holding registers, so it does not tally with the hypothesis that H1-G2 is like KH. The overlap in registers between this file and KH has been identified as PV3 and PV4, which aren't available on H1 or H1-G2 in any case. Confusing isn't it...

[jHamshaw]

Here you go Input, then holding for each:

- Input and holding register 10016

error: >-
Error reading registers. Type: RegisterType.INPUT; start: 10016; count: 1;
slave: 247 from tcp://192.168.1.150:502: Exception Response(132, 4,
IllegalAddress)

error: >-
Error reading registers. Type: RegisterType.HOLDING; start: 10016; count: 1;
slave: 247 from tcp://192.168.1.150:502: Exception Response(131, 3,
IllegalAddress)

- Input and holding register 30016

values:
"30016": 13872
values:
"30016": 13872

- Input and holding register 11000

error: >-
Error reading registers. Type: RegisterType.INPUT; start: 11000; count: 1;
slave: 247 from tcp://192.168.1.150:502: Exception Response(132, 4,
IllegalAddress)

error: >-
Error reading registers. Type: RegisterType.HOLDING; start: 11000; count: 1;
slave: 247 from tcp://192.168.1.150:502: Exception Response(131, 3,
IllegalAddress)

- Input and holding register 31000

values:
"31000": 1920
values:
"31000": 1927

- Input and holding register 32000

values:
"32000": 0
values:
"32000": 0

- Input and holding register 41000

values:
"41000": 0
values:
"41000": 0

[TonyM1958]

39002 - the first 8 words are 16 chars of an ASCII encoded byte string that reads H1-5.0-E-G2.
39108 - should be the serial number, probably encoded the same way?
39050 - model ID
39051 - number of string inputs
39052 - number of MPPT

That's about as far as I can go for now, unfortunately.

[jHamshaw]

39108 - should be the serial number, probably encoded the same way?

Or maybe not....

values:
"39108": 0
"39109": 0
"39110": 0
"39111": 0
"39112": 0
"39113": 0
"39114": 0
"39115": 0
"39116": 0
"39117": 0
"39118": 0
"39119": 37
"39120": 0
"39121": 0
"39122": 0
"39123": 0

[TonyM1958]

sorry, typo - 39018...

[jHamshaw]

39018 to 39025 each hold a 5-character number (39026 to 39033 are all 0) - I won't post my inverter serial number here for obvious reasons, but it's a 15-character alphanumeric string. I've reached my limits on how to decode the registers though....

[TonyM1958]

@jHamshaw PM me via the FB group (Tony Matthews) if you would like to see if we can get your inverter talking to HA?

[paultweedy77]

I'm going to have my H1-3.7-E swapped for a H1-5.0-E-G2 within the next few weeks. When that happens I'll be keen to get modbus working again very quickly, and will be on hand to prod the registers to try to create a new mapping, if Fox haven't generously supplied them themselves before that point..

[canton7]

Ooh awesome, thank you!

INVERTER_PROFILES specifies a regex for each inverter, which is matched against the model number (and also pulls out the capacity, needed for the force charge/discharge stuff).

During the setup flow, we read the model number, then find the inverter profile which matches, and store that (and the connection type and details) in the config.

On start-up, sensor.py/number.py/etc call create_entities which calls inverter_connection_type_profile_from_config, which pulls the InverterModel and ConnectionType out of the config, and uses that to find the InverterModelConnectionTypeProfile for that inverter + connection type. That gives us the Inv type and the RegisterType. These are then used when creating the entities (entity_factory.create_entity_if_supported), to select which entities are created and what address they have.

If you open a PR, I'm happy to take a look tomorrow.

[TonyM1958]

Always easier when you don't have the distraction of having to work for a living ;-)

Thanks to @jHamshaw for offering up his inverter as the guinea pig and putting up with a few iterations of trial and error. Hopefully, it will benefit a wider group of people in the long run.

[canton7]

I noticed some are marked as input registers (e.g. foxess_inv1_eps_current_r). Are those also readable as holding registers, or do we need to do a mix of input and holding reads?

[TonyM1958]

The main registers are all holding - apart from the inverter settings - so anything else is just copy and paste errors.

I've amended the files to remove the incorrect inputs. Some of them may read OK but there were outstanding questions I had about the accuracy of the EPS sensors that we didn't investigate as the main sensors were OK. Hopefully, testing against a wider base will throw up any other discrepancies.

[paultweedy77]

#585 for a first go..

Most entities that @TonyM1958 and @jHamshaw mapped seem to work.. a couple of nonsensical values (InvBatVolt 300V.. really? although I have just added a new ECS2900 slave so maybe that's expected)

Can't get charge periods or the charge period card to work. But at least I've got real-time data coming out..

[jHamshaw]

I’d recommend a firmware upgrade first - those versions are quite old.I’m currently on Master 1.21, Slave 1.02 and Manager 1.32 and£ there are still bugs in forced export and Agile integration - another update is due this week - I have a ticket raised and waiting….On 5 Apr 2024, at 16:12, Paul Tweedy ***@***.***> wrote: hi @TonyM1958 - My H1-5.0-E-G2 was installed today, up and running. Master 1.18, Slave 1.02, Manager 1.28. Currently digging around in the holding registers trying to make some sense of what's there. —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: ***@***.***>

[jHamshaw]

H1-5.0-E-G2 Inverter firmware >v1.32 (due imminently) is awaited to fix bugs - inability to set force discharge mode and in cloud Agile integration so could be linked…….On 6 Apr 2024, at 00:35, Paul Tweedy ***@***.***> wrote: #585 for a first go.. Most entities that @TonyM1958 and @jHamshaw mapped seem to work.. a couple of nonsensical values (InvBatVolt 300V.. really? although I have just added a new ECS2900 slave so maybe that's expected) Can't get charge periods or the charge period card to work. But at least I've got real-time data coming out.. —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: ***@***.***>

[canton7]

Thanks to @paultweedy77 and @TonyM1958, a first stab at support has just been released in v1.10.2b5.

Please let me know if you find any issues with that pre-released.

Thanks!

[canton7]

@paultweedy77 Would you mind checking the _today and _total sensors (e.g. solar_energy_today)? The H3-Pro spec I have uses the same new registers as the G2, but the scale is 10x more than @TonyM1958's YAML file. So I'm wondering whether we accidentally have those values 10x too large.

[TonyM1958]

I'm reading the registers at 32000, 32002, same as H1. The new 32-bit energy registers with gain x 100 are at 39601, 39603 etc, if that's the ones you mean? Those addresses didn't respond on H1_G2 when we were looking.

Lots of things in the modbus 'v2' spec didn't work on H1_G2. I think the spec is a goal rather than a statement of fact and H1-G2 is a hybrid / partial implementation. I can't rule out a firmware update that moves the modbus spec more towards v2 over time though??

[paultweedy77]

They both look ok I think, if I look at the history this week, after Friday (when my inverter was upgraded), they seem to be scaling in the same way as before:

Slightly trickier to compare solar_generation_total as that reset with the new inverter but looks to be scaling in line with the generation:

Certainly doesn't look 10x out..

[paultweedy77]

An update on the large values I've been seeing on PV1 Power & PV2 Power registers on my new H1 G2..

Two random samples, seconds apart, just now:

[39282]: 	65528 (-8)
[39283]: 	0
.....
[39282]: 	65532 (-4)
[39283]: 	0

Also definitely present on the old 16 bit registers at the same time:
[31005]: 65525 (-11)

They can occur at any time in the night, mainly on PV2 Power but sometimes on PV1 Power. I wonder if they're triggered by variations in marginal DC input after the sun has set waking up/shutting down an MPPT... More an annoyance than anything serious but definitely behaviour that wasn't present on my H1 G1.

[canton7]

Aah, so looks like they defined it as a 2-register value, but only actually implemented one of the registers...
If we change the config to only read the lower register, thay should sort it out.

[paultweedy77]

Now the sun's out (I had the registers wrong in my comment above):

PV1:
[39279]: 	0
[39280]: 	586

PV2:
[39281]: 	0
[39282]: 	1797

[TonyM1958]

Looking like it's only a partial implementation of modbus v2 and they kept a lot of the modbus v1 registers. Have a look at:

[31000] PV1 Voltage
[31001] PV1 Current
[31002] PV1 Power
[31003] PV2 Voltage
[31004] PV2 Current
[31005] PV2 Power

These should read correctly as 16-bit int. Looks like they just copied the 16-bit power values to the new registers without extending them to 32-bits.

[paultweedy77]

Created #590 to remove upper registers for PV1 & PV2 power reads.

[paultweedy77]

Another difference discovered tonight - at least on firmware 1.18, the G2 doesn't support Back-up work mode.
You can set holding register 41000 to '2', but it does nothing.
Confirmed that the inverter settings menu only contains Self Use, Feed-in First and Peak Shaving options.
@jHamshaw does yours look any different?

[canton7]

The new KH firmware is the same - although I think there was going to be a firmware update to fix that.

[jHamshaw]

I’m up to v1.32 already with another update due this week to fix issues with force discharge and Octopus Agile function in Fox ESS Cloud - neither of which work but at least appear now  - it all seems to be a bit of a “work in progress” still….Jim On 7 Apr 2024, at 23:49, Paul Tweedy ***@***.***> wrote: Another difference discovered tonight - at least on firmware 1.18, the G2 doesn't support Back-up work mode. You can set holding register 41000 to '2', but it does nothing. Confirmed that the inverter settings menu only contains Self Use, Feed-in First and Peak Shaving options. @jHamshaw does yours look any different? —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: ***@***.***>

[paultweedy77]

Agreed, definitely early days (again) with the G2.
Back-up mode is easy enough to replicate by setting the discharge rate to 0A so not a biggie for me at the moment, just another ‘quirk’.

[jHamshaw]

On 7 Apr 2024, at 23:49, Paul Tweedy ***@***.***> wrote: Another difference discovered tonight - at least on firmware 1.18, the G2 doesn't support Back-up work mode. You can set holding register 41000 to '2', but it does nothing. Confirmed that the inverter settings menu only contains Self Use, Feed-in First and Peak Shaving options. @jHamshaw does yours look any different? —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: ***@***.***>

[jHamshaw]

[paultweedy77]

Another potential G2 firmware difference. Not relevant to the integration but worth knowing anyway.

On my H1 G1, Max SoC used to limit the timed force charge from grid so it wouldn't go beyond what you set it to. Then it would dump any PV excess into the battery (under Self Use).

Now Max SoC seems to to the opposite; it doesn't limit the force charge from grid (my batteries charged to 100% last night despite Max SoC being set to 50% as I knew today would be sunny), but does limit battery charging from PV; if current SoC is > Max SoC, any excess is exported, even under Self Use. If I set it above current SoC, the battery charges.

Haven't tested Force Charge work mode yet (instead of time periods) to see if that behaves any differently.

[FozzieUK]

I’ve also had that reported about the KH as well - maxSoC doesn't limit grid charge, but does limit solar PV - I had been told this should be ‘fixed’ shortly in KH so this may only be a temporary ‘feature’ 😉

[TonyM1958]

it's not been working on H1 either since they introduced Force Charge work mode. The way I've heard most people are working around this is to set a schedule that spans the time of their cheap rate with Self Use and fdMin_Soc set to 50%, for example. If the battery is above the target SoC at the start of the period, it will be consumed and reduce grid usage. If the battery is lower than the target, it will slowly charge up and the house load will use the grid. Sounds simple, but it's a pretty effective way to get a target SoC and optimises the use of residual energy in the battery.

[canton7]

Max SoC on the H1 doesn't work if you use strategy periods, but it does still work with normal charge periods.

The problem there is not with Max SoC per se, but with the fact that strategy periods use remote control, and remote control doesn't respect Max SoC.

Also note that Force Charge as provided by this integration does respect Max SoC.

[jHamshaw]

On the basis of tickets I have open for my H1 G2  (unable to force discharge) I’m not sure Fox UK support even realise that as they don’t seem to understand how my current settings are even working (but they are!) I can't even set MaxSoC - for Force Charge or Self Use - I get an error code 40257-Parameter does not meet expectations….  I can't set a Force Discharge period at all - same error code... 

[jHamshaw]

Update - a full shutdown and restart of my inverter, BMS and PV in the (correct order) after V1.32 was installed has sorted my inability to set force discharge mode!

[jHamshaw]

Could that be an issue on my inverter (can’t set forced discharge) that needs fixing? Remote control = 1 in ModBus but can’t be changed on inverter front panel as nothing under that menu option…. No documentation that I can find either….

[canton7]

I'm not aware of any way to control the remote control using the front panel.

[jHamshaw]

Does anyone know what the Remote Control settings actually do?

[canton7]

Yes, and this integration uses those registers to provide intelligent "Force Charge" and "Force Discharge" work modes.

The fact that you're seeing those entities at all means that you're not using this integration.

[jHamshaw]

I'm currently using the TonyM1958 integration (I helped with registers etc. while he updated it at his request) as this one didn't work at all when I got my G2 inverter in February. Has it been updated to support H1 G2 (it's still not listed in supported models) now? Regardless of that, I still can't even set a force discharge period simply using Fox or ES apps either...."Write Error" ....

[TonyM1958]

The integration is read only for all registers so is just reporting the values. That's how I noticed Fox are using remote control for strategy periods, as the registers change to match your Force Discharge when it runs.

[canton7]

It looks like someone has Illegal Address trying to read the serial number on a G2: #594 (comment)

Any ideas, anyone?

[canton7]

Wait a sec, why is it even trying to read 11000. I'll take a proper look when I'm at a computer.