[73_AutoShuttersControl.pm] - aktuelle Entwicklerversionen zum testen

[majestro84]

Das sollte mit der neusten Entwicklerversion aber nicht mehr der Fall sein.

Ich nutze aktuell die 0.4.0.11beta69

Hattest du dir das auch mit den Brightness angeguckt das wenn das Fenster gekippt ist zum Beispiel beim schließen nicht mehr in die ventilate Pos. Gefahren wird sondern es komplett offen bleibt. Und auch nach dem schließen die Fahrt nicht nachgeholt wird. Das hat vorher irgendwann Mal funktioniert.

[CoolTux]

Ich nutze aktuell die 0.4.0.11beta69

Hattest du dir das auch mit den Brightness angeguckt das wenn das Fenster gekippt ist zum Beispiel beim schließen nicht mehr in die ventilate Pos. Gefahren wird sondern es komplett offen bleibt. Und auch nach dem schließen die Fahrt nicht nachgeholt wird. Das hat vorher irgendwann Mal funktioniert.

Das ist aber so gewollt. Wenn das Fenster geschlossen wird soll ja gerade nicht in die ventilate Position gefahren werden. Da wird nur hingefahren wenn es gekippt wird.

Oder meinst das Rolllo soll geschlossen werden wenn der Brightnesswert unterhalb des Abendwertes steht? Da habe ich ein bisschen was gemacht, muss aber mal schauen wie es sich aktuell aus wirkt. Gerade das Erkennen von Tag und Nacht wurde noch mal bearbeitet.

[majestro84]

Also vorher war es so Fenster tagsüber gekippt. Dann ist der Wert unter min gefallen, Fenster immer noch gekippt, Rollo fährt in ventilate Pos. Wenn ich dann später am Abend das Fenster schließe fährt das Rollo komplett runter. So war es Mal.

Jetzt ist es so daß das Rollo bei gleicher Situation sich überhaupt nicht bewegt selbst beim Fenster schließen am Abend muss ich manuell schließen. Da auch die Fahrt zum kompletten schließen nicht nachgeholt wird.

[CoolTux]

Also vorher war es so Fenster tagsüber gekippt. Dann ist der Wert unter min gefallen, Fenster immer noch gekippt, Rollo fährt in ventilate Pos. Wenn ich dann später am Abend das Fenster schließe fährt das Rollo komplett runter. So war es Mal.

Jetzt ist es so daß das Rollo bei gleicher Situation sich überhaupt nicht bewegt selbst beim Fenster schließen am Abend muss ich manuell schließen. Da auch die Fahrt zum kompletten schließen nicht nachgeholt wird.

Ah, das klingt schon ganz anders. Ich schaue.

[stefanpf]

Habe vor 6 min ein shadding in bei geöffneter Tür beobachtet.
Logs müsste ich später sammeln... (Hänge gerade am Handy)

[CoolTux]

Habe vor 6 min ein shadding in bei geöffneter Tür beobachtet.
Logs müsste ich später sammeln... (Hänge gerade am Handy)

Das ist gut möglich. Ich glaube aktuell überschriebt ein Shading so gut wie alles. Ausnahme sind die Blockingzeiten.

[Prof. Dr. Peter Henning]

Das sollte mit der neusten Entwicklerversion aber nicht mehr der Fall sein.

Stimmt - ich hatte die dooferweise nicht gegen das Überschreiben geschützt.

Hänge gerade am Handy

Stelle ich mit interessant vor - meine mobilen Geräte haben keine Haken zum Aufhängen.

LG

pah

[CoolTux]

Ich habe soeben Version 0.5.99.1 in Devel geladen.
Im Grunde habe ich Hauptsächlich die deutsche Commandref sortiert und fehlendes ergänzt sowie Fehler beseitigt die für die Commandref gemeldet wurden.
Heute Abend schaue ich mir noch mal das Thema Fenster und Brightness an.


Komme was wolle. Bis Ende diesen Monats wird es eine Version 0.6.0 geben welche auf Basis der jetzigen 0.5.99.1 und folgende entsteht.

[stefanpf]

Das ist gut möglich. Ich glaube aktuell überschriebt ein Shading so gut wie alles. Ausnahme sind die Blockingzeiten.

Gerade mal grob drüber geschaut: ShadingProcessing() achtet wirklich nicht auf Fenster und Co, allerdings verstehe ich das so, dass die implementierten Sicherheitsabfragen in ShuttersCommandSet($$$) eigentlich hätten greifen müssen.

[CoolTux]

Im Normalfall greifen die Abfragen in der ShuttersCommandSet aber nicht bei Shading. Das ist so beabsichtigt.
Ich werde da aber eine Abfrage für Terrassentür einbauen.

[Karflyer]

Irgendwie stehe ich mit den brightness-attributen auf 'Kriegsfuß'. Ich habe die aktuelle dev-Version 0.5.99.1 im Einsatz.
Im Modul habe ich:
ASC_brightnessDriveUpDown
ASC_brightnessMaxVal
ASC_brightnessMinVal
Am Rolladendevice gibt es dann noch:
ASC_BrightnessSensor

Welche Werte können diese Attribute beinhalten? Bei dem ASC_BrightnessSensor hatte ich mal gelesen, dass der Wert in etwa so lauten könnte 'brightness_eastside:brightness 40:-1'?
Wie wirken die einzelnen Attribute, bzw, wie interagieren sie miteinander? Wie müssten die Werte für die einzelnen Attribute lauten, wenn der Rolladen über brightness gesteuert, Abends bei unterschreiten einer bestimmten Helligkeit zufahren soll?
Wäre schön wenn ich hier ein wenig Aufklärung bekomme.

Gruß
Stefan

[CoolTux]

Es gibt eine Commandref. Wenn man die Developer Version verwendet muss man diese noch von Hand erstellen

Code Auswählen Erweitern


cd /opt/fhem/
/usr/bin/perl contrib/commandref_join


ASC_brightnessMaxVal
ASC_brightnessMinVal

Diese Attribute sind absolete. Wenn man die Commandref hat wird dies auch angezeigt bei der Auswahl.

Das Attribut aus dem ASC Device

Code Auswählen Erweitern

ASC_brightnessDriveUpDown
Hier wird für Morgend rauf und Abends runter die brightness Werte angegeben.

Code Auswählen Erweitern

ASC_brightnessDriveUpDown 600:800

Am Rolladendevice gibt es dann noch:
ASC_BrightnessSensor
Wo Du das Sensor Device für Brightness mit oder ohne Reading an gibst.

Code Auswählen Erweitern

ASC_BrightnessSensor mySensor
Sensor Device ist mySensor und als Reading wird default brightness verwendet

Code Auswählen Erweitern

ASC_BrightnessSensor mySensor:lux
Hier wird als Reading lux verwendet

[stefanpf]

Nichts gravierendes, aber kann es sein, dass shading durcheinander kommt wenn zwischendurch scanforshutters aufruft?
Konkret stand die Südseite auf shading out, aber alle Rollladen blieben unten.

[CoolTux]

Das ist in der Tat möglich. Habe ich so noch nie getestet.

[CoolTux]

Ich habe soeben Version 0.5.99.2 hoch geladen ins Git.
Es sollte nun auch mit Brightness der Korrekte Tagesstatus ermittelt werden.