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

[CoolTux]

Hallo Zusammen,

ich gebe jetzt auch mal meinen Senf dazu. Also wenn ich schlafen gehe, dann ist immer der Rollladen oben (Aber ich verwende im Moment Roommate oder Residents nicht). Ansonsten sehe ich das ähnlich wie det.. Eine manuelle Fahrt setzt die Automatik bis zum Nachtevent (oder Morgenevent) außer Kraft. Sonst greift ja der Fensterkontakt - da fährt der Rollladen ja nach dem Schließen des Fensters wieder in den ursprünglichen Zustand (wie vor dem öffnen des Fensters).

Viele Grüße und vielen Dank,
Dirk

Dann brauche ich ja keine automatische Beschattung ein zu bauen. Dann kann man das auch per Hand machen 
Ich werde das so nicht umsetzen. Dann möge man bitte einfach mit at und sunset sunrise arbeiten.
Aktuell gibt es bei Beschattung 4 Verzögerungszeiten und bei den anderen Events 3. Darunter BlockingAfterManual da kann man dann also großzügig einstellen. Muss aber wissen das dies dann auch für die Beschattung gilt.

Die Fahrten für Nacht und Tag also Sunrise und Sunset sind von allem aussen vor. Man kann also wegen meiner BlockingAfterManual auf 24 Stunden setzen (86400) und schon wird ausschlie0lich bei sunrise und sunset gefahren.

[CoolTux]

Bei Einbruchsfensterlarm fände ich es gut, wenn die Dinger runterfahren, egal wo sie vorher gestanden haben. Bei Feueralarm genau das Gegenteil. Beide Alarmformen traten zum Glück bisher nur als Testevent auf 

Sowas sollte von einem Alarmmodul ausgehen und dann als Befehl einfach alle runter oder hoch fahren lassen. Gehört nicht in die ASC Automatik.

[det.]

Dann brauche ich ja keine automatische Beschattung ein zu bauen. Dann kann man das auch per Hand machen 

Das sehe ich nicht so, mir geht es nur darum, wer Chef der Haussteuerung ist. Der Mensch oder Fhem? MMn sollte der Wille des Menschen, wenn er daheim ist nicht von Fhem korrigiert werden. Die Automatik übernimmt die komplette Steuerung während der Abwesenheit der Bewohner und macht wohl Vorschläge auch bei seiner Anwesenheit, die aber durch manuellen Eingiff geändert werden können.

[det.]

Sowas sollte von einem Alarmmodul ausgehen und dann als Befehl einfach alle runter oder hoch fahren lassen. Gehört nicht in die ASC Automatik.

O.k., solange die Automatic kurz darauf nicht anderer Meinung ist und den Zustand ändert.

[CoolTux]

Das sehe ich nicht so, mir geht es nur darum, wer Chef der Haussteuerung ist. Der Mensch oder Fhem? MMn sollte der Wille des Menschen, wenn er daheim ist nicht von Fhem korrigiert werden. Die Automatik übernimmt die komplette Steuerung während der Abwesenheit der Bewohner und macht wohl Vorschläge auch bei seiner Anwesenheit, die aber durch manuellen Eingiff geändert werden können.

Nun das klingt ja schon wieder ganz anders.
Dafür gibt es ein Attribut. Hier kann man unter anderem sagen das nur bei Abwesenheit die Beschattung stattfinden soll.

[det.]

Hallo CoolTux,
Ja, ich will Dir ja keine Steine in den Weg legen, oder etwa Vorschriften machen. Es geht mir allein darum, Vorschläge einzubringen und Aspekte aufzeigen, die Dir helfen das Modul möglichst rund zu bekommen. Dabei bin ich der Meinung, das FHEM inzwischen so umfangreich und kompliziert geworden ist, das man ein Industrie 4.0 Zusatzstudium braucht, um die Möglichkeiten annähernd auszuschöpfen.
Weniger und das noch selbsterklärend ist mehr.

[CoolTux]

Hallo CoolTux,
Ja, ich will Dir ja keine Steine in den Weg legen, oder etwa Vorschriften machen. Es geht mir allein darum, Vorschläge einzubringen und Aspekte aufzeigen, die Dir helfen das Modul möglichst rund zu bekommen. Dabei bin ich der Meinung, das FHEM inzwischen so umfangreich und kompliziert geworden ist, das man ein Industrie 4.0 Zusatzstudium braucht, um die Möglichkeiten annähernd auszuschöpfen.
Weniger und das noch selbsterklärend ist mehr.

Keine Sorge. Ich diskutiere gerne und lasse mir gerne aufzeigen welche Wünsche/Denkansätze die User haben. Ich übernehme nur nicht alles. Heißt aber nicht das ich eine Diskussion deswegen störend oder sinnlos erachte. Dem ist nicht so. 

[diki]

Hallo CoolTux,

Keine Sorge. Ich diskutiere gerne und lasse mir gerne aufzeigen welche Wünsche/Denkansätze die User haben. Ich übernehme nur nicht alles. Heißt aber nicht das ich eine Diskussion deswegen störend oder sinnlos erachte. Dem ist nicht so.

Super, dann beschreibe ich meinen Denkansatz gleich nochmal ausführlicher.

Dann brauche ich ja keine automatische Beschattung ein zu bauen. Dann kann man das auch per Hand machen

Nein, eben nicht, das Modul ist gut und auf die Beschattung warten sicher viele Anwender.

Ich denke, es gibt zwei verschiedene Anwendungsfälle um die Automatik zu übersteuern.:

Fall 1: Wenn ich die Automatik unterbrechen will (Nachtmodus oder Beschattung) um mal eben schnell den Müll zur Terrassentür heraus zu bringen, dann öffne ich die Terrassentür mit dem Fensterkontakt, der Rollladen soll hochfahren und nach dem Schließen der Terrassentür wieder in die vor dem Öffnen automatisch eingestellte Position fahren.

Fall 2: Wenn ich die Automatik unterbrechen will (Nachtmodus oder Beschattung) weil ich einfach rausgucken will, dann fahre ich manuell. Mir ist in dem Fall klar, das die Automatik absichtlich unterbrochen wurde. Jetzt kann ich später auch die Terrassentür öffnen und wieder schließen und der Rollladen bleibt in der manuell angefahrenen Position. Hier ist das Attribut "Attribut ASC_BlockingTime_afterManual" schon sinnvoll, nur weiß ich heute nicht, wie lange ich morgen zum Fenster rausgucken will.

Vielleicht kann das Modul auf ein Ereignis (für diesen Rollladen) wie "Automatik_wieder_ein" reagieren (ähnlich wie beim Aussperrschutz - nur ist dafür eben aus meiner Sicht der Fensterkontakt ungeeignet)?

Danke und Gruß,
Dirk

[dk3572]

Hallo CoolTux,Super, dann beschreibe ich meinen Denkansatz gleich nochmal ausführlicher.Nein, eben nicht, das Modul ist gut und auf die Beschattung warten sicher viele Anwender.

Ich denke, es gibt zwei verschiedene Anwendungsfälle um die Automatik zu übersteuern.:

Fall 1: Wenn ich die Automatik unterbrechen will (Nachtmodus oder Beschattung) um mal eben schnell den Müll zur Terrassentür heraus zu bringen, dann öffne ich die Terrassentür mit dem Fensterkontakt, der Rollladen soll hochfahren und nach dem Schließen der Terrassentür wieder in die vor dem Öffnen automatisch eingestellte Position fahren.

Fall 2: Wenn ich die Automatik unterbrechen will (Nachtmodus oder Beschattung) weil ich einfach rausgucken will, dann fahre ich manuell. Mir ist in dem Fall klar, das die Automatik absichtlich unterbrochen wurde. Jetzt kann ich später auch die Terrassentür öffnen und wieder schließen und der Rollladen bleibt in der manuell angefahrenen Position. Hier ist das Attribut "Attribut ASC_BlockingTime_afterManual" schon sinnvoll, nur weiß ich heute nicht, wie lange ich morgen zum Fenster rausgucken will.

Vielleicht kann das Modul auf ein Ereignis (für diesen Rollladen) wie "Automatik_wieder_ein" reagieren (ähnlich wie beim Aussperrschutz - nur ist dafür eben aus meiner Sicht der Fensterkontakt ungeeignet)?

Danke und Gruß,
Dirk

Hallo CoolTux,

du erkennst bestimmt die Parallelen zwischen Dirk´s und meinen Wünschen? 
Die Automatik sollte vielleicht erst wieder greifen, wenn sie abends od. morgens wieder fahren möchte.

Schönes Wochenende und Gruß
Dieter

[homi]

Hallo CoolTux,

danke für das ASC-Modul  . Nach dem ich seit ein paar Tagen zwei Rollläden via ZWAVE (FIBARO System FGRM222 Roller Shutter Controller 2) in FHEM integriert habe, kommt mir das Modul gerade recht.

Habe nun aber festgetellt das die Rollläden Abends zwar auf 20 % herunterfahren aber morgens nicht auf 100 % aufgehen (er bleibt auf 20%) 

Meine Einschätzung ist, das "set ZWave_SWITCH_MULTILEVEL dim 100" wird ignoriert, da ein dimmen bei den FGRM222 nur von 0 - 99 vorgesehen ist.

Meine Einstellungen mit denen ich aktuell erfolgreich arbeite sind:
ASC_Closed_Pos 20
ASC_Open_Pos 90

... bei 90 ist der Rollladen aber noch zu sehen und noch nicht ganz hochgefahren.

Währe es möglich diese Werte manuell festzulegen, damit auch Werte wie 99 möglich sind !?

Grüße und einen schönen 2. Advent
homi

[CoolTux]

Hallo CoolTux,

danke für das ASC-Modul  . Nach dem ich seit ein paar Tagen zwei Rollläden via ZWAVE (FIBARO System FGRM222 Roller Shutter Controller 2) in FHEM integriert habe, kommt mir das Modul gerade recht.

Habe nun aber festgetellt das die Rollläden Abends zwar auf 20 % herunterfahren aber morgens nicht auf 100 % aufgehen (er bleibt auf 20%) 

Meine Einschätzung ist, das "set ZWave_SWITCH_MULTILEVEL dim 100" wird ignoriert, da ein dimmen bei den FGRM222 nur von 0 - 99 vorgesehen ist.

Meine Einstellungen mit denen ich aktuell erfolgreich arbeite sind:
ASC_Closed_Pos 20
ASC_Open_Pos 90

... bei 90 ist der Rollladen aber noch zu sehen und noch nicht ganz hochgefahren.

Währe es möglich diese Werte manuell festzulegen, damit auch Werte wie 99 möglich sind !?

Grüße und einen schönen 2. Advent
homi

Hallo homi,

Du kannst diesen Wert ohne Probleme selber festlegen.
Einfach in der FHEM Kommandozeile mit dem Befehl attr den Wert auf 99 setzen.


Grüße

[homi]

Hallo homi,

Du kannst diesen Wert ohne Probleme selber festlegen.
Einfach in der FHEM Kommandozeile mit dem Befehl attr den Wert auf 99 setzen.


Grüße

Peinlich - da hätte ich auch selbst drauf kommen können.  DANKE.

[Beetle2003]

Hallo,

ich bin dabei das Modul einzurichten und somit meine manuellen Steuerungen zu entfernen.
Dabei ergeben sich zwei Fragen:
1. Wie kann ich eine Verzögerung je Rolle eingeben, damit nicht zum angegebenen Zeitpunkt alle Rollos gleichzeitig auffahren ( sunrise(+600))?
2. Ich habe bei der Eingabe der Fensterkontakte mich vertippt. Den Fehler habe ich behoben, doch in meinem NOTIFYDEV ist der Fehleintrag noch vorhanden. Wie lösche ich den?

Danke

[CoolTux]

Hallo,

ich bin dabei das Modul einzurichten und somit meine manuellen Steuerungen zu entfernen.
Dabei ergeben sich zwei Fragen:
1. Wie kann ich eine Verzögerung je Rolle eingeben, damit nicht zum angegebenen Zeitpunkt alle Rollos gleichzeitig auffahren ( sunrise(+600))?
2. Ich habe bei der Eingabe der Fensterkontakte mich vertippt. Den Fehler habe ich behoben, doch in meinem NOTIFYDEV ist der Fehleintrag noch vorhanden. Wie lösche ich den?

Danke

1. Im ASC Device gibt es das Attribut ASC_shuttersDriveOffset hier in Sekunden die Verzögerung einstellen. Diese wird dann zwischen 0 und Deinem eingetragenen Wert als Zufall "errechnet". Diese Einstellung wäre Global für alle Rollläden.
Du kannst auch in den Attributen im Rollladen ASC_Drive_Offset setzen. Dann wäre es für jeden Rolladen noch mal unterschiedlich.
2. Entweder das Attribut entfernen und dann neu setzen. Das wäre aber nun bei Dir zu spät da Du es bereits geändert hast.
Du kannst das Attribut expert auf 1 setzen und dann ein set createNewNotifyDev machen.


Grüße

[FunkOdyssey]

Ich habe es nun endlich getan und habe meine gesamte Jalousiensteuerung auf ASC umgestellt.
Bisher hatte ich nur einige Test-Jalousien in unwichtigen Räumen aktiv.

Nun habe ich aber direkt ein paar Fragen:
1) Das Thema mit den "kombinierten Offsets" hatte ich ja bereits hier angesprochen. Über Structures zu arbeiten, wie von CoolTux vorgeschlagen, wäre natürlich möglich, aber ich verliere dann die feinen Konfigurationsmöglichkeiten, die ich sonst hätte. Nun ja, ich werde warten.

2) Ich gehöre zu den Anwendern, die die Jalousien über Helligkeitswerte fahren lassen. Das klappt beim Herunterfahren auch ganz gut, aber beim Hochfahren sind die Schwellwerte (brightnessMinVal) zu groß. Ich fahre die Jalousien bei einer geringeren Helligkeit hoch, da ich sonst viel zu lange warten muss.
Frage: Besteht die Möglichkeit, die Schwellwerte für das Hoch- und Runterfahren zu trennen?

3) Bei der Erstkonfiguration musste ich bei allen Jalousien manuell "ASC_Shading_Brightness_Sensor" und "ASC_Shading_Brightness_Reading" setzen. Beim "ASC_residentsDevice" und "ASC_temperatureSensor" hast du zusätzlich die Möglichkeit eingebaut, dies im ASC-Modul global zu definieren. Könnte man das beim Brightness-Sensor nicht auch anbieten? Also global wie auch individuell je Jalousie?


4) Das Fahren über "absent" bedeutet, dass ausschließlich gefahren wird, wenn die Kriterien (time, astro & Co.) zutreffen UND die Bewohner absent|gone sind, oder? Die Statusänderung auf "absent" ist kein Trigger, der das Fahren auslöst, oder? Ich dachte, vermutlich fälschlicherweise, dass beim Verlassen die Jalousien durch das absent-Event gefahren werden. Dies ist nur eine Frage - kein Änderungswunsch.