Release 2026.9.2-a4

Author: ReikanYsora

ARCHITECTURE.md

@@ -243,9 +243,12 @@ moment, dashed, as its own line: the same shape, only its certainty gives way.
 
 The curve is projected by the engine but rendered as a **HUD layer**, not scene
 geometry, and deliberately: `#map-container` is its own stacking context, so
-anything the renderer draws is pinned below the chips. Like the sun arc it is
-layered in two depth passes around them (far behind at z 5, near over at z 11),
-which also puts it clear of the buildings it would otherwise cut through. The engine
+anything the renderer draws is pinned below the chips. It is layered in two depth
+passes (far and near) so the curve self-occludes at its own crossings, and both
+passes sit **above** the solar overlays (sun disc, arc, incidence ray, irradiance
+label): with auto-rotation the sun would otherwise sweep across the curve and hide
+the reading, so the diagram wins that overlap. It stays below the per-chip detail
+panel and the timeline, and clear of the buildings it would otherwise cut through. The engine
 stamps the radius on because it owns the arc scale, so the card hands over everything
 but that.
 
@@ -302,7 +305,11 @@ altitude), and rain, snow and thunderstorm stack on top. The overlay is CSS
 layers plus two particle canvases (`WeatherRain`, `WeatherSnow`) and a scripted
 lightning flash (`WeatherStorm`), driven by `--wx-*` custom properties the card
 sets from the layer strengths. It sits between the scene and the chips, so weather
-tints the map, never the data.
+tints the map, never the data. The scene grade itself (saturation + brightness for
+cloud cover) is **baked into the ground and building paint** by the renderer
+(`SceneRenderer.setWeatherGrade`), not applied as a CSS `filter` on the map layer:
+a filter there wraps the CSS 3D-transformed basemap and forces the whole scene to
+re-flatten every frame while rotating, which flickers hard on Android WebViews.
 
 ### Weather overrides, `data/sources/irradiance.ts`, `data/sources/weather-override.ts`
 

CHANGELOG.md

@@ -56,6 +56,31 @@ rotation on a **CPU-rasterized** basemap, which dodges the corruption while stay
 pixel-correct, so the scene turns smoothly on those devices too. Thanks to
 @beatschubser (#383).
 
+### Fixed: no more flicker on Android tablets when the map rotates
+
+On Android WebViews (the Home Assistant app, kiosk browsers) the scene could flicker
+heavily while rotating or panning. The "your real sky" weather grade was applied as a
+CSS filter over the map, which forced the whole 3D scene to re-draw every frame on
+those devices. The grade is now painted straight into the ground and buildings, so the
+map turns cleanly. This also removes a small per-frame cost on every device. Thanks to
+@Aaroneisele55 (#396) and @charleslales (#370).
+
+### Fixed: the energy diagram stays readable while the scene turns
+
+With auto-rotation on, the sun path and the irradiance readout swept in front of the
+day's energy diagram, so you had to wait for the rotation to come round before you
+could read it. The diagram now always draws on top of the sun path. Thanks to
+@beatschubser (#397).
+
+### Fixed: the cost chip no longer flips to zero between meter reports
+
+For a grid meter that reports on a coarse cadence (every 15 minutes, say), Home
+Assistant's cost sensor only steps when the meter does, leaving the buckets in between
+at zero. The cost chip read those as a real 0.00/h, so it flickered between the true
+rate and zero while you were genuinely importing. It now recognises the meter's
+reporting cadence and holds the last report's rate between updates, while a meter that
+has genuinely stopped still falls to zero. Thanks to @Rag30 (#395).
+
 ---
 
 ## 2026.9.1

dist/helios.js

@@ -1,6 +1,6 @@
 {
   "name": "helios",
-  "version": "2026.9.2-a3",
+  "version": "2026.9.2-a4",
   "description": "HELIOS - real-time solar exposure, cloud cover and PV production card for Home Assistant",
   "license": "GPL-3.0-or-later",
   "type": "module",