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

[throbin]

Hi,
ich hatte jetzt die Gelegenheit ein Paar Tage mit dem Modul herumzuspielen. Funktioniert ganz gut, ich benutze zwar keine Sensoren (noch nicht), aber das Test-Rollo wird zuverlässig gesteuert - super, tolle Arbeit! Der Plan ist irgendwann meine DOIFs zur Rollosteuerung komplett zu ersetzen. Ich habe ein Paar generelle Fragen zum Modul, vielleicht kann mir jemand weiterhelfen:
1) Die Konfiguration wird größtenteils durch die Attribute gemacht, diese kann ich bspw. über die Tablet UI oder Webinterface von FHEM ändern, muss aber die Konfiguration danach speichern. Gibt es hier eine Möglichkeit das implizit zu tun (automatisch etc.)?
2) Ich benutze einen UP-Switch (Relay) von FIBARO um den Lockout mit einer Wandwippe zu aktivieren. Diese wird in meinen DOIFs ausgewertet, damit einige Rollos (Terrasse bspw.) nicht runterfahren. Wie kann ich das mit meinem Rollo, welches vom ASC-Modul gesteuert wird, koppeln. Muss ich ein bestimmtest Reading definieren? Kann man irgendwo ein Lockout Device angeben? Denkbar wäre hier natürlich auch anderes Device zu nehmen (bspw. Shelly 1 etc.)...
3) Mit dem Betätigen des Lockout-Switch während der Fahrt, werden die entsprechenden Rollos angehalten/gestoppt. Das ist über eine Perl Funktion implementiert. Wie kann ich (evtl. über eine Perl-Funktion) dasselbe beim ASC-Rollo erreichen - reicht es aus ein Stop-Befehl abzusetzen? Oder muss ich noch was beachten?

Danke!

[chrisse111179]

Hallo,
danke für das klasse Modul! Es hat bei mir gefühlte 100 Dummys und DOIFs ersetzt.
Zwei Fragen hätte ich noch:

• Meine Rollläden haben sich generell geschlossen wenn niemand anwesend war. Geht das mit ASC auch?
• Ich habe das Attribut ASC_GuestRoom entdeckt, kann aber in der Commandref keine Beschreibung dazu finden. Was macht das denn?

Viele Grüße,
Christian

[CoolTux]

1) Die Konfiguration wird größtenteils durch die Attribute gemacht, diese kann ich bspw. über die Tablet UI oder Webinterface von FHEM ändern, muss aber die Konfiguration danach speichern. Gibt es hier eine Möglichkeit das implizit zu tun (automatisch etc.)?

Attribute sind eigentlich dafür da einmalig eine entsprechende Einstellung vor zu nehmen und es dann dabei zu belassen. So ist es auch vom ASC Modul her gedacht.

2) Ich benutze einen UP-Switch (Relay) von FIBARO um den Lockout mit einer Wandwippe zu aktivieren. Diese wird in meinen DOIFs ausgewertet, damit einige Rollos (Terrasse bspw.) nicht runterfahren. Wie kann ich das mit meinem Rollo, welches vom ASC-Modul gesteuert wird, koppeln. Muss ich ein bestimmtest Reading definieren? Kann man irgendwo ein Lockout Device angeben? Denkbar wäre hier natürlich auch anderes Device zu nehmen (bspw. Shelly 1 etc.)...

Da wurde mir als externes Device nur ein Fensterkontakt einfallen. Du könntest einen Dummy anlegen der als state ein open gibt wenn Dein FIBARO on ist und closed wenn er off ist

3) Mit dem Betätigen des Lockout-Switch während der Fahrt, werden die entsprechenden Rollos angehalten/gestoppt. Das ist über eine Perl Funktion implementiert. Wie kann ich (evtl. über eine Perl-Funktion) dasselbe beim ASC-Rollo erreichen - reicht es aus ein Stop-Befehl abzusetzen? Oder muss ich noch was beachten?

Diese Funktion sollte ohne Probleme erhalten bleiben. Du kannst also auch locker während der Fahrt, welche von ASC ausgelöst wurde, dein Lockout-Switch auslösen.

[CoolTux]

Hallo,
danke für das klasse Modul! Es hat bei mir gefühlte 100 Dummys und DOIFs ersetzt.
Zwei Fragen hätte ich noch:

• Meine Rollläden haben sich generell geschlossen wenn niemand anwesend war. Geht das mit ASC auch?

Ja das geht auch. Du musst dazu ein Device im ASC Attribut ASC_residentsDevice hinterlegen.
Du kannst auch direkt mit Residents und Roommates arbeiten sofern Du es verwendest. Ansonsten Dummys.

• Ich habe das Attribut ASC_GuestRoom entdeckt, kann aber in der Commandref keine Beschreibung dazu finden. Was macht das denn?

Viele Grüße,
Christian

Das ist aktuell noch ohne Funktion.

[chrisse111179]

Ja das geht auch. Du musst dazu ein Device im ASC Attribut ASC_residentsDevice hinterlegen.
Du kannst auch direkt mit Residents und Roommates arbeiten sofern Du es verwendest. Ansonsten Dummys.

Achso, ok, danke! Ich hatte das missverstanden, und wollte das mit dem Attribut ASC_Roommate_Device am Rollladen selbst steuern.
Also wenn ich das ASC_residentsDevice hinterlege, und der state wechselt auf absent schließen sich alle Rollläden?

Viele Grüße

[CoolTux]

Achso, ok, danke! Ich hatte das missverstanden, und wollte das mit dem Attribut ASC_Roommate_Device am Rollladen selbst steuern.
Also wenn ich das ASC_residentsDevice hinterlege, und der state wechselt auf absent schließen sich alle Rollläden?

Viele Grüße

Wenn selfDefense aktiviert ist dann schließen sich die Rolläden nur da wo Fenster auf geblieben sind.
Wenn der Residents auf gone geht, default nach 36 Stunden schließen sie sich da die Rolläden, egal ob Fenster auf oder zu, wo der Rolladen als Terrasse gesetzt ist.

Also um es kurz zu machen.
Es gibt keine Einstellung welche alle Rollläden sofort nach absent schließt.

[chrisse111179]

Wenn selfDefense aktiviert ist dann schließen sich die Rolläden nur da wo Fenster auf geblieben sind.
Wenn der Residents auf gone geht, default nach 36 Stunden schließen sie sich da die Rolläden, egal ob Fenster auf oder zu, wo der Rolladen als Terrasse gesetzt ist.

Also um es kurz zu machen.
Es gibt keine Einstellung welche alle Rollläden sofort nach absent schließt.

Ok, dann werden ich das wohl über ein DOIF lösen. Wobei ich persönlich die Funktion im ASC-Modul super fände. Alles aus einer Hand sozusagen.
Nichtsdestotrotz danke für die Hilfe und ein schönes Restwochenende!
Christian

[eurofinder]

@CoolTux:
Würde mich auch sehr über eine Funktionalität freuen, in der bei absent ein Befehl abgesetzt werden kann, der alle dafür "markierten" Rollläden schließt. Ähnlich wie bei selfDefense , nur dass halt nicht Voraussetzung ist, dass ein Fenster offen ist.

Danke für dein tolles Modul.

Gruß
eurofinder

[CoolTux]

@CoolTux:
Würde mich auch sehr über eine Funktionalität freuen, in der bei absent ein Befehl abgesetzt werden kann, der alle dafür "markierten" Rollläden schließt. Ähnlich wie bei selfDefense , nur dass halt nicht Voraussetzung ist, dass ein Fenster offen ist.

Danke für dein tolles Modul.

Gruß
eurofinder

Ich habe schon drüber nachgedacht. Aber wenn dann alle Rolläden. Ohne markiert würde ich sagen.

[Kai-Alfonso]

Ich habe schon drüber nachgedacht. Aber wenn dann alle Rolläden. Ohne markiert würde ich sagen.

Ich bin auch dafür - mit oder ohne markieren wäre mir sogar egal, aber eine "Vorlaufzeit" wäre nett, die man einstellen kann. Damit beim Gassigehen nicht immer die Rollladen runterfahen

[eurofinder]

Eine einstellbare Zeit als Verzögerung finde ich auch sehr gut.

Befürworte trotzdem die individuelle Angabe, denn beim Verlassen des Hauses müssen ja nicht zwangsläufig alle offenen Rolläden geschlossen werden, sondern lediglich die Sicherheitsrelevanten.

Vorschlag:
Set Befehle für ASC-Device:
SecurityMode (on/off)

Attribute im AutoShuttersControl Device:
ASC_SecurityMode_Offset (Standard = 0) Zeitangabe in Minuten für Berücksichtigung der Verzögerung

Attribut im Rolllädendevices:
ASC_SecurityMode (on/off)

Gruß
eurofinder

[Kai-Alfonso]

Eine einstellbare Zeit als Verzögerung finde ich auch sehr gut.

Befürworte trotzdem die individuelle Angabe, denn beim Verlassen des Hauses müssen ja nicht zwangsläufig alle offenen Rolläden geschlossen werden, sondern lediglich die Sicherheitsrelevanten.

Vorschlag:
Set Befehle für ASC-Device:
SecurityMode (on/off)

Attribute im AutoShuttersControl Device:
ASC_SecurityMode_Offset (Standard = 0) Zeitangabe in Minuten für Berücksichtigung der Verzögerung

Attribut im Rolllädendevices:
ASC_SecurityMode (on/off)

Gruß
eurofinder

Klingt gut 


Ich hab noch mal eine andere Frage: ich nutze erst seit kurzen das Modul und bis jetzt funktioniert es auch. Er fährt runter, wenn der Wert in brightnessMinVal unterschritten wurde. Allerdings fährt er nicht hoch, wenn die Rollladen unten sind und der Brightnesswert wieder > brightnessMinVal ist. Oder muss der Brightnesswert in brightnessMaxVal? brightnessMaxVal  verstehe ich eher als Wert, den ich für Beschattung nutzen würde, deswegen ist der nicht gesetzt.

[CoolTux]

Wenn er einmal runter gefahren ist wegen Sonnenuntergang und brightness, fährt er den Abend nicht mehr hoch. Das ist so.
Der max Wert ist für frühs hoch fahren.

[Kai-Alfonso]

Wenn er einmal runter gefahren ist wegen Sonnenuntergang und brightness, fährt er den Abend nicht mehr hoch. Das ist so.
Der max Wert ist für frühs hoch fahren.

Ich hab mich vielleicht falsch ausgedrückt - er fährt Abends wegen brightness runter, aber morgen nicht wegen brightness hoch. Erst wenn ASC_Time_Up_Late erreicht wird.

Also ist der max wert fürs frühe hochfahren. Also brigthness < minWert = runterfahren, brigthness > maxWert  = hochfahren?

Habe ich das richtig verstanden?

[CoolTux]

Ich hab mich vielleicht falsch ausgedrückt - er fährt Abends wegen brightness runter, aber morgen nicht wegen brightness hoch. Erst wenn ASC_Time_Up_Late erreicht wird.

Also ist der max wert fürs frühe hochfahren. Also brigthness < minWert = runterfahren, brigthness > maxWert  = hochfahren?

Habe ich das richtig verstanden?

Korrekt. Genau so