Telegramme mit falscher physikalischer Adresse

[gbglace]

Na ist ja gut, dass das SW-Projekt da lebt.

[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

[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.

[gbglace]

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

[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]

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

[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.

[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

[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.

[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]

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]

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]

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]

Okay, das hilft mir schonmal weiter.

[Klaus Gütter]

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