Feststellen ob der Rolladen manuell verfahren wurde

Bäschdler · 11 April 2018, 23:04:35

Hallo,

ich habe Rolladenmodule HM-LC-BI1-FM im Einsatz welche ich mittels FHEM steuere. Die Module haben jeweils einen Taster für auf / ab der direkt am Modul angeschlossen ist.

Jetzt würde ich gerne darauf reagieren, wenn der Rolladen mittels der Taster manuell verfahren wurde. Leider habe ich bisher keine Möglichkeit gefunden wie ich feststellen kann dass dies der Fall war. Im Logfile sehe ich Unterschiede zwischen manuellem Fahren und einem verfahren via Fahrbefehl. Aber der ist hauptsächlich der, dass beim automatisierten Fahren ein "set_[Prozentwert]" an das Modul gesendet wird.

Hier die Meldungen im Logfile wenn der Rolladen von FHEM aus angesteuert wurde:

2018-04-09_09:00:00 OG_KiZ_Roll level: set_0
2018-04-09_09:00:00 OG_KiZ_Roll set_0
2018-04-09_09:00:00 man_log_OG_KiZ_Roll log "Rolladen morgens auf Position 0 % fahren"
2018-04-09_09:00:00 OG_KiZ_Roll deviceMsg: off (to myHmUART)
2018-04-09_09:00:00 OG_KiZ_Roll level: 0
2018-04-09_09:00:00 OG_KiZ_Roll motor: stop:off
2018-04-09_09:00:00 OG_KiZ_Roll pct: 0
2018-04-09_09:00:00 OG_KiZ_Roll off
2018-04-09_09:00:00 OG_KiZ_Roll timedOn: off
2018-04-09_09:00:05 OG_KiZ_Roll deviceMsg: off (to myHmUART)
2018-04-09_09:00:05 OG_KiZ_Roll level: 0
2018-04-09_09:00:05 OG_KiZ_Roll motor: stop:off
2018-04-09_09:00:05 OG_KiZ_Roll pct: 0
2018-04-09_09:00:05 OG_KiZ_Roll off
2018-04-09_09:00:05 OG_KiZ_Roll timedOn: off

Und hier wenn er per Taster am Modul verfahren wurde:

2018-04-09_10:24:07 OG_KiZ_Roll deviceMsg: 8.5 (to myHmUART)
2018-04-09_10:24:07 OG_KiZ_Roll level: 8.5
2018-04-09_10:24:07 OG_KiZ_Roll motor: up:8.5
2018-04-09_10:24:07 OG_KiZ_Roll pct: 8.5
2018-04-09_10:24:07 OG_KiZ_Roll 8.5
2018-04-09_10:24:07 OG_KiZ_Roll timedOn: off
2018-04-09_10:24:30 OG_KiZ_Roll deviceMsg: 96 (to myHmUART)
2018-04-09_10:24:30 OG_KiZ_Roll level: 96
2018-04-09_10:24:30 OG_KiZ_Roll motor: stop:96
2018-04-09_10:24:30 OG_KiZ_Roll pct: 96
2018-04-09_10:24:30 OG_KiZ_Roll 96
2018-04-09_10:24:30 OG_KiZ_Roll timedOn: off

Kann mir jemand sagen wie ich da einen dummy "Rolladen_KiZ_wurde_manuell_verfahren" setzen kann um damit dann z. B. in weiteren Befehlen darauf zu reagieren?

Vielen Dank schon mal.

sumsum · 12 April 2018, 08:08:53

Du könntest ein Userreading setzen, wenn du automatisch fährst. In einem notify kannst du dann den Zeitunterschied zwischen state und deinem Userreading auswerten.
Würde mir als erstes so einfallen.

steffenp · 12 April 2018, 08:32:05

Schau mal in den Eventmonitor welche Events jeweils erzeugt werden.
Ich würde vielleicht in einem Dummy oder besser Userreading vom Rolladen bei jedem programmgesteuerten Fahren mir die Zielposition merken.
Dann auf ein Event, welches am Ende jeder Fahrt
(egal ob automatisch oder manuell) ausgelöst wird reagieren und letztes gespeichertes Ziel mit aktueller Position vergleichen. Stimmen die nicht überein war es wohl ein manueller Eingriff, stimmen sie überein war es eine automatische Fahrt oder wir sind zumindest dort wo wir automatisch auch wären.
Wenn das so reicht das Ergebnis speichern und fertig.
Ansonsten müsstest du mal genauer definieren was du erreichen willst.

Gruß

CoolTux · 12 April 2018, 08:36:00

Ganz einfach.

Wenn FHEM den Rolladen fährt, scheint es nur dieses
2018-04-09_09:00:00 OG_KiZ_Roll level: set_0
2018-04-09_09:00:00 OG_KiZ_Roll set_0
zu geben.
Also set_

Du kannst darauf mit einem Notify reagieren.

Otto123 · 12 April 2018, 09:05:46

Zitat von: CoolTux am 12 April 2018, 08:36:00
Ganz einfach.

Wenn FHEM den Rolladen fährt, scheint es nur dieses
2018-04-09_09:00:00 OG_KiZ_Roll level: set_0
2018-04-09_09:00:00 OG_KiZ_Roll set_0
zu geben.
Also set_

Du kannst darauf mit einem Notify reagieren.

Naja aber das ist der Fall den er nicht ermitteln will.

Und leider ist kein Event nicht die Negation von "mit FHEM gefahren"

Ich würde eher so wie steffenp ansetzen, also gezielt merken was mit FHEM gefahren wurde.

Gruß Otto

Beta-User · 12 April 2018, 09:37:34

Das notify sollte auf das "motor"-reading (nur up/down) reagieren. Es handelt sich um einen Tastendruck, wenn bei einem solchen Event der STATE des devices nicht auf "set_.*" steht...
Das notify kann dann ja ein reading am Device direkt setzen, ich würde das z.B. "localAction" nennen und einen boolschen Wert verwenden.

frank · 12 April 2018, 10:01:57

ZitatDas notify kann dann ja ein reading am Device direkt setzen, ich würde das z.B. "localAction" nennen und einen boolschen Wert verwenden.

in diesem fall (trigger und setreading von/auf selbes device) aber mit userreading arbeiten.

Otto123 · 12 April 2018, 10:04:21

Ihr müsst bedenken: Die Status Meldungen vom Aktor (un damit die Events) kommen wegen der Funklast ein paar sekunden zeitverzögert. Ich bin mir nicht sicher ob das wirklich geht.

Beta-User · 12 April 2018, 10:38:49

Zitat von: Otto123 am 12 April 2018, 10:04:21
Ihr müsst bedenken: Die Status Meldungen vom Aktor (un damit die Events) kommen wegen der Funklast ein paar sekunden zeitverzögert. Ich bin mir nicht sicher ob das wirklich geht.

Teste es doch einfach

. Es kommt ja alles zeitverzögert

. Und wenn du ein paar Sekunden hast, solltest du checken, ob du sonst Probleme mit dem Netz hast. Hier kommen über das PI-PCB@USB (CP2102) bei einer Jalousie (Laufzeit ca. 60 Sekunden) updates des Levels teilweise in 0.5-er-Schritten

.

Ich hatte das mal ähnlich umgesetzt in einer myUtils-Routine, um bei einem geöffneten Fenster bei einer Zwischenposition anzuhalten, dabei aber eine eventuelle Zielposition (gibt es nur bei "set_.*") für später (nach Schließen/Kippen) zu speichern. Das funktionierte grundsätzlich auch, wobei es nach meiner Erinnerung nicht notwendig war, das in ein userreading zu packen. Es geht hier lt. der eingangs gestellten Anforderung des TE ja nicht darum, gleich wieder ein Event zu generieren (commandref zu setreading), sondern später zu wissen, ob der letzte Schaltbefehl lokal war oder von FHEM aus gesendet wurde. Das sollte durch ein einfaches setreading zu machen sein. Im Gegenteil: hier finde ich es sinnvoll, dass kein Event generiert wird...
In der angesprochenen myUtils hatte ich das so gelöst, dass weitere Events am Fensterkontakt oder Aktor, dann einen erneuten Durchlauf angestoßen hat (z.B: ein "stop"). Da wurde dann wieder geprüft, welchen Wert das reading hat - keine Probleme damit.

steffenp · 12 April 2018, 10:54:14

Vor allem ist nicht sichergestellt das der Rollladen wirklich dort angekommen ist wo fhem denkt.
Stoppt der Benutzer im fahren durch Tastendruck einfach nur den Motor seht ihr eine automatische Fahrt, das
würde ich jedoch eher als manuellen Eingriff sehen.

Abgesehen davon sehe ich das Problem das (zumindest bei mir, Homematic) das set_* nur sehr kurz im state zu sehen ist.
Es wird sofort wieder durch die aktuelle Position überschrieben.

Beta-User · 12 April 2018, 11:03:25

Zitat von: steffenp am 12 April 2018, 10:54:14
Abgesehen davon sehe ich das Problem das (zumindest bei mir, Homematic) das set_* nur sehr kurz im state zu sehen ist.
Es wird sofort wieder durch die aktuelle Position überschrieben.

Deswegen STATE und nicht state. STATE bleibt, jedenfalls, wenn es um ein set_.* geht, bis die Zielposition erreicht ist (oder ein NACK kommt).

Zitat von: steffenp am 12 April 2018, 10:54:14
Vor allem ist nicht sichergestellt das der Rollladen wirklich dort angekommen ist wo fhem denkt.
Stoppt der Benutzer im fahren durch Tastendruck einfach nur den Motor seht ihr eine automatische Fahrt, das
würde ich jedoch eher als manuellen Eingriff sehen.

Der Einwand ist berechtigt. Ist natürlich die Frage, wie oft das ggf. vorkommt.

Das könnte man abfangen, indem man die Zielposition bei automatischer Fahrt in das reading packt bzw. bei einem manuellen Start eine "-1" oder so (halt was, was es bei einem realen "set" nicht gibt).
Dann müßte auch auf "motor: stop" reagiert werden und geprüft ob state=gespeicherter Zielstate (dann manueller Stop).
Geht stark in die Richtung meines codes. Wer einen "Steinbruch" dazu braucht, der ist hier zu finden: https://github.com/rejoe2/FHEM/blob/master/myShutter/99_myShutterUtils.pm.

Gruß, Beta-User

Otto123 · 12 April 2018, 11:07:00

Naja dann doch erstmal wie CoolTux vorgeschlagen hat, den set_ Befehl "merken" und später nach irgendeinem Kriterium löschen. Dann hat man eine Art automatische Phase. Man kann ermitteln ob er dort angekommen ist wo er sollte (zumindest in den Werten)

Oder man überlegt einfach, ob draußen das Wetter nicht schöner ist und es andere Problem auf der Welt gibt

Wenn Du den Tastendruck abfragen willst, brauchst Du entweder eine andere Firmware oder getrennte Aktoren/Taster.

Meine Rollladen fahren zu 95 % nur automatisch, ich habe bis auf 3 Ausnahmen keine Taster angeschlossen und damit das Problem gar nicht

Gruß Otto

Beta-User · 12 April 2018, 11:11:51

Zitat von: Otto123 am 12 April 2018, 11:07:00
Oder man überlegt einfach, ob draußen das Wetter nicht schöner ist und es andere Problem auf der Welt gibt

Der code ist hauptsächlich bei schlechtem Wetter entstanden; ansonsten auch gerne auf der Terrasse mit dem Laptop.

Btw.: ich habe hier Mitbewohner, die Schalter mögen, und deren aktuelle Vorlieben per code vorauszusagen, ist mir leider noch nicht vollständig gelungen...

steffenp · 12 April 2018, 11:17:56

Damit sind wir dann ja wieder bei dem was ich ganz am Anfang vorgeschlagen habe.
Bei set Position merken und immer bei Motorstop nachsehen ob aktuelle Position == gespeicherte Position
Wenn das True ist dann war es entweder eine automatische Fahrt oder der Benutzer hat den Punkt angefahren
wo er auch wäre ohne manuellen Eingriff.
Bei false war es eine manuelle Fahrt.

Je nach dem was der OP vor hat kann das so reichen oder sogar so gewünscht sein. Aber das weiß nur er.

enno · 12 April 2018, 11:19:02

Wenn bei mir FHEM stehen bleibt, merken wir das morgens immer an den Rollos die unten sind. Wenn da meine Mitbewohnerin nicht mit einem Taster die Dinger hochfahren kann, gibt das ganz schlechte Noten und keinen Kaffee zum Frühstück.

Ich trigger auf den Taster, setze ein Reading und nutze den Zeitstempel zum Vergleich. Danach entscheide ich ob es Manuel oder Automatisch gestartet wurde.

Gruss
Enno