telegraf schreibt nicht alle Messwerte weg

[DAZ]

Guten Abend zusammen,

als ich heute Abend durch Grafana stöberte fiel mir auf, dass ich sehr unregelmäßig Messwerte bekomme. Siehe zB Anhang. Eigentlich soll im vorliegenden Fall jede Minute ein Datenpunkt kommen. Schnell im ETS überprüft... Ja, der Sensor liefert die Messwerte minütlich zurück. Da liegt das Problem nicht.

Influx2 und Grafana kann ich auch ausschließen. Ich habe im telegraf im Debug Modus laufen lassen. Die Nachrichten, die er in log als gesehen schreibt, sind auch alle in der influx2 DB zu finden, aber es fehlen halt super viele Nachrichten.

Kennt jemand das Problem? Hat telegraf vielleicht ein Rate Limiting?

telegraf läuft im Docker Container. IP Gateway ist MDT.

Grüße
Alex

Bildschirmfoto 2022-08-15 um 22.08.29.png

[gbglace]

Eigentlich soll im vorliegenden Fall jede Minute ein Datenpunkt kommen. Schnell im ETS überprüft... Ja, der Sensor liefert die Messwerte minütlich zurück. Da liegt das Problem nicht.

womöglich schon, weil wenn Du sehr viel von solchen Telegrammschleudern gebaut hast ist ggf. einfach zu viel los an Telegrammverkehr auf dem Bus und dann kommt nicht alles durch den Tunnel der Schnittstelle. Da gibt es auch Telegrammratenbegrenzungen.

[meti]

Telegrammratenbegrenzungen bei IP? Davon hätt ich noch nix gehört. Auf jeden Fall nix unter der möglichen Rate von TP. Und in ETS sieht er die Telegramme ja.

DAZ benutzt du Routing oder Tunnelling für die Verbindung?

[gbglace]

Wo steht das er die Telegramme im ETS Busmonitor gesehen hat?

Er hat womöglich auch einfach nur in die Parameter des Gerätes geschaut und gesehen ja steht auf zyklisch senden.

Insofern kann der Bus immer noch einfach zugemüllt sein.

Und ja IP ist schnell aber das Interface kann nur x Telegramme die Sekunde durch reichen, egal in welche Richtung.

[DAZ]

Das IP Interface kann ich nun auch ausschließen. Hier liegt keine Limitierung (aktuell) vor. Ich habe parallel zu telegraf mit xknx auch mal die Daten auf dem Server gemonitort. Siehe Anhang.

telegraf (Fenster unten rechts) sieht back-to-back 7/3/91 und dann 7/2/151. In der Zwischenzeit hat xknx mal locker 40 Telegrame mehr gesehen (oberes Fenster). Ich mache mal ein Issue bei telegraf auf.

Grüße
Alex
Bildschirmfoto 2022-08-16 um 08.07.41.png

[DAZ]

gbglace Ja du hast Recht. Mein Text war nicht sauber geschrieben. Ich habe die Telegramme im ETS Busmonitor gesehen.

Aber davon abgesehen, werde ich ich wohl auch die Frequenz mal unterstellen. Alle 2 Minuten einen Messwert für Temp / CO2 uws. reicht wohl auch locker aus

[gbglace]

Ja ich denke die normale Raumtemperatur wird sich so schnell nicht ändern. So einen VOC Sensor in der WC Ecke kann ich ja noch mit kurzem Zyklus oder halt relativer Änderung verstehen.

[meti]

xknx is halt schnell 🏎 das musst in Go erst mal nachmachen 🤣

Bis das gefixt ist könntest du natürlich auch schnell ein kleines Script schreiben mit dem du über aiohttp das von xknx empfangene Telegram an influx weiterleitest. Und das dann im xknx Repo als example Script veröffentlichen (oder eigenes Projekt). Freuen sich sicher n paar Leute drüber.
Oder über Home Assistant gehen, aber das wär mit Kanonen auf Spatzen... 🐥

[DAZ]

Der Autor von knx-go ist eigentlich ziemlich flott unterwegs. Ich hatte letztes Jahr bereits etwas Code (diverse DPTs) beigesteuert. Der Pull Request war schnell durch.

Wenn ich tippen müsste, würde ich auch nicht auf KNX-go wetten sondern auf telegraf direkt. In der Config gibt es die Einstellung

...
  # Configuration for telegraf agent
  [agent]
    ## Default data collection interval for all inputs
    interval = "1s"
...

Ich habe schon etwas mit dem Wert rumgespielt. Dies hat aber kein Einfluss. Sollte es ja auch IMO nicht haben, da es ja das Polling Interval betrifft. Im vorliegenden Fall, wird aber ja gar nicht gepollt.

Ich schaue mir heute Abend nochmals den GO Code an. An irgendeiner Stelle müssen die Telegramme ja gebuffert werden.

[meti]

Eigentlich müsste Telegraf mit weit mehr Datenmenge umgehen können als von Knx(TP) überhaupt kommen können.
Wie du schon geschrieben hast, der interval bezieht sich auf polling, was hier nicht der Fall ist.
Vielleicht kannst du ja den log-Level von Knx-Go auf Debug setzten.
Ach ja: Routing oder Tunnelling? xknx macht per default Tunnelling. Wenn Knx-Go auf Routing konfiguriert ist könnte es ein einfaches Filtertabellen-Problem sein.

PS: Ich bin Maintainer von xknx, daher die Freude darüber dass es jemand zum Debuggen von anderen libs verwendet und der Anstoß für das Script 😉

[DAZ]

meti LOL. Das wusste ich nicht ;-) Dann hast du mir schon einmal auf anderem Wege (Discord) geholfen. Auf jeden Fall super Arbeit! Danke dafür.

Routing oder Tunnelling? Guter Punkt. Bis jetzt ich knx-go als UDP Unicast Tunnel konfiguriert. Bei xknx habe ich euer Monitor Beispiel 1:1 übernommen. Du meintest oben das xknx Tunnel per default nutzt. Das Bespiel-Script von euch macht doch Multicast auf 224.0.23.12:3671 oder sehe ich das falsch?

[meti]

Das benutzt unser Auto-Discovery, was der default ist wenn keine `ConnectionConfig` übergeben wird. Und das verbindet über einen Tunnel - wenn es kann. Und zwar TCP > UDP > Routing
Der Discovery-Prozess läuft über Multicast.

[DAZ]

Ok, danke. Gerade überprüft: xknx baut ein TCP Tunnel auf, knx-go einen UDP. Leider kann ich knx-go nicht auf TCP forcen. Ich mache jetzt mal ein Issue auf Github auf. Gestern Abend war ich dazu nicht mehr wirklich motiviert ;-)

[meti]

Mhm. Knx-Go unterstützt kein TCP (zumindest laut meiner 1-Minuten Recherche - Go ist nicht meine Welt...) aber das sollte egal sein. Ein Tunnel ist ein Tunnel, das Protokoll spielt für die übertragenen Telegramme keine Rolle.
Ist nur bei Routing ne andere Geschichte.

[DAZ]

Jo, klar. Das fehlende Congestion Control von UDP sollte bei mir im LAN ja keine Rolle spielen. Ich melde mich hier zurück, wenn ich mehr weiß.