[Gelöst] PM Sperre wird sporadisch nach Read Request gesetzt

[James_T_Kirk]

Hallo,

ich habe im Haus einige BJ Mini Premium PM, die ich Nachts über eine GA sperre damit die Katze nicht ständig das Licht auslöst (wird leider erkannt, habe schon an der Empfundlichkeit diverses getestet).

Auf einigen MDT Glastastern kann die Sperre aktiviert / deaktiviert werden, zusätzlich wird der Status über eine LED angezeigt.
Jetzt kommt es sporadisch vor, das die Sperre aktiviert wird (oder besser gesagt die Freigabe deaktiviert wird). Im Busmonitor sieht man das sehr schön. Auf einen Leserequest von OH (PA 1.0.250) antworten die Glastaster mit dem Status Enable - und einer (PA 1.0.30) sendet Disable. Das führt dazu das der PM gesperrt wird und das Licht nicht mehr automatisch geht. Der "sperrende" Glastaster ist immer der selbe, ich habe mehrfach die Parameter in der ETS geprüft und diese sind gleich wie die anderen. Der TWS ist hier nicht involviert.



Woran kann das liegen?
Eine Status GA würde vermutlich helfen, ich wollte hierfür aber nicht extra einen Schaltaktor Kanal belegen. Neben dem TWS hätte ich auch ein MDT Logikmodul zur Verfügung.

[gbglace]

Ist oder war da mal irgendetwas an Logiken in den GT programmiert? Und sind in der ETS alle Häkchen grün bei dem GT?
Und es gibt auch kein zweites Gerät was irgendwie noch mit der PA am Bus aber nicht im ETS Projekt hängt?

Da HJK hier nicht in dem Forum unterwegs ist, wäre die Frage wohl im KNX-UF besser aufgehoben, weil eben auch technisch keine Betroffenheit des TWS vorliegt, nur das es eben durch die Möglichkeiten des TWS (Busmonitor) Dir möglich war den Fehler auf ein bestimmtes Gerät einzugrenzen.
Das wäre dann auch wieder ne positive Storry im KNX-UF bzgl. des TWS.

[S. Kolbinger]

Hi Captain,

ich habe mich mal schnell auf deinem TWS257 eingewählt.
Dabei ist mir in den Grafana-KNX-Statistics aufgefallen, dass nicht nur PA=1.0.30, sondern auch PA=1.0.19 mit "0" (="Disable") antwortet.



Hast du die 1.0.19 im Busmonitor-Filter absichtlich abgewählt?


Das Phänomen dürfte meiner Ansicht nach mit den Objekt-Flags zusammenhängen.
Siehe: https://support.knx.org/hc/de/articles/ ... 8089-Flags

Ich bin jetzt nicht der große KNX-Experte, aber ich denke, es sollte nur ein Objekt aus der GA ein L-Flag haben und evtl. bei denn Schaltern das A-Flag gesetzt sein.

Sonst kann ich nur Göran zustimmen.

... nur das es eben durch die Möglichkeiten des TWS (Busmonitor) Dir möglich war den Fehler auf ein bestimmtes Gerät einzugrenzen.
Das wäre dann auch wieder ne positive Storry im KNX-UF bzgl. des TWS.

und vielleicht auch noch die KNX-Statistics dabei erwähnen

Ich hoffe, dass hilft dir weiter.

Gruß,
Stefan K.

[Cepheus73]

Der eigentliche Grund hier bzw. das Grundproblem dürfte sein, dass der eine GT bzw. auch der zweite, den Stefan rausgefunden hat, nicht mitbekommen, dass die Sperre aktiv ist und daher weiterhin auf den Leserequest "Disabled" senden.
Da du das reproduzieren kannst, dürfte das die wahrscheinlichste Ursache sein.

Für gründlichere Ursachenforschung wäre dann aber die Parametrierung in der ETS inkl. Zuweisung der GAs auf den betroffenen GTs notwendig.

Viele Grüße

Bernhard

Ergänzung:
Wie du ja schon richtig erkannst hast, ist das so eine ungünstige Implementierung. Es sollte eigentlich nur einen Master geben, der den Status hält, alle anderen sollten von diesem abhängen.

[James_T_Kirk]

Danke für eure Rückmeldung. Bezüglich eines Masters, was wäre der Vorschlag? Einen ungenutzten Schaltaktor Kanal um eine Status GA zu haben? Wird es mit den Logiken im TWS etwas dazu geben? Es müsste dann aber auch auf Read Requests vom Bus geantwortet werden. (Mit Openhab habe ich das derzeit noch nicht versucht, da ich mein NAS bei längerer Abwesenheit herunterfahre - dann funktioniert das Licht nicht wenn die Katze gefüttert wird.)

Hast du die 1.0.19 im Busmonitor-Filter absichtlich abgewählt?

Nein, ich habe den Filter vor längerem schon erstellt und das Gerät mit der PA ist erst vor 1-2 Wochen neu hinzu gekommen. Scheinbar speichert ihr die PA explizit zum Zeitpunkt der Filter Erstellung? Es ist schon etwas her, aber ich meine nur auf die GA gefiltert zu haben.

[James_T_Kirk]

Es sollte eigentlich nur einen Master geben, der den Status hält, alle anderen sollten von diesem abhängen.

Ich muss das nochmal aufwärmen, kam die letzte Zeit nicht dazu. Meinst du damit das es ähnlich die bei einem Schaltaktor eine eigene Status GA geben sollte?

Da denke ich gerade an eine AND Logik mit einem Eingang - hier senden die Taster das Telegram hin wenn die Taste zum Sperre Ein/Aus gedrückt wurde. Der Logik Ausgang sendet an eine Status GA und diese wird zur LED Anzeige genutzt.

Wenn ja, wäre es generell Best Practise bei Logik "Flags" (z.B. Anwesenheit, Sommer/Winter, Tag/Nacht) eine Status GA zu nutzen - ganz unabhängig von meinem Problem hier?

In meinem konkreten Fall habe ich auch noch ein Verständnis-Problem mit den Flags.
KO 5, welches den Status sendet. Sollte hier nicht S statt L aktiv sein?
KO 6, welches den Status um Umschalten liest. Sollte hier nicht L statt S aktiv sein?
KO 38, welches den Status als LED anzeigt. Müssten hier nicht die Flags S/Ü/A deaktiviert und L aktivert werden?

[Eraser]

In meinem konkreten Fall habe ich auch noch ein Verständnis-Problem mit den Flags.

Es geht bei den Flags ja darum, was man beim Zugriff auf die Objekte machen kann und nicht was das Objekt machen kann.

Bei S darfst du (oder ein anderes Gerät) auf dieses Objekt schreiben und nicht umgekehrt dass das Objekt nach außen schreiben darf.
Das musst du dir immer so vorstellen, wenn du in der Mitte zwischen 2 Objekten wärst und das Paket von A (Sensor) nach B(Aktor) geht.
Dabei wird das Paket von dir bei A gelesen und in B geschrieben.

[gbglace]

Sehr schöne Beschreibung für das Wesen der GA und Flags an den KO.

Das zeigt auch das es semantisch immer falsch ist beim Umgang mit der ETS zu schreiben mann soll KO in die GA ziehen um eine Verbindung herzustellen. Die GA als virteuller Draht wird wo eingesteckt, nicht die Klemmstelle in den Draht.