Telegramme mit falscher physikalischer Adresse

[ewfwd]

Hallo, ich habe hier einen X1 als IP Interface. Zu diesem Gerät gibt es 2 Tunnel Verbindungen. Einmal Home Assistant mit 1.1.5 und einmal InfluxDB/Telegraf, genauer Adresse da weiß ich nicht, es hört aber eh nur mit.
Telegraf logt zB meine Wind und Regenalarme. Die Geräte haben jeweils die PA 1.1.50 und 1.1.51. Das wird auch alles korrekt in InfluxDB mitgeschrieben auch mit der korrekten PA.

Wenn ich Home Assistant allerdings neustarte liest es die Sensorwerte vom Bus. HA will ebenfalls Regenarlam und Windalarm wissen. In der ETS sehe ich auch "GroupValue_Read" jeweils mit der korrekten HomeAssistant Physikalischen Adresse und auch die Sensoren antworten mit GroupValue_Response, ebenfalls mit jeweils ihrer PA.

In InfluxDB sieht das ganze aber nun anders aus. Hier empfange ich ebenfalls diese Alarme allerdings haben sie jetzt ein falsche PA nämlich die 1.1.5, die PA die eigentlich Home Assistant hat.

Gibt es hierfür eine logische Erklärung wieso hier die PA vom Tunnel genommen wird und nicht die vom eigentlichen Sensor?

Mein KNX Verständnis ist so dass wenn ich irgendwelche Werte lese ich an jedem Tunnel als Quelladresse doch eben die PA vom Sensor selbst sehen müsste und nicht die PA von einem anderen Tunnel. Oder ist das ein gewolltes Verhalten?

Wenn ich mich gleichzeitig mit der ETS verbinde zum X1 und dort den Status Abfrage der entsprechenden Gruppenadresse sehe ich in InfluxDB die PA des Tunnels mit der meine ETS grad verbunden ist...

Fehler in InfluxDB/Telegraf oder gibt es dafür eine andere Erklärung?

edit:

Problem sollte mit Telegraf ab v1.30.1 nicht mehr auftreten

[ewfwd]

Mit der kommenden Telegraf Version v1.30.1 am 1. April werden die read Telegramme nun ausgefiltert.

auch der automatische reconnect bei verbindungsverlust sollte dort mit drin sein

[Klaus Gütter]

Klingt tatsächlich so, als ob dein Telegraf fälschlicherweise das GroupValue_Read auswertet.

[ewfwd]

Okay, das hilft mir schonmal weiter.

[gbglace]

Loggt dann der Telegraf auch das Respond Telegramm?

Aber es scheint sehr wahrscheinlich, das Telegraf einfach alles mitlogt, was grundsätzlich nicht sinnlos ist, man müsste dann nur die Telegrammtypkennung mit als Attribut wegspeichern. Dann hast erstamal ein kompletttes Buslog aber wenn es um die effektiven Befehle und Status geht gehören die dann ausgefiltert.

[ewfwd]

Jap. Das GroupValue_Response wird wohl auch mitgelogt und hat dann auch die richtige Adresse. Witzerweise macht er das nur bei DPT1.005 (andere 1-Bit DPTs habe ich bislang nicht getestet). Bei 8Bit Werten und allen anderen DPTs die ich benutze kann ich keine Tunnel Adresse finden bei irgendwelchen mitgeloggten Daten.

In meinen Augen macht das so aber kein Sinn und scheint tatsächlich ein Bug zu sein

[gbglace]

Die PA ist schon richtig, er loggt halt nur auch die "falsche" Sorte Telegramme.

Das es sich dann aber je DPT wieder inkonsistent verhält ist eher was mich stören würde.

[ewfwd]

Allerdings sind GroupValue_Read Nachrichten ja auch immer 0. Es macht kein Sinn diese zu loggen wenn man nur an den Werten interesiert ist
Wenn mein Alarm grad 1 ist habe ich wenn ich nicht grad die quelladdresse rausfiltere auch eine Statusänderung von 1 nach 0 und dann wieder zu 1

Klingt tatsächlich so, als ob dein Telegraf fälschlicherweise das GroupValue_Read auswertet.

Zusätzlich scheint es das zu tun. Es loggt die richtigen Werte ja schon auch mit.

[gbglace]

Wie ich schon sagte der logt halt wohl alles an Telegrammen bis auf die echten Systemtelegramme wie ein ACK. Ich denke da fehlt dem Ding einfach noch die Interpretation der Telegrammtypen. Das eben der Readrequest selbst ignoriert wird. Oder rkann man da Custom Filter definieren dann eben selber diesen Telegrammtyp wegfilrern.

[Beleuchtfix]

Ich habe das Problem so verstanden, dass HASS auf den Read Request antwortet, ob das Aufzeichnen sinnvoll ist, ist eine fanz andre Sache.
Gruß Florian

[ewfwd]

Hass spielt eigentlich nur in sofern eine Rolle wie dass es bei Neustart eben read Telegramme aussendet um die Statuswerte abzufragen. Grundsätzlich ist es aber egal ob Hass nun das tut oder ich es manuell über die ets anstoße.
merkwürdig ist nur dass es nur bei 1bit dpt 1.005 auftritt. Werde mal andere 1bit dpts testen

ein read telegram hat ja keine payload. In sofern ist die Frage was man da überhaupt loggen will. Die „0“ die er in die Datenbank schreibt ist ja so gesehen schon falsch.

[gbglace]

Wie gesagt wenn das Ready als solches Merkmal dabei steht hat man in der DB ein vollständiges Buslog.

[ewfwd]

Nop das steht nicht dabei. Es ist in der Datenbank nicht zu unterscheiden welche Telegramart auf KNX Seite es war. Wenn ich zB manuell in der ETS auf den Bus schreibe wäre der Datenbankeintrag exakt identisch. Er bekäme dann ebenfalls die PA des Tunnels der ETS

Daher halte ich das auch für falsch Read Telegramme zu loggen einfach weil es da keine Payload gibt.

[gbglace]

Ja das ist dann eine unsaubere Implementierung in dem KNX Adapter vom Telegraf. Wohin auch immer man das ändert.

[ewfwd]

Dass es nur bei 1Bit DPTs verarbeitet wird liegt daran dass das Script alle anderen Telegramme nicht verarbeiten kann weil es zum Fehler kommt bei der Datenverarbeitung weil diese Telegramme eine andere Länge haben.
Die "Idee" war wohl wirklich auch die Read Telegramme mitzuloggen...
naja ggf ergibt das für eine andere Anwendung ja Sinn. Für eine Datenbank aber eher weniger.

[ewfwd]

Mit der kommenden Telegraf Version v1.30.1 am 1. April werden die read Telegramme nun ausgefiltert.

auch der automatische reconnect bei verbindungsverlust sollte dort mit drin sein