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

[FunkOdyssey]

Ich traue mich kaum, das nun zu sagen. Ich bin mir sicher, dass du das bereits kennst. Aber dennoch: Ist dir bekannt, dass du in den GitHub-Commits mit der Raute auf die Issues referenzieren kannst? Beispiel: Mit "Fixing bug abc #12"

[CoolTux]

Ich traue mich kaum, das nun zu sagen. Ich bin mir sicher, dass du das bereits kennst. Aber dennoch: Ist dir bekannt, dass du in den GitHub-Commits mit der Raute auf die Issues referenzieren kannst? Beispiel: Mit "Fixing bug abc #12"

Wie gut das Du Dich getraut hast. Das ist mir nicht bekannt. Um ehrlich zu sein kenne ich mich sehr wenig mit Github aus. Ich verwendete es bisher nur zur Veröffentlichung neuer Module die noch nicht ins FHEM SVN sollten.
Ich danke Dir für den Tip. Das teste ich mal bei Gelegenheit.

[CoolTux]

Ah ok dachte weil unter Issues steht , das es schon mit drin ist.

Mein Fehler, da hatte ich mich vertan. Ich werde sehen das ich die Tage da was ein baue. Idee ist schon vorhanden.

[majestro84]

Mein Fehler, da hatte ich mich vertan. Ich werde sehen das ich die Tage da was ein baue. Idee ist schon vorhanden.

Kein Stress ist ja eher ein kleiner Bug.

[FunkOdyssey]

Wie gut das Du Dich getraut hast. Das ist mir nicht bekannt. Um ehrlich zu sein kenne ich mich sehr wenig mit Github aus. Ich verwendete es bisher nur zur Veröffentlichung neuer Module die noch nicht ins FHEM SVN sollten.
Ich danke Dir für den Tip. Das teste ich mal bei Gelegenheit.

Auch wenn es nun offtopic wird, aber man kann das sogar auf die Spitze treiben. Durch Tagging, Referenzieren, Issue-Tagging usw. kann man auf GitHub sogar automatisiert Releases generieren lassen. Brauchen wir nur in der FHEM-Welt nicht.

[CoolTux]

Ich habe mal den Issues Link an gepasst. Ich werde nun aktiv die Issues unter https://github.com/fhem/AutoShuttersControl/issues pflegen.
Auch wird es da ausser der FHEM SVN Reihe Updates des Modules geben. Aber keine Sorge, mein eigenes Git wird parallel mit gepflegt. Wer also das neue FHEM Github Team nicht mag holt sich die Daten von mir.

[FunkOdyssey]

Es wird kompliziert. Jetzt haben wir drei Repositories (2xGit / 1x SVN) mit unterschiedlichen Ständen und teils sogar mehreren Branches. Die Anzahl der Issues passt auch noch nicht. Aber vermutlich bist du gerade dabei.

Du hättest dein Repo auch verschieben und das FHEM-Repo forken können.

Ich finde das aktuell nicht so glücklich.

[Beta-User]

Ein, oder vielleicht zwei Kleinigkeiten mal noch zur eigentlichen Funktionalität (Beobachtung, ohne nähere Analyse im code):

Vorab mal zu m Umfeld: Ich habe an zwei Rollläden im Schlafzimmer (CUL_HM) eine open-Position eingetragen, die deutlich unterhalb der vollständigen Öffnung liegt. Es soll damit nur "weiter als offen" gefahren werden, wenn das manuell angewiesen wird. Auch die Lüften-(und comf.open) Position liegt über der offen-Position. Meine Residents-Geräte sind nicht besonders intelligent befüllt, die dienen nur dazu, die jeweils spätesten Varianten abzudecken (und das soll auch mind. erst mal so bleiben).

1. Hat jetzt jemand vor dem ASC-Öffnen die Rollläden weiter manuell geöffnet, werden diese wieder etwas geschlossen. Das muß eigentlich nicht sein, "weiter offen" als "offen" ist in der Situation ok .

2. Morgens machen wir dann schon mal das Fenster zum lüften auf. Bis vor einigen Tagen hat das ASC auch dahingehend zur Kenntnis genommen, dass der betr. Rollladen auf "Lüften" (bzw. comfort-Position) gefahren ist, jetzt nicht mehr, vermutlich, weil keine Stunde mehr zwischen Öffnen und Sonnenaufgang liegt (die blocking-Times stehen auf default).
Ohne jetzt im Detail alles schon vollständig durchschaut zu haben, was mit den blockingTimes zusammenhängt,  mal die Frage, ob das in dieser Situation allgemein Sinn macht. Beim Schließen ja (deswegen würde ich auch ungern den Wert ändern), aber auch beim Öffnen?

Wenn es allg. Sinn macht, kann ich die beiden Punkte gerne als Issue öffnen, sollte dann halt wissen, was der beste Ort dafür ist .

[CoolTux]

Es wird kompliziert. Jetzt haben wir drei Repositories (2xGit / 1x SVN) mit unterschiedlichen Ständen und teils sogar mehreren Branches. Die Anzahl der Issues passt auch noch nicht. Aber vermutlich bist du gerade dabei.

Du hättest dein Repo auch verschieben und das FHEM-Repo forken können.

Ich finde das aktuell nicht so glücklich.

Für den Enduser soll nur noch das FHEM Git wichtig sein. Es kann dann auch in Zukunft als zusätzliches FHEM Update Repo eingebunden werden. Dazu wird es bald ein Modul geben wo dann die einzelnen Repos angezeigt werden und als Updatepath eingebunden werden kann.

[CoolTux]

Ein, oder vielleicht zwei Kleinigkeiten mal noch zur eigentlichen Funktionalität (Beobachtung, ohne nähere Analyse im code):

Vorab mal zu m Umfeld: Ich habe an zwei Rollläden im Schlafzimmer (CUL_HM) eine open-Position eingetragen, die deutlich unterhalb der vollständigen Öffnung liegt. Es soll damit nur "weiter als offen" gefahren werden, wenn das manuell angewiesen wird. Auch die Lüften-(und comf.open) Position liegt über der offen-Position. Meine Residents-Geräte sind nicht besonders intelligent befüllt, die dienen nur dazu, die jeweils spätesten Varianten abzudecken (und das soll auch mind. erst mal so bleiben).

1. Hat jetzt jemand vor dem ASC-Öffnen die Rollläden weiter manuell geöffnet, werden diese wieder etwas geschlossen. Das muß eigentlich nicht sein, "weiter offen" als "offen" ist in der Situation ok .

Klingt für mich logisch und einleuchtend. Ich werde da mal eine Abfrage einbauen.

2. Morgens machen wir dann schon mal das Fenster zum lüften auf. Bis vor einigen Tagen hat das ASC auch dahingehend zur Kenntnis genommen, dass der betr. Rollladen auf "Lüften" (bzw. comfort-Position) gefahren ist, jetzt nicht mehr, vermutlich, weil keine Stunde mehr zwischen Öffnen und Sonnenaufgang liegt (die blocking-Times stehen auf default).
Ohne jetzt im Detail alles schon vollständig durchschaut zu haben, was mit den blockingTimes zusammenhängt,  mal die Frage, ob das in dieser Situation allgemein Sinn macht. Beim Schließen ja (deswegen würde ich auch ungern den Wert ändern), aber auch beim Öffnen?

Das muß ich mir noch mal anschauen. Mach da bitte einfach mal ein Issues zu auf. Wie gesagt unter FHEM auf Github bitte.

[Kai-Alfonso]

 Hmm,

jetzt hat er auf     minimum brightness threshold fell below gewechselt, aber es ist keine Rolllade runtergefahren. Nur die im Kinderzimmer, die immer um 17:30 runterfährt.

Edit: ich hab nix gesagt:  nur im Wohnzimmer ist sie nicht runtergefahren, aber das kann auch ne andere Ursache haben

[CoolTux]

Bitte weiter beobachten. Danke Dir.

[FunkOdyssey]

Bei mir läuft es nach dem Update wieder einwandfrei.

[Kai-Alfonso]

Bei mir läuft es nach dem Update wieder einwandfrei.

Ich vermute bei mir auch. Hatte nur das Wohnzimmerfenster gesehen, aber auch gebohrt und dann gedacht, es hätte sich nix getan. Aus der Ferne sah das Küchenfenster auch nicht heruntergefahren aus (war es aber) 

[LukeSky007]

Hallo zusammen,

nach dem Update auf Version  0.4.0.5  hatte ich das Phänomen, das beim abendlichen Schießen manche Rollos nicht, bzw. verspätet geschlossen wurden.
Im ASC Device und den Rollos  stand ASC_Drive_Offset=-1  und   ASC_Drive_OffsetStart=-1

Alle ASC_Drive_Offset=0  und   ASC_Drive_OffsetStart=0  gestellt  und alles funktioniert wieder wie gewohnt.

...wurde unter https://github.com/fhem/AutoShuttersControl/issues/6  eingetragen.