Implementierung der ZWAVE Command Class SECURITY (0x98, AES Verschlüsselung)

[Buwe]

Ich hoffe, dass ist hier richtig:
Seit dem Update am 5.01.2016 (10_ZWave.pm) wird mir das Log mit diesen Meldungen "geflutet":

Code Auswählen Erweitern

secUnlock will call Zwave_secEnd

Von den 8 Philio/Devolo/D-Link Kontakten sind "historisch" nur zwei mit Security inkludiert. Die Meldungen kommen nur von diesen beiden und immer nur dann wenn der jeweilige Sensor Status-Meldungen (Auf/Zu/Temperatur/etc) sendet. Fehlfunktionen kann ich bisher keine erkennen.

Edith: 10:32:01 war das Schließen des Fensters. 10:32.08 war der stündliche Status Report von Temperatur/Luminance. Das war Zufall.
Wenn ich das globale Log mit dem jeweiligen Filelog vergleiche, scheint die o.g. Meldung immer mit sieben Sekunden Verzögerung zu kommen.

Log (Fenster wieder geschlossen):

Code Auswählen Erweitern


2016.01.07 10:32:01.496 4: ZWDongle_Read zw.dongle: sending ACK, processing 00040005029840
2016.01.07 10:32:01.497 5: SW: 06
2016.01.07 10:32:01.499 5: zw.dongle dispatch 00040005029840
2016.01.07 10:32:01.500 4: zw.dongle CMD:APPLICATION_COMMAND_HANDLER ID:05 ARG:029840
2016.01.07 10:32:01.506 5: ZWDongle_Write 0013050a98801ac1286b45b809cb2505 (e58b19ca)
2016.01.07 10:32:01.507 5: SW: 01110013050a98801ac1286b45b809cb25056d
2016.01.07 10:32:01.512 5: ACK received, WaitForAck=>2 for 01110013050a98801ac1286b45b809cb25056d
2016.01.07 10:32:01.517 4: ZWDongle_Read zw.dongle: sending ACK, processing 011301
2016.01.07 10:32:01.518 5: SW: 06
2016.01.07 10:32:01.520 5: zw.dongle dispatch 011301
2016.01.07 10:32:01.540 4: ZWDongle_Read zw.dongle: sending ACK, processing 001305000003
2016.01.07 10:32:01.541 5: SW: 06
2016.01.07 10:32:01.542 5: device ack reveived, removing 01110013050a98801ac1286b45b809cb25056d from dongle sendstack
2016.01.07 10:32:01.543 5: zw.dongle dispatch 001305000003
2016.01.07 10:32:01.544 4: zw.dongle CMD:ZW_SEND_DATA ID:00 ARG:0003
2016.01.07 10:32:01.544 4: zw.dongle transmit OK for 05
2016.01.07 10:32:01.582 4: ZWDongle_Read zw.dongle: sending ACK, processing 000400052d988164838b4ecc47394510eda224416cff215b12bda50ea37ff37b84443f2331b616cf681a1b5a5d5da020c3e9
2016.01.07 10:32:01.583 5: SW: 06
2016.01.07 10:32:01.585 5: zw.dongle dispatch 000400052d988164838b4ecc47394510eda224416cff215b12bda50ea37ff37b84443f2331b616cf681a1b5a5d5da020c3e9
2016.01.07 10:32:01.586 4: zw.dongle CMD:APPLICATION_COMMAND_HANDLER ID:05 ARG:2d988164838b4ecc47394510eda224416cff215b12bda50ea37ff37b84443f2331b616cf681a1b5a5d5da020c3e9
2016.01.07 10:32:01.589 4: zw.dongle CMD:APPLICATION_COMMAND_HANDLER ID:05 ARG:198f010403800364043003000a05310503011206310501220096
2016.01.07 10:32:08.510 3: secUnlock will call Zwave_secEnd
2016.01.07 10:32:08.692 4: ZWDongle_Read zw.dongle: sending ACK, processing 00040005029840
2016.01.07 10:32:08.692 5: SW: 06
2016.01.07 10:32:08.694 5: zw.dongle dispatch 00040005029840
2016.01.07 10:32:08.695 4: zw.dongle CMD:APPLICATION_COMMAND_HANDLER ID:05 ARG:029840
2016.01.07 10:32:08.701 5: ZWDongle_Write 0013050a9880e6bc2cd823a42d9f2505 (e58b19ca)
2016.01.07 10:32:08.702 5: SW: 01110013050a9880e6bc2cd823a42d9f250551
2016.01.07 10:32:08.706 5: ACK received, WaitForAck=>2 for 01110013050a9880e6bc2cd823a42d9f250551
2016.01.07 10:32:08.712 4: ZWDongle_Read zw.dongle: sending ACK, processing 011301
2016.01.07 10:32:08.712 5: SW: 06
2016.01.07 10:32:08.714 5: zw.dongle dispatch 011301
2016.01.07 10:32:08.733 4: ZWDongle_Read zw.dongle: sending ACK, processing 001305000003
2016.01.07 10:32:08.734 5: SW: 06
2016.01.07 10:32:08.736 5: device ack reveived, removing 01110013050a9880e6bc2cd823a42d9f250551 from dongle sendstack
2016.01.07 10:32:08.736 5: zw.dongle dispatch 001305000003
2016.01.07 10:32:08.737 4: zw.dongle CMD:ZW_SEND_DATA ID:00 ARG:0003
2016.01.07 10:32:08.737 4: zw.dongle transmit OK for 05
2016.01.07 10:32:08.761 4: ZWDongle_Read zw.dongle: sending ACK, processing 000400052498813d75f0362f7b548ac8ade47ec8f5cbe93ff644bf33fd9d753de6c02c9389d213afbe
2016.01.07 10:32:08.762 5: SW: 06
2016.01.07 10:32:08.764 5: zw.dongle dispatch 000400052498813d75f0362f7b548ac8ade47ec8f5cbe93ff644bf33fd9d753de6c02c9389d213afbe
2016.01.07 10:32:08.764 4: zw.dongle CMD:APPLICATION_COMMAND_HANDLER ID:05 ARG:2498813d75f0362f7b548ac8ade47ec8f5cbe93ff644bf33fd9d753de6c02c9389d213afbe
2016.01.07 10:32:08.767 4: zw.dongle CMD:APPLICATION_COMMAND_HANDLER ID:05 ARG:108f010205310503011c06310501220096
2016.01.07 10:32:15.705 3: secUnlock will call Zwave_secEnd


Log Sensor:

Code Auswählen Erweitern


2016-01-07_10:32:01 eg.wc.window_open battery: 100 %
2016-01-07_10:32:01 eg.wc.window_open doorWindow: Zu
2016-01-07_10:32:01 eg.wc.window_open luminance: 18 %
2016-01-07_10:32:01 eg.wc.window_open temperature: 15.0 C
2016-01-07_10:32:08 eg.wc.window_open luminance: 28 %
2016-01-07_10:32:08 eg.wc.window_open temperature: 15.0 C


List Sensor:

Code Auswählen Erweitern


Internals:
   DEF        e58b19ca 5
   IODev      zw.dongle
   LASTInputDev zw.dongle
   MSGCNT     4
   NAME       eg.wc.window_open
   NR         77
   STATE      Zu
   TYPE       ZWave
   homeId     e58b19ca
   isWakeUp   1
   lastMsgSent 1452159128.70422
   nodeIdHex  05
   secTime    1452159128.69713
   zw.dongle_MSGCNT 4
   zw.dongle_RAWMSG 000400052498813d75f0362f7b548ac8ade47ec8f5cbe93ff644bf33fd9d753de6c02c9389d213afbe
   zw.dongle_TIME 2016-01-07 10:32:08
   Readings:
     2015-10-20 12:17:40   SECURITY        ENABLED
     2015-10-20 12:19:48   assocGroup_01   Max 08 Nodes 01
     2015-10-20 12:19:49   assocGroup_02   Max 08 Nodes
     2015-10-20 12:19:47   assocGroups     2
     2016-01-07 10:32:01   battery         100 %
     2015-10-20 12:28:25   configAutoReportIlluminationTime 2
     2015-10-20 12:27:16   configAutoReportTemperatureTime 2
     2015-10-20 12:20:43   configTurnOffLightTime 4
     2016-01-07 10:32:01   doorWindow      00
     2016-01-07 10:32:08   luminance       28 %
     2015-10-20 12:25:28   model           devolo Door/Window Contact MT02648
     2015-10-20 12:25:28   modelConfig     philio/pst02-1c.xml
     2015-10-20 12:25:28   modelId         0175-0002-000e
     2015-10-20 12:28:24   received_nonce  cfbec5c6e77fa1d5
     2015-12-23 18:44:27   state           TRANSMIT_NO_ACK
     2015-10-20 12:56:43   tamper          ff
     2016-01-07 10:32:08   temperature     15.0 C
     2016-01-07 10:32:08   transmit        OK
     2016-01-07 08:10:24   wakeup          notification
     2015-10-20 12:23:26   wakeupReport    interval 21600 target 1
Attributes:
   IODev      zw.dongle
   alarmDevice Sensor
   alarmSettings alarm4,|eg.wc.window_open:.*Auf|Fenster Gäste WC|on
   alias      Fenster Gäste-WC
   classes    ZWAVEPLUS_INFO BATTERY ALARM ASSOCIATION CONFIGURATION MANUFACTURER_SPECIFIC VERSION SENSOR_BINARY SENSOR_MULTILEVEL WAKE_UP ASSOCIATION_GRP_INFO POWERLEVEL DEVICE_RESET_LOCALLY MULTI_CMD SECURITY FIRMWARE_UPDATE_MD MARK BASIC
   devStateIcon .*Zu:fts_window_1w@green .*Auf:fts_window_1w_open@red
   eventMap   00:Zu ff:Auf
   group      Türen/Fenster
   icon       control_building_eg
   room       Status
   secure_classes BATTERY ALARM ASSOCIATION CONFIGURATION SENSOR_BINARY SENSOR_MULTILEVEL WAKE_UP MARK
   sortby     22
   stateFormat doorWindow


List Dongle:

Code Auswählen Erweitern


Internals:
   CallbackNr 0
   Clients    :ZWave:
   DEF        /dev/ttyACM0@115200
   DeviceName /dev/ttyACM0@115200
   FD         10
   MaxSendRetries 3
   NAME       zw.dongle
   NR         20
   PARTIAL
   RAWMSG     00040007198f010403800364043003ff0c053105030113063105012200be
   ReadTime   1452159433.1713
   STATE      Initialized
   SendRetries 0
   SendTime   1452159275.69238
   TYPE       ZWDongle
   WaitForAck 0
   homeId     e58b19ca
   nodeIdHex  01
   nrNAck     0
   zw.dongle_MSGCNT 32
   zw.dongle_TIME 2016-01-07 10:37:13
   Matchlist:
     1:ZWave    .*
   Readings:
     2016-01-07 10:07:22   caps            Vers:5 Rev:3 ManufID:0115 ProductType:0400 ProductID:0001 SERIAL_API_GET_INIT_DATA SERIAL_API_APPL_NODE_INFORMATION APPLICATION_COMMAND_HANDLER ZW_GET_CONTROLLER_CAPABILITIES SERIAL_API_SET_TIMEOUTS SERIAL_API_GET_CAPABILITIES SERIAL_API_SOFT_RESET UNKNOWN_09 UNKNOWN_0a ZW_SET_R_F_RECEIVE_MODE ZW_SET_SLEEP_MODE ZW_SEND_NODE_INFORMATION ZW_SEND_DATA ZW_SEND_DATA_MULTI ZW_GET_VERSION ZW_SEND_DATA_ABORT ZW_R_F_POWER_LEVEL_SET ZW_SEND_DATA_META ZW_GET_RANDOM MEMORY_GET_ID MEMORY_GET_BYTE MEMORY_PUT_BYTE MEMORY_GET_BUFFER MEMORY_PUT_BUFFER FLASH_AUTO_PROG_SET UNKNOWN_28 NVM_GET_ID NVM_EXT_READ_LONG_BUFFER NVM_EXT_WRITE_LONG_BUFFER NVM_EXT_READ_LONG_BYTE NVM_EXT_WRITE_LONG_BYTE ZW_GET_NODE_PROTOCOL_INFO ZW_SET_DEFAULT ZW_REPLICATION_COMMAND_COMPLETE ZW_REPLICATION_SEND_DATA ZW_ASSIGN_RETURN_ROUTE ZW_DELETE_RETURN_ROUTE ZW_REQUEST_NODE_NEIGHBOR_UPDATE ZW_APPLICATION_UPDATE ZW_ADD_NODE_TO_NETWORK ZW_REMOVE_NODE_FROM_NETWORK ZW_CREATE_NEW_PRIMARY ZW_CONTROLLER_CHANGE ZW_SET_LEARN_MODE ZW_ASSIGN_SUC_RETURN_ROUTE ZW_REQUEST_NETWORK_UPDATE ZW_SET_SUC_NODE_ID ZW_DELETE_SUC_RETURN_ROUTE ZW_GET_SUC_NODE_ID ZW_SEND_SUC_ID ZW_EXPLORE_REQUEST_INCLUSION ZW_REQUEST_NODE_INFO ZW_REMOVE_FAILED_NODE_ID ZW_IS_FAILED_NODE ZW_REPLACE_FAILED_NODE UNKNOWN_66 UNKNOWN_67 UNKNOWN_78 GET_ROUTING_TABLE_LINE LOCK_ROUTE_RESPONSE UNKNOWN_92 UNKNOWN_93 UNKNOWN_98 UNKNOWN_b4 ZW_WATCHDOG_ENABLE ZW_WATCHDOG_DISABLE ZW_WATCHDOG_CHECK ZW_SET_EXT_INT_LEVEL ZW_RF_POWERLEVEL_GET ZW_TYPE_LIBRARY ZW_SEND_TEST_FRAME ZW_GET_PROTOCOL_STATUS WATCHDOG_START WATCHDOG_STOP UNKNOWN_d4 UNKNOWN_ef ZME_FREQ_CHANGE ZME_BOOTLOADER_FLASH UNKNOWN_f5
     2015-10-07 20:02:47   ctrlCaps        MEMBER PRIMARY SUC
     2016-01-07 10:07:22   homeId          HomeId:e58b19ca CtrlNodeId:01
     2015-12-18 23:33:13   neighborList_10 zw.dongle
     2015-12-09 22:55:13   neighborList_11 zw.dongle eg.wz.media_switch
     2015-12-09 22:53:40   neighborList_2  zw.dongle eg.wz.media_switch
     2015-12-09 22:53:48   neighborList_4  zw.dongle eg.wz.media_switch
     2015-12-09 22:52:58   neighborList_7  zw.dongle eg.wz.media_switch
     2016-01-05 22:56:29   neighborList_8  zw.dongle eg.wz.media_switch
     2015-12-18 23:32:26   neighborList_9  eg.wz.media_switch
     2015-10-07 20:05:38   nodeInfo_1      STATIC_CONTROLLER STATIC_CONTROLLER listening frequentListening:0 beaming:16 40kBaud Vers:4 Security:0
     2015-12-09 22:54:19   nodeInfo_10     ROUTING_SLAVE GARAGE_DOOR sleeping frequentListening:0 beaming:16 routing 40kBaud Vers:4 Security:0
     2015-12-09 22:54:26   nodeInfo_11     ROUTING_SLAVE GARAGE_DOOR sleeping frequentListening:0 beaming:16 routing 40kBaud Vers:4 Security:0
     2015-12-20 17:29:05   nodeInfo_12     ROUTING_SLAVE SENSOR_NOTIFICATION sleeping frequentListening:0 beaming:16 routing 40kBaud Vers:4 Security:0
     2015-10-08 12:02:47   nodeInfo_2      ROUTING_SLAVE GARAGE_DOOR sleeping frequentListening:0 beaming:16 routing 40kBaud Vers:4 Security:0
     2015-10-29 12:11:34   nodeInfo_3      ROUTING_SLAVE SWITCH_BINARY listening frequentListening:0 beaming:16 routing 40kBaud Vers:4 Security:0
     2015-10-16 20:49:49   nodeInfo_4      ROUTING_SLAVE GARAGE_DOOR sleeping frequentListening:0 beaming:16 routing 40kBaud Vers:4 Security:0
     2015-10-21 13:40:20   nodeInfo_5      ROUTING_SLAVE GARAGE_DOOR sleeping frequentListening:0 beaming:16 routing 40kBaud Vers:4 Security:0
     2015-10-29 12:11:16   nodeInfo_6      node 6 is not present
     2015-10-29 16:50:54   nodeInfo_7      ROUTING_SLAVE GARAGE_DOOR sleeping frequentListening:0 beaming:16 routing 40kBaud Vers:4 Security:0
     2015-12-03 21:43:31   nodeInfo_8      ROUTING_SLAVE GARAGE_DOOR sleeping frequentListening:0 beaming:16 routing 40kBaud Vers:4 Security:0
     2015-12-03 21:43:42   nodeInfo_9      ROUTING_SLAVE GARAGE_DOOR sleeping frequentListening:0 beaming:16 routing 40kBaud Vers:4 Security:0
     2015-12-22 11:06:03   nodeList        zw.dongle eg.wz.window_open eg.wz.media_switch eg.fl.window_open eg.wc.window_open eg.kue.window_open dg.hint.window_open dg.vorn.window_open ke.hint.window_open ke.vorn.window_open eg.wz.smoke_detect
     2016-01-07 10:07:22   random          7ea84ce19a49ad9ed5f20bf45647a35d6ab1c3355e326568a77ccf10ff06c44b
     2016-01-07 10:07:22   state           Initialized
     2015-10-08 18:14:43   version         Z-Wave 4.05 STATIC_CONTROLLER
   SendStack:
Attributes:
   alias      Z-Wave Controller
   group      Controllers
   icon       it_wireless_dcf77
   networkKey 73479945XXXXXXXXXXXXXXXXXX
   room       Infrastruktur
   verbose    3


[A.Harrenberg]

Hi,

Ich hoffe, dass ist hier richtig:
Seit dem Update am 5.01.2016 (10_ZWave.pm) wird mir das Log mit diesen Meldungen "geflutet":

Code Auswählen Erweitern

secUnlock will call Zwave_secEnd

Von den 8 Philio/Devolo/D-Link Kontakten sind "historisch" nur zwei mit Security inkludiert. Die Meldungen kommen nur von diesen beiden und immer nur dann wenn der jeweilige Sensor Status-Meldungen (Auf/Zu/Temperatur/etc) sendet. Fehlfunktionen kann ich bisher keine erkennen.

Edith: 10:32:01 war das Schließen des Fensters. 10:32.08 war der stündliche Status Report von Temperatur/Luminance. Das war Zufall.
Wenn ich das globale Log mit dem jeweiligen Filelog vergleiche, scheint die o.g. Meldung immer mit sieben Sekunden Verzögerung zu kommen.

diese Meldung sollte eigentlich nur kommen wenn im Ablauf mit SECURITY etwas durcheinander gekommen ist. Da ist ein Timer drin, der erkennen soll ob das System "klemmt" und dann das System wieder "resettet".

Ich schau heute abend mal genauer in das Log um zu sehen ob die Meldung bei Dir zu Recht kommt oder ein "Fehlalarm" ist. Es könnte sein das automatische Nachrichten ohne einen entsprechenden Get-Befehl evtl. die Erkennungslogik durcheinander bringt.

Gruß,
Andreas.

[A.Harrenberg]

Hallo Rudi,

kannst Du bitte den Patch für den Workaround einchecken?

In der ursprünglichen Version wurde die Warnung ausgegeben und secEnd aufgerufen wenn der Timer abgelaufen war, unabhängig davon ob secEnd bereits aufgerufen war.
Ich habe das jetzt mit in die Abfrage aufgenommen.

Gruß,
Andreas.

[rudolfkoenig]

Habs eingechekt, bin aber der Ansicht, dass es besser waere den Aufruf ganz zu sparen, indem man an der passenden Stelle RemoveInternalTimer aufruft.

[A.Harrenberg]

Hi Rudi,

das geht ja nur wenn ich da einen "eigenen" Timer mit "eigenem" hash anlege. Soweit habe ich mir das mit den Timer noch nicht angesehen, einen entsprechenden Umbau schreibe ich mir auf meine ToDo-Liste.

Gruß,
Andreas.

[rudolfkoenig]

Code Auswählen Erweitern

$hash->{secTimer} = { hash => $hash };
InternalTimer(time()+5,"MyFunction", $hash->{secTimer},0);
sub
MyFunction($)
{
  my ($p) = @_;
  my $hash = $p->{hash};
  Log3 $hash, 1, "Hello";
}
RemoveInternalTimer($hash-{secTimer});


Ungetestet, aber vom Prinzip her sollte es stimmen.

[krikan]

Nachdem jetzt addNode die sec-Einbindung standardmäßig anbietet (Danke, Rudi), hätte ich dazu gerne ein paar Sätze im Wiki.
Andreas, soll ich das machen?
Falls ja, würde ich anmerken, dass SECURITY erhöhte Funklast sowie ggfs. Reaktionsverzögerungen verursacht und nur bei wirklich sicherheitsrelevanten Dingen (Schloß, etc) genutzt werden sollte. Standard ist ohne sec. Ok?

[A.Harrenberg]

Hi Christian,

ja, das kannst Du gerne so in das Wiki übernehmen!

Vielen Dank dafür!
Andreas.

[A.Harrenberg]

Hi Rudi,

habe jetzt so wie von Dir vorgeschlagen einen eigenen Timer das "Unlock" gemacht und die Änderungen in processSendStack wieder rückgängig gemacht das sie dann ja nicht mehr benötigt werden.
Patchfile habe ich angehängt.

Gruß,
Andreas.

Edit: Patchfile noch mal geändert erweitert, jetzt ist auch der Timer bei NetworkkeyVerify ein "eigener", außerdem werden die hash-werte jetzt wieder aufgeräumt.

[A.Harrenberg]

Hi Rudi,

wegen "zwave_parsehook"...

Das wird ja sogar schon aktiv verwendet. Ob es fuer die Sec-Funktionen an der richtigen Stelle geprueft/aufgerufen wird, weiss ich aber nicht.

steh' ich anscheinend irgendwie auf dem Schlauch oder bin im falschen Film...

Was genau meinst Du mit zwave_parsehook? Ich finde keine Funktion mit dem Namen und auch sonst kommt mir auf den ersten Blick da nichts geändert vor.

Was übersehe ich?

Gruß,
Andreas.

[rudolfkoenig]

Patch eingecheckt.

zwave_parsehook: sorry, es heisst zwave_parseHook (H gross). Hier traegt man fuer eine nodeId/Command-Regexp Kombination eine Funktion ein, und falls in ZWave_Parse eine passende Nachricht auftaucht, dann wird diese Funktion aufgerufen. Ich gehe davon aus, dass wir dafuer noch leichte Anpassungen vornehmen muessen, z.Bsp. Pruefung an anderer Stelle, je nach Rueckgabe der Funktion Abbruch der Weiterverarbeitung, um unerwuenschte Events zu vermeiden.

Ist nicht so dringend, da bisher keine Meldungen diesbezueglich aufgetaucht sind, andererseits wuerden Meldungen anderswo auftauchen, weil manche Module (z.Bsp. Homematic) empfindlich auf verspaetete Aufrufe reagieren. Die Ursache waere dann das blockierende Warten auf Security-Gets in ZWave.

Fuer direkte Aufrufe ueber die Frontends koennte man justme1968's Vorschlag implementieren, damit waeren diese Aufrufe auch blockierungsfrei. Bleiben noch die gets aufgerufen aus notify/at, dafuer koennten wir mit einem speziellen set einen Ersatz bauen, der nicht auf die Antwort wartet. Der Benutzer muss die Auswertung der Antworten (falls ueberhaupt noetig) mit einem weiteren notify realisieren.

[A.Harrenberg]

Hi Rudi,

ah, jetzt, mein Editor zeigt mir eine Übersicht aller FUNKTIONEN an, da hatte ich nach zwave_parsehook geschaut und nichts gefunden. Jetzt weiß ich wenigstens wo ich schauen muss...

Danke,
Andreas.

[A.Harrenberg]

Hi Rudi,

zwave_parsehook: sorry, es heisst zwave_parseHook (H gross). Hier traegt man fuer eine nodeId/Command-Regexp Kombination eine Funktion ein, und falls in ZWave_Parse eine passende Nachricht auftaucht, dann wird diese Funktion aufgerufen. Ich gehe davon aus, dass wir dafuer noch leichte Anpassungen vornehmen muessen, z.Bsp. Pruefung an anderer Stelle, je nach Rueckgabe der Funktion Abbruch der Weiterverarbeitung, um unerwuenschte Events zu vermeiden.

Ist nicht so dringend, da bisher keine Meldungen diesbezueglich aufgetaucht sind, andererseits wuerden Meldungen anderswo auftauchen, weil manche Module (z.Bsp. Homematic) empfindlich auf verspaetete Aufrufe reagieren. Die Ursache waere dann das blockierende Warten auf Security-Gets in ZWave.

Fuer direkte Aufrufe ueber die Frontends koennte man justme1968's Vorschlag implementieren, damit waeren diese Aufrufe auch blockierungsfrei. Bleiben noch die gets aufgerufen aus notify/at, dafuer koennten wir mit einem speziellen set einen Ersatz bauen, der nicht auf die Antwort wartet. Der Benutzer muss die Auswertung der Antworten (falls ueberhaupt noetig) mit einem weiteren notify realisieren.

hier verstehe ich so einige Sachen noch nicht...

Was bringt das Aufrufen einer Funktion in Parse durch zwave_parseHook wenn eine passende Nachricht eintrifft? Die würde doch auch sonst ganz normal geparst werden, wo ist da der Vorteil? Die Schwierigkeit, oder nennen wir es Herausforderung, ist doch zwischen dem GET und dem REPORT blockierungsfrei auf die Antwort zu warten. Mit dieser Konstruktion würde ja der normale Ablauf weitergehen und die Antwort bei Eintreffen geparst werden, aber nicht verhindert werden das der nächste Befehl die Kommunikation evtl. durcheinander bringt, oder bin ich hier auf dem Holzweg?

Ich habe den ganzen Ablauf immer noch so verstanden das der Dongle zwischen GET und REPORT auch keine weiteren Befehle verträgt, d.h. man muss warten. Wie lange ist natürlich eine Frage... Bei den Controller-Befehlen gibt es da 0x06 SERIAL_API_SET_TIMEOUTS, könnten das evtl. die internen Timeouts für den Dongle sein? Der muss ja auch irgendwann mal aufgeben und wieder weitermachen dürfen...

Mein Verständnis ist weiterhin das die globale, FHEM-weite, Blockierung durch ReadAnswerFn ausgelöst wird, das wird aber "nur" in ZWave_Parse bei get-Befehlen ausgeführt, die NICHT per SECURITY gesendet werden. In Security werden die ja vorher abgefangen und dann verschlüsselt als SET gesendet. Meiner Meinung nach dürfte es daher bei den Verschlüsselten Befehlen zu keiner Blockade von FHEM kommen. Ich überlege zwar gerade das verschlüsselte Senden je nach Inhalt als SET oder GET deklariert durchzuführen, die Stelle mit dem ReadAnswerFn erreichen verschlüsselte Pakete aber sowieso nie...

Könntest Du mir bitte noch mal auf die Sprünge helfen und mir sagen ob bzw. wo ich hier in meinem Verständnis einen Fehler habe?

Meine momentane Idee wäre es analog zu secStart/secEnd bzw. dem warten auf das ACK auch den normalen Sendstack anhalten zu können. Bei einem Get-Befehl einen Timer starten, falls die passende Antwort eintrifft Timer löschen, Sendstack wieder freigeben. Falls Timer abläuft, könnte man den Befehl wiederholen (mit Retry-counter) und letztendlich aufgeben und den nächsten Befehl abarbeiten.

Danke,
Andreas.

[rudolfkoenig]

Problem:
Aufruf von ZWave get konzentriert sich nur auf dem betroffenen ZWDongle, und ignoriert z.Bsp. das HomeMatic CUL, die telnet und FHEMWEB Verbindung, usw. Im Normalfall sind das nur 100ms, und vermutlich irrelevant, im Problemfall kann das mit 3 Sekunden schon ein Problem werden, z.Bsp. wenn ein ACK im HomeMatic in FHEM generiert wird.

Vorgeschlagene Lösungen:
- fuer FHEMWEB/telnet: spezielle Benachrichtigungsroutinen in den Modulen, die beim Eintreffen der passenden Nachricht die Daten anzeigen. Es wird nicht blockierend gewartet, und im Problemfall gibts entweder keine Nachricht, oder im Modul muss ein Timer aufgezogen werden.
- fuer Modulinterne "get" schlage ich zwave_parseHook vor: da spezifiziert man, was man erwartet, und wo es weitergehen soll, wenn die Nachricht eintrifft. Fuer den Fall, dass sie nicht eintrifft, muss man einen Timer aufrufen.

Ich habe die Gets im ZWave jetzt naeher angeschaut, und ich meine man kommt auch viel einfacher an eine Loesung:
Es gibt drei Aufrufe von ZWave_Cmd im Security Kontext, aber alle drei Ergebnisse werden nicht direkt ausgewertet, sondern indirekt ueber ZWave_secNonceRequestReceived/ZWave_secSupported. Damit ist es trivial, aus diesen "get secNonce/set secSupported" gleichwertige "set secNonce/set secSupported" Aufrufe zu machen (die beiden gets auch im set Hash anbieten, und get durch set zu ersetzen). Nach diesem Umbau waere Security in ZWave blockierungsfrei.

[A.Harrenberg]

Hi Rudi,

irgendwie bin ich jetzt auch noch nicht wirklich schlauer...

Problem:
Aufruf von ZWave get konzentriert sich nur auf dem betroffenen ZWDongle, und ignoriert z.Bsp. das HomeMatic CUL, die telnet und FHEMWEB Verbindung, usw. Im Normalfall sind das nur 100ms, und vermutlich irrelevant, im Problemfall kann das mit 3 Sekunden schon ein Problem werden, z.Bsp. wenn ein ACK im HomeMatic in FHEM generiert wird.

mir ist klar das eine blockierende Funktion innerhalb FHEM schlecht ist, aber welcher Teil GENAU löst das aus? Ist das wie von mir postuliert NUR die ReadAnswerFn?

Vorgeschlagene Lösungen:
- fuer FHEMWEB/telnet: spezielle Benachrichtigungsroutinen in den Modulen, die beim Eintreffen der passenden Nachricht die Daten anzeigen. Es wird nicht blockierend gewartet, und im Problemfall gibts entweder keine Nachricht, oder im Modul muss ein Timer aufgezogen werden.

Hier kann ich Dir jetzt nicht mehr folgen. Meinst Du hier das in FHEMWEB bzw. über telnet die Rückgabe des GET-Befehls angezeigt werden soll?

- fuer Modulinterne "get" schlage ich zwave_parseHook vor: da spezifiziert man, was man erwartet, und wo es weitergehen soll, wenn die Nachricht eintrifft. Fuer den Fall, dass sie nicht eintrifft, muss man einen Timer aufrufen.

Auch hier verstehe ich Dich nicht wirklich, ich habe den tieferen Sinn des zwave_parseHook aber auch noch nicht verstanden. Aber warum/wie soll ich einen Timer aufrufen wenn die Nachricht NICHT eintrifft? Das "nicht eintreffen" kann ich doch nur über einen Time-Out definieren/erkennen den ich ja über einen Timer realisieren muss...

Ich habe die Gets im ZWave jetzt naeher angeschaut, und ich meine man kommt auch viel einfacher an eine Loesung:
Es gibt drei Aufrufe von ZWave_Cmd im Security Kontext, aber alle drei Ergebnisse werden nicht direkt ausgewertet, sondern indirekt ueber ZWave_secNonceRequestReceived/ZWave_secSupported. Damit ist es trivial, aus diesen "get secNonce/set secSupported" gleichwertige "set secNonce/set secSupported" Aufrufe zu machen (die beiden gets auch im set Hash anbieten, und get durch set zu ersetzen). Nach diesem Umbau waere Security in ZWave blockierungsfrei.

Auch hier muss ich mir das noch mal genau ansehen, allerdings bin ich mir nicht sicher warum Du unbedingt die GET Befehle in SET Befehle (selbst im hash) ändern willst.

Ich verstehe immer noch nicht wo das Problem an einem GET Befehl ist was sich durch eine Umdeklarierung in ein SET ändern lässt... Wie soll das überhaupt mit den ganzen Befehlen rein namenstechnisch gehen. Die Klasse TIME z.B. hat ein SET timeOffset und ein GET timeOffset.

Meiner Meinung nach muss man zwischen einem SET und einem GET unterscheiden, woher ist denn sonst überhaupt klar das eine Antwort erwartet wird? Weiterhin muss man weiterhin zwingend zwischen dem GET und dem REPORT (der Antwort) verhindern das weitere Befehle über den Dongle abgesetzt werden. Das gilt MINDESTENS für die betroffene Node, wahrscheinlich aber eben global für den Dongle.

Mein Verständnis ist das bisher bei einem GET am Ende von ZWave_Cmd die ReadAnswerFn des IODev aufgerufen wird und das diese Funktion blockierend ist. (Kannst Du bitte mal bestätigen das dies wirklich die einzige Blockade ist?)

Prinzipiell macht dieser Block am ende von ZWave_Cmd ja nichts anderes als auf den REPORT zu warten und anschliessend ZWave_Parse für die erhaltene Antwort aufzurufen. Meiner Meinung nach muss das Problem an dieser Stelle gelöst werden.

Sendstack anhalten, Get-Befehl absetzen, Time-Out timer starten
Falls Nachricht eintrifft mit erwartetem Muster (Klasse und Befehl!) vergleichen, Nachricht passt -> Timer stoppen, Sendstack wieder freigben
Falls Nachricht eintrifft ohne erwartetes Muster, Nachricht normal parsen, weiter warten
Timer läuft ab ohne passende Nachricht -> Fehlermeldung, Sendstack wieder freigeben.

So ein Konstrukt sollte FHEM nicht blockieren aber sicherstellen das zwischen GET und REPORT nicht gesendet wird.

Mir dämmert aber gerade das hierbei kein Rückgabewert per "return" (an FHEMWEB/telnet) übergeben werden kann, da man dann ja quasi schon ohne die Antwort weitermacht... Dann wäre das Problem ja eher wie bekommt man die aufrufende Instanz asynchron hin? Die Funktion selbst müsste dann auch so aufgebaut sein das sie die Antwort nicht direkt im GET erwartet sondern diese "später" als REPORT bekommt...

Das werde ich mir am WE noch mal genauer anschauen müssen.

Immer noch verwirrt, (oder sogar noch mehr...)
Andreas.

P.S.: In Erweiterung der Diskussion wäre ich dafür bei den GET-Befehlen das "Muster" mit dem erwarteten REPORT mit in den hash aufzunehmen. Bisher wird ja quasi JEDE Antwort dieser Befehlsklasse als Treffer gewertet, falls da dann zufällig z.B. eine "unsolicited" Message (Bewegungsmelder...) kommt dann geht das schief. Bei jedem GET ist eigentlich zusätzlich zu der Klasse auch die Befehlsnummer klar die man als Antwort erwartet. Bei den meisten Befehlen sogar die Länge, einige haben jedoch auch eine variable, nicht vorhersehbare Länge.