Lovelace: Power wheel card

[gurbyz (Gerben)]

@Mariusthvdb

I am never sure what to use in calculating costs. what are you calculating in the card. The total costs, or the current cost for the day. If the latter, we should subtract the total count from the current count? use the daystart sensors again here?

I use ‘energy consumed/produced this day’ for the card in my own set up, because I like the more significant values you get by doing that. For this you indeed need the day start values. (Totals are also interesting, but I personally show them somewhere else in HA, not in the card.)

Tip: please use float instead of int to not loose the decimals in each of your counters. It matters when you multiply energy times price.

@Mariusthvdb

what are you calculating in the card.

Calculation for costs/savings is very basic: all values shown in the energy view are multiplied with the (averaged) energy_price and shown in the money view. If you use ‘energy burned this day’ it calculates to ‘money spent this day’.

@gurbyz

but you still have to find a solution for not having the production of the solar panels split in high and low tariff.

You have to solve this problem first before you can start thinking about using the different tariffs in the card.

Thx for testing the dev version of the power-wheel-card!

[eh50 (Ezra)]

Yeah, well i suppose we could, for the time beeing just use High grid tariff and low solor production tariff. That way you wont be surprised with a higher cost or lower income, right? Got IRC or something like that? Testing this in native language and on chat would speed it up

[Mariusthvdb (Marius)]

@gurbyz

I use ‘energy consumed/produced this day’ for the card in my own set up, because I like the more significant values you get by doing that. For this you indeed need the day start values

cool:

calculated_totaal_dag_afname:
  friendly_name: Totaal dag afname
  unit_of_measurement: 'kWh'
  value_template: >
   {{ (states('sensor.teller_1')|float
     + states('sensor.teller_2')|float -

     states('sensor.teller_1_daystart')|float
     - states('sensor.teller_2_daystart')|float)|round(2) }}

calculated_totaal_dag_levering:
  friendly_name: Totaal dag levering
  unit_of_measurement: 'kWh'
  value_template: >
   {{ (states('sensor.teller_1_terug')|float
     + states('sensor.teller_2_terug')|float -

     states('sensor.teller_1_terug_daystart')|float
     - states('sensor.teller_2_terug_daystart')|float) | round(2)}}

@gurbyz

You have to solve this problem first before you can start thinking about using the different tariffs in the card.

would simply need to split the above sensors per ‘teller’:

calculated_totaal_dag_afname_t1:
  friendly_name: Totaal dag afname T1
  unit_of_measurement: 'kWh'
  value_template: >
   {{ (states('sensor.teller_1')|float -
       states('sensor.teller_1_daystart')|float)|round(2) }}

calculated_totaal_dag_levering_t1:
  friendly_name: Totaal dag levering T1
  unit_of_measurement: 'kWh'
  value_template: >
   {{ (states('sensor.teller_1_terug')|float -
       states('sensor.teller_1_terug_daystart')|float) | round(2)}}

calculated_totaal_dag_afname_t2:
  friendly_name: Totaal dag afname T2
  unit_of_measurement: 'kWh'
  value_template: >
   {{ (states('sensor.teller_2')|float -
       states('sensor.teller_2_daystart')|float)|round(2) }}

calculated_totaal_dag_levering_t2:
  friendly_name: Totaal dag levering T2
  unit_of_measurement: 'kWh'
  value_template: >
   {{ (states('sensor.teller_2_terug')|float -
       states('sensor.teller_2_terug_daystart')|float) | round(2)}}

Got them working nicely here…proof (uncustomized new sensors at the top), at the bottom the sensors used now in the card version 0.0.5:

now where is the link for the dev version 0.0.6?

EDIT
never mind the link, Ive found it.
Im bending my mind here, so please help me:

this is the config, and Ive left the old entities in there for reference:

  - type: 'custom:power-wheel-card'
    title: 'Power distribution'
    solar_power_entity: sensor.zp_actuele_opbrengst
    grid_power_entity: sensor.netto_verbruik
    grid_power_consumption_entity:
    grid_power_production_entity:
    solar_energy_entity: sensor.solar_energy_entity
    grid_energy_entity: sensor.grid_energy_total
    grid_energy_consumption_entity: sensor.calculated_totaal_dag_afname
    grid_energy_production_entity: sensor.calculated_totaal_dag_levering
    color_icons: true
    power_decimals: 2
    energy_decimals: 2
    energy_price:
    initial_view: energy

I take it I have to use the newly created sensors Ive posted above at the grid_energy_consumption/production_entity ?

Im stuck what to do at the grid_power_consumption/production_entity though. Would you please have another look and assist in configuration? Thanks!

would this do for production:

  {{ (states.sensor.zp_pulse_total.state|float -
  states.sensor.zp_pulse_total_daystart.state|float)|round(2) }}

being the current total production pulses - daystart, hence the production for the day?

I also have a dedicated sensor for last_day production of the solar panels, but that seems to calculate the day before, and not from daystart to now…

What to use for grid_power_consumption/production_entity?

Since my dsmr sensors read the netto verbruik directly, I don’t have to calculate that. Power consumption should hence be as follows? :

calculated_bruto_verbruik:
  friendly_name: Bruto verbruik
  unit_of_measurement: 'Watt'
  value_template: >
    {{ (states('sensor.zp_actuele_opbrengst')|int)
     + (states('sensor.netto_verbruik')|int) }}

and as a consequence I should then use the current solar production, sensor.zp_actuele_opbrengst, as power production?

completing the config as follows:

  - type: 'custom:power-wheel-card'
    title: 'Power distribution'
    solar_power_entity: sensor.zp_actuele_opbrengst
    grid_power_entity: sensor.netto_verbruik
    grid_power_consumption_entity: sensor.calculated_bruto_verbruik
    grid_power_production_entity: sensor.zp_actuele_opbrengst
    solar_energy_entity: sensor.solar_energy_entity
    grid_energy_entity: sensor.grid_energy_total
    grid_energy_consumption_entity: sensor.calculated_totaal_dag_afname
    grid_energy_production_entity: sensor.calculated_totaal_dag_levering
    color_icons: true
    power_decimals: 2
    energy_decimals: 2
    energy_price: 0.45
    initial_view: energy

above setup gives:

which seems alright at first glance?

[VDRainer]

@gurbyz, i’ve enabled the color_icons parameter.
producing: yellow
consuming: green

Shouldn’t the grid power icon be yellow on positive values (producing), or am i thinking wrong?

[gurbyz (Gerben)]

Hi @Mariusthvdb ,
I think your calculated_totaal_dag_afname and calculated_totaal_dag_levering are correct. Maybe you could round them to 3 decimals, because then the calculation in the card will be more precise. You can leave the card parameter energy_decimals still at 2 though.

@Mariusthvdb

I take it I have to use the newly created sensors Ive posted above at the grid_energy_consumption/production_entity ?

Yes

@Mariusthvdb

would simply need to split the above sensors per ‘teller’:

No. But let’s talk about different tariffs later.

@Mariusthvdb

Ive left the old entities in there for reference

And you should, because you do use the grid_power_entity e.g. for its dynamic icon. See the second table of card parameters in the readme (for advanced users).

@Mariusthvdb

What to use for grid_power_consumption/production_entity?

It should be in ‘Watt’ in your situation. And it should be a sensor that gets its information only from DSMR. I think you are mixing up things, because you have grid_power_production_entity: sensor.zp_actuele_opbrengst and that’s coming from your solarpanels.
Looking at your DSMR4 Slimme Meter image a couple of posts before, I see indeed only one Netto verbruik sensor in Watts. Did you see that ever turn negative on a very sunny day? Then you can split this sensor into grid_power_consumption/production_entity yourself like I explained. (The explanation was for grid_energy_consumption, but you can use it also for power).

Almost there!

[gurbyz (Gerben)]

@VDRainer

Shouldn’t the grid power icon be yellow on positive values (producing), or am i thinking wrong?

Yes, they should. But it should be producing_color resp. consuming_color as card parameters. Not producing and consuming. Maybe that’s why it’s not picked up. (But then it’s still strange because it would use the default colors of your theme. And they probably didn’t switch the colors like this.)

[VDRainer]

This is what i have in the config:

color_icons: true
consuming_color: "#9bc53d"
producing_color: "#fde74c"

[gurbyz (Gerben)]

@eh50

eah, well i suppose we could, for the time being just use High grid tariff and low solor production tariff. That way you wont be surprised with a higher cost or lower income, right?

Hi @eh50, for now I like the combination of “an average price and less complexity, but not exactly right” more than the combination of “two prices and more complexity, but still not exactly right”. We’re talking about daily energy consumption here. But solutions would be off in the range of some cents.

I like the conversation via the forum: everyone can join/learn and we don’t have to sync our dev time.

Maybe we could split the solar energy values based on the tariff value? I mean building up a solar_low and solar_high value during the day by comparing the value with the last actual value and add the difference to one of the two variables according to tariff?
Or, use db queries?

[gurbyz (Gerben)]

@VDRainer

consuming_color: “#9bc53d” producing_color: “#fde74c”

You mixed up the color codes. The top one is a greenish color, the bottom one a yellowish…

[VDRainer]

Yes, i want it that way.
Yellow (sun) -> producing
Green (house) -> consuming
I only switched the color values from your default config.
BTW: The screenshot on your git shows the same, only the other way around.

Sorry for the confusion!

[gurbyz (Gerben)]

Ah, okay. Now I see what you mean.

It’s by design. I chose to have color A for ‘good for your wallet’ everywhere in the card. Color B is for the ‘bad for your wallet’. That’s why solar is color A or inactive; grid can be either color A, B or inactive and home is color B or inactive.

[Mariusthvdb (Marius)]

@gurbyz

What to use for grid_power_consumption/production_entity?

It should be in ‘Watt’ in your situation. And it should be a sensor that gets its information only from DSMR. I think you are mixing up things, because you have grid_power_production_entity: sensor.zp_actuele_opbrengst and that’s coming from your solarpanels.
Looking at your DSMR4 Slimme Meter image a couple of posts before, I see indeed only one Netto verbruik sensor in Watts. Did you see that ever turn negative on a very sunny day? Then you can split this sensor into grid_power_consumption/production_entity yourself like I explained. (The explanation was for grid_energy_consumption , but you can use it also for power).

Almost there!

Thanks!
I’m not really sure im misconfigured right now. The card matches my own production/consumption sensor perfectly.

As said, the only dmsr sensor is a netto verbruik sensor, meaning it shows only the true grid power consumption, taking into account my homes production and subtracting that from the total (bruto) consumption.
Hence I had to create this Bruto sensor which adds the current Solar production to the Netto consumption…

What I don’t understand in your explanation is what is wrong with the setting for the grid_power_production_entity: sensor.zp_actuele_opbrengst.
It calculates perfectly, and is in fact the only sensor having to do with my homes production, namely my solar panels. It is in Watt.

@gurbyz

Did you see that ever turn negative on a very sunny day? Then you can split this sensor into grid_power_consumption/production_entity yourself like I explained. (The explanation was for grid_energy_consumption , but you can use it also for power).

Yes it does frequently, as does my own sensor. Ill give you the configuration for that below:

levering_of_verbruik:
  friendly_name_template: >
    {% if states('sensor.netto_verbruik')|int > 0 %} Verbruik
    {% else %} Levering
    {% endif %}
  icon_template: >
    {% if states('sensor.netto_verbruik')|int > 0 %} mdi:import
    {% else %} mdi:export
    {% endif %}
  value_template: >
    {{states('sensor.netto_verbruik')|int}}

and customized to show the bruto verbruik also:

sensor.levering_of_verbruik:
  state_card_mode: badges
  templates:
    theme: >
      if (state > 0) return 'orange';
      return 'green';
    unit_of_measurement: >
      ${entities['sensor.calculated_bruto_verbruik'].state}

as it is night now this is what’s showing:

and your card:

I’ll change the bruto_verbruik sensor into floats and round them too.

@gurbyz

Looking at your DSMR4 Slimme Meter image a couple of posts before, I see indeed only one Netto verbruik sensor in Watts. Did you see that ever turn negative on a very sunny day? Then you can split this sensor into grid_power_consumption/production_entity yourself like I explained. (The explanation was for grid_energy_consumption , but you can use it also for power).

so you mean this example?:

grid_energy_consumption:
  friendly_name: Grid energy consumption
  unit_of_measurement: 'kWh'
  value_template: >-
    {%- if states('sensor.grid_energy_total') | float > 0 -%}
      {{ states('sensor.grid_energy_total') }}
    {%- else -%}
      0 
    {%- endif -%}

which would then become:

grid_power_consumption:
  friendly_name: Grid power consumption
  unit_of_measurement: 'Watt'
  value_template: >
    {% if states('sensor.netto_verbruik') | float > 0 %}
      {{ states('sensor.netto_verbruik')|float|round(2) }}
    {% else %}
      0 
    {% endif %}

grid_power_production:
  friendly_name: Grid power production
  unit_of_measurement: 'Watt'
  value_template: >
    {% if states('sensor.netto_verbruik') | float < 0 %}
      - {{ states('sensor.netto_verbruik')|float|round(2) }}
    {% else %}
      0 
    {% endif %}

?

[Mariusthvdb (Marius)]

@gurbyz

Maybe we could split the solar energy values based on the tariff value? I mean building up a solar_low and solar_high value during the day by comparing the value with the last actual value and add the difference to one of the two variables according to tariff ?

Wouldn’t that be futile? Solar production will always be in the High tariff? So no use building a solar_low entity or calculation, at least here in the Low Countries with our tariffs regulations.

When considering using those tariffs differentiations it would make more sense doing so with the power consumption …?

[gurbyz (Gerben)]

@Mariusthvdb

What I don’t understand in your explanation is what is wrong with the setting for the grid_power_production_entity: sensor.zp_actuele_opbrengst .
It calculates perfectly, and is in fact the only sensor having to do with my homes production, namely my solar panels.

Hi @Mariusthvdb . Let me try to explain. The value of grid_power_production_entity is displayed (in version 0.0.6) on the left arrow. It should be a sensor that takes into account only a value of your DSMR, not of your solar panels. It states what you give back to the grid. You could see the (wrong) result in the image that you shared a couple of posts ago (in post 103). It shows 156.06W in top, but since your house is consuming 674.00W, the right arrow should give a value, because the power produced by your solar panels is flowing to your house, where it’s consumed directly. It’s not given back to the grid, like your card shows now.
But you found the solution already: in post 112 your wrote down the correct sensors to use.

@Mariusthvdb

Solar production will always be in the High tariff?

Not with my energy provider. All weekends are completely Low Tariff for me. Maybe that differs per company.

[Mariusthvdb (Marius)]

You’re right on both accounts . Indeed I realized after creating these these new templates what you were after… and of course I forgot about the weekends. Sorry!

I was confused , but you have made it more confusing than necessary tbh

It is rather counter intuitive to have to use 2 separate entries for the same sensor. Whether the power is pos or neg shouldn’t really matter, like before. Why did you change that?

If I might suggest another improvement: do away with the word ‘ entity’ in the config. It is a reserved word in HA and adds to the confusion( did in my experience )

Why not simply use something like

current_netto_power ( for both production and consumption, it is after the same sensor, either positive or negative)
and
total_day_production and total_day_consumption

I feel that would make it all the more user friendly.

As you said , I’ve got it working correctly now, but had to make 8 dedicated sensors
up to now added to my default sensors I already had…

Hope this helps, and as always: thanks for your effort and replies, they truly help!

[gurbyz (Gerben)]

Version 0.0.6 has been released

Please don’t forget to update the v= parameter as described in the Note in the first post.

New features

• Unit is displayed in the center of the wheel.
• BREAKING. To switch views click the unit. The button has been removed.
• Arrow coloring now also in energy view. *)
• Power, energy and money values displayed next to all arrows. *)
• A third view: money view for displaying energy costs and savings. *)
  When you supply card parameter energy_price (in addition to the parameters needed for the energy view) the money view becomes available.

*) To make this feature possible the breaking changes as described below were needed.

Improvements

• Rewrite: separating calculating values in the code.
• Value for home will be calculated always and not taken from evt. home sensors anymore.
• BREAKING. Card parameter grid_power_entity has been split into grid_power_consumption_entity and grid_power_production_entity.
  Both card parameters are required and should have positive values.
  The combined parameter grid_power_entity can still be used to supply the grid icon in the power view, but the power value isn’t used anymore.
• BREAKING. Card parameter grid_energy_entity has been split into grid_energy_consumption_entity and grid_energy_production_entity.
  Both card parameters are required if you want to use the energy view and should have positive values.
  The combined parameter grid_energy_entity can still be used to supply the grid icon in the energy view, but the energy value isn’t used anymore.

[gurbyz (Gerben)]

@Mariusthvdb

I was confused , but you have made it more confusing than necessary tbh

It is rather counter intuitive to have to use 2 separate entries for the same sensor. Whether the power is pos or neg shouldn’t really matter, like before. Why did you change that?

For the power card parameters you have a point, but for the energy card parameters is was necessary to be able to derive all the 6 values to be displayed. I chose for consistency between the energy and the power parameters. That’s why I also changed the power parameters.

@Mariusthvdb

total_day_production and total_day_consumption

Then these card parameters names would be more restrictive than grid_energy_production and grid_energy_consumption. Maybe too restrictive. E.g. if you want to use weekly or monthly input sensors, the card will function fine with that. (Although the money view will be a bit more off if you own double meter counter with High/Low tariff. )

@Mariusthvdb

thanks for your effort and replies, they truly help!

Thx. Your comments and suggestions are more than welcome. They also will help other users, because of your examples and shared images.

[Mariusthvdb (Marius)]

Cool. Appreciated!

Final thought: it just dawned to me: the confusion lies mostly in the word ‘production’. This is not the same as ‘returned to the grid’

I produce a lot of power but mostly use it my self…

I think changing the names to reflect that, and lose the entity part might be a best solution?

Cheerio!

[jstride (Jake Stride)]

I’d agree the grid producing and consuming names are the ‘wrong’ way around for me - took trial and error to figure it out.

Also, the money piece could be great but my tarrif has a cost to purchase from the grid and cost to sell that are different (obviously my utility charges me more to buy power from them than to sell it back) so having multiple values would be helpful.

Thanks for the updates!

[cjsimmons (Chris Simmons)]

Well, I think that’s the end of this card for me. The new update makes it useless for me as I now have to have very certain entities to use this card, and any existing setup now no longer works.

Splitting the grid production and consumption in to 2 different entities and both requiring to have a positive value is not possible. My solar PV system has a net output and it’s either a positive or negative value. There is no need for me to go and fart around for who knows how long to convert this into yet more sensors just to get this card to work. Either power is flowing in or out, + or -.

I’d like to know what systems output in this new format you are using? I think this card has gone from something simple to something so complex that it now only applies to a very small subset of users.

As of v0.0.6, this card is useless to me.