Hallo und ein "gutes Neues" in die Runde!
Ich habe mal wieder "Spaß" mit der Bestandsinstallation in einem Zweckbau BJ. 2004.
Zur Steuerung von Jalousie und Licht sind in den Räumen größtenteils Jung 2094 NABS sowie die kleineren Pendants mit vier Tasten verbaut.
Schon länger war mir aufgefallen, dass die Jalousien beim Auslösen einer Fahrt irgendwie sehr seltsam stocken. Daraufhin habe ich mir die Telegramme angesehen.
Ein Mitschnitt ist auf dem Screenshot im Anhang zu sehen.
Erster Test Kurzzeit, alles OK. Das ist Telegramm #6.
Dann langer Tastendruck - Telegramme ab #14. Was würde man erwarten? Einen Fahrbefehl "Ab". Was passiert tatsächlich? Es wird erst kurz der Stopp-/Lamelle-Befehl gesendet (daher auch das kurze Ruckeln des Motors) und dann erst der normale Fahrbefehl gesendet. Einen netten Bonus gibt es noch, wenn man dann nicht noch extra lange wartet (selbst eine Sekunde reicht nicht, wie man an den Zeiten sieht - vgl. Telegramm #14 und #22), sondern den Taster trotz schon getriggertem Langzeitbetrieb zu "früh" wieder loslässt. Dann wird nämlich gleich nochmal ein Stopp-Telegramm gesendet.
Das Ganze ist a) maximal nervig und b) natürlich auch nicht unbedingt gesund für Motor und Aktor. OK, fairerweise läuft das ja schon so seit 20 Jahren, aber es entlockt einem ja trotzdem ein maximales Kopfschütteln.
Was übersehe ich? Die Parameter sind ja höchst übersichtlich, siehe zweiten Screenshot - ich wüsste nicht, was der Vorgänger da verkehrt gemacht hätte und was man da noch anpassen könnte, um das zu beheben. Ist das also wirklich mal wieder ein Bug aus der Kategorie "ist halt so, musste mit leben"? Eine sinnvolle Begründung, dass das tatsächlich gewollt sein könnte, will mir partout nicht einfallen. Ein Schutz gegen direktes Reversieren, der zumindest das anfängliche, "prophylaktische" Stopp-Telegramm erklären könnte, ist ja vermutlich schon immer in sämtlichen Jalousieaktoren direkt implementiert.
Summa summarum haut das wahrscheinlich wieder in gleiche Kerbe wie der von mir entdecke Bug bei den Gira Präsenzmeldern. Wirft dann leider zum wiederholten Mal alles andere als ein gutes Bild auf die Softwareentwickler grade bei den "großen" Herstellern...
Wobei, eines erschließt sich mir tatsächlich nicht so recht: Warum stelle ich im Taster (!) eine Lamellenverstellzeit ein? Das ist doch eine Sache des Aktors, was er wie lange / überhaupt (Jalousie vs. Rolladen) nach einem Telegramm auf die GA für "Stopp/Lamelle" macht. Liegt vielleicht da der Hund begraben und bei "falschen" Zeiten kommt es zu so einem Phänomen, dass mehrfach Telegramme gesendet werden? Hatte aber auch schon mal mit den Werten experimentiert, ohne Verbesserung, zumindest im Hinblick auf das erste Problem. Die Sache mit dem Anhalten bei zu frühem Loslassen müsste ich nochmal checken. Die 8ms * 250 wären ja genau diese zwei Sekunden, innerhalb der es Probleme gibt. Das wäre sogar alles noch einigermaßen erklärbar, quasi als "manuelle, verlängerte Lamellenverstellung" über das Langzeitobjekt, anstatt über Kurzzeit und nur mit der im Aktor vordefinierten Zeit.
Edit: OK, nochmals die Applikationsbeschreibung konsultiert. Das mit der Lamellenverstellzeit ist tatsächlich so wie von mir vermutet. Auf die Idee wäre ich aber initial schlicht nicht gekommen, ist ja auch (zumindest vom heuten Verständnis für Lamellenverstellung her, eventuell war das vor 20 Jahren anders) völliger Käse. Bei den MDT-Tastern gibt es das z.B. zurecht gar nicht. Aber damit wird das zumindest erklärbar und sollte auch lösbar sein. Es bleibt die (Haupt-)Frage, was man gegen das unnötige Stopp-Telegram am Anfang unternehmen kann.
Ich habe mal wieder "Spaß" mit der Bestandsinstallation in einem Zweckbau BJ. 2004.
Zur Steuerung von Jalousie und Licht sind in den Räumen größtenteils Jung 2094 NABS sowie die kleineren Pendants mit vier Tasten verbaut.
Schon länger war mir aufgefallen, dass die Jalousien beim Auslösen einer Fahrt irgendwie sehr seltsam stocken. Daraufhin habe ich mir die Telegramme angesehen.
Ein Mitschnitt ist auf dem Screenshot im Anhang zu sehen.
Erster Test Kurzzeit, alles OK. Das ist Telegramm #6.
Dann langer Tastendruck - Telegramme ab #14. Was würde man erwarten? Einen Fahrbefehl "Ab". Was passiert tatsächlich? Es wird erst kurz der Stopp-/Lamelle-Befehl gesendet (daher auch das kurze Ruckeln des Motors) und dann erst der normale Fahrbefehl gesendet. Einen netten Bonus gibt es noch, wenn man dann nicht noch extra lange wartet (selbst eine Sekunde reicht nicht, wie man an den Zeiten sieht - vgl. Telegramm #14 und #22), sondern den Taster trotz schon getriggertem Langzeitbetrieb zu "früh" wieder loslässt. Dann wird nämlich gleich nochmal ein Stopp-Telegramm gesendet.
Das Ganze ist a) maximal nervig und b) natürlich auch nicht unbedingt gesund für Motor und Aktor. OK, fairerweise läuft das ja schon so seit 20 Jahren, aber es entlockt einem ja trotzdem ein maximales Kopfschütteln.
Was übersehe ich? Die Parameter sind ja höchst übersichtlich, siehe zweiten Screenshot - ich wüsste nicht, was der Vorgänger da verkehrt gemacht hätte und was man da noch anpassen könnte, um das zu beheben. Ist das also wirklich mal wieder ein Bug aus der Kategorie "ist halt so, musste mit leben"? Eine sinnvolle Begründung, dass das tatsächlich gewollt sein könnte, will mir partout nicht einfallen. Ein Schutz gegen direktes Reversieren, der zumindest das anfängliche, "prophylaktische" Stopp-Telegramm erklären könnte, ist ja vermutlich schon immer in sämtlichen Jalousieaktoren direkt implementiert.
Summa summarum haut das wahrscheinlich wieder in gleiche Kerbe wie der von mir entdecke Bug bei den Gira Präsenzmeldern. Wirft dann leider zum wiederholten Mal alles andere als ein gutes Bild auf die Softwareentwickler grade bei den "großen" Herstellern...
Wobei, eines erschließt sich mir tatsächlich nicht so recht: Warum stelle ich im Taster (!) eine Lamellenverstellzeit ein? Das ist doch eine Sache des Aktors, was er wie lange / überhaupt (Jalousie vs. Rolladen) nach einem Telegramm auf die GA für "Stopp/Lamelle" macht. Liegt vielleicht da der Hund begraben und bei "falschen" Zeiten kommt es zu so einem Phänomen, dass mehrfach Telegramme gesendet werden? Hatte aber auch schon mal mit den Werten experimentiert, ohne Verbesserung, zumindest im Hinblick auf das erste Problem. Die Sache mit dem Anhalten bei zu frühem Loslassen müsste ich nochmal checken. Die 8ms * 250 wären ja genau diese zwei Sekunden, innerhalb der es Probleme gibt. Das wäre sogar alles noch einigermaßen erklärbar, quasi als "manuelle, verlängerte Lamellenverstellung" über das Langzeitobjekt, anstatt über Kurzzeit und nur mit der im Aktor vordefinierten Zeit.
Edit: OK, nochmals die Applikationsbeschreibung konsultiert. Das mit der Lamellenverstellzeit ist tatsächlich so wie von mir vermutet. Auf die Idee wäre ich aber initial schlicht nicht gekommen, ist ja auch (zumindest vom heuten Verständnis für Lamellenverstellung her, eventuell war das vor 20 Jahren anders) völliger Käse. Bei den MDT-Tastern gibt es das z.B. zurecht gar nicht. Aber damit wird das zumindest erklärbar und sollte auch lösbar sein. Es bleibt die (Haupt-)Frage, was man gegen das unnötige Stopp-Telegram am Anfang unternehmen kann.
Kommentar