Lösung für Single Object Control Bug im MDT Jalousieaktor?

[hansblafoo]

Hallo zusammen,

bevor ich mir selbst eine Lösung überlege, wollte ich mal fragen, ob hier jemand vielleicht schon eine Lösung für nachfolgend beschriebenes Problem entwickelt hat oder vielleicht eine schlauere Lösung als ich hat.

Problem
Ich benutze in den MDT Jalousieaktoren für die Rollladen Single Object Control und das klappt soweit auch sehr gut. Eine Sache fuchst mich aber: wenn man einen Rollladen zum Beispiel mittels Single Object Control nach ganz oben gefahren hat (also zu 0% geschlossen) und aus welchem Grund auch immer dann nochmal das KO zum Hochfahren sendet (z.B. falsche Taste gedrückt, zentrale Funktion zur Ansteuerung mehrerer Rollladen), dann muss man zweimal das KO für das Herunterfahren senden, damit sich der Rollladen schließt. Das erste Senden des KOs wird quasi ignoriert bzw. glaube ich, dass der Aktor auf dem Kanal in einem ungültigen Zustand ist. Das ganze gilt übrigens auch für den umgekehrten Fall, also Rollladen geschlossen, nochmal KO für schließen gesendet und danach öffnen wollen, was zweimal das Senden des KOs verlangt. Nach Aussage des MDT-Supports sei das ein normales und erwartetes Verhalten, aus meiner Sicht ist es ein klarer Bug.

Meine bisherige Lösungsidee
Da ich Single Object Control weiter nutzen will, wäre nun meine Idee, dem Senden des KOs an den Jalousieaktor eine Logik vorzuschalten. Es würde dann nur der Auf/Ab-Befehl gesendet werden, wenn der Rollladen nicht komplett offen/geschlossen ist. Ich würde damit dann Taster vom Jalousieaktor entkoppeln, da der Logikserver dazwischen sitzt. Ich denke, die Lösung würde so funktionieren, ist aber natürlich Aufwand, da ich das für jeden Rollladen und alle Gruppenadressen machen muss, die Single Object Control nutzen. Zudem hätte ich in dieser Kette einen weiteren Teilnehmer, nämlich den Logikserver, was unschön ist.

Habt ihr vielleicht noch eine bessere Idee?

Danke und viele Grüße

[TabSel]

muss ja kein zentraler Logikserver sein. Wenn doch, dann Logik kapseln und wiederverwenden.
aber auch dezentrale Logiken können ausfallen, die Fehlversuche ist dann m.E. trickreicher.

ob bug oder gewolltes Verhalten: für mich macht es keinen Sinn ein Rollo das schon ganz oben/unten ist rauf/runter zu fahren. Bei mir hat die Auf-/Ab-Taste bei Rollo ganz oben/unten die Funktion den Rollo in dieser Lage gegen automatisches Verfahren zu (ent)sperren, mit LED angezeigt. Der Rollo bleibt dann ganz oben/unten und kann nur manuell gefahren werden. Wenn das passiert wird auch entsperrt. Einen Rollo in einer Position <> 0/100% zu halten/sperren, ich finde dafür keinen use case bei uns.

also ja, funktioniert, ich halte es für ne gute Idee.

[ewfwd]

Wenn du eine auf/ab-Fahrt auslöst wird der Kanal meines wissens nach für die volle parametrierte Dauer durchgeschaltet, unabhängig von wo gestartet wurde. ggf kommt der absolute Status 0% bzw 100% bereits wenn der Rollade sich rechnerisch in der Endposition befindet.

Du musst 2mal drücken weil beim ersten drücken quasi aufgrund des Single Object Controls daraus ein Stop-Befehl gemacht wird.

Das ist einfach so und daran ist nichts zu ändern. Abhilfe schafft hier der MDT Aktor mit Fahrzeitmessung. Der kann die Endlage direkt über den Strom erkennen.

[hansblafoo]

muss ja kein zentraler Logikserver sein. Wenn doch, dann Logik kapseln und wiederverwenden.
aber auch dezentrale Logiken können ausfallen, die Fehlversuche ist dann m.E. trickreicher.

ob bug oder gewolltes Verhalten: für mich macht es keinen Sinn ein Rollo das schon ganz oben/unten ist rauf/runter zu fahren. Bei mir hat die Auf-/Ab-Taste bei Rollo ganz oben/unten die Funktion den Rollo in dieser Lage gegen automatisches Verfahren zu (ent)sperren, mit LED angezeigt. Der Rollo bleibt dann ganz oben/unten und kann nur manuell gefahren werden. Wenn das passiert wird auch entsperrt. Einen Rollo in einer Position <> 0/100% zu halten/sperren, ich finde dafür keinen use case bei uns.

also ja, funktioniert, ich halte es für ne gute Idee.

Okay, das ist auch ein Ansatz! Bisher habe ich noch keine Automatiken für die Rollos, vielleicht juckt mich das dann auch nicht mehr so sehr.

Wenn du eine auf/ab-Fahrt auslöst wird der Kanal meines wissens nach für die volle parametrierte Dauer durchgeschaltet, unabhängig von wo gestartet wurde. ggf kommt der absolute Status 0% bzw 100% bereits wenn der Rollade sich rechnerisch in der Endposition befindet.

Du musst 2mal drücken weil beim ersten drücken quasi aufgrund des Single Object Controls daraus ein Stop-Befehl gemacht wird.

Das ist einfach so und daran ist nichts zu ändern. Abhilfe schafft hier der MDT Aktor mit Fahrzeitmessung. Der kann die Endlage direkt über den Strom erkennen.

Hat damit nichts zu tun. ;-) Das dachte ich auch erst, aber erstens habe ich die Aktoren mit Fahrzeitmessung (und die ist natürlich auch aktiv) und zum anderen können zwischen dem nochmaligen Auf und dem späteren Ab Stunden vergehen. Ich muss dann zweimal Ab senden, damit er runterfährt.

[ewfwd]

und zum anderen können zwischen dem nochmaligen Auf und dem späteren Ab Stunden vergehen

Dann goto Support. Ich meine ich habe sowas noch nicht beobachten können und habe den selben Aktor.

Nutze dieses SingleControlObjekt aber nicht "produktiv".

Problem für mich dabei ist: Wenn ich es nutze dann kann ich beim Senden von Auf/Ab Befehl nicht mehr davon ausgehen dass der Aktor auch zwangsweise nach oben oder unten fährt weil der Befehl sofern der Rolladen sich grade bewegt in einem "Stop" verpuffen würde was ich nicht so toll finde.

Besser wäre es wenn man das SCO parallel nutzen können. Geht aber mit der Application meine ich nicht, ist ein entweder/oder.

[DerStandart]

Ich nutze das tatsächlich produktiv und kann keinen Fehler feststellen. Hab aber den Aktor ohne Fahrzeitmessung, von daher wahrscheinlich nicht vergleichbar.

[hjk]

Erstmal ist die Erklärung in Post #3 korrekt. Da es sich aber um die JAL M handelt scheint hier ein anderes Problem vorzuliegen. Dazu müsste man aber erstmal die Parameter kennen, ob der Kanal auch über die Stromerkennung abschaltet.
Hier ist mir nicht klar, ob es sich beim Taster um eine Eintastenfunktion oder Zweitastenfunktion handelt.
Auch die Verbindung der GAs wäre interessant.
Um das Verhalten besser zu verstehen, braucht man eine Gruppenmonitoraufnahme, wo auch der Fahrstatus zu sehen ist.

Grundsätzlich ist die Funktion kompromissbehaftet. Sie hat, je nach Anforderung, Vorteile, aber auch Nachteile.

[Beleuchtfix]

Nur zum Verständnis, ist das Problem zeitnah zum weiteren Fahrbefehl oder wenn er z.B. morgens hochfährt geht er abends nicht mehr runter. (Also erst nach dem 2 Druck?)
Gruß Florian

[TabSel]

Ich glaube mich zu erinnern dass es bei meinen JALB1UP ohne Fahrtzeitmessung so war, dass der Rollo die gesamte fahrtzeitdauer lang einen zweiten Impuls auf das SOC als Stop interpretierte selbst wenn der Rollo schon oben war. Ich weiß nicht mehr ob zuvor Pos0%/StatusOben gesendet wurde.
letztlich hat mich das Verhalten aber so gestört, dass ich das Bedienkonzept meiner Rollos umbaute: Taster einfach:=0 auf SOC, Taster lang:=Position#1(=100%), d.h. TasteLang fährt den Rollo runter, TasteKurz fährt den Rollo hoch oder stoppt eine Fahrt. Damit hab ich ne Ein-Tastenbedienung auf/ab/Stop, erweitert durch nen Eibpc2 um AutomatikSperre setzen/entfernen wenn Rollo eh schon oben/unten.
da die Rollos eh vollautomatisch fahren wollte ich nicht mehr als eine Taste für manuelles fahren „opfern“

[ewfwd]

Ich glaube mich zu erinnern dass es bei meinen JALB1UP ohne Fahrtzeitmessung so war, dass der Rollo die gesamte fahrtzeitdauer lang einen zweiten Impuls auf das SOC als Stop interpretierte selbst wenn der Rollo schon oben war. Ich weiß nicht mehr ob zuvor Pos0%/StatusOben gesendet wurde.

Ja für die Dauer der Fahrzeit. Aber der TE sagt ja dass auch Stunden danach er auch dann 2mal drücken muss. Das scheint tatsächlich ein Bug zu sein.

Aber es kann auch hier andere Gründe haben wie Steuerung über eine Taste zB und der Schalter dann den falschen Befehl sendet.

Rolladen/Jal über eine Taste ist eh Murks für den Alltag.

[hansblafoo]

Dann goto Support. Ich meine ich habe sowas noch nicht beobachten können und habe den selben Aktor.

Dem Support habe ich das schon vor Ewigkeiten gemeldet. Ich habe auch komplette Logs und ein Beispielprojekt geschickt. Eine Teamviewer-Session, in der der MDT-Support meine Parametrierung geprüft hat und in dem ich ihm das Live vorgeführt habe, gab es auch. MDT hat am Ende selbst auch nach Rücksprache mit der Entwicklungsabteilung bestätigt, dass der Aktor sich so verhält, aber sie sagen, es sei kein Bug sondern das erwartete und normale Verhalten. Für mich ist es das nicht. Hätten sie gesagt, dass das keine Priorität hat und sie es deshalb nicht beheben, hätte ich ja akzeptiert. Aber so zu tun, es sei kein Fehler, finde ich dann schon recht stark. Aber sei es drum: MDT will dieses offensichtliche Problem nicht beheben.

Erstmal ist die Erklärung in Post #3 korrekt. Da es sich aber um die JAL M handelt scheint hier ein anderes Problem vorzuliegen. Dazu müsste man aber erstmal die Parameter kennen, ob der Kanal auch über die Stromerkennung abschaltet.
Hier ist mir nicht klar, ob es sich beim Taster um eine Eintastenfunktion oder Zweitastenfunktion handelt.
Auch die Verbindung der GAs wäre interessant.
Um das Verhalten besser zu verstehen, braucht man eine Gruppenmonitoraufnahme, wo auch der Fahrstatus zu sehen ist.

Grundsätzlich ist die Funktion kompromissbehaftet. Sie hat, je nach Anforderung, Vorteile, aber auch Nachteile.

Wie ich schon schrieb, euer Support hat das bestätigt, hält es aber für normal. ;-) Es liegt übrigens auch nicht am Taster, ich brauche einfach nur per ETS auf die entsprechende Gruppenadresse schreiben und kann das Verhalten jederzeit zu 100% reproduzieren.

Nur zum Verständnis, ist das Problem zeitnah zum weiteren Fahrbefehl oder wenn er z.B. morgens hochfährt geht er abends nicht mehr runter. (Also erst nach dem 2 Druck?)
Gruß Florian

Exakt richtig verstanden.

Hier sieht man das übrigens mal als Screenshot (den hat MDT auch bekommen):251104_Screenshot ETS Diagnose Rollladenproblem.png

[beauty]

Hallo,
ich habe gnau das gleiche Problem mit den Jal- Aktoren ohne Fahrzeitmessung. Ich muss morgens oft nach dem ich die "Gute Nacht" Szene im Kinderzimmer deaktiviert habe 2 mal "hoch" drücken damit der Rolladen hochfährt. Ich konnt bisher auch nicht lokalisieren woher das kommt.

[hansblafoo]

Hallo,
ich habe gnau das gleiche Problem mit den Jal- Aktoren ohne Fahrzeitmessung. Ich muss morgens oft nach dem ich die "Gute Nacht" Szene im Kinderzimmer deaktiviert habe 2 mal "hoch" drücken damit der Rolladen hochfährt. Ich konnt bisher auch nicht lokalisieren woher das kommt.

Also wenn du Single Object Control nutzt, wird das wohl die Ursache sein. Kannst du ja mal gezielt per ETS Diagnose versuchen nachzuvollziehen.

[beauty]

Ja ich nutze SOC und werde das die Tage mal näher beobachten und unter doe Lupe nehmen.

[TabSel]

Idee: ist das Verhalten auch nach einer Referenzfahrt reproduzierbar?