Problem mit MDT Patsch Funktion und Logik/Szenen Zuordnung

[Schmerzlassnach]

Hallo zusammen,
ich hab ein Problem mit der Patsch Funktion und die mit einer Logik und Szenen zu verheiraten.

Im Einsatz sind nur MDT Komponenten, auch das Licht läuft nicht über einen Dimmaktor sondern einfaches "ein/aus" (MDT AKS), Bedienelement ist ein MDT Glastaster II. Zeit bzw Dämmerung/Tag wird über eine MDT Bedienzentrale realisiert.

Folgendes ist das Ziel:
Tagsüber soll bei Patsch das Licht nicht angehen aber die Steckdose(n)
Dämmerung soll bei Patsch (oder Idealerweise auch bei Eintritt Dämmerung) das Licht und die Steckdose(n) angehen

Ich habe folgende Gruppenadressen
0/0/4 Dämmerung/Tag
2/2/50 Szene Logik
2/2/51 Szene

Bedienzentrale:
Über die Zeitsteuerung wird Ein/Aus an die Adresse 0/0/4 Dämmerung/Tag gesendet

Glastaster II:
2 Logikblöcke sind aktiv mit "UND"
Da der Glastaster II Patsch nicht intern Abfragen kann (zumindest nichts gefunden) habe ich Logikobjekt Eingang 1A und 2A in 2/2/50 Szene Logik gepackt
"Umschaltstatus" für Patsch nehme ich vom AKS Kanal für die Steckdose den Status
Logikobjekt Eingang 1B und 2B sind in der Gruppenadresse für 0/0/4 Dämmerung/Tag, 2B ist invertiert eingestellt (soll meine Tagschaltung sein). Ausgangsstatus ist auf 0
Logikobjekt 1 Ausgang sendet Szene 1 an 2/2/51 Szene
Logikobjekt 2 Ausgang sendet Szene 2 an 2/2/51 Szene

AKS
Für die zwei Kanäle sind entsprechende Szeneneinstellungen gesetzt, Szene 1 ist der Lichtkanal Aus, Steckdose Ein, Szene 2 sind beide an
Beide Szeneobjekte sind mit der GA 2/2/51 Szene verknüpft

Was jetzt passiert verstehe ich nicht
Patsche ich auf den Taster wenn alles aus ist, sendet er ein "EIN" an die Adresse 2/2/50 Szene Logik, es passiert sonst nichts
Patsche ich erneut auf den Taster wenn alles aus ist, sendet er ein "AUS" an die Adresse 2/2/50 Szene Logik
Patsche ich erneut auf den Taster wenn alles aus ist, sendet er ein "EIN" an die Adresse 2/2/50 Szene Logik, kurz darauf sendet der Taster die Szene (je nach Dämmerung/Tag) 1 oder 2 an 2/2/51 und der AKS schaltet Licht/Strom wie gewünscht.
Ausschalten geht aber nicht über Patsch, ich vermute hier müsste ich noch ein Logikblock setzen der das macht aber erst mal wäre mir das "Anschalten" das eigentlich wichtige

Was auch funktioneirt, wenn ich "Tagsüber" die oben genannten 3x Patsche und die Dämmerung tritt ein, schaltet er zusätzlich noch das Licht ein

Was mach ich falsch?

[gbglace]

Erstmal packt man keine KO in GA das habe ich bestimmt auch schon Mal in einer deiner Fragen geschrieben. Tippe ich jetzt nicht nochmal warum das so geschrieben Unsinn ergibt.

Die Nennung der GA scheint mir arg unsortiert, da fehlt bestimmt ein vernünftiges GA Konzept. Aber egal.

Ich verstehe da jetzt noch nicht ganz den Zwang zu einer Szene und entsprechenden Namen in der GA.

Patsch sendet eine GA (2/2/50) 1Bit 0/1 , diese GA ist mit dem Aktor für die Steckdose verbunden, da der ja immer Tag wie Nacht schalten soll. Und die dritte Verbindung ist dann eine Logikfunktion UND. An diese Logikfunktion geht dann noch die GA Tag/Nacht, je nach Polarität negiert. Das Ergebnis der Logik geht per GA an Deinen Lichtaktor. Da auch einfach eine GA 1Bit 0/1. Fertig. Nix Szene oder so.

Logiken sind halt keine Szenen, du machst da aber was mit Szenen und Szenen kann man nicht AUS schalten. Da müsstest für AUS eine dritte Szene definieren. Und der Patsch kennt den Status nicht weswegen der immer seinen eigenen Rhythmus AN/AUS hat unabhängig davon ob eine andere Bedienstelle da mal was zwischendurch geschalten hat.
Da aber alles nur ganz binär ist sehe ich da keinen Grund für Szenen, zumal da auch keine allgemeine Szenen GA mit Szenennummern von Dir verwendet wird sondern für alle Versionen ne eigene GA, das macht so keinen Sinn.

Das mit dem Nachschalten der Lampe wenn es denn dunkel wird kann man als Feature begreifen. Wenn man es so nicht will, dann brauchst eine externe Logik, die nur das Telegramm des Patsch als Trigger zur Neuberechnung verwendet und die Tag/Nacht Information nur als Information nutzt. Das geht aber eben nicht in den einfachen Logiken der Aktoren/Taster.

[Schmerzlassnach]

Erstmal packt man keine KO in GA das habe ich bestimmt auch schon Mal in einer deiner Fragen geschrieben. Tippe ich jetzt nicht nochmal warum das so geschrieben Unsinn ergibt.

Da ich bisweilen keine KNX Frage gepostet habe würde mich das wundern, die Aussage stellt mein bisheriges Verständnis aber kräftig in Frage, was ordne ich denn einer Gruppenadresse sonst zu wenn keine Kommunikationsobjekte oder steht KO für was anderes? Oder meintest du "dasselbe KO in mehrere GA"? Das habe ich nicht

Die Nennung der GA scheint mir arg unsortiert, da fehlt bestimmt ein vernünftiges GA Konzept. Aber egal.

Ich verstehe da jetzt noch nicht ganz den Zwang zu einer Szene und entsprechenden Namen in der GA.

Richtig
Es gibt keinen Zwang, es ist "mal was mit ner Szenen gemacht zu haben" aber auch die überlegung "schalte ich mehrere sachen auf einmal, mach ich das immer über szenen" auch wenn keine notwendigkeit besteht

Patsch sendet eine GA (2/2/50) 1Bit 0/1 , diese GA ist mit dem Aktor für die Steckdose verbunden, da der ja immer Tag wie Nacht schalten soll. Und die dritte Verbindung ist dann eine Logikfunktion UND. An diese Logikfunktion geht dann noch die GA Tag/Nacht, je nach Polarität negiert. Das Ergebnis der Logik geht per GA an Deinen Lichtaktor. Da auch einfach eine GA 1Bit 0/1. Fertig. Nix Szene oder so.

Ok meine Anforderung lässt sich rein über die Logikfunktion ohne Szene regeln, verstanden soweit. Probier ich auch mal auf dem weg.

Würde es trotzdem gerne auch über Szenen probieren oder verstehen warum es nicht will

Logiken sind halt keine Szenen, du machst da aber was mit Szenen und Szenen kann man nicht AUS schalten. Da müsstest für AUS eine dritte Szene definieren. Und der Patsch kennt den Status nicht weswegen der immer seinen eigenen Rhythmus AN/AUS hat unabhängig davon ob eine andere Bedienstelle da mal was zwischendurch geschalten hat.

Habe beim Suchen das hier gefunden:
https://knx-user-forum.de/forum/%C3%...91#post1471891
Im Prinzip nutze ich eben für den "Status" aus Punkt 1+3 keine Logik (also "mehrere Lampen") sondern halt den Status eines festen Kanals, die "Aus" Szene habe ich (noch) nicht da ich ja schon beim Einschalten Probleme habe

Allerdings postet Waldemar nachfolgend dann auch
https://knx-user-forum.de/forum/%C3%...06#post1473106
dass es da wohl ein Problem mit den MDT Tastern gibt und so nicht möglich ist, der prinzipielle Gedanke aber richtig zu sein?

So sieht das aufm Bus aus
szenenlogikotkt8.png
Nach senden der Szene Schaltet der Aktor dann auch wie gewünscht
Warum genau passiert jetzt beim ersten Patsch aber nichts? Das verstehe ich auch im anderen Thread nicht...

in der 2/2/50 ist im Prinzip nur der Taster selbst (Eingang 3 A wäre aktuell die "AUS" Szene)
Szene Logik.png
Da ich in den Logiken "Vorbelgung 0" ausgewählt habe müsste man doch nach dem 2. Patsch in der Ausgangssituation von Patsch 1 sein...nur passiert bei Patsch 3 eben das gewünschte?! "not a bug, not a feature"?

Da aber alles nur ganz binär ist sehe ich da keinen Grund für Szenen, zumal da auch keine allgemeine Szenen GA mit Szenennummern von Dir verwendet wird sondern für alle Versionen ne eigene GA, das macht so keinen Sinn.

Ich habe irgendwo hier mal gelesen man soll nicht alles in zentrale Szenen packen, hab ich dann jetzt erst mal so gemacht pro Raum eine "Szene GA"...hier im Beispiel gerade die 2/2/51 an die ich Szene 1, 2 oder auch 3 (für aus) senden könnte.

Das mit dem Nachschalten der Lampe wenn es denn dunkel wird kann man als Feature begreifen. Wenn man es so nicht will, dann brauchst eine externe Logik, die nur das Telegramm des Patsch als Trigger zur Neuberechnung verwendet und die Tag/Nacht Information nur als Information nutzt. Das geht aber eben nicht in den einfachen Logiken der Aktoren/Taster.

Mit dem aktuellen Aufbau mit Szene funktioniert das nachschalten ja, ich gehe auch von aus mit der oben genannte logik würde das ebenso klappen

[gbglace]

Da ich bisweilen keine KNX Frage gepostet habe würde mich das wundern, die Aussage stellt mein bisheriges Verständnis aber kräftig in Frage, was ordne ich denn einer Gruppenadresse sonst zu wenn keine Kommunikationsobjekte oder steht KO für was anderes?

Naja in der ETS kann man da viel per Drag and Drop machen. allerdings passiert im KNX auf dem Bus alles etwas anders und das ist am Ende das entscheidende wenn man auf einmal komischen Effekte beobachtet.

KNX kommuniziert mit Telegrammen zwischen den Geräten. Dabei sind die KO als Kommunikationsobjekte diejenigen Teile die da kommunizieren und di Eigenschaften an den KO (Flags) definieren wie so ein KO reagiert und was von Innen (Gerät) nach Außen (Bus) und umgekehrt an Information transportiert wird.

Auf dem Bus selbst gibt es die Telegramme und diese haben im wesentlichen die GA und den Nutzwert als Inhalt. Insofern ist auf dem Bus eine GA kein Objekt, sondern teil der transportierten Information, da kann man also nichts rein tun. Und man kann auch nichts auf eine GA senden, wird auch gern so falsch formuliert. Man kann viele KO mit vielen GA verbinden, das ist es aber auch schon. Die KO wissen dann wenn Telegramme auf dem Bus zirkulieren, das sie sich für diese interessieren können ja/nein. Eine andere Analogie dazu, eine GA ist ein Draht zwischen den Geräten. Und einen Draht (GA) kann man in Klemmen (KO) stecken aber man kann keine Klemmen in einen Draht stecken.

Gefühlt schreibe ich das jeden zweiten Tag. Weil sich da jeder irgendwie so auf die ETS versteift und im GA-Baum rumhantiert und so denkt so funktioniert der Bus, alles mögliche in eine GA stecken. Didaktisch ganz blöde Errungenschaft das ganze. Aber eben so ein Effekt wie man es überall in der IT erfährt. je bunter die Oberflächen desto verdummter der User der die grundlegende Mechanik dahinter nicht versteht, nicht mal im einfachen Prinzip. Die Details wie sich die einzelnen Bits im KNX-Telegramm ergeben muss ja auch nicht jeder verstehen aber das wesentliche tät schon Sinn ergeben.

So sieht das aufm Bus aus
szenenlogikotkt8.png
Nach senden der Szene Schaltet der Aktor dann auch wie gewünscht
Warum genau passiert jetzt beim ersten Patsch aber nichts? Das verstehe ich auch im anderen Thread nicht

Der Bus ist Event basiert.

Wenn Du einen Taster neu parametreist hat der erstmal ein Gedächtnis von nichts bzgl. des Status vom Aktor. Im KNX gibt es kein zentrales Gedächtnis, sondern die KO in den Geräten speichern sich selbst den letzten empfangenen Wert. Da der Aktor noch keinen Zustandswechsel hatte seit der Taster online gegangen ist, siehst Du zwar als Bediener das der Aktor aus ist aber der Taster nicht, kam ja noch kein neues Telegramm an. Sendet der Taster dann selber ein AUS und die Logik macht auch ein AUS für den Aktor, dann kommt da aber kein AUS aus dem Aktor zurück, weil der ist ja schon aus. somit ist der Status für den Taster weiterhin undefiniert. ggf reagiert er dann aber in seiner UM-Schaltfunktion aus seiner eigenen inneren Erkenntnis ich habe ja zuletzt AUS gesendet, dann sende ich jetzt als nächstes AN. Das wiederum nötigt den Aktor auch was umzuschalten und einen neuen Status zu senden, den der Taster dann auch mitbekommt.

Da Du aber keine Szene AUS hast sendet der Taster zwar AUS aber die Logiken senden nichts weil die ja nur eine AN Szene haben damit passiert dann beim Aktor wieder nichts.

Ich habe irgendwo hier mal gelesen man soll nicht alles in zentrale Szenen packen, hab ich dann jetzt erst mal so gemacht pro Raum eine "Szene GA"...hier im Beispiel gerade die 2/2/51 an die ich Szene 1, 2 oder auch 3 (für aus) senden könnte.

Naja eine Szene ist ein Gewerkeübergreifender Zustand verschiedener Geräte, das hat man ggf nicht alles raumweise. denn bedenke ein KNX-KO sendet immer genau ein Telegramm udn in einem telegramm wird als Information genau eine GA gesendet. Bei Szenen stehen 64 Nummern zur Auswahl. Eine Szene für eine Lampe/Steckdose ist für mich keine Szene, sondern eher alles in einem Raum. Szene TV, da habe ich diverse leuchten auf Dimmstufen andere sind aus, Rollos sind in einem Automatik-Zustand wegen Antiblendung oder wegen Antimitschauen der Nachbarn. TV geht an, AV Reciever auch. Echos gehen aus. usw. usw.

Wenn man da nun einfach nur Kanal A und Kanal B AN/AUS am selben Aktor haben will sehe ich da keinerlei Mehrwert an Szenen. Wobei die Kunst ja nicht im Auslösen von AN/AUS liegt, sondern in der Filterung des einen Kanals.

Eine andere einfache Lösung unabhängig vom Patsch wäre ja wenn Du für den Tag/Nacht bedingten Kanal die UND-Logik nicht am Taster sondern am Aktor selbst einstellst der hat ja auch Logikfunktionen. Das würde dort dann nur bedeuten. das die Leuchte grundsätzlich nur leuchten Kann wenn Dämmerung/dunkel ist. Muss man also sehn was man erreichen will. Ob die Lampe grundsätzlich von der Helligkeit gesteuert ist oder nur die Auslösung aus dem einen Taster. Was machst wenn es von einer Visu aus geschalten wird, hat das dann den Effekt wie der Taster? Oder geht das dann unabhängig? Nur mal so als Gedanken die sicher noch kommen werden, beim weiteren Ausbau der Anlage.

Mit dem aktuellen Aufbau mit Szene funktioniert das nachschalten ja, ich gehe auch von aus mit der oben genannte Logik würde das ebenso klappen

Ja wenn man die Logik entsprechend mit den triggern definiert, sollte das auch mit Szenen funktionieren.

Nachteil bei den Szenen ist eben es braucht zwei Logiken und drei Szenen. Weil es in Deinem Falle keine sinnvolles Verhalten in einem UND gibt wenn true dann Szene1 sonst Szene2.

Bei der einfachen Lösung ohne Szene braucht es nur eine Logik für das bedingte AN, das unbedingte AN kommt immer an und das AUS kommt an beiden Zielen auch immer an. Finde ich deutlich übersichtlicher und weniger komplex.

[Beleuchtfix]

KOs in GAs packen, das ist Görans Spezialgebiet es geht um die Semantische Richtung, also bitte GAs in die KOs stecken. Oft geht es bei den Anwendern nicht nur um die sprachliche Feinheit, sondern auch um das Verständnis der KNX Funktionalität.

Ein Umschalter (Glas Patch) bekommt immer sein eigenes Schalten mit, insofern ist es verständlich, wenn nach jedem Schalten entgegengesetzt schaltet. Erst wenn ein zusätzlicher Impuls einen anderen Status erzeugt, wird dieser wichtig und ändert etwas.

Logik, die Logik funktioniert erst, wenn alle Eingänge einen gültigen Wert haben, nach dem Programmieren fehlen einzelne Eingänge. Die kannst du teilweise aber auf einen Defaultwert setzen.
Viel Erfolg, Florian

[Schmerzlassnach]

Ok dann hab ich das GA/KO verstanden, die Adresse wird dem Objekt zugeordnet und nicht das Objekt der Adresse

Der Bus ist Event basiert.

Wenn Du einen Taster neu parametreist hat der erstmal ein Gedächtnis von nichts bzgl. des Status vom Aktor. Im KNX gibt es kein zentrales Gedächtnis, sondern die KO in den Geräten speichern sich selbst den letzten empfangenen Wert. Da der Aktor noch keinen Zustandswechsel hatte seit der Taster online gegangen ist, siehst Du zwar als Bediener das der Aktor aus ist aber der Taster nicht, kam ja noch kein neues Telegramm an. Sendet der Taster dann selber ein AUS und die Logik macht auch ein AUS für den Aktor, dann kommt da aber kein AUS aus dem Aktor zurück, weil der ist ja schon aus. somit ist der Status für den Taster weiterhin undefiniert. ggf reagiert er dann aber in seiner UM-Schaltfunktion aus seiner eigenen inneren Erkenntnis ich habe ja zuletzt AUS gesendet, dann sende ich jetzt als nächstes AN. Das wiederum nötigt den Aktor auch was umzuschalten und einen neuen Status zu senden, den der Taster dann auch mitbekommt.

Da Du aber keine Szene AUS hast sendet der Taster zwar AUS aber die Logiken senden nichts weil die ja nur eine AN Szene haben damit passiert dann beim Aktor wieder nichts.

Wenn der Taster jetzt beim 1. Patsch ein Ein sendet müsste doch aber die Tasterlogik einen gültigen Wert "1" bekommen und dann die Logik entsprechend reagieren weil dann ja ein gültiger Wert vorhanden ist? Warum reagiert der Taster auf sich selbst erst nachdem er einmal 1, dann 0 und wieder die 1 bekam?

Wie ist vor dem Hintergrund des undefinierten Zustands nach Parameterisierung denn die "Vorbelegung 0" zu verstehen? Dachte das ist genau für den "undeffinierten Zustand", mache ich hier nämlich Vorbelegung 1 ist Steckdose/Licht direkt nach Parameterisierung an
Szenen Logik Tastereinstellung.png


Allerdings funktioniert mein Logikaufbau ab dem 3. Patsch wie erwartet, das hatte ich gestern Abend nicht probiert (also ein patsch reicht für ein und ausschalten), ok ich habe jetzt auch die "AUS" Szene definiert
Allerdings nur so lange bis ich den Kanal mit der Statusprüfung über den Taster manuell schalte, dann ist wieder 3x Patsch angesagt und das ruft bei mir trotzdem noch Fragezeichen auf. Was Patsch sendet kommt ja über den Zustand meiner Steckdose und er sendet auch entsprechend der Steckdosen Status das jeweilige Gegenteil (also ist die Steckdose aus, sendet Patsch ein/1) aber die Logik reagiert nicht und da verstehe ich nicht wieso - es werden nämlich die richtigen Werte gesendet so dass sie reagieren müsste/sollte

[gbglace]

Allerdings nur so lange bis ich einen Kanal über den Taster manuell schalte,

Der Patsch kennt keinen quasi sinnvollen Status, das musst noch korrigieren dann wird das sicher besser werden.

Ich habe diesen Taster nicht um das mal zu probieren.

[willisurf]

Der Statusausgang des Aktors für die Steckdose gehört an den Statuseingang für die Patschumschaltung, dann sollte es funktionieren.

[Schmerzlassnach]

Der Statusausgang des Aktors für die Steckdose gehört an den Statuseingang für die Patschumschaltung, dann sollte es funktionieren.

Genau das habe ich
Wert für Umschaltung.png

und je nachdem wie hier der Status ist, sendet mein Patsch auch "EIN" oder "AUS" (sowohl wenn ich über den Taster, direkt am Aktor oder über die Szene/Patsch geschalten habe). Sieht man so auch in der Diagnose auf dem Bus und auch am Stati den der Taster anzeigt.

Ist hier der Status "EIN" sendet mein Patsch "AUS" an die Logik Szenen Adresse, ist der Status "AUS" sendet mein Patsch "EIN"...

[Beleuchtfix]

Ist hier der Status "EIN" sendet mein Patsch "AUS" an die Logik Szenen Adresse, ist der Status "AUS" sendet mein Patsch "EIN"...

und das ist erst einmal richtig - wenn du etwas anderes willst musst du es auch anders machen.
Gruß
Florian

[Schmerzlassnach]

Genau das ist ja mein Problem, es ist richtig was da gesendet wird, es ist das was ich will aber es passiert nicht das was passieren soll

Folgende Situation habe ich nachdem ich nach der parameterisierung 3x gepatscht habe zum einschalten bzw ein 4x zum ausschalten.

Folgendes Funktioniert
- Ich patsche einmal, es passiert was ich erwarte. Steckdose + Licht gehen an. Auf dem Bus sehe ich dass "EIN" durch mein Patsch gesendet wurde
- Patsche ich erneut sendet mein Patsch auf den Bus wie gewollt ein "AUS" und Steckdose + Licht (wenn aktuell ein) gehen aus
Das funktioniert wiederholt genau so wie erwartet.

Folgendes ist ein Problem bzw mein aktuelles Problem
- Schalte ich per Patsch die Szene um die Steckdose/Licht einzuschalten geht das
- Schalte ich dann per Taster (T3) den Kanal der Steckdose AUS von der auch der Status kommt passiert folgendes
- Ich patsche, es wird auf den Bus wie erwartet "EIN" gesendet aber es passiert wie direkt nach der Parametrisierung nichts weiter
- Ich patsche erneut, es wird auf den Bus ein "AUS" gesendet, ist das Licht AN geht das aus (also im Prinzip wie erwartet/gewollt)
- Patsche ich nun ein drittes mal habe ich wieder den Zustand, es wird ein "EIN" auf den BUS gesendet und Steckdose/Licht gehen an

Danach funktioniert das Patschen wieder wie erwartet bis ich wieder "Einzelsteuerung" mache, das ist zwar ein Szenario das eher selten vorkommen sollte aber es stört mich trotzdem dass, das nicht so funktioniert wie ich erwarte bzw sollte. Das ist mir völlig schleierhaft.
Der Taster sendet die richtigen nachrichten aber die logik reagiert nicht und ich verstehe nicht wieso

Hoffe jetzt ist verständlich was mein (aktuelles) Problem ist

[gbglace]

Ich patsche, es wird auf den Bus wie erwartet "EIN" gesendet aber es passiert wie direkt nach der Parametrisierung nichts weiter

Weil Du alles durch die Logik schiebst. Die Logik hat ja immer noch die alten Informationen an Ihren Eingangs-KO bevor du mit T3 das AUS gemacht hast. Für die ist da alles noch true und nun kommt Patsch nochmal mit einem true, das ist nix neues also wird sie da vermutlich kein erneutes true senden. Das Sendeverhalten kann man hier und da aber einstellen, derzeit steht es wohl auf sende nur bei Änderung, das müsste dann auf Sende immer stehen.

[Schmerzlassnach]

Das ist es wohl
Hm finde keine Einstellung beim Glastaster II die da was steuern kann wies aussieht.
Beim MDT Präsenzmelder kann ich die Sendebedingung festlegen (Bei Änderung am Ausgang, bei Eingangstelegram und ein paar statische)

Sieht so aus dass ich mit einer alten Produktdatenbank arbeite die diese Einstellung für den Glastaster II nicht kennt (konkret 2.5), die aktuelle 2.8 kennt die Einstellung für den Glastaster. Kann ich alle Zuordnungen/Einstellungen irgendwie übernehmen oder muss ich beim ersetzen alles neu ersetzen und den Taster komplett neu parameterisieren? Also geht um 2.5 durch 2.8 im Projekt ersetzen, im Projekt sind die ganzen Glastaster mit 2.5 drin

Stimmt auch nicht, mit Szene als Objekttyp gibts das nicht, gibts nur bei "Schalten", zumindest beim Glastaster, beim Präsenzmelder geht das auch bei Szenen einzustellen
Logik Objekttyp.png
Ideen dazu außer dass ich die Logik des Präsenzmelders missbrauch?

[Schmerzlassnach]

Für die dies interessiert, habe auch mit MDT darüber gesprochen
Eine wirkliche Lösung für den Glastaster II gibt es nicht, es ist fest hinterlegt dass nur bei Bedingungseintritt die Logik eine Szene sendet (also bei Änderung Ausgang), die Sendebedingung kann nicht beeinflusst werden. Empfehlung ist Ausweichen auf Präsenzmelder.
Etwas enttäuscht bin ich dass diese Einschränkung u.a. auch die Bedienzentrale(n) betrifft und noch weitere Geräte von MDT.

Nunja, isso.