Hallo zusammen,
habe gerade meinen neuen FGS223 in Betrieb genommen und ihn mit
set ZWDongle_0 addNode onNwSec
inkludiert, daraufhin habe ich folgende Devices in Fhem bekommen
ZWave_SWITCH_BINARY_14
ZWave_ZWAVEPLUS_INFO_14.01
ZWave_ZWAVEPLUS_INFO_14.02
Device ZWave_SWITCH_BINARY_14 lässt sich Problemlos per WebUI schalten und auch der Status des lokalen Schalters wird korrekt übermittelt. Aber bei Device 14.01 & 14.02 tut sich nichts (wobei 14.01 nur eine "Kopie" von 14 bzw. Kanal 1 zu sein scheint wenn ich das richtig verstanden habe).
Zuvor hatte ich ein Update von Fhem aufgrund dieses Beitrags (https://forum.fhem.de/index.php/topic,61159.60.html) gemacht damit die inkludierung gleich den Patch berücksichtigt. Hat aber scheinbar nicht geholfen oder es ist doch ein anderes Problem.
Dann habe ich noch associationAdd versucht, aber ich dachte eigentlich das die bei der inklusion schon gesetzt wurde da ich 14 ja auch stuern kann
set ZWave_ZWAVEPLUS_INFO_14.02 associationAdd 1 1
hier noch ein List von 14 & 14.02
Internals:
CFGFN
DEF d9846de7 14
IODev ZWDongle_0
LASTInputDev ZWDongle_0
MSGCNT 26
NAME ZWave_SWITCH_BINARY_14
NR 123
STATE off
TYPE ZWave
ZWDongle_0_MSGCNT 26
ZWDongle_0_RAWMSG 0004000e083202213200000000
ZWDongle_0_TIME 2017-01-27 16:54:36
ZWaveSubDevice no
endpointChildren ZWave_ZWAVEPLUS_INFO_14.01,ZWave_ZWAVEPLUS_INFO_14.02
homeId d9846de7
isWakeUp
lastMsgSent 1485532476.06078
nodeIdHex 0e
secTime 1485532476.06051
Readings:
2017-01-27 16:51:34 SECURITY ENABLED
2017-01-27 16:51:37 mcCapability_01 ZWAVEPLUS_INFO VERSION SWITCH_BINARY ASSOCIATION ASSOCIATION_GRP_INFO MULTI_CHANNEL_ASSOCIATION METER MARK SWITCH_MULTILEVEL
2017-01-27 16:51:38 mcCapability_02 ZWAVEPLUS_INFO VERSION SWITCH_BINARY ASSOCIATION ASSOCIATION_GRP_INFO MULTI_CHANNEL_ASSOCIATION METER MARK SWITCH_MULTILEVEL
2017-01-27 16:51:37 mcEndpoints total 2, identical
2017-01-27 16:51:37 model FIBARO System FGS223 Double Relay
2017-01-27 16:51:37 modelConfig fibaro/fgs223.xml
2017-01-27 16:51:37 modelId 010f-0203-1000
2017-01-27 16:54:36 power 0 W
2017-01-27 16:54:36 reportedState off
2017-01-27 16:54:36 state off
2017-01-27 16:54:36 timeToAck 0.027
2017-01-27 16:54:36 transmit OK
secMsg:
Secnonce:
Attributes:
IODev ZWDongle_0
classes ZWAVEPLUS_INFO VERSION MANUFACTURER_SPECIFIC SWITCH_BINARY DEVICE_RESET_LOCALLY ASSOCIATION_GRP_INFO ASSOCIATION POWERLEVEL CRC_16_ENCAP CONFIGURATION METER MULTI_CHANNEL_ASSOCIATION MULTI_CHANNEL APPLICATION_STATUS PROTECTION ALARM SECURITY FIRMWARE_UPDATE_MD CENTRAL_SCENE MARK SWITCH_MULTILEVEL
room ZWave
secure_classes SWITCH_BINARY DEVICE_RESET_LOCALLY ASSOCIATION CONFIGURATION MULTI_CHANNEL_ASSOCIATION MULTI_CHANNEL PROTECTION CENTRAL_SCENE MARK SWITCH_MULTILEVEL
vclasses ALARM:5 APPLICATION_STATUS:1 ASSOCIATION:2 ASSOCIATION_GRP_INFO:1 CENTRAL_SCENE:2 CONFIGURATION:1 CRC_16_ENCAP:1 DEVICE_RESET_LOCALLY:1 FIRMWARE_UPDATE_MD:3 MANUFACTURER_SPECIFIC:2 METER:3 MULTI_CHANNEL:4 MULTI_CHANNEL_ASSOCIATION:3 POWERLEVEL:1 PROTECTION:2 SECURITY:1 SWITCH_BINARY:1 SWITCH_MULTILEVEL:3 VERSION:2 ZWAVEPLUS_INFO:2
Internals:
CFGFN
DEF d9846de7 3586
IODev ZWDongle_0
NAME ZWave_ZWAVEPLUS_INFO_14.02
NR 127
STATE off
TYPE ZWave
ZWaveSubDevice yes
endpointParent ZWave_SWITCH_BINARY_14
homeId d9846de7
nodeIdHex 0e02
Readings:
2017-01-27 16:52:55 state off
Attributes:
IODev ZWDongle_0
classes ZWAVEPLUS_INFO VERSION SWITCH_BINARY ASSOCIATION ASSOCIATION_GRP_INFO MULTI_CHANNEL_ASSOCIATION METER MARK SWITCH_MULTILEVEL
room ZWave
Übersehe ich irgendwo was ?
Danke
Ja,
siehe hier:
https://forum.fhem.de/index.php/topic,61159.msg558461.html#msg558461
Eigentlich sollte das mit einem Patch geregelt sein worden.
Ich hatte das Problem auch, hab dann die Associations so eingestellt wie in dem Thread dort empfohlen.
Nun wird alles richtig an die Subdevices gesendet.
hm ok, danke, dann stimmt wohl was mit dem Patch nicht, habe gerade die beiden Befehle von denen ich dachte die sein damit schon drin manuell ausgeführt und nun bekomme ich beim betätigen des schalters eine Rückmeldung auf 14.01 & 14.02. Aber schalten kann ich dort per WebUi nichts, schalten tut er nur wenn ich 14 nutze und dann sehe ich den identischen Status auch bei 14.01.. muss ich für das schalten auch noch etwas tun bzw. wie kann ich 14.02 schalten ?
Zitat von: nerothos am 28 Januar 2017, 11:29:51
hm ok, danke, dann stimmt wohl was mit dem Patch nicht,
Kann mir höchstens ein Problem im Zusammenhang mit SECURITY vorstellen, weil es bei anderen wohl funktioniert hat. Aber selbst dort habe ich meine Zweifel, ob es ein Problem des Patches oder ein anderes ist.
Um das zu kontrollieren, wäre ein verbose 5-Log einer secure-Inklusion für mich mit den diversen anderen Infos hilfreich (siehe https://wiki.fhem.de/wiki/Z-Wave#Welche_Infos_sollten_Anfragen_im_ZWave-Forum_enthalten.3F).
Wenn Du keine neue Inklusion machen möchtest, bestreite ich frech einen Patch-Fehler :) :
Das letzte Posting liest sich eher nach einem Konfigurationsfehler. Frage mal die im Wiki genannten Werte vom Aktor ab und poste bitte die Ausgabe von "list <device>".
Gruß, Christian
heureka, mein Held des Tages... krikan ;)
es liegt wirklich an der security, habe gerade eine inklusion ohne gemacht und siehe da es funktioniert einwandfrei :)
somit nehme ich natürlich die Vermutung! (wollte keinem was unterstellen ;)) zurück, der Patch ist einwandrei ! ;)
wenn ich damit unterstützen kann mache ich das gerne, also eine inklusion mit security und folgenden gesetzten attr ?
attr <ZWDongle> verbose 5
attr global mseclog 1
Ohne Security ist aber der gesamte Funkverkehr unverschlüsselt oder ?
leider doch nicht ganz richtig gewesen, habe bei manuelle betätigung keine Rückmeldung erhalten, erst nachdem ich jetzt manuell noch mal
set <MainDevice> associationDel 1 <ControllerNodeId>
set <MainDevice> mcaAdd 1 0 <ControllerNodeId> 1
gesetzt habe funktioniert rückmeldung vom schalter als auch schalten per WebUi einwandfrei ;)
Dann brauche ich Logs mit den genannten gesetzten Attributen von der Inklusion. Es sei denn jemand anderes findet ein mögliches Problem ohne Logs.
Hi,
und wie sieht das dann mit SECURITY aus? Besteht da wirklich ein Problem? Dann müsste ich mir das ansehen.
Gruß,
Andreas.
Denke, dass das nicht mit SECURITY zusammenhaengt. Habe mir jetzt heute mittag den Aktor selbst besorgt, damit ich testen kann. Erster Versuch ist normale Inklusion gewesen. Die beiden init-Befehle wurden dabei tatsaechlich nicht ausgeführt. Ursache finde ich leider bisher nicht.
list Hauptdevice:
Internals:
CFGFN
DEF e345c452 2
IODev ZWDongle_1
LASTInputDev ZWDongle_1
MSGCNT 10
NAME ZWave_SWITCH_BINARY_2
NR 65
STATE associationAdd 1 1
TYPE ZWave
ZWDongle_1_MSGCNT 10
ZWDongle_1_RAWMSG 00040002058e03050500
ZWDongle_1_TIME 2017-01-28 18:11:26
ZWaveSubDevice no
endpointChildren ZWave_ZWAVEPLUS_INFO_2.01,ZWave_ZWAVEPLUS_INFO_2.02
homeId e345c452
isWakeUp
lastMsgSent 1485623485.83298
nodeIdHex 02
Readings:
2017-01-28 18:08:51 mcCapability_01 ZWAVEPLUS_INFO VERSION SWITCH_BINARY ASSOCIATION ASSOCIATION_GRP_INFO MULTI_CHANNEL_ASSOCIATION METER MARK SWITCH_MULTILEVEL
2017-01-28 18:08:53 mcCapability_02 ZWAVEPLUS_INFO VERSION SWITCH_BINARY ASSOCIATION ASSOCIATION_GRP_INFO MULTI_CHANNEL_ASSOCIATION METER MARK SWITCH_MULTILEVEL
2017-01-28 18:08:51 mcEndpoints total 2, identical
2017-01-28 18:11:24 mcaGroups 5
2017-01-28 18:11:25 mca_1 Max 1 Nodes ZWDongle_1
2017-01-28 18:11:25 mca_2 Max 5
2017-01-28 18:11:25 mca_3 Max 5
2017-01-28 18:11:25 mca_4 Max 5
2017-01-28 18:11:26 mca_5 Max 5
2017-01-28 18:08:51 model FIBARO System FGS223 Double Relay
2017-01-28 18:08:51 modelConfig fibaro/fgs223.xml
2017-01-28 18:08:51 modelId 010f-0203-1000
2017-01-28 18:08:26 state associationAdd 1 1
2017-01-28 18:11:25 timeToAck 0.155
2017-01-28 18:11:25 transmit OK
Attributes:
IODev ZWDongle_1
classes ZWAVEPLUS_INFO VERSION MANUFACTURER_SPECIFIC SWITCH_BINARY DEVICE_RESET_LOCALLY ASSOCIATION_GRP_INFO ASSOCIATION POWERLEVEL CRC_16_ENCAP CONFIGURATION METER MULTI_CHANNEL_ASSOCIATION MULTI_CHANNEL APPLICATION_STATUS PROTECTION ALARM SECURITY FIRMWARE_UPDATE_MD CENTRAL_SCENE MARK SWITCH_MULTILEVEL
room ZWave
vclasses ALARM:5 ASSOCIATION_GRP_INFO:1 CENTRAL_SCENE:2 CRC_16_ENCAP:1 DEVICE_RESET_LOCALLY:1 FIRMWARE_UPDATE_MD:3 MANUFACTURER_SPECIFIC:2 METER:3 MULTI_CHANNEL:4 MULTI_CHANNEL_ASSOCIATION:3 POWERLEVEL:1 PROTECTION:2 SECURITY:1 SWITCH_BINARY:1 SWITCH_MULTILEVEL:3 VERSION:2 ZWAVEPLUS_INFO:2
list Endpoint 1
Internals:
CFGFN
DEF e345c452 513
IODev ZWDongle_1
LASTInputDev ZWDongle_1
MSGCNT 4
NAME ZWave_ZWAVEPLUS_INFO_2.01
NR 68
STATE ???
TYPE ZWave
ZWDongle_1_MSGCNT 4
ZWDongle_1_RAWMSG 0004000209600d01008e03030500
ZWDongle_1_TIME 2017-01-28 18:10:41
ZWaveSubDevice yes
endpointParent ZWave_SWITCH_BINARY_2
homeId e345c452
isWakeUp
nodeIdHex 0201
Readings:
2017-01-28 18:10:40 mcaGroups 3
2017-01-28 18:10:40 mca_1 Max 0
2017-01-28 18:10:40 mca_2 Max 5
2017-01-28 18:10:41 mca_3 Max 5
Attributes:
IODev ZWDongle_1
classes ZWAVEPLUS_INFO VERSION SWITCH_BINARY ASSOCIATION ASSOCIATION_GRP_INFO MULTI_CHANNEL_ASSOCIATION METER MARK SWITCH_MULTILEVEL
room ZWave
list Endpoint 2
Internals:
CFGFN
DEF e345c452 514
IODev ZWDongle_1
LASTInputDev ZWDongle_1
MSGCNT 4
NAME ZWave_ZWAVEPLUS_INFO_2.02
NR 70
STATE ???
TYPE ZWave
ZWDongle_1_MSGCNT 4
ZWDongle_1_RAWMSG 0004000209600d02008e03030500
ZWDongle_1_TIME 2017-01-28 18:11:03
ZWaveSubDevice yes
endpointParent ZWave_SWITCH_BINARY_2
homeId e345c452
isWakeUp
nodeIdHex 0202
Readings:
2017-01-28 18:11:02 mcaGroups 3
2017-01-28 18:11:03 mca_1 Max 0
2017-01-28 18:11:03 mca_2 Max 5
2017-01-28 18:11:03 mca_3 Max 5
Attributes:
IODev ZWDongle_1
classes ZWAVEPLUS_INFO VERSION SWITCH_BINARY ASSOCIATION ASSOCIATION_GRP_INFO MULTI_CHANNEL_ASSOCIATION METER MARK SWITCH_MULTILEVEL
room ZWave
Die Benennung der Endpoints 1 und 2 stimmt auch nicht (mehr). Es wird statt der Generic-Class die erste COMMAND CLASS zur Bennung herangezogen. Darum heißen die Endpoints ZWave_ZWAVEPLUS_INFO_2.0x statt ZWave_SWITCH_BINARY_2.02.
Log haengt an.
ZitatDie beiden init-Befehle wurden dabei tatsaechlich nicht ausgeführt.
Das hat auch noch nie funktioniert: get model setzt 3 readings in 3 Schritten: das Einsammeln der init Befehle kommt in Schritt zwei (beim Setzen von modelConfig), braucht aber modelId, und das wird im Schritt drei gesetzt. Habe es gefixt.
ZitatDie Benennung der Endpoints 1 und 2 stimmt auch nicht (mehr). Es wird statt der Generic-Class die erste COMMAND CLASS zur Bennung herangezogen. Darum heißen die Endpoints ZWave_ZWAVEPLUS_INFO_2.0x statt ZWave_SWITCH_BINARY_2.02.
Das "(mehr)" darfst du striechen, das hat nie gestimmt. Ich habe jetzt die erste Klasse durch die generic ersetzt, aber nicht getestet.
sorry, war beruflich unterwegs, kann ich noch was tun um zu helfen ?
Also ich habe mit dem FGS223 ebenfalls Probleme, wenn er "Secure" eingebunden ist. Schalten lässt sich nur am Hauptgerät. Endpoint1 schaltet mit dem Hautgerät, Endpoint2 lässt sich gar nicht schalten. "Unsecure" funktioniert er ohne Probleme
Hauptgerät
Internals:
DEF cdf6772a 15
IODev ZDongle
LASTInputDev ZDongle
MSGCNT 73
NAME ZWave_SWITCH_BINARY_15
NR 121
STATE off
TYPE ZWave
ZDongle_MSGCNT 73
ZDongle_RAWMSG 0004000f19988106b3c97035924b3fb9c262f0a7c5defea9fd4249f47d94
ZDongle_TIME 2017-03-14 16:47:33
ZWaveSubDevice no
endpointChildren ZWave_10_15.01,ZWave_10_15.02
homeId cdf6772a
isWakeUp
lastMsgSent 1489506459.23952
nodeIdHex 0f
secTime 1489506453.81418
Readings:
2017-03-14 16:00:59 SECURITY ENABLED
2017-03-14 16:47:31 assocGroup_1 Max 1 Nodes
2017-03-14 16:47:31 assocGroup_2 Max 5 Nodes
2017-03-14 16:47:31 assocGroup_3 Max 5 Nodes
2017-03-14 16:47:31 assocGroup_4 Max 5 Nodes
2017-03-14 16:47:32 assocGroup_5 Max 5 Nodes
2017-03-14 16:47:31 assocGroups 5
2017-03-14 16:13:08 configAssociationsInZWaveNetwork27 15
2017-03-14 16:13:08 configFirstChannelEnergyReports 100
2017-03-14 16:13:08 configFirstChannelMinimalTimeBetween51 10
2017-03-14 16:13:08 configFirstChannelOperatingMode StandardOperation
2017-03-14 16:13:08 configFirstChannelPowerReports 20
2017-03-14 16:13:08 configFirstChannelPulseTimeForFlashing13 5
2017-03-14 16:13:08 configFirstChannelReactionToSwitchFor11 CancelModeAndSetTargetState
2017-03-14 16:13:09 configFirstChannelTimeParameterFor12 50
2017-03-14 16:13:09 configFlashingAlarmDuration 600
2017-03-14 16:13:09 configFlashingModeReport Disabled
2017-03-14 16:13:09 configMeasuringEnergyConsumedByThe60 functionInactive
2017-03-14 16:13:09 configPeriodicEnergyReports 3600
2017-03-14 16:13:09 configPeriodicPowerReports 3600
2017-03-14 16:13:09 configReactionToCOCO2SmokeAlarm Flash
2017-03-14 16:13:09 configReactionToFloodAlarm TurnOFF
2017-03-14 16:13:10 configReactionToGeneralAlarm Flash
2017-03-14 16:13:10 configReactionToHeatAlarm TurnOn
2017-03-14 16:13:10 configS1AssociationsSentTo2ndAnd3rd30 0
2017-03-14 16:13:10 configS1SwitchDoubleClickValueSent33 99
2017-03-14 16:13:10 configS1SwitchOFFValueSentTo2ndAnd3rd32 0
2017-03-14 16:13:10 configS1SwitchONValueSentTo2ndAnd3rd31 255
2017-03-14 16:13:10 configS1SwitchScenesSent 0
2017-03-14 16:13:11 configS2AssociationsSentTo4thAnd5th35 0
2017-03-14 16:13:11 configS2SwitchDoubleClickValueSent38 99
2017-03-14 16:13:11 configS2SwitchOFFValueSentTo4thAnd5th37 0
2017-03-14 16:13:11 configS2SwitchONValueSentTo4thAnd5th36 255
2017-03-14 16:13:11 configS2SwitchScenesSent 0
2017-03-14 16:13:11 configSavingStateBeforePowerFailure StateSavedAtPowerFailureAll1
2017-03-14 16:13:11 configSecondChannelEnergyReports 100
2017-03-14 16:13:12 configSecondChannelMinimalTimeBetween55 10
2017-03-14 16:13:12 configSecondChannelOperatingMode StandardOperation
2017-03-14 16:13:12 configSecondChannelPowerReports 20
2017-03-14 16:13:12 configSecondChannelPulseTimeFor18 5
2017-03-14 16:13:12 configSecondChannelReactionToSwitchFor16 CancelModeAndSetTargetState
2017-03-14 16:13:12 configSecondChannelTimeParameterFor17 50
2017-03-14 16:13:12 configSwitchType ToggleSwitchDeviceChangesStatus2
2017-03-14 16:01:06 mcCapability_01 ZWAVEPLUS_INFO VERSION SWITCH_BINARY ASSOCIATION ASSOCIATION_GRP_INFO MULTI_CHANNEL_ASSOCIATION METER MARK SWITCH_MULTILEVEL
2017-03-14 16:01:06 mcCapability_02 ZWAVEPLUS_INFO VERSION SWITCH_BINARY ASSOCIATION ASSOCIATION_GRP_INFO MULTI_CHANNEL_ASSOCIATION METER MARK SWITCH_MULTILEVEL
2017-03-14 16:01:06 mcEndpoints total 2, identical
2017-03-14 16:47:33 mcaGroups 5
2017-03-14 16:47:33 mca_1 Max 1 Nodes ZDongle:1
2017-03-14 16:47:33 mca_2 Max 5
2017-03-14 16:47:33 mca_3 Max 5
2017-03-14 16:47:33 mca_4 Max 5
2017-03-14 16:47:33 mca_5 Max 5
2017-03-14 16:01:06 model FIBARO System FGS223 Double Relay
2017-03-14 16:01:06 modelConfig fibaro/fgs223.xml
2017-03-14 16:01:06 modelId 010f-0203-1000
2017-03-14 16:14:01 neighborList ZDongle
2017-03-14 16:13:49 neighborUpdate done
2017-03-14 16:27:55 state off
2017-03-14 16:47:39 timeToAck 0.027
2017-03-14 16:47:39 transmit OK
secMsg:
Secnonce:
Attributes:
IODev ZDongle
classes ZWAVEPLUS_INFO VERSION MANUFACTURER_SPECIFIC SWITCH_BINARY DEVICE_RESET_LOCALLY ASSOCIATION_GRP_INFO ASSOCIATION POWERLEVEL CRC_16_ENCAP CONFIGURATION METER MULTI_CHANNEL_ASSOCIATION MULTI_CHANNEL APPLICATION_STATUS PROTECTION ALARM SECURITY FIRMWARE_UPDATE_MD CENTRAL_SCENE MARK SWITCH_MULTILEVEL
room ZWave
secure_classes SWITCH_BINARY DEVICE_RESET_LOCALLY ASSOCIATION CONFIGURATION MULTI_CHANNEL_ASSOCIATION MULTI_CHANNEL PROTECTION CENTRAL_SCENE MARK SWITCH_MULTILEVEL
vclasses ALARM:5 APPLICATION_STATUS:1 ASSOCIATION:2 ASSOCIATION_GRP_INFO:1 CENTRAL_SCENE:2 CONFIGURATION:1 CRC_16_ENCAP:1 DEVICE_RESET_LOCALLY:1 FIRMWARE_UPDATE_MD:3 MANUFACTURER_SPECIFIC:2 METER:3 MULTI_CHANNEL:4 MULTI_CHANNEL_ASSOCIATION:3 POWERLEVEL:1 PROTECTION:2 SECURITY:1 SWITCH_BINARY:1 SWITCH_MULTILEVEL:3 VERSION:2 ZWAVEPLUS_INFO:2
Endpoint1
Internals:
DEF cdf6772a 3841
IODev ZDongle
NAME ZWave_10_15.01
NR 123
STATE off
TYPE ZWave
ZWaveSubDevice yes
endpointParent ZWave_SWITCH_BINARY_15
homeId cdf6772a
isWakeUp
nodeIdHex 0f01
CHANGED:
on
reportedState: on
power: 0 W
on
reportedState: on
off
reportedState: off
power: 0 W
on
reportedState: on
power: 0 W
off
reportedState: off
power: 0 W
on
reportedState: on
power: 0 W
on
reportedState: on
off
reportedState: off
power: 0 W
CHANGEDWITHSTATE:
Readings:
2017-03-14 16:27:56 power 0 W
2017-03-14 16:27:56 reportedState off
2017-03-14 16:27:56 state off
Attributes:
IODev ZDongle
classes ZWAVEPLUS_INFO VERSION SWITCH_BINARY ASSOCIATION ASSOCIATION_GRP_INFO MULTI_CHANNEL_ASSOCIATION METER MARK SWITCH_MULTILEVEL
room ZWave
Endpoint2
Internals:
DEF cdf6772a 3842
IODev ZDongle
NAME ZWave_10_15.02
NR 125
STATE off
TYPE ZWave
ZWaveSubDevice yes
endpointParent ZWave_SWITCH_BINARY_15
homeId cdf6772a
nodeIdHex 0f02
Readings:
2017-03-14 16:15:40 state off
Attributes:
IODev ZDongle
classes ZWAVEPLUS_INFO VERSION SWITCH_BINARY ASSOCIATION ASSOCIATION_GRP_INFO MULTI_CHANNEL_ASSOCIATION METER MARK SWITCH_MULTILEVEL
room ZWave
Kann man hier in irgendeiner Weise (z.B. Logs) noch unterstützen? Würde den Switch schon gerne "Secure" einbinden.
Hi,
ja, an Logs wäre ich interessiert!
fhemwiki.de Welche Infos sollten Anfragen im ZWave-Forum enthalten? (http://www.fhemwiki.de/wiki/Z-Wave#Welche_Infos_sollten_Anfragen_im_ZWave-Forum_enthalten.3F) (verbose 5 und mseclog 1 setzen)
Idealerweise einmal unsecure wo es funktioniert, dann secure wo es nicht funktioniert.
Mit den Logs kannst Du Dir aber etwas Zeit lassen, ich werde diese Woche nicht mehr dazu kommen und bin dann 2 Wochen unterwegs...
Verstehen tue ich das aber erst mal nicht, aber die Logs werden sicherlich helfen das zu verstehen.
Gruß,
Andreas.
Hi,
anbei die beiden Logs. Im Insecure Log hat das Gerät nun einen anderen Namen (ZWave_SWITCH_BINARY_16, etc.). Das listing oben passt ja zum Secure Log.
Grüße Andreas
Hi Andreas,
Zitat von: acw81 am 16 März 2017, 10:47:33
anbei die beiden Logs. Im Insecure Log hat das Gerät nun einen anderen Namen (ZWave_SWITCH_BINARY_16, etc.). Das listing oben passt ja zum Secure Log.
danke, habe mir den Thread mal als Lesezeichen gespeichert, bin aber die nächsten 2 Wochen unterwegs und werde erst danach dazu kommen. Am besten "triggerst" Du mich in 2 Wochen noch mal an wenn ich mich nicht melde. Könnte gut sein das mir das ansonsten durchrutscht.
Gruß,
(auch) Andreas.
Hi Andreas,
Zitat von: acw81 am 16 März 2017, 10:47:33
anbei die beiden Logs. Im Insecure Log hat das Gerät nun einen anderen Namen (ZWave_SWITCH_BINARY_16, etc.). Das listing oben passt ja zum Secure Log.
so, habe mal kurz in die Logs reingeschaut...
Tja, die Abfrage ob eine Klasse verschlüsselt werden soll funktioniert anscheinend bei sub-devices nicht. Ich prüfe ob die Klasse im Attribut "secure_classes" drin steht, sub-devices haben dieses Attribut aber nicht, nur das Hauptdevice!
Daher werden die Befehle an die sub-devices unverschlüsselt versendet, was das Gerät richtigerweise ignoriert.
Leider habe ich kein "echtes" Testgeräte mit MULTI_CHANNEL und SECURITY hier, das muss ich mir jetzt erst mit einem Z-Uno "bauen" ;-)
Dann kann ich damit debuggen.
Gruß,
Andreas.
@ Andreas
soll ich dir einen FGS-223 mal schicken zum testen?
LG
Tom
Hi,
Zitat von: tomspatz am 07 April 2017, 10:08:11
soll ich dir einen FGS-223 mal schicken zum testen?
danke, aber das sollte nicht nötig sein. Soweit ich das sehe ist das ein generelles Problem mit sub-devices. Ich habe mir gestern mit dem Z-Uno schon mal ein Geräte "erzeugt" das Security und Multi_Channel hat. Damit kann ich das ausreichend ausprobieren.
Es sollte auch nicht sooo schwierig sein das zu fixen. Ich muss bei der Abfrage erst prüfen ob es sich um ein sub-device handelt und falls ja "irgendwie" das main-device referenzieren. Etwas ähnliches hatte ich schon mal für ein anderes Problem implementiert dann aber wieder gelöscht da Rudi das Problem intern gelöst hat. Daher muss ich mir das jetzt noch mal austüfteln. Denke aber das dies in ein paar Tagen erledigt ist.
Gruß,
Andreas.
Hallo Rudi,
durch diesen Thread hier ist aufgefallen das Security mit sub-devices bisher überhaupt nicht funktioniert hat... :-[
Hintergrund: Ich prüfe eine zu verschickende Nachricht dadurch das ich die Klasse im Attribut "secure_classes" suche. Sub-Devices haben diese Klasse aber gar nicht, wodurch hier immer unverschlüsselt gesendet wurde, was die Geräte richtigerweise ignorieren.
Ich habe in dem Patch jetzt eingebaut das ich im Fall eines sub-device beim parent-device nachschaue.
Zweites Problem ist das der Befehl beim sub-device zwischengespeichert wird, die angeforderte Nonce jedoch beim parent-device ankommt... Dort habe ich es jetzt so angepasst das die Nachricht auch beim parent-device gespeichert wird. Hierzu musste ich auch "secStart" entsprechend umbiegen.
Bitte schau noch mal in den Patch rein, ich suche dort in %defs um das parent-device anhand des Namens zu finden, wahrscheinlich gibt es dafür eine elegantere/schnellere Lösung.
Gruß,
Andreas.
Das Parent-Device ist $defs{$hash->{endpointParent}}, ich habe dein Patch dementsprechend verkuerzt.
Habs eingecheckt, konnte es aber nicht testen.
Hi Rudi,
Zitat von: rudolfkoenig am 09 April 2017, 10:34:14
Das Parent-Device ist $defs{$hash->{endpointParent}}, ich habe dein Patch dementsprechend verkuerzt.
hmm, so einfach... Das man dort direkt mit dem Namen agieren kann war mir nicht klar.
Zitat von: rudolfkoenig am 09 April 2017, 10:34:14
Habs eingecheckt, konnte es aber nicht testen.
Bei mir ist mit dem Testen auch knapp, ich muss gleich weg, evtl. schaffe ich das heute abend noch.
Danke,
Andreas.
Hi Rudi,
hab' es doch noch geschafft das kurz zu testen. Läuft!
Danke,
Andreas.
Hi TomSpatz, hi Andreas!
Habt Ihr das mit einem aktualisierten FHEM bei euch mal ausprobiert ob es jetzt geht? Ich gehe zwar davon aus das es jetzt funktioniert, eine positive RM würde mir aber helfen Nachts wieder besser zu schlafen ;D
Gruß,
Andreas.
Sorry aber bislang habe ich noch nichts mit Security eingebunden.
LG
Tom
Sorry, für die späte Antwort aber der Switch ist bei mir nicht gerade leicht zu erreichen ;)
Auf den ersten Blick scheint aber nun alles "SECURE" zu funktionieren 8)
Falls ich noch etwas entdecken sollte melde ich mich wieder hier.
Danke und Gruß
Andreas
Hi,
kein Problem, vor allem nicht wenn es jetzt zu funktionieren scheint! ;-)
Gruß,
Andreas.
Ein Problem habe ich nun leider doch festgestellt und zwar das die Events von den Schaltzuständen nicht sauber kommen. Ich weiß aber nicht ob das nun mit der Umstellung auf "SECURE" zu tun hat.
Ich schalte in folgendem Beispiel die Wandbeleuchtung im Esszimmer ein, welche sich aber auf Grund der Helligkeit gleich wieder ausschaltet.
Im listing sind die Endzustände der Readings für state und reportedState soweit korrekt
Internals:
DEF cdf6772a 4353
IODev ZDongle
NAME ez_Wandleuchten
NR 152
STATE off
TYPE ZWave
ZWaveSubDevice yes
endpointParent hwr_MasterSchalter
homeId cdf6772a
isWakeUp
nodeIdHex 1101
CHANGED:
off
reportedState: off
power: 0.8 W
CHANGEDWITHSTATE:
Readings:
2017-04-18 13:08:51 energy 3.16 kWh
2017-04-18 14:07:58 power 0.8 W
2017-04-18 14:07:58 reportedState off
2017-04-18 14:07:58 state off
Helper:
Bm:
Zwave_get:
cnt 2
dmx 0
mAr
max 0
tot 0
Zwave_set:
cnt 16
dmx 0
max 3
tot 11
mAr:
HASH(0x3ee9348)
ez_Wandleuchten
on
Attributes:
IODev ZDongle
classes ZWAVEPLUS_INFO VERSION SWITCH_BINARY ASSOCIATION ASSOCIATION_GRP_INFO MULTI_CHANNEL_ASSOCIATION METER MARK SWITCH_MULTILEVEL
room Esszimmer
im Event Monitor fehlt aber das reportedState event
2017-04-18 14:07:57.036 ZWave ez_Wandleuchten on
2017-04-18 14:07:57.036 ZWave ez_Wandleuchten reportedState: on
2017-04-18 14:07:57.036 ZWave ez_Wandleuchten power: 24 W
2017-04-18 14:07:57.051 ZWave ez_Wandleuchten off
Schalte ich die Wandbeleuchtung nochmals an, kommen die entsprechenden "Off" Events im Event Monitor.
Also hier nochmal ausführliche Logs und Listings zu dem oben angesprochenen Verhalten. Ich diesem Szenario habe ich ez_Wandleuchten um 9:45:55 Uhr ausgeschaltet und um 9:47:42 Uhr wieder eingeschaltet.
Event Monitor
2017-04-21 09:45:55.791 ZWave ez_Wandleuchten on
2017-04-21 09:45:55.791 ZWave ez_Wandleuchten reportedState: on
2017-04-21 09:45:55.791 ZWave ez_Wandleuchten power: 24 W
2017-04-21 09:47:42.775 ZWave ez_Wandleuchten off
2017-04-21 09:47:42.775 ZWave ez_Wandleuchten reportedState: off
2017-04-21 09:47:42.775 ZWave ez_Wandleuchten power: 0.8 W
Listing nach dem Ausschalten
Internals:
DEF cdf6772a 4353
IODev ZDongle
NAME ez_Wandleuchten
NR 152
STATE off
TYPE ZWave
ZWaveSubDevice yes
endpointParent hwr_MasterSchalter
homeId cdf6772a
isWakeUp
nodeIdHex 1101
CHANGED:
off
reportedState: off
power: 0.8 W
CHANGEDWITHSTATE:
Readings:
2017-04-21 09:08:51 energy 3.58 kWh
2017-04-21 09:45:56 power 0.8 W
2017-04-21 09:45:56 reportedState off
2017-04-21 09:45:56 state off
Attributes:
IODev ZDongle
classes ZWAVEPLUS_INFO VERSION SWITCH_BINARY ASSOCIATION ASSOCIATION_GRP_INFO MULTI_CHANNEL_ASSOCIATION METER MARK SWITCH_MULTILEVEL
room Esszimmer
verbose 5
Listing nach dem Einschalten
Internals:
DEF cdf6772a 4353
IODev ZDongle
NAME ez_Wandleuchten
NR 152
STATE on
TYPE ZWave
ZWaveSubDevice yes
endpointParent hwr_MasterSchalter
homeId cdf6772a
isWakeUp
nodeIdHex 1101
CHANGED:
on
reportedState: on
power: 24 W
CHANGEDWITHSTATE:
Readings:
2017-04-21 09:08:51 energy 3.58 kWh
2017-04-21 09:47:45 power 24 W
2017-04-21 09:47:43 reportedState on
2017-04-21 09:47:43 state on
Attributes:
IODev ZDongle
classes ZWAVEPLUS_INFO VERSION SWITCH_BINARY ASSOCIATION ASSOCIATION_GRP_INFO MULTI_CHANNEL_ASSOCIATION METER MARK SWITCH_MULTILEVEL
room Esszimmer
verbose 5
Logfile ZWave Dongle
2017.04.21 09:45:55.783 3: ZWave set ez_Wandleuchten off
2017.04.21 09:45:55.784 5: ez_Wandleuchten: MULTI_CHANNEL is a secured class!
2017.04.21 09:45:55.784 5: ez_Wandleuchten SECURITY: 600d0001250100 stored for encryption
2017.04.21 09:45:55.784 5: ZWDongle_Write 0013110298402518 (cdf6772a)
2017.04.21 09:45:55.785 5: SW: 0109001311029840251813
2017.04.21 09:45:55.798 5: ACK received, WaitForAck=>2 for 0109001311029840251813
2017.04.21 09:45:55.798 4: ZWDongle_Read ZDongle: rcvd 011301 (answer ZW_SEND_DATA), sending ACK
2017.04.21 09:45:55.798 5: SW: 06
2017.04.21 09:45:55.800 5: ZDongle: dispatch 011301
2017.04.21 09:45:55.809 4: ZWDongle_Read ZDongle: rcvd 001318000002 (request ZW_SEND_DATA), sending ACK
2017.04.21 09:45:55.810 5: SW: 06
2017.04.21 09:45:55.811 5: device ack reveived, removing 0109001311029840251813 from dongle sendstack
2017.04.21 09:45:55.811 5: ZDongle: dispatch 001318000002
2017.04.21 09:45:55.812 4: CMD:ZW_SEND_DATA ID:00 ARG:0002 CB:18
2017.04.21 09:45:55.812 4: ZDongle transmit OK for CB 18, target hwr_MasterSchalter
2017.04.21 09:45:55.823 4: ZWDongle_Read ZDongle: rcvd 000400110a98805a46fcb38a028b47 (request APPLICATION_COMMAND_HANDLER), sending ACK
2017.04.21 09:45:55.823 5: SW: 06
2017.04.21 09:45:55.824 5: ZDongle: dispatch 000400110a98805a46fcb38a028b47
2017.04.21 09:45:55.825 4: CMD:APPLICATION_COMMAND_HANDLER ID:11 ARG:0a98805a46fcb38a028b47 CB:00
2017.04.21 09:45:55.825 5: hwr_MasterSchalter SECURITY: 600d0001250100 set ez_Wandleuchten off retrieved for encryption
2017.04.21 09:45:55.826 5: hwr_MasterSchalter: secEncrypt plain:00600d0001250100 enc:93466017ce88b295
2017.04.21 09:45:55.826 5: ZWDongle_Write 0013111b9881d1c1750aca16757793466017ce88b2955a1e6d0daf997fa74a2519 (cdf6772a)
2017.04.21 09:45:55.827 5: SW: 01220013111b9881d1c1750aca16757793466017ce88b2955a1e6d0daf997fa74a251913
2017.04.21 09:45:55.828 5: hwr_MasterSchalter: type=set, cmd=off (600d0001250100 set ez_Wandleuchten off)
2017.04.21 09:45:55.830 5: ACK received, WaitForAck=>2 for 01220013111b9881d1c1750aca16757793466017ce88b2955a1e6d0daf997fa74a251913
2017.04.21 09:45:55.838 4: ZWDongle_Read ZDongle: rcvd 011301 (answer ZW_SEND_DATA), sending ACK
2017.04.21 09:45:55.838 5: SW: 06
2017.04.21 09:45:55.839 5: ZDongle: dispatch 011301
2017.04.21 09:45:55.855 4: ZWDongle_Read ZDongle: rcvd 001319000002 (request ZW_SEND_DATA), sending ACK
2017.04.21 09:45:55.856 5: SW: 06
2017.04.21 09:45:55.857 5: device ack reveived, removing 01220013111b9881d1c1750aca16757793466017ce88b2955a1e6d0daf997fa74a251913 from dongle sendstack
2017.04.21 09:45:55.857 5: ZDongle: dispatch 001319000002
2017.04.21 09:45:55.858 4: CMD:ZW_SEND_DATA ID:00 ARG:0002 CB:19
2017.04.21 09:45:55.858 4: ZDongle transmit OK for CB 19, target hwr_MasterSchalter
2017.04.21 09:45:55.952 4: ZWDongle_Read ZDongle: rcvd 00040011029840 (request APPLICATION_COMMAND_HANDLER), sending ACK
2017.04.21 09:45:55.952 5: SW: 06
2017.04.21 09:45:55.954 5: ZDongle: dispatch 00040011029840
2017.04.21 09:45:55.954 4: CMD:APPLICATION_COMMAND_HANDLER ID:11 ARG:029840 CB:00
2017.04.21 09:45:55.955 5: ZWDongle_Write 0013110a988017e3d480a63a0f7f251a (cdf6772a)
2017.04.21 09:45:55.955 5: SW: 01110013110a988017e3d480a63a0f7f251a8d
2017.04.21 09:45:55.958 5: ACK received, WaitForAck=>2 for 01110013110a988017e3d480a63a0f7f251a8d
2017.04.21 09:45:55.965 4: ZWDongle_Read ZDongle: rcvd 011301 (answer ZW_SEND_DATA), sending ACK
2017.04.21 09:45:55.965 5: SW: 06
2017.04.21 09:45:55.966 5: ZDongle: dispatch 011301
2017.04.21 09:45:55.981 4: ZWDongle_Read ZDongle: rcvd 00131a000002 (request ZW_SEND_DATA), sending ACK
2017.04.21 09:45:55.981 5: SW: 06
2017.04.21 09:45:55.982 5: device ack reveived, removing 01110013110a988017e3d480a63a0f7f251a8d from dongle sendstack
2017.04.21 09:45:55.983 5: ZDongle: dispatch 00131a000002
2017.04.21 09:45:55.983 4: CMD:ZW_SEND_DATA ID:00 ARG:0002 CB:1a
2017.04.21 09:45:55.983 4: ZDongle transmit OK for CB 1a, target hwr_MasterSchalter
2017.04.21 09:45:56.001 4: ZWDongle_Read ZDongle: rcvd 000400111b9881b1a8bcd76446f8926957a2f35c6dd8dc173d6062caefdaf418 (request APPLICATION_COMMAND_HANDLER), sending ACK
2017.04.21 09:45:56.001 5: SW: 06
2017.04.21 09:45:56.002 5: ZDongle: dispatch 000400111b9881b1a8bcd76446f8926957a2f35c6dd8dc173d6062caefdaf418
2017.04.21 09:45:56.003 4: CMD:APPLICATION_COMMAND_HANDLER ID:11 ARG:1b9881b1a8bcd76446f8926957a2f35c6dd8dc173d6062caefdaf418 CB:00
2017.04.21 09:45:56.004 5: hwr_MasterSchalter: secDecrypt: send_nonce 17e3d480a63a0f7f with nonce_id 17 retrieved
2017.04.21 09:45:56.004 5: hwr_MasterSchalter: secDecrypt: decrypted cmd 00600d0101250300
2017.04.21 09:45:56.004 5: hwr_MasterSchalter: secDecrypt: Sequencebyte 0, sequenced 0, secondFrame 0, sequenceCounter 00
2017.04.21 09:45:56.004 5: hwr_MasterSchalter: secDecrypt: calculated Authentication code 3d6062caefdaf418
2017.04.21 09:45:56.004 5: hwr_MasterSchalter: secDecrypt: parsing 0004001107600d0101250300
2017.04.21 09:45:56.004 4: CMD:APPLICATION_COMMAND_HANDLER ID:11 ARG:07600d0101250300 CB:00
2017.04.21 09:45:56.853 4: ZWDongle_Read ZDongle: rcvd 00040011029840 (request APPLICATION_COMMAND_HANDLER), sending ACK
2017.04.21 09:45:56.853 5: SW: 06
2017.04.21 09:45:56.854 5: ZDongle: dispatch 00040011029840
2017.04.21 09:45:56.855 4: CMD:APPLICATION_COMMAND_HANDLER ID:11 ARG:029840 CB:00
2017.04.21 09:45:56.856 5: ZWDongle_Write 0013110a98808438a06c5b438398251b (cdf6772a)
2017.04.21 09:45:56.856 5: SW: 01110013110a98808438a06c5b438398251bb3
2017.04.21 09:45:56.859 5: ACK received, WaitForAck=>2 for 01110013110a98808438a06c5b438398251bb3
2017.04.21 09:45:56.865 4: ZWDongle_Read ZDongle: rcvd 011301 (answer ZW_SEND_DATA), sending ACK
2017.04.21 09:45:56.865 5: SW: 06
2017.04.21 09:45:56.867 5: ZDongle: dispatch 011301
2017.04.21 09:45:56.882 4: ZWDongle_Read ZDongle: rcvd 00131b000002 (request ZW_SEND_DATA), sending ACK
2017.04.21 09:45:56.882 5: SW: 06
2017.04.21 09:45:56.883 5: device ack reveived, removing 01110013110a98808438a06c5b438398251bb3 from dongle sendstack
2017.04.21 09:45:56.884 5: ZDongle: dispatch 00131b000002
2017.04.21 09:45:56.884 4: CMD:ZW_SEND_DATA ID:00 ARG:0002 CB:1b
2017.04.21 09:45:56.884 4: ZDongle transmit OK for CB 1b, target hwr_MasterSchalter
2017.04.21 09:45:56.903 4: ZWDongle_Read ZDongle: rcvd 000400112098812b7ab0ea39244bad8945366c763776c847523ef5c384d2b0bb7e75cbc4e2 (request APPLICATION_COMMAND_HANDLER), sending ACK
2017.04.21 09:45:56.903 5: SW: 06
2017.04.21 09:45:56.906 5: ZDongle: dispatch 000400112098812b7ab0ea39244bad8945366c763776c847523ef5c384d2b0bb7e75cbc4e2
2017.04.21 09:45:56.906 4: CMD:APPLICATION_COMMAND_HANDLER ID:11 ARG:2098812b7ab0ea39244bad8945366c763776c847523ef5c384d2b0bb7e75cbc4e2 CB:00
2017.04.21 09:45:56.907 5: hwr_MasterSchalter: secDecrypt: send_nonce 8438a06c5b438398 with nonce_id 84 retrieved
2017.04.21 09:45:56.907 5: hwr_MasterSchalter: secDecrypt: decrypted cmd 00600d01013202213200080000
2017.04.21 09:45:56.908 5: hwr_MasterSchalter: secDecrypt: Sequencebyte 0, sequenced 0, secondFrame 0, sequenceCounter 00
2017.04.21 09:45:56.908 5: hwr_MasterSchalter: secDecrypt: calculated Authentication code d2b0bb7e75cbc4e2
2017.04.21 09:45:56.908 5: hwr_MasterSchalter: secDecrypt: parsing 000400110c600d01013202213200080000
2017.04.21 09:45:56.908 4: CMD:APPLICATION_COMMAND_HANDLER ID:11 ARG:0c600d01013202213200080000 CB:00
2017.04.21 09:47:42.765 3: ZWave set ez_Wandleuchten on
2017.04.21 09:47:42.765 5: ez_Wandleuchten: MULTI_CHANNEL is a secured class!
2017.04.21 09:47:42.766 5: ez_Wandleuchten SECURITY: 600d00012501FF stored for encryption
2017.04.21 09:47:42.766 5: ZWDongle_Write 001311029840251d (cdf6772a)
2017.04.21 09:47:42.767 5: SW: 0109001311029840251d16
2017.04.21 09:47:42.783 5: ACK received, WaitForAck=>2 for 0109001311029840251d16
2017.04.21 09:47:42.784 4: ZWDongle_Read ZDongle: rcvd 011301 (answer ZW_SEND_DATA), sending ACK
2017.04.21 09:47:42.784 5: SW: 06
2017.04.21 09:47:42.786 5: ZDongle: dispatch 011301
2017.04.21 09:47:43.027 4: ZWDongle_Read ZDongle: rcvd 00131d000002 (request ZW_SEND_DATA), sending ACK
2017.04.21 09:47:43.028 5: SW: 06
2017.04.21 09:47:43.029 5: device ack reveived, removing 0109001311029840251d16 from dongle sendstack
2017.04.21 09:47:43.029 5: ZDongle: dispatch 00131d000002
2017.04.21 09:47:43.030 4: CMD:ZW_SEND_DATA ID:00 ARG:0002 CB:1d
2017.04.21 09:47:43.030 4: ZDongle transmit OK for CB 1d, target hwr_MasterSchalter
2017.04.21 09:47:43.033 4: ZWDongle_Read ZDongle: rcvd 000400110a9880cbd80c56b8736336 (request APPLICATION_COMMAND_HANDLER), sending ACK
2017.04.21 09:47:43.033 5: SW: 06
2017.04.21 09:47:43.035 5: ZDongle: dispatch 000400110a9880cbd80c56b8736336
2017.04.21 09:47:43.035 4: CMD:APPLICATION_COMMAND_HANDLER ID:11 ARG:0a9880cbd80c56b8736336 CB:00
2017.04.21 09:47:43.036 5: hwr_MasterSchalter SECURITY: 600d00012501FF set ez_Wandleuchten on retrieved for encryption
2017.04.21 09:47:43.036 5: hwr_MasterSchalter: secEncrypt plain:00600d00012501FF enc:58539a2c084e57b0
2017.04.21 09:47:43.037 5: ZWDongle_Write 0013111b988145bd9ba87446cb3958539a2c084e57b0cb7003fa46650e0f13251e (cdf6772a)
2017.04.21 09:47:43.037 5: SW: 01220013111b988145bd9ba87446cb3958539a2c084e57b0cb7003fa46650e0f13251e82
2017.04.21 09:47:43.039 5: hwr_MasterSchalter: type=set, cmd=on (600d00012501FF set ez_Wandleuchten on)
2017.04.21 09:47:43.041 5: ACK received, WaitForAck=>2 for 01220013111b988145bd9ba87446cb3958539a2c084e57b0cb7003fa46650e0f13251e82
2017.04.21 09:47:43.297 4: ZWDongle_Read ZDongle: rcvd 011301 (answer ZW_SEND_DATA), sending ACK
2017.04.21 09:47:43.297 5: SW: 06
2017.04.21 09:47:43.299 5: ZDongle: dispatch 011301
2017.04.21 09:47:43.301 4: ZWDongle_Read ZDongle: rcvd 00131e000003 (request ZW_SEND_DATA), sending ACK
2017.04.21 09:47:43.301 5: SW: 06
2017.04.21 09:47:43.303 5: device ack reveived, removing 01220013111b988145bd9ba87446cb3958539a2c084e57b0cb7003fa46650e0f13251e82 from dongle sendstack
2017.04.21 09:47:43.303 5: ZDongle: dispatch 00131e000003
2017.04.21 09:47:43.304 4: CMD:ZW_SEND_DATA ID:00 ARG:0003 CB:1e
2017.04.21 09:47:43.304 4: ZDongle transmit OK for CB 1e, target hwr_MasterSchalter
2017.04.21 09:47:43.306 4: ZWDongle_Read ZDongle: rcvd 00040011029840 (request APPLICATION_COMMAND_HANDLER), sending ACK
2017.04.21 09:47:43.306 5: SW: 06
2017.04.21 09:47:43.308 5: ZDongle: dispatch 00040011029840
2017.04.21 09:47:43.308 4: CMD:APPLICATION_COMMAND_HANDLER ID:11 ARG:029840 CB:00
2017.04.21 09:47:43.309 5: ZWDongle_Write 0013110a988052cef061fca651d3251f (cdf6772a)
2017.04.21 09:47:43.310 5: SW: 01110013110a988052cef061fca651d3251f11
2017.04.21 09:47:43.313 5: ACK received, WaitForAck=>2 for 01110013110a988052cef061fca651d3251f11
2017.04.21 09:47:43.320 4: ZWDongle_Read ZDongle: rcvd 011301 (answer ZW_SEND_DATA), sending ACK
2017.04.21 09:47:43.321 5: SW: 06
2017.04.21 09:47:43.322 5: ZDongle: dispatch 011301
2017.04.21 09:47:43.559 4: ZWDongle_Read ZDongle: rcvd 00131f000002 (request ZW_SEND_DATA), sending ACK
2017.04.21 09:47:43.560 5: SW: 06
2017.04.21 09:47:43.561 5: device ack reveived, removing 01110013110a988052cef061fca651d3251f11 from dongle sendstack
2017.04.21 09:47:43.561 5: ZDongle: dispatch 00131f000002
2017.04.21 09:47:43.562 4: CMD:ZW_SEND_DATA ID:00 ARG:0002 CB:1f
2017.04.21 09:47:43.562 4: ZDongle transmit OK for CB 1f, target hwr_MasterSchalter
2017.04.21 09:47:43.565 4: ZWDongle_Read ZDongle: rcvd 000400111b98814b24423f7e6cef7204da77daa516944c52867161c75bbc5dda (request APPLICATION_COMMAND_HANDLER), sending ACK
2017.04.21 09:47:43.565 5: SW: 06
2017.04.21 09:47:43.567 5: ZDongle: dispatch 000400111b98814b24423f7e6cef7204da77daa516944c52867161c75bbc5dda
2017.04.21 09:47:43.567 4: CMD:APPLICATION_COMMAND_HANDLER ID:11 ARG:1b98814b24423f7e6cef7204da77daa516944c52867161c75bbc5dda CB:00
2017.04.21 09:47:43.568 5: hwr_MasterSchalter: secDecrypt: send_nonce 52cef061fca651d3 with nonce_id 52 retrieved
2017.04.21 09:47:43.568 5: hwr_MasterSchalter: secDecrypt: decrypted cmd 00600d01012503ff
2017.04.21 09:47:43.568 5: hwr_MasterSchalter: secDecrypt: Sequencebyte 0, sequenced 0, secondFrame 0, sequenceCounter 00
2017.04.21 09:47:43.569 5: hwr_MasterSchalter: secDecrypt: calculated Authentication code 867161c75bbc5dda
2017.04.21 09:47:43.569 5: hwr_MasterSchalter: secDecrypt: parsing 0004001107600d01012503ff
2017.04.21 09:47:43.569 4: CMD:APPLICATION_COMMAND_HANDLER ID:11 ARG:07600d01012503ff CB:00
2017.04.21 09:47:45.853 4: ZWDongle_Read ZDongle: rcvd 00040011029840 (request APPLICATION_COMMAND_HANDLER), sending ACK
2017.04.21 09:47:45.853 5: SW: 06
2017.04.21 09:47:45.855 5: ZDongle: dispatch 00040011029840
2017.04.21 09:47:45.855 4: CMD:APPLICATION_COMMAND_HANDLER ID:11 ARG:029840 CB:00
2017.04.21 09:47:45.856 5: ZWDongle_Write 0013110a98800ba38e790982680f2520 (cdf6772a)
2017.04.21 09:47:45.857 5: SW: 01110013110a98800ba38e790982680f252048
2017.04.21 09:47:45.860 5: ACK received, WaitForAck=>2 for 01110013110a98800ba38e790982680f252048
2017.04.21 09:47:45.866 4: ZWDongle_Read ZDongle: rcvd 011301 (answer ZW_SEND_DATA), sending ACK
2017.04.21 09:47:45.866 5: SW: 06
2017.04.21 09:47:45.868 5: ZDongle: dispatch 011301
2017.04.21 09:47:45.882 4: ZWDongle_Read ZDongle: rcvd 001320000002 (request ZW_SEND_DATA), sending ACK
2017.04.21 09:47:45.882 5: SW: 06
2017.04.21 09:47:45.884 5: device ack reveived, removing 01110013110a98800ba38e790982680f252048 from dongle sendstack
2017.04.21 09:47:45.884 5: ZDongle: dispatch 001320000002
2017.04.21 09:47:45.884 4: CMD:ZW_SEND_DATA ID:00 ARG:0002 CB:20
2017.04.21 09:47:45.885 4: ZDongle transmit OK for CB 20, target hwr_MasterSchalter
2017.04.21 09:47:45.905 4: ZWDongle_Read ZDongle: rcvd 00040011209881c79cf7fa7764df5098725ac9938a4e92b6eac938e90b5cfbba5561a1eaab (request APPLICATION_COMMAND_HANDLER), sending ACK
2017.04.21 09:47:45.905 5: SW: 06
2017.04.21 09:47:45.906 5: ZDongle: dispatch 00040011209881c79cf7fa7764df5098725ac9938a4e92b6eac938e90b5cfbba5561a1eaab
2017.04.21 09:47:45.907 4: CMD:APPLICATION_COMMAND_HANDLER ID:11 ARG:209881c79cf7fa7764df5098725ac9938a4e92b6eac938e90b5cfbba5561a1eaab CB:00
2017.04.21 09:47:45.908 5: hwr_MasterSchalter: secDecrypt: send_nonce 0ba38e790982680f with nonce_id 0b retrieved
2017.04.21 09:47:45.908 5: hwr_MasterSchalter: secDecrypt: decrypted cmd 00600d01013202213200f00000
2017.04.21 09:47:45.908 5: hwr_MasterSchalter: secDecrypt: Sequencebyte 0, sequenced 0, secondFrame 0, sequenceCounter 00
2017.04.21 09:47:45.908 5: hwr_MasterSchalter: secDecrypt: calculated Authentication code 5cfbba5561a1eaab
2017.04.21 09:47:45.908 5: hwr_MasterSchalter: secDecrypt: parsing 000400110c600d01013202213200f00000
2017.04.21 09:47:45.909 4: CMD:APPLICATION_COMMAND_HANDLER ID:11 ARG:0c600d01013202213200f00000 CB:00
LogFile Wandleuchten
2017-04-21_09:45:55.787 ez_Wandleuchten on
2017-04-21_09:45:55.787 ez_Wandleuchten reportedState: on
2017-04-21_09:45:55.787 ez_Wandleuchten power: 24 W
2017-04-21_09:47:42.769 ez_Wandleuchten off
2017-04-21_09:47:42.769 ez_Wandleuchten reportedState: off
2017-04-21_09:47:42.769 ez_Wandleuchten power: 0.8 W