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
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
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
Zitat von: Thomas_Homepilot am 26 April 2015, 21:03:34
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.
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
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:
ZitatPROTECTION => { 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
Hallo Christian,
noch einmal vielen Dank. Die Änderung der 10_ZWave.pm funktioniert bei mir einwandfrei.
Gruß
Thomas
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?
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
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
...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
Zitat von: Thomas_Homepilot am 28 April 2015, 10:11:51
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.
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
Zitat von: Thomas_Homepilot am 29 April 2015, 08:52:32
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.
Zitat von: Thomas_Homepilot am 29 April 2015, 08:52:32
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.
Zitat von: Thomas_Homepilot am 29 April 2015, 08:52:32
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.
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:
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
Hallo Thomas,
Du bist aber schnell ;). Zu Eleganz kann ich mir kein Urteil erlauben; Hauptsache es läuft erstmal.
Ich werde mal versuchen, ob man ich set-Commands in separate sub´s auslagern kann wie parse. Dann könnte man vielleicht Dein Problem mit den fehlenden Wildcards über ReadingsVal lösen, müsste sich nicht die Codes für Einstellungen protectionV2 merken, sondern könnte mit Klartext arbeiten, und man könnte noch die Classes unterscheiden. Aber wahrscheinlich ist das wieder zu viel für mich auf einmal...
Gruß, Christian
PS: Meine obigen Prios sind durch :). War einfacher als gedacht.
Hallo Christian,
ich habe das set-Kommando jetzt in protectionBytes umbenannt. So bleibt es vergleichbar mit configByte und kann auch erhalten bleiben, wenn Du bzw. jemand anderes das Problem mit den Wildcards und den Klartextkommandos gelöst haben. Ich hänge den zugehörigen Patch mal hier an, in der Hoffnung, dass Rudolf hier mitliest. Ansonsten öffne ich morgen einen eigenen Beitrag für den Patch, wenn Du keine Einwände hast.
Gruß
Thomas
Von meiner Seite gibt es keine Einwände. Ob und wann ich mit meinen Basteleien zum Erfolg komme, steht in den Sternen :-[.
Rudi wird schon mitlesen, wenn er wieder Zeit hat.
Was mir gestern noch aufgefallen ist: Die Meldungen über Befehle an per PROTECTION geschützte Geräte kommen über die noch nicht eingebaute Class APPLICATION_STATUS rein.
Zitat von: krikan am 30 April 2015, 09:56:59
Die Meldungen über Befehle an per PROTECTION geschützte Geräte kommen über die noch nicht eingebaute Class APPLICATION_STATUS rein.
Bei mir wird nur die Position (COMMAND_CLASS_SWITCH_MULTILEVEL, 0x26) und Leistung (COMMAND_CLASS_SENSOR_MULTILEVEL, 0x31) zurückgemeldet.
Kannst Du mal einen Log davon posten?
Gruß
Thomas
Entschuldige war vielleicht zu unpräzise: Ich habe das nicht am Aktor getestet. Mein "Wissen" beruht allein auf den Infos von S. 199 (oben) des besagten PDFs. Werde mal testen, wenn ich den Aktor wieder im Zugriff habe; es sei denn Du kommst mir zuvor.
@Thomas: hab dein Patch umgebaut (den Code in die Funktion ZWave_protectionParse ausgelagert), und eingecheckt. Bitte testen.
Btw: disable gibts nicht, aber dummy (mit der gleichen Funktionalitaet). Ist wohl nicht ganz konsistent, aber geerbt von FS20, und funktioniert fuer alle Systeme, die zwei Module (ZWDongle/ZWave) verwenden, die per IOWrite kommunizieren (wie es sich gehoert).
Hallo Rudolf,
habs getestet - läuft einwandfrei. Vielen Dank (auch für die Info bzgl. dummy-Attribut).
Gruß
Thomas
Hallo Thomas,
kannst Du "RF:No response" einschalten? Bei mir hat 2 keine Auswirkung: RF bleibt immer "unprotected", obwohl der verschickte Befehl korrekt aussieht:
2015.04.30 19:43:08 2: ZWave set ZWave_SWITCH_MULTILEVEL_4 protectionBytes
2015.04.30 19:43:08 5: SW: 010b0013040475010002050490
2015.04.30 19:43:09 5: ZWDongle/RAW: /060104011301e8
2015.04.30 19:43:09 5: SW: 06
2015.04.30 19:43:09 5: ZWDongle_Read ZWDongle_0: 011301
2015.04.30 19:43:09 5: ZWDongle_0 dispatch 011301
2015.04.30 19:43:09 5: ZWDongle/RAW: /010500130400ed
2015.04.30 19:43:09 5: SW: 06
2015.04.30 19:43:09 5: ZWDongle_Read ZWDongle_0: 00130400
2015.04.30 19:43:09 5: ZWDongle_0 dispatch 00130400
2015.04.30 19:43:09 4: ZWDongle_0 CMD:ZW_SEND_DATA ID:00 ARG:
2015.04.30 19:43:09 4: ZWDongle_0 transmit OK for 04
2015.04.30 19:43:20 2: ZWave get ZWave_SWITCH_MULTILEVEL_4 protection
2015.04.30 19:43:20 5: SW: 01080013040275020590
2015.04.30 19:43:20 5: ZWDongle/RAW: /060104011301e8
2015.04.30 19:43:20 5: SW: 06
2015.04.30 19:43:20 5: ZWDongle_Read ZWDongle_0: 011301
2015.04.30 19:43:20 5: ZWDongle_0 dispatch 011301
2015.04.30 19:43:20 5: ZWDongle/RAW: /010500130200eb
2015.04.30 19:43:20 5: SW: 06
2015.04.30 19:43:20 5: ZWDongle_Read ZWDongle_0: 00130200
2015.04.30 19:43:20 5: ZWDongle_0 dispatch 00130200
2015.04.30 19:43:20 4: ZWDongle_0 CMD:ZW_SEND_DATA ID:00 ARG:
2015.04.30 19:43:20 4: ZWDongle_0 transmit OK for 02
2015.04.30 19:43:20 5: ZWDongle/RAW: /010a00040004047503000087
2015.04.30 19:43:20 5: SW: 06
2015.04.30 19:43:20 5: ZWDongle_Read ZWDongle_0: 000400040475030000
2015.04.30 19:43:20 4: ZWDongle_0 CMD:APPLICATION_COMMAND_HANDLER ID:04 ARG:0475030000
1 funktioniert auch bei RF wie gewünscht.
Gruß, Christian
Hallo Christian,
'2' ist lt. Anleitung "not supported".
Gruß
Thomas
Danke (sehr schlau von mir), hätte ich da auch noch einmal reingeschaut, hätte ich mir Zeit sparen können 8). Soviel von mir zu strukturiertem Vorgehen.
Dann ist auch Class APPLICATION_STATUS hier nicht relevant.
Schönen Abend, Christian