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.
Have taken your two suggestions into account already. And I’m following your discussion on performance in the mini-graph-card topic with great interest.
cool. Though I have stopped using that for the cards I had, too much burden on the system. Your power-wheel seems to be much easier on the system lately so that’s fine too 
love the idea of this card
got a question - I have an Enphase system using an Envoy-S, which provides grid consumption and array production data - is anyone using this card with an Envoy, if so how are you calculating grid export?
Hi @DrewXT, I saw you’re getting support already in another topic by @exxamalte . Super! I understand the naming of the card parameters can be confusing. I will add some more explanation to it in next release. (I want to postpone changing the parameter names itself for a while since that would cause a breaking change and people are still recovering from the last breaking change. ).
HI,
testing the new card, and the added options seem to work as promised
trying to use the coloring options, I am a bit puzzled though if what I want is already possible.
First: am I correct the icons don’t color along the customizations set for the individual entities in the HA setup?
If the above is true, how could I
have the solar icon turn yellow when >0 (producing) or else grey;
have the grid icon turn green when returning to the grid, and red when consuming
have the home icon turn green when using only solar energy, orange when using a mix, red when using only grid energy…
lastly I would think it better to have the grid icon to the house turn red when consuming (vs the yellow for the solar energy color arrows which are yellow when producing)
right now we have 2 options, and they go for all icons I think, which could be made more insightful.
if not yet available, please consider this a feature request
Time for a new release of the power-wheel-card.
0.0.9
Features
- Set a different title per view by using optional card parameters
title_power,title_energyand/ortitle_money.
All three card parameters default to the value of card parametertitle. - Auto-toggle between views. Click the recycle icon to turn on and off the auto-toggle.
The initial auto-toggle state can be set by optional card parameterinitial_auto_toggle_view.
The period between views can be set by optional card parameterauto_toggle_view_period(in seconds).
Improvements
- Performance. Update only on specific changes of the
hassobject. - Don’t suppress zero values on solar, home and grid icon; only on arrows.
- More explanation in the readme about which sensor to use for what card parameter.
(No support for backwards counting energy sensors yet. Have to work on that a bit more.)
Power-wheel-card is still in beta. You can expect breaking changes in future releases.
You have very specific icon coloring requests. Power-wheel-card does support a few out of the box. Let’s explain them for other users first, before diving into your request:
- You can choose to not color the 3 icons at all. Use
color_icons: falsewhich is default. - You can choose to color them automatically. Producing icons will turn green. Consuming icons will turn yellow. Use
color_icons: true. - You can choose to have your own colors for producing and consuming. Use
consuming_color:andproducing_color:for that. - You can set a theme in HA and the power-wheel-card will use
--label-badge-yellowof the theme for the yellow color, etc. automatically.
Your coloring requests go beyond these out of the box features and are not supported.
However since some users (you for instance 
) are able to add a color to the sensor itself, I will take the feature request as “let custom colors of the input sensors override the colors in the power-wheel-card”. Like it does for icons already. In that way advanced users can color the icons dynamically very specifically. Can you give an example of how the entity attributes will look like if there is a custom color dynamically set by some other component? (B.t.w. I won’t work on this feature immediately, because there are a couple of other features to go first.)
not sure if this is what you mean but I use a template sensor:
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')}}
which I customize like this:
sensor.levering_of_verbruik:
state_card_mode: badges
templates:
# icon_color: >
# if (state === 'Levering') return 'rgb(251, 210, 41)';
# return 'rgb(54, 95, 140)';
theme: >
if (state > 0) return 'orange';
return 'green';
unit_of_measurement: >
${Math.round(entities['sensor.calculated_bruto_verbruik'].state)}
based on these:
(different numbers caused by real time updating, energy flow sensors not colored in customize yet )
would be really nice if we could set these customizations, but for the Home icon bottom right, that would not be possible would it, since the card calculates that?
Home icon is same as my (sh)own sensor.levering_of_verbruik, but that isn’t used in the config entities…
you might think I have a specific colorizing request, but I feel when you give it some thought it is very useful one. Having a default setting for all of the entities simply doesn’t do the card justice, and tacks back from its purpose
And what do the attributes look like when you look up the sensor in the /dev-state page? Do they get a color attribute e.g.?
a sorry, didn’t follow…
no I don’t set a color in that template but a theme. Could be a color of course, that is, icon_color (see my commented icon_color template).
this is the dev-state:
{
"friendly_name": "Verbruik",
"icon": "mdi:import",
"custom_ui_state_card": "state-card-custom-ui",
"state_card_mode": "badges",
"templates": {
"theme": "if (state > 0) return 'orange'; return 'green';\n",
"unit_of_measurement": "${Math.round(entities['sensor.calculated_bruto_verbruik'].state)}\n"
},
"theme": "orange",
"unit_of_measurement": "444\n"
}
btw heres a view hat might explain my coloring request:
Sun is yellow when producing (or active, and grey when inactive)
while returning to the grid is green and consuming from the grid is red.
as your an see here the kWh view combines with the money view, which is quite effective. Might be a good idea for your card also?
cheers!
separate post, because this could be something to point out for reference and use for others.
just templated this, which I think is the most compact way of defining both entities for production and consumption, based on a netto verbruik sensor:
{{[0,(states('sensor.netto_verbruik')|int|abs)]|max}}
which means I can now use:
grid_power_consumption:
friendly_name: Grid power consumption
unit_of_measurement: 'Watt'
value_template: >
{{[0,(states('sensor.netto_verbruik')|int|abs)]|max}}
grid_power_production:
friendly_name: Grid power production
unit_of_measurement: 'Watt'
value_template: >
{{[0,(states('sensor.netto_verbruik')|int|abs)]|max}}
instead of
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 %}
or worse, depending on your available sensors of course:
grid_power_production:
friendly_name: 'Current Energy Exporting'
value_template: >
{{ [0, (states('sensor.zp_actuele_opbrengst') | int -
states('sensor.calculated_bruto_verbruik') | int)] | max }}
unit_of_measurement: 'Watt'
grid_power_consumption:
friendly_name: 'Current Energy Importing'
value_template: >
{{ [0, (states('sensor.calculated_bruto_verbruik') | int -
states('sensor.zp_actuele_opbrengst') | int)] | max }}
unit_of_measurement: 'Watt'
1 Like
Almost but not quite. Because now you want to use exactly the same value_template for both sensors. But I like the idea. You could use a min in the latter, but don’t forget to abs in the end then.