FHEM Forum

Hallo zusammen,

wir erweitern unseren Garten um einen Sonnenschutz und werden hierbei drei elektrische Rollos / Zip-Screens und 24 V LED-Streifen zu steuern haben.
Aufgrund der örtlichen Gegebenheiten (Verbau des Empfängers, WLAN Empfang nicht möglich, Kabel legen ebenfalls ausgeschlossen) sind die Fibaro Roller Shutter Aktuatoren ziemlich weit oben auf meiner Hardwareliste. Alternative wären vielleicht noch die Shelly Wave Shutter.
Allerdings habe ich bisher noch keine Erfahrung mit ZWave unter FHEM. Ich habe einiges von Homematic (die alten Geräte, nicht Homematic IP) sehr problemlos am Laufen, aber hier gibt es keine Hardware mehr zu kaufen.

Soweit ich dem Forum entnehmen konnte, wird der "Vorgänger" FGR-223 wohl schon direkt von FHEM unterstützt. Leider gibt es den nicht mehr zu kaufen...

Hat schon jemand Erfahrung mit dem Fibaro FGR-224 bzw. ist das für jemanden der bisher noch nichts mit ZWave unter FHEM zu tun hatte machbar? Ich bin Mechatroniker, mit Software tue ich mich bisweilen etwas schwer  ;D

Grüße Axel

Zu dem Shutter kann ich nichts sagen, aber Zwave unter FHEM einrichten ist jetzt keine Hürde. Das geht ratzfatz mit Hilfed er vorhandenen Doku.

Erlaube mir aber die Frage, warum Du am Einbauort Zwave-Empfang aber kein Wlan hast? Wenn es nur ein Aktor ist, würde ich deswegen keine ZWave-Netz aufbauen, es sei denn Du hat es eh vor.

Ich kenne weder das FGR223 noch das FGR224, ich habe nur gerade die Handbuecher studiert, deswegen sind die folgenden Aussagen mit etwas Vorsicht zu lesen.

- die Grundfunktionalitaet (Rollo hoch/runter) wird beim FGR223 mit der SWITCH_MULTILEVEL Klasse (ZWave Terminologie fuer Teilfunktionalitaet) implementiert.
- das FGR224 bietet diese Klasse auch an.
- FHEM implementiert diese Klasse und bietet damit etliche dim* Befehle an, siehe die Doku hier: https://fhem.de/commandref_modular.html#ZWave-set , unter "Class SWITCH_MULTILEVEL"

- FHEM implementiert fuer den FGRM222 (Vorgaenger) eine herstellerspezifische Loesung fuer die Verstellung der Lamellen (positionSlat/positionBlinds). Weiss nicht, ob das fuer FGR223 oder gar FGR224 noch funktioniert, das geht aus dem verlinkten Beitrag auch nicht hervor.

- zusaetzlich implementiert das FGR224 die Klasse WINDOW_COVERING, was explizit fuer Rollos/Jalousien ersonnen wurde, und was FHEM nich kennt.
- weiterhin kennt FHEM die Konfigurationsbefehle der FGR224 nicht "persoenlich", d.h. man muss statt sprechende config* Befehle erst den Beipackzettel studieren, und in FHEM "set <DEV> configByte <parameterNummer> <Wert>" eingeben.

Ich bin bereit die WINDOW_COVERING Klasse in FHEM zu implementieren, falls jemand mir hilft, es zu testen.

Zitat von: Flachzange am 03 März 2025, 21:54:41Erlaube mir aber die Frage, warum Du am Einbauort Zwave-Empfang aber kein Wlan hast? Wenn es nur ein Aktor ist, würde ich deswegen keine ZWave-Netz aufbauen, es sei denn Du hat es eh vor.

Na klar ist die Frage erlaubt und auch berechtigt. Die (insgesamt vier) Aktuatoren werden im Aluminiumrahmen des Sonnenschutzes verbaut. Es gibt hier eine Wartungsöffnung, an dem der Hersteller normalerweise Aktuatoren von Somfy montiert. Leider habe ich mit Somfy im Hause meiner Mutter keine gute Erfahrung gemacht, das liegt insbesondere an der sehr umständlichen Möglichkeiten zum Anlernen bei Somfy als auch am "geschlossenen" Funkprotokoll Somfy IO.
Des weiteren soll der Aktuator unbedingt auch den Anschluss von Hardware-Tastern zur direkten Steuerung der Rollos vorsehen, diese Möglichkeit gibt es bei Somfy auch nicht.

WLAN Empfang in einem nahezu geschlossenem Aluminiumprofil ist aufgrund der geringen Durchdringung von 2.4 GHz sehr unwahrscheinlich. Nachdem die vom Sonnenschutzhersteller verbauten Somfy Aktuatoren bei sehr vielen Kunden einwandfrei funktionieren, sehe ich die Chance auf Funktion bei einer Funktechnik im gleichen Frequenzbereich (Somfy und ZWave arbeiten ja beide auf 868 MHz) als sehr hoch an.
Ich möchte im Wohnzimmer noch die Möglichkeit vorsehen, die Rollos mittels Taster zu bewegen. Wenn man hier z.B. einen Somfy i4 ZWave einsetzt, könnte dieser sogar als Repeater fungieren, um die Strecke zwischen dem FHEM-Raspberry und der Terasse besser abzudecken.

Zitat von: rudolfkoenig am 03 März 2025, 22:08:43......

- zusaetzlich implementiert das FGR224 die Klasse WINDOW_COVERING, was explizit fuer Rollos/Jalousien ersonnen wurde, und was FHEM nich kennt.
- weiterhin kennt FHEM die Konfigurationsbefehle der FGR224 nicht "persoenlich", d.h. man muss statt sprechende config* Befehle erst den Beipackzettel studieren, und in FHEM "set <DEV> configByte <parameterNummer> <Wert>" eingeben.

Ich bin bereit die WINDOW_COVERING Klasse in FHEM zu implementieren, falls jemand mir hilft, es zu testen.

Danke dir schon mal für den Input. Das klingt zumindest ja schon mal, als wenn man das irgendwie zum Laufen bekommen könnte.
Das Thema WINDOW_COVERING muss ich mir mal genauer anschaunen, aktuell kann ich mir da noch nichts drunter vorstellen. Ich werde mir heute Abend mal das Handbuch vom Hersteller zu Gemüte führen.

Bezüglich der Config mache ich mir keine Sorgen. Ich denke das benötigt man ja nur einmal am Anfang zur Einrichtung. Wichtig wäre es, dass ich verschiedene Funktaster direkt mit dem Aktuator koppeln kann. In welcher Form man das dann aus FHEM macht, spielt für mich keine so große Rolle.

Danke für das Angebot für die Implementierung von WINDOW_COVERING. Sollte sich das an der bei mir geplante Hardware testen lassen, können wir das gerne zusammen angehen.

Ich befinde mich aktuell noch in der Planungsphase, vorraussichtlich kommt der Sonnenschutz im Mai. Es ist also noch etwas Zeit, bis es konkret wird.

ZWave einzurichten ist in der Tat kein Hexenwerk.

Habe beide alten Modelle, und auch den FGRM-223. Der 223 ergibt 3 FHEM-Devices: Ein "Hauptdevice" (das ich nicht direkt benötige, über das aber auch die Behanghöhe einzustellen wäre), einen Kanal für die Behanghöhe (mit Energy-Werten, anhand denen man erkennen kann, ob gerade gefahren wird) und einen für die Lamellendrehung (ist eine Jalousie dran, das mit den 3 Devices hängt aber nicht daran).

Bei dem Modell ist es "unschön", dass das so "zerfällt", die älteren lösen das als Einheitsdevice, und vielleicht hast du Glück, dass der 224 das auch wieder so abbildet ;) , ansonsten geht das auch anders.

Prinzipiell bin ich mit den Fibaro-ZWave sehr zufrieden (die Rollladenaktoren können "nebenbei" auch noch Szenen-Steuerung, wir nutzen z.B. Doppelklicks für "alle hoch/runter), allerdings verursacht hin und wieder der Parallelbetrieb mit Homematic Probleme, v.a., wenn man die Befehle nicht zeitlich entzerrt.

Bedenken hätte ich, dass ein Dongle ohne "Mesh-Hop" direkt größere Entfernungen packt.

Da du Löten kannst: Vielleicht wären in diesem Fall ein paar gebrauchte BidCoS-Geräte die einfachere Lösung? (Oder ZigBee, falls du irgendwo zwischendrin ein, zwei "Router"-Device(s) platzieren könntest und das "eh" hast?).

Das klingt ja schon mal nach sehr positiven Erfahrungen. Toll wäre natürlich, wenn ich einen prozentualen Wert für die Position vorgeben könnte. Das scheint ja schon zu funktionieren.

Ich könnte mir auch vorstellen, im Laufe der Zeit die Homematic-Komponenten dann auch durch ZWave zu ersetzten. Allerdings sind hier ein paar Eigenbaulösungen mit dabei, das scheint bei ZWave nicht ganz so einfach zu sein. Aktuell funktioniert das alles ziemlich stabil, daher würde ich aus Zeit- und Geldgründen das ungern alles umbauen.

Bezüglich der Reichweite/"Mesh-Hop": ich würde im Wohnzimmer gerne einen Shelly i4 Wave für die Steuerung über Taster verbauen. Dieser befindet sich auf jeden Fall im Empfangsbereich des Dongle. Wenn ich die Informationen zum Shelly richtig verstehe, dann würde er als "ZWave Repeater" das Signal auch verstärken können. Das wäre dann auch ein großer Vorteil gegenüber einer Homematic-Lösung.

Über gebrauchte BidCoS Geräte hatte ich auch schon nachgedacht. Die dort verlangten Preise finde ich teilweise für so alte Hardware ziemlich hoch. Aber vielleicht sind mir auch noch nicht die richtigen Angebote über den Weg gelaufen...

Edit:
ZigBee arbeitet ja auch im 2.4 GHz-Bereich. Versuche zur Abschirmung von WLAN habe ich schon gemacht, das Ergebnis ist ernüchternd. Daher mache ich mir bei ZigBee leider auch wenig Hoffnung. Man findet leider kaum Aktuatoren, die den Anschluss einer externen Antenne ermöglichen. Damit könnte man natürlich das Problem mit dem Aluminiumprofil sehr einfach Lösen.

Ich habe Z-WAVE mit zahlreichen FIBARO FGR-223 seit ca. 4 Jahren im Einsatz. Ein Aktor musste auf Garantie ausgetauscht werden (POLEN).
Zusätzlich habe ich einen Rolladen mit Z-WAVE/TechniSat, da dort die Logik direkt im Schalter sitzt.
Alles funktioniert einwandfrei. Die Open- und Close-Steuerung geht bei mir mit automatischer Abschaltung (Markise auf?).
Die %-Steuerung stimmt dazwischen nicht mit dem tatsächlichen Stand überein. Kann man vielleicht noch besser hinpopeln.
Die Kombination mit verdrahteten Schalter (konventionell) funktioniert einwandfrei.
Die Kombination mit einem batteriebetriebenen Funkschalter (Z-Wave.Me ZME_WALLC-S Secure Wall Controller) ist problematisch, weil für die Konfiguration die Batterie stark belastet wird und die Batteriezustandanzeige unzuverlässig ist. Wenn das Ding konfiguriert und die Batterie ausgetauscht ist, kann man das lange benutzen (wegen ALEXA).
Ich habe alles hinbekommen. ALEXA über Umweg MODUL ROLLO, vielleicht gehts auch direkt? Habe das am Anfang nicht hinbekommen. Never touch ..., habe mich anderen smart-home Themen zugewandt

Vielen Dank für die zahlreichen Rückmeldungen. Das stimmt mich ja schon mal sehr positiv, ich denke das bekommme ich dann schon zum Laufen.

Ich werde die Aktuatoren dann mal beschaffen, allerdings kommt der Sonnenschutz dann erst im Mai. Nachdem die FGR-224 wohl als erstes eine Kalibrierfahrt zu den Endanschlägen machen, weiß ich nicht ob vorab eine Inbetriebnahme auf dem Schreibtisch Sinn ergibt.

Zum Shelly Wave i4, den ich für die Taster im Wohnzimmer verwenden möchte gibt es auch schon ein Thema hier:
https://forum.fhem.de/index.php?topic=140259.0 (https://forum.fhem.de/index.php?topic=140259.0)

Allerdings werde ich hieraus noch nicht so ganz schlau, ob das Gerät nur zum Laufen gebracht wurde oder nicht. Für mich klingt es so, als wenn von Softwareseite alles zur Verfügung stehen würde.

Wenn die ganze Geschichte dann läuft, ist es vielleicht doch eine Gelegenheit von Homematic auf ZWave komplett umzusteigen. Teilweise erziehlt die Homematic-Hardware auf dem Gebrauchtmarkt Liebhaberpreise, so dass sich ein Austauch vielleicht sogar kostenneutral erfolgen könnte.

Eine kurze Frage hätte ich doch noch:

Wenn ich die Informationen im FHEM-Wiki richtig verstanden habe, dann ist es möglich durch eine Assoziation von Taster und Aktuator eine direkte Kommunikation herzustellen.

D.h. falls mal der Raspberry aussteigen sollte (was wirklich noch nie passiert ist, FHEM läuft seit vielen Jahren sehr stabil), wäre auch ohne ihn eine Bedienung über den Shelly Wave i4  möglich?

Zitatwäre auch ohne ihn eine Bedienung über den Shelly Wave i4  möglich?

Ja.

Super, danke für die schnelle Antwort.

Dann melde ich mich spätestens wieder, wenn ich die Hardware hier habe. Mal schauen, wie weit ich da mit den Anleitungen komme und wo ich etwas Unterstützung benötige. Wie gesagt, es wird dann vorr. erst im Mai so weit sein.

Dann können wir auch gerne die WINDOW_COVERING Klasse noch mal anschauen.

Hallo zusammen,

ich habe jetzt die ZWave Hardware im Hause und bin gerade dabei, das alles in FHEM einzubinden.
Es sieht so aus, als wenn ich beim Aeotec Z-Stick Gen5 erfolgreich war.
Im nächsten Schritt versuche ich mich gerade an einem der drei Fibaro FGR-224 Aktuatoren.

Im Grunde bin ich der Anleitung aus dem Wiki für den FGRM-222 gefolgt.

https://wiki.fhem.de/wiki/Z-Wave-FIB_FGRM-222-Rollladenaktor (https://wiki.fhem.de/wiki/Z-Wave-FIB_FGRM-222-Rollladenaktor)

Allerdings scheint es in FHEM doch noch keine Eintragungen in der Config-XML Datei dafür zu geben.

get <device> model ergibt folgende Ausgabe:

model:0x010f 0x0304 0x1000

Im Reading

Zitatmodel

steht auch nicht wie im Wiki beschrieben der Klartextname.

Leider ist die Pergola nicht vorhanden und ich kann daher akutell sehr schlecht irgendetwas zum Thema Bewegungen von Motoren testen.

Ist es erforderlich, dass in der Config-XML die korrekten Daten stehen, oder funktioniert der FGR-224 auch so?

ZitatIst es erforderlich, dass in der Config-XML die korrekten Daten stehen, oder funktioniert der FGR-224 auch so?

Das XML ermoeglicht in FHEM sprechende config* Befehle, und Hilfe zu diesen Befehlen, d.h. ohne XML muss man den Beipackzettel konsultieren, und die Zahlen per configByte, etc eingeben.
Ein weiterer Eintrag ordnet manchen Geraeten ein Bild zu.

Fuer das FGRM-222 gibt es die "hartkodierten" positionSlat/positionBlinds Befehle (im Abschnitt MANUFACTURER_PROPRIETARY), ich habe jetzt das oben erwaehnte modelId auch zu diese Liste hinzugefuegt, und ins SVN eingecheckt (per FHEM update morgen ab 8 Uhr).
Kannst Du bitte berichten, ob diese Funktion von dem FGR-224 unterstuetzt wird?

Super, vielen Dank.
Ich werde morgen das Update laden. Ob die positionSlat/positionBlinds Befehle auch ohne Kalibrierung (Motoren sind ja leider noch nicht da) testen kann, muss ich probieren.

ZitatHabe beide alten Modelle, und auch den FGRM-223. Der 223 ergibt 3 FHEM-Devices: Ein "Hauptdevice" (das ich nicht direkt benötige, über das aber auch die Behanghöhe einzustellen wäre), einen Kanal für die Behanghöhe (mit Energy-Werten, anhand denen man erkennen kann, ob gerade gefahren wird) und einen für die Lamellendrehung (ist eine Jalousie dran, das mit den 3 Devices hängt aber nicht daran).

Das scheint übrigens beim 224 nicht mehr der Fall zu sein. Es ist nur ein Hauptdevice erzeugt worden.

Dafür hat der Shelly i4 Wave gleich 6 Devices erzeugt. Zwei "Hauptdevices" und dann pro Tastereingang ein weiteres Device.
Ich werde mal provisorisch ein paar Taster anschließen und ausprobieren, was genau dort passiert.

Ich habe heute morgen das Update geladen und versucht etwas damit rum zu spielen (die Zeit war bei dem super Wetter leider etwas begrenzt, es gab genug im Garten zu tun).

Sollte sich seit dem Update bezüglich bei einer Antwort des Devices auf
get <device> model etwas bezüglich des Klartextnamens getan haben?
Aktuell erhalte ich hier immer noch die gleiche Antwort wie vor dem Update:

model:0x010f 0x0304 0x1000
modelId:010f-0304-1000
model:0x010f 0x0304 0x1000
Bezüglich der classes steht beim Device folgendes:

ZWAVEPLUS_INFO WINDOW_COVERING SWITCH_MULTILEVEL ASSOCIATION MULTI_CHANNEL_ASSOCIATION ASSOCIATION_GRP_INFO TRANSPORT_SERVICE VERSION MANUFACTURER_SPECIFIC DEVICE_RESET_LOCALLY POWERLEVEL SECURITY SECURITY_S2 METER CONFIGURATION ALARM PROTECTION CENTRAL_SCENE FIRMWARE_UPDATE_MD SUPERVISION INDICATOR APPLICATION_STATUS

ZitatAktuell erhalte ich hier immer noch die gleiche Antwort wie vor dem Update:

Meine Aenderung aktiviert bei obigen modelId und Vorhandensein der Klasse MANUFACTURER_PROPRIETARY die Befehle positionSlat und positionBlinds.
Da die genannte Klasse nicht angeboten wird, aendert sich nichts, und ich kann meine Aenderungen wieder ausbauen.

Wir muessen wohl den Weg ueber das Implementieren der Klasse WINDOW_COVERING gehen.
Welche Version dieser Klasse implementiert das Geraet? Steht in vclasses.

Kannst Du bitte pruefen, ob das Geraet die beiden Herstellerabhaengigen Befehle nicht doch implementiert?
Dazu ergaenzt man das classes Attribut mit MANUFACTURER_PROPRIETARY.
Ich mache mir zwar keine grossen Hoffnungen, aber ich wuerde gerne sicher sein.

Ich habe gearde bei classes das Attribut MANUFACTURER_PROPRIETARY hinzugefügt.

Ich kann über
set <device> positionSlats und
set <device> positionBlinds prozentuale Vorgaben an das Device senden, ohne dass eine Fehlermeldung zurück kommt. Da ich noch keine Motoren/Rolladen hier habe, kann ich aber leider nicht sagen, ob das grundsätzlich funktioniert.
Unter state steht dann auch der zuletzt gesendete Befehl.

Zitat von: rudolfkoenig am 13 April 2025, 11:47:56Wir muessen wohl den Weg ueber das Implementieren der Klasse WINDOW_COVERING gehen.
Welche Version dieser Klasse implementiert das Geraet?

Unter vclasses steht WINDOW_COVERING:1

In der Doku (SDS13781) steht fuer Implementierer von WINDOW_COVERING:1

ZitatWith the exception for slats angle control, the following mapping MUST apply:
• The Multilevel Switch value 0x00 MUST represent the least light, i.e. covering fully closed.
• The Multilevel Switch value 0x63 MUST represent the most light, i.e. covering fully opened.
For slats angle control, the following mapping MUST apply:
• The Multilevel Switch value 0x00 MUST represent slats closed to the one side.
• The Multilevel Switch value 0x32 MUST represent slats open.
• The Multilevel Switch value 0x63 MUST represent slats closed to the other side.
[...]
A supporting node MAY use the Multilevel Switch Command Class to control multiple features like
up/down control as well as slats angle control. For instance, the Start Level Change command may start
changing the slats angle towards the extreme angle and when reaching that extreme angle, it may start
moving up or down.

Die erwaehnte SWITCH_MULTILEVEL Befehle sind im FHEM implementiert.

Ich lese die Doku trotzdem weiter :)

Danke dir!
Wenn ich gerade irgendwie unterstützen kann, dann bitte Bescheid geben. Über die Osterfeiertage sind wir nämlich nicht da.

Aktuell arbeite ich gerade im Keller an der wasserdichten Verpackung für meine Aktuatoren und Schalter. Ich möchte bestmöglich vorbereitet sein, wenn die Firma die Pergola liefert.

Mal schauen, ob ich vor den Feiertagen noch dazu komme den ebenfalls beschafften Fibaro FGRGBW-442 mal in der Werkstatt provisorisch anzuschließen und zu testen. Da gibt es ja auch schon Hinweise hier im Forum, allerdings wird es bei mir nicht so komplex mit Mischfarben usw. Ich habe nur weiß  ;D

Ich habe jetzt etliche get Befehle eingebaut.
Anfangen sollte man mit "get wincov_supported", das sollte ein wincov_supported Reading erzeugen, und eine weitere Menge an "get wincov_*" Befehlen freischalten. Natuerlich ungetestet, und ich bin auf Feedback gespannt.

Ein Problem bleibt die Dokumentation: es gibt 22 moegliche get/set Varianten: absolut oder mit start/stopp, von oben nach unten, nach links aussen, usw, jenachdem, was das Geraet unterstuetzt. Ohne Bilder ist das schwer verstaendlich, selbst damit habe ich meine Schwierigkeiten.

Alles klar, ich schaue gleich morgen gleich mal, was passiert und gebe Bescheid. Ich werde allerdings erst abends dazu kommen.

So, das Update ist drauf und FHEM neu gestartet.

"get wincov_supported" erzeugt wie vorhergesehen das Reading "wincov_supported" mit dem Inhalt "out_bottom_mvt".

Zusätzlich ist dann nur ein get Befehlt hinzugekommen:
"get <device> wincov_out_bottom_mvt"

Das device hat ja bei mir aufgrund der noch nicht vorhandenen Motoren noch keine Kalibrierung durchgeführt. Kann es sein, dass manche Sachen erst nach der Kalibierung zur Verfügung stehen?

Zitat von: rudolfkoenig am 14 April 2025, 22:23:15Ein Problem bleibt die Dokumentation: es gibt 22 moegliche get/set Varianten: absolut oder mit start/stopp, von oben nach unten, nach links aussen, usw, jenachdem, was das Geraet unterstuetzt. Ohne Bilder ist das schwer verstaendlich, selbst damit habe ich meine Schwierigkeiten.

Da bin ich ja froh, ich habe auch versucht mir das zu Gemüte zu führen. Tue mich aber als Nicht-Informatiker trotz Mechatronikstudium sehr schwer damit.

"get <device> wincov_out_bottom_mvt"
Was wird da geliefert?

Timeout reading answer for wincov_out_bottom_mvt

ZitatKann es sein, dass manche Sachen erst nach der Kalibierung zur Verfügung stehen?

Klingt plausibel, die pos Befehle (absolute Position anfahren) koennen ohne Kalibrierung nicht funktionieren.
Der "Beipackzettel" (https://manuals.fibaro.com/document-category/fgr-224/) bestaetigt diese Hypothese: ohne Kalibrierung:12==out_bottom_mvt, mit:13==out_bottom_pos.
Wuesste gerne, ob nach der Kalibrierung- *mvt noch verfuegbar ist.

ZitatTimeout reading answer for wincov_out_bottom_mvt

Ich habe einen Fehler gefixt, bitte erneut testen.
Die Rueckgabewerte (aktuelle Position, usw) sind ohne Kalibrierung vmtl. nicht sehr aufregend.

Ich habe auch die wincov_set Befehle hinzugefuegt, und ab sofort sollte in FHEMWEB die passende Hilfe fuer alle ZWave set/get Befehle auftauchen.

Super, vielen Dank nocheinmal für deinen super Einsatz!

Ich versuche morgen mal das Update zu machen - habe hier im Campingurlaub nur das Tablet dabei und die Internetverbindung lässt zu wünschen übrig. Ich hoffe ich komme zu Hause per VPN drauf. Falls nicht, dann klappt es erst am Montag abend.

Ich habe übrigens kurz vor dem Losfahren noch den Fibaro FGWGRB-442 in der Werkstatt provisorisch in Betrieb genommen. Das Ding legt leider ziemlich viele Devices an. Aber ich habe es zumindest auf Anhieb geschafft ein LED-Streifen an- und auszuschalten und zu dimmen. Auch konnte ich die Dimmerzeiten für die einzelen Kanäle für mich passend einstellen. Klappt also sehr gut aus FHEM heraus.

So, Update ist drauf.

"get <device> wincov_out_bottom_mvt"
liefert jetzt ein:

wincov_out_bottom_mvt: current:99 target:99 duration:0

ZitatIch habe auch die wincov_set Befehle hinzugefuegt, und ab sofort sollte in FHEMWEB die passende Hilfe fuer alle ZWave set/get Befehle auftauchen.

Ich finde hier nur einen "set <device> wincov_out_bottom_mvt" Befehl, für den dann auch die entsprechende Hilfe angezeigt wird.

Zitatwincov_out_bottom_mvt: current:99 target:99 duration:0

Ist wie ich es erwartet habe: da das Geraet nicht kalibriert ist, kann es auch nichts Anderes sagen.

ZitatIch finde hier nur einen "set <device> wincov_out_bottom_mvt" Befehl, für den dann auch die entsprechende Hilfe angezeigt wird.

Korrekt: da laut wincov_supported nur das unterstuetzt wird, werden die anderen Befehle nicht angeboten.
Ich gehe davon aus, dass nach der Kalibrierung wincov_supported  out_bottom_pos melden wird, damit wird dann dieser Befehl angeboten.
Faellt mir ein: vmtl. werden dann bis zum naechsten Neustart beide Befehle angeboten.
Bin unsicher, ob ich das fixen will :)

Ok, dann scheint ja bisher alles soweit zu passen. Dann schon einmal vielen Dank für die Unterstützung.

Ich denke dann müssen wir jetzt zunächst einmal auf die Hardware warten. Das wir aber sicherlich noch zwei bis drei Wochen dauern.
Habe heute erst mit dem Aushub für die Fundamente begonnen...

Ich gebe Bescheid, sobald ich die FGR-224 kalibrieren kann und übe solang noch ein bißchen mit dem Shelly Wave i4 und den daran angeschlossenen Tastern.

Hallo zusammen,

die Pergola steht und ich konnte an den drei FGR-224 die Kalibrierung durchführen.

"get <device> wincov_supported" liefert "wincov_supported:out_bottom_pos"


"get <device> wincov_out_bottom_mvt" liefert "Unsupported command: wincov_out_bottom_mvt"


"get <device> wincov_out_bottom_pos" liefert "wincov_out_bottom_pos: current:68 target:68 duration:0"

Das passt auch, ich hatte zuvor den Aktuator mittels "set <device> dim 68" auf genau diese Position gefahren.

Danke fuers Feedback!

Was liefert "get <device> swmStatus" und "get <device> swmSupported"? Das sind die Abfragen in der Klasse SWITCH_MULTILEVEL/dim.

Ich befuerchte, fuer dieses Geraet bringt die Klasse WINDOW_COVERING keinen Zusatznutzen ueber SWITCH_MULTILEVEL.

"get <device> swmStatus"
liefert
"state:dim 68
swmStatus:68 target 68 duration 0 seconds"


"get <device> swmSupported"
liefert
"swmSwitchType:primary Up/Down secondary Undefined"


Ich stehe ja erst am Anfang mit dem Aktuator, daher verzeiht mir meine noch unbeholfenen Fragen:

Wenn ich in z.B. Tablet UI eine einfachen Knopf für das Öffnen bzw. Schließen mit dem FGR-224 umsetzen möchte (Rollo fährt so lange, wie der Knopf gedrückt wird), würde man das z.B. mit einem
set <device> dimUpDown UP IGNORE 0 umsetzen?


Mein Ziel wäre es, am Schluss den/die Aktuatoren direkt mit dem Shelly wave i4 zu verbinden. Das geht ja über eine Assoziation. Dahingehen muss ich die Handbücher beider Geräte erst einmal zu den Themen lesen und verstehen. Dort wäre es natürlich schön, wenn man nicht nur bestimme Positionen über Szenen anfahren kann, sondern eine "manuelle Bedienung" umsetzten kann -- > Rollo fährt, so lange der Knopf gedrückt wird und hält beim Loslassen wieder an.

set <device> dimUpDown UP IGNORE 0Ich habe die Patches von hier (https://forum.fhem.de/index.php?topic=60468) eingefuegt, und mangels Geraet nie konkret getestet.
Ich interpetiere die Doku so, dass man die Bewegung mit dimUpDown startet, und mit stop endet.

ZitatRollo fährt so lange, wie der Knopf gedrückt wird

Da ich TabletUI nicht kenne: wird da sowas wie "Knopf losgelassen" oder "Knopf wird immer noch gedrueckt" angeboten?

Danke, ich denke das war genau der Hinweis die richtige Richtung für TabletUI:

Zitatdata-set-on    Wert, der beim Drücken gesendet werden soll. Kann auch ein Array sein, um verschiedene Werte abwechselnd zu schalten    on    data-set-on="1"

data-set-off    Wert, der nach dem Loslassen gesendet werden soll        data-set-off="0"

Das werde ich mal probieren. Klingt aber schon nach der passenden Lösung.


Dann muss ich mich nur noch mit dem Thema Assoziation beschäftigen. Wird aber bestimmmt auch irgendwie lösbar sein  :)

So, ich versuche mich gerade an des Assoziation.
Ausgangslage ist folgende:

- Shelly i4 Wave (4-fach Wall Switch)
  Der i4 Wave erzeugt für jeden Taster ein eigenes Device: Z_Wave_Taster_1.02 - 1.05
  Für den ersten Eingang  wird eine ZWave NodeID 0302 angezeigt

- Fibaro Roller Shutter 4 FGR-224 mit ZWave NodeID 02

Der Taster unterstützt laut Doku (https://kb.shelly.cloud/knowledge-base/wave-i4#Wavei4(EU)-Z-WaveAssociations) verschiede Funktionen, ich denke ich habe die für mich relevante gefunden:

ZitatRoot device - Association Group 4

Association Group 4
Allowed nodes: 9
It is assigned to switch connected to the SW (SW1) terminal (uses Basic command class).
Triggered by SW (SW1). The device sends according to the state of SW (SW1) (switch or push-button) the command BASIC_SET ON or BASIC_SET OFF to the associated device. This command is reflected to the output of associated device. Supports the following command classes:

    BASIC_SET : set On / Off state at the associated device

Root device - Association Group 5

Association Group 5
Allowed nodes: 9
It is assigned to switch connected to the SW (SW1) terminal (uses Switch Multilevel command class). Triggered by SW (SW1).

It is recommended to use push buttons for this association. Supports the following command classes:

    SWITCH_MULTILEVEL_START_LEVEL_CHANGE : initiate a transition to a new level (increase or decrease light intensity in case of dimmer, or move shutter up or down, ...)

    SWITCH_MULTILEVEL_STOP_LEVEL_CHANGE : stop an ongoing transition (stop increase or decrease light intensity in case of dimmer, or stop moving shutter up or down, ...)

Root device - Association Group 6

Association Group 6
Allowed nodes: 9
It is assigned to switch connected to the SW2 terminal (uses Basic command class).
Triggered by SW2. Supports the following command classes:

    BASIC_SET : set On / Off state at the associated device

Root device - Association Group 7

Association Group 7
Allowed nodes: 9
It is assigned to switch connected to the SW2 terminal (uses Switch Multilevel command class). Triggered by SW2.

It is recommended to use push buttons for this association. Supports the following command classes:

    SWITCH_MULTILEVEL_START_LEVEL_CHANGE : initiate a transition to a new level (increase or decrease light intensity in case of dimmer, or move shutter up or down, ...)

    SWITCH_MULTILEVEL_STOP_LEVEL_CHANGE : stop an ongoing transition (stop increase or decrease light intensity in case of dimmer, or stop moving shutter up or down, ...)

Ich versetehe es so, dass ich den FGR-224 in die Assoziationsgruppe 5 vom Shelly i4 Wave aufnehmen müsste, um z.B. das Rollo nach oben fahren zu lassen.

Meine ersten Versuch mit set <name> associationAdd 5 0302 war leider nicht erfolgreich. Ich glaube es wird schon etwas zugewiesen, aber leider kann ich dem Aktuator keine Bewegung entlocken.

Vielleicht hat jemand einen Tipp für mich?

ZitatFür den ersten Eingang  wird eine ZWave NodeID 0302 angezeigt

Welche Klassen hat dieses "Kanal-Geraet"?
Wenn es auch selbst Association unterstuetzt, dann wuerde ich
set <Node_0302> associationAdd 5 2
versuchen.

Ansonsten muss man den komplexeren MULTI_CHANNEL_ASSOCIATION (aka mca) bemuehen.
Wenn ich mich nicht irre, dann geht das so:
set <Dev_03> mcaAdd 5 2 0 3 1
<Dev_03> is Name der Shelly
5 ist die Association-Gruppe
2 ist Kanalnummer der Sender (Knopf 1)
0 ist Trenner in der Zahlenfolge
3 ist NodeId des Ziels
1 ist Kanal auf dem Ziel (bei Geraeten ohne Kanal weglassen?)
Laut Doku:

ZitatmcaAdd groupId node1 node2 ... 0 node1 endPoint1 node2 endPoint2 ...

Zum entwirren:
- in der o.g. mcaAdd Doku meint endPoint1 Kanalnummer, und nodeX nodeId des "Elterngeraetes".
- die Parameter sind Dezimal einzugeben.
- der letzte Parameter in der FHEM Definition (DEF) enthaelt nodeId Dezimal, nodeIdHex ist das Gleiche  in Hex
- die NodeId der "Kanal-Geraete" in der FHEM Definition besteht aus nodeId des Elterngeraetes*256+Kanalnummer. Das sieht man bei nodeIdHex deutlicher.

Der Shelly i4 Wave unterstüzt die Klasse ASSOCIATION.

set <Node_0302> associationAdd 5 2
war also genau der richtige Hinwweis. Vielen herzlichen Dank! Ich konnte jetzt die einzelnen Rollos (NodeID 06 und NodeID 05) auf jeweils einen Taster legen, das funktioniert einwandfrei.

Jetzt habe ich noch einen Tastereingang übrig, den könnte man natürlich für die LED Beleuchtung einsetzen.
Diese hängt an einem Fibaro FGRGBW442 RGBW Controller 2.
Ich glaube ich habe die Funktion des FGRBW442 rudimentär verstanden, ein paar Einzelheiten muss ich noch herausfinden. Mir würde für den Anfang ein einfaches Ein- und Ausschalten der LED-Beleuchtung ausreichen.

Der FGRBW442 erzeugt für jeden LED-Ausgang ein eigenes Device:
<device>_1.02  nodeIdHex 0402 --> Kanal 1
<device>_1.03  nodeIdHex 0403 --> Kanal 2
<device>_1.04  nodeIdHex 0404 --> Kanal 3
<device>_1.05  nodeIdHex 0405 --> Kanal 4

Außerdem gibt es noch eine Art "Hauptdevice"
<device>_1  nodeIdHex 04

Für mich sieht es so aus, als wenn die Kanalnummern an die nodeIdHex vom Hauptdevice angehängt.

Über die Weboberfläche von FHEM kann ich <device>_1.02 bis <device>_1.05 auch jeweils einzeln Ein- und Ausschalten.


Bezüglich der Assoziation des 4. Tasters:

set <Node_0302> associationAdd 10 1026
erzeugt keinen Eintrag in der assocGroup_10
(Association Group 10: It is assigned to switch connected to the SW4 terminal (uses Basic command class).
Triggered by SW4. Supports the following command classes: BASIC_SET : set On / Off state at the associated device)

Mache ich einen Fehler in der Umrechnung von Hex in Dec (nodeIdHex 0402), oder gibt es da für die Berechung von NodeID und Kanal noch einen Trick?

ZitatFür mich sieht es so aus, als wenn die Kanalnummern an die nodeIdHex vom Hauptdevice angehängt.

Das ist (nur) die FHEM-Interne Notation, und kann fuer kein Befehl verwendet werden.

Zitatset <Node_0302> associationAdd 10 1026

Bei association kann man nur nodeId angeben, und das ist im Bereich von 1 bis 255 (oder 224?), d.h dieses Befehl wird ignoriert.
Wenn man Kanaele adressieren will (egal ob bei der Quelle oder beim Ziel) dann muss man mcaAdd verwenden (Klasse MULTI_CHANNEL_ASSOCIATION), siehe oben.

Mein Vorschlag mit associationAdd aus dem Kanalgeraet (nicht aus dem Hauptgeraet!) ist nach etwas Nachdenken falsch.
Kein Kanalgeraet wird ASSOCIATION anbieten, d.h. das classes Attribut des Kanalgeraetes wird diese Klasse nicht enthalten.

Alles klar, ich habe es gerade über mcaAdd probiert und konnte zumindest mal einen Kanal vom LED-Dimmer (nodeIdHex 04) mit dem gewünschten Taster verbinden und auch steuren.

set Z_Wave_Taster_Pergola_1 mcaAdd 10 0 4 2
Leider funktioniert es gar nicht nicht mehr, sobald ich dem gleichen Taster (Association Group 10) einen weiteren Kanal vom LED-Dimmer angebe.

set Z_Wave_Taster_Pergola_1 mcaAdd 10 0 4 3
Da muss ich in Ruhe noch einmal etwas nachforschen. Vielleicht hat der Dimmer auch so etwas wie einen "Masterkanal", mit dem man das Problem umgehen könnte.

Trotzdem würde es mich natürlich interessieren, warum es dann nicht mehr funktioniert sobald mehr als ein Kanal verbunden wird...

Wieviele Nodes unterstuetzt die Gruppe 10?
Womoeglich ist nicht vorgesehen mit einer Taste das gleiche Node zweimal zu benachrichtigen.
Zum Testen koennte man den Umweg ueber FHEM nehmen.

Laut Doku werden für die Gruppe 10 maximal 9 nodes erlaubt.

Wenn ich testweise mal einen der FGR-224 Rolladenaktuatoren in die Gruppe hinzufüge, dann werden durch den einen Taster beide Aktuatoren angesteueuert. Dann scheint es wohl nicht zu funktionieren das gleiche Node zweimal zu benachrichtigen.
Der LED-Dimmer hat ja noch zwei "Hauptkanäle", deren Funktion ich (insbesondere mit den Hardware-Tasten am Dimmer) noch nicht ganz verstanden habe. Ich werde mal noch etwas rumprobieren, was damit möglich ist. Bisher haben die Kanäle 1&2 dann leider die Hardwareeingänge deaktiviert. Das wäre dann nicht so toll...

So, ich bin mit dem LES Dimmer leider nicht ganz so wie gewünscht weiter gekommen. Wenn das Hauptdevice auf "off" gestellt wird, dann lassen sich die einzelnen Kanäle nicht mehr von den angeschlossen Tastern bedienen.

Daher bin ich jetzt folgenden Umweg gegangen:
Der Shelly i4 Wave Kanal wird von FHEM mit einem Notify ausgelesen und dann der entsprechende ZWave Befehl an den LED Dimmer geschickt. Das ist dann zwar keine direkte Assoziation mehr, aber für die Beleuchtung kann ich damit leben.


Damit konnte ich jetzt alles wie gewünscht umsetzen.
Vielen herzlichen Dank für den Support!

Außerdem werde ich jetzt doch so nach und nach die alten Homematic Komponenten durch ZWave Komponenten ersetzen. Mir gefällt die verbesserte Reichweite durch das Mesh doch sehr gut.
Leider scheint es keine ganz so solide Unterputzaktuatoren mit ZWave mit einer Strombelastbarkeit von 16A zu geben oder ich habe sie noch nicht gefunden.
Es gibt eine Modell von Shelly, aber ob ich den Schraubklemmen über längere Zeit hohe Ströme anvertrauen möchte, weiß ich nicht...
Mal schauen, vielleicht entdecke ich ja noch einen Hersteller.