[73_AutoShuttersControl.pm] Rolllos automatisiert steuern - Version 0.6.x

[CoolTux]

Meinst Du vielleicht
98_jarolift.pm


oder das hier

14_SD_Jaro.pm

[Beta-User]

Was auch immer das Jaro Modul ist. Aber ich denke am einfachsten ist es in diesem Modul eine vernünftige Steuerung zu implementieren.

Vermutlich ist es effektiv halt nur ein Hilfsmittel, um den (fast) dummen Motor anzuwerfen (bzw. zu stoppen). Es scheint nur eine Option zu geben, um sich eine Zwischenposition zu "merken", ansonsten ist es scheinbar eigentlich nichts anderes als mehrere "ota" jeweils paarig geschaltete Relais.
Der Aufwand dürfte sich nicht lohnen, die in ROLLO implementierten Timer-Funktionen in ein eigenes Modul zu doppeln...

[kjmEjfu]

Vielleicht sollte man in groß und fett in die Voraussetzungen für ASC schreiben, dass steuerbare Rollos (im Sinne von "fahre x% an") verfügbar sein müssen, weil ASC diese Logik selber nicht zur Verfügung stellt 

[Loredo]

Gerade geschaut. In der Tat habe ich die feinere Auswertung nur für Astro und Brightness genommen. Ich fixe das die Tage.

Ich nutze hier Brightness und habe trotzdem das gleiche Verhalten, dass einige(!) Rollos (komischerweise nicht alle?!) beim Wechsel von "awoken" auf "home" gerade wieder runter gefahren ist. Falls du also einen Fehler nur bei festen Zeiten vermutest, stimmt das vermutlich nicht.

[Loredo]

Zur Info: Im Wiki habe ich die ReadingsGroup für Level mal angepaßt, so dass die auch mit den nicht vorbelegten Attributen klarkommt.

Sollte ich dann auch noch Änderungen vornehmen können, so wie vorher? Aktuell gibt es nur noch eine Anzeige (ich kenne readingsGroup nicht weiter).

IsWE() greift auf state zu (den Reading-Wert, nicht das Internal STATE!). Wie in dem von CoolTux verlinkten Beitrag erläutert, gab es eine Änderung bei "$we", das stateFormat hilft also nicht mehr weiter (das war früher in der Tat anders). Wenn du "state" bei dem calview nicht manipulieren kannst/willst, brauchst du ein anderes device, Lösungen haben wir einige in den Vorthreads diskutiert.

Ich habe das auch gerade bei mir eingerichtet, allerdings scheint IsWe() und $we korrekt auf 1 zu sein, obwohl das CALVIEW Device nur das Internal STATE auf "yes" hat und das Reading state einen anderen Wert hat. Oder tritt das Problem nur auf, wenn es sich um "none" handelt? Das ist mir ehrlich gesagt beim lesen des erwähnten Threads nicht klar geworden, wo da die eigentliche Änderung lag...

[Loredo]

Vielleicht sollte man in groß und fett in die Voraussetzungen für ASC schreiben, dass steuerbare Rollos (im Sinne von "fahre x% an") verfügbar sein müssen, weil ASC diese Logik selber nicht zur Verfügung stellt 

Finde ich eigentlich gar nicht, der Name allein sagt doch bereits, dass es um Automatisierung geht und das beinhaltet nicht die eigentliche Ansteuerung von etwas.

[CoolTux]

Sollte ich dann auch noch Änderungen vornehmen können, so wie vorher? Aktuell gibt es nur noch eine Anzeige (ich kenne readingsGroup nicht weiter).

Ich habe das auch gerade bei mir eingerichtet, allerdings scheint IsWe() und $we korrekt auf 1 zu sein, obwohl das CALVIEW Device nur das Internal STATE auf "yes" hat und das Reading state einen anderen Wert hat. Oder tritt das Problem nur auf, wenn es sich um "none" handelt? Das ist mir ehrlich gesagt beim lesen des erwähnten Threads nicht klar geworden, wo da die eigentliche Änderung lag...

Gibt es Unterschiede in der Konfiguration der Rolllos?

[Beta-User]

Mit der ReadingsGroup kann man dann auch wieder die Werte einstellen. Der einzige negative Seiteneffekt, den ich bisher gesehen habe: Wenn undef, wird der erste Wert aus der Auswahlliste angezeigt (also idR "0").
Oder ist das bei dir anders?

Die Änderung ist die, dass bisher $we wahr war, wenn Value() was anderes als "none" zurückgab (=> Zugriff auf Internal STATE, das in der Regel aus dem Reading "state" abgeleitet wird). Jetzt muß das Reading "state" was anderes als "none" sein...
Das hier mit dem CalView ist der 3. Fall, bei dem das überhaupt einen Unterschied macht .

[CoolTux]

Die Öffnungszeit der Rolläden sind in der Woche auf 05.45Uhr (zeitgesteurt) eingestellt. Zu dieser Zeit fahren die Rolläden ordnungsgemäß hoch. Anschließend steht als Öffnungszeit (NextDriveUp) die Uhrzeit vom Wochenende (07:30) Uhr aber für den heutigen Tag im ASC-Modul. Findet nun ein Wechsel des Status des Residentsmodul von asleep nach awoken (bzw. home) statt, fahren die Rollos wieder runter. Die Rollos fahren danach zur, für das Wochenende vorgegebenen Öffnungszeit, wieder hoch. Erst jetzt steht im ASC-Modul die Öffnungszeit für das Wochenende mit Datum vom morgigen Tag.

Gruß
Stefan

Habe ich gerade gefixt. Ich denke das ich für morgen früh ein Update klar mache. Kannst aber auch schon aus dem Github Devel branch laden wenn Du magst.

[D3ltorohd]

Genau das ist diese Modul hier

https://github.com/HomeAutoUser/Jaro

Der Hersteller selber hat dort leider nur Funkempfänger verbaut, das wars auch schon. Dank des Signalduinos und diesem Modul, kann ich sie wenigstens ansteuern.

Aber genau dafür sollte doch FHEM und dessen Module da sein um aus diesem dummen Motor einen schlauen zu machen zumindest, Softwareseitig.

[nils_]

Aber genau dafür sollte doch FHEM und dessen Module da sein um aus diesem dummen Motor einen schlauen zu machen zumindest, Softwareseitig.

na das geht doch auch.... erstmal mit dem ROLLO Modul den ersten Schritt machen zur Ansteuerung. Und danach die Automatisierung mit ASC.

[CoolTux]

Oder HomeAutoUser bitten sein Modul zu erweitern. So das nicht nur feste Endpunkte angesteuert werden können sondern auch zwischen Positionen. Dies kann man am besten über Zeitfahren machen.
Also wie lange brauch das Rollo um von ganz unten nach ganz oben zu fahren und wie lange um von ganz oben nach ganz unten. Damit kann man dann in Prozent Schritte fahren.
Aber der Author des Modules muss es halt ein bauen.

[Typ1er]

Ich frage jetzt nochmal, wäre es möglich den Rollladen bei Auf- oder Abfahrt. Mal mit on oder off zu steuern?

Beim dim befehlen kann es sich durch Temperaturschwankungen und der dadurch unterschiedlichen Laufzeiten leichte Verschiebungen geben. Die sich über mehre Tage addieren. Mit On oder Off würde er dann wieder seine richtige Ausgangslage bekommen, die Position ist dann wieder ganz auf null.

Bemerken tue ich den Effekt am meisten an den Jalousien, da hier Lamellenbewegungen auch nur Fahrbefehle ausgeführt werden. Die großen Rollladen an den r aumhohen Fenstern stehen z.B. momentan offen auf 97%. Die 99% würden Sie er's mit dem off Befehl erreichen.

[Beta-User]

Ich frage jetzt nochmal, wäre es möglich den Rollladen bei Auf- oder Abfahrt. Mal mit on oder off zu steuern?

Hast du das mal mit der eventMap ("{usr =>...") versucht? Hatte dazu neulich was vorgeschlagen, aber keine Rückmeldung dazu erhalten.

Bitte Fragen, wenn das zu kryptisch gewesen sein sollte, aber bitte erst den Ursprungsbeitrag suchen und testen wie dort vorgeschlagen!

[Loredo]

Oder ist das bei dir anders?

Passt, hatte die Newlines beim Copy&Paste nicht entfernt.

Die Änderung ist die, dass bisher $we wahr war, wenn Value() was anderes als "none" zurückgab (=> Zugriff auf Internal STATE, das in der Regel aus dem Reading "state" abgeleitet wird). Jetzt muß das Reading "state" was anderes als "none" sein...
Das hier mit dem CalView ist der 3. Fall, bei dem das überhaupt einen Unterschied macht .

Puh, ziemlich umständlich 3 Geräte für nur eine Kleinigkeit zu haben... naja, hab jetzt Calendar, CALVIEW und readingsProxy kombiniert. Letzteres Device habe ich dann ins globale holiday2we Attribut mit aufgenommen. Hier für Interessierte die Definition des readingsProxy Device:

Code Auswählen Erweitern


defmod rr_Julian_vacation readingsProxy rr_Julian_vacationView:c-today
attr rr_Julian_vacation valueFn {\
fhem "setreading rr_Julian_vacation tomorrow ".(ReadingsVal($DEVICE,"c-tomorrow",0) > 0 ? "yes":"none");;\
return $VALUE > 0 ? "yes":"none";;\
}


Die Verarbeitungsreihenfolge ist also Calendar > CALVIEW > readingsProxy (rr_Julian_vacationView ist also mein CALVIEW Device, in holiday2we habe ich rr_Julian_vacation hinzugefügt, also das readingsProxy Device).