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

Begonnen von CoolTux, 22 Juni 2020, 12:38:36

Vorheriges Thema - Nächstes Thema

Reinhard.M

Zitat von: marvin78 am 22 Oktober 2021, 18:28:03
Nachtrag: Kannst du mit die Probleme mit den Positionen mal genauer erläutern? Danke.

Komme morgen darauf zurück, habe heute keine Zeit mehr.

marvin78

Zitat von: Beta-User am 22 Oktober 2021, 18:34:42
@marvin78:Evtl. kannst du einen patch erstellen? Eine Art ASC_commandTemplate-Attribut, z.B.?

Danke für den Vorschlag. Aber an dieses Modul gehe ich bei meiner geringen Zeit sicher nicht ran. Ich habe eine funktionierende myUtils ohne ASC dafür. Ich steuere hier nur abends runter und morgens wieder hoch. Es ist nicht einmal für mich, sondern für die Schwiegermutter. So groß scheint die Not auch nicht zu sein. Sonst wäre es hei der Historie des Moduls längst drin....

marvin78

Zitat von: Reinhard.M am 22 Oktober 2021, 18:48:21
Komme morgen darauf zurück, habe heute keine Zeit mehr.

Ok Danke. Morgen reicht völlig. Schönen Abend!

Beta-User

Zitat von: marvin78 am 22 Oktober 2021, 19:15:52
So groß scheint die Not auch nicht zu sein. Sonst wäre es hei der Historie des Moduls längst drin....
Na ja, bei der Entwicklung wurden halt von vornherein zum einen viele Fälle abgefangen, und zum anderen sind Jalousien halt nicht ganz so verbreitet wie "rauf-runter"-Rollläden - Jalousien kam erst mit Version 0.9.

@CoolTux: Da afaik alle Fahrbefehle irgendwo über zentralen Code laufen, kann es eigentlich nicht so schwer sein, da noch eine weitere Prüfung reinzubasteln, um diesen ganzen Sonderfälle auch noch zu erfassen.
Vielleicht magst du dich wenigstens dazu äußern, notfalls mache ich dann bei Gelegenheit auch einen Vorschlag dazu, selbst wenn es für meine Zwecke nicht (mehr) erforderlich ist.

@marvin78:
Für meine Jalousien auf CUL_HM-Rollladenaktor-Basis hatte ich früher mal einen Code, der mit einer (zentralen) dummy+notify-Konstruktion dann die "Lamellen"-Anweisung mißbraucht hat, um die Fahranweisungen zu korrigieren. Müßte eigentlich bei "getesteter Hardware" zu finden sein, sonst suche ich das bei Interesse auch nochmal raus. Irgendwie sagt mein Bauchgefühl, dass das kompatibler ist wie die "Punkt-Lösung"...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Reinhard.M

Mit der Punkt Lösung fahre ich inzwischen sehr gut. Die Jalousie reagiert aus allen Positionen wie sie soll. Warum das jetzt so ist kann ich aber nicht genau sagen, leider sperrte sich ASC gegeben alle diesbezüglich Debugging Versuche. Werde in meiner Antwort an Marvin78 noch darauf eingehen.

CoolTux

Zitat von: FFHEM am 22 Oktober 2021, 15:38:06
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ß

Ich habe da etwas gefunden und geändert. Kannst Du das bitte einmal testen?

Entweder Du nimmst den testing Branch in Dein Update mit auf sofern noch nicht geschehen
update add https://git.cooltux.net/FHEM/mod-AutoShuttersControl/raw/branch/testing/controls_AutoShuttersControl.txt
und machst dann ein update, oder Du kopierst Dir nur die Rainprotection.pm in Dein FHEM Verzeichnis nach "lib/FHEM/Automation/ShuttersControl/".

https://git.cooltux.net/FHEM/mod-AutoShuttersControl/raw/branch/testing/lib/FHEM/Automation/ShuttersControl/Rainprotection.pm



Grüße
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

Reinhard.M

Hallo CoolTux,
ich habe in einem meiner Devices ein Verhalten das ich schlicht nicht verstehe, ich hoffe du kannst mir helfen.
Es geht um das Reading "ASC_ShuttersLastDrive". Bei meinem HmIP Jalousie Device wird es von ASC weder angelegt noch upgedated. Intern wird es aber sehr wohl verwaltet was ich mit einem {ascAPIget('LastDrive', 'HM_JAU_Jalousie')} überprüft habe. Dort wird korrekt 'day open' oder 'night closed' angezeigt. Alles funktioniert soweit ich es beurteilen kann einwandfrei. Ich verwende aktuell die offizielle Release von dir.

Gruß Reinhard

CoolTux

Zitat von: Reinhard.M am 23 Oktober 2021, 10:52:17
Hallo CoolTux,
ich habe in einem meiner Devices ein Verhalten das ich schlicht nicht verstehe, ich hoffe du kannst mir helfen.
Es geht um das Reading "ASC_ShuttersLastDrive". Bei meinem HmIP Jalousie Device wird es von ASC weder angelegt noch upgedated. Intern wird es aber sehr wohl verwaltet was ich mit einem {ascAPIget('LastDrive', 'HM_JAU_Jalousie')} überprüft habe. Dort wird korrekt 'day open' oder 'night closed' angezeigt. Alles funktioniert soweit ich es beurteilen kann einwandfrei. Ich verwende aktuell die offizielle Release von dir.

Gruß Reinhard

Hallo Reinhard,

Es gibt im FHEM Ordner unter lib/FHEM/Automation/ShuttersControl/ die Datei Shutters.pm. Dort gibt es in ~ Zeile 339 die Funktion "setLastDriveReading {"
Ändere bitte einmal die Zeile
    ::InternalTimer( ::gettimeofday() + 0.1,

in

    ::InternalTimer( ::gettimeofday() + 0.5,

und starte FHEM dann neu und schau ob sich im laufe des Tages das Reading "ASC_ShuttersLastDrive" im Rollo anlegt.


Grüße
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

FFHEM

Zitat von: CoolTux am 23 Oktober 2021, 10:15:32
Ich habe da etwas gefunden und geändert. Kannst Du das bitte einmal testen?
Grüße
Gerne, wie kann ich für den Test am effektivsten die Rolladen wieder glauben lassen, es wäre noch Nacht, und sie wären noch nicht hochgefahren? Ich möchte ja nicht bis morgen früh warten.
Es ist jetzt z. B. 11:30 Uhr, die Rolladen sind ja schon oben.
Reicht es, wenn ich die Time_Up_Early manipuliere auf 12:00 Uhr und den Rolladen manuell herunterfahre? (Fürchte ich, geht nicht).
Raspberry Pi 4B, Homematic, Sonoff, Shelly, Worx, Arduino, ESP8266

CoolTux

Zitat von: FFHEM am 23 Oktober 2021, 11:32:58
Gerne, wie kann ich für den Test am effektivsten die Rolladen wieder glauben lassen, es wäre noch Nacht, und sie wären noch nicht hochgefahren? Ich möchte ja nicht bis morgen früh warten.
Es ist jetzt z. B. 11:30 Uhr, die Rolladen sind ja schon oben.
Reicht es, wenn ich die Time_Up_Early manipuliere auf 12:00 Uhr und den Rolladen manuell herunterfahre? (Fürchte ich, geht nicht).

Das ist einfach. Das eigentliche Problem war das die aktuelle Position gleich der Regenposition war und deswegen der Status nicht gesetzt wurde.

Also fahre einfach das Rollo komplett runter. Warte bis ASC_BlockingTime_afterManual vorbei ist oder setze ASC_BlockingTime_afterManual auf 5 oder so. Und dann lass es regnen. Wenn Du dann den Status ausliest sollte protected kommen.
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

Reinhard.M

Zitat von: CoolTux am 23 Oktober 2021, 11:30:36
Hallo Reinhard,

Es gibt im FHEM Ordner unter lib/FHEM/Automation/ShuttersControl/ die Datei Shutters.pm. Dort gibt es in ~ Zeile 339 die Funktion "setLastDriveReading {"
Ändere bitte einmal die Zeile
    ::InternalTimer( ::gettimeofday() + 0.1,

in

    ::InternalTimer( ::gettimeofday() + 0.5,

und starte FHEM dann neu und schau ob sich im laufe des Tages das Reading "ASC_ShuttersLastDrive" im Rollo anlegt.


Grüße

Das hat es leider nicht gebracht. Ich habe die Jalousie von astro auf time umgestellt und die entsprechenden Fahrten mit einem entsprechenden Setting der Zeiten ausgelöst. Intern weiterhin der richtige Wert (night closed, day open) aber weder im Reading noch in der ASC Information Summary. Die rechts daneben stehenden Positionen werden allerdings in der Summary richtig gewechselt und angezeigt. Für den Fall das es etwas auslösen könnte: 'ASC_Shutter_IdleDetection' habe ich ebenfalls gesetzt. Und gerade gelöscht, brachte keine Veränderung.

Ganz nebenbei, ich bin deswegen heute morgen mal flüchtig durch deinen Code gegangen. Die "if the else" Bäume sind schon ganz schön sportlich, Respekt  :D

FFHEM

Zitat von: CoolTux am 23 Oktober 2021, 11:38:33
Das ist einfach. Das eigentliche Problem war das die aktuelle Position gleich der Regenposition war und deswegen der Status nicht gesetzt wurde.

Also fahre einfach das Rollo komplett runter. Warte bis ASC_BlockingTime_afterManual vorbei ist oder setze ASC_BlockingTime_afterManual auf 5 oder so. Und dann lass es regnen. Wenn Du dann den Status ausliest sollte protected kommen.
Wieder mal Bingo! Es kommt "protected"!
Werde das morgen früh noch einmal mit künstlichem Regen vor der Morgenfahrt testen und Rückmeldung geben!
Vielen Dank erst einmal!
Gruß,
Friedhelm
Raspberry Pi 4B, Homematic, Sonoff, Shelly, Worx, Arduino, ESP8266

Reinhard.M

Zitat von: marvin78 am 22 Oktober 2021, 21:28:54
Ok Danke. Morgen reicht völlig. Schönen Abend!

Hallo marvin78,
ich verwende aktuell die offizielle Release v0.10.16. Ich kann also aktuell nur für diese Release eine Aussage machen.
Zunächst habe ich ein entsprechendes eventMap aufgebaut:


attr HM_JAU_Jalousie eventMap {\
usr => {'stop'              => 'datapoint 4.STOP true',\
         'open'              => 'datapoint 4.LEVEL_2 100 4.LEVEL 100',\
         'close'             => 'datapoint 4.LEVEL_2   0 4.LEVEL   0',\
         'Closed_Pos'        => 'datapoint 4.LEVEL_2   0 4.LEVEL   0',\
         'Sleep_Pos'         => 'datapoint 4.LEVEL_2   0 4.LEVEL   1',\
         'Open_Pos'          => 'datapoint 4.LEVEL_2 100 4.LEVEL   2',\
         'TV_Pos'            => 'datapoint 4.LEVEL_2  66 4.LEVEL   3',\
         'Ventilate_Pos'     => 'datapoint 4.LEVEL_2  75 4.LEVEL   4',\
         'Comfort_Pos'       => 'datapoint 4.LEVEL_2 100 4.LEVEL 100',\
         '^sltpct(.*)'       => 'datapoint 4.LEVEL_2  $1 4.LEVEL ".(ReadingsVal($NAME, "4.LEVEL",0))."',\
         '^pctslt(.*)\.(.*)' => 'datapoint 4.LEVEL_2  $2 4.LEVEL $1',\
         '^pct(.*)\.(.*)'    => 'datapoint 4.LEVEL_2  $2 4.LEVEL $1'},\
fw  => {'^sltpct(.*)'       => 'sltpct',\
         '^pctslt(.*)\.(.*)' => 'pctslt',\
         '^pct(.*)\.(.*)'    => 'pct'}\
}


Die einzelnen Positionsbefehle 'xxx_Pos' sind nur "bequem" aber nicht notwendig. 'pctslt' und 'pct' sind in dieser Form aber notwendig, über einen alleine habe ich es bislang nicht hinbekommen da das Reading von 'pct' immer als Integer zurück kommt. 'pct' wird ASC intern zum Ansteuern verwendet, 'pctslt' verwendet ASC als Rückmeldung. 'sltpct' verwende ich um den Winkel der Lamellen unabhängig verändern zu können. Folgende Attribute habe ich spezifisch angelegt:


attr HM_JAU_Jalousie ASC_Pos_Reading pctslt
attr HM_JAU_Jalousie ASC_Closed_Pos 0.0
attr HM_JAU_Jalousie ASC_ComfortOpen_Pos 100.100
attr HM_JAU_Jalousie ASC_ExternalTrigger di_HY:TV_Jalousie TV-On:TV-Off 3.66
attr HM_JAU_Jalousie ASC_Open_Pos 2.100
attr HM_JAU_Jalousie ASC_Sleep_Pos 0.0
attr HM_JAU_Jalousie userReadings pctslt {ReadingsVal($NAME,"pct",0).'.'.ReadingsVal($NAME,"sltpct",0)}
attr HM_JAU_Jalousie webCmd pct:open:stop:close:sltpct
attr HM_JAU_Jalousie widgetOverride pct:selectnumbers,0,1,100,0,lin sltpct:0,25,33,50,66,75,100


Damit lassen sich alle Positionen problemlos ansteuern, auch die für einen external Trigger. Auch wenn ich die Jalousie manuell komplett hoch fahre gibt es keine Problem beim automatischen Schließen durch ASC.
2 Dinge fallen mir aber noch auf. Bei der Einrichtung scheint es die ersten Male immer etwas zu hakeln. Eventuell bin ich schlicht zu ungeduldig und teste nach dem Einrichten zu schnell. Könnte also alleine mein Fehler sein. Der 2. Punkt ist das Reading 'ASC_ShuttersLastDrive'. Das wird bei diesem Device nicht mehr upgedatet. Scheint mir aber eher zu helfen als zu stören. ASC verweigert jetzt jedenfalls nicht mehr die Fahrt wegen "last drive manuel" :)
Das "Problem mit den Positionen" betraf die Positionsüberprüfung. Man darf ja für 2 Positionen (z.B. ASC_Open_Pos, ASC_Closed_Pos) nicht den gleichen Wert verwenden. Warum auch immer scheint das (zumindest bei mir und diesem Device) der Vergangenheit anzugehören. Diese Fälle habe ich noch bei meinem ersten diesbezüglichen Posting gehabt, jetzt aber nicht mehr.

Gruß Reinhard

CoolTux

Zitat von: Reinhard.M am 23 Oktober 2021, 11:58:51
Das hat es leider nicht gebracht. Ich habe die Jalousie von astro auf time umgestellt und die entsprechenden Fahrten mit einem entsprechenden Setting der Zeiten ausgelöst. Intern weiterhin der richtige Wert (night closed, day open) aber weder im Reading noch in der ASC Information Summary. Die rechts daneben stehenden Positionen werden allerdings in der Summary richtig gewechselt und angezeigt. Für den Fall das es etwas auslösen könnte: 'ASC_Shutter_IdleDetection' habe ich ebenfalls gesetzt. Und gerade gelöscht, brachte keine Veränderung.

Ganz nebenbei, ich bin deswegen heute morgen mal flüchtig durch deinen Code gegangen. Die "if the else" Bäume sind schon ganz schön sportlich, Respekt  :D

Dann gehe ich mal davon aus das Deine Rollos länger für eine Fahrt brauchen wie in ASC_DriveUpMaxDuration per default gesetzt ist. Am besten Du setzt das Attribut einmal in ein paar Rollos und zwar mit dem tatsächlichen Wert welche die Rollos zum hochfahren benötigen.
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

Reinhard.M

Zitat von: CoolTux am 23 Oktober 2021, 12:35:15
Dann gehe ich mal davon aus das Deine Rollos länger für eine Fahrt brauchen wie in ASC_DriveUpMaxDuration per default gesetzt ist. Am besten Du setzt das Attribut einmal in ein paar Rollos und zwar mit dem tatsächlichen Wert welche die Rollos zum hochfahren benötigen.

Die aktuell tatsächliche Fahrzeit von Open nach Closed und umgekehrt beträgt bei mir ca. 3 Sekunden da im Grunde nur die Lamellenpositon verändert wird. Ich hatte ASC_DriveUpMaxDuration bereits auf 60 Sekunden gesetzt. War ein wenig knapp bei einer realen Gesamtfahrzeit von 58 Sekunden. Habe den Wert jetzt auf 65 Sekunden gesetzt und erneut getestet. Weiterhin das gleiche Problem, das Reading wird nicht auf den entsprechenden Wert gesetzt. Wie kann ich weiterhelfen um den Fehler zu finden?