I’ll be sticking to 0.0.5 as well.
It’s just a simple template sensor.
e3dc_net_power_pos:
unit_of_measurement: 'W'
value_template: >
{% if states('sensor.e3dc_net_power') | float < 0 %}
{{ (states('sensor.e3dc_net_power') | int) | abs }}
{% else -%}
0
{% endif %}
Sorry, edited. 
1 Like
Right but my meter doesn’t produce a negative kWh reading. It just starts counting backwards.
Sorry to have lost some people on the way. For the sensors I try to be very close to ‘native’ HA which has a special sensor platform for connecting to a Smart Meter, the DSMR platform. This platform gives you 2 separate sensors for current power:
-
sensor.power_consumption, and -
sensor.power_production.
Also the naming (“consumption/production”) is according to this HA platform.
Most users would be able to split the sensor (see post 122 of @VDRainer for an example) if they have a combined nett power sensor. But for @firstof9 I don’t see a solution yet, because that’s an energy sensor counting backwards. That sensor doesn’t give enough information to color or not color the left energy arrow.*) So it makes sense to me that this energy sensor is incompatible with the card now. What component or platform are you using to get the sensor? And doesn’t it supply also an energy_producing and energy_consumption sensor?
*) Some more explanation about this. If @firstof9 's sensor says 500 kWh at 8 o’clock and again 500 kWh at 12 o’clock you wouldn’t know if you did consume zero home energy or did consume home energy but also did produce the same amount of solar energy.
That is my Aeotec DSB28 Home Energy Meter using zwave. It is 2 CTs clamped to the mains power in my breaker panel. I have a 2nd system producing data via EmonCMS for reading my solar output/input (inverter consumes power at night).
My sensors:
solar production (watts)
solar energy (kWh)
grid consumption/production (via the mains CTs this flips to negitive on production) (watts)
grid energy (which counts backwards on production) (kWh)
Examples:
This is a very specific platform for one country. Besides, for me personally, I’d prefer to see a +/- value. It’s quicker to read and I can instantly tell what’s happening by looking at the number as opposed to looking at a word and a number. (It’s the little things for me. 
I haven’t had a chance to play with that work around to convert a - value to work with this. I’ll see how it goes.
HI again,
please don’t read this a me knowing better or anything, but I fear you are following an incorrect standard…
The DSMR meter uses T1, T2 for both tariffs using from grid, and -T1 and -T2 for returning to grid.
If the DSMR HA component translates -T1 and -T2 to ‘producing’, they are simply incorrect too. Producing is what the Solar panels do, and the -T1/-T2 are returning the non consumed produced power to the Grid.
Hence my suggestion to change those names. It would really make things much more intuitive.
In my DMSR settings I’ve named -T1/-T2 Teller1_terug and Teller2_terug, (which is in fact what it does, as the other member shows so clearly, his meter is truly turning backwards).
If you want to stay in english, ‘current power returned’ and current power used’ would be most illustrative. If you would want to prevent any mishaps on the word current, which of course has another meaning also, you might even want to use
‘power currently returned’ and ‘power currently used’
2 more cents…
talking about cents and the money view, I take it that is based on the kWh settings? But how are the figures on the arrows calculated:
the icon numbers seem to add correctly as dos the individual numbers press, but i cant see why lets say 0.90 kWH is listed as delivered to the grid, and why not all is going there. Same goes for the money view of course, but this would explain both probably.
please have a look?
how do i invert the solar value ?
the solar cells are outputting 3628W and i am outputting 3085W to the grid when this screenshot was taken.
so i imagine that the solar value must be inverted (positive instead of negative) to appear correctly in the power wheel.
my sensor:
- platform: influxdb
host: xxxxxxxxx
username: xxxxx
password: xxxxxxxx
queries:- name: iotawatt_solar
unit_of_measurement: W
group_function: last
value_template: ‘{{ value | round(1) }}’
where: ‘time > now() - 1m’
measurement: ‘“Solar”’
field: value
database: xxxxxx
- name: iotawatt_solar
If you used your sensor.ioatawatt_solar as solar_power_entity you could add a minus sign in value_template: ‘{{ -value | round(1) }}’ but that would effect your dashboard everywhere where this sensor was used. You also could derive an extra sensor of it and feed that to the card:
solar_power_positive:
unit_of_measurement: 'W'
value_template: >-
{{ -(states('sensor.ioatawatt_solar') | float) }}
@firstof9, you also need this, because your image shows a negative solar power value and the card needs a positive one. Then the card values make more sense and the right arrow starts becoming active.
@Mariusthvdb, also not trying to knowing better here but my energy provider calls me a ‘producer’ when I’m delivering back to the grid. And most of the time I’m a consumer according to them, the grid.
Fact is: half of the world is familiar with A, the other half with B. Half of the world likes to see + and - numbers on the card (perfectly understandable @cjsimmons) and the other half likes positive values with color to show the difference. I can’t serve both worlds or maybe I could, but then the complexity rises (extra parameters, code complexity, etc). And there are already some that say that complexity has risen too far. 
This is about energy, not power. (On the power view this couldn’t happen.) There are times during the day that energy produced by your solar panels wasn’t consumed immediately by your house, but ‘produced’ to the grid. This was the case for 0.90 kWh. But sometimes your house was consuming the produced solar energy immediately, which is shown by the 2.76 kWh at the right arrow. Probably your house was consuming even more than your solar panels did produce, because you were consuming from the grid another 17.43 kWh.
(Same goes for the money view where all the energy values are simply multiplied by the (evt. averaged) energy_price).
Currently I’m working on the upgrade to a higher version of lit-element and I will think about the phenomenon of backward counting energy sensors (@firstof9) . And I want to stay away from breaking changes for a while. 
exactly, you are of course a producer when you are, as you state correctly, delivering back to the grid. But, that is from the power company’s point of view, and they don’t care if you have true sensors in your HA that are the real producers… and have to make a logical distinction between that sensor, and the returned to grid energy that has taken into account that production and substracted that from the total usage…
and yes, creating a negative value would also be better. right now you choose the third best option I fear. Colors are always customizable, so that could be left to the individual choices.
but hey, its your card…
Thought as much, thanks! but, tbh, can’t imagine that happened yesterday… but will have an extra eye on that to check if this shows the real situation correctly. In an all grey and rainy day, my house almost always consumes more than that tiny fraction of solar power :-((
otoh, if your card shows me that right now, that would be all the more valuable information.
you really should have a look at this thread, talking about insight in power consumption… so cool.
EDIT
also have a look at this graph, which shows tin another way. Export (returning to the grid, production in your card) being the total of the real production minus self consumption.
At night the negative power on the solar is the inverter pulling power from the grid, while the solar is active it’s a positive number.
Ah, then you’re okay with the polarity of the input sensor. Sorry, the arrows don’t start pointing the other way around. They can’t cope with the negative values. In my household the energy consumption of the inverter is part of the (bottom-right) home energy.
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 _ )?