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

[CoolTux]

Rollo macht lediglich eine manuelle Steuerung. Ist mehr so eine Art Übersetzer bei Befehlen wie stop oder start als Set Befehl. Ausserdem macht es glaube eine Laufzeitberechnung.

ASC automatisiert auf Basis von Ereignissen.
Ich habe eben noch mit Bernd (Cluni) telefoniert. Wir haben erörtert welche Möglichkeiten es in Deinem Fall gibt.
Ich muss gestehen daß Du derzeit der einzige bist wo man so starke Änderungen im Modul machen müsste. Der Aufwand ist es aktuell nicht Wert, da haben andere Dinge Vorrang. Zum Beispiel Raffstores Steuerung.

Tut mir leid.

[ch.eick]

Okay, danke für Eure prompte Diskussion

Ich denke diese Art von Änderung/Korrektur wäre auch sicherlich besser im EnOcean Modul aufgehoben, da es ja eigentlich eine Fehler oder Ungenauigkeitskorrektur ist. Ich habe dort auch schon mal angefragt. Die Positionen 0 und 100 sollten schon exakt sein.

Vielen dank auch für die Differenzierung von Rollo zu ASC.

Gruß
   Christian

[JHo]

Hallo Christian,

probiere doch Rollo einfach mal aus. Das funktioniert ja zusätzlich zur generischen Steuerung über das EnOcean-Modul. Eingerichtet ist es wirklich schnell.
Ich hatte ganz ähnliche Probleme mit meinen 3 Uniroll-Gurtwicklern und bin mit readingsproxy und co nicht warm geworden. ASC triggert jetzt für diese Rolläden das Rollo-Modul, und das steuert das normale Uniroll-Modul entsprechend an. Funktioniert, ist transparent und ich kann natürlich auch noch manuell über das Uniroll-Modul eingreifen, was dann wiederum auch das Rollo-Modul und ASC mitbekommen.

Grüße,
Jan

[msfox]

AutoShuttersControl bring FHEM komplett zum Absturz:

- Ich habe via define asc AutoShutterControl das Device angelegt.
- Bei einem Shutter HM485 ASC auf 2 gestellt.
- Wenn ich jetzt beim ASC-Device die Auswahlbox = scanForShutters mit SET bestätige, liefert der Browser einen Fehler, dass der FHEM-Servcer nicht erreichbar ist.

Im Log steht dazu:
Undefined subroutine &main::delFromDevAttrList called at ./FHEM/73_AutoShuttersControl.pm line 584.

Ich muss FHEM via ssh manuell neu starten.

"Version" von FHEM liefert:
73_AutoShuttersControl.pm 18753 2019-02-27 20:34:46Z CoolTux

Das letzte Commit in Github stammt auch vom 27.02.2019. Sollte beim mir also aktuell sein.
----------
wenn ich SET asc scanForShutters im Commando-Feld eintrage, kommt der Fehler:
"Please define asc first "
Aber das device heißt doch "asc", darüber konnte ich doch den Absturz produzieren.

[CoolTux]

AutoShuttersControl bring FHEM komplett zum Absturz:

- Ich habe via define asc AutoShutterControl das Device angelegt.
- Bei einem Shutter HM485 ASC auf 2 gestellt.
- Wenn ich jetzt beim ASC-Device die Auswahlbox = scanForShutters mit SET bestätige, liefert der Browser einen Fehler, dass der FHEM-Servcer nicht erreichbar ist.

Im Log steht dazu:
Undefined subroutine &main::delFromDevAttrList called at ./FHEM/73_AutoShuttersControl.pm line 584.

Ich muss FHEM via ssh manuell neu starten.

"Version" von FHEM liefert:
73_AutoShuttersControl.pm 18753 2019-02-27 20:34:46Z CoolTux

Das letzte Commit in Github stammt auch vom 27.02.2019. Sollte beim mir also aktuell sein.
----------
wenn ich SET asc scanForShutters im Commando-Feld eintrage, kommt der Fehler:
"Please define asc first "
Aber das device heißt doch "asc", darüber konnte ich doch den Absturz produzieren.

Lass mich raten. Du aktualisierst nur einzelne Module und nie das ganze FHEM. Richtig?
Deine fhem.pl ist Uralt. Locker ein halbes Jahr

[Beta-User]

Wegen des "speziellen" Kommandos:
Das  könnte auch mit einer angepaßte eventMap (am Rollladendevice) klappen. Ungetestet:

Code Auswählen Erweitern

{ usr=>{pct.0=>'opens',pct.100=>'closes'} }
Könnte man ggf. "verfeinern", indem man "exotischere" Werte wie 0.1 und 99.9 nimmt.

@CoolTux:
Da scheinbar mehrere Leute damit ein Problem haben, wäre evtl. zu überlegen, ob wir das nicht auch ähnlich direkt im Modul abfackeln könnten. Eventuell ist es weniger Arbeit wie gedacht, und diese tendenziell fehleranfälligen Umwege via ROLLO etc. würde man sich sparen können...

[CoolTux]

Hatte ich die Nacht auch noch mal drüber nach gedacht. Ich behalte es mal im Auge.

[Alcamar]

Es ist wieder Freitag. 
Ich finde keinen Grund weshalb die Rollos  planmäßig hochfahren und dann sporadisch wieder runter. Immer nur freitags.
ASC_ShuttersLastDrive manual
Wo kann ich noch den Auslöser für die Geisterfahrten suchen?

[CoolTux]

Sind alle gefahren? Kann es sein das Du da noch eine andere automatik hast die läuft?

[Alcamar]

Alle fahren regulät und in einem Zimmer fahren die Rollos dann Sonderfahrten. Warum nur freitags verstehe ich nicht.
Ich kann keine andere Logik erkennen, die diese Rollos steuert. Die Steuerung vor ASC war alle zur gleichen Uhrzeit (hoch oder runter). Jetzt fahren einzelne aber völlig autark. Die alte Steuerung habe ich mit Einführung von ASC deaktivert.

[CoolTux]

ASC_ShuttersLastDrive manual

bedeutet das eine Fahrt von extern angestoßen wurde. ASC hat hier definitiv keinen Fahrbefehl gegeben.
Da ich die Tag die aktuelle Developer Version als stabil ausgebe und sie somit per FHEM Udate kommt kann man da noch mal expliziert debug aktivieren um zu sehen was genau passiert.

[Alcamar]

d.h. ich warte auf das Update?
Wie kann ich das debugging aktivieren? Oder ist es einfach per verbose zu ändern?
Ich werde nochmal mit einem grep alle Dateien durchstöbern, die die betroffenen Rollos erwähnen. Ich kann mir aktuell trotzdem nicht erklären, warum sich dieses Verhalten nur an einem einzigen Tag pro Woche zeigt.

[CoolTux]

Das debug attribut gibt es erst mit der neuen 0.6.x Version von ASC

[msfox]

Lass mich raten. Du aktualisierst nur einzelne Module und nie das ganze FHEM. Richtig?
Deine fhem.pl ist Uralt. Locker ein halbes Jahr

Ah, ok fiel mir dann auch ein. Ich hatte gestern auch FHEM aktualisiert. Dabei lief aber mein Homematic-Modul nicht mehr (irgend ein perl-modul wurde nicht gefunden.) Dann hab ich ein Restore gemacht und nur AutoShuttersControl aktualisiert.
Werd mich heut nochmal an FHEM-Komplett-Update versuchen.

[diki]

Hallo zusammen,

@ch.eick

Hast Du eine Empfehlung für richtige Kontakte, eventuell mit EnOcean ?

Ich habe an allen Fenstern diese hier: https://www.hoppe.com/de/de/fenstergriffe/hoppe-innovationen/secusignal
Basieren auf enOcean und funktionieren bei mir einwandfrei.

Nun noch zwei Fragen zum Modul:

Beim automatischen Öffnen des Rollladen per twostate Fensterkontakt auf die ASC_Ventilate_Pos = 100 am Tag, fährt der Rollladen nach Schließen des Fensterkontaktes nicht wieder auf die letzte Position zurück. Bei ASC_Ventilate_Pos = 99 funktioniert das. Ich habe eine Terrassentür, da muss ich auf 100 % (also ganz auf, ASC =2) fahren. Gibt es da Lösungsansätze?

Im Beschattungsmodus und nach dem Öffnen des Rollladen per twostate Fensterkontakt fährt der Rollladen nach einer zufälligen Zeit (sicher wenn das Modul die Notwendigkeit der Beschattung überprüft) wieder nach unten. Wie kann ich das verhindern, solange der Fensterkontakt auf offen steht?

Danke, Dirk