Neues Modul: Rolladensteuerung

[KernSani]

Hallo zusammen,
ich setze bei mir einen Raspberry PI3 und eine HomeMatic CCU2 ein, mit der ich die Rollos schon AUF/AB/STOP steuern kann. Nun interessiere ich mich für das genannte Rollo-Modul. Ist es möglich, das Modul ausschliesslich mit der CCU2 und dem Raspberry einzusetzen ? Wenn ja, kann mir da jemand Hilfestellung geben, da ich in diesem Thema noch nicht so wirklich bewandert bin ?
Vielen Dank!

Was meinst du mit nur einem Raspberry und der CCU2? Das ROLLO Modul geht davon aus, dass du deine Rollläden bereits in FHEM eingebunden hast und die Bedienung in FHEM grundsätzlich funktioniert. Wenn das der Fall ist, dann ist es wahrschenilich am Besten, wenn du dich einfach mal ROLLO Device definierst und versuchst einen Rollladen anzubinden (siehe auch https://wiki.fhem.de/wiki/ROLLO). Wenn dabei Fragen oder Probleme auftreten poste ein "list" des ROLLO devices und wir versuchen das gemeinsam hinzubekommen.

[redstar2003]

Der Punkt ist, ich setze kein FHEM ein (ich weiss, ist dann hier das etwas falsche Forum). Ich habe ausschließlich einen Raspberry PI und eine HomeMatic CCU2. Mit einer Anleitung aus diesem Forum habe ich meine Fernotron 2411 über die genannten Geräte steuerbar gemacht. Meine Frage wäre (auch wenn es kein FHEM ist), kann man das Rollo Modul irgendwie auf die HomeMatic CCU2 adaptieren ?
Vielen Dank.

[KernSani]

Ich setze Homematic ein, aber keine CCU FHEM und auch FHEM Module sind in Perl geschrieben, ich vermute damit kann die CCU nicht viel anfangen. FHEM Module auch das ROLLO Modul sind speziell auf FHEM zugeschnittene "Plugins" die auf FHEM Basisfunktionalität aufsetzen. Mit anderen Worten: Man kann sowas vielleicht irgendwie auf der CCU nachbauen, aber ich habe keine Ahnung wie und sicher nicht mit geringem Aufwand.

[stefan-dd]

Kann man die Bezeichnungen irgendwie ändern?

webCmd     open:closed:half:stop:position

Deutsch wäre schon nicht schlecht, aber wie?

[KernSani]

Kann man die Bezeichnungen irgendwie ändern?

webCmd     open:closed:half:stop:position

Das webCmd Attribut macht nichts anderes als "set" Befehle auf das Frontend zu bringen. Die Set-Befehle sind in ROLLO, wie in FHEM üblich auf englisch... Durch das Attribut cmdIcon, werden für die webCmds icons angezeigt... Ist das bei dir nicht der Fall?

[KernSani]

Frage in die Runde:

Ich habe die Idee, das ROLLO Modul um eine einfache "Fenster offen"-Steuerung zu erweitern:
* Neues Attribut "blockNtf": das eine regexp entgegen nimmt, wie z.B. "WoziFenster:open"
* Neues Attribut "unblockNtf": das eine regexp entgegen nimmt, wie z.B. "WoziFenster:closed"
* Bei Eintreten des jeweiligen Ereignisses würde das ROLLO-Device auf blocked bzw. unblocked gesetzt, damit ließe sich eine sehr einfache Steuerung realisieren ohne haufenweise notifies/DOIFs zu erstellen.

Bestünde daran Interesse? Hättet ihr zusätzliche Anforderungen/Ideen?


 

[Frank_Huber]

Würde da evtl noch nen Schritt weiter gehen.
Fenster auf: rollo hoch, dann blocked
Fenster zu: rollo geht auf gesetzten Status, dann unblock.

Würde aber voraussetzen dass man Positionen setzen kann wenn er Blocked ist.
Wäre ideal für Terassentüren...


Gesendet von meinem S3_32 mit Tapatalk

[KernSani]

Würde aber voraussetzen dass man Positionen setzen kann wenn er Blocked ist.
Wäre ideal für Terassentüren...

In der aktuellen ROLLO Version (im master branch auf Github) ist es möglich die Position zu setzen, während der ROLLO blocked ist. In der Version im developer branch ist das ausgebaut, da es aus meiner Sicht zu ungewünschten Nebeneffekten führen kann. Meine Rollläden werden z.B. erst runtergefahren, wenn die Terrassentür länger als 5 Minuten zu ist). Ich denke ich kann da noch ein Attribut einbauen um das zu steuern.

[redstar2003]

Hallo zusammen,
ich habe es jetzt geschafft meine in FHEM integrierten Rollos per ioBroker aus der HomeMatic CCU2 zu steuern. Allerdings habe ich noch ein kleines Problem. IN FHEM bedeutet Postion 100% geschlossen, in der CCU2 bedeutet 100% geöffnet. Kann ich das Rollo-Modul so umändern, dass 100% auch geöffnet (und natürlich noch die weiteren folgenden Werte anpassen) ?

Vielen Dank!

[KernSani]

Code Auswählen Erweitern

[quote author=redstar2003 link=topic=47202.msg637632#msg637632 date=1495224448]
IN FHEM bedeutet Postion 100% geschlossen, in der CCU2 bedeutet 100% geöffnet. Kann ich das Rollo-Modul so umändern, dass 100% auch geöffnet (und natürlich noch die weiteren folgenden Werte anpassen) ?
[/quote]
Ist mir zwar neu dass HomeMatic sich so verhält, aber gut... ROLLO hat ein Attribut "type" - wenn das auf "HomeKit" gesetzt ist, werden 100% und 0% vertauscht (und alles andere).
attr <myROLLO> type HomeKit

[stefan7]

Hallo,

dankeschön erst mal für das Modul.
Ich habe noch ein Verständnisproblem mit den Parametern.
Ist die Zeit für "excessBottom" bzw. "excessTop" in "secondsDown" bzw. "secondsUp" bereits enthalten oder muss diese hinzugerechnet werden?
Und sind auch Kommazahlen möglich? Eine Sekunde (Ganzzahl) bringt eine große Ungenauigkeit rein, die sich bis auf 5 Sekunden = ca. 20% hochaddiert.

Ich mache mal ein Beispiel zur Verdeutlichung.

Runterfahrzeit von Oberkante Fensterrahmen bis Oberkante Glasscheibe: 0,5 Sekunden
Runterfahrzeit von Oberkante Glasscheibe bis Unterkante Glasscheibe: 15,1 Sekunden
Runterfahrzeit von Unterkante Glasscheibe bis Unterkante Fensterrahmen: 3,8 Sekunden
Hochfahrzeit von Unterkante Fensterrahmen bis Unterkante Glasscheibe: 4,3 Sekunden
Hochfahrzeit von Unterkante Glasscheibe bis Oberkante Glasscheibe: 16,2 Sekunden
Hochfahrzeit von Oberkante  Glasscheibe bis Oberkante Fensterrahmen: 0,6 Sekunden
Die Ansprechzeit von meinem Motor ist ca. 300 ms. Kann ich reactionTime = 0.3 setzen oder geht wirklich nur Ganzzahl?

Was müsste ich hier nehmen für die wesentlichen Parameter?

secondsDown 0,5+15,1+3,8 = 19,4 ? ODER nur 15,1 (ohne excess)
secondsUp 0,6+16,2+4,3 = 21,1 ODER nur 16,2 (ohne excess)
excessTop 0,5 (von oben nach unten) oder 0,6 (von unten nach oben)?
excessBottom 3,8 (von oben nach unten) oder 4,3 (von unten nach oben)?
reactionTime 0,3 ?

Ich hab verschiedene Varianten versucht, aber das ganze ist relativ ungenau und ich bekomme je nach Anzahl der angefahrenen Positionen einen Fehler bis ca. 20% der Fensterfläche.

Danke für Eure Hinweise. 

[stefan-dd]

Das gleiche Problem habe ich auch. Man bekommt es nicht perfekt hin.
Die Ursache ist, das der Rollladen mit einer höheren Geschwindigkeit beginnt und nach unten immer langsamer wird.
Ist der Rollladen voll aufgewickelt entspricht z.B. eine Motorumdrehung 40cm. Ist er fast abgewickelt nur noch 30cm. Die Maße sind jetzt nur Schätzungen.
Dies müsste man bei der Berechnung des prozentualen Weges mit berücksichtigen. Mit  "excessBottom" bzw. "excessTop" hat das nichts zu tun, das sind die versteckten Wege auf die Laufzeit bezogen.
Hat man Mitte perfekt, stimmt 90% nicht, stimmt 90%, passt die Mitte nicht.
Das prozentuale Verhältnis darf nicht linear sein. Vielleicht könnte man einen Korrekturfaktor mit einbauen?

[KernSani]

@stefan7


Grundsätzlich ist es so, dass die Werte aufaddiert werden (also wenn der Rollo auf 0 = open ist und auf 100 gefahren werden soll, wird berechnet sich die Gesamtfahrzeit aus reactionTime + excessTop + secondsUp + excessBottom)


@stefan-dd


Keine schlechter Gedanke... ich mache mir mal Gedanken, wie man das praktikabel umsetzen könnte. Wenn du Ideen hast: Immer her damit...

[stefan-dd]

Zu meiner Idee...

man müsste die Werte der Fahrtzeit von dem Weg trennen.
Also am Beginn: 6% der Zeit entspricht 10% vom Weg
Kurz vorm schließen: 15% der Zeit entspricht 10% vom Weg

Oder man lässt den Nutzer über die Zeiten zwischen den 10% Schritten entscheiden. z.B. über zusätzliche optionale Attribute
Man könnte Werte vorgeben, die verändert werden können.

Die  Zeiten "excessBottom" bzw. "excessTop" könnte man unverändert lassen. Oder man rechnet sie dann in den ersten und letzten Schritt mit ein. Macht es dann vielleicht wieder etwas einfacher, der Übersicht wegen.

z.B. so
  0-10% -> 4s
10-20% -> 1.6s
20-30% -> 1.8s
30-40% -> 2.0s
....
90-100% -> 4s

[KernSani]

Zu meiner Idee...

man müsste die Werte der Fahrtzeit von dem Weg trennen.
Also am Beginn: 6% der Zeit entspricht 10% vom Weg
Kurz vorm schließen: 15% der Zeit entspricht 10% vom Weg

Oder man lässt den Nutzer über die Zeiten zwischen den 10% Schritten entscheiden. z.B. über zusätzliche optionale Attribute
Man könnte Werte vorgeben, die verändert werden können.

Die  Zeiten "excessBottom" bzw. "excessTop" könnte man unverändert lassen. Oder man rechnet sie dann in den ersten und letzten Schritt mit ein. Macht es dann vielleicht wieder etwas einfacher, der Übersicht wegen.

z.B. so
  0-10% -> 4s
10-20% -> 1.6s
20-30% -> 1.8s
30-40% -> 2.0s
....
90-100% -> 4s

Hmmm, das macht es recht umständlich für den Anwender... Ich dachte mehr ein einen Faktor, angenommen die ersten 10% brauchen 1 Sekunde, die letzten 10% 2 Sekunden, dann wäre der Faktor 2, alles zwischendrin würde linear hochgerechnet... ExcessTop/Bottom würde ich davon ausnehmen, da das ja ein absolute Zahl ist.