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.
mdi:transmission-tower is at last available in 0.87.0b0 
2 Likes
Loving the work that has gone into this. Like others have said the UI could do with a clean up as there is some redundant info plus I think it could look more modern. I was inspired by the Tesla app to create this animated mock up - https://i.imgur.com/obG0k4N.gifv (the statistics at the bottom are another project) I am not a dev myself but if I could get some analysis on the skills required to create this, I’ll find someone that can.
6 Likes
A new release again. I’m preparing the code for future changes (like support for backwards counting meters, etc). So this release is mostly about code improvements instead of functional improvements. But still there are some. See the changes below.
@mitchmario Thank you for sharing your design on what the card could look like. Very inspiring.
0.0.8
New features
- All zero values are suppressed. And values on the arrows are visible only when relevant. E.g. on a sunny day when part of your produced solar panel energy was returned to the grid and the other part was consumed by your home.
- More-info dialogues for arrows that are related to a sensor.
Improvements
- Immediate response when you click on the unit to toggle between views.
- Using the local version of lit-element.
- Code improvements.
Fixes
- More-info dialogues only for icons that are related to a sensor.
- Reduced clickable area for toggling the view.
1 Like
Hey Gerben,
updated to the version 08. All views are now bothered by the numbers, which are in the wrong place…and are wrong by them selves…
this is the correct situation:
also. loading your card to test it once more, made my HA instance become unresponsive and caused a spontaneous restart. Something in this card is really bugging HA. dev-state and dev-template take huge amounts of time, if they come up at all…
Ill take it out again, and wait for a next version, hope you’ll be able to sort things out.
Hi @Mariusthvdb, I can try to explain what’s going on with the values, but I’m hesitating since you gave me the “don’t go that route please” the last time when I pointed in the direction of your template sensors. 
(You had a template sensor that was giving a string result with a double minus sign in it.)
But no sarcasm on my side here. Let’s explain what’s going on with the values: The card can’t handle input sensors well that give values that were measured on different times.
In above example (I took your image) the solar energy input sensor gave a 0 and the grid energy production sensor gave 0.18 kWh. That is an invalid combination in itself which couldn’t happen in real life, but can happen in HA. Because the sensors are measured by HA on different times. I myself am blessed with input sensors that update both every 10 seconds. But if the solar sensor is updating every minute (for e.g.) and the grid sensors are updating every 30 seconds, you could get into this problem.
Maybe the card should check these temporarily invalid input combinations, but I could check only for detectable invalid situations and the undetectable invalid (but still invalid) combinations still wouldn’t be detected because they are obscured by the data itself (= you can’t write a if-statement for it).
Since you are also experiencing performance issues as well, the timing effect could be magnified by the performance issue.
About the performance issue. Although I have 116 components running in HA and don’t have performance issues, that doesn’t help you of course. But on the other hand, I could mean that you have a very specific situation that I can’t reproduce. Maybe other users of the power-wheel-card can confirm (or deny) any performance issues with version 0.0.8 that they could relate to the card?
One thing that comes to my mind is that if you have problems with the /dev-state en /dev-template pages of HA, that that is related to the backend of HA. The card runs completely in the frontend that resides in your browser not in the backend.
To be clear: if you switch off the card, you don’t experience any performance issues? And do you see any errors or warnings in the console of your browser? There should be none.
not sure. most of my sensors are updated real time, and my netto_verbruik sensor, and its templates, are updated every 10 seconds I think, its the DSMR that updates these.
this is another view, all shown just fine, and I can see each sensor update and respond to the other:
They all show just fine in my setup, regular and Lovelace. It’s when your card is used the performance is severely hampered. And, on each new version, new issues arise, and templates or sensors have to be adjusted to the way your card uses the data. That simply won’t do it I am afraid…
I am a heavy user, admitted, use 128 components. but they all fare well. Well mostly, only Hue has some issues, but apparently that is only the messenger of I/O going on. As I can see with using your card, Hue light show unavailable … (other story) It does signal that it burdens the system.
things changed though, and now this shows:
would this reflect your design better?
_Update
the response to the centre toggle is immediate, so that’s much better indeed.
well, yes, that’s what’s happened each time I test your card. It was an immediate effect after updating to the latest version also. Still, wondering about what you said, I thought it might have to do with history. That has been a terrible performer ever since I started with HA, and has been for many people. So I checked what else is using that, and found the history-graph of course, but also the mini-graph-card-bundle see Lovelace: mini graph card. I’ve temporarily disabled that to see what happens. (I was using your card and the mini-graph card alongside each other)
It seems to have effect… not sure if it is all gone, but if I use either card things speed up. If I use both, I get the aforementioned result: spontaneous reboot, halting system, and when trying to load the inspector, my browser kills itself and reloads the page, which it then won’t do… you get the picture of the issue)
needs further inspection.
Still, everything happening in the frontend does take its toll, especially with much customization going on. Not sure if that’s cause for relieve or sorrow.
Thx for your extensive response. Yes, now the images do reflect the current design. I found some hours this evening to dive into possible performance improvements. Found something in lit-element about the shouldUpdate() function that could help.
What’s happening? HA gives each custom card a large hass property. Cards check this hass object for changes in entities. By default HA and Lit-element cards are designed to update each visible card on every change of every entity (= automations, sensors, scripts, etc, etc). For large HA setups with many entities this can become a problem if you combine it with one or more of the heavier kind of cards. 
I made a change to the power-wheel-card to update the card only on specific entity changes (e.g. all the input sensors). That should skip a lot of unnecessary updates and should free some browser resources. There’s a version 0.0.9-dev available on the dev branch in the repo if you want to give it a try.
But since HA updates the visible cards only, you could also/first try to temporarily isolate each heavier kind of card on a separate view in Lovelace to test things. This approach could help to pinpoint the performance problems to a specific card.
I hope the dev-release and the test approach can in the end solve some of your performance problems, if not all.
testing right now…
please allow 2 suggestions:
the missing 0 under the sun icon is a bit too clean for me… In fact, it gives an uncertain feeling as the sensor isn’t picking up alright. I’d prefer it if no solar production is available to have it show 0 under the icon.
secondly, what would really be nice is if the title of the card were to change along with the view, and show, Power- Watt, Usage/Energy -kWh and Cost (which sound better than Money iyam) instead of the Power Distribution or whatever fixed title we give it, it is showing now.
thanks for trying to make it better, ill report if anything arises, good or bad…
UPDATE
after having taken out the mini-graph-card and letting it run for more than a day, I can report most of the performance issues have disappeared. (loading the page still takes out the Hue lights…) Apparently the combination of the 2 cards causes trouble. Not sure how and what to ask to check what could be the cause for this, but please let me tag @kalkih here to have a look? fyi, I am using HA 084.3.