Hi @del13r
Thank you for the pointer below. I didn’t notice this in the GUI (but it actually is on the “hamburger” (three vertical dots) config menu on the right top corner where it should be). My bad.
So I would say your reply was truly “enlightening”
Adding the “Return to grid” as the same entity as “Grid consumption” actually has some logic as this is the CT is the same sensor and the integration probably ignores positive and negative values between the two respective instances.
Pre V.7 I had my Python polling data in something like 10 second intervals from various Envoy APIs. You are right that on many APIs one is on their own calculating energy integral but I was interested about the metrics for individual panels (and washing odd/even to see the difference). So I was polling fast, aligning data from various API sources by the time stamps and filling-in the blanks not provided by the “lifetime” energy API. I might eventually get back to that but I need to decipher how to share the access token since the two applications requesting tokens would be “pulling rug under each other” - disqualifying the other party acquired token.
I spent way too much time yesterday trying to figure out where in the filesystem does the
./enphase_energy/diagnostics.py
live. This module contains a set “TO_REDACT” containing “CONF_TOKEN”. Once I comment that line out I can harvest the token from the log and re-use in parallel with hass. Shouldn’t be that hard, right?
Another reason to possibly venture into a custom integration might be the granularity of reporting. Right now he binning is on a hourly basis. I remember someone loudly defending on one of the forums that kWh can be (obviously ) reported only in hourly increments (and it would then be easy to deduce that J (or Ws) work only when reported for each second
For now I just need to be more patient or resurrect my non hass implementation.
Thanks a lot for your help!
I disagree with that assumption. In my experience, I have a 12 month token for home assistant to talk to envoy and I generate a seperate token whenever I access https://envoy.local from my browser.
The only thing that matters for tokens is the expiry date. As long as you are using the token before the expiry date, you can generate hundreds of other tokens and it won’t invalidate your existing token.
I also disagree with this CT assumption.
I have found that the native HASS enphase integration calls on pyenphase to extract “total-consumption” and “production” from https://envoy.local/production.json . Total-consumption is calculated by the envoy which adds both CT clamps (CT1 production + CT2 net-consumption) = total-consumption. This is calculated every time that url is requested.
Total-consumption is actually what your house consumed. It includes both what your house used from the grid as well as what your house used from the solar production. For this reason, I disagree with using it in energy dashboard without using calculations to separate what was used from the grid and what was used from your panels.
If you want actual figures direct from the CT clamps, you need to use https://envoy.local/ivp/meters/readings as a data source and you still need need to perform calculations in home assistant. The data source you might incorrectly assume that you are using is net-consumption which is direct from the ct clamp. I can assure you that if you are using the native HASS integration, you will not be getting net-consumption.
Either way, if you want energy dashboard to report correct figures, you need home assistant to perform calculations to provide a sensor to accurately represent grid import and grid export.
Interesting! I will have to test that. Since I didn’t yet get access to the token hass pulls my only assumption was based on the fact that any time I manually pull a token at https://entrez.enphaseenergy.com/entrez_tokens I get a different one.
But I never verified the assumption “newly generated token disqualifies predecessors” . The only thing I noticed was that next day my (manually generated) token didn’t work and I assumed it was because hass pulled a new one in the meantime.
@del13r Thank you so much for the fantastic work. Please bear with me if I ask stupid questions. I have tried my first stab at following the instructions. But I guess I’m missing few things.
The integration sensor for Export Energy is showing up as Unavailable. Note: At the time of writing this, its 9:54 PM EST and obviously the Export Power is 0 W which shows properly. Please see screenshots.
When I still try to add these sensors into the Energy Dashboard, I see that I get validation errors. Example errors are: sensor.grid_export_energy → statistics_not_defined and sensor.grid_export_energy (unavailable). Please see screenshots.
The Energy Distribution section on Energy Dashboard seems to be super off. I assume its because of the issues with the sensors in some invalid state. Screenshots attached as well.
Some useful info:
HAOS with Core - 2024.1.6
Enphase Envoy - Firmware Version: D8.2.127 (b9a901)
Enphase Part Number: 800-00664-r05
Envoy Integration: Official HA Integration
Any help that you can offer by looking at my challenge and a guidance is much appreciated. Again, please forgive me if I have made a stupid mistake.
I think the biggest hurdle for you right now is that your export sensor has not increased above 0 yet, and therefore the integration sensor you have named “Grid Export Energy” will not be properly formatted until the sun starts shining tomorrow and your panels generate more than your house consumes. At this point you cannot use that export energy sensor in energy dashboard yet until tomorrow.
Once that energy sensor is properly formatted once the figure rises above 0, you may need to go to developer-tools/statistics and see if there is a fix issue button you can press.
I dont recomend pressing it until the integration sensor is properly formatted.
The obvious difference is that you are using float and then multiplying by 1000 to convert kW down to W presumably because your IQ gateway is supplying kW.
I see no problem with doing that as long as the sensor has the correct attributes with the focus on having the correct unit_of_measurement defined for your intended W or kW preference.
You theoretically may not need to divide by 1000 if you are happy viewing your power sensor in kW which is the same unit of measurement that the IQ gateway is providing.
As my Envoy returns watts as an integer, ive tried to match what the envoy provides as well as keep decimal points out of the equation, but thats just my preference, you may be doing floating points and decimals due to how the data is being provided by the IQ gateway.
Here is my current YAML setup in Watts
- sensor:
name: Power Export
state_class: measurement
icon: mdi:transmission-tower
unit_of_measurement: W
device_class: power
state : >
{{ [0, states('sensor.power_production') | int(0) - states('sensor.power_consumption') | int(0) ] | max }}
Here is the POWER sensor shown in developer tools of home assistant.
This figure can increase and decrease like a car speedometer defined by “state_class: measurement”
Then I take power as a source which is supplied in W and then convert that to energy over time in kWh which divides the Watts by 1000 to get kWh.
This figure only ever increases like an car odometer indicated by “state_class: total_increasing”
Here is the ENERGY sensor shown in developer tools of home assistant.
Thank you @del13r for taking time to respond. Much appreciate it.
I see that my Energy Dashboard is in a good state now. I figured that the moment the Export related entities started having values, my issues went away.
I also see that the Unavailable issue may pop up anytime during the initial setup as the integration is the culprit.
Please see the github issue and I think its the inherent behavior of HA which started in 2023.5.2.
A constructive feedback from my side. If you could please add this scenario as a note in your original post, it would be great and our fellow HA users may find it useful during the initial setup. Kindly please consider.
Thanks for the feedback. I did make a small mention in post 1 but I might have been a bit vague with my wording and I should update the word production to the word export.
Thanks again.
Hi @del13r, wondered if you have any pointers, have been successfully polling the home.json and also using the add-on to get grid status but a month ago both options stopped working. I can’t seem to find anything online regarding Enphase changing the API. I was previously was using the below but the empower parameter no longer exists.
Hello! Unfortunately, the server occasionally stops, mine does this randomly too. It restarts on its own after 1-2 hours. It might be happening only with wireless communication. I’ll soon connect it with a LAN cable, I’m curious if it still happens then.
I have a question, not sure if I can do this. I am getting a new tuya based heat pump with boosting element installed soon and was thinking if I can get real time export info from enphase then I could automate the boosting element to turn on off based on how much energy is being exported. Am I able to get this info or am I dreaming?
Hello @Mrsash,
You have come to the right place.
I am doing the same thing for my pool pump.
Here is a basic example of my pool pump automation based on power export being more than how much power my pool pump uses.
alias: Pool Pump On grid export
description: ""
trigger:
- platform: numeric_state
above: "1050"
for:
hours: 0
minutes: 2
seconds: 0
entity_id: sensor.power_export
condition:
- condition: state
entity_id: switch.sonoff_MACADDRESS
state: "off"
- condition: sun
before: sunset
after: sunrise
action:
- service: switch.turn_on
target:
entity_id: switch.sonoff_MACADDRESS
data: {}
- service: notify.notify
data_template:
message: >-
Pool Pump On
mode: single
max: 10
And if it gets cloudy, I have another automation to turn the pool pump off to reduce energy costs
alias: Pool Pump Off grid import
description: ""
trigger:
- platform: numeric_state
entity_id:
- sensor.power_import
for:
hours: 0
minutes: 4
seconds: 0
above: 200
- platform: state
entity_id:
- sun.sun
attribute: next_setting
condition:
- condition: state
state: "on"
entity_id: switch.sonoff_MACADDRESS
action:
- service: switch.turn_off
data: {}
target:
entity_id: switch.sonoff_MACADDRESS
- service: notify.notify
data_template:
message: >-
Pool Pump Off
mode: single
Awesome. You might have to explain to me please. Ok maybe I understand a little. The entity
sensor.power_import and sensor.power_export are missing in mine.
Guess I need to test for few things
Turn On:
Water temp under 55C
Time between sunrise + 3 hours and sunset - 2 hours
Power exported above 1800w(for 1.8kw element) for more than a minute etc.
Turn Off:
Temp reaches 60C(heat pump limit)
Export below Zero(cloudy)
Time after sunset - 2 hours and before sunrise + 3 hours
I have 7 people in the house so if I even turn it the element on manually I would need to add an automation to disable the Turn Off: automation on manual mode. Maybe wont complicate it for myself ans just add a button for automation on/off etc
Oh one more question if I may. I tried to make a solar.yaml to split the solar in its own file but failed miserably. I added solar: !include solar.yaml and proceeded to move all sensors I am using for the enphase stuff. Would you by any chance have done this already? For me check config in Dev tools gave an error…
Hi, I have just made an updated guide for Enphase Envoy and Energy Dashboard.
Here is the guide Enphase Envoy on 2024.4
I’ve tried to make it easier for new users by using the GUI rather than editing the configuration.yaml.
I have not attempted moving sensors out of configuration.yaml yet.
) reported only in hourly increments (and it would then be easy to deduce that J (or Ws) work only when reported for each second 
