adminandClaude Opus 5
07bca5104e
Die Einstellungen bestanden aus einer einzigen langen Spalte mit den Preistabellen. Sie bekommt Reiter, und darin zwei neue Flaechen: was die Kacheln der Startseite anzeigen, und welche Geraete es ueberhaupt gibt. Reiter gab es vorher dreimal in drei Ausfuehrungen - die Etagen ueber den Automatismen mit eigenem switchTab(), die Geraetegruppen im Raum-Modal mit eigener CSS-Klasse, und die Einstellungsseite noch einmal anders. Jetzt baut restricted/reiter.php alle drei; umgeschaltet wird von Bootstrap, den offenen Reiter merkt reiterMerken() in der Adresse. Kachelwerte: was auf einer Kachel steht, stand fest in rooms.php. Die neue Tabelle kachelWerte (solarLog_kacheln.sql) ueberschreibt das je Raum, die Maske waehlt die Messwerte aus demselben Katalog wie der Automatik-Editor - nach Etage sortiert, die Geraete des eigenen Raums oben. Fehlt die Tabelle, zeigt jede Kachel weiter ihre Vorgabe. Geraete: die Zuordnung Geraet -> Raum war ein Modal, erreichbar ueber ein Zahnrad neben den Automatismen. Sie ist eine Einstellung und steht jetzt dort, zusammen mit dem, was fehlte: seit wann ein Geraet nichts mehr meldet, in welchen Automatiken es steckt, und ein Loeschknopf. Letzterer ist noetig, weil der Suchlauf nichts loescht - er legt an und frischt auf, damit die Automatiken ihre Zustands-Ids behalten; ein abgebautes Geraet bliebe sonst fuer immer stehen. Geloescht wird nur, was in keiner Automatik vorkommt. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
27 lines
1.5 KiB
SQL
27 lines
1.5 KiB
SQL
-- Anzeigewerte der Home-Kacheln.
|
|
--
|
|
-- Eine Zeile je Kachel, und nur fuer die Kacheln, an denen etwas geaendert
|
|
-- wurde. Steht keine Zeile da, gilt die Vorgabe aus restricted/rooms.php: bei
|
|
-- Thermostatraeumen die drei Werte Soll, Ist und Feuchte, sonst die dort
|
|
-- eingetragene Liste. Die Tabelle ist damit reine Ueberschreibung - sie muss
|
|
-- weder vollstaendig sein noch mitwachsen, wenn ein Raum hinzukommt.
|
|
--
|
|
-- Die Werte stehen als JSON in einer Spalte und nicht in Einzelspalten. Eine
|
|
-- Wertdefinition ist heterogen: mal ein Topic mit Pfad in einer
|
|
-- JSON-Nachricht, mal eine Liste von Wechselrichternamen, dazu Einheit,
|
|
-- Nachkommastellen, Symbol und ob die Zahl gross steht. In Spalten gegossen
|
|
-- waeren das ein Dutzend Felder, von denen je nach Quelle die Haelfte leer
|
|
-- bleibt - und jede neue Anzeigeoption waere eine Schemaaenderung. So ist es
|
|
-- genau die Form, die restricted/rooms.php ohnehin verarbeitet.
|
|
--
|
|
-- Geprueft wird beim Speichern in restricted/kacheln.php, nicht hier: die
|
|
-- Datenbank kann JSON zwar halten, aber nicht wissen, welche Symbole es gibt.
|
|
|
|
CREATE TABLE IF NOT EXISTS `kachelWerte` (
|
|
`floor` varchar(4) NOT NULL COMMENT 'Etage, wie in rooms.php',
|
|
`room` varchar(40) NOT NULL COMMENT 'Kuerzel des Raums (rooms.id)',
|
|
`werte` text NOT NULL COMMENT 'JSON-Liste der Wertdefinitionen, hoechstens drei',
|
|
`aktualisiert` timestamp NOT NULL DEFAULT current_timestamp() ON UPDATE current_timestamp(),
|
|
PRIMARY KEY (`floor`, `room`)
|
|
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;
|