Betatester für neues Modul AutoShuttersControl gesucht!

[CoolTux]

0.1.73 ist am Start .

Das neu Aufbauen des Notifydev hat gut funktioniert, die Leichen sind jetzt weg.

Das neue get für die überwachten Devices ist auch nett.
Dazu hätte ich einen Wunsch (mal wieder eher useability-getrieben bzw. dem Gedanken, das möglichst übersichtlich zu haben, also nicht wirklich eilig oder wichtig): Die Sortierung sollte m.E. nach Shutter-Device sein, im Moment geht das bunt durcheinander (k.A., nach welcher Logik). Also alle zu einem bestimmten Rollladen gehörende Angaben zu Roommate und WindowContact nacheinander, dann erst der nächste Rollladen; das ganze am besten als nächste Sortierebene nach Räumen.

Kann ich mir gerne anschauen. Ist ja nur eine Sortierreinfolge. Weiß nur nicht in wie fern FHEMWEB da auch was macht. Müssen wir mal aus testen.
Aktuell schreibe ich das Modul komplett für OOP (Objektorientierte Programmierung in Perl) um. Ist natürlich bisschen Perl  für die Säue mit nur einer Modul/Klassen Datei, aber mir geht es um das lernen.


Grüße

[Beta-User]

Der Ansatz gefällt mir gut, eine Art "Muster"-Modul daraus zu machen, auch wenn es vermutlich "overdone" ist. Aber wen "copy/paste"-Hobbyisten wie ich schon Code irgendwo her klauen, ist es besser, es wird aus einer mustergültigen Quelle gemacht .

Wenn du magst (du warst ja auf der Suche nach einem guten 2-stufigen): Schau doch mal bei MySensors vorbei. Das war mal kurz und knackig (und ist es im wesentlichen noch). Vielleicht kannst du uns ja Tips dazu geben... (Was man besser dokumentierne könnte ist das etwas unübersichtliche Durcheinander, was sich aus Abfrage von irgendwas und verzögerter Reaktion ergibt).

Wäre gut für den Fall, dass ich irgendwann mal zigbee@serial anfangen sollte .

[C0mmanda]

Neue Version ist nun im Git. Ich denke damit gewinnt unser Modul mehr und mehr an Stabilität. Als nächstes können wir dann neue Funktionen hinzufügen.

Da hätte ich ja direkt eine Idee
Abgesehen von den bereits angesprochenen Zwischenfahrten habe ich einen weiteren "Wunsch":

Ich hatte bisher immer ein DOIF/notify o.ä. welches kritische Fenster im EG "überwacht" und die Rolläden schliesst wenn
ein Fenster geöffnet ist, aber niemand mehr zuhause ist. (Also vergessen hat das Fenster zu schliessen).
Der Rolladen wird dann aus Sicherheitsgründen herunter gefahren.
Kommt nun ein Roommate nach Hause wird der Rolladen wieder in die vorherige Position zurück gefahren, es sei denn
das Nachtschliessen wäre bereits gewesen, dann bleibt der Rolladen natürlich auch geschlossen.

Wäre natürlich optimal wenn solch eine Funktion implementiert werden könnte. Roommates + Fensterkontakte werden ohnehin bereits abgefragt.

Komme darauf weil ich dies jetzt wieder implementieren wollte aber kein passendes Reading habe (Clunis myUtils-Code hatte z.B. "Nachtschliessen (0|1)" welches ich abfragen konnte).
Müsste wohl die Zeitstempel abfragen und vergleichen um heraus zu finden ob das Nachtschliessen schon gewesen wäre, wäre der Rolladen offen gewesen..

Nur eine Idee. 
Für die jetzt schon großartige Arbeit vielen vielen Dank!

gruß
CmdA

[CoolTux]

Da hätte ich ja direkt eine Idee
Abgesehen von den bereits angesprochenen Zwischenfahrten habe ich einen weiteren "Wunsch":

Ich hatte bisher immer ein DOIF/notify o.ä. welches kritische Fenster im EG "überwacht" und die Rolläden schliesst wenn
ein Fenster geöffnet ist, aber niemand mehr zuhause ist. (Also vergessen hat das Fenster zu schliessen).
Der Rolladen wird dann aus Sicherheitsgründen herunter gefahren.
Kommt nun ein Roommate nach Hause wird der Rolladen wieder in die vorherige Position zurück gefahren, es sei denn
das Nachtschliessen wäre bereits gewesen, dann bleibt der Rolladen natürlich auch geschlossen.

Wäre natürlich optimal wenn solch eine Funktion implementiert werden könnte. Roommates + Fensterkontakte werden ohnehin bereits abgefragt.

Komme darauf weil ich dies jetzt wieder implementieren wollte aber kein passendes Reading habe (Clunis myUtils-Code hatte z.B. "Nachtschliessen (0|1)" welches ich abfragen konnte).
Müsste wohl die Zeitstempel abfragen und vergleichen um heraus zu finden ob das Nachtschliessen schon gewesen wäre, wäre der Rolladen offen gewesen..

Nur eine Idee. 
Für die jetzt schon großartige Arbeit vielen vielen Dank!

gruß
CmdA

Von einem Smart Home Kollegen habe ich auch geade eine super tolle Logikidee bekommenIch finde das ist eine super tolle Idee.

Self Defence, wenn beim Verlassen des letzten Bewohners noch ein Fenster gekippt ist, wird der Rolladen an diesem Fenster automatisch geschlossen.

Kommt also

[FunkOdyssey]

Aber erst die Helligkeitssteuerung

[CoolTux]

Der Ansatz gefällt mir gut, eine Art "Muster"-Modul daraus zu machen, auch wenn es vermutlich "overdone" ist. Aber wen "copy/paste"-Hobbyisten wie ich schon Code irgendwo her klauen, ist es besser, es wird aus einer mustergültigen Quelle gemacht .

Wenn du magst (du warst ja auf der Suche nach einem guten 2-stufigen): Schau doch mal bei MySensors vorbei. Das war mal kurz und knackig (und ist es im wesentlichen noch). Vielleicht kannst du uns ja Tips dazu geben... (Was man besser dokumentierne könnte ist das etwas unübersichtliche Durcheinander, was sich aus Abfrage von irgendwas und verzögerter Reaktion ergibt).

Wäre gut für den Fall, dass ich irgendwann mal zigbee@serial anfangen sollte .

Kann mich gerade nicht erinnern auf der Suche nach einem 2-stufigen Modul gewesen zu sein
Habe ja selber schon 2-3 gemacht. Da kann ich dann im Winter wenn ich bisschen das Developer Wiki erweitere ein paar Auszüge als Beispiel nehmen 
Wenn Du auch gerne ein Modul erstellen willst kannst Du Dir auch einen Mentor suchen. Denke das kennst Du ja bestimmt, wurde schon paar mal im Forum erwähnt. 

Ein gutes Beispiel kann das Modul sein, zu mindest was die Verwendung von package an geht. OOP muss aber nicht sein.


Grüße

[Beta-User]

Wenn Du auch gerne ein Modul erstellen willst kannst Du Dir auch einen Mentor suchen. Denke das kennst Du ja bestimmt, wurde schon paar mal im Forum erwähnt. 

Ist schon klar, ich will aber erst mal niemanden mit meinen rudimentären Perl-Kenntnissen behelligen, zumal ich auch erst mal noch HW (und viel ruhige Zeit) dafür benötige (ist im Zulauf). Welches "2-stufige" würdest du denn als mustergültig einschätzen? (Dass du da schon mehrere gemacht hast, ist mir bekannt, aber manchmal ist es so, dass man im Lauf der Zeit Dinge dazulernt und manches dann ganz anders machen würde, würde man nochmal "grüne Wiese" haben... Hätte mich im wesentlichen an MySensors orientiert, da ich das schon etwas in der Funktionsweise einschätzen kann und ansonsten vorrangig bei CUL+CUL_HM bedient, da es vermutlich viele Parallelen zwischen HM-BidCos und zigbee gibt).

Ich komme aber ggf. auf den Hinweis zurück, oder war das ein konkretes Angebot?

[Karflyer]

Habe die neue Version eingespielt. Das Verhalten bzgl. Comfort-Stellung und threestate-Fenstergriffen ist jetzt wie erwartet.
Das Modul ist wirklich klasse! Weiter so.

Stefan

[CoolTux]

Aber erst die Helligkeitssteuerung

Was genau stellst Du Dir darunter vor?

[CoolTux]

Ich habe eine neue Version nun fertig. Komplett umgestellt auf OOP und mit selfDevense Mode
Ich teste die Tage noch und dann stelle ich sie online.


Grüße

[FunkOdyssey]

Was genau stellst Du Dir darunter vor?

Sind dafür nicht die Brightness-Attribute gedacht?

Ich will keinen Astro-Modus, weil die Helligkeitssensoren rund um mein Haus viel genauer sind.
Von diesem Werte lege ich einen Durchschnitt an und bei Unterschreitung des Wertes x fahren die Jalousien halt runter.

(Ehrlich gesagt fahren die Jalousien bei mir einmal auf 50% und dann auf 0% runter. Das hier bereits erwähnt Zweistufenverfahren, welches viel später kommen soll. )

[Cluni]

...(und viel ruhige Zeit) dafür benötige (ist im Zulauf). ...

Geilomat - wo bekommst du die ruhige Zeit denn her? Suche schon lange, aber habe bis jetzt noch keinen Händler gefunden. Würde da auch jede Menge von bestellen und abnehmen! 

[CoolTux]

Sind dafür nicht die Brightness-Attribute gedacht?

Ich will keinen Astro-Modus, weil die Helligkeitssensoren rund um mein Haus viel genauer sind.
Von diesem Werte lege ich einen Durchschnitt an und bei Unterschreitung des Wertes x fahren die Jalousien halt runter.

(Ehrlich gesagt fahren die Jalousien bei mir einmal auf 50% und dann auf 0% runter. Das hier bereits erwähnt Zweistufenverfahren, welches viel später kommen soll. )

Interessant. Die Helligkeitssensoren sind eigentlich für die Abschattung gedacht. Aber ich denke mal man kann Prinzip auch assoziieren.

[FunkOdyssey]

Ich habe auch nie verstanden, wieso ich zweigleisig fahren sollte.
- Astro,
- fixe Uhrzeiten,
- und die Umgebungshelligkeit.

Fixe Uhrzeiten in Kombination mit der Umgebungshelligkeit oder mit den Astro-Zeiten macht ja noch Sinn. Aber Astro mit Helligkeit zu kombinieren halt nicht.

Die Astro-Zeiten (egal ob Modul ASTRO oder Twilight) sind mir halt nicht genau genug. Und wenn ich die Sensoren sowieso schon für die Abschattung benötige, so kann ich dieses auch zum Runterfahren nutzen.

Twilight habe ich nur zusätzlich in meinen DOIFs, um den Zeitrahmen grob vorzubelegen. Ich will halt nicht, dass die Jalousien herunterfahren wenn es mal tagsüber zu dunkel wird. Aber diese Extreme gab es nur ein bis zweimal im Jahr.

[Beta-User]

Auch wenn ich sehr positiv angetan bin von den Astro-Ergebnissen: Könnte man die Logik für eine helligkeitsbasierte Variante nicht ähnlich machen wie mit Astro?
Also frühestens, wenn die Mindestzeit durch ist und der Helligkeitswert bereits paßt, dann Reaktion auf Helligkeit, es sei denn, die späteste Zeit würde erreicht (dann Zwangsfahrt).

Vermutlich sollte man zwei Schwellenwerte definieren: einen Mindestwert für das Öffnen und einen für das Schließen (muß ja nicht zwangsläufig gleich sein).