KNX über Node Red in InfluxDB

[Gentleman]

Das ist für die neueren InfluxDB-Versionen (ab 2.0) die Flux-Query-Language. Die meisten Beispiele (inkl. hier im Thread) beziehen sich halt noch auf InfluxQL, das kann man mit InfluxDB ab 2.0 auch nutzen, ist aber etwas mehr Einrichtungsaufwand.

Danke dir! jetzt bin ich ein Schritt weiter! also muss ich jetzt nach dem passenden Tutorial suchen

[gerribaldi]

Wenn du in Influx dir die Daten anzeigen lässt, kannst du auf Script-Editor klicken, dann wird dir die Flux-Query-Language Anzeige für die Abfrage angezeigt. Das kannst Du dann einfach direkt nach Grafana kopieren. Schon hast du eine fertige Abfrage :-)

[jhmeier]

Zu KNX easy kann ich nichts sagen, mit KNX Ultimate ist es in Node RED absolut einfach.

Screenshot_2.jpg

Ignorier die beiden Debug-Nodes, die haben sonst keine Funktion
Der knx-ultimate Node muss im Universalmodus sein, damit er alles empfängt.
Funktionsnode:

[{"id":"a5018672.cfa578","type":"function","z":"bc30345e.5ba938","name":"KNX to Influx","func":"// Filter DPTs that are not suitable for logging, like time, RGB, etc\nvar forbiddenDptStarts = [\n \"10.\", // Time\n \"11.\", // Date\n \"19.\", // Date/Time\n \"232.\", // RGB\n];\n\nvar dpt = msg.knx.dpt;\nfor (var i = 0; i < forbiddenDptStarts.length; i++) {\n if (dpt.startsWith(forbiddenDptStarts [i])) {\n return null;\n }\n}\n\n// Boolean values cannot be compacted by InfluxDB into lower resolution retention policies (=database tables)\n// The reason is that the mean/average computation of boolean results in null value in InfluxDB.\n// Thus we turn all booleans into numeric values: false=0, true=100.\n// See Post #200 below for further information about InfluxDB retention policies and compacting data\nvar payloadValue = msg.payload;\nif (typeof payloadValue === 'boolean'){\n if (payloadValue === true){\n payloadValue = 100;\n } else {\n payloadValue = 0;\n }\n}\n\nvar newMsg = {\n measurement: msg.knx.destination,\n payload: [\n {\n value: payloadValue\n },\n {\n source: msg.knx.source,\n dpt: msg.knx.dpt,\n //description: msg.devicename,\n event: msg.knx.event\n }\n ],\n _msgid: msg._msgid\n};\n\nreturn newMsg;\n","outputs":1,"noerr":0,"initialize":"","finalize":"","x":370,"y":920,"wires":[["99a34bc5.dfe5f8","2e188c1d.c05c14"]]}]

Angelehnt an die Vorlage von xrk, habe es aber eben alles über eine einzelne Funktionsnode gelöst.

Moin. Wenn ihr alle Daten auf diese Art nach Influx geschrieben habt, nutzt ihr das dann auch als (historischen) Busmonitor? Falls ja, wie habt ihr dies umgesetzt? Direkt in Influx? Grafana?
Interessant wäre es ja z.B. sich einen bestimmten Zeitraum oder bestimmte Adressen nachträglich anzuschauen.

[Alloc]

Nein, dafür ist meines Erachtens auch eine Datenstruktur wie sie InfluxDB oder RRDs bieten nicht geeignet. Für eine Busaufzeichnung will man ja jedes Telegram als eigenen Datenpunkt, keine Aggregationen etc. Da würde ich eher auf eine klassiche SQL-DB gehen und schauen, dass man dort einfach jedes Telegram mit all seinen Infos reinschreibt. Das Hauptproblem bei sowas ist aber auch gar nicht die Aufzeichnung, sondern das sinnvolle Auswerten. Da dann direkt auf SQL-Ebene zu arbeiten ist zwar flexibel aber nicht sehr komfortabel / übersichtlich. Eine schöne Oberfläche, die auf diese Anwendung zugeschnitten ist, wäre da schon nett, gibt es aber (frei) glaube ich nicht. Alternativ wäre noch ein kleiner Exporter der dann einen Zeitraum der Telegramme in ein ETS-Gruppenmonitor kompatibles XML schreibt, damit man dann dort weiter schauen kann. In die Richtung geht mein Plan bisher

[Beleuchtfix]

Die IT-GmbH bietet ein schönes und schnelles Tool zur Auswertung an (Recorder glaube ich) man kann aber auch nur die Auswertung kaufen, extrem viel schneller als in der ETS.
Gruß Florian

[jhmeier]

Ja, das Tool der IT-GmbH habe ich gesehen - sieht nicht schlecht aus, aber ich würde gerne auf ein weiteres Tool verzichten
Nach meinem Verständnis nutzt aber doch z.B. der Timberwolf Server auch die Influx DB für das KNX Logging oder?

[Alloc]

Für die Graphen ja, aber ob das auch für die Busmonitor-Aufzeichnungen genutzt wird weiß ich nicht. Eventuell kann gbglace was dazu sagen.
Machbar ist es definitiv, nur halt nicht für den Zweck gemacht. Letztlich ist aber auch die Frage wie/wo du auswerten willst: Mit ner SQL-Tabelle bist du tendentiell mächtiger in der direkten Auswertung, wenn es aber eh exportiert wird um es z.B. in die ETS zu füttern spielt das natürlich wiederum keine Rolle

[gbglace]

Nach meinem Verständnis nutzt aber doch z.B. der Timberwolf Server auch die Influx DB für das KNX Logging oder?

Ja aber er teilt das auf.

Alles was an Telegrammen an der TWS-Schnittstelle vorbeikommt landet in einer Influx-DB die quasi als Ringspeicher ausgelegt ist. Das ist dann auch die Basis für den KNX-Busmonitor. Da hat man quasi den Liveblick mit filtern usw. aber direkt auch den Blick in die Vergangenheit. Hat man mehrere Linien im Projekt kann man mehrere Schnittstellenadapter an den TWS anbinden und somit auch die Telegramme der anderen Linie separat loggen. Damit lässt sich auch die Funktion der LK gut überprüfen.

Daneben existiert noch eine Instanz/Tabelle in der die manuell markierten Informationen gespeichert werden, diese unterliegen dann auch keiner Zeitbeschränkung.
a kommt dann alles rein wo man je konfiguriertem KNX-KO oder einer anderen Komponente (Ausgang einer Logik / MQTT-Eingang / Modbus-Dateneingang / 1-wire usw.) sich mit einem individuellen Intervall/Regel meint sich Werte speichern zu wollen.

Mit der installierten Grafanainstanz kannst beides Auswerten und mit dem nutzen was Grafana da so alles bietet und auch in externe Systeme einbinden.

[jhmeier]

Läuft denn der Busmonitor, der auf den "Ringspeicher" zugreift, auch über Grafana oder wird da was anderes genutzt?

[gbglace]

Das ist eine Eigenentwicklung und ist ne "Tabelle", da kannst aber über Schaltflächen nach Grafana zu Charts abzweigen.
Grafana als Liveview in Tabellenansicht halte ich für ungeeignet.
Der Busmonitor wurde zwar erweitert/verbessert aber eines der ersten Youtube Videos zum TWS beschäftigt sich genau damit und der Matthias Kleine hatte den auch in einem seiner Videos gezeigt, da auch in der aktuellen Form.

Die Daten aus dem Ringspeicher kannst aber in Grafana anzeigen und auch ne Tabelle bauen aber schön ist das nicht.

[jhmeier]

Ah ok - hatte gedacht, die nutzen da zufälligerweise auch ein "Standard" Produkt, weil die Tabelle im Video sieht echt gut aus. Das Konzept insgesamt finde ich auch nicht schlecht, aber derzeit bräuchte ich bestimmt 90-95% der Funktionen nicht, da ich derzeit erstmal "nur" KNX nutze und dafür finde ich den Preis zu hoch. Es gibt ja leider keine Möglichkeit nur den Basis-Server zu kaufen und die einzelnen Bereiche dann bei Bedarf zu erwerben.

Hat sich zufällig schon einmal selber etwas ähnliches gebaut? (Auf welcher Basis auch immer)

[gbglace]

Es gibt ja leider keine Möglichkeit nur den Basis-Server zu kaufen und die einzelnen Bereiche dann bei Bedarf zu erwerben.

sowas kommt in Zukunft, nur ist das was der derzeit kann einfach Basis in einem EFH, OK 1-wire mal außen vor das gibt es halt Gratis aus der Vergangenheit.
Aber Modbus und die IP-Protokolle wie MQTT und REST-API, da wirst schneller Bedarf haben als Du denkst, gerade wenn Du jetzt schon über NR nachdenkst.

Ansonsten sparst Dir damit schon in HW ne IP-Schnittstelle und den einen oder anderen RPI für das Bastelprojekt.

Ist halt die Frage braucht man in einem Smarthome einen LogikServer / Visu Server. Ich denke ja, weil man meist doch mehr als nur Licht/Rollo/Heizung bedienen und smart haben will (Gartenbewässerung / Robo Mäher / Robo Sauger / Sprachassistenten als weitere Bedienoption)

Alternativ zum Freizeitverbrauch für die kostenlosen Tools die irgendwo auf einem 24/7 Server laufen wirst mit Kauf-HW bei allen Kandidaten beim gleichen oder höheren Preis landen.

[jhmeier]

Das würde ich jetzt tatsächlich etwas differenzierter betrachten.
Der 24/7 Server läuft sowieso und bleibt - daher versuche ich eher möglichst viel darauf zu konsolidieren um nicht x RPI's oder sonstiges laufen zu lassen. Modbus Geräte habe ich nicht und die Anschaffung ist derzeit auch nicht geplant. Die IP-Schnittstelle habe ich vor einiger Zeit, aufgrund eines Fehlers, durch einen IP Router ersetzt, d.h. hier ist der Bedarf erst einmal gedeckt.
Node Red läuft zudem schon länger und sammelt die entsprechenden "Langzeit-Daten" ala Temperatur etc. Hatte gehofft dies jetzt auch einfach als "Langzeit-Busmonitor" verwenden zu können.
Visu/Logik ist im Moment Edomi - einen Vorteil darin diese nicht auf dem sowieso vorhandenen Server und dafür auf das Timberwolf System zu verschieben sehe ich jetzt nicht. Da sehe ich im Moment auch die größte "Schwäche" vom Timberwolf Server - eine einfache und vorkonfigurierte Visu. Ja Edomi und Cometvisu können darauf laufen, müssen aber dennoch separat konfiguriert werden.

Unabhängig davon bin ich bei Dir - rechnet man Freizeitverbrauch etc rein, kann sich der Timberwolf-Server schnell rentieren. Mir persönlich fehlte aber ein günstiger (am besten sogar Hardware unabhängiger) Einstieg, dann hätte ich sicherlich Timberwolf damals bei der Node-Red Betrachtung eher in Erwägung gezogen. Aber nur um damit einzusteigen, waren mir 700€+ als Einstieg einfach zu hoch, zumal ich "nur" den Bedarf hatte ein paar Daten über Grafana zu visalisieren und ggfs. einen historischen Busmonitor zu haben.

Daher bleibt meine Frage, ob zufällig schon mal jemand einen ähnlichen Bus-Monitor mit Influx-DB im Hintergrund umgesetzt hat?

[gbglace]

In einigen Threads habe ich gelesen EDOMI selbst hat ja auch einen Busmonitor, ob der aber auch direkt die Historie hat oder ein reiner Liveview ist kann ich nicht sagen.

Und das ist auch genau das was wohl das komplexe ist. Einmal wird einfach auf den KNX-Stack gelauscht und alles angezeigt was da so rein läuft, vs das Frontend muss regelmäßig gegen die Datenbank prüfen ob ne neue Zeile da ist und die dann laden. Das sind dann leicht gegensätzliche Konzepte.

Und diese spezielle Frage wäre dann eher ein neuer Thread.

[jhmeier]

Ja, Busmonitor gibt es in Edomi, aber ohne große Funktionen. Einmal als Live-Ansicht und einmal als HTML in der in Tabellen alle KNX-Telegramme aufgelistet sind.