H3 load power is incorrect

[benbeton]

currently there is no sensors which represents the current energy usage in W (regardless of whether the energy is drawn from the grid, the PV system or the battery. ) for the Fox H3 Inverters

tried this one for "house usage", but there seems to be missing something: should be equal to sensor.foxess_load_power (FoxESS Cloud integration) but is not (close but not complete)

- name: "fox house energy current"
        unique_id: fox_house_energy_current
        unit_of_measurement: 'kW'
        device_class: power
        state_class: measurement
        state: >
          {{ ((states('sensor.fox_grid_consumption') | float(default=0)
          + states('sensor.fox_pv_power') | float(default=0)
          + states('sensor.fox_battery_discharge') | float(default=0) ))
          - states('sensor.fox_battery_charge') | float(default=0)  | round(2) }}

following can be combined with a template sensor:
Grid usage

- name: "fox Grid Consumption"  #positive or zero
        device_class: "power"
        unit_of_measurement: "W"
        state_class: measurement
        state: >
               {{ (states('sensor.fox_grid_consumption_r') | float(default=0)
               + states('sensor.fox_grid_consumption_s') | float(default=0)
               + states('sensor.fox_grid_consumption_t') | float(default=0)) | round(2) }}

Feed In

- name: "fox Feed In Power"  #positive or zero
        device_class: "power"
        unit_of_measurement: "W"
        state_class: measurement
        state: >
               {{ (states('sensor.fox_feed_in_r') | float(default=0)
               + states('sensor.fox_feed_in_s') | float(default=0)
               + states('sensor.fox_feed_in_t') | float(default=0)) | round(2) }}

Load Power

- name: "fox Load Power"
        device_class: "power"
        unit_of_measurement: "W"
        state_class: measurement
        state: >
               {{ (states('sensor.fox_load_power_r') | float(default=0)
               + states('sensor.fox_load_power_s') | float(default=0)
               + states('sensor.fox_load_power_t') | float(default=0)) | round(2) }}

would be great if we complete the sensors together

[canton7]

There seem to be a number of things going on here.

currently there is no sensors which represents the current energy usage in W (regardless of whether the energy is drawn from the grid, the PV system or the battery. )

Yes there are. Energy drawn from the grid is grid_consumption_R/S/T, energy from the PV system is pv_power_now, energy to/from the battery is battery_charge / battery_discharge

The power taken by your house is load power. This is exposed by this integration load_power_R/S/T.

but is not (close but not complete)

This missing piece is that the inverter is not 100% efficient. The difference between your sum and load_power will be the inverter losses.

[benbeton]

thank you @canton7 maybe I expressed myself wrong, there is not one sensor that displays the current consumption of the house. individual sensors do that as e.g for the consumption from the grid or from the battery.

I also thought that *.load sensors should show the load of the house, but on my side its not, maybe there is a bug here!?
the sensors shows that:

although the current load is:

the load sensors showing strange values:

against it, load from FoxESS Cloud: (which is correct)

if, *.load sensors has the correct values, then they can be combined, any ideas!?

[canton7]

Interesting, yes that doesn't look right.

On a hunch, can you take a look at Grid CT R/S/T? I wonder whether those two have got mixed up.

@TonyM1958 FYI

[benbeton]

Grid CT is showing values, but combined these are not near the correct value:

Grid CT

Load FoxESS Cloud

Inverter Power seems to be near, but also not correct and I think that's not the correct value:

[mafischerhei]

Ben, can you have a look at my recent post. I think we have a similar "problem":

I think there's a miscalculation in the code for some entities which prevents us from calculating the correct house load

please have a look -> #456
Thanks

[benbeton]

thanks @mafischerhei looks promising - i'll follow you thread!

[TonyM1958]

Do you just have 1 x H3 inverter or do you have another solar inverter connected as well? A second inverter will throw out the sensor values on the H3 so its best to understand this first.

[benbeton]

it's just 1 H3 Inverter

[TonyM1958]

Thanks, connected to a Chint meter sitting in line with you grid supply, or is it connected via current transformers?

[benbeton]

there is a Chint DTSU666 sitting in line

[TonyM1958]

OK, just to confirm, you are getting the correct R S T power values for your grid consumption and feedin to/from the grid?

From what I know of the sensors on the H1 inverter, Fox may not actually use the inverter load power sensors when the data gets to the cloud because they are not correct in all circumstances. For example, when you add a second inverter, the load power sensor on the inverter returns a -ve value but the Fox cloud returns a +ve value.

For H1, the load power calculation in the cloud may be (Output Power - Grid CT + CT2), where Grid CT is positive for export and -ve for import. This is the sum of the power going through the henley block, so there are no conversion losses (but sampling errors are possible).

The same may apply to H3...

Here's an example of some code I wrote to derrive load power and compare against the inverter value for H1:

    - name: "Load Power X"
      device_class: "power"
      unique_id: foxess_inv1_load_power_x
      unit_of_measurement: "kW"
      state: >
        {% set rpower = states('sensor.rpower') | float(default=0) %}
        {% set spower = states('sensor.spower') | float(default=0) %}
        {% set tpower = states('sensor.tpower') | float(default=0) %}
        {% set ct2 = states('sensor.ct2') | float(default=0) %}
        {% set grid = states('sensor.grid_ct') | float(default=0) %}
        {% set rgrid = states('sensor.meter_rpower') | float(default=0) %}
        {% set sgrid = states('sensor.meter_spower') | float(default=0) %}
        {% set tgrid = states('sensor.meter_tpower') | float(default=0) %}
        {% set result = rpower + spower + tpower - grid - rgrid - sgrid - tgrid + ct2 %}
        {{ result }}

And an example of how this tracks the inverter load sensor for the H1 base case:

You can try to calculate Load Power RST separately as well, but I don't think it will be correct if a second inverter is also connected as you don't have Meter2 Power RST values.

[TonyM1958]

BTW - no idea what this means in terms of accuracy for Load Energy Today and Load Energy Total counters on the inverter. I don't think anyone has yet done long term tracking of these counters for more complex cases...

You can do a similar derrived load energy calculation based on Output Energy, Input Energy, Grid Consumption and Feedin Energy but you don't have an energy counter for CT2 / Meter 2. You could try to get generation energy directly from the second inverter, and that total will only be correct if the inverters were installed at the same time?

[benbeton]

I do only have one inverter, there has to be a register for the correct load.
for my understanding, this integration has a good register mapping for the H3 inverters, from what aI can see is for example:

31029 should be "Load Power R" but in this repo, its not tagged with H3

31030 should be "Load Power S" and is tagged here with H3:

source:

foxess_modbus/custom_components/foxess_modbus/entities/entity_descriptions.py

Line 38 in 300dacf

ModbusAddressSpec(models=[H1, AIO_H1, AC1, KH], input=11058, holding=31029),

could that be a cause?

[TonyM1958]

The registers are listed here: https://github.com/TonyM1958/HA-FoxESS-Modbus/wiki/Modbus-Map.xls

These include Load Power RST as 31029, 31030 and 31031. I thought you had already looked at these and concluded the values were incorrect?

If you think the registers are not mapped correctly in the integration then this is something @canton7 can investigate.

These still need to taken into account when calculating overall Load Power and the effects on this from CT2 / Meter2 Power injection.

[canton7]

I think you needed to click "find next" one more time?

foxess_modbus/custom_components/foxess_modbus/entities/entity_descriptions.py

Lines 803 to 814 in 300dacf

	ModbusSensorDescription(
	key="load_power_R",
	addresses=[ModbusAddressesSpec(models=[H3, AIO_H3], holding=[31029])],
	name="Load Power R",
	device_class=SensorDeviceClass.POWER,
	state_class=SensorStateClass.MEASUREMENT,
	native_unit_of_measurement="kW",
	icon="mdi:home-lightning-bolt-outline",
	scale=0.001,
	round_to=0.01,
	validate=[Range(-100, 100)],
	),

[TonyM1958]

Been running the calculated load power for a day now to compare with the base case sensor:

Load Power CT1 is the raw H1 load sensor. Load Power is the value calculated as follows:

There's s small adaptation here to stop the value going negative (due to sampling error) as the house load cannot generate. 300w was chosen arbitrarily as an approximation to an average house base load.

You can see around 10:15, the load power spikes up to 5kw but the calculated value spikes to 7kw due to sampling error. I added a filter, load_power_smooth, using a 30 second rolling average to see what it looks like if you smooth out spikes. The filter introduces a small lag in the data transients:

- name: load_power_smooth platform: statistics unique_id: foxess_inv1_load_power_smooth entity_id: sensor.load_power state_characteristic: average_linear max_age: seconds: 30 precision: 3

Combining the plots highlights the small differences...

A few options to consider, but it looks like calcuating load power to cover different configurations will work fine where the inverter sensors are not returning the correct values.

[TonyM1958]

Wondering if you might have a naming conflict in your system from some previous integration. Have you checked Settings, Devices & Services. Entities and searched for entities with Load in the name and looked for any names with _2 at the end?

[canton7]

I'm curious how you think a naming conflict could cause this?

[TonyM1958]

Probably a long shot, but if I've read the conversation correctly, you think Load Power RST are probably configured in the integration, but the OP thinks the values are wrong. I've seen many cases where older code has created sensors and when a new integration is added the names unique id or integration name conflict so HA renames the new sensor with _2 at the end. You can end up looking at the old sensor instead of the new one. Just one thing to rule out but it might explain why this instance might not work when others do?

Other suggestions as to what might be going on or how to collect more data to diagnose welcome...

[canton7]

Looks like the Chint might be the culprit. Try restarting it. #371 (comment)

[benbeton]

I'll tried, cut off the power of the chint, still the same - but could a configuration mistake of the chint cause the sensor not to show the values?!

[vip-klaus]

@FozzieUK thanks for the tip. I deleted the lines in the file and restarted HA. I won't be able to say until tomorrow whether it works, as the problem only occurs when the battery is massively charged.

But there must also be a problem with the inverter_current_r/s/t: On the screenshot you can see that inverter_current is around 1.4A, even though the inverter_power is "0". If the actual inverter_power is actually negative, then the inverter_current should also be negative, right?

Greetings
Klaus

[FozzieUK]

ok, thanks - on the inverter current, with a single phase inverter the current is an absolute value (positive), I think the 3 phase is the same, hopefully that will be confirmed tomorrow when you can see the correct power readings.

[vip-klaus]

In the FoxESS app, the inverter_current values (RCurrent, SCurrent, TCurrent) can also become negative. This always happens when the slave inverter delivers AC power to the master to charge the battery to the maximum.

I can give feedback tomorrow, but then I'll be on vacation for a week - without access to my computer.

More will come from October 1st.

Thank you again for your excellent support!

Greetings
Klaus

[TonyM1958]

What happens doesn't always work as you might expect as these are AC rather than DC values. Here's what you see on H1 with RPower and RCurrent when charging:

As you can see, RPower goes -ve when charging but RCurrent stays +ve. RVolt is positive for both charging and discharging - so you really need to follow the power values and not multiply volts and current. There are other registers that tell you stuff like real and apparent power - but mostly, people just go by the real power.

[canton7]

Let me know what you find -- I've got the change ready to go

[halfprice11]

hi folks,

I do face a similar issue - as I try to get rid of the FoxCloud, by building up a local view within home assistand.
Gid, Battery, Solar values are all fine.
Inverter Power does show the values, inverter power output is.

Tried to build something like this "flixlix

power-flow-card-plus

But correct home consumption is always wrong, as power consumption of the inverter is not used for calculation.

so same on my side: load_Power_RST does have constant values not at all same as my house consumption.

just my view cents.

Found this:

is load power related to EPS only?

[vip-klaus]

Hello,

please excuse my late reply. With the two changes mentioned here in the entity_descriptions.py ('validate=[Range(-100, 100)]' // remove of: post_process=lambda x: max(x, 0)) the values for the inverter power now displayed correctly - including the negative values while charging the battery with additional power from the slave inverter!
The inverter current remains positive, although mathematically correct it should actually be negative. But it's the same with the FoxESS Cloud.
From my point of view, FoxESS-Modbus now works absolutely correctly!

Many thanks to everyone for the competent support!

Best regards
Klaus

[canton7]

Thanks! I'll get this released soon

[Lich2023]

I have one more question.
I read This:
https://github.com/nathanmarlor/foxess_modbus/wiki/Supported-Features

Is there still No Support for the H3 to Read/write charge periods and Read/write work mode, min/max SoC or does this now also Work with the H3 too?
I am also very interessted to so This with the H3:
https://github.com/nathanmarlor/foxess_em

Does this Work now for the FoxESS H3 correctly?
What modbus adapters can you prefer for the H3?

[Lich2023]

What about sungrow or goodwe...nur i dont know If the Funktion "load battery from grind " exists

[Lich2023]

I want to use evcc.

[calum-mcfarlane]

No idea I'm afraid! Probably best to contact the manufacturers first (or at least read up on their products) to find out what support they have for Modbus, MQTT, or whatever - ideally some kind of open standard that HA can use. Then you're not dependent on a specific integration per se. Searching on Github is a pretty good place to start if you are looking for projects developed for a particular brand of solar kit.

[TonyM1958]

You can give this a try if you wish: https://github.com/TonyM1958/FoxESS-Cloud/wiki/Running-in-Google-Colaboratory

This has been tested with H1 but not H3 (I believe the API calls are identical across Fox inverter models).

You don't need Home Assistant, as it uses the Fox ESS Cloud API to read and update your charge settings and, optionally, change work modes. By default, the code won't change any settings when you run it, but it will look at your generation and consumption and the state of your battery and recommend what charge might be needed. You should add Solcast so it has a solar forecast for tomorrow as it will then be a lot more accurate. Due to the limited number of API calls to Solcast, downloading forecast is restricted to certain times by default - but I can tell you how to update that if required and how to enable it to update your charge settings if you wish.

Here's an example of what it produces when I run it in Jupyter Lab / Colab:

[TonyM1958]

One thing worth noting: Google Colab sets local time to GMT but the code adjusts this to BST. If you are in a different time zone, add the parameter time_shift=n to the call to charge_needed. This disables BST and adds / subtracts the number of hours (n) you specify to GMT. Check the time is correct under Parameters when it runs, otherwise, the battery discharge and charge times will be off.

Charge times are configured via f.tariff, by default this is octopus_flux but you can change the tariff or setup custom_periods.

[benbeton]

what kind of template sensor do you guys use to monitor the current load of the house, whether the power comes from the grid, the battery or the PV system

[mafischerhei]

@benbeton : maybe you could try if this works for you, too?

#462

[mafischerhei]

Houseload

I think the easiest and most accurate results can be get by simply adding: (no matter if we have solar, solar export or battery power)
By just adding 6 sensors together I get very close results as the foxes app gives:
(Maybe we can have this sensor in this integration here as "household" with an update:

Grid Consumption R (foxess)

• Grid Consumption S (foxess)
• Grid Consumption T (foxess)
• Inverter Power R (foxess)
• Inverter Power S (foxess)
• Inverter Power T (foxess)

Done

(Would be even better to add all three Inverter ESP outlets, but as I can see we don't have those currently in this integration, do we?

EDIT: I made a little correction of my above calculation. You can have a look here:
#462

[canton7]

They're there, they're just disabled by default so you need to enable them.