Rollladensteuerung für HM/ROLLO inkl. Abschattung und Komfortfunktionen in Perl

[HoTi]

Klingt als Ansatz gut.

Wobei ich gerade überlege, ob es nicht auch eine Alternative wäre auf ein Event von Twilight auf das ss_weather Reading zu reagieren. Wenn das auslöst, dann den entsprechenden Timer anpassen. Hätte eventuell den Vorteil, dass man sich keine Gedanken über Vogel, Laub oder sonstwas auf einem Lichtsensor Gedanken machen muss.
Zumindest bei uns ist ss_weather ziemlich zuverlässig.

Da hast du wohl recht, aber das habe ich schon öfters gedacht und habe dann doch wieder gesagt bekommen das es vorher besser war.
Es geht nichts über echte Werte statt berechnete. Vor allem weil ich auf dem Land wohne und sich die Helligkeit immer Subjektiv unterscheidet.
Also ein und der selbe Mensch empfindet Dunkelheit in der Stadt anders als auf dem Land.

Vg
Tim

[Cluni]

Wie ist das denn mit ss_weather? Wird das auch tagsüber angepasst, wenn sich das Wetter ändert?

Ich glaube, dass mein zweiter Ansatz recht zielführend ist. Da geht es dann nach dem reellen Helligkeitswert gemessen mit dem eigenen Sensor und gut ist. Ggf. noch den Intervall für die Überprüfung am Dummy anpassbar machen, die Schwelle(n) an jedem Aktor und ab dafür...

[kjmEjfu]

Da hast du wohl recht, aber das habe ich schon öfters gedacht und habe dann doch wieder gesagt bekommen das es vorher besser war.
Es geht nichts über echte Werte statt berechnete. Vor allem weil ich auf dem Land wohne und sich die Helligkeit immer Subjektiv unterscheidet.
Also ein und der selbe Mensch empfindet Dunkelheit in der Stadt anders als auf dem Land.

siehst du, so geht das subjektiv auseinander
Bei uns gefielen der Frau vorher die Fahrzeiten über Twilight besser, weil sie die realistischer fand. Zwischenzeitliche Tests mit den echten Werten waren da nicht so positiv, weil da zu viele Faktoren für Ungenauigkeiten gesorgt haben (Wolken, Vögel, ...).
Wobei es tatsächlich etwas längeres justieren an indoor_horizon war, bis das ganz gut passte.

Wie ist das denn mit ss_weather? Wird das auch tagsüber angepasst, wenn sich das Wetter ändert?

Ja, wird auch tagsüber angepasst. Ich weiß nicht, in welchem Intervall die Updates passieren, aber da das aktuelle Yahoo! Wetter für die Berechnung berücksichtigt wird, ...

Man könnte vielleicht auch beide Varianten erschlagen.
Twilight liefert auch das Reading light (mit Werte von 0 bis 6). Wenn man nun im Dummy ein Device und Reading hinterlegen kann und dann beim Aktor die Schwelle, dann sollte das auch gehen.
Außer ich habe deine Variante 2 nicht richtig verstanden.

[Cluni]

Wenn man nun im Dummy ein Device und Reading hinterlegen kann und dann beim Aktor die Schwelle, dann sollte das auch gehen.

Nein, ich wollte nicht nochmal ein extra Attribut anlegen, um ein weiteres Reading zu hinterlegen. Das macht die Sache doch nur unübersichtlicher. Ich kann mir nicht vorstellen, dass man sowas mit dem normalen (schon vorhandenen) Helligkeitswert und einer zusätzlichen Schwelle nicht auch hinbekommen kann. Damit eine Wolke oder auch ein Vogel nicht direkt zum Schließen der Rollladen führt, wird ja (genau wie bei der normalen Abschattung) noch eine Zeit lang gewartet und zwischendurch geschaut, ob die Bedingungen noch vorhanden sind...

[Living]

Ich möchte in eine bestehende "Cluni" Rollosteuerung eine Fenster-Drehgriff-Kontakt einbinden.
In dem Modul finde ich folgende Einstellmöglichkeiten
Auto_Aussperrschutz       ja/nein
Auto_Fensterkontakttyp    twostate
Wenn ich hier ja einstelle, wie wird mein Kontakt mit dem Rollo verbunden?
Nehme ich ein notify und verändere jeweils das attr Automatik_Modus_runter auf aus/immer
oder gibt es bessere Wege?

[kpl]

Hallo Cluni,

ich hätte falls du Lust hast auch noch eine Funktionsanfrage.
Für mich wäre es hilfreich, wenn am Rollladen ein Anwesenheits-Reading definiert werden könnte, um die einzelnen Rollladen von unterschiedlichen Personen oder Gruppen abhängig zu Steuern.

Gruß
kpl

[kjmEjfu]

Ich möchte in eine bestehende "Cluni" Rollosteuerung eine Fenster-Drehgriff-Kontakt einbinden.
In dem Modul finde ich folgende Einstellmöglichkeiten
Auto_Aussperrschutz       ja/nein
Auto_Fensterkontakttyp    twostate
Wenn ich hier ja einstelle, wie wird mein Kontakt mit dem Rollo verbunden?
Nehme ich ein notify und verändere jeweils das attr Automatik_Modus_runter auf aus/immer
oder gibt es bessere Wege?

es gibt doch noch das Attribut Auto_Fensterkontakt. Da trägst du den Namen von dem entsprechenden Kontakt ein.
Den Auto_Fensterkontakttyp musst du dann noch von twostate auf threestate ändern.

[kjmEjfu]

@Cluni: Da sich die Kinder gerade aufgrund eines beweglichem Ferientag total über das frühe Öffnen der Rollos "freuen", hast du schone Idee bzgl. Implementierung des angedachten Urlaubs-Modus?

[Schnurpi]

Wenn Dein Ferien-notify richtig funktioniert, hätten die Rollläden heute eigentlich wie am Wochenende fahren müssen... Welchen Wert hat das Reading ,,Ferientag" im Dummy ,,Rollladensteuerung Einstellungen"?

[Cluni]

@kjmEjfu: normalerweise müsstest du nur einen Urlaubskalender analog zu den anderen Kalendern anlegen und ein korrektes Notify dafür erzeugen, so dass der Eintrag im Dummy landet wie bei den anderen beiden Kalendern. Dann sollte das schon funktionieren - ist ja schon lange eingebaut...

@Living: Läuft es jetzt?

@kpl: Muss mir mal ansehen, wie viel Aufwand das wäre. Aber mach dir nicht zu viel Hoffnung.


Gesendet von iPhone mit Tapatalk

[kjmEjfu]

@kjmEjfu: normalerweise müsstest du nur einen Urlaubskalender analog zu den anderen Kalendern anlegen und ein korrektes Notify dafür erzeugen, so dass der Eintrag im Dummy landet wie bei den anderen beiden Kalendern. Dann sollte das schon funktionieren - ist ja schon lange eingebaut...

Hmm, also es gibt im Device Rolladensteuerung ein Reading Feiertag  und ein Reading Ferientag. Gibt es auch noch eins für Urlaub, das ich übersehen habe?
Aber selbst wenn, laufe ich wieder in mein "Lieblingsproblem": mir fehlen Attribute

Letztlich steuert Auto_Zeit_hoch_WE_Urlaub ja nur, dass bei Feier- oder Ferientag das Rollo später hochfährt. Es gibt aber keine Unterscheidung. Sprich, einen Feiertag analog zum Wochenende zu behandeln, ist kein Problem. Ein Ferientag trifft aber nicht für jedes Rollo zu, weil u.U. die Eltern (oder ein Teil der Eltern) ja trotzdem zur Arbeit müssen (und entsprechende Rollos früher oben haben wollen). Analog zum Urlaubstag, an dem das Rollo im Elternschlafzimmer unten bleiben soll, die bei den Kindern aber nicht unbedingt.

Ich glaube, ich werde nicht drum herum kommen, mir nachgelagert eine Funktion zu schreiben, die die Zeiten für öffnen und schließen nochmal anpasst.

[Living]

Fenster Drehgriff Kontakt ist installiert und läuft!!

[Schnurpi]

@Cluni,
ich hatte ja auch schon vor einiger Zeit einen ähnlichen Wunsch geäußert 
Momentan haben wir Ferien und alle Rollläden im gesamten Haus bleiben länger unten (bis zur Auto_Zeit_hoch_WE_Urlaub eben). Wäre statt einer zusätzlichen Zeit im einzelnen Rollladen vielleicht auch ein Attribut denkbar, worüber man einstellen kann, dass Ferien ausgeschlossen werden?

[oli82]

Guten Morgen.

Aus irgendwelchen Gründen bekomme ich das Script nicht zum laufen.

Beim Anlegen der Attribute erhalte ich folgende Fehlermeldung:

Code Auswählen Erweitern

Undefined subroutine &main::Rollladensteuerung_update_device called at (eval 6273) line 1.

Im Log steht folgendes:

Code Auswählen Erweitern

2018.02.14 10:39:49 1: PERL WARNING: Use of uninitialized value $Modulversion in string ne at ./FHEM/99_myUtils_Shutter.pm line 76.
2018.02.14 10:39:49 1: PERL WARNING: Use of uninitialized value $Modulversion in concatenation (.) or string at ./FHEM/99_myUtils_Shutter.pm line 76.
2018.02.14 10:41:08 1: ERROR evaluating {Rollladensteuerung_update_device('[EG.Rollo.Gaeste.Fenster]')}: Undefined subroutine &main::Rollladensteuerung_update_device called at (eval 6273) line 1.

Handelt sich um eine frische Installation des Scriptes.
Der Raum "Haus" wurde aber angelegt.

Danke für die Hilfe, Oli

[Cluni]

@kjmEjfu & @Schnurpi: Leider werden die Attribute immer mehr und wie ihr selber wisst, haben die Devices nicht gerade wenige zusätzliche Attribute. Jedenfalls würde ich gerne zusätzliche Attribute vermeiden.

Ich werde mir das mal ansehen und schauen, wie ich den Parameter "Auto_Zeit_hoch_WE_Urlaub" am besten stückeln könnte. Das meine ich so, dass man das zum Beispiel so machen könnte:

Ist das Attribut Auto_Zeit_hoch_WE_Urlaub leer oder nicht vorhanden, dann werden alle Sondertage ignoriert und die Zeiten werden wie an "normalen" Wochentagen berechnet.

Auto_Zeit_hoch_WE_Urlaub: 09:15:00  ==> im Urlaub, an WE, an Ferientagen und an Feiertagen geht dieser Rollladen um 9:15Uhr hoch   (das ist so, wie es gerade ist und würde auch in Zukunft so funktionieren)

Nun könnte ich mir vorstellen, dass man weitere Parameter übergibt - z.B. "U" für Urlaub, "W" für Wochenende, "F" für Feiertag und "V" für Vacation/Ferien. Alle Parameter werden dann z.B. durch Komma (muss ich mir noch überlegen) getrennt.

Auto_Zeit_hoch_WE_Urlaub: 09:15:00,W,F,10:30:00,V würde dann also folgendes heißen:

- an Wochenenden und Feiertagen ist 9:15Uhr die früheste Öffnungszeit
- in den Ferien ist 10:30Uhr die früheste Öffnungszeit
- die Angabe für Urlaub fehlt, also wird hier die "normale" Öffnungszeit wie an einem Wochentag genommen

Bei dieser Reglung müsste man sich jedoch eine Rangordnung überlegen - sprich Feiertag vor Wochenende vor Ferien vor Urlaub oder sowas in der Art, falls alle Zeiten angegeben sind und mehrere zutreffen wie zum Beispiel Wochenende im Urlaub.

Muss ich mir aber definitiv ansehen, ob sich das so recht einfach umsetzen lassen würde. Leider sehe ich aber auch, dass das die ganze Sache für Neulinge sehr kompliziert aussehen lässt und wird demnach wohl viele abschrecken...

@oli82: Mich irritiert die zweite Fehlermeldung - in meinem Code ist in Zeile 76 keinen Rede von $Modulversion. Bist du sicher, dass du den kompletten Inhalt (inkl. Kopf) von meiner 99_myUtils_Shutter.pm in deine 99_myUtils_Shutter.pm kopiert hast und dass du wirklich die aktuelle Version hast??