Wiki zu AutoShuttersControl

Begonnen von Beta-User, 18 Februar 2019, 16:46:05

Vorheriges Thema - Nächstes Thema

Beta-User

Hallo zusammen,

nachdem das AutoshuttersControl-Modul jetzt nicht nur einen großen Funktionsumfang sowie eine hohe Stabilität aufweist, hier also der Thread zum Wiki-Artikel, um das aus der allg. Diskussion zum Modul rauszulösen.
Ziel des Threads ist es v.a. ggf. Unklarheiten bei der Vorgehensweise der allg. Darstellung zu beseitigen - daher der Aufruf an die anderen Beteiligten an dem Artikel: Da gibt's noch einige Leerstellen und offene Fragen...
Zum anderen dürfen user hier gerne eine Anlaufstelle für das Melden von Fehlern sehen (so es denn welche geben sollte 8) ...)

An der Stelle auch nochmal ein ausdrückliches Danke!!!! an:
- CoolTux für's Erstellen des Moduls;
- Cluni und Frini für die Vorarbeit am Ausgangscript;
- hugomckinley für viele grundlegenden Gedanken und
- den vielen bisher schon an der Artikelerstellung Beteiligten für die umfangreiche Vorarbeit!

Gruß, Beta-User
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

CoolTux

Thema Beschattung.

- man brauch ein Astro oder Twilight Modul (wird automatisch erkannt beim anlegen oder FHEM Start)
- ein Brightness Sensor
- ein Temperatursensor

Dann gibt man noch folgende Werte genau mit an
- ASC_Shading_Direction ist die Richtung des Fensters. Kompass nehmen
- ASC_Shading_Angle_Left - Sonneneintritt ins Zimmer. Also ASC_Shading_Direction - ASC_Shading_Angle_Left = Eintritts Winkel. -90 wäre sehr steil, daher 85
- ASC_Shading_Angle_Right - das selbe wie ASC_Shading_Angle_Left nur halt Sonnenaustritt also ASC_Shading_Direction + ASC_Shading_Angle_Right ergibt austritt und somit keine Sonne mehr im Raum.
- ASC_Shading_Min_Elevation - Sonnenhochstand. Im Winter weniger so um die 10-15 im Sommer mehr so ab 25 / 30 Februar Mai
- ASC_Shading_StateChange_Sunny Brightness Wert ab dem in die Beschattung gefahren werden soll, wenn auch alles andere passt
- ASC_Shading_StateChange_Cloudy Brightness Wert aus dem aus die Beschattung gefahren werden soll, wenn auch alles andere passt


Der Rest sollte selbsterklärend sein


Grüße
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

Beta-User

Zitat von: CoolTux am 18 Februar 2019, 17:08:55
Thema Beschattung.
[...]
Der Rest sollte selbsterklärend sein

Das meiste schon, habe den Input gleich noch verarbeitet :) .

Sorry, wenn ich das ausdrücklich nicht nochmal geschrieben habe, die praktische Frage war auch: Was macht man denn zweckmäßigerweise auf der Nordseite mit den Winkelangaben? Einfach die Richtung festlegen und die 85° da lassen oder ändern?
Und: dort besser eine andere Mindesttemperatur festlegen?

Vielleicht eine grundsätzliche Anmerkung: Letzteres ist eher eine Praktikerfrage, das hat nicht so viel mit der Modulfunktionalität an sich zu tun, das Modul nimmt eben den objektiven Wert und "macht dann mal". Ähnliches gilt für die Beschattung. Eigentlich will ich das nur im Sommer anwenden, habe aber noch keine so richtig klare Vorstellung, was zweckmäßige Einstellungen für einen ersten Start sind.
Sowas fände ich als Anwenderhinweise noch gut, auch wenn da sicher viele subjektive Dinge reinspielen und es "die" Lösung kaum geben wird...

Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

CoolTux

Hast Du im Norden jemals die Sonne gesehen mein Bester?  ;D
Fenster im Norden behalten den Wert off beim Attribut Shading_Mode.


Grüße
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

Beta-User

Meine Güte, ich die Bäume und der Wald  ::) ??? ::) ... Danke!

(Aber im Ernst: das Haus ist leicht gedreht, und auch durch die Nordfenster kommt hin und wieder ein Sonnenstrahl... Vielleicht mache ich da trotzdem Beschattung, wenn's richtig heiß wird? Werde dann schon merken, ob das Modul versehentlich übersehene negative Werte mag ;D 8) )
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

CoolTux

Bin gespannt was dabei raus kommt.
Ich habe sowas ähnliches bei meinen Nord-Ost Fenstern. Frühs scheint die Sonne rein und das blendet beim Frühstück. Da werde ich auch beschatten.
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

Beta-User

Kurze Info:
Im Wiki ist jetzt auch die gestern vorgestellte readingsGroup zu Beschattung zu finden, mit ein paar kleineren Änderungen. Finde das so jetzt eigentlich ganz praktisch und halbwegs intuitiv zu bedienen mit den diversen Winkelangaben usw.. Es ist nur leider teilweise ein wenig "fummelig", einen genauen Wert zu treffen, wenn die Rasterung sehr fein ist (z.B. 360 Schritte aus 360 zu direction).

Jedenfalls für die ganzen Winkelfunktionen ist der "knob" m.E. optimal, weil die graphische Aufarbeitung recht leicht "in die Wirklichkeit" übersetzt werden kann und umgekehrt. Das widget hat einige Einstellmöglichkeiten, einiges ist da jetzt auch hoffentlich sinnstiftend umgesetzt, aber wenn da jemand Verbesserungsideen hat: her damit!

Im Moment bin ich noch am Zaudern, ob es nicht auch für die allgemeine Level-Einstellerei passend wäre, dazu alternativ eine graphische Variante zu präsentieren? Leider gibt es aber keinen "Hochkant"-Slider, und ob man den allgemeinen vertikalen verkleinern kann, habe ich noch nicht getestet, bezweifle das aber. Bliebe wieder der knob...
Meinungen dazu?
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

CoolTux

Ich würde die ganze readingsGroups gerne bei Gelegenheit mit in den Modulcode nehmen.


Grüße
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

Beta-User

Von mir aus gerne!

Wie soll das konkret aussehen?
Es müßten ja irgendwie auch die Sonderfälle (wie die 99 statt 100 max. Öffnung) berücksichtigt werden (und Mischungen der Typen...). Klingt nach einer Menge Arbeit!
Oder soll das "nur" ein "set ASC makeReadingsGroup level 99" werden?

Nochmal eine allgemeine Anmerkung: Eigentlich fände ich es zwischenzeitlich besser, wenn die ganzen Vorgaben intern verwaltet würden, ins Unreine gesprochen: Ein Rollladen, der das allg. Attribut ASC hat und mit "3" belegt ist, verhält sich wie ein "1"-er, aber die ganzen Attributwerte werden (als Readings oder Internals?) beim ASC-Gerät verwaltet und nicht mehr am Rollladen. (Nur) beim ASC können sie dann eingestellt werden (ggf. in einem Dialogfeld oder so, aber eben "auf einen Rutsch", mind. pro Rollladen, am "schönsten" wäre es in entsprechenden Übersichten zentral).
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

CoolTux

Zitat von: Beta-User am 20 Februar 2019, 12:14:51
Von mir aus gerne!

Wie soll das konkret aussehen?
Es müßten ja irgendwie auch die Sonderfälle (wie die 99 statt 100 max. Öffnung) berücksichtigt werden (und Mischungen der Typen...). Klingt nach einer Menge Arbeit!
Oder soll das "nur" ein "set ASC makeReadingsGroup level 99" werden?

Nochmal eine allgemeine Anmerkung: Eigentlich fände ich es zwischenzeitlich besser, wenn die ganzen Vorgaben intern verwaltet würden, ins Unreine gesprochen: Ein Rollladen, der das allg. Attribut ASC hat und mit "3" belegt ist, verhält sich wie ein "1"-er, aber die ganzen Attributwerte werden (als Readings oder Internals?) beim ASC-Gerät verwaltet und nicht mehr am Rollladen. (Nur) beim ASC können sie dann eingestellt werden (ggf. in einem Dialogfeld oder so, aber eben "auf einen Rutsch", mind. pro Rollladen, am "schönsten" wäre es in entsprechenden Übersichten zentral).

Gerne. Wenn ich mal viiiel Zeit habe, hihi. Da gibt es dann nämlich eine Menge zu beachten. Alleine schon das nach einem Neustart zu mindest die Internals nicht mehr da sind. Als Reading lässt sich reden. Im besten Fall eventuell in einem Konfigfile.
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

Beta-User

Zitat von: CoolTux am 20 Februar 2019, 12:23:11
Gerne. Wenn ich mal viiiel Zeit habe, hihi. Da gibt es dann nämlich eine Menge zu beachten. Alleine schon das nach einem Neustart zu mindest die Internals nicht mehr da sind. Als Reading lässt sich reden. Im besten Fall eventuell in einem Konfigfile.
;D
Schon klar, dass das eine Menge Arbeit ist, aber auf der anderen Seite (für den Fall, dass das nicht schon länger so ist, habe den Code schon eine ganze Zeit nicht mehr durchgesehen ;) ): warum nicht die Logik in Schritt 1 so umbauen, dass nicht bei jedem Befehl noch erst die Infos ausgelesen werden, sondern das _einmal_ nach INITIALIZED machen (und ggf. nur updaten, wenn was geändert wurde). Dann wäre es fast egal, woher die Daten kommen, nach dem Start wären sie immer an derselben Stelle (als Internal, oder?)...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

CoolTux

Zitat von: Beta-User am 20 Februar 2019, 12:36:01
;D
Schon klar, dass das eine Menge Arbeit ist, aber auf der anderen Seite (für den Fall, dass das nicht schon länger so ist, habe den Code schon eine ganze Zeit nicht mehr durchgesehen ;) ): warum nicht die Logik in Schritt 1 so umbauen, dass nicht bei jedem Befehl noch erst die Infos ausgelesen werden, sondern das _einmal_ nach INITIALIZED machen (und ggf. nur updaten, wenn was geändert wurde). Dann wäre es fast egal, woher die Daten kommen, nach dem Start wären sie immer an derselben Stelle (als Internal, oder?)...

Das ist korrekt. Da dies aber mein erstes Modul ist welches so Systemweit Daten sammelt und über mehrere Schleifen hintereinander FHEM Funktionen dafür auf ruft, wollte ich erstmal sehen wie sehr es das System belastet. Scheint aber Robuster zu sein wie ich befürchtet hatte  :D
Ich werde mir mal für die Zukunft etwas überlegen. Aber nicht mehr dieses Jahr. Jetzt sorgen wir erstmal dafür das es vernünftig läuft. Und zwar mit allen derzeitigen Möglichkeiten  :)
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

Beta-User

Laß dir Zeit! Funktioniert ja (im Wesentlichen) alles, ist "nur" Schönheit und useability... Wind wäre mir auch wichtiger *grins*.
Zitat von: CoolTux am 20 Februar 2019, 12:40:41
Aber nicht mehr dieses Jahr.
*grins* das hat doch erst angefangen... Und wer hätte geglaubt, dass das so schnell einen derartigen Funktionsumfang annimmt und so großen Anklang findet?!?
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

CoolTux

Stimmt. Wind habe ich noch gar nicht auf dem Schirm. Muss gleich mal schauen ob ich da einen Issues Eintrag für habe.
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net