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

[Beta-User]

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... 

[zife]

 

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).

[Beta-User]

  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).

[zife]

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...

[Beta-User]

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"

[zife]

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 

[zife]

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?

[Beta-User]

ad https://forum.fhem.de/index.php/topic,126566.msg1211716.html#msg1211716:

und dann per "setreading" oder "setstate" auf das EnOcean-Ding zu schieben.

Es war relativ bewußt von zwei Alternativen die Rede .

[zife]

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.

[Beta-User]

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:

Code Auswählen Erweitern

{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).

[zife]

jeeezzz... für einen trainierten if-Schubser mit kleinen Perl-Ausflügen geht's hier rund 
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