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

[nils_]

Ich habe letzte Woche bereits lange mit MarkusHiBa telefoniert - es ist nicht alles ganz so einfach. Beim Rollo-Mudul scheint das ein wenig verdreht zu sein. Das eine wird umgerechnet, der andere Wert nicht. Grob gesagt man sendet z.B. einen Befehl "set {name} position 70" und auf position steht nachher 30....

ok. sowas hatte ich befürchtet, das es nicht mit der "einfachen umrechnung" getan ist

[Cluni]

Also wenn ich das letzte Woche richtig verstanden habe, dann entspricht beim Rollo-Modul 0 = auf und 100 = zu - sowohl beim setzen des Wert als auch beim zurück lesen. Nun kann man dort wohl über ein Attribut sagen, dass man invertieren möchte. In dem Fall setzt man den Rollladen auf 100, um ihn zu öffnen und auf 0 um ihn zu schließen. Ließt man aber die Position zurück, so kommt beim geöffneten Rollladen aber immer noch 0 und beim geschlossenen Rollladen 100 zurück.
Wir haben uns dann so beholfen, dass wir einfach am Rollo-Modul ein Userreading erzeugt haben, wo bei jedem neuen Zustand der Wert 100-Position auf z.B. InvPos oder so abgebildet wird. Ich müsste dann nur in meinem Code je nach verwendetem Typ entweder den einen oder den anderen Wert behandeln und müsste nichts mehr umrechnen...

[Cluni]

19.07.2017 ( v0.9.1.8 ):
- Kleiner Fehler in der Komfortfunktion behoben - es wurde ein Öffnen-Befehl in einer bestimmten Situation beim Schließen eines Fensters abgesetzt, obwohl der Rollladen bereits
  auf der korrekten Position war
- Logging etwas angepasst in der Komfortfunktion - bei Telegram_Log_Komfort = 1 sollte nur noch bei wirklichen Fahrten des Rollos geloggt werden
- Die Modulversionsangabe in den Dummies wird nun auch in der Komfortfunktion und in der Abschattungsfunktion gesetzt. Die aktuelle Version wird im Normalfall also recht zügig
  auf den aktuellen Stand gebracht und nicht erst nachts bei der Neuberechnung der Timer.

[Chris8888]

Hallo Bernd,

ich habe inzwiwschen fast alle unsere Rollos umgestellt und das Modul läuft wirklich super. Ich habe bisher null Probleme damit gehabt! Besten Dank an dieser Stelle für euren Einsatz!

Ich habe 2 kleine Fragen:
1. Gibt es für die Logeinträge zum Ferien-Notifier inzwischen eine Lösung? Oder muss man damit leben?
Ferien.notify return value: SCALAR(0x5cbc030)

2. Wie reagiert das Modul auf "aktiviere Beschattung", wenn das Rollo aufgrund der Nachtphase noch geschlossen ist?
Geht es trotzdem in den Beschattungsmodus?
Für einen Teenager eine wirklich kritische Frage!

Beste Grüße
Christian

[Cluni]

ich habe inzwiwschen fast alle unsere Rollos umgestellt und das Modul läuft wirklich super. Ich habe bisher null Probleme damit gehabt! Besten Dank an dieser Stelle für euren Einsatz!

Das freut mich sehr zu hören! Schön, dass es so reibungslos funktioniert!

1. Gibt es für die Logeinträge zum Ferien-Notifier inzwischen eine Lösung? Oder muss man damit leben?
Ferien.notify return value: SCALAR(0x5cbc030)

Uhhhh, da war mal was - musst du mal im Forum suchen. Ich gucke auch gleich nochmal. Ich meine, dass ich dazu in dem anderen Thread mal was geschrieben habe...

2. Wie reagiert das Modul auf "aktiviere Beschattung", wenn das Rollo aufgrund der Nachtphase noch geschlossen ist?
Geht es trotzdem in den Beschattungsmodus?
Für einen Teenager eine wirklich kritische Frage!

Abwarten und beten....
Nein - so lange die Position des Rollladen niedriger ist, als für die Abschattung eingestellt, passiert da nichts. Warum auch - ist ja dann nicht nötig. Und wenn der Rollladen schon auf einer tieferen Position ist, dann will man den wohl auch dort haben - und nicht in der höheren Abschattungsposition...


Ich teste gerade zusammen mit MarkusHiBa und Frini eine Version, die sowohl mit Homematic als auch mit dem ROLLO-Mudul laufen müsste. Es hakelt aber noch an (bis jetzt) einer Stelle. Für alle, die nur Homematic verwenden sollte das Update ohne große Änderungen durchführbar sein. Es gibt dann nur ein weiteres Attribut am Rollladenaktor, wo man den Fahrbefehl eintragen kann (bei Homematic pct und bei ROLLO position). Das default ohne Eingabe ist jedoch pct für Homematic. Es müsste sogar ohne weiteres möglich sein, dass man beide Möglichkeiten gleichzeitig in einem System benutzen kann. Mal sehen - ist höchstwahrscheinlich im nächsten Update drin...

[Cluni]

Schon gefunden: https://forum.fhem.de/index.php/topic,69704.msg645798.html#msg645798

Gibt's ja gar nicht - das war sogar eine direkte Antwort an dich! Nächstes Mal besser lesen! 

[Chris8888]

Wenn es so einfach wäre....

Das ist für den Feiertagsnotifier...ich habe das Problem auch noch beim Feriennotifier...

Nein - so lange die Position des Rollladen niedriger ist, als für die Abschattung eingestellt, passiert da nichts. Warum auch - ist ja dann nicht nötig. Und wenn der Rollladen schon auf einer tieferen Position ist, dann will man den wohl auch dort haben - und nicht in der höheren Abschattungsposition...

und das ist spitze! An der Stelle erlebe ich wenig Toleranz ...gerade jetzt in den Ferien.

VG
Christian

[Cluni]

Wenn es so einfach wäre....

Das ist für den Feiertagsnotifier...ich habe das Problem auch noch beim Feriennotifier...

Eieieiei - und du schaffst es nicht jeweils das Wort "Feier" gegen "Ferien" auszutauschen??? 

[C0mmanda]

Mahlzeit,

habe nun auch bereits die Hälfte meiner Rolladen umgestellt und wie es aussieht läuft auch alles einwandfrei.
Vielen Dank dafür!

Da ich auf V 0.9.1.5 unterwegs bin und einiges im Code für mich anpassen mußte (Stichwort: param levelInverse bei Homematic) würde mich natürlich interessieren ob es angedacht ist levelInverse in Zukunft zu berücksichtigen. Ansonsten würden Updates recht aufwendig für mich...

Desweiteren, wenn ich nochmal so "frech" sein darf, ein paar Punkte die ich mir in Zukunft wünschen würde:

- Außentemp-Device per Attribut konfigurierbar (Spart Dummy +notify)
- Anwesenheits-Device per Attribut konfigurierbar (Stati ebenfalls, das RESIDENTS-Modul z.B. liefert "home"|"absent", nicht "present"|"absent") Spart außerdem ebenfalls Dummy + notify)
- Einen "Override" für die nächste automatisch Fahrt des Rolladen (morgens). Stichwort: Gast schläft auf der Couch und soll um 6:45 nicht durch hochfahrende Rolladen geweckt werden.(z.b. über einen Dummy oder ein Dropdown im Automatik.morgens Device)
- Eine zweistufige Fahrt der Rolladen abends. Gerade im Winter lasse ich die Rolladen bei Dämmerung gerne halb (Sichtschutz) und erst sehr viel später dann komplett herunter.
- Für User die in Perl-Code nicht so bewandert sind evtl. auch eine Einstellung der Helligkeitswerte des Sensors. (Nicht jeder hat den Homematic-Sensor welcher Lux liefert sondern wie ich nur die Bewegungsmelder).

Nicht falsch verstehen, sind nur Dinge die mir aufgefallen sind und die ich mir Wünschen würde.
Ich weiß ihr arbeitet aktuell an der implementierung von ROLLO. Wollte es nur aufschreiben ehe ich es vergesse.

Das Modul ist auch jetzt schon großartig und genau das wonach ich schon sehr lange suche!
Vielen vielen Dank für die Arbeit die ihr euch gemacht habt! Ich hätte es so komplex niemals hinbekommen.

grtz
CmdA

[Chris8888]

Eieieiei - und du schaffst es nicht jeweils das Wort "Feier" gegen "Ferien" auszutauschen??? 

Ich brauche Urlaub....das habe ich nicht gesehen...<davonschleich>

[Cluni]

Uhhhh, das sind ja gleich (mehr als) drei Wünsche auf einmal - das geht nun wirklich nicht.... LOL

Die momentane (noch nicht öffentliche) Version ist v0.9.2.2 - es wächst und wächst.
Über levelInvers mache ich mir zwar schon Gedanken, aber das ist alles nicht so einfach, wie man sich das erstmal denkt. Es gibt da verschiede Lösungsansätze, die aber alle nicht mal eben so umzusetzen sind. Aber ich denke bereits darüber nach. Was mir vorschwebt ist folgendes: Wenn levelInvers gesetzt ist, dann müsste man theoretisch jeden gelesenen Wert umrechnen auf 100 - gelesener Wert. Auch der errechnete Wert, auf den gefahren werden soll, müsste dann auf diese Art umgerechnet werden. Dann müsste es theoretisch so sein, dass alles andere (z.B. Vergleiche in den if/ifelse-Bedingungen) so bleiben könnte. Aber das ist wie gesagt erst mal hinten angestellt, bis das ROLLO-Modul mit meinem Code läuft.

Die Implementation der direkten Messwerte (also nicht über den Dummy-Umweg) habe ich auch die ganze Zeit schon im Hinterkopf. Ggf. mache ich dafür einen Dummy "Rollladen-Steuerung" oder so, in dem dann die jeweiligen Sensoren und dessen Messwert namentlich hinterlegt werden. An diese Stelle würde ich dann auch zentral die Einstellungen für alle Loggings verlegen. Auch an dieser Stelle wird dann der Grenzwert sein, unter dem die Abschattungsroutine nicht mehr aufgerufen werden soll (das ist ja momentan hartcodiert auf den Wert 500(Lux) im Code). Alle anderen Werte legt man ja eh bereits am Rollladen selber fest für wolkig/sonnig. Die Bezeichnung für anwesend/abwesend und den Namen + dem entsprechenden Reading könnte ich dann auch direkt auf diesem Dummy jeweils als Attribut ablegen.

Deinen Wunsch nach dem Override verstehe ich nicht ganz? Willst du das manuell (irgendwann) vor der Öffnung ändern oder wie hast du dir das gedacht? Dann kannst du einfach schon jetzt an dem Rollladen-Aktor das Attribut Auto_Modus_hoch auf aus setzen. Das reicht schon - auch, wenn es einen Timer gibt. Der sollte dann nicht ausgeführt werden.

Für den abendlichen Sichtschutz müsste man ein weiters at generieren - kein Ding der Unmöglichkeit. Wie hast du dir das gedacht? x Minuten vor dem kompletten Herunterfahren oder eine feste Zeit?

Ich verstehe da nichts falsch - keine Bange. Das alles ist nur so mächtig geworden, weil schon recht früh viele Ideen von Frini eingeflossen sind. Und jetzt kommt ja auch noch die Sache mit dem ROLLO-Modul auf Anfrage von MarkusHiBa hinzu. Ohne äußere Einflüsse wäre das noch lange nicht auf dem aktuellen Stand...

[Cluni]

Ich brauche Urlaub....das habe ich nicht gesehen...<davonschleich>

Wem sagst du das? Ich habe gerade mal einen halben Tag meines diesjährigen Urlaubs verbraucht....

[C0mmanda]

Uhhhh, das sind ja gleich (mehr als) drei Wünsche auf einmal - das geht nun wirklich nicht.... LOL

Sorry 

Die momentane (noch nicht öffentliche) Version ist v0.9.2.2 - es wächst und wächst.
Über levelInvers mache ich mir zwar schon Gedanken, aber das ist alles nicht so einfach, wie man sich das erstmal denkt. Es gibt da verschiede Lösungsansätze, die aber alle nicht mal eben so umzusetzen sind. Aber ich denke bereits darüber nach. Was mir vorschwebt ist folgendes: Wenn levelInvers gesetzt ist, dann müsste man theoretisch jeden gelesenen Wert umrechnen auf 100 - gelesener Wert. Auch der errechnete Wert, auf den gefahren werden soll, müsste dann auf diese Art umgerechnet werden. Dann müsste es theoretisch so sein, dass alles andere (z.B. Vergleiche in den if/ifelse-Bedingungen) so bleiben könnte. Aber das ist wie gesagt erst mal hinten angestellt, bis das ROLLO-Modul mit meinem Code läuft.

Klingt als könnte das funktionieren.

Ich habe ja bei mir einfach alle Vergleichsabfragen umgekehrt. Über den Daumen schätze ich es sind so 10-12?!
Hier einfach vorher TYPE=CUL_HM + param=levelInverse abzufragen und entsprechend das Gegenteil auszuführen ist vermutlich zu kurz und naiv von mir gedacht.
Ich weiß auch nicht was am Ende Code-sparender ist. So gut sind meine Perl-Kenntnisse sicher nicht.

Ich bin schon froh dass Ihr die Option für die Zukunft bedenkt. Danke dafür!
Die Implementierung von ROLLO hat Prio was auch absolut OK ist.

Ich kann warten, es funktioniert ja jetzt.
War nur interessiert ob mein kleines Problem es auf die Agenda geschafft hat.

Die Implementation der direkten Messwerte (also nicht über den Dummy-Umweg) habe ich auch die ganze Zeit schon im Hinterkopf. Ggf. mache ich dafür einen Dummy "Rollladen-Steuerung" oder so, in dem dann die jeweiligen Sensoren und dessen Messwert namentlich hinterlegt werden. An diese Stelle würde ich dann auch zentral die Einstellungen für alle Loggings verlegen. Auch an dieser Stelle wird dann der Grenzwert sein, unter dem die Abschattungsroutine nicht mehr aufgerufen werden soll (das ist ja momentan hartcodiert auf den Wert 500(Lux) im Code). Alle anderen Werte legt man ja eh bereits am Rollladen selber fest für wolkig/sonnig. Die Bezeichnung für anwesend/abwesend und den Namen + dem entsprechenden Reading könnte ich dann auch direkt auf diesem Dummy jeweils als Attribut ablegen.

Cool, das hört sich super an.

Deinen Wunsch nach dem Override verstehe ich nicht ganz? Willst du das manuell (irgendwann) vor der Öffnung ändern oder wie hast du dir das gedacht? Dann kannst du einfach schon jetzt an dem Rollladen-Aktor das Attribut Auto_Modus_hoch auf aus setzen. Das reicht schon - auch, wenn es einen Timer gibt. Der sollte dann nicht ausgeführt werden.

Aktuell habe ich für jeden Rolladen einen Dummy "Rolladen-Override". (Screenshot im Anhang).

Beispiel: Im Gästezimmer fahren die Rolladen regulär 30min. nach Sonnenaufgang per Timer hoch.
Heute Nacht habe ich jedoch einen Gast der dort schläft. Also stelle ich den Override auf "Skip" und am nächsten Tag wird der Timer ausgesetzt.

Also ja, ich will/muss den Override immer am Abend vorher aktivieren wenn ich ihn denn benötige. (Kann dies aber bequem recht schnell erledigen, z.B. mittels TabletUI die ich nutze).

Am Übernächsten Tag fährt der Rolladen dann wieder normal nach Zeitplan.
Ich muss nicht daran denken den Timer wieder zu aktivieren oder etwas umzustellen.
(Zugegeben, bleibt der Gast länger als einen Tag muss ich wieder daran denken zu "skippen").

Den Code dazu habe ich hier aus dem Forum, bei Interesse kann ich Ihn dir gern schicken.

Natürlich ginge das auch über das verstellen der Attribute, das finde ich nur nicht ganz "sauber".

Essentiell ist dieser Override auch nicht wirklich, ich bin es halt nur gewohnt ihn zu haben.
Es ist ein "Luxus" den ich vielleicht 10x/Jahr benutze.

Für den abendlichen Sichtschutz müsste man ein weiters at generieren - kein Ding der Unmöglichkeit. Wie hast du dir das gedacht? x Minuten vor dem kompletten Herunterfahren oder eine feste Zeit?

Ich orientiere mich hier am Sonnenuntergang, vor allem im Winter.
Zum Beispiel 30min. vor Sonnenuntergang (Dämmerung) fahren die Rolladen auf 60%, 60min. nach Sonnenuntergang dann komplett herunter.

Die Schliessen-Zeit ist in eurer Steuerung ja konfigurierbar (Astro, Zeit).
Hier wäre ich persönlich mit einem festen Vorlauf bereits glücklich.
Ich sage mal: attr Automatik_runter_Zeit_Vorlauf 30min.
Die 60min. nach Sonnenuntergang könnte man ja mittels Offset erreichen den es schon gibt.

Da fällt mir ein: Bei der Astro-Funktion in eurer Steuerung ist sunset("REAL") hart-gecoded. Beim Sonnenuntergang war mir das gestern z.B. deutlich zu früh (21:30Uhr), weshalb ich beim abendlichen Schliessen dies auf "CIVIL" geändert habe (ca. 22:35Uhr). Also evtl. auch eine Option die konfigurierbar sein könnte.

Ich verstehe da nichts falsch - keine Bange. Das alles ist nur so mächtig geworden, weil schon recht früh viele Ideen von Frini eingeflossen sind. Und jetzt kommt ja auch noch die Sache mit dem ROLLO-Modul auf Anfrage von MarkusHiBa hinzu. Ohne äußere Einflüsse wäre das noch lange nicht auf dem aktuellen Stand...

Dann ist ja gut. 
Ich finde es auch jetzt schon Mega was Ihr da gebaut habt.
Ich grübel immer wieder seit über einem Jahr darüber nach wie ich solche eine Steuerung realisieren kann, habe mich da aber nie heran gewagt.
Und nun kann eure Steuerung bereits meine zusammengebastelten Konstrukte aus subs, weekdaytimern, notifys und dummies komplett ablösen und ich habe dazu noch eine sehr gute und durchdachte Abschattung (Die habe ich bisher nie hinbekommen).

Also danke dafür und weiter so!

grtz
CmdA

[kjmEjfu]

Cool, das hört sich super an.

Aktuell habe ich für jeden Rolladen einen Dummy "Rolladen-Override". (Screenshot im Anhang).

Beispiel: Im Gästezimmer fahren die Rolladen regulär 30min. nach Sonnenaufgang per Timer hoch.
Heute Nacht habe ich jedoch einen Gast der dort schläft. Also stelle ich den Override auf "Skip" und am nächsten Tag wird der Timer ausgesetzt.

Also ja, ich will/muss den Override immer am Abend vorher aktivieren wenn ich ihn denn benötige. (Kann dies aber bequem recht schnell erledigen, z.B. mittels TabletUI die ich nutze).

Am Übernächsten Tag fährt der Rolladen dann wieder normal nach Zeitplan.
Ich muss nicht daran denken den Timer wieder zu aktivieren oder etwas umzustellen.
(Zugegeben, bleibt der Gast länger als einen Tag muss ich wieder daran denken zu "skippen").

vielleicht wäre es ja hier eine Option, wenn man den Rolladen an einen bestimmten Resident/Guest hängen könnte.
So nach dem Motto: wenn Resident/Guest nicht abwesend, dann fahre hoch um x Uhr. wenn der Resident/Guest anwesend ist, dann fahre hoch um y Uhr.
Somit müsste man sich nur um das entsprechende Resident/Guest-Device kümmern und nicht u.U. eine größere Anzahl von Rollos (je nach Größe und Anzahl der Gästezimmer) direkt übersteuern.
Würde aber natürlich bedeuten, dass man wieder zusätzliche Attribute an jedes Rollo hängen muss (zugehörte(r) Resident/Guest-Device(s), abweichende Zeit hoch, abweichende Zeit runter).

Und den Guest kann man ja entweder automatisch erkennen (analog zu nem Resident) oder halt manuell einfach umsetzen.

Just my 2 cent 

[Cluni]

Das mit dem Gastmodus ist auch nicht so einfach, wie ich erst gedacht habe - folgende Szenarien:

1) Am Abend schalte ich den Gastmodus ein. Bei der Berechnung in der Nacht um 3:05Uhr wird dies berücksichtigt und der korrekte (Gast-)Zeitpunkt statt dem berechneten eingestellt. Alles perfekt und kein Problem.

2) Die Timer wurden um 3.05Uhr berechnet und ich komme mit einem Gast um sagen wir mal 4Uhr heim, schalte den Gastmodus auf skip oder auf sagen wir 11Uhr. Kommt nun der normale Timer, so kann ich die Vorgabe berücksichtigen: Bei skip mache ich gar nichts - ist ein späterer Zeitpunkt ausgewählt, so erzeuge ich einfach ein at für diesen späteren Zeitpunkt. Wieder alles perfekt und kein Problem.

3) Die Timer wurden um 3.05Uhr berechnet und ich komme mit einem Gast wieder um 4Uhr heim, schalte den Gastmodus auf 7:00Uhr (ok - ist ein blödes Beispiel, aber könnte ja so sein) - der normale, berechnete Zeitpunkt wäre jedoch z.B. 8:23Uhr. In diesem Fall müsste auf das Einstellen des neuen Modi eine Aktion folgen - entweder muss die Zeit des at manipuliert werden, oder es müsste ein weiteres at angelegt werden und das andere entweder gelöscht oder halt so gelassen werden. Nicht ganz so trivial....

Wenn man den Rollladen später oder gar nicht fahren will, ist es also kein Problem. Will man aber den Rollladen zu einem früheren Zeitpunkt sozusagen als Wecker benutzen, dann müsste da noch etwas drum herum entwickelt werden. Sollten wir nun sagen, dass die beim Guestmode eingestellte Zeit die FRÜHESTE Öffnungszeit ist, dann wäre das (mit Vorbehalt gesagt) keine allzu große Sache und wäre nicht so kompliziert zu integrieren.

Wie wäre das dann mit der Zeiteinstellung? Könnte man den Gastmodus global im (kommenden) großen Dummy für die Rollladensteuerung mit einer Zeit für alle (Gästezimmer-) Rollladen aktivieren, oder müsste jedes Gästezimmer wieder eine eigene Zeitangabe haben? Ich fände ersteres besser. Am Rollladenaktor würde ich nur ein Attribut Gästezimmer ja/nein vorsehen?! In dem globalen Dummy kommt dann auch die Möglichkeit der Angabe eines Guest-Device und dessen Meldungen für an- und abwesend. Wird kein Guest-Device angegeben, dann würde einfach auf die Zeiteinstellung geschaut...