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).