MDT Präsenzmelder SCN -> externer Taster

[Cannon]

So lange die Präsenzmelder automatisch an- und ausschalten ist alles easy und funktioniert. Auch das manuelle ein- und ausschalten funktioniert wunderbar. Allerdings kriege ich die Umsetzung bei einer Konstellation aus beidem nicht so recht hin.

Ich möchte mit dem Taster den Präsenzmelder übersteuern, dass heißt der soll an- oder ausgehen. Grundsätzlich ist die ganze Thematik ja in der Applikationssoftware abgebildet. Das heißt ich lege den Tastsensor (schalten) auf (externer Taster lang) auf den Präsenzmelder. Der Präsenzmelder steuert dann den entsprechenen Aktor am Schaltausgang.

Grundsätzlich funktioniert das. Es gibt aber immer mal wieder Situationen, die ich nicht nachvollziehen kann, da ist das Licht angeschaltet, ich bekomme es aber nicht mehr aus. Weder mit dem Präsenzmelder, noch mangels nicht vorhandener Präsenz. Wenn das eine Fehlerkennung des Präsenzmelders wäre, dann würde doch zumindest das wiederholte ein- bzw. ausschalten irgendwann dazu führen, dass das Licht aus ist .... ich habe das Gefühl der hört manchmal nicht auf den Eingang (externer Taster). Kann sowas sein oder ist hier ein grundsätzlich anderer Gedankenfehler?

[gbglace]

Screenshot von Parameter und GA. Dazu eine etwas übersichtlere Situationsbeschreibung dessen was als Falsch empfunden wird.

Es gibt aber immer mal wieder Situationen, die ich nicht nachvollziehen kann,

Ist eben schwierig eine Lösung für zu geben.

[Haiphong]

Bus Monitor verwenden !!!!
Dann wird's schon ....

[Cannon]

Der Bus-Monitor geht irgendwie nicht. Da kriege ich keien Verbindung zum IP-Router. Der Gruppenmonitor geht aber und ich konnte es nachvollziehen ... Tastsensor löst aus Gruppenadresse wird gesendet, aber der Präsenzmelder macht nichts.

Ich hatte gehofft, dass jemand auch schon so ein Problem hatte und dann wäre es leicht. ;-)

Ich habe jetzt mal die Bilder hochgeladen. Lichtkanal 3 ist der Schaltkanal, alle anderen sind Dimmkanäle und nicht problematisch, weil ich mit dem Tastsensor den Dimmaktor bzw. DALI-Kanal direkt ansteuere und der externe Tastereingang nur den Präsenzmelder "informiert". Allerdings geht das mit einem normalen Schaltaktor nicht, hier gehe ich den Weg, dass der Tastsensor den Präsenzmelder über den externen Tastereingang informiert und der Präsenzmelder dann schalten soll, was er aber nicht immer macht.

[gbglace]

Du scheinst nen kreatives GA-Schema zu haben. Schalt-GA Lichtkanal3 = 0/0/13 und Eingang Taster Lang Lichtkanal 0/0/12.

Wer sendet denn auf die 0/3/1 externe Bewegung, die ist auf allen Lichtkanälen aktiviert?

Wer sendet auf GA 0/2/13? Was ist das für ein Taster? Die GA ist zwar mit der Statusanzeige der Wippe verbunden, es könnte aber sein das diese Verknüpfung keine Auswirkung darauf hat das der Taster korrekt die Umschaltfunktion beherrscht weil er so keinen Status des Aktors mitbekommt. Lösung könnte hier sein, die GA 0/2/13 als hörende Adresse mit an das KO 18 zu verlinken.
Wenn der Taster den falschen Status hat kann eben sein das er genau asynchron zum PM/Aktorstatus eben ein EIN sendet obwohl schon ein ist. Der PM will ja am Taster Eingang lang expliziet 0Aus / 1Ein erhalten, der toggelt ja nicht selbständig in dem man ihn einfach immer mit 1Ein antriggert.

[Cannon]

Du scheinst nen kreatives GA-Schema zu haben. Schalt-GA Lichtkanal3 = 0/0/13 und Eingang Taster Lang Lichtkanal 0/0/12.

Das ist die Gruppe, die für Licht schalten zuständig ist und kommt dann vom Tastsensor oder ggf. auch Präsenzmelder. Das Problem dabei ist, dass ich eben nicht immer direkt schalte und das dann auf den Präsenzmelder lege. Und wenn ich den Schaltausgang nicht brauche, dann brauche ich keinen 2. "Licht schalten". Sollte ich das anders lösen?

Wer sendet denn auf die 0/3/1 externe Bewegung, die ist auf allen Lichtkanälen aktiviert?

Das ist nur im Bad, dass sind 2 Präsenzmelder (Dusche und WC) als Halbautomatik, die sind als "Slave" angebunden.

Wer sendet auf GA 0/2/13?

Da sendet der Schaltaktor den Status an/aus zurück.

Das Problem mit dem PM ist wohl, dass er anscheinend nicht nur den Wechsel ein oder aus mitbekommt, sondern auch darüber entscheidet, obd as Licht vermeintlich an oder aus ist. Das heißt Licht ist an, PM denkt aber es sei aus und dann funktioniert auch ein aus nicht. Könnte das sein? Wenn dem so ist, müsste man den PM auch extern irgendwie mitteilen können, dass Licht nun wirklich an oder aus ist. Also quasi die Rückmeldung vom Aktor.

[gbglace]

Das Problem mit dem PM ist wohl, dass er anscheinend nicht nur den Wechsel ein oder aus mitbekommt, sondern auch darüber entscheidet, obd as Licht vermeintlich an oder aus ist. Das heißt Licht ist an, PM denkt aber es sei aus und dann funktioniert auch ein aus nicht. Könnte das sein? Wenn dem so ist, müsste man den PM auch extern irgendwie mitteilen können, dass Licht nun wirklich an oder aus ist. Also quasi die Rückmeldung vom Aktor.

Solange nur der PM final mit dem Aktor kommuniziert und im Aktor keine Treppenlichtzeiten usw. parametriert sind, dann geht das auch ohne Status Aktor /PM. Nur eben meine Vermutung ist das der Taster ggf nicht weis ob AN/AUS ist und deshalb beim drücken genau das falsche sendet, daher ggf die Rückmelde-Adresse auch auf das KO18 verlinken.


Naja eine Gruppe für schalten Licht ist ja i.O: aber die sollten dann nur die KO bekommen die wirklich im direkten Schaltprozess beteiligt sind. indirekt quasi neutral "Klick Taste Taster" würde ich auch irgendwie so neutral nennen und eine eigene gruppe machen. das erleichtert es auch sofern man Taster für alle möglichen Funktionen mitverwendet. So halt mein Ansatz.

[Cannon]

Solange nur der PM final mit dem Aktor kommuniziert und im Aktor keine Treppenlichtzeiten usw. parametriert sind, dann geht das auch ohne Status Aktor /PM. Nur eben meine Vermutung ist das der Taster ggf nicht weis ob AN/AUS ist und deshalb beim drücken genau das falsche sendet, daher ggf die Rückmelde-Adresse auch auf das KO18 verlinken.

Dem Tastsensor ist das egal, der sendet auch noch mal an, wenn man drückt, obwohl er an ist. KO18 habe ich aber nicht verstanden, was damit gemeint ist ...

Naja eine Gruppe für schalten Licht ist ja i.O: aber die sollten dann nur die KO bekommen die wirklich im direkten Schaltprozess beteiligt sind. indirekt quasi neutral "Klick Taste Taster" würde ich auch irgendwie so neutral nennen und eine eigene gruppe machen. das erleichtert es auch sofern man Taster für alle möglichen Funktionen mitverwendet. So halt mein Ansatz.

Das werde ich so umsetzen. Bisher war das Ganze nur noch nicht fertig und ich musste erst einmal porobieren, wie ich das mitd en Tastern am Besten löse. Den Weg über den PM zu gehen hat nämlich zumindest mit Dimmfunktion viele Nachteile und deshalb mache ich es jetzt bei den dimmbaren direkt. Vorher waren alle immer indirekt, aber dann ging ständig irgendwo das Licht nicht mehr aus, weder manuell noch über den PM.

[gbglace]

Dem Tastsensor ist das egal, der sendet auch noch mal an, wenn man drückt, obwohl er an ist. KO18 habe ich aber nicht verstanden, was damit gemeint ist ...

Ja das ist doch aber schon das Problem, wie willst denn ausschalten wenn er EIN sendet? Oder eben anschalten wenn er AUS sendet, also sollte der Taster doch wissen wie der aktuelle Status ist damit er eben genau das entgegengesetzte sendet.

Ansonsten versteh ich dein Problem noch nicht genau aus Post #1

[Cannon]

Der Taster sendet ein aus, wenn ich auf aus drücke und ein ein, wenn ich auf ein drücke - unabhängig davon ob der Status an oder aus ist. Dem Taster ist das also egal. Dennoch geht das Licht öfter nicht aus, weil der Präsenzmelder nicht merkt, ob das Licht an oder aus ist. Jetzt nachvollziehbar? :-)

[gbglace]

Dann müsste noch ein anderes Objekt dem Aktor einen Schaltbefehl senden. Wenn das aber auszuschließen ist sollte es funktionieren, da der im PM errechnete (Ablaufdiagramm siehe Handbuch PM) Status gleich dem Status des Aktors sein muss.

[Cannon]

Leider ist aber genau das das Problem. Das Ganze funktioniert nicht immer zuverlässig. Ich hatte gehofft es ist ein bekanntes Problem, was man evtl. umgehen könnte....

[gbglace]

Spielen ggf Nachlaufzeiten / Rückfallzeiten eine Rolle, die es komisch erscheinen lassen?

[Cannon]

Leider nein, die sind genau auf die gleiche Zeit, wie die Präsenzzeit eingestellt. Und selbst wenn, mit dem externen Taster müsste ich das doch übersteuern können.

[mumpf]

Leider nein, die sind genau auf die gleiche Zeit, wie die Präsenzzeit eingestellt.

Hi,

diese Annahme ist prinzipiell falsch! Ein Beispiel: PM und Treppenlicht Nachlaufzeit 1 Minute. PM schaltet ein, nach 30 Sekunden wird Bewegung festgestellt. Jetzt würde der PM nach 1:30 Minuten (vom Einschaltzeitpunkt aus) ausschalten. Treppenlicht schaltet trotzdem nach 1 Minute aus.

Also: Gleiche Nachlaufzeiten können durchaus unterschiedliches Verhalten bewirken. Ob das bei Dir eine Auswirkung hat, kann ich nicht sagen.

Gruß, Waldemar