viele Rolladenaktoren synchron schalten

[Klaus0815]

Situation: Haus umgebaut, 13 Rolladenaktoren, teils nicht optimale Empfangsbedingungen.

Die Rolläden sollen jetzt bei Sonnenaufgang synchron aufgehen, abends wieder zu
Momentan werden diese einfach über "Structure" in FHEM angesteuert

Leider dauert das Ganze oft ein wenig / wirkt sehr zäh
Meinem Verständniss nach kommt das durch die bi-direktionale Kommunikation, Rolladen 1 wird getriggert - Antwort abgewartet, dann Rolladen 2 usw.

Ich könnte jetzt virtuelle Taster anlegen, die Aktoren alle mit diesen peeren - bringt das was?
Ist wohl auch ein riesen Aufwand, wenn man dann noch mehrere Gruppen hat, wieviel peers kann so ein AKtor?

Irgendwo habe ich auch mal was gelesen, das man das System so "verbiegen" kann das erst alle Befehle an die Aktoren geschickt werden, bevor auf Antworten gewartet wird?
Leider finde ich diesen Beitrag nicht mehr - macht es Sinn über so was nachzudenken?

Mir wäre lieber 11 der 13 Rolläden laufen zeitgleich los, die beiden mit schlechtem Empfang dann halt 5 sec später

Viele Grüße

Klaus

[Otto123]

Hallo Klaus,

ich habe 13 Rollladenaktoren - wirklich!
Ich starte die mit set Rollo.* - ich habe das Gefühl es geht im Sekundentakt oder sogar kürzer.

Da es mich so nicht stört habe ich es so gelassen.

Was Du wohl machen kannst:
Alle mit einem virtuellen Kanal als Taster peeren. Wenn du dann diesen Taster drückst, laufen sie wohl alle gleichzeitig los.
Nur Theorie, habe ich mal irgendwo gelesen, muss nicht stimmen, kann ich falsch verstanden haben.

Gruß Otto

[Klaus0815]

Hallo Otto,

Alle mit einem virtuellen Kanal als Taster peeren.

So hatte ich es auch gemeint - bräuchte nur dann wohl trotzdem mehrere virtuelle Kanäle, 1 x "alle Rolläden", 1 x " Gruppe EG", 1 x "Gruppe OG", 1 x Gruppe "Wohnzimmer" ....

Das gibt wohl leider alleine einen Tagelangen Tippaufwand bis das alles gepeert ist ?

[Otto123]

Moin,

naja ein Script durch copy&paste und vielleicht ein Template. Das geht schon.

Aber ich habe gerade nochmal geschaut: Bei mir wird der Befehl set Rollo.* in etwa 600 msec (laut FHEM Log) für alle 13 Aktoren aufgelöst und abgesetzt. Die Rollläden fahren einer nach dem anderen los aber - ja rechts und links vom Haus nicht synchron.
Ist das wirklich ein Problem?

Was auch noch den Vorteil hat, dass der gemeinsame Stromstoss von 13 anlaufenden Motoren nicht vorhanden  ist 

Gruß Otto

[frank]

ausserdem erweckt ein sequentielles fahren mit unterschiedlichen pausenzeiten den anschein, dass jemand gemütlich durch das haus schlendert, um die rollos zu öffnen.

=> anwesenheitssimulation

[Joker]

Ich schalte bei mir auch alle einfach mit set Rollo.*
Würde auch sagen dass die Verzögerung unter einer Sekunde liegt, aber habe es nie kontrolliert. Es ist ja eh so dass die Rollos evtl. (bei mir definitiv) unterschiedlich groß sind (kleines Badfenster gegen Bodentiefes Wohnzimmerfenster, Terrassentür etc), und somit die Fahrzeit sowieso unterschiedlich ist. Von daher wüßte ich nicht warum das ein Problem sein sollte wenn die leicht versetzt anfangen zu laufen.

[Beta-User]

Komme max auf 18 , allerdings fahren immer nur welche "gleichzeitig", die (u.a.) einen bestimmten Status haben, der mit FILTER abgefragt wird. Das geht zwar auch alles ratzfatz, aber man kann hören, dass die Rolläden nicht ganz gleichzeitig anfangen.
Für eine Anwenseheitssimulation taugt das m.E. aber nicht, so schnell kann ich nicht "gemütlich durch's Haus schlendern" ), für eine Anwesenheitssimulation würde ich eher für die Rolladenssteuerung von cluni plädieren oder eine eigene myUtils-Lösung mit Zufallszahlen, temporären at-Definitionen für jeden Rollanden usw. .

Bei structure ist unter Umständen automatisch ein delay eingebaut (braucht man nach meinem Kenntnisstand uU. bei IT-Aktoren), das kannst du ja mal nachsehen und ggf. verringern.

Zurück zur Ausgangsfrage:
Was das direkte pairen angeht, finde ich leider keine Angaben dazu in den Bedienungsanleitungen, meine mich aber erinnern zu können, dass man jeweils max. 6 peers definieren kann. Das sollte zwar für den Normalfall ausreichen, wenn man nicht zusätzlich noch ein direktes peering mit diversen (realen) Tastern realisieren will (so habe ich das teilweise gemacht und deswegen auf virtuelle Taster als peers weitestgehend verzichtet).

Gruß, Beta-User

[dadoc]

Ich habe insgesamt 14 Rolladenaktoren im Einsatz, gemischt aus (noch hauptsächlich) FS20MS2, Homematic und eigenen Relaislösungen auf FS20- und Homematic-Basis.
Meine Erfahrung ist, dass die FS20-Altoren dank des Gruppencodes absolut synchron reagieren, was in meinem Fall optisch wichtig ist: Dachwohnung in denkmalgeschütztem Haus, wo immer zwei identische, teilweise sehr kleine Fenster direkt nebeneinander sind. Da sieht es von innen extrem doof aus, wenn der rechte Rolladen eine Handbreit tiefer hängt als der linke.
Bei den (noch wenigen) auf Homematic umgerüsteten stelle ich fest, dass es - egal ob per DOIF/notify oder per structure - einen zeitlichen Versatz zwischen der Schaltung der Aktorenpaare gibt, der dann zu unterschiedlichen Höhen führt.
Momentan bereue ich es daher, von FS20auf Homematic umzurüsten.
Grüße
Martin

[Otto123]

Hallo Martin,

und hast Du mal probiert, zwei dieser Laden (ein Fensterpaar) mit einem Sender peerst? Fahren sie dann synchron?

Ich habe einige sehr große Fenster nebeneinander, die zweier Pärchen bilden. Dort habe ich einfach Koppelrelais genommen und mir somit ca. 1/3 der Aktoren gespart.

Gruß Otto

[Klaus0815]

Meine Erfahrung ist, dass die FS20-Altoren dank des Gruppencodes absolut synchron reagieren,

Genai so geht es mir auch - bin wohl FS20-verwohnt, mit all seinen Nachteilen

Wenn es Dir aber nur darum geht, das die Rolläden letztendlich "glaich halb offen" sind, lass sie doch bei Homematic auf definierte Positionen fahren?
Musst halt ein mal die Laufzeit einprogrammieren

[dadoc]

Hallo Otto,

und hast Du mal probiert, zwei dieser Laden (ein Fensterpaar) mit einem Sender peerst? Fahren sie dann synchron?

Ja, ich habe zwei an einem Kanal eines HM-Sender gepeert. Da laufen sie (meistens) synchron. Aber wenn ich auf anderen Wegen schalte (z.B. ftui mit Slider oder über notify oder doif, dann hapert's.

Ich habe einige sehr große Fenster nebeneinander, die zweier Pärchen bilden. Dort habe ich einfach Koppelrelais genommen und mir somit ca. 1/3 der Aktoren gespart.

Hatte ich beim Googeln in Deinem Blog gelesen, interessant. Ich muss manchmal allerdings die Doppel-Läden auch einzeln bedienen können, z.B. zur Reinigung. Ließe sich zwar auch mit Relais bewerkstelligen. Aber das Problem hier wäre ja dann, dass man keine unterschiedlichen Fahrzeiten einstellen kann (die ich trotz identischer, nebeneinander liegender Läden teilweise habe...).
Grüße
Martin

[Beta-User]

@dadoc

Das synchrone Starten von FHEM aus geht (nur) dann, wenn du nicht mehrere Befehle sendest, sondern wie bei einem Tastendruck auf einer gepeerten Fernbedienung je Päarchen _einen_. Dazu müsstest du die Rolläden jeweils mit einem virtuellen Taster(paar) (z.B. einer VCCU) peeren und dann diesen "short" bedienen (vgl. hier: https://wiki.fhem.de/wiki/Virtueller_Controller_VCCU#Virtuelle_Kan.C3.A4le_der_VCCU).

[dadoc]

d.h. Structure wird zum Senden wieder in Einzelbefehle zerlegt?

[Beta-User]

d.h. Structure wird zum Senden wieder in Einzelbefehle zerlegt?

Auszug aus der commandref zu structure:

async_delay Wenn dieses Attribut gesetzt ist, werden ungefilterte set Kommandos nicht sofort an die Clients weitergereicht. Stattdessen werden sie einer Warteschlange hinzugefügt, um später ausgeführt zu werden. Das set Kommando kehrt sofort zurück, die Clients werden danach timer-gesteuert einzeln abgearbeitet. Die Zeit zwischen den Timer-Aufrufen ist dabei durch den Wert von async_delay (in Sekunden) gegeben, ein Wert von 0 entspricht der schnellstmöglichen Abfolge. So können besonders lange Verzögerungen, die gerade bei großen structures vorkommen können, in unproblematischere Häppchen zerlegt werden.

Lese das so: Es werden immer alle Devices einzeln angesteuert. Da CUL_HM (oder was auch immer) für jeden Befehl etwas Zeit benötigt bzw. das IO eine eigene Queue hat, gibt es Verzögerungen.

Der einzige Weg, der da raus führt, ist eben, das in "Hardware" zu realisieren, also nur die _eine_ Info zu versenden, dass ein bestimmter Knopf (virtuell) gedrückt wurde. Auf diese _eine_ Info reagieren dann alle gepeerten Aktoren . Das IO wartet dann die ACK's ab und wiederholt ggf. _dieselbe_ Message, wenn nicht rechtzeitig alle Acks eingehen (für echte Hardware-Knöpfe zu erkennen an einer bestimmten Nummer im Event-Monitor). Danach können die Empfänger(-Aktoren) entscheiden, ob sie noch darauf reagieren sollen (und ggf. nur nochmal ein Ack senden). (Edit im Hinblick auf die zutreffenden Hinweis von betateilchen).

(Hoffe, das war jetzt halbwegs verständlich erklärt).

Gruß, Beta-User

[betateilchen]

Auch bei nur einem virtuellen Taster werden die Rolläden nicht gleichzeitig loslaufen, weil auch dann die Kommunikation von Homematic nacheinander an die peers geschickt wird. Homematic selbst und alleine kann das zwar viel schneller als die Implementierung in FHEM. aber eine 100% synchrone Schaltung wird es nicht geben.

Was das direkte pairen angeht, finde ich leider keine Angaben dazu in den Bedienungsanleitungen

Du meinst peeren, nicht pairen.

d.h. Structure wird zum Senden wieder in Einzelbefehle zerlegt?

Ja. Es wird pro device ein Befehl generiert und von FHEM ausgeführt.