[Showcase] SpectrumKNX – Neues Tool für Langzeit-Analyse & Telegramm-Deep-Dive

[Alloc]

Geht mir genauso. Was ich aber fast interessanter fände wäre die Frage, warum das Update sein muss? Das ist ja im Prinzip eine rein interne Datenbank "in" einem Programm (Spectrum), wen interessiert es da, ob das nun v15 oder v17 oder sonst was ist?

[aleksanda]

Zur PG Migration - das ist dann vmtl nicht trivial mit einem Container umzusetzen.

Ich scripte das seit ein paar Jahren schon mit einem fertigen Container genau für den Zweck. Von PG 11 (?) bis jetzt 18.

tianon/postgres-upgrade:$FROM-to-$TO"

Dein Setup kenne ich nicht genau, hatte noch keine Zeit, es mir anzusehen, aber wahrscheinlich braucht es da nur ein paar Zeilen Shell Script.

Was ich aber fast interessanter fände wäre die Frage, warum das Update sein muss?

Mit 18 (glaube ich) gab es ein paar spannende Neuerungen im Bereich Vacuum, die vielleicht interessant wären. Ob man das bei der Menge an Daten lokal merkt? Keine Ahnung.

[martinhoefling]

Zur PG Migration - das ist dann vmtl nicht trivial mit einem Container umzusetzen.

Was ich meinte ist eben genau, dass ein zusätzlicher Container benötigt wird, der auch noch je nach Kontext gestartet wird. Ich weiß nicht wie man das z.B. in HA mit einbaut. In Kubernetes kann man diesen z.B. einfach als Init Container für den Pod anhängen. Bei Compose wird es evtl. was ähnliches geben. Wie gesagt, wenn das jemand bauen möchte, so dass es konsistent für die Setups funktioniert, gerne.

[Alloc]

Ich hab gesehen du warst fleißig 👍
Ich kenn mich leider in der GitHub+Docker Verbindung nicht aus... wird da automatisch irgendwann ein neues Image gebaut oder musst du das manuell anwerfen? Wollte aktualisieren und hab dann gesehen, dass latest noch 1.5.0 ist von letzter Woche.
Soll keine Beschwerde oder Anspruch sein, es ist da wenn es da ist Aber ich lerne auch gerne dazu, wie das abläuft.

LG,
Chris

[martinhoefling]

Genau, ich hab jetzt mal alle Ideen / Fixes implementiert. Du kannst das gerne testen bevor ich ein neues Release schneide. Hast du den code mit Git ausgecheckt? Falls ja, mit git pull den branch auf den aktuellen Stand bringen und dann mit docker-compose up -d --build ein Stack mit aktuellen Images starten.

[Alloc]

Hab das nur über mit Docker Compose runtergeladen, keine eigenen Builds/Container erstellt.

[BadSmiley]

Hmmm ich wollte gerade mal über cloudflare daheim was nach sehen, leider geht da die Anwendung nicht? Oder geht es generell nicht..
Ah per VPN und Browser geht die 1.5 auch nicht. 500 bad gateway... Ich such mal woran e liegt.

[martinhoefling]

v1.6.0 ist released, damit müsste man auch ohne Entwicklungssetup updaten können.

[Alloc]

Danke, hatte gestern noch die Notification von GitHub gesehen, war aber leider schon weg vom Rechner
Hab das mal durchgeschaut, funktioniert alles (bis auf Projektupload, den kann ich erst sinnvoll testen, wenn ich wieder mal Änderungen hab) wunderbar. Vielen Dank!
Hab heute nochmal ein paar Kleinigkeiten entdeckt, aber ist schon auch echt ein hilfreiches Tool.

[Amenophis]

Ich verfolge eure Beiträge seit Tagen sehr spannend. Bisher nutze ich KNXLens und bin damit sehr zufrieden aber hier entsteht ja quasi eine "weiterentwickelte" Version von der Idee die KNXLens auch hat.

Leider fehlen mir die Kenntnisse und die Antworten von ChatGPT dazu sind für mich nicht eindeutig genug. Könnte ich das auch als LXC in Proxmox laufen lassen oder bedarf es zwingend Docker zum installieren? Alternative, wird von ChatGPT bevorzugt, Docker in einem LXC oder VM und darin SpectrumKNX laufen lassen. Finde ich aber etwas überzogen, wenn es nicht sein muss. Gegen die Variante von HA spricht für mich, dass ich es gerne unabhängig von HA laufen lassen würde.

[henfri]

Hallo,

bisher (wobei ich mich auf die Screenshots und eine der ersten Versionen beziehe) sehe ich nur wenig overlap zwischen Spectrum-KNX und KNX-Lens. Die Stärke von letzterem ist halt, dass man nicht nach GA browst sondern dass man den Status aller KO eines *Gerätes* sieht.
Ich würde begrüßen, wenn Spectrum-KNX das auch könnte und so KNX-Lens ersetzt (wobei KNX-Lens dann noch für die Kommandozeile einen Wert hat).

Ich habe gerade mal die letzte Version gepullt, bekomme da aber nur ein Connection Refused.

services:
  db:
    image: timescale/timescaledb:latest-pg15
    container_name: knx_timescale
    environment:
      POSTGRES_USER: ${POSTGRES_USER:-knxuser}
      POSTGRES_PASSWORD: ${POSTGRES_PASSWORD:-knxpassword}
      POSTGRES_DB: ${POSTGRES_DB:-knx_analyzer}
    ports:
      - ${POSTGRES_PORT:-5432}:5432
    volumes:
      - ${DOCKERCONFIG}/spectrumknx/db/init.sql:/docker-entrypoint-initdb.d/init.sql
      - knx_db_data:/var/lib/postgresql/data
    restart: unless-stopped
  backend:
    image: ${APP_IMAGE:-ghcr.io/martinhoefling/spectrumknx:latest}
    container_name: knx_backend
    environment:
      - POSTGRES_USER=${POSTGRES_USER:-knxuser}
      - POSTGRES_PASSWORD=${POSTGRES_PASSWORD:-knxpassword}
      - POSTGRES_DB=${POSTGRES_DB:-knx_analyzer}
      - POSTGRES_HOST=${POSTGRES_HOST:-db}
      - POSTGRES_PORT=${POSTGRES_PORT:-5432}
      - LOG_LEVEL=${LOG_LEVEL:-INFO}
    env_file:
      - .env
    volumes:
      - ${DOCKERCONFIG}/spectrumknx:/project
    ports:
      - 8005:8000
    depends_on:
      - db
    restart: unless-stopped
volumes:
  knx_db_data: null
networks: {}​

knx_backend    | INFO:     Started server process [1]
knx_backend    | INFO:     Waiting for application startup.
knx_backend    | INFO:     Starting Spectrum KNX Backend (Version: v1.6.0)
knx_backend    | INFO:knx_daemon:Starting KNX Daemon...
knx_timescale  | 2026-06-04 11:12:27.403 UTC [27] LOG:  checkpoint starting: wal
knx_timescale  | 2026-06-04 11:13:12.438 UTC [27] LOG:  checkpoint complete: wrote 7830 buffers (1.6%); 0 WAL file(s) added, 2 removed, 31 recycled; write=34.244 s, sync=5.581 s, total=45.035 s; sync files=106, longest=5.050 s, average=0.053 s; distance=552266 kB, estimate=552266 kB
knx_timescale  | 2026-06-04 11:13:12.438 UTC [27] LOG:  checkpoint starting: wal
knx_timescale  | 2026-06-04 11:13:40.351 UTC [27] LOG:  checkpoint complete: wrote 7841 buffers (1.6%); 0 WAL file(s) added, 3 removed, 31 recycled; write=25.167 s, sync=1.283 s, total=27.914 s; sync files=62, longest=0.386 s, average=0.021 s; distance=545234 kB, estimate=551563 kB
knx_timescale  | 2026-06-04 11:13:40.352 UTC [27] LOG:  checkpoints are occurring too frequently (28 seconds apart)
knx_timescale  | 2026-06-04 11:13:40.352 UTC [27] HINT:  Consider increasing the configuration parameter "max_wal_size".
knx_timescale  | 2026-06-04 11:13:40.352 UTC [27] LOG:  checkpoint starting: wal
knx_timescale  | 2026-06-04 11:14:19.362 UTC [27] LOG:  checkpoint complete: wrote 55988 buffers (11.1%); 0 WAL file(s) added, 3 removed, 31 recycled; write=17.461 s, sync=15.142 s, total=39.011 s; sync files=66, longest=4.151 s, average=0.230 s; distance=560169 kB, estimate=560169 kB
knx_timescale  | 2026-06-04 11:14:19.362 UTC [27] LOG:  checkpoint starting: wal
knx_timescale  | 2026-06-04 11:14:57.053 UTC [27] LOG:  checkpoint complete: wrote 71223 buffers (14.1%); 0 WAL file(s) added, 14 removed, 22 recycled; write=21.672 s, sync=13.381 s, total=37.691 s; sync files=42, longest=6.167 s, average=0.319 s; distance=595836 kB, estimate=595836 kB
knx_timescale  | 2026-06-04 11:14:57.053 UTC [27] LOG:  checkpoint starting: wal
knx_timescale  | 2026-06-04 11:15:40.005 UTC [27] LOG:  checkpoint complete: wrote 53259 buffers (10.5%); 0 WAL file(s) added, 14 removed, 30 recycled; write=33.517 s, sync=7.764 s, total=42.949 s; sync files=42, longest=4.888 s, average=0.185 s; distance=719038 kB, estimate=719038 kB​

Mache ich etwas falsch?

Gruß,
Hendrik

[Alloc]

Sollte eigentlich eher so in der Art aussehen:

INFO: Started server process [1]
INFO: Waiting for application startup.
INFO: Starting Spectrum KNX Backend (Version: v1.6.0)
INFO:knx_daemon:Starting KNX Daemon...
INFO:knx_daemon:Connecting to KNX bus: type=ROUTING, gateway=AUTO, port=3671, local_ip=default, route_back=True, secure=no
INFO:xknxproject.log:Xknxproject version 3.9.0 parsing "/project/w614.knxproj" without password...
INFO:xknxproject.log:Parsing took 8.362958908081055 seconds
INFO:xknxproject.log:Found 2781 group addresses, 130 devices and 4045 used communication objects
INFO:knx_daemon:Successfully loaded KNX project from /project/w614.knxproj
INFO:xknx.log:XKNX v3.15.0 starting routing connection to KNX bus.
INFO:knx_daemon:KNX Daemon connected to bus and listening.
INFO:knx_daemon:Starting file watcher for ['/project/w614.knxproj', '/project/knx_keys.knxkeys'] (interval: 60s)
INFO: Application startup complete.
INFO: Uvicorn running on http://0.0.0.0:8000 (Press CTRL+C to quit)
​

Wie sieht denn deine .env aus?

/EDIT: Und ich sehe bei dir im Dockerfile das unten: "knx_db_data: null". Ich kenne mich mit Docker nicht im Detail aus, aber in meiner Datei steht da nur "knx_db_data: " also ohne "null".

Und ja, KNX-Lens hat immer noch seine Stärken. Der aus meiner Sicht größte Vorteil von SpectrumKNX ist schon einfach das angenehmere Web UI. Die Projektstruktur-Ansicht von KNX-Lens ist aber auch geil, und dass man dort (wie auch bei den andren Auswahlansichten) die letzten drei Werte je KO sieht ist top. Eventuell könnte ja wirklich SpectrumKNX irgendwann neben Group Monitor und History Search noch eine Art Projektansicht bekommen, in der man dann die Projekstruktur bis runter zu den KOs der Devices hat und dann auch die aktuellen Werte dazu. Aber dafür gibt es ja den Issue-Tracker, da kann man wunderbar Featurerequests einstellen

[Alloc]

Martin, wie sieht denn dein Plan für das Tool aus? Wären Erweiterungen in der Richtung wie KNX-Lens sie hat denkbar?

Konkret sehe ich zwei/drei größere Funktionsblöcke, die da noch kommen könnten (1 und 2 könnten Hand in Hand gehen):
1. Übersicht über die letzten Werte bei "Elementen". Elemente wären dabei GAs (also letzte x Werte die für zu der GA empfangen wurden) oder (siehe Punkt 2) KOs (letzte x Werte die auf *beliebigen* mit dem KO verbundenen KOs kamen).

2. Gebäudeansicht: Struktur anzeigen wie in der ETS bis runter zu den KOs der Geräte.

3. Statistiken: KNX-Lens hat hier die Telegrammverteilung in verschiedenen Kategorien: für welche GA wurden wie viele Telegramme gesendet (relativ zu der gesamten Anzahl aufgezeichneter Telegramme), von welchem KO, und von welchen Haupt/Mittelgruppen. Jeweils ausklappbar für weitere Aufteilung.

Wenn sowas überhaupt in Frage kommt würde ich das jeweils in sauberer ausformulierte Featurerequests verpacken. Da will ich nur ungerne die Zeit reinstecken, wenn das auf keinen Fall denkbar ist

/PS: Natürlich heißt ein "ja" erstmal nicht, dass ich erwarte, dass die Featurerequests dann überhaupt oder exakt so umgesetzt werden. Nur wenn du jetzt sagst "auf keinen Fall, das Tool ist so in seinem Funktionsumfang wie es sein soll" dann wäre es halt unnötig die Tickets zu schreiben