ZWave @ culfw

[rudolfkoenig]

Habe noDispatch durch intruderMode ausgetauscht. intruderMode muss im monitor-Mode (homeId = 00000000) gesetzt sein, damit Events an das ZWave Modul weitergereicht werden.

[A.Harrenberg]

Hi Rudi,

Habe noDispatch durch intruderMode ausgetauscht. intruderMode muss im monitor-Mode (homeId = 00000000) gesetzt sein, damit Events an das ZWave Modul weitergereicht werden.

Danke, schau ich mir demnächst an, bis jetzt ist meine homeId aber "sauber" geblieben.

In ZWave_Parse wird bei "ADD_NODE" der Devicehandle mit

Code Auswählen Erweitern

my $dh = $modules{ZWave}{deftptr}{"$homeId $1"}
ermittelt. An der Stelle ist das Problem ja dann bei mir entstanden. Wenn ich nun den ZWCul als "Intruder" nutzen möchte wird die homeId ja auch gesetzt, oder?

An der Stelle passiert dann aber wieder das gleiche das dann dort mit einem mal der ZWCul ermittelt wird anstelle des eigentlichen device. Da ich immer noch keinen Überblick über diesen ganzen hashes habe blicke ich da auch nicht durch wie man an der Stelle den richtigen hash bekommt...

Kannst Du da bitte bei Gelegenheit mal schauen?

Danke,
Andreas.

[rudolfkoenig]

Wenn du den ZWCUL als "Intruder" verwendest, dann hast du sicher keinen zweiten ZWDongle mit richtiger HomeId angeschlossen. Oder du bist Schizophren, aber das ist mir dann egal

[A.Harrenberg]

Hi Rudi,

Wenn du den ZWCUL als "Intruder" verwendest, dann hast du sicher keinen zweiten ZWDongle mit richtiger HomeId angeschlossen. Oder du bist Schizophren, aber das ist mir dann egal

UNS ist das aber nicht egal!

Ok, ich hatte Dich damals so verstanden das Du einen ZWCul "neben" einem ZWDongle betreiben wolltest. Wenn das nicht so ist sollten ja auch keine Probleme auftauchen.

Kleine Nebenfrage, hast Du mit dem ZWCul schon mal Befehle an eine Node geschickt und dabei NICHT die Controller-Id gesendet? Eigentlich müssten doch alle Geräte im Netz Befehle von "irgendwelchen" Nodes (mit der gleichen homeId) akzeptieren, oder? Anders kann das ja mit den Assoziationen nicht funktionieren, oder?

Gruß,
Andreas.

[rudolfkoenig]

Befehle an eine Node geschickt und dabei NICHT die Controller-Id gesendet?

Gerade getestet, geht. Sogar mit dem (versehentlich eingestellen) gleichen nodeId, wie das Endgeraet selbst . Und man kriegt dafuer auch ein ACK zurueck. Etwas verwirrend. Aber auch mit anderen nodeIds kein Problem.

[A.Harrenberg]

Hi Rudi,

danke für den Test und die RM. War eine Verständnisfrage für mich, musste aber wegen der Assoziationen und auch Sekundärkontroller eigentlich so sein. Das die NodeId selbst funktioniert ist natürlich wirklich verwirrend... Wahrscheinlich auch für die anderen Geräte falls die Nachricht geroutet wurde ,-)

Gruß,
Andreas.

[Thyraz]

Sehr spannender Thread. Einen CUL statt den ZWave Modulen zu verwenden hätte viele interessante Aspekte.
Ihr hattet es ja auch vom Thema Backup und wie das bei Z-Way etc. aussieht.

Habe davon zufällig gestern hier geschrieben:
http://forum.fhem.de/index.php/topic,48621.0.html

Nachdem ich das eben hier mit dem Backup gelesen habe, hab ich nochmal einen genauen Blick auf die Datei geworfen.
Wenn man das Backup in .tar.gz umbenennt kann man es problemlos entpacken.

Darin sind einige Dateien die nicht groß interessieren solange man nicht ZWay als seine Automatisierungssoftware verwendet,
aber im Unterordner zddx gibt es eine xxxxxxxx-DevicesData.xml welche die gewünschten Infos liefert.

Ich häng das mal hier an und hoffe ich veröffentliche damit keine privaten Infos.
Aber eigentlich sollten das ja neben der HomeID hautpsächlich die Node-Infos sein.

Da ich selber noch keinen CUL habe und auch die bisherigen Infos hier nicht genauer angeschaut habe wie das später in FHEM gespeichert wird,
kann ich nicht sagen ob man da recht einfach einen Converter hinbekommen könnte.
Ein bestehendes Netz in FHEM von Z-Wave-Stick/Razberry nach CUL umzuziehen ohne neu anzulernen wäre natürlich genial...

[rudolfkoenig]

Ein bestehendes Netz in FHEM von Z-Wave-Stick/Razberry nach CUL umzuziehen ohne neu anzulernen wäre natürlich genial...

Fuer jemanden mit etwas Perl-Kenntnissen sollte es eine Fingeruebung sein, Textkonvertierung ist schliesslich die Staerke von Perl.
- Vom controller Tag ist nodeId und homeId interessant, das fliesst in die Definition von ZWCUL ein
- Aus dem device Tag muss man mehr rausfischen, mind. nodeId und classes, modelId waere aber auch interessant.
- die Liste der commandClass Eintraege muss in das Attribut classes uebersetzt werden, das ist notwendig
- die comandClass Versionen werden z.Zt. noch nicht ausgewertet, gespeichert werden sie in FHEM in vclasses
- neighbors werden in FHEM (noch) nicht benoetigt. Ich werde zunaechst statische Routes implementieren, da Dynamische mir suspekt, und in meinem Heimnetz definitiv falsch implementiert sind. Eine erste Version koennte man aus neighbors ableiten.
- ich vermisse modelId, nodeId, associations, abgefragte config-Parameter und gemeldete Daten: ich vermute die kommen weiter hinten in der Datei, und sie ist abgeschnitten, geschaetzt 90% fehlt.

Auf der anderen Seite ist so eine Konvertierung fuer ein Austausch ZWDongle gegen ZWCUL nicht noetig, wenn du vorher auch FHEM verwendet hast, da (bis auf neighbors) alles in fhem.cfg gespeichert ist. Die Konvertierung waere nett, wenn jemand, der eine Umgebung mit Z-Way aufgebaut hat, schnell FHEM ausprobieren wollte. Lebenswichtig ist das auch in diesem Fall nicht, da man mit createNode die mit Z-Way angelernten Nodes in FHEM nachtraeglich anlegen kann.

Koenntest du bitte die komplette Datei anhaengen, und die aktuellen Daten loeschen: sie sind in dieser Form schwer lesbar und unvollstaendig.

[Thyraz]

Himmel hilf, da hat es den Code Tag verrissen durch den langen Text.
In der Post-Vorschau sah noch alles gut aus, das Textlimit muss dann erst beim Abschicken gegriffen haben, sorry.

Hab jetzt oben direkt die Datei angehängt.

Das heißt, FHEM sichert an sich jetzt schon alle relevanten Infos die man für das ZWave Netz braucht, auch wenn ich noch den Razberry verwende.
Das Problem bei einem Hardwaredefekt war also eher, dass man diese Daten von FHEM eben nicht mehr auf einen neuen Razberry/Zway-Stick aufspielen kann.

Auf ZWCUL hingegen schon...

[rudolfkoenig]

Das Problem bei einem Hardwaredefekt war also eher, dass man diese Daten von FHEM eben nicht mehr auf einen neuen Razberry/Zway-Stick aufspielen kann.

Das Hauptproblem bei einem defekten ZWDongle@FHEM ist, dass es keinen mir bekannten Weg gibt, dem neuen Dongle das alte homeId beizubringen. Etwas weniger kritisch aber unschoen ist, dass auch die Nachbarschafts-Eigenschaften verloren sind, und damit das Netz neu berechnet werden muss. Ein Node muss nicht zwangsweise im Dongle nodeList vorliegen, die Kommunikation funktioniert auch ohne (getestet), nur halt ohne Routing.
Ist zway in der Lage das backup auf beliebigen neuen "Dongles" zu restaurieren, oder ist das nur auf dem gleichen Hardware moeglich?

[Thyraz]

Gute Frage, ich hab um mir das Risiko zu sparen einfach nochmal den gleichen Razberry bestellt.
Zumindest eine Wiederherstellung auf Hardware des selben Herstellers könnte man sich ja evtl vorstellen (UZB1).

Wenn man Pech hat geht aber evtl. nicht einmal Razberry V1 zu Razberry V2 (Zwave+ Variante).

[rudolfkoenig]

Habe Routing (ADD/DELETE_RETURN_ROUTE) Kommandos protokolliert, indem ich den Goodway Kommandos ausfuehren liess (siehe Klammer), und mit dem ZWCUL im Monitor mode die Funknachrichten mitgelesen habe (alles auf 40k). S
Studierobjekt ist das komische Routing zu Geraet 12, Nachrichtenweg 01->12 laeuft ab als 01 -> 1a -> 0b -> 12. Beispiel:

   S:12 F:81 f:0 SN:f L:10 T:01 R:00200b1a P:8407 C:5a
   F: singleCast routed, rf:00 hopCnt:2 hopPos:0 hops:0b 1a 
bzw.
   S:01 F:81 f:0 SN:f L:10 T:12 R:00201a0b P:8408 C:55
   F: singleCast routed, rf:00 hopCnt:2 hopPos:0 hops:1a 0b 

Zur Info: es gibt noch ein weiteres "bekanntes" Geraet: 0c (ausgesteckt).
"Ueberfluessige" Daten wie Acks, NodeId, etc habe ich im Folgenden geloescht, bleibt S(ource), T(arget) und P(ayload).

ZW_DELETE_RETURN_ROUTE 12 (get zwdongle raw 4712)
S:01 T:12 P:01 0c 00 0 0    08
S:01 T:12 P:01 0c 00 1 0    08
S:01 T:12 P:01 0c 00 2 0    08
S:01 T:12 P:01 0c 00 3 0    08

ZW_ASSIGN_RETURN_ROUTE 12 (get zwdongle raw 461201)
S:01 T:12 P:01 0c 01 0 1 0b 10
S:01 T:12 P:01 0c 01 1 1 0c 10
S:01 T:12 P:01 0c 00 2 0    08
S:01 T:12 P:01 0c 00 3 0    08

ZW_ASSIGN_RETURN_ROUTE 0b (get zwdongle raw 460b01)
S:01 T:0b P:01 0c 01 0 0    10
S:01 T:0b P:01 0c 01 1 1 0c 10
S:01 T:0b P:01 0c 01 2 1 1a 10
S:01 T:0b P:01 0c 00 3 0    08

ZW_ASSIGN_RETURN_ROUTE 1a (get zwdongle raw 461a01)
S:01 T:1a P:01 0c 01 0 0    10
S:01 T:1a P:01 0c 01 1 1 0b 10
S:01 T:1a P:01 0c 01 2 1 0c 10
S:01 T:1a P:01 0c 00 3 0    08

set "0b" neighborUpdate
S:01 T:0b P:01 04 0401080002   (04: zwaveFindNodesInRange)
S:0b T:01 P:01 07 00           (07: zwaveCommandComplete)
S:01 T:0b P:01 05              (05: zwaveGetNodesInRange)
S:0b T:01 P:01 06 0400000002   (07: zwaveNodeRangeInfo)

Ich lese das so:
- es werden immer 4 Slots gesetzt, 0-3.
- der Inhalt beschreibt optionale Nodes, die als "Weg zurueck" in Frage kommen.
- die verwendete Klasse ist 01, Befehl ist 0c (ich hab das zwaveAssignRoute genannt).
- nach 0c folgt 01, falls das Slot belegt ist, oder 00, falls nicht. Ausnahme: Slot 0 fuer 0b. (?)
- danach kommt Slot-Nummer als Nibble
- danach 1 (als Nibble) falls Routing-Node angegeben wird, sonst 0
- danach (optional) das Routing-Node
- danach 10 oder 08, jenachdem ob der Parameter nach 0c 01 oder 00 war.

Ich bin inzwischen nicht mehr sicher, dass diese Route schwachsinnig ist, da es oefters vorkommt, dass der Goodway die Acks von 12 und 0b nicht hoert, und die Funknachrichten wieder sendet.

Was ich nicht verstehe: Woher weiss 12, dass er Pakete per Route ueber 1a schicken soll? Wenn 12 das vom Routing-Info des Hinwegs ablesen kann, wozu ist Assign_Return_Route gedacht? Vermutung: das sind alles nur Experimente auf dem langen Weg zum volkommenen Routing.

[rudolfkoenig]

Habe in ZWCUL Routing implementiert (gefuehlt Work in Progress).
Howto: "attr ZWNode1 zwaveRoute ZWNode2 ZWNode3"
Dieses Attribut wird nur vom ZWCUL beachtet.
Das Firmware (culfw) muss auch aktualisiert werden.

Ich kann damit ein sonst nicht erreichbaren Node schalten, habe allerdings Zweifel, ob ich alles richtig mache, insb. ob ich die Acks richtig sende.
Weiss jemand, wie _genau_ Routing funktioniert, will sagen, wann wer wem ein ACK schickt? Ich habe in Protocol Overview (SDS10243-2, 6.1.2) einen Diagramm gesehen, das stimmt aber mit meinem Protokoll nicht ueberein:

22:44:41.315 5: deadbeef S:01 F:81 f:0 SN:d L:10 T:12 R:00201a0b P:8408 C:xx
22:44:41.315 5:    F: singleCast routed, rf:00 hopCnt:2 hopPos:0 hops:1a 0b
22:44:41.322 5: deadbeef S:01 F:81 f:0 SN:d L:10 T:12 R:00211a0b P:8408 C:xx
22:44:41.322 5:    F: singleCast routed, rf:00 hopCnt:2 hopPos:1 hops:1a 0b
22:44:41.330 5: deadbeef S:01 F:81 f:0 SN:d L:10 T:12 R:00221a0b P:8408 C:xx
22:44:41.330 5:    F: singleCast routed, rf:00 hopCnt:2 hopPos:2 hops:1a 0b

22:44:41.337 5: deadbeef S:12 F:81 f:0 SN:d L:0e T:01 R:03211a0b P: C:xx
22:44:41.337 5:    F: singleCast routed, rf:03 hopCnt:2 hopPos:1 hops:1a 0b
22:44:41.345 5: deadbeef S:12 F:81 f:0 SN:d L:0e T:01 R:03201a0b P: C:xx
22:44:41.345 5:    F: singleCast routed, rf:03 hopCnt:2 hopPos:0 hops:1a 0b
22:44:41.373 5: deadbeef S:12 F:81 f:0 SN:d L:0e T:01 R:03201a0b P: C:xx
22:44:41.373 5:    F: singleCast routed, rf:03 hopCnt:2 hopPos:0 hops:1a 0b
22:44:41.380 5: deadbeef S:12 F:c1 f:0 SN:d L:0e T:01 R:032f1a0b P: C:xx
22:44:41.380 5:    F: singleCast ackReq routed, rf:03 hopCnt:2 hopPos:15 hops:1a 0b
22:44:41.386 5: deadbeef S:01 F:03 f:0 SN:d L:0a T:1a P: C:xx
22:44:41.386 5:    F: ack

[A.Harrenberg]

Hi Rudi,

mal ein paar Anmerkungen/Vorschläge in gewohnt chaotischer Reihenfolge:

• könntest Du den Post #1 evtl. dahingehend nutzen um die jeweils aktuelle Version der culfw und der ZWCul anzukündigen und dort auch eine kleine History und ein paar Infos ablegen? Z.B. welche culfw für welche ZWCul Version nötig ist?
• hast Du eine Art Roadmap für die Entwicklung des ZWCul?
  Ohne ist es schwer nachzuvollziehen was gerade in Arbeit ist, wohin die Reise geht und wo wir unterstützen können. In Deinem Vortrag in Karlsruhe (habe ich mir im Livestream angesehen) hast Du gesagt das die "anderen" kein Interesse an der Entwicklung haben. Ich habe da sogar großes Interesse dran, hab' ja auch für den CC1100 bereits so einiges gemacht, ist aber so das Du mir da ein gutes Stück voraus bist und mir da einfach der Ansatz fehlt an welcher Stelle gerade Arbeit nötig wäre. Auch das könnte dann gerne in den Post #1.
• Sobald wir das Routing besser verstehen und das ganze einen gewissen Reifegrad hat, würde ich vorschlagen einen "Spin-Off" von ZWCul zu machen, ZWCulNode ,-)
  Hiermit meine ich eine Implementierung von einigen CC als Node in einem nanoCul oder etwas ähnlichem. Ich würde zuerst mal an Schalter / Dimmer oder einfache Sensoren denken die man dann vom Arduino aus realisieren muss/kann.
  
  
  
  • Hier könnte ich mir auch eine "dumme" Node vorstellen die einfach nur vorgebene Nachrichten verschickt (oder entgegennimmt) um das Netz oder neue Funktionen zu testen (geht mit dem ZWCul ja jetzt auch schon) z.B. um OTA zu testen
  Das ist jetzt erst mal nur eine vage Idee und würde schon eine ganze Menge an ZWave-Code auf dem Arduino erfordern der ja beim ZWCul in FHEM ist. Von daher denke ich das dies dann kein kleines Projekt wäre...
  

Gruß,
Andreas.

BTW.: Momentan gibt es erste Planungen für ein Usertreffen in der Region Köln im Mai, bestünden Chancen auf Deine Anwesenheit?

[krikan]

• könntest Du den Post #1 evtl. dahingehend nutzen um die jeweils aktuelle Version der culfw und der ZWCul anzukündigen und dort auch eine kleine History und ein paar Infos ablegen? Z.B. welche culfw für welche ZWCul Version nötig ist?

Sorry Andreas, dass ich da Contra gebe.
Bitte nicht per Edits Aktualisierungen posten. Das geht unter, da man nicht über Änderungen informiert wird. Es sei denn, Rudi weist in einem neuen Post im Thread auf die Änderungen im ersten Post hin. Ist ein wenig ABM  .