Probleme mit 'off-for-timer'

[aloss]

Hallo Gemeinde!

Bin neu im Forum angekommen, weil mich gleich ein Problem drückt.

Ich nutze bei mir zu Hause ca. 10 Rollladen-Schalter FS20 RSU. Wenn abends die Dämmerung einbricht, möchte ich die Rollladen nicht gleich ganz runter fahren, sondern erst noch so halb, damit man nicht gleich ganz abgeschottet ist. Ich tue das, indem ich per Perl-Code zwei Kommandos absetze:

   fhem ("set WZRoll on");
   fhem ("define WZRollHalb at +00:00:30 set WZRoll off-for-timer 8");

Das erste Kommando fährt die Rollladen ganz hoch (um einen definierten Zustand zu erreichen). Das zweite Kommando wartet 30 Sekunden und fährt den Rollladen dann für 8 Sekunden runter. (Die 8 Sekunden sind empirisch ermittelt, so dass der Rollladen an die Stelle fährt, wo ich ihn hinhaben möchte.)

Für jeden Rollladen einzeln funktioniert das wunderbar, aber wenn bei Einbruch der Dämmerung alle 10 Rollladen praktisch gleichzeitig gesteuert werden, halten die Rollladen an völlig anderen Stellen an als geplant.

Mein Verdacht ist folgender: beim Absenken des Rollladen wird irgendwo, entweder in der CUL oder auch direkt im Raspberry Pie, ein Timer gesetzt, der den Rollladenmotor für 8 Sekunden unter Strom setzt. Im Sekundentakt werden danach die Timer für alle anderen Rollladen gesetzt und irgendwie kommt die steuernde Komponente damit nicht klar. Es führt zu Überschneidungen und die Timer werden an willkürlichen Stellen abgebrochen.

Daher meine Fragen:
1.   Hat jemand damit bereits Erfahrungen und kann dazu etwas sagen?
2.   Welche Komponente verwaltet den/die Timer beim Kommando ,,set ... on-for-timer..."? Ist es die CUL oder ist es FHEM selbst?
3.   Wenn es die CUL ist: Weiß jemand, ob es eine andere CUL gibt, die mehr Timer parallel verwalten kann?

(Bitte von sinnarmen Vorschlägen wie ,,nimm lieber HomeMatic" abzusehen. Dies wäre mit einem nicht unerheblichen baulichen Aufwand verbunden)

Nun zu meinem System:
•   FHEM (stets auf neuestem Stand) läuft auf einem Raspberry Pie Typ B.
•   Die angeschlossene CUL ist eine FHZ 1300 PC
•   FS20-Komponenten:
   o   13x FS20 RSU Rollladenschalter
   o   8x FS20 ST Steckdosenschalter, z.T. Unterputz
   o   1x FHZ Heizungssteuerung

Ich bin für jeden Tipp dankbar!

Grüße,
Andreas

[Rince]

Hat jemand damit bereits Erfahrungen

nein

und kann dazu etwas sagen?

ja

Ob es hilft, weiß ich nicht.
Zunächst solltest du dir mal den Eventmonitor ansehen. Da wird genau aufgelistet was und vor allem, wann fhem was tut.

Weiterhin kannst du mal wenn das nicht weiterhilft den Loglevel für deine Rollos auf 4 oder 5 setzen, dann kannst du im Logfile nachlesen wann was passiert.


Alternativ könnte das weiterhelfen:

Da das FS20 Protokoll 0.22Sek für eine Funksequenz benötigt wird nach jeder Ausführung eine Pause von 0.22Sek eingefügt.

Macht also mal eben mindestens 2,2 Sekunden Verzögerung für den letzten Rollo.
Erschwerend kommt dazu, dass du vorher schon 10 Telegramme rausgepustet hast, also nochmal mindestens 2,2 Sekunden vergangen sind. Macht in Summe also mindestens 4,4 Sekunden, vermutlich sogar mehr.

halten die Rollladen an völlig anderen Stellen an als geplant.

Das ist jetzt eine zu ungenaue Beschreibung des Problems, um es definitiv zu sagen, ob das die Ursache ist.


Die Frage ist, ob das off-for-timer im Aktor gesetzt wird, oder ob es fhem nachbaut (=nach 8 Sekunden ein off schickt). Weiß nicht wie das im FS20 Modul gelöst ist. Wenn fhem selber nach 8 Sekunden aktiv werden muss, hast du glatt noch mehr Verzögerung



Ich würde, an deiner Stelle, einen Workaround nehmen:
Lasse die Rollos erstens 10-60 Sekunden vor der Dämmerung hochfahren
Weiterhin schalte sie bei runterfahren nicht alle gleichzeitig, sondern lass einen Abstand von je 2 Sekunden. Damit dürfte kein Funktelegramm in einer Sendewarteschleife hängen bleiben.
Wenn du die rchtigen Rollos nacheinander auswählst, sieht das bestimmt von außen sehr stylisch aus wenn sie alle der Reihe nach im 2-Sekundentakt runterfahren

[rudolfkoenig]

Die Frage ist, ob das off-for-timer im Aktor gesetzt wird,

Ja, das Argument wird notfalls gerundet, siehe http://www.fhemwiki.de/wiki/FS20_Allgemein

[Rince]

Hm, wie kommen denn die 8 Sekunden zum fs20 Gerät?
Offenbar geht was schief, wenn ein off-for-timer zu lange in der Warteschlange hängt. Aber wieso? Wenn fhem keinen off Befehl senden muss, erfolgt die 8 Sekunden Timer Sache ja im Device selber.

Wenn fhem jetzt wirklich dem Gerät 8 Sekunden on sagen würde, wäre es doch egal ob der Befehl zu spät gesendet wird? Dann liefe der ganze Vorgang halt verzögert ab, oder?
Oder wird das irgendwie mit der Uhrzeit berechnet? Dann müssten die Rollos quasi zu früh stehen bleiben.

Ich bleibe erst mal bei meinem vorherigen Lösungsvorschlag:
Jeden Rollo mit 2 Sekunden Verzögerung nach dem Vorherigen loslaufen lassen

[aloss]

Zunächst mal vielen Dank für die Anregungen! Ich habe jetzt einen Wrapper um die FHEM-Kommandos herum geschrieben, der nach jedem Kommando ein "sleep(2);" macht. Ich werde morgen über das Ergebnis berichten.

Grüße,
Andreas

[Rince]

Das ist vielleicht ein schlechter Ansatz
http://forum.fhem.de/index.php/topic,30462.0.html

Besser wäre es, gleich am Anfang die at Definition die vom sunset gesteuert wird für jeden Rollo extra zu verändern. Aber vielleicht postest du mal den Code...

[aloss]

Also: ich habe es jetzt sowohl mit 'sleep (2)' als auch mit 'fhem("sleep 2");' probiert. Keine Veränderung.

Hier die essentiellen Code-Sniplets:

In meiner fhem.cfg:
define WohnRollladen1 FS20 0340 00
...
define atsunset at *{sunset("HORIZON=-3",0,"16:02","22:02")} { atsunset();; }
...

In meiner 99_myUtils.pm:

sub atsunset()
{
   ...
   fhem ("set WohnRollladen1 on");
   fhem ("sleep 3");
   fhem ("define WohnRollladen1 at +00:00:30 set WohnRollladen1 off-for-timer ;
   ...
}
   

(Hoffe, das ist syntaktisch richtig. Hab's ein bisschen vereinfacht - in Wahrheit werden da zwei Perl-Unterroutinen mit Parametern aufgerufen.)

Grüße,
Andreas

[rudolfkoenig]

Code Auswählen Erweitern

fhem ("set WohnRollladen1 on;; sleep 33;; set WohnRollladen1 off-for-timer 8")

[aloss]

Danke, Rudolf!

Hab das jetzt implementiert, muss aber bis morgen warten zum Testen. Ich melde mich.

Grüße, Andreas

[aloss]

Sorry für die verspätete Rückmeldung. Ich kann hier im Moment nicht so gut testen.

Also, inzwischen habe ich einige Variationen ausprobiert:
1.

fhem ("set WohnRollladen1 on;; sleep 33;; set WohnRollladen1 off-for-timer 8")

hat überhaupt nichts geändert.

2. Umstellen auf 2 Phasen:

fhem.cfg:

Code Auswählen Erweitern


define atsunsetP1 at *{sunset("HORIZON=-3",0,"16:02","22:02")} { atsunsetP1();; }
define atsunsetP2 at *{sunset("HORIZON=-3",90,"16:03","22:03")} { atsunsetP2();; }


In der 1. Phase fahre ich nun die Rollladen ganz rauf und in der 2. Phase nach 90 Sekunden "halb" runter. Ergebnis: Rollladen fahren nun in eine andere Position, aber immer noch nicht so, als wenn ich sie einzeln setze.

Ich habe nun aus den 2 Phasen 4 gemacht. Mal sehen, was heute Abend passiert...

[jojoja]

Du könntest auch einen Dummy AlleRollaeden erstellen, auf den jeder RSU praktisch "als zweiter Sender" hört. So werden nur 2 Befehle gesendet:

Code Auswählen Erweitern

fhem ("set AlleRollaeden on;; sleep 33;; set AlleRollaeden off-for-timer 8")

Nachteil: Es kann nicht für jeden Rolladen einzeln der off-for-timer bestimmt werden, es laufen alle 8 Sekunden lang.

Habe sowas allerdings nie selber getestet, also keine Garantie

[aloss]

@jojoja: Danke für den Hinweis. Ist aber keine Lösung für mich. Meine Rollladen sind unterschiedlich und ich fahre sie individuell in die gewünschte Position. Abgesehen davon bezweifele ich, dass Dein Vorschlag wirklich weniger Befehle an die Aktoren sendet. 

[aloss]

Inzwischen bin ich zuversichtlich, dass das Problem gelöst ist. Ich fahre nun die Rollladen in drei Phasen mit 90 Sekunden Abstand in die gewünschte Postionen (Obergeschoss, Untergeschoss, Anbau). Das ist von der Programmstruktur etwas unschöner, funktioniert aber offenbar auf die gewünschten Weise.

Ich interpretiere das so, dass entweder FHEM oder die CUL nicht damit klar kommt, wenn zu viele "set ... off-for-timer ..." Befehlsfolgen zu schnell aufeinander folgen. Warteschleifen mit sleep haben weder in Perl noch mittels fhem Erfolg gebracht. Ich habe also drei at-Kommandos mit zugehörigen Perl-Routinen in der fhem.cfg gesetzt:

Code Auswählen Erweitern


define atsunsetP1 at *{sunset("HORIZON=-3",0,"16:02","22:02")} { atsunsetP1();; }
define atsunsetP2 at *{sunset("HORIZON=-3",90,"16:03","22:03")} { atsunsetP2();; }
define atsunsetP3 at *{sunset("HORIZON=-3",150,"16:04","22:04")} { atsunsetP3();; }


Vielen Dank für Eure Hilfe und noch einen schönen Feiertag!

Grüße,
Andreas