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