Telegraf & KNX

[meti]

Ich bin da auf GitHub über was gestolpert das vielleicht für manche nützlich sein könnte. Telegraf config über Projektimport.
https://github.com/svsool/knx-telegraf-config-generator

[stonie2oo4]

Ich hab das bei mir auch schon seit einer Weile so laufen.
Also das Telegraf über das KNX-Plugin meine Daten sammelt.
An für sich eine super Lösung, bloß hab ich ein kleines Problem damit.
Und zwar wenn mein KNX-Router kurz nicht erreichbar ist (z.B. beim Update von Switch oder Router) dann wird keine erneute Verbindung von dem KNX-Telegraf Plugin zum KNX-Router aufgebaut wenn dieser wieder erreichbar ist.
Das ist ein bisschen nervig, da ich das manchmal nicht merke und mir so immer paar Tage an Aufzeichnungen fehlen. Abgesehen davon ist es auch nervig von Hand eingreifen zu müssen 😅.

Konntet ihr dieses Problem auch schon feststellen?

Ich muss dazu sagen das InfluxDB und der KNX-Router sich in 2 verschiedenen Netzen befinden.
Die Verbindung von Telegraf zu KNX wird über „Tunnel“ hergestellt und funktioniert im normalen Betrieb auch absolut unauffällig ☺️.

[meti]

Den Bugreport solltest du denke ich eher auf GitHub machen. Da werden es die Entwickler eher sehen 😉

[stonie2oo4]

Hab ich mal gemacht, Danke für den Tipp.
Wäre trotzdem interessant gewesen ob sonst noch jemand dieses Verhalten nachstellen kann oder ob es irgendwie an meinem Setup liegt.

[BlicKtNiX]

Vielen Dank micha149 für Deinen Beitrag! Das hat mir einiges an Grübeln erspart :-) Funktioniert super!

[ewfwd]

Soweit ich das sehe unterstützt das KNX-Input-Plugin wirklich nicht die Möglichkeit einer GA ein Tag zuzuweisen. Ich löse das nun per Processor-Plugins. Hier meine Konfiguration:

Alternativ kann man das auch über Task machen wenn man die Werte dann in ein anderes Bucket für die Langzeitspeicherung überführt.
Die Tag vergabe des Plugins finde ich aber auch nicht wirklich perfekt.

source sollte in meinen Augen eher "KNX" als string enthalten weil man unter Umständen nicht nur Daten aus KNX in seiner influxdb hat.
Habe daher source="KNX" gesetzt und das ursprünglich source in physicaladdress umbenannt...

[DJ.Picasso]

Moin micha149

habe diesen Beitrag von Dir "ausgegraben". Super, hat mir wirklich weitergeholfen.

Habe auf meiner Synology NAS InfluxDB und Telegraf im Docker laufen. Im Telegraf habe ich den KNX_Listener konfiguriert und lasse mir jetzt die KNX Daten in die InfluxDB schreiben.

Frage von meiner Seite, ich habe noch einige weitere Feature des Processors genutzt, um die Daten anzureichern.

Sowohl bei "processors.enum" habe ich entsprechend weitere Mappings bzw. "dest" gemacht aber vor allem auch mit "processors.regex.tags" noch weitere Tags hingzugefügt.

Bsp. habe ich nicht die Groupaddress per rename geändert, sondern über regex den Raum hinzugefügt.
Zusätzlich noch die Etage und eine Entität.

Bist Du bei Dir schon weiter mit Deiner Config?
Hast Du da auch noch was ergänzt?

Würde mich interessieren, wie Du Deine Daten strukturiert hast.
Ciao
Der DJ

[ewfwd]

Ich möchte eine weitere Möglichkeit vorstellen:

Statt processors.enum kann man auch einfach processors.lookup verwenden. Dadurch kann man die Zuordnungen für weitere Tags durch eine json oder csv Datei vornehmen.

Am Beispiel mit Linux:

folgende Zeilen werden im config file ergänzt.

# Lookup a key derived from metrics in a static file
[[processors.lookup]]
  ## List of files containing the lookup-table
  files = ["/etc/telegraf/telegraf.d/lut.json"]

  ## Format of the lookup file(s)
  ## Available formats are:
  ##    json               -- JSON file with 'key: {tag-key: tag-value, ...}' mapping
  ##    csv_key_name_value -- CSV file with 'key,tag-key,tag-value,...,tag-key,tag-value' mapping
  ##    csv_key_values     -- CSV file with a header containing tag-names and
  ##                          rows with 'key,tag-value,...,tag-value' mappings
  format = "json"

  ## Template for generating the lookup-key from the metric.
  ## This is a Golang template (see https://pkg.go.dev/text/template) to
  ## access the metric name (`{{.Name}}`), a tag value (`{{.Tag "name"}}`) or
  ## a field value (`{{.Field "name"}}`).
  key = '{{.Tag "groupaddress"}}'​

Dann erstellt man sich eine json Datei in meinem Fall lut.json nach folgendem Muster:

{

"0/2/6": {
"Himmelsrichtung": "Ost",
"Standort": "Dach"
},

"0/2/7": {
"Himmelsrichtung": "Süd",
"Standort": "Dach"
},

"0/2/8": {
"Himmelsrichtung": "West",
"Standort": "Dach"
},

"10/3/41": {
"Etage": "EG",
"Gewerk": "Heizen/Klima"
},

"10/3/42": {
"Etage": "EG",
"Gewerk": "Heizen/Klima"
},

"10/3/43": {
"Etage": "EG",
"Gewerk": "Heizen/Klima"
},

"20/3/41": {
"Etage": "OG",
"Gewerk": "Heizen/Klima"
},

"20/3/42": {
"Etage": "OG",
"Gewerk": "Heizen/Klima"
},

"20/3/43": {
"Etage": "OG",
"Gewerk": "Heizen/Klima"
}




}

Nachteil bei json ist es erlaubt keine Kommentierungen. Ich überlege grade ob ich daher nicht einfach den kompletten GA namen, also die vergebene Bezeichnung ebenfalls unter einem tag wie beispielsweise "name" abspeichere.

Es sind auch mehrere json Dateien einbindbar. Man könnte zB für jede Hauptgruppe eine eigene Datei anlegen.Auch müssen die json Dateien nicht im telegraf config Ordner sein.

In meinen Augen ist dieser Ansatz übersichtlicher wenn man beabsichtigt mehr als ein weiteres Tag zu vergeben. Wenn man mal eine GA verschiebt muss darüber hinaus nur an 2 Stellen die GA geändert werden, einmal in der config Datei und einmal in der json Datei.
Mit processor.enum hingegen muss ich an jeder Stelle wo ich nochmal bezug auf die GA nehme diese Zahl korrigieren. Meiner Meinung nach kann es schnell dafür führen dass man hier durchaus mal eine Stelle vergisst wenn man nicht über die Suchfunktion sich dann sämtliche Stelle anzeigen lässt mit der besagten GA.

P.S:
In meinen Augen bietet es sich an für verschiedene Dinge eigene config Files anzulegen.
Ich habe zB

inputs.knx.conf
inputs.mqtt.conf
outputs.influxdb.conf und
processors.conf

Globale Dinge werden eine Ebene darüber in telegraf.conf angelegt

[ewfwd]

Code:

[[inputs.knx_listener]] service_address = "192.168.1.234:3671" [[inputs.knx_listener.measurement]] name = "room-temperature" dpt = "9.001" addresses = [ "5/2/4", # Badezimmer "5/1/2" # Gäste WC # ... ] [[processors.enum]] namepass = ["room-temperature"] order = 1 [[processors.enum.mapping]] tag="groupaddress" [processors.enum.mapping.value_mappings] "5/2/4" = "Badezimmer" "5/1/2" = "Gäste WC" # ... [[processors.rename]] namepass = ["room-temperature"] order = 2 [[processors.rename.replace]] tag="groupaddress" dest="room"

Anmerkung:

Ich bekomme aktuell in der Console eine Warnmeldung wegen der Verwendung von "tag". Mit Version 1.40 soll es nicht mehr funktionieren. Meiner Meinung nach muss "tag" hier in "tags" unbenannt werden.

Wenn man hier schaut https://github.com/influxdata/telegr...rocessors/enum

wird auch schon tags benutzt.

[ewfwd]

Sowohl bei "processors.enum" habe ich entsprechend weitere Mappings bzw. "dest" gemacht aber vor allem auch mit "processors.regex.tags" noch weitere Tags hingzugefügt.

Bsp. habe ich nicht die Groupaddress per rename geändert, sondern über regex den Raum hinzugefügt.
Zusätzlich noch die Etage und eine Entität.

Vielleicht wird es einfacher das nachzuvollziehen wenn du den Code hier einfügst.

Ich habe das zB mit processors.emum.mapping gemacht

[[processors.enum.mapping]]
tag = "groupaddress"
dest = "Raum"
[processors.enum.mapping.value_mappings]

"12/3/131" = "EG-Flur" # EG-Flur-RTR-Stellwert *Status*

Mir erscheint die Lösung mit lookup aber übersichtlicher.

[DJ.Picasso]

Hi ewfwd

teilweise habe ich auch enum.mapping genutzt.
Es geht aber eher prinzipiell darum, was man überhaupt in welcher Form als "line protocol" in Richtung influxdb schreiben möchtest und was Du als tags bzw. fields schreiben möchtest, da tags und fields unterschiedlich von influxdb verarbeitet werden.

Meine Struktur:
Measurement: Licht, Licht_Helligkeit (für Dimmen), Rollladen, Rollladen_Position usw.

Tags:
Etage, Raum, Kategorie, Lokation, Groupaddress, Objekt, Full_Name
Host und Source werden automatisch bereits mitgeliefert, sind aber überflüssig

Field:
Value
Dies sind letztendlich die Schaltwerte, die auf den Bus geliefert werden (DPT 1.001, 1.008, 5.001, 9.001 usw usw.

Damit wird beispielsweise ein Licht-Protocol wie folgt geliefert.

light,category=toggle,floor=EG,full_name=Esszimmer _Licht_Pfeiler_AnAus,groupaddress=1/1/130,host=telegraf,object=pfeiler,room=Esszimmer,so urce=1.1.62 value=false 1758170613914281440

Um diese Struktur der Tags zu erstellen habe ich folgende knx_listener.conf erstellt. Da meine conf Datei ca. 4.000 Zeilen enthält, hier nur die wesentlichsten als Beispiel.

################################################## ######
# Licht
################################################## ######
[[inputs.knx_listener.measurement]] # Measurement definition(s)
name = "light" # Name of the measurement
dpt = "1.001" # Datapoint_Type (DPT) of the KNX messages
addresses = [ # List of Group_Addresses (GAs) assigned to the measurement
"1/1/130", light "Esszimmer Pfeiler"
... # Hier können natürlich alle Lichtobjekte stehen, die vom Typ her DPT 1.001 sind, also boolean inkl. natürlich der Statusinfos. Daher nacher auch der Tag Category, in dem "state" hinterlegt wird. Somit habe ich die Möglichkeit, später mit Flux die reinen "on/off" Schaltzustände rauszufiltern.
...


################################################## ########
# Esszimmer
################################################## ########
[[processors.regex]]
[[processors.regex.tags]]
key = "groupaddress"
pattern = "^1/1/120$|^1/1/122$"

# Wichtig hier ist vor jede Adresse das "Haus" zu setzen und am Ende das $-Zeichen, ansonsten ordnet processor.regex die Adressen nicht korrekt zu
replacement = "EG"
result_key = "floor"

[[processors.regex.tags]]
key = "groupaddress"
pattern = "^1/1/120$|^1/1/122$"
replacement = "Esszimmer"
result_key = "room"

[[processors.enum]]
[[processors.enum.mapping]]
tags = ["groupaddress"] # hier kommt bereits tags zum Einsatz, damit erübrigt sich dann die Meldung
dest = "location"
[processors.enum.mapping.value_mappings]
"3/1/80" = "ost" #binary_sensor_onoff Esszimmer_Fenster_Ost_Kippen
"3/1/85" = "ost" #binary_sensor_onoff

[[processors.enum.mapping]]
tags = ["groupaddress"]
dest = "object"
[processors.enum.mapping.value_mappings]
"1/1/120" = "decke"
"1/1/125" = "kamin"
"1/1/130" = "pfeiler"
"1/1/132" = "pfeiler"

[[processors.enum.mapping]]
tags = ["groupaddress"]
dest = "category"
[processors.enum.mapping.value_mappings]

"1/1/120" = "toggle" light Esszimmer_Decke_
"1/1/122" = "state" #light_state Esszimmer_Decke
"1/1/128" = "dim" #light_brightness Esszimmer_Kamin
"1/1/130" = "toggle" light Esszimmer_Pfeiler_
"1/1/132" = "state" #light_state Esszimmer_Pfeiler
"1/1/133" = "dim" #light_brightness Esszimmer_Pfeiler


[[processors.enum.mapping]]
tags = ["groupaddress"]
dest = "full_name"
[processors.enum.mapping.value_mappings]
"1/1/120" = "Esszimmer_Licht_Decke_AnAus"
"1/1/122" = "Esszimmer_Licht_Decke_Status"

Wie man sieht, wird "location" nur für ganz bestimmte Objekte eingesetzt, die später mit zusätzlichen Infos gejoint werden. Wenn ich wirklich alle Objekte mit Join benötigen sollte, dann kann man schnell in diese Struktur die Dinge ergänzen.

Ansonsten müssen die o.g. Strukturen halt für alle Objekte und Gewerke "durchgezogen" werden. Ist etwas Fleißarbeit, aber wer mit Excel umgehen kann, der kann sich mit einigen Skripten alles leichter machen, dann kann man - wie gesagt - 4.000 Zeilen auch schnell mal, vor allem strukturiert, in 1 - 2 Stunden erstellen.

Hoffe, das hilft weiter.

Es gibt auch andere Möglichkeiten mir regex bsp. die Etage zu definieren.
Wenn Du beispielsweise Deine Addresse so strukturiert hast, dass bei 1/2/5 die erste Ebene das Gewerk darstellt, die 2. Ebene die Etage und die 3. Ebene halt das Objekt, dann kann man regex auch anders nutzen.
Ist bei mir eigentlich so, aber es gibt einige Ausnahmen und daher habe ich bei regex halt diesen Weg gewählt. Damit musste ich nicht die Adressen ändern, die von den normalen Strukturen abweichen.

[ewfwd]

da tags und fields unterschiedlich von influxdb verarbeitet werden.

Nun ja bei dieser Integration gibt es ohnehin immer nur ein Field pro measurement. Das sollte man auch so lassen weil das sonst Performance kostet.Wenn du Wert A und Wert B mit dem selben measurement schreiben willst aber zu unterschiedlichen Zeiten werden daraus 2 Einträge und der jeweils fehlende Wert wäre NULL. Das gilt es zu vermeiden weil damit würde die Tabelle größer werden nur weil sie an zig Stellen NULL "Werte" hat. Einen Temperaturwert und einen Feuchtigkeitswert vom selben KNX Teilnehmer kann man ja nicht zur exakt selben Zeit bekommen (außer ein Hersteller würde ein Kombiobjekt benutzen wo er dann alles in ein Telegram packt, ob es sowas gibt keine Ahnung)

Da meine conf Datei ca. 4.000 Zeilen enthält, hier nur die wesentlichsten als Beispiel.

Warum splittest du sie nicht auf?

[[processors.enum.mapping]]
tags = ["groupaddress"]
dest = "object"
[processors.enum.mapping.value_mappings]
"1/1/120" = "decke"
"1/1/125" = "kamin"
"1/1/130" = "pfeiler"
"1/1/132" = "pfeiler"

[[processors.enum.mapping]]
tags = ["groupaddress"]
dest = "category"
[processors.enum.mapping.value_mappings]

"1/1/120" = "toggle" light Esszimmer_Decke_
"1/1/122" = "state" #light_state Esszimmer_Decke
"1/1/128" = "dim" #light_brightness Esszimmer_Kamin
"1/1/130" = "toggle" light Esszimmer_Pfeiler_
"1/1/132" = "state" #light_state Esszimmer_Pfeiler
"1/1/133" = "dim" #light_brightness Esszimmer_Pfeiler


[[processors.enum.mapping]]
tags = ["groupaddress"]
dest = "full_name"
[processors.enum.mapping.value_mappings]
"1/1/120" = "Esszimmer_Licht_Decke_AnAus"
"1/1/122" = "Esszimmer_Licht_Decke_Status"

Und diesen Part würde ich persönlich auslagern bzw über lookup lösen weil du dann unter "1/1/120" einfach alle Tags eintragen kannst die du hinzufügen willst.
Durch enum.mapping muss ich jedesmal auf die GA bezug nehmen was schwieriger zu warten ist weil du musst erstmal im Code an jeder Stelle "1/1/120" suchen und es dann an allen Stellen ändern.


regex.tags ergibt Sinn weil du dadurch gleich für mehrere GAs die sich auf etwas bestimmtes beziehen weil HG11 immer die Küche ist beispielsweise das Ganze nur an einer Stelle setzen kannst und nicht für jede GA es einzelnt zuweisen müsstest.


Ob man wirklich alle vergebenen Tags tatsächlich benötigt muss man selbst entscheiden. Performancetechnisch kostet dich jedes Tag etwas performance bzw genauer gesagt Cardinality ist hier das Stichwort.
Wenn du eh nie suchst/filterst über ein bestimmtes Tag ist es erstmal unnützer Ballast. Aber es kommt drauf an:
Wenn TagA=x und TagB=y sowieso immer nur zusammen auftauchen wächst die Cardinality dadurch nicht. Wenn sie sich aber unterscheiden dann schon. Und wenn du dann nie damit filterst ist halt überflüssig. Soweit die Theorie. Ob diese Performance Penalty überzeugt spürbar ist bei der Menge an Daten kann ich nicht beurteilen.

Ich persönlich schreibe ohnehin nicht alles mit sondern grob nur Statuswerte.
"schalten ein/aus" GA interessiert mich zB nicht.

Man kann die verschiedenen verfahren natürlich auch Kombinieren. Lookup ergibt Sinn wenn man sehr individuell Tags vergeben will.
regex ergibt mehr Sinn wenn bestimmte Bereiche perse dasselbe Tag bekommen sollen. zB 11/x/y immer das Schlafzimmer ist.


Im Idealfall kommen die Tags die am wichtigsten sind, also nach denen man hauptsächlich filtert, ganz nach vorne (aufs Line Protocoll bezogen) und dann in absteigender Reihenfolge.Das habe ich aber noch nicht rausgefunden wie man darauf Einfluss nehmen kann.


Leider ist der KNX.Listener sehr basic. Ich würde es begrüßen wenn man die Zuordnung GA=>Measurement direkt durch eine externes File machen könnte oder ich alternativ im KNX.Listener schon individuelle weitere Tags vergeben könnte sodass ich die GA nur an einer Stelle im Code habe. Das stört mich am meisten, ich will die GA nur an EINER Stelle im Code eingetragen haben sodass ich bei Verschiebung auch nur dort an einer Stelle sie ändern brauche...
Mit lookup kann ich es immerhin schon auf 2 Stellen begrenzen.

[DJ.Picasso]

Nun ja bei dieser Integration gibt es ohnehin immer nur ein Field pro measurement. Das sollte man auch so lassen weil das sonst Performance kostet.

Wieso? Du kannst doch auch mehrere Fields definieren und bei einer Time Series DB ist das doch Peanuts, die kann mit ganz anderen Dingen umgehen bis sich wirklich mal ein Performance Problem einstellt. Ich mache aus den vielleicht ca. 3.000 bis 4.000 lines, die ich täglich zum Licht speichere über aggregationWindow in Flux ungefähr 130.000 täglich - wie gesagt nur für Licht. Alles in Allem werden aus meinen Daten dadurch über 500.000 Datensätze jeden Tag.
Für eine Time Series doch Kleinkram. Das ist ja gerade das coole an einer derartigen Datenbank und ob Du einfach mal 100.000 oder 200.000 Daten mehr oder weniger hast, vollkommen egal! So eine DB ist auf echte Größenordnungen ausgelegt.

Und über fill(usePrevious: true) kannst Du dann relativ einfach in Flux die leeren Daten auffüllen, EASY!

Einen Temperaturwert und einen Feuchtigkeitswert vom selben KNX Teilnehmer kann man ja nicht zur exakt selben Zeit bekommen

Brauchst Du doch auch nicht, wofür?

Wenn Du die Daten zusammenfügen willst, dann lässt Du einfach vorher entweder ein aggregationWindow in Flux drüberlaufen oder Du machst einen timeShift und das Thema ist erledigt. Dafür hast Du doch Flux und das ist doch der Vorteil im Gegensatz zu SQL oder NoSQL!
Bei Flux hast Du ein "Query + Process + Act".

Und diesen Part würde ich persönlich auslagern bzw über lookup lösen

Muss ich mir mal ansehen, aber aktuell habe ich erst einmal diese Struktur und werde sie erst einmal weiterbehalten. Die Erweiterungen werden sich in Grenzen halten, daher wird die knx_listener mehr oder weniger statisch sein!

Ob man wirklich alle vergebenen Tags tatsächlich benötigt muss man selbst entscheiden. Performancetechnisch kostet dich jedes Tag etwas performance bzw genauer gesagt

Für das was ich vorhabe, YEP, da brauche ich es! Wenn ich so etwas mache, dann schon mit entsprechendem Konzept. Ich fange nicht einfach an und schau mal was dann kommt! .. Das tun nur die, die blauäugig an die Sache rangehen und keine strukturierte Vorgehensweise kennen bzw. neudeutsch nennt man das auch AGIL

Und wie gesagt, Performance ist Peanuts bei den Kleinigkeiten. Wenn man Transaktionssysteme gewohnt ist, die hunderte von Millionen Datensätze pro Tag erzeugen, da muss man sich über Performance Gedanken machen, nicht hier!

Im Idealfall kommen die Tags die am wichtigsten sind, also nach denen man hauptsächlich filtert, ganz nach vorne (aufs Line Protocoll bezogen) und dann in absteigender Reihenfolge.Das habe ich aber noch nicht rausgefunden wie man darauf Einfluss nehmen kann.

Das ist doch vollkommen egal. Wofür soll die Reihenfolge der tags notwendig sein? Ich weiß auch nicht, ob Du es überhaupt beeinflussen kannst. Wenn Du Telegraf stoppst und wieder startest, ändert sich jedesmal die Reihenfolge.
Wie gesagt, spielt aus meiner Sicht in influxdb auch keine Rolle und wenn Du die tags mit Flux filterst bekommst Du sowieso wieder eine andere Reihenfolge Deiner Tabellen. Würde ich mir keinen Kopf machen.

Leider ist der KNX.Listener sehr basic.
...ich will die GA nur an EINER Stelle im Code eingetragen haben sodass ich bei Verschiebung auch nur dort an einer Stelle sie ändern brauche...
Mit lookup kann ich es immerhin schon auf 2 Stellen begrenzen.

Das ist ehrlich gesagt für mich eher vollkommen nebensächlich. Mir geht es lediglich darum, meinen KNX Bus zu monitoren und alles mitzuschreiben, was auf dem Bus passiert. Alles Wichtige kommt erst im Anschluss! Dann mache ich es wie Pippilotta: "Ich mach mir die Welt, wie sie mir gefällt"
Für mich ist lediglich wichtig, dass ich die Daten dann in influxdb identifizieren kann und mit Flux dann weiterverarbeiten und vor allem vollständig umorganisieren kann.

Beim KNX Listener hätte mich eher eine andere Sache interessiert.
Ich habe versucht meine input_knx_listener.conf auf mehrere conf-Dateien aufzusplitten aber da hat mir das System kontinuierlich Fehler aufgezeigt. Nachdem ich einige Sachen versucht habe, hatte ich "Keinen Bock" mehr mich damit zu beschäftigen und habe das Thema Ad-Acta gelegt.
Bei anderen Listener oder API ist die Trennung der conf Dateien kein Problem. Der knx_listener - wie gesagt - wollte nicht so wie ich wollte.

[ewfwd]

Das ist doch vollkommen egal. Wofür soll die Reihenfolge der tags notwendig sein? Ich weiß auch nicht, ob Du es überhaupt beeinflussen kannst. Wenn Du Telegraf stoppst und wieder startest, ändert sich jedesmal die Reihenfolge.
Wie gesagt, spielt aus meiner Sicht in influxdb auch keine Rolle und wenn Du die tags mit Flux filterst bekommst Du sowieso wieder eine andere Reihenfolge Deiner Tabellen. Würde ich mir keinen Kopf machen.

Das ist ne Info die du auf der Seite von Influx direkt so nachlesen kannst. Vermutlich weil beim Lesen dann nur bis zu diesem Punkt gelesen werden muss. Wenn das Tag weiter vorne steht muss ich weniger Lesen als wenn es erst an Stelle 10 steht. Ich spreche nicht davon was wie angezeigt wird sondern wie die Daten in der Datenbank angeordet sind in der Tabelle.
Sobald der erste Eintrag geschrieben ist für das Measurement ist die Reihenfolge gesetzt und kann auch nicht mehr geändert werden. Wenn du Dinge ergänzt werden die folglich hinten angehängt und wenn du die "alten" Dinge nicht mehr brauchst werden nicht alle bestehenden Daten neu geschrieben sondern es wird einfach aufgefüllt mit NULL Werten. Es liegt auf der Hand das dies am Ende Performance kostet wenn du lauter "Lücken" in der Datenbank hast, das sind Daten die gelesen werden müssen und dann am Ende verworfen werden...
Kurzum die wichtigsten Tags, die die man am häufigsten benutzt beim Query stehen besser weiter vorne.Wenn ich zB einen Gaszähler habe, nur einen und ich speichere die Zählernummer mit ab als Tag, werde ich bei nur einem Gaszähler vermutlich nie nach der Zählernummer filtern. Wenn ich 10.000 verschiedene in der Datenbank habe dann mag es genau umgekehrt sein. Aus theoretischer Betrachtung zumindest.

Und über fill(usePrevious: true) kannst Du dann relativ einfach in Flux die leeren Daten auffüllen, EASY!

Sicher, aber das ist ja nun etwas anders. Ich rede davon wie die Daten auf dem Datenträger halt abgelegt sind. Das Auffüllen ist ja nicht das Problem sondern dass du dennoch die ganzen NULL Werte erstmal trotzdem mitlesen musst. Platzverschwendung könnte nen weiterer Aspekt sein aber da bin ich nicht so drin und ist in unserem Fall hier eher weniger wichtig.

Wieso? Du kannst doch auch mehrere Fields definieren und bei einer Time Series DB ist das doch Peanuts, die kann mit ganz anderen Dingen umgehen bis sich wirklich mal ein Performance Problem einstellt.

Es bezieht sich auf KNX. Wenn KNX 2 Temp werte auf den Bus sendet kommen diese zu unterschiedlichen Zeiten auf den Bus. Ergo haben sie in der Datenbank auch erstmal 2 unterschiedliche Timestamps. Es werden also 2 Einträge erzeugt auch wenn du dasgleiche Measurement benutzt.
Du hast ja keine sinnvollen Daten die du in weitere Fields reinpacken kannst. Das einzige was Sinn ergeben würde wäre zB ein Statuswert RGBW und man teilt die Kanäle gleich auf verschiedene Fields auf. Das kann die Integration so aber nicht.

Wenn 2 Fields bei einem Measurement definierst aber nur Daten pro Zeitstempel bekommst um ein Field zu füllen wird das andere Field mit NULL beschrieben. Da macht es mehr Sinn dann besser ein eigenes Measurement herzunehmen.

Wenn Du die Daten zusammenfügen willst, dann lässt Du einfach vorher entweder ein aggregationWindow in Flux drüberlaufen oder Du machst einen timeShift und das Thema ist erledigt. Dafür hast Du doch Flux und das ist doch der Vorteil im Gegensatz zu SQL oder NoSQL!
Bei Flux hast Du ein "Query + Process + Act".

Das kannst du machen aber es ändert ja trotzdem nichts an den bestehenden Daten in der Datenbank.

Wenn du bei einem Measurement mehrere Fields definierst (sobald die ersten Daten geschrieben werden) dann solltest du auch immer alle Fields beschreiben.
Was zB falsch ist wäre 3 Spannungen zu haben U1, U2, U3 die aber zu verschiedenen Zeiten reinkommen. Und du fängst dann an U1,U2,U3 auf 3 verschiedene Fields aufzuteilen und hast jedesmal für 2 Fields keine Daten zum reinschreiben. dann schreibt Influx folglich die beiden Fields mit NULL. Wenn U1 an erster Stelle steht dann bleibt es da halt. Influx wird nicht wenn du nur Daten für U2 hast auf einmal U2 an die Stelle schreiben vor zuletzt noch U1 war. Dann wird eben U1=NULL,U2=230,U3=NULL geschrieben.

Da die Daten pro measurement aber immer an der gleichen Stelle in der Datenbank abgespeichert werden müssen kann es nicht anders sein. Die Reihenfolge muss sich also durchziehen und kann nicht bei jedem Schreibvorgang aufs Measurement anders sein.


Du kannst natürlich später mit einem Query und aggregat die Durchschnittswerte pro Minute jeweils nehmen und dann unter einem neuen Measurement abspeichern, dann hast du ja jedesmal Daten für alle 3 Fields...



[[inputs.knx_listener.measurement]]

sollte sich in verschiedene confs packen lassen.Dadurch dass ich processors und den ganzen Rest aber nun ausgelagert habe ist die inputs.knx.conf bei mir aber eh überschaubar. Die Doppelten Klammern bedeuten eigentlich dass diese Dinge mehrfach definiert werden können. Aber nicht unter etc/telegraf. Die telegraf.conf kann einen leeren Inhalt haben und man erzeugt sich dann mehere conf Dateien in dem Unterverzeichnis telegraf.d. Oder man packt in telegraf.conf die Globalen Dinge rein und packt den Rest in conf Dateien unterhalb von telegraf.d.

in meiner telegraf.conf befindet sich aktuell nur [agent]

Der ganze Rest ist getrennt im Ordner telegraf.d

Wer mit Platzhaltern wie token = "${INFLUX_TOKEN}" arbeiten will der muss wissen dass diese Variablen in /etc/default/telegraf definiert werden.
Hatte Anfangs fälschlicherweise angenommen man kann das einfach in einer conf Datei setzen telegraf Ordner. Das geht nicht

Muss ich mir mal ansehen, aber aktuell habe ich erst einmal diese Struktur und werde sie erst einmal weiterbehalten. Die Erweiterungen werden sich in Grenzen halten, daher wird die knx_listener mehr oder weniger statisch sein!

Wenns läuft gibt es ja kein Grund es zu ändern. Ich habe bei mir etwas erweitert und bin über das hier angesprochene gestoßen weil enum.mapping schnell zu einem Krampf wird in meinen Augen wenn ich mehrere Tags bei bestimmten GAs ergänzen will. Wenn du nur ein Tag ergänzen willst geht das noch. Bei mehreren hat lookup Vorteile was die Übersichtlichkeit angeht und auch der Ergänzung.

[DJ.Picasso]

Ich vergaß zu erwähnen, ich sammle meine Daten nur in einem Bucket, strukturiere sie dann um reichere sie an und schiebe diese Daten dann in einen anderen Bucket.

Wenn du bei einem Measurement mehrere Fields definierst (sobald die ersten Daten geschrieben werden) dann solltest du auch immer alle Fields beschreiben.
Was zB falsch ist wäre 3 Spannungen zu haben U1, U2, U3 die aber zu verschiedenen Zeiten reinkommen. Und du fängst dann an U1,U2,U3 auf 3 verschiedene Fields aufzuteilen und hast jedesmal für 2 Fields keine Daten zum reinschreiben. dann schreibt Influx folglich die beiden Fields mit NULL. Wenn U1 an erster Stelle steht dann bleibt es da halt. Influx wird nicht wenn du nur Daten für U2 hast auf einmal U2 an die Stelle schreiben vor zuletzt noch U1 war. Dann wird eben U1=NULL,U2=230,U3=NULL geschrieben.

OK, das ist mir bewußt. Daher habe ich auch lediglich 1 field, dass entsprechend gefüllt ist. In Deinem Beispiel würde ich auch nur 1 field schreiben (für U1, U2, U3).
Dann hast Du das von Dir beschriebene Problem nicht!




Zu den conf-Dateien:
In meiner telegraf.conf habe ich auch nur die wesentlichen Dinge. Alles weitere liegt in telegraf.d
Aber wie gesagt, hier habe ich eine Reihe unterschiedlicher confs, die auch teilweise wiederum getrennt sind. Lediglich bei der knx_listener conf habe ich es nicht ans Laufen bekommen. Daher alles in einer Datei. Funzt auch, ist etwas gewöhnungsbedürftig ... gibt schlimmeres!

Hast Du mal ein Beispiel, wie Deine verschiedenen knx.confs aussehen. Hast Du die entsprechend nummeriert, damit die Reihenfolge sichergestellt ist?