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

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

Vorheriges Thema - Nächstes Thema

FFHEM

Hallo CoolTux,
hier noch weitere Infos:
Gestern abend ist der manuell hoch gefahrene Rolladen nicht zur geplanten Twilightzeit heruntergefahren.
Deshalb hab ich ihn manuell heruntergefahren.

Geplante Rauffahrzeit war heute morgen: 07:15 Uhr, um diese Zeit stand aber "rain" eigentlich an, es schüttete hier wie aus Kübeln ;-)
Eigentlich dürfte der Rolladen nicht hochfahren, sondern untenbleiben, meine Holzfenster möchte ich vor Regen schützen.
Er fährt aber um 07:15 Uhr hoch!
Im Debug sieht man, dass ASC meint, der RolladenArbeitszimmer sei bei RainProtection "unprotected":


ASC_DEBUG!!! 2021.09.15 07:15:01 - EventProcessingTwilightDevice: Rolladensteuerung - Passendes Event wurde erkannt. Verarbeitung über alle Rollos beginnt

ASC_DEBUG!!! 2021.09.15 07:15:01 - EventProcessingTwilightDevice: RolladenArbeitszimmer RainProtection: unprotected WindProtection: unprotected

ASC_DEBUG!!! 2021.09.15 07:15:01 - FnIsDay: RolladenArbeitszimmer Allgemein: 1

ASC_DEBUG!!! 2021.09.15 07:15:01 - FnIsDay: RolladenArbeitszimmer getDownBrightness: 1 Brightness: 18 BrightnessMin: 500 Sunset: 1

ASC_DEBUG!!! 2021.09.15 07:15:01 - FnIsDay: RolladenArbeitszimmer getUpBrightness: 1 Brightness: 18 BrightnessMax: 800 Sunrise: 0

ASC_DEBUG!!! 2021.09.15 07:15:01 - FnIsDay: RolladenArbeitszimmer Allgemein: 1

ASC_DEBUG!!! 2021.09.15 07:15:01 - FnIsDay: RolladenArbeitszimmer getDownBrightness: 1 Brightness: 18 BrightnessMin: 500 Sunset: 1

ASC_DEBUG!!! 2021.09.15 07:15:01 - FnIsDay: RolladenArbeitszimmer getUpBrightness: 1 Brightness: 18 BrightnessMax: 800 Sunrise: 0

ASC_DEBUG!!! 2021.09.15 07:15:01 - ShadingProcessing: RolladenArbeitszimmer - Übergebende Werte - Azimuth:86.08, Elevation: -0.69, Brightness: 11, OutTemp: 18.0, Azimut Beschattung: 90, Azimut Endschattung: 260, Ist es nach der Zeitblockadezeit: JA, Das Rollo ist in der Beschattung und wurde manuell gefahren: NEIN, Ist es nach der Hälfte der Beschattungswartezeit: JA

ASC_DEBUG!!! 2021.09.15 07:15:01 - ShadingProcessing: RolladenArbeitszimmer - Alle Werte für die weitere Verarbeitung sind korrekt vorhanden und es wird nun mit der Beschattungsverarbeitung begonnen

ASC_DEBUG!!! 2021.09.15 07:15:01 - ShadingProcessing: RolladenArbeitszimmer - Einer der Beschattungsbedingungen wird nicht mehr erfüllt und somit wird der Beschattungsstatus um eine Stufe reduziert. Alter Status: out Neuer Status: out

ASC_DEBUG!!! 2021.09.15 07:15:01 - FnIsDay: RolladenArbeitszimmer Allgemein: 1

ASC_DEBUG!!! 2021.09.15 07:15:01 - FnIsDay: RolladenArbeitszimmer getDownBrightness: 1 Brightness: 18 BrightnessMin: 500 Sunset: 1

ASC_DEBUG!!! 2021.09.15 07:15:01 - FnIsDay: RolladenArbeitszimmer getUpBrightness: 1 Brightness: 18 BrightnessMax: 800 Sunrise: 0

ASC_DEBUG!!! 2021.09.15 07:15:01 - FnIsDay: RolladenArbeitszimmer Allgemein: 1

ASC_DEBUG!!! 2021.09.15 07:15:01 - FnIsDay: RolladenArbeitszimmer getDownBrightness: 1 Brightness: 18 BrightnessMin: 500 Sunset: 1

ASC_DEBUG!!! 2021.09.15 07:15:01 - FnIsDay: RolladenArbeitszimmer getUpBrightness: 1 Brightness: 18 BrightnessMax: 800 Sunrise: 0

ASC_DEBUG!!! 2021.09.15 07:15:01 - EventProcessingTwilightDevice: RolladenArbeitszimmer - Alle Bedingungen zur weiteren Beschattungsverarbeitung sind erfüllt. Es wird nun die Beschattungsfunktion ausgeführt

ASC_DEBUG!!! 2021.09.15 07:15:01 - EventProcessingTwilightDevice: RolladenFlur RainProtection: unprotected WindProtection: unprotected

ASC_DEBUG!!! 2021.09.15 07:15:01 - FnIsDay: RolladenFlur Allgemein: 1

ASC_DEBUG!!! 2021.09.15 07:15:01 - FnIsDay: RolladenFlur getDownBrightness: 1 Brightness: 21 BrightnessMin: 500 Sunset: 1



Um ca. 08:55 Uhr kam wieder "rain", und da fuhren die Rolladen wieder herunter.
Sieht so aus, als käme ASC bei einer manuellen Fahrt während Regens mit den Zuständen durcheinander.
Raspberry Pi 4B, Homematic, Sonoff, Shelly, Worx, Arduino, ESP8266

kjmEjfu

Zitat von: balli1187 am 15 September 2021, 08:55:59
ich habe auch mal versucht in den Modul-Code zu schauen aber dort leider kaum was verstanden  ???
Auf welche roommate Stati oder nach welcher Logik reagiert denn ASC hier überhaupt?
Können sich die Einstellungen in den einzelnen Rollläden mit dem globalen ResidentsDev im ASC-Modul in die Quere kommen?

Zu welcher Uhrzeit stehen deine Roommates denn auf?
Eventuell passen die Default-Werte von ASC_Time_Up_Early  und ASC_Time_Up_Late nicht?

Ohne Roommate fährt das Rollo aber hoch?
Du könntest mal ausprobieren bei ASC_Up was anderes einzustellen, so dass es grundsätzlich passt.
Sobald du dann einen Roommate ergänzt, wird der automatisch (unabhängig von ASC_Up) berücksichtigt und morgens nicht hochgefahren, solange der auf "asleep" gesetzt ist. Hab damit z.B. eingestellt, dass das Schlafzimmerrollo automatisch hochfährt, wenn wir nicht zuhause sind. Aber wenn wir zuhause sind, fährt es erst dann hoch, beide aufgestanden sind.

Du könntest auch mal probieren, ob es funktioniert, wenn du statt dem Struct nur ein Roommate hinterlegst. Dann könnte man den Fehler eingrenzen.
Migriere derzeit zu Home Assistant

CoolTux

Zitat von: FFHEM am 15 September 2021, 09:06:17
Hallo CoolTux,
hier noch weitere Infos:
Gestern abend ist der manuell hoch gefahrene Rolladen nicht zur geplanten Twilightzeit heruntergefahren.
Deshalb hab ich ihn manuell heruntergefahren.

Geplante Rauffahrzeit war heute morgen: 07:15 Uhr, um diese Zeit stand aber "rain" eigentlich an, es schüttete hier wie aus Kübeln ;-)
Eigentlich dürfte der Rolladen nicht hochfahren, sondern untenbleiben, meine Holzfenster möchte ich vor Regen schützen.
Er fährt aber um 07:15 Uhr hoch!
Im Debug sieht man, dass ASC meint, der RolladenArbeitszimmer sei bei RainProtection "unprotected":


ASC_DEBUG!!! 2021.09.15 07:15:01 - EventProcessingTwilightDevice: Rolladensteuerung - Passendes Event wurde erkannt. Verarbeitung über alle Rollos beginnt

ASC_DEBUG!!! 2021.09.15 07:15:01 - EventProcessingTwilightDevice: RolladenArbeitszimmer RainProtection: unprotected WindProtection: unprotected

ASC_DEBUG!!! 2021.09.15 07:15:01 - FnIsDay: RolladenArbeitszimmer Allgemein: 1

ASC_DEBUG!!! 2021.09.15 07:15:01 - FnIsDay: RolladenArbeitszimmer getDownBrightness: 1 Brightness: 18 BrightnessMin: 500 Sunset: 1

ASC_DEBUG!!! 2021.09.15 07:15:01 - FnIsDay: RolladenArbeitszimmer getUpBrightness: 1 Brightness: 18 BrightnessMax: 800 Sunrise: 0

ASC_DEBUG!!! 2021.09.15 07:15:01 - FnIsDay: RolladenArbeitszimmer Allgemein: 1

ASC_DEBUG!!! 2021.09.15 07:15:01 - FnIsDay: RolladenArbeitszimmer getDownBrightness: 1 Brightness: 18 BrightnessMin: 500 Sunset: 1

ASC_DEBUG!!! 2021.09.15 07:15:01 - FnIsDay: RolladenArbeitszimmer getUpBrightness: 1 Brightness: 18 BrightnessMax: 800 Sunrise: 0

ASC_DEBUG!!! 2021.09.15 07:15:01 - ShadingProcessing: RolladenArbeitszimmer - Übergebende Werte - Azimuth:86.08, Elevation: -0.69, Brightness: 11, OutTemp: 18.0, Azimut Beschattung: 90, Azimut Endschattung: 260, Ist es nach der Zeitblockadezeit: JA, Das Rollo ist in der Beschattung und wurde manuell gefahren: NEIN, Ist es nach der Hälfte der Beschattungswartezeit: JA

ASC_DEBUG!!! 2021.09.15 07:15:01 - ShadingProcessing: RolladenArbeitszimmer - Alle Werte für die weitere Verarbeitung sind korrekt vorhanden und es wird nun mit der Beschattungsverarbeitung begonnen

ASC_DEBUG!!! 2021.09.15 07:15:01 - ShadingProcessing: RolladenArbeitszimmer - Einer der Beschattungsbedingungen wird nicht mehr erfüllt und somit wird der Beschattungsstatus um eine Stufe reduziert. Alter Status: out Neuer Status: out

ASC_DEBUG!!! 2021.09.15 07:15:01 - FnIsDay: RolladenArbeitszimmer Allgemein: 1

ASC_DEBUG!!! 2021.09.15 07:15:01 - FnIsDay: RolladenArbeitszimmer getDownBrightness: 1 Brightness: 18 BrightnessMin: 500 Sunset: 1

ASC_DEBUG!!! 2021.09.15 07:15:01 - FnIsDay: RolladenArbeitszimmer getUpBrightness: 1 Brightness: 18 BrightnessMax: 800 Sunrise: 0

ASC_DEBUG!!! 2021.09.15 07:15:01 - FnIsDay: RolladenArbeitszimmer Allgemein: 1

ASC_DEBUG!!! 2021.09.15 07:15:01 - FnIsDay: RolladenArbeitszimmer getDownBrightness: 1 Brightness: 18 BrightnessMin: 500 Sunset: 1

ASC_DEBUG!!! 2021.09.15 07:15:01 - FnIsDay: RolladenArbeitszimmer getUpBrightness: 1 Brightness: 18 BrightnessMax: 800 Sunrise: 0

ASC_DEBUG!!! 2021.09.15 07:15:01 - EventProcessingTwilightDevice: RolladenArbeitszimmer - Alle Bedingungen zur weiteren Beschattungsverarbeitung sind erfüllt. Es wird nun die Beschattungsfunktion ausgeführt

ASC_DEBUG!!! 2021.09.15 07:15:01 - EventProcessingTwilightDevice: RolladenFlur RainProtection: unprotected WindProtection: unprotected

ASC_DEBUG!!! 2021.09.15 07:15:01 - FnIsDay: RolladenFlur Allgemein: 1

ASC_DEBUG!!! 2021.09.15 07:15:01 - FnIsDay: RolladenFlur getDownBrightness: 1 Brightness: 21 BrightnessMin: 500 Sunset: 1



Um ca. 08:55 Uhr kam wieder "rain", und da fuhren die Rolladen wieder herunter.
Sieht so aus, als käme ASC bei einer manuellen Fahrt während Regens mit den Zuständen durcheinander.

Aus dem Log schließe ich das für ASC es noch immer Nacht war. Hast Du auch Logauszüge vom Mittag? Wichtig ist hier

ASC_DEBUG!!! 2021.09.15 07:15:01 - FnIsDay: RolladenArbeitszimmer getDownBrightness: 1 Brightness: 18 BrightnessMin: 500 Sunset: 1

ASC_DEBUG!!! 2021.09.15 07:15:01 - FnIsDay: RolladenArbeitszimmer getUpBrightness: 1 Brightness: 18 BrightnessMax: 800 Sunrise: 0


Sunset muss 0 sein und Sunrise 1.
Aktuell ist der Brightness Wert auch unterhalb des BrightnessMax. Also noch Nacht.
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

Hallo CoolTux,
Mein Debugauszug ging nur bis 07:15:01, Entschuldigung!
Der RolladenArbeitszimmer ist aber, wie ich schrieb, um 07:15:02 ( = ASC_Time_Up_Early) hochgefahren. Er hätte wegen des anstehenden Regens aber unten bleiben müssen (so mein Verständnis).

ASC_DEBUG!!! 2021.09.15 07:15:02 - FnSetCmdFn: RolladenArbeitszimmer - Rollo wird gefahren, aktuelle Position: 0, Zielposition: 100. Grund der Fahrt: day open
2021.09.15 07:15:02 3: MQTT2_DEVICE set RolladenArbeitszimmer pct 100

ASC_DEBUG!!! 2021.09.15 07:15:02 - FnSetDriveCmd: RolladenArbeitszimmer - NICHT versetztes fahren

ASC_DEBUG!!! 2021.09.15 07:15:02 - FnSetDriveCmd: RolladenArbeitszimmer - NoDelay: NEIN

ASC_DEBUG!!! 2021.09.15 07:15:02 - FnShuttersCommandSet: RolladenArbeitszimmer - Das Rollo wird gefahren. Kein Partymodus aktiv und das zugordnete Fenster ist entweder nicht offen oder keine Terassentür

ASC_DEBUG!!! 2021.09.15 07:15:02 - FnSetDriveCmd: RolladenWohnzimmerLinks - NICHT versetztes fahren

ASC_DEBUG!!! 2021.09.15 07:15:02 - FnSetDriveCmd: RolladenWohnzimmerLinks - NoDelay: NEIN


Meiner Meinung nach müsste in FnShuttersCommandSet:
FnShuttersCommandSet: RolladenArbeitszimmer - Das Rollo wird gefahren. Kein Partymodus aktiv und das zugordnete Fenster ist entweder nicht offen oder keine Terassentür
die Prüfung auf Regen hineinkommen.

Das scheint mir aber nur ein Nebeneffekt zu sein, Hauptproblem ist die manuelle Hochfahrt, nachdem Regenschutz angefahren wurde und der Rolladen unten ist.
Das bringt die Zustandsmaschine in einen Zustand, der zur Komplikation führt.
Danach "glaubt" ASC, dass es immer noch im Regenschutz (also unten) wäre und fährt dann bei einem erneuten Regen nicht mehr herunter und ignoriert auch die Schattierung.
Manchmal fängt sich der Rolladen dann nach einer abendlichen Runterfahrt, aber dies auch nicht immer.

Raspberry Pi 4B, Homematic, Sonoff, Shelly, Worx, Arduino, ESP8266

CoolTux

Zitat von: FFHEM am 17 September 2021, 10:02:19
Hallo CoolTux,
Mein Debugauszug ging nur bis 07:15:01, Entschuldigung!
Der RolladenArbeitszimmer ist aber, wie ich schrieb, um 07:15:02 ( = ASC_Time_Up_Early) hochgefahren. Er hätte wegen des anstehenden Regens aber unten bleiben müssen (so mein Verständnis).

ASC_DEBUG!!! 2021.09.15 07:15:02 - FnSetCmdFn: RolladenArbeitszimmer - Rollo wird gefahren, aktuelle Position: 0, Zielposition: 100. Grund der Fahrt: day open
2021.09.15 07:15:02 3: MQTT2_DEVICE set RolladenArbeitszimmer pct 100

ASC_DEBUG!!! 2021.09.15 07:15:02 - FnSetDriveCmd: RolladenArbeitszimmer - NICHT versetztes fahren

ASC_DEBUG!!! 2021.09.15 07:15:02 - FnSetDriveCmd: RolladenArbeitszimmer - NoDelay: NEIN

ASC_DEBUG!!! 2021.09.15 07:15:02 - FnShuttersCommandSet: RolladenArbeitszimmer - Das Rollo wird gefahren. Kein Partymodus aktiv und das zugordnete Fenster ist entweder nicht offen oder keine Terassentür

ASC_DEBUG!!! 2021.09.15 07:15:02 - FnSetDriveCmd: RolladenWohnzimmerLinks - NICHT versetztes fahren

ASC_DEBUG!!! 2021.09.15 07:15:02 - FnSetDriveCmd: RolladenWohnzimmerLinks - NoDelay: NEIN


Meiner Meinung nach müsste in FnShuttersCommandSet:
FnShuttersCommandSet: RolladenArbeitszimmer - Das Rollo wird gefahren. Kein Partymodus aktiv und das zugordnete Fenster ist entweder nicht offen oder keine Terassentür
die Prüfung auf Regen hineinkommen.

Das scheint mir aber nur ein Nebeneffekt zu sein, Hauptproblem ist die manuelle Hochfahrt, nachdem Regenschutz angefahren wurde und der Rolladen unten ist.
Das bringt die Zustandsmaschine in einen Zustand, der zur Komplikation führt.
Danach "glaubt" ASC, dass es immer noch im Regenschutz (also unten) wäre und fährt dann bei einem erneuten Regen nicht mehr herunter und ignoriert auch die Schattierung.
Manchmal fängt sich der Rolladen dann nach einer abendlichen Runterfahrt, aber dies auch nicht immer.

Wird denn bei Dir im allgemeinen eine manuelle Fahrt erkannt? Eigentlich sollte ja immer nach einer manuellen Fahrt im Reading LastDrive manual stehen.
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 18 September 2021, 08:57:32
Wird denn bei Dir im allgemeinen eine manuelle Fahrt erkannt? Eigentlich sollte ja immer nach einer manuellen Fahrt im Reading LastDrive manual stehen.
Ja, wird immer richtig erkannt:
ASC_ShuttersLastDrive
manual
2021-09-18 09:25:14


Habe das noch einmal getestet, wenn durch "rain" der Rolladen unten ist:


ASC_ShuttersLastDrive
rain protected
2021-09-18 09:27:54


Und dann manuell hochgefahren:

ASC_ShuttersLastDrive
manual
2021-09-18 09:28:51


Das sieht also alles so aus, wie es sein soll
Raspberry Pi 4B, Homematic, Sonoff, Shelly, Worx, Arduino, ESP8266

FFHEM

Ich habe jetzt noch einen Test gemacht, um herauszufinden, ob nur die aktuelle Position ASC im Regenschutz verwirrt. Ist aber nicht der Fall, es liegt alleine am manuellen Betätigen überhaupt:

Bisher war ja immer "rain" -> Rolladen fährt runter, "manuell hoch", "dry" -> Rolladen reagiert nicht mehr auf Regen
Jetzt habe ich einmal "rain" -> Rolladen fährt runter , "manuell hoch", "manuell runter", "dry" -> Rolladen reagiert hier aber auch nicht mehr auf Regen

Wie früher auch, wird jetzt die Schattierung eingefroren, hier auf 09:20:01 Uhr (es ist jetzt 09:40 Uhr) und ändert sich den ganzen Tag nicht mehr bis zur nächsten morgendlichen Auffahrt.
ASC_ShadingMessage
INFO: current shading status is 'out' - next check in 10m
2021-09-18 09:20:01
Raspberry Pi 4B, Homematic, Sonoff, Shelly, Worx, Arduino, ESP8266

kjmEjfu

Ich wäre übrigens dafür den Thread zu schließen, so dass dann pro Thema wieder ein einzelner Thread eröffnet werden muss.
Das ist hier mittlerweile wahnsinnig unübersichtlich geworden. Man muss mehr Zeit investieren um zu verstehen, welcher Beitrag zu welchem eigentlichen Thema gehört, als für die Tipps.
Migriere derzeit zu Home Assistant

Reinhard.M

Zitat von: kjmEjfu am 18 September 2021, 10:51:55
Ich wäre übrigens dafür den Thread zu schließen, so dass dann pro Thema wieder ein einzelner Thread eröffnet werden muss.
Das ist hier mittlerweile wahnsinnig unübersichtlich geworden. Man muss mehr Zeit investieren um zu verstehen, welcher Beitrag zu welchem eigentlichen Thema gehört, als für die Tipps.
Das kann ich nur voll und ganz unterstützen. Gerne eine Gruppe ASC und darunter separate Threads für spezielle Fragen/Fehler. In mehr als 130 Seiten findet man nichts mehr, leider.

sukram

Zitat von: Beta-User am 08 September 2021, 21:38:16
Aber ich bin weiter der Ansicht, dass das auf (Modbus-) Modulebene zu lösen wäre, wenn man _immer_ eine (gleichbleibende) Art "post-processing" braucht.

Hallo Beta,

noch eine kurze Rückmeldung: Es funktioniert!
Stand jetzt habe ich mit eventMap die 11 Positionen von 0-100% in 10er Schritten mit gesetztem Bit (also 0-100 + 1024) hinterlegt; die Leserichtung läuft über die userReading und Maskierung 0x00FF. Um das Steuerbit dann wieder zurückzusetzen, kommt ein Notify auf ein separates userReading mit Maskierung auf 0xFF00. Damit läuft die Ansteuerung aus ASC heraus erstmal für Morgens/Abends. Regen oder Sonnenerkennung nutze ich derzeit nicht, daher kann ich mit der groben Abstufung erstmal leben.

Eigentlich wollte ich das eventMap rechnen lassen, aber mit der Perl-Notation bin ich echt nicht zurecht gekommen...

Weiter kann ich leider gerade nicht berichten, mir ist gestern Abend die HDD meines Servers mit defekten Sektoren abgeklappert  >:( Da muss ich erstmal das System wieder an den Start bringen. Positiv ist allerdings in der Situation, dass FHEM "nur" zusätzlich Komfort obendrauf bringt und nicht elementar wichtig für den Betrieb ist - der Grundbetrieb wird durch die SPS abgewickelt.

Beta-User

Zitat von: sukram am 19 September 2021, 11:08:37
noch eine kurze Rückmeldung: Es funktioniert!
Danke für die Rückmeldung, auch wenn sich das mit der HDD nicht so lustig liest....

Dennoch bin ich weiter der Ansicht, dass es sinnvoll wäre, das "post-processing" DIREKT im MODUL-Code abfangen zu können, indem man eine Art "mache das immer hinterher"-Anweisung (als Attribut, z.B.) hinterlegt. Dafür weiteren Code zu brauchen (und eventMap) ist suboptimal, und es wäre - jedenfalls auf den ersten Blick - mAn. kein größeres Problem, sowas in den Code mit reinzunehmen.

Daher die Frage: Hast du mal den betreffenden Modul-Maintainer kontaktiert?

Ansonsten (wenn dieser das nicht umsetzen will): Es wäre schön, wenn du deine gesamte Lösung dann bei "mit ASC getestete Hardware" posten könntest.
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

Guten Morgen CoolTux :)
Ich bin weiterhin damit beschäftigt meine Jalousiesteuerung "sauber" in den Griff zu kriegen. Zur Erinnerung: Homematic-IP Device HmIP-FBL. Die Lamellensteuerung funktioniert bei diesem Device ja nur über einen Doppelbefehl in der Form
set <device> datapoint 4.LEVEL_2  66 4.LEVEL   3
um zum Beispiel die Lamellen auf 66% einzustellen. Ich hatte dazu ja bereits hier eine Umsetzungsmöglichkeit mit eventMap in der Form
'^pctslt(.*),(.*)' => 'datapoint 4.LEVEL_2 $2  4.LEVEL $1'
gepostet. Die Werte der Positionsattribute habe ich dann in der Form "3,66" angegeben um beim obigen Beispiel zu bleiben. Außerdem hatte ich natürlich die ASC_Pos_Reading auf "pctslt" gesetzt.
Das funktionierte soweit ganz gut, insbesondere konnte ich so auch das External_Device mit einer Positionsangabe verwenden. Dann habe ich deine Test-Version mit den Änderungen von Beta-User eingespielt und es ging nichts mehr. Nach der Rückstellung auf die stabile Version sind mir jede Menge Perl Warnings im ASC Modul aufgefallen. Alle in der Form "Numerischer Vergleich, Wert ist aber nicht numerisch". Klar, "3,66" ist nicht numerisch.
Somit habe ich versucht, das Problem mit festen Zuordnungen in der Form
'TV_Pos'           => 'datapoint 4.LEVEL_2  66 4.LEVEL   3'
zu lösen. Als Positionsnamen habe ich die Attributnamen ohne das führende "ASC_" verwendet, also beispielsweise "Ventilate_Pos". Das funktioniert jetzt soweit wieder ganz gut. Deterministisch ist das Verhalten des ASC Moduls dabei aber nicht, was aber wohl noch ein grundsätzliches Thema ist. Dabei sind mir folgende Ungereimtheiten aufgefallen:

  • In der Commandref steht, dass eine feste Zuordnung in der Form "attr ROLLONAME ASC_Shading_Pos 30:Beschattung" anzugeben ist. Also "<Position>:<FesteZuordnung>". Das funktioniert bei mir nicht. Statt dessen funktioniert "attr ROLLONAME ASC_Shading_Pos Beschattung" problemlos. Ist die Commandref falsch oder ist das ein Bug im Modul? Falls es ein Bug im Modul ist bitte so drin lassen.
  • Die festen Zuordnungen machen Probleme beim "set" wenn sie sehr ähnlich sind wie z.B. Open_Pos und ComfortOpen_Pos. Wenn ich ComfortOpen_Pos aufrufe wird Open_Pos angefahren. Erst wenn ich auf Comfort_Pos ändere werden immer die richtigen Positionen angefahren. Das ist eigentlich nicht dein Thema, wem könnte ich das melden?
Das scheint mir derzeit die beste und stabilste Lösung zu sein. Sie funktioniert auf allen Positionsangaben und auch auf dem External_Device das du ja bislang für Lamellensteuerung noch nicht umgestellt hast. Kannst du mir bitte zu meinen 2 Punkten ein kurzes Feedback geben?

Gruß Reinhard

Beta-User

Dann habe ich deine Test-Version mit den Änderungen von Beta-User eingespielt und es ging nichts mehr.
@CoolTux: Das kann dann m.E. eigentlich nur daran liegen, dass HMCCUDEV dort mit aufgenommen wurde und dann hart ein anderer setter verwendet wird .

@Reinhart.M:
Du könntest das testweise auskommentieren (in ./lib/Automation/ShuttersControl.pm), und dann mal versuchen, den Punkt als Trenner zu verwenden. Den müßtest du dann aber maskieren
'^pctslt(\d+)\.(\d+)' => 'datapoint 4.LEVEL_2 $2  4.LEVEL $1'

Anmerkung: Wieso nicht direkt mit pct arbeiten und die Angaben umdrehen? Ins Unreine:

'^pct(\d+)[.]?(\d*)' => $2 ? 'datapoint 4.LEVEL_2 $1  4.LEVEL $2' : 'datapoint 4.LEVEL_2 $1'
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

Zitat von: Beta-User am 19 September 2021, 11:48:05
@Reinhart.M:
Du könntest das testweise auskommentieren (in ./lib/Automation/ShuttersControl.pm), und dann mal versuchen, den Punkt als Trenner zu verwenden. Den müßtest du dann aber maskieren
'^pctslt(\d+)\.(\d+)' => 'datapoint 4.LEVEL_2 $2  4.LEVEL $1'

Anmerkung: Wieso nicht direkt mit pct arbeiten und die Angaben umdrehen? Ins Unreine:

'^pct(\d+)[.]?(\d*)' => $2 ? 'datapoint 4.LEVEL_2 $1  4.LEVEL $2' : 'datapoint 4.LEVEL_2 $1'
Danke für die schnelle Reaktion, wäre auch eine interessante Lösung. Behalte ich auf alle Fälle im Hinterkopf. Momentan habe ich aber mehr die Ablaufsteuerung des Moduls im Fokus. Es gibt immer noch Fälle, dass die Jalousie gestern automatisch aus der TV_Pos in die Closed_Pos gefahren ist, heute aber nicht. Trotz scheinbar gleicher Randbedingungen. Da möchte ich erst einmal mehr Klarheit erlangen um besseres Feedback bezüglich Verhalten/Fehlverhalten geben zu können. Dann nehme ich deinen Vorschlag gerne wieder auf und teste ihn mal.

Beta-User

THX für die Rückmeldung, allerdings war das mit dem Punkt sich zu kurz gedacht; dann passen nämlich die Vergleiche nicht mehr... Sorry.
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