Probleme bei Notify Automatisierung mit FS 20 Beschattung

Begonnen von Luco, 04 Mai 2015, 18:32:26

Vorheriges Thema - Nächstes Thema

Luco

Servus Community,

als blutiger Anfänger habe ich nun mein erstes kleines System aufgebaut. Im gekauften Haus waren mehrere FS20 RSU verbaut, die ich nun mit einem CUL am Raspberry prima schalten kann.
Merkwürdigerweise, reagierten sie zunächst alle exakt spiegelverkehrt. Auf = Rolladen runter, Ab = Rolladen hoch. Vermutlich hat der Vorbesitzer die Verkabelung zu den Rolladenmotoren genau spiegelverkehrt angelegt - nach einem Wechsel arbeitet nun alles wie es soll.

Was mir allerdings nicht gelingt ist die Beschattung. Ich habe dafür einen FS20 BS, darum geht es hier aber nicht, sondern um die Funktion "off-for-timer"
Dafür fand ich ein fertiges Skript im Forum und so sieht eine Rollade bei mir aus:


define WZ_TUR1 FS20 1b1b 02
attr WZ_TUR1 IODev CUL_0
attr WZ_TUR1 devStateIcon Auf:fts_shutter_10 Schatten:fts_shutter_60 Ab:fts_shutter_90
attr WZ_TUR1 eventMap /on:Auf/off-for-timer 3:Schatten/off:Ab/
attr WZ_TUR1 group Rollo
attr WZ_TUR1 icon fts_shutter_30
attr WZ_TUR1 model fs20rsu
attr WZ_TUR1 room Wohnzimmer
attr WZ_TUR1 webCmd Auf:Schatten:Ab


Wenn ich "Schatten" aktiviere, fährt die Rollade jedoch nicht für 3 Sekunden runter, sondern komplett. Auch wenn die Fahrtzeit nicht besonders lang ist, mehr als 3 Sekunden ist sie definitiv.
Habe ich irgendwie ein Verständnisproblem? Hoffe jemand kann mir weiterhelfen.
Vielen Dank im Voraus

ph1959de

Also die eventMap funktioniert bei mir mit RSUs einwandfrei.

Ist es möglich, dass Du mit dem Vertauschen der Anschlüsse das Verhalten in diese Richtung beeinflusst hast?

Was passiert, wenn Du mal (ruhig auch "von Hand" also im Befehlseingabefeld) mit "set WZ_TUR1 on-for-timer 3" prüftst, ob da richtungsmäßig doch noch nicht alles korrekt ist?

Peter
Aktives Mitglied des FHEM e.V. | Moderator im Forenbereich "Wiki"

Luco

Hallo hp1959de,

danke für deine Antwort. on-for-timer hat leider gar nichts gebracht, aber es hat mir einen Denkanstoss gegeben.
Die Rolladen waren quasi immer im jeweils anderen Status als FHEM gedacht hat. Ich konnte das Problem lösen, indem ich die hochgefahrene Rollade einmal vom RSU abgesteckt habe, dann in FHEM auf ON gestellt und dann wieder angesteckt habe. So passt FHEM mit Status ON zur hochgefahrenen Rollade. Nun funktioniert off-for-timer wie es soll.
Eventuell stand ich mir da selbst im weg, da ON für mich HOCH ist und eben nicht Rollade runter.

Danke dir für deinen erfolgreichen Denkanstoss

Luco

Hallo,

ich muss das Thema doch noch mal reaktivieren. Bislang haben die FS20 Aktoren wunderbar funktioniert.
Jetzt gerade kam es zum zweiten mal vor, dass FHEM set WZ_TUR3 Schatten ausführt und die Rollade letztlich ganz runter fährt.
Quasi wird der off-Befehl zu lange gesendet. Dies passiert aber scheinbar nur ab und zu.

Gibt es irgendwie eine Möglichkeit zu sehen, was FHEM bzw. der CUL wirklich exakt gemacht haben?
Im Eventmonitor bzw. Log steht ja einfach nur der Befehl set WZ_TUR3 Schatten
Liegt das wohl an den betagten FS20? Weil die Entfernung ist mit 2-3 Metern ideal und der Befehl funktioniert ja auch größtenteils.
Oder liegt es an mehreren Befehlen gleichzeitig? Es werden nämlich mehrere Rolladen gleichzeitig gesteuert set WZ_TUR1,WZ_TUR2,WZ_TUR3,WZ_TUR4 Schatten
Löse ich das wohl besser über Gruppen-Adressen in FS20? Fragen über Fragen  :o

Vielleicht hat jemand eine Vermutung aus eigener Erfahrung heraus

rudolfkoenig

Gruppenadresse ist aus RF-Sicht besser, da nur eine Nachricht gesendet wird, statt 4.

Jede FS20 Nachricht wird vom CUL/FHZ1x00 3-mal wiederholt, und diese 3-er Tupel dauert max. 0.23 Sekunden. FHEM wartet 0.3 Sekunden, bevor die naechste FS20 Nachricht gesendet wird, damit Ueberlappungen vermieden werden. Ein Repeater oder aehnliches kann so eine Kommunikation empfindlich stoeren.

Luco

Hallöchen,

ich muss das Thema leider noch mal hervor holen.
Und zwar habe ich unabhängig von der Anzahl der Aktoren folgendes Problem.

Die Rolladen habe ich wie folgt definiert:
define WZ_TUR1 FS20 1b1b 02
attr WZ_TUR1 IODev CUL_0
attr WZ_TUR1 devStateIcon Auf:fts_shutter_10 Schatten:fts_shutter_60 Ab:fts_shutter_90
attr WZ_TUR1 eventMap /on:Auf/off-for-timer 13:Schatten/off:Ab/
attr WZ_TUR1 group Rollo
attr WZ_TUR1 icon fts_shutter_30
attr WZ_TUR1 model fs20rsu
attr WZ_TUR1 room Wohnzimmer
attr WZ_TUR1 webCmd Auf:Schatten:Ab


Wenn ich nun manuell "Schatten" aktiviere über die Weboberfläche oder die FHEM Remote App, fährt die Rollade zuverlässig 13 Sekunden lang herunter. Da bleiben so rund 10% unverdeckt.
Nun habe ich den FS20 BS definiert:

define WZ_BS FS20 0000 00
attr WZ_BS IODev CUL_0
attr WZ_BS alias Sonneneinstrahlung
attr WZ_BS comment Beschattungssteuerung on=dunkel off=hell
attr WZ_BS devStateIcon hell:weather_sun dunkel:weather_cloudy
attr WZ_BS dummy 1
attr WZ_BS eventMap /off 2.5:hell/on 2:dunkel/
attr WZ_BS group Beschattung
attr WZ_BS model fs20bs
attr WZ_BS room Wohnzimmer


und mit einem Notify versehen:


define WZ_Beschattung notify WZ_BS:* {\
if('%' !~ m/dunkel/) {\
  if(Value('WZ_TUR1') eq 'Auf') { fhem("set WZ_TUR1 Schatten") } \
} else { fhem ("set WZ_TUR1 Auf") } \
}


Das notify arbeitet auch korrekt, aber die Rollade fährt zuverlässig statt 13 Sekunden einfach komplett runter, als würde ein Off gesendet statt off-for-timer
Ich habe auch schon folgende Dinge versucht:

  • set WZ_TUR1 off-for-timer 13 statt Schatten
  • fhem 'befehl' statt der runden Klammer-Schreibweise

Das merkwürdige ist, dass ich mit einem trigger WZ_BS hell das Notify auslösen kann und es funktioniert wie gewünscht.
Es scheint also, dass NUR bei der Automatisierung zu haken, wenn ich nichts manuell ausgelöst habe.

Leider bin ich gerade echt ratlos. Die Rollade ist rund 2 Meter weg vom Raspberry. Die Befehle haben auch absolut nie Aussetzer und werden immer ausgeführt, nur halt in diesem Fall off statt off-for-timer

Hat noch irgendjemand einen Hinweis oder Idee, was ich noch ausprobieren könnte?
Vielen Dank für jede Anregung