Fakro ZWS230 Dachfenstermotor - Problem mit dem ansteuern

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