Mini Graph Card: a small Lovelace card with an unusually long options table
Minimalistic graph card for Home Assistant Lovelace UI
At a glance
- What is it?
- A Home Assistant custom card that draws a sensor's history as a line or bar graph, and documents every one of its options down to the version it arrived in.
- Who is it for?
- Mini Graph Card earns its place because it does one narrow thing and gives you a lot of control over it. The bound options alone, with soft minimums and a minimum range floor, solve the most common complaint about sensor graphs, which is that autoscaling turns a two-degree change into a dramatic mountain.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 1 day ago.
- What is it written in?
- Mainly JavaScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on October 7, 2026, and from our analysis. They are not legal advice.
Editorial analysis
What the card actually renders
The description is precise: a minimalistic graph card for the Home Assistant Lovelace UI that works with entities in the `sensor` and `binary_sensor` domains. It displays the current state as text and the history as a graph. There is no claim of being a general dashboard component.
That narrowness is the design. The card type string is `custom:mini-graph-card` and the only required option besides that is `entities`, a list of one or more sensors. Everything else is optional and every option carries a default.
The README presents the whole configuration surface as a table with a column recording which version introduced each option, which is unusual and genuinely useful when you are reading a dashboard someone else wrote. Options date back to `v0.0.1`, so the table doubles as a history of what the project has added over time.
The options that decide whether a graph reads correctly
Four options do most of the work. `hours_to_show` sets the window of history, defaulting to 24. `points_per_hour` sets how many data points appear per hour, defaulting to 0.5, and the README describes it in plain terms as the detail, accuracy and smoothing of the graph. `height` defaults to 150 pixels and `line_width` to 5.
Then there is the aggregation pair. `aggregate_func` defaults to `avg` and chooses how each point or bar is computed. `group_by` defaults to `interval`, with `date` and `hour` as alternatives, controlling how data is grouped into those points.
The bound options are the ones that fix misleading graphs. `lower_bound` and `upper_bound` pin the Y axis, and the README documents a trick: a string value starting with a tilde, such as `~50`, specifies a soft bound. `min_bound_range` then guarantees a minimum axis range so a small change does not look large because of scale. Secondary bounds exist for cards combining two different units.
Caching, update interval and the dependency list
Two options are about cost rather than appearance. `update_interval`, added in v0.4.0, sets a custom refresh interval in seconds instead of refetching on every state change. `cache`, added in v0.9.0 and defaulting to true, controls local caching of history data.
The `package.json` explains how that caching works. The runtime dependencies are small and specific: `lit-element` for the custom element, `custom-card-helpers` for Lovelace integration, `d3-interpolate` for color transitions, `localforage` as the local storage layer behind the cache, `@kalkih/lz-string` for compressing stored data, and `spark-md5` for hashing.
Build tooling is Babel plus Rollup with a semantic-release setup, and the tree includes a `.babelrc`, a `rollup.config.js`, a `release.config.js`, a `hacs.json` for the community store, and a devcontainer. So the shipped artifact is a bundle produced by a conventional JavaScript build, not a file edited by hand.
Three installation paths, and the update step people forget
HACS is the recommended route, and the README notes in small print that HACS is a third party store not included in Home Assistant by default. The manual route is to download `mini-graph-card-bundle.js` from the latest release into `config/www`. The third is a command line fetch from that same directory:
$ wget https://github.com/kalkih/mini-graph-card/releases/download/v0.13.0/mini-graph-card-bundle.jsWhichever route you take, the resource has to be registered. For YAML configuration:
resources:
- url: /local/mini-graph-card-bundle.js?v=0.13.0
type: moduleThe graphical editor path requires enabling advanced mode in the user profile, then adding the resource under the Resources tab with type JavaScript Module, then restarting Home Assistant. HACS installs use a different path, `/hacsfiles/mini-graph-card/mini-graph-card-bundle.js`.
The updating section is the part worth reading twice. The version query string in the URL has to be bumped to the new number or the browser keeps the old file, and the README warns that clearing the browser cache may be necessary. It also says that anyone on a version older than v0.0.8 should delete the existing files and install again.
Two pre-release versions and a wide contributor base
The two most recent releases are development builds rather than stable ones. v0.14.0-dev.2, published 2026-09-20, carries an explicit warning that functionality may change before the final release, including option names and feature behaviour, and asks for testing and bug reports.
That build adds per-entity color thresholds, static value labels, hiding inactive bars, spacing between bar groups and overlapping bars, options validation, a customizable fill threshold height, and an icon color option, among others. v0.14.0-dev.1 from 2026-06-26 came first with a card picker suggestion for numeric sensors, legend and extrema elements below the graph, locale-aware 12 and 24 hour formatting, more number format options, per-entity logarithmic override, and graph display order reversal.
The last stable release, v0.13.0 from 2025-05-29, was mostly fixes: tooltip-driven state colors, unit of measurement computation for attributes, replacing a deprecated icon property, hiding the graph loading indicator when appropriate.
Open issues number 137 against 3893 stars, and a single contributor, ildar170975, accounts for a large share of the recent commits. The repository was pushed to on 2026-09-23.
Editorial conclusion
Mini Graph Card earns its place because it does one narrow thing and gives you a lot of control over it. The bound options alone, with soft minimums and a minimum range floor, solve the most common complaint about sensor graphs, which is that autoscaling turns a two-degree change into a dramatic mountain. Local caching via `localforage` and a configurable update interval mean it can stay cheap on a busy instance. The catch is that the option surface is now large enough that reading the table in the README is a real prerequisite, and the two most recent releases are both pre-release builds. Start with `hours_to_show` and `points_per_hour`, add bounds once the shape looks right, and check the release page before upgrading from v0.13.0.
Frequently asked questions
How do I add a graph to my Home Assistant dashboard?
With Mini Graph Card, add the bundle as a resource, then declare a card of type `custom:mini-graph-card` with an `entities` list. In YAML the resource is a URL under `/local/mini-graph-card-bundle.js?v=<version>` with type `module`, and the card itself needs at minimum the type and entities keys.
What does Mini Graph Card need at minimum to work?
Two options. The `type` key set to `custom:mini-graph-card`, and an `entities` list holding one or more entities from the sensor or binary_sensor domain. Everything else has a default, including a 24 hour history window, 150 pixel height and half a data point per hour.
How do I stop a small change looking dramatic on the graph?
Set `min_bound_range`, which is applied last and guarantees a minimum Y-axis range. You can also pin `lower_bound` and `upper_bound` directly, and prefix a value with a tilde to make it a soft bound that is respected but not rigid.
Why is my updated card not showing the new version?
The version query string in the resource URL has to be bumped each time you replace the bundle file. The README also notes you may need to empty the browser cache if the card still fails to load. If you are upgrading from something older than v0.0.8, delete the existing files and install from scratch.
Does Mini Graph Card send sensor data anywhere?
History data is cached locally in the browser, using `localforage` and a compression library, which the README describes as local caching enabled by default. You can also set an `update_interval` in seconds so the card fetches history periodically rather than on every state change.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/kalkih-mini-graph-card)