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

[CoolTux]

So endlich hat es mal geklappt und das Fenster war gekippt.

Hier nun die Log vom ASC.

Müsste so um 171 Uhr rum sein, denke eher nach 17 Uhr. Es geht um Schlafzimmer links.

Hi,

Ist aber leider ne Tür. Ich hab nur das Attribut für Terrasse vergessen wieder zu setzen... ich setzt das Attribut einmal und Probier dann nochmal...

Du warst auch gar nicht gemeint 

Mach mal bitte heute Abend nach Sonnenuntergang noch mal Fenster auf und Debugge das. Und dann hier bitte die Logausgabe posten.

Oder bezog sich Deine Aussage darauf?

[Wardancer]

Nee
Werd aber heute Abend nochmal nen debug log machen...

[CoolTux]

Nee
Werd aber heute Abend nochmal nen debug log machen...

Ich hatte bei Dir was im Log gefunden, allerdings noch bei 99 und Tag. 99 war bei Dir ganz oben und bei Tag fährt er eh hoch. Deswegen müssen wir das noch mal sauber machen.

[moonsorrox]

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.

ich habe die Version 0.6.33

Heute morgen ein komisches Verhalten ich hatte die ASC_closed Position auf 10 gesetzt die hatte er gestern Abend auch angefahren. Heute morgen nun stand er auf 15 und das ist bei mir die ASC_Shading_Pos. aber die Beschattung ist aktuell ausgeschaltet, warum hat er die nun angefahren anstatt komplett hoch zufahren..?

Jetzt nun habe ich die ASC_closed Position komplett gelöscht da ich ja ASC auf 2 stehen habe mal schauen was morgen früh passiert.
Es zwar nicht die Position die ich gern hätte, aber damit ich es testen kann ob es nun daran liegt das er morgens nicht öffnet ist das Attribut nun erst einmal raus.

[D3ltorohd]

Bitte entferne einmal das Attribut

Code Auswählen Erweitern

ASC_LockOut
Das wird das "Problem" verursachen. Es ist ein Fenster und auch als solchen in ASC Vermerkt, da braucht man das Attribut gar nicht.

Hm wurde das vllt automatisch gesetzt ? Ich kann mich nicht erinnern das gesetzt zu haben. Ich schmeiße es raus und schau morgen.

Hier noch was zu ::

Code Auswählen Erweitern

ASC_AutoAstroModeEvening
HORIZON

und

Code Auswählen Erweitern

ASC_AutoAstroModeEveningHorizon
-4

Wie sollte ich das aktuell einstellen, damit es so bei Dämmerungsanfang runter fährt. Jetzt fahren sie so ziemlich spät, da ist es draußen schon dunkel.

[CoolTux]

Du kannst CIVIL probieren.

[D3ltorohd]

Das

Code Auswählen Erweitern

ASC_AutoAstroModeEveningHorizon -4 komplett löschen ?

Gibt es irgendwo eine Möglichkeit rein zu lesen, was das beeinflusst, oder besser gesagt was CIVIL, REAL usw bedeutet, von welchen Werten die ausgehen ? Was ist wenn ich das Attr auch lösche, was ist Standard ?

[CoolTux]

Das

Code Auswählen Erweitern

ASC_AutoAstroModeEveningHorizon -4 komplett löschen ?

Gibt es irgendwo eine Möglichkeit rein zu lesen, was das beeinflusst, oder besser gesagt was CIVIL, REAL usw bedeutet, von welchen Werten die ausgehen ? Was ist wenn ich das Attr auch lösche, was ist Standard ?

Ja kannst löschen.

Nachlesen kannst du im Wiki zu sunrise oder bei Wikipedia.

[Wardancer]

Hi,

Hier ist das Debug, der Einfachheit halber nur öffnen und schließen. Nach wie vor das Verhalten, Rollade fährt hoch, aber nach dem close nicht wieder runter.

Code Auswählen Erweitern

ASC_DEBUG!!! 2019.11. 3 19:08:19 - EventProcessingWindowRec: OG_SZ_ROLLO_LI - RECEIVED EVENT: alarm: AccessControl: Window/Door is open state: open - IDENTIFIED EVENT: open - STORED EVENT: open

ASC_DEBUG!!! 2019.11. 3 19:08:19 - EventProcessingWindowRec: OG_SZ_ROLLO_LI - HOMEMODE: none QueryShuttersPosWinRecTilted:1 QueryShuttersPosWinRecComfort: 1

ASC_DEBUG!!! 2019.11. 3 19:08:19 - FnSetCmdFn: OG_SZ_ROLLO_LI - Rollo wird gefahren, aktuelle Position: 0, Zielposition: 99. Grund der Fahrt: comfort - window open
2019.11.03 19:08:19 3: ZWave set OG_SZ_ROLLO_LI dim 99

ASC_DEBUG!!! 2019.11. 3 19:08:19 - FnSetDriveCmd: OG_SZ_ROLLO_LI - NICHT versetztes fahren

ASC_DEBUG!!! 2019.11. 3 19:08:19 - FnSetDriveCmd: OG_SZ_ROLLO_LI - NoOffset: JA

ASC_DEBUG!!! 2019.11. 3 19:08:47 - Notify:  ASC_Pos_Reading Event vom Rollo wurde erkannt  - RECEIVED EVENT: [
  'reportedState: dim 99',
  'dim: 99'
]


ASC_DEBUG!!! 2019.11. 3 19:08:47 - EventProcessingShutters:  Fn wurde durch Notify aufgerufen da ASC_Pos_Reading Event erkannt wurde  - RECEIVED EVENT: 'reportedState: dim 99 dim: 99'


ASC_DEBUG!!! 2019.11. 3 19:08:47 - EventProcessingShutters: OG_SZ_ROLLO_LI - Event vom Rollo erkannt. Es wird nun eine etwaige manuelle Fahrt ausgewertet. Int von gettimeofday: 1572804527 Last Position Timestamp: 1572804499 Drive Up Max Duration: 60 Last Position: 0 aktuelle Position: 99

ASC_DEBUG!!! 2019.11. 3 19:08:47 - EventProcessingShutters: eine automatisierte Fahrt durch ASC wurde erkannt! Es werden nun die LastDriveReading und StateReading Werte gesetzt!

ASC_DEBUG!!! 2019.11. 3 19:08:47 - EventProcessingShutters:  Fn wurde durlaufen und es sollten Debugausgaben gekommen sein.  !!!Wenn nicht!!! wurde der Event nicht korrekt als Nummerisch erkannt.

ASC_DEBUG!!! 2019.11. 3 19:09:13 - 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. 3 19:09:13 - EventProcessingWindowRec: OG_SZ_ROLLO_LI - HOMEMODE: none QueryShuttersPosWinRecTilted: QueryShuttersPosWinRecComfort:

ASC_DEBUG!!! 2019.11. 3 19:09:13 - FnIsDay: OG_SZ_ROLLO_LI Allgemein: 0

ASC_DEBUG!!! 2019.11. 3 19:09:13 - FnIsDay: OG_SZ_ROLLO_LI getDownBrightness: 0 Brightness: -1 BrightnessMin: 500 Sunset: 1

ASC_DEBUG!!! 2019.11. 3 19:09:13 - FnIsDay: OG_SZ_ROLLO_LI getUpBrightness: 0 Brightness: -1 BrightnessMax: 800 Sunrise: 0

ASC_DEBUG!!! 2019.11. 3 19:09:13 - FnIsDay: OG_SZ_ROLLO_LI Allgemein: 0

ASC_DEBUG!!! 2019.11. 3 19:09:13 - FnIsDay: OG_SZ_ROLLO_LI getDownBrightness: 0 Brightness: -1 BrightnessMin: 500 Sunset: 1

ASC_DEBUG!!! 2019.11. 3 19:09:13 - FnIsDay: OG_SZ_ROLLO_LI getUpBrightness: 0 Brightness: -1 BrightnessMax: 800 Sunrise: 0

ASC_DEBUG!!! 2019.11. 3 19:09:13 - EventProcessingWindowRec: OG_SZ_ROLLO_LI Event Closed

ASC_DEBUG!!! 2019.11. 3 19:09:13 - FnIsDay: OG_SZ_ROLLO_LI Allgemein: 0

ASC_DEBUG!!! 2019.11. 3 19:09:13 - FnIsDay: OG_SZ_ROLLO_LI getDownBrightness: 0 Brightness: -1 BrightnessMin: 500 Sunset: 1

ASC_DEBUG!!! 2019.11. 3 19:09:13 - FnIsDay: OG_SZ_ROLLO_LI getUpBrightness: 0 Brightness: -1 BrightnessMax: 800 Sunrise: 0

[CoolTux]

Fehler gefunden

Code Auswählen Erweitern

ASC_Mode_Up off

Auf dem ersten Blick würde ich es für einen Bug halten. Muss es mir aber noch genauer anschauen.

[CoolTux]

War in meinen Augen ein Bug. Ich habe es gefixt und es wird morgen früh ein Update geben.
Dieser Bug gilt aber ausschließlich bei erkannter Nacht und damit verbundenen schließen des Fensters.
Am Tag würde bei Deiner derzeitigen Konfig auch nichts passieren da Du ja ComfortOpenPos mit 99 und damit dem selben Wert wie Open angegeben hast.

Grüße

[Wardancer]

Top! Danke... ich check dann morgen aus und werde berichten

[Wardancer]

Der Fix klappt!

Danke fürs fixen!

[Darkwing Duck]

Ich versuche bereits seit einiger Zeit erfolglos, meine Xiaomi Aqara Fensterkontakte in Verbindung mit  AutoShuttersControl zu nutzen. Die Fensterkontakte sind über Zigbee2Mqtt als MQTT2_Device in FHEM eingebunden. Erst durch die Beiträge von Wardancer ist mir aufgefallen, dass bei diesen Devices (im Gegensatz zu einem Homematic-Drehgriffsensor, der quasi "OOTB" mit Autoshutterscontrol funktioniert) ebenfalls kein "State"-Reading vorhanden ist (lediglich das Internal "STATE"). Verstehe ich das also richtig, dass ich ein UserReading mit dem Namen "State" benötige, das die Zustände "Open" und "Closed" kennt?

[Beta-User]

Du könntest "contact" auch via $JSONMAP nach "state" bringen, wäre m.E. die bessere Lösung. Würde dazu tendieren, das dann auch so in das attrTemplate einzubauen. Bitte melden, wenn du Hilfe brauchst.

@CoolTux: Eventuell wäre es insgesamt eine Idee, auch hier DEVICE[:READING] zu ermöglichen (geht jedenfalls lt. cref nicht), so wie beim ASC_windSensor? Der Sensor hier ist sicher nicht der erste oder letzte, der uns "quer" kommt...