[73_AutoShuttersControl] unterschiedliche Positionsangaben in den Pos Attributen

CoolTux · 18 April 2020, 10:13:40

Guten Morgen,

Da schon sehr oft und auch angebracht "Kritik" zur Auswertung oder Erkennung einer Fahrt geäußert wurde und darum gebeten wurde doch nicht mit Positionen sondern mit dem Fahrgrund (also lüften, beschatten etc) zu arbeiten möchte ich hier meine Probleme beim Umsetzen einmal vorstellen.
Kurz nur erwähnt. Ich sehe aktuell keine andere Lösung. Da aber viele Leute hier tolle Ideen schreiben möchte ich versuchen zu erklären wie so ein Ablauf innerhalb von ASC funktioniert und wieso ich denke das es nicht ohne Positionsangaben geht. Wer eine bessere Lösung (funktional) findet immer her damit.

Ein Beispiel wäre ich schließe das Fenster

Code Auswählen

         (
               $match =~ m{[Cc]lose|true}xms
            && IsAfterShuttersTimeBlocking($shuttersDev)
            && (   $shutters->getStatus == $shutters->getVentilatePos
                || $shutters->getStatus == $shutters->getComfortOpenPos
                || $shutters->getStatus == $shutters->getOpenPos )
            && (   $shutters->getVentilateOpen eq 'on'
                || $ascDev->getAutoShuttersControlComfort eq 'on' )
         )

Es wird hier also explizit geschaut ob das Fenster aktuell in eine "Fenster offen Position" steht. Dies wird natürlich an Hand der jeweiligen Positionsangaben gemacht.
Wenn das Rollo nun aber in der Beschatten Position steht oder sogar wie schon mal von Usern erzählt in eine manuelle Position, dann wird aktuell das Rollo nicht gefahren.
Ist nun aber die "Beschatten Position" gleich der (Ventilate Position) also einfach lüften dann würde das Rollo am Tag entsprechend in die letzte Stellung fahren (vor dem Beschatten) oder ganz nach oben.

Dies ist ein hoffentlich einfaches Beispiel. Mich würde nun interessieren wie man das anders lösen könnte.
Aktuell versuche ich zu mindestens andere Abhängigkeiten auf zu lösen was Positionsabfragen an geht. Aber die "Fenster offen" Positionen würden nach aktuellem Stand übrig bleiben.

Grüße
Marko

Wscheff · 18 April 2020, 11:52:05

Mir fällt dazu nur spontan ein Reading ein, dass den aktuellen Status als Zahl oder Text wiedergibt. Das wäre dann eineindeutig.

Beta-User · 19 April 2020, 08:21:30

Vorab: Ich habe nicht in den aktuellen Quelltext gesehen, meine aber beim letzten Blick da rein verstanden zu haben, dass bei jedem Fahranlass _innerhalb dieser Unterroutine_ geprüft wird, ob zu fahren ist und dann jeweils erst der Fahrbefehl abgesetzt wird.

Ich _glaube_ (Achtung: Bauchgefühl), dass es besser wäre, aus den einzelnen anlassbezogenen Unterroutinen _immer (indirekt) die Fahrroutine_ anzusteuern. Mit indirekt ist gemeint: eine allgemeine "state machine" (ob der Begriff paßt?) zwischenzuschalten, und der dann aber auch den Fahranlass mitzugeben (und den ggf. weiterzureichen an den eigentlichen Fahrbefehl, damit man ggf. eigene Perl-Routinen "anflanschen kann" wie das Anliegen von Typ1er von gestern mit der sehr unterschiedlichen Reaktion bei Beschattung). Weiter könnte man auch ein "delete" für bestimmte Zustände an die "state machine" weitergeben.

Die "state machine" müßte dann erst entscheiden, was zu tun ist (also - ggf. in veränderter Form - diese ganzen Abfragen durchführen (so noch erforderlich) und dann letztendlich erst den eigentlichen Fahrbefehl "raushauen" oder eben nicht.

Weiter _glaube_ (wieder Achtung: Bauchgefühl), dass wir uns (ob Reading oder als im Lauf der Zeit zur Laufzeit entstehende komplexere Datenstruktur) einige Dinge "merken" sollten:
- Den "Grundlevel" = Tag- oder Nacht-Position
- temporäre "override"-Zustände (solange sie gelten!): Wind, Beschattung, Fenster-offen/gekippt, Frost, ...
- Eingriffe des Users einschl. deren Zeitstempel
(- evtl: Fahrterkennung - ist aber ein komplexes Thema, sollten wir gesondert behandeln; aber: Wenn wir den Ziellevel kennen, könnten wir gleich entscheiden, ob wir ihn ändern, wenn wir ihn nicht kennen, könnten wir die EDIT: ~~Fahrroutine~~ "state machine" mit einem InternalTimer wiederholt mit denselben Parametern aufrufen...)

Macht man das über eine zentrale Funktion, könnte man vermutlich auch einfacher die internen Abhängigkeiten erkennen und ggf. sogar durch den user änderbar konfigurieren, indem man default-Prioritäten vergibt (for ... sort keys). Stellt man die Prioritäten im list dar, wird für den user evtl. auch leichter erkennbar, warum etwas passiert ist bzw. warum ggf. nicht?

Ist eventuell noch nicht zuende gedacht, aber das war in etwa der gedankliche Hintergrund, warum ich neulich geschrieben hatte, dass es m.E. Sinn macht, aus den Teilfunktionen den Fahranlass auch mit zu übergeben. Bitte nachfragen, wenn was unverständlich sein sollte...

Beta-User · 19 April 2020, 09:24:12

Hmm, sobald man was zu Papier gebracht hat und etwas drüber nachdenken kann, kommen noch mehr Gedanken:

- Gibt es eine zentrale "state machine", könnte man als User/Mitentwickler die recht einfach tauschen (als Experten-Modus-Attribut oder notfalls im Code selbst).
- Meine mich zu erinnern, dass es Anfragen gab, (bestimmte?) Fahrbefehle ggf. auch wiederholt rauszuschicken "ohne Rücksicht auf Verluste". Wenn der Zeitpunkt (und Anlaß) des letzten Fahrbefehls bekannt ist, kann man den ggf. in einstellbaren Mindestintervallen auch wiederholen, wenn entsprechende Events eingegangen sind...
(Wieder so eine Art Expertenmodus)
- Wenn der Zeitpunkt des letzten eigenen Fahrbefehls bekannt ist, ist es einfacher zu entscheiden, ob eine "externe Fahrt" vorliegt oder eine "eigene": Z.B. CUL_HM-Devices senden "motor"-Events, sobald sie laufen bzw. beim anhalten, der ZWave sendet dann (verzögert) einen Verbrauchswert. Greifen wir diese bestimmten Events ab und vergleichen die Zeitstempel, wissen wir mit einiger Wahrscheinlichkeit, ob ASC der Verursacher war oder nicht... (die Events sind aus der Hüfte geschossen, müßte man ggf. nochmal separat sammeln).

JWRu · 19 April 2020, 10:43:15

Da ihr alle mitten im Brainstorming seid, will ich mal etwas beteiligen:
Wenn man die verschiedenen Funktionen von einander trennt, könnte man sie im Programmablaufs auch leichter bypassen oder disablen.
Ich weiß nicht, ob das jetzt schon passiert, dass z.B. mit dem Reading controlShading die ganze Beschattungsroutine abgeschaltet wird oder mit selfDefense die entsprechende Routine.
Genauso könnte man sich ein Reading controlSlats oder controlFreeze vorstellen. Der Benutzer, der z.B. nur Abend- und Morgenfahrt nutzen will, schaltet alle auf off und das Programm läuft entsprechend schlank.

CoolTux · 19 April 2020, 11:15:33

Zitat von: JWRu am 19 April 2020, 10:43:15
Da ihr alle mitten im Brainstorming seid, will ich mal etwas beteiligen:
Wenn man die verschiedenen Funktionen von einander trennt, könnte man sie im Programmablaufs auch leichter bypassen oder disablen.
Ich weiß nicht, ob das jetzt schon passiert, dass z.B. mit dem Reading controlShading die ganze Beschattungsroutine abgeschaltet wird oder mit selfDefense die entsprechende Routine.
Genauso könnte man sich ein Reading controlSlats oder controlFreeze vorstellen. Der Benutzer, der z.B. nur Abend- und Morgenfahrt nutzen will, schaltet alle auf off und das Programm läuft entsprechend schlank.

Die erwähnten Readings schalten bereits die komplette Routine ab. Also controlShading und selfDefense zentral im ASC

flummy1978 · 19 April 2020, 16:22:02

Aloha,

Vielleicht auch etwas zu einfach gedacht, aber vielleicht ist es auch eine Möglichkeit. Was spricht denn gegen ein vollständiges Ignorieren des aktuellen Zustandes und ein Beachten dieses erst bei der zentralen und eigentlichen Bearbeitung des Fahrbefehles ?

Mein Gedanke führt in die Richtung:
alle Routinen die dieses Reading berücksichtigen, werden bearbeitet -> jede Routine gibt eine Rückmeldung ob von dieser Routine aus eine fahrt notwendig wäre.
Das Ganze geht durch alle Routinen durch.
Am Ende kommt von jedem Teil ein Ergebnis heraus wie, das zusammengefasst so etwas herausgibt: Shading pos = 0 Lüften pos = 1 windschutz = 1 regenschutz = 0 usw
Ab hier werden lediglich die Routinen beachtet die eine Fahrt notwendig machen würden. Diese werden dann mit der aktuellen Position verglichen

Alle Routinen, die sich INNERHALB von dieser Position befinden, fliegen wieder raus und am Ende kann es folgende Ergebnisse geben:

- Es bleiben übrig z.B. Regenschutz UND Windschutz -> weil beide die gleiche Position haben -> wird in diese Position gefahren.
- Es bleiben übrig z.B. Regenschutz UND Sonnenschutz UND Privacy (weil alle außerhalb der akt. Position liegen ) -> die einstellbare Priorät kommt zum Tragen -> abhängig dieser wird in die Position gefahren die die Priorität* vorgibt.

So könnte man ein eindeutiges Ergebnis am ende haben und es würde nur aus einem einzigen Grund gefahren werden.

* Die Priorität muss VORAB unterscheiden ob die Blockingzeit beachtet wird (manuelles fahren, shading usw JA - Regenschutz, Windschutz, Lockout NEIN).
Darüberhinaus ist die Priorität imho der variabelste Grund, weil für jeden User (manchmal auch innerhalb des Hauses) die Priorität wo anders liegt. z.B. würde bei meiner Markise Wind + Regen (gleiche Pos) > Sonne (gegenüberliegende Position) > alles andere folgt danach. Bei 2 meiner Rollos wiederum Sonne > Privacy > Zeiten > Wind > alles andere usw.

Vielleicht ist das ja eine Idee, mit der man was anfangen kann.....

Viele Grüße
Andreas