Behauptung: Der HS kann HTML5 und CSS in einer Visu. Aber ich nicht-Hilfe?Bitte?

[BadSmiley]

Die werden im Webserver Baustein selbst gespeichert und damit nicht im klassischen remanent Speicher. Darum der Export und Import.

[BadSmiley]

Achso alternativ kannst du sie über einen Ausgang an ein 14byts iko schicken.

[uzi10]

Und das läuft alles auf den homeserver ohne zusatz und ohne nas? Wie machst du das alles noch mal? Das klingt ja echt interessant

[BadSmiley]

Und das läuft alles auf den homeserver ohne zusatz und ohne nas?

Richtig, das war das Ziel und weil es einfach und schnell gehen sollte auch möglichst automatisch.

Das Archivieren passiert wie gesagt über den eigenen HTTP Server im HS. Ich bin ja blöd, das mit dem Server war am Anfang. Da war es ein Baustein, jetzt sind es ja 2. Der Server stellt die Verbindung her, die Werte werden aber im Wertespeicher je GA gespeichert. Da werden die Daten in diesen geschrieben. Sicherung und Rückspielen als Json. Es können auch gezielt Zeilen aus dem Archiv gelöscht werden oder das komplette Archiv. Wer das nicht möchte, kann die Archive auch in 14Byte iKOs schreiben lassen, dann wird das auch via Remantspeicher sichern gesichert und zurück gespielt. Trotzdem bleiben die Archive editiertbar.

Wie machst du das alles noch mal?

Die HTML Seite ist eine Index.html die mit ein bißchen Zubehör für CSS und ICONs auf den HS übertragen wird. Die Konfiguration wird dann in 14byte iKOs über das Gateway gespeichert. Die Tests liefen jetzt alle in einer VM, ich werde heute mal in meinen HS Daheim alles schieben und gucken wie die Performance ist. Man muss das nicht machen, aber dann wird die Konfiguration nur Lokal gespeichert und man muss sie bei jedem Endgerät neu erstellen. Darauf hatte ich keine Lust.

PS: Ich teste gerade noch weitere Bausteine, damit kann der HS quasi "unendlich" viele UDP/TCP Tunnels aufbauen. Dann könnte man auch Projekte wie Hotels machen, in denen alles gleich ist. Also Jedes Zimmer hat die gleichen GAs und PAs. Nur die IP des Tunnels entscheidet, welches Zimmer dies ist. Da gibt es einen Empfänger, bei dem trägt man die GAs + DPT ein (sonst weiß der HS das nicht, gibt ja keine KO Verwaltung) und einen Sender, der dann gezielt auf die Tunnel schreibt. Bisher liefen die Tests mega. Egal wie viele Bausteine ich in den HS gezogen habe, es wurde bei der gleichen IP immer nur ein Tunnel aufgebaut.
PPS: Mit dem Baustein kann auch die offzielle Gira VM mit dem Bus reden.
PPPS: Die Idee mit dem HTTP Server und den Archiven habe ich von concept geklaut, dafür danke.
PPPPS: das Ganze sollte ja schon immer im HS laufen. HTML5 + CSS habe ich über den Upload via Experten bereits zum laufen bekommen. Was ich nicht ohne Hilfe hin bekommen habe, die Verbindung zum KO Gateway. Das hat dann Claude für mich gemacht. Alternativ würde auch via URL Endpoints gehen, aber dann kann ich die XML Struktur nicht vom HS ziehen.

[SvenB]

2000€ bei Gira oder einfach das Python mit XKNX auf nem Pi? Ahh letzteres ist nicht vom Gira.

Aber ich meine was verwendest du dann noch vom HS? Und wieso sieht es aus wie HASS? Hat Claus etwa da gelernt? 🤪

[BadSmiley]

2000€ bei Gira oder einfach das Python mit XKNX auf nem Pi? Ahh letzteres ist nicht vom Gira.

Ne, damit würde es ja einfach funktionieren.

[concept]

PPPS: Die Idee mit dem HTTP Server und den Archiven habe ich von concept geklaut, dafür danke.

Das war nicht geklaut, sondern geschenkt! Ich profitiere ja auch dauernd von Deinem Wissen!

Und ja, Gira hat keinen Hochschimmer davon, was für eine geile Community sie haben...

[Gergi]

Danke BadSmiley, wirklich klasse.
Habe mal zum testen einfach mal die index.html gegen die von der KI erzeugten LCARS Version ersätzt und hat wirklich ganz gut funktioniert. Da sind jetzt wirklich tolle sachen möglich.

[johannesbonn]

BadSmiley: kurze Frage, weil ich mir ähnliche Gedanken bzgl. dem Archivieren von Werten mache...Was spricht dagegen die Werte per sqlite in den Ordner /hs/data/gdsdata oder /hs/data/remanent zu schreiben? Bin mit Hilfe von Claude ein bisschen am rumprobieren und diese beiden Ordner sind beschreibbar aus einem Logikbaustein heraus und anscheinend remanent. Deine Lösung finde ich ziemlich smart, allerdings scheint die Anzahl an Werten beschränkt oder täusche ich mich da?

[BadSmiley]

Was spricht dagegen die Werte per sqlite in den Ordner /hs/data/gdsdata oder /hs/data/remanent zu schreiben?

Dass ich noch nicht darauf gekommen bin, dafür gibt es diesen Thread. Danke! Das kann man gerne mal durch probieren.

[Grobmotoriker]

BadSmiley: Was spricht dagegen die Werte per sqlite in den Ordner /hs/data/gdsdata oder /hs/data/remanent zu schreiben?

Wenn du wirklich Werte über einen längeren Zeitraum schreiben (und danach auch anzeigen) willst, würde ich dir eher eine separate Timescale Datenbank empfehlen. Ich habe mir einen kleine MQTT-Adapter geschrieben, der auf dem Bus mithört und alles was von Interesse ist in die DB schreibt. Klar, direkt auf dem HS geht das nicht, aber mir ist es eh lieber, wenn die Aufzeichnungsschicht getrennt vom "produktiven System" liegt.

[johannesbonn]

Ist ein anderer Ansatz, ich wollte gerne alles auf einem Gerät laufen haben. Ich habe auch schon was fertig, allerdings fehlen mir noch IDs von der Dacom.

[BadSmiley]

allerdings fehlen mir noch IDs von der Dacom.

Würfel mit Warnung oder warten.. wobei ich schon gehört habe von Leuten, da gibt es keine IDs mehr.

[johannesbonn]

Mhhh ok, im Moment arbeite ich mit IDs im Bereich >10800, die werden explizit zum Testen angegeben….wenn ich jetzt welche “würfel” geht das doch früher oder später in die Hose. Wie hoch gehen die IDs denn? Ich habe zum raten nicht den Hauch eines Schimmers oder hast du nen Tipp? Die Dacom wäregut beraten das zu managen, denn mit KI und Python 3.9 geht jetzt so einiges…Selbst für mich Dummy. Ich habe bereits eine Homekit Brücke und ein SQLite Archiv testweise laufen und der Aufwand war mehr als überschaubar. Fehlt nur noch eine vernünftige Diagrammfunktion und der HS hat fast alles was mir fehlte.

[concept]

SQLite Archiv

Willst dazu mehr verraten?