[Gelöst] [V4.5] Read Telegramme werden nicht beantwortet

[Hauke]

Hallo,

ich habe in der Knowledge Base (insbesondere hier: app.php/kb/viewarticle?a=122) leider nicht die Lösung gefunden, vielleicht kann ja jemand weiterhelfen.

Ich möchte Read-Telegramme der Visu vom Timberwolf beantworten lassen. Der Wert dazu kommt aus einer Logik.
- KNX-Objekt mit K|L|Ü-Flags ist eingerichtet
- KNX-Objekt ist mit Ausgang der Logik verknüpft
- Persistenz in der Logik ist gesetzt

Ich dachte damit wäre alles getan, aber die Read-Telegramme die ich testweise über die ETS absetze werden nicht beantwortet.

Kann mir jemand sagen was ich falsch mache?

Gruß, Hauke

[gbglace]

Gab es denn schonmal einen regulären Output aus dem KO als normales GroupValue Write Telegramm?

Mindestens wenn es das schon gegeben hat, sollte der TWS auch mit aktivem L Flag eine quasi Wiederholung als GrouValue Respond schicken, wenn mit einer an dem KO verbundenen GA ein GroupReadRequest Telegramm ankommt.

Sind mehrere GA an dem KO angebunden und die GA mit der Du in der ETS den readrequest absendest ist auch die GA die als erste an dem TWS-Ko angebunden ist?, sonst antwortet der TWs auf einer anderen GA.

Insofern Screenshot der KO Ansicht der ETS mit allen Spalten Flags und verbundenen GA. und Screenshot Busmonitor/Gruppenmonitor mit allen Telegrammen aus dem Zeitfenster mit allen Spalten in voller breite ohne xxx... Und nach Zeitstempel sortiert.

Alles andere dauert erstmal zu lange in der Diagnose, um grundsätzliche Sachverhalte ausschließen zu können.

[Hauke]

Vielen Dank für die schnelle Unterstützung!

ich wollte eigentlich den Screenshot aus der Objektverwaltung im TWS angehangen haben, hat aber irgendwie nicht geklappt... Es ist nur eine GA an das KO angebunden.

Der hilfreiche Tipp war vermutlich das der TWS auf diesem Objekt schon mal ein Write Telegramm gesendet haben muss. Ich habe zu gestern nichts weiter geändert, bekomme aber heute eine korrekte Response Antwort vom TWS.

[StefanW]

Hu Hauke,

der KNX Stack im Timberwolf Server beantwortet Read-Requests aus dem Cache seiner Objekte. Es führt also zu keiner Anfrage nach intern, aktuelle Werte zu "besorgen", weil das vom Systemdesign her schwierig wäre. Man stelle ich vor, das KNX-Objekt ist über den Dispatcher mit einem 1-Wire verknüpft, der - kraft Einstellung - nur alle 24 Stunden abgefragt wird. Dann müsste eine Weiterleitung der Abfrage zu einer Neuabfrage des 1-Wire Wertes führen. Das könnte schwer überschaubare Konsequenzen haben, z.B. wenn es (durch schlechte Einstellung) jede Minute zu einer solchen Abfrage kommt - und das bei 50 Werten.

Noch unübersichtlicher würde es werden, wenn das KNX Objekt mit einem Logik-Ausgang verknüpft wäre. Dann müsste in voller Konsequenz die Logik neu berechnet werden. So eine Logik kann aber am Eingang den Ausgang anderer Logiken verknüpft haben und diese Logiken erhalten Informationen von 1-Wire, Modbus und MQTT. Dann müssten eigentlich erst diese drei Werte zuerst gepollt werden (was bei MQTT gar nicht geht) und damit die vorgeschaltete Logik aktuelle berechnet werden kann um der nachfolgenden Logik aktuelle Daten zu liefern, deren Ausgang dann mit dem KNX-Objekt verknüpft ist, damit die Read-Abfrage darauf wirklich aktuell wäre. Das würde nicht nur die ganze Software viel aufwändiger gestalten, sondern auch die Benutzeroberfläche und auch alle Doku.

Chaotisch würde es werden, wenn ein KNX-Objekt mit mehreren anderen Objekten verknüpft ist. Dann wäre die Frage, an welches müsste man den Read weiterleiten und in welcher Reihenfolge?

Darum geht das nur mit der Lösung solche Read-Requests aus dem Objektcache des KNX-Stacks zu beantworten, wozu dieser wenigstens einmal seit Start gefüllt sein muss.

Ich weiß, DU hast das jetzt nicht gefragt oder kritisiert, aber für alle Mitlesenden, weil in der Vergangenheit immer mal wieder die Frage aufkam "warum geht der REad-Request nicht ins System weiter". Weil das was Forward gut funktioniert, Backwards sehr schwierig wäre, auch für den Einrichter.

lg

Stefan