Yup that doesn’t bother me and I can do the template for the exporting/importing of watts, just can’t do anything about the kWh going backwards.
I think i’m categorie B, i want too see the grid icon as consuming when the power goes to the grid.
As i only use the power view, i changed line 150 from
data.grid = this._makePositionObject(hass, data.grid.val, config.grid_power_entity, config.grid_icon,
'mdi:flash-circle', this.power_decimals, false);
to
data.grid = this._makePositionObject(hass, data.grid.val, config.grid_power_entity, config.grid_icon,
'mdi:flash-circle', this.power_decimals, true);
Now the color is OK for me.
@gurbyz, what about a simple flag invert_grid_color: true ? 
Was totally unhappy that the home_power_entity is no more used, as i have a battery. 
I’m now using the card twice with the conditional card.
Only changed the solar_power_entity to the battery sensor, and the icon.
If the sun is down and the power comes from the battery, it shows the sun as battery.
- type: conditional
conditions:
- entity: binary_sensor.e3dc_pv0_batt_neg
state: 'on'
card:
type: "custom:power-wheel-card"
title: Leistungsverteilung
solar_power_entity: sensor.e3dc_battery_power_pos
grid_power_production_entity: sensor.e3dc_net_power_pos
grid_power_consumption_entity: sensor.e3dc_net_power_neg
home_icon: mdi:home-outline
solar_icon: mdi:car-battery
grid_icon: mdi:sitemap
color_icons: true
consuming_color: "#9bc53d"
producing_color: "#fde74c"
- type: conditional
conditions:
- entity: binary_sensor.e3dc_pv0_batt_neg
state: 'off'
card:
type: "custom:power-wheel-card"
title: Leistungsverteilung
solar_power_entity: sensor.e3dc_pv_total
grid_power_production_entity: sensor.e3dc_net_power_pos
grid_power_consumption_entity: sensor.e3dc_net_power_neg
home_icon: mdi:home-outline
solar_icon: mdi:white-balance-sunny
#grid_icon: mdi:transmission-tower
grid_icon: mdi:sitemap
color_icons: true
consuming_color: "#9bc53d"
producing_color: "#fde74c"
Thanks for your effort!
1 Like
First of all thanks for all the great effort. I will get my solar panels in a month and wanted to start with the lovelace configuration before so everything is ready when they arrive. So… I just migrated to HA 0.86.1. And now lovelace is default. I wanted to wait to implement everything until now. However I was able to set this up before but now I started from scratch. If I understand this correct I now press the plus sign in the gui, choose a card to add but as this card is not default I press skip and is presented with an editor. I just do not get the syntax here. Would anyone want to share their code if you are able to edit the card. I wanted to do this in the gui prior to use the raw editor as I am afraid to mess everything up.
I’m only using yaml mode, so nut sure, but i think you need the raw editor to configure custom cards.
The alternative CDN does break the current version. On DEV is already a better version. I will release later today to MASTER.
EDIT: Release is done.
0.0.7
Improvements
- Upgrade to lit-element 0.6.5.
Fixes
- Switch back from unpkg-gcp.firebaseapp.com to unpkg.com again because of CORS error.
HI @gurbyz
any thoughts on this: Cross-origin script load denied by Cross-Origin Resource Sharing policy
suddenly I see these, didn’t change a working setup …
Hi @Mariusthvdb Please see the message above your message. It’s the CORS error. It was caused by firebaseapp.com. Maybe they weren’t too happy that everyone switched from unpkg.com to them (because of the ‘localhost issue’ that occurred on the original unpkg.com CDN a while ago.)
It’s fixed in release 0.0.7 yesterday.
duh, I am so sorry…
one thing to note, in the new version you use render without a _
render({ hass, config }) {
let data = {
solar: {},
solar2grid: {},
solar2home: {},
grid: {},
grid2home: {},
home: {},
};
while in the old versions you use
_render({ hass, config }) {
let data = {
solar: {},
solar2grid: {},
solar2home: {},
grid: {},
grid2home: {},
home: {},
};
is that correct or a typo (all other functions use the _ )?
That’s part of the changes that lit-element had between version 5.2 and 6.5. In fact, almost all the changes of release 0.0.7 are because of this reason. I have a few major changes of lit-element to go before I get to your suggestion (to include the local version of lit-element). 
ok thanks, Ive changed that, but not showing the card yet… this Lit thing is quite annoying o the cards that use it…
I can use it on ha 0.84.3 can I, havent updated to higher HA yet
Should be fine, because the lit-element is taken from the CDN, not from HA itself. It’s independent.
What did you do to update the power-wheel-card to 0.0.7?
your were quicker than I could be deleting my post…
I edited my older card, and have replaced it with your new card now, and it is showing!
thanks.
now that i have your attention 
would you consider adding a config option for the font-styles, and especially the central toggle-view one, which now is rather large and bold…
? It seems really out of content with the rest of the Ha style.
I probably can edit the style in the card, but making the a config option would make everyone happy?
1 Like
I want to switch to a different layout a.s.a.p. Nice big curvy arrows to make it a circle and the ‘wheel’ part of the name starts to make sense. All styling requests are postponed till after that.
But first, the backwards counting energy sensor and the confusing names issue to solve…
Ah yes, but don’t forget power distribution doesn’t always cycle like a wheel… maybe you shouldn’t focus as much on that for layout, especially when batteries are going to be used more in the nearby future. combined with domestic car electricity.
+1 on that 
start with ditching the word entity, and the config will become much cleaner… (changed grid_production to grid_return, cause that’s what it is, and solar is the only production entity… in the current setup.
- type: 'custom:power-wheel-card'
title: 'Power distribution'
# Watt units, as in real_time power
solar_power_production: sensor.zp_actuele_opbrengst #production = opbrengst
grid_power: sensor.netto_verbruik
grid_power_consumption: sensor.grid_power_consumption
grid_power_return: sensor.grid_power_return
# kWh units, as in total day energy
solar_energy_production: sensor.solar_energy_production
grid_energy: sensor.grid_energy_total
grid_energy_consumption: sensor.calculated_totaal_dag_afname
grid_energy_return: sensor.calculated_totaal_dag_levering #return = levering
color_icons: true
power_decimals: 2
energy_decimals: 2
energy_price: 0.51
initial_view: energy
my 2 cents.
o and changing to this:
ha-icon {
transition: color 0.5s ease-in-out, filter 0.3s ease-in-out;
color: var(--paper-item-icon-color, #44739e);
width: 36px;
height: 36px;
}
and
.unit {
display: table-cell;
text-align: center;
vertical-align: middle;
font-size: var(--paper-font-headline_-_font-size);
color: var(--secondary-text-color);
font-weight: bold;
}
wasn’t much of an effort, making all the difference (to me), so never mind the cosmetics for now
hope im not yet again asking a stupid question, but since I updated yesterday to your newest card version, I have this issue in a power returning situation:
as you can see a double minus…
and NaN in the card:
you must have changed the calculations in your CC, because my template is unchanged:
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 %}
or can we use the same netto sensor for both entities again ?
I know my sensors are working as expected because of 
I did change the calculations, but it’s the input sensor that behaves a bit strange. The value probably isn’t parsable as a number. Maybe you could try changing your sensor to this:
grid_power_production:
friendly_name: Grid power production
unit_of_measurement: 'Watt'
value_template: >
{% if states('sensor.netto_verbruik') | float < 0 %}
{{ 0 - states('sensor.netto_verbruik')|float|round(2) }}
{% else %}
0
{% endif %}
Hope this helps.
no, don’t go that route please…
my sensor.netto_verbruik is negative when returning power to the grid. It is the actual smart meter returning this…
Maybe I shouldn’t use the -?
which would make the 2 sensors (assuming you need a negative value when returning power?:
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 %}
… for + or - values, the same sensor.
as an update:
I’ve fixed it for now, hope you will stop changing algorithm’s needing us to create new sensors over and over…
this does the trick in the current card:
grid_power_consumption:
friendly_name: Grid power consumption
unit_of_measurement: 'Watt'
value_template: >
{% if states('sensor.netto_verbruik')|int > 0 %}
{{ states('sensor.netto_verbruik')|int }}
{% else %}
0
{% endif %}
grid_power_production:
friendly_name: Grid power production
unit_of_measurement: 'Watt'
value_template: >
{% if states('sensor.netto_verbruik')|int < 0 %}
{{ (states('sensor.netto_verbruik')|int|abs )}}
{% else %}
0
{% endif %}
which means I can use the same sensor for both entities after all, because {{ (states('sensor.netto_verbruik')|int|abs )}} is also valid for > 0 and 0.
I’ve reexamined my DSMR data, and the netto_verbruik sensors in fact an int, so no use creating floats out of that. But that wasn’t the solution. Sine you require the data in the grid all to be positive (and the net_verbruik is negative when returning power to the grid) I use |abs to make it positive:
the returned power shows up as negative though, which does seem somewhat irregular, but it is the correct value. As you can see the icon is green, which means it is returning power, and the icon is correct too: mdi:export (though in this card it might seem confusing pointing to the right…
consuming:
Edit:
as you can see in the ‘returning power’ top screenshot, the numbers next to the arrows are the same as the entity numbers. Might not be necessary to show them in next to the arrows, to avoid an overload of data. As you needn’t show 0, when not returning or not consuming.
1 Like
Looking at the images above, it looks like a lot of redundant info is displayed with the arrows. The arrows have the exact same value as one of the entities either side of it. It’s good to see this card develop, but I don’t get why the same value is shown twice. For example, if the solar is exporting excess power, the arrow and the grid icon both show the same value.
Even though I have stopped using this card for now as it’s way over the top and complex for my use, and requires me to make more template sensors that I don’t really need, I’m still following it to see how things progress.
1 Like
seems we cross posted
there’s another, more worrying issue though: ever since I loaded the new card, my Lovelace has become rather slow, up to unresponsive. dev-state and dev-template wot load and the system even has restarted itself twice…
first thought it to be another set of sensors but now I have installed the Power wheel card, all those issues have disappeared. Not sure what calculations take place inside the card, and will check of course, maybe its the Lit dependency. Don’t know. I have excluded all entities in recorder, so that shouldn’t be it.