Lovelace: Gauge card


#41

@gojonny Not at the moment, you can raise an issue for this enhancement here: https://github.com/ciotlosm/custom-lovelace/issues

@sti0 Please use:

- type: custom:gauge-card
  title: Download
  entity: sensor.speedtest_download
  max: 51
  severity:
    green: 45
    red: 0
    amber: 30

#42

Thank you. Work’s perfectly. It’s the small things in code :wink:


#43

I’m having some strange behavior when loading the lovelace with gauge, it shows the error for a second and then the normal gauge appears correct, see below:

I have this behaviour too, but additionally other card are also affected:

This is the view, if “custom-gauge” is commented out in ui-lovelace.yaml

And this is the view, if “custom-gauge” is activated in ui-lovelace.yaml

Seems, this is probably the error message, while “custom-gauge” is loading
http://192.168.2.141:8123/static/webcomponents-bundle.js:151:186 TypeError: 'dispatchEvent' called on an object that does not implement interface EventTarget.

EDIT: This behaviour does NOT happen in Chrome, only with Firefox and Edge.


#44

@lev2000 Edge is not supported for my custom cards, and Firefox requires the shadowDOM flags to be enabled. Have a look at the FAQ here: https://github.com/ciotlosm/custom-lovelace/blob/master/README.md#faq


#45

I have this with all my custoim widget, so not only the gauge


#46

Well, enabling the two components helps, hope there won’t be any unwanted side effects…


#47

@Klagio I will try to give you a more complete answer, maybe it helps other understand some of the decisions I’ve had to take along the way. The explanation below is from a personal perspective and I am sure I might have a distorted view on things but people should take it as it is :slight_smile:

Background

The way most of custom cards are built is using vanilla javascript. This allows for easier development and no need for extra tools to make the code available. Also leaves the code readable so users can test and try changes and fixes if something is not how they desire.

The downside of using vanilla javascript is that some features might not be available on all browsers. Majority of my cards for example are using shadow DOM for better context separation and to avoid css conflicts or id conflicts in the DOM. This is far easier to maintain than prefixing everything with a card name that someone could potentially do in a different card. The downside is that you need your browser to support shadow DOM (the major culprit in compatibility). There are also some other side effects like special styles (For example in SVG) that browsers render differently.


Potential approaches to fix downsides

User polymer or some other framework that provides polyfills for the missing features

Advantage:

  • Majority of features work cross browser without writing specific code because of polyfills
  • Easier to get a card into core if it’s written in polymer as it would require less modification to do so

Disadvantages:

  • Requires extra files to be loaded by the UI either from the internet (which I disagree with) or from local storage
  • Requires a bundler or a preprocessor to reduce the number of resources loaded
  • Harder for people to create a ‘dev’ environment to write code and improve features - less contributions
  • If you use a bundler to reduce code loaded you will obfuscate and mimify which makes code unreadable once it’s ‘published for production’ which makes it harder to get relevant errors from users

Avoid using shadow DOM & other incompatible features

Advantages

  • More compatibility between browsers (not guaranteed)
  • Easier to read if you keep to vanilla javascript
  • Easier contributions
  • Easier to read relevant errors (if you don’t use a bundlers / obfuscation)

Disadvantages

  • If code grows, you can’t do code splitting for better maintenance and development
  • Development is harder sometimes as you have to keep track of which feature is compatible with which browser

Using something like StencilJS which I tested out which compiles code to vanilla javascript

Advantage:

  • Majority of features work cross browser without writing specific code because of polyfills
  • You can keep code without obfuscation and get more relevant errors
  • You can code split for easier development

Disadvantages

  • Still harder to build a dev environment and get new contributions in
  • Requires you to know the framework syntax (similar to angular or polymer) but this is the same with all frameworks

The main reasons I chose my cards to avoid frameworks are

  • No extra resources except the card - My goal is for people to just link one javascript file and that includes everything: style, code, etc.
  • No internet resources - My setup must work without internet connection
  • Errors received from people are directly relevant without trying to ping-pong dev versions and clearing caches to understand the exact error
  • More people contribute - If people can read the code directly in their downloaded javascript, they can make small mods or fixes that if relevant can get back into the upstream code without any headache - Also true because you just need the 1 file and refresh to see changes

What I’m missing out

  • Browser compatibility - chrome, opera, safari are supported for most part with firefox requiring the two ‘dev’ flags, only edge is not supported
  • Code splitting - at the moment I can’t keep code split and can’t reuse code between cards - Can lead to code duplication if I end up doing similar things between card variations (translations support?!)

Notes

I am happy with the browser support vs the disadvantages of using a framework. I plan to do code splitting by building just a bundler (bash or something very lightweight) to concatenate multiple files together. Keeping just 1 file (Thermostat is a good example of how complexity can grow) makes it easier for tools like tracker-card to also install cards or update cards without too much complexity.


#48

This is a fantastic card! Have it working but there’s a slight display issue - when I put two cards in a horizontal stack (just as in the example) it seems to break out of its boundaries. Is there a way to resize the gauge?


#49

@tismondo use the ‘scale’ option in the config. Use around 30px and see how it works.


#50

Mine was an observation, not a complain of any sort.

You are definitely a God Guru of Lovelace


#51

Hey, how did you achieve this? What do you specify in CPU load entity? My log shows this error:
https://hassio.hub:8123/local/gauge-card.js?v=1:169:21 Uncaught TypeError: Cannot read property 'state' of undefined


#52

Your script makes indeed the magic happen. Thank you for the good documentation!


#53

Is there a way to add more then three severity?
I want to have a good value as green, and yellow then red if it increeses or decreeses too much


#54

I’m trying to set it up and i’m getting this error

element.setConfig is not a function
this is the code i have in lovelace.yaml

  • type: custom:gauge-card
    title: Temperature
    entity: sensor.temperature_2
    min: -5
    max: 40

#55

I can’t seem to find a way to change the colors, I tried changing things in the JS file but nothing seems to work.

  - type: horizontal-stack
    cards:
      - type: custom:gauge-card
        title: Hårddisk
        entity: sensor.disk_use_percent_home
        scale: '38px'            
        min: 0
        max: 100
        severity:
          red: 90
          green: 0
          amber: 75
      - type: custom:gauge-card
        title: Ram
        entity: sensor.memory_use_percent
        scale: '38px'            
        min: 0
        max: 100
        severity:
          red: 90
          green: 0
          amber: 75  
      - type: custom:gauge-card
        title: Processor
        entity: sensor.processor_use
        scale: '38px'            
        min: 0
        max: 100
        severity:
          red: 90
          green: 0
          amber: 75

My default UI is dark-themed and STATE elements show up as blue, therefor I would like these gauge’s to be blue on “default” aka “green” instead of actually green.


#56

Take a look here


#57

Hello,
I’m not sure if I’m in the right thread because I’m using the Gauge Card included in Home assistant.

I would like to have a variable as the max value, is that possible? (I tried to no avail)

Also : For the temperature, a special mode with a gradient color from blue to red would be awesome!


#58

Looks like the build in gauge feature in home assistant is missing many features from this card. Like size/scale?


#59

Is there a way to have the severity options work with a sensor where the higher the value, the better it is (such as a battery charge)? If have tried it like this:

- type: custom:gauge-card
  title: Phone Battery
  entity: sensor.phone_battery_level
  min: 0
  max: 100
  severity:
    red: 0
    amber: 20
    green: 50

With the battery level at 15% the gauge is showing green when I would want it to be red.

Edit: It turns out that this was an issue with a dark theme I was using (not one of my own). The theme set label-badge-red to the same as accent-color, which was set to a shade of green. After editing the theme to remove this, it is working fine and shows as red when the battery level is low as expected.


#60

Could use a little help from the community here. I’m still getting this error:

2018-10-19 09:40:29 ERROR (MainThread) [frontend.js.latest.201810140] http://hassio.local:8123/local/gauge-card.js?v=1.1:169:21 Uncaught TypeError: Cannot read property 'state' of undefined

I think I’ve tried everything I’ve seen in the thread to address this including: downloading the .js file using the raw button in Github, putting it in a www directory in config (note: I had no such directory so I had to create one), restarting Hassio, clearing browser cache.

Any idea what I might be doing wrong?