MOBILE — Smartphone-Ansicht von homeESS

Zweck: Grundkonstrukt und Arbeitsstand der mobilen Ansicht. Jede Seite und jeder Dialog erhält eine vollwertige Smartphone-Darstellung mit der gleichen Funktionalität wie am Desktop — kein bloßes Zusammenquetschen der Desktop-Kacheln. Beim Abschluss einer Seite die Checkliste unten pflegen.

Konzept

• Ein Breakpoint: @media (max-width: 768px) = Smartphone-Ansicht.

Alles darüber bleibt die unveränderte Desktop-Ansicht.

• Gleiches DOM, zwei Darstellungen. Die Seiten bleiben serverseitig

gerendert (Leitprinzip 1); die mobile Darstellung entsteht per CSS im Mobile-Layer am Ende von public/styles.css. Der Layer steht bewusst hinter allen älteren max-width-Regeln (640/720/760/900px) und gewinnt damit die Kaskade — ältere Regeln müssen nicht angefasst werden.

• Mobile-eigene Bausteine (Tab-Bar, Menü-Sheet) werden in layout.js

immer mitgerendert und sind am Desktop per CSS unsichtbar.

• Braucht eine Seite abweichendes Markup, gibt es die Utilities

.only-mobile / .only-desktop (Anzeige nur in der jeweiligen Ansicht).

Shell (layout.js + Mobile-Layer)

• Header: kompakt, position: sticky statt fixed — er darf dadurch

bei Platzmangel gefahrlos in eine zweite Zeile umbrechen (kein horizontales Scrollen). Zeit-/Datum-Pills sind ausgeblendet (zeigt das Smartphone selbst), die gemeinsame Leistungs-Pill (☀️⚡🏠🔋) ist Desktop-only (.only-desktop), das „Aussen"-Label entfällt (der °C-Wert spricht für sich), die Batterie zeigt das Icon mit Füllstand und der SoC-Prozentzahl klein/weiß mittig im Symbol (statt daneben wie am PC); Temperatur, Batterie, Betriebslevel und Himmelssymbol bleiben sichtbar.

• Sidebar aus, stattdessen:
• Tab-Bar unten (fixiert, MOBILE_TABS in layout.js): Dashboard,

Energie, Prognose, Heizung, Wetter — ohne eigenen Menü-Tab. Stromverbrauch, Photovoltaik und Batterie haben keinen eigenen Tab: Die Energieseite ist der Einstieg in alle drei und markiert sich über match auch auf deren Unterseiten. Der vierte Platz hängt am Modul Heizung & Klima — ist es deaktiviert, steht dort Messen (Feld module bzw. hiddenWithModule eines Tabs, ausgewertet in mobileTabAvailable). Die Beschriftungen bleiben kurz, damit fünf Tabs nebeneinander passen.

• Titellogo = Menüschaltfläche: das homeESS-Logo im Header öffnet das

Menü-Sheet (nur ≤ 768px; am Desktop ist der Logo-Button funktionslos). Das Logo im Menü-Sheet hat dieselbe Größe wie im Titel (24px).

• Menü-Sheet (vollflächig, renderMobileNav): alle Hauptseiten inkl.

aktivierter Module und Unterseiten, Footer-Seiten (Module, Einstellungen), Abmelden, Copyright/Version. Das Sheet liegt mobil dauerhaft im Layout und ist geschlossen nach links aus dem Bild geschoben (transform: translateX(-100%) + opacity/visibility); beim Öffnen gleitet es von links nach rechts über den Inhalt und blendet ein (CSS-Transition im Mobile-Layer, respektiert prefers-reduced-motion). Das reine Umschalten von display wäre nicht animierbar — daher die Transform-Lösung.

• JS-Schnittstelle für die native App-Hülle: mobileNavScript() in

layout.js legt window.homeESSApp mit openMenu(), closeMenu(), toggleMenu() und isMenuOpen() an. Die App-WebView öffnet das Menü so per Wischgeste (window.homeESSApp && window.homeESSApp.openMenu && window.homeESSApp.openMenu();). openMenu() ignoriert den Breakpoint (expliziter App-Aufruf); der Logo-Button bleibt Smartphone-only.

• main-content reserviert unten Platz für die Tab-Bar

(env(safe-area-inset-bottom) für iPhone-Home-Indicator; Viewport-Meta mit viewport-fit=cover).

• Zoom auf 100 % fixiert: Das Viewport-Meta in layout.js erlaubt keinen

Zoom (initial-scale=1, minimum-scale=1, maximum-scale=1, user-scalable=no). Das Layout wird also nie skaliert — jede Seite muss exakt viewport-breit sein, horizontaler Überlauf ist ein Fehler (Symptom: Seite „skaliert größer" und schiebt die Tab-Bar aus dem Bild).

Framework-Regeln (gelten automatisch auf allen Seiten)

Arbeitsweise je Seite

1. Seite am Smartphone-Viewport (≈ 390px) durchgehen: Was bricht, was ist

unbedienbar, welche Information geht verloren?

1. Seiten-Abschnitt im Mobile-Layer von styles.css ergänzen

(Kommentar-Überschrift ── <Seite> ──). Ziel ist eine eigene mobile Informationsarchitektur (Zeilenlisten statt schmaler Spalten, gestapelte Karten, volle Breite), nicht nur Umbruch.

1. Nur wenn CSS nicht reicht: mobiles Zusatz-Markup über

.only-mobile/.only-desktop in der View ergänzen.

1. Dialoge der Seite als Bottom-Sheet prüfen (Scrollen, Tastatur, Buttons

erreichbar).

1. Checkliste hier aktualisieren, CHANGELOG-Eintrag.

Bekannte offene Punkte (Framework)

• Drag & Drop (Dashboard, Messen + Schalten) ist natives HTML5-DnD und

funktioniert nicht per Touch — mobile Alternative nötig (z. B. Verschieben-Aktion im Bearbeiten-Dialog). Siehe Roadmap-Punkt in PROJECT_CONTEXT.md.

• State-Picker-Popover dockt am Eingabefeld an; am Smartphone ggf.

besser als Bottom-Sheet.

Checkliste / Arbeitsstand