ZWave @ culfw

krikan · 06 Januar 2016, 09:23:13

Zitat von: A.Harrenberg am 06 Januar 2016, 09:02:38
mir ging es erst mal darum das FLIRS als Eigenschaft in NIF erkannt wird. Soweit ich das bisher gesehen habe steht da eigentlich immer nur "Listening".

FLIRS Eigenschaft können wir auch ohne sniffen erkennen. Wenn nodeInfo (0x42) abgerufen wird, steckt das jetzt in beaming (ungenau) drin. Könntest Du die raw-Messages von nodeInfo posten? Habe hier schon eine Sammlung von raw-nodeInfo plus Auswertung (flirs, beaming, 100k usw.) und muss das Schema noch finden. Wenn einer von Euch das so kann, natürlich auch gut. Bei mir dauert das noch....

A.Harrenberg · 06 Januar 2016, 11:55:04

Hi Christian,

Zitat von: krikan am 06 Januar 2016, 09:23:13
FLIRS Eigenschaft können wir auch ohne sniffen erkennen. Wenn nodeInfo (0x42) abgerufen wird, steckt das jetzt in beaming (ungenau) drin. Könntest Du die raw-Messages von nodeInfo posten? Habe hier schon eine Sammlung von raw-nodeInfo plus Auswertung (flirs, beaming, 100k usw.) und muss das Schema noch finden. Wenn einer von Euch das so kann, natürlich auch gut. Bei mir dauert das noch....

ich lerne das Ding dann noch mal unter FHEM an und protokolliere die Inklusion, da ist der NIF ja mit drin.

Allerdings ist mir aufgefallen das unter Z-Way der Kontroller 3-4 Nachrichten schickt bevor das Danalock antwortet, ich muss mal schauen ob das mit FHEM auch so ist.

Und was das dekodieren des Schemas angeht hilft da wohl nur sich alle gefundenen Möglichkeiten mal hexadezimal oder sogar binär untereinander zu schreiben und dann zu schauen. Ich drängel mich da jetzt nicht in die erste Reihe...

Gruß,
Andreas.

krikan · 06 Januar 2016, 13:06:10

Zitat von: A.Harrenberg am 06 Januar 2016, 11:55:04
ich lerne das Ding dann noch mal unter FHEM an und protokolliere die Inklusion, da ist der NIF ja mit drin.

Mir reicht eigentlich die Rohnachricht der Abfrage von "get <device> nodeInfo" (siehe btw http://forum.fhem.de/index.php/topic,44905.msg378940.html#msg378940)
Bei mir dauert die Umsetzung noch etwas, wollte nicht, dass ihr Euch wegen mir zurückhaltet

. Prio ist niedrig; erst kommt EnO-Wiki.

Zu SDR:
Gibt so etwas für DVB-T Sticks. Meine ich habe sogar noch einen Terratec, der hier erwähnt wird http://sdr.osmocom.org/trac/wiki/rtl-sdr. Wenn Interesse besteht schaue ich mal, ob der noch funktioniert und stelle den gerne zur Verfügung.

A.Harrenberg · 06 Januar 2016, 13:22:41

Hi Christian,

Zitat von: krikan am 06 Januar 2016, 13:06:10
Mir reicht eigentlich die Rohnachricht der Abfrage von "get <device> nodeInfo" (siehe btw http://forum.fhem.de/index.php/topic,44905.msg378940.html#msg378940)
Bei mir dauert die Umsetzung noch etwas, wollte nicht, dass ihr Euch wegen mir zurückhaltet . Prio ist niedrig; erst kommt EnO-Wiki.

da das Ding momentan an Z-Way angelernt ist muss ich es sowie so anlernen, ich kann mal das Anlernen und die Abfrage loggen, der darin übertragene NIF sollte mMn aber identisch sein.

Zitat von: krikan am 06 Januar 2016, 13:06:10
Zu SDR:
Gibt so etwas für DVB-T Sticks. Meine ich habe sogar noch einen Terratec, der hier erwähnt wird http://sdr.osmocom.org/trac/wiki/rtl-sdr. Wenn Interesse besteht schaue ich mal, ob der noch funktioniert und stelle den gerne zur Verfügung.

Ich muss mal schauen, ich habe auch noch so einen Stick rumzuliegen, allerdings bin ich nicht sicher wie das mit der Modulation ist und ob man die bei ZWave verwendete Modulation auch für den DVB Stick einstellen kann.

Ich schau mir das in den nächsten Tagen mal an, wird aber etwas dauern.

Gruß,
Andreas.

A.Harrenberg · 06 Januar 2016, 18:53:22

Hallo Christian,

hier die NodeInfo von dem Danalock, das ist aber 0x41 und nicht 0x42...

Code Auswählen

2016.01.06 18:51:02.123 4: ZWDongle get ZWDongle_0 nodeInfo 189
2016.01.06 18:51:02.123 5: ZWDongle_Write 0041bd ()
2016.01.06 18:51:02.123 5: SW: 01040041bd07
2016.01.06 18:51:02.124 4: ZWDongle_ReadAnswer arg:nodeInfo regexp:^0141
2016.01.06 18:51:02.219 5: ACK received, removing 01040041bd07 from dongle sendstack
2016.01.06 18:51:02.246 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 014153dc01044003
2016.01.06 18:51:02.246 5: SW: 06
2016.01.06 18:51:02.247 4: ZWDongle_ReadAnswer for nodeInfo: 014153dc01044003

Gruß,
Andreas.

krikan · 06 Januar 2016, 18:59:14

Zitat von: A.Harrenberg am 06 Januar 2016, 18:53:22
hier die NodeInfo von dem Danalock, das ist aber 0x41 und nicht 0x42...

Danke und korrekt; und das mit meiner neuen Brille hatte ich dieser Tage schon mal erwähnt.

A.Harrenberg · 07 Januar 2016, 22:29:16

Hi Christian,

Zitat von: A.Harrenberg am 06 Januar 2016, 13:22:41
Hi Christian,da das Ding momentan an Z-Way angelernt ist muss ich es sowie so anlernen, ich kann mal das Anlernen und die Abfrage loggen, der darin übertragene NIF sollte mMn aber identisch sein.
Ich muss mal schauen, ich habe auch noch so einen Stick rumzuliegen, allerdings bin ich nicht sicher wie das mit der Modulation ist und ob man die bei ZWave verwendete Modulation auch für den DVB Stick einstellen kann.

Ich schau mir das in den nächsten Tagen mal an, wird aber etwas dauern.

hab die SW mal compiliert, mein Stick scheint aber nicht kompatibel zu sein, zumindest sagt rtl-test "No supported devices found." ,-(

Ich ich bin mir aber auch nach etwas lesen nicht sicher ob uns das weiterbringen würde...
Wenn es jemand schaffen sollte mit so einem Stick die Übertragung irgendwie sichtbar zu machen könnte man da noch mal ran, aber so lasse ich das jetzt erst mal wieder liegen...

Gruß,
Andreas.

A.Harrenberg · 08 Januar 2016, 23:47:05

Hallo Rudi,

senden in 9.6k geht ,-)

Momentan zwar nur händisch, aber es funktioniert so wie ich mir das gedacht habe.

Manchester ausschalten, 15x 0x55 als Preamble, 1x 0xf0 als Sync und das Datenpaket (momentan extern) als Manchester kodieren, dann zweimal 0x00 anhängen und senden ...
Zusätzlich habe ich noch den Syncmode auf "4" -> "No preamble/sync, carrier-sense above threshold" gesetzt damit nicht noch eine zusätzliche Preamble gesendet wird.

Näheres dann morgen...

Gruß,
Andreas.

A.Harrenberg · 09 Januar 2016, 08:12:29

Hi,

kleines Update:
Bisher kann ich nur an den Controller senden, der Steckdosenschalter reagiert nicht, an meine Sirene möchte ich lieber kein Testkommando schicken...

Der Controller scheint aber die "Code violation" nicht zu benötigen, zumindest empfängt der auch ohne das ich hinten "0000" anhänge. Das der Steckdosenschalter nicht reagiert könnte also alles möglich sein... ;-(

Gruß,
Andreas.

A.Harrenberg · 09 Januar 2016, 08:22:27

Hi,

kaum geschrieben und schon den Fehler gefunden... Die Checksumme bei den Befehlen an den Steckdosenschalter war falsch ,-(
Senden funktioniert also doch allgemein ,-)

Allerdings bin ich etwas verwirrt, da der Steckdosenschalter auch ohne die "Code Violation" funktioniert... Da frage ich mich dann warum das mit Manchester in Hardware nicht funktioniert.

Grübelnd,
Andreas.

A.Harrenberg · 09 Januar 2016, 11:31:22

Hi Rudi,

ich habe mal ein paar Zeilen in die rf_zwave.c eingehackt, damit kann ich jetzt 9.6k senden und empfangen. Auch wenn der Betreff "Patch" ist, ich hab' die ganze Datei angehängt...

Vielleicht schaust Du mal ob das mit dem Umschalten des CC1100_MDMCFG2 Register so in Ordnung ist, ich hatte ein paar Probleme damit...

Gruß,
Andreas.

A.Harrenberg · 09 Januar 2016, 20:20:11

Hi,

ich habe jetzt den Tag über weiter mit dem CUL rumgespielt. Meine ZWave-Geräte scheinen immer wieder mal die Datenrate zu ändern, vor allem wenn man mit einem Geräte z.B. in 9.6k kommuniziert scheint es mir so als ob dann auch ein anderes Gerät dann plötzlich in 9.6 senden würde. Könnte sein das da Effekte von gesetzten Routen reinspielen, die dann auch komplett umschalten...

Ab-und-zu habe ich auch den Eindruck das der CUL nichts empfangen will... Dann wechsel ich von 9.6 auf 40 auf 100 und dann wieder runter und plötzlich sehe ich wieder Nachrichten. Das kann ich jetzt aber momentan nicht provozieren, kann auch sein das es mit dem Umschalten des Registers zu tun hatte und ein selbstgemachtes Problem war.

Ich habe mir momentan die LED mal zu "Anzeige" der RSSI eingerichtet, bei RSSI > 0x70 geht die LED an, bei <0x60 wieder aus. Ich habe das jetzt noch nicht in dB umgerechnet, dient auch nur als Anzeige ob gerade "Traffic" ist...
Bei empfangenen Paketen lasse ich mir den Wert auch noch schicken um zu sehen wie hoch die Werte so gehen, eine meiner Ideen war es ja zyklisch durch die drei Modi zu schalten und den RSSI auszuwerten um zu erkennen welcher Mode gerade gesendet wird.

Nach den bisherigen Erkenntnissen wird das allerding eher nicht gehen. Trotz der Unterschiede in der Frequenz zeigt sich im 9.6 Modus eine deutliche Erhöhung im RSSI-Wert wenn eine 100k Nachricht verschickt wird. Daher wird man anhand des RSSI (alleine) nicht erkennen können um welche Übertragungsart es sich handelt.

Nach meiner ersten Abschätzung reicht aber die Zeit nicht aus um mit dem Preamble Quality Threshold (PQT) eine Aussage treffen zu können... Ich schau mir den PQT jetzt aber dennoch mal an, sehr viele weitere Ideen habe ich dann auch nicht mehr. Es bleibt also "interessant"...

Gruß,
Andreas.

rudolfkoenig · 10 Januar 2016, 16:18:25

Andreas: Senden @ 9600 scheint bei mir mit dem as6 zuverlaessig zu funktionieren, vielen Dank. Ist in culfw eingecheckt, mit CUL_V3_ZWAVE.hex und CUL_V4.hex

Habe in ZWCUL addNode/removeNode implementiert, das hat jetzt auch merfach funktioniert, gefuehlt 100-mal, bis ich das alles ohne Fehler hingekriegt habe

. Fuer addNode/removeNode geht das CUL auf 9600, um nach getaner Arbeit wieder auf 40k/100k umzuschalten. Die init Strings (associationAdd, get model, etc) werden ohne Probleme abgearbeitet.

Damit ist ein CUL ab sofort "drop-in" Ersatz fuer beliebige ZWDongles, obwohl einige Features wie routing, explorer Frames, etc noch nicht implementiert sind. Ich muss aber nicht mehr Panik schieben, falls mein Goodway seinen Geist aufgibt, und ich werde demnaechst die Routen so setzen koennen, wie ich es fuer sinnvoll halte.

Neu: addNodeId <decimalNodeId>, um bestimmte nodeIds setzen zu koennen. Merkwuerdig: wenn ich mit dem CUL dem as6 die ID 55 zuweise, und dann versuche sie mit dem ZME zu schalten, dann funktioniert das, obwohl laut nodeList die ZME keinen Node mit ID 55 kennt.

nodeInfo funktioniert auch, wenn man den Knoten mit dem CUL includiert, da es dabei ein paar Bytes in dem nodeInfo Reading des Nodes gespeichert werden. Allerdings ist "ROUTING_SLAVE" geflunkert, keine Ahnung, wo das (bzw. Byte 5) herkommt.

A.Harrenberg · 10 Januar 2016, 16:50:23

Hallo Rudi,

Zitat von: rudolfkoenig am 10 Januar 2016, 16:18:25
Andreas: Senden @ 9600 scheint bei mir mit dem as6 zuverlaessig zu funktionieren, vielen Dank. Ist in culfw eingecheckt, mit CUL_V3_ZWAVE.hex und CUL_V4.hex

Habe in ZWCUL addNode/removeNode implementiert, das hat jetzt auch merfach funktioniert, gefuehlt 100-mal, bis ich das alles ohne Fehler hingekriegt habe . Fuer addNode/removeNode geht das CUL auf 9600, um nach getaner Arbeit wieder auf 40k/100k umzuschalten. Die init Strings (associationAdd, get model, etc) werden ohne Probleme abgearbeitet.

Ich habe den CUL auch schon gefühlte 500mal geflasht, in Wirklichkeit sind es aber wahrscheinlich 100-200

Und bei meinen Testsytem an dem ich SECURITY und das DanaLock daran habe bin ich jetzt bei ID 194, ich bin mal gespannt was nach 232 kommt...

Gehen die Geräte denn nach der Inklusion sauber auf Ihre 40k/100k? Ich habe bei mir sehr schwer nachvollziehbare Effekte wenn ich auf 9.6k sende. Teilweise kommt das ACK dann auf 9.6k, die nächste Nachricht aber wieder auf 40k. Ich geh' davon aus das die Geräte immer zuerst Ihre höchste Datenrate senden, egal was gerade so an anderen Geräten mit dabei ist.

Zitat von: rudolfkoenig am 10 Januar 2016, 16:18:25
Damit ist ein CUL ab sofort "drop-in" Ersatz fuer beliebige ZWDongles, obwohl einige Features wie routing, explorer Frames, etc noch nicht implementiert sind. Ich muss aber nicht mehr Panik schieben, falls mein Goodway seinen Geist aufgibt, und ich werde demnaechst die Routen so setzen koennen, wie ich es fuer sinnvoll halte.

Hmm, so ein "Backup" des Sticks wäre ja nicht schlecht. Ich muss mal schauen, das müsste von Z-Way ja eigentlich unterstützt werden... Vielleicht kann ich damit ja meinen normalen Stick mal auslesen, wobei ich ja nur die RazBerry Version habe und der den Stick dann vielleicht gar nicht will...

Aber wie kannst Du denn Routen setzen? Habe ich da was verpasst und Ihr habt in der Zwischenzeit rausgefunden wie das mit den Routen funktioniert und welche Informationen man der Node mitteilen muss?

Zitat von: rudolfkoenig am 10 Januar 2016, 16:18:25
Neu: addNodeId <decimalNodeId>, um bestimmte nodeIds setzen zu koennen. Merkwuerdig: wenn ich mit dem CUL dem as6 die ID 55 zuweise, und dann versuche sie mit dem ZME zu schalten, dann funktioniert das, obwohl laut nodeList die ZME keinen Node mit ID 55 kennt.

Äh, das ist dann aber für bereits im Netz inkludierte Geräte gedacht, oder?

Zitat von: rudolfkoenig am 10 Januar 2016, 16:18:25
nodeInfo funktioniert auch, wenn man den Knoten mit dem CUL includiert, da es dabei ein paar Bytes in dem nodeInfo Reading des Nodes gespeichert werden. Allerdings ist "ROUTING_SLAVE" geflunkert, keine Ahnung, wo das (bzw. Byte 5) herkommt.

Das sagt mir jetzt auch Anbieb nicht viel, dazu müsste ich mir ansehen was da in der NodeInfo so alles drin steckt...

Aber das Problem mit den verschiedenen Datenraten haben wir auch weiterhin und ich bin nicht wirklich optimistisch was so eine "Umschaltstrategie" angeht. Die Lösung mit (nur) RSSI wird nicht funktionieren, das reagiert auch auf mein HomeMatic und wer weiß was sonst noch. Diese PQT (Preambel Quality) kann man nicht als Wert auslesen, sondern es gibt nur ein Bit wenn sie erreicht wurde. Damit schaltet man dann aber auch ein das die Schwelle nötig ist um das SyncWort als gültig zu erkennen. Ich habe bisher noch nicht viel Erfolg damit gehabt das mal einzuschalten (ist standardmäßig aus), und zu tracen ohne gleich Logfiles von einigen Megabytes zu haben in denen ich dann auch nichts mehr finden kann...

Ich werde das mal mit einer etwas niedrigeren Prioriät weiter verfolgen und den CUL jetzt erstmal dazu einsetzen wozu ich Ihn eigentlich gekauft habe, nämlich rauszubekommen war mein RFID-Leser nicht über den Steckdosenschalter routen will deshalb so oft nicht funktioniert...

Gruß,
Andreas.

rudolfkoenig · 10 Januar 2016, 18:54:45

ZitatGehen die Geräte denn nach der Inklusion sauber auf Ihre 40k/100k?

Naja, bisher habe ich nur die as6 getestet. Ich sende da nur den ACK auf NIF und danach zwaveAssignId @ 9600. sobald die ACK dafuer eintrifft, schalte ich auf 40k, um die init Befehle abzusetzen. Das klappt bisher ohne Aussetzer. Auch die "freiwilligen" Nachrichten kommen auf 40k. In nodeInfo steht zwar drin, ob ein Geraet 40k kann, ich habe aber nicht rausgefunden, wie man die 100k rauskriegt. Und ich erwarte, dass als Controller dem Endgeraet auch mitteilen kann, was man selbst senden kann, das ist aber auch noch Forschung. Mit einem parallelen Empfang aller Datenraten mit dem CUL rechne ich nicht.

Wenn du den Backup hinkriegst, bitte dokumentieren. Aber selbst mit einem Backup hat man Probleme, man ist naemlich auf dem Hersteller angewiesen, dass er genau dieses Produkt vorraetig haelt. Ist mAn ein Designfehler aller ZWave Sticks.

Statische Routen kann man im Paket setzen (das kennen wir), und es muss ein Befehle geben, um diese im Endgeraet zu speichern. Es gibt ein ZW_ASSIGN_RETURN_ROUTE, leider weiss ich nicht, wie man es bedient.

addNodeId kann man zum bequemeren Austausch eines Geraetes verwenden. Oder wenn man eine bestimmte Systematik bei der Nummernvergabe hat. Und zum Experimentieren

Im nodeInfo steht drin, ob das Geraet per Security angebunden ist (oder es nur kann?), ob es routen kann (weil staendig an), ob es FLIRS kann, und ob es 40k kann. Einige Bits sind aber ein Raetsel fuer mich, und die Erklaerung im Aeon-updater-XML kapiere ich auch nicht.