home-assistant / core

:house_with_garden: Open source home automation that puts local control and privacy first.
https://www.home-assistant.io
Apache License 2.0
73.47k stars 30.69k forks source link

Enphase Envoy lifetime generation does not have enough precision for energy dashboard #54553

Closed rianadon closed 3 years ago

rianadon commented 3 years ago

The problem

I know it's best to use lifetime generation for integrating into the energy dashboard, but on the envoy model I have, firmware R3.7.31 (11b4e9), the lifetime generation is reported in MWh.

e.g. http://envoy/production:

image

In the last seven days the system hasn't even managed to produce 1 MWh, so with this configuration I don't expect accurate daily breakdowns of energy production.

I don't know if this is a problem with other firmwares/envoy models, so maybe the solution is to allow both lifetime usage and one of the other kWh measurements for use with the energy dashboard? Or choose which one to supply depending on whether the units for lifetime are detected as MWh or kWh?

What is version of Home Assistant Core has the issue?

2021.8.4

What was the last working version of Home Assistant Core?

No response

What type of installation are you running?

Home Assistant Core

Integration causing the issue

No response

Link to integration documentation on our website

No response

Example YAML snippet

No response

Anything in the logs that might be useful for us?

No response

Additional information

No response

gtdiehl commented 3 years ago

@rianadon Yes unfortunately this is a limitation of Envoy's running Firmware <3.9, because the data is being scraped from the webpage. Envoys running Firmware >= 3.9 still have a large Lifetime value but it is being returned as a Wh value, from a page that returns it in JSON format.

The Envoy integration is returning a Daily production value in Wh to Home Assistant. I believe you see this sensor in Home Assistant for your Envoy?

Screen Shot 2021-08-12 at 11 14 00 AM

If you have this sensor, the last_reset attribute just needs to be added to the sensor and you can then add it to the Energy Dashboard.

I quickly put this template together, as a test to see if just adding the last_reset attribute to the Production daily sensor would work. See if adding this to your configuration.yaml and adding the new sensor My Daily Production to the Energy Dashboard works.

template:
  - sensor:
      - name: "My Daily Production"
        state: "{{ states('sensor.envoy_today_s_energy_production') }}"
        unique_id: "envoy_daily_energy_consumption_last_reset"
        unit_of_measurement: 'Wh'
        icon: mdi:solar-power
        device_class: 'energy'
        state_class: 'measurement'
        attributes:
          last_reset: "{{as_timestamp(now()) | timestamp_custom('%Y-%m-%d') }}T00:00:00+00:00"

EDIT: I'm just not sure if I should be using now() or utcnow() in the above template

rianadon commented 3 years ago

I don't think the last_reset is getting converted to the correct timezone.

This is what I tried based off your config:

template:
  - sensor:
      - name: "My Daily Production"
        state: "{{ states('sensor.envoy_today_s_energy_production') }}"
        unique_id: "envoy_daily_energy_consumption_last_reset"
        unit_of_measurement: 'Wh'
        icon: mdi:solar-power
        device_class: 'energy'
        state_class: 'measurement'
        attributes:
          last_reset: "{{ now().replace(hour=0, minute=0, second=0, microsecond=0).isoformat() }}"
image
gtdiehl commented 3 years ago

How about replacing now() with utcnow()?

rianadon commented 3 years ago

Using utcnow gives 2021-08-12T00:00:00+00:00 for last_reset.

gtdiehl commented 3 years ago

That should be what you want as the daily production value on the Envoy should be reset to zero at the beginning of each day.

rianadon commented 3 years ago

It depends whether the Envoy resets itself at 12:00 AM UTC time or 12:00 AM local time.

2021-08-12T00:00:00+00:00 looks like UTC time to me, since the timezone offset is +00:00. Meanwhile 2021-08-12T00:00:00-07:00 has the offset for Pacific time.

I might just have to wait until midnight to tell you which the Envoy uses.

gtdiehl commented 3 years ago

The System Administration page on the Envoy should tell you which Timezone the device is configured for. Screen Shot 2021-08-12 at 12 25 35 PM

I'm just not sure how Home Assistant interprets the last_reset time value given the Timezone. I think if the Envoy device and Home Assistant are configured for the same timezone, and the last_reset is given in UTC then the time calculations should work out. So when the device resets its Production value to zero at Midnight local time, Home Assistant will know to restart its kWh values for the day, Atleast this is what I'm thinking🤞

EDIT: No I think I'm wrong. If the last_reset time is set to Midnight UTC in Home Assistant, (for me) that's 5pm the previous day. So I think in the last_reset template above you should be using now() rather than utcnow(). This is assuming that Home Assistant and the Envoy are configured for the same timezone.

rianadon commented 3 years ago

I just realized I can also view the sensor history (I trust that more than the configuration page).

image

The total is definitely resetting at local time.

I set up both now and utcnow and added them to statistics cards, so I'll test which one is correct. Now it'll just be some time before Home Assistant generates those statistics.

Thanks for all the help so far!

gtdiehl commented 3 years ago

Your welcome! Nice, let me know the results after a day or two.

I did notice another Issue that was attributed to polling and the last_reset attribute. Not for the Envoy integration but could apply here if the Envoy and Home Assistant times are off a little. Probably an edge case but something to be aware of. https://github.com/home-assistant/core/issues/54309#issuecomment-895904347

probot-home-assistant[bot] commented 3 years ago

enphase_envoy documentation enphase_envoy source (message by IssueLinks)

rianadon commented 3 years ago
image

Local time is the winner.