Rolladenaktor - manuelle Bedienung mit Zeit erkennen HM-LC-Bl1PBU-FM

[Tsturm]

Hallo Zusammen,

ich habe mir eine nette Rollladensteuerung  ausgedacht, die entlang von Sonnenstand und -stärke die Rollläden abregelt.
Nun haben meine User manchmal das Bedürfnis, die Einstellung der Rollläden zu verändern, und finden es nicht lustig, dass meine Steuerung nach kurzer Zeit anderer Meinung ist und das auch wieder so zurückregelt.

Ich würde gerne erkennen, ob der Rollladenaktor  HM-LC-Bl1PBU-FM in einer bestimmten Zeitspanne manuell betätigt wurde - im Unterschied zur Ansteuerung durch mein Sonnenstands-DOIF. Das DoIF gibt einfach ein "Set Rollladen 50" zur Ansteuerung aus.

Mir fehlt das Reading, das mir eindeutig den Tastendruck liefert (den Rest bekomme ich hin - "wenn Rollladen manuell getätigt wurde, keine Regelung für die nächsten x Std"). Gibt es ein Reading, dass mir eindeutig einen Tastendruck mit Zeitstempel liefert?

VG Timmo

[zap]

Ich glaube, diese Aktoren unterstützen das nicht. Die HmIP Rollladenaktoren hingegen liefern die entsprech nden Infos

[Otto123]

Hi,
Die manuelle Bedienung lässt der Aktor meines Wissens nicht einfach erkennen.
Mir fallen zwei Ansätze ein:
1. Den Ansatz verwende ich auch an einigen Stellen. Das Reading ist die Position Das es unwahrscheinlich ist, das manuell eine bestimmte Zwischenposition angefahren wird, verwende ich die in der Automatik. z.B. 95% anstatt on oder 100%. Fällt nicht auf, aber bei 95% weiß ich, das war die Automatik und meine Steuerung reagiert auf die 95%.
2. Man könnte vielleicht die zeitliche Abfolge der Events auswerten. Schau Dir mal an wie es im Event Monitor aussieht wenn Du Befehle über FHEM sendest und wenn du den Aktor vor Ort betätigst.

Gruß Otto

[automatisierer]

Sowas hab ich mir auch mal gebaut, da ich das gleiche Problem hatte.

Code Auswählen Erweitern

attr Kueche_ak_Jalousie userReadings setTo:level..set.* {(split("_",ReadingsVal($name,"level","?")))[1]} , mode:pct.* {if (ReadingsVal($name,"pct","?") == ReadingsVal($name,"setTo","?")) {"auto"} else {"manuell"}}


Ist schon ne weile her, dass ich das eingebaut habe und ich bin mir nichtr sicher, ob es reicht, wenn du das userReading einsetzt.

Wenn du über FHEM steuerst, dann gibt es ein setTo im Status, wenn du es Manuell über den Taster machst, dann gibt es diesen Wert nicht.
Das ganze word zurück gesetzt, wenn der Rollladen einmal wieder über fhem verfahren wird oder halt abends/morgens die Automatik den Rollladen hoch oder runter fährt. Die Beschattungsautomatik steuert dann nur die Rollläden, die auf auto stehen...

Probier es aus, wenn du magst und meld dich bei Problemen...

Gruß
Ingo

[Tsturm]

Hallo zusammen,

vielen Dank - die Richtung von Otto hatte ich auch schon in Erwägung gezogen... das mit setto klingt noch interessanter, werde mal die Events genau checken. Werde ich wohl so machen, Ergebnisse in den nächsten Tagen.

VG timmo

[Pfriemler]

... setTo im Status, wenn du es Manuell über den Taster machst, dann gibt es diesen Wert nicht.

Wird bei mir in ähnlicher Weise eine bisherige Erkennung, ob der letzte Steuerbefehl von FHEM oder vom Benutzer kam, ablösen.
Dabei ist es egal, ob das lokal oder über eine gepeerte Fernbedienung erfolgt ist, habe ich gerade gecheckt.
Genialer Code, passt 1:1 ohne Anpassung an das jeweilige Gerät. Sollte ins Wiki, weiß nur noch nicht wo...
edit: Wie bei Ottos Lösung ist allerdings auch hier logischerweise das Problem vorhanden, dass der mode auf "auto" wechselt, wenn der Benutzer zufällig den Wert von "setTo" einstellt. Das kann ja sogar gewollt sein, etwa wenn der Benutzer auf diese Weise durch das Verfahren in eine Endlage den "auto"-Zustand einfach selbst wiederherstellen kann. Ansonsten bleibt das Verfahren auf "krumme" Werte durch die Automatik das Mittel der Wahl.

[Wzut]

Genialer Code, passt 1:1 ohne Anpassung an das jeweilige Gerät. Sollte ins Wiki,

Stimmt , nur würde ich das == durch eq ersetzen sonst gibt es Gemecker wenn eines der beiden Readings den default Wert "?" hat

[Tsturm]

Klappt prima, nur mit dem userReadings "mode" hat mein DoIf Probleme - nachdem ich das in "usermode" umbenannt habe, ging es (ich vermute mal, das mode irgendwie im DOIF-Universum als Keywort verwendet wird)

Code Auswählen Erweitern

setTo:level..set.* {(split("_",ReadingsVal($name,"level","?")))[1]} , usermode:pct.* {if (ReadingsVal($name,"pct","?") eq ReadingsVal($name,"setTo","?")) {"auto"} else {"manuell"}}

Hier die vollständigen Beispiele für die Nachwelt..

1. Doif (die Wait-Perioden müssen natürlich für den Realbetrieb länger sein, sonst geht der Rollladen ständig hoch und runter)

Code Auswählen Erweitern


defmod AZtest_sun DOIF (\
([AZ_Roll:usermode] eq "auto")\
and \
([testsun:state] > 30)\
)\
({ if ( ReadingsVal("AZ_Roll","pct",100) > 50) { fhem("set AZ_Roll 80") }})\
DOELSEIF\
(\
([?AZ_Roll:usermode] eq "auto") \
and \
([testsun:state] < 30)\
)\
({ if ( ReadingsVal("AZ_Roll","pct",99) < 100) { fhem("set AZ_Roll 100") }})\

attr AZtest_sun checkall all
attr AZtest_sun do always
attr AZtest_sun wait 30:30


2 Rollladen mit userreadings

Code Auswählen Erweitern

defmod AZ_Roll CUL_HM 4D0115
(...)
attr AZ_Roll userReadings setTo:level..set.* {(split("_",ReadingsVal($name,"level","?")))[1]} , usermode:pct.* {if (ReadingsVal($name,"pct","?") eq ReadingsVal($name,"setTo","?")) {"auto"} else {"manuell"}}



3. Testdummy zum Simulieren der Sonne

Code Auswählen Erweitern

defmod testsun dummy
attr testsun readingList state
attr testsun room Test
attr testsun setList state:slider,0,10,100
attr testsun webCmd state


VG Timmo

[pwlr]

Moin,

Ich würde gerne erkennen, ob der Rollladenaktor  HM-LC-Bl1PBU-FM in einer bestimmten Zeitspanne manuell betätigt wurde - im Unterschied zur Ansteuerung durch mein Sonnenstands-DOIF. Das DoIF gibt einfach ein "Set Rollladen 50" zur Ansteuerung aus.

..es gibt viele Lösungen, hier noch mal ein ganz anderer Ansatz:
die folgenden Register von self01 und self02 ändern:
shOnTime und shOffTime = 0
shOnDly und shOffDly = 90000 (25 Stunden)
Nur bei manuellem Betrieb über self01 und self02 bleibt die Statemachine dann nicht im Status on oder off stehen, sondern "rutscht" weiter nach dlyon oder dlyoff. Für die Schaltspannung an der Jalousie ist das identisch, aber mit dem Unterschied, dass das Reading "timedOn" dann von "off" in "running" umschaltet. Das wäre dann also der Indikator, den Du suchst. 

Bei Steuerung über fhem sind diese Register nicht wirksam und das Reading "timedOn" steht auf "off".

Deine Automation kann nun anhand des Readings "timedOn" leicht erkennen, ob eine manuelle Bedienung erfolgte und am Timestamp des Readings auch die Uhrzeit dieser manuellen Steuerung.

Damit haben wir so etwas wie "on-for-timer" oder "off-for-timer" im Device programmiert (Zeitkonstante = Wert in shOnDly bzw. shOffDly). Nach Ablauf dieser Zeit wird das Device also die Jalousie in den jeweils anderen Status fahren, was ja nicht gewollt ist - Abzug in der B-Note für diese Lösung!
Aber Deine Automation muss ja eh irgendwie vom manuellen Mode wieder auf Automatik zurück schalten, und das sollte dann zwingend innerhalb dieser Zeitkonstante erfolgen. Also beispielsweise immer um 24:00 Uhr oder bei Dunkelheit oder wie auch immer.
Wenn also von DOIF irgendein Befehl kommt, wird das Reading wieder auf "off" gesetzt und damit der automatische Mode aktiviert und die B-Note ist geretttet.

Ist vielleicht einfacher als diese ellenlangen DOIFs und es gibt keine Probleme mit zufällig übereinstimmenden Positionen.

Moin
Bernd

[martinp876]

auf die (korrekte) Anmerkung hin, dass man nicht erkennen kann ob der letzte Trigger von FHEM kam habe ich nun das Reading "trigLast" vervollständig. Bislang wurden nur Trigger externen Devices eingetragen. Nun wird "fhem:<code>" gesetzt wenn man ein "set on/off" oder ähnlich ausgelöst hat.
Nicht ausgewertet wird immer noch der interne peer (also der eingebaute Taster).
Vielelicht hilfts wem.

[Pfriemler]

In der Sache hilft es weniger, aber das Problem ist auch vielschichtiger: Zwar kann man nun erkennen, dass der letzte Fahrbefehl von "außen" kam, FHEM inklusive, aber eine manuelle Bedienung kann ja auch von einem externen Peer (Fernbedienung) kommen - im Sinne der Fragestellung auch eine manuelle Verstellung, bei der die Automatik nicht hineinpfuschen soll.
Denkbare Auswertung: Wenn bei einer Statusänderung des Readings "motor" das Reading trigLast älter ein paar Sekunden ist, dann wurde die Fahrt per internem Button ausgelöst. Könnte man nicht daraus auch trigLast mit "local: xxx" bestücken? "motor" liefert ja auch die Bewegungsrichtung. Nur: wenn der Benutzer den extern angestoßenen Lauf händisch stoppt, liegt ja auch eine manuelle Bedienung vor. Immerhin erkennt die "setTo"-Lösung diese Abweichung auch sicher.

Noch jemand ne Idee?

[frank]

wenn ich das richtig verstanden habe, ist es doch für die fragestellung egal, ob intern oder extern getriggert wurde. jede änderung, die nicht von fhem kommt, ist manuel, auch von externen peers.

[martinp876]

ich überlege einmal. Allerdings werde ich in keinem Fall "local" setzen, wenn es nicht eindeutig ist. Wir haben die Möglichkeit, das ein Sensor in innerhalb der Reichweite des Blind ist aber ausserhalb des IO Device (warum auch immer). Oder FHEM hat es nicht gesehen.
TrigLast ist nicht nur für Blind. Also scheidet Motor aus.
Man kann auch eine Verzögerung programmieren - eher für Lichter, auch für Rollo möglich. Dann hat ein Trigger das Fahren beauftragt aber zeitlich lässt sich kaum ein zusammenhang finden.


Und ja, sich denke frank hat recht - in diesem Fall.

[pwlr]

Moin,

Nun wird "fhem:<code>" gesetzt wenn man ein "set on/off" oder ähnlich ausgelöst hat.

Das ist schon mal eine wesentliche Verbesserung. Danke, Martin !

Ja, es gibt dieses Reichweitenproblem. Ich sehe aber noch ein weiteres Problem - die Devices können auch den Status eigenständig ändern, bei Ablauf eines Timers wie nach set xxx on-for-timer (bei Schaltern) oder allgemein intern registergesteuert. In diesem Fall wäre das letzte tigLast von einem externen Peer dann weiter richtig und man kann nicht zwangsläufig und allgemeingültig durch Vergleich der Timestamps auf selfxx schließen.

Wenn ich das richtig verstanden habe, bekommt FHEM die Infos zum auslösenden Peer durch mitlesen. Also fehlen im FHEM die Infos bei
a) Reichweitenproblemen
b) Betätigung der internen (oder extern angeschlossenen) Tasten selfxx
c) interne Statusänderungen der Statemachine
d) Ausfall oder Beeinträchtigungen des Funkkanals (z.B. HMLAN etc.) - FHEM hat es nicht gesehen.

Korrekter, aber auch nicht 100% richtig (siehe c),  wäre meies Erachtens in diesen Fällen ein trigLast = unknown
Ein User kann dann individuell entscheiden, ob bei unknown vermutlich selfxx der Auslöser war.

Was besseres fällt mir nicht ein 

[DS_Starter]

Hallo Martin, @all,

ich habe einen Rolloschalter HM-LC-Ja1PBU-FM. Bei diesem Typ finde ich kein Reading "trigLast".
Wäre das Reading hier noch "nachzurüsten" oder gibt es evtl. einen anderen Grund dass dieser Rolloschalter dieses Reading nicht hat ?

VG
Heiko