Vorstellung LoxInFlux: Lox-Daten zu Telegraf/Influx für "Echtzeit" Loxone Statistiken

[Acidcliff]

Hallo zusammen,

ich möchte euch ein Projekt vorstellen, das ich rund um Weihnachten umgesetzt habe:

LoxInFlux
GitHub: https://github.com/Jakob-Gliwa/loxInFlux

Kurz gesagt:
Es ist vergleichbar mit dem Kern von Stats4Lox, jedoch speziell für Power User gedacht, die kompromisslos alle von Loxone generierten Daten sammeln wollen – insbesondere, wenn ohnehin eine Telegraf-Instanz für andere Zwecke (z. B. Zigbee2MQTT oder HASS-Daten) läuft.

Details:

• LoxInFlux hängt sich an die Websocket-Schnittstelle von Loxone und erhält in Echtzeit alle Updates der in der Visu sichtbaren Controls. Für alle anderen Daten wird ein Grabber verwendet, der diese periodisch (auch über die bestehende Websocketverbindung) abfragt.
• Die gesammelten Daten werden an eine Telegraf-Instanz weitergeleitet und können in Timeseries-Datenbanken wie InfluxDB gespeichert werden. Mit Tools wie Grafana lassen sich dann wie gewohnt Dashboards und Analysen erstellen.
• Keine Konfiguration von bspw. VirtualIns in Loxone notwendig : Es werden pauschal alle Daten abgefragt, keine explizite Auswahl von Controls erforderlich.
• "Opinionated" Ansatz":
  • Keine UI oder Konfigurationsmöglichkeiten für spezifische Controls
  • Filterung, Umbenennung und Deduplizierung erfolgen ausschließlich über Telegraf.
  • Keine End-to-End-Lösung: Telegraf, InfluxDB und Grafana müssen separat installiert werden.
  • Läuft standalone oder als Docker-Container (empfohlen).

Warum das Ganze?
Ehrlich gesagt: „Weil es geht.“ 😉

Da ich selbst jahrelang Stats4Lox benutzt habe (und zur Sicherheit noch nutze), sollten die Tags weitgehend konsistent zu Stats4Lox sein - dass ihr eure Historie nahtlos weiterführen könnt, kann ich aber nicht garantieren.

Würde mich über Feedback freuen, falls es jemand von euch probieren will!

[<Andreas>]

Ich find das richtig Cool, Stats4Lox belastet mit den Mqtt Broker zu stark und außerdem könnte man dann alles sauber in Docker laufen lassen 😃

Werd ich definitiv testen 👌🏻

[Acidcliff]

Danke dir! 😊

LoxInFlux kann theoretisch auch MQTT statt UDP als Übertragungsprotokoll zu Telegraf nutzen – also falls du deinen Broker noch mehr knechten möchtest, wäre das die optimale Gelegenheit. 😄 Spaß beiseite: In meinen Tests war MQTT tatsächlich sogar ressourcenschonender als UDP.

Übrigens, zum Thema Docker: Ich habe auch einen Docker-fähigen “MQTT Relay” entwickelt – im Prinzip eine ähnlich abgespeckte/opinionated Version des MQTT-Gateway. Läuft bei mir jetzt seit etwa drei Wochen stabil. Da es eine kritische Komponente ist, möchte ich es aber erst nach umfangreichen Tests veröffentlichen. Falls du Interesse hast, es vorab zu testen, schick mir einfach eine PN! 🙂

[Prof.Mobilux]

Stats4Lox nutzt kein MQTT - außer beim Live Collector wenn man JEDE Änderung haben will. Das möchte man aber nicht für alles haben, weil es die Datenbank gigantisch anwachsen lässt.

Ansonsten werden die Daten per HTTP vom Miniserver abgeholt und dann über ein Socket weiterverarbeitet. Aber eben als Pull.

[<Andreas>]

Ja, ich meinte den live controller, wobei ich es mittlerweile besser in Griff habe

[Acidcliff]

Das mit dem Datenwachstum ist aber auf jeden Fall ein wichtiger Punkt. Bspw. sind Elemente wie die Energiemeter können extrem gesprächig sein.

Daher ist es wichtig ein sinnvolles Telegraf-Setup aufzubauen, bspw.:
- processors.dedup -> Um gleichbleibende Werte zu filtern
- aggregators.final (oder andere Aggregatoren) -> Um Werte über einen bestimmten Zeitraum zu aggregieren

Dass es am Ende größer wird als wenn man nur für ausgwählte Elemente alle X Minuten grabt ist aber natürlich klar.

Mit großer Macht kommt große Verantwortung

[<Andreas>]

Hey Acidcliff,

Ich hab gesehen du hast noch ein anderes Projekt 🤩

https://github.com/Jakob-Gliwa/loxMqttRelay

Mach doch auch mal hier im Forum einen Trend dazu auf, ich denke das kann der ein oder andere gebrauchen 😃

Ich für meinen Teil hab was für den nächsten Winter 😁

[Acidcliff]

Hey Andreas,

jau wollte das schon länger mal hier vorstellen, wollte das aber nicht ohne ausgiebiges Testen vorstellen.
Habe das gerade mit einem Nutzer hier aus dem Forum seit ca. Januar im Testing. Bei uns beiden läuft das jetzt seit ca 1 Monat stabil, daher denke ich kann man es mal der breiten Masse bekannt machen.

Bin gerade etwas unter Wasser, aber ich kann am Wochenende mal einen Thread dazu erstellen

[<Andreas>]

Sehr cool, fühl dich nicht gedrängt 😅

[<Andreas>]

Hey Acidcliff ,

Bin drauf und dran deine Lösung umzusetzen, läuft schonmal und übermittelt Daten den Telegraph ✌🏻👌🏻

Ich möchte aber im Gegenzug zu dir nur bestimmte Werte speichern, und lieber nicht pauschal alles in die Datenbank klopfen

In Telegraph könnte die Daten recht gut über den nahmen filtern
[[processors.filter]]
namepass = ["EWT Solepumpe"]

In LoxInFlux ist es schwieriger, da man nur über die UUID eine Whiteliste machen kann
Oder ist der Datenverker zwischen Telegraph und loxinflux performancemeßig ganz zu vernachlässigen?

Was wären deine best pratices um so was umzusetzen?

Danke

[Acidcliff]

Hey Andreas,

aus Performancesicht:

• CPU-Ressourcenverbrauch:
  • Vernachlässigbar da der Filter ohnehin erst im letzten Schritt eingesetzt würde. Bis zur Filterung müssten ohnehin alle Nachrichten vom Miniserver verarbeitet werden. Und ob ein UDP Datagram geschrieben wird oder wir rausfiltern macht fast nichts aus.
  • Telegraf ist in Go geschrieben und kann deutlich effizienter die Filterungen durchführen als loxinflux es in Python könnte.
    Daher damals meine Entscheidung das nicht in loxinflux bereitzustellen.
• Datenverkehr: Sollte auch vernachlässigbar sein - die UDP Datagramme sind extrem klein. Bei TCP ist der Kanal ohnehin permanent offen.

Von daher wäre die Best Practice in Sachen Performance auf jeden Fall die Filterung in Telegraf zu nutzen.

Ich sehe auch gerade, dass meine Implementierung einen Bug hat und beim Websocket die UUID Filter später übergangen werden...
Muss ich mal fixen am Wochenende.

Btw kleiner Ratschlag am Rande, weil ich mich zufällig damit über Weihnachten beschäftigt habe:
Influxdb v2 ist ziemlich ressourcen- und speicherhungrig.
Wenn du heute schon weißt, dass du nie texthelle Sachen speichern willst, dann schau dir mal an ob du nicht direkt auf Victoria Metrics gehst.
Falls du doch auch Strings brauchst, dann geh ggf. auf influxdb 3 (nicht die OpenSource-Variante sondern die Enterprisevariante - da gibt es eigene, freie Lizenzen für Home-User).
Alle o.g. sind über Telegraf "anspielbar"

[<Andreas>]

Danke dir für die ausführliche Antwort, hatte befürchtet das ich in die falsche richtung laufe

Victoria Metrics schreckt mich ein wenig ab da die Jahres/- Monatsauswertungen nicht so toll sind

Ich wollte tatsächlich zuerst Influxdb3 installieren, das ist aber nicht mehr kompatibel mit meiner Synology CPU 😬

Hab mir darauf GreptimeDB angesehen, scheint recht gut geeignet auch vom Ressourcenverbrauch

Wo ich hier momentan hänge sind die nicht möglichen Leerzeichen, möchte die in Telegrapf einfach geben "_" ersetzen, muss mich damit aber noch genauer auseinandersetzen 😅

[Acidcliff]

Oh das ist ja interessant - was ist den so schwierig an den Monats-/Jahresauswertungen?

[<Andreas>]

Ich finde die PromQL Abfragen echt komplex / unübersichtlich wenn man irgendwelche Langzeitauswertungen zusammenbasteln will, hab da ein bisschen in der Doku gestöbert und werde nicht so richtig warm damit

sowas wie letzten Tag, Monat, Jahr abfragen ist aber echt gut und easy

Ich denke ich bleibe aber vorerst bei normalen SQL

[<Andreas>]

GreptimeDB läuft bei mir recht gut, in den ersten Momenten zumindest wesentlich ressourcenarmer als InfluxDB2
Hab die Daten auch eiskalt über MQTT laufen lassen, hat den Vorteil das man mal unkompliziert draufschauen kann (der CPU juckt das gar nicht)

Das umbenennen in Telegraf war als Anfänger nicht gerade easy damit es den Datenbankanforderungen genügt, ich poste mal meinen aktuellen Stand falls jemand das gleiche Problem hat

[[processors.regex]]
namepass = ["*"]

# Umlaute ersetzen
[[processors.regex.metric_rename]]
pattern = "ä"
replacement = "ae"
[[processors.regex.metric_rename]]
pattern = "ö"
replacement = "oe"
[[processors.regex.metric_rename]]
pattern = "ü"
replacement = "ue"
[[processors.regex.metric_rename]]
pattern = "ß"
replacement = "ss"

# Alles was kein Buchstabe/Zahl ist durch _ ersetzen
[[processors.regex.metric_rename]]
pattern = "[^a-zA-Z0-9]+"
replacement = "_"
# doppelte Unterstriche oder solche am Rand vermeiden
[[processors.regex.metric_rename]]
pattern = "^_+|_+$"
replacement = ""

# Das gleiche für die Tags
[[processors.regex.tag_rename]]
pattern = "[^a-zA-Z0-9]+"
replacement = "_"

# Grossbuchstaben ersetzen
[[processors.strings]]
[[processors.strings.lowercase]]
measurement = "*"
tag_key = "*"
field_key = "*"

[<Andreas>]

PomQL habe ich mir noch einmal angeschaut und wäre durchaus eine schöne Alternative, da war wohl meine erste Einschätzung zu schnell 😅

Dazu müsste ich aber soweit ich verstanden habe die von LoxInFlux kommenden Daten in reine Zeitstempel und Value Tabellen umwandeln, aber das wird mir ohne Vorlage zu komplex

Aber generell könnte man dadurch die Datenlast durchaus reduzieren, GreptimeDB wäre da auch nicht so ungünstig da es beides könnte falls man mal wirklich Text braucht

[Acidcliff]

Theoretisch unterstützt VictoriaMetrics das normale Influx Line Protocol, von daher sollte es eigentlich kein Problem sein.
Problem sind eher die String-Werte, wenn jemand bspw. einen Statusbaustein hat und den über die Zeit - weshalb auch immer - auswerten will.

Daher finde ich Greptime super interessant - werde das bei mir mal diese Woche testen.

VictoriaMetrics war Performance-mäßig schon echt stark bei mir:
- Statt mehrerer GB DB-Größe war meine gesamte Historie nur noch bei 600-700 MB
- CPU Verbrauch lag bei ca 10% von influx v2

Hast du zufällig auch mal Vector statt Telegraf ausprobiert?

[<Andreas>]

Alles klar, halt mich am laufenden wie deine Lösung aussieht 👍🏻

Ne, Vector schaut aber durchaus interessant aus

[<Andreas>]

Hab mal Vector als test installiert, für mich ist das nichts. Es ist mit den Daten so pingelig das man zig Ausnahmen braucht um überhaupt einmal irgendwas in die Datenbank zu bekommen und der Compiler meckert gefühlt immer, selbst wenn man nur einen unnötigen Sicherheitscheck macht 😅
Ist eher was für Profis 🙈
Da schubbert Telegraf halt einfach darüber 😂