Recommended setup for combined power reporting?

[poldim]

Hey, thanks for making this. I was using this for a few months when I just had my battery storage installed and it worked great. My inverter, a Sol Ark 12k, provides combined power usage variables for grid, battery, solar, and load. My issue is that I'm not sure how to calculate where the power is going. IE is the solar power going to the house, battery, or grid?

generation_to_grid_entity
generation_to_battery_entity
generation_to_house_entity
grid_to_battery_entity
grid_to_house_entity
battery_to_grid_entity
battery_to_house_entity

Conceptually, here's a breakdown of how power can flow. The question is how do I know if for example, solar, is flowing to grid, battery, or the house?

	Grid	Solar	Battery	House
Import (in from)	Yes	Yes	Yes	No
Export (out to)	Yes	No	Yes	Yes

Below is the basic template I had prior to getting solar and this worked fine:

### TEMPLATE SENSORS FOR POWER FLOW CARD
template:
  - sensor:
      - name: "Powerflow Battery Discharge"
        ### POSITIVE WHEN DISCHARGING
        state: "{% if states('sensor.solark_battery_power') | float(0) > 0 %}
                    {{ states('sensor.solark_battery_power') | float(0) }}
                {% else %}
                    0
                {% endif %}"
        device_class: power
        unit_of_measurement: W
      - name: "Powerflow Battery Charge"
        ### NEGATIVE WHEN CHARGING
        state: "{% if states('sensor.solark_battery_power') | float(0) < 0 %}
                    {{ states('sensor.solark_battery_power') | float(0) * -1 }}
                {% else %}
                    0
                {% endif %}"
        device_class: power
        unit_of_measurement: W

[reptilex]

Well you need to have more sensors to know that otherwise you can't. Maybe check out the documentation it has a 2 cases like this one. But it can only work if you actually have more sensors from your solar setup. House consumption, grid consumption being two you would need. Than you can add more ifs into the upper sensor.

[poldim]

Well you need to have more sensors to know that otherwise you can't. Maybe check out the documentation it has a 2 cases like this one. But it can only work if you actually have more sensors from your solar setup. House consumption, grid consumption being two you would need. Then you can add more ifs into the upper sensor.

I have the sensors below and then some, but I don't have the same exact sensors that break down where the power is going (ie destination). I'm guessing you get from the powerwall.

I guess I just have to make some kind of angry template sensors to try to figure out where the power is going. But it would be cool if this card could just accept the four entities for grid, battery, solar, and load and have the logic internally for determining where it's going.

sensor.solark_battery_current
sensor.solark_battery_power
sensor.solark_battery_state_of_charge
sensor.solark_battery_voltage
sensor.solark_daily_battery_charge_energy
sensor.solark_daily_battery_discharge_energy
sensor.solark_daily_grid_buy_energy
sensor.solark_daily_grid_sell_energy
sensor.solark_daily_inverter_energy
sensor.solark_daily_pv_energy
sensor.solark_external_lmt_l1_current
sensor.solark_external_lmt_l2_current
sensor.solark_grid_external_total_power
sensor.solark_grid_frequency
sensor.solark_grid_limiter_l1_power
sensor.solark_grid_limiter_l2_power
sensor.solark_inverter_error_message
sensor.solark_inverter_l1_power
sensor.solark_inverter_l2_power
sensor.solark_inverter_power
sensor.solark_load_power
sensor.solark_pv1_current
sensor.solark_pv1_input_power
sensor.solark_pv1_voltage
sensor.solark_total_grid_power

So I was trying to figure out how HA is doing this in their code. Any chance this could be integrated into your card?
https://github.com/home-assistant/frontend/blob/master/src/panels/lovelace/cards/energy/hui-energy-distribution-card.ts

[reptilex]

Me neither, this is how I broke up mine:

- platform: template
    sensors:
      solar_yield:
        value_template: '{{ ((states.sensor.solarsensors.attributes["power_dc1"] | int + states.sensor.solarsensors.attributes["power_dc2"] | int)) }}'
        device_class: power
        unit_of_measurement: W
      battery_charge:
        value_template: '{{ states.sensor.solarsensors.attributes["act_state_of_charge"] }}'
        unit_of_measurement: '%'
      battery_consumption:
        value_template: '{% set batter_cons = states.sensor.solarsensors.attributes["total_dc_power"] - states.sensor.solarsensors.attributes["power_dc1"] - states.sensor.solarsensors.attributes["power_dc2"] | int %}
                        {% if batter_cons > 0 %}
                            {{ batter_cons | int }}
                        {% else %}
                            0
                        {% endif %}'
        device_class: power
        unit_of_measurement: W
      battery_charging:
        value_template: '{% set batter_cons = (states.sensor.solarsensors.attributes["total_dc_power"] - states.sensor.solarsensors.attributes["power_dc1"] - states.sensor.solarsensors.attributes["power_dc2"]) | int %}
                        {% if batter_cons < 0 %}
                            {{ (batter_cons * -1) | int }}
                        {% else %}
                            0
                        {% endif %}'
        device_class: power
        unit_of_measurement: W      
      grid_consumption:
        value_template: '{{ states.sensor.solarsensors.attributes["home_own_consumption_from_grid"] | int }}'
        device_class: power
        unit_of_measurement: W
      grid_feed_in:
        value_template: '{% set feed_in = states.sensor.solarsensors.attributes["inverter_generation_power_actual"] | int - states.sensor.solarsensors.attributes["total_active_power_powermeter_home_consumption"] | int %}
                         {% if feed_in < 9000 and feed_in > 0 %}
                            {{ feed_in | int }}
                        {% else %}
                            0
                        {% endif %} '
        device_class: power
        unit_of_measurement: W
      solar_consumption:
        value_template: '{{ states.sensor.solarsensors.attributes["home_own_consumption_from_pv"] | int }}'
        device_class: power
        unit_of_measurement: W
      house_consumption:
        value_template: '{{ states.sensor.solarsensors.attributes["total_active_power_powermeter_home_consumption"]  | int }}'
        device_class: power
        unit_of_measurement: W
      house_energy:
        value_template: "{% set phase1 =  state_attr('sensor.solarsensors', 'active_power_phase_1_powermeter') %}
                        {% set phase2 =  state_attr('sensor.solarsensors', 'active_power_phase_2_powermeter') %}
                        {% set phase3 =  state_attr('sensor.solarsensors', 'active_power_phase_3_powermeter') %}
                        {{ (phase1 + phase2 + phase3) | int }}"
        device_class: power
        unit_of_measurement: W

[poldim]

home_own_consumption_from_grid
home_own_consumption_from_pv

is these sensor values given by your inverter or do you calculate them?

[reptilex]

Those are given by the Kostal energy meter connected to the Inverter.

[poldim]

Those are given by the Kostal energy meter connected to the Inverter.

Are you using two meters - one on wires from the grid and one on the wires from your pv?

[AviadorLP]

Well i have studied how many inverters work with the power transfers and its logic, and how they distribute the power available. So i made a template to create all the flows, you only need to provide the grid, house, battery and PV entities, my template will create the rest of them after a small adjustment of house power because sometimes you can get sensor readings that don't make any sense...... This template corrects the house load when import in power does not equal export out power for example if are importing 1000W from the grid and 500w from the solar panels and you don't have batteries or you do but its not charging or discharging and your house load shows as 1400w my template will correct house load to 1500w that will appear in a new sensor called REAL.HOUSE.LOAD (this happens because power readings are not that exact and also because the inverter itself will consume power that is not being included in house load so i corrected this, and the math will all work just fine from then on). I'm a strong believer that the inverter power consumption when its working should appear included in the house load because it is a house consumption device required to manage the adjustment of power available. There is usually no sensor that shows inverter power consumption so i created one using the available sensors. If anyone needs help just say so....

[AviadorLP]

and HA does not use power sensors for the energy dashboard it uses the energy sensors, and that is a slightly different thing. It calculates the distribution of energy over a period of time (in each hour)

[poldim]

@AviadorLP can you share this template?

[AviadorLP]

Of course i can, but its using my sensors from wills 106 solax modbus integration and it would not make any sense to other users. I'm trying to adapt it so anyone can use it with some simple changes. But you will find a link to my current one here... it requires you to change all solax sensors with yours...

https://github.com/wills106/homsassistant-solax-modbus/discussions/31

Or wait till i have some time and, I'll try do an adaptation soon and paste it here....

[AviadorLP]

Ok done an adaptation for all to use. Just insert your grid, house, battery and PV sensors in the required place. Save inside a file in your packages folder like "apf_sensors.yaml"

Could not test this adaptation in different scenarios so it might include bugs. Test it and tell me about the possible bugs.

# Templates for Actual Powerflow transfer charts (APF - Actual PowerFlow)
#
# For the math to add up a new Real House Load must be calculated and used, witch includes
# the inverter consumption and excludes rounding errors and corrects inaccurate power readings.
#
# It never made sense that inbound power sometimes does not equal outbound power. This fixes it!
#
# Developed by AviadorLP
#
# Just replace the 4 words below "ReplaceWithYourSensor" with your specific sensors,
# for grid, house, solar and battery entities, example "sensor.solax_house_load" 
#
# If your sensor is negative when it should be positive replace that complete line with
#         state: "{{ 0 - states('ReplaceWithYourSensor')|int(default=0) }}"
#
# If you don't have a battery replace that complete line with
#         state: "{{ 0 }}"

template:
- sensor:
# grid sensor must be negative when importing and positive when exporting
  - name: APF Grid Entity
    device_class: power
    state_class: measurement
    unit_of_measurement: W
    state: "{{ states('ReplaceWithYourSensor')|int(default=0) }}"

# sensor must always be 0 or positive (i think they always are)
  - name: APF House Entity
    device_class: power
    state_class: measurement
    unit_of_measurement: W
    state: "{{ states('ReplaceWithYourSensor')|int(default=0) }}"

# sensor must always be 0 or positive (i think they always are)
  - name: APF Generation Entity
    device_class: power
    state_class: measurement
    unit_of_measurement: W
    state: "{{ states('ReplaceWithYourSensor')|int(default=0) }}"

# battery sensor must be positive when charging and negative when discharging
  - name: APF Battery Entity
    device_class: power
    state_class: measurement
    unit_of_measurement: W
    state: "{{ states('ReplaceWithYourSensor')|int(default=0) }}"

# Required to reduce code later on
  - name: APF Grid Import
    device_class: power
    state_class: measurement
    unit_of_measurement: W
    state: >
      {% if states('sensor.apf_grid_entity')|int(default=0) < 0 %}
        {{ states('sensor.apf_grid_entity')|int(default=0)|abs }}
      {% else %}
        0
      {% endif %}

#   Inverter consumption and power losses due to Inverter transfers and power conversions (AC/DC)
#   excludes rounding errors made worst by the fact that some inverters round all sensors readings to INT
#   Occasionally this might be negative probably due to cumulative errors in not so accurate power readings.
  - name: APF Inverter Power Consumption
    device_class: power
    state_class: measurement
    unit_of_measurement: W
    state: "{{ states('sensor.apf_generation_entity')|int(default=0) - states('sensor.apf_battery_entity')|int(default=0) - states('sensor.apf_house_entity')|int(default=0) - states('sensor.apf_grid_entity')|int(default=0) }}"

# Real House Load Includes Inverter consumption and transfer conversions and losses and rounding errors.
# It never made sense that inbound power sometimes does not equal outbound power. This fixes it!
  - name: APF Real House Load
    device_class: power
    state_class: measurement
    unit_of_measurement: W
    state: "{{ states('sensor.apf_house_entity')|int(default=0) + states('sensor.apf_inverter_power_consumption')|int(default=0) }}"
    icon: mdi:home-lightning-bolt

  - name: APF Grid2House
    device_class: power
    state_class: measurement
    unit_of_measurement: W
    state:  >
      {% if states('sensor.apf_grid_import')|int(default=0) > states('sensor.apf_real_house_load')|int(default=0) %}
        {{ states('sensor.apf_real_house_load')|int(default=0) }}
      {% else %}
        {{ states('sensor.apf_grid_import')|int(default=0) }}
      {% endif %}

  - name: APF Grid2Batt
    device_class: power
    state_class: measurement
    unit_of_measurement: W
    state: >
      {% if states('sensor.apf_grid_import')|int(default=0) > states('sensor.apf_real_house_load')|int(default=0) %}
        {{ states('sensor.apf_grid_import')|int(default=0) - states('sensor.apf_real_house_load')|int(default=0) }}
      {% else %}
        0
      {% endif %}

  - name: APF Batt2House
    device_class: power
    state_class: measurement
    unit_of_measurement: W
    state: >
      {% if states('sensor.apf_battery_entity')|int(default=0) < 0 %}
        {% if states('sensor.apf_battery_entity')|int(default=0)|abs > states('sensor.apf_real_house_load')|int(default=0) %}
          {{ states('sensor.apf_real_house_load')|int(default=0) }}
        {% else %}
          {{ states('sensor.apf_battery_entity')|int(default=0)|abs }}
        {% endif %}
      {% else %}
        0
      {% endif %}

# This might be called house to grid, and can happen in rare circumstances,
# like when the inverter is not able to do a precise adjustment of power fast enough
# or when you want to force a discharge of the battery or something...
# But it only happens with battery or other power generator users.
  - name: APF Batt2Grid
    device_class: power
    state_class: measurement
    unit_of_measurement: W
    state: >
      {% if states('sensor.apf_battery_entity')|int(default=0) < 0 %}
        {% if states('sensor.apf_battery_entity')|int(default=0)|abs > states('sensor.apf_real_house_load')|int(default=0) %}
          {{ states('sensor.apf_battery_entity')|int(default=0)|abs - states('sensor.apf_real_house_load')|int(default=0) }}
        {% else %}
          0
        {% endif %}
      {% else %}
        0
      {% endif %}

  - name: APF Solar2Grid
    device_class: power
    state_class: measurement
    unit_of_measurement: W
    state: >
      {% if states('sensor.apf_grid_entity')|int(default=0) > states('sensor.apf_batt2grid')|int(default=0) %}
        {{ states('sensor.apf_grid_entity')|int(default=0) - states('sensor.apf_batt2grid')|int(default=0) }}
      {% else %}
        0
      {% endif %}

  - name: APF Solar2House
    device_class: power
    state_class: measurement
    unit_of_measurement: W
    state: >
      {% if states('sensor.apf_generation_entity')|int(default=0) > 0 and states('sensor.apf_real_house_load')|int(default=0) > states('sensor.apf_batt2house')|int(default=0) + states('sensor.apf_grid_import')|int(default=0) %}
        {% if states('sensor.apf_generation_entity')|int(default=0) > states('sensor.apf_real_house_load')|int(default=0) - states('sensor.apf_batt2house')|int(default=0) - states('sensor.apf_grid2house')|int(default=0) %}
          {{ states('sensor.apf_real_house_load')|int(default=0) - states('sensor.apf_batt2house')|int(default=0) - states('sensor.apf_grid2house')|int(default=0) }}
        {% else %}
          {{ states('sensor.apf_generation_entity')|int(default=0) }}
        {% endif %}
      {% else %}
        0
      {% endif %}

  - name: APF Solar2Batt
    device_class: power
    state_class: measurement
    unit_of_measurement: W
    state: >
      {% if states('sensor.apf_generation_entity')|int(default=0) > 0 and states('sensor.apf_battery_entity')|int(default=0) > 0 %}
        {% if states('sensor.apf_battery_entity')|int(default=0) > states('sensor.apf_grid2batt')|int(default=0) %}
          {% if states('sensor.apf_generation_entity')|int(default=0) - states('sensor.apf_solar2house')|int(default=0) > states('sensor.apf_battery_entity')|int(default=0) - states('sensor.apf_grid2batt')|int(default=0) %}
            {{ states('sensor.apf_battery_entity')|int(default=0) - states('sensor.apf_grid2batt')|int(default=0) }}
          {% else %}
            {{ states('sensor.apf_generation_entity')|int(default=0) - states('sensor.apf_solar2house')|int(default=0) - states('sensor.apf_solar2grid')|int(default=0) }}
          {% endif %}
        {% else %}
          0
        {% endif %}
      {% else %}
        0
      {% endif %}

Restart HASS or something..... and then create a custom card using this... plus whatever you need: Remove the lines that include the word "battery" if you don't have a battery, but i think you probably would not need this if you didn't.

type: custom:tesla-style-solar-power-card
name: Actual Power Flow
grid_to_house_entity: sensor.apf_grid2house
grid_to_battery_entity: sensor.apf_grid2batt
generation_to_grid_entity: sensor.apf_solar2grid
generation_to_battery_entity: sensor.apf_solar2batt
generation_to_house_entity: sensor.apf_solar2house
battery_to_house_entity: sensor.apf_batt2house
battery_to_grid_entity: sensor.apf_batt2grid
grid_entity: sensor.apf_grid_entity
house_entity: sensor.apf_real_house_load
generation_entity: sensor.apf_generation_entity
battery_entity: sensor.apf_battery_entity

Could not test this adaptation in different scenarios so it might include bugs. Test it and tell me about the possible bugs and show me a picture of the card with the bug showing please...

[AviadorLP]

@AviadorLP can you share this template?

I would appreciate some feedback, if you tried my template and if its working ok for you ?

[Rebem13]

@AviadorLP - I tried your template and it worked PERFECTLY, thank you!

[poldim]

@AviadorLP can you share this template?

I would appreciate some feedback, if you tried my template and if its working ok for you ?

Hey there, thanks for posting this! I was traveling for a bit and finally got some time to dedicate to HA. I copied your yaml over, filled in my values and it fired right up. The only thing I had to do was invert my grid sensor as it works opposite to your logic where importing is positive for me ({{ states('sensor.solark_grid_external_total_power')|int(default=0) * -1}}).

I'll watch this for the next little bit and see how it does. Thanks for your effort!

[AviadorLP]

@AviadorLP can you share this template?

I would appreciate some feedback, if you tried my template and if its working ok for you ?

Hey there, thanks for posting this! I was traveling for a bit and finally got some time to dedicate to HA. I copied your yaml over, filled in my values and it fired right up. The only thing I had to do was invert my grid sensor as it works opposite to your logic where importing is positive for me ({{ states('sensor.solark_grid_external_total_power')|int(default=0) * -1}}).

I'll watch this for the next little bit and see how it does. Thanks for your effort!

I explained this situation in the beginning of the script

# If your sensor is negative when it should be positive replace that complete line with
#         state: "{{ 0 - states('ReplaceWithYourSensor')|int(default=0) }}"

It achieves the same result as your solution :)

[poldim]

I ended up changing my config to how your header showed after positing this.

Today I noticed my battery flow wasn't looking correct. My battery sensor is negative when charging as seen below. I tried inversing the battery flow and it look ok for now, but I'm not sure of how that will impact it later in the day.

Using this now:

# battery sensor must be negative when charging and positive when discharging
  - name: APF Battery Entity
    device_class: power
    state_class: measurement
    unit_of_measurement: W
    state: "{{ 0 - states('sensor.solark_battery_power')|int(default=0) }}"

[AviadorLP]

I ended up changing my config to how your header showed after positing this.

Today I noticed my battery flow wasn't looking correct. My battery sensor is negative when charging as seen below. I tried inversing the battery flow and it look ok for now, but I'm not sure of how that will impact it later in the day.

Sorry, i made a mistake in the comment, it works the other way around in my script. Already updated the comment in the script above..... But do notice that in reptilex flow chart he calculates the battery entity alone, it does not use your sensor at all. (Its calculated from the flows and other entities and he chose to show it as positive when charging and negative when discharging, and you cannot change this behavior )

in my chart i even use this 2 lines the same

battery_entity: sensor.solax_battery_capacity
battery_extra_entity: sensor.solax_battery_capacity

I still get the info of the battery charge/discharge rate, (because like i said, its calculated automatically) but now when i click the bubble i get the capacity history (that is what i want to see, my personal choice)

I think its a little funny that he calculates the battery entity from the flows and not the flows from the entities (maybe he does not have a charging entity sensor ????) I do understand that all the flows are really hard to calculate, it took me 20 hours to make it work the right way and i even had to correct the house load for it to be exact. But then again i'm not really a programmer. This is just a hobby. And the sensors aren't that accurate, a correction was always required for the flows to make sense.

[poldim]

I ended up changing my config to how your header showed after positing this. Today I noticed my battery flow wasn't looking correct. My battery sensor is negative when charging as seen below. I tried inversing the battery flow and it look ok for now, but I'm not sure of how that will impact it later in the day.

Sorry, i made a mistake in the comment, it works the other way around in my script. Already updated the comment in the script above..... But do notice that in reptilex flow chart he calculates the battery entity alone, it does not use your sensor at all. (Its calculated from the flows and other entities and he chose to show it as positive when charging and negative when discharging, and you cannot change this behavior )

in my chart i even use this 2 lines the same

battery_entity: sensor.solax_battery_capacity
battery_extra_entity: sensor.solax_battery_capacity

I still get the info of the battery charge/discharge rate, (because like i said, its calculated automatically) but now when i click the bubble i get the capacity history (that is what i want to see, my personal choice)

I think its a little funny that he calculates the battery entity from the flows and not the flows from the entities (maybe he does not have a charging entity sensor ????) I do understand that all the flows are really hard to calculate, it took me 20 hours to make it work the right way and i even had to correct the house load for it to be exact. But then again i'm not really a programmer. This is just a hobby. And the sensors aren't that accurate, a correction was always required for the flows to make sense.

Yes, this appears to be working correctly

I also am not a programmer or I would have been able to figure this out. Ideally, I would like this card adapted with a 5th point which is the inverter in the middle of all of these as the inverter is in real life. The issue is that this assumes ideal world condition where the inverter has no losses and all consumption goes to the house. It would be nice if it was portrayed more accurately. It would also help visualize the contanstant power that's used up by the inverter.

[AviadorLP]

Yes, that was what i was looking for also, when i was searching the internet for a flow chart like this one. But for now if you are not using the extra appliances of this card you can add this code to the end of the script above:

  - name: APF Inverter Short Name
    state: Inverter

and then add this to your card:

appliance1_consumption_entity: sensor.apf_inverter_power_consumption
appliance1_extra_entity: sensor.apf_inverter_short_name
appliance1_icon: mdi:flash

This will help you visualize the Inverter consumption, sort of. Because It will include sometimes major inaccurate sensor reading corrections, or those readings where obtained before the inverter was able to adjust to the new readings witch takes maybe a few tenths of a second... (Its fast but not that fast...) so sometimes it will even be negative. But it is useful most of the times... And you will be able to see how much power is being used by the inverter most of the times, when the sensors are more accurate, and you will notice a higher consumption when its converting higher power from DC to AC or AC to DC.

[AviadorLP]

Or an easier solution, just keep an eye on it over your house load.

house_extra_entity: sensor.apf_inverter_power_consumption

[reptilex]

I'm glad @AviadorLP was so nice to help you, I was swamped the last months. I realize there is an inverter loss, but I think most people are not interested in the loss. I know it can be considerable on the long run but since we are here showing current flows I don't think the loss is substantial enough. The rendering is a pain, therefore if someone else puts in a new entity that can be added in the middle I will test and merge but I will not create this code. Sorry.

[AviadorLP]

Ok. But do notice that the actual inverter loss and consumption and loss can reach up to hundred of watts. I've seen at times more than 300 watts. I learned a bit of java and c++ about 20 years ago. Not inclined to re-learn it again. Cant help here. Sorry :) All i can do is give you all the flows.

[purcell-lab]

@AviadorLP you have done a fantastic job in mapping the flows from the four power sources.

I, and many others, have been going around in circles trying to map these flows, it is straight forward without a battery, but with a battery there are always two different ways to satisfy the solution, which you have solved. Well done.

I have a powerwall so have made some minor adaptations, and will update the examples shortly.

[AviadorLP]

Thank you. It was lucky that you found this after reptilex closed this issue. I will try to create this again under a new issue called "mapping the flows from the four power sources" and ask reptilex to mark it as documentation. So it will be easier for new users to find this solution. If you find a bug in the flows please show me a picture of the flow chart so i can revise the math again. I did not test a dump of the battery to the grid but i created this templates also to include this.

[purcell-lab]

@reptilex maybe this is something we could document on the wiki for this project?

I can see the wiki tab for the project but it just seems to take me back to the code tab, is there something else you need to do to enable the wiki?

I'll also shortly raise a PR, after a few more folk have tested, to update your Readme.md for the powerwall example configuration.

[reptilex]

Hi, try here: https://github.com/reptilex/tesla-style-solar-power-card/wiki/Powerwall-templates-and-configuration Can you edit? A PR would be good too, though

[purcell-lab]

Thanks for creating the wiki page, it won't let me edit though?

Have you allowed collaborators under settings?

[image: image.png]

On Sat, 23 Apr 2022 at 06:04, reptilex @.***> wrote:

Hi, try here: https://github.com/reptilex/tesla-style-solar-power-card/wiki/Powerwall-templates-and-configuration Can you edit? A PR would be good too, though

— Reply to this email directly, view it on GitHub https://github.com/reptilex/tesla-style-solar-power-card/issues/96#issuecomment-1106820248, or unsubscribe https://github.com/notifications/unsubscribe-auth/AS4B3XW2EC2FL7LWXQITV2LVGMA6FANCNFSM5JUZET6A . You are receiving this because you commented.Message ID: @.***>

[purcell-lab]

Thank you. It was lucky that you found this after reptilex closed this issue. I will try to create this again under a new issue called "mapping the flows from the four power sources" and ask reptilex to mark it as documentation. So it will be easier for new users to find this solution. If you find a bug in the flows please show me a picture of the flow chart so i can revise the math again. I did not test a dump of the battery to the grid but i created this templates also to include this.

@AviadorLP Thanks again for your great work, I have been using the card for over a year, but it was only after recently getting a battery that the flows were really complex to map. The battery discharge to grid is working well, thanks.

One minor comment is visible on the flow here: https://github.com/reptilex/tesla-style-solar-power-card/issues/99#issuecomment-1106605935

Solar is generating 404 W, which is less than the house consumption (641 W), so you have allocated that to the generation2grid flow, which is OK, but that makes it seem that the house is running 100% off battery. Now of course solar and battery are both connected to the home gateway, which connects to grid and house so allocating to the generation2grid flow isn't incorrect.

It might be a 'nicer' visualisation to have the solar 404W allocated to the house first (generation2house flow) and reduce the battery2house flow by the same amount (404W) to keep the ledger in balance.

[purcell-lab]

If you find a bug in the flows please show me a picture of the flow chart so i can revise the math again.

@AviadorLP another minor comment would be to address the threshold for minor power flows #115 , which I would imagine could be straight forward in the templates with adjusted min/ max functions. Perhaps dumping the additional 'rounding errors' into the 'inverter power consumption sensor, which also was a neat hack in your template code.

[AviadorLP]

If you find a bug in the flows please show me a picture of the flow chart so i can revise the math again.

@AviadorLP another minor comment would be to address the threshold for minor power flows #115 , which I would imagine could be straight forward in the templates with adjusted min/ max functions. Perhaps dumping the additional 'rounding errors' into the 'inverter power consumption sensor, which also was a neat hack in your template code.

That is a very easy thing to do in my templates, although I believe it to be a wrong thing to do. If the inverter is actually telling you the battery is discharging at 1 W i do believe it is discharging at more or less 1 W. Because it is the inverter that sets the battery to charge or discharge at whatever rate it is charging or discharging at... , after analysing house load and solar production sensors. And with that very small charge or discharge also comes a conversion or transfer loss again and if you keep an eye on "sensor.apf_inverter_power_consumption" like I usually do, you will notice it to increase sometimes from 0 to like 10 or 30 W. Its bad that the inverter does such small scale adjustments sometimes not in a good way. But if i have time tomorrow (I'm home on call i might be called for emergency work tomorrow), I will rewrite this possibility to the templates, for those who want this only...

[purcell-lab]

It might be a 'nicer' visualisation to have the solar 404W allocated to the house first (generation2house flow) and reduce the battery2house flow by the same amount (404W) to keep the ledger in balance.

@AviadorLP

Another example of flow not going to the house from solar, whilst not technically incorrect it would be nicer to have the solar allocated to house first?

https://user-images.githubusercontent.com/79175134/164878047-05ee5558-ce1f-4b13-a705-1b5ba3c1df96.mp4

[AviadorLP]

It might be a 'nicer' visualisation to have the solar 404W allocated to the house first (generation2house flow) and reduce the battery2house flow by the same amount (404W) to keep the ledger in balance.

@AviadorLP

Another example of flow not going to the house from solar, whilst not technically incorrect it would be nicer to have the solar allocated to house first?

Screen.recording.2022-04-23.14.39.32.video-converter.com.mp4

Inverter are kind of smart and avoid converting power from ac to dc or dc to ac when they can, because like i said that carries a loss that can be avoided if there is no conversion. So inverters avoid conversion whenever they can (also i think almost all inverters are not able to convert ac to dc and dc to ac at the same time, they do one or the other witch is smart, only 1 conversion equals smaller power losses and longer inverter life). Inverters are programed to save power if they can and the higher amount of power being converted the higher the power loss due to inverter consumption and also extra heat that is generated that damages the hardware.

So in short the flows above show exactly what is going on in reality. Because Solar DC power is all being transferred to battery DC power, no conversion power loss is happening here. And partial Grid AC power is being transferred to the house AC power, no conversion power loss is happening here also. An a partial 2.7 kW Grid AC power is being converted to DC and transferred to Battery DC power (This is the only power conversion happening at this time with maybe a loss of about 100 to 200 watts)

If the system worked like you say it would be converting 2.3 kW from solar to house plus 5 kW grid to Battery that would increase the inverter consumption maybe to 500 W. And like i said from what i learned inverters are not able to convert ac to dc and dc to ac at the same time (That could even cause inverter over temperature and shutdown)

Simple power transfers also have some power losses but a lot less than power conversions.

[AviadorLP]

If you find a bug in the flows please show me a picture of the flow chart so i can revise the math again.

@AviadorLP another minor comment would be to address the threshold for minor power flows #115 , which I would imagine could be straight forward in the templates with adjusted min/ max functions. Perhaps dumping the additional 'rounding errors' into the 'inverter power consumption sensor, which also was a neat hack in your template code.

That is a very easy thing to do in my templates, although I believe it to be a wrong thing to do. If the inverter is actually telling you the battery is discharging at 1 W i do believe it is discharging at more or less 1 W. Because it is the inverter that sets the battery to charge or discharge at whatever rate it is charging or discharging at... , after analysing house load and solar production sensors. And with that very small charge or discharge also comes a conversion or transfer loss again and if you keep an eye on "sensor.apf_inverter_power_consumption" like I usually do, you will notice it to increase sometimes from 0 to like 10 or 30 W. Its bad that the inverter does such small scale adjustments sometimes not in a good way. But if i have time tomorrow (I'm home on call i might be called for emergency work tomorrow), I will rewrite this possibility to the templates, for those who want this only...

Ok i've done it, the easy way with min changes. Although i do not recommend this. Here it is. Just change the beginning of the script with this and adjust as you like.

# Templates for Actual Powerflow transfer charts (APF - Actual PowerFlow)
#
# For the math to add up a new Real House Load must be calculated and used, witch includes
# the inverter consumption and excludes rounding errors and corrects inaccurate power readings.
#
# It never made sense that inbound power sometimes does not equal outbound power. This fixes it!
#
# Developed by AviadorLP
#
# Just replace the 4 words below "ReplaceWithYourSensor" with your specific sensors,
# for grid, house, solar and battery entities, example "sensor.solax_house_load" 
#
# If your sensor is negative when it should be positive replace the following:
# states('ReplaceWithYourSensor')|int(default=0) with (0 - states('ReplaceWithYourSensor')|int(default=0))
#
# If you don't have a battery replace that complete line with
#         state: "{{ 0 }}"
#
# If you only want to show flows for values above a certain value change the "initial" value below
# of the input numbers as required ex: 3 for minbattflow and minsolarflow and maybe 25 for mingridflow
# do notice that the flow chart entities will also show as "0" below this values.

input_number:
  minbattflow:
    name: Minimun Battery Flow
    initial: 0
    min: 0
    max: 100
    unit_of_measurement: W
    icon: mdi:flash
  minsolarflow:
    name: Minimun Solar Flow
    initial: 0
    min: 0
    max: 100
    unit_of_measurement: W
    icon: mdi:flash
  mingridflow:
    name: Minimun Grid Flow
    initial: 0
    min: 0
    max: 100
    unit_of_measurement: W
    icon: mdi:flash

template:
- sensor:
# grid sensor must be negative when importing and positive when exporting
  - name: APF Grid Entity
    device_class: power
    state_class: measurement
    unit_of_measurement: W
    state: >
      {%- set APFGE = states('ReplaceWithYourSensor')|int(default=0) %}
      {{ APFGE if APFGE|abs >= states('input_number.mingridflow')|int(default=0) else 0 }}

# sensor must always be 0 or positive (i think they always are)
  - name: APF House Entity
    device_class: power
    state_class: measurement
    unit_of_measurement: W
    state: "{{ states('ReplaceWithYourSensor')|int(default=0) }}"

# sensor must always be 0 or positive (i think they always are)
  - name: APF Generation Entity
    device_class: power
    state_class: measurement
    unit_of_measurement: W
    state: >
      {%- set APFSE = states('ReplaceWithYourSensor')|int(default=0) %}
      {{ APFSE if APFSE|abs >= states('input_number.minsolarflow')|int(default=0) else 0 }}

# battery sensor must be positive when charging and negative when discharging
  - name: APF Battery Entity
    device_class: power
    state_class: measurement
    unit_of_measurement: W
    state: >
      {%- set APFBE = states('ReplaceWithYourSensor')|int(default=0) %}
      {{ APFBE if APFBE|abs >= states('input_number.minbattflow')|int(default=0) else 0 }}

[purcell-lab]

Because Solar DC power is all being transferred to battery DC power, no conversion power loss is happening here.

Thanks for the explanation, which makes even more sense in my case as I have a AC coupled battery (Powerwall2) so every time energy is going into or out of the battery there is another conversation loss. The bias will always to consume grid energy directly in the house as there is no conversion. I was thinking, incorrectly, the bias would be to use solar as it is locally generated.

So in my case with a AC coupled battery the APF Inverter Power Consumption would be the sum of my battery inverter and my two solar inverters.

I do have a number of measurement points I can access do an wondering what impact that would could have on the APF Inverter Consumption calculations.

My two three phase solar inverters (SolarEdge MODBUS) can report both DC & AC power flows, so that would report the conversion loss directly. My Powerwall energy gateway also measures the critical four power points if solar, home (load), site (grid) and battery, which is what is feeding the APF templates.

[AviadorLP]

Ok i spent a while studying my inverter and how it manages power. To make a script that represented real flows. I did not know that some batteries are AC. All batteries i know of are DC. So in your case if you have an AC battery i guess the flows will not be a real representation in you case. Sorry for that. I could make an adaptation for you but i would have to understand all the logic behind your system to know how your inverter distributes power in all cases. Witch i do not understand or visualize right now in my head.

[poldim]

Ok i spent a while studying my inverter and how it manages power. To make a script that represented real flows. I did not know that some batteries are AC. All batteries i know of are DC. So in your case if you have an AC battery i guess the flows will not be a real representation in you case. Sorry for that. I could make an adaptation for you but i would have to understand all the logic behind your system to know how your inverter distributes power in all cases. Witch i do not understand or visualize right now in my head.

It looks like they've decided to package the inverter with each PW2 so the output is always AC. There are a few SLDs that show the standard implementations on the second page.

https://www.tesla.com/sites/default/files/pdfs/powerwall/Powerwall%202_AC_Datasheet_en_northamerica.pdf

But doesn't the PW provide the same outputs as listed in this original card?

[AviadorLP]

From what i can see. The flows works about the same way with maybe a change when charging the PW, it might get the power from the grid instead of from the solar inverter. But that would be the only change in the flows and not even that is certain. All i can see is that all solar DC power is always converted to AC then it goes to house or to PW or even to the grid if in excess, not sure the priority. So like you said, technically the flows are correct although they might not be exactly what is going on in your case. But for the rest of the inverters with DC Batteries they are correct! In any case what i believe is that all your solar power is always injected in you "House Power Line" plus whatever you get from the grid at the same time so in fact you will get mixed values of flows into the PW and the House load (both should be be getting power from both the inverter and from the grid at the same time)

[AviadorLP]

A division of these the flows might be best in your case, like you said before, this would be the most accurate visualization . Don't know how to program this though, i have to thing about this.....