KNX Monitor als Website (Python/Linux [Windows])

[concept]

Ich kann beide Sichtweisen irgendwie verstehen...

ich hätte gern einen, der mit grossen Datenmengen super funktioniert und auf Windows läuft...

[henfri]

Welcher von denen, die es gibt, kommt dann mit großen datenmengen nicht klar.

Und welcher läuft nicht unter Windows.

Ich kann mir vorstellen, dass für den einen oder anderen docker erstmal abschreckend ist.

Aber statt docker kann man auch eine executable zeugen.

Und das ist genau der Punkt.

Statt jetzt den dritten fünften oder 23 Bus Monitor zu schreiben, der dann das eine Feature zusätzlich hat, aber 17 andere nicht dann wäre es doch viel sinnvoller, die Lücken in einem bestehenden zu beheben

[GLoCKE]

Ok, ich habe knx-lens geschaffen, also darf ich kritisieren.

Es geht ja auch nicht gegen dich persönlich. Es geht einfach nur darum, dass es doch toll, wäre sich auf einen zu konzentrieren

Sollte man dann nicht einen eigenen Thread aufmachen und mit Vorschlägen kommen?
So macht es nur den Eindruck hier fühlen sich ein paar Leute zurückgedrängt und lassen das am "Neuen" aus.

Ich will wie gesagt niemenden meine Lösung aufschwatzen - ich wollte lediglich deren Existenz bekanntgeben.
Was hab ich daraus gelernt. "Bleib im eigenen Kämmerlein und du führst ein ruhiges Leben. Versuchst du der Welt zu "helfen" kommen sofort die Kritiker aus dem Bau."

Zu Ihrer Lösung - die entspricht nicht dem was ich brauchte und was mich bei einer Recherche vor der Erstellung meiner App davon abgehalten hätte meine Eigene Lösung zu erstellen.
Ihr Ansatz ist vielleicht ähnlich, aber nicht mit dem vergleichbar was ich hier erstellt habe. Das soll in keinster Weise überheblich sein oder meine Lösung als überlegen darstellen, es soll nur heißen sie haben einen ganz anderen Fokus und sehr limitiert auf die Auswahl bestimmter Elemente und dann einer eher Textuellen Darstellung ohne weitere Filter etc.
Zumindest ist es da, was ich aus den animierten Grafiken auf Ihrem GIT Repo erkennen kann.

Also - OK - ich verstehe Ihre Aussagen, kann diese aber auch einordnen.

[GLoCKE]

Welcher von denen, die es gibt, kommt dann mit großen datenmengen nicht klar.

Und welcher läuft nicht unter Windows.

Ich kann mir vorstellen, dass für den einen oder anderen docker erstmal abschreckend ist.

Aber statt docker kann man auch eine executable zeugen.

Und das ist genau der Punkt.

Statt jetzt den dritten fünften oder 23 Bus Monitor zu schreiben, der dann das eine Feature zusätzlich hat, aber 17 andere nicht dann wäre es doch viel sinnvoller, die Lücken in einem bestehenden zu beheben

Darf ich Sie höflichst bitten das Thema - "es gibt 23 Bus Monitore" - nicht hier weiter zu diskutieren.
Machen Sie bitte einen extra Thread auf und bringen Sie dort Ihre Vorschläge.
Danke!

[GLoCKE]

Ich kann beide Sichtweisen irgendwie verstehen...

ich hätte gern einen, der mit grossen Datenmengen super funktioniert und auf Windows läuft...

Gern mal ausprobieren Die Installation sollte sowohl auf Windows als auch auf Linux recht leicht sein.
Die Zip Datei entpacken, die entsprechende Install MD Datei durchlesen und den Installationsschritten folgen. Sollte in 5 - 10 Mintuten eingerichtet sein.

Von welcher Größe Gruppenaddressen oder Telegrammen pro Minute reden wir bei Ihren Projekten?
Es kann gut sein, das diese Lösung hier dafür nichts taugt. Aber Versuch macht klug. 😉

[bmx]

Hallo GLoCKE,

danke das Du Dein Projekt hier teilst. Ich habe bisher noch keine 17 Monitore gesehen aber ja, es gibt schon einige davon. Ich habe bisher noch keinen wirklich gebraucht aber ich finde das ganz hübsch was Du da erstellt hast. Das schaue ich mir mal an wenn ich wieder etwas mehr Luft habe.

Und an die anderen Mitleser: Ich finde die Idee einer Übersicht gar nicht so schlecht. Also vielleicht einfach mal machen und andere können es nutzen oder dazu Beitragen. Die Settings sind schliesslich bei jedem irgendwi anders, der eine arbeitet lieber auf Windows, der andere lieber unter Linux, der nächst braucht am Ende nur eine Sammlung welche GA den meisten Lärm macht und wieder jemand will nur mal schauen ob GA x/y/z überhaupt mal was sendet.

Gruß,
Bernd

[concept]

Welcher von denen, die es gibt, kommt dann mit großen datenmengen nicht klar.

Na ja, ich meinte natürlich eine schnelle Reaktion bei einem Aufruf / einer Selektion. Und nicht minutenlanges Warten, wenn man mal die Daten eines Jahres drin hat. Ich kann mir durchaus vorstellen, dass es je nach verwendeter Datenbak da Unterschiede geben kann.

Von welcher Größe Gruppenaddressen oder Telegrammen pro Minute reden wir bei Ihren Projekten?

Edit: zwischen 100 und 500

[henfri]

Hallo,

GLoCKE Sie oder Du? Mich musst/müssen du/Sie nicht Siezen, aber ich kann das gerne machen, wenn du/Sie das bevorzugen.

es gibt:

• knx-lens - ist v.a. an der Kommandozeile - Web nur als "Spinn-Off". Uniqe Selling Point: Man kann nicht nur nach GA suchen, sondern man kann wie in der ETS navigieren und z.B. alle GAs an einem KO wählen. Logging in Dateien
• spectrum-knx - web first, database. Hat die Sicht nach KO übernommen. Hat einen MCP Server
• knx-ng-monitor - hab ich mich nicht mit befasst, da doppelt, nach meinem daführhalten. Wohl in .NET geschrieben
• knx-monitor (dieser Thread) - python, Windows installer

Nach spectrum-knx sehe ich nicht so recht, warum die entwickelt wurden. Aber vielleicht übersehe ich was. Bei Spectrum ist m.M. alles gut gelaufen: Was von knx-lens Sinn machte, wurde übertragen. knx-lens behält seine niesche "Kommandozeile" muss aber nicht weiter entwickelt werden. Spectrum kann mehr und mehr Features machen an der CLI kaum Sinn.
Wenn jetzt in spectrum noch was fehlte, hätte das m.M. gut ergänzt werden können.

Ich verstehe aber auch die Frustration. Es ist gut gemeint, die Arbeit zu teilen und ich weiß das zu Schätzen.

Gruß,
Hendrik

[ewfwd]

Egebnis: Man macht mehr Beleuchtung und verbraucht mehr Engerie als je zuvor. Jetzt hat jeder KI. Also bauen wir 100x das Gleiche.

Das kann man ja gern so sehen, aber wenn nen Kollege mir jetzt ganz stolz sein neues Haus zeigt oder Raum xy den er renoviert hat, würde ich mal sagen ist das irgendwie vielleicht nicht der beste Moment so eine Grundsatzdiskussion zu starten oder Meinung "soviel mehr Licht, hier auch indirekt, und smarthome, braucht doch alles viel mehr Strom als damals".
Ich mein kann man machen aber wenn einige einen dann als Nörgler sehen muss man sich irgendwo auch nicht wundern...

Nen Thread über den neuen BMW xy ist vielleicht auch nicht so der Ort um darüber zu diskutieren dass es sowieso schon viel zu viele verschiedene Autos gibt..

Also den Kern der Kritik kann ich verstehen, den Ort wo man diese Kritik anbringt ist aber schon suboptimal finde ich. Empathie Leute
Aber wer heute was macht und es zeigt muss sich auf Kommentare die vom Inhalt sind "finde ich doof" "braucht kein Mensch" "gibt es schon ganz oft also unnötig!" "das gibts woanders schon in viel besser" wohl leider einstellen.

[GLoCKE]

Na ja, ich meinte natürlich eine schnelle Reaktion bei einem Aufruf / einer Selektion. Und nicht minutenlanges Warten, wenn man mal die Daten eines Jahres drin hat. Ich kann mir durchaus vorstellen, dass es je nach verwendeter Datenbak da Unterschiede geben kann.

Edit: zwischen 100 und 500

Also 100 schafft meine Lösung auf einem sehr dünnen Atom laufend (backend) und einem alten AMD Ryzen ohne Verzögerung. Die 500 Telegramme pro Minute wären ein interessanter Testfall.

Die Lösung bietet den "Echtzeit Monitor" an, da laufen die aktuellen Diagramme durch. Desweiteren gibt es dann einen zweiten Tab, wo die Daten aus der DB geholt werden, dort stehen dann die vollen Daten der letzten x Tage (meine Konfiguration ist 120 Tage) zur Verfügung.
Da ich nur aller (konfigurierbar) 300 Sekunden in die DB schreibe, kann es da einen entsprechenden versatz geben ... das war mir aber für Langzeitanalysen ein in Kauf zu nehmender Kompromiss (Plattenschonung).
Ab da die DB bei voller Größe noch effizient ist, besonders bei 500 Telegrammen pro Minute, das kann ich leider (noch nicht) abschätzen, wäre aber auch ein guter Test. Ich werde den Monitor nicht täglich nutzen, daher würde mich das nicht so stören ... aber ich verstehe schon, das die Daten effektiv und schnell übertragen werden sollten.
Es findet ein paging im Telegramme Tab statt, so dass nicht alle Daten den Browser zum erliegen bringen.

(Der Telegramme Tab ermöglicht auch den Export nach CSV, so das man wenn die Daten da sind dann ggf. auch mit anderen Mitteln noch in diesen seine Recherche tätigen könnte.)


Es gibt aber auch andere Visualisierungen welche bei einer zu großen Anzahl von an Daten an Ihre Grenzen stoßen könnten (z.B. das Verbindungsdiagramm - 2000 sind da aktuell möglich - kann man erhöhen - ob das dann im Browser noch performant ist, kann ich nicht sagen.)

[GLoCKE]

So das ganze mal simuliert, mit folgenden Ergebnissen (für die Telegramm Anzeige)

Messwerte (mein Entwicklungs-PC, aber bewusst gedrosselt auf 2 Threads und die 256 MB Speichergrenze aus der Voreinstellung; Zeit =Seite + Zählung):

Fall	17,3 Mio (100/min)	86,4 Mio (500/min)
Voreinstellung: letzte 24 h	0,03 s	0,05 s
120 Tage, kein Filter, Seite 1	1,1 s	8,1 s
120 Tage, Ziel „1/2"	0,1 s	0,8 s
120 Tage, Name „Wohnzimmer"	0,7 s	2,4 s
120 Tage, Volltextsuche	1,5 s	7,1 s
120 Tage, Seite 5000 (offset 1 Mio)	4,7 s	45 s
120 Tage, letzte Seite	7,0 s	49 s
CSV-Export 100 000 Zeilen	4,1 s	40 s

Der Atom ist langsamer als dieser PC — je nach Modell und Datenträger grob Faktor 3 bis 5. Die 24-Stunden-Ansicht bleibt damit überall sofort da, die 120-Tage-Ansicht mit Filter ist bei 100/min noch erträglich, und alles Fettgedruckte ist bei 500/min auf dem Atom unbenutzbar.

Ich lass da mal noch was optimieren, kommt in die nächste Version rein.

[GLoCKE]

Hier mal ein paar erste Ergebnisse der selben Datenabfragen nach der Optimierung:

Anzeige in der GUI Gemessen an denselben Testdatenbanken
(2 Threads, 256 MB, Seite + Zählung):
vorher | nachher

17,3 Mio, Seite 5000	4,7 s	1,2 s
17,3 Mio, letzte Seite	7,0 s	0,01 s
86,4 Mio, Seite 5000	45 s	5,0 s
86,4 Mio, letzte Seite	49 s	0,01 s

CSV Export nach Optimierung gemessen:
(dieselben Testdatenbanken, 2 Threads, 256 MB):
vorher | nachher

17,3 Mio, Seite 1 über 120 Tage	1,1 s	0,17 s
17,3 Mio, Seite 5000	4,7 s	0,16 s
17,3 Mio, CSV 100 000 Zeilen	4,1 s	1,5 s
86,4 Mio, Seite 1 über 120 Tage	8,1 s	1,0 s
86,4 Mio, Seite 5000	45 s	0,86 s
86,4 Mio, CSV 100 000 Zeilen	40 s	1,1 s
86,4 Mio, letzte Seite	49 s	0,01 s

Da gab es noch eine Ungereimtheit - es wurden nur max 100 000 Datensätze exportiert, das ist jetzt auch behoben.

[GLoCKE]

Ich habe jetzt eine neue Version komplett fertig. Danke für die Anregung bezüglich Performance, das habe ich versucht zu optimieren. Genau kann man das aber erst sagen wenn mal soviel Daten in der DB gelandet sind das es auch ordentlich Last erzeugt wenn man "alles" abfragt.


KNX Monitor 1.10: Was seit 1.8 neu ist

Seit 1.8 ist einiges dazugekommen — vor allem beim Filtern, bei der Übersicht über Geräte und beim Tempo großer Datenbestände.

Filter direkt im Tabellenkopf (Live und Telegramme)

• Jede Spalte hat ein eigenes Filterfeld: Zeit, Quelle, Ziel, Name, Dienst (Write/Read/Response), DPT, Wert und Rohdaten.
• Adressen werden sinnvoll gefiltert: 1/2/3 trifft genau diese Adresse, 1/2 die ganze Mittelgruppe, 1.1 die ganze Linie. Sonst wird im Namen gesucht.
• Beim DPT trifft 9 alle Gleitkommatypen.
• Unter „Telegramme" filtert der Server, also über alle Seiten hinweg und auch beim CSV-Export.

Nach Räumen und Gruppen filtern

• Der Namensfilter sucht jedes Wort in Name, Haupt- und Mittelgruppe, Raum, Etage und eigenen Gruppen. „Wohnzimmer Ist" findet die Ist-Temperatur im Wohnzimmer.
• Die Auswahl „Gruppe" fasst Räume über alle Hauptgruppen zusammen. „Wohnzimmer" zeigt alles aus dem Wohnzimmer, egal ob es unter Licht, Heizung oder Jalousie liegt. Mit „Licht" im Namen bleibt nur noch das Licht dort übrig.
• Die Auswahl bietet nur Gruppen an, in denen der Namensfilter etwas findet.

Geräte benennen

• Übersicht „Geräte" mit allem, was das ETS-Projekt kennt oder auf dem Bus gesendet hat, samt Herkunft, Telegrammzahl und Zeitpunkt des letzten Lebenszeichens.
• Geräte, die im ETS-Projekt fehlen — eine Visualisierung, ein Tunnel wie 0.0.20 — lassen sich dort selbst benennen. Der Name erscheint überall und überlebt einen neuen Projektimport.
• Im Live-Mitschnitt steht der Gerätename unter der Absenderadresse.

Tempo bei großen Datenbeständen
Das war der eigentliche Brocken in 1.10. Getestet gegen künstliche Datenbanken mit 17 und 86 Millionen Telegrammen (120 Tage bei 100 bzw. 500 Telegrammen je Minute):

• Geblättert wird über den Zeitstempel der letzten Zeile statt über eine Zeilenzahl, und die Namen kommen erst zur fertigen Seite dazu. Eine Seite weit hinten im Zeitraum kostete vorher 45 Sekunden, jetzt unter einer.
• Der CSV-Export hatte eine unsichtbare Grenze bei 100 000 Zeilen — bei 100 Telegrammen je Minute ist ein einziger Tag schon größer. Die Grenze ist weg: der Export liefert alles, was zum Filter passt, wird blockweise gelesen und sofort ausgeliefert. Ein Tag sind rund 144 000 Zeilen und 13 MB, der Download beginnt nach einem Augenblick, und der Speicherbedarf des Dienstes bleibt gleich, egal wie groß der Auszug wird.

Wie viel angezeigt wird, entscheidest du

• In „Telegramme" die Zeilen je Seite (100 bis 2000), in „Live" wie viele Telegramme der Mitschnitt vorhält (200 bis 5000). Wirkt sofort und bleibt im Browser gemerkt — am Telefon klein, am Arbeitsplatz groß.
• Die Vorgabe steht in der Konfiguration unter web.page_size und web.live_rows.
• Auch sonst wird nichts mehr stillschweigend weggelassen: der Zeitverlauf unter „Verkehr nach Gruppen" zeigt alle Gruppen statt der acht größten, die Tabelle „Sender → Empfänger" alle Verbindungen (scrollbar, mit Filtern für Sender und Empfänger), und die Referenz für den Zeitversatz ist immer eine der ausgewählten Adressen.

Installation
./install.sh --test führt nach der Installation einen Selbsttest aus, unter Windows install.ps1 -Test.
und speichert die Ergebnisse in rauchtest.log [ich hab der KI nicht gesagt sie soll Fachbegriffe nicht übersetzen 🙄😁]

Der Monitor liest weiterhin nur mit und schreibt nie auf den Bus.

Ich hab die neueste Version hier angehangen, werde sie aber auch am ersten Eintrag austauschen.

[Noschvie]

nach der Optimierung

Darf ich freundlich fragen, was wie optimiert wurde?

[GLoCKE]

Darf ich freundlich fragen, was wie optimiert wurde?

In der Hauptsache wurden die Abfragen und die Datenmengen dieser optimiert.
Das Grundproblem war immer dasselbe: für 200 sichtbare Zeilen hat die Datenbank Millionen angefasst.

Das Blättern lief vorher über einen Offset — „überspringe eine Million Zeilen, dann gib mir 200". Dafür muss die Datenbank alles Übersprungene erst sortieren, und bei knappem Speicher landet diese Sortierung auf der Platte. Jetzt merkt sich die Oberfläche Zeitstempel und laufende Nummer der letzten gezeigten Zeile und fragt nach den nächsten 200 darunter (Keyset-Paginierung). Der Aufwand hängt damit nicht mehr an der Seitennummer — die letzte Seite ist jetzt die billigste. Die laufende Nummer braucht es, weil Zeitstempel nicht garantiert eindeutig sind und ohne eindeutige Sortierung beim Blättern eine Zeile doppelt oder gar nicht erscheinen könnte.

Zweite Bremse war die Reihenfolge der Verknüpfungen: die Namen von Gruppenadresse und Gerät wurden an alle Zeilen des Zeitraums gehängt, bevor überhaupt 200 ausgewählt waren. Jetzt wird erst die Seite gebildet, die Namen kommen danach dazu. Dafür mussten die Namensfilter umformuliert werden — sie schlagen jetzt zuerst im kleinen Adresskatalog nach, welche Adressen so heißen, und suchen dann nur noch nach diesen. Aus demselben Grund fielen die Verknüpfungen auch aus der Zählung „1–200 von N" heraus, die sie nie gebraucht hat.

Der CSV-Export schließlich baute die Datei komplett im Arbeitsspeicher auf und war deshalb bei 100 000 Zeilen gedeckelt. Jetzt liest er blockweise — mit derselben Marke wie das Blättern, nur vorwärts — und schickt jeden Block sofort raus; der Speicherbedarf bleibt konstant, die Obergrenze konnte ersatzlos weg.

Einen Index habe ich bewusst nicht angelegt. Die Datenbank ist spaltenorientiert und führt je Datenblock Minimum und Maximum mit; weil der Logger nur anhängt, liegen die Telegramme physisch schon zeitlich sortiert, und diese Blockstatistiken wirken bei Zeitbereichen wie ein Index — ohne die Schreiblast, die ein echter Index auf SD-Karte oder SSD kostet.

Gemessen an 86 Millionen Telegrammen auf absichtlich knappen Ressourcen: eine Seite weit hinten in der Liste von 45 Sekunden auf 0,9, die letzte Seite auf Hundertstel, ein Export von 100 000 Zeilen von 40 Sekunden auf gut eine — Download-Beginn nach zwei Zehntelsekunden statt am Ende.