Bug im MDT Glaspräsenzmelder oder Konfigurationsfehler?

[hansblafoo]

Hallo,

ich bin seit Tagen an einem kuriosen Fehler dran und ich schwanke dazwischen, ob es sich hier um einen Bug im MDT Glaspräsenzmelder (aktuellste Firmware 4.6) oder einen Konfigurationsfehler von mir handelt. Da ich in der Vergangenheit schon in zwei anderen MDT Geräten Bugs entdeckt habe, die gemeldet habe und sie mir teilweise nach etwas Diskussion bestätigt aber danach nie gefixt worden sind, probiere ich es mal hier.

Hintergrund:
- Zwei DALI-Spotgruppen (Sofa, Terrassentür) im Wohnzimmer als einzelne Lichtkanäle, wobei sie im MDT Dali Pro Gateway in ihrem Verhalten so konfiguriert sind, dass sie beim Empfangen eines Dimmwertes auch den An-/Aus-Status setzen
- MDT SCN-G360K3.03 als Präsenzmelder als Halbautomat für beide Lichtkanäle sowie mit Dimmen statt Schalten
- An/Aus sowie Dimmen erfolgt über den Präsenzmelder, auch um leicht Sperren umzusetzen sowie zwischen Tag- und Nacht einfach unterscheiden zu können
- Folgende Konfiguration der Gruppenadressen, wobei die Ausgänge der Lichtkanäle mit den EVGs im Dali Gateway verknüpft sind
Konfiguration.png

Nachfolgend der Happy Case, aus dem ersichtlich ist, dass diese Konfiguration grundsätzlich funktioniert: Mit Senden eines absoluten Dimmbefehls dimmen beide Spotgruppen auf und melden ihren Status. Über ein "Aus" über die Gruppenadresse "Alle Spots Schalten Ein/Aus" gehen sie auf den Dimmwert 0% und sind aus. So wie man es also erwarten würde.Happy Case.png
Nun was nicht funktioniert: gleicher Ablauf wie eben, aber vor dem Senden von "Aus" werden die Lichtkanäle des Präsenzmelders gesperrt und wieder entsperrt. Es ist nun nicht mehr möglich über "Alle Spots Schalten Ein/Aus" die Spots auszuschalten. Man sieht, dass keine Reaktion der Ausgangsobjekte der Lichtkanäle erfolgt. Das funktioniert auch nicht über die Gruppenadresse je Spotgruppe. Die einzigen Wege, die ich bisher gefunden habe, war über den Dimmbefehl 0% zu senden oder über "Alle Spots Schalten Ein/Aus" nochmal "einzuschalten" (obwohl sie schon an sind) und danach auszuschalten.
Bad Case.png
Ich bin mir zu 95% sicher, dass das ein Bug ist, da...
- ich es an zwei verschiedenen Präsenzmeldern exakt genauso reproduzieren konnte
- es keine Rolle spielt, ob der Präsenzmelder mich sieht oder nicht
- es auch keine Rolle spielt, wie viel Zeit zwischen dem Aktivieren und Deaktivieren der Sperre vergeht, das Verhalten bleibt so
- wenn die Lichtkanäle nicht auf Dimmen sondern auf Schalten gestellt sind, funktioniert (abgesehen natürlich vom Dimmen) der Ablauf mit der Sperre korrekt
- wenn die Lichtkanäle des Präsenzmelders auf Vollautomat umgestellt werden (und sonst nichts geändert wird), auch der Ablauf mit der Sperre korrekt funktioniert

Kurzum: ich glaube, wenn über einen absoluten Dimmbefehl die Spots eingeschaltet werden und der Präsenzmelder dann gesperrt wird, so kommt er intern in einen ungültigen Zustand, der das Schalten der Ausgänge blockiert

Kann dieses Verhalten jemand reproduzieren?

Danke und VG

[gbglace]

Du meinst also, das KO0 und KO15 nicht mehr reagieren wenn sie statt auf 1-Bit schalten auf 1-Byte Dimmerwert absolut gestellt sind und vorab ein Zyklus Sperre 1 >> 0 durch laufen wurde?

Ansonsten wäre es sehr hilfreich wenn das Buslog alle Spalten zeigen würde, vorallem auch die sendende PA der Telegramme.
Denn aktuell fällt es sehr schwer die Eigenschaft HAlb vs Vollautomat nachzuvollziehen in den Bildern. Da nicht ersichtlich ist, wer denn da eigentlich AN oder AUS schaltet.

[hansblafoo]

Richtig, das meine ich.

In beiden Bildern oben läuft der PM als Halbautomat. Der Unterschied zwischen den Logs ist nur, dass ich einmal den Sperrenzyklus mache (zweiter Log) und einmal nicht (erster Log). Die Quelle spielt in diesem Fall keine Rolle. Ich habe es von zwei verschiedenen Tastern sowie über die 1Home App probiert und es macht keinen Unterschied, das (Fehl-)verhalten bleibt identisch.

Eine interessante Entdeckung noch: wird über KO3 bzw. KO18 (Externer Taster Kurz) ein Schaltsignal gesendet, dimmen die Spots anhand der Tag/Nacht-Einstellung im PM passend auf. Mache ich auch hier den Sperrenzyklus kann ich danach trotzdem problemlos ausschalten. Der Fehler tritt bei mir also tatsächlich bisher nur auf, wenn über KO0 und KO15 das Licht eingeschaltet wurde.

[hjk]

Wie sind die Parameter? Insbesondere für die Sperre?
Leg mal die 15/0/0 statt auf externer Taster kurz direkt auf den Dimmer.
Der PM bekommt das über den Status mit.
Dann könnte alles funktionieren.
Die Konstellation mit Halbautomat, Sperre und externer Taster ist eher ungewöhnlich. Ob da tatsächlich noch ein Fehler ist, müsste der Support prüfen.

[hansblafoo]

Danke dir, dass du dich auch auf dem Sonntag mit solchen Themen beschäftigst.

Hier die Konfiguration für den Lichtkanal 1 inkl. Sperre. Lichtkanal 2 ist analog.
Konfiguration_Sperre1.png
Konfiguration_Sperre2.png

Ich habe die 15/0/0 direkt auf den Dimmer gelegt und das klappt. Das habe ich aber auch so erwartet. Was ich dabei aber doch verliere, ist die Tag/Nacht-abhängige Dimmung der Spots? Denn das macht ja der PM in Folge des Triggerns über KO3 bzw. KO18 (externer Taster kurz). Wo ich im Haus keine Tag-/Nacht-abhängige Dimmung habe, mache ich das übrigens so, nutze also nicht diese KOs und das klappt.
Klar, ich könnte anfangen das über das DALI-Gateway mit zeitabhängigen Einstellungen zu machen, aber über den PM finde ich das praktischer und einfacher, da ich die ganze Lichtsteuerung (An/Aus, Dimmen, Sperren) eben lieber über ein Gerät statt verteilt über mehrere machen wollen würde

Ich finde im Übrigen die Konstellation gar nicht ungewöhnlich. Einen Halbautomaten muss ich ja einschalten und dafür bietet sich nun mal ein Taster an. Dass das automatische Abschalten bei nicht erkannter Präsenz auch mal unterbunden werden könnte und dafür eine Sperre genutzt wird, finde ich persönlich naheliegend.

[gbglace]

Dann könntest auch drüber nachdenken die GA an den Status und den Taster Kurz zu hängen.

[hjk]

Ein Workaround könnte sein, die 15/0/0 gleichzeitig auf Dimmer und PM zu geben. Beim Dimmer den Einschaltwert auf 30%. Der PM sendet wahrscheinlich den gewünschten Dimmwert hinterher. Das könnte klappen und das Ausschalten dann auch.
Oder das Problem zum Support, damit ein Ticket aufgemacht werden kann, falls sich das Problem da bestätigt.

[hansblafoo]

Dann könntest auch drüber nachdenken die GA an den Status und den Taster Kurz zu hängen.

Du meinst die 15/0/0 auf Taster kurz zu legen? Und auf welchen Status? Auf Status Ein/Aus einer der beiden Spotgruppen?

Ein Workaround könnte sein, die 15/0/0 gleichzeitig auf Dimmer und PM zu geben. Beim Dimmer den Einschaltwert auf 30%. Der PM sendet wahrscheinlich den gewünschten Dimmwert hinterher. Das könnte klappen und das Ausschalten dann auch.
Oder das Problem zum Support, damit ein Ticket aufgemacht werden kann, falls sich das Problem da bestätigt.

Ich habe das mal getestet und zumindest heute Abend hat das sehr gut funktioniert, danke! Ich teste das mal am Tag, um zu sehen, dass es da kein komisches Aufdimmen gibt.

Ich überlege es, dennoch dem Support das Problem zu melden. Ich scheue nur etwas den Aufwand, denn bei meinen anderen zwei Bug-Reports war es halt auch Arbeit, aber passiert ist leider nie etwas.