Rollläden fahren nicht herunter / herauf

[Sven_A]

...dann führt die CCU die Sendebefehle auch in dieser Reihenfolge durch - und zwar einen nach dem anderen. Dabei wartet die CCU natürlich immer das "ok"-Rückmelden des jeweiligen Aktors ab, BEVOR der nächste Sendebefehl rausgeht. ...

Das sind zwei Annahmen. Die erste davon ist definitiv falsch. Die Reihenfolge im Programm sagt nichts über die Reihenfolge in der Abarbeitung der Befehle aus. Mach doch mal ein Programm:

Licht 1 verzögert um 2 Sekunden an.
Licht 2 sofort an.

Nach deiner Logik müsste dann nach 2 Sekunden erste Licht 1, und dann (fast) Zeitgleich Licht 2 angehen. So ist es aber nicht.

Wie kommst du also drauf das deine zweite Annahme (Abwarten der ACK Meldungen) stimmt?

Gruß,
Sven

[Xel66]

Jetzt überleg mal: Wenn im Pgm alle Aktoren nacheinander angesprochen werden, dann führt die CCU die Sendebefehle auch in dieser Reihenfolge durch - und zwar einen nach dem anderen. Dabei wartet die CCU natürlich immer das "ok"-Rückmelden des jeweiligen Aktors ab, BEVOR der nächste Sendebefehl rausgeht.

...Versus...

Es werden alle Aktoren schnellstmöglich von der CCU angesprochen (die fahren "fast" zeitgleich hoch).

Ja was denn nun? Irgendwie widersprechen sich die beiden Äußerungen. Die CCU wird bei Programmabarbeitung die Befehle so schnell wie möglich raushauen. Die Aktorik aber wird entsrpechend ihrer eigenen Verzögerungen antworten. Und gerade bei klassischen Aktoren, die kein listen before talk machen, senden alle (CCU und Aktoren) in diesem Szenario schnell gemeinsam, so dass Kommunikationsstörungen zwangsläufig sind. Das deckt sich auch mit den Erfahrungen, die andere Anwender machen. Nur Du bist anderer Meinung. Und es geht hier um klassische Aktorik (HM-LC-Bl1PBU-FM). Mit "Die Probleme gab's früher (ist aber schon laaange her) aber dann..." ist da nix. Das ist immer noch so.

Gruß Xel66

[MichaelN]

Das sind zwei Annahmen. Die erste davon ist definitiv falsch. Die Reihenfolge im Programm sagt nichts über die Reihenfolge in der Abarbeitung der Befehle aus.

Das wird immer wieder behauptet, ich glaube aber das es ein Trugschluss aus dem beobachteten Verhalten ist. Nur weil ein Funkbefehl nicht in der erwarteten Reihenfolge ankommt, bedeutet das nicht, daß er ungeordnet gesendet wurde. Hier müssen wir 2 Dinge unterscheiden: aussenden des Befehls und erfolgreiches (!) Empfangen des Befehls.

Denn: auch das Betriebssystem der CCU arbeitet streng deterministisch. Oder glaubst du, das die CCU erstmal alle Befehle sammelt, diese dann in einem Zufallsgenerator durcheinander würfelt und in der neuen Reihenfolge aussenden? Nein, bestimmt nicht. Das macht einfach keinen Sinn. Also werden die Befehle strikt in der Reihenfolge abgearbeitet.

Das es wegen Empfangsproblem zu wiederholten Aussendeungen kommen kann und so im Endeffekt Befehl 2 den Befehl 1 überholt, ist andere ganz andere Sache. Wenn Du das allerdings gemeint hast, dann ignoriere den Sermon.

[Sven_A]

...Oder glaubst du, das die CCU erstmal alle Befehle sammelt, diese dann in einem Zufallsgenerator durcheinander würfelt und in der neuen Reihenfolge aussenden?...

Nein, ich meinte das die angezeigte Reihenfolge in der WebUI nicht unbedingt etwas damit zu tun hat was intern passiert. Meistens wird das Stimmen, aber bei editierten Programmen würde ich mich nichtmehr darauf verlassen. Es gibt ja durchaus Programme die ein "Eigenleben" entwickelt haben.

Das es wegen Empfangsproblem zu wiederholten Aussendeungen kommen kann und so im Endeffekt Befehl 2 den Befehl 1 überholt, ist andere ganz andere Sache. ..

Und genau das wurde bestritten. Weiter oben wurde von hel400 behauptet das genau das nicht passieren kann, weil Befehl 2 erst rausgeht wenn die CCU das ACK für Befehl 1 erhalten hätte. Und dem hatte ich widersprochen.

WIR beide sind uns also durchaus einig

[rentier-s]

Es geht aber um die "Fertig"-Meldung wenn ein Rollladen komplett hoch/runtergefahren ist - genau diese Abschlussmeldung kann man einstellen und dann gibt's weder ein Ballett noch Funkprobleme!

Damit hast Du einen Denkfehler. Das Problem sind nicht die Statusmeldungen, für den haben die klassischen HM Aktoren extra den Zufallsanteil. Also falls wirklich zwei Rollläden gleichzeitig oben sind, warten sie zufällig unterschiedlich lang, bevor sie den Status senden.

Das eigentliche Problem sind die Rückmeldungen auf den Befehl der CCU. Also sozusagen das "verstanden, fahre hoch". Die CCU wartet sehr sicher nicht darauf, bevor sie den nächsten Aktor anfunkt. Spricht man alle Aktoren ohne Programmverzögerung in einem Rutsch an, kann es bei den klassischen Aktoren passieren, dass sich die Bestätigungen der Aktoren mit dem weiteren Funkverkehr der CCU in die Quere kommen. HMIP lauscht vor dem Senden erst, ob die Frequenz frei ist.

Ich benutze den Status der Rollläden teilweise als Trigger für Programme. Die Dunstabzugshaube läuft nur, wenn die Luftklappe am Holzoffen geschlossen, oder ein Fenster samt zugehörigem Rollladen offen ist. Da wäre es extrem nervig, nachdem der Rollladen oben ist, erst nochmal eine halbe Minute warten zu müssen, bis der Dunstabzug an geht, nur um Funkprobleme morgens und abends zu vermeiden. Deshalb haben die Aktoren bei mir alle die obligatorische 1 Sekunde Meldeverzögerung und 1s Zufallsanteil.

[Braeuni]

Moin,

leider konnte ich hier lange nicht weiterverfolgen.

Das Problem bleibt. Bei zwei Rolläden zeigen sich immer noch Probleme.
Wartenzeiten sind eingefügt.
Der Wohnzimmerrollo fährt manchmal abends nicht herunter und morgens nicht herauf.
Der Rollo im Kinderzimmer von meinem Sohn fährt abends nicht herunter.

Fehlermeldungen in der CCU3 gibt es nicht. Manuelle Bedienung am Aktor ist problemlos möglich.
Stromlos machen und wieder anschalten bringt keinen Unterschied.

Was kann ich noch tun?

Grüße,
Bräuni

[MichaelN]

Du könntest mal die Programme hier zeigen.

Oder Du wendest dies hier viewtopic.php?f=18&t=60764&start=10#p602658 gezeigte Technik an, die den Rollo solange ansteuert, bis er sich endlich mal bewegt.

Btw: Wenn Du in der WebUI den Rollo bedient, bewegt er sich schon?!