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

Cluni · 16 Oktober 2017, 15:02:28

Hi Maik,

der Wunsch steht schon auf der Liste. Aber das wird gefühlt an sehr vielen Stellen Umbaumaßnahmen erfordern. Ich weiß noch nicht, wann ich dazu kommen werde. Außerdem werde ich das nur im "Blindflug" machen können, weil ich keine Testumgebung habe (ich weiß - müsste ich mir mal aufsetzen) und mir auch meine System nicht umdrehen möchte. Für mich ist es so herum halt komplett intuitiv: 0% entspricht 0% geöffnet und 100% halt 100% geöffnet. Ist halt Ansichtssache - jeder Jeck ist anders jeck...

Gruß Bernd

Schnurpi · 16 Oktober 2017, 16:43:53

... ja genau. Bei mir ist es 0% bis 100% abgeschattet/verdunkelt. Eben alles Ansichtssache.

Nächste Woche hab ich etwas mehr Zeit, dann teste ich die Version eventuell mal.

C0mmanda · 16 Oktober 2017, 19:33:37

Zitat von: Cluni am 14 Oktober 2017, 20:45:02
Und, hat sich schon jemand getraut und ein wenig ausprobiert?

Gesendet von iPhone mit Tapatalk

Leider nein, bin beim testen neuer Versionen vorerst raus.
Ich habe zu viel am Modul umgebaut, die "Standard"-Version würde bei mir nicht mehr laufen.

Habe z.B. "umgebaut:
Anpassung auf levelInverse,
Steuerung per WeekdayTimer (dadurch entfallen die ganzen "at"),
Optionale Zwischenschritte beim öffnen und beim schliessen für jeden Rollladen (möglich durch WeekdayTimer).

Ansonsten läuft das Modul allerdings prima.
Vielen Dank nochmal für die Arbeit und Bereitstellung!!

grtz
CmdA

MarkusHiba · 16 Oktober 2017, 19:58:22

Hallo commanda

Was hast du da alles so umgebaut vielleicht könnte man weekdaytimer auch mit einbauen.

Grüße
Markus

Gesendet von meinem E6653 mit Tapatalk

Cluni · 16 Oktober 2017, 20:02:51

Mojn zusammen,

Weekdaytimer habe ich für mich ziemlich zu Anfang ausgeschlossen. Wollte das ganze zuerst auch damit realisieren, bevor ich den ganzen Eigenbau angefangen habe. Das ist bei mir leider nicht gelaufen. Hatte auch Kontakt zum Programmierer. Der konnte mir damals aber auch nicht sagen, wo das Problem lag.

Aber was genau hast du gegen die ats? At und auch Notify sind doch die grundlegendsten Dinge in fhem überhaupt. Ich denke, dass damit die Belastung fürs System minimal ist....

Gesendet von iPhone mit Tapatalk

C0mmanda · 16 Oktober 2017, 21:19:03

Zitat von: Cluni am 16 Oktober 2017, 20:02:51
Mojn zusammen,

Weekdaytimer habe ich für mich ziemlich zu Anfang ausgeschlossen. Wollte das ganze zuerst auch damit realisieren, bevor ich den ganzen Eigenbau angefangen habe. Das ist bei mir leider nicht gelaufen. Hatte auch Kontakt zum Programmierer. Der konnte mir damals aber auch nicht sagen, wo das Problem lag.

Aber was genau hast du gegen die ats? At und auch Notify sind doch die grundlegendsten Dinge in fhem überhaupt. Ich denke, dass damit die Belastung fürs System minimal ist....

Gesendet von iPhone mit Tapatalk

Ich habe grundsätzlich überhaupt nichts gegen die ats.
Das war auch nicht der Grund weshalb ich auf WeekdayTimer umgebaut habe.

Der Hauptgrund war die Zwischenfahrt. Ich hatte keine Idee wie ich das mit den ats zusammenbringe und der Weg über WeekdayTimer erschien mir einfacher.

Außerdem basierte meine Rolladensteuerung vor deinem Modul ebenfalls auf WeekdayTimer weshalb ich ihn einfach "mag"

.
Zusätzlich liegt der Vorteil darin dass ich heute schon die Fahrtzeit vom Sonntag sehen kann. (Für die Monks unter uns

)

Ich bin ganz sicher absolut kein FHEM-Profi, behaupte aber einfach mal das der WeekdayTimer noch Ressourcen-schonender ist da das tägliche generieren der ats entfällt. (aber selbst die "Belastung" ist vermutlich nicht erwähnenswert).

Wie gesagt, der Hauptgrund war die Zwischenfahrt.

grtz

Zitat von: MarkusHiba am 16 Oktober 2017, 19:58:22
Hallo commanda

Was hast du da alles so umgebaut vielleicht könnte man weekdaytimer auch mit einbauen.

Grüße
Markus

Gesendet von meinem E6653 mit Tapatalk

Im wesentlichen ist es sehr simpel.

Weekdaytimer definiert mit den gewünschten Fahrzeiten, als Device im WDT jeweils den Rolladen und als command der Aufruf einer neuen sub.

Code Auswählen


Rol.eg.Kueche $we|{sunrise_abs_dat($date, "CIVIL",-1800,"08:00","10:00")}|up:pre $we|{sunrise_abs_dat($date, "CIVIL",0,"09:00","11:00")}|up:full !$we|{sunrise_abs_dat($date, "CIVIL",-1800,"06:00","06:50")}|up:pre !$we|{sunrise_abs_dat($date, "CIVIL",0,"07:00","07:15")}|up:full {sunset_abs_dat($date, "CIVIL",-1800,"17:00","23:00")}|down:pre {sunset_abs_dat($date, "CIVIL",0,"17:00","23:00")}|down:full {Auto_Rollladen_WDT_Steuerung($NAME, $EVENT)}

Es wird also für jeden Rolladen ein Weekdaytimer benötigt.

Die Fahrzeiten werden mit dem Befehl "up:pre", "up:full" und entsprechend "down:pre" und "down-full" definiert. Wenn keine Zwischenfahrt gewünscht ist dann die Befehle mit "pre" einfach weglassen und nur "full" einstellen.

Der Weekdaytimer ruft dann eine sub mit dem Device-Namen und dem Befehl auf.
Die sub splittet das ganze dann und je nachdem ob "up" oder "down" gefahren werden soll wird die sub "Auto_Rollladen_schliessen" oder "Auto_Rollladen_öffnen" aufgerufen. Auch wieder mit dem Device und dem Parameter "pre" oder "full".

Code Auswählen

sub Auto_Rollladen_WDT_Steuerung($$) {
	my ($device, $parameter) = @_;
	
	my ($direction, $prefull) = split(/ /, $parameter);	 
	
	if ($direction eq 'up') {
		Auto_Rollladen_oeffnen($device,$prefull);
	} 
	elsif ($direction eq 'down') {
		Auto_Rollladen_schliessen($device,$prefull);
	}
	else { # Fürs Debuggen
		Log 3, '=== Fehler in Übergabe Rollladen-Weekdaytimer an Rollladen-Steuerung ===';
		fhem("msg Device:$device Param:$parameter - Direction:$direction PreFull:$prefull");
	}
}

Für die Zwischenfahrten werden dann im jedem Rollladen neue Attribute benötigt, nämlich
"Automatik_offen_Pos_pre" und "Automatik_geschlossen_Pos_pre".

In den subs fürs schliessen und öffnen muss dann nur noch unterschieden werden ob pre oder full gefahren werden soll und die Übergabe muss berücksichtigt werden.

Code Auswählen

sub Auto_Rollladen_oeffnen($$)

Und my $dev=shift(@_); habe ich einfach in my ($dev, $param) = @_; geändert.

Die Erstellung der ats habe ich dann natürlich auskommentiert.
Damit das ganze dann aber auch schick in der Readingsgroup dargestellt wird habe ich da auch etwas umgebaut.

Wenn ernstes Interesse besteht könnte ich die Änderungen mal genau dokumentieren und den Code teilen.
Am besten wäre vermutlich per PM um hier im Thread keine Verwirrung zu stiften.

Ich denke WDT zu integrieren sollte möglich sein da man im Grunde nur die Erstellung der ats unterbinden muss (was per Attribut im Zentralen Dummy machbar wäre).
Der WDT ruft dann ja die subs öffnen/schliessen auf. (Über eine weitere kleine sub die bei Verwendung von ats dann einfach "brach" liegt)

grtz
CmdA

Cluni · 17 Oktober 2017, 08:58:35

Mojn!

Also ich werde die WDT aus verschiedenen Gründen nicht implementieren:

1. wegen meiner schon erwähnten Erfahrung
2. weil man damit abhängig von einem weiteren Modul ist - wenn was geändert wird, steht man da und muss wieder anpassen
3. kann man die Zwischenfahrten mMn auch ins vorhandene Programm integrieren

Muss unbedingt für jeden Rollladen eine eigene Stellung definiert werden, oder würde auch "halboffen" bzw "halbgeschlossen" reichen? Ich stelle mir vor, dass dann ein weiteres Attribut "Auto_sanft_up_down" mit den Möglichkeiten aus, sanft hoch, sanft runter und sanft hoch und runter oder so. Das nimmt sonst irgendwann etwas überhand mit den Attributen...

Die Sache mit den ats ist ja die - wenn die ganze Sache irgendwann in ein Modul verwandelt wird, dann werden diese Dingen eh in internals verpackt und sind dann nicht mehr sichtbar. Anders wird das beim WDT auch nicht gelöst sein, denke ich. Und mann könnte die Berechnung dann ja auch für eine Woche im voraus machen, damit Nerds die Zeiten schon im Vorfeld abchecken könnten. Aber das finde ich Quatsch - wird bei einem festen Rollladentimer in der Wand auch nicht gehen (ist mir zumindest noch nicht untergekommen). Ist aber eine Sache, über die man nachdenken kann und nicht direkt verwerfen muss. Ich schreibe es mal auf die Wunschliste.

Gruß Bernd

C0mmanda · 17 Oktober 2017, 19:07:54

Zitat von: Cluni am 17 Oktober 2017, 08:58:35
Mojn!

Also ich werde die WDT aus verschiedenen Gründen nicht implementieren:

1. wegen meiner schon erwähnten Erfahrung
2. weil man damit abhängig von einem weiteren Modul ist - wenn was geändert wird, steht man da und muss wieder anpassen
3. kann man die Zwischenfahrten mMn auch ins vorhandene Programm integrieren

Moin.

Alles gut!
Ich habe nur auf die Frage von MarkusHiba geantwortet!
Es ist von mir persönlich kein Feature-Request den WeekdayTimer zu implementieren!
Ich habe lediglich meine Meinung kundgetan bezgl. der Aussage "vielleicht könnte man den WDT implementieren".

Zitat
Muss unbedingt für jeden Rollladen eine eigene Stellung definiert werden, oder würde auch "halboffen" bzw "halbgeschlossen" reichen? Ich stelle mir vor, dass dann ein weiteres Attribut "Auto_sanft_up_down" mit den Möglichkeiten aus, sanft hoch, sanft runter und sanft hoch und runter oder so. Das nimmt sonst irgendwann etwas überhand mit den Attributen...

Ich schätze das würde ausreichen. Hängt natürlich ein bisschen davon ab was genau du dir darunter vorstellst.

Bei mir persönlich habe ich es nun so gebaut dass die Rolläden 30min. vor Sonnenuntergang auf pct 60 heruntergefahren werden. (Ohne levelInverse sollte das pct 40 sein). Damit ist ca. 1/3 der Fensterscheibe noch "frei".
Zum Sonnenuntergang wird der Rolladen dann komplett geschlossen.

Zitat
Die Sache mit den ats ist ja die - wenn die ganze Sache irgendwann in ein Modul verwandelt wird, dann werden diese Dingen eh in internals verpackt und sind dann nicht mehr sichtbar. Anders wird das beim WDT auch nicht gelöst sein, denke ich. Und mann könnte die Berechnung dann ja auch für eine Woche im voraus machen, damit Nerds die Zeiten schon im Vorfeld abchecken könnten. Aber das finde ich Quatsch - wird bei einem festen Rollladentimer in der Wand auch nicht gehen (ist mir zumindest noch nicht untergekommen). Ist aber eine Sache, über die man nachdenken kann und nicht direkt verwerfen muss. Ich schreibe es mal auf die Wunschliste.

Gruß Bernd

Sicherlich hast du recht. Soweit reichen meine Kenntnisse in FHEM nicht.
Und natürlich ist es nerdig und im Grunde unnötig zu wissen wann die Rolläden nächste Woche gefahren werden, auch da gebe ich dir Recht.

Wenn die ganze Geschichte mal in ein Modul gegossen wird und die Features da sind werde ich es womöglich auch in der out-of-the-box Version benutzen.
Der Weg mit den ats ist nichts wo ich etwas dagegen habe, ich hatte lediglich keine andere Idee das mit den Zwischenfahrten zu realisieren.

Aktuell habe ich halt einfach die Dinge eingebaut die ich mir gewünscht habe, was aber bitte absolut nicht als Kritik aufgefasst werden soll. Ich weiß wieviel Arbeit darin steckt und langwierig die Entwicklung ist und auch dass man die ganzen Wünsche nicht zeitnah einbauen kann.

Ich bin nach wie vor wirklich sehr dankbar für das Modul und eure Arbeit.

grtz
CmdA

nils_ · 18 Oktober 2017, 09:20:17

nur mal für mich ne verständnisfrage:
was sind denn "zwischenfahrten" ??

bisher haben mir die "normalen" fahrzeiten ausgereicht?!

kannst auch gerne per PM antworten, will den thread hier nicht damit aufblähen (ups... schon passiert

)

C0mmanda · 18 Oktober 2017, 09:39:33

Ich verstehe unter Zwischenfahrt dass der Rolladen zunächst nur halb herunter fährt, zb sls Sichtschutz in der Dämmerung.
Wenn es dann dunkel ist fährt der Rolladen komplett herunter.

Grtz

nils_ · 18 Oktober 2017, 09:59:53

Zitat von: C0mmanda am 18 Oktober 2017, 09:39:33
Ich verstehe unter Zwischenfahrt dass der Rolladen zunächst nur halb herunter fährt, zb sls Sichtschutz in der Dämmerung.
Wenn es dann dunkel ist fährt der Rolladen komplett herunter.

Grtz

ah ok....
danke für die erklärung!

Cluni · 18 Oktober 2017, 10:13:39

Im Kopf spiele ich mit den Zwischenfahrten schon herum. Ich glaube nicht, dass dies schwierig im Code zu implementieren ist. Stelle mir folgendes vor:

- Zeitverzögerung wird im globalen Dummy eingestellt (also für alle gleich)
- gleiches gilt für die Stellung in %, auf die gefahren werden soll
- neues Attribut am Aktor; z.B. "Auto_sanft_up_down" mit den Möglichkeiten "aus", "sanft hoch", "sanft runter" und "sanft hoch und runter"
- bei gesetztem Attribut wird jeweils ein weiteres at vor dem "normalen" at erzeugt, welches die "Vorfahrt" erledigt

Sollte relativ einfach und schnell zu implementieren sein, wenn gewünscht...

Es stehen natürlich auch noch andere Dinge auf dem Wunschzettel wie Invertierung bei levelInvers, Partymodus, Anwesenheit einzeln pro Rollladen einstellen und die Implementation von Regen- und Windsensor. Außerdem würde ich mir gerne bald mal ansehen, wie ich das ganze in ein Modul umgebaut bekomme.

Bald kommen ja die langen und dunklen Tage. Mal sehen...

nils_ · 18 Oktober 2017, 10:21:21

jetzt hab ich schon wieder eine frage

wie kommst du auf "sanft" ??

verständlicher für mich wäre:
Auto_zwischenfahrt_up_down
oder
Auto_zusatzfahrt_up_down

ist aber nur meine meinung, denn ich würde sowas nicht bei dem begriff "sanft" vermuten.
(da ich hier mitlese wüsste ich es natürlich

)

C0mmanda · 18 Oktober 2017, 10:23:08

@Cluni

Hört sich alles sehr gut an!
Ich freu mich drauf

Grtz

Cluni · 18 Oktober 2017, 10:24:17

Das hatte irgendjemand (ich glaube Frini per WhatsApp) mal so genannt, weil es nicht hart sondern sanft öffnet bzw schließt. Man kann das Kind auch anders nennen...