Betatester für neues Modul AutoShuttersControl gesucht!

[elle]

Hallo,

super Sache, das Ganze endlich in ein Modul zu verpacken.

Leider kann ich lt. der Anleitung im Einleitungspost nicht testen, da ich bereits das Script einsetze. Ich denke aber darueber nach, ein komplettes Backup der Installation zu ziehen, das Script rauszuschmeissen und hier mitzutesten, aber leider habe ich im Moment nicht soviel Zeit, mich mit FHEM zu beschaeftigen.

Eine Frage/Anregung haette ich aber bzgl. des AutoShutterControl Attributs: Waere es u.U. nicht sinnvoller statt der Zahlenwerte Strings zu benutzen:
0 -> "Nein" oder "Aus"
1 -> "Homematic"
2 -> "Inverse" oder "Rollo"

M.E. ist dies fuer den Anwender einfacher als sich merken zu muessen, was die Zahlenwerte bedeuten und sollte performancetechnisch keinen oder kaum Impact haben.

Ein anderer Gedanke bzgl. des Setzens der Timer, den ich auch schon beim Script hatte (wobei ich allerdings nicht weiss, wie das hier im Modul implementiert ist), ist der, ob es nicht sinnvoller - und moeglich - ist, nicht die Timer zu einer festen Zeit fuer alles zu setzen, sondern zusaetzlich bei einer Aenderung des Attributs eines Rolladens die Timer fuer diesen auf Basis der neuen Attributwerte gleich neu zu setzen.
Beispiel:
- Im Laufe des Tages stelle ich fest, dass der Runterfahrentimer fuer den Rollladen im Arbeitszimmer unguenstig liegt, weil ich den Rollladen als Zugang zur Terrasse laenger offen halten moechte ohne den Partymodus fuer diesen Raum einzuschalten. Also aendere ich die Zeit und wundere mich (da ich vergessen habe den at manuell zu starten), dass der Rollladen zu frueh runterfaehrt ...

Nur so ein paar Gedanken ...

Ansonsten weiter so!

Gruss

/elle

[CoolTux]

Vielen Dank für Deine Anregungen.

Das mit dem AutoShutterControl Attribut ist mit Absicht in Zahlen gemacht, da ich diese Zahlen eins zu eins für ein Array nehme. Das erspart viel umschreiben innerhalb des Codes.
Nun könnte man zur Not noch über das umschreiben nachdenken, aber Du kannst nicht komplett fest machen das 1 Homematic ist und 2 der Inverse oder Rollo. Es gibt so viele verschiedene Möglichkeiten. Dann lieber an Hand von Eigenschaften fest machen und es einfach 1 und 2 nennen, denke ich.


Das setzen der Timer wäre im Prinzip automatisch möglich. Müsste ich mir anschauen. Frage ist nur ab wann Du das machen willst? Welches Attribut soll den Event liefern?
Alle wäre ungünstig dann haben wir ein Feuerwerk und was ist mit der Änderung der Attribute im Moduldevice für Sunset Sunrise? Es gibt einfach zu viele Möglichkeiten.
Aber ich werde gerne einmal darüber nachdenken wie man es machen könnte, der Aufwand es später zu implementieren ist minimal. Siehe meinen nächsten Post.


Grüße

[CoolTux]

Ich habe soeben erfolgreich das Value time der Attribute AutoShuttersControl_Down und AutoShuttersControl_Up implementiert. Sind diese Attribute gesetzt werden automatisch die Zeiten aus den Attributen AutoShuttersControl_Time_Down_Early und AutoShuttersControl_Time_Up_Early als Fahrzeiten genommen.

Version kommt aber erst morgen.

[Beta-User]

Welches Attribut soll den Event liefern?

Wie wäre es mit:

Code Auswählen Erweitern

AutoShuttersControl_Time_.*

Und ob es ein Feuerwerk gibt?
Aber die Vorgehensweise, Attribute zu ändern, wenn was nicht längerfristig wirksam sein soll, finde ich grundsätzlich nicht so toll, das rote ? sollte nach meinem Verständnis/meiner Handhabung eigentlich wirklich eine Warnung darstellen, dass potentiell gewollte Änderungen verlorengehen.

Eine Idee für die Lösung der aufgezeigten Aufgabe habe ich leider nicht wirklich, meine Gedanken gingen in Richtung eines "set <ASC-Device> blockUntil <devspec - kann auch ein room-Filter sein> <HH:MM>"; damit könnte man laufende Timer einfach auf diesen Zeitpunkt verschieben bzw. löschen, wenn zwischenzeitlich ein weiterer Befehl anstünde (und dann stattdessen diesen in den Timer setzen).

[CoolTux]

Wie wäre es mit:

Code Auswählen Erweitern

AutoShuttersControl_Time_.*

Und ob es ein Feuerwerk gibt?
Aber die Vorgehensweise, Attribute zu ändern, wenn was nicht längerfristig wirksam sein soll, finde ich grundsätzlich nicht so toll, das rote ? sollte nach meinem Verständnis/meiner Handhabung eigentlich wirklich eine Warnung darstellen, dass potentiell gewollte Änderungen verlorengehen.

Eine Idee für die Lösung der aufgezeigten Aufgabe habe ich leider nicht wirklich, meine Gedanken gingen in Richtung eines "set <ASC-Device> blockUntil <devspec - kann auch ein room-Filter sein> <HH:MM>"; damit könnte man laufende Timer einfach auf diesen Zeitpunkt verschieben bzw. löschen, wenn zwischenzeitlich ein weiterer Befehl anstünde (und dann stattdessen diesen in den Timer setzen).

Was ist mit AutoShuttersControl_Up oder AutoShuttersControl_Down, also wenn ich von astro auf time gehe? Ist nicht einfach.

Das mit dem Set finde ich ganz praktisch. Muss mal drüber nach denken.

[Beta-User]

Was ist mit AutoShuttersControl_Up oder AutoShuttersControl_Down, also wenn ich von astro auf time gehe? Ist nicht einfach.

Nee, ist es nicht. Diese Attribute hatte ich gar nicht auf dem Schirm, und für ..._Mode_Up/Down gilt dasselbe...

Meine Meinung dazu ist aber, dass solche Änderungen aus Usersicht mit der Erwartung verbunden werden, dass sie sofort wirksam werden. Ergo muß man sie, jedenfalls sofern nicht nur Ziel-Positionen drin stehen, die zum Ausführungszeitpunkt genutzt werden (?) auch alle Attribute überwachen.

Spontaner Gedanke: Das ganze bei den Devices nur als Readings hinterlegen, und Setzen der Werte dann über das zentrale Device? Das hätte allerdings den erheblichen Nachteil, dass ohne statefile alles weg wäre => eher auch nicht optimal .

[CoolTux]

Nee, ist es nicht. Diese Attribute hatte ich gar nicht auf dem Schirm, und für ..._Mode_Up/Down gilt dasselbe...

Meine Meinung dazu ist aber, dass solche Änderungen aus Usersicht mit der Erwartung verbunden werden, dass sie sofort wirksam werden. Ergo muß man sie, jedenfalls sofern nicht nur Ziel-Positionen drin stehen, die zum Ausführungszeitpunkt genutzt werden (?) auch alle Attribute überwachen.

Spontaner Gedanke: Das ganze bei den Devices nur als Readings hinterlegen, und Setzen der Werte dann über das zentrale Device? Das hätte allerdings den erheblichen Nachteil, dass ohne statefile alles weg wäre => eher auch nicht optimal .

Und ich will nicht in fremde Devices mehr wie nötig reinschreiben. Das über wachen der Rollädendevices habe ich auf den Schirm, es gibt sogar schon eine Funktion um das ein zu richten, aktuell deaktiviert.
Aber wenn überhaupt dann werde ich nur einige wenige Attribute triggern. Muss selber erstmal schauen.

[elle]

Das mit dem AutoShutterControl Attribut ist mit Absicht in Zahlen gemacht, da ich diese Zahlen eins zu eins für ein Array nehme. Das erspart viel umschreiben innerhalb des Codes.
Nun könnte man zur Not noch über das umschreiben nachdenken, aber Du kannst nicht komplett fest machen das 1 Homematic ist und 2 der Inverse oder Rollo. Es gibt so viele verschiedene Möglichkeiten. Dann lieber an Hand von Eigenschaften fest machen und es einfach 1 und 2 nennen, denke ich.

Der Gedanke war, damit die Positionierungslogik zu beschreiben, vllt. eher "Homematic Style" fuer 100% => offen und 0% geschlossen bzw. Inverse Style fuer die Variante wie es Rollo macht mit 0% offen und 100% geschlossen.

Eventuell koennte aber ein Hash mit numerischen Keys benutzt werden, aber um dies zu beurteilen, kenne ich weder die Interna des Moduls noch jene von FHEM zur Genuege ...

Code Auswählen Erweitern


my %hash = ( 0 => 'Aus', 1 => 'Homematic Style', 2 => 'Reverse Style' );
my %rev_hash = reverse %hash;

ergibt, ueber Data::Dumper ausgegeben:

Code Auswählen Erweitern


$VAR1 = {
          '2' => 'Foo',
          '0' => 'Nein',
          '1' => 'Homematic style'
        };

$VAR1 = {
          'Homematic style' => '1',
          'Foo' => '2',
          'Nein' => '0'
        };

sodass man in beiden Richtungen auf alles zugreifen kann, aber nur einmal definieren muss, wie als wenn man ein einfaches Array definiert. Das Array kann man zur Not immer noch aus den Keys des Hashes abgreifen ...

Das setzen der Timer wäre im Prinzip automatisch möglich. Müsste ich mir anschauen. Frage ist nur ab wann Du das machen willst? Welches Attribut soll den Event liefern?
Alle wäre ungünstig dann haben wir ein Feuerwerk und was ist mit der Änderung der Attribute im Moduldevice für Sunset Sunrise? Es gibt einfach zu viele Möglichkeiten.
Aber ich werde gerne einmal darüber nachdenken wie man es machen könnte, der Aufwand es später zu implementieren ist minimal. Siehe meinen nächsten Post.

Die Frage ist tatsaechlich komplex - da stimme ich Dir zu ...

Und Beta-User hat bereits beschrieben, wieso ich diesen Gedanken hatte, da es mir - auch wenn ich mich schon laenger mit FHEM beschaeftige (nur so gut wie gar nicht hier aktiv war) - auch schon ein paar Mal passiert ist, dass ich mich gewundert hatte, warum die Aenderung nicht aktiv war und dann fiel mir ein, dass ich den at->exec_now nicht angestossen hatte  ...

Gruss

[Beta-User]

Der Gedanke war, damit die Positionierungslogik zu beschreiben, vllt. eher "Homematic Style" fuer 100% => offen und 0% geschlossen bzw. Inverse Style fuer die Variante wie es Rollo macht mit 0% offen und 100% geschlossen.

Da sind wir m.E. im Prinzip ja wieder alle beieinander, oder?

Denn im Prinzip dürfte es nur zwei Grundtypen geben, nämlich entweder "Geschlossen" entspricht "0%" oder eben "100%".
Mehr Varianten sind denkbar bei den Fahrbefehlen (level, pct, percent, direkte Zahleneingabe [0-100] oder [0-1],...). Aber CoolTux hat dahingehend recht, dass man irgendwann aufhören sollte, jeden Fall unmittelbar abfangen zu wollen. Weit verbreitete Typen sollten einfach abgedeckt werden können, aber wer exotische Hardware hat, kann die volle Flexibilität nutzen und seinen eigenen Kram da händisch einpflegen.



Wie bereits geschrieben, dürfte aber die Info, wo oben und unten ist, für die Steuerung des Rolladens insgesamt sehr wichtig sein. In dem Zusammenhang zwei Fragen:

- Im Schlafzimmer sind zwei Rolläden, die werden bisher aber fast nie ganz aufgemacht, sondern z.B. meistens nur zu 20-30%. Wenn ich diese beiden Werte jetzt als "Open"-Werte angebe, gehe ich davon aus, dass das nur die auf-Befehle aus der Automatik betrifft und das System nicht insgesamt aus dem Tritt kommt, nur weil einer der Rolläden versehentlich mal manuell auf einen Wert außerhalb "Closed" und "Open" steht. Das könnte nämlich insbesondere im Rahmen der Beschattung vorkommen - da wäre z.B. 40 für den einen Rolladen ein guter Wert.

- Beschattung: Jemand stellt den Rolladen manuell auf einen Wert, der unterhalb der eigentlichen Beschattung liegt (also nachts geschlossen=0, dann Automatik-auf auf 100, manuell auf 20, Beschattung würde 40 ergeben). Wird der Rolladen gefahren?
Wunsch wäre: nein, weil ein user zwischenzeitlich anders wollte als die Automatik.
Anders wäre das, wenn der user auf 40 gestellt hätte, aber die Beschattung auf 20 erfolgen sollte. Nach einer Karenzfrist (z.B. von einer Stunde seit der letzten Betätigung) wäre es im zweiten Fall ok, wenn die Automatik greift.


Überhaupt: manuelle Betätigung.
Da ich noch keine Automatik für die Roommates hatte, gingen die Rolladen heute morgen ziemlich früh hoch. Das wollte ich mit einem Tastendruck abbrechen, was allerdings nur kurzfristig Wirkung zeigte. Nach einigen Sekunden fuhr der Rolladen wieder an...
Absicht oder nicht?
Wunsch wäre, dass Usereingriffe während einer automatischen Fahrt Prio haben.

Gruß, Beta-User

[CoolTux]

Der Rolläden ist bestimmt bei Sonnenaufgang gefahren nehme ich an. Da aktuell der Sonnenaufgang immer später wird, wird es wohl so gewesen sein das nach dem ablaufen des timers der rolkaden fuhr, dann würde der nächste Sonnenaufgang berechnet, dieser war paar Minuten später wie der gerade eben und deswegen noch am selben Tag. Genau nach dem du Stop gemacht hast.

Hätte noch keine Idee zum abfangen.

[Beta-User]

Jup, astro/CIVIL, ob jetzt innerhalb der gesetzten Grenzen.

Unschöne Schleife eigentlich. Auf die Schnelle mögliche Ansätze, ohne den Modulcode analysiert zu habeb: entweder beim Erstellen des Timers eine andere sunrise-Variante nehmen, oder das Ergebnis darauf prüfen, ob es zu nah an jetzt liegt (dann +24h) oder die Ausführung nur des Fahrbefehls unterlassen, wenn der Rolladen erst vor ein paar Sekunden gefahren wurde (ReadingsAge auf "level" oder "pct")?

[CoolTux]

Jup, astro/CIVIL, ob jetzt innerhalb der gesetzten Grenzen.

Unschöne Schleife eigentlich. Auf die Schnelle mögliche Ansätze, ohne den Modulcode analysiert zu habeb: entweder beim Erstellen des Timers eine andere sunrise-Variante nehmen, oder das Ergebnis darauf prüfen, ob es zu nah an jetzt liegt (dann +24h) oder die Ausführung nur des Fahrbefehls unterlassen, wenn der Rolladen erst vor ein paar Sekunden gefahren wurde (ReadingsAge auf "level" oder "pct")?

Ich schaue es mir die Tage mal genauer an. Heute Abend muss ich noch was am Lüften Modus umbauen. Habe da glaube einen Fehler gefunden.

[CoolTux]

Guten Abend,

Ich habe soeben Version 0.1.9 integriert. Mit dabei ist nun Ausperrschutz und Frostschutz.
Bitte achtet wie immer auf den ersten Post.


Eine Warnung habe ich noch. Ich musste das Value eines Attributes ändern. Dies hat zur Folge das es zur Inkonsistenz kommt und damit zu Problemen. Je nach Anzahl und Konfiguration der Rolläden gibt es zwei Wege.
Vorbereitung vor dem Update
- Entweder das Moduldevice löschen und damit eine saubere Deinstallation
- oder jeden Rolladen anfassen und im Attribut userattr den Eintrag für AutoShuttersControl_Antifreeze sowie das Attribut AutoShuttersControl_Antifreeze an sich entfernen.
Danach speichern und dann die neue Modulversion installieren. Dann ist ein neustart Pflicht



Grüße

[CoolTux]

Guten Morgen,

Wie ich finde sind wir schon sehr weit gekommen. Heute schaue ich mir die Probleme mit dem zweimal ausführen von Sunset und Sunrise am selben Tag wenn der neuerrechnete Zeitpunkt nach dem aktuellen am selben Tag liegt.
Außerdem fange ich im Modul mit der Dokumentation an. Hier nehme ich gerne auch Patches entgegen. Ich hasse Dokumentation 

Ansonsten freuen wir uns über jeden mutigen Tester und Eure Berichte und Anregungen.

[Beta-User]

Moin zusammen,

bin auch schwer beeindruckt, wie schnell die Entwicklung vorangeht und v.a., wie positiv Anregungen aufgenommen werden!
Einfach super .

Der Wechsel zur neuen Version war - anders als erwartet - keine größere Sache, geht recht einfach mit dem FILTER, nachdem man FHEM samt Modul aktualisiert hat (kam von 0.0.5, die Rolläden wurden also noch nicht über das neue Attribut erkannt, sonst muss man evtl. auch anders vorgehen):

Code Auswählen Erweitern

deleteattr TYPE=CUL_HM:FILTER=subType=blindActuator AutoShuttersControl_Antifreeze
attr TYPE=CUL_HM:FILTER=subType=blindActuator AutoShuttersControl 2
und dann das Attribut bei der Leinwand wieder gelöscht.

Für die Default-Werte bei den Timern: Sollte man die Grenzen nicht etwas "nachbarfreundlicher" setzen? Kann ja jeder später passend ändern.


Zu dem Zusammenfassen mehrerer Presence-Devices als Hilfsmittel noch eine RAW-Definition für eine Structure:

Code Auswählen Erweitern

define rr_Parents structure eltern rr_Mann rr_Frau
attr rr_Parents clientstate_behavior relative
attr rr_Parents clientstate_priority asleep gotosleep awoken home absent
attr rr_Parents group Persons
attr rr_Parents icon user_unknown
attr rr_Parents room Steuerung
attr rr_Parents userReadings lastState:(home|awoken|asleep|gotosleep|absent) { OldValue($name) }und als Muster ein Weekdaytimer für meinen "Mann"-Dummy, damit der sich erst mal "bewegt". Gibt's in ähnlicher Form auch für weitere Personen

Code Auswählen Erweitern

define rr_Mann_Presence_Timer WeekdayTimer rr_Mann !$we|06:30|awoken !$we|06:40|home $we|08:00|awoken $we|08:30|home !$we|07:30|absent !$we|19:00|home 01234|21:45|gotosleep 01234|22:00|asleep 56|22:40|gotosleep 56|23:00|asleep
attr rr_Mann_Presence_Timer commandTemplate set $NAME  $EVENT
attr rr_Mann_Presence_Timer disable 0
attr rr_Mann_Presence_Timer group Persons
attr rr_Mann_Presence_Timer icon status_automatic
attr rr_Mann_Presence_Timer room Steuerung


Probleme habe ich noch mit dem Versuch einer handy-basierten Anwesenheitserkennung, das ist aber ein gesondertes Thema und hier eigentlich OT. Für den Fall, dass aber jemand zum Testen die "makeFamily" nutzt und das ähnlich (u.a. mit einer Fritzbox) abbilden will, hier schon mal ein Zwischenstand:

Die setlist wird bei den Personen-Dummys erweitert:

Code Auswählen Erweitern

attr rr_Mann readingList state smartphone smartphone_MAC
attr rr_Mann setList state:home,gotosleep,awoken,absent,asleep smartphone:absent,present smartphone_MAC

mit "set rr_Mann smartphone_MAC <mac_....:>" (kompletter Event-Teil der Fritzbox einschließlich Doppelpunkt) wird das Reading gefüllt.
Dann wird das Reading "smartphone" per notify mit "absent" bzw. "present" gefüllt:

Code Auswählen Erweitern

define n_MAC_Check notify Fritzbox:mac_.*:.* {if ($EVTPART1 eq "inactive") {\
    fhem("set TYPE=dummy:FILTER=smartphone_MAC=$EVTPART0 smartphone absent");;\
  }\
  else {\
    fhem("set TYPE=dummy:FILTER=smartphone_MAC=$EVTPART0 smartphone present");;\
  }\
}
attr n_MAC_Check group Persons

Fehlt noch eine einschränkende event-on-change-reading-Definition und ein notify samt sinnvoller Logik, um aus der Anwesenheit des Smartphones passende Schlüsse zu ziehen (eigentlich sagt das - da ein DD-WRT-Router das "bessere WLAN" bereitstellt - im Moment nicht mehr wie: ziemlich sicher zuhause... Das will ich dann erst mal mit currValue aus dem jeweiligen Weekdaytimer verheiraten).


Was Doku angeht, schau' ich bei Gelegenheit mal, ob ich dazu komme, was sinnvolles beizutragen.

Gerne kann ich den "Begleitkram" mit den ReadingsGroups, der Musterfamilie etc. (wenn's mal funktioniert) dann auch ins Wiki packen, wenn das für andere von Interesse sein sollte?



Der Vollständigkeit halber zu guter Letzt noch eine Liste der offene Punkte/Wünsche:
- abgearbeitete Timer nicht mehr am selben Tag ausführen
- Timer-Attribute im HH:MM-Format möglich (? kann sein, dass es schon jetzt funktioniert, statt HH:MM:SS)
- Erster Thread:
-- chmod 644 (Erster Thread) ist ausreichend
-- Thread-Titel
-- (Meine versehentlich) inkonsistente Namensgebung: "defmod rr_Mann dummy" statt "defmod rr_Maria dummy"
Großes Danke, Grüße und: Macht euch keinen Stress!

Beta-User

EDIT: Zeiten am WeekdayTimer verbessert