[73_AutoShuttersControl.pm] Rolllos automatisiert steuern - Version 0.10

[FFHEM]

Hallo CoolTux,
der Regenschutz bereitet bei mir noch ein Problem; ASC fährt den Rolladen morgens hoch, obwohl es regnet.
Kann man so nachstellen:

1. Regenschutz muss auf "on" stehen
2. Rolladen ist unten und soll bspw. um 07:00 Uhr hochfahren (Tagfahrt), es sei jetzt 06:55 Uhr
3. Regensensor meldet Regen
4. Um 07:00 Uhr fährt der Rolladen hoch, obwohl es noch regnet!

Eigentlich soll der Rolladen ja wegen des Regens solange unten bleiben, bis das Regensignal nicht mehr da ist.
Ich denke mal, da ist ein List nicht nötig!?

Gruß,
Friedhelm

[CoolTux]

Hallo Friedhelm,

Interessant wäre hier zu wissen wie der Status intern zum Zeitpunkt stand.

Code Auswählen Erweitern

{ ascAPIget('RainProtectionStatus','ROLLONAME') }

Bei einem Protected hätte er nicht fahren dürfen.

[D3ltorohd]

Hm interessante Sache mit dem Roommate. Aber so wie es momentan läuft ist es eigentlich super. Da sie meist zur gleichen Zeit ins Bett gehen unter der Woche klappt das prima mit dem Rollo, auch am WE fährt er ja später.

Aber mal sehen, ist ja überall ne Alexa, dann bräuchte ich keinen Schalter.

[FFHEM]

Hallo Friedhelm,

Interessant wäre hier zu wissen wie der Status intern zum Zeitpunkt stand.

Code Auswählen Erweitern

{ ascAPIget('RainProtectionStatus','ROLLONAME') }
Bei einem Protected hätte er nicht fahren dürfen.

Du bist dem Fehler auf der Spur:
Es ist jetzt zwar keine Morgenfahrt, aber das Regensignal scheint nachts nicht anzukommen.

Nach der Nachtfahrt heute um 18:00 Uhr habe ich einmal Regen simuliert:

Vor Nachtfahrt: kein Regen, "unprotected"
18:00 Uhr Runterfahrt
18:01 Uhr Regensimulation, liefert "unprotected"

Gerne kann ich das morgen früh noch einmal für die Morgenauffahrt prüfen.

[CoolTux]

Du bist dem Fehler auf der Spur:
Es ist jetzt zwar keine Morgenfahrt, aber das Regensignal scheint nachts nicht anzukommen.

Nach der Nachtfahrt heute um 18:00 Uhr habe ich einmal Regen simuliert:

Vor Nachtfahrt: kein Regen, "unprotected"
18:00 Uhr Runterfahrt
18:01 Uhr Regensimulation, liefert "unprotected"

Gerne kann ich das morgen früh noch einmal für die Morgenauffahrt prüfen.

Kannst Du das bitte auch mal am Tag testen.
Hab auch schon ne Idee wo ich mal schauen kann

[FFHEM]

Kannst Du das bitte auch mal am Tag testen.
Hab auch schon ne Idee wo ich mal schauen kann

Gerne, der Test bestätigt den gestrigen Test:

Heute morgen - Bedingungen: Rolladen sind unten wegen Nachtfahrt, geplante Auffahrt ist 07:49 Uhr

07:30 Regen wird simuliert
07:40  ascAPIget('RainProtectionStatus','RolladenArbeitszimmer') }  liefert  "unprotected"!
07:49 Rolladen fahren hoch

[CoolTux]

Gerne, der Test bestätigt den gestrigen Test:

Heute morgen - Bedingungen: Rolladen sind unten wegen Nachtfahrt, geplante Auffahrt ist 07:49 Uhr

07:30 Regen wird simuliert
07:40  ascAPIget('RainProtectionStatus','RolladenArbeitszimmer') }  liefert  "unprotected"!
07:49 Rolladen fahren hoch

Ich meinte eher warte bitte bis die Rollos zur Tagfahrt hochgefahren sind und simuliere dann Regen. Dann mach bitte die Anfrage.


Grüße

[FFHEM]

Ich meinte eher warte bitte bis die Rollos zur Tagfahrt hochgefahren sind und simuliere dann Regen. Dann mach bitte die Anfrage.
Grüße

Ok, Regen simuliert -> Rolladen fahren herunter, Status ist "protected".
Regen wieder entfernt -> Rolladen fahren rauf, Status ist "unprotected".

Zusammengefasst: in der Nacht greift der Regenschutz nicht, wohl am Tag.

Gruß

[CoolTux]

Ok, Regen simuliert -> Rolladen fahren herunter, Status ist "protected".
Regen wieder entfernt -> Rolladen fahren rauf, Status ist "unprotected".

Zusammengefasst: in der Nacht greift der Regenschutz nicht, wohl am Tag.

Gruß

Habe ich mir fast gedacht. Ich schaue nächste Woche einmal.

[FFHEM]

Prima, danke Dir vielmals!
Gruß, Friedhelm

[marvin78]

Hallo,

ich habe es sicher im Wust überlesen. In der Doku habe ich in der Genauigkeit aber nichts dazu gefunden.

Die HmIP-Wired Jalousien werden etwas anders gesteuert, als ASC es scheinbar erwartet. Wenn man sie bspw. wirklich 100% öffnen möchte, muss man (ja nach aktuellem Stand der Lamellen) folgendes machen:

Ein Attribut eventMap mit Auschnittweise folgendem Inhalt:

Code Auswählen Erweitern

datapoint LEVEL_2 1 LEVEL 100:on

und dann

Code Auswählen Erweitern

set <DEVICE> on

Es wird also der gesamte Doppel-Befehl auf on gemapt. Schickt man das einzeln, fahren die Lamellen nicht in Position und die Jalousie lässt sich nur auf bspw. 96% öffnen. Das gleiche gilt für runter.

Lässt sich das abbilden? Kann man bspw. direkt "on" als openCmd senden?

Danke.

[Reinhard.M]

Hallo,

ich habe es sicher im Wust überlesen. In der Doku habe ich in der Genauigkeit aber nichts dazu gefunden.

Die HmIP-Wired Jalousien werden etwas anders gesteuert, als ASC es scheinbar erwartet. Wenn man sie bspw. wirklich 100% öffnen möchte, muss man (ja nach aktuellem Stand der Lamellen) folgendes machen:

Ein Attribut eventMap mit Auschnittweise folgendem Inhalt:

Code Auswählen Erweitern

datapoint LEVEL_2 1 LEVEL 100:on
Hallo Marvin78,
ich hatte das gleiche Problem mit einem HmIP-FBL. Mit der folgenden Lösung fahre ich bislang ganz gut:
https://forum.fhem.de/index.php/topic,112325.msg1171561.html#msg1171561

und dann

Code Auswählen Erweitern

set <DEVICE> on

Es wird also der gesamte Doppel-Befehl auf on gemapt. Schickt man das einzeln, fahren die Lamellen nicht in Position und die Jalousie lässt sich nur auf bspw. 96% öffnen. Das gleiche gilt für runter.

Lässt sich das abbilden? Kann man bspw. direkt "on" als openCmd senden?

Danke.

Hallo Marvin78,
ich hatte das gleiche Problem mit einem HmIP-FBL. Mit der folgenden Lösung fahre ich bislang ganz gut:
https://forum.fhem.de/index.php/topic,112325.msg1171561.html#msg1171561
Das Komma habe ich durch einen Punkt ersetzt, damit gibt es keine Perl-Warnings mehr. Außerdem noch ein paar andere "Kleinigkeiten" angepasst. Bei Interesse kannst du mich gerne kontaktieren.

Gruß Reinhard

[marvin78]

@Reinhard.M: Vielen Dank. Die Lösung gefällt mir, weil sie offenbar funktioniert. Tatsächlich hatte ich schonmal an sowas gedacht, finde es aber am Ende nicht ganz sauber. Sauber wäre, wenn man in ASC Kommandos für open und close definieren könnte. Aber bis dahin tut es das hier sicher. Danke nochmal!!

Achso: Interesse an den Anpassungen hätte ich.

[marvin78]

Nachtrag: Kannst du mit die Probleme mit den Positionen mal genauer erläutern? Danke.

[Beta-User]

@marvin78:Evtl. kannst du einen patch erstellen? Eine Art ASC_commandTemplate-Attribut, z.B.?

Soweit mir bekannt, ist das wohl signifikant unterschiedlich. Bei den CUL_HM-Geräten ist es zumindest möglich, beide Befehle getrennt auf das jeweilige Reading abzusetzen (analog zu ZWave). Das war einer der Gründe, warum ASC diese Befehle sequentiell erzeugt - was grade bei den HM-IP-Geräten für Probleme zu sorgen scheint.

Vielleicht muss man sich mit dem Thema auch hinter den Kulissen nochmal befassen. "Damals" gab es zwar mal eine Sammlung vorab, wer was braucht an Kommandos für die Lamellensteuerung, aber da war HM-IP noch nicht besonders verbreitet gewesen, und Lamellen hatte schon gleich keiner...
Andererseits ist jeder weitere "Tweak" geeignet, für weitere Verwirrung und/oder Komplexität zu sorgen, und rückwärtskompatibel sollte es dann auch noch sein. Schwierig.

@CoolTux: evtl. könnte man (doch) sowas wie

Code Auswählen Erweitern

command="set $DEVICE $cover; set xyz $slat"
oder

Code Auswählen Erweitern

command="set $DEVICE pct $cover slats $slat"
zulassen?

In der Ausführung müßte man dann erst checken, ob was "spezielles" da steht, dann entweder normal weiter oder diese drei Parameter vorher extrapolieren und dann das Ergebnis z.B. an AnalyzeCommandChain() übergeben; damit sollte sich (fast) alles erschlagen lassen, was so "kreucht und fleucht"?

(Sowas für den normalen Fahr-Command würde dann auch das SPS-Problem von weiter oben lösen?).