[73_AutoShuttersControl.pm] Rolllos automatisiert steuern - Version 0.6.x

[Loredo]

Du beziehst es jetzt ja auf Beschattung. Das gab es vorher ja nicht. Aber davon mal ab, was ist wenn nicht die Beschattungsposition aktiv war sondern eine andere Position, dann wird in Wind Protection gefahren als Beispiel und wenn Wind unprotected kommt wohin soll dann gefahren werden? Gar nicht, so habe ich Dich gerade verstanden, oder in die alte Position?

Beim Ereignis "Wind unprotected" sollte gar nicht gefahren werden. Wenn die vorherige Position manuell angefahren war, ist sie nach einem solchen Ereignis irrelevant.
Wenn die vorherige Position automatisch angefahren war, dann wird der Mechanismus, der das verursacht hat, dann wieder greifen. So ist mein Verständnis einer Automatisierung ganz generell. Es sollte so viel wie möglich automatisch passieren und wenn das richtig funktioniert, dann habe ich gar nicht mehr das Bedürfnis irgendwas manuell zu steuern. Und wenn ich es dann doch mache, dann weiß ich, dass die Automation aktiv ist. Wenn ich dann nicht will, dass sie gegen mich steuern könnte, dann stelle ich sie ganz aus (dafür hat ASC noch keinen globalen Setter mit Reading, fehlt halt noch). Du hast ja auch bereits eingebaut, dass nach einer manuellen Betätigung für eine gewisse Zeit kein Event mehr dagegen ansteuert. Das sollte ja dann reichen.

[CoolTux]

Wenn die vorherige Position automatisch angefahren war, dann wird der Mechanismus, der das verursacht hat, dann wieder greifen. So ist mein Verständnis einer Automatisierung ganz generell.

Das stimmt lediglich bei Beschattung oder Brightness. Fenster, Roommate oder Residents passt dann nicht mehr.
Aber ich habe kein Problem damit das so zu machen wenn die User es wollen.
Dabei fällt mir aber noch was ein.
Nehmen wir an es ist self defense auf absent und wir haben Wind Protection mit Rolllo auf.
Was hat mehr prio, Schutz des Rolllos oder des Eigentums? Self defense ist aktiv weil Fenster offen steht.

[christoph.kaiser.in]

Hallo,

ich habe seit Montag die Beschattung im Modul aktiviert und an einem Rollladen sehr "nervöses" Fahrverhalten. Die übrigen Rollläden sind unauffällig.

An diesem Rollladen ist Beschattung und die Fenstergriffüberwachung aktiviert.
Ich vermute diese Funktionen beinflussen sich gegenseitig. Kann es sein, dass in jedem Durchlauf eines Events des Fenstergriffs auch die Positionen der Beschattung bestimmt werden ? Das würde die kurzen Abstände zwischen den Fahrten erklären, da mein Griffsensor aktuell alle 15 min ein Statusprotokoll sendet. Anders kann ich mir das Fahrverhalten nicht erklären...

Werden die neuen Positionen im Griffevent nicht nur bei Änderung des Fenstergriffzustands ermittelt werden ?

Gruß
Christoph

[Cluni]

Hast du event-on-change-reading am Fenstersensor gesetzt?


Gesendet von iPhone XR mit Tapatalk

[christoph.kaiser.in]

Guter Punkt,

nein, natürlich nicht. Sensoren ausgepackt, montiert, eingebunden, ASC konfiguriert und "muss gehen".

Schaue ich mir an - sollte auch meine Eventlast erheblich reduzieren.

Danke !

[Loredo]

Ein nervöses Fahrverhalten sollte auch bei vielen Events nicht auftreten. Meine Wetterstation sendet alle 12 Sekunden und ich würde verrückt werden, wenn das so wäre
Es muss also irgendwo anders klemmen.

[CoolTux]

Ein nervöses Fahrverhalten sollte auch bei vielen Events nicht auftreten. Meine Wetterstation sendet alle 12 Sekunden und ich würde verrückt werden, wenn das so wäre
Es muss also irgendwo anders klemmen.

Wenn der Fensterkontakt jedesmal ein Event für state mit status open sendet und ASC der Meinung ist das Rolllo zu bewegen dann schon. Es ist ein unnötiger Event weil ja eigentlich gar nichts geändert wurde.

[Typ1er]

3 von 11 sind gestern wieder nicht runter. Die Position war falsch drin gestanden.

[CoolTux]

Aber die Position kommt ja von Deinem Rollomodul. Hast du auch das Problem das da immer ein oder zwei Unterschied zur eigentlich abgefahrenen Position steht?

[Typ1er]

Es kommt scheinbar gar keine 

[Loredo]

Das stimmt lediglich bei Beschattung oder Brightness. Fenster, Roommate oder Residents passt dann nicht mehr.
Aber ich habe kein Problem damit das so zu machen wenn die User es wollen.

Fenster und wach/schlafen ist ja auch soweit ok. Es geht ja um die Art Events, die den regulären Ablauf unterbrechen. Ich stehe wohl eher regelmäßig/täglich auf und gehe zu Bett, auch Fenster öffne und schließe ich mehrfach täglich. Regen, Sturm (als Negativevents) oder Sonne (als "Positivevent") in der Art, dass es einer Handlung bedarf, habe ich aber außerplanmäßig. Dieser Ereignisse "stören" den normalen Ablauf und entsprechend bestimmen sie dann den Betrieb, solange diese Ausnahme besteht. Fällt die Ausnahme weg, geht alles zum "Alltag" zurück. Man müsste also alle Use Cases einmal in (mindestens) diese zwei Kategorien einteilen. Grob gesagt gibt es dann im Regelbetrieb Use Cases, die allesamt gleichberechtigt ablaufen und entsprechend aufeinander abgestimmt sein müssen. Außerhalb des Regelbetriebs gibt es jedoch dann eine ganz klare Hierarchie, bei der der kritischste Use Case ganz vorne an steht und ganz am Ende der Regelbetrieb bleibt. Daraus ergibt sich dann automatisch ein "Rückfall" in den Regelbetrieb, sobald alle außerplanmäßigen Zustände nicht mehr zutreffen.

Dabei fällt mir aber noch was ein.Nehmen wir an es ist self defense auf absent und wir haben Wind Protection mit Rolllo auf.Was hat mehr prio, Schutz des Rolllos oder des Eigentums? Self defense ist aktiv weil Fenster offen steht.

Das kommt auf den Typ des Rollos an. Das ist bisher ja nicht berücksichtigt.
Beim Typ "Lamellen" oder "Markise" ist es wichtiger sie vor dem Wind in Sicherheit zu bringen. Beide haben ohnehin keinen großen Gewinn für die Sicherheit.
Richtige Rollos hingegen haben eine tatsächliche Schutzwirkung (besonders die aus Alu und nicht nur aus Kunststoff). Wenn diese 100% geschlossen sind, bieten sie dem Wind in der Regel nicht mehr genug Angriffsfläche und können getrost unten bleiben. Bedeutet natürlich, dass sich die Fahrposition nochmals von der ansonsten "closed" Position unterscheiden kann. Ist aber auch nicht tragisch, denn Self-Defense sollte sich IMHO entweder beim Status "gone" aktivieren oder bei "absent", sofern ein Fenster offen ist oder auf kipp (hier jedoch nur, wenn es sich um ein zugängliches Fenster handelt wie bei Terrasse, Balkon, Erdgeschoss, etc.).

Innenrollos hingegen sind komplett egal. Wenn dort jemand solche Funktionen alle aktiviert hätte, dann hätte halt der Sicherheitsaspekt Vorrang.

Für eine korrekte Steuerung und Entscheidung fehlen also noch so manche Eingangswerte. Ich denke aber das klingt erstmal komplizierter als es am Ende sein muss.
Ich gehe bei meinen Modulen/Automationen immer so vor, dass ich mir sämtliche Eingangsgrößen, die mir einfallen, definiere und dann schaue, was ich mit ihnen anstellen kann. Das kann vielleicht dann auch bedeuten, dass ich Daten erfasse, die erstmal (noch) nicht verwendet werden. Es hilft aber einen möglichst breiten Überblick zu bekommen und anfänglich Zusammenhänge besser zu erkennen.

Ich vermute stark, dass der aktuelle Stand von ASC ein hervorragendes/r Proof-of-Concept/PoC ist, man letztendlich aber mit den Lessons Learned dann nochmals sauber die Anforderungen definierten sollte, alle Eingangsgrößen und dann in der Kombination ein Ablaufdiagramm anfertigt, auf dessen Basis man dann die Modullogik für eine Version "2.0" programmieren kann.
Ob es dabei tatsächlich hilfreich ist das ganze nicht nur als Perl Package zu kapseln, sondern auch noch objektorientiert zu bauen, lasse ich mal dahin gestellt. Bisher habe ich den Eindruck, dass es keinerlei Vorteile bringt, dass das Modul intern objektorientiert programmiert wird, sondern im Gegenteil es schwierig ist bereits einfachere Logiken umzusetzen (Beispiel: das selbe Device mit unterschiedlichen Readings für unterschiedliche Sensorik nutzen).

[CoolTux]

Es kommt scheinbar gar keine 

Aber das liegt ja dann n Deinem Modul zur Rolllosteuerung. Was hast Du denn da?

[christoph.kaiser.in]

Wenn der Fensterkontakt jedesmal ein Event für state mit status open sendet und ASC der Meinung ist das Rolllo zu bewegen dann schon. Es ist ein unnötiger Event weil ja eigentlich gar nichts geändert wurde.

Jein, es sollte dann aber auch nicht bei einem Durchlauf ohne Griffstatusänderung eine Fahrt auf die Comfort Open Position Ventilation Position (70) ausgelöst werden, wie es bei mir der Fall war. Maximal würde ich erwarten ,das die Rollläden zwischen der Shading Position und der Open Position hin und her pendeln.

...was zum knobeln ?

[EDIT]: Die Fahrten auf Komfort Closing (10) waren echte Anforderungen über den Griff bzw. Der Griff stand auf "open"

[CoolTux]

Wie stand den der Drehgriff zu der Zeit? Auf Open?

[christoph.kaiser.in]

Kläre ich heute Abend. Ist aus der Ferne nicht so einfach heraus zu bekommen, da das Plot nichts anzeigt (Konfiguration).

Unter Vorbehalt "closed".

[EDIT 18:02 Uhr]: Fenstergriffposition am vormittag aus dem Logfile bestätigt. Die einzigen Anforderungen sind zwei bekannte Anforderungen Griff "open" um ca.18:56 und 19:53 für je ca. 20s. Danach wieder Griff "closed".

Damit kann ich mir das Verhalten auf meinem Screenshot so beschreiben:

07:00 - Automatik Öffnen in Position Shading (50). Dort bereits Wechsel zwischen Position Shading (50) und Ventilation(70) . Dann gewollte Konfiguration der Position Shading (50 -> 40). Danach den ganzen Tag Wechsel der Position Shading (40) mit Ventilation (70). Um 18:56 Griff wechsel auf "open" - dann Start der Wechsel Position Shading (40) und Comfort Open (70). Kurze Pause nach Schließen des Griffs (Wartezeiten ?). Zweite Phase mit Griff in "open"- dann Automatik schließen um ca. 20:48.

Alle Wechsel sind auch tatsächlich gefahren worden.

Seit dem ich

Code Auswählen Erweitern

attr <Fenstergriff> event-on-change-reading
beim Fenstergriff gesetzt habe - Ruhe. -> Das bestätigt den Zusammenhang mit den Events der Grifferkennung.

Konfiguration des Rolladens: Türgriff, threestate; Comfort Öffnen on, Beschattung on; Shutterplace: TERRACE
UND: Rolladen Küche: Türgriff, threestate; Comfort Öffnen on, Beschattung OFF; Shutterplace: window
UND: Rolladen Essbereich.Rechts: Türgriff, threestate; Comfort Öffnen on, Beschattung on; Shutterplace: window