Zentral-Rollo Baustein reagiert anders als Rollo Baustein

[t_heinrich]

Hallo zusammen,

ich habe 2 Rollläden im Wohnzimmer.

• wenn ich bei einer aktiven Fahrt bei einem einzelnen Rollo "auf", "ab" drücke, stoppt das Rollo
• wenn ich bei einer aktiven Fahrt bei dem Zentral-Rollo "auf", "ab" drücke, stoppen die Rollos kurz und setzen dann die Fahrt fort
• um Zentral-Rollo zu stoppen, muss ich in den Baustein und den Lammellen Button drücken

Kann man das Verhalten des Zentral-Rollo so beeinflussen, dass es sich genauso wie ein einzelnes Rollo verhält?
Wieso gibt es überhaupt dieses unterschiedliche Verhalten, hab ich hier was übersehen?

Gruß Thomas

[romildo]

Hallo,
Ich habe das Verhalten vor einiger Zeit bei Loxone bemängelt. Deren Aussage war, dass das so gewollt ist.
Vielleicht hilft da eine erneute Supportanfrage von Dir.
Wenn Du an Stelle des "Beschattung Zentral" den Zentralbaustein nimmst, funktioniert dies wie erwartet.

[t_heinrich]

Hallo,
Ich habe das Verhalten vor einiger Zeit bei Loxone bemängelt. Deren Aussage war, dass das so gewollt ist.

Wenn man so einen Blödsinn liest - was soll denn daran gewollt sein, dass das Ganze für ne Sekunde stoppt und dann weiterfährt?

Danke für den Hinweis mit dem Zentralbaustein, dass probiere ich mal aus.

Und den Support schreibe ich auch mal, werde die Antwort dann hier posten.

[Christian Fenzl]

Ich bemängle ja beim AutoJalo-Baustein, dass ein Cu und Cd nicht _sicher_ funktioniert: Fährt der Rolladen gerade, stoppt ein Cu oder Cd einfach, statt die Position anzufahren. Somit lässt sich eine Komplettfahrt nicht automatisieren, wenn die Fahrt dann nur meistens und nicht immer ausgeführt wird.

In einem Zentralbaustein würde ich das begrüßen, wenn Cu und Cd IMMER funktioniert, EGAL was die Beschattung gerade macht.

Aber Stoppen und dann einfach Weiterfahren ist ja auch nicht das, was man sich erwarten würde.

Aber wie immer: Wenn 10 Leute sich das Verhalten A wünschen, und 10 das Verhalten B, dann macht Loxone doch immer das Verhalten C, weil sie es besser wissen, und es kann sich keiner beschweren, weil keiner das bekommen hat, was gebraucht würde ;-)

[Christian Fenzl]

Also der Zentral-Jalo-Baustein fährt eh in die gewünschte Richtung? Dann passt eh alles ;-)

Wenn eine Logik sagt, „Auf“, dann soll sie ja wirklich auf fahren, und nicht einfach stehen bleiben, nur weil sie - z.B. per Visu getriggert - schon unterwegs ist.

[romildo]

Wenn aber die Logik im Anschluss darauf, durch ein Stopp-Kommando sagt, dass sie stoppen soll, dann würde ich das von ihr auch erwarten.
Zumindest dann, wenn auch alles andere auf den letzten Eingangsbefehl reagiert.

[Christian Fenzl]

Natürlich - nur so macht das Sinn.

[t_heinrich]

Hallo,

der Loxone-Support hat mir auch den Hinweis mit dem „normalen“ Zentralbaustein gegeben, soweit so gut, das probiere ich noch aus.

Auch wurde mir mitgeteilt, dass das kurze Stoppen und weiterfahren so gewollt ist.
Auf meine Nachfrage, welcher Sinn dahintersteckt, kann man mir (noch) keine konkrete Antwort geben:

genau kann ich Ihnen dass momentan auch nicht sagen, aber ich glaube es technisch nicht anders gegangen, besonders wegen der Motorverriegelung und Totzeit

[Robert L.]

ja, alle 3 (Jalou, zentral-Jalou, und Zetral.baustein) machen was anders..
ist eben so "gewachsen" und loxone ändern keine Funktionaltiät (mehr) von bestehenden Bausteinen..

Problem beim "ich will dass es Stoppt, wenn sie fahren": wenn EINE Jalousie fährt und eine nicht.. gibt das "lustige" Effekte..
DAS war das Hauptkritikpunkt bisher..
deshalb z.b. auch das nachgereichte "sychroniesieren" durch langclickt beim normalen Zentralbaustein..

beim jalou-zentral wollte man es (vermutlich) gleich "besser" machen..

im Grunde musst du dir ein Vorgehen ausdenken: z.b. wenn EINE jalousie der gruppe fährt, müssen bei tastendruck erstmal ALLE stehen bleiben..
wenn ALLE stehen darf bei tastendruck gefahren werden, oder so ähnlich

wie du das umsetzt.. keine Anhung.. mit viel logik vielleicht..

Problem ist dann eher, wenn man eigentlich den Zentralbaustein in der VISU verwenden möchte, das heißt es friss oder stirb..

[romildo]

Das für mich unverständliche ist nur, dass die Funktionsweise der "Beschattung Zentral" sich nicht so verhält wie die Jalousie.
Erwarten würde zumindest ich, dass bei einem Tastendruck auf AB alle Jalousien nach unten fahren und bei einem erneuten Tastendruck auf AB alle stoppen.

Jetzt ist es ja so, dass beim ersten Tastendruck die Jalousien losfahren, beim zweiten Tastendruck stoppen und nach Ablauf der Zeit Tc weiter fahren.
Und das ist wirklich so gewünscht?

Dass Loxone bei bestehenden Bausteinen nichts mehr ändert, müsste sich dann aber auf Zukünftige Versionen beziehen. Zumindest bisher ist dies nicht zutreffend

[t_heinrich]

Ich finde es in dem Zusammenhang eher schade das Loxone oft die Standardantwort gibt: „das ist so gewollt“ und wenn man dann mal weiter fragt kommt nichts (nachvollziehbar Vernünftiges).

[Robert L.]

>Erwarten würde zumindest ich,
was erwartest du für den Fall das eine Jalousie bereits fährt und eine andere nicht..

[romildo]

Ich würde erwarten, dass eine gewisse "Intelligenz" in der Software programmiert ist.
Ganz einfach gesagt, wurde der Zentralbefehl in den letzten Minuten nicht ausgelöst, würde ich davon ausgehen, dass alle fahren sollen.
Wurde der Befehl hingegen vor ein paar Sekunden schon mal gegeben, könnte man annehmen dass jetzt gestoppt werden soll.

Ohne es irgendwie getestet zu haben, könnte ich es mir Beispielsweise wie folgt vorstellen:
Aus meiner Sicht müssten die Jalousiebausteine den Zentralbefehl als solchen erkennen und die jeweilige Jalousie in den gewünschten Modus versetzen.
Die Jalousiebausteine, müssten den Befehl bestätigen, damit der Zentralbaustein weiss, wann er vom Fahrmodus in den Stoppmodus wechseln darf.

Wird Taste Cd gedrückt, bekommen alle Jalousien den Befehl für Ab.
Jalousie A steht zu diesem Zeitpunkt, fährt nach dem Befehl sofort los und gibt die Bestätigung an den Zentralbaustein.
Jalousie B fährt zu diesem Zeitpunkt ab, wird durch den Befehl nochmals neu auf ab gesetzt und die Rückmeldung an den Zentralbaustein gesendet.
Jalousie C fährt zu diesem Zeitpunkt auf, wird durch den Befehl zuerst auf gestoppt und dann auf ab gesetzt, danach auch an den Zentralbaustein zurückgemeldet.
Melden bei erneutem Tastendruck auf Cd nicht alle Jalousien den Status Ab zurück wird nochmals das Kommando Ab gesendet, andernfalls das Kommando Stopp.

[Christian Fenzl]

Loxone hat in Ihrem Produkt die eigenen Bedienkonzepte "übersehen", und das wirkt sich besonders bei der AutoJalo, aber auch bei anderen Bausteinen aus:

Ein Bedienkonzept ist die humane Bedienung, also eine Person drückt wo drauf und diese Aktion löst Ereignisse aus.

Das zweite Bedienkonzept ist die Automatisierung bzw. Vernetzung, wo Sensorik oder die Änderung von Bedingungen Aktionen auslöst.

Einige Bausteine sind exklusiv für die Automatisierung implementiert, aber manche - besonders die AutoJalo - ist auf ein händisches Bedienkonzept ausgelegt. Bei diesem Baustein zieht sich das von vorne bis hinten durch, dass alles für eine Schalter- oder App-Bedienung gebaut sind, aber die Automatisierung nicht berücksichtigt ist.

Das wirkt sich dahingehend aus, dass wir in einem sogenannten "Real SmartHome" sitzen, wo wir uns Stunden damit auseinandersetzen, irgendwelche Workarounds um die "AutoPiloten" zu basteln, weil die Bausteine nicht automatisierbar sind.

Bei der AutoJalo ist das genau so: Cu und Cd sind genau dafür gebaut, dass ein Mensch eine Fahrt starten und wieder stoppen kann. In der Loxone-internen, automatisierten Programmierung lässt sich deswegen eine Jalousie nicht zuverlässig per Logik bedienen. Dabei reden wir noch von reinen Loxone-Komponenten, ohne irgendwelchen Interfaces zu anderen Schnittstellen oder Bussen.
Das gleiche gilt in der AutoJalo für den Automatik-Betrieb. Der auch durch Eingriffe einer Logik immer sofort abschaltet, und mit schrägen Implementierungen (insgesamt gibt es alleine 3 Eingänge, die die Aktivierung der Automatik betreffen) immer wieder manuell aktiviert werden will, damit er funktioniert.

So stellen sich manche Bausteine selbst ein Bein und wir basteln seitenweise bunt in der Loxone Config herum, damit ein (als Neukunde eigentlich als De-facto-Standard erwartetes) Verhalten irgendwie hinzubekommen ist.

In diese Gruppe der schwer automatisierbaren Bausteine fällt z.B. auch die Lichtsteuerung (neuer Stolperstein: SmartAktor Ausgang nicht auswertbar), der Status-Baustein (Änderung eines Ausgangs kann nicht identifiziert werden), oder etwa die Tor-Steuerung, die bei Eintastenbetrieb selbst bei 3 definierten Zuständen nicht schlau genug ist, die Ziellage anzufahren.

Und somit gleiten jetzt die Anforderungen von uns Kunden auseinander, und wegen mäßiger Abstimmung im Entwicklungsteam dann offenbar auch die Umsetzungen.

Und es gibt bei der Jalo diese beiden Anforderungen: Manuell bedienbar mit der Erwartung, dass ein zweites Drücken eine Fahrt wieder stoppt; und automatisiert bedienbar, wo wenn ich sage "Auf" dann auch wirklich "Auf" zu fahren ist, und nicht „Vielleicht Auf", „vielleicht auch Stopp", oder "garnichts".