Load power with second inverter

[TonyM1958]

When an other solar inverter is connected to CT2, the load power sent by the inverter, detected by CT1 is incorrect as the second inverter is adding power into the load / grid.

To correct this, you need to add the power reported by CT2 to the load power reported by the inverter to give the correct load power.

You may also want to add the power from CT2 as another solar source and possibly integrate and add this into the total yield to get the overall yield from both inverters.

[alpriest]

I've been looking at this but can't see the CT2 load power reported from FoxESS. Do you have any idea which parameter it is?

[TonyM1958]

Looking at foxesscloud.com, it is the power from the second inverter in the power flow. In the fox app, it's the power from the top inverter.

In the drop down list of variables, there are 2 called MeterPower and Meter2Power. The first is also known as Grid_CT / CT1 and the 2nd is CT2 in the HA integrations for single phase inverters. Where CT2 is not in use, I expect Meter2Power to return 0, so I think its safe to incorporate this into the load power irrespective of whether its connected or not.

There is also R, S and T versions of LoadPower and MeterPower for 3 phase inverters. There is an option to connect a second meter to a 3 phase inverter (equivalent to CT1 and CT2) but I don't currently have a good example of how these might affect the 3 phase inverter load power.

[TonyM1958]

I scanned the fox cloud raw data and pulled out the json variables list:

"variables": ["pv1Volt", "pv1Current", "pv1Power", "pvPower", "pv2Volt", "pv2Current", "pv2Power", "pv3Volt", "pv3Current", "pv3Power", "pv4Volt", "pv4Current", "pv4Power", "epsPower", "epsCurrentR", "epsVoltR", "epsPowerR", "epsCurrentS", "epsVoltS", "epsPowerS", "epsCurrentT", "epsVoltT", "epsPowerT", "RCurrent", "RVolt", "RFreq", "RPower", "SCurrent", "SVolt", "SFreq", "SPower", "TCurrent", "TVolt", "TFreq", "TPower", "ambientTemperation", "boostTemperation", "invTemperation", "chargeTemperature", "batTemperature", "dspTemperature", "loadsPower", "loadsPowerR", "loadsPowerS", "loadsPowerT", "generationPower", "feedinPower", "gridConsumptionPower", "invBatVolt", "invBatCurrent", "invBatPower", "batChargePower", "batDischargePower", "batVolt", "batCurrent", "meterPower", "meterPower2", "meterPowerR", "meterPowerS", "meterPowerT", "SoC", "ReactivePower", "PowerFactor"]

From this, it looks like you need to add the one called "meterPower2" to your query?

[alpriest]

I just tried an account with multiple inverters (H1-6.0 and F3000). For that setup the H1-6.0 the meterPower2 is showing negative values so if I sum that with the house load I should get the correct load from that inverter I think. I'll give that a go this week.

[TonyM1958]

At least you have a non zero value to work with now..

The example I've seen using HA data: load power from the inverter was negative and CT2 was positive, so adding CT2 to inverter load power produced the correct load power in HA.

Fox appear to do some fix ups somewhere between the inverter and the cloud data, as the user was saying the load power in the cloud was correct when raw data in HA was negative. But, if this is correct, why are the values in Energy Stats wrong...

Best to look at the data displayed in the Fox app and also foxesscloud alongside your query data to see if you can work out what to adjust to align things?

[alpriest]

I've been trying this today based on our FB conversation. I have access to an account with two inverters (F3000 and H1-6.0-E).

I can get Energy Stats to mirror FoxCloud 100% for both inverters in the energy flow from the loadsPower variable without using the meterPower2 variable. Energy Stats doesn't display the second inverter on the flow screen which is providing power.

If I sum the meterPower2 (negative) and loadsPower (positive) then I get a loads total different than Fox cloud so I think i'm missing something.

[TonyM1958]

OK, I just replied to your previous comment on FB, but let's continue here as its all a bit technical for a general audience.

Obviously, there is something about the setups with 2 inverters we don't understand, as the screen shots showed -ve load power but you are not seeing that. May need to put out a release that doesn't change loads Power and ask for feedback to try to narrow things down.

I wonder if it's as complex as whether the solar inverter is Fox and has a datalogger so they make adjustments to the cloud data for inverters in the same site? How many inverters do you see on your test account?

[alpriest]

Here's a snapshot of the two inverters on my secondary account (a helpful user provided me their login to narrow down this stuff).

Currently i'm reading home usage as:

raws.currentValue(for: "gridConsumptionPower") + raws.currentValue(for: "generationPower") - raws.currentValue(for: "feedinPower")

This seems overly complex as raws.currentValue(for: "loadsPower") seems to get the same value as Fox. I think you're right to put out a new version with this and the change for solar = hasPV ? pvPower : meterPower2 which will bring back the solar feed for multiple inverter users.

[TonyM1958]

Generating is inverter output, so I think H1 is using excess generation to charge the battery in that snapshot.

One option would be to have a setting, off by default, to add meterPower2 to loadsPower for people who's load goes negative. They can switch it on if needed, rather than trying to work out all the different scenarios?

[TonyM1958]

BTW, in your Home usage calculation above, the missing element is meterPower2 or generationPower from the solar inverter(should be same thing) as these are all connected to the same node. I wonder if your value goes negative because this isn't included, where Fox are adding this to their loadsPower in the cloud because they see both inverters in the same site and/or see CT2. You may be able to check this against the data in your test site?

I think you may still see a negative value if the second inverter is not in the Fox cloud?

[alpriest]

My second account has both inverters in the Fox cloud.

The H1-6.0-E shows meter2Power: -1.228 pvPower: 1.6219999999999999 loadPower: 0.722

And this is what I'm showing on my dev build.

This obviously feels wrong that the solar is generating less than the battery amount. If I add the absolute meterPower2 to the 'pvPower' for solar then I get this which seems closer.

I suspect as you say it might be best to have some of this as toggles for a user to select for their own configuration as there are clearly complexities not handled by the cloud for some of this.

[TonyM1958]

One of the problems with meterPower2 is that there isn't a good way to tell if CT2 is on the right way around. I suspect Fox detects which way around the clamp is and reverses the polarity in software - so in the example above meterPower2 should be +1.228 not -1.228 ?

[TonyM1958]

An extreme example however, would when CT2 is attached to monitor a remote feed, such as a garage where there is both an inverter and a local load at the other end of the cable. In this scenario, CT2 would read +ve for generation during the day but could be -ve at night if, for example, a fridge or freezer was plugged in in the garage... so there could be an element of what time of day it is when deciding whether to reverse CT2 as you would not want to show generation at night.

No real idea how Fox would handle this though...

[TonyM1958]

Again, most flexible option might be a switch to flip polarity of CT2 / meterPower2. Could be a garage with an EV charger on the other end...

Not sure if you would need to add CT2 to load power and zero generation if it goes negative when the polarity is correct for generation as I don't have any examples of this.

[TonyM1958]

So, I looked at this and decided there was no reliable way to detect if CT2 was reversed. For my Fox Cloud python code, I'm going to add a global setting you can configure that flips CT2 if required.

Looking at the load, I decided, if you need to add CT2 to load, use the abs value for this, so it adds when generating and if the load reverses. For total PV, I ignore negative CT2 values and just add positive values to PV generation. This means, if there is a load at the far end of the cable CT2 monitors, this adds to the load when negative but not to the generation...

I dont think there is 100% right answer? Fix what works for you and put it out there - there are too many use cases and not enough test cases for everything to be fully tied down.

[alpriest]

I’ve just pushed 1.58 to the Play Store review. It updates to use pvPower + meterPower2 (inverted based on a config toggle).

Al

On 29 Aug 2023, at 19:04, TonyM1958 @.***> wrote:

So, I looked at this and decided there was no reliable way to detect if CT2 was reversed. For my Fox Cloud python code, I'm going to add a global setting you can configure that flips CT2 if required.

Looking at the load, I decided, if you need to add CT2 to load, use the abs value for this, so it adds when generating and if the load reverses. For total PV, I ignore negative CT2 values and just add positive values to PV generation. This means, if there is a load at the far end of the cable CT2 monitors, this adds to the load when negative but not to the generation...

I dont think there is 100% right answer? Fix what works for you and put it out there - there are too many use cases and not enough test cases for everything to be fully tied down.

— Reply to this email directly, view it on GitHub https://github.com/alpriest/EnergyStats-Android/issues/3#issuecomment-1697903517, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABWAOM5BTAL3FSHC76236LXXYVLVANCNFSM6AAAAAAYV44R5M. You are receiving this because you commented.

[TonyM1958]

Thanks - I've downloaded and installed this. The power values look correct for my setup, compared to what Home Assistant is showing me. I have H1-6.0-E, CT2 is not connected.

HA is telling me my solar yield for today is 3.1 kwh and EnergyStats is telling me 6.1 kwh though - so it look like it might be double counting the yield?

Stats page says my output energy is 6.2 kwh and that agrees with HA, so I guess it's the same number rather than my PV generation being shown on the power flow screen?

[TonyM1958]

Also - when I go into inverter settings and toggle 'show inverter icon', 'invert CT2' toggles with it - either they are the same or the wrong toggle is being displayed?

[TonyM1958]

if you are doing updates really minor, but the device ID text clashes with the label. Suggest either wrapping across 2 lines or not showing the device ID as I don't think the end user can really do anything with this?

I'm also not clear what Module Serial No should be - I get unknown. Should this show the serial number of the data logger?

[alpriest]

The toggle was a copy/paste error. I duplicated the toggle code but forgot to update the underlying variable it modified. Fixed in 1.59.

Can you attach a screenshot of what you mean with the clashing please, it wraps two lines already according to the previews I see in Android Studio.

The Module Serial Number is returned in the response from https://www.foxesscloud.com/c/v0/device/addressbook?deviceID=<###>. I'm not sure what these things actually are but was asked by a couple of people to show them.

[TonyM1958]

Here's what it looks like for me - just looks a bit untidy? Don't know if you could wrap in the middle or add a space at the end of label so it looks better?

The module serial number is present in the data logger info and I see it when I query my inverter device info but it shows as unknown here.

has Battery is also True in my cloud data?

[alpriest]

Can you try log out and back in please to see if that resolves the module SN issue?The latest version has a small gap between the label and device ID, which may help a little. I should also vertically align the rows.On 31 Aug 2023, at 14:16, TonyM1958 @.***> wrote:

Here's what it looks like for me - just looks a bit untidy? Don't know if you could wrap in the middle or add a space at the end of label so it looks better? The module serial number is present in the data logger info and I see it when I query my inverter device info but it shows as unknown here.

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: @.***>

[TonyM1958]

No problem, that definitely helps. Presumably something was being cached?

I've seem you tell people to do this a few times, is there anyway to force a refresh?

[alpriest]

There’s no easy way unfortunately. I added an additional stored field (hasBattery). On iOS if that doesn’t exist in the stored version of the Inverter object then it fails to fetch it, I detect that and then fetch the inverter again. On Android it silently sets the Boolean to false when it doesn’t find that field, so I can’t differentiate between a legitimate false and a bad decode becoming false.On 4 Sep 2023, at 09:07, TonyM1958 @.***> wrote: No problem, that definitely helps. Presumably something was being cached?

I've seem you tell people to do this a few times, is there anyway to force a refresh?

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: @.***>

[TonyM1958]

Do you cache the user credentials in the back ground? I store the time when I get the token and refresh the token if its more than 1 hour old. That seems to avoid the problem Fox has when you get token no longer valid.

Just wonder if you could do something similar and force a logout to clear the cache and then login in the background periodically. It doesn't seem to take long, so might not be a big overhead?

Obviously, this might fail if someone changed their password but you'd need to ask them to enter it again anyway.

[alpriest]

Yep, the credentials are cached and then I relogin silently if I get a 401 Unauthorised from the server and retry the original request. So if Fox change their token validity period it will automatically refresh at the new duration.

Due to the way I stored the data if I log someone out then they would lose their battery capacity override as it's stored in the same model, and then it becomes impossible to differentiate between the user-overridden value and a potentially different value from the server. Easiest just to reply to FB for folk to relogin in this instance then they're in control.

[TonyM1958]

So, presumably, they loose the over ride anyway when they logout and back in again. Guess it's hard to tell how many people actually use the over ride - I did to start with but it always seem to get the right value these days.

You can't grab the over ride, logout, login and restore it? Or have a button to remove cached data that logs out and back in again - just to avoid putting people that can't remember their password through the login again?

[alpriest]

I’ve modified the apps to externalise the storage of the override value and reload the device list and firmware versions on cold start.

Anyone who had overridden it will lose their values when they upgrade but they can just enter it again.

On 4 Sep 2023, at 09:50, TonyM1958 @.***> wrote:

So, presumably, they loose the over ride anyway when they logout and back in again. Guess it's hard to tell how many people actually use the over ride - I did to start with but it always seem to get the right value these days.

You can't grab the over ride, logout, login and restore it? Or have a button to remove cached data that logs out and back in again - just to avoid putting people that can't remember their password through the login again?

— Reply to this email directly, view it on GitHub https://github.com/alpriest/EnergyStats-Android/issues/3#issuecomment-1704868613, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABWAOISRO23E2UBQ2JOB4DXYWI6RANCNFSM6AAAAAAYV44R5M. You are receiving this because you commented.

[TonyM1958]

Sounds good. There must be a restart / cold start whenever the app is updated. Hopefully it will significantly reduce the number of times you have to tell people to logout and back in again if their data looks wierd.

[TonyM1958]

To summarise what we found looking at Sam's data: if CT2 is the wrong way around, Fox calculates the loadsPower incorrectly and you have to reverse CT2 to fix this.

When loadsPower works as expected, meterPower2 in the cloud reads a negative value - so you need to invert the value to be able to show the solar generation correctly. as loadsPower doesn't work the wrong way around, you may as well remove the option to flip CT2 and hard code the inversion?

This is what I have now done in my code to generate PV Output. I don't invert the raw values that are returned by Fox as I think this would just add to any confusion about that the underlying data looks like. I only use the negative values if I calculate the energy generated via CT2 and ignore any postive values.

Does that make sense?

[TonyM1958]

I've asked Richard Bagshaw for some data from his system as it has HA and 2 x inverters with CT2 connected. Here's what it looks like.

This is HA showing the raw CT2 sensor data and the Load Power after CT2 has been added to it. Here CT2 is +ve when the second inverter is generating:

This is the same data collected from the Fox cloud in EnergyStats:

It's quite a dull day today, but you can clearly see that Fox has inverted Meter2Power compared to the data coming into HA directly from the inverter. Both have Load Power fixed compared to what is coming directly from the inverter.

So, this is why I was confused before... This confirms that the default behaviour for data from Fox Cloud should be to invert CT2 to get the solar generation from the second inverter.

Richard has both inverters available in Energy Stats so I wondered what the best way might be to display data in EnergyStats?

One option to consider might be, instead of the switch to flip CT2 for the main inverter, you could have a switch to enable / disable inclusion of CT2 in the solar generation you show in the power flow screen. By default, the switch would be on (so it shows generation associated with AC inverters), but users with 2 inverters would have the option to only show solar generation from the main inverter if they wanted?

Alternatively, you could show a break down of the solar generation - what power is coming from PV and what power is coming via CT2 (e.g. when inverted CT2 is making a +ve contribution to generation) on the power flow screen so it's more obvious what people are looking at?

[alpriest]

I think having the transparency of a CT2 source on the power flow page is probably the most clear. With an option to aggregate (as current) or not.

[alpriest]

I've added a separate CT2 indicator in the latest version. I've also fixed a bug whereby the CT2 values weren't being inverted if your inverter hasPV == false.

I can't seem to determine when to show the CT2 feed automatically so if it's enabled then it appears.