Wiki > Dashboard

[Esquilo007]

Hey,
I saw you are working on the Dashboard Categorie (see Wiki).
Just wanted to say it looks great and I'd love to see this feature in future.
I tried it, but there are several things to add / configure and due to me being new to home assistant I was just able to get few things working.
For example, you have a custom integration of DWD Forecast of weather, which needs to be configured.
Or the internal temperature of the Inverter, which needs to be activated manually to get it work.

Thank you in advance.

[wlcrs]

Pinging @heinemannj , as he has created that wiki page.

I hadn't noticed that new page yet myself.

First feedback for @heinemannj : You have a lot of info on that page, but you need to break it down into bitesize pieces to make it understandable. Can you break it down into a screenshot of each card separately, with the YAML on how to recreate it under it? (+ extra explanation if necessary).

Please remove the cards which have nothing to do with this integration, as they create unwanted support requests (exhibit A: this issue). Maybe also grey them out on your screenshots of your full dashboards to prevent unwanted confusion?

[wlcrs]

I've read through the current Dashboard page, and while it's a lot clearer now what piece of code relates to which card, I'm starting to feel like it would be a better fit as a separate git repository. Now you have a lot of embedded yaml files which makes it easier to navigate the page and understand what is on it, but a pain to actually use it.

A separate git repo would have the advantage that interested users can just do a git clone of that repo into their config -folder, add a few includes to reference to your work and be on their way. It will also make it easier for you to maintain.

You can of course still have a reference on this Wiki to aid discoverability of all your hard work.

What do you think?

[heinemannj]

My proposal for outsourcing of code elements from your wiki:

• Create a documentation branch within your huawei solar repository
• Add an asset folder and remove everything else ...

This documentation branch can be easily cloned by everybody e.g. by the usage of GitHub Desktop or HA tools.

• Merge requests for GitHub Wiki are really painful and not possible via GitHub Desktop.
• Merge requests for normal branches are working easily.

After merging the yaml/pictures/... assets into the documentation branch all wiki pages can be simplified and their maintanence will be much more easier.

I don't like the idea to segregate different parts of documentation into a couple of independent wikis.
The user will lost overview and visibility.

Contribution to a distributed environment potentially will not work.
Contribution for a centralized setup for the moment is working.

[wlcrs]

Why not just create a brand new repo instead of awkwardly cloning this existing one, creating a separate branch and throwing all files that are in there away? You will end up with unnecessary branches, tags, etc. because of that.

I would certainly not use the Wiki in that separate repository: you can just use the wiki in this repository to showcase your Dashboards. I just want to keep it limited to one page - and not 6 different pages - as I don't want the "Pages" sidebar to get cluttered.

[heinemannj]

"... Why not just create a brand new repo instead of awkwardly cloning this existing one, creating a separate branch and throwing all files that are in there away? ..."

I'm open for any solution - a branch or a new repro make from end user/contributor perspective no difference.
Please create and add me as the first contributor and I will try to implement as discussed.

"... I would certainly not use the Wiki in that separate repository: you can just use the wiki in this repository to showcase your Dashboards. ..."

To be cystal clear:
I really don't have the need to get likes, appreciation or acknowledgment ...
I'm nearly 57 years old, in a service manager role and standing with two feets inside the real world ...

But:
Home Assistant including the community with supporting staff is extremly helpful and on a very high quality level!!!
My only intention is to support each other to improve ...
And if we are talking about solar energy: To save our earth!

"... I just want to keep it limited to one page - and not 6 different pages - as I don't want the "Pages" sidebar to get cluttered. ..."

Outsourcing the code snips will help a lot ...
Afterwards I will try to be ceative ;-)

Cheers
Joerg

[wlcrs]

Please create that repository yourself. I will not be participating in maintaining it, and do not want to take ownership in it.

Thanks!

[heinemannj]

The pain with github wiki is, that you can't create a subpage for an subpage.

If we break it down for each card we will end to more than 30 chapters and you will loose the dashboard design, because a dashboard page is mostlikely ONE card only with multiple nested cards inside.

But for sure I can provide some extra explanations on the visualisation page.
But this takes time ;-)

About exhibit A:
We are dealing within solar energy production - right?
Considering that sun is required to produce solar energy, the most basic and most important information is an reliable weather and solar forecast.
Obviously this are additional independant integrations but combining this integrations together with HA huawei_solar integration you will receive 2000% more then on 'FusionSolar' portal.

Sorry to compare your really professional work with the FusionSolar waste ...

But for sure it MUST be clearly highlighted:

• Dashboards Ideas/Proposals only
• Not supported by your integration
• Not for HA beginners ...
• Hardcore ...

URL to the Wiki Dashboard page: https://github.com/wlcrs/huawei_solar/wiki/Dashboards

[wlcrs]

W.r.t. splitting the page: you can keep the screenshots of the dashboards on top, and then add a table of contents just below each screenshot where you list the cards in each dashboard and link to the section in the page of each card (with an anchor)

I do want to keep the Wiki focused on the integration itself. Your dashboards are obviously of high quality in their whole. That's why I suggested to gray out the non-solar cards instead of removing them completely. I would suggest that you create a post in the "Show your dashboards" discussion category if you want to document the non-solar cards publicly. I will then gladly pin it to improve its visibility.

[heinemannj]

I've try to catch up your recommendations us much as possible.
Please review updated dashboad wiki.

Cheers
Joerg

[Esquilo007]

Thank you @heinemannj
Just saw you updated the wiki.
Your dashboards look really nice, I will try to optimize my own, thank you for providing it.

[heinemannj]

Please share your optimizations too. Will be very interesting and needful for all of us.

[Kreatinbulle]

Since some days I am also using the dashboard Level 2 - what i can't manage is to display the battery flows correctly. In the Power Flows (now) everything fits, but in the Solar-Yield - Usage (Today), House-Consumption (Today) and in the Energy Flow (Today) the battery is ignored.
As soon as I enter values in the input sensors battery_charge_loss_daily and battery_discharge_loss_daily, the display also works. So far I could deduce that, but I don't understand the sense of these Input_Sensors and think that I'm doing something completely wrong. Do you have a tip here?

[heinemannj]

I have synced my config files to GitHub: heinemannj/home-assistant-config

The two Input_Sensors are required to have persistant values in case HA will be restarted or Huawei_Solar Integration will be restarted.

I've removed
#initial: 0
because I have lost the values after restarts.

Try to set both manually to 0.0:

input_number.battery_discharge_loss_daily
input_number.battery_charge_loss_daily

Then all other related template sensors should automatically update within a couple of minutes, dependant on your polling frequency.

[Kreatinbulle]

Thanks, I'll give it a try!

[wergio]

for future extension i think this custom integration could be useful: https://github.com/enkama/hass-variables or this similar https://github.com/snarky-snark/home-assistant-variables

I'll try to use it instead of input_number

[heinemannj]

I had also a look to the last integration ...

Actually I'm using this approach:

{%- macro globalVariables() %}
    {# 1 x Huawei SUN2000-6KTL-M1 (High Current Version) #}
    {# 1 x Huawei LUNA2000-10-S0 #}
    {# 1 x Huawei LUNA2000-5-S0 #}
    {{- {
            'inverter_rated_power': 6000,
            'inverter_maximum_active_power': 6600,
            'batteries_rated_capacity': 15,
            'batteries_rated_charge_energy': 17.250,
            'batteries_rated_discharge_power': 6600,
            'batteries_rated_charge_power': 7500,
            'batteries_charge_end_time_expected': '14:00',
            'batteries_soc_setpoint_low': 15,
            'batteries_soc_setpoint_neutral': 45,
            'batteries_soc_setpoint_high': 75,
            'epexspot_quantile_setpoint_low': 0.15,
            'epexspot_quantile_setpoint_neutral': 0.33,
            'epexspot_quantile_setpoint_high': 0.8
        }|to_json -}}
{%- endmacro %}

template:
  - sensor:
      - name: inverter_input_power_with_correction
        unique_id: inverter_input_power_with_correction
        #friendly_name: "Inverter input power"
        state_class: measurement
        device_class: power
        unit_of_measurement: "W"
        icon: mdi:solar-power
        state: >-
          {# For SUN2000-3-10KTL-M1 (High Current Version) #}
          {# Check the Input Voltage of connected MPPTs #}
          {# Assuming an Input Voltage above 600 V #}

          {% from '032-emhass.jinja' import globalVariables %}
          {% set var = globalVariables()|from_json %}
          {% set inv_rating = var.inverter_rated_power %}

          {% set inv_input_power = states('sensor.inverter_input_power')|float(0) %}

          {% if inv_input_power < (inv_rating*0.05) %}
            {# inv_input_power < 300 W - For above rated power of 6000 W #}
            {{ (inv_input_power * 1.00)|float(0) }}
          {% elif inv_input_power < (inv_rating*0.1) %}
            {# inv_input_power < 600 W - For above rated power of 6000 W #}
            {{ (inv_input_power * 1.00)|float(0) }}
          {% elif inv_input_power < (inv_rating*0.15) %}
            {# inv_input_power < 900 W - For above rated power of 6000 W #}
            {{ (inv_input_power * 1.00)|float(0) }}
          {% elif inv_input_power < (inv_rating*0.2) %}
            {# inv_input_power < 1200 W - For above rated power of 6000 W #}
            {{ (inv_input_power * 1.00)|float(0) }}
          {% elif inv_input_power < (inv_rating*0.25) %}
            {# inv_input_power < 1500 W - For above rated power of 6000 W #}
            {{ (inv_input_power * 1.00)|float(0) }}
          {% elif inv_input_power < (inv_rating*0.3) %}
            {# inv_input_power < 1800 W - For above rated power of 6000 W #}
            {{ (inv_input_power * 1.0038)|float(0) }}
          {% else %}
            {# inv_input_power >= 1800 W - For above rated power of 6000 W #}
            {{ (inv_input_power * 1.0063)|float(0) }}
          {% endif %}
        availability: >-
          {{ (states('sensor.inverter_input_power')|is_number) }}

The custom templates can excecuted from elsewhere even from dashboards.

[jabums]

Thanks for sharing this great dashboard with us @heinemannj !
I recently started building my own setup as I really don't want to rely on Fusion Solar for further installations and also would like to be able to automate things in the future.
Unfortunately I seem to have a little more complex hardware setup with cascaded inverters. I have a 10KTL (+ Powermeter) and a 6KTL daisy chained. Huawei_Solar would only work utilizing two instances of the integration. (One for each inverter)
I am reading modbus values with an RPi4 for each inverter connected to the internal Wifi. Both RPi are sharing their entities via Remote Home Assistant. So on my main HA server I have the whole set of data from each inverter with a prefix of pv1_ and pv2_ .
Now I got a bit lost on how to combine both data sets to be able to achieve a similar dashboard.

Maybe I can work around by creating custom combined sensors with naming scheme of the Huawei_Solar Integration?
For example:
sensor.inverter_active_power = sensor.pv1_inverter_active_power + sensor.pv2_inverter_active_power

If someone is aware of a different, possibly easier approach please share some directions.

[heinemannj]

Please have a look on Huawei Solar Wiki:
https://github.com/wlcrs/huawei_solar/wiki/Connecting-to-daisy-chained-inverters

I have connected my inverter via WiFi directly to my Home Network:

• No more Interference to the Doongle and FusionSolar
• No need for a WLAN Bridge
• Only one RPI
• Only one HA instance

Easy to implement, easy to maintain ...

In my opinion you will need three dashboards:

• for the main inverter
• for the second one
• for custom combined sensors

[wergio]

Hi, thanks for your work!

could you explain how to "translate" the efficiency curve of the inverter (this is mine: SUN2000-3-10KTL-M1 https://solar.huawei.com/-/media/Solar/attachment/pdf/la/datasheet/SUN2000-3-10KTL-M1.pdf ) to the configuration of the "inverter_input_power_with_correction" entity?
I notice that yours is different from the one specified here https://github.com/wlcrs/huawei_solar/wiki/Daily-Solar-Yield#a-better-approach

and another question: I don't understand in "battery_state_of_capacity_remaining_charge_energy" entity why you use this:
{{ 11500 * (1 - bat_state / 100) }}
why 11500 ?

thanks

[heinemannj]

My actual settings:

{%- macro globalVariables() %}
    {# 1 x Huawei SUN2000-6KTL-M1 (High Current Version) #}
    {# 1 x Huawei LUNA2000-10-S0 #}
    {# 1 x Huawei LUNA2000-5-S0 #}
    {{- {
            'inverter_rated_power': 6000,
            'inverter_maximum_active_power': 6600,
            'batteries_rated_capacity': 15,
            'batteries_rated_charge_energy': 17.250,
            'batteries_rated_discharge_power': 6600,
            'batteries_rated_charge_power': 7500,
            'batteries_charge_end_time_expected': '14:00',
            'batteries_soc_setpoint_low': 15,
            'batteries_soc_setpoint_neutral': 45,
            'batteries_soc_setpoint_high': 75,
            'epexspot_quantile_setpoint_low': 0.15,
            'epexspot_quantile_setpoint_neutral': 0.33,
            'epexspot_quantile_setpoint_high': 0.8
        }|to_json -}}
{%- endmacro %}

# ########## Start: Inverter Input Power with Correction ##########
#
# - for Riemann Integration:
#   - for real Solar Input Energy (Solar Yield )
#
template:
  - sensor:
      - name: inverter_input_power_with_correction
        unique_id: inverter_input_power_with_correction
        #friendly_name: "Inverter input power"
        state_class: measurement
        device_class: power
        unit_of_measurement: "W"
        icon: mdi:solar-power
        state: >-
          {# For SUN2000-3-10KTL-M1 (High Current Version) #}
          {# Check the Input Voltage of connected MPPTs #}
          {# Assuming an Input Voltage above 600 V #}

          {% from '032-emhass.jinja' import globalVariables %}
          {% set var = globalVariables()|from_json %}
          {% set inv_rating = var.inverter_rated_power %}

          {% set inv_input_power = states('sensor.inverter_input_power')|float(0) %}

          {% if inv_input_power < (inv_rating*0.05) %}
            {# inv_input_power < 300 W - For above rated power of 6000 W #}
            {{ (inv_input_power * 1.00)|float(0) }}
          {% elif inv_input_power < (inv_rating*0.1) %}
            {# inv_input_power < 600 W - For above rated power of 6000 W #}
            {{ (inv_input_power * 1.00)|float(0) }}
          {% elif inv_input_power < (inv_rating*0.15) %}
            {# inv_input_power < 900 W - For above rated power of 6000 W #}
            {{ (inv_input_power * 1.00)|float(0) }}
          {% elif inv_input_power < (inv_rating*0.2) %}
            {# inv_input_power < 1200 W - For above rated power of 6000 W #}
            {{ (inv_input_power * 1.00)|float(0) }}
          {% elif inv_input_power < (inv_rating*0.25) %}
            {# inv_input_power < 1500 W - For above rated power of 6000 W #}
            {{ (inv_input_power * 1.00)|float(0) }}
          {% elif inv_input_power < (inv_rating*0.3) %}
            {# inv_input_power < 1800 W - For above rated power of 6000 W #}
            {{ (inv_input_power * 1.0038)|float(0) }}
          {% else %}
            {# inv_input_power >= 1800 W - For above rated power of 6000 W #}
            {{ (inv_input_power * 1.0063)|float(0) }}
          {% endif %}
        availability: >-
          {{ (states('sensor.inverter_input_power')|is_number) }}
#
# ########## End: Inverter Input Power with Correction ##########

Above correction is only for the High Current Versions.

My measurements and investigations:

• No power loss
• Power gain > 1800 W

For LUNA2000-5-E0 and LUNA2000-5KW-C0:
My measurements and investigations:

• Charging of each battery modul will request ~5750Wh => 750Wh more then the rated capacity of 5000Wh

[wergio]

thanks now it's clear, i saw also your old post on the main integration thread, can you upload here the pdf “FusionSolar Residential Datasheet EU 230403” you refer to? because the download is not possible for me (keeps asking to register as a business on huawei website).

[daveB30]

Is there any way to verify the input Voltage of connected MPPTs?
In HA I see 2 entities: sensor.inverter_tension_fv_1 and sensor.inverter_tension_fv_2 both with max daily values (sunny weather) around 230V as the screenshot below.

Is this the value to consider to calculate the "Input Power with Correction" value?

I've a SUN2000-6KTL-M1 inverter installed.

[Roving-Ronin]

@daveB30 see below, this covers for both a primary (and if you have one) a secondary inverter in a cascade.

template:

########### Start: PV Strings - Power ###########

  # Inverter 1 - PV String 1  - Power. Calculated from current x voltage.
  # Referred to as PV1 on the SunSynk card.
  - sensor:
    - name: "Inverter 1 - PV 1 Power"
      unique_id: inverter_1_pv_1_power
      state_class: "measurement"
      device_class: power
      unit_of_measurement: "W"
      icon: mdi:solar-power
      state: >-
        {% set current_state = states('sensor.inverter_pv_1_current') %}
        {% set voltage_state = states('sensor.inverter_pv_1_voltage') %}

         {% if current_state not in ['unknown', 'none', 'unavailable'] and
              voltage_state not in ['unknown', 'none', 'unavailable'] %}
          {% set current = current_state | float(default=0) %}
          {% set voltage = voltage_state | float(default=0) %}
          {{ (current * voltage) | round(3) }}
        {% else %}
          unknown
        {% endif %}
      availability: >-
        {{ states('sensor.inverter_pv_1_current') | is_number and 
           states('sensor.inverter_pv_1_voltage') | is_number }}


  # Inverter 1 - PV String 2  - Power. Calculated from current x voltage.
  # Referred to as PV2 on the SunSynk card.
  - sensor:
    - name: "Inverter 1 - PV 2 Power"
      unique_id: inverter_1_pv_2_power
      state_class: "measurement"
      device_class: power
      unit_of_measurement: "W"
      icon: mdi:solar-power
      state: >-
        {% set current_state = states('sensor.inverter_pv_2_current') %}
        {% set voltage_state = states('sensor.inverter_pv_2_voltage') %}

         {% if current_state not in ['unknown', 'none', 'unavailable'] and
              voltage_state not in ['unknown', 'none', 'unavailable'] %}
          {% set current = current_state | float(default=0) %}
          {% set voltage = voltage_state | float(default=0) %}
          {{ (current * voltage) | round(3) }}
        {% else %}
          unknown
        {% endif %}
      availability: >-
        {{ states('sensor.inverter_pv_2_current') | is_number and 
           states('sensor.inverter_pv_2_voltage') | is_number }}


  # Inverter 2 - PV String 1  - Power. Calculated from current x voltage.
  # Referred to as PV3 on the SunSynk card.
  - sensor:
    - name: "Inverter 2 - PV 1 Power"
      unique_id: inverter_2_pv_1_power
      state_class: "measurement"
      device_class: power
      unit_of_measurement: "W"
      icon: mdi:solar-power
      state: >-
        {% set current_state = states('sensor.inverter_pv_1_current_2') %}
        {% set voltage_state = states('sensor.inverter_pv_1_voltage_2') %}

         {% if current_state not in ['unknown', 'none', 'unavailable'] and
              voltage_state not in ['unknown', 'none', 'unavailable'] %}
          {% set current = current_state | float(default=0) %}
          {% set voltage = voltage_state | float(default=0) %}
          {{ (current * voltage) | round(3) }}
        {% else %}
          unknown
        {% endif %}
      availability: >-
        {{ states('sensor.inverter_pv_1_current_2') | is_number and 
           states('sensor.inverter_pv_1_voltage_2') | is_number }}


  # Inverter 2 - PV String 2  - Power. Calculated from current x voltage.
  # Referred to as PV2 on the SunSynk card.
  - sensor:
    - name: "Inverter 2 - PV 2 Power"
      unique_id: inverter_2_pv_2_power
      state_class: "measurement"
      device_class: power
      unit_of_measurement: "W"
      icon: mdi:solar-power
      state: >-
        {% set current_state = states('sensor.inverter_pv_2_current_2') %}
        {% set voltage_state = states('sensor.inverter_pv_2_voltage_2') %}
         {% if current_state not in ['unknown', 'none', 'unavailable'] and
              voltage_state not in ['unknown', 'none', 'unavailable'] %}
          {% set current = current_state | float(default=0) %}
          {% set voltage = voltage_state | float(default=0) %}
          {{ (current * voltage) | round(3) }}
        {% else %}
          unknown
        {% endif %}
      availability: >-
        {{ states('sensor.inverter_pv_2_current_2') | is_number and 
           states('sensor.inverter_pv_2_voltage_2') | is_number }}

Will give you a sensor that gives the Input Power for each of the 2 PV Arrays per inverter (or MPPT as you refer to). Like this, that is for Inverter 1 - PV 1 (or String 1 / MPPT 1). Can't show you PV2 as I only run 1 string per inverter (all with optimizers).

[daveB30]

@Roving-Ronin Thank you very much for the fast reply.

My goal is follow @heinemannj dashboard guide and I'm try to understand the behaviour of his packages (I've installed the PV system at home and I'm a newbie in PV environment). Does your advice replace the calculations provided for the inverter_input_power_with_correction sensor?

I've tried this model and the result is higher (about 100W) than the default inverter_input_power sensor provided by the integration, which is what I expect from inverter_input_power_with_correction.

{% set volt_1 = states('sensor.inverter_tensione_fv_1') | float(0) %}
{% set volt_2 = states('sensor.inverter_tensione_fv_2') | float(0) %}
{% set amp_1 = states('sensor.inverter_corrente_fv_1') | float(0) %}
{% set amp_2 = states('sensor.inverter_corrente_fv_2') | float(0) %}
{% set pwr = states('sensor.inverter_potenza_in_ingresso') | float(0) %}

{% if pwr > 0 %}
  {% set pwr_1 = (volt_1 * amp_1) | round(2) %}
  {% set pwr_2 = (volt_2 * amp_2) | round(2) %}
  {{ (pwr_1 + pwr_2 - pwr) | round(0) }}
{% else %}
  NaN
{% endif %}

[wergio]

Hi all, I think the info on the official page of the wiki https://github.com/wlcrs/huawei_solar/wiki/Daily-Solar-Yield are misleading, especially the “A Better Approach” chapter, and caused a lot of cascade misinterpretation, the logic used is correct but it’s used on the wrong sensor (inverter_input_power)!

I made a lot of measurements and calculations and I think i came up to a solution, also about the following old post of @heinemannj

First of all nobody ever talked about the sensor “inverter_total_dc_input_energy” (maybe because it was added later?!) but this is the real “solar yield” sensor
if you make the simple riemann integration of “inverter_input_power” (without any correction) -> utility meter daily. and you compare it with the utility meter daily of “inverter_total_dc_input_energy” you can verify a 2% difference (very similar to the typical efficiency loss of our inverters) so very likely “inverter_input_power” is already reduced by the efficiency loss! So there is no need to deduce loss from inverter’s datasheet efficiency curve.

for a double check that “inverter_total_dc_input_energy” is the real “solar yield” you can make a template variable with this sensor combination:
(huawei_pv_1_current * inverter_pv_1_voltage)+(huawei_pv_2_current * inverter_pv_2_voltage) -> riemann integration -> utility meter daily, and you will get the exact same curve of the one above derived from “inverter_total_dc_input_energy”.

and now it comes the more interesting part: the reason for the slope in the efficiency loss detected by @heinemannj in the post above.
obviously he used this formula to calculate the losses:
L = SY -BC +BD -Y
and it’s correct, but the slope is there because “inverter_input_power” integration it’s used as SY in the formula instead of “inverter_total_dc_input_energy”

those are the correct sensor to use:
SY daily Solar Yield (from sensor.inverter_total_dc_input_energy -> utility meter daily)
BC daily Battery Charged (from sensor.battery_day_charge)
BD daily Battery Discharged (from sensor.battery_day_discharge)
Y daily Inverter Output (Yield) (from sensor.inverter_daily_yield)

in the following graph you can see in blue the curve (with slope) using “inverter_input_power” integration, and the purple one, with no slope using “inverter_total_dc_input_energy”, there is some jitter but the curve is clearly going always up.

the reason is explained by the third (azure) curve: the difference between the real SY and the “reduced by efficiency” Yield. as you can see the curve is “weirdley” steeper when the battery is at 100% doing nothing, but I think there is an explanation also for that:

first of all we can conceptually divide the losses of huawei system in two parts: the DC/AC loss (the one referred in the sentence before) and the battery chemical conversion loss, their sum is L. But remember: the battery is a DC battery so the “battery in” loss are mostly, if not totally, only from battery conversion; on the contrary when the battery is doing nothing the losses are all DC/AC at the maximum possible; and finally the “battery out” loss is battery conversion + DC/AC but, when battery is discharging, output power is smaller compared with sunny day output and it’s hard to notice the bigger percentual loss, so this explains the third curve.

With those calculations I can finally correlate the solar yield with losses and house consumption, production counter, etc, with very little discrepancy

I hope this post may be useful

[wergio]

i have it from 19 june, depends when you updated the integration, definetely it was introduced recently

[heinemannj]

This sensor have been introduced on:

Add forcible charge sensor (broken translation)
main
1.4.1 1.4.0
@wlcrs
wlcrs committed on Jun 15

But obviously there is a bug within the sensor definition:

[sensor.py]

236 | HuaweiSolarSensorEntityDescription(
237 | key=rn.TOTAL_DC_INPUT_POWER,
238 | native_unit_of_measurement=UnitOfEnergy.KILO_WATT_HOUR,
239 | device_class=SensorDeviceClass.ENERGY,
240 | state_class=SensorStateClass.TOTAL,

[strings.json]

            "total_dc_input_power": {
                "name": "Total DC input energy"
            },

A mixture between input_power [W] and input_energy [kWh] ...

I will test this new sensor in a couple of days andpotentially raise an issue to fix the power/energy inconsistance.

[daveB30]

I've made some tests with 3 utility meters:

• PV string power ( volts x amps ) -> riemann integration (left) -> daily meter FV rendimento giornaliero
• sensor.inverter_total_dc_input_energy (new sensor providedy by wlcrs integration) -> daily meter FV Rendimento giornaliero WERGIO
• sensor.inverter_input_power (with no correction providedy by wlcrs integration) -> riemann integration (left) -> daily meter FV Rendimento senza correzione giornaliero

Here the results over the last 2 days (+ current day):

The yield from inverter_total_dc_input_energy sensor (FV Rendimento giornaliero WERGIO) is always slightly higher than the one obtained from the string power production (FV rendimento giornaliero). I think it's beause of the rounded caclulation made by the inverter itself: multipling the volt x amps can return the PV power production with #0,000 W precision (useful whith low irradiance values). Furthermore, the values updating speed ​​is greater (I've set the UPDATE_INTERVAL to 15 seconds in const.py) than the kWh value given by the inverter.
Look at these quater-hour / hour / daily yield graphics:

Even if in daily yield these differeces are minors, in the efficiency loss calculations might have a quite-big relevance (please bypass the DAY 3 because is the current day):

I know that 3-4% inefficiency seems lower than the 98% max efficiency from inverter's data-sheets, but: 1) it's a mean value of the day 2) due to project reasons my PV system does't works in the 600V load range (with which you have maximum efficiency).

Be aware that I am not an expert, so feel free to scold me if I've said something stupid.
I hope I've been helpful.

Please @wergio and @heinemannj let me know.

[wergio]

0,13 kwh discrepancy is very low, keep in mind that is very difficult to achieve a better precision and, even if you can achieve it, it's also not so useful because at the end is difficult to precisely correlate variables that are not read all at the same time (because of HA limitations)

keep also in mind that riemann variable (or other "calculated" variables) is less reliable on the long run because they are not updated during HA reboot or if the system is down for any reason, instead variables directly read from the inverter are always consistent.

unfortunately some of the variables read from the inverter have a limitation on update frequency, for example battery_day_charge and battery_day_discharge are updated only every 3 min independently from the update interval (I think it's a limitation of the system)

Your DC/AC loss seem a bit higher compared to mine (I have 3-phase model SUN2000-10KTL slightly better on efficiency compared to monophase and I rarely go over 3%), but it also depends day by day: low irradiance means always a bit more inefficiency

[daveB30]

0,13 kwh discrepancy is very low, keep in mind that is very difficult to achieve a better precision and, even if you can achieve it, it's also not so useful because at the end is difficult to precisely correlate variables that are not read all at the same time (because of HA limitations)

Yes, agree. But sometimes (not this case) small variations may be important: my power meter (from Huawei app) shows a monthly energy import from the grid different from what I see in the elecrtic bill, specially if absortions are low. I think that if I try the riemann integration of power from the grid I would get values ​​very similar to the electricity bill but:

keep also in mind that riemann variable (or other "calculated" variables) is less reliable on the long run because they are not updated during HA reboot or if the system is down for any reason, instead variables directly read from the inverter are always consistent.

Agree again, absolutly.

unfortunately some of the variables read from the inverter have a limitation on update frequency, for example battery_day_charge and battery_day_discharge are updated only every 3 min independently from the update interval (I think it's a limitation of the system)

So the 0.13 difference is shoud be dued by the approximation only.

Your DC/AC loss seem a bit higher compared to mine (I have 3-phase model SUN2000-10KTL slightly better on efficiency compared to monophase and I rarely go over 3%), but it also depends day by day: low irradiance means always a bit more inefficiency

Mine is 3-phase also (SUN2000-6KTL-M1) but the layout of the panels was forced by the layout of roof, so the installer did the best he could but there were technical limitations (that's what he told me...)

[heinemannj]

Interesting follow-up on the discussion related on Huawei Solar dashboards starting at April 2023 ;-)

Actually I'm on the next stage of evolution by introduing an Home Energy Management System (HEMS) for Huawei Solar.
For EMS all efficiency loss needs to be considered and clearly calculated.

I'm happy to collect all helpful input into a dedicated repository and wiki.

See you later when my alpha version is ready to discuss #()

[daveB30]

Interesting follow-up on the discussion related on Huawei Solar dashboards starting at April 2023 ;-)

When something is good the interest is always on..

Actually I'm on the next stage of evolution by introduing an Home Energy Management System (HEMS) for Huawei Solar.

Great news, hope to see your alpha version soon!
I have no knowledge or skills to help you, so I can only be very grateful for all your work and effort without which I would not have understood many things. As soon as it is available I will test the HEMS so as to give you some benchmarks.
Thank you very much from Italy!!

[heinemannj]

The first alpha version of Home Energy Management System (HEMS) for Huawei Solar is ready for testing.
For EMS all efficiency loss needs to be considered and clearly calculated.

I'm happy to collect all helpful input within Home Assistent (HA) Home Energy Management System (HEMS) repository and Wiki.

[daveB30]

Bravo! Incredible effort and great result!!