Fibaro Roller Shutter FGRM 222: Lokale Bedienung sperren

[Thomas_Homepilot]

Hallo zusammen,

lt. Doku des o.g. Rolladenaktors sollte sich bei diesem die lokale Bedienung mittels set xxx configLocalProtection LocalProtectionActive2 sperren lassen.
Leider wird der Befehl bei mit mit einem Timeout quittiert - ebenso wie set xxx configByte 1 2 oder get xxx config 1.
Ich wollte mal fragen, ob noch jemand das Problem hat, oder ob ich was falsch mache bzw. der Aktor defekt ist. Ab Parameter 3 werden alle dokumentierten Befehle akzeptiert.

Gruß
Thomas

[krikan]

Hallo Thomas,
habe das auch mal festgestellt, wegen fehlender lokaler Bedienung, aber nicht beachtet.

Vermutung:
Die Parameter 1 und 2 beziehen sich auf die Class PROTECTION V2 (siehe Handbuch). Warum die Parameter dennoch unter Class CONFIGURATION in den openzwave Config-XMLs enthalten sind, ist eines der Dinge, die ich an den XMLs nicht verstehe. Oder anders: Verstehe den Zusammenhang zwischen CONFIGURATION und PROTECTION nicht.
Du könntest mal mit den get/set-Befehlen zur Class PROTECTION probieren und berichten. Vielleicht hast Du damit Erfolg. Wenn ich es nächstes Wochenende schaffe, probiere ich es auch mal an einem FGRM222.

Gruß, Christian

[Thomas_Homepilot]

Hallo Christian,

vielen Dank für die schnelle Antwort. Da ich gerade erst mit Z-Wave anfange, muss ich mich wohl erst mal einlesen, damit ich Deine Ausführung verstehe. Ein get xxx protection bringt mir kein neues Reading. Wenn Du das am Wochenende testen könntest wäre das echt super. Unser Nachwuchs hat nämlich das Talent, die Rolladen runterzufahren, wenn wir auf der Terrasse sitzen

Gruß
Thomas

[krikan]

Ein get xxx protection bringt mir kein neues Reading.

Bringt das einen TimeOut? Wenn nein, müsstest Du ggfs. mal verbose 5 setzen und schauen, was zurückkommt. Kann sein, dass das noch nicht ausgewertet wird.
Die interessantere Frage ist auch, ob set xxx protectionOn bzw. set xxx protectionOff etwas bewirkt -> Test auf eigene Gefahr.

[Thomas_Homepilot]

Hallo Christian,

vielen Dank für Deine Hilfe. Ein timeout kommt nicht. Werde morgen mal loggen. Ein set xxx protectionOn klappt tatsächlich und löst mein Problem. Jetzt ist allerdings meine Neugier geweckt. Es gibt ja 2 Arten von Protection, nämlich lokal und remote. Lokal funktioniert, aber wie sperre ich die remotesteuerung bzw. Wie wähle ich, was ich sperren will... Viele Fragen Ich werd wohl mal lernen müssen, wie Zwave überhaupt "tickt".

Gruß
Thomas

[krikan]

Hallo Thomas.
Die set-protectionOn bzw. set-protectionOff - Befehle sollten funktionieren. Zumindest signalisiert hier ein FGRM222 das. Die Events für get-protection werden generiert, wenn  Du in 10_ZWave.pm ab Z. 231 den Block PROTECTION austauscht gegen:

PROTECTION               => { id => '75',
    set   => { protectionOff => "0100",
               protectionSeq => "0101",
               protectionOn  => "0102", },
    get   => { protection    => "02", },
    parse => { "03750300"    => "protection:off",
               "03750301"    => "protection:seq",
               "03750302"    => "protection:on",
               "0475030000"  => "protection:local:off rf:off",       #V2
               "0475030200"  => "protection:local:on rf:off", }, },  #V2

Geändert sind nur die letzten 2 Zeilen, der Rest ist unverändert. Es wäre schön, wenn Du das mal mit dem Taster testen könntest.
Probleme konnte ich keine im Kurztest erkennen. Ein- und Ausschalten funktioniert.
Wenn es bei Dir auch läuft, dann würde ich einen Patch für Rudi bereitstellen.

___
Während Du den letzten  Post geschrieben hast, ist obiger Teil enstanden und ich bin zu faul das zu ändern...
___

Remotesteuerungssperre ist nicht implemtiert, da das mit V2 der Class PROTECTION reinkam. Bisher ist nur Class V1, die ausschließlich lokale Sperre bot, in Fhem drin. Obiges wertet nur die Rückmeldungen der V2 grundlegend aus. Restliche Features der V2 müssten noch implementiert werden. Dazu brauche ich aber professionelle Hilfe (z.b. Rudi). Nach meiner Meinung muss man dann je nach unterstützter Class eines Aktors verschiedene Befehle anbieten und das bekomme ich nicht in Perl gegossen.
Gruß, Christian

[Thomas_Homepilot]

Hallo Christian,

noch einmal vielen Dank. Die Änderung der 10_ZWave.pm funktioniert bei mir einwandfrei.

Gruß
Thomas

[krikan]

OK, werde mich in Kürze um einen Patch kümmern.
Wegen Implementierung der vollständigen Version 2 der Class brauchen wir Hilfe. Zudem bin ich auch nicht sicher, ob Remotesperre sinnvoll ist. Hast Du dafür einen Anwendungsfall?

[Thomas_Homepilot]

Klar hab ich einen Anwendungsfall:

1. Wenn die Terrassentür offen ist (Fenstergriffsensor) sollten die Rollläden auch nicht durch Zeit- oder Beschattungssteuerung geschlossen werden. Mit der Remotesperre wäre das viel einfacher umsetzbar als mit mehreren if-Abfragen.

2. Ich hatte schon mehrfach das Bedürfnis, (temporär) einen Aktor aus den automatischen Abläufen auszuschließen. Da ich mehrere Szenarien und Automatiken (Abwesenheit/Alarm/Beschattung etc.) habe, musste ich bisher immer an mehreren Stellen den entsprechenden Code ändern.

Wenn die Implementierung jedoch zu aufwändig ist, kann ich auch ohne leben. Die o.g. Probleme lassen sich ja auch anders lösen.

Gruß
Thomas

[krikan]

Ob es zu aufwendig ist und ob ich es überhaupt hinbekomme weiß ich nicht. Jedoch habe ich auch Angst vor dem Testen. Was passiert, wenn ich mich beim Testen selbst aussperre? Das Freischaltkommando muss definitiv funktionieren, sonst habe ich den Controller ausgesperrt.

Prio bzgl. des FGRM222 hat bei mir eigentlich:

• stop-Kommando, das meines Wissen nach noch fehlt
• Event "position" aus der Class MANUFACTURER_PROPRIETARY, das irgendwie seit einer der letzten Änderung verloren gegangen ist

[Thomas_Homepilot]

...die Prio sehe ich auch eher untergeordnet. Wenn es ums Testen geht - da bin ich relativ schmerzfrei. Da ich gerade nach und nach meine Homepilot-Aktoren gegen ZWave tauschen will habe ich noch 6 neue im Regal liegen. Würde Dich hier also unterstützen können, wenn Du die anderen Themen gelöst hast.
Gruß
Thomas

[krikan]

Würde Dich hier also unterstützen können, wenn Du die anderen Themen gelöst hast.

Oh, Testbereitschaft hatte ich nicht bedacht . Werde mich versuchen, kann aber dauern, da ab morgen arbeitsmäßig "landunter".

Ich frage mich, ob man für Deine genannten Zwecke nicht das Attribut do_not_notify oder ein Attribut disable einfacher und gefahrloser nutzen könnte.

[Thomas_Homepilot]

Hallo Christian,

ein disable würde in meinem Fall helfen, ist aber für den Aktor nicht vorgesehen. Do_not_notify ist doch für die Generierung von events - oder ich hab das falsch verstanden. Wo hast du die Informationen für das Parsen der V2 her? Vielleicht finde ich da auch die notwendigen Änderungen für das setzen derselben.

Gruß
Thomas

[krikan]

ein disable würde in meinem Fall helfen, ist aber für den Aktor nicht vorgesehen.

Ja, ist bei ZWave nicht drin; könnte man aber einbauen.

Do_not_notify ist doch für die Generierung von events

Bin ich mir selbst nicht sicher; habe ich noch nicht genutzt und auch noch nicht mit auseinandergesetzt.

Wo hast du die Informationen für das Parsen der V2 her? Vielleicht finde ich da auch die notwendigen Änderungen für das setzen derselben.

Suche mal im Internet nach dem Pdf "SDS11060-7 Z-Wave Command Class" oder folge im fhemwiki zu Zwave dem Link zu "Infos zu CommandClasses (ausführlich)" und klicke Dich durch. Das sind relativ alte Infos, aber die Protection V2 ist drin. Weitere Infos findest Du im Quellcode bei Openhab/Openzwave.
Einbau ist von den zu sendenden Codes relativ einfach, die habe ich schon rausgesucht. Ich scheitere mit meinen Nicht-Programmierfähigkeiten aber am User-Interface, da ich keine Ahnung habe wie ich bei einem set-Befehl 2 übergebbare Argumente einbaue, die ausschließlich on/off akzeptieren (bspw. set protection localOn rfOff).
Vermutlich auch eine größere Baustelle: Mir ist unklar wie wir die Versionen der Classes im Code unterscheiden, damit nicht Befehle beim Device zur Verfügung stehen, die das Gerät nciht unterstützt. Das Problem habe ich auch bei anderen Classes (bspw. METER V3). Vermutlich müssten die Versionen der Classes einmalig abgefragt werden und dann die Befehle aufgrund dieser Angaben zur Verfügung gestellt werden. So handhaben es auch Openhab/Openzwave.
Wenn Du zu den Themen Ideen und/oder Patches hättest wäre das schön. 

[Thomas_Homepilot]

Hallo Christian,

danke für die Quellen. Hab ein bisschen gespielt. Die Lösung ist zwar nicht besonders elegant, aber für mich durchaus brauchbar:

Code Auswählen Erweitern

  PROTECTION               => { id => '75',
    set   => { protectionOff => "0100",
               protectionSeq => "0101",
               protectionOn  => "0102",
               protectionV2  => "01%02x%02x",
    get   => { protection    => "02", },
    parse => { "03750300"    => "protection:off",
               "03750301"    => "protection:seq",
               "03750302"    => "protection:on",
               "047503(..)(..)"  => '"protection: Local Protection: "
                                    .($1 eq "00" ? "unprotected"
                                   $1 eq "01" ? "Protection by sequence"
                                    :"No operation possible"))
                                    .", RF Protection: ".($2 eq "00" ? "unprotected"
                                   $2 eq "01" ? "No RF control": "No RF response at all"))',  }, },

Leider fällt mir auch keine Lösung ein, wie ich RF-Protection unabhängig von der lokalen Sperre ändern kann, ohne das ggf. vorher auszulesen. So etwas wie eine Wildcard gibt es vermutlich nicht.
Was hältst Du hiervon?

Gruß
Thomas