[ASC] Zusatz-Attribut für gepeinigte FSB61-Nutzer mit Positionsproblem

[zife]

Frage und Vorschlag zu ASC/AutoShuttersControl:

Ich gehöre zu denen, die (leider) FSB61-Aktoren eingebaut haben und die - bauartbedingt - keine Position zurückmelden. Die geschätzte Position in fhem ist wohl das beste, was technisch/logisch geht - aber früher oder später eben abweichend von der Realität. Sprich: nach der ein oder anderen manuellen Taster-Fahrt ist sie am majestätischen Hinterteil - also, am A...  und ASC steuert in der Folge falsch.

Also... kein Vorwurf an einen Modulautor, sondern einfach nur dumm gelaufen... 

Die Hoffnung, das durch Feineinstellungen hinzubekommen, gebe ich langsam auf. Deshalb ein ganz anderer Vorschlag, gerne zur Diskussion:

Könnte man ein ASC-Rolladen-Device-Attribut einbauen ("ASC_ExtraCalibrationDrive" oder so), dass dann folgende Funktion bei diesem Rolladen auslöst:
... Wenn letzte Fahrt des Rolladens manuell und Position nicht ganz oben oder ganz unten, dann wird vor der Anfahrt einer Position erstmal ganz hoch bzw. runtergefahren, um sich so neu zu kalibrieren. Erst nach kurzer Pause (max. "shutTimeCloses" oder ASC-Attribut "ASC_DriveUpMaxDuration") folgt die Fahrt auf die Soll-Position.

Mir ist klar, dass das nicht wirklich elegant ist. Aber ich finde keine andere Lösung, um ASC parallel mit manuellen Tastern und Eltako FSB61 sinnvoll zu nutzen. Andere Ideen sind natürlich willkommen.

[CoolTux]

Bekommt denn das eigentlich benutze Modul zur Steuerung der Rollos in FHEM eine vom Taster ausgelöste Fahrt mit? Ich bin der Meinung das so etwas über das eigentliche Modul gelöst werden sollte.

Lese hier aber sehr gerne mit.

[Beta-User]

Ergänzend zwei Gedanken dazu:
- ROLLO (hier nicht als "Zwischenschicht" sondern als "Nebenschicht") könnte evtl. helfen, den "korrekten" (oder wenigstens korrekteren) Stand der Position zu ermitteln und dann per "setreading" oder "setstate" auf das EnOcean-Ding zu schieben. Setzt halt voraus, dass der Taster Events wirft und ist ggf. ein Gefrickel...

- Wenn ASC eine Fahrt veranlasst, kannst du neuerdings den Fahrbefehl beliebig selbst manipulieren und z.B. per Perl-Funktion selbst checken, ob es sinnvoll ist, eine Kalibirerfahrt zu machen. Was nicht gehen dürfte, ist die prinzipielle Logik zu umgehen, mit der geprüft wird, ob überhaupt gefahren werden soll (Rollladen steht (vermeintlich) schon höher wie die neue Soll-Position nach oben fahren würde).

[zife]

Bekommt denn das eigentlich benutze Modul zur Steuerung der Rollos in FHEM eine vom Taster ausgelöste Fahrt mit? Ich bin der Meinung das so etwas über das eigentliche Modul gelöst werden sollte.

Lese hier aber sehr gerne mit.

Gesteuert werden meine Rollos über das 10_EnOcean-Modul von Klaus. fhem bekommt die Tasterfahrten mit, aber die daraus folgende Positionsbestimmung ist früher oder später daneben.

Klaus hat schon ausführlich und gut in zurückliegenden Fäden argumentiert, warum eine Positionsbestimmung nicht besser hinzubekommen ist. Ich hab im EnOcean-Bereich nochmal einen "letzten" Versuch gestartet - vielleicht gibt's noch einen Trick, der mir entgangen ist. Aber groß ist meine Hoffnung da nicht.

Ergänzend zwei Gedanken dazu:
- ROLLO (hier nicht als "Zwischenschicht" sondern als "Nebenschicht") könnte evtl. helfen, den "korrekten" (oder wenigstens korrekteren) Stand der Position zu ermitteln und dann per "setreading" oder "setstate" auf das EnOcean-Ding zu schieben. Setzt halt voraus, dass der Taster Events wirft und ist ggf. ein Gefrickel...

- Wenn ASC eine Fahrt veranlasst, kannst du neuerdings den Fahrbefehl beliebig selbst manipulieren und z.B. per Perl-Funktion selbst checken, ob es sinnvoll ist, eine Kalibirerfahrt zu machen. Was nicht gehen dürfte, ist die prinzipielle Logik zu umgehen, mit der geprüft wird, ob überhaupt gefahren werden soll (Rollladen steht (vermeintlich) schon höher wie die neue Soll-Position nach oben fahren würde).

Hmmm... ok, da muss ich mich mal tiefer eingraben. Mit ROLLO hab ich noch nichts gemacht... und mir eine Perl-Logik zu bauen, die die Kalibrierfahrt selbst ermittelt/durchführt, stellt mich vor eine gewisse (große) Herausforderung     Aber gut, ich geh mal schwanger mit der Idee und schau, was ich hinbekomme.

Mein Vorschlag zu so einer "Quick & Dirty"-Lösung kam neben o.g. eingeschränkten Fähigkeiten auch daher, dass es gemäß vergangener Threads/Posts zahlreiche Betroffene gibt, von denen viele eher im Perl-Anfänger-Status stehen

[Beta-User]

Gesteuert werden meine Rollos über das 10_EnOcean-Modul von Klaus. fhem bekommt die Tasterfahrten mit, aber die daraus folgende Positionsbestimmung ist früher oder später daneben.

Klaus hat schon [...]

Na ja, wenn der Maintainer das Thema kennt, wird es vermutlich kaum genauer werden mit ROLLO (obwohl da afaik ziemlich viele Optionen drin sind, die Laufzeit-Einflüsse zu berücksichtigen wie Anlaufzeiten, ...) 

und mir eine Perl-Logik zu bauen, die die Kalibrierfahrt selbst ermittelt/durchführt, stellt mich vor eine gewisse (große) Herausforderung     Aber gut, ich geh mal schwanger mit der Idee und schau, was ich hinbekomme.

Mein Vorschlag zu so einer "Quick & Dirty"-Lösung kam neben o.g. eingeschränkten Fähigkeiten auch daher, dass es gemäß vergangener Threads/Posts zahlreiche Betroffene gibt, von denen viele eher im Perl-Anfänger-Status stehen

Na ja, auch bei einer q&d-Lösung müßtest du ja eine Idee haben, wie das konkret aussehen soll. Wenn du das zeigst bzw. mal skizzierst, kann man ggf. helfen, eine Lösung zu bauen, die man dann auch im "getestete Hardware"-Thread verlinken kann...

[zife]

Also, ich werd mich jetzt erstmal mit ROLLO auseinandersetzen und sehen, ob das ein Weg sein kann.
Wenn das scheitert, mache ich mich an Plan B.

Meine erste Idee zu Q&D war ja im Eingangspost skizziert... ich verstehe schon, dass das nicht die "Aufgabe" des ASC-Moduls ist. Bin nur gerade etwas verloren, wo so eine "Korrekturfahrt" nun eigentlich am besten aufgehoben wäre - als Ergänzung im EnOcean-Modul, als Ergänzung im ROLLO-Modul, als Ergänzung im ASC-Modul, als Perl-Schnipsel zur Verwendung mit dem ASC-Modul oder, oder, oder 

Selbst schuld... Die Geister die ich rief     Jetzt schneid ich den Elefanten erstmal in Scheiben und schau mir ROLLO genauer an.

[Beta-User]

...ohne die (konkreten) Readings zum zeitpunkt einer solchen Fahrt zu kennen ist das nicht so einfach. Das Attribut nennt sich "ASC_CommandTemplate", als Beispiel findet sich:

Code Auswählen Erweitern

attr ROLLO ASC_CommandTemplate { fhem("set $name ".($pos+1024)).";set $name 0")}

Wenn du also alle Kommandos "durchlassen" willst bis auf das "mach zu":

Code Auswählen Erweitern

attr ROLLO ASC_CommandTemplate { return fhem("set $name $pos") if $pos; <hier dein Schwurbel-Code für die Kalibrierfahrt samt "sleep" auf die Beendigungsbedingung + Endpositionsfahrt>}

[zife]

Danke für die Starthilfe!

Wenn ich nicht gleich konkreter werde, liegt das nur daran, dass das Projekt gerade größer wird, als anfangs gedacht - und mein Zeitrahmen wg Job & Familie nicht so üppig ist. Ich fuchs mich da mal rein! Zumindest hab ich ja nun wieder Hoffnung, ASC doch noch mit den "dummen" Aktoren zum Einsatz zu bringen 

[Beta-User]

...wird schon...

PS: Ich bin in der "CUL_HM-Logik" verhaftet, da ist "0" geschlossen, und 100 offen. Bitte dadurch nicht verwirren lassen, ich hoffe, das Prinzip ist jetzt jedenfalls klarer...

Generell sollte es so sein, dass sich die Familie daran gewöhnen kann, dass ASC den Job so macht, dass der Gang zum Taster unnötig wird...

[zife]

Generell sollte es so sein, dass sich die Familie daran gewöhnen kann, dass ASC den Job so macht, dass der Gang zum Taster unnötig wird...

  Also... das Abbilden der Gedankengänge meiner Frau und Kinder in einer Logik dürfte noch den ein oder anderen KI-Spezialisten verschleißen... 

Ergänzend zwei Gedanken dazu:
- ROLLO (hier nicht als "Zwischenschicht" sondern als "Nebenschicht") könnte evtl. helfen, den "korrekten" (oder wenigstens korrekteren) Stand der Position zu ermitteln und dann per "setreading" oder "setstate" auf das EnOcean-Ding zu schieben. Setzt halt voraus, dass der Taster Events wirft und ist ggf. ein Gefrickel...

Sieht schon mal ganz gut aus, so bekomme ich zumindest eine deutlich genauere Position nach Taster-Fahrt hin. Ich bleibe dran.

[Beta-User]

Btw.: vermutlich ist dein Problem in https://forum.fhem.de/index.php/topic,126379.0.html ein Resultat aus setreading-Anweisungen, die du in diesem Zusammenhang hier absetzt...

[zife]

Danke für Idee... wäre mir auch zuzutrauen 

Allerdings... derzeit läuft "nur" ein zusätzliches ROLLO-Device, das ich erstmal in Kleinarbeit so justiert habe, dass die Position per Tasterfahrt halbwegs mit der Realität übereinstimmt. Es gibt hier also noch kein einziges "setreading" o.ä. ...

[zife]

So, ich mache Fortschritte. Ich habe nun ein ROLLO-Device angelegt ("Arbeitszimmer_RolladenR"), das genauere Positionen führt. Sobald sich dort das Reading "pct" ändert, überträgt ein Notify das per setreading an die Positionsangabe des eigentlichen (EnOcean)-Rolladen-Device ("Arbeitszimmer_Rolladen").

Das funktioniert soweit.

Nun kommt das ABER...
Weder fhemWEB noch mein Floorplan werden dadurch aktualisiert, obwohl fhemWEB longpoll auf 1 steht. Wenn ich das setreading per Kommandozeile absetze, ändert sich alles sofort und korrekt.

Hier mal mein NOTIFY:

Code Auswählen Erweitern

defmod RolloTasterSyncSchreiben notify .*_RolladenR:pct:.* {\
   my $RolloR = $NAME;; $RolloR =~ s/RolladenR/Rolladen/;;\
   fhem ("setreading $RolloR position [$NAME:pct]")\
}
attr RolloTasterSyncSchreiben group DOIF und NOTIFY Fenster
attr RolloTasterSyncSchreiben room Funktionen
Zur Erklärung: ich wollte nur ein NOTIFY für alle Rolläden. Also reagiert es auf egal welches ROLLO-Device, erkennbar am Namen "...RolladenR". Es leitet dann daraus das eigentliche Rolladen-Device ab, indem es "RolladenR" durch "Rolladen" ersetzt - und diesem Device dann die neue Position aus dem ROLLO-Reading "pct" ins Rolladen-Reading "position" schreibt.

Ist vielleicht nicht die eleganteste/kürzeste Variante, aber naja, irgendwo muss ich ja anfangen 


So... also bleibt nun die Frage: wie schaffe ich es, dass fhemWEB und Floorplan ohne Reload die neue Position zeigen?

[Beta-User]

Wenn du "im Kreis herum" per Eventhandler (ROLLO ist insoweit auch einer...) Readings an ein Device schreiben willst, muss die Benennung der Eventhandler passen! Siehe z.B. auch https://forum.fhem.de/index.php/topic,126409.0.html.
Vermutlich ist es in diesem Fall das einfachste, ein kurzes "sleep" vor das "setreading" zu packen, damit das außerhalb der Event-loop ausgeführt wird.

[zife]

Ok, das werde ich probieren... danke!

Hab gerade noch an einer weiteren Baustelle zu kämpfen, das pack ich aber in einen separaten Faden, sonst zerfasert der hier endgültig.
Wenn man an einer Stelle zieht, fädelt sich der ganze Pullover auf