Z-Wave Dimmer lässt sich meist nicht einschalten

[jensb]

Hi Andreas,

es ergibt keinen Unterschied, ob man mit FHEM von aus nach an wechselt oder von aus nach gedimmt. In beiden Fällen wird meist wieder nach aus getoggelt. Für den Dimmer ist es typisch, dass er auf "on" mit "dim 99%" antwortet bzw. mit dem letzten eingestellten Dimmerwert.

Es gibt den Parameter 22 "Assign toggle switch status to the device status" der sich aber nicht auf den beschriebenen Effekt auswirkt. Für Parameter 23 "Double click option - set the brightness level to MAX" gilt das Gleiche.

Merkwürdig bleibt das zuverlässige Abschalten über FHEM und das Verhalten auf den optimal getimeten FHEM-"Doppelklick"-Ein. Ich vermute, dass der 2. Klick irgendwo nach dem Versenden des "verschlüsselten set" Telegramm vom Webfrontend eintrifft und möglicherweise den Hash des Dimmer-Devices so ändert, das die nachfolgenden Telegramme das eigentlich gewünschte bewirken. Hier geht wahrscheinlich etwas mit den Daten durcheinander.

... könnte man evtl. sehen ob das Paket vielleicht zwei Mal gesendet ...

Das müsste sich dann aber auch im Log wiederfinden oder?

Mein Analyse hat gezeigt, dass "2016.01.01 20:50:11.329 4: ZWave CMD:APPLICATION_COMMAND_HANDLER ID:04 ARG:029840" das "state"-Reading auf off zurücksetzt. Was ich nicht überprüfen kann ist, ob der Dimmer zu diesem Zeitpunkt schon den Zustand aus angenommen hat und diesen meldet oder ob der Dimmer erst mit einem der folgenden Telegramme wieder ausgeschaltet wird. Dafür geht das ganze leider zu schnell. Vielleicht sollte ich in ZWave_Parse mal vorübergehend ein dickes Sleep einbauen?

Grüße,
Jens

[A.Harrenberg]

Hi Jens,

Merkwürdig bleibt das zuverlässige Abschalten über FHEM und das Verhalten auf den optimal getimeten FHEM-"Doppelklick"-Ein. Ich vermute, dass der 2. Klick irgendwo nach dem Versenden des "verschlüsselten set" Telegramm vom Webfrontend eintrifft und möglicherweise den Hash des Dimmer-Devices so ändert, das die nachfolgenden Telegramme das eigentlich gewünschte bewirken. Hier geht wahrscheinlich etwas mit den Daten durcheinander.

das ist unwahrscheinlich. Die Nachricht die versendet wird ist völlig unabhängig vom aktuellen Status des Devices. Die Nachrichten die Du siehst gehören alle zu dem einen Befehl!

Ich habe mal ein paar Kommentare in Dein Log aus Post #3 geschrieben:

Code Auswählen Erweitern

2016.01.01 20:50:10.702 2: ZWave set Dimmer_WZ on
2016.01.01 20:50:10.703 5: Dimmer_WZ: SWITCH_MULTILEVEL is a secured class!
2016.01.01 20:50:10.704 5: Dimmer_WZ SECURITY: 2601FF stored for encryption

hier wurde der Befehl 2601FF (26 = Command Class  SWITCH_MULTILEVEL, 01 = set, FF = on) "abgefangen" und auf einen internen Stack gelegt.

2016.01.01 20:50:10.710 4: ZWave get Dimmer_WZ secNonce

Zur Verschlüsselung wird eine sogennanten NONCE benötigt, diese wird vom Dimmer angefordert.
(9840: 98 = Command Class SECURITY, 40 = get NONCE)

2016.01.01 20:50:10.711 5: ZWDongle_Write 0013040298402504 (f77586ab)
2016.01.01 20:50:10.713 5: SW: 010900130402984025041a
2016.01.01 20:50:10.715 4: ZWDongle_ReadAnswer arg:secNonce regexp:^00040004..98
2016.01.01 20:50:10.716 5: ACK received, WaitForAck=>2 for 010900130402984025041a
2016.01.01 20:50:10.722 4: ZWDongle_Read ZWave: sending ACK, processing 011301
2016.01.01 20:50:10.723 5: SW: 06
2016.01.01 20:50:10.725 5: ZWave dispatch 011301
2016.01.01 20:50:10.742 4: ZWDongle_Read ZWave: sending ACK, processing 001304000003
2016.01.01 20:50:10.743 5: SW: 06
2016.01.01 20:50:10.745 5: device ack reveived, removing 010900130402984025041a from dongle sendstack
2016.01.01 20:50:10.745 5: ZWave dispatch 001304000003
2016.01.01 20:50:10.746 4: ZWave CMD:ZW_SEND_DATA ID:00 ARG:0003
2016.01.01 20:50:10.747 4: ZWave transmit OK for 04

Hier wurde der Befehl gesendet und die Übertragung vom Dongle und von Dimmer bestätigt


2016.01.01 20:50:10.758 4: ZWDongle_Read ZWave: sending ACK, processing 000400040a9880e4cdbf3ba57bb976

Das ist die angeforderte NONCE (9880.....)

2016.01.01 20:50:10.758 5: SW: 06
2016.01.01 20:50:10.761 4: ZWDongle_ReadAnswer for secNonce: 000400040a9880e4cdbf3ba57bb976
2016.01.01 20:50:10.761 4: ZWave CMD:APPLICATION_COMMAND_HANDLER ID:04 ARG:0a9880e4cdbf3ba57bb976
2016.01.01 20:50:10.764 5: Dimmer_WZ SECURITY: 2601FF set Dimmer_WZ on  retrieved for encryption
2016.01.01 20:50:10.765 5: Dimmer_WZ: secEncrypt plain:002601FF enc:2873adc9

Hier wird der abgegelegte Befehl verschlüsselt, Du erkennst die 2601FF von oben wieder...

2016.01.01 20:50:10.771 4: ZWave set Dimmer_WZ secEncap 8188f3075e8d0761622873adc9e4907386a297ca9c2a
2016.01.01 20:50:10.772 5: ZWDongle_Write 00130417988188f3075e8d0761622873adc9e4907386a297ca9c2a2504 (f77586ab)

Hier wird der verschlüsselte Befehl versendet

2016.01.01 20:50:10.774 5: SW: 011e00130417988188f3075e8d0761622873adc9e4907386a297ca9c2a250485
2016.01.01 20:50:10.813 5: Dimmer_WZ: type=set, cmd=on  (2601FF set Dimmer_WZ on )
2016.01.01 20:50:10.833 5: ACK received, WaitForAck=>2 for 011e00130417988188f3075e8d0761622873adc9e4907386a297ca9c2a250485
2016.01.01 20:50:10.833 4: ZWDongle_Read ZWave: sending ACK, processing 011301
2016.01.01 20:50:10.834 5: SW: 06
2016.01.01 20:50:10.836 5: ZWave dispatch 011301
2016.01.01 20:50:10.839 4: ZWDongle_Read ZWave: sending ACK, processing 001304000003
2016.01.01 20:50:10.839 5: SW: 06
2016.01.01 20:50:10.841 5: device ack reveived, removing 011e00130417988188f3075e8d0761622873adc9e4907386a297ca9c2a250485 from dongle sendstack
2016.01.01 20:50:10.842 5: ZWave dispatch 001304000003
2016.01.01 20:50:10.843 4: ZWave CMD:ZW_SEND_DATA ID:00 ARG:0003
2016.01.01 20:50:10.843 4: ZWave transmit OK for 04

Hier ist der verschlüsselte Befehl von Dongel und vom Dimmer bestätigt worden.

2016.01.01 20:50:11.325 4: ZWDongle_Read ZWave: sending ACK, processing 00040004029840

Jetzt will uns der Dimmer etwas verschlüsseltes schicken und benötigt dazu eine NONCE von FHEM

2016.01.01 20:50:11.325 5: SW: 06
2016.01.01 20:50:11.328 5: ZWave dispatch 00040004029840
2016.01.01 20:50:11.329 4: ZWave CMD:APPLICATION_COMMAND_HANDLER ID:04 ARG:029840
2016.01.01 20:50:11.339 4: ZWave set Dimmer_WZ sendNonce

Der Befehl zum verschicken der NONCE wird ausgelöst

2016.01.01 20:50:11.340 5: ZWDongle_Write 0013040a98805dbc064a222c7ff42504 (f77586ab)
2016.01.01 20:50:11.342 5: SW: 01110013040a98805dbc064a222c7ff42504e2

Die NONCE wird an den Dimmer verschickt (9880....)

2016.01.01 20:50:11.349 5: ACK received, WaitForAck=>2 for 01110013040a98805dbc064a222c7ff42504e2
2016.01.01 20:50:11.353 4: ZWDongle_Read ZWave: sending ACK, processing 011301
2016.01.01 20:50:11.353 5: SW: 06
2016.01.01 20:50:11.359 5: ZWave dispatch 011301
2016.01.01 20:50:11.375 4: ZWDongle_Read ZWave: sending ACK, processing 001304000003
2016.01.01 20:50:11.375 5: SW: 06
2016.01.01 20:50:11.377 5: device ack reveived, removing 01110013040a98805dbc064a222c7ff42504e2 from dongle sendstack
2016.01.01 20:50:11.378 5: ZWave dispatch 001304000003
2016.01.01 20:50:11.379 4: ZWave CMD:ZW_SEND_DATA ID:00 ARG:0003
2016.01.01 20:50:11.379 4: ZWave transmit OK for 04

Die Übertragung wurde wieder vom Dongle und vom Dimmer bestätigt.

2016.01.01 20:50:11.396 4: ZWDongle_Read ZWave: sending ACK, processing 00040004179881d858dec93453f4960c99cb395d399068f5624e40c3

Die verschlüsselte Nachricht vom Dimmer kommt ist angekommen...

2016.01.01 20:50:11.397 5: SW: 06
2016.01.01 20:50:11.398 5: ZWave dispatch 00040004179881d858dec93453f4960c99cb395d399068f5624e40c3
2016.01.01 20:50:11.399 4: ZWave CMD:APPLICATION_COMMAND_HANDLER ID:04 ARG:179881d858dec93453f4960c99cb395d399068f5624e40c3
2016.01.01 20:50:11.402 5: Dimmer_WZ: secDecrypt: decrypted cmd 00260300
2016.01.01 20:50:11.403 5: Dimmer_WZ: secDecrypt: Sequencebyte 0, sequenced 0, secondFrame 0, sequenceCounter 00
2016.01.01 20:50:11.404 5: Dimmer_WZ: secDecrypt: calculated Authentication code 399068f5624e40c3
2016.01.01 20:50:11.404 5: Dimmer_WZ: secDecrypt: parsing 0004000403260300
2016.01.01 20:50:11.405 4: ZWave CMD:APPLICATION_COMMAND_HANDLER ID:04 ARG:03260300

Nach dem Entschlüssel findet sich eine 260300 Nachricht: 26 Command Class  SWITCH_MULTILEVEL, 03 = Report, 00=off

Das heisst der Dimmer meldet das er aus.

Das ganze "hin-und-her" ist also wirklich nichts weiter als "schalt ein", "ich bin aus"...

[zweifaches senden]
Das müsste sich dann aber auch im Log wiederfinden oder?

Nein, das macht der Dongle von ganz alleine... Falls er keine Bestätigung vom Dimmer bekommt sendet er noch mal ohne das auf Protokollebene zu melden. Erst wenn er gar keine Bestätigung bekommt meldet er ein "NO_ACK". Da das ganze hier aber nur bei einem Befehl auftritt ist es relativ unwahrscheinlich das hier ein Empfangsproblem zu einem mehrfachen Senden führt. Außerdem sollten die Geräte soetwas anhand einer fortlaufenden Nummer feststellen können (diese Nummer existiert nur auf der Funkebene, in der Protokollebene gibt es die nicht...)

Mein Analyse hat gezeigt, dass "2016.01.01 20:50:11.329 4: ZWave CMD:APPLICATION_COMMAND_HANDLER ID:04 ARG:029840" das "state"-Reading auf off zurücksetzt. Was ich nicht überprüfen kann ist, ob der Dimmer zu diesem Zeitpunkt schon den Zustand aus angenommen hat und diesen meldet oder ob der Dimmer erst mit einem der folgenden Telegramme wieder ausgeschaltet wird. Dafür geht das ganze leider zu schnell. Vielleicht sollte ich in ZWave_Parse mal vorübergehend ein dickes Sleep einbauen?

Wie oben in Deinem Log beschrieben, der 029840 ist nur der Beginn der verschlüsselten Statusmeldung vom Dimmer. Da wird kein weiterer Befehl gesendet und nichts geschaltet. Das Ding geht wieder aus und meldet dies auch korrekt.

Ich gehe nach-wie-vor von einem Firmware-Problem des Dimmers aus.

Gruß,
Andreas.

[jensb]

Hallo Andreas,

danke für die ausführlichen Erklärungen, das ist schon sehr interessant und auch nachvollziehbar.

Gibt es nach deinen Infos jemanden spezielles bei Fibaro, den man wegen der Firmware ansprechen sollte oder ist eine Mail an support@fibaro.com der richtige Weg?

Grüße,
Jens

[krikan]

Habe mich mal bei den üblichen Foren nach dem Aktor umgesehen. Probleme werden häufiger berichtet. z-way (ZWave+ zertifiziert) scheint den Dimmer nicht zu untersützen: http://forum.z-wave.me/viewtopic.php?f=3423&t=22236. Dort kann man auch schon Fibaros Antwort auf Problemberichte finden. Bei ozw und den darauf aufbauenden Programmen gab es wohl auch Besonderheiten bei der Einbindung. Zu Security speziell habe ich aber nichts gefunden.
Vielleicht tatsächlich mal anschreiben und schauen, ob die Antwort anders als im ZWay-Forum ist.

Gruß, Christian

[jensb]

Die Support-Anfrage an Fibaro ist per Mail raus. Melde mich (spätestens) wieder, wenn ich eine Antwort habe.

Gruß,
Jens