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... 8)
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.
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.
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).
Zitat von: CoolTux am 21 Februar 2022, 11:21:51
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.
Zitat von: Beta-User am 21 Februar 2022, 11:24:28
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 ;D 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 ;)
Zitat von: zife am 21 Februar 2022, 11:38:35
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, ...)
Zitat
und mir eine Perl-Logik zu bauen, die die Kalibrierfahrt selbst ermittelt/durchführt, stellt mich vor eine gewisse (große) Herausforderung ;D 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...
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 ;D Jetzt schneid ich den Elefanten erstmal in Scheiben und schau mir ROLLO genauer an.
...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:
attr ROLLO ASC_CommandTemplate { fhem("set $name ".($pos+1024)).";set $name 0")}
Wenn du also alle Kommandos "durchlassen" willst bis auf das "mach zu":
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>}
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 :)
...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...
Zitat von: Beta-User am 21 Februar 2022, 12:23:59
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...
8) Also... das Abbilden der Gedankengänge meiner Frau und Kinder in einer Logik dürfte noch den ein oder anderen KI-Spezialisten verschleißen... ;D ;D ;D
Zitat von: Beta-User am 21 Februar 2022, 11:24:28
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.
Btw.: vermutlich ist dein Problem in https://forum.fhem.de/index.php/topic,126379.0.html (https://forum.fhem.de/index.php/topic,126379.0.html) ein Resultat aus setreading-Anweisungen, die du in diesem Zusammenhang hier absetzt...
Danke für Idee... wäre mir auch zuzutrauen 8)
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.ä. ...
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:
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 8)
So... also bleibt nun die Frage: wie schaffe ich es, dass fhemWEB und Floorplan ohne Reload die neue Position zeigen?
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.
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 :P
Nun ja, wenn man "ordentliche Hardware" hätte, müßte man sich nicht mit würgarounds plagen, die vertieftes Verständnis der Zusammenhänge erfordern... :P
:D
Tja, ich zerre mal meinen Elektriker hier rein und bewerfe ihn mit Bits & Bytes... leider hat das fhem-Fieber erst NACH Installation eingesetzt, und so reift diese Erkenntnis zu spät. Immerhin macht ein "vertieftes Verständnis" ja auch Spaß, da lerne ich gleich noch was.
Und mal eben 16 Aktoren umbauen ist nicht zuletzt auch eine finanzielle Frage, die sich aber wohl über kurz oder lang neu stellen wird bei dem Gefrickel (sofern es was Brauchbares bei Enocean-Geräten gibt, denn auf diesen Standard bin ich inzwischen festgelegt).
;D ja, manche Hardware-Entscheidung lernt man erst in der Rückschau richtig "zu schätzen", bei mir waren es "damals" die MiLights, die ich mir in größerer Menge reingezogen habe (zusammen mit dem falschen Modul dafür...).
Vielleicht hast du so große Erkenntnis-Gewinne, dass das am Ende in das EnOcean-Modul einfließen kann...? Oder du baust ein "ROLLO-add-on" für beliebige Aktoren, um nach externen Triggern die Positionen zu korrigieren...?
(Hätte auch nie geglaubt, dass ich jemanls irgendwas an allgemein verwertbarem Code beisteuern kann...)
(OT: Schöne Darstellung in dem anderen Thread, ich habe auch wegen einigen logs, die mir im Lauf der Zeit über den Weg gelaufen sind, den leisen Verdacht, dass ASC nicht an allen Enden effizient mit den Ressourcen umgeht, aber der Code ist mir ehrlich gesagt auch zu abstrakt, um dazu was substantielles sagen zu können).
Zitat von: Beta-User am 24 Februar 2022, 14:02:54
Vielleicht hast du so große Erkenntnis-Gewinne, dass das am Ende in das EnOcean-Modul einfließen kann...? Oder du baust ein "ROLLO-add-on" für beliebige Aktoren, um nach externen Triggern die Positionen zu korrigieren...?
Meine Lernkurve ist gerade sehr steil, aber ob sie steil und lang genug ist, um das zu schaffen, muss sich noch zeigen. An sich möchte ich gern was zurückgeben - an Motivation mangelt es jedenfalls nicht. Die Umstellung meiner (jahrzehntealten) Programmiererfahrung auf Perl & Co ist aber zäher als gedacht. Muss am ungefragt zunehmenden Alter liegen...
Zitat von: zife am 24 Februar 2022, 14:20:11
Meine Lernkurve ist gerade sehr steil, aber ob sie steil und lang genug ist, um das zu schaffen, muss sich noch zeigen. An sich möchte ich gern was zurückgeben - an Motivation mangelt es jedenfalls nicht. Die Umstellung meiner (jahrzehntealten) Programmiererfahrung auf Perl & Co ist aber zäher als gedacht. Muss am ungefragt zunehmenden Alter liegen...
...Rom wurde auch nicht an einem Tag erbaut, und ich habe mich auch etwas schwer getan, meine verstaubten "Kenntnisse" in der Excel-Makro-sprache aus Excel 4.0 auf Perl anzupassen... Jetzt kann ich auch "unleserlich schreiben" :P
Also, falls das noch irgendein Betroffener:in (m/w/d) mitliest, hier mein "Projektstand":
Der Versuch, via ROLLO-Modul die genaue Position nach Tasterfahrt zu ermitteln und ins eigentliche Rolladen-Device zurückzuschreiben, funktioniert zwar technisch - jedoch löst das ne Menge Systemlast aus. Das Rolladen-Device hat ja seine eigenen Positions-Readings, die z.B. ASC auswertet, und dann kommt von ROLLO nochmal eine Korrektur quergeschossen, die wieder Auswertungen nach sich zieht.
Das findet mein seniorer Raspi unlustig und reagiert mit zahlreichen kurzen Freezes.
Zweites Problem ist, dass ASC z.B. auf 70% fährt, aber dann ebenso ROLLO zuschlägt und besserwisserisch auf z.B. 69% korrigiert - und schon ist die ASC-Auswertung am Hinterteil. Die beiden so genau auszujustieren, dass solche Korrekturen nicht vorkommen, halte ich für unrealistisch.
Es muss also zum einen eine kleine Auswert-Pause eingebaut werden, um das dauernde Triggern von ASC auszufiltern. Und für Problem zwei müsste man entweder die Quelle des Fahrbefehls auswerten und dann wiederum ROLLO korrigeren... bla bla... laber...
Also in Summe ein unsägliches Gebastel, und alleine das Ausjustieren der ROLLO und der Rolladen-Device-Readings ist ein Krampf.
cmd: RESET Hirn.
Ich gehe nun also einen anderen Weg und teste, ob sich ROLLO statt als korrigierendes Neben-Layer doch als "Frontend" nutzen lässt. Dafür habe ich nun ein userReading gebaut, dass die Position auf 10er-Prozent rundet und habe ASC auf das ROLLO-Device umgelenkt. Auch in meinem Floorplan wird dann der Rolladen-Status des ROLLO-Devices gezogen.
Erste Testläufe sind vielversprechend. Ob das Last-Problem dem Ganzen am Ende des Tages dann doch noch das Genick bricht, bleibt abzuwarten. Ich lass das jetzt erstmal mit einem Test-Rollo so laufen und erweitere dann stückweise auf den Rest.
Sofern das hier kein Thread ist, denn nur ich lese, berichte ich gern über den weiteren Verlauf des Experiments. Und kaufe am Ende wahrscheinlich doch neue Aktoren ;D
In diesem Kontext... kann man irgendwie feststellen (im Rahmen eines NOTIFY oder DOIF), wer die Fahrt des Rolladen-Devices ausgelöst hat? Ich würde gerne eine ASC-ausgelöste Fahrt von einer manuellen Fahrt (sei es via fhemweb oder Taster) unterscheiden.
$NAME liefert mir ja den Namen des triggernden Devices, $SELF den des Notify und $EVENT das Event. Und ich kenne $data(sequence_source) im Kontext von SEQUENCE. Gibt es sowas auch für ASC?
ad https://forum.fhem.de/index.php/topic,126566.msg1211716.html#msg1211716:
Zitat von: Beta-User am 21 Februar 2022, 11:24:28
und dann per "setreading" oder "setstate" auf das EnOcean-Ding zu schieben.
Es war relativ bewußt von zwei Alternativen die Rede ;) .
Sorry, ich schnall's (noch) nicht.
Alles, was ich aus der Commandref lesen konnte, ist, dass ich mit setstate quasi einen Status ins Device "schummeln" kann, ohne ein Event auszulösen. Aber damit kann ich ja nicht "position" schreiben, nur "STATE" - wenn ich es richtig verstehe.
setreading löst wiederum ein Event aus, wenn das NOTIFY nicht das Gerät selbst betrifft.
Und wenn ich die Position so manipuliere, zerschieße ich ja vermutlich die ASC-Auswertung trotzdem - sprich: ASC fährt das Rollo auf Position 70, meine Korrektur-Funktion lauscht mit und meint, das auf 69 korrigieren zu müssen - und tschüß, ASC ::)
Ich versuche es hinzubekommen, dass mein Korrektur-Mechanismus nur greift, wenn der Auslöser der Fahrt mein Taster war, oder ne App, oder was immer so auf mein Rolladen-Device außerhalb fhem so einprasseln kann... dann ist die Fahrt nämlich eh manuell und ASC interpretiert es korrekt als solche - und die prozent-genaue Position ist wurscht.
Also... seh ich den Wald vor Bäumen nicht?
Bitte noch ein Puzzlestück Deiner Gedanken... ich seh das Zielbild noch nicht.
Parallel versuch ich es gerade auch andersherum und bastle an einer Positionserkennung über Timestamps des Tasters. Mal sehen, was am Ende am besten funktioniert.
Jein. Man kann mit setstate auch Readingswerte zuweisen, allerdings muss man dazu dann auch noch den Zeitstempel mitgeben (schau dir mal eine RAW-Definition von einem beliebigen Device mit Readings an).
Vermutlich wäre es einfacher, mit den readings.*update-Funktionen aus fhem.pl zu agieren, wenn man das haben will, hatte ich nicht in der Form auf dem Schirm.
Prinzipiell musst/kannst du ja abfragen, wohin ASC das jeweilige Rollo denn haben wollte: {ascAPIget('LastPos','<rollo>')}
Diesen Wert kann man vergleichen mit dem, was sich rechnerisch ergibt, und dann eben den "korrekten" Wert nehmen (das kann ja durchaus auch der Sollwert aus ASC sein...).
Ob der "korrekte" Wert triggernd gesetzt wird oder nicht, ist ASC übrigens egal, solange es nicht zu spät passiert (trigger nach der eingestellten Fahrtdauer => manual).
jeeezzz... für einen trainierten if-Schubser mit kleinen Perl-Ausflügen geht's hier rund 8)
Aber interessante Idee, danke! Bau ich mal in mein Puzzle ein und lasse die Idee in den Wettbewerb mit den anderen treten. Und wenn am Ende nur "Erfahrung" bei rauskommt, auch gut ;D