# Helios hides any chip whose sensor cannot be trusted > Helios is a Home Assistant Lovelace card that redraws the Energy dashboard as a 2.5D scene, with a tilted vector basemap, no WebGL and two runtime dependencies. Its most interesting decision is negative: when a source has no live sensor, the card shows nothing rather than a plausible number. **ReikanYsora/Helios** — Helios - Make your energy visible, in 2.5D in a Lovelace card for Home Assistant - Repository: https://github.com/ReikanYsora/Helios - Website: https://helios-ha.org - Stars: 1,009 · Forks: 29 - Language: TypeScript - License: GPL-3.0 - Published: 2026-09-18 · Updated: 2026-09-18 · Language: en - Canonical page: https://hysenlabs.com/projects/reikanysora-helios ## Every number is either a live sensor or recorder statistics The card follows your Energy dashboard and never estimates a value, and the definitions it uses are strict about which is which. A chip is always a real-time measurement read from the live power sensor of that source, so a source with no live sensor simply has no chip, and the editor tells you which one is missing. Nothing is derived from a cumulative meter to stand in for a now. A curve or a total is always your own meter data read through the recorder statistics, which is stated to be the same set of numbers the official Energy dashboard's bars are built from. Home consumption is the dashboard's own balance, solar plus import minus export minus battery, and it appears only once every configured family has a live sensor to compute it honestly. A sensor detected as mis-wired hides the affected chips, with the editor explaining what to fix instead of showing a figure you cannot trust. ## Two runtime dependencies, one of them for clipping shadows The package manifest lists exactly two runtime dependencies, lit at 3.3.3 and polygon-clipping at 0.15.7. The second one is the tell: cast shadows are projected from real building footprints, and that geometry has to be clipped, so the library doing the clipping is a direct consequence of the visual claim. Everything else is written in the project itself, from the solar position maths to the weather handling and the scene composition. The rendering path is the other unusual choice. Rather than a 3D context, the scene is painted by a self-contained 2.5D engine with no WebGL: a tilted vector basemap drawn on a canvas, with every overlay projected on top in SVG. The stated reason is weight, staying fluid on a phone, a tablet or an old wall panel, and running where a classic 3D render will not. ## Install is HACS and a reload, or one YAML resource line The HACS path is four steps: open HACS, search for Helios, install it, reload your browser, then use Edit and Add card on your dashboard and search for Helios. No API key, no account and no per-card entity list is needed, because the card wires itself from the Energy dashboard you already configured, taking solar, grid, battery and the devices you track from there. The manual path skips HACS by shipping one built file: download helios.js from the latest release, copy it to /www/community/helios/, then register it as a dashboard resource. ```yaml url: /local/community/helios/helios.js type: module ``` A hard refresh finishes it. That single module file is consistent with the manifest, which is marked private and therefore never published to a package registry, and with the top level of the repository carrying a dist/ directory next to src/ and test/. ## Versions are dates, and two of the last three releases share a day The version scheme is a calendar one: the manifest reads 2026.9.6, and the release tags are 2026.9.4, 2026.9.5 and 2026.9.6. Their timestamps show a pattern worth knowing before you file anything. 2026.9.4 went out on 5 September 2026, then 2026.9.5 and 2026.9.6 both went out on 12 September, the earlier at 07:40 and the later at 15:43, with the last push to the repository recorded at 15:43:58 the same day, half a minute after the release itself. So the trailing digit is a sequence within a release day rather than a patch count, two builds can ship on one date, and a given tag can sit on a commit that is not the tip. Anyone pinning a version should pin the tag and expect the branch to move past it. ## Energy figures stay local, but tiles and weather go to two open services The privacy claim is specific about its scope: your solar, battery and grid figures never leave your browser, and there is no Helios server, no account and no telemetry. Two outside services are named for everything else, Open-Meteo for weather and OpenFreeMap for the map tiles the ground is drawn from, and neither needs a key. That distinction matters if you read the local promise broadly, since the scene still issues lookups to two third party hosts for sky and terrain, and neither is configurable to a local mirror in what the repository describes. The escape hatch applies to readings rather than to tiles: each weather value, covering temperature, humidity, cloud cover, precipitation, snow and the condition itself, can be pointed at your own weather station sensor, which then takes over from the forecast for the live and past hours. ## The moon carries no reading and the sun's arc is your own address Several elements exist purely to be looked at, and the project is explicit about which. The moon crosses its own arc with the actual crescent for tonight's phase lit toward the sun, appears at night by default with an always or never option, and carries no reading at all. The sun is different: its arc is placed over your own address, with a live sun disc, an incidence ray and either the irradiance reading or the sun's azimuth and elevation, and sunrise and sunset sit where that arc meets your horizon. The horizon itself is derived from the terrain around your home, so the scene dims when the sun drops behind a hill rather than at a flat line, with the skyline drawn as a discreet ridge. The production, grid and battery flows each carry a bead that travels to the home at the speed of the power it carries, and an optional wall mode fades the controls away after a few seconds with a viewing angle locked once and reproduced on every device. ## The forecast sibling feeds this card a dashed prediction curve Helios Forecast is a separate repository in the same family, and the two are designed to interlock. The forecast side is a solar production forecast that learns from your own panels and runs entirely on your Home Assistant, feeds the official Energy dashboard, corrects itself against what the installation really produces, and exposes a set of sensors. Helios consumes that output rather than computing it: the prediction is drawn as the dashed curve your production is tracked against, and each array you configured there is marked in the scene as a small tile at its position, turned and tilted the way the panels look, with its own ray to the sun. The practical consequence is that the visual prediction layer is optional and additive, and that the card itself holds no forecasting code. ## Two descriptions, two places for architecture notes The two self descriptions do not match. The repository blurb is Make your energy visible, in 2.5D in a Lovelace card for Home Assistant, while the manifest describes a real-time solar exposure, cloud cover and PV production card. One is about presentation, the other about instrumentation, and neither mentions the moon, the flows or the wall mode. The documentation layout is similarly split, with a configuration reference at docs/CONFIGURATION.md covering every option in both the editor and YAML, development notes at docs/DEVELOPMENT.md, and ARCHITECTURE.md sitting at the repository root rather than inside docs/. Around that sits the tooling the manifest declares: vite for the build, typescript for typecheck, eslint with Lit, accessibility and custom element plugins, vitest for the tests and a knip configuration for unused code, with eslint.config.mjs, knip.json, vite.config.ts and vitest.config.ts all at the top level. ## Conclusion Helios earns its place for anyone who has already configured the Home Assistant Energy dashboard and wants the same numbers in a scene rather than in bars, on a wall panel that cannot run a WebGL render. Check first that each source you want shown has a live power sensor, since Helios deliberately shows nothing without one, and decide whether sending tile and weather lookups to Open-Meteo and OpenFreeMap fits your privacy expectations. Anyone wanting per-card entity pickers, server side rendering or a card that keeps showing numbers through a broken sensor should look elsewhere. ## FAQ ### Does Helios need an API key or an account to run? No. It reads the Energy dashboard you already configured in Home Assistant, needs no API key, no account and no per-card entity list, and the two outside services it uses, Open-Meteo for weather and OpenFreeMap for map tiles, do not require a key either. ### What does the Helios card do when a source has no live power sensor? Its chip is not shown and the editor names the sensor that is missing. Nothing is derived from a cumulative meter to fake a current value, and a sensor detected as mis-wired hides the affected chips instead of showing an untrustworthy number. ### Can Helios be used in a home without solar panels? Yes. Without panels you still get the sun, your home and your consumption, and the production layers simply do not appear. ### Does Helios need WebGL to render its scene? No. The scene is painted by a self-contained 2.5D engine, a tilted vector basemap on a canvas with every overlay projected on top in SVG, which is what lets it stay fluid on a phone, a tablet or an older wall panel where a classic 3D render will not run. ### Where does Helios get its weather and map data? From Open-Meteo for weather and OpenFreeMap for the map tiles the ground is drawn from, and neither needs a key. Any individual weather reading, such as temperature, humidity, cloud cover, precipitation, snow or the condition, can be pointed at your own sensor, which then takes over from the forecast for the live and past hours. ## Sources - [License: GPL-3.0](https://github.com/ReikanYsora/Helios/blob/main/LICENSE) - [Project website](https://helios-ha.org) - [README](https://github.com/ReikanYsora/Helios/blob/main/README.md) - [ReikanYsora/Helios on GitHub](https://github.com/ReikanYsora/Helios) - [Releases](https://github.com/ReikanYsora/Helios/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/reikanysora-helios