[gelöst] FGR-223 als VenetianBlind: Wie konfigurieren?

[Beta-User]

Hallo zusammen,

nachdem das Teil jetzt erfolgreich (mit 3x sehr schnell die Taste drücken, siehe hier) inkludiert ist, wollte ich das jetzt irgendwie sinnvoll angesteuert bekommen, stolpere da aber irgendwie von einer Fragestellung in die nächste...

Stand: Aktor (2. Angabe in der DEF ist "5") ist includiert, configOperatingMode ist auf "VenetionaBlind" gestellt. Damit habe ich drei Devices, einen für den Aktor an sich mit Steuerungsmöglichkeit NUR für den Level sowie zwei weitere für Kanäle, mit denen ich jeweils einzeln den Level (Endpoint .01) wie die Lamellendrehung (Endpoint .02) steuern kann. Hmm, nicht optimal, die Erwartung wäre, dass entweder das Hauptgerät noch ein (setzbares) Reading für die Lamellen bekommt, oder von mir aus auch Kanal 1... Fehlanzeige.

Gut. Woanders (hier im Forum zum Vorgänger 222) hatte ich gelesen, dass evtl. die in den xml-files enthaltenen Konfigurationsangaben neu eingelesen werden müssen. Da war von Exkludieren und neu inkludieren die Rede. Das habe ich noch nicht gemacht, aber alle drei Devices nochmal gelöscht und dann (ohne Neustart) über das IO ein "createNode 5" (?) abgesetzt. Dadurch wurden die drei Devices wieder angelegt, aber wieder kein steuerbares "slat"-Reading.

Da in dem anderen Thread die Rede davon war, dass der Aktor "zickig" sei, habe ich erst mal von weiteren Experimenten abgesehen, ebenso davon, die mir bisher nicht vertrauten xml-files näher anzusehen und hoffe jetzt hier mal auf "Nachhilfe", was denn genau zu tun ist, damit ich (irgend-) ein steuerbares Device bekomme, das
a) beide Elemente steuern kann (Position und Drehwinkel) und
b) "vernünftig" auf nummerische Positionsangaben sowie "on" und "off" reagiert...

Zu b) noch: Ziel ist es, die Jalousie via ASC (autoShuttersControl) ansteuern zu können. Dafür wäre es notwendig, dass man rein nummerisch steuert, also (z.B.) 0 = ganz zu, 100 = ganz offen. Damit scheint aber auch der Vorgänger gewisse Probleme zu haben, weswegen sich manche hier mit einer eventMap behelfen (siehe hier, der User Typ1er hat diesen Aktor, wenn ich das richtig verstanden habe.).
Ich hatte das ebenfalls versucht, nur dass die eventMap beim 223-er wieder etwas anders auszusehen hatte wie beim Vorgänger; nach der Umstellung auf VenetianBlind wollte die geänderte aber auch nicht mehr so recht...

Jemand Ideen, was zu tun ist bzw. wo anzufangen und mag mir verraten, was ich besser machen kann?

Lists liefere ich gerne nach, allerdings komme ich grade nicht gut an die Daten und list -R verhält sich bei ZWave auch etwas anders wie erwartet (das addressiere ich aber gesondert).

Danke vorab,

Beta-User

[majestro84]

Nutze den Vorgänger und der geht super mit ASC. Habe nur seit dem ich mein UZB aktualisiert habe ab und zu das das Reading Position nicht aktualisiert wird.

Das steuern über die Prozente sollte doch so funktionieren 0 zu 99 auf. Siehe Wiki vom Vorgänger

Code Auswählen Erweitern

Rollladen

Nach Kalibrierung kann die Rolllade sofort prozentual durch

set <device> dim <%>

gesteuert werden. Weitere Parametereinstellung sind grundsätzlich nicht notwendig.

Standardmäßig wird die Rollladenposition mit "off", "dimXY" (xy=1-99) und "on" angezeigt. Möchte man das Reading "position" mit aussschließlich zahlenmäßiger Angabe der Position haben, dann muss die Konfiguration für den Versand des Fibaro-Reports angepasst werden:

set <device> configByte 3 1

oder

set <device> configReportsType BlindPositionReportsSentToThe1


Hoffe habe dich da richtig verstanden.
Zur Lamellen Steuerung kann ich leider nicht sagen.

Gruß Alex

[Beta-User]

Danke, das mit dem configByte 3 1 werde ich mal testen, das kommt mir sinnvoll vor.

Vielleicht sollte ich noch ergänzen: Vor der Umstellung auf VenetianBlind hatte das "im Prinzip" - soweit erkennbar auch mit ASC (ich habe nur kurz die Fahrbefehle getestet, aber wenn das klappt, geht es auch mit ASC) - zu meiner Zufriedenheit funktioniert. Da ich aber auch die Lamellenposition steuern will, benötige ich die Umstellung, und ab da wurde es dann "seltsam".

Zum Vorgänger in Venetian hatte ich u.A. das hier von krikan gefunden:

list vom FGRM-222:Internals:
[...]
   STATE      Blind 0 Slat 0

(Ohne stateFormat, das auf irgendwas externes zugreift). Demnach kennt der Vorgänger in dem Modus einen Slat-STATE-Anteil, vermutlich müßte das auch darüber zu steuern sein.

Code Auswählen Erweitern

configReportsType BlindPositionReportsSentToThe1 habe ich nicht - bzw. zumindest hab' ich's bisher nicht gefunden, auch nichts, was irgendwie in die Richtung geht...

Ergänzend: ein get ... configAll hatte ich auch bereits abgesetzt.

[krikan]

Der FGR-223 hat wohl (im Gegensatz zum FGR(M)-222) die Command Class MANUFACTURER_PROPRIETARY mit der fibaro-spezifischen Ansteuerung des Aktors über positon.* und die entsprechenden Rückmeldungen (Fibaro-Reports) nicht. Das war zumindest mein Ergebnis aus den Angaben des Threads: https://forum.fhem.de/index.php/topic,96848.0/all.html.

Die Steuerung der Lamellen ist beim FGR-223 vermutlich nur über das Endpoint-Device möglich. Wenn Rückmeldungen über Veränderungen des Lamellenwinkels in keinem Device automatisch bei der standardmäßigen Assoziation mit Gruppe 1 kommen, tippe ich darauf, dass man auf mca-Assoziationen umstellen muss und auch eine Assoziation mit Gruppe 3 erfolgen muss. Das ist aber nur eine Idee und nicht getestet/gewusst, da ich keinen FGR223 im Zugriff habe.

Gruß, Christian

[Beta-User]

Grummel... Dieser Thread las sich so, als wäre die xml für den 223er jetzt vollständig . Mit Begrifflichkeiten wie "Assoziation mit Gruppe 3" femdle ich noch "ein wenig", es scheint aber erforderlich zu werden, dass ich mich da einlese (und mit diesen 144 Seiten des ominösen Handbuchs mal anfange), oder deute ich das falsch .

Gerne kann ich versuchen, einen "mittelbaren Zugriff" auf den FRG223 zu vermitteln. Was brauchst du bzw. was soll ich tun, wenn ich wieder vor Ort bin?
Einfach erst mal ein "set <Hauptkanal> mcaAdd 3" absetzen?

Ich werde dem am WE mal einen Taster verpassen (hängt grade nur an einem Jalousien-Doppel-Schalter, was ausgesprochen unhandlich ist), dann kann ich auch sowas wie neu assoziieren machen; mit dem Schalter bin ich zu langsam...

EDIT:
Evtl. hilfreicher Link dazu: https://community.hom.ee/t/roller-shutter-3-allgemeine-fragen/20022/3 - Handbuch mit
Assocation groups mapping:

Root	Endpoint	Association Group in Endpoint
Association Group 2	Endpoint 1	Association Group 2
Association Group 3	Endpoint 2	Association Group 2

[krikan]

Grummel... Dieser Thread las sich so, als wäre die xml für den 223er jetzt vollständig .

Gehe davon aus, dass die vollständig ist. Die Assoziation erfolgt bei dem Aktor -wie meistens- mit Command Class ASSOCIATION; sollte auch die meisten Standardfälle abdecken.
Assoziationen mit MULTI_CHANNEL_ASSOCIATION setzt FHEM nur in wenigen Ausnahmefällen automatisch. Das sind die, wo wir sicher waren und die Class ASSOCIATION unzureichend ist. Ansonsten ist der Anwender gefragt.

Weitere (wichtige) Schlußfolgerung aus dem Thread: Bestimmte Aktorfirmware hat laut Fibaro ein Problem mit der Positionsmeldung.

Mit Begrifflichkeiten wie "Assoziation mit Gruppe 3" femdle ich noch "ein wenig", es scheint aber erforderlich zu werden, dass ich mich da einlese (und mit diesen 144 Seiten des ominösen Handbuchs mal anfange), oder deute ich das falsch .

Die Themen Inklusion, Assoziation und Konfiguration zu kennen, schadet nicht und erleichtern das ZWave-Leben. Insbesondere Assoziationen ist aufgrund der verschiedenen Assoziationsklassen in mehreren Versionen und der teilweise eigenwilligen Umsetzung in den Geräten nicht gerade einfach. Für mich bietet das Thema immer wieder neue Überraschungen.

Gerne kann ich versuchen, einen "mittelbaren Zugriff" auf den FRG223 zu vermitteln. Was brauchst du bzw. was soll ich tun, wenn ich wieder vor Ort bin?
Einfach erst mal ein "set <Hauptkanal> mcaAdd 3" absetzen?

Nein, bitte übergangsweise an ZWDongle verbose-Level-Hochsetzen und folgendes Absetzen

Code Auswählen Erweitern

set <MainDevice> associationDel 1 <ControllerNodeId>
set <MainDevice> mcaAdd 1 3 0 <ControllerNodeId> 1

Dann bitte Testen und -falls Zeit/Lust besteht- bitte auch bei Erfolg Log von Schaltvorgängen mit kurzen Hinweisen zu Schaltvorgängen posten. Danke.

Bei mcaAdd könnte als Zielangabe "<ControllerNodeId> 0" statt "<ControllerNodeId> 1" besser sein. Müsste man testen.

Gruß, Christian

[krikan]

EDIT:
Evtl. hilfreicher Link dazu: https://community.hom.ee/t/roller-shutter-3-allgemeine-fragen/20022/3 - Handbuch mit
Assocation groups mapping:

Root	Endpoint	Association Group in Endpoint
Association Group 2	Endpoint 1	Association Group 2
Association Group 3	Endpoint 2	Association Group 2

Zu spät gelesen; verstehe ich jedoch nicht ohne selbst am Gerät experimentieren zu können. ->jetzt ist Assogroup 2 die Richtige/Wichtige??

[Beta-User]

Ich werd's versuchen.

Ein paar Fragen vorab noch: ich habe noch einen MapleCUN im Einsatz, mit dem ich die ersten (erfolglosen) Tests gemacht hatte. Da sind noch zwei (STCKABLE) ZWCUL-Definitionen vorhanden, die eventuell relevant sein könnten. Die hex-NodeId des .me-Dongles ist aber 01. Soll ich die ZWCUL-Definitionen vorher rauswerfen oder mit dem aktuellen Stand weitermachen? Bzw. ändert das was an den Befehlen, die du mir aufgeschrieben hast?

Die Themen Inklusion, Assoziation und Konfiguration zu kennen, schadet nicht und erleichtern das ZWave-Leben. Insbesondere Assoziationen ist aufgrund der verschiedenen Assoziationsklassen in mehreren Versionen und der teilweise eigenwilligen Umsetzung in den Geräten nicht gerade einfach. Für mich bietet das Thema immer wieder neue Überraschungen.

Schon klar, dass man "gewisse Grundlagen" braucht... Bisher hatte ich den Eindruck, dass das eigentlich auch nur etwas andere Begrifflichkeiten zu denselben "Problemen" wie bei HM bzw. zigbee sind (mal abgesehen davon, dass das Dongle - wie bei zigbee - seine "Partner" (=Pairs@HM) direkt "kennt" (also im eeprom der MCU auf dem Stick gespeichert hat, wie z.B. der CC2350@zigbee), das ist bei HM-BidCoS ggf. etwas anders; eine Assoziation gibt es auch bei zigbee, bei HM nennt sich das Peering, oder?). Dann werde ich mir die Spezifika@ZWave mal ansehen .

Mal schauen, ob es wirklich (nur) ein firmware-Thema auf dem Aktor ist, der verlinkte Beitrag von oben stimmt mich hoffnungsfroh, dass es ohne ein "echtes" Fibaro-GW geht. Mal sehen.

Logs versuche ich zu liefern, schließlich will ich auch Leuten helfen können, die ebenfalls glauben, dass ZWave besser ist als HM (BidCoS und IP)...

Zu spät gelesen; verstehe ich jedoch nicht ohne selbst am Gerät experimentieren zu können. ->jetzt ist Assogroup 2 die Richtige/Wichtige??

Ohne in der Materie bereits tief drin zu sein würde ich behaupten, dass das die Aussage des Fibaro-Handbuchs ist (da habe ich es rauskopiert).

[krikan]

Ein paar Fragen vorab noch: ich habe noch einen MapleCUN im Einsatz, mit dem ich die ersten (erfolglosen) Tests gemacht hatte. Da sind noch zwei (STCKABLE) ZWCUL-Definitionen vorhanden, die eventuell relevant sein könnten. Die hex-NodeId des .me-Dongles ist aber 01. Soll ich die ZWCUL-Definitionen vorher rauswerfen oder mit dem aktuellen Stand weitermachen? Bzw. ändert das was an den Befehlen, die du mir aufgeschrieben hast?

Sollte  eigentlich keinen Einfluß haben. Meine Installation hat auch ZWCul-Defs, die ich nur zum Testen brauche und ansonsten disabled sind. Befehle auf ZWave-Device-Ebene sind gleich.

Schon klar, dass man "gewisse Grundlagen" braucht... Bisher hatte ich den Eindruck, dass das eigentlich auch nur etwas andere Begrifflichkeiten zu denselben "Problemen" wie bei HM bzw. zigbee sind (mal abgesehen davon, dass das Dongle - wie bei zigbee - seine "Partner" (=Pairs@HM) direkt "kennt" (also im eeprom der MCU auf dem Stick gespeichert hat, wie z.B. der CC2350@zigbee), das ist bei HM-BidCoS ggf. etwas anders; eine Assoziation gibt es auch bei zigbee, bei HM nennt sich das Peering, oder?). Dann werde ich mir die Spezifika@ZWave mal ansehen .

Traue mich nicht in Vergleiche einzusteigen. HM ist zu lange her und ZigBee habe ich noch nie genutzt.
Wichtig für ZWave: Assoziationen der Geräte mit dem Controller bestimmen, was der Controller wie an Events/Infos bekommt. Ohne Assoziation des Controllers bekommt der Controller/Software grds (fast) keine Infos.

Mal schauen, ob es wirklich (nur) ein firmware-Thema auf dem Aktor ist, der verlinkte Beitrag von oben stimmt mich hoffnungsfroh, dass es ohne ein "echtes" Fibaro-GW geht. Mal sehen.

Firmware-Thema ist eigentlich bisher nur falsche Positionsangabe für Rolläden gewesen.

Logs versuche ich zu liefern, schließlich will ich auch Leuten helfen können, die ebenfalls glauben, dass ZWave besser ist als HM (BidCoS und IP)...

Ob es besser ist:?
Für mich war nur wichtig, die vorhandene Systemvielfalt zu reduzieren und HM hat es hier dann aus diversen Gründen nicht "überlebt".
Ansonsten bin ich nur neugierig, wie ZWave funktioniert. Also reiner Egoismus. 

Ohne in der Materie bereits tief drin zu sein würde ich behaupten, dass das die Aussage des Fibaro-Handbuchs ist (da habe ich es rauskopiert).

Ja, stammt aus dem Handbuch. Vollständige Handbücher gibt es bei Fibaro immer auf https://manuals.fibaro.com/ bzw. https://products.z-wavealliance.org/. Die gedruckten Beipackzettel sind bei ZWave meistens nur Schmalspurausgaben. Handbuch-Angabe verstehe ich aber nicht... 

[Beta-User]

bitte übergangsweise an ZWDongle verbose-Level-Hochsetzen und folgendes Absetzen

Code Auswählen Erweitern

set <MainDevice> associationDel 1 <ControllerNodeId>
set <MainDevice> mcaAdd 1 3 0 <ControllerNodeId> 1

Dann bitte Testen und -falls Zeit/Lust besteht- bitte auch bei Erfolg Log von Schaltvorgängen mit kurzen Hinweisen zu Schaltvorgängen posten. Danke.

Bei mcaAdd könnte als Zielangabe "<ControllerNodeId> 0" statt "<ControllerNodeId> 1" besser sein. Müsste man testen.

Moin, habe das eben mal versucht, logs anbei (zumindest im 2. sind auch die Schaltanweisungen dring). Für die <ControllerNodeId> habe ich 01 verwendet (ZWdongle sagt: "nodeIdHex 01").
Habe dann weiter 3 Devices, keine Änderung zu vorher, was die Steuerungsmöglichkeiten der einzelnen Devices angeht: Main-Device ohne Config-Optionen = Kanal 1, Kanal 2 = Lamellenposition.
Ob die Positionen@Kanal 1 richtig sind, mag ich noch nicht beurteilen, evtl. müßte nochmal kalibriert werden, aber komplett daneben scheint es nicht zu sein...

[krikan]

Wie oben geschrieben: Steuerungsmöglichkeit geht vermutlich nur über die 2. Endpoints; eine Möglichkeit über Hauptdevice erkenne ich nicht.
Die von mir genannten Befehle ändern nur das Rück-Meldeverhalten des Aktors an den Controller. Wunschziel meinerseits ist, dass Lamellenposition auch gemeldet wird.
Danke für Logs; anschauen meinerseits dauert noch.

Ohne Kalibrierung sind die alten FGRM222 nicht sinnvoll einsetzbar.

Main-Device

ohne Config-Optionen

= Kanal 1, Kanal 2 = Lamellenposition.

Was bedeutet ohne config-Optionen? Wird das XML für die configXY-Befehle nicht eingebunden?

[Beta-User]

Dass man zwei ZWave-Instanzen braucht für die Endpoints ist irgendwie ärgerlich (und vermutlich ein Nachteil gg. HM), weil das die Steuerung über ASC vermutlich sehr umständlich macht und auch der Status schlecht darstellbar ist, mal schauen...

Irgendwie hatte ich nach der Lektüre zum 222-er den Eindruck, dass da ein "Einheitsdevice" möglich sei und daraus dann geschlossen, dass das auch für den 223-er gehen müßte.

Was das Rückmeldeverhalten angeht: das hatte ich mißverstanden und melde mich dazu, sobald der Taster angeschlossen ist (vorher ist Henne und Ei schlecht zu unterscheiden).

Die Kalibrierung sollte durch sein, das hatte ich neulich schon angestoßen (glaube ich zumindest...).

Mit "ohne Config-Optionen" war nur gemeint, dass eben Kanal 1 dem Hauptdevice entspricht, nur eben in einer "abgespeckten" Version, die im wesentlichen nur die Steuerung der Jalousie erlaubt, aber eben keine Konfigurationsbefehle (ist m.E. ok so).

[krikan]

Irgendwie hatte ich nach der Lektüre zum 222-er den Eindruck, dass da ein "Einheitsdevice" möglich sei und daraus dann geschlossen, dass das auch für den 223-er gehen müßte.

FGRM222 geht definitiv als Einheitsdevice.
FGR223 erkenne ich nicht, wie das ohne Hilfskonstrukte (dummy?) umsetzbar ist. Eine Anpassungsmöglichkeit im Aktor fällt mir nicht ein.

Was das Rückmeldeverhalten angeht: das hatte ich mißverstanden und melde mich dazu, sobald der Taster angeschlossen ist (vorher ist Henne und Ei schlecht zu unterscheiden).

Bei ZWave_SWITCH_MULTILEVEL_5.02 erkenne ich MULTI_CHANNEL-Postions-Rückmeldungen (->gut) bei ZWave_SWITCH_MULTILEVEL_5.01 finde ich dagegen gar keine Rückmeldungen (-> schlecht)

Mit "ohne Config-Optionen" war nur gemeint, dass eben Kanal 1 dem Hauptdevice entspricht, nur eben in einer "abgespeckten" Version, die im wesentlichen nur die Steuerung der Jalousie erlaubt, aber eben keine Konfigurationsbefehle (ist m.E. ok so).

Historisch und vereinfacht:
Hauptdevice ist für die Kommunikationspartner, die kein MULTI_CHANNEL unterstützen; bietet nicht immer vollen Funktionsumfang.

Das ganze ist vermutlich noch ein bißchen Bastelei. Ich selbst kann mangels Gerät nur wilde Hypothesen aufstellen.

[Beta-User]

Nein, bitte übergangsweise an ZWDongle verbose-Level-Hochsetzen und folgendes Absetzen

Code Auswählen Erweitern

set <MainDevice> associationDel 1 <ControllerNodeId>
set <MainDevice> mcaAdd 1 3 0 <ControllerNodeId> 1

Dann bitte Testen und -falls Zeit/Lust besteht- bitte auch bei Erfolg Log von Schaltvorgängen mit kurzen Hinweisen zu Schaltvorgängen posten. Danke.

Bei mcaAdd könnte als Zielangabe "<ControllerNodeId> 0" statt "<ControllerNodeId> 1" besser sein. Müsste man testen.

So, jetzt habe ich versucht, mich wenigstens etwas in das Thema einzulesen.
Voräufiges Ergebnis: Weder mit mcaAdd ... 1 noch ... 0 bekomme ich irgendwelche Rückmeldungen, wenn ich lokal schalte. Es steht auch mit verbose 5 am ZWDongle nichts im log. (Von FHEM ausgelöste Schaltvorgänge schon).

Weitere Ideen bzw. kurze Hinweise, was ich jetzt wie "durchspielen" kann? (oder ist der Aktor halt doch einfach firmwaremäßig ...na ja?).
Und: ich habe kein Problem mit "wilden Hypothesen", geht auch darum, was zu lernen...

[krikan]

Zunaechst: Mein geposteter mcaAdd-Befehl war falsch. Damit wurde nicht mit Assogroup 3, sondern mit NodeID 3 assoziiert. Sorry.

Bitte lösche alle angelegten Assoziationen und dann von vorne:

Code Auswählen Erweitern

set <MainDevice> mcaAdd <GroupId> 0 <ControllerNodeId> 1
Bei GroupId bitte alle Groups der Reihenfolge nach setzen und Meldungen beobachten. Unnötige würde ich dann wieder löschen.

[Typ1er]

Hier mal ein list vom meiner Jalousie, ist aber der Rollershutter 2 mit Lamellensteuerung und Homekit Mapping

Code Auswählen Erweitern

Internals:
   DEF        dacfd218 10
   FUUID      5c44a1c8-f33f-06ea-500d-615df2d0d3e005e2
   IMAGE      /fhem/deviceimages/zwave/271.770.4096_fgr222.roller.shutter.controller.jpg
   IODev      ZWDongle_0
   LASTInputDev ZWDongle_0
   MSGCNT     29
   NAME       Jalousie_Links
   NR         208
   STATE      99
   TYPE       ZWave
   ZWDongle_0_MSGCNT 29
   ZWDongle_0_RAWMSG 0004000a06310504220000a800
   ZWDongle_0_TIME 2019-05-19 20:38:29
   ZWaveSubDevice no
   cmdsPending 0
   homeId     dacfd218
   isWakeUp   
   lastMsgSent 1558290334.86444
   nodeIdHex  0a
   READINGS:
     2019-05-19 16:38:29   UNPARSED        MANUFACTURER_PROPRIETARY 0891010f2603036363
     2019-05-19 20:25:01   assocGroup_1    Max 16 Nodes ZWDongle_0
     2019-05-19 20:25:01   assocGroup_2    Max 16 Nodes
     2019-05-19 20:25:01   assocGroup_3    Max 1 Nodes ZWDongle_0
     2019-05-19 20:25:00   assocGroups     3
     2019-05-19 20:25:14   configEnergyReports 10
     2019-05-19 20:25:14   configInRollerBlindModeOrVenetianBlind17 10
     2019-05-19 20:25:14   configInVenetianBlindModeTheParameter12 70
     2019-05-19 20:25:19   configManagingLamellasInResponseTo35 SetLamellasToTheirExtreme1
     2019-05-19 20:25:19   configMotorOperationDetection 10
     2019-05-19 20:25:19   configMotorOperationTime 240
     2019-05-19 20:25:19   configPeriodicPowerOrEnergyReports 3600
     2019-05-19 20:25:19   configPowerReports 10
     2019-05-19 20:25:24   configReportsType BlindPositionReportsSentToThe1
     2019-05-19 20:25:24   configResponseToFloodingAlarm NoReaction
     2019-05-19 20:25:24   configResponseToGeneralAlarm CloseBlind
     2019-05-19 20:25:24   configResponseToSmokeCOOrCO2Alarm OpenBlind
     2019-05-19 20:25:24   configResponseToTemperatureAlarm OpenBlind
     2019-05-19 20:25:24   configRollerShutterOperatingModes 2VenetianBlindModeWith2
     2019-05-19 20:25:25   configScenesAssociationsActivation AssociationsActivation
     2019-05-19 20:25:25   configSelfMeasurement SelfMeasurementInactive
     2019-05-19 20:25:25   configSetLamellasBackToPrevious13 2LamellasReturnToPreviouslySet2
     2019-05-19 20:25:25   configSwitchType ToggleSwitches
     2019-05-19 20:37:44   energy           0.95 kWh
     2019-05-19 20:25:25   mcaGroups       2
     2019-05-19 20:25:25   mca_1           Max 7 Nodes ZWDongle_0
     2019-05-19 20:25:25   mca_2           Max 7
     2019-05-19 20:25:08   model           FIBARO System FGRM222 Roller Shutter Controller 2
     2019-05-19 20:25:08   modelConfig     fibaro/fgrm222.xml
     2019-05-19 20:25:08   modelId         010f-0302-1000
     2019-05-19 20:25:23   neighborList    ZWDongle_0 Rollladen_Wz_Re Rollladen_Wz_Li Rollladen_Ki Rollladen_Sz Rollladen_Bu Rollladen_Bad Rollladen_Flur Jalousie_Rechts Jalousie_Mitte
     2019-05-19 20:25:28   position        Blind 99 Slat 99
     2019-05-19 20:38:29   position_blind  99
     2019-05-19 20:38:29   position_slat   99
     2019-05-19 20:38:29   power           0.0 W
     2019-05-19 20:25:08   state           associationAdd 3 1
     2019-05-19 20:25:34   timeToAck       0.032
     2019-05-19 20:25:34   transmit        OK
Attributes:
   IODev      ZWDongle_0
   classes    MULTI_CHANNEL_ASSOCIATION MANUFACTURER_SPECIFIC VERSION CONFIGURATION ASSOCIATION POWERLEVEL METER SWITCH_MULTILEVEL SENSOR_MULTILEVEL SWITCH_BINARY MANUFACTURER_PROPRIETARY PROTECTION MARK METER SENSOR_MULTILEVEL MANUFACTURER_PROPRIETARY SCENE_ACTIVATION SWITCH_MULTILEVEL SWITCH_BINARY
   devStateIcon 99.*:fts_window_2w 9\d.*:fts_shutter_10@orange 8\d.*:fts_shutter_20@orange 7\d.*:fts_shutter_30@orange 6\d.*:fts_shutter_40@orange 5\d.*:fts_shutter_50@orange 4\d.*:fts_shutter_60@orange 3\d.*:fts_shutter_70@orange 2\d.*:fts_shutter_80@orange 1\d.*:fts_shutter_90@orange \d.*:fts_shutter_100
   eventMap   /on:öffnen/off:schließen/positionSlat 0:Lamelle 0%/positionSlat 15:15%/positionSlat 50:50%/positionSlat 99:100%/
   genericDeviceType blind
   homebridgeMapping clear
CurrentPosition=position_blind,minValue=0,maxValue=99
TargetPosition=positionBlinds::position_blind,minValue=0,maxValue=99,minStep=1
CurrentTiltAngle=position_slat,minValue=0,maxValue=99
TargetTiltAngle=positionSlat::position_slat,minValue=0,maxValue=99,minStep=33
   icon       fts_shutter
   neighborListPos 648,3
   room       Homekit,Wintergarten,Z-Wave
   stateFormat position_blind
   userReadings position_blind { (split ' ',ReadingsVal("Jalousie_Links","position",0))[1]}, position_slat { (split ' ',ReadingsVal("Jalousie_Links","position",0))[3]}
   vclasses   ASSOCIATION:2 CONFIGURATION:1 MANUFACTURER_PROPRIETARY:1 MANUFACTURER_SPECIFIC:1 METER:2 MULTI_CHANNEL_ASSOCIATION:2 POWERLEVEL:1 PROTECTION:2 SCENE_ACTIVATION:1 SENSOR_MULTILEVEL:2 SWITCH_BINARY:1 SWITCH_MULTILEVEL:3 VERSION:1
   webCmd     dim:stop:öffnen:schließen:Lamelle 0%:15%:50%:100%

[Beta-User]

Zunaechst: Mein geposteter mcaAdd-Befehl war falsch. Damit wurde nicht mit Assogroup 3, sondern mit NodeID 3 assoziiert. Sorry.

Bitte lösche alle angelegten Assoziationen und dann von vorne:

Code Auswählen Erweitern

set <MainDevice> mcaAdd <GroupId> 0 <ControllerNodeId> 1
Bei GroupId bitte alle Groups der Reihenfolge nach setzen und Meldungen beobachten. Unnötige würde ich dann wieder löschen.

So, bin zwar noch nicht "fertig", aber ich habe schon nach  "set Jalousie_WZ_neu mcaAdd 1 0 1 1" ein Zwischenresultat: ich sehe in den Endpoints die Level nach lokaler Schaltung (also nicht aus FHEM heraus, sondern mit den Tastern); die Werte sind auch halbwegs plausibel, allerdings erst mal ohne "heavy testing".
Brauchst du einen Log-Auszug?
In dem Zusammenhang ein paar Anmerkungen:
- Es wird nichts im "Hauptdevice" angezeigt, ich nehme an, das hängt mit dem folgenden zusammen?
- das Ding ist nicht in der Class BASIC_WINDOW_COVERING. Würde es helfen, das irgendwie (wie?) da reinzubasteln?
- die (englische) cref zu mcaAdd ist (m.E.) selbst dann "schwer verdaulich", wenn man weiß, nach was man sucht. Da stehen letztlich viel mehr Parameter-Worte drin als Parameter verwendet werden. Hier wäre doch

mcaAdd <groupId> 0 <node1> <node2>

ausreichend gewesen, mit dem Hinweis, dass "0" der Trenner ist. Wenn es eine längere Form gibt, sollte man auch ein dazu passendes Beispiel machen. Oder übersehe ich da was?

@Typ1er:
Danke für das list. Im Moment bin ich noch etwas unschlüssig, wie ich das verwerten kann. Da muß ich wohl noch "spielen und lernen"...

[krikan]

Brauchst du einen Log-Auszug?

Probiere erst einmal weiter.  Bin momentan zeitlich eng.

- Es wird nichts im "Hauptdevice" angezeigt, ich nehme an, das hängt mit dem folgenden zusammen?

Kann gut  sein, da die Werte aufgrund der Assoziation in den Endpoint-Childrens landen. Ist gerätespezifisch. Zusammenhang gibt es nicht.

- das Ding ist nicht in der Class BASIC_WINDOW_COVERING. Würde es helfen, das irgendwie (wie?) da reinzubasteln?

Nein.
Würde nur helfen, wenn das Gerät die Class könnte und fälschlicherweise nicht im NIF bei der Inklusion an FHEM melden würde. Laut Datenblatt kann der FGR223 die nicht und es würde mich auch wundern, da diese Class seit Ewigkeiten "deprecated" ist. Es gibt kaum ein Gerät, das die Class nutzt(e). Gehe auch davon aus, dass ZWavePlus-Zertifizierung mit der Class nicht erteilt würde.

- die (englische) cref zu mcaAdd ist (m.E.) selbst dann "schwer verdaulich", wenn man weiß, nach was man sucht. Da stehen letztlich viel mehr Parameter-Worte drin als Parameter verwendet werden. Hier wäre doch ausreichend gewesen, mit dem Hinweis, dass "0" der Trenner ist. Wenn es eine längere Form gibt, sollte man auch ein dazu passendes Beispiel machen. Oder übersehe ich da was?

Jein. Muss jemand erstellen.
Problem: Das wird sehr schnell sehr ausführlich; außerdem müsste man die diversen Versionen der Class berücksichtigen. Befürchte, dass für einen kompletten Überblick ein Studium der veröffentlichten COMMAND CLASS Spezifikation notwendig ist.

[krikan]

- das Ding ist nicht in der Class BASIC_WINDOW_COVERING. Würde es helfen, das irgendwie (wie?) da reinzubasteln?

Ergänzend: Das Attribut classes bestimmt iW nur, welche set-/get-Befehle angeboten werden. Von FHEM empfangene Nachrichten eines Gerätes werden unabhängig vom Attributwert ausgewertet: Wenn FHEM die Nachricht kennt, wird ein passendes Event/Reading erzeugt; ansonsten landet die Nachricht im Reading UNPARSED.

[stekram]

Hallo zusammen,

dies ist mein erster Post hier im Forum, also seht es mir nach, wenn ich nicht alle Fäden die es irgendwo gab kenne. Ich besitze zum Test auch einen FGR-223 und möchte Euch mal meine aktuellen Erfahrungen mitteilen.

Ich versuche seit ungefähr Ende März/Anfang April den FGR-223 mit FHEM und einem ZME_UZB1 konfiguriert zu bekommen. Die erste Hürde war das Pairing. Bei mir hat es nicht mit dem Schalter funktioniert, sondern nur direkt mit dem Knopf am FGR. Als Hardware-Schalter verwende ich ein Modell mit zwei Tastenwippen, d.h. jeweils eine für Auf- und eine für Ab-Bewegung mit "Feststellmöglichkeit". Diesen Schaltertyp musste ich anschließend erstmal korrekt hinterlegen, denn per Default war nur der Auf-Schalter aktiv, d.h. Parameter 20 auf Wert 1. Den Parameter 151 habe ich dann auf den Wert 2 für Jalousien gestellt und dann die Kalibrierung angestoßen. Die Laufzeiten wurden dabei relativ genau ermittelt.

In FHEM sehe ich das Hauptgerät und zwei Untergeräte. Wobei das erste davon identische Werte wie das Hauptgerät liefert was den aktuellen "reportedState" angeht. Anfangs habe ich hier auch nur 0 und 99 gesehen, inzwischen (ungefähr seit Mai) stimmt das Reading aber (nur FHEM Updates, keine FW Updates).

Ich habe relativ lange gebraucht um zu kapieren wozu das zweite Untergerät gut ist. Ein set-dim resultierte immer in einer sehr kurzen Laufzeit, selbst bei den Extremwerten 0 und 99. Irgendwann habe ich mal den Parameter 152 angepasst und dabei festgestellt, dass das zweite Gerät immer exakt die Laufzeit hat, die für die Lamellenverstellung konfiguriert ist. Mehr noch, der dort zurückgemeldete Wert in "reportedState" entspricht auch immer der Neigung der Lamellen, auch wenn ich diesen über die Hardwareschalter verändere.

Was mich etwas verwirrt ist, dass ein "dim 0" bei mir bedeutet Jalousie komplett geschlossen und ein "dim 99" komplett offen, ist das normal? Gefühlt ist das für mich verkehrt herum. Für die Lamellenstellung gilt, "dim 0" bedeutet komplett nach außen gekippt (für mich die Normalstellung) und "dim 99" bedeutet komplett nach innen gekippt. "dim 50" stellt zuverlässig auf waagrechte Mittelstellung, egal wie die Neigung zuvor war.

Damit ist die Steuerung jetzt sehr genau möglich, allerdings bedarf es etwas Logik um immer die Richtige Kombination von Untergerät 1 und Untergerät zwei zu erwischen. Kritisch hierbei vor allem der Parameter 153, diesen habe ich nach einigen Versuchen jetzt auf den Wert 0 gestellt. Mein Hauptproblem dabei ist, wenn jemand die Jalousie manuell ganz nach oben fährt, dass dann der Lamellenwinkel auf "dim 99" (komplett nach innen gekippt) gestellt wird. Fährt man die Jalousie später, per FHEM dann auf einen gewünschten anderen Wert, dann wird explizit dieser nach innen gekippte Zustand hergestellt, was in der Regel ungewollt ist.

Soweit erstmal meine Beobachtungen und mein erster Forums-Post, für jegliche Anregung zu weiteren Optimierungen bin ich dankbar!

Viele Grüße
Steffen

[Beta-User]

Moin,

erst mal herzlich willkommen im Forum, Steffen!

@krikan:
Wie es scheint, habe ich "zu früh" was rausgeschmissen, oder täuscht mich das (ich glaube, ziemlich genau nach meinem Post gab es eine  Umstellung bei den xml's, oder?)?

Zwischenzeitlich hatte ich noch ein "mcaAdd 2 0 1 1" abgesetzt, und bekomme seither auf das Hauptdevice auch Infos von lokalen Schaltungen, aber leider nicht mehr den aktuellen dim-Wert von Kanal 1 (steuern geht noch). So wie sekram das schreibt, wäre es vermutlich das beste, das Ding nochmal zu resetten, jedenfalls die wichtigsten Readings und Infos scheinen dann ja doch schon da zu sein (wenn auch an einer etwas ungeschickten Stelle) .

@stekram: Es gibt noch eine Einstelloption, nämlich dafür, wie die Lamellen nach dem Fahren stehen sollen. Leider ist das trotzdem irgendwie unglücklich gelöst, denn wenn dim 99 angesagt ist, sollen die eigentlich wirklich ganz oben bleiben, aber zum Drehen geht es eben doch nach unten...
dim 99 ist "in meiner Welt" übrigens normal für den Öffnungsgrad, das entspricht auch der "Denke" bei Homematic-Geräten, und ist nur für ROLLO-Nutzer "sonderbar".

Was das Lamellen-Thema nach "FHEM-Fahrten" angeht, ist das für mich erst mal eine Sache, die ich im Zusammenhang mit der automatisierten Steuerung lösen möchte. Dafür verwende ich AutoShuttersControl, wo es aber vermutlich noch spezieller Code-Parts bedarf, um gleich die Einstellung der Lamellenpositiion "mitzuerledigen". Erst wenn ich dann noch "Nacharbeitsbedarf" haben sollte für Bedienung aus FHEM heraus, werde ich über notify-Code nachdenken (der dann ASC-Fahrten aussondern müßte).

Was ich aber gerne angehen würde (wenn die Grundsteuerung dann paßt und ich die korrekten Statusmeldungen habe), wäre ein devStateIcon/DeviceOverview oder eine ReadingsGroup, damit man beide Geräte (Öffnung und Drehwinkel) sehen (und steuern) kann.
Da muß ich mich dann aber noch etwas vertiefter eindenken; im Moment sehe ich Schwierigkeiten dahingehend, wie man über ein knob-Widget ein "anderes" Device steuern kann (für den Drehwinkel finde ich knob besser als einen slider, der auch zu breit wäre).

Bis dahin erst mal,

Beta-User

[stekram]

@Beta-User: Danke für die Infos! Wenn ich händisch fahre, dann bleibt er auch ganz oben und der Wert ist "dim 99". Da dies aber leider der komplett nach innen gekippten Variante entspricht, steht die Jalousie selten beim losfahren in dieser Position, sondern in der Regel bei "dim 0" oder irgendwo dazwischen. In der Praxis bedeutet das beim automatisierten kompletten Hochfahren dann, dass er nach erreichen des Endes nochmal etwas herunterfährt um den Neigungswinkel wieder herzustellen.

Mit welchem Parameter kann ich den Wert nach dem Fahren festlegen? Ich finde im Handbuch nur 153 um festzulegen ob auch nach manuellen Schalteraktionen die Neigungswinkel wieder hergestellt werden soll. Dies führt aber eher zu Verwirrungen und beim kompletten Hochfahren zu leicht sichtbaren bzw. minimal heruntergefahrenen Jalousien. Daher habe ich das jetzt mal auf Wert 0 gestellt, für mich die intuitivste Variante.

[Beta-User]

Parameter 153 sollte das gewesen sein, aber glücklich bin ich bisher tatsächlich auch mit keiner bisher getesteten Variante. Wie geschrieben, halte ich die Sache an der Stelle für nicht zuende gedacht, weil man in der Regel ja genau beim Hochfahren haben will, das das Ding komplett "im Kasten" ist und auch da bleibt. (Für mich sinnig) wäre, wenn die firmware das "on" (100%) auf diesem Kanal "untypisch" (für einen Dimmer...) interpretieren würde, nämlich als "fahr das Teil ganz ein, merke dir aber für die nächste Fahrt die Lamellenstellung").

(Anmerkung @stekram: Ich bin in ZWave ziemlicher noob, bitte beachten!)

[krikan]

Wie es scheint, habe ich "zu früh" was rausgeschmissen, oder täuscht mich das (ich glaube, ziemlich genau nach meinem Post gab es eine  Umstellung bei den xml's, oder?)?

Es gab keine Umstellung mit Auswirkungen auf Assoziationen beim FGR-223. Allenfalls die configXY-Befehle könnten sich geändert haben (habe das nicht kontrolliert!); das hat aber hier mMn keine Bedeutung.

[gZWm]

Hallo zuammen,

ich betreibe auch einen FGR-223 (übrigens mit FW 5.0) an einer Jalousie. Nach etwas längerem Herumkonfigurieren lief eigentlich alles: Direktes Anfahren  ("dim") bestimmter Positionen und Winkel über die beiden Endpoints sowie ein "devStateIcon" für den aktuellen Zustand.

Aber jetzt habe ich den FGR nochmal rausgeworfen und neu SECURE inkludiert. Alles wieder konfiguriert wie zuvor, aber die beiden Endpoints akzeptieren kein "dim" mehr (geht nur beim Haupteintrag) und bei den Classes der Endpoints ist kein SWITCH_MULTILEVEL mehr aufgeführt, was wohl (?) die dafür Ursache ist. Das kann ich zwar nachtragen und dann geht "dim" wieder. Aber der "devStateIcon" funktioniert nur auf dem Haupteintrag, nicht bei den Endpoints.

Die beiden Endpoints haben übrigens nur classes und keine secure_classes wie der Haupteintrag. Hat das alles so seine Richtigkeit? Sind die Endpoints dann überhaupt verschlüsselt? Ich blicke bei all dem noch nicht so wirklich durch.

Wie ist das eigentlich mit Assoziationen mit non-Secure Geräten - ist das überhaupt möglich? (dann wohl aber unsicher?)

[Beta-User]

Hallo zusammen,

nach einigem Rumfrickeln und Probieren mal mein aktueller Zwischenstand...

Vorab mal die RAW-Definitionen der ZWave-Geräte samt setstate:

Code Auswählen Erweitern

defmod ZWave_SWITCH_MULTILEVEL_8 ZWave 12345678 8
attr ZWave_SWITCH_MULTILEVEL_8 IODev zwaveme
attr ZWave_SWITCH_MULTILEVEL_8 classes ZWAVEPLUS_INFO SWITCH_MULTILEVEL ASSOCIATION MULTI_CHANNEL_ASSOCIATION ASSOCIATION_GRP_INFO TRANSPORT_SERVICE VERSION MANUFACTURER_SPECIFIC DEVICE_RESET_LOCALLY POWERLEVEL SECURITY SECURITY_S2 METER CONFIGURATION CRC_16_ENCAP ALARM PROTECTION MULTI_CHANNEL CENTRAL_SCENE FIRMWARE_UPDATE_MD APPLICATION_STATUS SUPERVISION
attr ZWave_SWITCH_MULTILEVEL_8 cmdIcon on:fts_shutter_up off:fts_shutter_down up:control_plus down:control_minus toggle:fts_shutter_updown stop:control_x
attr ZWave_SWITCH_MULTILEVEL_8 devStateIcon off:fts_shutter_up:on on:fts_shutter_down:off dim.9\d.*:fts_shutter_10:off dim.8\d.*:fts_shutter_20:off dim.7\d.*:fts_shutter_30:off dim.6\d.*:fts_shutter_40:off dim.5\d.*:fts_shutter_50:off dim.4\d.*:fts_shutter_60:on dim.3\d.*:fts_shutter_70:on dim.2\d.*:fts_shutter_80:on dim.1\d.*:fts_shutter_90:on dim.\d.*:fts_shutter_100:on
attr ZWave_SWITCH_MULTILEVEL_8 eventMap { usr=>{'dim.100'=>'dim 99'}}
attr ZWave_SWITCH_MULTILEVEL_8 userReadings dim:.*dim.* {ReadingsNum("ZWave_SWITCH_MULTILEVEL_8","state",0)}
attr ZWave_SWITCH_MULTILEVEL_8 vclasses ALARM:8 APPLICATION_STATUS:1 ASSOCIATION:2 ASSOCIATION_GRP_INFO:2 CENTRAL_SCENE:3 CONFIGURATION:1 CRC_16_ENCAP:1 DEVICE_RESET_LOCALLY:1 FIRMWARE_UPDATE_MD:4 MANUFACTURER_SPECIFIC:2 METER:3 MULTI_CHANNEL:4 MULTI_CHANNEL_ASSOCIATION:3 POWERLEVEL:1 PROTECTION:2 SECURITY:1 SECURITY_S2:1 SUPERVISION:1 SWITCH_MULTILEVEL:4 TRANSPORT_SERVICE:2 VERSION:2 ZWAVEPLUS_INFO:2
attr ZWave_SWITCH_MULTILEVEL_8 webCmd on:off:dim
attr ZWave_SWITCH_MULTILEVEL_8 widgetOverride dim:colorpicker,BRI,0,1,99

defmod Jalousie_WZ ZWave 12345678 2049
attr Jalousie_WZ userattr 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 ASC_DriveUpMaxDuration ASC_Drive_Offset ASC_Drive_OffsetStart 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_PrivacyDownTime_beforNightClose ASC_PrivacyDown_Pos ASC_RainProtection:on,off ASC_Roommate_Device ASC_Roommate_Reading ASC_Self_Defense_Exclude:on,off ASC_Shading_Angle_Left ASC_Shading_Angle_Right ASC_Shading_Direction 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_Cloudy ASC_Shading_StateChange_Sunny ASC_Shading_WaitingPeriod ASC_ShuttersPlace:window,terrace 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 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_subType:twostate,threestate room_map structexclude
attr Jalousie_WZ ASC 2
attr Jalousie_WZ ASC_BrightnessSensor Bewegungsmelder_1
attr Jalousie_WZ ASC_DriveUpMaxDuration 65
attr Jalousie_WZ ASC_LockOut soft
attr Jalousie_WZ ASC_Open_Pos 99
attr Jalousie_WZ ASC_Pos_Reading dim
attr Jalousie_WZ ASC_Shading_Angle_Left 25
attr Jalousie_WZ ASC_Shading_Angle_Right 30
attr Jalousie_WZ ASC_Shading_Direction 115
attr Jalousie_WZ ASC_Shading_Pos 15
attr Jalousie_WZ ASC_Time_Down_Early 18:15
attr Jalousie_WZ ASC_Time_Down_Late 22:30
attr Jalousie_WZ ASC_Time_Up_Early 06:30
attr Jalousie_WZ ASC_Time_Up_Late 09:00
attr Jalousie_WZ ASC_Time_Up_WE_Holiday 08:30
attr Jalousie_WZ ASC_Ventilate_Pos 85
attr Jalousie_WZ ASC_WindParameters 60
attr Jalousie_WZ ASC_WindowRec Terrassentuer_WZ
attr Jalousie_WZ IODev zwaveme
attr Jalousie_WZ alias Wohnzimmer-Jalousie
attr Jalousie_WZ classes ZWAVEPLUS_INFO SWITCH_MULTILEVEL ASSOCIATION MULTI_CHANNEL_ASSOCIATION ASSOCIATION_GRP_INFO SECURITY SECURITY_S2 SUPERVISION METER ALARM APPLICATION_STATUS
attr Jalousie_WZ cmdIcon on:fts_shutter_up off:fts_shutter_down up:control_plus down:control_minus toggle:fts_shutter_updown stop:control_x
attr Jalousie_WZ devStateIcon {devStateIcon_FGR223($name)}
attr Jalousie_WZ eventMap { usr=>{'dim.100'=>'dim 99','on'=>'dim 99'}}
attr Jalousie_WZ group Türen und Fenster
attr Jalousie_WZ icon fts_shutter_updown
attr Jalousie_WZ room Wohnzimmer
attr Jalousie_WZ userReadings dim:(dim|reportedState).* {$1 =~ /reportedState/ ? ReadingsNum($name,"reportedState",0):ReadingsNum($name,"state",0)}
attr Jalousie_WZ webCmd dim
attr Jalousie_WZ widgetOverride dim:colorpicker,BRI,0,1,99

defmod ZWave_SWITCH_MULTILEVEL_8.02 ZWave 12345678 2050
attr ZWave_SWITCH_MULTILEVEL_8.02 IODev zwaveme
attr ZWave_SWITCH_MULTILEVEL_8.02 classes ZWAVEPLUS_INFO SWITCH_MULTILEVEL ASSOCIATION MULTI_CHANNEL_ASSOCIATION ASSOCIATION_GRP_INFO SECURITY SECURITY_S2 SUPERVISION APPLICATION_STATUS
attr ZWave_SWITCH_MULTILEVEL_8.02 room ZWave
attr ZWave_SWITCH_MULTILEVEL_8.02 userReadings state:swmStatus.* {ReadingsNum($name,"swmStatus",0)}
attr ZWave_SWITCH_MULTILEVEL_8.02 webCmd dim


setstate Jalousie_WZ dim 0
setstate Jalousie_WZ 2019-06-16 16:11:07 ASC_Enable on
setstate Jalousie_WZ 2019-06-18 09:52:08 ASC_ShuttersLastDrive manual
setstate Jalousie_WZ 2019-06-18 22:14:05 ASC_Time_DriveDown 19.06.2019 - 22:14
setstate Jalousie_WZ 2019-06-18 22:14:05 ASC_Time_DriveUp 19.06.2019 - 08:30
setstate Jalousie_WZ 2019-06-16 13:49:02 UNPARSED SWITCH_MULTILEVEL 04260114ff
setstate Jalousie_WZ 2019-06-16 16:27:20 associatedWith ZWave_SWITCH_MULTILEVEL_8
setstate Jalousie_WZ 2019-06-19 07:34:32 dim 0
setstate Jalousie_WZ 2019-06-19 07:41:38 energy  0.35 kWh
setstate Jalousie_WZ 2019-06-19 07:51:14 power  0 W
setstate Jalousie_WZ 2019-06-19 07:34:30 reportedState dim 3
setstate Jalousie_WZ 2019-06-19 07:34:32 state dim 0
setstate Jalousie_WZ 2019-06-19 07:34:30 swmStatus 3 target 3 duration unknown

setstate ZWave_SWITCH_MULTILEVEL_8 dim 84
setstate ZWave_SWITCH_MULTILEVEL_8 2019-06-02 15:43:24 ASC_Enable on
setstate ZWave_SWITCH_MULTILEVEL_8 2019-06-05 06:30:02 ASC_ShuttersLastDrive day open
setstate ZWave_SWITCH_MULTILEVEL_8 2019-06-16 08:30:02 ASC_Time_DriveDown 16.06.2019 - 22:13
setstate ZWave_SWITCH_MULTILEVEL_8 2019-06-16 08:30:02 ASC_Time_DriveUp 17.06.2019 - 08:30
setstate ZWave_SWITCH_MULTILEVEL_8 2019-06-16 13:49:02 UNPARSED SWITCH_MULTILEVEL 04260114ff
setstate ZWave_SWITCH_MULTILEVEL_8 2019-06-16 16:27:20 associatedWith Jalousie_WZ,ZWave_SWITCH_MULTILEVEL_8.02
setstate ZWave_SWITCH_MULTILEVEL_8 2019-06-02 15:40:43 configAlarmConfiguration1stSlot 0
setstate ZWave_SWITCH_MULTILEVEL_8 2019-06-02 15:40:43 configAlarmConfiguration2stSlotWater 100597760
setstate ZWave_SWITCH_MULTILEVEL_8 2019-06-02 15:40:43 configAlarmConfiguration3stSlotSmoke 33488897
setstate ZWave_SWITCH_MULTILEVEL_8 2019-06-02 15:40:43 configAlarmConfiguration4stSlotCO 50266113
setstate ZWave_SWITCH_MULTILEVEL_8 2019-06-02 15:40:43 configAlarmConfiguration5stSlotHeat 83820545
setstate ZWave_SWITCH_MULTILEVEL_8 2019-06-02 15:40:43 configDelayMotorStopAfterReachingEnd154 10
setstate ZWave_SWITCH_MULTILEVEL_8 2019-06-02 15:40:43 configEnergyReportsOnChange 10
setstate ZWave_SWITCH_MULTILEVEL_8 2019-06-02 15:40:43 configEnergyReportsPeriodic 3600
setstate ZWave_SWITCH_MULTILEVEL_8 2019-06-02 15:40:43 configForceCalibration DeviceIsCalibrated
setstate ZWave_SWITCH_MULTILEVEL_8 2019-06-02 15:40:43 configInputsOrientation Default
setstate ZWave_SWITCH_MULTILEVEL_8 2019-06-02 15:40:43 configMeasuringPowerConsumedByThe60 Disabled
setstate ZWave_SWITCH_MULTILEVEL_8 2019-06-02 15:40:43 configMotorOperationDetection 10
setstate ZWave_SWITCH_MULTILEVEL_8 2019-06-02 15:40:43 configOperatingMode VenetianBlind
setstate ZWave_SWITCH_MULTILEVEL_8 2019-06-02 15:40:43 configOutputsOrientation Default
setstate ZWave_SWITCH_MULTILEVEL_8 2019-06-02 15:40:43 configPowerReportsOnChange 15
setstate ZWave_SWITCH_MULTILEVEL_8 2019-06-02 15:40:43 configPowerReportsPeriodic 3600
setstate ZWave_SWITCH_MULTILEVEL_8 2019-06-02 15:40:43 configS1SwitchScenesSent 0
setstate ZWave_SWITCH_MULTILEVEL_8 2019-06-02 15:40:43 configS2SwitchScenesSent 0
setstate ZWave_SWITCH_MULTILEVEL_8 2019-06-02 15:40:43 configSetSlatsBackToPreviousPosition InCaseOfTheMainController1
setstate ZWave_SWITCH_MULTILEVEL_8 2019-06-02 15:40:44 configSwitchType MomentarySwitches
setstate ZWave_SWITCH_MULTILEVEL_8 2019-06-02 15:40:44 configTimeOfDownMovement 6630
setstate ZWave_SWITCH_MULTILEVEL_8 2019-06-02 15:40:44 configTimeOfUpMovement 6778
setstate ZWave_SWITCH_MULTILEVEL_8 2019-06-02 15:40:44 configVenetianBlindTimeOfFullTurnOfThe152 100
setstate ZWave_SWITCH_MULTILEVEL_8 2019-06-16 15:42:45 dim 84
setstate ZWave_SWITCH_MULTILEVEL_8 2019-06-16 14:00:34 energy 0.3 kWh
setstate ZWave_SWITCH_MULTILEVEL_8 2019-06-02 15:30:49 mcCapability_01 ZWAVEPLUS_INFO SWITCH_MULTILEVEL ASSOCIATION MULTI_CHANNEL_ASSOCIATION ASSOCIATION_GRP_INFO SECURITY SECURITY_S2 SUPERVISION METER ALARM APPLICATION_STATUS
setstate ZWave_SWITCH_MULTILEVEL_8 2019-06-02 15:30:49 mcCapability_02 ZWAVEPLUS_INFO SWITCH_MULTILEVEL ASSOCIATION MULTI_CHANNEL_ASSOCIATION ASSOCIATION_GRP_INFO SECURITY SECURITY_S2 SUPERVISION APPLICATION_STATUS
setstate ZWave_SWITCH_MULTILEVEL_8 2019-06-02 15:30:49 mcEndpoints total 2, different
setstate ZWave_SWITCH_MULTILEVEL_8 2019-06-16 15:42:34 mcaGroups 3
setstate ZWave_SWITCH_MULTILEVEL_8 2019-06-16 15:42:34 mca_1 Max 1 Nodes zwaveme:0
setstate ZWave_SWITCH_MULTILEVEL_8 2019-06-16 15:42:34 mca_2 Max 5 Nodes zwaveme:1
setstate ZWave_SWITCH_MULTILEVEL_8 2019-06-16 15:42:34 mca_3 Max 5 Nodes zwaveme:2
setstate ZWave_SWITCH_MULTILEVEL_8 2019-06-02 15:30:49 model FIBARO System FGR223 Roller Shutter Controller 3
setstate ZWave_SWITCH_MULTILEVEL_8 2019-06-02 15:30:49 modelConfig fibaro/fgr223.xml
setstate ZWave_SWITCH_MULTILEVEL_8 2019-06-02 15:30:49 modelId 010f-0303-1000
setstate ZWave_SWITCH_MULTILEVEL_8 2019-06-16 14:44:14 power 0 W
setstate ZWave_SWITCH_MULTILEVEL_8 2019-06-16 15:37:07 reportedState swmEnd
setstate ZWave_SWITCH_MULTILEVEL_8 2019-06-16 15:42:45 state dim 84
setstate ZWave_SWITCH_MULTILEVEL_8 2019-06-16 14:43:41 swmStatus 76 target 76 duration unknown
setstate ZWave_SWITCH_MULTILEVEL_8 2019-06-19 07:50:41 timeToAck 0.035
setstate ZWave_SWITCH_MULTILEVEL_8 2019-06-19 07:50:41 transmit OK

setstate ZWave_SWITCH_MULTILEVEL_8.02 50
setstate ZWave_SWITCH_MULTILEVEL_8.02 2019-06-18 09:52:04 UNPARSED SWITCH_MULTILEVEL 0426015dff
setstate ZWave_SWITCH_MULTILEVEL_8.02 2019-06-18 19:30:42 applicationStatus cmdRejected
setstate ZWave_SWITCH_MULTILEVEL_8.02 2019-06-16 16:27:20 associatedWith ZWave_SWITCH_MULTILEVEL_8
setstate ZWave_SWITCH_MULTILEVEL_8.02 2019-06-02 20:13:17 mcaGroups 2
setstate ZWave_SWITCH_MULTILEVEL_8.02 2019-06-02 20:13:17 mca_1 Max 0 Nodes zwaveme
setstate ZWave_SWITCH_MULTILEVEL_8.02 2019-06-02 20:13:17 mca_2 Max 5 Nodes zwaveme:2
setstate ZWave_SWITCH_MULTILEVEL_8.02 2019-06-19 07:50:44 reportedState dim 50
setstate ZWave_SWITCH_MULTILEVEL_8.02 2019-06-19 07:50:44 state 50
setstate ZWave_SWITCH_MULTILEVEL_8.02 2019-06-19 07:50:44 swmStatus 50 target 50 duration unknown

Die aktuelle Konfiguration sieht danach also wie folgt aus (firmware ist auch 5.0, es scheint aber eine aktuellere 5.1 zu geben):
- Das Hauptgerät
-- ist als VentetianBlind konfiguriert;
-- Die Assoziation der Gruppe 1 gelöscht;
-- mca-Assoziazionen gibt es nur folgende:
  - mca_1 => zwaveme:0
  - mca_2 => zwaveme:1
  - mca_3 => zwaveme:2
=> Damit bekomme ich alle Schaltvorgänge auf die Kanaldevices gemeldet, und zwar als %-Angabe, egal, ob durch FHEM verursacht oder durch lokale Schaltvorgänge am Aktor selbst (Tasterkonfiguration mit Doppeltastern).
Das Hauptgerät nutze ich jetzt in der Regel nicht mehr zur Steuerung, das findet sich jetzt nur noch in einem Unterraum.

- Der 1. Kanal wird in der Raumansicht angezeigt und zur Steuerung des ganzen (auch des 2. Kanals!) genutzt. Details dann unten.
- Der 2. Kanal ist auch in einen internen Unterraum verschoben, und mit einem userReading versehen, damit man ggf. auch eine lokale Schaltung via Taster als nummerischen Wert im state sehen kann:

Code Auswählen Erweitern

attr ZWave_SWITCH_MULTILEVEL_8.02 userReadings state:swmStatus.* {ReadingsNum($name,"swmStatus",0)}

Die Raumansicht (des 1. Kanals) sowie die Bereitstellung eines für ASC erforderlichen nummerischen Level-Readings (hier "dim"), wird mit folgenden Attributen gesteuert:

Code Auswählen Erweitern

attr Jalousie_WZ devStateIcon {devStateIcon_FGR223($name)}
attr Jalousie_WZ eventMap { usr=>{'dim.100'=>'dim 99','on'=>'dim 99'}}
attr Jalousie_WZ icon fts_shutter_updown
attr Jalousie_WZ room Wohnzimmer
attr Jalousie_WZ userReadings dim:(dim|reportedState).* {$1 =~ /reportedState/ ? ReadingsNum($name,"reportedState",0):ReadingsNum($name,"state",0)}
attr Jalousie_WZ webCmd dim
attr Jalousie_WZ widgetOverride dim:colorpicker,BRI,0,1,99
Die letzten beiden sorgen dafür, dass rechts ein Brightness-Slider für den dim-Wert erscheint, mit dem Perl-devStateIcon bekomme ich dann noch links davon (von rechts)
- eine Level-Anzeige durch ein (halbwegs) passendes Icon;
- einen "Stop"-Button
- ein Icon, das den jeweiligen Drehwinkel der Lamellen anzeigt (3 Stufen), das ganze klickbar: (vereinfacht gesagt) von 0% wird auf 25% geschaltet, von 25% auf 50% und von 50% auf 0%,
- zuletzt noch eine nummerische Anzeige des Lamellenwinkes (könnte mittelfristig entfallen, diente v.a. meiner Info, ob die interne Verarbeitung paßt).

Der Code dazu:

Code Auswählen Erweitern



##############################################
# $Id: myUtils_ZWave.pm 08-15 2019-06-19 06:13:42Z Beta-User $
#

package main;

use strict;
use warnings;
use POSIX;

sub
myUtils_ZWave_Initialize($$)
{
  my ($hash) = @_;
}

# Enter you functions below _this_ line.

sub devStateIcon_FGR223($) {
my $levelname = shift(@_);
my $ret ="";
my ($def,$defnr) = split(" ", InternalVal($levelname,"DEF",$levelname));
$defnr++;
my @slatnames = devspec2array("DEF=$def".'.'.$defnr);
my $slatname = shift @slatnames;
my $dimlevel= ReadingsNum($levelname,"dim",0);
my $slatlevel= ReadingsNum($slatname,"state",0);

#levelicon
my $symbol_string = "fts_shutter_";
my $command_string = "dim 99";
$command_string = "off" if $dimlevel > 50;
$symbol_string .= int ((109 - $dimlevel)/10)*10;
$ret .= "<a href=\"/fhem?cmd.dummy=set $levelname $command_string&XHR=1\">" . FW_makeImage($symbol_string,"fts_shutter_10") . "</a> ";

#stop
$ret .= "<a href=\"/fhem?cmd.dummy=set $levelname stop&XHR=1\">" . FW_makeImage("fts_shutter_shadding_stop","fts_shutter_shadding_stop") . "</a> ";

#slat
$symbol_string = "fts_blade_arc_close_";
$command_string = "dim ";
$slatlevel > 49 ? $symbol_string .= "00" : $slatlevel > 24 ? $symbol_string .= "50" : $slatlevel < 25 ? $symbol_string .= "100" : undef;
$slatlevel > 49 ? $command_string = "off" : $slatlevel > 24 ? $command_string .= "50" : $slatlevel < 25 ? $command_string .= "25" : undef;
$ret .= "<a href=\"/fhem?cmd.dummy=set $slatname $command_string&XHR=1\">" . FW_makeImage($symbol_string,"fts_blade_arc_close_100") . "</a> $slatlevel \%";

return "<div><p style=\"text-align:right\">$ret</p></div>"
;
}


1;

=pod
=begin html

<a name="myUtils_ZWave"></a>
<h3>myUtils_ZWave</h3>
<ul>
  <b>devStateIcon_FGR223</b>
  <br>
  Use this to get a multifunctional iconset to control Fibaro FGR-223 devices in venetian blind mode<br>
  Examples:
  <ul>
   <code>attr Jalousie_WZ devStateIcon {devStateIcon_FGR223($name)}<br> attr Jalousie_WZ webCmd dim<br>attr Jalousie_WZ userReadings dim:(dim|reportedState).* {$1 =~ /reportedState/ ? ReadingsNum($name,"reportedState",0):ReadingsNum($name,"state",0)}
</code><br>
   The FHEM device to control slat level has to have a userReadings attribute for state like this:<br>
<code>attr attr ZWave_SWITCH_MULTILEVEL_8.02 userReadings state:swmStatus.* {ReadingsNum($name,"swmStatus",0)}</code>
  </ul>
</ul>
=end html
=cut


Kann sein, dass ich noch etwas am Code feilen muß, aber das Prinzip sollte passen.
Vielleicht noch eine Anmerkung, warum ich den 1. Nebenkanal und nicht das Hauptdevice verwende: Über die DEF läßt sich (hoffentlich!) recht leicht das Gerät ermitteln, das die Lamellen steuert, es ist einfach das mit der nächsten Nummer (glaube ich zumindest)...

Wenn jemand bessere Vorschläge oder Anregungen hat: Her damit...

EDIT: ein Bild sagt mehr als viele Worte...

[stw-fhem]

Hallo,

danke für die umfangreiche Konfiguration. Hast du noch eine Lösung dafür, dass das Icon für die Lamellenposition aktualisiert wird, nachdem eine Schaltfläche betätigt wurde?

Und wie hast du die Assoziation des Schalters gelöscht?

Danke

Steffen

[Beta-User]

Hmm, bei mir wird das Icon auch für die Lamellenposition aktualisiert (dauert nur ggf. etwas).

Könnte damit zusammenhängen, dass du scheinbar die erste Assoziation noch aktiv hast. Dazu gibt es mehrere Möglichkeiten, geht sowohl mit mcaDel wie mit dem "einfachen" Befehl, den krikan aufgezeigt hatte:

Code Auswählen Erweitern

set <MainDevice> associationDel 1 <ControllerNodeId>

[krikan]

-- ist als VentetianBlind konfiguriert;
-- Die Assoziation der Gruppe 1 gelöscht;
-- mca-Assoziazionen gibt es nur folgende:
  - mca_1 => zwaveme:0
  - mca_2 => zwaveme:1
  - mca_3 => zwaveme:2
=> Damit bekomme ich alle Schaltvorgänge auf die Kanaldevices gemeldet, und zwar als %-Angabe, egal, ob durch FHEM verursacht oder durch lokale Schaltvorgänge am Aktor selbst (Tasterkonfiguration mit Doppeltastern).

Meldet der FGR-223 so konfiguriert bei Ansteuerung über FHEM die Position am Ende der Fahrt zurück?
Das "Schwestermodell" FGWR-111 meldet es so nicht und auch sonst habe ich noch keine Alternativlösung gefunden. 

Gruß, Christian

[Beta-User]

Nein, in dieser Konfiguration bekomme ich keine Rückmeldung, wenn dann der Motor abschaltet usw..
Das hat mich bisher nicht gestört, weil das Teil zuverlässig läuft, also ein set-Befehl dann auch ausgeführt wird. Greift jemand via Taster ein, bekommt FHEM das aber mit (egal ob während einer FHEM-Fahrt oder danach).

Man kann zwar den Aktor zwar durch eine weitere Assotiation (welche, müßte ich wieder austesten) anweisen, auch das Abschalten zu melden, aber dann geht der %-Wert verloren (jedenfalls, wenn man keine weiteren Einstellungen in Bereichen vornimmt, in die ich bisher nicht vertieft eingestiegen bin).

Ich nehme an, es würde dir helfen, die entsprechenden Daten zu bekommen, oder? (dann mache ich das bei Gelegenheit, wird aber dauern).

(Zwischenzeitlich hatte ich mal versucht, die firmware auf den letzten Stand zu heben, aber das wollte mir mit dieser seltsamen z-way-Software nicht gelingen; irgendwie erkennt die nicht, dass der Stick (den konnte ich updaten) schon Assoziationen gespeichert hat, hatte aber keine Muße, mich da vertiefter einzudenken...).

[krikan]

Nein, in dieser Konfiguration bekomme ich keine Rückmeldung, wenn dann der Motor abschaltet usw..
[...] Greift jemand via Taster ein, bekommt FHEM das aber mit (egal ob während einer FHEM-Fahrt oder danach).

Danke. Passt leider zu meinen Feststellungen mit dem FGWR-111.

Man kann zwar den Aktor zwar durch eine weitere Assotiation (welche, müßte ich wieder austesten) anweisen, auch das Abschalten zu melden, aber dann geht der %-Wert verloren

Das hilft mir leider nicht. Denn genau den Prozentwert hätte ich gerne. Beim alten FGR(M)-222 wird der für inklusive Winkel immer am Ende gemeldet. Experimentiere dann mal weiter und hoffe (auch wenn ich fast keine Hoffnung mehr habe) auf Prozentwerte.

Ich nehme an, es würde dir helfen, die entsprechenden Daten zu bekommen, oder?

Danke für das Angebot, aber das brauche ich dann wohl nicht.

Zwischenzeitlich hatte ich mal versucht, die firmware auf den letzten Stand zu heben, aber das wollte mir mit dieser seltsamen z-way-Software nicht gelingen

Nach meinem letzten Kenntnisstand geht ein Firmwareupdate der Fibaro-Geräte nur über Fibaro Homecenter. Hat sich das geändert und man kann Fibaro-Geräte auch über z-way updaten?

Gruß, Christian

[Beta-User]

Hmm, so richtig intensiv hatte ich mich nicht damit auseinandergesetzt, welche Messages kommen, man sieht halt im state dann immer nur die letzte Info, und das scheint das Abschalten zu sein, wenn man die betreffende Assotiation nutzt. Ob davor noch was interessantes kommt, wäre die Frage... Schau ich mir vielleicht bei Gelegenheit nochmal an, hat aber für mich keine hohe Prio.

Was z-way angeht:
- Die firmware des Dongles (zwave.me) konnte ich darüber updaten; es gibt also in jedem Fall irgendeine Art Verbindung zwischen dem Fibaro-update-Server und dieser software.
- Es gibt auch Buttons für das Update von ZWave-Geräten. Von daher habe ich den dringenden Verdacht, dass es tatsächlich auch mit z-way gehen sollte.
- Allerdings ist das einzige Gerät, das ich bisher _in_ dieser Software habe das Dongle, und dafür gibt es zwar einen "update-button" auch in der Anzeige als "normales Gerät", aber leider kommt dann der Hinweis, dass das für diese Art Gerät nicht ginge; Für zwave.me läuft das dann über die "Interface"-Schiene (wie die da heißt, ist mir grad nicht präsent).

Für mich ist daher die nächste spannende Frage: Wie bekomme ich weitere Devices in diese Software bzw. was muß ich tun, um bereits mit dem IO assoziierte Aktoren auch in dieser zu sehen...? Bisher hatte ich verstanden, dass die Assotiationen auf dem Dongle gespeichert werden (dort liest sie ja auch FHEM aus, oder?). War da in z-way anders ist, habe ich noch nicht ganz kapiert, und mit einem Testgerät und dem Versuch, das neu zu assoziieren bin ich da auch nicht recht weitergekommen (war aber sehr auf die Schnelle...).

[rudolfkoenig]

Bisher hatte ich verstanden, dass die Assotiationen auf dem Dongle gespeichert werden (dort liest sie ja auch FHEM aus, oder?)

Meines Wissens werden im Dongle nur die (bis zu vier) Nachbarn gespeichert, das verwendet FHEM fuer die Anzeige des grafischen Maps.
Haken an der Sache: ich gehe davon aus, dass beim dynamischen Routing diese Daten egal sind. Selbst beim statischen Routing habe ich keinen sinnvollen Zusammenhang erkannt.
Weiterhin wird im Dongle fuer jedes Geraet ID, Hauptklasse, ob FLiRS und Datenrate gespeichert (wenn ich mich recht erinnere).

Assoziationen werden im Endgeraet gespeichert, wenn man diese auslesen will, muss man mit dem Geraet kommunizieren.
Rationale: Wenn man Schalter mit Aktor assoziiert hat, dann geht das ohne Dongle.

[Beta-User]

Danke für die Klarstellung, ich hatte da Assotiation und GeräteID durcheinandergebracht.

Gemeint war: Auf dem Dongle sind seine "Clienten" "irgendwie" auslesbar abgespeichert, und man braucht diese Daten auch auf dem Dongle, um mit den anderen Geräten kommunizieren zu können. Dass Assotiation ansonsten so ähnlich zu sein scheint wie in der HM-Welt das "peering", darüber also die controller-freie direkte Kommunikation abläuft, ist klar. Verwirrend in dem Zusammenhang ist eigentlich nur, dass man dem Endgerät mittels Assotiation mitteilen muß, was der Controller (FHEM oder z-way, oder ...) erfahren soll.

Die Frage bleibt, wie ich dieser dusseligen z-way-Software beibringe, welche Geräte vorhanden sind, und zwar möglichst "auf einen Rutsch", ohne in FHEM dann nochmal von vorne anzufangen. (Aber die funktionieren ja grundsätzlich fast so wie gewünscht, von daher habe ich bisher das ganze nur "homöopathisch" getestet).

[krikan]

man sieht halt im state dann immer nur die letzte Info, und das scheint das Abschalten zu sein, wenn man die betreffende Assotiation nutzt. Ob davor noch was interessantes kommt, wäre die Frage...

Die dim % - Info als Rückinfo vom Gerät taucht hier nur bei manuellen Schaltvorgängen auf. Bei FHEM-Ansteuerung wird bei ACK des Gerätes über den Erhalt des dim %-Befehls, der state auf "dim %" gesetzt; es gibt jedoch keine Rückinfo am Fahrtende.

Nach dem Abschalten bei Ansteuerung über FHEM kommt bei allen Experimenten immer nur die "power 0" Info.

- Es gibt auch Buttons für das Update von ZWave-Geräten. Von daher habe ich den dringenden Verdacht, dass es tatsächlich auch mit z-way gehen sollte.

Den Button gibt es sicherlich bei allen Geräten mit der passenden Command Class; so habe ich es zumindest in der Vergangenheit festgestellt. Nur muss man das passende Firmewarefile haben. Das stellte Fibaro damals nicht bereit; ging nur über Homecenter.

Bei allen Experimenten aus eigener leidvoller Erfahrung die Warnung: teilweise gibt es Automatiken/Funktionen in anderen Programmen, die mühevoll erarbeitete Assoziationen und Konfigurationen ändern (können).

[Beta-User]

Die dim % - Info als Rückinfo vom Gerät taucht hier nur bei manuellen Schaltvorgängen auf. Bei FHEM-Ansteuerung wird bei ACK des Gerätes über den Erhalt des dim %-Befehls, der state auf "dim %" gesetzt; es gibt jedoch keine Rückinfo am Fahrtende.

Wenn die state-Änderung erst erfolgt, wenn der Aktor den Befehl erhalten hat, finde ich das hinreichend. Dann kann eigentlich nur noch was manuelles erfolgen (bekommen wir dann wieder mit) (oder ein assoziierter Taster löst was aus - k.A., was dann Sache ist,) oder der Strom fällt aus...

Nach dem Abschalten bei Ansteuerung über FHEM kommt bei allen Experimenten immer nur die "power 0" Info.

Die sollte auch so in der beschriebenen Konfiguration da sein; evtl. könnte man das für FHEM-spezifischen Zusatzcode nutzen (Aktor hat Zielposition erreicht). Aber wie geschrieben: das ist m.E. eher Kosmetik und wäre dann interessant, wenn wir wissen wollen, ob der Aktor noch fährt - das könnte man dann aber auch auf direktem Weg über das Reading erfahren.

Den Button gibt es sicherlich bei allen Geräten mit der passenden Command Class; so habe ich es zumindest in der Vergangenheit festgestellt. Nur muss man das passende Firmewarefile haben. Das stellte Fibaro damals nicht bereit; ging nur über Homecenter.

Hmm, war das früher auch schon so, dass darüber der Dongle aktualisiert werden konnte? Denn auch dafür braucht man ja die Info, dass eine fw verfügbar ist und muß die runterladen können. Hatte daraus geschlossen, dass das tendenziell keine Insellösung sein dürfte mit dem Dongle...?

Bei allen Experimenten aus eigener leidvoller Erfahrung die Warnung: teilweise gibt es Automatiken/Funktionen in anderen Programmen, die mühevoll erarbeitete Assoziationen und Konfigurationen ändern (können).

Dachte ich mir; wollte auch erst mal mit einem (ungenutzen) 2-er Switch (222) anfangen, der nur "pro forma" mal in FHEM eingebunden war - und bin leider bislang schon daran gescheitert... Ansonsten ist es nicht soooo tragisch, ich muß/will ja noch üben mit dem Zeug .
Diese z-way-Sache ist aber auch gewöhnungsbedürftig. Wer versteht schon, dass "eine App installieren" bedeutet, dass man eine Art plugin in den z-way-Code einfügen muß...? Dachte eher: "Was hat denn mein Handy damit zu tun?" Vielleicht übersehe ich noch was in diese Richtung, muß mal das Handbuch nebendranlegen. Aber an sich sollte diese "eine App" ausreichend sein, und das Dongle ist jedenfalls mit einiger Sicherheit ordnungsgemäß eingebunden (sonst hätte das mit dem fw-update ja nicht funktioniert).

[krikan]

Meine typische Anwendererwartung: Was früher (FGRM222) ging, sollte auch mit dem neuen Aktor gehen.    Klar brauche ich das nicht zwingend und kann mir anders behelfen, aber gut finde ich es nicht.

Dongle konnte man der Erinnerung nach im expert-Ansicht updaten. Aber das ist alles nur halbgar; habe mit z-way nur das sehr wenig Erfahrung.

[Beta-User]

...mit der Erwartung (223=222+n) war ich auch mal gestartet ...

Es wäre natürlich toll, wenn wir irgendwie den Würgaround/die passenden Einstellungen etc. für den VenetianMode gleich "im Modul" (wo dort auch immer genau) unterbringen könnten. "An sich" sollte das irgendwie anhand des Readings, ob der V-Mode eingestellt ist gehen, aber zugegebenermaßen wollte ich mich bei ZWave nicht auch noch soooo weit "unter das Auto legen", um das "sauber" zu verorten .

Vorab wollte ich halt möglichst "wenigstens" mit der neuesten fw arbeiten. An z-way scheint es schon im Lauf auch der letzten 18 Monate umfangreichere "Renovierungsarbeiten" gegeben zu haben. Mal schauen, wann das mit dem intensiveren Blick da rein was wird, und evtl. liest ja auch der eine oder andere mit, der "uns" im Sinne der community weiterhelfen kann und mag...?

[Mundus]

Hi,

ich habe einen Rollershutter FGR 223, den ich wie folgt konfiguriert habe:

Code Auswählen Erweitern



Internals:
   CFGFN     
   DEF        cf62bc16 27
   FUUID      5e8f63b1-f33f-23be-8372-6cb78c5aeb3a0972
   IODev      ZWAVE1
   LASTInputDev ZWAVE1
   MSGCNT     178
   NAME       ku_Raff_gr_li
   NR         12943
   STATE      dim 96
   TYPE       ZWave
   ZWAVE1_MSGCNT 178
   ZWAVE1_RAWMSG 0004001b0e320221440000000d000000000000
   ZWAVE1_TIME 2020-04-10 13:28:19
   ZWaveSubDevice no
   cmdsPending 0
   endpointChildren ku_Raff_gr_li_Kanal01,ku_Raff_gr_li_Kanal02
   homeId     cf62bc16
   isWakeUp   
   lastMsgSent 1586476549.41968
   nodeIdHex  1b
   READINGS:
     2020-04-10 00:28:45   SEND_DATA       failed:00
     2020-04-10 00:26:33   applicationStatus cmdRejected
     2020-04-10 00:24:25   associatedWith  ku_Raff_gr_li_Kanal01,ku_Raff_gr_li_Kanal02
     2020-04-09 20:21:44   configAlarmConfiguration1stSlot 0
     2020-04-09 20:21:45   configAlarmConfiguration2stSlotWater 100597760
     2020-04-09 20:21:45   configAlarmConfiguration3stSlotSmoke 33488896
     2020-04-09 20:21:45   configAlarmConfiguration4stSlotCO 50266112
     2020-04-09 20:21:45   configAlarmConfiguration5stSlotHeat 83820544
     2020-04-09 20:21:46   configDelayMotorStopAfterReachingEnd154 10
     2020-04-09 20:21:46   configEnergyReportsOnChange 10
     2020-04-09 20:21:46   configEnergyReportsPeriodic 3600
     2020-04-09 20:26:41   configForceCalibration DeviceIsCalibrated
     2020-04-09 20:21:47   configInputsOrientation Default
     2020-04-09 20:21:47   configMeasuringPowerConsumedByThe60 Disabled
     2020-04-09 20:21:47   configMotorOperationDetection 10
     2020-04-09 20:21:47   configOperatingMode VenetianBlind
     2020-04-09 20:21:48   configOutputsOrientation Default
     2020-04-09 20:21:48   configPowerReportsOnChange 15
     2020-04-09 20:21:48   configPowerReportsPeriodic 3600
     2020-04-09 20:21:48   configS1SwitchScenesSent 0
     2020-04-09 20:21:49   configS2SwitchScenesSent 0
     2020-04-09 20:21:49   configSetSlatsBackToPreviousPosition InCaseOfTheMainController1
     2020-04-09 20:21:49   configSwitchType MomentarySwitches
     2020-04-09 20:26:41   configTimeOfDownMovement 5746
     2020-04-09 20:26:41   configTimeOfUpMovement 6024
     2020-04-09 20:21:50   configVenetianBlindTimeOfFullTurnOfThe152 150
     2020-04-10 13:28:19   energy           0.13 kWh
     2020-04-09 20:04:46   mcCapability_01 ZWAVEPLUS_INFO SWITCH_MULTILEVEL ASSOCIATION MULTI_CHANNEL_ASSOCIATION ASSOCIATION_GRP_INFO SECURITY SECURITY_S2 SUPERVISION METER ALARM APPLICATION_STATUS
     2020-04-09 20:04:47   mcCapability_02 ZWAVEPLUS_INFO SWITCH_MULTILEVEL ASSOCIATION MULTI_CHANNEL_ASSOCIATION ASSOCIATION_GRP_INFO SECURITY SECURITY_S2 SUPERVISION APPLICATION_STATUS
     2020-04-09 20:04:46   mcEndpoints     total 2, different
     2020-04-10 00:28:43   mcaGroups       3
     2020-04-09 20:04:46   model           FIBARO System FGR223 Roller Shutter Controller 3
     2020-04-09 20:04:46   modelConfig     fibaro/fgr223.xml
     2020-04-09 20:04:46   modelId         010f-0303-1000
     2020-04-10 13:28:19   power            0 W
     2020-04-10 09:08:05   reportedState   dim 96
     2020-04-10 09:08:05   state           dim 96
     2020-04-10 09:08:05   swmStatus       96 target 96 duration unknown
     2020-04-10 01:55:49   timeToAck       0.081
     2020-04-10 01:55:49   transmit        OK
Attributes:
   IODev      ZWAVE1
   alias      Küche großer Raffstore links
   classes    ZWAVEPLUS_INFO SWITCH_MULTILEVEL ASSOCIATION MULTI_CHANNEL_ASSOCIATION ASSOCIATION_GRP_INFO TRANSPORT_SERVICE VERSION MANUFACTURER_SPECIFIC DEVICE_RESET_LOCALLY POWERLEVEL SECURITY SECURITY_S2 METER CONFIGURATION CRC_16_ENCAP ALARM PROTECTION MULTI_CHANNEL CENTRAL_SCENE FIRMWARE_UPDATE_MD APPLICATION_STATUS SUPERVISION
   cmdIcon    stop:rc_PAUSE dim0:fts_shutter_down dim99:fts_shutter_up
   devStateIcon dim0:fts_shutter_90 dim.[0-5]:fts_shutter_90 dim.[6-9]:fts_shutter_70 dim.[1-3][0-9]:fts_shutter_70 dim.[4-5][0-9]:fts_shutter_50 dim.[6-8][0-9]:fts_shutter_30 dim.[9][0-8]:fts_shutter_30 dim.99:fts_window_2w dim99:fts_window2w
   eventMap   /dim 0:dim0/dim 99:dim99/on:dim99/off:dim0/
   group      Raffstore/Jalousie
   room       Küche,ZWave
   userReadings Lamellenwinkle {my $ret; my $dev = $name."Kanal02";my $dev}
   vclasses   ALARM:8 APPLICATION_STATUS:1 ASSOCIATION:2 ASSOCIATION_GRP_INFO:2 CENTRAL_SCENE:3 CONFIGURATION:1 CRC_16_ENCAP:1 DEVICE_RESET_LOCALLY:1 FIRMWARE_UPDATE_MD:4 MANUFACTURER_SPECIFIC:2 METER:3 MULTI_CHANNEL:4 MULTI_CHANNEL_ASSOCIATION:3 POWERLEVEL:1 PROTECTION:2 SECURITY:1 SECURITY_S2:1 SUPERVISION:1 SWITCH_MULTILEVEL:4 TRANSPORT_SERVICE:2 VERSION:2 ZWAVEPLUS_INFO:2
   webCmd     stop:dim0:dim99


Der Kanal 02, dessen list ich gerne nachreichen kann, steuert den Winkel der Lamellen. Der Kanal 1 bzw das Main-Device, das hoch und runter Fahren.

So und jetzt mein Hauptproblem: Wenn ich an den manuellen Schalter den Raffstore hoch bzw. runter fahre, dann stellt der FGR 223 am Ende der Fahrt den alten Einstellwinkel der Lamellen ein. Das führt bei meiner Frau zu maximaler Frustration. Gewünscht ist auch eine manuelle Veränderung des Winkels der Lamellen. Leider habe ich gerade keine Idee. Gibt es hierzu eine Lösung oder kann mir jmd. einen Denkanstoß geben. Auch Hinweise nutze den HomeMatic-Actor xyz sind willkommen.

Ich hoffe das Problem ist verständlich.

Gruß und bleibt gesund!

Mundus
P.S.: Gibt es bereits eine Möglichkeit mittels Userreading, die Daten anderer Devices (in diesem Fall den Kanal 02) anzeigen zu lassen? So in der Art

Code Auswählen Erweitern



attr ku_Raff_gr_li userReadings ku_Raff_gr_li_Kanal02:state


- dieses Beispiel funktioniert bei mir nicht  . Außerdem, kann ich einen Set-Befehl aus einem Device für andere Devices absetzen? Ich kann es natürlich mit einem Dummy und Notify lösen, dass dann die jeweiligen "echten" Devices steuert.

[Beta-User]

Hi Mundus,

bzgl. der Drehung der Lamellen würde ich mal auf "configSetSlatsBackToPreviousPosition" tippen. Der sieht bei mir so aus:

Code Auswählen Erweitern


setstate ZWave_SWITCH_MULTILEVEL_8 2020-04-20 05:09:53 configSetSlatsBackToPreviousPosition OnlyInCaseOfTheMainController0

Hier noch das ganze RAW des Hauptdevices:

Code Auswählen Erweitern

defmod ZWave_SWITCH_MULTILEVEL_8 ZWave 12345678 8
attr ZWave_SWITCH_MULTILEVEL_8 ASC 0
attr ZWave_SWITCH_MULTILEVEL_8 IODev zwaveme
attr ZWave_SWITCH_MULTILEVEL_8 classes ZWAVEPLUS_INFO SWITCH_MULTILEVEL ASSOCIATION MULTI_CHANNEL_ASSOCIATION ASSOCIATION_GRP_INFO TRANSPORT_SERVICE VERSION MANUFACTURER_SPECIFIC DEVICE_RESET_LOCALLY POWERLEVEL SECURITY SECURITY_S2 METER CONFIGURATION CRC_16_ENCAP ALARM PROTECTION MULTI_CHANNEL CENTRAL_SCENE FIRMWARE_UPDATE_MD APPLICATION_STATUS SUPERVISION
attr ZWave_SWITCH_MULTILEVEL_8 cmdIcon on:fts_shutter_up off:fts_shutter_down up:control_plus down:control_minus toggle:fts_shutter_updown stop:control_x
attr ZWave_SWITCH_MULTILEVEL_8 devStateIcon off:fts_shutter_up:on on:fts_shutter_down:off dim.9\d.*:fts_shutter_10:off dim.8\d.*:fts_shutter_20:off dim.7\d.*:fts_shutter_30:off dim.6\d.*:fts_shutter_40:off dim.5\d.*:fts_shutter_50:off dim.4\d.*:fts_shutter_60:on dim.3\d.*:fts_shutter_70:on dim.2\d.*:fts_shutter_80:on dim.1\d.*:fts_shutter_90:on dim.\d.*:fts_shutter_100:on
attr ZWave_SWITCH_MULTILEVEL_8 eventMap { usr=>{'dim.100'=>'dim 99'}}
attr ZWave_SWITCH_MULTILEVEL_8 group Türen und Fenster
attr ZWave_SWITCH_MULTILEVEL_8 icon fts_shutter_updown
attr ZWave_SWITCH_MULTILEVEL_8 room Steuerung->Unused_Devices
attr ZWave_SWITCH_MULTILEVEL_8 userReadings dim:.*dim.* {ReadingsNum("Jalousie_WZ_neu","state",0)}
attr ZWave_SWITCH_MULTILEVEL_8 vclasses ALARM:8 APPLICATION_STATUS:1 ASSOCIATION:2 ASSOCIATION_GRP_INFO:2 CENTRAL_SCENE:3 CONFIGURATION:1 CRC_16_ENCAP:1 DEVICE_RESET_LOCALLY:1 FIRMWARE_UPDATE_MD:4 MANUFACTURER_SPECIFIC:2 METER:3 MULTI_CHANNEL:4 MULTI_CHANNEL_ASSOCIATION:3 POWERLEVEL:1 PROTECTION:2 SECURITY:1 SECURITY_S2:1 SUPERVISION:1 SWITCH_MULTILEVEL:4 TRANSPORT_SERVICE:2 VERSION:2 ZWAVEPLUS_INFO:2
attr ZWave_SWITCH_MULTILEVEL_8 webCmd on:off:dim
attr ZWave_SWITCH_MULTILEVEL_8 widgetOverride dim:colorpicker,BRI,0,1,99

setstate ZWave_SWITCH_MULTILEVEL_8 configS1SwitchScenesSent 0
setstate ZWave_SWITCH_MULTILEVEL_8 2020-04-20 05:09:40 assocGroup_1 Max 1 Nodes
setstate ZWave_SWITCH_MULTILEVEL_8 2020-04-20 05:09:40 assocGroup_2 Max 5 Nodes
setstate ZWave_SWITCH_MULTILEVEL_8 2020-04-20 05:09:40 assocGroup_3 Max 5 Nodes
setstate ZWave_SWITCH_MULTILEVEL_8 2020-04-20 05:09:40 assocGroups 3
setstate ZWave_SWITCH_MULTILEVEL_8 2020-04-20 08:04:16 associatedWith Jalousie_WZ,ZWave_SWITCH_MULTILEVEL_8.02
setstate ZWave_SWITCH_MULTILEVEL_8 2019-09-14 06:02:01 cSceneDim 5
setstate ZWave_SWITCH_MULTILEVEL_8 2020-04-20 05:09:53 configAlarmConfiguration1stSlot 0
setstate ZWave_SWITCH_MULTILEVEL_8 2020-04-20 05:09:53 configAlarmConfiguration2stSlotWater 100597760
setstate ZWave_SWITCH_MULTILEVEL_8 2020-04-20 05:09:53 configAlarmConfiguration3stSlotSmoke 33488897
setstate ZWave_SWITCH_MULTILEVEL_8 2020-04-20 05:09:53 configAlarmConfiguration4stSlotCO 50266113
setstate ZWave_SWITCH_MULTILEVEL_8 2020-04-20 05:09:53 configAlarmConfiguration5stSlotHeat 83820545
setstate ZWave_SWITCH_MULTILEVEL_8 2020-04-20 05:09:53 configDelayMotorStopAfterReachingEnd154 10
setstate ZWave_SWITCH_MULTILEVEL_8 2020-04-20 05:09:53 configEnergyReportsOnChange 10
setstate ZWave_SWITCH_MULTILEVEL_8 2020-04-20 05:09:53 configEnergyReportsPeriodic 3600
setstate ZWave_SWITCH_MULTILEVEL_8 2020-04-20 05:09:53 configForceCalibration DeviceIsCalibrated
setstate ZWave_SWITCH_MULTILEVEL_8 2020-04-20 05:09:53 configInputsOrientation Default
setstate ZWave_SWITCH_MULTILEVEL_8 2020-04-20 05:09:53 configMeasuringPowerConsumedByThe60 Disabled
setstate ZWave_SWITCH_MULTILEVEL_8 2020-04-20 05:09:53 configMotorOperationDetection 10
setstate ZWave_SWITCH_MULTILEVEL_8 2020-04-20 05:09:53 configOperatingMode VenetianBlind
setstate ZWave_SWITCH_MULTILEVEL_8 2020-04-20 05:09:53 configOutputsOrientation Default
setstate ZWave_SWITCH_MULTILEVEL_8 2020-04-20 05:09:53 configPowerReportsOnChange 15
setstate ZWave_SWITCH_MULTILEVEL_8 2020-04-20 05:09:53 configPowerReportsPeriodic 3600
setstate ZWave_SWITCH_MULTILEVEL_8 2020-04-20 05:09:53 configS1SwitchScenesSent 0
setstate ZWave_SWITCH_MULTILEVEL_8 2020-04-20 05:09:53 configS2SwitchScenesSent 0
setstate ZWave_SWITCH_MULTILEVEL_8 2020-04-20 05:09:53 configSetSlatsBackToPreviousPosition OnlyInCaseOfTheMainController0
setstate ZWave_SWITCH_MULTILEVEL_8 2020-04-20 05:09:53 configSwitchType MomentarySwitches
setstate ZWave_SWITCH_MULTILEVEL_8 2020-04-20 05:09:54 configTimeOfDownMovement 6630
setstate ZWave_SWITCH_MULTILEVEL_8 2020-04-20 05:09:54 configTimeOfUpMovement 6778
setstate ZWave_SWITCH_MULTILEVEL_8 2020-04-20 05:09:54 configVenetianBlindTimeOfFullTurnOfThe152 170
setstate ZWave_SWITCH_MULTILEVEL_8 2019-11-09 12:58:54 fwMd fwMdManId: 010f, fwMdFwId_0: 0313, fwMdChkSum_0: 7657, fwMdUpgradeable: ff, fwMdNrTarg: 01, fwMdFrqSize: 0028, fwMdFwId_1: 0313
setstate ZWave_SWITCH_MULTILEVEL_8 2019-11-09 12:58:18 model FIBARO System FGRM223 Roller Shutter Controller 3
setstate ZWave_SWITCH_MULTILEVEL_8 2019-11-09 12:58:18 modelConfig fibaro/fgr223.xml
setstate ZWave_SWITCH_MULTILEVEL_8 2019-11-09 12:58:18 modelId 010f-0303-1000
setstate ZWave_SWITCH_MULTILEVEL_8 2019-11-11 08:40:05 state configS1SwitchScenesSent 0
setstate ZWave_SWITCH_MULTILEVEL_8 2020-04-20 06:30:02 timeToAck 0.062
setstate ZWave_SWITCH_MULTILEVEL_8 2020-04-20 06:30:02 transmit OK


(Irgendwas ist bei der Formatierung deines Betrags verloren gegangen, btw.).

Zur Steuerung der "eigentlichen" Jalousie verwende ich jetzt den 1. Kanal und habe dort auch das "spezielle" devStateIcon, das dann auch direkt auf den richtigen Readingwert des Lamellenkanals zugreift und den anzeigt bzw. auch direkt steuerbar macht. Bei einem Userreading hast du das Problem, dass das getriggert werden muß, was hier aber auch nicht so sehr das Problem sein sollte, weil ja gleichzeitig z.B. auch reportedState am Hauptdevice aktualisiert wurde. Das als trigger verwenden und dann einfach ein ReadingsNum() auf das passende Device setzen, falls dir mein devStateIcon nicht zusagt...

[Beta-User]

Hallo zusammen,

fyi: zwischenzeitlich gibt es den FGR-223 auch als attrTemplate mit der Wahl zwischen Rollladen- und Jalousiemodus. Ist noch nicht vollständig ausgetestet, bitte also um Rückmeldung, falls also jemand noch Wünsche/Vorschläge dazu hat.

Da im ZWave-Modulcode auch der "Bruder" FGS-223 eine Sonderbehandlung bekommt, was die Assoziationen mit dem Controller angeht, ist das im attrTemplate für den "R" auch entsprechend hinterlegt.

Grüße, Beta-User

[matrix115]

Hallo zusammen,

habe auch einen FGR-223 (Firmware Version 5.1) und mit dem attrTemplate konfiguriert.Vielen Dank dafür, funktioniert bei mir bis auf zwei Probleme sehr gut. Lese schon immer wieder im Forum und konnte bisher alles lösen, diesmal stehe ich an. Deshalb auch mein erster Beitrag

1. Obwohl ich "SetSlatsBackToPreviousPosition" auf "OnlyInCaseOfTheMainController" eingestellt habe, stellen sich die Lamellen immer auf den Ursprungszustand zurück. Ganz egal ob ich den Hauptkanal oder Kanal 1 zur Steuerung verwende. Hat jemand eine Idee, was die Ursache sein kann?

2. "on" (also die Raffstores hochfahren) funktioniert nur, wenn sie die Endposition unten erreichen haben. Gehe ich z.B. auf dim 50 und will dann mittels "on" die Raffstores hochfahren erhalte ich

Code Auswählen Erweitern

ZWave Raffstore2 on
ZWave Raffstore2 applicationStatus: cmdRejected
Das Problem ist erst aufgetreten als ich in den "VenetianBlind" Modus umgeschaltet habe. Als "RollerBlind" hat es noch geklappt. Als Workaround kann ich natürlich auf "dim 99" zurückgreifen, trotzdem ist das Verhalten irgendwie komisch.

[Beta-User]

Dann mal Willkommen im Forum un dDanke für die Rückmeldung bzgl. des attrTemplate!

1. ist m.E. normal bzw. "as described" - es gibt nur den Weg da raus, auch den Lamellenwinkel von FHEM aus zu senden (macht bei mir in der Regel AutoShuttersControl).
Wenn man die andere Einstellung wählt, wird die alte Lamellenstellung auch bei Tastendrücken am Aktor wiederhergestellt (=>noch doofer...).

2. kann man eventuell über ein erweitertes eventMap lösen und da on auch noch auf dim 99 mappen. Klappt bei mir jedenfalls auch nicht ohne weitere Anpassung.
Evtl. erläuterst du, wo der Bedarf herkommt, dann kann ich das ggf. noch mit in das attrTemplate aufnehmen...

[matrix115]

Danke Beta-User für die schnelle Antwort und Bestätigung, dass das beschriebene Verhalten normal ist. Gerade beim ersten Punkt hätte ich gedacht irgendetwas übersehen zu haben, da die SetSlatsBackToPreviousPosition/OnlyInCaseOfTheMainController-Option dann eigentlich nicht das tut was sie lt. Fibaro Handbuch tun soll.

Hab einen Anwendungsfall für on bzw. off aufgrund der Verwendung von "structure". Werde nun aber auch auf AutoShuttersControl umsteigen, damit sollte auch alles klappen.

[Beta-User]

Hmm, hatte auch meine Probleme zu verstehen, was denn mit den beiden Einstellungen gemeint sein könnte, meine aber, dass das Handbuch auch nichts anderes sagt, wenn man den Wunschlesemodus ausschaltet ...

Was strucutre angeht: Da gibt es auch die Option, spezielle Mappings anzulegen, um das "on" umzubiegen. Ändert aber nichts daran, dass man irgendwas zusätzliches für die Lamellen braucht; das ginge aber z.B. auch über ein notify, das das zugehörige Lamellendevice dann immer bei 0 auch auf 0 stellt bzw. bei 99 am Hauptdevice auf 99 für die Lamellen (in der myUtils zu den attrTemplate ist code, der das "Nebendevice" unabhängig vom Namen ermitteln kann)...
(ASC ist selbstredend trotzdem interessant, aber eben auch sehr mächtig und daher nicht in allen Punkten ganz einfach einzurichten).