Lovelace: Power wheel card

oops, of course, was confused by my phase meters… sorry.

which is too bad really, because this could actually be interesting to record… and my db is already 6gig and never gets purged. no matter what try

1 Like

check this please:

{{ (states('sensor.teller_1')|float + states('sensor.teller_2')|float - 
    states('sensor.teller_1_terug')|float - states('sensor.teller_2_terug')|float -
    states('sensor.teller_1_daystart')|float + states('sensor.teller_2_daystart')|float -
    states('sensor.teller_1_terug_daystart')|float - states('sensor.teller_2_terug_daystart')|float)|round(2) }}

getting a value of: 6318

30

would that be a value you recognize to be correct for the power wheel?

You need some operators fixed:

{{ (states('sensor.teller_1')|float + states('sensor.teller_2')|float -
 states('sensor.teller_1_terug')|float - states('sensor.teller_2_terug')|float - 
states('sensor.teller_1_daystart')|float - states('sensor.teller_2_daystart')|float + 
states('sensor.teller_1_terug_daystart')|float + 
states('sensor.teller_2_terug_daystart')|float)|round(2) }}

(E.g. You had + states('sensor.teller_2_daystart'). Make that - states('sensor.teller_2_daystart') please. I changed 3 things.)
If you end up with a number between 10 and 20 kWh you would have a fairly normal household. :slight_smile:

made it!

just above normal…

17
27

thanks!
now i can search for a better way to create those values, I might even have them hidden in my system sensors somewhere…this seems to be an awful complex way of calculating

feature request: have some logical naming on the card, right now it could have use some to the point clarification wattt 's watt :slight_smile:

btw had the solar energy sensors in the reverse order also… it should be now() - daystart on both sensors…

@Mariusthvdb Your solar energy sensor should have a positive value. Maybe you did ‘solar_midnight_energy minus solar_actual_energy’ instead of ‘solar_actual_energy minus solar_midnight_energy’? If the value is positive (as it should), the icon will turn green and your home energy will have a higher value than your grid energy.

EDIT: You got the point already (saw your EDIT to late) :smiley:

Going to let it rest for now, but also because I feel this card is heavy on the system. I’m experiencing sudden and long beachballs and the system log/error has returned…

clicking the i in the system tools has my HA instance wait and nothing happens, where that was rather immediate before.

Maybe this second functionality of the card takes a lot of resources ?

Request: please make this double meter sensitive… especially when future use will be calculating costs we need the discernabilty for high and low tariff.

Right now all consumption is added while in real life those tariffs are separated in calculations and costs. That’s why I now have such a long template adding it all together…

EDIT:
added these in my configuration:

grid_energy_total_verbose:
  friendly_name: Grid energy total verbose
  unit_of_measurement: 'kWh'
  value_template: >
    {{ (states('sensor.teller_1')|float + states('sensor.teller_2')|float -
        states('sensor.teller_1_terug')|float - states('sensor.teller_2_terug')|float -
        states('sensor.teller_1_daystart')|float - states('sensor.teller_2_daystart')|float +
        states('sensor.teller_1_terug_daystart')|float +
        states('sensor.teller_2_terug_daystart')|float)|round(2) }}

grid_energy_total:
  friendly_name: Grid energy total
  unit_of_measurement: 'kWh'
  value_template: >
    {{(states('sensor.grid_energy_teller_1')|float + states('sensor.grid_energy_teller_2')|float)|round(2)}}

grid_energy_teller_1:
  friendly_name: Grid energy 1
  unit_of_measurement: 'kWh'
  value_template: >
    {{ (states('sensor.teller_1')|float - states('sensor.teller_1_terug')|float -
        states('sensor.teller_1_daystart')|float + states('sensor.teller_1_terug_daystart')|float)|round(2) }}

grid_energy__teller_2:
  friendly_name: Grid energy 2
  unit_of_measurement: 'kWh'
  value_template: >
    {{ (states('sensor.teller_2')|float - states('sensor.teller_2_terug')|float -
        states('sensor.teller_2_daystart')|float + states('sensor.teller_2_terug_daystart')|float)|round(2) }}

The card itself isn’t that heavy. And it’s running in your browser, not in your HA instance. But the set of sensors could be to heavy depending on the way they are configured. You could switch off the card (or the sensors) temporarily to see if it’s the card or the extra sensors. Then you get more information where to improve.

The tip I gave on recorder: will decrease database resources (and also network resources if your db isn’t local) because template sensors based on dsmr sensors will update the db every 10 seconds.

Could you elaborate on how your ‘daystart’ sensors are configured?

will test some further and report back. And yes, I have excluded the sensors from recorder, so that not it.

my daystars sensors are directly taken from the dsmr smart meters sensors, via mqtt:

##########################################################################################
# DSMR4 Slimme meter Daystart
##########################################################################################
- platform: mqtt
  state_topic: 'mac/energy-dsmr4/id/T1_daystart'
  name: 'Teller 1 daystart'
  unit_of_measurement: 'kWh'
  value_template: '{{ value | round(2) }}'

- platform: mqtt
  state_topic: 'mac/energy-dsmr4/id/T2_daystart'
  name: 'Teller 2 daystart'
  unit_of_measurement: 'kWh'
  value_template: '{{ value | round(2) }}'

- platform: mqtt
  state_topic: 'mac/energy-dsmr4/id/-T1_daystart'
  name: 'Teller 1 terug daystart'
  unit_of_measurement: 'kWh'
  value_template: '{{ value | round(2) }}'

- platform: mqtt
  state_topic: 'mac/energy-dsmr4/id-T2_daystart'
  name: 'Teller 2 terug daystart'
  unit_of_measurement: 'kWh'
  value_template: '{{ value | round(2) }}'

Okay, cool. And those sensors aren’t heavy. At least no db queries there. :wink:
My own DMSR doesn’t return them directly. I have an automation which saves the current meter counters into a series of input_numbers each midnight.

yes, I’ve thought about saving these values. Might be better to have the CC variable do that? Custom component to declare/set variables

it can store several historic data, maybe easier? I use it in various other places and it works beautifully.

could you share your input_number setup? I don’t have that yet.

still, I am a bit surprised your DSMR doesn’t support this, aren’t that industry standardized configurations?

Thx for the link. Here’s the setup that I use to get the values of the meter counters every midnight.

The input_numbers in configuration.yaml:

input_number:
  solar_energy_midnight:
    name: "Solar energy production 00:00"
    min: 0
    max: 999999
    mode: box
    unit_of_measurement: 'kWh'
    icon: mdi:white-balance-sunny
  grid_energy_consumption_midnight:
    name: "Grid energy consumption 00:00"
    min: 0
    max: 999999
    mode: box
    unit_of_measurement: 'kWh'
    icon: mdi:flash-circle
  grid_energy_production_midnight:
    name: "Grid energy production 00:00"
    min: 0
    max: 999999
    mode: box
    unit_of_measurement: 'kWh'
    icon: mdi:flash-circle
  home_energy_midnight:
    name: "Home energy consumption 00:00"
    min: 0
    max: 999999
    mode: box
    unit_of_measurement: 'kWh'
    icon: mdi:home

The automation:

- alias: set_energy_midnight
  trigger:
    platform: time
    at: '00:00:00'
  action:
  - service: input_number.set_value
    data_template:
      entity_id: input_number.solar_energy_midnight
      value: >-
        {{ states("sensor.solar_energy") }}
  - service: input_number.set_value
    data_template:
      entity_id: input_number.grid_energy_consumption_midnight
      value: >-
        {{ states("sensor.grid_energy_consumption") }}
  - service: input_number.set_value
    data_template:
      entity_id: input_number.grid_energy_production_midnight
      value: >-
        {{ states("sensor.grid_energy_production") }}
  - service: input_number.set_value
    data_template:
      entity_id: input_number.home_energy_midnight
      value: >-
        {{ states("sensor.home_energy") }}

Then I use their values in other sensors, e.g.

- platform: template
  sensors:
    solar_energy_today:
      friendly_name: 'Solar energy production today'
      unit_of_measurement: 'kWh'
      value_template: >-
        {{ (states("sensor.solar_energy") | float - states("input_number.solar_energy_midnight") | float) | round(3) }}
1 Like

Aha, I see now. You use these as I use my daystart sensors. I don’t need these input_numbers for that. Luckily :wink:

I thought you wanted to save the daily usage/production somehow. Since we’ve disable the sensors_today in recorder, it would be possible to do the same to my sensor.grid_energy_total, save it automatically at midnight in a sensors/input/variable, and have recorder record these values once a day, instead of constantly during the day.
Hope this makes sense…

input_number:
  daily_grid_energy
    name: 'Daily grid energy production 00:00"
    min: 0
    max: 999999
    mode: box
    unit_of_measurement: 'kWh'
    icon: mdi:flash-circle


variable:
  daily_grid_energy:
    value: 'Not set'
    restore: true
    attributes:
      icon: mdi:ener-circle
      name: 'Daily grid energy'

automation:
# Update Grid energy variable
  - alias: 'Update Daily Grid Energy'
    id: 'Update daily grid energy'
    initial_state: 'on'
    trigger:
      platform: time
      at: '00:00:00'

    action:
      - service: input_number.set_value
        data_template:
          entity_id: input_number.daily_grid_energy
          value: >-
            {{ states('sensor.grid_energy_total') }}
      - service: variable.set_variable
        data:
          variable: daily_grid_energy
          attributes_template: >
            {
                  "history_1": "{{ variable.state }}",
                  "history_2": "{{ variable.attributes.history_1 }}",
                  "history_3": "{{ variable.attributes.history_2 }}",
                  "history_4": "{{ variable.attributes.history_3 }}",
                  "history_5": "{{ variable.attributes.history_4 }}"
            }
        data_template:
          value: >
            {{ trigger.to_state.attributes.friendly_name }}

beware, this is a quick and dirty transplant of one of my other variable automations, so i must still check everything… especially the data_template, which seems a bit useless right now.
Added a quick input_number to it, so recorder can save that too …:wink:

Would just like to share a new recently added icon:

mdi:transmission-tower

https://materialdesignicons.com/icon/transmission-tower

2 Likes

@dgomes Been wanting this. This will work well for me.

UPDATE: I can’t get this icon to show… :exploding_head:

Great icon @dgomes . I will add this as the default icon for the grid in the next release after HA includes this icon.

@cjsimmons The icon is just created at https://materialdesignicons.com. It takes a while before you can use it in HA. See this topic.

@gurbyz thanks. I did not know about that. Learnt something new. :slight_smile:

@gurbyz, great lovelace card.

I have one question. I’m using the plugin from hass for my solarpanel (sma). This gives values wh en the sun is up, and works fine. At night, the sma plugin gives the status: unknown. Because the power wheel gives with the solar NaN W, but also the home power is now NaN W. (see picture). It should be nice that if the solar is not working or unknown is that the power grid is the home power.

Hi @kroonen,

I’d like to keep the code as simple as possible. Instead of taking into account every situation that could occur for an individual sensor, there are some requirements in the readme. Otherwise the card becomes too heavy/slow and/or the code too complex. E.g. the value of the sensor always should be parsable as an int of float. The value ‘unknown’ doesn’t comply to that.

Maybe you already know how to fix this with a derived sensor, but then the explanation below can be useful for other people.

You can create a sensor based on your solarpanel sensor that is complying to the requirements:

sensor:
  - platform: template
    sensors:
      better_sensor:
        friendly_name: 'My better sensor'
        unit_of_measurement: 'W'
        value_template: >-
          {%- if is_state('sensor.original_sensor', 'unknown') -%}
            0
          {%- else -%}
            {{ states('sensor.original_sensor') }}
          {%- endif -%}

Then use the sensor.better_sensor as input for the card. I expect that both solar value and home value in the power-wheel-card will be correct when you do this. It’s because the ‘unknown’ value will be replaced by a zero value.

If you don’t want to record both sensors in your database, you can exclude one in your recorder setting.

recorder:
  exclude:
    entities:
      - sensor.original_sensor
1 Like

Thnx for this solution, this also a good option.

1 Like

best would be when the original sensor wouldn’t return ‘unknown’ of course… maybe you should file an issue at the components GitHub. Even at night/dark the sensor should work correctly and show 0, if no energy was produced.