Open joergbattermann opened 2 weeks ago
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:
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!
(message by CodeOwnersMention)
enphase_envoy documentation enphase_envoy source (message by IssueLinks)
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.
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 !
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.
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.
Thats fine, thanks. Sleep well
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:
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:
Thanks @joergbattermann , I just downloaded then successfully so you can close it again. Time for some number crunching. I'll keep you posted.
Appreciate it, thank you @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
Some side-notes from your data:
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.
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.
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