UPGRADE IP 9 verfügbar!
Timberwolf VISU jetzt mit NEUEM Layout Editor
Freie Anordnung, Reihenfolge und Größe der Widgets - viele weitere Verbesserungen
Infos im Wiki: https://elabnet.atlassian.net/l/cp/06SeuHRJ

NEU! Insider & Leistungsmerkmale FÜR ALLE freigeschaltet
Damit kann nun jeder das Upgrade vornehmen und VISU & IFTTT testen. Alle Info hier: viewtopic.php?f=8&t=5074

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

Diskussionen über die KNX-Funktionen im Timberwolf Server
Forumsregeln
  • Denke bitte an aussagekräftige Titel und gebe dort auch die [Firmware] an. Wenn ETS oder CometVisu beteiligt sind, dann auch deren Version
  • Bitte mache vollständige Angaben zu Deinem Server, dessen ID und dem Online-Status in Deiner Signatur. Hilfreich ist oft auch die Beschreibung der angeschlossener Hardware sowie die verwendeten Protokolle
  • Beschreibe Dein Projekt und Dein Problem bitte vollständig. Achte bitte darauf, dass auf Screenshots die Statusleiste sichtbar ist
  • Bitte sei stets freundlich und wohlwollend, bleibe beim Thema und unterschreibe mit deinem Vornamen. Bitte lese alle Regeln, die Du hier findest: https://wiki.timberwolf.io/Forenregeln
Antworten

Ersteller
James_T_Kirk
Reactions:
Beiträge: 309
Registriert: Do Sep 13, 2018 10:54 pm
Hat sich bedankt: 99 Mal
Danksagung erhalten: 120 Mal

PM Sperre wird sporadisch nach Read Request gesetzt

#1

Beitrag von 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.

Bild

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.
TWS 950Q 435 verkauft, umgestiegen auf Home Assistant

gbglace
Reactions:
Beiträge: 3585
Registriert: So Aug 12, 2018 10:20 am
Hat sich bedankt: 1253 Mal
Danksagung erhalten: 1649 Mal

#2

Beitrag von 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.
Grüße
Göran

#1 Timberwolf 2600 Velvet Red TWS #225 / VPN aktiv / Reboot OK
#2 Timberwolf 2600 Organic Silver TWS #438 / VPN aktiv / Reboot OK
#3 PBM 3 Kanäle, #4 Modbus-Extension

S. Kolbinger
Elaborated Networks
Reactions:
Beiträge: 588
Registriert: Mi Aug 15, 2018 11:34 am
Hat sich bedankt: 82 Mal
Danksagung erhalten: 558 Mal

#3

Beitrag von 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.

Bild

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

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.
gbglace hat geschrieben: Fr Mai 03, 2019 12:26 pm ... 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 :whistle:

Ich hoffe, dass hilft dir weiter.

Gruß,
Stefan K.
Gruß,
Stefan K.

Cepheus73
Reactions:
Beiträge: 167
Registriert: Sa Aug 11, 2018 11:36 pm
Wohnort: München
Hat sich bedankt: 394 Mal
Danksagung erhalten: 108 Mal

#4

Beitrag von 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.
Zuletzt geändert von Cepheus73 am Fr Mai 03, 2019 2:28 pm, insgesamt 2-mal geändert.
TW 2600 #178 - VPN offen, Zugriff jederzeit
EFH, KNX, 1-Wire, DALI, Wiregate,
CometVisu (TW Docker-Container), Mobotix T25, Logiken für Licht- und Rolladensteuerung
1-Wire-Ventilaktoren + Logiken für Gartenbewässerung

Ersteller
James_T_Kirk
Reactions:
Beiträge: 309
Registriert: Do Sep 13, 2018 10:54 pm
Hat sich bedankt: 99 Mal
Danksagung erhalten: 120 Mal

#5

Beitrag von 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.)
S. Kolbinger hat geschrieben: Fr Mai 03, 2019 1:15 pmHast 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.
TWS 950Q 435 verkauft, umgestiegen auf Home Assistant

Ersteller
James_T_Kirk
Reactions:
Beiträge: 309
Registriert: Do Sep 13, 2018 10:54 pm
Hat sich bedankt: 99 Mal
Danksagung erhalten: 120 Mal

#6

Beitrag von James_T_Kirk »

Cepheus73 hat geschrieben: Fr Mai 03, 2019 2:26 pm 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?
Bild
Zuletzt geändert von James_T_Kirk am Mi Jun 19, 2019 2:18 pm, insgesamt 1-mal geändert.
TWS 950Q 435 verkauft, umgestiegen auf Home Assistant
Benutzeravatar

Eraser
Reactions:
Beiträge: 646
Registriert: So Aug 12, 2018 1:51 pm
Wohnort: Amstetten, Österreich
Hat sich bedankt: 205 Mal
Danksagung erhalten: 275 Mal

#7

Beitrag von Eraser »

James_T_Kirk hat geschrieben: Mi Jun 19, 2019 2:17 pm 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.
Zuletzt geändert von Eraser am Mi Jun 19, 2019 2:44 pm, insgesamt 1-mal geändert.
mfg
Wolfgang

Timberwolf 2500 #151 / VPN offen / Reboot nach Rücksprache
+ PBM #938

gbglace
Reactions:
Beiträge: 3585
Registriert: So Aug 12, 2018 10:20 am
Hat sich bedankt: 1253 Mal
Danksagung erhalten: 1649 Mal

#8

Beitrag von 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.
Grüße
Göran

#1 Timberwolf 2600 Velvet Red TWS #225 / VPN aktiv / Reboot OK
#2 Timberwolf 2600 Organic Silver TWS #438 / VPN aktiv / Reboot OK
#3 PBM 3 Kanäle, #4 Modbus-Extension
Antworten

Zurück zu „KNX“