Home id ZWDongle hat sich von selbst geändert???

[rudolfkoenig]

Die Ursache des Problems ist, das man als "Abnehmer" alle Meldungen mit "ACK" bestaetigen muss. Passiert das nicht, werden die Daten erneut gesendet. Deine Aenderung der Regexp in ZWDongle_Clear sollte das Problem loesen, das habe ich eingecheckt.

Beim CANCEL die Letzte Nachricht weiderholt zu schicken ist mAn falsch, ich hatte schon deswegen eine Endlosschleife, weil ich eine Nachricht senden wollte, was der Dongle nicht akzeptieren wollte. Keine Ahnung, wieso, lag irgendwie an der Reihenfolge.

SendStack Erklaerungen: 13 ist ZW_SEND_DATA, also Nachricht an ZWave Geraet, nicht an das ZWDongle selbst. Warum es bei SOF-Fehler geloescht wird, weiss ich auch nicht mehr, vmtl. hatte ich Probleme damit. Verbleiben bei Protokoll-ACK ist mAn ok, erst ein "ZW_SEND_DATA:OK"  (1300..)  entfernt die Nachricht.

[gero]

Die Ursache des Problems ist, das man als "Abnehmer" alle Meldungen mit "ACK" bestaetigen muss. Passiert das nicht, werden die Daten erneut gesendet. Deine Aenderung der Regexp in ZWDongle_Clear sollte das Problem loesen, das habe ich eingecheckt.

Das hat bei mir leider nicht gereicht. Das Log lief mit meinem Patch. Leider sieht man es nicht im Log, aber es werden beim Clear alle gelesenen Nachrichten mit einem ACK quittiert. Trotzdem kommen beim Versuch die homeId zu holen weitere Nachrichten aus dem Dongle. Vermutlich ist es ein Bug im Dongle. Es wäre interessant zu testen, ob sich andere Dongles anders verhalten.

Beim CANCEL die Letzte Nachricht weiderholt zu schicken ist mAn falsch, ich hatte schon deswegen eine Endlosschleife, weil ich eine Nachricht senden wollte, was der Dongle nicht akzeptieren wollte. Keine Ahnung, wieso, lag irgendwie an der Reihenfolge.

Leider habe ich bisher keine Beschreibung gefunden, wo man genau nachlesen kann, was das CANCEL bedeutet und wie darauf reagiert werden soll. Ich habe nur zwei Stellen im Internet gefunden, die auf ein erneutes Senden vom letzten Frame hinweisen.
http://www.homegenie.it/forum/index.php?topic=780.0
http://www.openremote.org/display/docs/Discover+Controller+Z-Wave+Devices
Das Wiederholen der Nachricht, war bei mir die einzige Chance irgendwann eine Antwort zu erhalten.

Hast du einen besseren Link?

[gero]

openzwave antwortet übrigens auf ein CAN mit bis zu 7 Wiederholungen.

Dort findet man auch ein paar Erklärungen:
Falls man ein Kommando gesendet hat und auf ein ACK wartet, aber ein anderes Frame (SOF) kommt:

Code Auswählen Erweitern

// This can happen on any normal network when a transmission overlaps an unexpected
// reception and the data in the buffer doesn't contain the ACK. The controller will
// notice and send us a CAN to retransmit.

Und falls man ein CAN empfängt:

Code Auswählen Erweitern

// This is the other side of an unsolicited ACK. As mentioned there if we receive a message
// just after we transmitted one, the controller will notice and tell us to retransmit here.
// Don't increment the transmission counter as it is possible the message will never get out
// on very busy networks with lots of unsolicited messages being received. Increase the amount
// of retries but only up to a limit so we don't stay here forever.


Bei einem NACK sollte die Nachricht auch wiederholt werden (begrenzt durch eine maximale Anzahl an Retrys), da es auf einen Empfangsfehler auf der Gegenseite hinweist.

Ich werde mir das ganze nochmal genauer ansehen.

[rudolfkoenig]

Habe deine LastMsg aenderungen doch hinzugefuegt, ergaenzt mit einem RetransmitCount (5-mal).
Ich kann das Problem zwar selbst nicht reproduzieren, aber Andreas hat vermutlich das gleiche Problem hier.

[gero]

Okay. Da bist du mir etwas zuvor gekommen. Ich habe nochmal recherchiert und mit das Z-Wave Transport Layer genauer angesehen.
Anbei ein Patch mit einigen Verbesserungen in der Low-Level-Kommunikation.

- Alle Nachrichten laufen jetzt über den sendStack
- Bei NACK und CAN gibt es Retransmits, die auf eine maximale Anzahl beschränkt sind.
- Das Auswerten von ZW_SEND_DATA:OK findet jetzt ebenfalls in der Datei 00_ZWDongle.pm statt. Damit ist der Aufruf von ZWave_HandleStack aus der 10_ZWave.pm überflüssig. Ich habe ihn aber erstmal drin gelassen und verwende in der 00_ZWDongle.pm eine andere Funktion, um keinen Patch für zwei Dateien zu liefern.
- Das Senden der nächsten Nachricht, wird jetzt schneller getriggert.
- Es wird sichergestellt, dass die Nachricht wakeupNoMoreInformation für ein Device nicht vor anderen Nachrichten auf dem sendStack stehen kann. Das führt manchmal bei einem notify auf das wakeup zu Problemen.
- Ich habe das Logging, dass ich zum Debuggen benötigt habe erstmal im Patch drin gelassen. In Zeile 24 befindet sich eine Konstante DEBUG_LL, die das Debuggen des Startups (missing homeId) vereinfacht, wenn sie auf 1 gesetzt wird.

Ich habe den Patch nach bestem Wissen und Gewissen getestet. Bei mir läuft die Kommunikation mit der mir zur Verfügung stehenden Hardware absolut fehlerfrei. Jetzt kann ich auch endlich bei einem batteriebetriebenden Gerät zig ConfigParameter auf einen Schwung abrufen und bekomme auch zuverlässig alle Antworten.

Ich bin mir bewußt, dass der Patch ziemlich viele und weitgehende Änderungen beinhaltet. Aber ich wollte ihn dir trotzdem nicht vorenthalten.
Mein Vorschlag wäre einige freiwillige Tester zu suchen, bevor der Patch offiziell ins SVN geht.

Gruß,
Gero

P.S.: Das Auftreten von CANCEL Nachrichten ist übrigens normal. Es gibt Nachrichten, bei denen nach dem SEND_DATA:OK noch eine unsolicited Message mit dem eigentlich angefragten Wert kommt (z.B. get battery). Wenn nach solchen Nachrichten direkt nach SEND_DATA:OK die nächste Nachricht gesendet wird, wird diese mit CANCEL neu angefordert, da zuerst die unsolicited Message verarbeitet werden mußte. Trotzdem ist das Senden der nächsten Nachricht nach SEND_DATA:OK eine übliche Praxis. Nur bei openzwave habe ich eine komplexere Lösung gefunden. Dort gibt es quasi für jeden Befehl gewisse Merkmale für die zu erwartende Antwort, die vor dem Versenden des nächsten Befehls abgewartet wird. Allerdings halte ich diese Vorgehensweise für etwas übertrieben und für schwer pflegbar.

[rudolfkoenig]

- ueblicherweise nehme ich so viele Aenderungen auf einmal nicht an: wenn moeglich, mir sowas in Haeppchen fuettern.
- wenn moeglich, beim Patch auf die Zeilenbreite von 80 Zeichen achten.
- DEBUG_LL kann man einfacher mit "attr ZWDongle verbose 5" realisieren, fuers debuggen beim Starten braucht man aber doch attr global verbose 5.
- habe first_index aus sentimentalen Gruenden entfernt (List::MoreUtils gibts nicht auf dem FB7270-er Perl).
- der Timeout von 1 Sekunde in Clear ist mir zu lang. Muss das sein?
- ich habe in ZWave_ProcessSendStack nach dem ersten InternalTimer ein return eingebaut.
- warum ist MaxSendRetries variabel? Reicht 3 als Festwert nicht?
- warum pruefst du unter "application messages are removed" nicht auf 01....13 sondern auf ......13?
- warum wird beim NACK ein resend durchgefuehrt?
- habe die DEBUG Konstanten entfernt, einige debug messages auch, andere umformuliert.
- habe selbst getestet, und eingecheckt.

[det.]

Hallo,
heute morgen neu nach dem Update:

Code Auswählen Erweitern

2015.05.31 09:07:36 2: SERIAL_API_SET_TIMEOUTS: ACK:64 BYTES:0f
2015.05.31 09:07:35 1: ERROR: define ZWave_Node_14: wrong homeId (initial): need an 8 digit hex value
2015.05.31 09:07:35 1: define ZWave_Node_14 ZWave_Node_14 ZWave initial 14: define ZWave_Node_14: wrong homeId (initial): need an 8 digit hex value
2015.05.31 09:07:35 2: autocreate: define ZWave_Node_14 ZWave initial 14
2015.05.31 09:07:35 1: ERROR: define ZWave_Node_14: wrong homeId (initial): need an 8 digit hex value
2015.05.31 09:07:35 1: define ZWave_Node_14 ZWave_Node_14 ZWave initial 14: define ZWave_Node_14: wrong homeId (initial): need an 8 digit hex value
2015.05.31 09:07:35 2: autocreate: define ZWave_Node_14 ZWave initial 14
2015.05.31 09:07:35 1: ERROR: define ZWave_Node_14: wrong homeId (initial): need an 8 digit hex value
2015.05.31 09:07:35 1: define ZWave_Node_14 ZWave_Node_14 ZWave initial 14: define ZWave_Node_14: wrong homeId (initial): need an 8 digit hex value
2015.05.31 09:07:35 2: autocreate: define ZWave_Node_14 ZWave initial 14
2015.05.31 09:07:35 1: ERROR: define ZWave_Node_14: wrong homeId (initial): need an 8 digit hex value
2015.05.31 09:07:35 1: define ZWave_Node_14 ZWave_Node_14 ZWave initial 14: define ZWave_Node_14: wrong homeId (initial): need an 8 digit hex value
2015.05.31 09:07:35 2: autocreate: define ZWave_Node_14 ZWave initial 14

[gero]

Ich habe heute nicht so viel Zeit. Die Familie will beschäftigt werden. Aber trotzdem kurz ein paar Antworten:

- ueblicherweise nehme ich so viele Aenderungen auf einmal nicht an: wenn moeglich, mir sowas in Haeppchen fuettern.

Kann ich verstehen. Aber in soviele Häppchen konnte ich den Patch nicht teilen.

- wenn moeglich, beim Patch auf die Zeilenbreite von 80 Zeichen achten.

Werde ich die nächsten Male drauf achten.

- DEBUG_LL kann man einfacher mit "attr ZWDongle verbose 5" realisieren, fuers debuggen beim Starten braucht man aber doch attr global verbose 5.

Ist okay. Wenn ich ein spezielles Problem beim Startup debugge, sind mir die Ausgaben mit attr global verbose 5 meist zu viel. Daher beschränke ich so etwas gerne auf ein Modul.

- habe first_index aus sentimentalen Gruenden entfernt (List::MoreUtils gibts nicht auf dem FB7270-er Perl).

Okay

- der Timeout von 1 Sekunde in Clear ist mir zu lang. Muss das sein?

Bei meinem Dongle wird bei einem Timeout von 0.3 Sekunden beim Clear häufiger nichts gelesen, obwohl Daten anliegen.

- ich habe in ZWave_ProcessSendStack nach dem ersten InternalTimer ein return eingebaut.

Sollte okay sein. Ich werde es mir morgen nochmal genau ansehen.

- warum ist MaxSendRetries variabel? Reicht 3 als Festwert nicht?

Das ist ein bisschen von einem anderen Code inspiriert worden. Dadurch dürfen mehr CAN als NACK Nachrichten auftreten. 3 CAN Nachrichten habe ich gerade beim Startup schon häufiger gesehen.

- warum pruefst du unter "application messages are removed" nicht auf 01....13 sondern auf ......13?

Muß ich mir nochmal genauer ansehen.

- warum wird beim NACK ein resend durchgefuehrt?

Ein NACK ist ein Anzeichen dafür, dass die Gegenseite eine Nachricht nicht korrekt empfangen hat (z.B. Checksum-Error oder SOF-Error). In solchen Fällen sollte die Nachricht wiederholt werden.

Gruß,
Gero

[gero]

Hallo,
heute morgen neu nach dem Update:

Code Auswählen Erweitern

2015.05.31 09:07:36 2: SERIAL_API_SET_TIMEOUTS: ACK:64 BYTES:0f
2015.05.31 09:07:35 1: ERROR: define ZWave_Node_14: wrong homeId (initial): need an 8 digit hex value
2015.05.31 09:07:35 1: define ZWave_Node_14 ZWave_Node_14 ZWave initial 14: define ZWave_Node_14: wrong homeId (initial): need an 8 digit hex value
2015.05.31 09:07:35 2: autocreate: define ZWave_Node_14 ZWave initial 14
2015.05.31 09:07:35 1: ERROR: define ZWave_Node_14: wrong homeId (initial): need an 8 digit hex value
2015.05.31 09:07:35 1: define ZWave_Node_14 ZWave_Node_14 ZWave initial 14: define ZWave_Node_14: wrong homeId (initial): need an 8 digit hex value
2015.05.31 09:07:35 2: autocreate: define ZWave_Node_14 ZWave initial 14
2015.05.31 09:07:35 1: ERROR: define ZWave_Node_14: wrong homeId (initial): need an 8 digit hex value
2015.05.31 09:07:35 1: define ZWave_Node_14 ZWave_Node_14 ZWave initial 14: define ZWave_Node_14: wrong homeId (initial): need an 8 digit hex value
2015.05.31 09:07:35 2: autocreate: define ZWave_Node_14 ZWave initial 14
2015.05.31 09:07:35 1: ERROR: define ZWave_Node_14: wrong homeId (initial): need an 8 digit hex value
2015.05.31 09:07:35 1: define ZWave_Node_14 ZWave_Node_14 ZWave initial 14: define ZWave_Node_14: wrong homeId (initial): need an 8 digit hex value
2015.05.31 09:07:35 2: autocreate: define ZWave_Node_14 ZWave initial 14

Mit welcher Version genau? Aus dem SVN oder per fhem update?

Der Fehler dürfte mit der aktuellen Version nicht mehr auftreten, da die Nachrichten erst Dispatched werden, nachdem der Dongle auf initialized steht.

Gruß,
Gero

[det.]

Hallo Gero,
mit der Version aus dem heutigen Update von kurz nach 9 Uhr. Werde mal die neue Version aus dem SVN testen. ...meine Familie ist schon groß und aus dem Hause...

[A.Harrenberg]

Hallo Gero,

Mir ist aufgefallen, dass der Dongle im Auslieferungszustand schon 3 mir unbekannte Geräte in der nodeList hatte (alles BINARY_SWITCHES). Jetzt habe ich gestern alles nochmal neu aufgesetzt, die drei unbekannten Geräte aus dem Dongle entfernt und nochmal alles neu inkludiert und assoziiert.

ich habe einen ZWave.me UZB und habe auch 2 unbekannte bzw. nicht vorhandenen Geräte in der Nodelist. Wie hast Du die denn aus der Liste rausbekommen?

Ein set removefailednode funktioniert(e) bei mir nicht. Um das noch mal zu bestätigen habe ich es während des Schreibens hier noch mal probiert und bei einem Gerät hat es funktioniert, das andere ist immer noch drin und lässt sich nicht entfernen.
Hier mal das Log für das get nodelist und das set removefailed node 3

Code Auswählen Erweitern

2015.05.31 14:22:00.427 5: ZWDongle_Write msg 02
2015.05.31 14:22:00.427 5: ZWave_ProcessSendStack: 1 items on stack, waitForAck 0
2015.05.31 14:22:00.427 5: ZWave_ProcessSendStack: sending msg 01030002fe
2015.05.31 14:22:00.427 5: SW: 01030002fe
2015.05.31 14:22:00.428 4: ZWDongle_ReadAnswer arg:nodeList regexp:^0102
2015.05.31 14:22:00.568 5: ZWDongle_ReadAnswer: read 1 bytes
2015.05.31 14:22:00.568 5: ZWDongle RAW buffer: 06
2015.05.31 14:22:00.568 5: ZWDongle_0: ACK received
2015.05.31 14:22:00.568 5: ZWave_ProcessSendStack: 0 items on stack, waitForAck 0
2015.05.31 14:22:00.568 5: ZWDongle_Read returning local msg undef hash PARTIAL:
2015.05.31 14:22:00.659 5: ZWDongle_ReadAnswer: read 2 bytes
2015.05.31 14:22:00.659 5: ZWDongle RAW buffer: 0125
2015.05.31 14:22:00.659 5: ZWDongle_Read returning local msg undef hash PARTIAL: 0125
2015.05.31 14:22:00.659 5: ZWDongle_ReadAnswer: read 4 bytes
2015.05.31 14:22:00.659 5: ZWDongle RAW buffer: 012501020500
2015.05.31 14:22:00.659 5: ZWDongle_Read returning local msg undef hash PARTIAL: 012501020500
2015.05.31 14:22:00.659 5: ZWDongle_ReadAnswer: read 1 bytes
2015.05.31 14:22:00.659 5: ZWDongle RAW buffer: 0125010205001d
2015.05.31 14:22:00.659 5: ZWDongle_Read returning local msg undef hash PARTIAL: 0125010205001d
2015.05.31 14:22:00.660 5: ZWDongle_ReadAnswer: read 1 bytes
2015.05.31 14:22:00.660 5: ZWDongle RAW buffer: 0125010205001d05
2015.05.31 14:22:00.660 5: ZWDongle_Read returning local msg undef hash PARTIAL: 0125010205001d05
2015.05.31 14:22:00.664 5: ZWDongle_ReadAnswer: read 1 bytes
2015.05.31 14:22:00.664 5: ZWDongle RAW buffer: 0125010205001d0500
2015.05.31 14:22:00.665 5: ZWDongle_Read returning local msg undef hash PARTIAL: 0125010205001d0500
2015.05.31 14:22:00.667 5: ZWDongle_ReadAnswer: read 1 bytes
2015.05.31 14:22:00.667 5: ZWDongle RAW buffer: 0125010205001d050000
2015.05.31 14:22:00.667 5: ZWDongle_Read returning local msg undef hash PARTIAL: 0125010205001d050000
2015.05.31 14:22:00.669 5: ZWDongle_ReadAnswer: read 1 bytes
2015.05.31 14:22:00.669 5: ZWDongle RAW buffer: 0125010205001d05000000
2015.05.31 14:22:00.669 5: ZWDongle_Read returning local msg undef hash PARTIAL: 0125010205001d05000000
2015.05.31 14:22:00.672 5: ZWDongle_ReadAnswer: read 1 bytes
2015.05.31 14:22:00.672 5: ZWDongle RAW buffer: 0125010205001d0500000000
2015.05.31 14:22:00.672 5: ZWDongle_Read returning local msg undef hash PARTIAL: 0125010205001d0500000000
2015.05.31 14:22:00.676 5: ZWDongle_ReadAnswer: read 1 bytes
2015.05.31 14:22:00.676 5: ZWDongle RAW buffer: 0125010205001d050000000000
2015.05.31 14:22:00.677 5: ZWDongle_Read returning local msg undef hash PARTIAL: 0125010205001d050000000000
2015.05.31 14:22:00.680 5: ZWDongle_ReadAnswer: read 1 bytes
2015.05.31 14:22:00.680 5: ZWDongle RAW buffer: 0125010205001d05000000000000
2015.05.31 14:22:00.680 5: ZWDongle_Read returning local msg undef hash PARTIAL: 0125010205001d05000000000000
2015.05.31 14:22:00.687 5: ZWDongle_ReadAnswer: read 2 bytes
2015.05.31 14:22:00.687 5: ZWDongle RAW buffer: 0125010205001d050000000000000000
2015.05.31 14:22:00.687 5: ZWDongle_Read returning local msg undef hash PARTIAL: 0125010205001d050000000000000000
2015.05.31 14:22:00.690 5: ZWDongle_ReadAnswer: read 23 bytes
2015.05.31 14:22:00.690 5: ZWDongle RAW buffer: 0125010205001d05000000000000000000000000000000000000000000000000000000000500c1
2015.05.31 14:22:00.690 5: ZWDongle_Read -> sending ACK
2015.05.31 14:22:00.690 5: SW: 06
2015.05.31 14:22:00.691 5: ZWDongle_Read ZWDongle_0: processing 010205001d05000000000000000000000000000000000000000000000000000000000500
2015.05.31 14:22:00.691 5: ZWave_ProcessSendStack: 0 items on stack, waitForAck 0
2015.05.31 14:22:00.692 5: ZWDongle_Read returning local msg 010205001d05000000000000000000000000000000000000000000000000000000000500 hash PARTIAL:
2015.05.31 14:22:00.692 5: ZWDongle_ReadAnswer: returning 010205001d05000000000000000000000000000000000000000000000000000000000500
2015.05.31 14:22:11.365 5: ZWDongle_Write msg 6103
2015.05.31 14:22:11.365 5: ZWave_ProcessSendStack: 1 items on stack, waitForAck 0
2015.05.31 14:22:11.365 5: ZWave_ProcessSendStack: sending msg 010400610399
2015.05.31 14:22:11.365 5: SW: 010400610399
2015.05.31 14:22:11.747 5: ZWDongle RAW buffer: 06
2015.05.31 14:22:11.747 5: ZWDongle_0: ACK received
2015.05.31 14:22:11.747 5: ZWave_ProcessSendStack: 0 items on stack, waitForAck 0
2015.05.31 14:22:11.836 5: ZWDongle RAW buffer: 01
2015.05.31 14:22:11.837 5: ZWDongle RAW buffer: 0104
2015.05.31 14:22:11.840 5: ZWDongle RAW buffer: 010401
2015.05.31 14:22:11.841 5: ZWDongle RAW buffer: 01040161
2015.05.31 14:22:11.842 5: ZWDongle RAW buffer: 0104016108
2015.05.31 14:22:11.844 5: ZWDongle RAW buffer: 010401610893
2015.05.31 14:22:11.845 5: ZWDongle_Read -> sending ACK
2015.05.31 14:22:11.845 5: SW: 06
2015.05.31 14:22:11.846 5: ZWDongle_Read ZWDongle_0: processing 016108
2015.05.31 14:22:11.846 5: ZWDongle_0 dispatch 016108
2015.05.31 14:22:11.846 4: ZWDongle_0 unhandled ANSWER: ZW_REMOVE_FAILED_NODE_ID 08
2015.05.31 14:22:11.846 5: ZWave_ProcessSendStack: 0 items on stack, waitForAck 0

Das kommt eine 08 als Antwort auf das Exclude, das ist (bisher) nicht definiert und unbekannt. Habe das auch im OpenZWave Code bisher nicht gefunden...

Gruß,
Andreas.

[krikan]

@Andreas:
Kennst Du den Beitrag: http://forum.fhem.de/index.php/topic,32823.msg292626.html#msg292626
->Du kannst nur löschen, wenn der Node in der failedNodeList steht. Bei wakeup-Geräten enstprechend markieren bzw bei netzbetriebenen ein Befehl hinschicken. Dann sollten die Geräte in der failedNodeList stehen und Du kannst löschen.

Wenn es Dein Test- und Spielcontroller ist, dann kannst du den Controller auch mit ZW_SetDefault reseten; aber Folgen beachten (siehe INS11095-2).

[det.]

Werde mal die neue Version aus dem SVN testen.

getan, alles prima - keinerlei Fehlermeldungen mehr! Danke!

[A.Harrenberg]

Hallo Christian,

@Andreas:
Kennst Du den Beitrag: http://forum.fhem.de/index.php/topic,32823.msg292626.html#msg292626
->Du kannst nur löschen, wenn der Node in der failedNodeList steht. Bei wakeup-Geräten enstprechend markieren bzw bei netzbetriebenen ein Befehl hinschicken. Dann sollten die Geräte in der failedNodeList stehen und Du kannst löschen.

hat funktioniert, danke für den Hinweis. Nach der Prozedur liess sich dann auch die zweite Node entfernen.

Wenn es Dein Test- und Spielcontroller ist, dann kannst du den Controller auch mit ZW_SetDefault reseten; aber Folgen beachten (siehe INS11095-2).

Auch hier Danke für den Hinweis auf das Dokument, kannst Du evtl. kurz erläutern was das für Folgen hätte, ich habe das zwar nicht vor und das Dokument hat immerhin >300 Seiten, das wollte ich jetzt erst mal noch nicht lesen ,-)

Danke,
Andreas.

[krikan]

>300 Seiten, das wollte ich jetzt erst mal noch nicht lesen ,-)

Brauchst nicht alles lesen, sondern nur die Seite zu ZW_SetDefault. Kurz: Werksreset des Controllers mit dem "Verlust" von allen Nodes, HomeId, Routen, usw. Inkludierte Geräte müssen ebenfalls resetet werden. Für Testzwecke meiner Meinung nach ganz praktisch.