Enphase Envoy's "Current battery discharge" sensor has incorrect values

[joergbattermann]

The problem

Good morning,

I haven't used the " Current battery discharge" until trying to use it just now and I noticed that its values are consistently off by 1 kW or so from what Enphase (Enlighten) reports (and also what the individual batteries' *_power sensors cumulatively report), see i.e. this:

or this:

... and the charge rates aren't fluctuating right now, meaning the number of that " Current battery discharge" sensor has been off by those several hundred watts consistently this morning. The batteries have not been charging at >4 kW the entire morning so far as per Enlighten, and yet that HA sensor says it has for a while now.

Maybe I am looking at the wrong sensor to see the aggregate batteries (dis) charge, but if it's supposed to show what goes in and out of them, then it appears it's not reading/providing the right value(s), at least not compared to Enlighten.

Is that a bug or am I using it wrong?

Thanks!

What version of Home Assistant Core has the issue?

core-2024.6.4

What was the last working version of Home Assistant Core?

No response

What type of installation are you running?

Home Assistant OS

Integration causing the issue

enphase_envoy

Link to integration documentation on our website

No response

Diagnostics information

No response

Example YAML snippet

No response

Anything in the logs that might be useful for us?

No response

Additional information

No response

[joergbattermann]

Some more info / update here: I also noticed that this particular sensor never really reaches / stays at or anywhere near '0kW', even though we are at 100% SoC usually around noon and then stay there for the rest of the afternoon (with the occasional 'dip' where the Enphase System charges another few wH for a minute or two). That particular sensor is during that time of the day always sitting at -1.something kW:

and

And semi-live / right now-ish it looked like this:

[home-assistant[bot]]

Hey there @bdraco, @cgarwood, @dgomes, @joostlek, @catsmanac, mind taking a look at this issue as it has been labeled with an integration (enphase_envoy) you are listed as a code owner for? Thanks!

Code owner commands

Code owners of `enphase_envoy` can trigger bot actions by commenting: - `@home-assistant close` Closes the issue. - `@home-assistant rename Awesome new title` Renames the issue. - `@home-assistant reopen` Reopen the issue. - `@home-assistant unassign enphase_envoy` Removes the current integration label and assignees on the issue, add the integration domain after the command. - `@home-assistant add-label needs-more-information` Add a label (needs-more-information, problem in dependency, problem in custom component) to the issue. - `@home-assistant remove-label needs-more-information` Remove a label (needs-more-information, problem in dependency, problem in custom component) on the issue.

_{^{(message by CodeOwnersMention)}}

---

enphase_envoy documentation enphase_envoy source _{^{(message by IssueLinks)}}

[catsmanac]

Hi @joergbattermann, can you upload your diagnostic file here after downloading it from HA

As the Storage CT is a recent add to the data, it would help if you can provide a couple of hours of debug log file for Envoy data collection while battery is charging/discharging to verify original assumptions on this.

[joergbattermann]

I turned debug logging for the last 1-2h of batteries charging earlier today.. and then about another 1-2h of them being mostly at 100% SoC during the afternoon... and I'll turn debug logging back on when we go into the evening and night to record / debug log what's happening and logged during the nightly discharge phase and will come back tomorrow with both files and also going to pull the Enphase Enlighten report data for today.

Is there any way to safely exchange files without exposing them permanently on the internet as part of a github issue & -discussion? I can gladly provide a temporary link which I can turn off once you confirmed you have the file, but if there's a usually used way to exchange those, lmk.

Thanks again @catsmanac !

[catsmanac]

Is there any way to safely exchange files without exposing them permanently on the internet as part of a github issue & -discussion?

I'm not really into how to do that, only method here I can think off is dropping the file here, me downloading it and you editing the topic again and removing the file again. But I'm not sure if that will remove the file also from the place where it was stored on github.

So if you have a method we might best use that.

[joergbattermann]

Ok will provide a shared link and we can do that (you letting me know once you got the file) - thank you! It's just before midnight here right now and I've had debug logging enabled as of circa 2-3hours again for the discharge phase.. but to give you a bit more/longer data, I'll just leave debug logging on overnight and provide the file from earlier today and this one in the morning.

[catsmanac]

Thats fine, thanks. Sleep well

[joergbattermann]

As I had mentioned, I kept debug logging on overnight until about 9:25am this morning, so you'll see the discharge dip down to about 43% or so this morning and then start going back up when the sun came out, see below. I was also trying to get the report from Enphase Enlighten, but somehow the data is not available there and I got to submit a support ticket with them first... so all I got is the graph representations below.

Either way, let me know if and what else you might need.. and thank you!

And this is what the graph as per Enphase Enlighten looks like for yesterday & this morning:

[joergbattermann]

Oh and here's the graph of the 'IQ Combiner 5 Current battery discharge' for the same time frame.. in which you can see that despite being at 100% SoC, the sensor says we had a somewhat continuous ~ -1.2kW reading on that sensor between noon and 7-8pm yesterday:

[catsmanac]

Thanks @joergbattermann , I just downloaded then successfully so you can close it again. Time for some number crunching. I'll keep you posted.

[joergbattermann]

Appreciate it, thank you @catsmanac !

[catsmanac]

Hi @joergbattermann, looking at the raw Envoy data there's indeed an offset in the Storage CT power reading. There's another battery power entity reported, real_power_mw which reports power from the battery data while current battery discharge comes from the Storage CT.

When I compare both, they have the same overall profile, but offset as you noticed. The Energy charged amount also slowly increases over the day while SOC is at 100.

So this is data reported by the Envoy. I think Enlighten app is using data from the batteries itself as they have access to way more data as we have. One would be inclined to think the Storage CT is not zeroed correctly, is picking up some noise or alike resulting in the non-zero value at rest. Might want to check with your installer if he can see what's going on.

I have all your data in a text file with only timestamps and values. Let me know if I should upload it here if you want to see it or in some other way.

Daytime power log

Nighttime power log

When comparing the battery SOC reported by ensemble and the Energy charge/discharge reported by the CT one can observe a continued amount of energy charged reported in the day when SOC reaches 100

Daytime energy changes

Nightime energy changes

[catsmanac]

Some side-notes from your data:

• Your Envoy switches every now and then between 2 IP addresses. I assume it's probably both on wired and WIFI. Depending on timing / order when it announces itself HA will switch to the other one. It's not an real issue unless one of the connections is shaky. In your case I see no real disturbances.
• Shortly after 11 PM there's a brief communication outage. That's a known behavior where the Envoy resets something internally or so and causes a timeout to happen. It happily resumes after it.

[joergbattermann]

Hi @catsmanac .. sorry for the slightly delayed reply. First of all thanks for the side-notes.. & yes I had the system connected to both, wifi and ethernet and turned the former off, so it's ethernet only now. I remember seeing in HA that the devices/entities becoming unavailable several times per day before that.. I think having only one connection improved that a bit.

I do understand your assessment that there might be something off with the storage CTs but I'm wondering if that wouldn't also impact the data Enlighten shows for our site? I am basically just wondering how Enlighten can receive/store/display data that seems not offset/"logically" correct (no continuous charge once 100% SoC has been reached) & is Enlighten getting data from a different source than whatever the HA integration pulls from the Combiner / Envoy?

The seemingly incorrect offset also varies - yesterday we had i.e. ~3.x kW all afternoon and we certainly had no continuous 3kW of charging at the 100% SoC during that time of the day:

vs

July-14-2024_battery_report.csv

I've attached the 'Battery' report from Enlighten for yesterday the 14th which breaks down each of the five batteries energy and power figures into 5 minute increments and as you can see, during those afternoon hours as pictured above that report says what one would expect from fully charged batteries with still plenty of PV production happening to cover the house consumption & -export.. not much, but some, going in and out of them/the batteries.

[catsmanac]

I am basically just wondering how Enlighten can receive/store/display data that seems not offset/"logically" correct (no continuous charge once 100% SoC has been reached) & is Enlighten getting data from a different source than whatever the HA integration pulls from the Combiner / Envoy?

The magic question, we do ask ourselves the same every now and then while scratching our heads. We have no full insight in how Enlighten processes it's data and our access to data in the Envoy is limited and poorly documented.

The Envoy communicates with the batteries directly and probably uses that data. The current transformer monitors the wires and is an independent data source to the Envoy. The data HA displays is as received from the Envoy aside from scaling W to kW and alike.

Based on the data I can only say the Envoy reports CT values different as the battery values. Why is unclear, but with the CT value never going to zero when the batteries do and the Battery values matching Enlighten, it makes the CT suspicious. If you want to confirm the values in the Envoy itself then I think you can see these when connecting to the Envoy with a browser and entering the token to get access.

So overall you are right that the CT values are weird. They come however from the Envoy.

[joergbattermann]

Quick update here @catsmanac : I don't know if you or Enphase changed something recently, but the numbers are now seemingly.. correct.. and have been for a week or two?! By that I mean whenever the SoC of the batteries is 100%, the "Current battery discharge" numbers are as expected hovering a wee bit over and under 0kW (literally just i.e. -0.0.36kW etc) and when (dis) charge is happening, the numbers are quite identical to what Enlighten says. Soooo not sure if something changed with one of the last few .x updates of HA and your integration or if Enphase pushed a new FW update that might have addressed that, but it looks good now!

[catsmanac]

Sounds as "miracles still happen". There were no changes in HA related to this. Furthermore, the values come straight from the envoy data reports, so i this suggest something made it to be stable again.

I would be speculating when calling out reasons for this. Keep an eye on it I'd say. If it's stable for say another 2 weeks let's close this issue. The content won't disappear when closing so it's documented for others as well.

[catsmanac]

I wonder if you got a new firmware (looking at your AI optimization issue #123216) and as a result the CT got reset!?

[joergbattermann]

I was looking back at the reporting history in HA for the past 10-ish days @catsmanac and it looks like the values had been correct at least since ~ July 27th or so (that's the earliest my history goes back?).. so about a week after your previously last comment above.

The new firmware for #123216 was rolled out the night between August 2nd/3rd .. so that one was not the actual cause for the 'improvement' but whatever it was / an update in between or something, I'll take it ;)

Anyway, I'll keep an eye on it and report back a bit down the road if it stayed seemingly correct. Thanks again!!

[catsmanac]

Should we go ahead and close this one Jörg?

[joergbattermann]

Morning Arie, I was about to write "yes let's close it" last night but double checked if the original divergence re-occured or if there's any change in the data which might provide some more info.. and it sure did, but not sure it's any less confusing.

Let me show you / explain:

When I said it looked correct, the battery discharge seemed to be equal in both, the HA sensor and what Enphase was reporting, so i.e. this:

vs Enphase Data being quasi equal-ish.. battery wasn't discharging (and house was pulling from the grid) due to batteries having had reached the discharge reserve of 20% prior to that (NEM3 / AI Optimization exporting stored energy during the most 'profitable' time of the day at around 7-8pm local time) and it's reflected in the(ir) report as well:

Battery discharge as per HA history hovers (in accordance to what Enphase reports) very, very closely around 0kW discharge for August 7th, 8th, 9th.

On August 10th onwards however the Battery discharge rate throughout the night all of a sudden is being reported in HA again as being a couple hundred watts constantly, depending on which nights, i.e.:

So even though the batteries were depleted down to their reserve way before those times and pulling from the grid all night, HA / the sensor logged battery (dis)charge, which.. per Enphase's Enlighten report, did not happen.. see i.e. that last HA history screenshot / August 15th at 3:30am-ish:

I've attached both .csv files - the HA history one from that exact same view as those are above & also the Enphase Enlighten report: reports.zip .. August 16th data / today wasn't available yet but you can see that 'incorrectness' (?) reflected in August 10th-15h.. and the seemingly correctness before that.

There's nothing obvious that changed between August 9th and 10th so I am, again, confused why it wouldn't (seemingly?) be incorrect before, then correct for a week or two.. and then not anymore again. Maybe you see something that I'm not seeing Arie

[catsmanac]

Think I'm seeing the same as you Jörg, when zooming in around the zero axis of your data, one can see that the nightly stable value drifts away from the zero. Really strange. It doesn't change every day and on the 8th it actually moved closer to zero compared to the 7th. But overall it moves slowly away from the zero.

I only know how to move bytes between Envoy and Home Assistant and have no real knowledge on the CT's, but I would be temped to ask the installer about this. One would think there's something weird with the CT, it's connection to the Envoy or with the Envoy. The values we are getting are what Envoy provides so somewhere this offset gets introduced.

Some offset is to be expected as the CT probably has some accuracy less then perfect, but this is quite a bit it seems. Looking at the daily high values, probably limited by the physical constraints of the battery, one can see these going down as well by what seems almost a similar amount.

That would give some handle on potentially dealing with this, but that is patch work, no fundamental solution. In a template you could calculate a known drift value, only when soc is 100%. Then use that value to correct the discharge amount and see if you get anywhere close to Enphase reports. As said, patchwork only. Or calculate battery charge/discharge from changes in soc or available capacity what others fallback to if no storage ct is present. But which shouldn't be needed if you have the Storage CT.