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
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
Hallo Otto,
ZitatAlle 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 ?
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 ;D
Gruß Otto
ausserdem erweckt ein sequentielles fahren mit unterschiedlichen pausenzeiten den anschein, dass jemand gemütlich durch das haus schlendert, um die rollos zu öffnen.
=> anwesenheitssimulation
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.
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" ;D ), 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
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
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
ZitatMeine 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
Hallo Otto,
Zitat von: Otto123 am 30 August 2018, 19:58:44
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.
Zitat
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
@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).
d.h. Structure wird zum Senden wieder in Einzelbefehle zerlegt?
Zitat von: dadoc am 31 August 2018, 12:53:43
d.h. Structure wird zum Senden wieder in Einzelbefehle zerlegt?
Auszug aus der commandref zu structure:
Zitatasync_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
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.
Zitat von: Beta-User am 27 August 2018, 16:57:54
Was das direkte pairen angeht, finde ich leider keine Angaben dazu in den Bedienungsanleitungen
Du meinst peeren, nicht pairen.
Zitat von: dadoc am 31 August 2018, 12:53:43
d.h. Structure wird zum Senden wieder in Einzelbefehle zerlegt?
Ja. Es wird pro device ein Befehl generiert und von FHEM ausgeführt.
Zitat von: betateilchen am 31 August 2018, 13:48:44
Du meinst peeren, nicht pairen.
:o klar...
Zitat von: betateilchen am 31 August 2018, 13:48:44
Homematic selbst und alleine kann das zwar viel schneller als die Implementierung in FHEM. aber eine 100% synchrone Schaltung wird es nicht geben.
Danke für die Klarstellung; so tief in die Analyse der Funkprotokolle war ich dann noch nicht vorgedrungen.
Danke für die Hinweise
Zitat von: betateilchen am 31 August 2018, 13:48:44
eine 100% synchrone Schaltung wird es nicht geben.
Es ist in der Praxis eine Frage der Quantität - solange das (in meinem Fall) nicht in sichtbaren Unterschieden mündet, ist es ja ok. Ich werde mal testen, ob das peeren mit einem virtuellen Kanal besser funktioniert.
Solange Du das mit einem virtuellen Aktor in FHEM probierst, bringt Dir das NULL Vorteile.
Besorge Dir irgendeine Hardware, die als Taster dienen kann, um einen Befehl an die gepeerten Aktoren zu schicken. Diese Hardware solltest Du dann direkt an Deine FHEM Plattform anschließen, z.B. per GPIO und darüber den Befehl schicken.
Das Entscheidende ist, dass der Befehl NICHT aus FHEM kommen darf, weil das viel zu lange dauert.
Ich habe gesten noch etwas herumprobiert, mit einem Ladenpaar mit zwei HM-LC-Bl1-FM, die beide mit ein und demselben Kanal eines HM-PB-6-WM55 gepeered waren. Auch das schaltet nicht immer synchron (öfters gefühlte 0,5 s Versatz). Was aber schlimmer ist: Nach ein paar Fahrten liefen die Läden plötzlich gegenläufig, d.h. einer hoch, der andere runter. Ich vermute mal, dass das daran liegt, dass bei 1-Kanal-Bedienung eine Art Toggle-Befehl im Schalter produziert wird, obwohl im Log on bzw. off steht...?