[73_AutoShuttersControl.pm] - Version 0.8.x DEVEL, !!!FEATURE FREEZE!!!

Begonnen von CoolTux, 17 September 2019, 13:46:12

Vorheriges Thema - Nächstes Thema

FunkOdyssey

Schon klar.
Aber was ist wenn zuerst der Late-Zeitpunkt erreicht wird?
Dann fehlt die Privacy-Fahrt.

ASC müsste x min vor Late auch in Privacy_Pos fahren.

CoolTux

Ja das ist richtig. Dann fehlt sie.

Zitat von: FunkOdyssey am 29 Oktober 2019, 21:00:51
ASC müsste x min vor Late auch in Privacy_Pos fahren.

Das kann ich nicht umsetzen, wer diesen Anspruch hat möchte es bitte anders lösen.
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

CoolTux

Zitat von: CoolTux am 29 Oktober 2019, 21:11:45
Ja das ist richtig. Dann fehlt sie.

Das kann ich nicht umsetzen, wer diesen Anspruch hat möchte es bitte anders lösen.

Mir ist heute Morgen im Bad eventuell eine Idee zur Umsetzung gekommen. Sollte das nicht klappen bleibe ich bei meiner Aussage.


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

CoolTux

Zitat von: CoolTux am 30 Oktober 2019, 06:00:44
Mir ist heute Morgen im Bad eventuell eine Idee zur Umsetzung gekommen. Sollte das nicht klappen bleibe ich bei meiner Aussage.


Grüße

Es scheint zu funktionieren. Zumindest für Morgens habe ich es schon mal testen können. Für Abends dauert noch etwas, bei der ganzen Sache muss man sich mega konzentrieren um alles mögliche zu beachten.
Mein armer Kopf.
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

Hallo zusammen,

bin zwar bisher nicht dazu gekommen, die V 0.8 zu testen, wollte jetzt dann aber auch wieder einsteigen, falls es Aussicht auf "news" zum Thema Jalousien gibt?
Oder ist das auf V 1.0 verschoben ;D ?

Wenn V 0.8: Wie wollen wir vorgehen? Bisher gab's dazu afaik keine große Rückmeldung, aber eigentlich kann ich mir nicht vorstellen, dass ich der einzige bin, der an dem feature Interesse hat...

Was die konkrete Umsetzung angeht, war mal der Gedanke, den Drehwinkel jeweils als weitere Angabe hinter den Ziellevel zu schreiben. Aber das ist zum einen schwerer zu pflegen (die readingsGroups mögen das nicht...), und zum anderen würde die Auswertung der Attribute dadurch erschwert.

Wäre es nicht ein Ansatzpunkt, die ganze Jalousie-Geschichte in EIN Attribut zu packen, und dort dann alle Einstellungen reinzupacken? Dann könnte man entweder so machen, dass man dort neben dem Namen und set-Befehl (bei meinem ZWave-Aktor ist das ein anderes Device, und dort "dim") die Attributnamen der dazu passenden Levelangaben nimmt, oder einfach nur nummerischen Zielleveln einen festen Drehwinkel zuordnet.

Beispiele:
- Für die Verwendung der Attributnamen:
attr DEVICE ASC_Venetian_Settings {{'Name'=>'mein_Lamellengerätename'},{'setCommand'=>'dim'},{'ASC_Open_Pos'=>'99'},{'ASC_Closed_Pos'=>'0'},{'ASC_Ventilate_Pos'=>'35'}}
- Für die Verwendung der nummerischen Werte:
attr DEVICE ASC_Venetian_Settings {{'Name'=>'mein_Lamellengerätename'},{'setCommand'=>'dim'},{'99'=>'99'},{'0'=>'0'},{'30'=>'35'}}


Vermute, die zweite Variante ist viel einfacher umzusetzen, denn von den Fahrbefehlen her müßte man dann nur "setDriveCmd" so erweitern, dass nachgesehen wird, ob es einen passenden Lamellen-Hash gibt und den dann zusätzlich absetzt. Zumindest bei den ZWave-Geräten ist es auch egal, wann der Lamellenbefehl abgesetzt wird, das darf dort direkt mit (oder auch schon vor) dem normalen Fahrbefehl gemacht werden.

Sonst müßte man "setDriveCmd" (und dessen Aufrufe...) so aufbohren, dass das erkennen kann, welcher Fahrbefehl gesendet wurde. Auch das ist vermutlich ein überschaubarer Aufwand, die Suche listet 28 Vorkommen des Textes, da sind aber log-Funktionen dabei.

Da der Vorschlag hier sehr auf eine bestimmte Gerätetype zugeschnitten ist: wäre es sinnvoll, dazu nochmal einen separaten Thread aufzumachen und um Rückmeldung von "Betroffenen" zu bitten? Macht aber nur Sinn, wenn das Thema noch einigermaßen zeitnah auf der Agenda steht?
Ansonsten könnten wir auch mit dem nummerischen Vorschlag mal starten; eine spätere optionale Verzögerung wäre vermutlich recht einfach nachträglich einzubauen, und m.E. ist es auch kein Beinbruch, eine so komplexe Attributeingabe (ist eine einmalige Aktion) vornehmen zu müssen; der Kreis der Interessenten scheint ja überschaubar zu sein, und wenn man mal ein Beispiel hat, ist es auch nicht unmöglich...

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

dancatt

Hallo,

habe seit gestern auch die devel Version am laufen. Ist es korrekt dass als Version v0.6.130 im Modul steht?
Gibt es einen Ort wo alle Änderungen beschrieben sind oder muss ich mir den kompletten thread durchlesen?

Vielen Dank.

Gruß Daniel
Cubietruck: FHEM-Server 6.0

Homematic: HM-USB-CFG2, HM-CFG-LAN, HM-LC-SW1-FM, HM-LC-Sw1-Pl-DN-R1, HM-CC-RT-DN, HM-TC-IT-WM-W-EU, HM-SEC-SC-2, HM-SEC-SD, HM-PB-6-WM55

FunkOdyssey

Zitat von: Beta-User am 30 Oktober 2019, 10:02:20
Wäre es nicht ein Ansatzpunkt, die ganze Jalousie-Geschichte in EIN Attribut zu packen, und dort dann alle Einstellungen reinzupacken? Dann könnte man entweder so machen, dass man dort neben dem Namen und set-Befehl (bei meinem ZWave-Aktor ist das ein anderes Device, und dort "dim") die Attributnamen der dazu passenden Levelangaben nimmt, oder einfach nur nummerischen Zielleveln einen festen Drehwinkel zuordnet.

Wieso willst du die Attribute so kompliziert machen?
Wenn wir so weitermachen, muss man demnächst Änderungen direkt im Perl-Code durchführen, wenn man mal nur kurz die Positionsdaten ändern möchte.
Lasst doch bitte die Attribute einfacher halten. So, dass man es auch versteht und nicht jedesmal die Doku zur Hand nehmen muss.
An der einen oder anderen Stelle kann man vielleicht noch zusammenfassen, wie z.B. ASC_Roommate_Device und ASC_Roommate_Reading.
Aber bitte nicht weiter kompliziert machen.

Beta-User

Zitat von: FunkOdyssey am 30 Oktober 2019, 10:25:46
Wieso willst du die Attribute so kompliziert machen?
Vorab: Schön, dass das Thema scheinbar doch noch jemanden anderen interessiert :) .

Von kompliziert machen "wollen" kann nicht die Rede sein, ich will zuvorderst eine Lösung ;D . Dazu ist es hilfreich, wenn es für den Programmierer einfach ist... Grundsätzlich ist es erst mal fast egal, wo die Infos herkommen, die müssen halt irgendwo sein, und es muß klar sein, dass eine bestimmte Funktionsweise gewünscht ist (also auch Lamellenwinkel gesteuert werden sollen). Von daher war der erste Angang, das eben alles erst mal "leicht verdaulich" (also aus Usersicht: etwas "speziell") alles auf einmal eingeben zu lassen.
Wenn es sinnvoll/erforderlich ist, könnte man das später immer noch auf mehrere Attribute verteilen, aber offen gesagt: sooo schwierig finde ich den Vorschlag jetzt auch wieder nicht, wenn man ein 2-3 Referenzbeispiele irgendwo erklärt.

Es geht übrigens auch nicht mehr darum, weitere Attribute zusammenzufassen; der Wunsch resultierte daraus, dass man früher immer alle Attribute ausgerollt erhalten hatte; seit es die Logik mit den defaults gibt, ist da m.E. "der Fisch geputzt".
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

CoolTux

Zitat von: dancatt am 30 Oktober 2019, 10:24:24
Hallo,

habe seit gestern auch die devel Version am laufen. Ist es korrekt dass als Version v0.6.130 im Modul steht?
Gibt es einen Ort wo alle Änderungen beschrieben sind oder muss ich mir den kompletten thread durchlesen?

Vielen Dank.

Gruß Daniel

Es gibt Github wo alle Commits festgehalten sind und es gibt die Commandref. Mehr kann ich nicht anbieten.
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

CoolTux

Ich habe eben eine neue Version hoch geladen. Hier ist es nun Pflicht wenn man Privacy mit Brightness fahren will einen Wert in Sekunden mit an zugeben. Das sieht, aktuell ausschließlich für Up, so aus
1800:600
Es soll also 1800 Sekunden vor dem UpLast oder bei einem Brightness Wert von über 600 in den Morgendlichen Privacy gefahren werden.
Ich konnte bisher nur 80% der eigentlichen Logik testen.

Für Down muss ich mir noch Zeit nehmen.
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

CoolTux

Ich habe nun eine komplett getestete Version für Privacy Up mit der neuen Art der Attributsangabe getestet. Doku muss ich noch machen.
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

FunkOdyssey

Zitat von: CoolTux am 30 Oktober 2019, 12:47:43
Ich habe eben eine neue Version hoch geladen. Hier ist es nun Pflicht wenn man Privacy mit Brightness fahren will einen Wert in Sekunden mit an zugeben. Das sieht, aktuell ausschließlich für Up, so aus
1800:600
Es soll also 1800 Sekunden vor dem UpLast oder bei einem Brightness Wert von über 600 in den Morgendlichen Privacy gefahren werden.
Ich konnte bisher nur 80% der eigentlichen Logik testen.

Für Down muss ich mir noch Zeit nehmen.

Danke, dass du dir hier so viel Mühe gibst. Bei Up fehlt mir das Einsatzszenario. Ich bin mal auf die Down-Lösung gespannt. :-)
Was genau meinst du mit UpLast? Du meinst den Late-Zeitpunkt ASC_Time_Up_Late, oder?




Sollen wirklich Zeit und Brightness-Werte in einem Attribut pflegen?

Kai-Alfonso

Raspi2|nanoCul433|nanoCul868|CCU2
Energie-USBZähler|homebrew HM Devices
DBLog|DBRep|Homematic|Baumarktsteckdosen
Hue|Webcams mit DS-Station (Synology)|Bewegungsmelder|Rollladen|Schalter (IT|HM)

CoolTux

Zitat von: FunkOdyssey am 30 Oktober 2019, 15:28:11
Was genau meinst du mit UpLast? Du meinst den Late-Zeitpunkt ASC_Time_Up_Late, oder?

Ja genau den meine ich. Sorry

Zitat von: FunkOdyssey am 30 Oktober 2019, 15:28:11



Sollen wirklich Zeit und Brightness-Werte in einem Attribut pflegen?

Ja ich finde das sogar richtig gut in dem Fall. Denn für die Brightness Leute steht so fest daß sie auf jeden Fall Zeit und Brightness Wert pflegen müssen.
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

Kai-Alfonso

kurze Rückmeldung: mit v0.6.130 sind die Rollladen heute eingestellt erst in den Privacy, dann irgendwann komplett runtergefahren. Alles auf Brightness Basis...

Vielen Dank  :-*
Raspi2|nanoCul433|nanoCul868|CCU2
Energie-USBZähler|homebrew HM Devices
DBLog|DBRep|Homematic|Baumarktsteckdosen
Hue|Webcams mit DS-Station (Synology)|Bewegungsmelder|Rollladen|Schalter (IT|HM)