# lovelace-flower-card: a Lovelace card for the Plant Monitor integration

> The Flower Card is a Home Assistant Lovelace card that renders plant readings as measurement bars, care guidance and badges for entities from the Plant Monitor custom integration, and it deliberately refuses to work with Home Assistant's built-in plant integration.

**Olen/lovelace-flower-card** — Lovelace Flower Card to match the custom plant integration

- Repository: https://github.com/Olen/lovelace-flower-card
- Website: https://github.com/Olen/homeassistant-plant/
- Stars: 521 · Forks: 51
- Language: TypeScript
- License: GPL-3.0
- Published: 2026-10-22 · Updated: 2026-10-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/olen-lovelace-flower-card

## The card is bound to Plant Monitor and refuses the built-in integration

The single most important line in the README is the important callout near the top: this card requires the Plant Monitor custom integration and is not compatible with the built-in plant integration. That constraint shapes everything else, because the bar names the card understands, the thresholds and the health status it shows, and the care text it can render all come from that integration's entity shape. A user with the standard plant integration gets nothing useful here, and the failure is likely to be silent rather than an error message, which is worth knowing before you spend an evening on the YAML. The card is a Lovelace custom card, so it lives in the dashboard layer rather than in the integration layer, and it is distributed through HACS as a custom dashboard repository. The repository also publishes a separate browser extension package, flower-card.js, plus a gzipped copy and a licence sidecar file, which is the shape a Home Assistant frontend resource normally takes.

## Two installation paths, one of them a single YAML resource

HACS is the recommended route and takes three steps: add the repository as a custom repository of type Dashboard, click Install on the Flower Card entry, then refresh the frontend with a shift-reload. The manual route is four steps and ends with the same refresh. You download flower-card.js and place it in the www folder of your configuration directory, then add it under Settings, Dashboards, Resources. The resource entry itself is two fields, a URL pointing at your local copy and the resource type JavaScript Module. The resource type matters, because a plain JavaScript resource will not load the way this card expects. Either path ends the same way, with a frontend refresh, since Home Assistant caches the resource file. Note that this is a frontend-only install: the card itself needs no configuration change in configuration.yaml, because it is added as a card on a dashboard rather than declared as a platform.

## Two lines of YAML are enough to put a plant on the dashboard

The card can be configured from the graphical editor, and the README shows a screenshot of that editor, so you can build a card without touching YAML at all. The equivalent YAML is as small as it gets, two keys and nothing else:

```yaml
type: custom:flower-card
entity: plant.my_plant
```

The custom: prefix is what routes the card to this resource rather than to a built-in card type, and the entity key points at the plant entity from Plant Monitor. Everything past that is optional and overrides a default. The full option table lists ten settings, of which only entity is required. name overrides the entity name for display, hide_species and hide_image each default to false, and the remaining options control which measurements appear, how they are laid out, and what else sits in the header. That shape matters for maintenance: a dashboard built from the defaults will keep working when the card is updated, and only the cards where you deviated need checking.

## display_type picks a preset you can still override piece by piece

Rather than exposing a dozen independent layout switches, the card starts from a preset chosen by display_type, of which there are two: full, which is the default, and compact, described as a smaller card layout with hidden units and single-column bars. Two settings change with the preset, hide_units and bars_per_row, which are false and 2 for full and true and 1 for compact. Because they are presets rather than hard rules, each one can be overridden on its own. The example shows a compact header with two bars per row and units visible, which is the opposite of what the compact preset would give you:

```yaml
# Compact header but 2 bars per row with units
type: custom:flower-card
entity: plant.my_plant
display_type: compact
bars_per_row: 2
hide_units: false
```

This is the design that makes the card practical on a wall tablet, where the full layout of several bars is legible, and on a phone in a sidebar, where it is not. The trade-off is that the default is not always the default you want, and the README does not describe how the card chooses between the two when the option is left out beyond the compact preset implying an explicit choice.

## show_bars is a whitelist of eight named measurements

Measurement bars are opt-in by name. The list of available bars is fixed: moisture, temperature, conductivity, illuminance, humidity, dli, co2 and soil_temperature. If you set show_bars, the card shows exactly those and nothing else, in the order you list them:

```yaml
show_bars:
  - moisture
  - temperature
  - illuminance
```

Left unset, the option shows all of them. The naming is the interesting part, since illuminance, dli (daily light integral), conductivity and soil_temperature are not what the built-in plant integration exposes under the same labels, and a typo in a bar name produces a card with a missing bar rather than a config error. The card is described as showing sensor readings, thresholds and health status in a compact visual layout, which means the bar itself carries a threshold judgement, not just a number. The documentation does not say where those thresholds come from, so it is not possible to tell from the README alone whether they are fixed values in the card or values carried on the entity.

## Care text needs a species refresh before it appears

The show_care option adds guidance text boxes on the card, and the fields are care_watering, care_sunlight, care_soil, care_pruning and care_fertilization. Each selected field renders as a labelled text box, and only when the plant actually has that care attribute, so missing or empty fields are skipped automatically. That last detail is why the note under the section matters: care text comes from OpenPlantbook through the plant integration, and existing plants need a species refresh before the care attributes appear, while newly added plants get them automatically. You can confirm the data on the plant entity under Developer Tools, States. So the first symptom of an empty care box is usually a stale plant record rather than a card bug. The values are selected as a list, and the order of that list decides the order of the boxes on the dashboard.

## The header carries a battery indicator and arbitrary extra badges

A battery_sensor option adds a battery indicator to the card header, and the icon colour follows the level: green at 40 percent and above, orange between 20 and 39 percent, red below 20 percent. The sensor is any entity you point at, so the card does not assume a particular sensor naming scheme. The extra_badges option goes further and adds icons next to the battery icon, and the badge reference file EXTRA_BADGES.md covers the full set. The documented types are sensor values, binary states, action buttons and static labels. In the example, a binary sensor carries an icon and two colours, one for on and one for off, and an input_button is used with no further configuration, which is the shape for an action the dashboard triggers rather than reads:

```yaml
extra_badges:
  - entity: sensor.room_humidity
    icon: mdi:water-percent
  - entity: binary_sensor.grow_light_on
    icon: mdi:lightbulb
    color_on: yellow
    color_off: grey
  - entity: input_button.water_plant
```

This is where the card stops being a passive display. An input_button in the header means a plant can be watered from the dashboard rather than from a phone app, which is a real reason to prefer a custom card over the built-in plant card even when the built-in one would carry the same data.

## Tapping the image opens a lightbox and the name opens more-info

The interaction model was changed recently, and the note under the section is explicit about the old behaviour. Tapping the plant thumbnail opens the full-size image in a popup with the plant name shown below it, which the README describes as handy for telling apart multiple plants of the same species that have different photos. Tapping the plant name, or anywhere else in the header, opens the standard more-info dialog instead. Previously the image opened more-info, so cards with no image, or with hide_image set to true, are unaffected by the change and tapping still opens more-info. That is the sort of behavioural change that breaks muscle memory in a dashboard used daily, and it is not visible from the version history in the README, which is why the note is worth reading before an upgrade. The section on the image lightbox is cut off in the source, so it is not possible to say whether the popup size or behaviour is configurable.

## Date based releases, a GPL card and a webpack build

Versions are calendar dated: v2026.8.0 on 2026-08-20, v2026.7.0 on 2026-07-28 and a beta of the same month, v2026.7.0-beta1, a day earlier on 2026-07-27. The repository is not archived and the last push was on 2026-10-14. A date in the version means a release cadence is tied to the calendar rather than to a sequence of feature milestones, which tells you how to read a version number but not how often a release is likely to appear. The licence is GPL-3.0, recorded as GPL-3.0-only in package.json, which matters more here than the MIT of a typical frontend component: the distributed flower-card.js is a derivative work, and the repository ships flower-card.js.LICENSE.txt alongside it to carry that obligation. The build is webpack with TypeScript compiled by ts-loader, the UI is Lit, and package.json wires lint, test and build scripts, with tests run through vitest and a jsdom environment.

## Conclusion

Adopt lovelace-flower-card if your plants are already tracked by the Plant Monitor custom integration and you want their readings on a dashboard without writing Lovelace YAML by hand for every entity, since the card's default view already picks the bar set for you. Do not adopt it for Home Assistant's built-in plant integration, which it explicitly does not support, or if you need a stable release: the tags are date based and the newest listed is v2026.8.0 from 2026-08-20. Before installing, confirm your plant entities come from Plant Monitor, refresh the species on any plant added before the care attributes existed, and check that the entity you name as battery_sensor actually reports a level.

## FAQ

### Does lovelace-flower-card work with the built-in Home Assistant plant integration?

No. The README states that the card requires the Plant Monitor custom integration and is not compatible with the built-in plant integration.

### How do I install lovelace-flower-card in Home Assistant?

Through HACS, by adding the repository as a custom repository of type Dashboard, clicking Install on the Flower Card entry and refreshing the frontend. Manually, you place flower-card.js in the www folder of your configuration directory and add it as a JavaScript Module resource under Settings, Dashboards, Resources.

### Which measurements can the Flower Card show as bars?

The available bars are moisture, temperature, conductivity, illuminance, humidity, dli, co2 and soil_temperature. The show_bars list selects which of them appear, and all of them are shown when the option is left out.

### Why do my care info boxes stay empty in lovelace-flower-card?

Care text comes from OpenPlantbook through the plant integration, and existing plants need a species refresh before the care attributes appear, while newly added plants get them automatically. You can check the data on the plant entity under Developer Tools, States.

### What is the difference between the full and compact display_type in lovelace-flower-card?

Full is the default and shows units with two bars per row, compact is a smaller layout with hidden units and a single column of bars. Both settings can be overridden individually, so a compact card can still use two bars per row with units.

### Under which licence is lovelace-flower-card released?

GPL-3.0, recorded as GPL-3.0-only in package.json, with the distributed flower-card.js accompanied by flower-card.js.LICENSE.txt in the repository root.

## Sources

- [License: GPL-3.0](https://github.com/Olen/lovelace-flower-card/blob/main/LICENSE)
- [Olen/lovelace-flower-card on GitHub](https://github.com/Olen/lovelace-flower-card)
- [Project website](https://github.com/Olen/homeassistant-plant/)
- [README](https://github.com/Olen/lovelace-flower-card/blob/main/README.md)
- [Releases](https://github.com/Olen/lovelace-flower-card/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/olen-lovelace-flower-card