Fakro ZWS230 Dachfenstermotor - Problem mit dem ansteuern

[reen]

Hi zusammen,

ich habe ein Fakro Dachfenstermotor in fhem eingebunden:

list fl_Dachfenster

Code Auswählen Erweitern

Internals:
   DEF        d344759d 34
   IODev      ZWAVE1
   NAME       fl_Dachfenster
   NR         61
   STATE      off
   TYPE       ZWave
   homeId     d344759d
   isWakeUp
   lastMsgSent 1466969590.92061
   nodeIdHex  22
   Readings:
     2016-05-01 11:55:17   model           0x0085 0x0003 0x0001
     2016-05-01 11:55:17   modelId         0085-0003-0001
     2016-06-26 21:33:10   state           off
     2016-06-26 21:33:10   transmit        OK
Attributes:
   IODev      ZWAVE1
   classes    SWITCH_MULTILEVEL SWITCH_ALL SWITCH_BINARY MANUFACTURER_SPECIFIC VERSION ASSOCIATION PROTECTION POWERLEVEL SECURITY
   room       Flur,HomeKit,ZWave

Ich kann das Fenster mit "An" und "Aus" komplett öffnen und schließen.
Wenn ich das Fenster aber jetzt nur zur hälfte geöffnet haben möchte, ich also "An" schalte und bei der hälfte der Strecke dann "Aus" schicke, dann geht der Motor direkt wieder zu und bleibt nicht erst stehen. (So funktioniert das zumindest bei meinen Fibaro Rolladensteuerungsaktoren)

Über fhem kann ich auch "dim" setzten, zb set fl_dachfenster dim 50, leider reagiert der Motor auf diesen Befehl garnicht.
es gibt noch stop: "set fl_dachfenster stop" - der Befehl funktioniert, bekomme ich aber ich der "Schalter" Ansicht des Motors nicht angezeigt.
1. kann ich "dim" irgendwie zum laufen bekommen?
2. Kann man den "Stop" Befehl als zusätzliche Schaltfunktion, genauso wie "An" und "Aus" für das Gerät definieren?

Vielen Dank schonmal für die Hilfe.

reen

[rudolfkoenig]

Fuer etwas mehr Klarheit: kannst du bitte "get fl_Dachfenster versionClassAll" ausfuehren? Eigentlich sollte dieses Befehl seit ca einem Monat bei der inklusion automatisch ausgefuehrt werden. Es wird vermutlich dein Problem nicht loesen, aber uns einen besseren Verstaendnis verschaffen.

der Befehl funktioniert, bekomme ich aber ich der "Schalter" Ansicht des Motors nicht angezeigt.

Das konnte ich nicht entziffern.

1. kann ich "dim" irgendwie zum laufen bekommen?

Vlt. kann man mit den config* Befehlen was machen, sonst wuesste ich nicht, was FHEM anders machen sollte.

2. Kann man den "Stop" Befehl als zusätzliche Schaltfunktion, genauso wie "An" und "Aus" für das Gerät definieren?

Ich rate mal: du willst auf der FHEMWEB Oberflaeche noch was zum Klicken. Dafuer ist das Attribut webCmd zustaendig.

[reen]

also nach get fl_Dachfenster versionClassAll bekomme ich folgendes im Reading:

Code Auswählen Erweitern

Readings
model
0x0085 0x0003 0x0001
2016-05-01 11:55:17
modelId
0085-0003-0001
2016-05-01 11:55:17
state
off
2016-06-29 23:03:10
transmit
OK
2016-06-29 23:03:10
versionClass_72
01
2016-06-29 23:01:45
versionClass_73
01
2016-06-29 23:02:08
versionClass_75
01
2016-06-29 23:02:08
versionClass_85
02
2016-06-29 23:02:37
versionClass_98
01
2016-06-29 23:02:36

Ändern an den Eigenschaften oder dem Verhalten tut sich leider nichts.

[reen]

Also den webCmd für "stop" habe ich einrichten können, damit funktioniert das anhalten jetzt auch schon, danke für den Hinweis.

Bin mit z-wave noch nicht so bewandert. Soweit ich das verstanden hab, hängen die Eigenschaften der z-wave Geräte ja von den commandclasses ab.
Das ein Gerät die "Dimm-Funktion hat, kommt wohl durch die commandclass Multilevel-Switch, bin ich da richtig?
Der Fakro Motor hat diese commandclass - aber keine Interaktion mit dem Dimmregler auf der fhem Oberfläche veranlasst den Motor irgendetwas zu tun, er schweigt einfach.

Kann/muss man da noch etwas manuell einstellen oder anpassen, damit auch der "dimm" Regler funktioniert?
Könnte mir vorstellen dass irgendwelche End-Punkte oder eine Strecke definiert werden müssen, damit sowas funktioniert.
Der Motor selbst bietet hardwareseitig leider keine Kalibrierungsroutine, daher die Frage ob man das in fhem umsetzen kann.

[krikan]

Bin mit z-wave noch nicht so bewandert. Soweit ich das verstanden hab, hängen die Eigenschaften der z-wave Geräte ja von den commandclasses ab.
Das ein Gerät die "Dimm-Funktion hat, kommt wohl durch die commandclass Multilevel-Switch, bin ich da richtig?

Ja.

Der Fakro Motor hat diese commandclass - aber keine Interaktion mit dem Dimmregler auf der fhem Oberfläche veranlasst den Motor irgendetwas zu tun, er schweigt einfach.

Kann/muss man da noch etwas manuell einstellen oder anpassen, damit auch der "dimm" Regler funktioniert?
Könnte mir vorstellen dass irgendwelche End-Punkte oder eine Strecke definiert werden müssen, damit sowas funktioniert.
Der Motor selbst bietet hardwareseitig leider keine Kalibrierungsroutine, daher die Frage ob man das in fhem umsetzen kann.

Wenn es nicht mittels der Class CONFIGURATION (configXY) Befehle im Aktor kalibriert werden kann, wüsste ich mit der CC SWITCH_MULTILEVEL keinen Weg. Kenne es nur, dass es dann automatisch durch den Aktor umgesetzt wird.

Im Standard der CC SWITCH_MULTILEVEL ist mWn nicht definiert, welche Aktorreaktion die dim-Werte auslösen. Also "dim 50" muss nicht zur halben Öffnung führen, sondern kann beliebig durch den Aktor auf einen anderen Wert gemappt werden. Zudem könnte der Aktor noch nicht in FHEM eingebaute Versionen der Class nutzen, dazu bräuchte man aber eine Angabe dazu, die ich in Deinen Posts nicht finde:
Am sinnvollsten wäre vermutlich erst einmal die Ausgabe von "list fl_Dachfenster" nach Abfrage aller notwendigen Infos: http://www.fhemwiki.de/wiki/Z-Wave#Welche_Infos_sollten_Anfragen_im_ZWave-Forum_enthalten.3F .

Gruß, Christian

[reen]

Hi Christian,
ok, dann nochmal ein list fl_Dachfenster nach den get-Befehlen:
get fl_Dachfenster associationAll
get fl_Dachfenster versionClassAll
get fl_Dachfenster configAll - gibt es nicht

Code Auswählen Erweitern

Internals:
   DEF        d344759d 34
   IODev      ZWAVE1
   LASTInputDev ZWAVE1
   MSGCNT     20
   NAME       fl_Dachfenster
   NR         58
   STATE      off
   TYPE       ZWave
   ZWAVE1_MSGCNT 20
   ZWAVE1_RAWMSG 000410220486148502
   ZWAVE1_TIME 2016-07-12 10:18:17
   homeId     d344759d
   isWakeUp
   lastMsgSent 1468311494.78726
   nodeIdHex  22
   Readings:
     2016-07-12 10:16:22   assocGroup_1    Max 5 Nodes ZWAVE1
     2016-07-12 10:16:22   assocGroups     1
     2016-05-01 11:55:17   model           0x0085 0x0003 0x0001
     2016-05-01 11:55:17   modelId         0085-0003-0001
     2016-07-12 07:46:06   state           off
     2016-07-12 10:18:16   transmit        OK
     2016-07-12 10:18:16   versionClass_73 01
     2016-07-12 10:18:15   versionClass_75 01
     2016-07-12 10:18:17   versionClass_85 02
     2016-07-12 10:18:17   versionClass_86 01
     2016-07-12 10:18:16   versionClass_98 01
Attributes:
   IODev      ZWAVE1
   classes    SWITCH_MULTILEVEL SWITCH_ALL SWITCH_BINARY MANUFACTURER_SPECIFIC VERSION ASSOCIATION PROTECTION POWERLEVEL SECURITY
   room       Flur,HomeKit,ZWave
   vclasses   SWITCH_MULTILEVEL:3 SWITCH_ALL:1 SWITCH_ALL:1 MANUFACTURER_SPECIFIC:1 MANUFACTURER_SPECIFIC:1 VERSION:1 VERSION:1 VERSION:1 ASSOCIATION:2
   verbose    5
   webCmd     on:off:stop

Ich habe leider garkeine config-Befehle zur Auswahl für den Motor.

[krikan]

Danke.
Version 3 von SWITCH_MULTILEVEL, aber das ist hier vermutlich nicht entscheidend.

Bitte "get fl_Dachfenster model" absetzen. Dann solltest Du (bei aktuellen FHEM) auch die config-Befehle haben.
Bei den configXY-Befehlen sollte es dann einen geben, der eine Kalibrierung anstoßen kann. Zumindest entnehme ich das den confg-Files. Den würde ich probieren.

[krikan]

Bei den configXY-Befehlen sollte es dann einen geben, der eine Kalibrierung anstoßen kann. Zumindest entnehme ich das den confg-Files. Den würde ich probieren.

Korrektur: Den Kalibrierungsbefehl wirst Du leider in den configXY-Befehlen nicht finden, da ich noch nicht die aktuellesten config-Files ins svn gestellt habe. Sorry. Aktualisierung wird auch noch dauern.
Kannst Du aber manuell mit den config-Befehlen machen. Demnach https://github.com/OpenZWave/open-zwave/blob/master/config/fakro/zws230.xml muss man Byte 12 auf 1 zum Starten der Kalibrierung setzen.

[reen]

Ah, das klingt doch garnicht so verkehrt.
...ich hatte gerade nämlich folgendes gesehen: http://www.pepper1.net/zwavedb/device/181
Dort wird auch nichts bezüglich config aufgeführt und dachte schon das fehlt ganz, aber dann ist die Auflistung wohl auch nicht komplett!?

Also in der Geräte-detailansicht der fhem-weboberfläche bekomme ich kein einzigen "config"-Befehl zur Auswahl angeboten.
Funktioniert es trotzdem, wenn ich diesen Befehl dann einfach über die Befehlszeile eingebe?

Code Auswählen Erweitern

set fl_Dachfenster configByte 12 1

[krikan]

Vermutlich. Musst Du testen.
Das ist zumindest der "manuelle" Weg.

[krikan]

Nach nochmaligen Durchsicht Deiner device-list:
Du findest keine config-Befehle im Auswahl-Menü, da das Attribut die notwendige Class CONFIGURATION nicht hat.
Entweder hat Dein Aktor die Class wirklich nicht, dann kannst Du keine Kalibrierung vornehmen und das verlinkte config-File passt nicht zum Aktor.
Oder der NIF des Aktor ist "kaputt": Das kannst Du ausprobieren indem Du die Class in das Attribut classes aufnimmst und den von Dir gezeigten config-Befehl absetzt und die Reaktion abwartest.

Btw. Seltsam ist auch, dass im Attribut vclasses VERSION:1 3x vorkommt und dafür andere fehlen. Kommunikationsstörungen im Netz?

[reen]

also ich habe nun "configByte" in das Attribut Classes aufgenommen und gespeichert.
Leider funktioniert danach der erwähnte Befehl immernoch nicht.
Eine Kommunikationsstörung wäre mir nicht bekannt. Ist nicht soweit entfernt vom Controller und die Kommandos kommen immer sauber an.

[krikan]

Die CC CONFIGURATION muss im Attribut classes ergänzt werden.
Sollte nachher so aussehen:

Code Auswählen Erweitern

classes    SWITCH_MULTILEVEL SWITCH_ALL SWITCH_BINARY MANUFACTURER_SPECIFIC VERSION ASSOCIATION PROTECTION POWERLEVEL SECURITY CONFIGURATION
Habe aber nicht viel Hoffnung. Befürchte es gibt mehrere Versionen des Aktors.

[reen]

Ah, ok habe es angepasst.
wenn ich nun den Befehl ausführe wird er ohne Fehler angenommen, passieren tut aber nichts und im STATE Reading steht dann "configByte 12 1"

Nun habe ich im "get"-Befehl auch configAll, wenn ich das ausführe erhalte ich aber:
"configAll: no model specific configs found"

...echt blöd, verstehe garnicht weshalb der Aktor denn Multilevel ist, aber sich nicht so einrichten lässt, dass man ihn mit dem "dim"-Befehl steuern kann. ...mir ist auch keine andere Version bekannt, einzig dass es die Motoren in 230V und 12V Versionen gibt.

[krikan]

Ah, ok habe es angepasst.
wenn ich nun den Befehl ausführe wird er ohne Fehler angenommen, passieren tut aber nichts und im STATE Reading steht dann "configByte 12 1"

Annahme des Befehls sagt leider nichts. Selbst wenn Du mit "get <device> config 12" etwas zurückbekommst, sagt das nichts.

Nun habe ich im "get"-Befehl auch configAll, wenn ich das ausführe erhalte ich aber:
"configAll: no model specific configs found"

Befehl bezieht sich auf die config-Parameter in der config.xml-Datei. Da keine config-Paramter dort drin stehen, ist die Ausgabe ok.

...echt blöd, verstehe garnicht weshalb der Aktor denn Multilevel ist, aber sich nicht so einrichten lässt, dass man ihn mit dem "dim"-Befehl steuern kann. ...mir ist auch keine andere Version bekannt, einzig dass es die Motoren in 230V und 12V Versionen gibt.

Irgendeine Bedeutung wird die CC SWITCH_MULTILEVEl haben, aber die zu finden!?
Hast Du schon mal mit dimWithDuration experimentiert?
Ansonsten blieben noch die nicht implentierten Commands der Class, wobei mich eine Auswirkung wundern würde, nur...

[reen]

dimWithDuration hat ebenso keine Auswirkung.

Code Auswählen Erweitern

Ansonsten blieben noch die nicht implentierten Commands der Class, wobei mich eine Auswirkung wundern würde, nur...
...versteh ich noch nicht ganz.

Scheint aber wohl wirklich so zu sein, also würde der Aktor diese configuration classes nicht besitzen, oder?
Richtige Angaben zur MultiLevel-Funktion für diesen Aktor habe ich nach längerer Recherche auch nicht rausfinden können.

[krikan]

Code Auswählen Erweitern

Ansonsten blieben noch die nicht implentierten Commands der Class, wobei mich eine Auswirkung wundern würde, nur...
...versteh ich noch nicht ganz.

Es gibt in der Command Class das Command StartLevelChange, das in FHEM bisher noch nicht eingebaut ist. Das wollte ich mir irgendwann iZm LED-Dimmer noch einmal anschauen. Theoretisch könnte das bei Deinem Aktor helfen.
Außerdem ist in FHEM bisher nicht die Version 3 der Class implementiert. Das sollte aber aufgrund der Rückwärtskompatibilität in ZWave für den Aktor normalerweise kein Problem sein.
Was ich an Deiner Stelle versuchen würde: Herausfinden, ob ozw den Aktor steuern kann. Dazu kann man bspw. Domoticz installieren und versuchen damit den Aktor zu steuern. Bei Erfolg ozw-Log mit höchstem Loglevel von Domoticz hier anhängen.

Scheint aber wohl wirklich so zu sein, also würde der Aktor diese configuration classes nicht besitzen, oder?

Korrekt, sehe ich auch so. Die ozw-Config.xml scheint für eine andere Aktorversion zu sein oder ist komplett falsch.

Richtige Angaben zur MultiLevel-Funktion für diesen Aktor habe ich nach längerer Recherche auch nicht rausfinden können.

Der Aktor ist ziemlich dürftig dokumentiert; zumindest finde ich auf Anhieb keine ausführliche Doku.

[reen]

...mir ist aufgefallen, dass im ozw configfile für diesen Aktor sowieso alles auskommentiert ist, das spricht wohl dafür dass der Aktor dort auch noch nicht wirklich implementiert ist und dieses "Calibration" ehre mal als "mögliche Implementierung" dort vermerkt wurde.
Denke dann ist der Versuch mit Domoticz zu steuern auch hinfällig.

Dann muss ich wohl noch warten bis das StartLevelChange Command integriert wurde und es dann damit noch probieren.
Außer es gäbe eine Möglichkeit wie ich selbst diesen command einbauen/testen kann, würde mich schon interessieren, was aber wohl viel tiefere Kenntnisse voraussetzt und dann nicht einfach "kurz" umgesetzt werden kann,oder?

[krikan]

..mir ist aufgefallen, dass im ozw configfile für diesen Aktor sowieso alles auskommentiert ist, das spricht wohl dafür dass der Aktor dort auch noch nicht wirklich implementiert ist und dieses "Calibration" ehre mal als "mögliche Implementierung" dort vermerkt wurde.

Stimmt. Mit dem merkwürdigen Hinweis im checkIn: "Configuration parameters are not yet implemented in this version". Keine Ahnung was das bedeutet.

Denke dann ist der Versuch mit Domoticz zu steuern auch hinfällig.

Sehe ich nicht unbedingt so; persönlich würde ich testen und/oder in der ozw-Mailingliste bzw. den entsprechenden Foren suchen.

Außer es gäbe eine Möglichkeit wie ich selbst diesen command einbauen/testen kann, würde mich schon interessieren, was aber wohl viel tiefere Kenntnisse voraussetzt und dann nicht einfach "kurz" umgesetzt werden kann,oder?

Ist nicht so schwer (selbst ich als Nicht-Entwickler bekomme manches hin). Einstiegspunkte neben der Forumssuche:
http://www.fhemwiki.de/wiki/Z-Wave#Informationsquellen_zur_Einbindung_von_Command_Classes
http://www.fhemwiki.de/wiki/Z-Wave_Command_Classes#Beispiel_f.C3.BCr_eine_Command_Class_und_deren_Implementierung_in_Fhem

[reen]

Mit dem merkwürdigen Hinweis im checkIn: "Configuration parameters are not yet implemented in this version". Keine Ahnung was das bedeutet.

...okok schon gut, hab ja verstanden, manchmal sieht man den Wald vor lauter Bäumen eben nicht. 

Ist nicht so schwer (selbst ich als Nicht-Entwickler bekomme manches hin).

Na dann schau ich mal wie weit ich komme und werde wieder berichten.

[krikan]

Na dann schau ich mal wie weit ich komme und werde wieder berichten.

Viel Spaß. Bei Fragen, bitte melden, irgendwer wird schon helfen können... 

Wenn ozw den Fakro steuern kann, kannst Du im ausführlichen ozw-Log die Hex-Codes sehen, die nach FHEM "übertragen" werden müssen. Das erleichtert es manchmal. Und config.xml hin oder her, das hat nicht notwendig etwas mit der Steuerbarkeit über ozw zu tuen.

Ansonsten:
verbose 5 bei ZWDongle, funktionierenden Befehl an Aktor absetzen, Hexcode des Befehls aus dem Log kopieren, an den passenden Stellen anpassen und über "get <ZWDongle> raw <hexCode>" ausprobieren.

[reen]

...gerade hab ich noch rausgefunden dass "dim" sehr wohl funktioniert, aber nur mit "dim 0" oder "dim99" ...dann fährt der Motor voll auf, oder ganz zu. Nur die Werte zwischendrin funktionierten nicht...

[krikan]

Das ist normal, da diese beiden Werte laut Class auf on und off gemappet werden...

[krikan]

Für Deine Experimente:

Nachfolgend der raw-Befehl für StartLevelChange. Bei aa muss die hex NodeID eingetragen werden.

Code Auswählen Erweitern

13aa0526046000032502
13=ZW_SENDDATA
aa=hexNodeId
05=Länge
26=CC SWITCH_MULTILEVEL
04=Command Start_Level_Change
60=Down/Ignoriere StartLevel
00=StartLevel
03=dimming Duration
25=Explorer Frames
02=CallbackID

Für die NodeId 04 muss man bspw. folgenden Befehl absetzen:

Code Auswählen Erweitern

get <ZWdongle> raw 13040526046000032502

Stoppen kann man den Motor laut Spec vorzeitig mit

Code Auswählen Erweitern

set <ZWaveDevice> stop

Da ich nicht testen kann, müsstest Du bei Interesse/Risikobereitschaft mal damit experimentieren. So richtig kann ich an den Erfolg nicht glauben, da sich das Command irgendwie eher nach Dimmer als Rollo liest. Aber wer kennt schon die Umsetzungen im Aktor...

[reen]

wow, danke für die große Unterstützung Christian!

nachdem ich den Befehl mit meinen Werten ergänzt  und ausgeführt habe, bekomme ich folgendes zurück:
so:

Code Auswählen Erweitern

get ZWAVE1 raw 13220526046000032502

Code Auswählen Erweitern

ZWAVE1 raw_13220526046000032502 => 011301

[krikan]

Code Auswählen Erweitern

ZWAVE1 raw_13220526046000032502 => 011301
Das ist korrekt.

Wenn Du bei <ZWDongle> das Attribut verbose auf 5 setzt, solltest Du einen ähnlichen Ablauf wie nachfolgend nach Befehlsausführung im Log finden:

Code Auswählen Erweitern

2016.07.14 06:33:15.327 4: ZWDongle *** get ZWDongle_0 raw 13040526046000032502
2016.07.14 06:33:15.327 5: ZWDongle_Write 0013040526046000032502 ()
2016.07.14 06:33:15.327 5: SW: 010c001304052604600003250287
2016.07.14 06:33:15.329 4: ZWDongle_ReadAnswer arg:raw regexp:^0113
2016.07.14 06:33:15.329 5: ACK received, WaitForAck=>2 for 010c001304052604600003250287
2016.07.14 06:33:15.331 4: ZWDongle_Read ZWDongle_0: rcvd 011301 (answer ZW_SEND_DATA), sending ACK
2016.07.14 06:33:15.332 5: SW: 06
2016.07.14 06:33:15.333 4: ZWDongle_ReadAnswer for raw: 011301
2016.07.14 06:33:15.366 4: ZWDongle_Read ZWDongle_0: rcvd 00130200 (request ZW_SEND_DATA), sending ACK
2016.07.14 06:33:15.366 5: SW: 06
2016.07.14 06:33:15.367 5: device ack reveived, removing 010c001304052604600003250287 from dongle sendstack
2016.07.14 06:33:15.367 5: ZWDongle_0 dispatch 00130200
Das ist die Auswirkung des Befehls bei einem Rolloaktor FGRM222. Der bewegt sich nach dem Befehl auch.
Im Detail zu wichtigen Punkten im Log:
011301 = Dongle konnte den Befehl ordnungsgemäß verschicken
00130200 = Aktor bestätigt den Empfang des Befehls (02 = CallbackId des Befehls = Zuordnung Bestätigung zu abgesetztem Befehl)

Im Prinzip musst Du nur feststellen, ob Dein Aktor reagiert. Dazu am Besten vor Befehlsabsetzung Rollo in Mitte fahren und nach Befehlsabsetzung ins Log schauen. Anhand Deiner Reaktion befürchte ich, dass der Aktor nicht reagiert..

Das Command ist für Version 2 der CC SWITCH_MULTILEVEL. Muss aber grds.  auch von Aktoren mit V3 der Class unterstützt werden. Der FGRM hat V3 und er reagiert auf diesen V2-Befehl.

[reen]

im Log wurde zum ausführen des Befehls folgendes eingetragen:

Code Auswählen Erweitern

2016.07.14 00:21:33 4: ZWDongle *** get ZWAVE1 raw 13220526046000032502
2016.07.14 00:21:33 5: ZWDongle_Write 0013220526046000032502 ()
2016.07.14 00:21:33 5: SW: 010c0013220526046000032502a1
2016.07.14 00:21:33 4: ZWDongle_ReadAnswer arg:raw regexp:^0113
2016.07.14 00:21:33 5: ACK received, WaitForAck=>2 for 010c0013220526046000032502a1
2016.07.14 00:21:33 4: ZWDongle_Read ZWAVE1: rcvd 011301 (answer ZW_SEND_DATA), sending ACK
2016.07.14 00:21:33 5: SW: 06
2016.07.14 00:21:33 4: ZWDongle_ReadAnswer for raw: 011301
2016.07.14 00:21:33 4: ZWDongle_Read ZWAVE1: rcvd 00130200 (request ZW_SEND_DATA), sending ACK
2016.07.14 00:21:33 5: SW: 06
2016.07.14 00:21:33 5: device ack reveived, removing 010c0013220526046000032502a1 from dongle sendstack
2016.07.14 00:21:33 5: ZWAVE1 dispatch 00130200
2016.07.14 00:21:33 4: CMD:ZW_SEND_DATA ID:00 ARG: CB:02
2016.07.14 00:21:33 4: ZWAVE1 transmit OK for CB 02, target unknown

Im Prinzip wird das ja so verarbeitet wie in deinem Beispiel, aber du hast Recht, mein Aktor reagiert auf den Befehl nicht.

[krikan]

mein Aktor reagiert auf den Befehl nicht

Das hatte ich befürchet  .
Ich könnte heute abend noch einmal die V3 - Version zusammenbasteln. Aber befürchte gleiches Ergebnis..
Mir gehen ein wenig die Ideen aus.

Du kannst natürlich auch mit Kombinationen von on/off, sleep, stop zur zeitgesteuerten Positionierung arbeiten, aber das kann es eigentlich nicht sein, wenn SWITCH_MULTILEVEL existiert. Außer SWITCH_MULTILEVEL ist wirklich so "dumm" implenmentiert, wie es derzeit scheint.

[reen]

Jo, auf Grund der Abwärtskompatibilität und der bisherigen Tests, denke ich dass du dir die Mühe für eine V3 Implementierung sparen kannst, aber wirklich sehr entgegenkommend von dir, Danke, hab dich ja schon genug strapaziert!

Du kannst natürlich auch mit Kombinationen von on/off, sleep, stop zur zeitgesteuerten Positionierung arbeiten

...an genau soetwas habe ich auch schon als Workaround gedacht.
In solch einem Fall habe ich ja aber keine verlässliche "Rückmeldung" über den aktuellen Status des Aktors mehr, was ja schon sehr informativ wäre.
Dafür bleibt dann wohl doch nur entweder ganz auf oder zu.

das kann es eigentlich nicht sein, wenn SWITCH_MULTILEVEL existiert

Dachte ich anfangs ja auch, aber nach deinen Bemühungen, schwindet meine Hoffnung ebenso...

[krikan]

Auch wenn es nicht wirklich hilft, mich beruhigt es ein wenig  : Wir sind nicht alleine mit der seltsamen Reaktion auf SWITCH_MULTILEVEL-Commands bei Fakro: https://www.domoticz.com/forum/viewtopic.php?f=38&t=6271. Auch dort läuft nur auf, zu, stop.

In solch einem Fall habe ich ja aber keine verlässliche "Rückmeldung" über den aktuellen Status des Aktors mehr, was ja schon sehr informativ wäre.

Also bekommst Du auch mit "get <device> swmStatus" oder ähnlich keine % Rückmeldung?

Es gibt eben leider manchmal seltsame Implementierungen bei Aktoren, wobei ich bei SDK 4.5 nicht mehr mit solchen Problemen gerechnet hätte..

[reen]

Also bekommst Du auch mit "get <device> swmStatus" oder ähnlich keine % Rückmeldung?

nicht wirklich, wenn ich den Motor einschalte und irgendwo wieder stoppe, ist der swmStatus "dim  254", wenn der Motor ganz zu ist, ist der Status "state:off".

...ich denke aber an diesem Punkt können wir die Bemühungen dann auch erstmal auf Eis legen.
Aber trotzdem vielen Dank für deine Hilfe, auch wenn ich noch paar "?" im Kopf habe, gerlernt habe ich dadurch schonmal einiges!

[krikan]

nicht wirklich, wenn ich den Motor einschalte und irgendwo wieder stoppe, ist der swmStatus "dim  254", wenn der Motor ganz zu ist, ist der Status "state:off".

Die Rückgabe von "dim 254" ist immerhin konsequent: 0xFE = 254 dec bedeutet laut CC "unknown state/position"

Könntest Du beim Aktor (hexNodeId=22) einmal "SupportGet" abfragen und das Log mit der Antwort posten:

Code Auswählen Erweitern

get <Zwdongle> raw 13220226062502
Das würde mich nämlich noch interessieren.

[reen]

natürlich, nach dem Befehl erscheint folgendes im log:

Code Auswählen Erweitern

2016.07.14 10:34:21 4: ZWDongle *** get ZWAVE1 raw 13220226062502
2016.07.14 10:34:21 5: ZWDongle_Write 0013220226062502 ()
2016.07.14 10:34:21 5: SW: 01090013220226062502c2
2016.07.14 10:34:21 4: ZWDongle_ReadAnswer arg:raw regexp:^0113
2016.07.14 10:34:21 5: ACK received, WaitForAck=>2 for 01090013220226062502c2
2016.07.14 10:34:21 4: ZWDongle_Read ZWAVE1: rcvd 011301 (answer ZW_SEND_DATA), sending ACK
2016.07.14 10:34:21 5: SW: 06
2016.07.14 10:34:21 4: ZWDongle_ReadAnswer for raw: 011301
2016.07.14 10:34:21 4: ZWDongle_Read ZWAVE1: rcvd 00130200 (request ZW_SEND_DATA), sending ACK
2016.07.14 10:34:21 5: SW: 06
2016.07.14 10:34:21 5: device ack reveived, removing 01090013220226062502c2 from dongle sendstack
2016.07.14 10:34:21 5: ZWAVE1 dispatch 00130200

...ist da alles dabei was du suchst?

[krikan]

Leider nicht. Die Antwort des Aktors danach auf die Abfrage fehlt noch. Erkennt man daran, dass in der Logzeile irgendwo ..2607.. in den Hexwerten enthalten ist. Die Logzeile suche ich..

[reen]

ok, nochmal ausgeführt:

Code Auswählen Erweitern

2016.07.14 10:57:41 4: ZWDongle *** get ZWAVE1 raw 13220226062502
2016.07.14 10:57:41 5: ZWDongle_Write 0013220226062502 ()
2016.07.14 10:57:41 5: SW: 01090013220226062502c2
2016.07.14 10:57:41 4: ZWDongle_ReadAnswer arg:raw regexp:^0113
2016.07.14 10:57:41 5: ACK received, WaitForAck=>2 for 01090013220226062502c2
2016.07.14 10:57:41 4: ZWDongle_Read ZWAVE1: rcvd 011301 (answer ZW_SEND_DATA), sending ACK
2016.07.14 10:57:41 5: SW: 06
2016.07.14 10:57:41 4: ZWDongle_ReadAnswer for raw: 011301
2016.07.14 10:57:42 4: ZWDongle_Read ZWAVE1: rcvd 00130200 (request ZW_SEND_DATA), sending ACK
2016.07.14 10:57:42 5: SW: 06
2016.07.14 10:57:42 5: device ack reveived, removing 01090013220226062502c2 from dongle sendstack
2016.07.14 10:57:42 5: ZWAVE1 dispatch 00130200
2016.07.14 10:57:42 4: CMD:ZW_SEND_DATA ID:00 ARG: CB:02
2016.07.14 10:57:42 4: ZWAVE1 transmit OK for CB 02, target kue_MultiSensor
2016.07.14 10:57:42 4: ZWDongle_Read ZWAVE1: rcvd 000400220426070300 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.07.14 10:57:42 5: SW: 06
2016.07.14 10:57:42 5: ZWAVE1 dispatch 000400220426070300
2016.07.14 10:57:42 4: CMD:APPLICATION_COMMAND_HANDLER ID:22 ARG:0426070300 CB:00

...dachte die letzten 6 Einträge gehören da schon nichtmehr zu, weil hier von einem anderen Sensoren als target die rede ist!?

[krikan]

2016.07.14 10:57:42 4: CMD:APPLICATION_COMMAND_HANDLER ID:22 ARG:0426070300 CB:00

Danke. Aber jetzt gebe ich auf:

Primary Switch Type: 03 -> Endpunkt A = close (0x00); Endpunkt B = open (0x63/0xFF); "unknown state/position" auf Abfragen sollten mMn nur kommen, wenn Primary Switch Type = 00
Secondary Switch Type: 00 -> nicht unterstützt (eigentlich für Command LevelChange vorgesehen)
-> das ist zumindest mein derzeitiges Verständnis.

[reen]

Kein Problem, hast sehr viel helfen!

...eine Sache noch:
Ich würde ja trotzdem gern verstehen wie das Zwave so in fhem aufgebaut ist und kommuniziert, finde aber immer nur so einzelne Forenbeiträge, die ich nicht komplett nachvollziehen kann.
Gibts denn zb ne deailiertere Erläuterung zur ZWave.pm, das würde mir schonmal weiterhelfen

[krikan]

Ich würde ja trotzdem gern verstehen wie das Zwave so in fhem aufgebaut ist und kommuniziert, finde aber immer nur so einzelne Forenbeiträge, die ich nicht komplett nachvollziehen kann.
Gibts denn zb ne deailiertere Erläuterung zur ZWave.pm, das würde mir schonmal weiterhelfen

Die Doku ist der frei verfügbare Perl-Code. Die Perl-Entwickler verstehen es beim Code-Lesen (ich nicht).
Die Frage ist, was Du wissen willst. Für ein volles Verständnis musst Du sicherlich Perl komplett lernen.
Es hilft aber auch schon, das Modul mit Log-Einträgen zu durchziehen und den Programm-Ablauf anhand der Log-Einträge zu verfolgen. Habe ich auch schon mal gemacht, ersetzt mMn aber keinesfalls Perl-Studium.
Wenn es nur um einzelne Dinge geht (Commands ergänzen usw.) brauchst Du aber gar nicht alles zu wissen. Es ist nur das Verständnis von bestimmten Strukturen notwendig. Mehr kenne ich auch nicht. Kann man sich durch die Log-Einträge, Forensuche, experimentieren (oder im Forum fragen) aneignen.