i didn t build it, probably i did it in the wrong way, but i just beautified it ( i did it using an online tool).
Yes, will be in the next release, see:
https://github.com/kalkih/mini-graph-card/issues/35#issuecomment-460463797
That looks really nice. Thanks!
Simply put, this card is amazing, thank you for all your hard work on making this great!
I have a couple of minor suggestions which I’m happy to put in GitHub if you prefer (I’m using v0.2.1).
-
The legend text is slightly misaligned with the square boxes:
-
When hovering over a line with multiple entities, would it be possible to reveal the entity name in place of the card title (e.g. it would show ‘Loft’ instead of ‘Indoor Temperatures 24hr’) in the same way the entity state changes to match which line the mouse hovers over please? This would be useful if I decide to not show a legend to help with the minimalist look.
-
I noticed that when enabling fill, it blends the line shading as each line is drawn (easily seen with animate enabled). Is it possible to keep line colours the same between it’s own line and the line below. e.g. in the screenshot below, only orange appears below Loft, purple between Loft and Study lines, and red between Kitchen and Study lines? I realise this may be technically impossible so no problems at all if so.
Thanks!
well, they do, and, tbh, make the card unusable in my setup unfortunately. Im not doing anything special, just try to show 3 sensors on the card…
it grinds my system, and immediately has all my Hue lights go unavailable, which is an indicator of resource issues in the system. resulting in a spontaneous restart…
i will test it on a dedicated view, with only this card:
title: Test
icon: mdi:test-tube
path: test
cards:
# - !include /config/lovelace/tiles/tiles_new_switches.yaml
# - !include /config/lovelace/tiles/tiles_switches.yaml
# - !include /config/lovelace/includes/dark_sky_custom_card.yaml
- type: 'custom:mini-graph-card'
name: 'Energie: verbruik - levering'
entities:
- entity: sensor.netto_verbruik
name: Netto verbruik
- entity: sensor.calculated_bruto_verbruik
name: Bruto verbruik
- entity: sensor.zp_actuele_opbrengst
name: Solar production
hours_to_show: 48
height: 100
line_width: 4
font_size: 75
show:
labels: true
extrema: true
fill: true
points: true
state: true
and see what happens.
__ update__
no difference. the only card on this view simply never loads (waited 2 minutes) and halts the system. tested it 2. first attempt had to restart through terminal ssh (HA interface wasn’t effective any more) second try restarted spontaneously.
I am forced to disable this beautiful card…
Thank you very much, appreciate the kind words!
Fix is in the dev branch and will be available in the next release
Fantastic idea! Please open an issue on github and I’ll get to it asap.
This should theoretically be possible with the help of masks and clip-paths (I think?), but might require a lot of work, open an issue for this as well, I’ll see if it’s possible to implement.
Thanks for the suggestions!
If the graph doesn’t even show up at all and your whole HA starts acting weird, it’s most definitely an issue in the backend.
Could be an issue with your database, you could try purging older history if you haven’t done so already and maybe consider switching form SQLite to something faster.
Here’s one of my views, loads without any issues.
Here’s the API call used by this card btw: https://developers.home-assistant.io/docs/en/external_api_rest.html#get-api-history-period-lt-timestamp
Hi @Mariusthvdb, just to back up @kalkih I’ve not seen any performance issues with using 6 instances of this custom card, two of which have 5 sensors each.
Do you see the same issues if you try using the history-graph card? https://www.home-assistant.io/lovelace/history-graph/
Thanks, I’ll do that now!
No problems, only worth it if a lot of other people ask the same too.
What i am missing ?
did this steps:
- Download and copy
mini-graph-card-bundle.js
from the latest release into yourconfig/www
directory. - Add a reference to
mini-graph-card-bundle.js
inside yourui-lovelace.yaml
.
If you’ve done those two steps it should work.
Are you using lovelace in yaml mode?
Please post your resource reference yaml.
If you are using current verion of HA and never used ui-lovelace.yaml
before just go to Overview, click the menu in top right corner and select Configure UI
, then click the menu again and select Raw config
editor and paste
resources:
- url: /local/mini-graph-card-bundle.js?v=0.2.1
type: module
at the boottom of the config.
resources:
- type: js
url: /local/custom_ui/dark-sky-weather-card.js?v=5 - type: module
url: /local/mini-graph-card-bundle.js?v=0.2.1
Looks fine.
Are you running Lovelace in storage or yaml mode?
With one of my template sensors im getting a NaN message instead of the sensor value.
Was this bug already reported?
(left mini graph card and right the default sensor card)
code:
- type: custom:card-modder
style: {border-radius: "20px", border: "solid 1px rgba(100,100,100,0.3)", overflow: hidden}
card:
type: custom:mini-graph-card
icon: mdi:fire
name: Gas
height: 100
align_header: default
align_icon: right
align_state: center
show:
graph: false
fill: true
points: false
legend: false
entities: sensor.gas
- type: custom:card-modder
style: {border-radius: "20px", border: "solid 1px rgba(100,100,100,0.3)", overflow: hidden}
card:
type: sensor
entity: sensor.gas
icon: mdi:fire
name: Gas
graph: none
``
Using this card since last week and what a visual difference it makes - great contribution to HA - thanks @kalkih
Question: is there a way to anchor the Y-axis lower-bound to a configurable number, say e.g. 0 (zero), and only let the upper bound (Y-axis scale) to be adjusted dynamically. For some graphs this is important, e.g. Humidity graphs, were you may not be interested in seeing tiny variations “amplified” because of the current dynamic lower-bound & upper-bound/scaling, but the big picture / significant trends.
Having the ability to anchor the lower-bound would allow you to quickly and accurately spot trending and discriminate large deviations from small ones.
Ideally, either ‘auto’ or a specific lower bound would apply on a per-entity basis (if different y-axis scales are support, which I believe is not the case now)
A small number of use cases could benefit of a similar approach applied to upper-bound as well
I’ve not seen this before, would be great if you could open an issue here on GitHub, and I’ll get to it.
Thanks a lot!
Thank you, it’s not possible right now but it’s a great suggestion and should definitely be possible to add as an option.
If you have time, please open an issue regarding this on GitHub, and we could discuss this further, could be a great addition to the card, thanks!
Done! thanks
@kalkih So, first of all… thank you for this awesome card! I’m loving it. Ever since I saw some graph cards for Lovelace I’ve wanted to combine multiple entities and this one does it perfectly!
I’ve got a question though… I’m currently showing the values of two temperature sensors in a single graph. Now, I would like to use line_color_above
, but applied to a single entity instead of the entire graph.
In the screenshot below you see the lines of the two sensors. The value shown (23.18 °C) is the value of the bottom of the two lines. The other room is above 25 °C (the upper line).
What I would like to do:
- Change the color of a line to red when above 25 °C.
- Change the color of a line to orange when above 21 °C.
- Below 21 °C default color for a line.
But only applied to each line. So, the lower line would be orange and the upper line would be red in the above screenshot. What it does now (when using the below configuration) is making them both red.
Is that possible? Or is this not possible with the graph library used?
cards:
- type: custom:mini-graph-card
name: Temperature
entities:
- entity: sensor.living_room_temperature
name: Living room
show_state: true
- entity: sensor.bedroom_temperature
name: Bedroom
points_per_hour: 6
hours_to_show: 24
hour24: true
more_info: false
line_color_above:
- value: 21
color: orange
- value: 25
color: red
show:
legend: false
extrema: true
Thanks for the detailed explanation @thmry,
The color thresholds are actually supposed to be checked and applied to the lines individually, so what you describe is most likely just a bug.
Would be great if you could post this in an issue on GitHub, and I’ll tr to figure out what the cause could be.
Thanks!