[Showcase] KNX-NG-Monitor: Busmonitor mit responsive Weboberfläche, zeichnet rund um die Uhr auf (Beta, Tester gesucht)

[elkomaster91]

Guten Tag,

ich habe das Projekt auch mal bei mir zuhause installiert. Leider kann ich meine GAs nicht so gut auswählen, da das Fenster zu klein ist.

Wäre sehr dankbar wenn das größer werden könnte, damit ich es auch gut nutzen kann, da mir das Projekt sehr gut gefällt.

Gruß

image.png

[elkomaster91]

Habe noch einen Verbesserungsvorschlag:

Bei den Diagrammen im Live Modus das nicht der letzte Wert rechts das ende ist, sondern der aktuelle Zeitstempel.

[ploetman]

Hab's auch installiert (als LXC Container in Proxmox) und es läuft. Gefällt mir gut.

Ich würde gerne sehen wieviele Telegramme pro GA in einem ausgewählten Zeitraum mitgeschnitten wurden. Quasi als Debugging-Feature zur Buslastanalyse.

[ingel81]

Steht doch in der Folgezeile: "ein paar chown / chgrp / setfacl später".
Es werden Annahmen zu Rechten getroffen, die nicht zutreffen (müssen), nämlich uid=1000(app) gid=1000(app) groups=1000(app). Sowas muss konfigurierbar sein.

Das macht Sinn. Kannst auf auf Github dazu ein enhancement Issue aufmachen.Danke!

Edit: bereits angelegt => Beides ist jetzt hier festgehalten, inkl. PUID/PGID: https://github.com/ingel81/knx-ng-monitor/issues/40

[ingel81]

Beim Import der GA werden die DPT nicht berücksichtigt. Unter Project/<Projekt>/Details steht bei allen DPT N/A (auch bei wiederholtem Import, auch bei Import eines zweiten Projekts).

Der ETS4 Parser hatte ein Problem mit DTP Erkennung. Ist seit v0.12.0 (22.09) behoben. Gerne damit nochmals testen.

[ingel81]

Wenn er die Telegramme nicht in grösseren Blöcken und Abständen in die DB schreibt (was ich nicht denke) macht Dir eine SD schnell mal schlapp

Stimmt leider, aktuell ist das (noch) ein direkter Insert in SQLite pro Telegramm. Nur bei Bursts landen mehrere in einem Commit. SQLite läuft im WAL-Modus, der fsync kommt beim Checkpoint etwa alle 10 s. Das Problem für eine SD ist aber weniger die Frequenz als die Menge => jeder Einzel-Commit schreibt mehrere volle 4-KB-Seiten, obwohl ein Telegramm nur ein paar hundert Byte hat.

Denke ich spendiere dafür eine Option: Telegramme werden in einem konfigurierbaren Puffer gesammelt und in größeren Intervallen als ein Block geschrieben. Die Live-Ansicht bleibt davon unberührt, nur die Historie wird entsprechend verzögert gefüllt. Trade-off: bei Stromausfall ist der Inhalt des Puffers weg.

[ingel81]

Habe noch einen Verbesserungsvorschlag:

Bei den Diagrammen im Live Modus das nicht der letzte Wert rechts das ende ist, sondern der aktuelle Zeitstempel.

Du hattest ja diverse PRs via Claude eingestellt. Danke dafür! Ein bisschen was habe ich gemerged, bei einem Teil musst du nochmal ein paar Dinge korrigieren (lassen) bitte, siehe Github

[ingel81]

Sehr interessantes Projekt
Wie leistungshungrig ist das Tool? Ich hab noch einen Pi 2 oder 3 rumliegen auf dem ich es testen könnte…
Wie verhält es sich mit Änderungen am ETS Projekt? Einfach neu hochladen und läuft? Mein KNX wächst gerade noch Stück für Stück.
Wieviel Speicher sollte man für Langzeitmonitoring einplanen? Sicher wäre ne SSD besser als ne SD Karte, oder?

Hi,

Pi: Es gibt nur 64-Bit-Builds (ARM64). Der Pi 2 fällt damit raus, ein Pi 3 mit 64-Bit-OS geht. Für den Dauerbetrieb reicht der, aufwändige Auswertungen über lange Zeiträume dauern dann halt etwas.

ETS-Änderungen: ja, einfach das neue Projekt hochladen. Namen, DPTs usw. werden dann auch für die bereits aufgezeichneten Telegramme verwendet.

Speicher: in der Datenbank etwa 140 MB pro 1 Mio. Telegramme. Standardmäßig werden die letzten 1 Mio. vorgehalten (einstellbar). Optional gibt es zusätzlich ein Langzeitarchiv, eine gzip-Datei pro Tag, das ist deutlich kompakter.

SSD vs. SD: SSD ist klar besser. Aktuell schreibt das Tool jedes Telegramm einzeln in die DB, das mag eine SD-Karte nicht. Dafür kommt vermutlich eine Option für gepuffertes Schreiben: https://github.com/ingel81/knx-ng-monitor/issues/37

[ingel81]

Hatte die vorige Version nun ein paar Wochen nebenbei laufen lassen und heute das Update / pull auf die Version ? (wo im GUI sehe ich die Version, außer beim Login?) gemacht, eigentlich ohne Probleme. Die 30-Tage Statistik zeigt über 700000 Events, und das Laden dauert schon ein einige Sekunden (RPi4 mit SSD), vermutlich wäre das mit einer PostgreSQL / TimescaleDB schneller.

Aber die GUI ist wirklich gelungen!

Zwei Anmerkungen:
.) im Docker Compose File würde ich mir einen TZ Parameter erwarten
.) "Collapse all" hat keinen Rahmen wie die anderen Buttons
.) Expand all / Collapse all -> vielleicht besser als ein einziger „Expand/Collapse all“-Button mit dynamischem Label, aber das ist sicher Geschmacksache

Nochmals Danke für's Teilen!

Danke fürs ausgiebige Testen und das Feedback!

- TZ: ist dank deines PRs im README drin.
- Version: wird mit dem nächsten Release zusätzlich im Benutzermenü oben rechts angezeigt.
- "Alle einklappen" hat dann auch einen Rahmen. Beim Toggle bin ich bei zwei Buttons geblieben, bei halb aufgeklappten Bäumen wäre ein einzelner Button nicht eindeutig.
- Statistik-Ladezeit: liegt nicht an SQLite, sondern daran, dass Statistik und Heatmap aktuell jeden einzelnen Zeitstempel laden und erst im Backend zählen. Das wandert in die DB und wird hoffentlich schneller: https://github.com/ingel81/knx-ng-monitor/issues/39

[ingel81]

Hab's auch installiert (als LXC Container in Proxmox) und es läuft. Gefällt mir gut.

Ich würde gerne sehen wieviele Telegramme pro GA in einem ausgewählten Zeitraum mitgeschnitten wurden. Quasi als Debugging-Feature zur Buslastanalyse.

Gute Idee, gerade für die Buslast-Analyse. Hab ein Issue dazu angelegt: https://github.com/ingel81/knx-ng-monitor/issues/38

[ingel81]

Der GIRA S1 hat beispielsweise eine Aufzeichnung integriert, so wie die ETS das auch macht. Wenn man jetzt die Vorteile Deines Programmes (neben der Aufzeichnung) nützen möchte, wäre der Gedanke ja nahe, eine vorhandene Aufzeichnung reinzuladen und entsprechend anzuzeigen :-)

Danke für die Erklärung, verstehe den Anwendungsfall. Einen Import fremder Aufzeichnungen plane ich aber vorerst nicht, der Fokus liegt auf der eigenen Aufzeichnung.

[Noschvie]

Wäre die Verwendung der Python-Bibliothek knx-telegram-store vielleicht eine Möglichkeit zur Vereinfachung?

[gbglace]

Auch in diesem Tool, fände ich eine Funktion sehr elegant wenn jedes Telegramm mit seinem Original-Zeitstempel, angereicht um die ETS Metadaten zur GA und sendenen PA, als JSON 1:1 nach MQTT weitergereicht werden könnte.


Einen KNX-Monitor als solchen für die Live-Analyse und eher kurzfristige Bug-Analyse (Telegrammretention bis zu einem Monat) ist dann gut in diesem Tool aufgehoben.

Effektive KI basierte Langzeitanalysen und Ideen für neue Automatisierungen mache ich dann aus einer zentralen Datenbank in die ich auch dieses JSON leiten würde. Denn z.B. alle energiemonitoring Rohdaten sind hier nicht im KNX, das würde mir den TP Bus ständig ans Limit bringen.

Also aber schonmal Daumen hoch für das was da ist.

geplante Plattform hier für mich auch ein LXC auf einem 24/7 Proxmox Server.

[Noschvie]

Würdest du den KNX-to-MQTT-Forwarder als Docker-Container betreiben wollen?

[gbglace]

Ja.

Allerdinsg habe ich heute auch noch ein paar mehr Zwiegespräche mit meinem KI Helferlein geführt.
Mein Haus ist ja ein generisch lebendes Objekt und nicht mal in einer enthusiastischen Session geplant und dann fixiert hingebaut. Da gibt es auch im KNX immer mal Umgestaltungen und entsprechende GA reuses.
Also einen Versionsstand GA zu Name und DPT usw. und dann damit 10 Jahre Historie auflösen past auch nicht für mich.

Aber für jemanden der erstmal anfängt und einfach eine Tool unabhängige Datenspeicherung möchte ist so ein Forwarder mit decodierung schon nicht schlecht.

Aktuell bastel ich da noch mit sehr begrenztem Tempo an einer eigenen Lösung.

mit den xknx Bibliotheken ist es ja erstmal kein großes Hinderniss die tieferen "CEMI" Daten und die gefilterten Telegrammdaten einzusammeln und direkt an MQTT zu werfen (das hat das Ding hier neute schon mal eben schnell gebaut) und per EMQX rules in mein raw schema der Datenbank.

In einer Minimalen UI muss ich dem Tool dann nur die KNX Key Datei der ETS beischaffen, damit es die Secure-telegramme soweit auflösen kann.


Und da ich sehr faul bin die ETS Projektdatei in so diverse Busmonitore, GA-Generatoren, HA, Nodered usw. hochzuladen. Habe ich da vor das nur noch in einem Tool zu machen und dann zerlegt der mir das alles und schreibt das sauber in Tabellen in ein meta Schema meiner Datenbank wo ich eh alle iot-Daten speichere wie auch die KNX-Daten.

In der Datenbank lassen sich dann auch die Metadaten versioniert speichern und Roh-Telegramme auch noch über x Jahre Vergangenheit sinnvoll semantisch decodieren.
Für einen reinen Busmonitor ist das aber alles zu langsam, um da mal eben schnell den Telegrammfluss aus Aktion Taster und Reaktion Aktoren begleiten zu können.
Solche tools brauchen die notwendigen Metadaten direkt im Zugriff.

Um das dann noch weiter zu automatisieren in einer größeren "APP" finde ich die Ansätze vom Power-Editor auch nicht schlecht die gesamte ETS Projektdatei im laufenden Betrieb der ETS sichtbar zu haben.

Da müsste man halt noch irgendwie eine Automatisierung hinbekommen, wenn es eine Projektänderung gab, oder eigentlich nur nach einer Applikationsprogrammierung, quasi die semantischen Datenspeicher des ETS Projektes auch direkt ausgeleitet zu bekommen oder aktiv auszulesen und an die andere Datenbank zu reichen. Ein JSON je PA / GA / Gebäudebaum und ws später ggf mal noch kommen wird in der ETS.

So andere Tools wie ein Busmonitor, GA-Generator und Anreicherungsviews als Zugriffsebene für Grafana und anderen Logiken mit Langzeitanalyse, müssten sich dann eigentlich nur den aktuellen Stand aus dem meta-Schema der Datenbank holen oder werden von dort betankt.

Ich habe ja derzeit ein paar ruhige Tage und bastel da auch noch was weiter in der Richtung.

Da meine Vorhaltung von Secrets bei mir vollständig in einer Infisical Instanz zentralisiert sind, ist das alles nur nicht unbedingt Massenkompatibel wo immer alles in .env Daten in den Containern übertragen wird und jeder Service immer alles als Insel vorhält. So eine App dann mit Installationsoptionen, Mini DB für das was muss im Tool und vs Datenspeicherung externe DB vs interne geht über meine fähigkeiten und Bedarf weit hinaus.

Insofern beobachte ich aktuell die diversen Busmonitor Projekte sehr genau.