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

[CoolTux]

Hi,

Ja das mag sein. Leider übermittelt der Sensor nich im gleichen Reading, den Status Open/closed/tilted, sondern es gibt im STATE ein Open oder closed, und zusätzlich gibt es ein Reading, tilt was on oder off sein kann.
Ich hab das alles über ein userreading im Reading state gemappt. https://forum.fhem.de/index.php/topic,101182.msg947361.html#msg947361
Aber ich verstehe das Problem nich nicht ganz: Welche von den Events sollte es denn nur geben? Nur die Alarm-Events?
Mich wundert tatsächlich, dass es dieses Event hier überhaupt gibt:

Code Auswählen Erweitern

ASC_DEBUG!!! 2019.11. 1 18:05:08 - EventProcessingWindowRec: OG_SZ_ROLLO_LI - RECEIVED EVENT: tilt: off state: closed - IDENTIFIED EVENT: closed - STORED EVENT: closed
Aber hätte da nicht einfach die Rolladen komplett runter fahren müssen?

Da wirst Du dann mit einem Dummy arbeiten müssen oder du machst twostate. Auf jeden Fall musst Du die Events begrenzen. Setze auf state erstmal event-on-change-reading und mache ein twostate Sensor daraus. Dann sollte das schon Mal klappen.

[Wardancer]

Hi,

Ich glaube ich muss nochmal was bohren... es geht mir jetzt nicht darum, dass es so mal funktioniert hat, sondern einfach darum zu verstehen, wie die Events aussehen müssten, ich würde diesen Sensor nämlich sehr ungern zu einem Two-State machen.
Also welche Events müsste ich denn in welcher Reihenfolge liefern? Oder anders ausgedrückt, wie verhalten sich denn so die anderen Three-States an der Stelle? Oder ist das alles eine Timing-Frage? Ich denke viele dieser Infos bräuchte ich auch für einen Dummy.

Danke schonmal fürs erklären....

[CoolTux]

Es sollte in der Regel immer nur ein Event für state kommen wenn das Fenster aufgemacht wird.
Das es, so wie Du es beschrieben hast, mal funktioniert haben soll möchte ich so nicht stehen lassen. Fenster gekippt kann zum Beispiel nie funktioniert haben wenn ich Dich richtig verstanden habe, da ja für das Reading state kein tilted Event kommt.
Laut Deiner Beschreibung gibt es für tilted ein extra Reading. Geht denn wenigstens der state in open? Denn dann fuhr zu mindestens das Rollo in die Lüften Position.

[moonsorrox]

Code Auswählen Erweitern

ASC_Closed_Pos 15
Ist das wirklich so? Ist 15 wirklich der tiefste Stand des Rollos?

Das hier wird das eigentliche Problem sein

Code Auswählen Erweitern

ASC_Closed_Pos 15
ASC_Shading_Pos 15

Ja das ist die closed Position. Das habe ich aber schon immer und ewig so und es funktionierte bisher.
Aktuell nutzt er ja die Beschattung nicht.
Heute morgen ist er wieder nicht hoch gefahren, aber da ich auf eine Rückmeldung warten wollte habe ich bisher auch nichts eingestellt.

Ist denn zwischenzeitlich am Modul etwas geändert worden das sich die beiden Positionen behindern könnten..?

Dann ändere ich die closed Position mal. Das ist kein Problem.

[CoolTux]

Dann ändere ich die closed Position mal. Das ist kein Problem.

Das verstehe ich nicht. Wie kann man die tiefste Position eines Rollos verändern? Du sagst 15 ist tatsächlich die tiefste Position, dann musst Du eher die Beschattungsposition ändern. Würde dann halt 16 nehmen.
Wenn ich Deine Konfig richtig sehe dann ist 100 bei Dir komplett oben und 15 komplett unten. Nun gut etwas seltsam aber ok,
Sollte es nicht sein und eigentlich 0 komplett unten sein dann arbeitest Du gegen die Modullogik und dann kann es auch nicht gehen.
Möglich das es mal ging aber mit fortschreitender Entwicklung werden auch Fehler bereinigt und/oder die Logiken kontrolliert.

[moonsorrox]

Das ist schon richtig was du sagst 100 ist offen und 0 ist komplett geschlossen, aber ich wollte diesen Rollladen nicht komplett schließen lassen am Abend.
Wie schon gesagt ich habe das bisher immer so gehabt, dann änder ich die closed Position mal auf 10 und werde morgen früh schauen und berichten. 

[CoolTux]

Das ist schon richtig was du sagst 100 ist offen und 0 ist komplett geschlossen, aber ich wollte diesen Rollladen nicht komplett schließen lassen am Abend.
Wie schon gesagt ich habe das bisher immer so gehabt, dann änder ich die closed Position mal auf 10 und werde morgen früh schauen und berichten. 

Ich weiß nicht ob das schon in Deiner Version vorhanden ist aber es gibt eine SleepPosition. Die wäre glaube besser in der Anwendung.
Du kannst natürlich die 10 gerne testen. Ich würde aber auf die Funktion kein Support geben. Du gehst mit dieser Einstellung an der Modullogik vorbei. Sorry

[Wardancer]

Hi,

Also um das nochmal kurz zu erklären:

Der Sensor hat ein extra Reading für tilt, ja. Was immer funktioniert ist das Fahren in die Lüftenposition und auch die Offen-Position ( funktioniert auch immer noch ). Was dann mal funktioniert hat, ist das dann auch anschließend bei einem schließen der Türe, die Rolladen auch wieder runter fuhr.
Ich habe halt ein kleines userReading geschrieben, was mir genau diese Status in den State schreibt, hier zur Anschauung der Code:

Code Auswählen Erweitern

userReadings state:alarm.* {
if ($event =~ /closed/)
{"closed"}
elsif ($event =~ /open/) {
if (ReadingsVal("tilted","tilt","off") eq "off") {"open"}
else {"tilted"}
}
   },
   
state:tilt.* {if ($eventValue eq "on") {"tilted"} else {"closed"}}

Wenn ich dich jetzt richtig verstehe sollte hier nur einmal ein closed auf state kommen

Code Auswählen Erweitern

SC_DEBUG!!! 2019.11. 1 18:05:08 - EventProcessingWindowRec: OG_SZ_ROLLO_LI - RECEIVED EVENT: alarm: AccessControl: Window/Door is closed state: closed - IDENTIFIED EVENT: closed - STORED EVENT: closed
ASC_DEBUG!!! 2019.11. 1 18:05:08 - EventProcessingWindowRec: OG_SZ_ROLLO_LI - RECEIVED EVENT: tilt: off state: closed - IDENTIFIED EVENT: closed - STORED EVENT: closed

Und zu ,, das halt mal funktioniert": ich hab das ganze ja nunmal in dem zitierten Thread dokumentiert, weil es mal gelaufen ist, aber es ist eine Lösung die ich gebastelt habe, und wenn die halt jetzt nicht mehr funktioniert, muss ich halt ran, muss nur verstehen was falsch läuft!

Du machst auf jeden Fall ein echt Super Modul!

[moonsorrox]

Ich habe ca. 3 Tage kein Update gemacht. Eine SleepPosition gibt es bei mir nicht.
Heißt die auch so, oder ASC_SleepPosition, aber auch die gibt es bei mir nicht.

OK, wenn das so ist das ich an der Modullogik vorbei gehe, dann brauche ich doch die ASC_closed Position gar nicht, denn default sollte die doch immer ,,0" sein, oder irre ich mich da.
Dann lösche ich die und es sollte funktionieren, oder muss die zwingend die ,,0" haben.?

[CoolTux]

Hi,

Also um das nochmal kurz zu erklären:

Der Sensor hat ein extra Reading für tilt, ja. Was immer funktioniert ist das Fahren in die Lüftenposition und auch die Offen-Position ( funktioniert auch immer noch ). Was dann mal funktioniert hat, ist das dann auch anschließend bei einem schließen der Türe, die Rolladen auch wieder runter fuhr.
Ich habe halt ein kleines userReading geschrieben, was mir genau diese Status in den State schreibt, hier zur Anschauung der Code:

Code Auswählen Erweitern

userReadings state:alarm.* {
if ($event =~ /closed/)
{"closed"}
elsif ($event =~ /open/) {
if (ReadingsVal("tilted","tilt","off") eq "off") {"open"}
else {"tilted"}
}
   },
   
state:tilt.* {if ($eventValue eq "on") {"tilted"} else {"closed"}}

Wenn ich dich jetzt richtig verstehe sollte hier nur einmal ein closed auf state kommen

Code Auswählen Erweitern

SC_DEBUG!!! 2019.11. 1 18:05:08 - EventProcessingWindowRec: OG_SZ_ROLLO_LI - RECEIVED EVENT: alarm: AccessControl: Window/Door is closed state: closed - IDENTIFIED EVENT: closed - STORED EVENT: closed
ASC_DEBUG!!! 2019.11. 1 18:05:08 - EventProcessingWindowRec: OG_SZ_ROLLO_LI - RECEIVED EVENT: tilt: off state: closed - IDENTIFIED EVENT: closed - STORED EVENT: closed

Und zu ,, das halt mal funktioniert": ich hab das ganze ja nunmal in dem zitierten Thread dokumentiert, weil es mal gelaufen ist, aber es ist eine Lösung die ich gebastelt habe, und wenn die halt jetzt nicht mehr funktioniert, muss ich halt ran, muss nur verstehen was falsch läuft!

Du machst auf jeden Fall ein echt Super Modul!

Ah ok das Du da extra was gebaut hast habe ich nicht vernommen. Das ist dann irgendwie noch schwieriger. Denn zu erst kommt der normale Event für state und dann Dein userReading Event. ein userReading ist aber nicht dafür da um ein bestehendes zu ersetzen.

Ich werde mir Deine Konfig mal in meiner Testumgebung anschauen. Aber so ist das schlecht wie es ist. Das Modul reagiert sofort  wenn ein state Event kommt und fängt augenblicklich mit der Verarbeitung an.

[CoolTux]

Ich habe ca. 3 Tage kein Update gemacht. Eine SleepPosition gibt es bei mir nicht.
Heißt die auch so, oder ASC_SleepPosition, aber auch die gibt es bei mir nicht.

OK, wenn das so ist das ich an der Modullogik vorbei gehe, dann brauche ich doch die ASC_closed Position gar nicht, denn default sollte die doch immer ,,0" sein, oder irre ich mich da.
Dann lösche ich die und es sollte funktionieren, oder muss die zwingend die ,,0" haben.?

Kann sein das die erst mit der Version 0.8 kam. Das Attribut lautet ASC_Sleep_Pos, wenn das gesetzt ist wird automatisch diese Position angefahren.
Die closed Position ist immer default 0 wenn ASC 2 als Attribut gewählt wurde.

[Wardancer]

Um das noch komplett schwieriger zu machen:

Ah ok das Du da extra was gebaut hast habe ich nicht vernommen. Das ist dann irgendwie noch schwieriger. Denn zu erst kommt der normale Event für state und dann Dein userReading Event. ein userReading ist aber nicht dafür da um ein bestehendes zu ersetzen.

Es gibt eigentlich gar kein state Reading in dem Sensor, das schreibe ich komplett selber aus einem alarm Reading und besagtem tilt Reading, dazu gibt es das userreading.
Ich könnte mir vorstellen, dass sich in der ZWave Verarbeitung was geändert hat. Ich gehe jetzt erstmal hin und baue meine Behandlung für das tilt-off etwas um... was mich aber tatsächlich wundert ist, dass der Rolladen noch nicht mal runter fährt, wenn die Türe komplett geschlossen wird.
Naja, ich werde berichten

[CoolTux]

Um das noch komplett schwieriger zu machen: Es gibt eigentlich gar kein state Reading in dem Sensor, das schreibe ich komplett selber aus einem alarm Reading und besagtem tilt Reading, dazu gibt es das userreading.
Ich könnte mir vorstellen, dass sich in der ZWave Verarbeitung was geändert hat. Ich gehe jetzt erstmal hin und baue meine Behandlung für das tilt-off etwas um... was mich aber tatsächlich wundert ist, dass der Rolladen noch nicht mal runter fährt, wenn die Türe komplett geschlossen wird.
Naja, ich werde berichten

Ah das ist ein wichtiger Hinweis. Dann ist Deine Methode nicht verkehrt. Da müssen wir nur schauen wieso der da so seltsam reagiert.

[CoolTux]

Code Auswählen Erweitern

userReadings state:alarm.* {
if ($event =~ /closed/)
{"closed"}
elsif ($event =~ /open/) {
if (ReadingsVal("tilted","tilt","off") eq "off") {"open"}
else {"tilted"}
}
   },
   
state:tilt.* {if ($eventValue eq "on") {"tilted"} else {"closed"}}

Das kann so nicht gehen.

Code Auswählen Erweitern

if (ReadingsVal("tilted","tilt","off") eq "off") {"open"}
Alleine das ist glaube falsch da Du sicherlich kein Device namens tilted hast, oder?

[CoolTux]

Unter der Voraussetzung das die Readings und die Werte genau so passen probiere bitte einmal dieses userReadings

Code Auswählen Erweitern

state:alarm:.* { (ReadingsVal($name,'alarm','none') eq 'closed' ? 'closed' : ( ReadingsVal($name,'tilt','none') eq 'on' ? 'tilted' : 'open')) }
Man müsste noch schauen ob das auslesen des Readings tilt geschieht nach dem es gesetzt wurde.