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

[Noschvie]

Meiner Meinung nach sollten wir aus den beiden vorhandenen Projekten ein drittes machen, und zwar mal unabhängig von HA unter dem Motto „das Beste aus den beiden…“, saubere Architektur mit Backend und Frontend in zb Node.js

[overkill]

standards.png

[BadSmiley]

saubere Architektur mit Backend und Frontend in zb Node.js

unabhängig von HASS ist wieder doof, jetzt hatten wir endlich was in HASS!

[martinhoefling]

Weder noch. Erstmal sieht der Plan so aus:

• SpectrumKNX: Bugs und Featurewünsche etc. bitte auf Github - ich plane nicht das ganze einfach einzustampfen da ich es selber aktiv verwende.
• KNX in HomeAssistant:
  • Evtl. Konvergenz vom Unterbau Home Assistant + SpectrumKNX (XKNX + Telegram Storage Abstraktion + Backend Queries).
  • Ich werde versuchen Features die in HA auch nützlich sind zu portieren.
• Sachen die klar in HA gehören (Automatisierung) plane ich erstmal nicht in Spectrum KNX einzubauen.

[epogo]

Hallo, wollte das Teil auch probieren... Beim importieren der Datei bekomme ich eine Object Object Fehlermeldung. Passwort hab ich keines vergeben. Ist also leer, die ETS Datei ist auch nicht Secure... Hab es schon mit zwei unterschiedlichen unverschlüsselten Projekten probiert.
Beides unter HA.

[martinhoefling]

Hallo, wollte das Teil auch probieren... Beim importieren der Datei bekomme ich eine Object Object Fehlermeldung. Passwort hab ich keines vergeben. Ist also leer, die ETS Datei ist auch nicht Secure... Hab es schon mit zwei unterschiedlichen unverschlüsselten Projekten probiert.
Beides unter HA.

Da hat das Frontend etwas zu streng validiert, dass ein Passwort vorhanden ist - https://github.com/martinhoefling/Sp...ses/tag/v1.3.1 sollte das beheben.

[Noschvie]

Eine techn. Frage im Detail: warum verwendest du latest-pg15 und nicht latest-pg17 ?

[Alloc]

Hi, ich kam nun auch endlich mal dazu, das einzurichten. Habe dazu die Environment-Datei runtergeladen sowie die docker-compose und die prod-Dateien. Habe aber beide dann gemerged (also in der regulären docker-compose.yml die restart- und volumes-Einträge ersetzt), da das sonst garantiert irgendwann bei Neustarts vergessen gehen würde
Env angepasst:
- KNX_PASSWORD=
- KNX_PROJECT_PATH=/project/w614.knxproj
- KNX_CONNECTION_TYPE=ROUTING
- KNX_ROUTE_BACK=true
- VITE_API_URL=http://localhost:8100 (bei dem Eintrag bin ich mir nicht sicher - habe aber in Docker den externen Port auf 8100 geändert, weil 8000 schon belegt war - scheint aber auch mit 8000 zu gehen)

Zuletzt noch die docker-compose.yml angepasst, so dass die Volumes lokal liegen und nicht in einem "magischen" Docker-Ordner tief im System
- knx_db_data:/var/lib/postgresql/data -> ./db:/var/lib/postgresql/data
- knx_project_data:/project -> ./project:/project

Das ganze dann per "docker-compose up -d" gestartet - und es läuft auch direkt. Nach platzieren der Projektdatei an der korrekten Stelle zeigt das Frontend auch in den Settings, dass die Projektdatei geladen ist und die Verbindung bestehen soll, und die Filter zeigen auch die ganzen PAs und GAs:
image.png

Log meldet auch keine Probleme:

INFO: Started server process [1]
INFO: Waiting for application startup.
INFO: Starting Spectrum KNX Backend (Version: v1.5.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.237638235092163 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)
​

(Danach kommen nur noch die Frontend-Zugriffe)

Allerdings kommen scheinbar keinerlei Daten an. Selbst nach der Nacht ist noch alles leer. Hab ich hier noch was falsch gemacht?

LG,
Chris

[martinhoefling]

Du hast nicht zufälligerweise Secure aktiviert (da keine KNX Keys mitgegeben wurde)?

Ein weiteres Problem könnte das Docker Setup im Zusammenspiel mit Multicast sein. Du könntest mal versuchen die Container an das Host interface zu binden (https://docs.docker.com/compose/how-...e-network-mode).

Ich kann multicast lokal leider nicht testen, aber die darunterliegende Bibliothek (XKNX) sollte das alles korrekt handeln.

[martinhoefling]

warum verwendest du latest-pg15 und nicht latest-pg17

Das hat überwiegend historische Gründe. Wenn jemand für das Setup eine automatische Migration bauen möchte können wir gerne auf PG17 gehen.

[Alloc]

Hi Martin, danke für die Antwort
Secure hab ich nicht aktiv.
Ich habe nun den Spectrum-Container auf "network_mode: host" umgestellt. Da damit dann auch keine Port-Mappings mehr einstellbar waren, musste ich den anderen Dienst auf 8000 wegbewegen. Wäre schön, wenn der Port bei SpectrumKNX auch einstellbar wäre

Ansonsten konnte auch der backend-container dann nicht mehr den Namen des DB-Containers auflösen ("db" kennt er nur im Docker-Netzwerk, nicht im Host-Netz). Musste also in der .env noch auf "POSTGRES_HOST=localhost" umstellen, dann geht das auch. Ist natürlich nicht so schön, weil nun die Datenbank im "öffentlichen" Netz hängen muss, aber gibt schlimmeres

Jedenfalls läuft es nun und ich kann mal damit rumspielen.

Vielen Dank!

[Alloc]

Hi Martin,

hab nun mal einige Dinge per SpectrumKNX untersucht. Ist schonmal echt cool und nützlich und läuft (nach den kurzen Startschwierigkeiten ) echt gut! Hab mal ein paar Tickets erstellt mit Kleinigkeiten, die mir aufgefallen sind (kommt sicher auch noch das ein oder andre ), aber das läuft auch so schon sehr rund. Hut ab!

LG,
Chris

[Noschvie]

Wenn jemand für das Setup eine automatische Migration bauen möchte können wir gerne auf PG17 gehen.

Für die Migration der PostgreSQL-Datenbank von Version 15 auf Version 17 wird ein Upgrade mittels Dump & Restore empfohlen.
Hierbei wird zunächst ein Backup der bestehenden PostgreSQL-15-Instanz mittels pg_dump erstellt. Anschließend wird eine neue PostgreSQL-17-Instanz bereitgestellt und die Daten werden mittels pg_restore eingespielt.

Vorteile dieses Vorgehens:

• Einfacher und nachvollziehbarer Migrationsprozess
• Geringes Risiko bei kleinen Datenbanken
• Möglichkeit zur Validierung der Daten vor der Produktivsetzung
• Keine direkte Abhängigkeit von den internen Datenstrukturen der alten PostgreSQL-Version

[martinhoefling]

Danke, ich schau mir die FRs und Bugs and sobald ich dazukomme. Zunächst hat noch das Einbinden von knx-telegram-store Priorität. Davon sollte Spectrum KNX aber auch profitieren, die alten kaputten json Daten werden z.B. mittlerweile migriert.

Zur PG Migration - das ist dann vmtl nicht trivial mit einem Container umzusetzen. Falls da jemand eine Idee oder Vorschläge / PR hat, gerne. Ansonsten müsste man das als breaking change machen. pgautoupdate braucht z.B. auch einen extra Container. Eventuell wird man um einen breaking change nicht drumherum kommen.

[henfri]

Braucht man die alten Protokolle?
Für mich wäre es ok, die Daten nicht zu migrieren...
Mir wurden da die letzten Tage reichen.

Ich weiß aber nicht, wie die Usecases der anderen sind