Skip to content

v0.3.0

Choose a tag to compare

View all tags
@VysseCodes VysseCodes released this 09 Sep 19:10
· 9 commits to main since this release
v0.3.0
5e16f6e

[0.3.0] - 2026-08-29

Changed

  • Text is now a tint of the accent rather than white or black. Previously
    the palette mixed 4% of the accent into a near-neutral, which read as plain
    white on dark themes and plain black on light ones - the accent was visible
    only on icons and controls.

    Text now takes the accent's own hue at a fixed OKLab lightness with chroma
    pulled back: L 0.93 on dark themes, L 0.28 on light. A rose accent gives
    warm off-white text, a blue accent gives cool. Contrast enforcement is
    unchanged, and all ten former presets still clear 4.5:1 in both modes -
    measured 11.3:1 to 13.2:1 dark, 13.8:1 to 15.2:1 light.

    Achromatic accents (pure white, pure black, grey) degrade to neutral text,
    which is correct - there is no hue to tint with.

  • The accent is now a colour picker. The ten-preset dropdown is gone. With
    the whole palette derived from one colour, presets were a shorter list than
    the spectrum rather than a feature - so the config flow uses Home
    Assistant's native RGB picker instead.

  • select.<profile>_accent has been removed. The accent is now available
    three ways:

    • A bundled Lovelace card, custom:chromha-card. Home Assistant has no
      colour-picker entity platform, and dressing the accent up as a light gave
      it a meaningless on/off state, so ChromHA ships its own card instead. It
      registers itself as a frontend module - there is no Lovelace resource to
      add. Add it from the card picker, or:

      type: custom:chromha-card
entity: text.chromha_ryan_accent

      With no entity it finds the accent entity itself. It also previews the
      derived palette underneath, reading the palette sensor on the same device.

    • text.<profile>_accent - the hex value, for automations.

    • Settings > Devices & Services > ChromHA > Configure - the same picker
      in a dialog.

  • Added an options flow: Settings > Devices & Services > ChromHA >
    Configure re-opens the picker along with style and mode.

  • sensor.<profile>_palette is now a diagnostic entity, so it sits apart
    from the controls. It is not needed for theming - CSS variables cover that -
    but it remains the only way to reach the resolved colours from a Jinja
    template or a charting card that passes colours into JavaScript.

  • examples/view-assist/convert.py no longer prunes lines inside block
    scalars. The pass that removes emptied mapping keys is line based, and
    a line such as "camera camera" :` inside a JavaScript template also
    ends in a colon - so it was deleted, silently corrupting the View
    Assist camera view. Only plain identifier keys are considered now.

Added

  • Config entry migration from version 1. Preset names resolve to their hex
    values and the separate accent_hex key is folded in, so existing profiles
    keep their colour with nothing to redo.
  • Push to View Assist, an optional per-profile setting in the options
    flow. Pick one or more View Assist devices and every rebuild calls
    view_assist.set_state on them, landing chromha_accent,
    chromha_background, chromha_surface, chromha_text,
    chromha_theme_name and chromha_transparent_url directly on that
    device's own View Assist sensor - readable from a dashboard with no
    separate ChromHA sensor to name. Off by default; a missing view_assist
    integration is handled the same way a not-yet-ready frontend is.

Fixed

  • light.py implemented an accent-as-a-light entity that was never in
    PLATFORMS and so never loaded. Removed - the bundled chromha-card.js
    and text.<profile>_accent already cover that UI.
  • Invalid accent input now surfaces invalid_colour in both the setup and
    options flow, instead of silently substituting the default accent.
  • examples/view-assist/views/* are now the bare custom:button-card shape
    View Assist's own views/<name>/<name>.yaml expects, rather than wrapped
    in views: / type: panel / cards: - a mismatch between what the files
    actually contained and what their own header comments and the example
    README told you to do with them.

Upgrading from 0.2.x

Profiles migrate automatically on load. select.<profile>_accent and
text.<profile>_custom_accent will linger as unavailable entities - Home
Assistant keeps removed entities rather than deleting them. Remove them from
any dashboard and delete them under Settings > Devices & Services > Entities.

Assets 2
Loading