Lovelace: Power wheel card

just as a followup, and to be sure things are working as you have designed them for now:

consuming:
32

returning to grid (displaying negative number is what you designed it to?):
43

using these sensors:

  grid_power_consumption:
    friendly_name: Grid power consumption
    unit_of_measurement: 'Watt'
    value_template: >
      {{[0,states('sensor.netto_verbruik')|int]|max}} 

  grid_power_production:
    friendly_name: Grid power production
    unit_of_measurement: 'Watt'
    value_template: >
      {{[0,states('sensor.netto_verbruik')|int]|min|abs}}

Yes, that minus is there by (current) design. Probably better that I skip the minus, because the icon coloring should give you that info. But since icon coloring is on or off by the color_icons parameter, the minus should only be skipped when this parameter is true. And that could bring an issue to the table for the feature request of custom coloring the icons. Thanks for bringing this bug under my attention. :smiley:
Home_Assistant

I vote for the minus and invert_grid_color. :upside_down_face:

lol. its always a perspective thing. In this case I would think minus would mean take out, or consume in Powerwheel language. Since this is a returning to the grid value, Producing in Powerwheel language, it should really be positive. Returning a negative value would be consuming :wink:

now that we see this picture there’s twice the 24 again. As it will always be when returning to the grid. Thas obviously double information, but wouldn’t know which to suppress tbh…

cheers!

With the new integration sensor

I can make a grid energy production/consumption sensor for this card now that doesn’t count backwards :smile:

1 Like

Newest beta 0.88.0b3 will break this card.

EDIT: This fix also works for power-wheel. :slightly_smiling_face:

1 Like

you beat me wanting to post this: Custom Dark Sky Animated Weather Card

now where does that leave us not yet upgraded people…The constant upgrading and breaking in Lovelace has held me back since 84.3/6… Especially since it has been made the default interface.

That’s a losing proposition… more and more stuff is going to break going forward and you’re going to drive yourself crazy holding everything back and constantly checking if something will work now…

Not to mention that the longer you hold back, when you do give in it will be a nightmare following all the breaking changes… I know you use custom-ui - I’ve never used that but it doesn’t look like it’s going to work with lovelace going forward…

I fear you’re right.
Thing is I am having issues at home defending to have to keep spending so much time repairing and fixing everything that gets broken all the time…Lovelace hasn’t been much of an improvement in that departement tbh.
Had hopes HA would mature into a system of reliability, needing a fine tweak here and there every once in a while. At this moment in time, it has developed into the opposite really, needing constant attention for the next breaking change.
Many of these arise in custom-cards, I realize that, but then again, checking out many of the frequent posters here, Lovelace can’t live without these. Bit of a catch22 really.

Maybe these breaking updates should stay longer in the Beta phase and when having ironed out most issues be called an update…

You should try the first beta!! Hahahaha…

lol. reading your posts about that kept me from it…

laughing like a farmer with a tooth-ache (Dutch proverb)

1 Like

There’s been a couple of major breaks but usually only for a few hours… I’m right on top of all the breaking changes let me tell you…

well, tried to update to87.1 and now have this:

00

its trying to load lovelace (I know its now default), but when I enter /states, it won’t come up either.

Briefly saw this:

about the __, can I simply take these out of my automations and sensors? Cant get to the dev-state anymore so I can’t check…
how to reenable the frontend? please… and then I’ll hop over to another thread not to hijack this one.

edit

never mind the front-end its back after a cache refresh… pff issue 1 tackled.

Now the __ scores

Double underscores are invalid… change to 1 and remove any trailing _’s

Thx! Fix is on the dev branch as part of release 0.0.10.

Because HA version 0.88.0 will probably released tomorrow, I released version 0.0.10 of the power-wheel-card today. You’ll need it if you plan to upgrade to HA 0.88.0, because version 0.0.9 of the card will break in this version of HA.

What’s new? Not much from a user perspective. It’s all about making the code more robuust and fit for future changes. I spent a lot of time in setting up automated testing with web-component-tester and making the first 142 tests.

Issue? If you encounter an issue, please file it in the GitHub issue tracker. You can copy the version info, etc. from the developer console after setting the card in debug mode. (You can set “debug: true” in the card config to enter debug mode.)

0.0.10

New features

  • New debug parameter for logging debug information in the console of the browser.
    Useful when you want to investigate or register an issue.
  • Errors and warnings are displayed in the card if they occur after the config step of HA Lovelace.

Improvements

  • Setup for automated testing of the card. 142 tests to start with.
  • Replaced default grid icon mdi:flash-circle with mdi:transmission-tower which is available since HA 0.87.0.
  • Render styles according to version 2.0.0-rc.5 of lit-element in HA 0.87.0.
  • Validation on HA sensors in the config. Display an error when a sensor couldn’t be found.
    E.g. when a user makes a typo in the config.
  • Improved error display on validation of units of sensors.
  • Performance improvement on unit definition. Define once instead of on each render.
  • Code improvements. Small performance improvements.

Fixes

  • Fix for disappearing hui-error-entity-row in HA 0.88.0 which would break the card.

Note: The minimal version of HA to be used with version 0.0.10 of the power-wheel-card is HA 0.87.0 (See list of improvements for details.)

Hi @firstof9, were you able to use the Integration Sensor?

I’m looking into the backward counting energy sensor issue. I’m wondering if it would still be useful for the power-wheel-card, because without a split grid energy sensor I wouldn’t able to calculate the energy spent by the Home. I can’t simply do “Home = Solar + Grid”, because some of the energy would be sent back to the grid. When you were using version 0.0.5 of the card, did you calculate Home power yourself (or did you have a hardware sensor specially for “Home”) and used that as input?

The integration sensor has provided the data needed for the card.

I calculated no “Home” power myself I let the card do it.

I have CTs on my mains coming into my 200A breaker, and a CT on my inverter breaker. It’s 2 different meters.

2 Likes

Version 0.0.11 has been released

It ‘unbreaks’ some breaking changes of version 0.0.6. Personally I love the reversing of an arrow in some cases. And because the card can be used now in setups I don’t have myself, I’ve setup automated testing for all setups.

Issue with the card? Please use the bug report of GitHub after reading the wiki to check what you can do before reporting a bug.

New features

  • Support for one (nett) grid power sensor. Some setups don’t have separate sensors for grid power consumption (from the grid) and grid power production (to the grid). Previously you had to make an extra template sensor for this.
    • Use current card parameter grid_power_entity to supply your input for the card. Default the polarity of this parameter has to be positive for producing (to the grid) and negative for consuming (from the grid).
  • Support for one (nett) grid energy sensor. Some setups don’t have separate sensors for grid energy consumption (from the grid) and grid energy production (to the grid). Previously you were not able to use the energy view.
    • Use current card parameter grid_energy_entity to supply your input for the card.
    • Use current card parameter home_energy_entity to supply your input for the card. This extra parameter is needed because the consumed energy of your home can’t be calculated if you only have one grid energy sensor.
    • Default the polarity of these parameters has to be positive for producing (to the grid) and negative for consuming (from the grid).
    • Nb. There still won’t be active arrows in the energy view nor values near the arrows.
      This is because you supply too less information to calculate these values.
      Power-wheel-card can’t do magic.
  • Support for switching the polarity of grid_power_entity, grid_energy_entity and home_energy_entity. Default the polarity of these parameters has to be positive for producing (to the grid) and negative for consuming (from the grid).
    • You can switch the polarity of all these 3 entities with the new card parameter production_is_positive.
    • Nb. The parameter is switching the polarity of exactly only the 3 mentioned input parameters. All other input parameters are not affected.
    • Nb. The parameter is switching the polarity of input values to be able to use them in calculations. Negative output values (i.e. displayed values) always represent consuming (from the grid).

Improvements

  • Arrows will reverse when their value becomes negative. (E.g. solar panel inverters start consuming when there is no sun and some users have a sensor that detects this.) The values next to arrows always are positive now.
  • About coloring the solar, grid and home icons, polarity of their values (‘+’ when producing, ‘-’ when consuming) and sign of their values (‘+’ or ‘-’):
    • When color_icons is set to true the Solar, Grid and Home values always are displayed as positive values, because the color of the icon represents the plus or minus sign already.
    • The polarity of the values for Grid and Home is switched for better consistency throughout the card. The polarity of the colors stayed the same. The changed polarity is visible only when color_icons is set to false, because negative values are displayed then only.
    • Card parameter color_icons is now default true. If you don’t want colored icons and see negative values, you have to set the parameter to false explicitly.
  • Added user agent to the debug output.
  • Automated testing before each commit.
  • Added tests to get a good functional and code coverage. There are 627 tests now.

Default should be the other way around … that is what utility meters do (and that’s what most people have access to): positive when your house gets energy from the utility, negative when you inject energy into the network

2 Likes