[wiregate] InfluxDB Schema

[ctr]

Ich plane so langsam den Abschied vom Wiregate. Nachdem meine Logiken inzwischen nach node-red migriert sind (siehe https://knx-user-forum.de/forum/%C3%...e-red-tagebuch) bleiben fast nur noch die Diagramme und eib logs.
Die historischen Daten würde ich ganz gern behalten und habe mir überlegt meine alten RRDs und/oder die ganzen eib logs in eine InfluxDB zu schreiben um das dann auch mit CV zu visualisieren. Der InfluxDB-Node in node-red wäre eine Option für neue Daten, aber vielleicht mache ich das doch lieber Standalone (sonst gibt es bei nicht-laufendem node-red keine logs - nicht ideal). Egal wer/wie die Daten in die InfluxDB schreibt, erstmal brauche ich ein Schema, das folgende Vorraussetzungen erfüllt:
1. Sinnvoll mit CV nutzbar
2. Kompatibel zu vorhandenen Alt-Daten (insbesondere bei Migration von RRD)
3. Ohne Datenverlust der Quelldaten (eib log bzw RRDs)

Anbieten würde sich natürlich ein ähnliches oder sogar gleichen Schema wie es der TWS Server nutzt, aber da konnte ich nicht viel finden außer:
Database: timeseries_db
measurement: KNX_LINE<int>
tags: GA

Aber welche fields (und Datentypen) sowie sonstige tags würden Sinn machen?
Oder gibt es gar das Konverter Scripts vom TWS Server als Open Source?

[wintermute]

Ich hab damals einfach das hier gemacht...

HTH :: Michael

[Chris M.]

Die CV sollte mit jedem vernünftigen Schema in der InfluxDB umgehen können, da die InfluxDB-Schnittstelle ausreichend generisch implementiert ist.
D.h. man kann es analog dem TWS machen, muss es aber nicht.

[edelb]

Ich nutze meine InfluxDB Instanz als Busmonitor (in Kombination mit NodeRed und KNX Ultimate Node).

Das InfluxDB Schema sieht bei mir folgendermaßen aus.
Die Felder entsprechen den Datentypen:

• valueRaw (string, der den unkommentierten hex-Wert zeigt - für all die Fälle, wo die Konvertierung nicht geklappt hat - wird immer befüllt)
• valueNumeric
• valueBool
• valueString

Ich habe also alle Daten in (mehr oder weniger) ein Feld gepackt und muss dann über die Tags filtern (hier habe ich recht viele gesetzt):

• content (z.B. Ist-Termperartur, RM schalten, ...)
• dataType
• destination (gruppenadresse)
• deviceType (z.B. Temperatursensor, Reed, ...)
• dpt
• floor
• gaMainGroup
• gaMiddleGroup
• location
• locationID
• room
• source
• type

Ich weiß, manche Tags sind redundant, aber soweit ich influx verstanden habe kosten Tags nur sehr wenig zusätzlichen Speicherplatz. Von daher war es für mich in Ordnung, da ich so mehr Filtermöglichkeiten für Auswertungen habe.
Die Daten für die Tags sind bei mir im NodeRed quasi schon vorhanden, da der KNX Ultimate Node die DPT-Auswertungen schoon direkt mit ausgibt und bei mir die relevanten Infos in der Bezeichnung der Gruppenadressen schon in der ETS vorhanden ist.
Eine GRuppenadresse heisst bei mir z.B.

L6.2 / EG / 06 Kueche / Arbeitsplatte / Deckenspots / schalten

Der String lässt sich im NodeRed recht einfach wieder auseinanderpflücken und zu einzelnen Tags machen.

Vielleicht hilft das ja jemandem als Anregung.

Gruß
Felix

[martiko]

edelb
Das klingt sehr spannend und ich bin gerade selbst mit KNX Ultimate am testen. Finde ich echt super, dass man damit praktisch einen KNX-Busmonitor nachbauen kann.

Im Moment schreibe ich mir erstmal mal alles was KNX Ultimate so von meinem Testbrett mitprotokolliert in eine Text-Datei, da kann ich später mal in Ruhe schauen, was da so alles ankommt. Vor allem habe ich dabei schon festgestellt, dass KNX Ultimate auch die Bezeichnung der Mittelgruppe mit angibt, das ist natürlich auf der einen Seite sehr gut um entweder schon vorab zu filtern was man in in die InfluxDB schreiben will oder auch später bei der Auswertung der Daten aus der InfluxDB verwendet werden kann. Auf der anderen Seite merke ich - zum Glück noch rechtzeitig - dass ich mir da bei der Namensgebung der Mittelgruppen und auch GAs noch etwas einfallen lassen muss, damit ich diese dann später in Node Red gut separieren kann.

Da ich aber noch nicht so richtig fit in Node Red (und erst Recht nicht der Influxdb) bin, fände ich es toll, wenn Du noch ein paar Tipps oder Anregungen geben könntest oder vielleicht sogar bereit wärst einen oder mehrere Deiner Flows zu zeigen.

[xrk]

martiko Vielleicht hilft Dich die Diskussion hier weiter.

[martiko]

xrk
Danke für den Hinweis, ich verfolge das auch schon sehr interessiert im anderen Thread

[edelb]

martiko | Sorry, dass ich jetzt erst antworte - lese einfach zu selten am Rechner hier im Forum, so dass ich auch was sinnvolles schreiben kann.

Mein Busmonitor-Flow ist ziemlich unspektakulär - siehe Screenshot.

Die drei Funktionsblöcke beinhalten selbstgeschriebenen Code, der die Daten InfluxDB-gerecht zusammenpackt .. (der Name ist dabei Programm ..). Das ist hochgradig spezifisch für mein DB-Schema und meine Namenskonvention der GA's (wie oben geschrieben). Ich glaube daher nicht, dass das allgemein weiterhilft.
Würde eher eines der vielen im Internet erhältlichen JavaScript Tutorials empfehlen ..