[73_AutoShuttersControl.pm] Neues Modul zum automatisierten steuern von Rolläden

[CoolTux]

Vielleicht mal wieder die Überlegung, ob man es nicht mit einer komplexeren Attributgestaltung im ASC-Device hinbekäme? Vielleicht mal als Idee:

Code Auswählen Erweitern

all_open:100,Jalousie_EZ.*:35:open,Jalousie_WZ:70:open,Rollladen.*:80:close
all_open als zentralen Kenner für den Extremfall, ansonsten alles nach dem Muster regex:<Grenzgeschwindigkeit>:<Reaktion>
Reaktion könnte auch ein Zielwert sein, der steht aber schon in einem Attribut, oder? Dann wäre es ggf. besser, dort den "Echtbefehl" für den Aktor zuzulassen (für CUL_HM: on/off).

Die Idee ist ja gut aber leider nicht zu realisieren. Wenn ich das ganze pro Rolladen mache, muss ich entsprechend die Einstellung für den jeweiligen Rolladen zuordnen können. Das kann ich auf diese Art leider nicht. Noch schlimmer wird es wenn es um ein Atributswert geht welcher in die NOTIFYDEV muss, also ein Device ist auf welches getriggert werden soll.

Aktuell wäre es möglich den Devicenamen einzeln als Attributswert zu nehmen und den Rest alles in ein zweites Attribut.

Hier mal ein Beispiel welches die Komplexibilität darlegen soll.

Code Auswählen Erweitern


Shutters/ASC-Device NOTIFYDEV                    Attribut
ASControl         AnniKraussStr                 ASC_residentsDevice
ASControl         AstroStahnsdorf                 ASC_twilightDevice
RolloKinZimIsabel_F2 FensterKontaktKinZimIsabel_F2 ASC_WindowRec
RolloKinZimSteven_F1 FensterKontaktKinZimSteven_F1 ASC_WindowRec
RolloKinZimSteven_F2 FensterKontaktKinZimSteven_F2 ASC_WindowRec
RolloWohnzimmer_F3 FensterKontaktWZ_F3         ASC_WindowRec
RolloKinZimIsabel_F1 HelligkeitsTempSensorKueche ASC_Brightness_Sensor
RolloKinZimIsabel_F2 HelligkeitsTempSensorKueche ASC_Brightness_Sensor
RolloKinZimSteven_F1 HelligkeitsTempSensorKueche ASC_Brightness_Sensor
RolloKinZimSteven_F2 HelligkeitsTempSensorKueche ASC_Brightness_Sensor
RolloKueche_F1         HelligkeitsTempSensorKueche ASC_Brightness_Sensor
RolloKueche_F2         HelligkeitsTempSensorKueche ASC_Brightness_Sensor
RolloSchlafzimmer_F1 HelligkeitsTempSensorKueche ASC_Brightness_Sensor
RolloSchlafzimmer_F2 HelligkeitsTempSensorKueche ASC_Brightness_Sensor
RolloWohnzimmer_F3 HelligkeitsTempSensorKueche ASC_Brightness_Sensor
RolloWohnzimmer_F4 HelligkeitsTempSensorKueche ASC_Brightness_Sensor


Alles unter NOTIFYDEV steht im INTERNAL NOTIFYDEV. Auf alle Events dieser Geräte spricht eine Routine an. Danach muss ich auswerten. Alles was ich habe ist der Devicename und das Event

Code Auswählen Erweitern


HelligkeitsTempSensorKueche brightness: 8000

Und nun versuche mal das ganze zu zuordnen. Es gilt erstmal raus zu finden was HelligkeitsTempSensorKueche überhaupt ist. Das Modul weiß es zu der Zeit ja noch gar nicht. Wofür ist das zuständig, was liefert es mir. Wind, Regen, Sonne, Temperatur. Das alles weiß das Modul ja gar nicht in dem Moment wo dieses Device Teil eines triggers ist.
Es gilt also eine einfache Art der Zuordnung zu finden und alle Rollos damit erfassen zu können welche das Event (Device) betrifft.

Ihr seht es ist nicht einfach und ich habe einen für mich akzeptablen Weg finden können.
Gerne bin ich für alternative Beispiele in Form von funktionierenden Code offen.


Grüße

[Beta-User]

Hmm,

sorry, mit fertigem Code kann ich nicht dienen, hoffe aber trotzdem eine Frage stellen zu dürfen: Greifst du eigentlich zur Laufzeit noch auf die Attribute zu oder holt sich das Modul nach dem Systemstart alle relevanten Werte aus den Attributen und verwendet dann anschließend die internen Infos?

Ich hatte den code so im Kopf, dass du im Kern recht wenige Abfragefunktionen intern nutzt, um rauszubekommen, was dich eigentlich grade interessiert, das aber immer wieder neu aus den Attributen extrahiert wird.

Wenn das erste (Auswertung zur Laufzeit aus den Attributen) der Fall sein sollte:
Vielleicht wäre es eine Überlegung (auch zur Vorbereitung des Wechsels auf das 2. Modell mit den internen Werten), dann einfach eine zweite Auswertelogik zu ergänzen, die (erst mal für einzelne Teilbereiche, hier erst mal angefangen beim Wind) nur noch die internen Werte verwendet.
Dann würde man dafür "nur noch" eine Logik pro Attribut benötigen, die die interne Datenstruktur aufbaut. Der Rest wäre dann identisch, würde aber auch intern (so mein begrenztes Perl-Verständnis) dann viel schneller ablaufen. So könntest du ggf. nach und nach dann auch die gesamte Logik so umbauen, dass man z.B. irgendwann die Infos aus einer Configfile oä. zieht, ohne dass das eine Revolution darstellt.

Dass das Extrahieren der Infos pro Rollladen-Device aus dem Vorschlag kein Hexenwerk (split+devspec2array, etwas Nachbearbeitung) ist, darüber sind wir uns einig, oder?
Wenn diese Gedanken grundsätzlich in die richtige Richtung gehen sollten, würde ich schauen, ob ich den "mach aus diesem doofen Atrributinhalt eine vernünftige Datenstruktur" - Code liefern kann. Ist zwar harte Arbeit, aber vielleicht kämen wir so vor dem Jahreswwechsel noch einen alternativen Weg zur Konfiguration des ganzen hin .

[CoolTux]

Hmm,

sorry, mit fertigem Code kann ich nicht dienen, hoffe aber trotzdem eine Frage stellen zu dürfen: Greifst du eigentlich zur Laufzeit noch auf die Attribute zu oder holt sich das Modul nach dem Systemstart alle relevanten Werte aus den Attributen und verwendet dann anschließend die internen Infos?

Ich hatte den code so im Kopf, dass du im Kern recht wenige Abfragefunktionen intern nutzt, um rauszubekommen, was dich eigentlich grade interessiert, das aber immer wieder neu aus den Attributen extrahiert wird.

Nur die Daten/Devices auf die getriggert werden soll sind einmalig eingelesen und dann immer fest.
Alles andere wird zur jeweiligen Laufzeit frisch ein gelesen. Ansonsten müsste man das Modul jedesmal neu laden wenn sich ein Attribut verändert.

Wenn das erste (Auswertung zur Laufzeit aus den Attributen) der Fall sein sollte:
Vielleicht wäre es eine Überlegung (auch zur Vorbereitung des Wechsels auf das 2. Modell mit den internen Werten), dann einfach eine zweite Auswertelogik zu ergänzen, die (erst mal für einzelne Teilbereiche, hier erst mal angefangen beim Wind) nur noch die internen Werte verwendet.
Dann würde man dafür "nur noch" eine Logik pro Attribut benötigen, die die interne Datenstruktur aufbaut. Der Rest wäre dann identisch, würde aber auch intern (so mein begrenztes Perl-Verständnis) dann viel schneller ablaufen. So könntest du ggf. nach und nach dann auch die gesamte Logik so umbauen, dass man z.B. irgendwann die Infos aus einer Configfile oä. zieht, ohne dass das eine Revolution darstellt.

Dass das Extrahieren der Infos pro Rollladen-Device aus dem Vorschlag kein Hexenwerk (split+devspec2array, etwas Nachbearbeitung) ist, darüber sind wir uns einig, oder?
Wenn diese Gedanken grundsätzlich in die richtige Richtung gehen sollten, würde ich schauen, ob ich den "mach aus diesem doofen Atrributinhalt eine vernünftige Datenstruktur" - Code liefern kann. Ist zwar harte Arbeit, aber vielleicht kämen wir so vor dem Jahreswwechsel noch einen alternativen Weg zur Konfiguration des ganzen hin .

So ganz Vorstellen kann ich mir Deine Idee noch nicht. Denke aber Du meinst das ich mir alle Values der Attribute und natürlich die Attribute und für welche Rolläden in einen internen Hash festhalten sollte. Kann man drüber nachdenken. Erster Kritikpunkt wenn Du das meinst wäre das wir dann doppelte Bestandpflege hätten, da es ja in FHEM bereits einen solchen Hash $defs gibt. Der macht ja genau das.

Nichts desto trotz können wir gerne versuchen eine bessere Möglichkeit zu finden. Einfach mal bisschen die Ideen ausprobieren.

[Beta-User]

Vorneweg: Ich bin immer noch Anfänger, was Perl & Co angeht und kenne vieles nur aus der Analyse von "fremdem" Code, will heißen: ich brauche immer ziemlich lange, bis ich mir eine Vorstellung von dem gemacht habe, was da abläuft. Und diese Vorstellung muß keineswegs richtig oder gar optimal sein. Sorry also, wenn ich mich da ggf, unpräzise äußere oder nur sowas wie ein Bauchgefühl dazu habe.

Nur die Daten/Devices auf die getriggert werden soll sind einmalig eingelesen und dann immer fest.
Alles andere wird zur jeweiligen Laufzeit frisch ein gelesen. Ansonsten müsste man das Modul jedesmal neu laden wenn sich ein Attribut verändert.

Das verstehe ich nicht. Es würde doch reichen, die relevanten Daten zu aktualisieren, und das ist m.E. völlig unabhängig von der Frage, wo die jetzt grade zufälligerweise konkret stehen. Dass man sie bei Bedarf dann da wieder rausholen muß, ist auch klar.

So ganz Vorstellen kann ich mir Deine Idee noch nicht. Denke aber Du meinst das ich mir alle Values der Attribute und natürlich die Attribute und für welche Rolläden in einen internen Hash festhalten sollte. Kann man drüber nachdenken. Erster Kritikpunkt wenn Du das meinst wäre das wir dann doppelte Bestandpflege hätten, da es ja in FHEM bereits einen solchen Hash $defs gibt. Der macht ja genau das.

Nichts desto trotz können wir gerne versuchen eine bessere Möglichkeit zu finden. Einfach mal bisschen die Ideen ausprobieren.

Das mit der doppelten Bestandspflege könnte sein, erledigt sich aber ggf. in dem Moment, wo wir wegkommen von der (reinen) Konfiguration über Attribute. Wenn man im ersten Angang nur "neue" Features wie Wind darüber abbildet, ist es gar nicht doppelt...
Oder anders betrachtet: Für's erste sind es ggf. zwar erst mal doppelte Daten, aber ganz ehrlich: es sind reine Textinfos, damit bekommt man nicht mal einen Pi in die Knie, oder?

Und ja, jedenfalls nach meinem begrenzten Perl-Verständnis müßte das schon irgendwo unter $defs liegen. Die Anregung war ja im Kern nur, das auf andere Weise als bisher ggf. da reinzuschreiben und auch wieder rauszuholen.
(Der Satz gefällt mir, denn der faßt den Grundgedanken des vorher geschriebenen ganz gut zusammen ).

[CoolTux]

Das verstehe ich nicht. Es würde doch reichen, die relevanten Daten zu aktualisieren, und das ist m.E. völlig unabhängig von der Frage, wo die jetzt grade zufälligerweise konkret stehen. Dass man sie bei Bedarf dann da wieder rausholen muß, ist auch klar.

Da fehlt mir gerade aktuell die Vorstellung wie genau das gemeint ist. Kann aber auch an meinen rauchenden Kopf liegen. Lach.
Wir können aber gerne einmal versuchen etwas zusammen zu tragen. Vielleicht redet es sich auch in einer Telko besser darüber.

[Beta-User]

Können wir gerne tun mit der Telco - mir raucht auch grade der Kopf ...

Aber nochmal zurück zu dem Wind-Thema: Wenn es keine doppelte Datenhaltung gibt, muß auch kein Attribut in irgendeinem anderen Device auf Änderung überwacht werden. Nur das "eigene". Dessen Änderungen bekommen wir mit und können das direkt auswerten bzw. die Daten aktuell halten. (Das andere ist eher eine theoretische Frage, die wir vermutlich gar nicht klären müssen).

Der Vorschlag vorher war: Bau eine neue, zusätzliche Auswerteroutine, die statt auf die Attribute fremder Geräte (die ja für die anderen Dinge vorläufig weiter relevant bleiben) auf einen internen Hash zugreift, und von da ab dasselbe macht bzw. zurückliefert... Die nutzen wir dann für den Zugriff auf die "neuen" Konfigurationsdaten.

Das ist erst mal Aufwand, aber eben auch der Einstieg in eine andere Art der Konfiguration als über die Attribute. Offener, flexibler. That's all...

Später können wir dann überlegen, ob und ggf. wie das insgesamt umgebaut werden kann und soll und wo die Konfigurationsdaten effektiv am besten aufgehoben sind. Aber ich würde damit anfangen, die auch für einzelne Rollläden vom Rollladendevice abzutrennen.



Vielleicht noch eine allgemeine Anmerkung:Als wir "noch im Urschleim" (zu Beginn der Entwicklung von Clunis Version) die Diskussionen hatten, wie das denn zu gestalten wäre, war die Überlegung, pro Rollladen vielleicht zwei Handvoll Attribute zu haben. Das wäre noch übersichtlich gewesen. Jetzt haben wir Mitte der 50, mit der Tendenz zu noch mehr, und es ist extrem schwer zu durchschauen, wie was zusammenhängt. Das ist bei einem derartigen Funktionsumfang vermutlich nicht ganz außergewöhnlich, aber wenn es wirklich gut - auch im Sinne von nutzerfreundlich (!) werden soll, benötigen wir eine besser strukturierte Nutzerführung, bei der der jeweilige Nutzer auch nur das sieht, was für ihn grade relevant ist.
Es tut mir sehr leid, dass ich selbst erst mehr oder weniger zeitgleich die ganzen Optionen zu erahnen begonnen habe, die sich mit der Modul-Variante ergeben, sonst hätten wir das ggf. vielleicht früher auf eine wechselseitig verständliche Weise diskutieren können.

Jetzt sollten wir das (endlich) irgendwie reparieren, glaube ich.

Aber auch an der Stelle nochmal: Es ist richtig toll, wie weit du gekommen bist und wie du die ganzen vielfältigen Wünsche umsetzt!

[CoolTux]

Wenn ich Dich also nun richtig verstanden habe wäre der Wunsch alle Einstellungen zentral vor zu nehmen. Natürlich mit der entsprechenden Zuteilung zu den jeweiligen Rollodevices. Eventuell über ein FHEMWEB Konfigurator vom Modul. Ich glaube Dan hatte da mal was angefangen bei Homemode.


Grüße

[Beta-User]

Das mit dem Konfigurator hast du gesagt, und auf die Idee, in diese Richtung zu denken hattest du mich erst neulich bei der ReadingsGroup-Geschichte gebracht ....

Aber im Kern ist das richtig, wir brauchen - jedenfalls in Teilen - irgendwas dynamischeres (auch im Sinne einer sinnvollen Kombination von notwendigen Informationen) als das heute mit der Attribut-Methode möglich ist.

Ob das am Ende eine Textfile ist, in der alles steht, Attribute, die dann nur noch im ASC-Gerät stehen, oder was auch immer: Mir im Prinzip egal. Aber eben einigermaßen übersichtlich (soweit das bei der Funktionsvielfalt möglich ist).

Den Konfigurator kenne ich btw. nicht, und auch an der Stelle gilt: ich bin gedanklich erst dabei, mich da in Grundlagen einzudenken, und Javascript wollte ich eigentlich nicht auch noch lernen. Wenn jemand zielführende Vorschläge hat oder diesen Teil gar programmieren will, dann sollten wir das annehmen.
Soweit mein programmiertechnisches Verständnis reicht, würde man dazu nur eine grundlegende Übereinkunft benötigen, wie was abzulegen ist. Textfile mit JSON?
Dann würden beide Enden die Daten da abholen/schreiben. That's all, oder?

Man müßte "nur" die Konfigurationsdaten erst mal datentechnisch von den Rollladen-Devices lösen (vielleicht sogar nicht mal das).

[stefanpf]

Ein paar unqualifizierte Kommentare / Gedanken von einem Laien:
Wäre etwas wie der "Edit Scenes" Dialog des Lightscene Modules am ASC Devices nicht ganz nett?
Statt der zu editierenden Szene wird der Rollladen gewählt und statt den Set Befehlen für die Devices stehen die jetzigen Attribute zur Verfügung

Aber: Charmant finde ich z.B. die Möglichkeit von Massenänderungen bei Attributen. So etwas wird mit einem einfachen Konfigurator vermutlich nicht mehr mit Bordmitteln möglich sein.

Mich stört allerdings die Menge an Attributen auch nicht wirklich. Letztendlich konfiguriert man da ja auch nicht ständig dran herum.
Da ließen sich sicher ein paar weg rationalisieren (z.B.
ASC_AutoAstroModeEvening und
ASC_AutoAstroModeEveningHorizon in einem Feld zusammenfassen).
So lange das Modul noch im "Wünsch dir was Modus" ist wäre das aber letztendlich  auch nur ein Tropfen auf den heißen Stein (es kommt ja immer mal wieder ein Parameter hinzu.

[Beta-User]

Vorab: Wir diskutieren auch Geschmacksfragen und Eindrücke.
M.E. ist es da zum sehr wichtig, auch und gerade die Meinung der "Betroffenen" zu hören. Also gibt es in diesem Bereich keine unqualifizierten Kommentare .

Der grundlegende Nachteil (bitte: das ist meine Meinung!) der Attribut-Lösung ist der, dass man alles auf einmal ausliefern muß und der "Einrichtende"  direkt mit einer ziemlich unübersichtlichen Menge von Optionen konfrontiert ist. Deren Wechselwirkungen zu verstehen, ist schon mal eine Aufgabe.
Man kann das mit guter Doku und ein paar Hilfsmitteln lindern - da ist dann der direkte Zugriff auf jedes Detail über ein einzelnes Attribut sogar hilfreich (weil über ReadingsGroup etc. einfach zugänglich).

Dass man die Mehrzahl der Vorgaben später nie mehr anfaßt, einfach weil sie Fakten wiedergeben, spräche dafür, das ggf. doch besser zu verdichten (die Winkelangaben z.B.).
Mit anderem will man "spielen", da wird es dann schwierig, wenn man unterschiedliche änderbare Einflüsse in einem Attribut zusammenführt.

"Massenänderungen" könnte man für wirklich dynamische Dinge per set im ASC-Device umsetzen, das wäre anders, aber vermutlich machbar.

Ein Konfigurator könnte vielleicht in Teilen aussehen wie ein lightscene-Dialog, das hängt aber sehr von den konkreten Umständen ab.

Als Idee finde  ich den Ansatz gut, den Einrichtungsdialog für den einzelnen Rollladen am ASC-Device aufrufen zu können, vielleicht auch spezielle Dialoge für Dinge wie die Winkelangaben, wo eine graphische Gesamtübersicht hilfreich ist.
Optimal wäre, wenn man in den Einzel-Geräte-Seiten dann auch wirklich nur das präsentiert bekommt, was "vorne" grundlegend ausgewählt wurde. Keine Beschattung? Ok, entsprechende Optionen sind gar nicht sichtbar und verwirren daher nicht.

Sowas ist sicher eine Aufgabe an sich, und eine statischere Variante täte es evtl. auch.

Bestimmte Bereiche sollten vielleicht sogar (als Attribut?) am Rollladendevice mit direktem Zugriff durch den/die Bewohner verbleiben, eben weil ggf. tatsächlich auch mal ein Resident eine andere Zeit eingeben will oder einen anderen Beschattungsgrad haben. Das sind aber vergleichsweise wenige (denke ich).

[mobiljoe123]

Ganz entspannt. Was ich sehe ist das jetzt erstmal alles korrekt erkannt und eingerichtet wurde. Und ich habe ein Event. Nun schaue ich einmal ob meine RexEx entsprechend greift und Du schaust bitte ob der Rest soweit funktioniert. Sprich fahren die Rollos bei den anderen Events. Morgens, Abends und was Du ausser Fenster sonst noch so eingerichtet hast.

Abends und Morgens hat es wie gewünscht funktioniert. 
Beschattung hab ich auch eingerichtet. Bewegt hat sich nichts. Ich hab allerdings mehrfach zum testen das ASC_twilightDevice gewechsel (zw. Astro und Twilight) Twilight aktualisiert schneller. Das ASC_Shading_Mode habe ich nur beim Rolladen auf on. Oder muss das auch "generell (auch im Device AutoShuttersControl)" auf on stehen?

[CoolTux]

Abends und Morgens hat es wie gewünscht funktioniert. 
Beschattung hab ich auch eingerichtet. Bewegt hat sich nichts. Ich hab allerdings mehrfach zum testen das ASC_twilightDevice gewechsel (zw. Astro und Twilight) Twilight aktualisiert schneller. Das ASC_Shading_Mode habe ich nur beim Rolladen auf on. Oder muss das auch "generell (auch im Device AutoShuttersControl)" auf on stehen?

Ich habe noch einen Fehler bei Dir gefunden. Warum hast Du das ASC Attribut auch im ASC Device selbst gesetzt? Das ist so nicht gedacht und wird sicherlich zu Problemen führen.

[CoolTux]

Ich habe nun auch im Modul den Code gefunden wo noch eine Anpassung für opened gefehlt hat.
Gibt morgen eine funktionierende Version für Dich per Update

[mobiljoe123]

Ich habe noch einen Fehler bei Dir gefunden. Warum hast Du das ASC Attribut auch im ASC Device selbst gesetzt? Das ist so nicht gedacht und wird sicherlich zu Problemen führen.

ich habs gelöscht.

Ich habe nun auch im Modul den Code gefunden wo noch eine Anpassung für opened gefehlt hat.
Gibt morgen eine funktionierende Version für Dich per Update

Danke.
Ich werde berichten.

[CoolTux]

ich habs gelöscht.Danke.
Ich werde berichten.

Und nun kann ich mir auch denken warum das automatische entfernen nicht geklappt hat.
Versuche mal bitte alle ASC_[GROSSERBUCHSTABE] Attribute aus dem ASC Device selbst zu entfernen.