FHEM Forum

FHEM - Hausautomations-Systeme => ZWave => Thema gestartet von: rudolfkoenig am 01 Mai 2016, 22:28:10

Titel: ZWDongle Sicherung
Beitrag von: rudolfkoenig am 01 Mai 2016, 22:28:10
Ich fang mal was Neues an, die andere Diskussion (https://forum.fhem.de/index.php/topic,52364.0.html) ist inzwischen voellig Off-Topic geworden.

freeusb hat mich zunaechst abgeschreckt, da in der Lizenzvereinbarung stand "This is not free software". Nun ja: ich habe es jetzt evaluiert. Damit ich es einfacher lesen kann, habe ich die Export-Datei des URB-Logs (.htm) durch den angehaengten perl-Skript gejagt.

Die Daten werden direkt mit NVM_EXT_READ_LONG_BUFFER gewonen, syntax: 2a O1 O2 O3 L1 L2, wobei Ox fuer Offset, und Lx fuer length steht. Einfach zu testen (mein Houscode habe ich mit x ersetzt):
fhem> get zwd raw 2a0000000010
zwd raw_2a0000000010 => 012a5a654e7359730000xxxxxxxx0a090807

Das Aeotec Backup Programm laeuft die Schleife von 0000 bis FFFF in (hex) 40-er Schritten 4-mal durch, wieso einmal nicht reicht, ist mir ein Raetsel. Vermutung: Programmierfehler, irgendwo wird uint_16 verwendet, und die aussere Schleife laeuft (mit uint_32) bis 256k.

1. Die Erzeugung einer Aeotec kompatiblen Backups aus FHEM aus sollte trivial sein, werde ich machen, wenn ich ein bisschen Zeit habe.
2. Wir muessten rausfinden, ob z.Bsp. ein ZME 64k oder 256k gesichert haben will. Aus dem USB-Log ist das fuer mich nicht ersichtlich, evtl. haengt das mit der abgefragten SERIAL_API_APPL_NODE_INFORMATION oder ZW_GET_NODE_PROTOCOL_INFO zusammen, und wird aus einer (uns nicht zur Verfuegung stehenden Tabelle) per Lookup festgestellt.
3. Ich muss noch ein Restore protokollieren, und dazu muss ich noch Mut sammeln :)
4. Zum Schluss brauchen wir "richtige" Tests, mir noch unklar, welche.
Titel: Antw:ZWDongle Sicherung
Beitrag von: krikan am 02 Mai 2016, 07:34:49
ZitatDamit ich es einfacher lesen kann, habe ich die Export-Datei des URB-Logs (.htm) durch den angehaengten perl-Skript gejagt.
Ok, verstanden  :) ; siehe Anlage zu Backup und Restore von Vision ZU1401-5. Restore-Log gehört zu einem anderem als dem angehängten Backup(-Log), weil das Perl-Script beim zugehörigen Backup-Log nichts schreibt. Hoffe, ist unproblematisch.

ZitatWir muessten rausfinden, ob z.Bsp. ein ZME 64k oder 256k gesichert haben will. Aus dem USB-Log ist das fuer mich nicht ersichtlich,
Beim Vision werden nur 2x64Kb = 128 KB gesichert. Warum?

Fände interessant, wie das Log für das Backup von einem AEOTEC Gen5-Stick aussieht.
Titel: Antw:ZWDongle Sicherung
Beitrag von: rudolfkoenig am 02 Mai 2016, 22:20:58
Ab sofort (bzw. update morgen) steht zur Verfuegung:
ZitatbackupCreate [64k|128k|256k]
    read out the NVRAM of the ZWDongle, and store it in a file called
    <ZWDongle_Name>.bin in the modpath folder.  Since the size of the
    NVRAM is currently unknown to FHEM, you have to specify the size. The ZWave
    ZME Stick seems to have 256k of NVRAM. Note: writing the file takes some
    time, usually about 10s for each 64k.

backupRestore
    Restore the file created by backupCreate. Restoring the file takes about
    the same time as saving it.

Getestet mit dem ZWave.me ZME USB Stick, ich habe 5-6 mal backupCreate gemacht (ohne Fehler, gleiches Ergebnis), und einmal backupRestore von 256k. Der Stick funktioniert danach, kann ein per Security angebundenes AS6 schalten auch nach abstecken/einstecken bzw. FHEM Neustart. Die ersten 64k der Datei sind (bis auf ein Byte) identisch mit dem Aeotec Backup.

ZitatBeim Vision werden nur 2x64Kb = 128 KB gesichert. Warum?
Wenn wir das rausfinden, dann koennen wir das Argument beim backupCreate einsparen. Ich habe NVM_GET_ID in Verdacht: der Vision liefert 03208011 zurueck, der ZME 03208012. 2^11*64 = 128k, und 2^12*64 = 256k. 64 Bytes ist die Einheit, mit dem Aeotec (und FHEM) die Daten liest und schreibt. Ok, gewagte Hypothese.

Mein Goodway kennt die NVM Kommandos nicht -> Kein Backup moeglich.

P.S.: Danke an Christian fuer die Vorarbeit :)

Titel: Antw:ZWDongle Sicherung
Beitrag von: Thyraz am 03 Mai 2016, 09:06:12
Ich hab zwei Razberry Zwave Module um bei einem Ausfall schnell reagieren zu können.

Ich kann die Tage mal testweise ob es mit dem Razberry Modul auch funktioniert.
Beim einen Stick ein neues Z-Wave Gerät anlernen -> Backup -> auf anderes Razberry Modul restoren.

Wie bekomme ich denn heraus was ich als NVRAM Größe angeben muss?
Titel: Antw:ZWDongle Sicherung
Beitrag von: rudolfkoenig am 03 Mai 2016, 12:02:36
Da bin ich noch unsicher, siehe Hypothese oben.

Ich wuerde mich freuen, wenn jeder mit einem hier noch nicht bekannten ZWDongle folgendes absetzt:
get ZWDongle_0 raw 29
und danach Ausgabe + ZWDongle Modellbezeichnung uns hier mitteilt. Ideal waere noch ein Versuch mit dem Aeotec Backup, und dann die Dateigroesse mitteilen.

Ich fange mal an:
Zwave.me ZME_UZB1:  raw_29 => 012903208012, Aeotec Backup Groesse: 256k
Viesion ZU_1401:         raw_29 => 012903208011, Aeotec Backup Groesse: 128k
Titel: Antw:ZWDongle Sicherung
Beitrag von: Thyraz am 03 Mai 2016, 12:18:50
Die Info bekomme ich für den Razberry (V5 / Zwave+ Variante) auch von hier per VPN raus. :)

012903208012 und somit wahrscheinlich auch die 256k wie beim UZB1.
Titel: Antw:ZWDongle Sicherung
Beitrag von: Thargor am 03 Mai 2016, 12:48:17

Aoetec Gen5: 012903208012
Titel: Antw:ZWDongle Sicherung
Beitrag von: jeep am 03 Mai 2016, 12:56:00
Hallo,


ZWDongle_Raz raw_29 => 012903208012

Ich versuchte ein Backup über socat zum RPI mit Razberry. Nach 256K wurde die Datei wieder auf 0 Byte gesetzt und fing wieder an zu wachsen. Aber nach kurzer Zeit ging die Verbindung verloren und ich vermute das socat sich verlaufen hat. Musste den RPI einfach neu starten, dann war die Verbindung wieder da.

Grüße,
Josef
Titel: Antw:ZWDongle Sicherung
Beitrag von: krikan am 03 Mai 2016, 15:27:59
Zitat
Vision ZU_1401:         raw_29 => 012903208011, Aeotec Backup Groesse: 128k
Das betrifft den Vision ZU_1401-5 mit 500er Sigma Chip und ZWave-Plus Zertifizierung. Der ZU_1401 ohne -5 hat nur einen 400er Chip und hat die notwendigen Sicherungs-Befehle nicht.
Titel: Antw:ZWDongle Sicherung
Beitrag von: krikan am 04 Mai 2016, 13:02:50
Sicherung scheitert leider bei mir sowohl mit UZB1 als auch VISION auf Produktiv-Raspi3- (raspbian) und Test-Win10-System immer mit einem TIMEOUT for ReadAnswer.

Beispiel-Log von Win10 für VISION:
2016.05.03 22:05:20.970 4: ZWDongle *** set ZWDongle_0 backupCreate 128k
2016.05.03 22:05:20.971 5: ZWDongle_Write 002a0000000040 ()
2016.05.03 22:05:20.971 5: SW: 0108002a00000000409d
2016.05.03 22:05:20.982 4: ZWDongle_ReadAnswer arg:NVM_EXT_READ_LONG_BUFFER regexp:^012a
2016.05.03 22:05:20.982 5: ACK received, removing 0108002a00000000409d from dongle sendstack
2016.05.03 22:05:20.983 4: ZWDongle_Read ZWDongle_0: rcvd 012a5a654e7359730000e068719200000000000000000054a50000000000000000000000000000000000000000000000000000000000000000000000000000000000 (answer NVM_EXT_READ_LONG_BUFFER), sending ACK
2016.05.03 22:05:20.983 5: SW: 06
2016.05.03 22:05:20.984 4: ZWDongle_ReadAnswer for NVM_EXT_READ_LONG_BUFFER: 012a5a654e7359730000e068719200000000000000000054a50000000000000000000000000000000000000000000000000000000000000000000000000000000000
2016.05.03 22:05:20.985 5: ZWDongle_Write 002a0000400040 ()
2016.05.03 22:05:20.985 5: SW: 0108002a0000400040dd
2016.05.03 22:05:20.987 4: ZWDongle_ReadAnswer arg:NVM_EXT_READ_LONG_BUFFER regexp:^012a
2016.05.03 22:05:20.987 5: ACK received, removing 0108002a0000400040dd from dongle sendstack
2016.05.03 22:05:21.993 4: ZWDongle_Read ZWDongle_0: rcvd 012a00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 (answer NVM_EXT_READ_LONG_BUFFER), sending ACK
2016.05.03 22:05:21.994 5: SW: 06
2016.05.03 22:05:21.996 4: ZWDongle_ReadAnswer for NVM_EXT_READ_LONG_BUFFER: 012a00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
2016.05.03 22:05:21.996 5: ZWDongle_Write 002a0000800040 ()
2016.05.03 22:05:21.996 5: SW: 0108002a00008000401d
2016.05.03 22:05:21.997 4: ZWDongle_ReadAnswer arg:NVM_EXT_READ_LONG_BUFFER regexp:^012a
2016.05.03 22:05:21.998 4: ZWDongle_Read ZWDongle_0: rcvd 012a00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 (answer NVM_EXT_READ_LONG_BUFFER), sending ACK
2016.05.03 22:05:21.998 5: SW: 06
2016.05.03 22:05:22.015 4: ZWDongle_ReadAnswer for NVM_EXT_READ_LONG_BUFFER: 012a00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
2016.05.03 22:05:22.015 5: ZWDongle_Write 002a0000c00040 ()
2016.05.03 22:05:22.015 4: ZWDongle_ReadAnswer arg:NVM_EXT_READ_LONG_BUFFER regexp:^012a
2016.05.03 22:05:22.015 5: ACK received, removing 0108002a00008000401d from dongle sendstack
2016.05.03 22:05:22.016 4: ZWDongle_Read ZWDongle_0: rcvd 012a00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 (answer NVM_EXT_READ_LONG_BUFFER), sending ACK
2016.05.03 22:05:22.016 5: SW: 06
2016.05.03 22:05:22.030 5: SW: 0108002a0000c000405d
2016.05.03 22:05:22.046 4: ZWDongle_ReadAnswer for NVM_EXT_READ_LONG_BUFFER: 012a00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
2016.05.03 22:05:22.046 5: ZWDongle_Write 002a0001000040 ()
2016.05.03 22:05:22.046 4: ZWDongle_ReadAnswer arg:NVM_EXT_READ_LONG_BUFFER regexp:^012a
2016.05.03 22:05:22.047 5: ACK received, removing 0108002a0000c000405d from dongle sendstack
2016.05.03 22:05:22.047 4: ZWDongle_Read ZWDongle_0: rcvd 012a0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000d316010201000000 (answer NVM_EXT_READ_LONG_BUFFER), sending ACK
2016.05.03 22:05:22.047 5: SW: 06
2016.05.03 22:05:22.061 5: SW: 0108002a00010000409c
2016.05.03 22:05:22.077 4: ZWDongle_ReadAnswer for NVM_EXT_READ_LONG_BUFFER: 012a0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000d316010201000000
2016.05.03 22:05:22.077 5: ZWDongle_Write 002a0001400040 ()
2016.05.03 22:05:22.078 4: ZWDongle_ReadAnswer arg:NVM_EXT_READ_LONG_BUFFER regexp:^012a
2016.05.03 22:05:22.078 5: ACK received, removing 0108002a00010000409c from dongle sendstack
2016.05.03 22:05:22.078 4: ZWDongle_Read ZWDongle_0: rcvd 012a00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 (answer NVM_EXT_READ_LONG_BUFFER), sending ACK
2016.05.03 22:05:22.078 5: SW: 06
2016.05.03 22:05:22.094 5: SW: 0108002a0001400040dc
2016.05.03 22:05:22.096 4: ZWDongle_ReadAnswer for NVM_EXT_READ_LONG_BUFFER: 012a00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
2016.05.03 22:05:22.096 5: ZWDongle_Write 002a0001800040 ()
2016.05.03 22:05:22.096 4: ZWDongle_ReadAnswer arg:NVM_EXT_READ_LONG_BUFFER regexp:^012a
2016.05.03 22:05:22.097 5: ACK received, removing 0108002a0001400040dc from dongle sendstack
2016.05.03 22:05:22.097 5: SW: 0108002a00018000401c
2016.05.03 22:05:22.102 4: ZWDongle_Read ZWDongle_0: rcvd 012a00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 (answer NVM_EXT_READ_LONG_BUFFER), sending ACK
2016.05.03 22:05:22.103 5: SW: 06
2016.05.03 22:05:22.115 4: ZWDongle_ReadAnswer for NVM_EXT_READ_LONG_BUFFER: 012a00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
2016.05.03 22:05:22.115 5: ZWDongle_Write 002a0001c00040 ()
2016.05.03 22:05:22.115 4: ZWDongle_ReadAnswer arg:NVM_EXT_READ_LONG_BUFFER regexp:^012a
2016.05.03 22:05:22.116 4: ZWDongle_Read ZWDongle_0: CAN received
2016.05.03 22:05:23.121 2: ZWDongle_ProcessSendStack: no ACK, resending message 0108002a00018000401c
2016.05.03 22:05:23.121 5: SW: 0108002a00018000401c
2016.05.03 22:05:23.129 5: ACK received, removing 0108002a00018000401c from dongle sendstack
2016.05.03 22:05:23.243 4: ZWDongle_Read ZWDongle_0: rcvd 012a00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 (answer NVM_EXT_READ_LONG_BUFFER), sending ACK
2016.05.03 22:05:23.243 5: SW: 06
2016.05.03 22:05:23.258 5: ZWDongle_0 dispatch 012a00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
2016.05.03 22:05:23.288 4: ZWDongle_0 unhandled ANSWER: NVM_EXT_READ_LONG_BUFFER 00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
2016.05.03 22:05:23.288 5: SW: 0108002a0001c000405c
2016.05.03 22:05:23.391 5: ACK received, removing 0108002a0001c000405c from dongle sendstack
2016.05.03 22:05:23.392 4: ZWDongle_Read ZWDongle_0: rcvd 012a00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 (answer NVM_EXT_READ_LONG_BUFFER), sending ACK
2016.05.03 22:05:23.392 5: SW: 06
2016.05.03 22:05:23.394 5: ZWDongle_0 dispatch 012a00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
2016.05.03 22:05:23.394 4: ZWDongle_0 unhandled ANSWER: NVM_EXT_READ_LONG_BUFFER 00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000

Titel: Antw:ZWDongle Sicherung
Beitrag von: jeep am 04 Mai 2016, 14:26:02
Habe Sicherung von 2 Stück UZB1 mit Raspi 2 mehrmals getestet. Das hat immer funktioniert, nur mein Razberry über socat bekomme ich nicht hin. Da verliere ich nach ca 3 Minuten die Verbindung.
Restore habe ich noch nicht getestet, denke das ich das morgen nachhole.

Grüße,
Josef
Titel: Antw:ZWDongle Sicherung
Beitrag von: krikan am 04 Mai 2016, 14:49:21
Zitat von: jeep am 04 Mai 2016, 14:26:02
Habe Sicherung von 2 Stück UZB1 mit Raspi 2 mehrmals getestet.  Das hat immer funktioniert,
Warum nur immer bei mir nicht   >:(  !? Aber gut, wenn es bei Euch läuft; und ich schaue/probiere bei mir mal weiter.

Habe mal nach den Chipsätzen/Flashspeichergößen der Sticks gesucht:
Vision ZU1401-5 nutzt laut Hersteller als Chip einen ZM5101a mit einen Flashspeicher von 128 kb.
UZB1 soll laut Internet den Chipsatz SD3503 ohne eingebauten Flashspeicher haben.
AEOTEC Gen5 finde ich keine Infos zum Chipsatz
Titel: Antw:ZWDongle Sicherung
Beitrag von: jeep am 04 Mai 2016, 21:24:38
Hallo Christian,

ich habe mal das log mit verbose 5 mitlaufen lassen. Nach dem üblichen Timeout der Webseite habe ich den RPI neu gestartet und mir das Log genauer angeschaut. In dem log gibt es 4 timeouts und immer nachdem kurz vorher ein notify oder andere events getriggert wurden.  Das muss aber nicht der gleiche Fehler sein den Du mit dem ReadAnswer hast. Ich vermute das meine Timeouts mit der socat Verbindung zum RaZberry zu tun haaben? :-[
Frage an Rudi - kann man fhem vor dem Backup mitteilen dass es nicht auf die ganzen events lauschen soll? Vielleicht wäre dass hilfreich. Zumindest für meine übers Netz Sicherung.

Ich häng mal die 4 Stellen aus dem log, die ich in Verdacht habe hier an.


: SW: 06
2016.05.04 14:49:00 4: ZWDongle_ReadAnswer for NVM_EXT_READ_LONG_BUFFER: 012affffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
2016.05.04 14:49:00 5: ZWDongle_Write 002a00fa400040 ()
2016.05.04 14:49:00 5: SW: 0108002a00fa40004027
2016.05.04 14:49:00 4: ZWDongle_ReadAnswer arg:NVM_EXT_READ_LONG_BUFFER regexp:^012a
2016.05.04 14:49:00 5: ACK received, removing 0108002a00fa40004027 from dongle sendstack
2016.05.04 14:49:00 4: ZWDongle_Read ZWDongle_Raz: rcvd 012affffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff (answer NVM_EXT_READ_LONG_BUFFER), sending ACK
2016.05.04 14:49:00 5: SW: 06
2016.05.04 14:49:00 4: ZWDongle_ReadAnswer for NVM_EXT_READ_LONG_BUFFER: 012affffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
2016.05.04 14:49:00 5: ZWDongle_Write 002a00fa800040 ()
2016.05.04 14:49:00 5: SW: 0108002a00fa800040e7
2016.05.04 14:49:00 4: ZWDongle_ReadAnswer arg:NVM_EXT_READ_LONG_BUFFER regexp:^012a
2016.05.04 14:49:00 5: ACK received, removing 0108002a00fa800040e7 from dongle sendstack
2016.05.04 14:49:00 4: ZWDongle_Read ZWDongle_Raz: rcvd 012affffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff (answer NVM_EXT_READ_LONG_BUFFER), sending ACK
2016.05.04 14:49:00 5: SW: 06
2016.05.04 14:49:00 4: ZWDongle_ReadAnswer for NVM_EXT_READ_LONG_BUFFER: 012affffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
2016.05.04 14:49:00 5: ZWDongle_Write 002a00fac00040 ()
2016.05.04 14:49:00 5: SW: 0108002a00fac00040a7
2016.05.04 14:49:00 4: ZWDongle_ReadAnswer arg:NVM_EXT_READ_LONG_BUFFER regexp:^012a
2016.05.04 14:49:00 4: ZWDongle_Read ZWDongle_Raz: rcvd 0004000706310504220000 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.05.04 14:49:00 5: SW: 06
2016.05.04 14:49:00 5: ZWDongle_Raz dispatch 0004000706310504220000
2016.05.04 14:49:00 4: CMD:APPLICATION_COMMAND_HANDLER ID:07 ARG:06310504220000 CB:00
2016.05.04 14:49:00 5: Triggering ZSt1 (1 changes)
2016.05.04 14:49:00 5: Starting notify loop for ZSt1, first event power: 0.0 W
2016.05.04 14:49:00 4: ZWDongle_Read ZWDongle_Raz: CAN received
2016.05.04 14:49:01 5: ZWDongle_ReadAnswer: select timeout
2016.05.04 14:49:01 2: ZWDongle_ProcessSendStack: no ACK, resending message 0108002a00fac00040a7
2016.05.04 14:49:01 5: SW: 0108002a00fac00040a7
2016.05.04 14:49:01 5: ACK received, removing 0108002a00fac00040a7 from dongle sendstack
2016.05.04 14:49:01 4: ZWDongle_Read ZWDongle_Raz: rcvd 012affffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff (answer NVM_EXT_READ_LONG_BUFFER), sending ACK
2016.05.04 14:49:01 5: SW: 06

*-*-*-*-*-*-*-*-*-*-*--*

2016.05.04 14:50:58 5: SW: 06
2016.05.04 14:50:58 5: ZWDongle_Raz dispatch 0004002403200100
2016.05.04 14:50:58 4: CMD:APPLICATION_COMMAND_HANDLER ID:24 ARG:03200100 CB:00
2016.05.04 14:50:58 5: Triggering TFS3 (1 changes)
2016.05.04 14:50:58 5: Starting notify loop for TFS3, first event basicSet: 00
2016.05.04 14:50:58 5: Cmd: >set ZSt4 off<
2016.05.04 14:50:58 2: ZWave set ZSt4 off
2016.05.04 14:50:58 5: ZWDongle_Write 0013290325010025c3 (ce68a7ac)
2016.05.04 14:50:58 2: ZWDongle_ProcessSendStack: no ACK, resending message 0108002a0268400040b7
2016.05.04 14:50:58 5: SW: 0108002a0268400040b7
2016.05.04 14:50:58 5: Triggering ZSt4 (1 changes)
2016.05.04 14:50:58 5: Starting notify loop for ZSt4, first event off
2016.05.04 14:50:58 5: Cmd: >set FensterKueche zu<
2016.05.04 14:50:58 4: dummy set FensterKueche zu
2016.05.04 14:50:58 5: Triggering FensterKueche (1 changes)
2016.05.04 14:50:58 5: Starting notify loop for FensterKueche, first event zu
2016.05.04 14:50:58 5: Triggering Dampfabzug_statDI (4 changes)
2016.05.04 14:50:58 5: Starting notify loop for Dampfabzug_statDI, first event cmd_nr: 2
2016.05.04 14:50:58 5: ACK received, removing 0108002a0268400040b7 from dongle sendstack
2016.05.04 14:50:58 5: SW: 010a0013290325010025c30e
2016.05.04 14:50:58 4: ZWDongle_Read ZWDongle_Raz: rcvd 012a0908070605040302010024232221201f1e1d1c1b1a191817161514131211100f0e0d0c0b0a0908070605040302010024232221201f1e1d1c1b1a191817161514 (answer NVM_EXT_READ_LONG_BUFFER), sending ACK
2016.05.04 14:50:58 5: SW: 06
2016.05.04 14:50:58 4: ZWDongle_ReadAnswer for NVM_EXT_READ_LONG_BUFFER: 012a0908070605040302010024232221201f1e1d1c1b1a191817161514131211100f0e0d0c0b0a0908070605040302010024232221201f1e1d1c1b1a191817161514
2016.05.04 14:50:58 5: ZWDongle_Write 002a0268800040 ()
2016.05.04 14:50:58 4: ZWDongle_ReadAnswer arg:NVM_EXT_READ_LONG_BUFFER regexp:^012a
2016.05.04 14:50:59 5: ZWDongle_ReadAnswer: select timeout
2016.05.04 14:50:59 4: name: /fhem&detail=ZWDongle_Raz&dev.setZWDongle_Raz=ZWDongle_Raz&cmd.setZWDongle_Raz=set&arg.setZWDongle_Raz=backupCreate&val.setZWDongle_Raz=256k / RL:1190 / text/html; charset=UTF-8 / Content-Encoding: gzip
/
2016.05.04 14:50:59 4: Closing inactive connection WEB_192.168.110.116_57192
2016.05.04 14:50:59 2: ZWDongle_ProcessSendStack: no ACK, resending message 010a0013290325010025c30e
2016.05.04 14:50:59 5: SW: 010a0013290325010025c30e
2016.05.04 14:50:59 4: Connection accepted from WEB_192.168.110.116_57226
2016.05.04 14:50:59 5: ACK received, WaitForAck=>2 for 010a0013290325010025c30e
2016.05.04 14:50:59 4: Connection closed for WEB_192.168.110.116_56774: EOF
2016.05.04 14:50:59 4: Connection accepted from WEB_192.168.110.116_57244
2016.05.04 14:50:59 4: WEB_192.168.110.116_57226 GET /fhem/FileLog_logWrapper?dev=Logfile&type=text&file=fhem-2016-05.log; BUFLEN:0
2016.05.04 14:50:59 4: WEB_192.168.110.116_57244 POST /fhem&detail=ZWDongle_Raz&dev.setZWDongle_Raz=ZWDongle_Raz&cmd.setZWDongle_Raz=set&arg.setZWDongle_Raz=backupCreate&val.setZWDongle_Raz=256k; BUFLEN:0
2016.05.04 14:50:59 5: Cmd: >set ZWDongle_Raz backupCreate 256k<
2016.05.04 14:50:59 4: ZWDongle *** set ZWDongle_Raz backupCreate 256k
2016.05.04 14:50:59 5: ZWDongle_Write 002a0000000040 ()
2016.05.04 14:50:59 4: ZWDongle_ReadAnswer arg:NVM_EXT_READ_LONG_BUFFER regexp:^012a
2016.05.04 14:50:59 4: ZWDongle_Read ZWDongle_Raz: rcvd 011301 (answer ZW_SEND_DATA), sending ACK
2016.05.04 14:50:59 5: SW: 06
2016.05.04 14:50:59 5: ZWDongle_Raz dispatch 011301
2016.05.04 14:50:59 4: ZWDongle_Read ZWDongle_Raz: rcvd 0013c3000002 (request ZW_SEND_DATA), sending ACK
2016.05.04 14:50:59 5: SW: 06
2016.05.04 14:50:59 5: device ack reveived, removing 010a0013290325010025c30e from dongle sendstack
2016.05.04 14:50:59 5: ZWDongle_Raz dispatch 0013c3000002
2016.05.04 14:50:59 4: CMD:ZW_SEND_DATA ID:00 ARG:0002 CB:c3
2016.05.04 14:50:59 4: ZWDongle_Raz transmit OK for CB c3, target ZSt4
2016.05.04 14:50:59 5: SW: 0108002a026880004077
2016.05.04 14:50:59 5: ACK received, removing 0108002a026880004077 from dongle sendstack
2016.05.04 14:50:59 5: SW: 0108002a00000000409d
2016.05.04 14:50:59 4: ZWDongle_Read ZWDongle_Raz: rcvd 012affffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff (answer NVM_EXT_READ_LONG_BUFFER), sending ACK
2016.05.04 14:50:59 5: SW: 06
2016.05.04 14:50:59 4: ZWDongle_ReadAnswer for NVM_EXT_READ_LONG_BUFFER: 012affffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
2016.05.04 14:50:59 5: ZWDongle_Write 002a0000400040 ()
2016.05.04 14:50:59 4: ZWDongle_ReadAnswer arg:NVM_EXT_READ_LONG_BUFFER regexp:^012a
2016.05.04 14:51:00 4: ZWDongle_Read ZWDongle_Raz: CAN received
2016.05.04 14:51:00 4: ZWDongle_Read ZWDongle_Raz: rcvd 0004002906310504220005 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.05.04 14:51:00 5: SW: 06
2016.05.04 14:51:00 5: ZWDongle_Raz dispatch 0004002906310504220005
2016.05.04 14:51:00 4: CMD:APPLICATION_COMMAND_HANDLER ID:29 ARG:06310504220005 CB:00
2016.05.04 14:51:00 5: Triggering ZSt4 (1 changes)
2016.05.04 14:51:00 5: Starting notify loop for ZSt4, first event power: 0.5 W
2016.05.04 14:51:00 2: ZWDongle_ProcessSendStack: no ACK, resending message 0108002a00000000409d
2016.05.04 14:51:00 5: SW: 0108002a00000000409d
2016.05.04 14:51:00 5: ACK received, removing 0108002a00000000409d from dongle sendstack
2016.05.04 14:51:00 5: SW: 0108002a0000400040dd
2016.05.04 14:51:00 4: ZWDongle_Read ZWDongle_Raz: rcvd 012a5a654e7359730000ce68a7ac0a090807000000000054a50000000000000000000000000000000000000000000000000000000000000000000000000000000000 (answer NVM_EXT_READ_LONG_BUFFER), sending ACK
2016.05.04 14:51:00 5: SW: 06

*-*-*-*-*-**-*-*-*-*-*

2016.05.04 14:50:59 5: SW: 06
2016.05.04 14:50:59 5: device ack reveived, removing 010a0013290325010025c30e from dongle sendstack
2016.05.04 14:50:59 5: ZWDongle_Raz dispatch 0013c3000002
2016.05.04 14:50:59 4: CMD:ZW_SEND_DATA ID:00 ARG:0002 CB:c3
2016.05.04 14:50:59 4: ZWDongle_Raz transmit OK for CB c3, target ZSt4
2016.05.04 14:50:59 5: SW: 0108002a026880004077
2016.05.04 14:50:59 5: ACK received, removing 0108002a026880004077 from dongle sendstack
2016.05.04 14:50:59 5: SW: 0108002a00000000409d
2016.05.04 14:50:59 4: ZWDongle_Read ZWDongle_Raz: rcvd 012affffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff (answer NVM_EXT_READ_LONG_BUFFER), sending ACK
2016.05.04 14:50:59 5: SW: 06
2016.05.04 14:50:59 4: ZWDongle_ReadAnswer for NVM_EXT_READ_LONG_BUFFER: 012affffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
2016.05.04 14:50:59 5: ZWDongle_Write 002a0000400040 ()
2016.05.04 14:50:59 4: ZWDongle_ReadAnswer arg:NVM_EXT_READ_LONG_BUFFER regexp:^012a
2016.05.04 14:51:00 4: ZWDongle_Read ZWDongle_Raz: CAN received
2016.05.04 14:51:00 4: ZWDongle_Read ZWDongle_Raz: rcvd 0004002906310504220005 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.05.04 14:51:00 5: SW: 06
2016.05.04 14:51:00 5: ZWDongle_Raz dispatch 0004002906310504220005
2016.05.04 14:51:00 4: CMD:APPLICATION_COMMAND_HANDLER ID:29 ARG:06310504220005 CB:00
2016.05.04 14:51:00 5: Triggering ZSt4 (1 changes)
2016.05.04 14:51:00 5: Starting notify loop for ZSt4, first event power: 0.5 W
2016.05.04 14:51:00 2: ZWDongle_ProcessSendStack: no ACK, resending message 0108002a00000000409d
2016.05.04 14:51:00 5: SW: 0108002a00000000409d
2016.05.04 14:51:00 5: ACK received, removing 0108002a00000000409d from dongle sendstack
2016.05.04 14:51:00 5: SW: 0108002a0000400040dd
2016.05.04 14:51:00 4: ZWDongle_Read ZWDongle_Raz: rcvd 012a5a654e7359730000ce68a7ac0a090807000000000054a50000000000000000000000000000000000000000000000000000000000000000000000000000000000 (answer NVM_EXT_READ_LONG_BUFFER), sending ACK
2016.05.04 14:51:00 5: SW: 06
2016.05.04 14:51:00 4: ZWDongle_ReadAnswer for NVM_EXT_READ_LONG_BUFFER: 012a5a654e7359730000ce68a7ac0a090807000000000054a50000000000000000000000000000000000000000000000000000000000000000000000000000000000
2016.05.04 14:51:00 5: ZWDongle_Write 002a0000800040 ()
2016.05.04 14:51:00 4: ZWDongle_ReadAnswer arg:NVM_EXT_READ_LONG_BUFFER regexp:^012a
2016.05.04 14:51:01 5: ZWDongle_ReadAnswer: select timeout
2016.05.04 14:51:01 4: name: /fhem&detail=ZWDongle_Raz&dev.setZWDongle_Raz=ZWDongle_Raz&cmd.setZWDongle_Raz=set&arg.setZWDongle_Raz=backupCreate&val.setZWDongle_Raz=256k / RL:1190 / text/html; charset=UTF-8 / Content-Encoding: gzip
/
2016.05.04 14:52:20 2: ZWDongle_ProcessSendStack: no ACK, resending message 0108002a0000400040dd
2016.05.04 14:52:20 5: SW: 0108002a0000400040dd
2016.05.04 14:52:20 4: Closing inactive connection WEB_192.168.110.116_57244
2016.05.04 14:52:20 4: Closing inactive connection WEB_192.168.110.116_57226
2016.05.04 14:52:20 4: Connection accepted from WEB_192.168.110.116_57245
2016.05.04 14:52:20 4: ZWDongle_Read ZWDongle_Raz: rcvd 0004001f0756013003ffd1cb (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.05.04 14:52:20 5: SW: 06

*-*-*-*-*-*-*-*-*

2016.05.04 15:07:27 5: SW: 06
2016.05.04 15:07:27 5: ZWDongle_Raz dispatch 0004001f07600d0101200100
2016.05.04 15:07:27 4: CMD:APPLICATION_COMMAND_HANDLER ID:1f ARG:07600d0101200100 CB:00
2016.05.04 15:07:27 5: Triggering ZWave_Node_31.1 (1 changes)
2016.05.04 15:07:27 5: Starting notify loop for ZWave_Node_31.1, first event basicSet: 00
2016.05.04 15:07:27 2: ZWDongle_ProcessSendStack: no ACK, resending message 0108002a0021c000407c
2016.05.04 15:07:27 5: SW: 0108002a0021c000407c
2016.05.04 15:07:27 5: ACK received, removing 0108002a0021c000407c from dongle sendstack
2016.05.04 15:07:27 4: ZWDongle_Read ZWDongle_Raz: rcvd 012a00000000000000000000000037015e2086725a5985738480715670318e22309c987a090300000000000000000000000000000000000000002901728670858e25 (answer NVM_EXT_READ_LONG_BUFFER), sending ACK
2016.05.04 15:07:27 5: SW: 06
2016.05.04 15:07:27 4: ZWDongle_ReadAnswer for NVM_EXT_READ_LONG_BUFFER: 012a00000000000000000000000037015e2086725a5985738480715670318e22309c987a090300000000000000000000000000000000000000002901728670858e25
2016.05.04 15:07:27 5: ZWDongle_Write 002a0022000040 ()
2016.05.04 15:07:27 5: SW: 0108002a0022000040bf
2016.05.04 15:07:27 4: ZWDongle_ReadAnswer arg:NVM_EXT_READ_LONG_BUFFER regexp:^012a
2016.05.04 15:07:27 5: ACK received, removing 0108002a0022000040bf from dongle sendstack
2016.05.04 15:07:27 4: ZWDongle_Read ZWDongle_Raz: rcvd 012a7332317aef2532310000000000001f0300000000000000000000000000000000000000000703308485808f567286708e319cef30319c00000000280330848580 (answer NVM_EXT_READ_LONG_BUFFER), sending ACK
2016.05.04 15:07:27 5: SW: 06
2016.05.04 15:07:27 4: ZWDongle_ReadAnswer for NVM_EXT_READ_LONG_BUFFER: 012a7332317aef2532310000000000001f0300000000000000000000000000000000000000000703308485808f567286708e319cef30319c00000000280330848580
2016.05.04 15:07:27 5: ZWDongle_Write 002a0022400040 ()
2016.05.04 15:07:27 5: SW: 0108002a0022400040ff
2016.05.04 15:07:27 4: ZWDongle_ReadAnswer arg:NVM_EXT_READ_LONG_BUFFER regexp:^012a
2016.05.04 15:07:27 4: ZWDongle_Read ZWDongle_Raz: rcvd 0004001f0a56013105030a001325c3 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.05.04 15:07:27 5: SW: 06
2016.05.04 15:07:27 5: ZWDongle_Raz dispatch 0004001f0a56013105030a001325c3
2016.05.04 15:07:27 4: CMD:APPLICATION_COMMAND_HANDLER ID:1f ARG:0a56013105030a001325c3 CB:00
2016.05.04 15:07:27 5: Triggering Fib_MS2 (1 changes)
2016.05.04 15:07:27 5: Starting notify loop for Fib_MS2, first event luminance: 19 Lux
2016.05.04 15:07:27 4: ZWDongle_Read ZWDongle_Raz: CAN received
2016.05.04 15:07:28 5: ZWDongle_ReadAnswer: select timeout
2016.05.04 15:07:28 2: ZWDongle_ProcessSendStack: no ACK, resending message 0108002a0022400040ff
2016.05.04 15:07:28 5: SW: 0108002a0022400040ff
2016.05.04 15:07:28 5: ACK received, removing 0108002a0022400040ff from dongle sendstack
2016.05.04 15:07:28 4: ZWDongle_Read ZWDongle_Raz: rcvd 012a8f567286708e319cef30319c000000001c03308485808f567286708e319cef30319c000000000801728670858e6025277a73ef25600000000000000009030000 (answer NVM_EXT_READ_LONG_BUFFER), sending ACK
2016.05.04 15:07:28 5: SW: 06
2016.05.04 15:07:28 4: ZWDongle_ReadAnswer for NVM_EXT_READ_LONG_BUFFER: 012a8f567286708e319cef30319c000000001c03308485808f567286708e319cef30319c000000000801728670858e6025277a73ef25600000000000000009030000
2016.05.04 15:07:28 5: ZWDongle_Write 002a0022800040 ()
2016.05.04 15:07:28 5: SW: 0108002a00228000403f
2016.05.04 15:07:28 4: ZWDongle_ReadAnswer arg:NVM_EXT_READ_LONG_BUFFER regexp:^012a
2016.05.04 15:07:28 5: ACK received, removing 0108002a00228000403f from dongle sendstack
2016.05.04 15:07:28 4: ZWDongle_Read ZWDongle_Raz: rcvd 012a0000000000000000000000000000000000000a0200000000000000000000000000000000000000000a0200000000000000000000000000000000000000002a01 (answer NVM_EXT_READ_LONG_BUFFER), sending ACK
2016.05.04 15:07:28 5: SW: 06
2016.05.04 15:07:28 4: ZWDongle_ReadAnswer for NVM_EXT_READ_LONG_BUFFER: 012a0000000000000000000000000000000000000a0200000000000000000000000000000000000000000a0200000000000000000000000000000000000000002a01
2016.05.04 15:07:28 5: ZWDongle_Write 002a0022c00040 ()
2016.05.04 15:07:28 5: SW: 0108002a0022c000407f
2016.05.04 15:07:28 4: ZWDongle_ReadAnswer arg:NVM_EXT_READ_LONG_BUFFER regexp:^012a
2016.05.04 15:07:28 5: ACK received, removing 0108002a0022c000407f from dongle sendstack
2016.05.04 15:07:28 4: ZWDongle_Read ZWDongle_Raz: rcvd 012a72867085257332317a259175ef3231912b2625002b01207072857386000000000000000000000000000006020000000000000000000000000000000000000000 (answer NVM_EXT_READ_LONG_BUFFER), sending ACK
2016.05.04 15:07:28 5: SW: 06
 

Grüße,
Josef
Titel: Antw:ZWDongle Sicherung
Beitrag von: jeep am 05 Mai 2016, 13:57:48
Restore vom UZB1 im 1. Testsystem war erfogreich. 

Restored 262144 bytes from ./ZWDongle_0.bin

Wenn jetzt noch das Backup meines RaZberry über socat funktionieren würde...

Grüße,
Josef
Titel: Antw:ZWDongle Sicherung
Beitrag von: rudolfkoenig am 05 Mai 2016, 18:07:40
Ich habe jetzt eine Weile lang mit Windows gespielt, und ein bei Windows fehlende Fehlerbehandlung nachgezogen. Damit kann ich auf einem Win7 VM oefters einen Backup erstellen, leider gibt es immer noch einzelne Abbrueche mit Timeouts. Normaler Funkverkehr fuehrt aber nicht mehr zum Abbruch wie frueher, Meldung im Log (no ACK, resending) gibts fuer sowas aber weiterhin. Merkwuerdig: Backup dauert unter Windows 4-mal laenger als sonst, evtl. liegt das an dem VM.
Titel: Antw:ZWDongle Sicherung
Beitrag von: krikan am 05 Mai 2016, 20:44:18
Danke. Unter Windows funktioniert es jetzt bei mir problemlos. Langsam ist relativ im Vergleich zu AEOTEC Backup (mit über 10 Minuten) ist FHEM mit 20 Sekunden rasend schnell.  :)
Titel: Antw:ZWDongle Sicherung
Beitrag von: jeep am 06 Mai 2016, 12:33:58
Zitat von: rudolfkoenig am 05 Mai 2016, 18:07:40
Ich habe jetzt eine Weile lang mit Windows gespielt, und ein bei Windows fehlende Fehlerbehandlung nachgezogen. Damit kann ich auf einem Win7 VM oefters einen Backup erstellen, leider gibt es immer noch einzelne Abbrueche mit Timeouts. Normaler Funkverkehr fuehrt aber nicht mehr zum Abbruch wie frueher, Meldung im Log (no ACK, resending) gibts fuer sowas aber weiterhin. Merkwuerdig: Backup dauert unter Windows 4-mal laenger als sonst, evtl. liegt das an dem VM.

Hilfe!
Ich verstehe nicht was bei mir schiefläuft. Die Sicherung meines Razberry übers Netz bekomme ich einfach nicht hin. Nachdem 256k geschrieben wurden (ich hatte ein 'watch  ls -l'  in einer console mit laufen) fing die Datei wieder bei 0 Bytes an.

Im Log sieht man dass nach ca 5 Minuten der Backup Befehl wieder abgesetzt wird, alles von vorne beginnt und die gleichen Daten wieder gelesen/geschrieben wurden, ohne jede andere Auffälligkeit. Ich hatte das verbose 5 diesmal nur auf dem Dongle.


2016.05.06 11:34:22 4: ZWDongle *** set ZWDongle_Raz backupCreate 256k
2016.05.06 11:34:22 5: ZWDongle_Write 002a0000000040 ()
2016.05.06 11:34:22 5: SW: 0108002a00000000409d
2016.05.06 11:34:22 4: ZWDongle_ReadAnswer arg:NVM_EXT_READ_LONG_BUFFER regexp:^012a
2016.05.06 11:34:22 5: ACK received, removing 0108002a00000000409d from dongle sendstack
2016.05.06 11:34:22 4: ZWDongle_Read ZWDongle_Raz: rcvd 012a5a654e7359730000ce68a7ac0a090807000000000054a50000000000000000000000000000000000000000000000000000000000000000000000000000000000 (answer NVM_EXT_READ_LONG_BUFFER), sending ACK
2016.05.06 11:34:22 5: SW: 06
2016.05.06 11:34:22 4: ZWDongle_ReadAnswer for NVM_EXT_READ_LONG_BUFFER: 012a5a654e7359730000ce68a7ac0a090807000000000054a50000000000000000000000000000000000000000000000000000000000000000000000000000000000
2016.05.06 11:34:22 5: ZWDongle_Write 002a0000400040 ()
2016.05.06 11:34:22 5: SW: 0108002a0000400040dd
2016.05.06 11:34:22 4: ZWDongle_ReadAnswer arg:NVM_EXT_READ_LONG_BUFFER regexp:^012a
2016.05.06 11:34:22 5: ACK received, removing 0108002a0000400040dd from dongle sendstack
2016.05.06 11:34:22 4: ZWDongle_Read ZWDongle_Raz: rcvd 012a00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 (answer NVM_EXT_READ_LONG_BUFFER), sending ACK
2016.05.06 11:34:22 5: SW: 06
2016.05.06 11:34:22 4: ZWDongle_ReadAnswer for NVM_EXT_READ_LONG_BUFFER: 012a00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
2016.05.06 11:34:22 5: ZWDongle_Write 002a0000800040 ()
2016.05.06 11:34:22 5: SW: 0108002a00008000401d
2016.05.06 11:34:22 4: ZWDongle_ReadAnswer arg:NVM_EXT_READ_LONG_BUFFER regexp:^012a
2016.05.06 11:34:22 5: ACK received, removing 0108002a00008000401d from dongle sendstack
2016.05.06 11:34:22 4: ZWDongle_Read ZWDongle_Raz: rcvd 012a00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 (answer NVM_EXT_READ_LONG_BUFFER), sending ACK
2016.05.06 11:34:22 5: SW: 06

[...]

2016.05.06 11:39:11 4: ZWDongle_ReadAnswer arg:NVM_EXT_READ_LONG_BUFFER regexp:^012a
2016.05.06 11:39:11 5: ACK received, removing 0108002a03ffc00040a1 from dongle sendstack
2016.05.06 11:39:11 4: ZWDongle_Read ZWDongle_Raz: rcvd 012affffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff (answer NVM_EXT_READ_LONG_BUFFER), sending ACK
2016.05.06 11:39:11 5: SW: 06
2016.05.06 11:39:11 4: ZWDongle_ReadAnswer for NVM_EXT_READ_LONG_BUFFER: 012affffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
2016.05.06 11:39:11 3: ZWDongle_Raz backupCreate at 262144 bytes
2016.05.06 11:39:11 4: ZWDongle *** set ZWDongle_Raz backupCreate 256k
2016.05.06 11:39:11 5: ZWDongle_Write 002a0000000040 ()
2016.05.06 11:39:11 5: SW: 0108002a00000000409d
2016.05.06 11:39:11 4: ZWDongle_ReadAnswer arg:NVM_EXT_READ_LONG_BUFFER regexp:^012a
2016.05.06 11:39:11 5: ACK received, removing 0108002a00000000409d from dongle sendstack
2016.05.06 11:39:11 4: ZWDongle_Read ZWDongle_Raz: rcvd 012a5a654e7359730000ce68a7ac0a090807000000000054a50000000000000000000000000000000000000000000000000000000000000000000000000000000000 (answer NVM_EXT_READ_LONG_BUFFER), sending ACK
2016.05.06 11:39:11 5: SW: 06
2016.05.06 11:39:11 4: ZWDongle_ReadAnswer for NVM_EXT_READ_LONG_BUFFER: 012a5a654e7359730000ce68a7ac0a090807000000000054a50000000000000000000000000000000000000000000000000000000000000000000000000000000000
2016.05.06 11:39:11 5: ZWDongle_Write 002a0000400040 ()
2016.05.06 11:39:11 5: SW: 0108002a0000400040dd
2016.05.06 11:39:11 4: ZWDongle_ReadAnswer arg:NVM_EXT_READ_LONG_BUFFER regexp:^012a
2016.05.06 11:39:11 5: ACK received, removing 0108002a0000400040dd from dongle sendstack
2016.05.06 11:39:11 4: ZWDongle_Read ZWDongle_Raz: rcvd 012a00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 (answer NVM_EXT_READ_LONG_BUFFER), sending ACK
2016.05.06 11:39:11 5: SW: 06


Grüße,
Josef
Titel: Antw:ZWDongle Sicherung
Beitrag von: rudolfkoenig am 06 Mai 2016, 12:49:44
Versuch bitte das Backup nicht aus dem Browser zu starten, und berichte.
Titel: Antw:ZWDongle Sicherung
Beitrag von: jeep am 06 Mai 2016, 14:13:09
Hallo Rudi,

wunderbar ich hab ein Backup :) :) :) :) :) :) :) :)
Ich denke ich habe dich richtig interpretiert. Habe "set ZWDongle_Raz backupCreate 256k" oben in dem weßen Feld eingegben und siehe da, nach 262144 Bytes hat es diesmal aufgehört. Die Verbindung im Browser war dann zur gleichen Zeit weg aber die Seite neu laden hat sofort reagiert.
Also ich kann mit der Lösung ganz gut leben. Besten Dank für Deine Hilfe.

Grüße,
Josef
Titel: Antw:ZWDongle Sicherung
Beitrag von: rudolfkoenig am 06 Mai 2016, 14:24:42
ZitatHabe "set ZWDongle_Raz backupCreate 256k" oben in dem weßen Feld eingegben

Noe, ich dachte eher an telnet/ssh/wget.
Jetzt bin ich (noch) verwirrter: der Browser wiederholt die Anfrage, wenn man im Detailfenster set drueckt, aber nicht, wenn man in der Kommandozeile direkt eingibt. Seufz.
Titel: Antw:ZWDongle Sicherung
Beitrag von: krikan am 06 Mai 2016, 14:27:24
Habe jetzt ein Backup vom Dongle am Raspi3 ziehen können. Dazu musste ich das Dongle direkt an den Raspi statt am USB-Hub anschließen und den Hub ausstöpseln.

___

Könnte bitte einer der AEOTEC Gen5 - Stick Nutzer das Backup mit dem offiziellen AEOTEC Backup-Programm https://aeotec.freshdesk.com/support/solutions/articles/6000108806-z-stick-gen5-backup-software ausführen und Angaben zur Größe der Backupdatei machen? Danke.
Titel: Antw:ZWDongle Sicherung
Beitrag von: jeep am 06 Mai 2016, 15:28:09
Zitat von: rudolfkoenig am 06 Mai 2016, 14:24:42
Noe, ich dachte eher an telnet/ssh/wget.

OK, kann ich gerne nochmal mit ssh testen, wenn  man mir einem Beispiel unter die Arme greift.  ;)
Titel: Antw:ZWDongle Sicherung
Beitrag von: rudolfkoenig am 06 Mai 2016, 15:49:29
Ich meinte mit ssh "socat openssl:fhemhost:fhemport,verify=0 readline", funktioniert nur, wenn man telnet mit SSL betreibt.
Sonst: "telnet <fhemhost> <fhem-telnet-port>" und Befehl eingeben. Hat sich aber offensichtlich erledigt.
Titel: Antw:ZWDongle Sicherung
Beitrag von: jeep am 06 Mai 2016, 15:53:11
OK, danke, gut zu wissen, viellecht werde ich es mal brauchen.
Titel: Antw:ZWDongle Sicherung
Beitrag von: krikan am 06 Mai 2016, 16:05:26
Hallo Josef, Hallo Rudi!
Ihr verwirrt mich: Josef hat beim erfolgreichen Versuch in der FHEMWeb-Kommandozeile den createBackup-Befehl direkt abgesetzt. Dadurch können mMn keine Wiederholungen durch den Browser entstehen. Vorher hat Josef vermutlich über set-Anklicken im Browser den Befehl aufgerufen, oder? Also ist doch alles normal und kein Grund über  telnet/ssh/wget zu gehen!?
Gruß, Christian
Titel: Antw:ZWDongle Sicherung
Beitrag von: jeep am 06 Mai 2016, 16:15:00
Hallo Christian,

Du hast alles richtig interpretiert. Genau das waren meine Vorgehensweisen.
Ist auch egal, ich  habe nur interessehalber nachgefragt. Für mich passt das so, den Befehl in der FHEMWeb-Kommandozeile einzugeben.
Haupsache das Backup wird erstellt. Werde gleich noch eine Razberry Platine ordern und das restore versuchen.
 
Grüße,
Josef
Titel: Antw:ZWDongle Sicherung
Beitrag von: rudolfkoenig am 06 Mai 2016, 16:21:22
Mir ist unklar, wieso beim set im Detailfenster eine Wiederholung entsteht, und bei der Browser-Kommandozeile keine, ich dachte der Browser loest in beiden Faellen die Wiederholung automatisch aus, wenn nach X Sekunden keine Antwort vom Server kommt. Und ich wollte dem Problem nicht unbedingt auf dem Grund gehen.
Titel: Antw:ZWDongle Sicherung
Beitrag von: krikan am 07 Mai 2016, 22:04:19
Zitat von: krikan am 04 Mai 2016, 14:49:21
Habe mal nach den Chipsätzen/Flashspeichergößen der Sticks gesucht:
Vision ZU1401-5 nutzt laut Hersteller als Chip einen ZM5101a mit einen Flashspeicher von 128 kb.
UZB1 soll laut Internet den Chipsatz SD3503 ohne eingebauten Flashspeicher haben.
AEOTEC Gen5 finde ich keine Infos zum Chipsatz
http://products.z-wavealliance.org hat die Angaben zu den Geräten erweitert. Unter anderem wird jetzt auch der genutzte Chipsatz gelistet:

Vision ZU1041-5 http://products.z-wavealliance.org/products/1068 : ZM5101 (meiner laut beiliegendem Datenblatt ZM5101a)
Zwave.Me UZB1 http://products.z-wavealliance.org/products/1147 : ZM5101
AEOTEC Gen 5 http://products.z-wavealliance.org/products/1355 :  ZM5101
Razberry http://products.z-wavealliance.org/products/1150: ZM5202

Sigma - Modul Comparison Table http://z-wave.sigmadesigns.com/docs/brochures/ZM5202_br.pdf ordnet allen 128 kb FLASH Memory zu. Wie kommen dann 256 kb bei Razberry/UZB1 zustande?

Vielleicht würde das helfen:
ZitatKönnte bitte einer der AEOTEC Gen5 - Stick Nutzer das Backup mit dem offiziellen AEOTEC Backup-Programm https://aeotec.freshdesk.com/support/solutions/articles/6000108806-z-stick-gen5-backup-software ausführen und Angaben zur Größe der Backupdatei machen? Danke.
Titel: Antw:ZWDongle Sicherung
Beitrag von: FunkOdyssey am 11 Juni 2016, 22:08:04
Ich habe auch mal eine Frage zu dieser Backup-Lösung.  Ich will meinen UZB sichern. Leider erscheint bei mir dann folgender Fehler: "Cant open ./ZWDongle_0.bin: Permission denied"

Habe ich das etwas übersehen?
Ich habe testweise auf meinem RasPi die Datei via "touch"'angelegt. Leider gleicher Fehler. Datei natürlich wieder gelöscht.

Habt ihr nen Tipp?  Danke.
Titel: Antw:ZWDongle Sicherung
Beitrag von: rudolfkoenig am 11 Juni 2016, 22:54:31
Ja: der FHEM-Benutzer (typischerweise fhem) sollte fuer diesen Ordner Schreibberechtigung haben.
Titel: Antw:ZWDongle Sicherung
Beitrag von: FunkOdyssey am 11 Juni 2016, 23:00:12
Ach, sorry. Ich hatte modpath in /opt/fhem/FHEM vermutet. Dort passten die Rechte. Aber ein chmod 777 auf /opt/fhem hat das Problem gelöst.
Titel: Antw:ZWDongle Sicherung
Beitrag von: krikan am 15 Juli 2016, 14:31:08
Hallo Rudi!
Hast Du schon den Aufbau der ausgelesenen Daten (Backupdatei) des Dongles analysiert? Habe heute mal damit angefangen; aber will nicht weitermachen, wenn Du sowieso schon alles hast.
Gruß, Christian
Titel: Antw:ZWDongle Sicherung
Beitrag von: rudolfkoenig am 15 Juli 2016, 14:50:09
Nein, weiss nur, dass homeId irgendwo am Anfang steht.
Die Daten in EEPROM muessen mAn folgendes enthalten:
- nodeId
- Nachbarschaftsbeziehung zu den anderen (neighborList). Wenn Bitfeld, dann sind es 29 Bytes, jedenfalls wird das per API geliefert.
- 3 bis 6 Bytes nodeInfo
Titel: Antw:ZWDongle Sicherung
Beitrag von: krikan am 15 Juli 2016, 15:29:04
Zitat von: rudolfkoenig am 15 Juli 2016, 14:50:09
Nein, weiss nur, dass homeId irgendwo am Anfang steht.
Die Daten in EEPROM muessen mAn folgendes enthalten:
- nodeId
- Nachbarschaftsbeziehung zu den anderen (neighborList). Wenn Bitfeld, dann sind es 29 Bytes, jedenfalls wird das per API geliefert.
- 3 bis 6 Bytes nodeInfo
Dann mache ich weiter  ;)

Finde alle von Dir erwähnten Angaben außer der NodeIds, die sich wohl einfach aus der Speicherreihenfolge ergeben.
Es wird in 5 Byte-Block pro Node fortlaufend der Inhalt der Antwort auf 0x41 (ZW_GET_NODE_PROTOCOL_INFO) gespeichert. Nicht vorhandene Nodes werden mit 5x 0x00 abgespeichert.
Nachbarschaftsbeziehungen werden mit der Antwort auf 0x80 (GET_ROUTING_TABLE_LINE) = 29 Bytes abgespeichert.
Die homeId mit der Antwort 0x20 (MEMORY_GET_ID).
Dann gibt es noch eine Zahl die zufällig(?) dem Wert der letzten verwendeten NodeId entspricht.
Ansonsten noch ein paar 0xFF, die ich momentan mal als unwichtig einstufe.

Irgendwie ist mir das fast schon zu einfach. Es sind bis auf die omniöse letzte verwendete NodeId alle gespeicherten Werte Abfrageergebnisse der API. Probleme habe ich noch mit der passenden Speicheradresse. Muss noch abgleichen, ob das bei UZB1 und Vision gleich ist.
Titel: Antw:ZWDongle Sicherung
Beitrag von: rudolfkoenig am 15 Juli 2016, 16:01:28
ZitatEs wird in 5 Byte-Block pro Node fortlaufend der Inhalt der Antwort auf 0x41 (ZW_GET_NODE_PROTOCOL_INFO) gespeichert. Nicht vorhandene Nodes werden mit 5x 0x00 abgespeichert.Nachbarschaftsbeziehungen werden mit der Antwort auf 0x80 (GET_ROUTING_TABLE_LINE) = 29 Bytes abgespeichert. Die homeId mit der Antwort 0x20 (MEMORY_GET_ID).
D.h. all diese Calls sind nur ein "Alias" auf NVM_EXT_READ_LONG_BUFFER

ZitatDann gibt es noch eine Zahl die zufällig(?) dem Wert der letzten verwendeten NodeId entspricht.
Ich meine, das war nicht zufaellig so: ich habe was dazu-Inkludiert, und die Zahl hat sich um eins erhoeht. Ich war aber zu feige zu testen, ob man es wieder auf eins setzen kann :)

Wir sollten eine Methode finden, Controller mit bekannten EEPROM-Layout von welchen mit unbekannten Layout zu unterscheiden, damit wir nicht etwas Neues/Unbekanntes kaputtschreiben, z.Bsp. indem wir den Slot fuer den Controller mit den Angaben ueber nodeInfo/nodeList vergleichen. Und wir erzwingen vorher ein Backup. Oder so.
Titel: Antw:ZWDongle Sicherung
Beitrag von: krikan am 15 Juli 2016, 18:28:49
Zitat von: rudolfkoenig am 15 Juli 2016, 16:01:28
D.h. all diese Calls sind nur ein "Alias" auf NVM_EXT_READ_LONG_BUFFER
Das will ich nach meiner Feststellung von gerade so direkt nicht behaupten:
Die homeId wird durch SET_DEFAULT am Offset 0x08 gespeichert.
Durch createNewPrimary erhält der Controller eine "neue" homeId des alten zu ersetzenden Sticks. Diese homeId wird unter Offset 0x16 gespeichert. Die per SET_DEFAULT zugeteilte bleibt unter 0x08 erhalten.
0x20 (MEMORY_GET_ID) liefert dann auch die homeId in 0x16 und nicht 0x08, obwohl beide vorhanden.

ZitatIch meine, das war nicht zufaellig so: ich habe was dazu-Inkludiert, und die Zahl hat sich um eins erhoeht. Ich war aber zu feige zu testen, ob man es wieder auf eins setzen kann
An Offset 0x268c steht auch beim 2. Stick die nächste NodeId.
Es gibt irgendeine Controllerwechselfunktion, bei der die Zählung laut API auch wieder von vorne losgeht, habe nur vergessen welche...

Zitat
Wir sollten eine Methode finden, Controller mit bekannten EEPROM-Layout von welchen mit unbekannten Layout zu unterscheiden, damit wir nicht etwas Neues/Unbekanntes kaputtschreiben
Ja.
Tippe derzeit darauf, dass Vision und UZB1 das gleiche Layout haben. Hatte eine Sicherung damals auch zwischen den Controllern vertauscht und im Schnelltest keine Probleme festgestellt.
Titel: Antw:ZWDongle Sicherung
Beitrag von: krikan am 15 Juli 2016, 20:14:00
Meine vorläufigen Ergebnisse zum Datei/EEP-Layout:

0x08                      = 4 Bytes = homeId = 0x20 komplette Antwort
0xf8  - 0x57f          = 5 Bytes pro Node bei 232 Nodes = nodeInfo = 0x41 Antwort ohne Byte für BASIC DEVICE CLASS oder 5x 0x00 bei nicht vorhanden
                                                                                                          (Bsp.: Antwort: 0141 d39c01041005 gespeichert wird nur d39c011005)
0x580 - 0x1fc7       = 29 Bytes pro Node = neighborList = 0x80 Antwort komplett oder 29x 0x00 bei nicht vorhanden
0x268c                   = 1 Byte = letzte inkludierte NodeId höchste inkludierte NodeId
0x1fc8                    = 1 Byte = von NodeId 1 abweichende ControllerId letzte inkludierte NodeId
0x1fc9                    = 1 Byte = SucNodeId = 0x56 Antwort komplett

Bei den Offsets 0x1fc8 und 0x1fc9 bin ich mir unsicher, aber die sind vermutlich nur in  Spezialfällen relevant.

edit:
0x1fc8 Bedeutung korrigiert
0x268c Bedeutung korrigiert
Titel: Antw:ZWDongle Sicherung
Beitrag von: krikan am 17 Juli 2016, 17:52:28
Weitere Erkenntnisse zum Datei/EEP-Layout der Gen5 Vision/UZB1-Sticks:

0x2568 - 0x264f = 1 Byte pro Node bei 232 Nodes = 0xff = Controller , 0xfe = belegt oder leer, 0x00 removeFailedNode erfolgreich
0x268b               = 1 Byte = ctrlCaps = 0x05 Antwort komplett
0x268d - 0x2800 (?) = evtl. Routing Infos?
Titel: Antw:ZWDongle Sicherung
Beitrag von: krikan am 18 Juli 2016, 06:54:56
Zitat von: krikan am 17 Juli 2016, 17:52:28
0x268d - 0x2800 (?) = evtl. Routing Infos?
Das ist falsch.

"Richtig"
0x268e - 0x2b15 =  5 Bytes pro Node bei 232 Nodes = Bedeutung unklar: ändert sich unter anderem bei addNode, removeNode, removeFailedNode
Titel: Antw:ZWDongle Sicherung
Beitrag von: krikan am 18 Juli 2016, 14:55:28
Zitat von: krikan am 18 Juli 2016, 06:54:56
0x268e - 0x2b15 =  5 Bytes pro Node bei 232 Nodes = Bedeutung unklar: ändert sich unter anderem bei addNode, removeNode, removeFailedNode
Ändert sich teilweise auch bei neigbhorUpdate -> also Routeninfos?
Titel: Antw:ZWDongle Sicherung
Beitrag von: umtauscher am 29 März 2018, 13:51:02
Ich weiß schon sehr alt, aber vielleicht hat jemand neue Erkenntnisse....

Hat jemand herausgefunden, wo die Information SUC/SIS/Primary steht?

Hintergrund meiner Anfrage ist ein Netzwerk, dass durch einen Fehler jetzt keinen primary Controller mehr hat.
Ich habe aber einen Aeotec Gen5 Stick, der das komplette Netzwerk kennt. Dummerweise steht der auf Secondary/Other Network und hat NodeID 134 bzw. 0x86.  Ich möchte das Backup so umpatchen, dass er jetzt zum Primary wird. Der alte Primary ist leider platt.
Wäre echt super, wenn Ihr noch etwas mehr wüsstet.

Wilhelm
Titel: Antw:ZWDongle Sicherung
Beitrag von: krikan am 29 März 2018, 15:27:32
Hallo Wilhelm!

Habe leider keine Antwort auf Deine Frage.

Aber eventuell ist ja Dein Secondary SUC, dann könntest Du mit "createNewPrimary" einen neuen Primary erzeugen.

Gruß, Christian
Titel: Antw:ZWDongle Sicherung
Beitrag von: umtauscher am 29 März 2018, 15:34:19
Hallo Christian,

ich habe diese Funktion auf meinem Secondary aktiviert, indem ich (wie oben beschrieben) das Byte 0x1fc9 auf die eigene Node (0x86) gesetzt habe. Seitdem zeigt das Zensys z-wave Tool meinen Secondary als SUC an.

Ich hatte nur noch nicht den Mut die Funktion CreatNewPrimary auszuprobieren.

Was soll denn da passieren? Wird nur der Stick geändert oder werden auch Associationen in den anderen Nodes Umprogrammiert?

Ich mache ja die ganze Forschung, um nicht alle 133 Nodes neu anlernen zu müssen. Es darf also nichts schiefgehen. ;-)

Für weiter Hinweise bin ich dankbar.
Schöne Grüße

Wilhelm
Titel: Antw:ZWDongle Sicherung
Beitrag von: krikan am 29 März 2018, 15:44:01
Infos zum Thema createNewPrimary findest Du in https://forum.fhem.de/index.php/topic,53372.0.html .
Der Weg sollte eigentlich genau Dein Problem lösen, wenn Du einen 2. Controller zur Verfügung hast und das manuelle Setzen des SUCs beim Secondary-Controller so reicht/erfolgreich war.


Titel: Antw:ZWDongle Sicherung
Beitrag von: umtauscher am 29 März 2018, 19:17:02
ok, jetzt habe ich wengistens wieder einen Primary - danke.

Weißt Du zufällig, ob ich durch setzen von 0x1fc8 auf 0 erreichen kann, dass die nächste inkludierte Node die 1 wird?
Titel: Antw:ZWDongle Sicherung
Beitrag von: umtauscher am 29 März 2018, 19:57:43
Nur kurz zur Info:
Meine Idee mit dem Überlauf habe ich getestet.
Nachdem ich die Zelle 0x1fc8  auf 0xE8 (232) gesetzt habe, wurde beim nächsten mal die Node 1 vergeben.
Mein neuer Stick ist jetzt auf 1 und der Controller Shift hat auch funktioniert.

Also habe ich es doch geschafft, ohne 133 Nodes neu zu lernen.

Danke für Deine Hilfe.
Schöne Ostertage.

Wilhelm
Titel: Antw:ZWDongle Sicherung
Beitrag von: krikan am 29 März 2018, 20:02:14
Hast Du mit controllerShift oder createNewPrimary gearbeitet?
Titel: Antw:ZWDongle Sicherung
Beitrag von: umtauscher am 29 März 2018, 20:26:42
Ja, mit CreateNewPrimary habe ich überhaupt die Möglichkeit bekommen, wieder einen Shift durchzuführen.
Dann habe ich mehrfach Backups gemacht und gepatched, bis ich den Primary wieder auf Node 1 hatte.

Das Aeotec backup schreibt beim Gen5 Stick übrigens 512 KB. Diese Datei enthält 8 gespiegelte Speicherbereiche. Ich habe die Datei dann auf 64KB gekürzt.
Ein restore dieser Datei liefert beim erneuten Backup wieder 8 identische Speicherblöcke.
Der Stick enthält also nur 64KB Speicher.

Beim UZB werden 256KB gesichert, er hat aber auch nur 64KB.
Soviel nur zur Info
LG
Wilhelm
Titel: Antw:ZWDongle Sicherung
Beitrag von: umtauscher am 30 März 2018, 16:09:00
Hallo Christian,

vielleicht kannst Du das bestätigen.

Neue Speichererkenntnisse:

0x0010-0x0013   Home ID von Othernetwork.

Bedeutet, wenn der Stick an einem Netzwerk angemeldet wird, steht hier die HomeID die er danach verwendet. Das bleibt auch bestehen, wenn er danach zum Primary hochgestuft wird. Erst nach einem Reset wird Othernetwork auf 0000 gesetzt und die ursprüngliche HomeID wird wieder verwendet.
Schöne Grüße
Wilhelm
Titel: Antw:ZWDongle Sicherung
Beitrag von: krikan am 30 März 2018, 18:14:14
Hallo Wilhelm!
Danke für die Info. Kann es nicht bestaetigen, da ich das  nicht getestet habe.
Mit den Angaben aus https://forum.fhem.de/index.php/topic,52914.msg472454.html#msg472454 haetten wir dann folgende Infos zu den homeIds:

0x08-0x0B homeId SET_DEFAULT
0x0C-0x0F  ??
0x10-0x13 homeId othernetwork
0x14-0x15  ??
0x16-0x19 homeId createNewPrimary

Ein wenig irritierend finde ich die 2-Byte-Lücke 0x14-0x15.

Gruß, Christian
Titel: Antw:ZWDongle Sicherung
Beitrag von: HomeAlone am 16 September 2018, 10:17:56
Zitat von: rudolfkoenig am 03 Mai 2016, 12:02:36
[...]
Ich wuerde mich freuen, wenn jeder mit einem hier noch nicht bekannten ZWDongle folgendes absetzt:
get ZWDongle_0 raw 29
und danach Ausgabe + ZWDongle Modellbezeichnung uns hier mitteilt. Ideal waere noch ein Versuch mit dem Aeotec Backup, und dann die Dateigroesse mitteilen.

Ich fange mal an:
Zwave.me ZME_UZB1:  raw_29 => 012903208012, Aeotec Backup Groesse: 256k
Viesion ZU_1401:         raw_29 => 012903208011, Aeotec Backup Groesse: 128k

Habe den Razberry2 ausgelesen und zudem die gesammelten Infos in diesem Thread konsolidiert. Vielleicht kommen so ja noch ein paar Module zusammen. Da ich mit dem GPIO-Modul das Aeotec Backup nicht laufen lassen kann, habe ich die Größe mit 256k aufgrund der Ausgabe geschätzt - gekennzeichnet durch das Fragezeichen.

Liste der in diesem Thread bereits gemeldeten ZWave Dongles:


get ZWDongle_0 raw 29

Aoetec Gen5      : raw_29 => 012903208012, Chip: ZM5101, Aeotec Backup Groesse: ???k
Razberry1        : raw_29 => 012903208012, Chip: ZM5202, Aeotec Backup Groesse: 256k?
Razberry2        : raw_29 => 012903208012, Chip: ZM5202, Aeotec Backup Groesse: 256k?
Vision ZU_1401   : raw_29 => 012903208011, Chip: ZM5101, Aeotec Backup Groesse: 128k
Zwave.me ZME_UZB1: raw_29 => 012903208012, Chip: ZM5101, Aeotec Backup Groesse: 256k



Viele Grüße
Sascha
Titel: Antw:ZWDongle Sicherung
Beitrag von: krikan am 16 September 2018, 10:24:14
Hallo Sascha,

bist Du sicher, dass der Razberry1 einen ZM5202 als Chip hat? Nach meiner Erinnerung hat der Razberry1 kein  ZWavePlus und einen 3er Chip.

Gruß, Christian
Titel: Antw:ZWDongle Sicherung
Beitrag von: HomeAlone am 16 September 2018, 10:36:04
Zitat von: krikan am 16 September 2018, 10:24:14
Hallo Sascha,

bist Du sicher, dass der Razberry1 einen ZM5202 als Chip hat? Nach meiner Erinnerung hat der Razberry1 kein  ZWavePlus und einen 3er Chip.

Gruß, Christian

Eigentlich ja (kann ich gleich noch mal verifizieren - mein Aufbau ist gerade Razberry2 Modul im alten Raspberry und der will nach dem backupRestore noch nicht so recht. Wird zwar korrekt angezeigt, aber schalten will er nicht. Schaue ich noch mal nach, wenn ich mit der Fehlersuche durch bin.

Die Infos haben aber auch andere hier im Thread geposted:
Zitat von: Thyraz am 03 Mai 2016, 12:18:50
Die Info bekomme ich für den Razberry (V5 / Zwave+ Variante) auch von hier per VPN raus. :)

012903208012 und somit wahrscheinlich auch die 256k wie beim UZB1.
und
Zitat von: jeep am 03 Mai 2016, 12:56:00
ZWDongle_Raz raw_29 => 012903208012

Ich versuchte ein Backup über socat zum RPI mit Razberry. Nach 256K wurde die Datei wieder auf 0 Byte gesetzt und fing wieder an zu wachsen. Aber nach kurzer Zeit ging die Verbindung verloren und ich vermute das socat sich verlaufen hat. Musste den RPI einfach neu starten, dann war die Verbindung wieder da.

Viele Grüße
Sascha
Titel: Antw:ZWDongle Sicherung
Beitrag von: HomeAlone am 16 September 2018, 11:20:24
So, alter Razberry1 wieder drauf und altes System gestartet:
Nach Eingabe von
get ZWAVE1 raw 29
erscheint als Antwort:
ZWAVE1 raw_29 => 012903208012

Zusätzlich in den Readings von caps (nur der Anfang):
Vers:5 Rev:0 ManufID:0147 ProductType:0400 ProductID:0001

Habe auch noch mal im Beiblatt zum Device geschaut: Da wird der ZM5202 Chip angegeben.

Also als Antwort zu Deiner ursprünglichen Frage: Definitiv ja. :)

Viele Grüße
Sascha
Titel: Antw:ZWDongle Sicherung
Beitrag von: krikan am 16 September 2018, 19:44:10
Dann ist der Razberry1 also die Zwave-Plus-Variante mit der "alten" Antenne!?
Dachte Razberry1 wäre die erste Version als ZWave-ohne-Plus-Variante.
Danke.
Gruß, Christian
Titel: Antw:ZWDongle Sicherung
Beitrag von: HomeAlone am 16 September 2018, 20:41:28
Was gab es denn noch davor? Wenn die Variante mit kleinem Board (=alte Antenne) nicht der Razberry 1 ist, dann ist die Frage welcher ist es dann?
Was dann noch Sinn machen würde wäre eine Unterteilung des Razberry 2 in Rev 1 (kleines Board) und Rev 2 (großes Board)?

Eine Suche im Netz nach Razberry 1 und 2 gestaltet sich schwierig, da natürlich angenommen wird, man meinte Rasbberry und da gibt es auch eine Variante 1 und 2.
Titel: Antw:ZWDongle Sicherung
Beitrag von: Thyraz am 17 September 2018, 07:58:12
Es gab vom alten, kleinen Razberry 2 Versionen.
Die erste hatte keine Unterstützung für ZWave+, die zweite hingegen schon.

Das neue Board nennt der Hersteller verwirrenderweise "Razberry 2",
wahrscheinlich weil er die ersten 2 Versionen sprachlich nur "Razberry" genannt hat.
Titel: Antw:ZWDongle Sicherung
Beitrag von: krikan am 17 September 2018, 13:13:04
Für den Controllerwechsel in Form von Sicherung Altcontroller / Rücksicherung Neucontroller bei Razberrys kann man dann wohl nur auf das Unterscheidungsmerkmal "ZWave-Plus" und "ohne ZWave-Plus" setzen, wenn die ersten beiden Versionen einfach "Razberry" heißen.

Ein Umzug zwischen ZWave-Plus-Controllern sollte mit einem einfachen backupCreate / backupRestore zu erledigen sein. Der Weg von "ohne ZWave-Plus" zu "Zwave-Plus" geht nur mit ein wenig Bastelei: https://forum.fhem.de/index.php/topic,53023.msg472541.html#msg472541