cool, just to be sure:
grid-energy = (T1+T2+T3 - T1terug -T2terug -T3terug) - daystartversions(T1+T2+T3 - T1terug -T2terug -T3terug)
Yes, but you can skip the T3’s because you only have two meters. 
And don’t forget to exclude those new sensors from recorder: because your database will grow very fast.
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
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. 
made it!
just above normal…
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
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) 
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.
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
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 …
Would just like to share a new recently added icon:
mdi:transmission-tower
2 Likes
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, 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