[73_AutoShuttersControl.pm] - Info-Thread zu getesteter Hardware

Begonnen von Beta-User, 05 Juni 2019, 14:35:20

Vorheriges Thema - Nächstes Thema

Beta-User

Hallo zusammen,

da immer mal wieder die Frage auftaucht, welche Rollladenaktoren, Fenster- und Türsensoren usw. denn eigentlich von AutoShuttersControl unterstützt werden, aber die betreffenden Antworten dann nur verstreut über diverse Threads wiederzufinden sind, soll dieser Thread als zentrale Anlaufstelle dienen, in der diese Fragen gestellt und beantwortet werden können.

Hier können ggf. auch "workarounds" vorgestellt werden, die man ggf. braucht, um irgendeinen Aktor oder Sensor "ASC-kompatibel" zumachen.

Längere Diskussionen bitte ich aber ggf. mit einem Link hierher ggf. außerhalb zu führen, die Darstellung sollte möglichst "straff" sein (Fragen sind aber erwünscht und erlaubt :) ).

Ggf. wird dies dann letztendlich Eingang ins Wiki finden.

Vorneweg:
Das Modul ist universell aufgebaut und sollte "im Prinzip" mit allen Sensoren und Aktoren umgehen können.


Rollladenaktoren
Bei einer Anzahl von weit verbreiteten Typen (derzeit: ROLLO, CUL_HM, ZWave, Siro, SOMFY, tahoma, KLF200Node, DUOFERN, HM485) sind dazu die notwendigen Einstellungen bereits im Modul berücksichtigt.
In solchen Fällen genügt es, den ASC-Typ per Attribut festzulegen (1= 100% entspricht geschlossen, 2= 0% entspricht geschlossen, oder genereller: 1 = höhere Werte entsprechend einem zunehmenden Schließgrad, 2 = höhere Werte entsprechen einem zunehmenden Öffnungsgrad des Rolladens).
Bei weiteren Rollladenaktortypen genügt es häufig, zusätzlich noch das Reading bzw. den Fahrbefehl zu benennen. Dieser ist häufig dim, pct oder level, wobei derzeit "pct" verwendet wird, wenn nichts anderes angegeben wird.

Tip: Für alle möglichen Systeme, die keine eigene Zeitmessung für die Fahrbefehle kennen (also von sich aus keine Zwischenpositionen ansteuern können), kann das Modul ROLLO genutzt werden. Für dieses sind im Prinzip nur unterschiedliche Befehle für öffnen und schließen sowie Stop-Möglichkeiten erforderlich; es genügen also als Basis 2 unabhängig voneinander arbeitende Relais (empfohlen wird eine solche Konstruktion dennoch nicht, hier besteht immer die Gefahr, bei Problemen mit der logischen Ansteuerung den Motor zu zerstören) oder entsprechende Funksteuersignale. ROLLO übernimmt in solchen Fällen dann die Überwachung der Timer und generiert daraus auch Zwischenpositionen.

Sensoren
Auch hier sollten viele Sensoren funktionieren, für Fenstersenoren sollte dabei open/opened, close/closed bzw. tilt/tilted als Event generiert werden.
Ansonsten sind v.a. bei Wind- und Helligkeitssensoren schlicht die Grenzwerte entsprechend anzupassen.



Damit hier auch noch echter Content steht:
Ich selbst nutze als Rollladenaktor hauptsächlich HM-LC-Bl1PBU-FM (=ASC-Typ 2) unter dem CUL_HM-Modul, was völlig unproblematisch ist, allerdings wenig geeignet für Jalousien (da gab es erst später spezielle Aktoren). Für diese teste ich grade einen ZWave-Aktor (FGR-223 in der Konfiguration als VenetianBlind). Dieser wäre (soweit kurz angetestet) im Prinzip im normalen Roller-Modus ebenfalls unproblematisch (wieder ASC-Typ 2) , wenn man davon absieht, dass ganz geöffnet "dim 99" entspricht. Wenn ich irgendwann rausgefunden haben sollte, wie man die Multi-Channel-Associations richtig macht, kommt auch dazu noch Info.
Bei manchen ZWave-Aktoren scheint es sinnvoll zu sein, dort ein eventMap-Attribut zu setzen. Leider habe ich kein eigenes Beispiel zur Hand, da meine eigenen Konfiguration da im Moment noch nicht final steht, aber wenigstens einen Link.

Als Fenstersensoren sind (unproblematisch) CUL_HM-Geräte im Einsatz (twoState magnetisch an den Türen, threeState Drehgriffkontakte an den Fenstern).



Gefunden habe ich eben noch HMCCUDEV (das scheint bislang nur bei manchen Typen zu klappen).

Viel Spaß beim Sammeln!
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

Wardancer

#1
Hallo,

hier einmal meine Erfahrungen mit meinen Autoren und Sensoren, sowie ASC:

Ich nutze Ausschließlich Z-Wave-Komponennten, und habe bei den Rolladen-Autoren nur die Fibaro Roller-Shutters 2 im Einsatz. Diese funktionieren mittlerweile im Standard ziemlich unproblematisch. Etwas gewöhnungebsdürftig sind die Standard-Einstellungen für Komplett offen: ASC geht hier von 100 % aus, die Fibaros von 99. Das muss in den Attributen evtl. umgestellt werden ( vielleicht könnte man ja auch was spezifisches in den Code übernehmen, da das m.W.n. für alle ZWave-Aktoren so gilt)

Wichtig ist aber auf jeden fall, dass man ein userReading "dim" in den Devices einführt, damit ASC den korrekten Stand der Rolladen auslesen kann. Ich habe das ganze so gelöst:

attr *Device* userReadings dim:reportedState.* { ReadingsNum($name,'reportedState',0)}

(23.02.22) Noch ein wichtiger Zusatz!!:
Ich hab das ganze so problemlos seit fast 3 Jahren am laufen. Ich hatte aber auf einmal immer komischere Zustände beim automatischen Fahren der Rollläden, z.B. beim Lüften. Lösung des Problems waren die nicht mehr ganz exakten Werte für die DIM-Positionen. Daher sollte man nach einiger Zeit noch einmal eine Rekalibrierung machen.

Beta-User hatte noch eine Alternative in seinem UserReading, was ich jetzt einfach mal hier reinposte. Ich nutze das so nicht, aber vielleicht hilft es dem ein oder anderen:

dim:power..0.0.W {my $pos = ReadingsVal($name,"state",0) =~ m,dim, ? ReadingsNum($name,"state",0) : ReadingsNum($name,"dim",0);; my $pos1 = ReadingsNum($name,"position",0);; $pos = $pos1 if ($pos > $pos1 +3 || $pos < $pos1 -3);; return $pos }, positionSlat:power..0.0.W {ReadingsVal($name,"position",0) =~ m,Slat.([0-9]+),?$1:undef}

Bei den Fenster-Sensoren hab ich mittlerweile drei Typen im Einsatz:

* Fibaro Door/Window Sensor 2
* Neo CoolCam Door/Window Detector
* Popp Tür-/Fensterkontakt mit Kipperkennung

Alle diese Sensoren senden eigentlich "nur" einen Alarm in Richtung FHEM und haben per Default keinen State. Ich habe mir da mit zwei kleinen attrs in den Sensor-Devices geholfen:

attr userReadings *Device* state:alarm.* {(split(/,|is /, ReadingsVal($name,"alarm","")))[1]}

Hier werden die Alarme geparst und zum einen in den STATE gepackt und dann auch noch in ein UserReading state
Das klappt soweit zuverlässig bei NeoCoolCam und Fibaro Sensoren.

Den Popp-Kontakt habe ich erst gestern im Einsatz und stehe da noch vor einer kleinen Herausforderung. Mein Ziel ist es diesen als Threestate-Sensor zu nutzen, da der Sensor eine Tilt-Erkennung hat. Dies wird allerdings nicht im Alarm geliefert, sondern in einem extra-Reading "tilted". Die dort möglichen Werte sind "on" und "off". Weiss jemand, wie man dieses Reading sinnvoll sowohl in STATE als auch in state hereinbekommt, so das ASC dies auch nutzen kann?

Update: Ich habe es jetzt so gelöst:

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"}}

Ich glaube es ist noch verbesserungswürdig, klappt aber zur Zeit recht gut

Kurz noch zur subjektiven Einschätzung der Sensoren:

Der Fibaro wirkt am hochwertigsten und hat auch noch einen (irgendwie ziemlich nutzlosen) Temperatursensor eingebaut. Der Popp-Sensor liegt für mich irgendwo in der Mitte, wenn dieser dann auch noch mit der Tilt-Erkennung nutzbar würde, wäre er für mich ein wirklich gut aufgebauter Window-Sensor.
Der NeoCoolCam ist etwas buckliger als die beiden anderen und wirkt einfach bulliger. Auch der mitgelieferte Magnet ist massiger. Das Plastik wirkt ziemlich billig, aber bisher sind diese Sensoren ziemlich robust und erkennen selbst bei großen Toleranzen noch den Magneten auf der Gegenseite. Da sind die Figaro-Sensoren deutlich zickiger.

Beta-User

Eigentlich sollte das mit userReadings alleine (ohne stateFormat gehen).

Der Code müßte aber komplexer sein und die Trigger eingeschränkter. Ungetesteter Pseudocode:
attr userReadings *Device* state:(alarm|tilted).* {if $EVENT =~ /alarm/ {(split(/,|is /, ReadingsVal($name,"alarm","")))[1]} else {"tilted"}}
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

Wardancer

Morgen,

ja das mit dem stateFormat, war historisch... ich habs in meinem Beitrag jetzt schon korrigiert und mal einen Trigger mit ins UserReading aufgenommen.

Jetzt kurz zum Verständnis deines Vorschlages:

else {"tilted"}

gibt aber ja nur den Wert von tilted zurück, oder stehe ich da auf dem Schlauch? im ASC müsste dann ja abhängig vom Wert von tilted eigentlich "tilted" als Wert in das State-Attribut geschrieben werden, oder? Sehr spannend wird es dann sicherlich auch, wenn man bedenkt, dass eigentlich erst ausgewertet werden müsste, ob das Fenster gekippt (also tilted ist), wenn es das nicht ist, dann müsste eigentlich erst der Alarm mit dem ist das Fenster offen oder geschlossen ausgewertet werden.
Ich versuche die Tage mal was zu basteln, bin aber jetzt erstmal für ein paar Tage vom Keyboard und komme erst Anfang nächster Woche wieder zum basteln ...


Beta-User

Das mit "tilted" als Rückgabewert sollte dann passen, wenn die Events auch entsprechend sind, aber um da wirklich was dazu zu sagen, müßte ich die Events kennen, wie sie in den unterschiedlichen Schaltversionen reinkommen.

Vorab solltest du mal nachsehen, ob man da was verzögern kann (meine HM-threestate-Sensoren sind alle so eingestellt, dass sie erst 2 Sek. warten, nachdem "Ruhe" ist (also nicht mehr von closed über open nach tilted gedreht wird (oder umgekehrt)).

Ging erst mal v.a. um das Prinzip, a) die Events besser einzugrenzen und b) dann eine Auswertung für unterschiedliche Event-Versionen zu haben. Kann gut sein, dass die Reihenfolge getauscht werden muß (erst die tilted-Auswertung) und dort on und off unterschieden werden sollten und dabei auch via ReadingsVal Werte des "anderen" Events berücksichtigt.

Bei Bedarf dann bitte Auszüge aus dem Event-Monitor zu den unterschiedlichen Schaltszenarien, am besten ggf. in einem separaten Thread (das wird hier vermutlich sonst zu speziell). Schönen "Tastatur-Entzug" :) .
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

wk

Hallo, hier meine Erfahrungen mit Shelly-Aktoren.

Ich habe sowohl Shelly 2 als auch Shelly 2.5. Beide funktionieren mit dem Shelly-Modul von pah als auch über MQTT.

Unabhängig vom Modul habe ich Verständnisprobleme mit dem Anfahren von Zwischenstellungen, wie z.B. beim Shading.
Egal, welchen Aktor ich ansteuere, es wird fast nie die vorgegebene Position eingestellt, obwohl ich die Kalibrierung mehrfach durchgeführt habe. Bei der Shading-Position 10 wird einmal 5 oder 6 oder 9 erreicht.

Da die Position bei den Aktoren über die Laufzeit errechnet wird und andererseits die Position über die Laufzeit gesteuert wird, müsste doch die Position der vorgegeben entsprechen, da absolute Positionswerte ja nicht vorhanden sind. Wenn jetzt z.B. für die Position 10 errechnet wird, dass der Aktor 8 Sekunden laufen muss, dann müsste er doch nach dieser Laufzeit errechnen, dass er auf Position 10 steht und nicht irgendetwas zwischen 5 und 10.

Kann mir jemand von Euch dieses Verhalten erklären?

Beta-User

Bitte ggf. die Diskussion zu den shellys wie angeregt separat führen und nur hier verlinken!

Grundsätzlich dürfte die Differenz zwischen dem "set xy" und dem gemeldeten Ergebnis daher kommen, wie der Aktor die Vorgaben behandelt (dürfte soll sagen: ich habe diesen Aktor nicht, kann aber ähnliches beobachten bei brightness und meinen zigbee2mqtt-Leuchten) .

Ich würde das so interpretieren: Zunächst erhält der Aktor den Befehl und muß das (hier: in eine Zeit) umrechnen. Dabei kommt es ggf. zu Rundungen. Dann schaltet er irgendwann das Relais aus und meldet das dann zurück. Eventuell wird dabei die Ausschaltzeit nochmals festgestellt (was als Verlängerung der Fahrzeit interpretiert werden dürfte, und ggf. davon abhängt, ob irgendwelche WLAN-Aktivitäten vom ESP8266 ausgeführt werden) und wieder zu einem Level umgerechnet (und wieder gerundet). Dieser wird dann wieder verschickt und dann von FHEM letztlich als Readingwert übernommen.

Ändern kann man das nur über die firmware (=Hersteller fragen, ob er das Verhalten verbessern kann, 3-5% Differenz kommt mir zu groß vor), oder, indem man die Verarbeitungslogik für das Position-Reading verbessert, also z.B. diesen Teil "shellies/DEVNAME/roller/0/pos:.* pct\" so ergänzt, dass eine Perl-Funktion aufgerufen wird (die z.B. den $EVENT mit dem aktuellen Reading vergleicht, im dem set_xy stehen sollte, dabei ReadingsAge gegenprüft usw.).
Wenn du selbst da nicht firm bist, solltest du (in dem zusätzlichen Thread) um Hilfe bitten, das geht am grünen Tisch eher nicht so leicht.
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

hubiuwe

#7
Hallo
Ich nutze die enocean Aktoren FSB61 von Eltako mit Erfolg.

Es gab nur ein Problem mit dem Ende der Beschattung und der vollständigen Öffnung, die Rollos wollten häufig nicht aus der Beschattung fahren.
Dabei ist mir aufgefallen daß nach dem Ende einer Fahrt das Reading "position" nicht den Wert des im Set-Befehl geforderten Wertes hatte.
Die Folge war des die Beschattung das Rollo immer ein Stück hoch und runter gefahren hat.

Bsp.

-   Beschattungsfunktion  sendet "set position 70"
-   der Aktor bestätigt das Ende der Fahrt mit "position 72"
-   Die Beschattungsfunktion will korrigieren mit "set position 70"
-   der Aktor fährt wieder hoch und Bestätigt mit "position 68"
-   usw.

Da das Rollo nicht in der Beschattungsposition steht wird es nicht mehr aus der Beschattung gefahren.


Ein einfaches enocean-Attribut hat geholfen:


attr <enocean_Rollodevice> settingAccuracy high

Die Positionierung ist jetzt perfekt.

ebenfalls ist dieser Eintrag wichtig um beim öffnen die Null Position korrekt anzufahren:

attr <enocean_Rollodevice> calAtEndpoints yes


So läuft alles super

Gruß
Uwe
Die beste Automatik ist die, die man abschalten kann!

thorschtn

Ich steuere Jarolift Funkempfänger (Einfachtaster TDRR 01W) über einen SignalDuino.

Da diese keine Positionswerte zurück liefern, mappe ich das ganze über das ROLLO Modul. Konfiguriert sind die Rollos mit ASC Typ=1, ich musste aber zusätzlich noch ASC_Pos_Reading=pct setzen.

Als Drehgriffsensor setze ich einen HomeMatic HM-Sec-RHS ein, als Lichtsensor einen Homnematic HMSen-LI-O.
NUC - FHEM & HA
MapleCUN, Homematic, 433MHz, AB440, 1-Wire Bewässerung & Pool, Jarolift (Signalduino), Signal Messenger, Denon AVR, LG WebOS, AmazonEcho, Jura S90 (ESP8266), Sonoff, Xiaomi Mii Sauger, Worx SO500i

Moonraker1

Hallo zusammen,

ich habe bisher einen HMIP-FROLL von Homematic im aktiven Einsatz (drei weitere hängen zum Testen inzwischen auch dran). Angesteuert wird er über das HMCCUDEV direkt über die CCU3. Was man bei diesem Aktor beachten sollte, ist die extreme "Gesprächigkeit" in Form von Events durch die virtuellen Aktorkanäle (diese bringen die Logik des ASC gewaltig durcheinander, da sie alle "*.LEVEL" heissen), das habe ich aber einfach über event-on-change bzw. event-on update im Zusammenspiel mit dem Filter "ccureadingfilter" / "ccureadingname" aus HMCCUDEV in den Griff bekommen (somit wird ASC dann nur noch mit einer level-Information versorgt, 3.LEVEL geht in den Status ein, 4.LEVEL ist zuständig für die Fahrbefehle mittels "control").

vG
Olli
NUC mit Ubuntu, MAX!Cube über LAN, 1 MAX WT, 8 MAX HT, 2 MAX Fensterkontakt, MaxScanner, HM CCU2 mit Homematic HT's, div. Schaltern, Bewegungsmelder, Ökofen Pelletheizung über httpmod

FHEM_newbie

Zitat von: hubiuwe am 03 August 2019, 10:42:10
Hallo
Ich nutze die enocean Aktoren FSB61 von Eltako mit Erfolg.

Es gab nur ein Problem mit dem Ende der Beschattung und der vollständigen Öffnung, die Rollos wollten häufig nicht aus der Beschattung fahren.
Dabei ist mir aufgefallen daß nach dem Ende einer Fahrt das Reading "position" nicht den Wert des im Set-Befehl geforderten Wertes hatte.
Die Folge war des die Beschattung das Rollo immer ein Stück hoch und runter gefahren hat.

Bsp.

-   Beschattungsfunktion  sendet "set position 70"
-   der Aktor bestätigt das Ende der Fahrt mit "position 72"
-   Die Beschattungsfunktion will korrigieren mit "set position 70"
-   der Aktor fährt wieder hoch und Bestätigt mit "position 68"
-   usw.

Da das Rollo nicht in der Beschattungsposition steht wird es nicht mehr aus der Beschattung gefahren.


Ein einfaches enocean-Attribut hat geholfen:


attr <enocean_Rollodevice> settingAccuracy on

Die Positionierung ist jetzt perfekt.

ebenfalls ist dieser Eintrag wichtig um beim öffnen die Null Position korrekt anzufahren:

attr <enocean_Rollodevice> calAtEndpoints yes


So läuft alles super

Gruß
Uwe

Ich habe dasselbe Problem: Die Werte calAtEndpoints yes und settingAccuracy high sind gesetzt. Es ist zwar schon etwas besser, aber trotzdem steht z.B manchmal der eine oder andere Rollladen statt auf 55 auf 54% und fährt dann nicht mehr aus der Beschattung.

JHo

@Moonraker1, hubiuwe und FHEM_newbie: schaut doch mal das ROLLO-Modul als Zwischenschicht an. Das sollte die Positionsprobleme für ASC beheben.
1: FHEM auf Ubuntu, MAX!Cube, Wand- und Heizkörperthermostate, Eco-Schalter, diverse LaCrosse-Sensoren, per remote angebundene DS18B20-Sensoren
2: FHEM auf Raspi 3, Max!Cube, Wand- und Heizkörperthermostate, Eco-Schalter, ht_pitiny-Adapter zu Junkers FW120

Beta-User

@JHo: So wie ich das verstanden habe, hat nur noch FHEM_newbie ein Problem, bei den anderen habt eine Konfiguration am Device bereits für hinreichend Abhilfe gesorgt.

Dieser Weg ist m.E. vorzugswürdig.

@FHEM_newbie:
Leider kann ich dazu auch wenig beitragen und sehe nur, dass du etwas andere Einstellungen verwendest als hubiuwe. Vielleicht könntest du das Thema im EnOcean-Bereich auch an den Entwickler adressieren, wenn das nicht "genau genug" ist.
(Eine Bitte: Vermeidet möglichst diese langen Zitatorgien, bei manchen Browsern ist das grausam zu lesen, ein einfacher Verweis (z.B. ein gekürztes Zitat) tut es m.E. in den meisten Fällen genauso... Danke!)
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

FHEM_newbie

Zitat von: Beta-User am 17 September 2019, 17:56:54
@FHEM_newbie:
Leider kann ich dazu auch wenig beitragen und sehe nur, dass du etwas andere Einstellungen verwendest als hubiuwe. Vielleicht könntest du das Thema im EnOcean-Bereich auch an den Entwickler adressieren, wenn das nicht "genau genug" ist.

@Beta-User: Mit den anderen Einstellungen meinst du settingAccuracy high anstatt settingAccuracy on, richtig? Ich habe hier nur die Auswahl high oder low. Eigentlich würde ich die Einstellungen im Device auch bevorzugen, dies liegt aber auch daran, dass ich nicht genau verstanden haben wie das mit dem zwischengeschalteten ROLLO Device gehen soll  :o


hubiuwe

#14
Hallo
Ich nutze an meinen Fenstern die EnOcean Fenstergriffe von Hoppe (werden auch von Eltako vertrieben) zusammen mit ASC.
Es gab zuerst Probleme wenn ich den Griff z.B. von "closed" über "open" zu "tilted" gedreht habe, das Fenster stand dann auf Kipp und ASC hat "open" ausgewehrtet (es kam ja als erstes) und das Rollo entsprechend gefahren.

Ich habe jetzt ein DOIF dazwichen gelegt welches den Zustand open verzögert und nur weitergibt wenn in einer bestimmten Zeit kein "closed" oder "tilted" folgt:
define DI_Fenster_WZ_Verz DOIF ([Fenster_WZ:"^tilted|closed"]) (set DU_Fenster_WZ $EVENT)\
DOELSEIF ([Fenster_WZ:"^open.*"]) (set DU_Fenster_WZ open)

attr DI_Fenster_WZ_Verz do always
attr DI_Fenster_WZ_Verz icon helper_doif
attr DI_Fenster_WZ_Verz wait 0:3


DU_Fenster.... ist ein Dummy welcher im Attribut ASC_WindowRec als Fenstergriff eingetragen ist.
Das Attribut wait bestimmt die Verzögerung hier 3s für CMD2
Das ganze muss natürlich für jedes Fenster so angelegt werden.
Das DOIF reagiert auf "open" und "open_from_tilted" leitet dann aber jeweils nur "open" nach der Verzögerung an den dummy weiter.

Es Funktioniert wunderbar, die 3s werde ich vermutlich noch etwas hoch setzen.
Gruß Uwe
Die beste Automatik ist die, die man abschalten kann!

Beta-User

Hier noch ein Fund, den der Autor leider nicht selbst hier eingestellt hat:

Zitat von: AutomatisierEtwas am 14 April 2020, 01:40:44
Habe das Modul in meiner FHEM Steuerung entsprechend im Zusammenhang mit einem Rolltron 1400 konfiguriert und im Einsatz.
[...]
Laut FHEM-Forum https://forum.fhem.de/index.php/topic,67800.msg660549.html#msg660549 kann eine Fahrt im Automatikmodus nur unter Verwendung des Befehls mit dem Endwort "timer" erzielt werden.
Beispiel: "set <aktor> position 50 timer"
[...]

Hardware: DuofernStick + Rollotron 1400 (1423 45 11 UW)
Software: Raspi + FHEM
Zitat von: AutomatisierEtwas am 01 Mai 2020, 13:27:52Es hat funktioniert:


set <RolladenDeviceName> timeAutomatic on
attr <RolladenDeviceName> eventMap {usr=>{'^position(.*)'=>'position $1 timer'}}


Hierbei muss der Platzhalter <RolladenDevice> durch den Namen des jeweiligen Rolladendevice Namen ersetzen werden.

Das eventMap Attribut [...]
- bleibt bei einem Update des Source Codes erhalten
- funktioniert auch, wenn die Rolladenfahrt manuel ausgelöst wird über set <RolladenDeviceName>  position XXX
- funktioniert auch, wenn die Rolladenfahrt durch einen ASC_ExternalTrigger ausgelöst wird.

Kann evtl. interessant sein, falls jemand ähnliche Probleme mit dem Erforderniss eines "erweiterten Fahrbefehls" hat.
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

phoenix-anasazi

Hallo,

ich habe 11 DUOFERN-Rohrmotoren (ILFM/RTFM bzw. ILFS/RTFS) und noch mehr DUOFERN-Fenster/Türkontakte im Einsatz. Funktionieren einwandfrei mit ASC (Shading, Ventilate, Wind und Brightness-Fahrten). Ggfs. muss im Rolladendevice die "positionDeviation" (s. Commandref) eingestellt werden.
Helligkeits- Wind- und Regensensor: Duofern-Umweltsensor
Temperatur kommt von einem Netatmo-Aussenmodul (ginge aber auch über Umweltsensor, aber der hängt natürlich in der Sonne)

crusader85

Hallo allerseits,
ich nutze KNX-Aktoren von MDT.

Bei der Definition muss dabei die Position (aktPos) mit ausgelesen werden, sowie ein Positionierungselement, dass dann geschrieben wird (bei mir z.B.)
2/2/97:dpt1.008 2/2/99:dpt5.001:position 2/2/101:dpt1.010:Halt 2/2/100:dpt5.001:aktPos 2/2/98:dpt1.008:Richtung


Des Weiteren benötigt man ein UserReading auf dass dann ASC triggert:
position:aktPos-get:.* {ReadingsNum($name,'aktPos-get',50)}

Funktioniert bei mir alles einwandfrei.

Grüße

phoenix-anasazi

Und jetzt funktionieren auch meine beiden HmIP-DRBLI4 (4-Fach Jalousieaktoren) mit ASC-Version 0.8, wenn ich 0.9 getestet habe, update ich hier. Man muss einzelne HMCCUDEV anlegen mit den entsprechenden Kanälen (9,13,17,21 Real-/Statuskanal und 10,14,18,22 (virtueller) Steuerkanal).

Internals:
   DEF        AKTOR-ID
   FUUID      5ed24e7d-f33f-6319-cda2-9999c6667de777aa
   IODev      d_ccu
   NAME       EGRollWGwest2
   NR         392
   STATE      100
   TYPE       HMCCUDEV
   ccuaddr    AKTOR-ID
   ccudevstate active
   ccuif      HmIP-RF
   ccuname    AKTOR WEST
   ccutype    HmIP-DRBLI4
   channels   26
   firmware   1.4.0
   statevals  devstate
   OLDREADINGS:
   READINGS:
     2020-06-05 07:42:35   0.ACTUAL_TEMPERATURE 30
     2020-06-05 07:42:38   0.CONFIG_PENDING no
     2020-06-05 07:42:38   0.DUTY_CYCLE    0
     2020-06-05 07:42:35   0.ERROR_CODE    0
     2020-06-05 07:42:35   0.ERROR_OVERHEAT no
     2020-06-05 07:42:35   0.ERROR_POWER_FAILURE no
     2020-06-05 07:15:05   0.INSTALL_TEST  yes
     2020-06-05 07:15:05   0.OPERATING_VOLTAGE 0
     2020-06-05 07:15:05   0.OPERATING_VOLTAGE_STATUS normal
     2020-06-05 07:42:38   0.RSSI_DEVICE   -67
     2020-06-05 07:15:05   0.RSSI_PEER     178
     2020-06-05 07:42:38   0.UNREACH       no
     2020-06-05 07:15:05   0.UPDATE_PENDING no
     2020-06-05 07:42:36   17.ACTIVITY_STATE stop
     2020-06-05 07:42:36   17.LEVEL        100
     2020-06-05 07:42:36   17.LEVEL_2      100
     2020-06-05 07:42:36   17.LEVEL_2_STATUS normal
     2020-06-05 07:42:36   17.LEVEL_STATUS normal
     2020-06-05 07:42:36   17.PROCESS      stable
     2020-06-05 07:15:05   17.SECTION     
     2020-06-05 07:42:36   17.SECTION_STATUS unknown
     2020-06-05 07:42:36   18.ACTIVITY_STATE stop
     2020-06-05 07:42:36   18.LEVEL        100
     2020-06-05 07:42:36   18.LEVEL_2      100
     2020-06-05 07:42:36   18.LEVEL_2_STATUS normal
     2020-06-05 07:42:36   18.LEVEL_STATUS normal
     2020-06-05 07:42:36   18.PROCESS      stable
     2020-06-05 07:42:36   18.SECTION      4
     2020-06-05 07:42:36   18.SECTION_STATUS normal
     2020-05-30 17:12:38   ASC_Enable      on
     2020-06-05 07:43:59   ASC_ShadingMessage INFO: current shading status is 'out' - next check in 2.5m
     2020-06-04 21:00:05   ASC_ShuttersLastDrive night close
     2020-06-05 07:14:59   ASC_Time_DriveDown  5.06.2020 - 21:00
     2020-06-05 07:14:59   ASC_Time_DriveUp  5.06.2020 - 08:30
     2020-06-05 07:14:55   associatedWith  RollCtrl
     2020-06-05 07:42:38   hmstate         100
     2020-06-05 07:43:59   pct             100
     2020-06-05 07:42:36   state           100
   hmccu:
     devspec    0025DA49A761F8
     dp:
       0.ACTUAL_TEMPERATURE:
         OSVAL      30
         OVAL       30.000000
         SVAL       30
         VAL        30.0
       0.CONFIG_PENDING:
         OSVAL      no
         OVAL       0
         SVAL       no
         VAL        0
       0.DUTY_CYCLE:
         OSVAL      0
         OVAL       0
         SVAL       0
         VAL        0
       0.ERROR_CODE:
         OSVAL      0
         OVAL       0
         SVAL       0
         VAL        0
       0.ERROR_OVERHEAT:
         OSVAL      no
         OVAL       false
         SVAL       no
         VAL        0
       0.ERROR_POWER_FAILURE:
         OSVAL      no
         OVAL       false
         SVAL       no
         VAL        0
       0.INSTALL_TEST:
         OSVAL      yes
         OVAL       true
         SVAL       yes
         VAL        true
       0.OPERATING_VOLTAGE:
         OSVAL      0
         OVAL       0.000000
         SVAL       0
         VAL        0.000000
       0.OPERATING_VOLTAGE_STATUS:
         OSVAL      normal
         OVAL       0
         SVAL       normal
         VAL        0
       0.RSSI_DEVICE:
         OSVAL      -67
         OVAL       -67
         SVAL       -67
         VAL        -67
       0.RSSI_PEER:
         OSVAL      178
         OVAL       178
         SVAL       178
         VAL        178
       0.UNREACH:
         OSVAL      no
         OVAL       0
         SVAL       no
         VAL        0
       0.UPDATE_PENDING:
         OSVAL      no
         OVAL       false
         SVAL       no
         VAL        false
       1.STATE:
         OVAL       false
         VAL        0
       10.ACTIVITY_STATE:
         OVAL       3
         VAL        3
       10.LEVEL:
         OVAL       1.000000
         VAL        1.0
       10.LEVEL_2:
         OVAL       1.000000
         VAL        1.0
       10.LEVEL_2_STATUS:
         OVAL       0
         VAL        0
       10.LEVEL_STATUS:
         OVAL       0
         VAL        0
       10.PROCESS:
         OVAL       0
         VAL        0
       10.SECTION:
         OVAL       4
         VAL        4
       10.SECTION_STATUS:
         OVAL       0
         VAL        0
       11.ACTIVITY_STATE:
         OVAL       3
         VAL        3
       11.LEVEL:
         OVAL       0.000000
         VAL        0.0
       11.LEVEL_2:
         OVAL       0.000000
         VAL        0.0
       11.LEVEL_2_STATUS:
         OVAL       0
         VAL        0
       11.LEVEL_STATUS:
         OVAL       0
         VAL        0
       11.PROCESS:
         OVAL       0
         VAL        0
       11.SECTION:
         OVAL       0
         VAL        0
       11.SECTION_STATUS:
         OVAL       0
         VAL        0
       12.ACTIVITY_STATE:
         OVAL       3
         VAL        3
       12.LEVEL:
         OVAL       0.000000
         VAL        0.0
       12.LEVEL_2:
         OVAL       0.000000
         VAL        0.0
       12.LEVEL_2_STATUS:
         OVAL       0
         VAL        0
       12.LEVEL_STATUS:
         OVAL       0
         VAL        0
       12.PROCESS:
         OVAL       0
         VAL        0
       12.SECTION:
         OVAL       0
         VAL        0
       12.SECTION_STATUS:
         OVAL       0
         VAL        0
       13.ACTIVITY_STATE:
         OVAL       3
         VAL        3
       13.LEVEL:
         OVAL       1.000000
         VAL        1.0
       13.LEVEL_2:
         OVAL       1.000000
         VAL        1.0
       13.LEVEL_2_STATUS:
         OVAL       0
         VAL        0
       13.LEVEL_STATUS:
         OVAL       0
         VAL        0
       13.PROCESS:
         OVAL       0
         VAL        0
       13.SECTION:
         OVAL       
         VAL       
       13.SECTION_STATUS:
         OVAL       1
         VAL        1
       14.ACTIVITY_STATE:
         OVAL       3
         VAL        3
       14.LEVEL:
         OVAL       1.000000
         VAL        1.0
       14.LEVEL_2:
         OVAL       1.000000
         VAL        1.0
       14.LEVEL_2_STATUS:
         OVAL       0
         VAL        0
       14.LEVEL_STATUS:
         OVAL       0
         VAL        0
       14.PROCESS:
         OVAL       0
         VAL        0
       14.SECTION:
         OVAL       4
         VAL        4
       14.SECTION_STATUS:
         OVAL       0
         VAL        0
       15.ACTIVITY_STATE:
         OVAL       3
         VAL        3
       15.LEVEL:
         OVAL       0.000000
         VAL        0.0
       15.LEVEL_2:
         OVAL       0.000000
         VAL        0.0
       15.LEVEL_2_STATUS:
         OVAL       0
         VAL        0
       15.LEVEL_STATUS:
         OVAL       0
         VAL        0
       15.PROCESS:
         OVAL       0
         VAL        0
       15.SECTION:
         OVAL       0
         VAL        0
       15.SECTION_STATUS:
         OVAL       0
         VAL        0
       16.ACTIVITY_STATE:
         OVAL       3
         VAL        3
       16.LEVEL:
         OVAL       0.000000
         VAL        0.0
       16.LEVEL_2:
         OVAL       0.000000
         VAL        0.0
       16.LEVEL_2_STATUS:
         OVAL       0
         VAL        0
       16.LEVEL_STATUS:
         OVAL       0
         VAL        0
       16.PROCESS:
         OVAL       0
         VAL        0
       16.SECTION:
         OVAL       0
         VAL        0
       16.SECTION_STATUS:
         OVAL       0
         VAL        0
       17.ACTIVITY_STATE:
         OSVAL      stop
         OVAL       3
         SVAL       stop
         VAL        3
       17.LEVEL:
         OSVAL      100
         OVAL       1.000000
         SVAL       100
         VAL        1.0
       17.LEVEL_2:
         OSVAL      100
         OVAL       1.000000
         SVAL       100
         VAL        1.0
       17.LEVEL_2_STATUS:
         OSVAL      normal
         OVAL       0
         SVAL       normal
         VAL        0
       17.LEVEL_STATUS:
         OSVAL      normal
         OVAL       0
         SVAL       normal
         VAL        0
       17.PROCESS:
         OSVAL      stable
         OVAL       0
         SVAL       stable
         VAL        0
       17.SECTION:
         OSVAL     
         OVAL       
         SVAL       
         VAL       
       17.SECTION_STATUS:
         OSVAL      unknown
         OVAL       1
         SVAL       unknown
         VAL        1
       18.ACTIVITY_STATE:
         OSVAL      stop
         OVAL       3
         SVAL       stop
         VAL        3
       18.LEVEL:
         OSVAL      100
         OVAL       1.000000
         SVAL       100
         VAL        1.0
       18.LEVEL_2:
         OSVAL      100
         OVAL       1.000000
         SVAL       100
         VAL        1.0
       18.LEVEL_2_STATUS:
         OSVAL      normal
         OVAL       0
         SVAL       normal
         VAL        0
       18.LEVEL_STATUS:
         OSVAL      normal
         OVAL       0
         SVAL       normal
         VAL        0
       18.PROCESS:
         OSVAL      stable
         OVAL       0
         SVAL       stable
         VAL        0
       18.SECTION:
         OSVAL      4
         OVAL       4
         SVAL       4
         VAL        4
       18.SECTION_STATUS:
         OSVAL      normal
         OVAL       0
         SVAL       normal
         VAL        0
       19.ACTIVITY_STATE:
         OVAL       3
         VAL        3
       19.LEVEL:
         OVAL       0.000000
         VAL        0.0
       19.LEVEL_2:
         OVAL       0.000000
         VAL        0.0
       19.LEVEL_2_STATUS:
         OVAL       0
         VAL        0
       19.LEVEL_STATUS:
         OVAL       0
         VAL        0
       19.PROCESS:
         OVAL       0
         VAL        0
       19.SECTION:
         OVAL       0
         VAL        0
       19.SECTION_STATUS:
         OVAL       0
         VAL        0
       2.STATE:
         OVAL       false
         VAL        0
       20.ACTIVITY_STATE:
         OVAL       3
         VAL        3
       20.LEVEL:
         OVAL       0.000000
         VAL        0.0
       20.LEVEL_2:
         OVAL       0.000000
         VAL        0.0
       20.LEVEL_2_STATUS:
         OVAL       0
         VAL        0
       20.LEVEL_STATUS:
         OVAL       0
         VAL        0
       20.PROCESS:
         OVAL       0
         VAL        0
       20.SECTION:
         OVAL       0
         VAL        0
       20.SECTION_STATUS:
         OVAL       0
         VAL        0
       21.ACTIVITY_STATE:
         OVAL       3
         VAL        3
       21.LEVEL:
         OVAL       1.000000
         VAL        1.0
       21.LEVEL_2:
         OVAL       1.000000
         VAL        1.0
       21.LEVEL_2_STATUS:
         OVAL       0
         VAL        0
       21.LEVEL_STATUS:
         OVAL       0
         VAL        0
       21.PROCESS:
         OVAL       0
         VAL        0
       21.SECTION:
         OVAL       
         VAL       
       21.SECTION_STATUS:
         OVAL       1
         VAL        1
       22.ACTIVITY_STATE:
         OVAL       3
         VAL        3
       22.LEVEL:
         OVAL       1.000000
         VAL        1.0
       22.LEVEL_2:
         OVAL       1.000000
         VAL        1.0
       22.LEVEL_2_STATUS:
         OVAL       0
         VAL        0
       22.LEVEL_STATUS:
         OVAL       0
         VAL        0
       22.PROCESS:
         OVAL       0
         VAL        0
       22.SECTION:
         OVAL       4
         VAL        4
       22.SECTION_STATUS:
         OVAL       0
         VAL        0
       23.ACTIVITY_STATE:
         OVAL       3
         VAL        3
       23.LEVEL:
         OVAL       0.000000
         VAL        0.0
       23.LEVEL_2:
         OVAL       0.000000
         VAL        0.0
       23.LEVEL_2_STATUS:
         OVAL       0
         VAL        0
       23.LEVEL_STATUS:
         OVAL       0
         VAL        0
       23.PROCESS:
         OVAL       0
         VAL        0
       23.SECTION:
         OVAL       0
         VAL        0
       23.SECTION_STATUS:
         OVAL       0
         VAL        0
       24.ACTIVITY_STATE:
         OVAL       3
         VAL        3
       24.LEVEL:
         OVAL       0.000000
         VAL        0.0
       24.LEVEL_2:
         OVAL       0.000000
         VAL        0.0
       24.LEVEL_2_STATUS:
         OVAL       0
         VAL        0
       24.LEVEL_STATUS:
         OVAL       0
         VAL        0
       24.PROCESS:
         OVAL       0
         VAL        0
       24.SECTION:
         OVAL       0
         VAL        0
       24.SECTION_STATUS:
         OVAL       0
         VAL        0
       25.WEEK_PROGRAM_CHANNEL_LOCKS:
         OVAL       4095
         VAL        4095
       3.STATE:
         OVAL       false
         VAL        0
       4.STATE:
         OVAL       false
         VAL        0
       5.STATE:
         OVAL       false
         VAL        0
       6.STATE:
         OVAL       false
         VAL        0
       7.STATE:
         OVAL       false
         VAL        0
       8.STATE:
         OVAL       false
         VAL        0
       9.ACTIVITY_STATE:
         OVAL       3
         VAL        3
       9.LEVEL:
         OVAL       1.000000
         VAL        1.0
       9.LEVEL_2:
         OVAL       1.000000
         VAL        1.0
       9.LEVEL_2_STATUS:
         OVAL       0
         VAL        0
       9.LEVEL_STATUS:
         OVAL       0
         VAL        0
       9.PROCESS:
         OVAL       0
         VAL        0
       9.SECTION:
         OVAL       
         VAL       
       9.SECTION_STATUS:
         OVAL       1
         VAL        1
Attributes:
   ASC        2
   ASC_BrightnessSensor DUOFERN_690DF4_sensor:brightnessAVG
   ASC_Closed_Pos 0:Geschlossen
   ASC_ComfortOpen_Pos 80
   ASC_Down   brightness
   ASC_Mode_Down always
   ASC_Mode_Up always
   ASC_Open_Pos 100:Offen
   ASC_Partymode off
   ASC_Pos_Reading pct
   ASC_PrivacyDown_Pos 70
   ASC_RainProtection off
   ASC_Shading_InOutAzimuth 110:290
   ASC_Shading_MinMax_Elevation 1:100
   ASC_Shading_Min_OutsideTemperature 20
   ASC_Shading_Mode always
   ASC_Shading_Pos 10:Beschattung
   ASC_Shading_StateChange_SunnyCloudy 60000:20000
   ASC_Shading_WaitingPeriod 300
   ASC_ShuttersPlace terrace
   ASC_Time_Down_Early 17:45
   ASC_Time_Down_Late 21:00
   ASC_Time_Up_Early 07:00
   ASC_Time_Up_Late 08:30
   ASC_Time_Up_WE_Holiday 07:30
   ASC_Up     brightness
   ASC_Ventilate_Pos 20:Ventilate
   ASC_WindParameters 10:6
   ASC_WindProtection on
   ASC_WindowRec EGTuerWGvorn
   ASC_WindowRec_subType twostate
   IODev      d_ccu
   alias      Wintergarten West 2
   ccureadingfilter 0..*;17..*;18..*
   ccureadingname 17.LEVEL$:+pct
   ccuscaleval LEVEL:0:1:0:100,LEVEL_2:0:1:0:100
   cmdIcon    up:fts_shutter_up stop:fts_shutter_manual down:fts_shutter_down
   controldatapoint 18.LEVEL$
   devStateIcon 100:fts_window_2w@green 0:fts_shutter_100@red 9\d.*:fts_shutter_10 8\d.*:fts_shutter_20 7\d.*:fts_shutter_30 6\d.*:fts_shutter_40 5\d.*:fts_shutter_50 4\d.*:fts_shutter_60 3\d.*:fts_shutter_70 2\d.*:fts_shutter_80 1\d.*:fts_shutter_90 0\d.*:fts_shutter_10
   event-on-change-reading .*
   eventMap   /datapoint 18.STOP true:stop/datapoint 18.LEVEL_2 100 18.LEVEL 100:up/datapoint 18.LEVEL_2 0 18.LEVEL 0:down/datapoint 18.LEVEL_2 100 18.LEVEL 100:Offen/datapoint 18.LEVEL_2 0 18.LEVEL 50:Halboffen/datapoint 18.LEVEL_2 30 18.LEVEL 0:Beschattung/datapoint 18.LEVEL_2 0 18.LEVEL 0:Geschlossen/
   group      Rolladen
   hmstatevals ACTUAL_TEMPERATURE_STATUS!2:tempOverflow,3:tempUnderflow;ERROR_OVERHEAT!(1|true):overheat
   icon       fts_shutter_updown
   room       EG->Wintergarten,Steuerung->Rolladen->Manuell
   stateFormat {round(ReadingsVal("EGRollWGwest2","17.LEVEL",0)/10,0)*10 }
   statedatapoint 17.LEVEL
   stripnumber 0
   substitute ACTUAL_TEMPERATURE_STATUS!0:normal,1:unknown,2:overflow,3:underflow;CONFIG_PENDING!(0|false):no,(1|true):yes;ERROR_OVERHEAT!(0|false):no,(1|true):yes;ERROR_POWER_FAILURE!(0|false):no,(1|true):yes;INSTALL_TEST!(0|false):no,(1|true):yes;OPERATING_VOLTAGE_STATUS!0:normal,1:unknown,2:overflow;UNREACH!(0|false):no,(1|true):yes;UPDATE_PENDING!(0|false):no,(1|true):yes;ACTIVITY_STATE!0:unknown,1:up,2:down,3:stop;LEVEL_STATUS!0:normal,1:unknown,2:overflow,3:underflow,4:error;LEVEL_2_STATUS!0:normal,1:unknown,2:overflow,3:underflow,4:error;PROCESS!0:stable,1:not_stable;SECTION_STATUS!0:normal,1:unknown
   userReadings pct {round(ReadingsVal("EGRollWGwest2","17.LEVEL",0)/10,0)*10 }
   userattr   ASC_Adv:on,off ASC_Antifreeze:off,soft,hard,am,pm ASC_Antifreeze_Pos:5,10,15,20,25,30,35,40,45,50,55,60,65,70,75,80,85,90,95,100 ASC_AutoAstroModeEvening:REAL,CIVIL,NAUTIC,ASTRONOMIC,HORIZON ASC_AutoAstroModeEveningHorizon:-9,-8,-7,-6,-5,-4,-3,-2,-1,0,1,2,3,4,5,6,7,8,9 ASC_AutoAstroModeMorning:REAL,CIVIL,NAUTIC,ASTRONOMIC,HORIZON ASC_AutoAstroModeMorningHorizon:-9,-8,-7,-6,-5,-4,-3,-2,-1,0,1,2,3,4,5,6,7,8,9 ASC_BlockingTime_afterManual ASC_BlockingTime_beforDayOpen ASC_BlockingTime_beforNightClose ASC_BrightnessSensor ASC_Closed_Pos:0,10,20,30,40,50,60,70,80,90,100 ASC_ComfortOpen_Pos:0,10,20,30,40,50,60,70,80,90,100 ASC_Down:time,astro,brightness,roommate ASC_DriveUpMaxDuration ASC_Drive_Delay ASC_Drive_DelayStart ASC_ExternalTrigger ASC_GuestRoom:on,off ASC_LockOut:soft,hard,off ASC_LockOut_Cmd:inhibit,blocked,protection ASC_Mode_Down:absent,always,off,home ASC_Mode_Up:absent,always,off,home ASC_Open_Pos:0,10,20,30,40,50,60,70,80,90,100 ASC_Partymode:on,off ASC_Pos_Reading ASC_PrivacyDownValue_beforeNightClose ASC_PrivacyDown_Pos ASC_PrivacyUpValue_beforeDayOpen ASC_PrivacyUp_Pos ASC_RainProtection:on,off ASC_Roommate_Device ASC_Roommate_Reading ASC_Self_Defense_AbsentDelay ASC_Self_Defense_Mode:absent,gone,off ASC_Shading_InOutAzimuth ASC_Shading_MinMax_Elevation ASC_Shading_Min_OutsideTemperature ASC_Shading_Mode:absent,always,off,home ASC_Shading_Pos:10,20,30,40,50,60,70,80,90,100 ASC_Shading_StateChange_SunnyCloudy ASC_Shading_WaitingPeriod ASC_Shutter_IdleDetection ASC_ShuttersPlace:window,terrace ASC_SlatPosCmd_SlatDevice ASC_Sleep_Pos:0,10,20,30,40,50,60,70,80,90,100 ASC_TempSensor ASC_Time_Down_Early ASC_Time_Down_Late ASC_Time_Up_Early ASC_Time_Up_Late ASC_Time_Up_WE_Holiday ASC_Up:time,astro,brightness,roommate ASC_Ventilate_Pos:10,20,30,40,50,60,70,80,90,100 ASC_Ventilate_Window_Open:on,off ASC_WiggleValue ASC_WindParameters ASC_WindProtection:on,off ASC_WindowRec ASC_WindowRec_PosAfterDayClosed:open,lastManual ASC_WindowRec_subType:twostate,threestate room_map structexclude
   webCmd     up:stop:down:pct
   widgetOverride pct:slider,0,10,100

Beta-User

@phoenix-anasazi
Danke für den Input.

Zwei Anmerkungen:
- Das list ist m.E. einigermaßen unübersichtlich; evtl. wäre es einfacher, wenn du in dem Fall eine "RAW-def" postest (z.B. mit list -r EGRollWGwest2; vermutlich würde der Teil ohne "setstate" reichen).
- Das sieht mir noch nicht ausoptimiert aus, z.B. bei "ASC_Closed_Pos 0:Geschlossen". ASC kennt diese "Doppelpunkt-Angaben" eigentlich erst ab 0.9 für Jalousien; es wäre also wenig überraschend, wenn das Probleme beim Testen mit 0.9 geben wird. Im normalen Modus sollte da m.E. eine reine Zahl stehen.
Du solltest also ggf. nochmal über das Mapping drübergehen. (Fragen dazu aber bitte nicht hier, das gehört eigentlich m.E. eher in den HM-Bereich; vielleicht machst du da einen Thread auf und verlinkst über den 0.9-Thread und den Beitrag hier dann dahin?)
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

phoenix-anasazi

#20
Ich habe heute das Update gemacht und schon die Positionsangaben wie von 0.9 erwartet eingepflegt. Also fallls das jemand basierend auf meinen Angaben mit 0.8 testen will, muss er/sie darauf achten. Ich denke die 0.9 wird ja aber bald ohnehin zum Standard, dann sollten die Jalousieaktoren ja auch so angesprochen werden. Die 0.9 muss ich aber erst noch ausgiebig testen.

Hier noch die RAW-Definition:
define EGRollWGwest2 HMCCUDEV AKTOR-ID
attr EGRollWGwest2 userattr ASC_Adv:on,off ASC_Antifreeze:off,soft,hard,am,pm ASC_Antifreeze_Pos:5,10,15,20,25,30,35,40,45,50,55,60,65,70,75,80,85,90,95,100 ASC_AutoAstroModeEvening:REAL,CIVIL,NAUTIC,ASTRONOMIC,HORIZON ASC_AutoAstroModeEveningHorizon:-9,-8,-7,-6,-5,-4,-3,-2,-1,0,1,2,3,4,5,6,7,8,9 ASC_AutoAstroModeMorning:REAL,CIVIL,NAUTIC,ASTRONOMIC,HORIZON ASC_AutoAstroModeMorningHorizon:-9,-8,-7,-6,-5,-4,-3,-2,-1,0,1,2,3,4,5,6,7,8,9 ASC_BlockingTime_afterManual ASC_BlockingTime_beforDayOpen ASC_BlockingTime_beforNightClose ASC_BrightnessSensor ASC_Closed_Pos:0,10,20,30,40,50,60,70,80,90,100 ASC_ComfortOpen_Pos:0,10,20,30,40,50,60,70,80,90,100 ASC_Down:time,astro,brightness,roommate ASC_DriveUpMaxDuration ASC_Drive_Delay ASC_Drive_DelayStart ASC_ExternalTrigger ASC_GuestRoom:on,off ASC_LockOut:soft,hard,off ASC_LockOut_Cmd:inhibit,blocked,protection ASC_Mode_Down:absent,always,off,home ASC_Mode_Up:absent,always,off,home ASC_Open_Pos:0,10,20,30,40,50,60,70,80,90,100 ASC_Partymode:on,off ASC_Pos_Reading ASC_PrivacyDownValue_beforeNightClose ASC_PrivacyDown_Pos ASC_PrivacyUpValue_beforeDayOpen ASC_PrivacyUp_Pos ASC_RainProtection:on,off ASC_Roommate_Device ASC_Roommate_Reading ASC_Self_Defense_AbsentDelay ASC_Self_Defense_Mode:absent,gone,off ASC_Shading_InOutAzimuth ASC_Shading_MinMax_Elevation ASC_Shading_Min_OutsideTemperature ASC_Shading_Mode:absent,always,off,home ASC_Shading_Pos:10,20,30,40,50,60,70,80,90,100 ASC_Shading_StateChange_SunnyCloudy ASC_Shading_WaitingPeriod ASC_Shutter_IdleDetection ASC_ShuttersPlace:window,terrace ASC_SlatPosCmd_SlatDevice ASC_Sleep_Pos:0,10,20,30,40,50,60,70,80,90,100 ASC_TempSensor ASC_Time_Down_Early ASC_Time_Down_Late ASC_Time_Up_Early ASC_Time_Up_Late ASC_Time_Up_WE_Holiday ASC_Up:time,astro,brightness,roommate ASC_Ventilate_Pos:10,20,30,40,50,60,70,80,90,100 ASC_Ventilate_Window_Open:on,off ASC_WiggleValue ASC_WindParameters ASC_WindProtection:on,off ASC_WindowRec ASC_WindowRec_PosAfterDayClosed:open,lastManual ASC_WindowRec_subType:twostate,threestate room_map structexclude
attr EGRollWGwest2 ASC 2
attr EGRollWGwest2 ASC_BrightnessSensor DUOFERN_690DF4_sensor:brightnessAVG
attr EGRollWGwest2 ASC_Closed_Pos 0:Geschlossen
attr EGRollWGwest2 ASC_ComfortOpen_Pos 80
attr EGRollWGwest2 ASC_Down brightness
attr EGRollWGwest2 ASC_Mode_Down always
attr EGRollWGwest2 ASC_Mode_Up always
attr EGRollWGwest2 ASC_Open_Pos 100:Offen
attr EGRollWGwest2 ASC_Partymode off
attr EGRollWGwest2 ASC_Pos_Reading pct
attr EGRollWGwest2 ASC_PrivacyDown_Pos 70
attr EGRollWGwest2 ASC_RainProtection off
attr EGRollWGwest2 ASC_Shading_InOutAzimuth 110:290
attr EGRollWGwest2 ASC_Shading_MinMax_Elevation 1:100
attr EGRollWGwest2 ASC_Shading_Min_OutsideTemperature 20
attr EGRollWGwest2 ASC_Shading_Mode always
attr EGRollWGwest2 ASC_Shading_Pos 10:Beschattung
attr EGRollWGwest2 ASC_Shading_StateChange_SunnyCloudy 60000:20000
attr EGRollWGwest2 ASC_Shading_WaitingPeriod 300
attr EGRollWGwest2 ASC_ShuttersPlace terrace
attr EGRollWGwest2 ASC_Time_Down_Early 17:45
attr EGRollWGwest2 ASC_Time_Down_Late 21:00
attr EGRollWGwest2 ASC_Time_Up_Early 07:00
attr EGRollWGwest2 ASC_Time_Up_Late 08:30
attr EGRollWGwest2 ASC_Time_Up_WE_Holiday 07:30
attr EGRollWGwest2 ASC_Up brightness
attr EGRollWGwest2 ASC_Ventilate_Pos 20:Ventilate
attr EGRollWGwest2 ASC_WindParameters 10:6
attr EGRollWGwest2 ASC_WindProtection on
attr EGRollWGwest2 ASC_WindowRec EGTuerWGvorn
attr EGRollWGwest2 ASC_WindowRec_subType twostate
attr EGRollWGwest2 IODev d_ccu
attr EGRollWGwest2 alias Wintergarten West 2
attr EGRollWGwest2 ccureadingfilter 0..*;;17..*;;18..*
attr EGRollWGwest2 ccureadingname 17.LEVEL$:+pct
attr EGRollWGwest2 ccuscaleval LEVEL:0:1:0:100,LEVEL_2:0:1:0:100
attr EGRollWGwest2 cmdIcon up:fts_shutter_up stop:fts_shutter_manual down:fts_shutter_down
attr EGRollWGwest2 controldatapoint 18.LEVEL$
attr EGRollWGwest2 devStateIcon 100:fts_window_2w@green 0:fts_shutter_100@red 9\d.*:fts_shutter_10 8\d.*:fts_shutter_20 7\d.*:fts_shutter_30 6\d.*:fts_shutter_40 5\d.*:fts_shutter_50 4\d.*:fts_shutter_60 3\d.*:fts_shutter_70 2\d.*:fts_shutter_80 1\d.*:fts_shutter_90 0\d.*:fts_shutter_10
attr EGRollWGwest2 event-on-change-reading .*
attr EGRollWGwest2 eventMap /datapoint 18.STOP true:stop/datapoint 18.LEVEL_2 100 18.LEVEL 100:up/datapoint 18.LEVEL_2 0 18.LEVEL 0:down/datapoint 18.LEVEL_2 100 18.LEVEL 100:Offen/datapoint 18.LEVEL_2 0 18.LEVEL 50:Halboffen/datapoint 18.LEVEL_2 30 18.LEVEL 0:Beschattung/datapoint 18.LEVEL_2 0 18.LEVEL 0:Geschlossen/
attr EGRollWGwest2 group Rolladen
attr EGRollWGwest2 hmstatevals ACTUAL_TEMPERATURE_STATUS!2:tempOverflow,3:tempUnderflow;;ERROR_OVERHEAT!(1|true):overheat
attr EGRollWGwest2 icon fts_shutter_updown
attr EGRollWGwest2 room EG->Wintergarten,Steuerung->Rolladen->Manuell
attr EGRollWGwest2 stateFormat {round(ReadingsVal("EGRollWGwest2","17.LEVEL",0)/10,0)*10 }
attr EGRollWGwest2 statedatapoint 17.LEVEL
attr EGRollWGwest2 stripnumber 0
attr EGRollWGwest2 substitute ACTUAL_TEMPERATURE_STATUS!0:normal,1:unknown,2:overflow,3:underflow;;CONFIG_PENDING!(0|false):no,(1|true):yes;;ERROR_OVERHEAT!(0|false):no,(1|true):yes;;ERROR_POWER_FAILURE!(0|false):no,(1|true):yes;;INSTALL_TEST!(0|false):no,(1|true):yes;;OPERATING_VOLTAGE_STATUS!0:normal,1:unknown,2:overflow;;UNREACH!(0|false):no,(1|true):yes;;UPDATE_PENDING!(0|false):no,(1|true):yes;;ACTIVITY_STATE!0:unknown,1:up,2:down,3:stop;;LEVEL_STATUS!0:normal,1:unknown,2:overflow,3:underflow,4:error;;LEVEL_2_STATUS!0:normal,1:unknown,2:overflow,3:underflow,4:error;;PROCESS!0:stable,1:not_stable;;SECTION_STATUS!0:normal,1:unknown
attr EGRollWGwest2 userReadings pct {round(ReadingsVal("EGRollWGwest2","17.LEVEL",0)/10,0)*10 }
attr EGRollWGwest2 webCmd up:stop:down:pct
attr EGRollWGwest2 widgetOverride pct:slider,0,10,100


P.S.: Wenn keine Lammellenposition übergeben wird, wird immer die letzte bekannte benutzt. Auch in den Endpositionen kann es dann sein, dass die Jalousie auf 100 % steht aber die Lamellen auf 30 % gehen. Sieht dann etwas schief aus ;)

Net4El4

Falls jemand ähnliche Probleme mit net4home Rollladen hat, hier der Thread zu meiner Lösung:

https://forum.fhem.de/index.php?topic=112179.new;topicseen#new

Hier die Lösungen für meinen Fall:
Generell habe ich für jeden Rollladen einen "dazugehörigen Rollo" aufgesetzt. Der Rollladen ist die Schnittstelle zu meinem net4home Bus und steuert aus fhem heraus den entsprechenden Rollladen. Das Rollo steuert dann den Rollladen über die "rl_command.*"-Attribute

1. Rollladensteuerung über ASC funktioniert nicht
Lösung: Nachdem ich die "rl_command.*"-Attribute gesetzt hatte ging es.
Beispiel: rl_commandDown set <Rollladen Device Name> down

2. Rollladensteuerung über Siri/Homekit funktioniert nicht
Lösung: Hier habe ich noch die richtigen Befehle (webcmd) setzen müssen.
In meinem Fall sind es up:down:half:stop:pct

Moonraker1

Hallo phoenix-anasazi,

ich habe einige Hmip-FROLL im Einsatz und immer wieder Probleme mit einer korrekten fhem-Interpretation der Endwerte der Behanghöhe (v.a. nominell 100%).
Ist das der Grund für die Zeilen in Deinem list mit den"round"-Berechnungen? Oder wozu sind die genau gut?

Danke
Olli
NUC mit Ubuntu, MAX!Cube über LAN, 1 MAX WT, 8 MAX HT, 2 MAX Fensterkontakt, MaxScanner, HM CCU2 mit Homematic HT's, div. Schaltern, Bewegungsmelder, Ökofen Pelletheizung über httpmod

phoenix-anasazi

Hallo Olli,

richtig erkannt. Bei mir haben die Positionen meistens nicht genau gepasst, also lasse ich sie auf 10er runden. Genauer muss ich sie nicht einstellen können. Funktioniert bei mir seither einwandfrei.

Grüße
Sascha

cbl

Hallo,

Zitat von: crusader85 am 24 Mai 2020, 14:18:33
Hallo allerseits,
ich nutze KNX-Aktoren von MDT.

Bei der Definition muss dabei die Position (aktPos) mit ausgelesen werden, sowie ein Positionierungselement, dass dann geschrieben wird (bei mir z.B.)
2/2/97:dpt1.008 2/2/99:dpt5.001:position 2/2/101:dpt1.010:Halt 2/2/100:dpt5.001:aktPos 2/2/98:dpt1.008:Richtung


Des Weiteren benötigt man ein UserReading auf dass dann ASC triggert:
position:aktPos-get:.* {ReadingsNum($name,'aktPos-get',50)}

Funktioniert bei mir alles einwandfrei.

Dem kann ich mich mit ABB-Rolladenaktoren nur anschließen. Die Konfiguration in FHEM ist identisch zu den MDTs und ASC funktioniert prächtig.

Gruß
Christian

tux75at

Da es eventuell hier besser aufgehoben ist, belebe ich den Thread nochmals.

Ich nehme gerade das ASC Modul mit meinem Fibaro Roller Shutter 3 (FGS223) in Betrieb.
Nach einigen Startschwierigkeiten habe ich jetzt einmal eine erste automatische Fahrt geschafft. Mein userReading hat jedoch noch Probleme bereitet. Inzwischen scheint es jedoch halbwegs zu passen, hat jedoch sicher Potential für Optimierungen.

Mein userReading sieht jetzt folgendermaßen aus:
dim:(dim|on|off).* {
my $state = ReadingsVal($name, "state", "off");
if ($state eq "off") {
return 0;
} elsif ($state eq "on") {
return 99;
} else {
my ($value1, $value2) = (split(" ",$state, 2));
if ($value1 eq "dim") {
return ReadingsNum($name, "state", "0");
}
}
},reportedState_Percent:(dim|on|off).* {
my $state = ReadingsVal($name, "state", "off");
if ($state eq "off") {
return "0 %"
} elsif ($state eq "on") {
return "100 %"
} else {
my ($value1, $value2) = (split(" ",$state, 2));
if ($value1 eq "dim") {
return ReadingsNum($name, "state", "0") ." %";
}
}
}


Ich habe früher auch mit dem Zustand gekämpft und nichts brauchbares für mein User Interface gefunden, jetzt beim erneuten herumprobieren habe ich jedoch eine Veränderung festgestellt. Ich hatte nur einige wenige Roller Shutter Kalibriert und hier zeigt sich der Unterschied. Bei nicht richtiger oder fehlender Kalibrierungen trennen sich die Fahrten per Taster bzw. die Fahrten mit FHEM Kommandos. Bei Tasternutzung war der Zustand nur im reportedState sichtbar und bei Kommandos nur im state Reading (Firmware Verison 5.1, für ein Update von 5.0 auf 5.1 ein Homecenter Lite zugelegt, mit 5.0 war es nicht besser). Nach Kalibrierung ist das Verhalten mittels Kommandos das gleiche, die Fahrten mit Tastern werden jedoch im reportedState und im state Reading angezeigt. Daher habe ich in meinem userReading nur den state in Verwendung.
Meine Auswertung ist sehr defensive, ich möchte verhindern dass ein anderer state Eintrag etwas anstellen kann. Keine Ahnung ob das passieren kann.

Die Probleme mit dem Zustand haben mich lange abgehalten das Modul zu testen, jetzt hatte ich wieder einmal etwas mehr freie Zeit und habe mich endlich aufgerafft und beginne damit.
Danke @CoolTux für deine Geduld mit mir im Thread für die derzeit aktuelle Version. Danke auch an @Beta-User ich habe jetzt den Spezialfall für das userReading mit state verstanden und hoffentlich ein richtiges Reading erstellt. Derzeit gibt es keine eocr settings, temestamp-on-change-reading und event-on-change-reading konnte ich jetzt löschen und es scheint noch zu funktionieren. Weitere Tests folgen noch, derzeit ist nur ein Rolladen mit obigen userReading versehen, und wegen manuellem bedienens zu knapp zur automatischen mag er zurzeit noch nicht. Obiges userReading werde ich morgen bei weiteren einstellen und testen.

Weitere andere Einstellung gegenüber anderen, ich habe als offen Position "0" und als geschlossen "99" also ASC = 1. Ist für mich logischer und für mein UI verständlicher.

Gruß
Tux

Reinhard.M

#26
Für den Homematic-IP Jalousie Aktor HmIP-FBL habe ich folgende Lösung für ASC erarbeitet:

Zitat von: Reinhard.M am 24 August 2021, 17:30:06
Hallo Zusammen!
Ich bin seit einiger Zeit damit beschäftigt meinen HmIP-FBL Jalousien Aktor sauber in ASC einzubinden. Leider kann ich die Lösung von CoolTux nicht direkt verwenden, das bei den HmIP Aktoren wohl die Slat Position nie unabhängig von der Höhe eingestellt werden kann. Der Aktor verstellt die Position der Lamellen nur wenn gleichzeitig die Höhe eingestellt wird (set <device> datapoint 4.LEVEL_2 <sltpct> 4.LEVEL <pct>). Für mich habe ich jetzt folgende Lösung gefunden, eventuell hat der ein oder andere Homematic Besitzer ebenfalls Interesse.
Zunächst habe ich ein eventMap für die Ansteuerung des Devices aufgesetzt:

attr <device> 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',\
         '^sltpct(.*)'      => 'datapoint 4.LEVEL_2$1   4.LEVEL ".(ReadingsVal($NAME, "4.LEVEL",0))."',\
         '^pctslt(.*),(.*)' => 'datapoint 4.LEVEL_2 $2  4.LEVEL$1'},\
fw  => {'^sltpct(.*)'      => 'sltpct',\
         '^pctslt(.*),(.*)' => 'pctslt'\
}

Die jeweiligen Positionen habe ich mit Kommatrennung aufgesetzt:

attr <device> ASC_Closed_Pos 2,0
attr <device> ASC_Open_Pos 1,100
attr <device> ASC_ComfortOpen_Pos 99,100
attr <device> ASC_ExternalTrigger di_HY:state TV-On:TV-Off 1,66
attr <device> ASC_Ventilate_Pos 3,75
attr <device> ASC_Sleep_Pos 0,0

Die Kommandos zum Einstellen sind dann folgendermaßen zugeordnet:

attr <device> ASC_SlatPosCmd_SlatDevice sltpct
attr <device> ASC_Pos_Reading pctslt

Damit die Positionen auch im Webinterface eingegeben werden können habe ich das widgetOverride verwendet:

attr <device> webCmd pct:open:stop:close:sltpct
attr <device> widgetOverride pct:selectnumbers,0,4,100,0,lin sltpct:0,25,33,50,66,75,100 ASC_Closed_Pos ASC_ComfortOpen_Pos ASC_Open_Pos ASC_Sleep_Pos ASC_Ventilate_Pos

Damit lassen sich jetzt im Webinterface Höhe und Position unabhängig voneinander einstellen. Über die Komma separierten Werte lässt sich außerdem die Automatisierung problemlos verwenden. Ok, letzteres ist mit der Kommaseparierung nicht die feine englische Art (CoolTux erwartet eigentlich nur Integer Werte), aber da die Werte nur durchgereicht werden funktioniert es hervorragend.
Einen kleinen Wehrmutstropfen gibt es allerdings. Die Intelligenz des Systems schlägt gelegentlich erbarmungslos zu. Gemeint ist damit die Positionsüberprüfung. Positionen dürfen nicht identisch sein und wenn die Jalousie nicht auf einer der Positionen steht werden nicht alle Automatikfahrten ausgeführt. Beide Einschränkungen kommen wohl aus der Historie des Moduls und sind nicht so einfach auszubauen. Mit dem oben gezeigten Setup läuft es aber bei mir ganz gut.
@CoolTux: Eventuell kannst du ja mal die Zusammenhänge darstellen damit man sich leichter darauf einrichten kann. Und falls ich zu Off-Topic bin lasst es mich wissen. Insbesondere unter welcher Rubrik ich für dieses Thema einen neuen Thread aufmachen soll.

Gruß Reinhard

Beta-User

Hallo zusammen,

falls jemand mittesten möchte: Es gibt seit heute morgen eine Testversion mit der Möglichkeit, eigene Fahrbefehle zu definieren: https://forum.fhem.de/index.php/topic,123670.0.html

Das sollte viele der "speziellen Probleme" lösen können, die wir hier diskutiert haben :) .

Viel Spaß mit dem neuen feature.

Beta-User
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

cbl

Ich habe neben den oben genannten Gira-Aktoren inzwischen auch noch seit einem Jahr ein KLF200 von VELUX als Type KLF200Node (ASC=2, ASC_Pos_Reading = pct) eingebunden.

Ferner Laufen seit wenigen Tagen zwei KADRILJ-Sichtschutzrolladen (tradfri, via conbee2 als HUEDevice eingebunden) mit ASC zur Beschattung.

Beide Einbindungen waren mit diesem mittlerweilesehr reifen Modul sehr einfach. Danke!

baumeister

Hallo,

wir haben 6 Roma Vorbau-Textilscreens, welche über somfy tahoma Motoren gesteuert werden und über das tahoma Modul im fhem integriert sind. Hier lassen wir eine komplexe Beschattung der Fenster via ASC fahren. Alle Rollladen sind an den somfy Windwächter angelernt, welcher sich leider nur über das Reading "PriorityLockTimerState" des Rollladen erahnen lässt. Die Temperaturwerte werden zum einen Teil von einem Homematic Sensor (HM-WDS30-T-O) und zum anderen Teil über den Aussentemperaturfühler unserer Buderus Heizung gemessen. Die Heizung frage ich dabei über das km200 Modul ab. Des weiteren haben wir zwei Somfy Sonnensensoren (Vor- und Rückseite vom Haus)

Beschattungsparameter sind bei uns:

  • Lage des Fensters
  • Uhrzeit
  • Werte des Sonnensensors
  • Temperatur
  • Azimuth
  • Elevation

Alles in allem funktioniert die Beschattung sehr zuverlässig. In wenigen Fällen klappt es mit dem morgentlichen und abendlichen rauf-/runterfahren nicht immer. Ich denke hier überschneiden sich bei mir einige Parameter und dann will es nicht so ganz.