Warnung: "Giving up reading datapoint x/x/x, the number of maximum retries (3)..."

[palKNX]

Hallo Zusammen,


ich versuche aktuell meine Warnungen aus dem Log zu entfernen. Allerdings ist eine Warnung sehr hartnäckig, und ich komme nicht so recht weiter. Ich hatte erst die KNX-Datentypen im Verdacht, daran lag es aber nicht.
Die Warnung ist mir bei einigen Fensterkontakten und Temperaturen aufgefallen. Die Warnungen lauten:

[SIZE=12px][FONT=courier new]2019-01-08 19:47:36.862 [WARN ] [nx.internal.client.AbstractKNXClient] - Giving up reading datapoint 2/3/13, the number of maximum retries (3) is reached.
Type contact        : Fenst_EG_Essz_re            "Window"        [ ga="1.019:<2/3/13" ]

2019-01-08 19:48:07.083 [WARN ] [nx.internal.client.AbstractKNXClient] - Giving up reading datapoint 2/5/16, the number of maximum retries (3) is reached.
Type number            : Temp_EG_Essz_Ist            "Temperature"    [ ga="9.001:<2/5/16" ][/FONT][/SIZE]

Kennt jemand die Warnungen? Wie bekomme ich diese beseitigt?

Zur Info hänge ich noch die entsprechenden Items und Things an.

Things

[SIZE=12px][FONT=courier new]Bridge knx:ip:bridge [
    ipAddress="192.168.178.28",
    portNumber=3671,
    localIp="192.168.178.32",
    type="TUNNEL",
    readingPause=50,
    responseTimeout=10,
    readRetriesLimit=3,
    autoReconnectPeriod=1,
    localSourceAddr="0.0.0"
] {
    Thing device generic [
        readInterval=0
    ] {
Type contact        : Fenst_EG_Essz_re            "Window"        [ ga="1.019:<2/3/13" ]
Type number            : Temp_EG_Essz_Ist            "Temperature"    [ ga="9.001:<2/5/16" ]
}
}[/FONT][/SIZE]

Items

[SIZE=12px][FONT=courier new]Contact            Fenst_EG_Essz_re        "Fenster Essz [%s]"        <window>            (gFenster)                        { channel="knx:device:bridge:generic:Fenst_EG_Essz_re" }
Number            Temp_EG_Essz_Ist           "Ist- Temp. [%.1f °C]"    <temperature_cold>    (gAVGTempIst)                    { channel="knx:device:bridge:generic:Temp_EG_Essz_Ist" }[/FONT][/SIZE]

[udo1toni]

Bist Du sicher, dass die beiden GA auf Read Requests antworten, also, dass ein Device im passenden KO das L-Flag gesetzt hat und in diesem KO die GA als 1. GA angegeben ist? Bist Du sicher, was die DPT betrifft? Im Zweifel könntest Du die DPT zum Testen auch weg lassen.

[palKNX]

Bist Du sicher, dass die beiden GA auf Read Requests antworten, also, dass ein Device im passenden KO das L-Flag gesetzt hat und in diesem KO die GA als 1. GA angegeben ist?

Beispiehaft für die GA 2/3/13 (Fenster/Tür)
Eigentlich war ich mir recht sicher, dass die DPT stimmen. Allerdings ist mir gerade aufgefallen, dass der Binäreingang auf dem Datentyp "Fenster/Tür" steht und der Aktor auf "schalten". Auch das L-Flag ist nicht gesetzt. Wo muss das L-Flag gesetzt werden? Am Sensor oder Aktor? Ich würde es jetzt am Sensor setzen...
KNX GA 2_3_13.jpg

Bei der GA 2/5/16 (Temperatur)
Hier stehen beide DPT auf "Temperatur", nur das L-Flag ist nihct gesetzt
KNX GA 2_5_16.jpg

und in diesem KO die GA als 1. GA angegeben ist?

??? Wie meinst du das?

Bist Du sicher, was die DPT betrifft? Im Zweifel könntest Du die DPT zum Testen auch weg lassen.

Habe ich jetzt noch nicht probiert? Meine Things würde ich dann doch folgendermaßen anlegen....

[SIZE=12px][FONT=courier new]Type contact : Fenst_EG_Essz_re "Window" [ ga="2/3/13" [/FONT][/SIZE]
[SIZE=12px][FONT=courier new]Type number : Temp_EG_Essz_Ist "Temperature" [ ga="2/5/16" ][/FONT][/SIZE]

Aber was mir noch durch den Kopf geht... die Ist-Temperaturen werden zyklisch an den Aktor gesendet und die Fenster-Statie ändern sich beim öffnen oder schließen. Warum muss dann das L-Flag gesetzt werden? Bei den anderen KNX-GA (wie Beleuchtung usw.) funktioniert es auch ohne das L-Flag. Liegt es tatsächlich nur am L-Flag?

[udo1toni]

Also, Deine Definition beinhaltet ein < vor der GA (GruppenAdresse), das < weist openHAB an, bei Programmstart zu versuchen, per Read Request den Status dieser GA vom Bus zu erfragen. Dies geschieht, wie gesagt nur einmal, bei Programmstart (bzw. bei Addon-Start).
Wenn openHAB keine Antwort auf den Request bekommt, versucht es den Request readRetriesLimit mal, bevor es aufgibt. Das ist die Fehlermeldung.

Grundsätzlich ist der Signalaufbau in knx folgendermaßen: Ein Schalter sendet über sein Schalt KO (KommunikationsObjekt) eine GA auf den Bus. Ein Aktor empfängt die GA auf seinem Schalt-KO und schaltet daraufhin seinen Ausgang. Gleichzeitig sendet der Aktor auf seinem Status-KO an die dort hinterlegte GA seinen neuen Status. Dieser Status wiederum wird vom Schalter empfangen und angezeigt. openHAB empfängt diesen Status ebenfalls und setzt das Item entsprechend.
Das Status KO des Aktors hat dabei das L-Flag gesetzt, denn hier ist der "echte" Status drin, jeder Busteilnehmer kann jederzeit den aktuellen Status abrufen.

Bei einem Temperatursensor wird das L-Flag entsprechend im Sensor KO gesetzt, denn dort ist der "echte" Status vorhanden

Wenn man knx (und openHAB) korrekt aufsetzt, werden sämtliche Status von Programmstart an korrekt angezeigt, ohne dass noch irgendetwas getan werden muss. Dabei spielt es keine Rolle, ob openHAB vorher lief, stundenlang aus war oder was auch immer, denn der Status jedes Channels wird bei Programmstart vom knx Bus gelesen.
Status GA sind sehr wichtig, weil Aktoren nicht ausschließlich auf das Schalt KO hören, es können Szenen zur Steuerung verwendet werden, Zwangssteuerung, Zeitsteuerung im Aktor... Deshalb ist auch das Setzen der Status GA in Wandtastern wichtig.

Man kann in den einzelnen KO eines Devices normalerweise mehrere GA hinterlegen. Dabei muss man aber beachten, dass ein Device pro KO nur eine GA zum Senden verwendet, dies ist die 1. angegebene GA. In ETS kann man die GA zur Haupt-GA oder sendenden GA erklären (ich hab grad vergessen, wie der Punkt nun heißt...), anschließend steht die GA dann als erste im KO. Kommt ein Read Request auf einem KO an, wird bei gesetztem L-Flag der aktuelle Status gesendet. Das KO kann aber nicht unterscheiden, auf welcher GA der Read Request einging, es antwortet also immer auf der 1. eingetragenen GA.

[palKNX]

Dies geschieht, wie gesagt nur einmal, bei Programmstart (bzw. bei Addon-Start).
Wenn openHAB keine Antwort auf den Request bekommt, versucht es den Request readRetriesLimit mal, bevor es aufgibt. Das ist die Fehlermeldung.

Die Warnungen kommen aber nicht nur einmal oder nach Addon-Start, sondern zyklisch. Trotz der Warnung bekomme ich aber die Temperaturen und Fenster-Stati angezeigt. Siehe Log:

[SIZE=12px][FONT=courier new]2019-01-28 19:52:44.758 [vent.ItemStateChangedEvent] - Temp_EG_Essz_Ist changed from 22.54 to 22.52[/FONT][/SIZE]

(ich hab grad vergessen, wie der Punkt nun heißt...)

Meinst du die sendende und/oder hörende GA?

Ok, ich denke ich habe es jetzt soweit verstanden. Ich werde einfach diesen beiden GA-Typen das L-Flag setzen. Das war mir bisher nicht bekannt, dass dieses gesetzt werden muss. Vielen Dank für den Hinweis.

[udo1toni]

Ich werde einfach diesen beiden GA-Typen das L-Flag setzen. Das war mir bisher nicht bekannt, dass dieses gesetzt werden muss. Vielen Dank für den Hinweis.

Nicht einfach setzen!
Das L-Flag darf nur in exakt einem KO pro GA gesetzt sein, und es muss an der richtigen Stelle gesetzt sein.
Überlege Dir, welches Device sinnvollerweise eine Frage nach dem aktuellen Status beantworten soll, dort setzt Du dann das L-Flag.
Üblicherweise sind die L-Flags von Haus aus in den Status KO gesetzt, bei meiner Installation musste ich jedenfalls nur an ein paar ausgewählten Stellen in die Flags eingreifen.

[palKNX]

Nicht einfach setzen!

Nein, natürlich nicht. Sorry, da habe ich mich falsch ausgedrückt.
Das L-Flag macht wahrscheinlich nur Sinn am Temp.-Sensor und dem Binäreingängen der Fensterkontakte.

[udo1toni]

Wie oben erwähnt, sinnvoll ist das L-Flag einmal pro GA, die einen Status hält, also nicht in den GA, die als Befehl gesendet werden.
Jeder Schaltaktor hat pro Kanal ein Status KO, welches exklusiv seinen Status senden sollte. Dort ist das L-Flag zu setzen. In einer knx Installation ist der Verzicht auf Status Rückmeldungen pro Schaltkanal keine ernstzunehmende Option.
Setzt man eine Hausautomation wie openHAB ein, so sind auch die Level Status Meldungen von Dimmern wichtig, die in einer konventionellen Installation oftmals keine Verwendung finden (z.B. MDT Glastaster können den Dimmlevel auch visualisieren), ebenso wie Positionsmeldungen von Rollläden.
Jeder Sensor sendet per Definition exklusiv eine GA, hier ist dann ebenfalls das L-Flag zu setzen.

[palKNX]

Bei den Schaltaktoren gibt es ja keine Probleme. Die Status-Objekte habe ich eigentlich auch überwiegend verwendet. Und bei den Binäreingängen und Temp.-Senoren habe ich gerade mal geschaut - hier gibt es keine Status-KO, bei welchen direkt schon das L-Flag gesetzt ist.
Siehe Binäreingang
Binäreingang.jpg

Oder die Taster mit integriertem Temp.-Sensoren
Taster mit Temp.jpg

Dort müsste ich jetzt doch einmal das L-Flag setzen? Habe ich doch richtig verstanden?

[udo1toni]

Genau, beim Binäreingang KO 1 und KO 8, Beim Taster KO 77. Vorausgesetzt natürlich, diese Devices sind die einzigen, welche auf der verknüpften GA senden dürfen.

[palKNX]

Ja, dass habe ich gestern auch so gemacht --> FUNKTIONIERT

Vielen Dank für die Hilfe