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

[gestein]

Wie das mit DOIF geht keine Ahnung, der FHEM Befehl lautet attr. Und ja damit kann man das. Aber dann muss man auch speichern da eine Konfigurationsänderung durchgeführt wurde.

Ja, das stimmt. Man müsste es immer speichern.
Ein "{ ascAPIset('ShadingMinMaxElevation','Rollo.WZ.Kueche','10:100');}" liefert leider das gleiche Ergebnis. Auch da wird logischerweise eine Konfigurationsänderung erzeugt.

lg, Gerhard

[CoolTux]

Ja das ist richtig. Ich finde sowas sollte auch ersichtlich sein.

[fraggle777]

Guten Morgen zusammen,

ich habe jetzt nochmal beobachtet, was das ASC_ShuttersLastDrive bei mir macht. Wenn ich meine beiden Velux Dachfensterrolladen manuell verfahre, wird nach Beendigung der Fahrt das Reading ASC_ShuttersLastDrive aktualisiert. So würde man es erwarten. Bei den DUOFERN Aktoren der Außenjalousien tut sich nichts. Die werden nicht aktualisiert. Also zumindest nicht zuverlässig, hin und wieder steht ja schon der richtige Wert drin. Irgendeine Idee, woran das liegen kann? Leider funktioniert dadurch das Blocking nach manueller Fahrt nur sehr unzuverlässig.

Viele Grüße

Philip

[fraggle777]

Update:

Habe gerade nochmal mit dem automatischen Shading rumgespielt und jetzt haben zwei von den DUOFERN Jalousieaktoren ASC_ShuttersLastDrive mit shading out korrekt übernommen und bei allen anderen Devices wurde das Reading nicht aktualisiet. Irgendwie erkenne ich da kein Muster...

Viele Grüße

Philip

[CoolTux]

Kann sein das nicht das korrekte Positionsreading ausgelesen werden kann.
Du kannst schauen ob es besser wird wenn Du ein usereadings pct an legst und dieses im Attribut ASC_Pos_Reading an gibst.

[Bronze]

@CoolTux

Ich habe Deinen Tip befolgt und das UserReading für die Fensterkontaktabfrage zusammen mit dem vorhandenen für die Position eingebaut.
Die Abfrage des Fensterkontaktes dient dem Softlock. Das habe ich getestet, das funktioniert.

Allerdings fahren die Rolladen jetzt nicht mehr ASC-gesteuert. Untern steht zB ASC_LastShuttersDrive day open, was dem angezeigten Zustand 100% = zu widerspricht, der Rollladen ist tatsächlich zu.

Irgendetwas scheint jetzt zu blockieren. Das gilt genau für alle Fenster, wo dieses Userreading für den Softlock eingebaut wurde.

Code Auswählen Erweitern


DeviceOverview
Rollade_OG_WZ_Tuer 100 %
Rollade_OG_WZ_Tuer
Rollade_OG_WZ_Tuer Internals
DEF
1/2/23:dpt5.001:position 1/2/12:dpt1:fahre 1/2/13:dpt1:stop 1/2/22:dpt5.001:position
DEVNAME Rollade_OG_WZ_Tuer
FIRSTGADNAME position
FUUID 5e9600b8-f33f-1985-04ee-6d19c25779e0c5cc
GETSTRING fahre:noArg stop:noArg position:noArg
IODev KNX
KNX_MSGCNT 16
KNX_RAWMSG C0110dw01217ff
KNX_TIME 2020-05-08 21:00:21
LASTInputDev KNX
MSGCNT 16
NAME Rollade_OG_WZ_Tuer
NR 423
NTFY_ORDER
50-Rollade_OG_WZ_Tuer
SETSTRING
fahre:off,on stop:off,on position:slider,0,1,100
STATE 100 %
TYPE KNX

Readings
ASC_Enable on
ASC_ShuttersLastDrive day open
ASC_Time_DriveDown 9.05.2020 - 21:01
ASC_Time_DriveUp 10.05.2020 - 05:52
associatedWith Autoroll
fahre-get off
last-sender 1/1/13
position 0
position-get 100 %
position-set 100 %
state 100 %
stop-get off
Rollade_OG_WZ_Tuer
KNX->Rollade

Attributes
ASC 1
ASC_Down astro
ASC_LockOut soft
ASC_Mode_Down always
ASC_Mode_Up always
ASC_Pos_Reading position
ASC_Up astro
ASC_WindowRec KNX_0403013
ASC_WindowRec_subType twostate
IODev KNX

userReadings
KNX_0403013 ascWinState.(alarm|no.alarm) { (ReadingsVal($name,'state','no alarm') eq 'alarm' ? 'open' : 'closed') },
position:position-get:.* { ReadingsNum($name,'position-get',50) }

[CoolTux]

Wieso steht das userreadings für den Fensterkontakt im Rollodevice.

[fraggle777]

Kann sein das nicht das korrekte Positionsreading ausgelesen werden kann.
Du kannst schauen ob es besser wird wenn Du ein usereadings pct an legst und dieses im Attribut ASC_Pos_Reading an gibst.

Vielen Dank für den Vorschlag. Ich habe das umgesetzt und es sah so aus, als ob es das gewesen wäre. Wenn Shading In ausgelöst wird, springt ASC_LastShuttersDrive sofort auf "Shading In". Jetzt sind meine Jalousien aber direkt im Device so programmiert, dass sie nach dem Herunterfahren die Lamellen ein Stück zurück drehen, damit man raus gucken kann. Das wird vom ASC wohl auch als manueller Eingriff gewertet. Ist ja aus Sicht von ASC auch korrekt. Dafür gibt es vermutlich aktuell keine Lösung, oder?

Viele Grüße

Philip

[Bronze]

@CoolTux


Hier in fett:

userReadings
KNX_0403013 ascWinState.(alarm|no.alarm) { (ReadingsVal($name,'state','no alarm') eq 'alarm' ? 'open' : 'closed') },
position:position-get:.* { ReadingsNum($name,'position-get',50) }

[gestein]

Ja das ist richtig. Ich finde sowas sollte auch ersichtlich sein.

Ja, finde ich auch gut so.

2 Bitten für die "ASC Configuration and Information Summary":
Könntest Du da vielleicht auch das "ASC_Shading_Mode" mit aufnehmen?

Bei mir schaut das so aus wie im Anhang.
Vielleicht könntest Du die Spalten für "Next DriveUp" und "Next DriveDown" etwas breiter machen?
Oder liegt das an meinem Browser?

Danke, lg, Gerhard

[CoolTux]

Vielen Dank für den Vorschlag. Ich habe das umgesetzt und es sah so aus, als ob es das gewesen wäre. Wenn Shading In ausgelöst wird, springt ASC_LastShuttersDrive sofort auf "Shading In". Jetzt sind meine Jalousien aber direkt im Device so programmiert, dass sie nach dem Herunterfahren die Lamellen ein Stück zurück drehen, damit man raus gucken kann. Das wird vom ASC wohl auch als manueller Eingriff gewertet. Ist ja aus Sicht von ASC auch korrekt. Dafür gibt es vermutlich aktuell keine Lösung, oder?

Viele Grüße

Philip

Wie viel Zeit vergeht denn zwischen dem runterfahren über ASC und dem manuellen nachjustieren? Du kannst das Attribut ASC_DriveUpMaxDuration entsprechend setzen. Das ist die längste Zeit welche das Rollo benötigt für eine komplette Fahrt. Bei Dir also inklusive nachjustieren.

[CoolTux]

@CoolTux


Hier in fett:

userReadings
KNX_0403013 ascWinState.(alarm|no.alarm) { (ReadingsVal($name,'state','no alarm') eq 'alarm' ? 'open' : 'closed') },
position:position-get:.* { ReadingsNum($name,'position-get',50) }

Sorry bin zu doof dafür, ich sehe an Hand Deines lists? weiter oben das alles in einem Device liegt. Du musst bitte etwas genauer erklären was Du wie gemacht hast.

[CoolTux]

Ja, finde ich auch gut so.

2 Bitten für die "ASC Configuration and Information Summary":
Könntest Du da vielleicht auch das "ASC_Shading_Mode" mit aufnehmen?

Bei mir schaut das so aus wie im Anhang.
Vielleicht könntest Du die Spalten für "Next DriveUp" und "Next DriveDown" etwas breiter machen?
Oder liegt das an meinem Browser?

Danke, lg, Gerhard

Kann ich gerne schauen das ich es mit rein nehme.

Bei mir sieht es im übrigen so aus.

[Bronze]

@CoolTux

Damit es mit KNX funktioniert, habe ich zunächst dieses userReading eingefügt:

Code Auswählen Erweitern

position:position-get:.* { ReadingsNum($name,'position-get',50) }

Damit ließen sich die Rollläden über ASC steuern.

Dann wollte ich die Aussperrsicherung mit dem Softlock einrichten.
Dazu war ein userReading für den Fensterkontakt nötig, damit "open" und "closed" gelesen wird:

Code Auswählen Erweitern

KNX_0403013 ascWinState.(alarm|no.alarm) { (ReadingsVal($name,'state','no alarm') eq 'alarm' ? 'open' : 'closed') }

Die Attibute der Rollläden sehen so aus:

Code Auswählen Erweitern

ASC 1
ASC_Down astro
ASC_LockOut soft
ASC_Mode_Down always
ASC_Mode_Up always
ASC_Pos_Reading position
ASC_Up astro
ASC_WindowRec KNX_0403013
ASC_WindowRec_subType twostate
IODev KNX
userReadings
KNX_0403013 ascWinState.(alarm|no.alarm) { (ReadingsVal($name,'state','no alarm') eq 'alarm' ? 'open' : 'closed') },
position:position-get:.* { ReadingsNum($name,'position-get',50) }


Nun fahren die Rollläden nicht mehr über ASC.
Hoffe, das war verständlicher.

[CoolTux]

Ich komme mit dem userreadings nicht klar.

Code Auswählen Erweitern

KNX_0403013 ascWinState.(alarm|no.alarm) { (ReadingsVal($name,'state','no alarm') eq 'alarm' ? 'open' : 'closed') }
Sieht für mich falsch aus.
Außerdem liest Du das state vom Rollo Device aus wo oben im list eine Zahl steht und nicht Alarm oder No alarm.