Hallo liebes Forum,
ich verwende erfolgreich seit ca. 2 Jahren den Z-Wave USB Stick (ZMEEUZB1).
Seit geraumer Zeit habe ich das Gefühl, dass der Stick einen kleinen Ditscher abbekommen hat. (er legt sich von Zeit zu Zeit schlafen und kann durch ein "get Z_Wave version" wieder zum Leben erweckt werden).
Nun gut, ich habe mir nun ein Modell-gleichen Stick gekauft, dieser wartet darauf nun den alten Stick zu ersetzen.
Laut commandref:
https://wiki.fhem.de/wiki/Z-Wavehabe ich versucht ein BackUp zu erstellen.
Dazu habe ich folgendes ausgeführt:
set Z_Wave backupCreate 256kNach ca. 5-10Sekunden kam dann folgende Meldung:
Timeout reading answer for get NVM_EXT_READ_LONG_BUFFERHabe den o.g. Befehl öfter ausgeführt, leider immer mit der o.g. Fehlermeldung.
Im Log habe ich 1x folgende Meldung gefunden:
2019.02.26 14:44:20 3: Z_Wave backupCreate at 16384 bytesNun habe ich aus reinem Interesse unter folgenden Pfad nachgeschaut:
/opt/fhem/Hier habe ich eine Datei mit dem Namen "Z_Wave.bin" entdeckt, die vom Zeitstempel her passt.
Meine Frage:
- Wurde das BackUp nun erfolgreich erstellt?
- Wie kann ich prüfen, ob es korrekt erstellt wurde?
- Ist die gefundene Datei tatsächlich das BackUp?
- Falls ja, kann ich dieses BackUp nun in meinen neuen Z-Wave ZMEEUZB1 per backupRestore einspielen?
Wie sollte ich bei dem backupRestore vorgehen?
Alten ZMEEUZB1 abstecken, neuen ZMEEUZB1 anstecken und dann einen Restore machen?
Recht herzlichen Dank für eure Hilfe.
Hier noch ein List von meinem jetzigen ZMEEUZB1:
Internals:
CallbackNr 0
Clients :ZWave:
DEF /dev/serial/by-id/usb-0658_0200-if00@115200
DeviceName /dev/serial/by-id/usb-0658_0200-if00@115200
FD 15
MaxSendRetries 3
NAME Z_Wave
NR 307
PARTIAL
RAWMSG 0004002b0a3202a14a000000350000
ReadTime 1551188686.74476
STATE Initialized
SendRetries 0
SendTime 1551188664.3332
TYPE ZWDongle
WaitForAck 0
Z_Wave_MSGCNT 228706
Z_Wave_TIME 2019-02-26 14:44:46
homeId d8a48054
nodeIdHex 01
nrNAck 0
MatchList:
1:ZWave .*
READINGS:
2019-02-12 11:28:58 caps Vers:5 Rev:5 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 ZW_NVR_GET_VALUE 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 ZW_FIRMWARE_UPDATE_NVM GET_ROUTING_TABLE_LINE LOCK_ROUTE_RESPONSE ZW_GET_PRIORITY_ROUTE ZW_SET_PRIORITY_ROUTE UNKNOWN_98 ZW_SET_WUT_TIMEOUT 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 ZW_SET_ROUTING_MAX UNKNOWN_ef ZME_FREQ_CHANGE ZME_BOOTLOADER_FLASH ZME_CAPABILITIES
2019-02-12 11:28:58 ctrlCaps PRIMARY
2019-02-12 11:28:58 homeId HomeId:d8a48054 CtrlNodeIdHex:01
2019-01-23 16:39:45 nodeList Z_Wave UNKNOWN_2 UNKNOWN_3 UNKNOWN_4 wz_TV UNKNOWN_6 sz_TV sz_Taster wz_Taster az_Taster sz_Taster_links fl_Taster_Server ku_Taster fl_Taster ku_Taster_Waschbecken UNKNOWN_36 UNKNOWN_38 UNKNOWN_39 ZWave_WALL_CONTROLLER_42 az_Computer fl_Display ku_Motion sz_Flackerstern sz_Knautschi fl_Servertuer az_Staubsauger sz_Motion ZWave_SENSOR_NOTIFICATION_52 fl_Motion ku_Boiler az_Schreibtisch wz_Receiver
2019-02-12 11:28:59 random e9e8c8e61d0cdcba635e3aa5cf1fe993e78f315837a4ba1088eadbad364abcd8
2019-02-12 11:28:59 state Initialized
2019-02-12 11:28:58 sucNodeId no
2019-02-26 14:43:59 version Z-Wave 4.05 STATIC_CONTROLLER
SendStack:
Attributes:
homeId d8a48054
icon cul_usb
room Z-Wave
verbose 0
Gruß
Mathze
ZitatWurde das BackUp nun erfolgreich erstellt?
Vermutlich nicht, sonst waere die Fehlermeldung sinnlos.
ZitatWie kann ich prüfen, ob es korrekt erstellt wurde?
Ein Hinweis ist, wenn die Datei wirklich 256k lang ist (256*1024 = 262144)
Dass dabei kein Fehler aufgetreten ist, ist aber nicht sicher.
ZitatIst die gefundene Datei tatsächlich das BackUp?
Ja.
ZitatFalls ja, kann ich dieses BackUp nun in meinen neuen Z-Wave ZMEEUZB1 per backupRestore einspielen?
Ich wuerde vorher von dem anderen Stick ein backup machen, mit dem gleichen Verfahren.
Wenn alles schiefgeht, gibt es noch der factoryReset Befehl.
ZitatAlten ZMEEUZB1 abstecken, neuen ZMEEUZB1 anstecken und dann einen Restore machen?
In etw ja, und danach nochmal abstecken/anstecken, wg. reset.
Ich habe ein backupCreate nun noch ein paar mal probiert, leider immer wieder mit der im Thread 1 beschriebenen Fehlermeldung abgeschlossen.
Das BackUp dauerte teilweise zwischen 2-10Sekunden.
Nach jedem Durchlauf habe ich die Z_Wave.bin Datei gelöscht um zu überprüfen, ob die Dateigröße identisch ist, leider nicht.
Hatte alles zwischen ~2.000b - 22.720Bytes, also jenseits von dem Ergebnis was erwartet wird.
Nun gut, dann ist jetzt die Frage, wieso / wo es bei mir hapert.
Mein FHEM System läuft auf einem QNAP in der Virtualization Station (VM).
Gruß
Mathze
Habe mal verbose auf 5 hochgeschraubt um zu schauen, ob ich irgendwas erkennen kann.
Dies kam dabei heraus (gekürzt):
Im Anhang befindet sich der komplette Logauszug!
2019.02.26 16:10:27 4: ZWDongle *** set Z_Wave backupCreate 256k
2019.02.26 16:10:27 5: ZWDongle_Write 002a0000000040 ()
2019.02.26 16:10:27 5: SW: 0108002a00000000409d
2019.02.26 16:10:27 4: ZWDongle_ReadAnswer arg:NVM_EXT_READ_LONG_BUFFER regexp:^012a
2019.02.26 16:10:27 5: ACK received, removing 0108002a00000000409d from dongle sendstack
2019.02.26 16:10:27 4: ZWDongle_Read Z_Wave: rcvd 012a5a654e7359730000d8a480540a090807000000000054a50000000000000000000000000000000000000000000000000000000000000000000000000040002000 (answer NVM_EXT_READ_LONG_BUFFER), sending ACK
2019.02.26 16:10:27 5: SW: 06
2019.02.26 16:10:27 4: ZWDongle_ReadAnswer for NVM_EXT_READ_LONG_BUFFER: 012a5a654e7359730000d8a480540a090807000000000054a50000000000000000000000000000000000000000000000000000000000000000000000000040002000
2019.02.26 16:10:27 5: ZWDongle_Write 002a0000400040 ()
2019.02.26 16:10:27 5: SW: 0108002a0000400040dd
2019.02.26 16:10:27 4: ZWDongle_ReadAnswer arg:NVM_EXT_READ_LONG_BUFFER regexp:^012a
2019.02.26 16:10:27 5: ACK received, removing 0108002a0000400040dd from dongle sendstack
2019.02.26 16:10:27 4: ZWDongle_Read Z_Wave: rcvd 012a00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 (answer NVM_EXT_READ_LONG_BUFFER), sending ACK
2019.02.26 16:10:27 5: SW: 06
2019.02.26 16:10:27 4: ZWDongle_ReadAnswer for NVM_EXT_READ_LONG_BUFFER: 012a00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
2019.02.26 16:10:27 5: ZWDongle_Write 002a0000800040 ()
2019.02.26 16:10:27 5: SW: 0108002a00008000401d
2019.02.26 16:10:27 4: ZWDongle_ReadAnswer arg:NVM_EXT_READ_LONG_BUFFER regexp:^012a
2019.02.26 16:10:27 5: ACK received, removing 0108002a00008000401d from dongle sendstack
2019.02.26 16:10:27 4: ZWDongle_Read Z_Wave: rcvd 012a00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 (answer NVM_EXT_READ_LONG_BUFFER), sending ACK
2019.02.26 16:10:27 5: SW: 06
2019.02.26 16:10:27 4: ZWDongle_ReadAnswer for NVM_EXT_READ_LONG_BUFFER: 012a00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
2019.02.26 16:10:27 5: ZWDongle_Write 002a0000c00040 ()
2019.02.26 16:10:27 5: SW: 0108002a0000c000405d
2019.02.26 16:10:27 4: ZWDongle_ReadAnswer arg:NVM_EXT_READ_LONG_BUFFER regexp:^012a
2019.02.26 16:10:27 5: ACK received, removing 0108002a0000c000405d from dongle sendstack
2019.02.26 16:10:27 4: ZWDongle_Read Z_Wave: rcvd 012a00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000009316010201539c01 (answer NVM_EXT_READ_LONG_BUFFER), sending ACK
[...]
2019.02.26 16:10:29 5: SW: 06
2019.02.26 16:10:29 4: ZWDongle_ReadAnswer for NVM_EXT_READ_LONG_BUFFER: 012a00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
2019.02.26 16:10:29 5: ZWDongle_Write 002a0018c00040 ()
2019.02.26 16:10:29 5: SW: 0108002a0018c0004045
2019.02.26 16:10:29 4: ZWDongle_ReadAnswer arg:NVM_EXT_READ_LONG_BUFFER regexp:^012a
2019.02.26 16:10:29 5: ACK received, removing 0108002a0018c0004045 from dongle sendstack
2019.02.26 16:10:29 4: ZWDongle_Read Z_Wave: rcvd 012a00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 (answer NVM_EXT_READ_LONG_BUFFER), sending ACK
2019.02.26 16:10:29 5: SW: 06
2019.02.26 16:10:29 4: ZWDongle_ReadAnswer for NVM_EXT_READ_LONG_BUFFER: 012a00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
2019.02.26 16:10:29 5: ZWDongle_Write 002a0019000040 ()
2019.02.26 16:10:29 5: SW: 0108002a001900004084
2019.02.26 16:10:29 4: ZWDongle_ReadAnswer arg:NVM_EXT_READ_LONG_BUFFER regexp:^012a
2019.02.26 16:10:29 5: ACK received, removing 0108002a001900004084 from dongle sendstack
2019.02.26 16:10:29 4: ZWDongle_Read Z_Wave: rcvd 012a00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 (answer NVM_EXT_READ_LONG_BUFFER), sending ACK
2019.02.26 16:10:29 5: SW: 06
2019.02.26 16:10:29 4: ZWDongle_ReadAnswer for NVM_EXT_READ_LONG_BUFFER: 012a00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
2019.02.26 16:10:29 5: ZWDongle_Write 002a0019400040 ()
2019.02.26 16:10:29 5: SW: 0108002a0019400040c4
2019.02.26 16:10:29 4: ZWDongle_ReadAnswer arg:NVM_EXT_READ_LONG_BUFFER regexp:^012a
2019.02.26 16:10:29 5: ACK received, removing 0108002a0019400040c4 from dongle sendstack
2019.02.26 16:10:29 4: ZWDongle_Read Z_Wave: rcvd 012a00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 (answer NVM_EXT_READ_LONG_BUFFER), sending ACK
2019.02.26 16:10:29 5: SW: 06
2019.02.26 16:10:29 4: ZWDongle_ReadAnswer for NVM_EXT_READ_LONG_BUFFER: 012a00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
2019.02.26 16:10:29 5: ZWDongle_Write 002a0019800040 ()
2019.02.26 16:10:29 5: SW: 0108002a001980004004
2019.02.26 16:10:29 4: ZWDongle_ReadAnswer arg:NVM_EXT_READ_LONG_BUFFER regexp:^012a
2019.02.26 16:10:29 5: ACK received, removing 0108002a001980004004 from dongle sendstack
2019.02.26 16:10:29 4: ZWDongle_Read Z_Wave: rcvd 012a00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 (answer NVM_EXT_READ_LONG_BUFFER), sending ACK
2019.02.26 16:10:29 5: SW: 06
2019.02.26 16:10:29 4: ZWDongle_ReadAnswer for NVM_EXT_READ_LONG_BUFFER: 012a00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
2019.02.26 16:10:29 5: ZWDongle_Write 002a0019c00040 ()
2019.02.26 16:10:29 5: SW: 0108002a0019c0004044
2019.02.26 16:10:29 4: ZWDongle_ReadAnswer arg:NVM_EXT_READ_LONG_BUFFER regexp:^012a
2019.02.26 16:10:29 5: ACK received, removing 0108002a0019c0004044 from dongle sendstack
2019.02.26 16:10:29 4: ZWDongle_Read Z_Wave: rcvd 012a00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 (answer NVM_EXT_READ_LONG_BUFFER), sending ACK
2019.02.26 16:10:29 5: SW: 06
2019.02.26 16:10:29 4: ZWDongle_ReadAnswer for NVM_EXT_READ_LONG_BUFFER: 012a00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
2019.02.26 16:10:29 5: ZWDongle_Write 002a001a000040 ()
2019.02.26 16:10:29 5: SW: 0108002a001a00004087
2019.02.26 16:10:29 4: ZWDongle_ReadAnswer arg:NVM_EXT_READ_LONG_BUFFER regexp:^012a
2019.02.26 16:10:29 5: ACK received, removing 0108002a001a00004087 from dongle sendstack
2019.02.26 16:10:29 4: ZWDongle_Read Z_Wave: rcvd 012a00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 (answer NVM_EXT_READ_LONG_BUFFER), sending ACK
2019.02.26 16:10:29 5: SW: 06
2019.02.26 16:10:29 4: ZWDongle_ReadAnswer for NVM_EXT_READ_LONG_BUFFER: 012a00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
2019.02.26 16:10:29 5: ZWDongle_Write 002a001a400040 ()
2019.02.26 16:10:29 5: SW: 0108002a001a400040c7
2019.02.26 16:10:29 4: ZWDongle_ReadAnswer arg:NVM_EXT_READ_LONG_BUFFER regexp:^012a
2019.02.26 16:10:29 5: ACK received, removing 0108002a001a400040c7 from dongle sendstack
2019.02.26 16:10:29 4: ZWDongle_Read Z_Wave: rcvd 012a00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 (answer NVM_EXT_READ_LONG_BUFFER), sending ACK
2019.02.26 16:10:29 5: SW: 06
2019.02.26 16:10:29 4: ZWDongle_ReadAnswer for NVM_EXT_READ_LONG_BUFFER: 012a00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
2019.02.26 16:10:29 5: ZWDongle_Write 002a001a800040 ()
2019.02.26 16:10:29 5: SW: 0108002a001a80004007
2019.02.26 16:10:29 4: ZWDongle_ReadAnswer arg:NVM_EXT_READ_LONG_BUFFER regexp:^012a
2019.02.26 16:10:29 5: ACK received, removing 0108002a001a80004007 from dongle sendstack
2019.02.26 16:10:29 4: ZWDongle_Read Z_Wave: rcvd 012a00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 (answer NVM_EXT_READ_LONG_BUFFER), sending ACK
2019.02.26 16:10:29 5: SW: 06
2019.02.26 16:10:29 4: ZWDongle_ReadAnswer for NVM_EXT_READ_LONG_BUFFER: 012a00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
2019.02.26 16:10:29 5: ZWDongle_Write 002a001ac00040 ()
2019.02.26 16:10:29 5: SW: 0108002a001ac0004047
2019.02.26 16:10:29 4: ZWDongle_ReadAnswer arg:NVM_EXT_READ_LONG_BUFFER regexp:^012a
2019.02.26 16:10:29 5: ACK received, removing 0108002a001ac0004047 from dongle sendstack
2019.02.26 16:10:30 1: Z_Wave: wrong checksum: received 00, computed fe for 43012a0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000143012a
2019.02.26 16:10:30 5: ZWDongle_Read wrong checksum -> sending NACK
2019.02.26 16:10:30 5: SW: 15
2019.02.26 16:10:30 4: ZWDongle_Read Z_Wave: rcvd 012a00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 (answer NVM_EXT_READ_LONG_BUFFER), sending ACK
2019.02.26 16:10:30 5: SW: 06
2019.02.26 16:10:30 4: ZWDongle_ReadAnswer for NVM_EXT_READ_LONG_BUFFER: 012a00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
2019.02.26 16:10:30 5: ZWDongle_Write 002a001b000040 ()
2019.02.26 16:10:30 5: SW: 0108002a001b00004086
2019.02.26 16:10:30 4: ZWDongle_ReadAnswer arg:NVM_EXT_READ_LONG_BUFFER regexp:^012a
2019.02.26 16:10:30 5: ACK received, removing 0108002a001b00004086 from dongle sendstack
2019.02.26 16:10:30 4: ZWDongle_Read Z_Wave: rcvd 012a00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 (answer NVM_EXT_READ_LONG_BUFFER), sending ACK
2019.02.26 16:10:30 5: SW: 06
2019.02.26 16:10:30 4: ZWDongle_ReadAnswer for NVM_EXT_READ_LONG_BUFFER: 012a00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
2019.02.26 16:10:30 5: ZWDongle_Write 002a001b400040 ()
2019.02.26 16:10:30 5: SW: 0108002a001b400040c6
2019.02.26 16:10:30 4: ZWDongle_ReadAnswer arg:NVM_EXT_READ_LONG_BUFFER regexp:^012a
2019.02.26 16:10:30 5: ACK received, removing 0108002a001b400040c6 from dongle sendstack
2019.02.26 16:10:30 4: ZWDongle_Read Z_Wave: rcvd 012a00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 (answer NVM_EXT_READ_LONG_BUFFER), sending ACK
2019.02.26 16:10:30 5: SW: 06
2019.02.26 16:10:30 4: ZWDongle_ReadAnswer for NVM_EXT_READ_LONG_BUFFER: 012a00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
2019.02.26 16:10:30 5: ZWDongle_Write 002a001b800040 ()
2019.02.26 16:10:30 5: SW: 0108002a001b80004006
2019.02.26 16:10:30 4: ZWDongle_ReadAnswer arg:NVM_EXT_READ_LONG_BUFFER regexp:^012a
2019.02.26 16:10:30 5: ACK received, removing 0108002a001b80004006 from dongle sendstack
2019.02.26 16:10:31 1: Z_Wave: wrong checksum: received 2a, computed d4 for 43012a00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000014301
2019.02.26 16:10:31 5: ZWDongle_Read wrong checksum -> sending NACK
2019.02.26 16:10:31 5: SW: 15
2019.02.26 16:10:31 1: Z_Wave: SOF missing (got 00 instead of 01)
2019.02.26 16:10:31 5: ZWDongle_Read SOF Error -> sending NACK
2019.02.26 16:10:31 5: SW: 15
2019.02.26 16:10:31 1: Z_Wave: SOF missing (got 00 instead of 01)
2019.02.26 16:10:31 5: ZWDongle_Read SOF Error -> sending NACK
2019.02.26 16:10:31 5: SW: 15
2019.02.26 16:10:31 1: Z_Wave: SOF missing (got 00 instead of 01)
2019.02.26 16:10:31 5: ZWDongle_Read SOF Error -> sending NACK
2019.02.26 16:10:31 5: SW: 15
2019.02.26 16:10:32 5: ZWDongle_ReadAnswer: select timeout
Gruß
Mathze
Zitat von: t1me2die am 26 Februar 2019, 15:54:56
[..] QNAP in der Virtualization Station (VM).
Nach meiner Erfahrung ist eine "sehr gute" USB-Verbindung zwingende Voraussetzung, damit das Auslesen des Sticks vollständig funktioniert.
HUB, USB-Verlängerungen, Raspi-USB führten bei mir häufig zu den beschriebenen Timeout-Abbrüchen.
Und bei einer VM habe ich Zweifel, ob die USB-Verbindung stabil ist..
Gruß, Christian
Hallo Christian,
auf welchem Wege soll ich den Z-Wave USB Stick dann anschließen?
HUB, USB-Verlängerung, Raspi-USB hast du ausgeschlossen.
Ich hätte hier noch einen Intel NUC mit VMWare und einem recht nackten FHEM herum stehen.
Außerdem habe ich noch einen Raspberry Pi Zero WH auch mit recht nacktem FHEM laufen, jedoch müsste ich hier einen USB Adapter (Micro->USB) verwenden, was auch nicht förderlich wäre.
Kann ich den Stick evtl. direkt an einem Windows PC sichern und wiederherstellen? Evtl. auch ohne FHEM?
Gibt es da andere Hilfsmittel, die ich benutzen könnte?
Gruß
Mathze
ZitatHUB, USB-Verlängerung, Raspi-USB hast du ausgeschlossen.
Zu hart: Schließe ich nicht aus, aber waren bei mir tendenziell problematisch insbesondere auch in Kombinationen der vorgenannten. Letztlich musst Du einfach probieren.
Windows PC mit FHEM ging hier. Aber man muss FHEM bzw. -das eigentliche Problem- den Win-Serial-Treiber von Perl installiert bekommen.
Eventuell geht unter Win auch https://aeotec.freshdesk.com/support/solutions/articles/6000108806-z-stick-gen5-backup-software.
Einige berichten hier im Forum im Übrigen, dass ein Firmware-Update des UZB1 das "Einschlafen" behoben hat. Vielleicht solltest Du das auch einmal probieren.
Zitat von: krikan am 26 Februar 2019, 16:50:47
Einige berichten hier im Forum im Übrigen, dass ein Firmware-Update des UZB1 das "Einschlafen" behoben hat. Vielleicht solltest Du das auch einmal probieren.
Hast du diesbezüglich für mich einen Link?
Das würde ich gerne einmal ausprobieren.
An meinem Intel NUC mit nacktem FHEM (in VMWare) hat das backupCreate auch nicht funktioniert!
Gruß
Mathze
Schau bspw. mal ans Ende von https://forum.fhem.de/index.php/topic,87812.0.html
Anleitung in https://forum.fhem.de/index.php/topic,96563.0.html ; obwohl Du leider mit der vorsichtshalber durchgeführten Sicherung (backupCreate) Probleme haben wirst.
Moin Christian, hab mir alles durch gelesen, danke.
Den Stick zu updaten ist ja ein Akt.
In meinem eigentlichen Problem bringt es mich aber leider nicht weiter.
Ohne BackUp bekomme ich die Daten vom USB Stick nicht auf einen neuen USB Stick (falls der Stick mal komplett abraucht!).
Dementsprechend stehe ich weiterhin am Anfang.
Meine Idee wäre (ich weiß nicht, ob dies umsetzbar ist!):
Zweiten UZB1 Stick mit FHEM verbinden.
Danach jedes Z-Wave Device beim 1. Stick entfernen (removeNode) und beim 2. Stick hinzufügen (addNode).
Somit könnte ich alle Z-Wave Geräte langsam vom einen Stick zu anderen migrieren.
Gruß
Mathze
Zitat von: t1me2die am 26 Februar 2019, 18:46:43
Meine Idee wäre (ich weiß nicht, ob dies umsetzbar ist!):
Zweiten UZB1 Stick mit FHEM verbinden.
Danach jedes Z-Wave Device beim 1. Stick entfernen (removeNode) und beim 2. Stick hinzufügen (addNode).
Somit könnte ich alle Z-Wave Geräte langsam vom einen Stick zu anderen migrieren.
Das würde ich so nicht machen, sondern dann lieber Raspi usw. mit backupCreate testen. Dein Weg garantiert Dir bspw. nicht gleiche NodeIds, wenn Du jetzt Lücken zwischen den NodeIds hast. Zudem werden viele ZWave-Geraete durch removeNode resetet usw.
Habe hier -damit wir generelle Probleme ausschließen können- mit Win-PC und Raspi nur mit ZWave-Stick backupCreate erfolgreich getestet.
Hallo,
Ich hab das vor kurzem auch gemacht. Raspi 2B (soviel ich weiss ist es ein 2er und ich hab sicher den besseren gekauft, ich weiss aber nicht mehr zu 100% die exakte Bezeichnung) mit einem etwas älteren FHEM, hat wunderbar geklappt. Vielleicht benötigst du ein besseres Netzteil, wenn das vielleicht älter ist, oder eventuell das Kabel nicht das beste ist und ein zu hoher Spannungsabfall beim Backup vorkommt ....
Gäbe ein paar Möglichkeiten, die man Probieren kann.
Interessant wäre noch, passiert der Fehler immer an der gleichen Stelle?
Mir fällt im LOG noch etwas auf:
Funktionierender Read:
2019.02.26 16:10:30 4: ZWDongle_ReadAnswer for NVM_EXT_READ_LONG_BUFFER: 012a00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
Fehlerhafter Read:
2019.02.26 16:10:31 1: Z_Wave: wrong checksum: received 2a, computed d4 for 43012a00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000014301
Beim Fehler hat er vorne die 43 nicht abgeschnitten, wobei das vielelicht nur der LOG Eintrag ist, er sucht in der RegExp nach 012a.
Wenn der Fehler immer an der gleichen Stelle passiert, dann gibt es vielleicht einen Lesefehler und der wird nicht mehr korrigierbar sein.
Ausser man Liest Zeile für Zeile und hofft, dass der Fehler eine unbenutzte Speicherzelle ist.
BTW (etwas offtopic, aber wegen Firmwareupdate als lösung zu obigen Problem):
Kann man das Backup nach einem Firmwareupgrade wieder einspielen? oder ist in dem Speicherbereich die Firmware auch drinnen?
Danke für eure Tipps.
Ich habe leider keinen Raspberry Pi hier liegen, sondern nur ein Zero WH und einen Banana Pi.
Mein FHEM läuft wie gesagt in einer VM auf einem QNAP.
Ich setze nun ein neues Debian auf dem BananaPi auf, installiere dort ganz frisch FHEM und schließe lediglich den Z-Wave Stick an.
Falls das BackUp dann auch nicht klappt, werde ich mir was anderes überlegen oder das Thema begraben bis zu dem Zeitpunkt, bis mir der Stick komplett abraucht ;D
Ich werde berichten.
Erst einmal danke für eure Hilfe!
Gruß
Mathze
Zitat von: tux75at am 26 Februar 2019, 19:37:28
Kann man das Backup nach einem Firmwareupgrade wieder einspielen? oder ist in dem Speicherbereich die Firmware auch drinnen?
Das Firmwareupgrade hat bei mir sowohl beim UZB1 als auch beim Razberry verlustfrei funktioniert, d.h. alle Nodes noch vorhanden.
Das Rückschreiben von backupCreate-Dateien zwischen verschiedenen Firmwareversionen hatte ich beim UZB1 von 5.05 bis 5.2? (alles SDK 6.5) getestet und auf Anhieb kein Problem festgestellt. Garantieren mag ich das aber nicht; meine auch hier gab es gegenteilige Berichte. Da ist eventuell viel Glück dabei. Wo genau der Speicherbereich für die Firmware beginnt, ist mir unbekannt. Wenn Du Dich mit Hardware auskennst, kannst Du das eventuell aus der ZWave-Doku von Sigma erlesen.
Zitat von: t1me2die am 26 Februar 2019, 19:49:19
Danke für eure Tipps.
Ich habe leider keinen Raspberry Pi hier liegen, sondern nur ein Zero WH und einen Banana Pi.
Mein FHEM läuft wie gesagt in einer VM auf einem QNAP.
Schau Dir mal das oben verlinkte Aeotec Windows Programm an. Meiner dunklen Erinnerung nach habe ich damit damals zuerst den UZB1 gesichert/zurückgeschrieben. Mehr irgendwo in den Tiefen des Forums. Schimpf aber bitte nicht, wenn Du Elektroschrott produzierst, was ich aber so noch nicht geschafft habe.
Tja, was soll ich sagen?
DANKE!
Wie eben beschrieben habe ich kurz FHEM auf einem BananaPi M2 Berry mit Debian Image aufgesetzt (war das einzige Gerät, was ich zuhause hatte).
- Neuen UZB Stick angestöpselt
- backupCreate gestartet (wow, es lief tatsächlich durch! Wollte erstmal den neuen Stick testen, bevor ich meinen Produktionsstick anschließe!)
- UZB Stick abgezogen
- shutdown restart
- alten UZB Stick angestöpselt
- backupCreate gestartet (lief auch durch!)
- Neuen UZB Stick wieder angestöpselt
- BackUp vom alten UZB Stick per backupRestore gestartet (lief ohne Probleme durch!)
- neuen UZB Stick an die VM angeschlossen
- FHEM kurz neugestartet
- funktioniert!
Das war wirklich einfach, sobald das Backup funktioniert hatte!
Warum es innerhalb der VM nicht geklappt hat, kann man nun spekulieren.
Nichts desto trotz, recht herzlichen Dank!
Gruß
Mathze
@t1me2die
Ich hatte in der VM auch das Problem, dass mir das Backup immer austimed.
Versuch das Backupcreate doch mal wenn du dich via Telnet auf die FHEM Console verbindest.
Nur so war bei mir ein Backup erfolgreich.
VM unter Windows?
oder Virtualisiert ala Proxmox oder ähnlichem?
Mein System ist grad am Aufbauen. NUC mit Proxmox ist der Plan, da ich zur Zeit alles im Testbetrieb habe (Raspi mit einigen ZWave Devices und NUC Server zum herumspielen) sollte ich mir das auch ansehen "bevor" ich das brauche :)
Ich hatte Windows 10 auf dem NUC laufen.
Installiert hatte ich VirtualBox, jedoch bereiteten mir die USB Geräte teilweise Schwierigkeiten.
Gerade das durchrouten von Bluetooth Sticks erwies sich bei mir als Stolperstein. (wollte zwei USB Bluetooth Sticks an zwei verschiedene VM's durchreichen, jedoch hat Windows sich die Sticks gegriffen und automatisch verwendet..)
Ende vom Lied war, dass ich mit der VM (Virtualization Station) von QNAP besser zurecht kam wie mit VirtualBox.
Kann auch daran liegen, dass ich einfach auf die Kombination QNAP -> Virtualization Station eingespielt bin.
Gruß
Mathze
also grundsätzlich halte ich bei Virtualisierungsschichten ein Firmwareupdate immer für kritisch.
Denn es steckt ja quasi noch ein Kernel dazwischen, mit interrupts und zusätzlichen timeout möglichkeiten die man nicht vorhersagen kann.
@Mathze wenn du sowieso schon einen extra raspi aufgesetzt hast, dann kannst du auch gleich ein Firmwareupdate auch durchführen. Welche FW Version haben deine beiden Sticks denn ?
Ich habe einen BananaPi kurz aufgesetzt.
Der neuere UZB Stick hat 4.61.
Der ältere UZB Stick hat 4.06.
Ich weiß nicht, was die zur Zeit aktuellste Version ist.
Ich werde mich heute Abend wohl mal ransetzen und Z-Wave.me installieren, irgendwo hatte ich im Forum auch mal eine Anleitung gefunden gehabt... Finde das leider sehr aufwendig und umständlich ein Firmeware Update zu machen, aber gut muss man ja auch nicht so oft machen!
Gruß
Mathze
PS.: Hab deine Anleitung wiedergefunden. Werde ich heute Abend direkt mal ausprobieren :)
So ganz steige ich da nun nicht durch.
Der neue UZB Stick hat laut FHEM die Version: 4.61
Der alte UZB Stick hatte Version: 4.05
Habe nun den Z-Way-Server installiert und einfach mal ein Update angeworfen.
Augenscheinlich lief es auch durch.
Danach wieder an FHEM rangestöpselt und aus der Version 4.05 wurde tatsächlich
version Z-Wave 4.38 STATIC_CONTROLLER
Schön und gut, aber warum ist die Versionsnummer kleiner als der neue UZB Stick mit der Version 4.61?
Gruß
Mathze
Vorweg:
Die Firmwareversion steht im Reading caps am Anfang (Rückgabe von "get <ZWDongle> caps").
Im Reading version steht die SDK Id, die die SDK-Version angibt. Es gibt zum Teil mehrere Firmwareversione für ein SDK
Du hast bspw. folgende SDKs angeführt
4.05 = SDK 6.51.05
4.38 = SDK 6.51.09
4.61 = SDK 6.71.01
Zum Firmwareupdate:
In z-way bekommt man nicht sofort die aktuelleste Firmwareversion zum Update angeboten. Vielmehr muss man schrittweise updaten. Vermutlich bietet Dir z-way jetzt ein weiteres Firmwareupdate an.
Gruß, Christian
Hallo Christian,
danke für die Aufklärung.
Das muss man natürlich auch erstmal wissen.
Bin nun auf:
Vers:5 Rev:36 ManufID:0115 ProductType:0400 ProductID:0001
Z-Wave 6.02 STATIC_CONTROLLER
Werde den Stick wohl demnächst mal an die Produktion anstöpseln und schauen, was sich tut ;)
Erst einmal danke für die Hilfe!
Gruß
Mathze