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

[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!

[Wardancer]

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:

Code Auswählen Erweitern

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:

Code Auswählen Erweitern

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:

Code Auswählen Erweitern

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:

Code Auswählen Erweitern

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:

Code Auswählen Erweitern

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

[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:

Code Auswählen Erweitern

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

[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.

[hubiuwe]

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:

Code Auswählen Erweitern


attr <enocean_Rollodevice> settingAccuracy high

Die Positionierung ist jetzt perfekt.

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

Code Auswählen Erweitern


attr <enocean_Rollodevice> calAtEndpoints yes


So läuft alles super

Gruß
Uwe

[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.

[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

[FHEM_newbie]

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:

Code Auswählen Erweitern


attr <enocean_Rollodevice> settingAccuracy on

Die Positionierung ist jetzt perfekt.

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

Code Auswählen Erweitern


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.

[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!)

[FHEM_newbie]

@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 

[hubiuwe]

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:

Code Auswählen Erweitern

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