ZWave @ culfw

krikan · 05 Dezember 2015, 20:53:14

Zitat von: krikan am 05 Dezember 2015, 15:12:48
Aus Deinen Ergebnissen muss man dann doch schließen, das 100k und 40k gleichzeitig laufen!? Hätte ich derzeit bei mir nicht so gesehen.

Auch bei mir sind nach Durchsicht von einigen Stunden Logs 40k und 100k gleichzeitig aktiv. 100k-Geräte sehe ich jetzt nicht mehr mit Telegrammen; 40k hingegen wohl. Warum das vorher anders war, verstehe ich nicht wirklich. An Zufälle glaube ich nicht. Evtl. wird in bestimmten Situationen automatisch runter- und hochgeschaltet?

A.Harrenberg · 06 Dezember 2015, 11:50:20

Hi,

so, ich kann jetzt 100kBaud empfangen!

Nachdem ich jetzt den ganzen Vormittag immer wieder neu geflasht habe, kann ich jetzt die 100kBaud Nachrichten sehen. Der "Witz" an der Sache war hauptsächlich das für 100kBaud eine andere Frequenz genutzt wird! 869.85MHz anstatt der "normalen" Frequenz von 868.40MHz, siehe hier.

Damit scheint es aber auch erst einmal ausgeschlossen zu sein das 40kBaud und 100kBaud "gleichzeitig" möglich sind. Die Empfänger in den ZWave-Sticks scheinen da mehrkanalig ausgelegt zu sein.

Die anderen Settings für z.B. Bandbreite und Deviation sind momentan willkürlich gesetzt (Vorgabe von TI für 100kBaud, allerdings mit anderen Modulation...) und sicherlich optimierungsfähig. Ab und zu tauchen da auch "Schrottpakete" auf, hält sich aber in Grenzen. Vielleicht gibt es ja jemanden der sich da RF mäßig etwas besser auskennt und die Parameter optimieren kann.

@Rudi: Siehst Du Dich in der Lage die beiden Presets umschaltbar in culfw zu implementieren? z1 -> 100kBaud, z4 -> 40kBaud?? Die geänderten Werte sind im angehängten rf_zwave.c.

@Christian: Ich habe Dir mal das hex angehängt falls Du nicht selbst compilieren kannst.

Gruß,
Andreas.

A.Harrenberg · 06 Dezember 2015, 12:35:43

Hi,

kleiner Nachtrag...
Senden scheint aber irgendwie nicht zu funktionieren...

Gruß,
Andreas.

P.S.: Ich werde jetzt aber erst mal wieder auf 40kBaud gehen, ich wollte damit ja mein RFID-Pad überwachen und sehen warum der die WUN mehrfach sendet, bzw. ob das Ding über den Steckdosenschalter geroutet wird oder nicht.

A.Harrenberg · 06 Dezember 2015, 13:16:32

Hi,

noch ein weiterer Nachtrag:

100kBaud Nachrichten 1 Byte länger...
Hier mal ein Beispiel 40kBaud aus meinem "Produktivnetzwerk", 100kBaud aus dem Testnetzwerk

zxxxxxxxx0141020D0A2501FFC9 (40 kBaud)
zxxxxxxxx0141090EAE2501FF8C7A (100 kBaud)

Unter 100kBaud gibt es jetzt anscheinend CRC16 Checksummen! Zumindest in dem Beispiel passt die "8C7A" zu meiner errechneten CRC16. Gut das ich das vor kurzem in ZWave integriert habe...

Ich habe mal das zwave_cs.pl entsprechend erweitert, das gibt jetzt die Cecksumme und eine CRC16 aus.

Allerdings reagiert mein Steckdosenschalter auch damit nicht auf gesendete Befehle...

Gruß,
Andreas.

krikan · 06 Dezember 2015, 13:34:01

@Andreas:
Glückwunsch. Habe ich das richtig verstanden: Wenn ich Dein .hex flashe, sehe ich kein 40k und muss wieder Rudis Variante für 40k flashen? Im Fazit brauche ich dann 2 Culs damit ich gleichzeitig 40k und 100k sehe?

A.Harrenberg · 06 Dezember 2015, 13:46:59

Hi Christian,

Zitat von: krikan am 06 Dezember 2015, 13:34:01
@Andreas:
Glückwunsch. Habe ich das richtig verstanden: Wenn ich Dein .hex flashe, sehe ich kein 40k und muss wieder Rudis Variante für 40k flashen? Im Fazit brauche ich dann 2 Culs damit ich gleichzeitig 40k und 100k sehe?

soweit ich das bisher verstehe ja.
Neben der unterschiedlichen Frequenz ist da auch noch ein anderes Modulationsverfahren für 100kBaud...

Ich bin mir nicht sicher ob die ZWave-Dongles mehrkanalige Empfänger haben und beides gleichzeitig haben, oder irgendwie an der Präambel erkennen können was gerade gesendet wird und dann schnell genug umprogrammieren können bevor die Nutzdaten kommen.

Senden funktioniert momentan ja anscheinend auch noch nicht, kann sein das da jetzt noch weitere Parameter geändert werden müssen. Das läuft noch darauf hinaus das man den zweiten Stick braucht um den ersten zu überwachen ,-)

Ich muss mich jetzt aber erst mal um mein Problem mit dem RFID-Pad kümmern, da habe ich gerade so einen Fall mitschneiden können in dem das Pad rot geblinkt hat und nichts in FHEM angekommen ist.
Die Nachrichten muss ich jetzt mal zerlegen und sehen was da drin ist...

Hast Du denn jetzt eigentlich so einen NanoCul genommen oder hast Du auch einen Cul_V3, das Hexfile war ja nur für den Cul_V3.

Gruß,
Andreas.

krikan · 06 Dezember 2015, 13:56:31

OK, dann warte ich mit dem umflashen erst noch mal und stürze mich auf 40k.
Habe den CUL V3 im Einsatz. Auf den miniCul von locutus warte ich noch. Für letzteren gibt es sowieso fertig "nur" die a-clufw und die ist noch ohne ZWave.

Zum umswitchen 40k/100k: Die Sirene von der die obigen Logs stammen hat auch 100k. Die tauchte nach einiger Zeit auch nicht mehr in "screen" auf.

A.Harrenberg · 06 Dezember 2015, 14:04:00

Hi,

ich denke das Rudi es hinbekommt die Parametersätze für 40kBaud / 100kBaud umschaltbar in culfw zu implementieren ,-)

Dann könnte man wenigstens ohne umflashen zwischen den beiden schalten. Wobei ich mich schon den zweiten kaufen sehe...

Gruß,
Andreas.

rudolfkoenig · 06 Dezember 2015, 15:19:19

@Andreas: ich habe deine Aenderungen eingecheckt.
Aktivieren kann man 100k mit zr1/zm1 (oder zr100/zm100), zr/zm (oder von mir aus zr40/zm40) aktiviert die 40k Version. Allerdings kann ich hier keine 100k Nachrichten empfangen, aus ca 20 Versuchen habe ich genau einmal ein Paket gesehen. 40k scheint dagegen 100% zu klappen.

A.Harrenberg · 06 Dezember 2015, 15:57:48

Hi Rudi,

super, vielen Dank, dann ziehe ich mir die neue Version gleich mal runter.

Zum 100k Empfang, meine Testgeräte befinden sich momentan alle im Radius von ca. 1m voneinander weg, kann sein das da die Einstellungen für die Bandbreite / Deviation nicht wirklich passen, da hört mein RF Wissen dann aber auch so langsam auf... Empfängst Du denn mit zr oder zm?? zr dürfte wegen der CRC16 nicht funktionieren, ich habe hier immer "zm" laufen.

Sehe ich das richtig das vom CC1100 nur die Präambel und das SyncByte vorangestellt wird, aber KEINE Checksumme angehängt wird? Falls da doch was angehängt wird müsste das zumindest für 100k abgeschaltet werden, der CC kann mMn ja keine CRC16.

Gruß,
Andreas.

A.Harrenberg · 06 Dezember 2015, 16:10:23

Hi Rudi,

läuft!

Jetzt muss ich mir aber endlich mal die Messages von meinem RFID-Pad anschauen...

Danke,
Andreas.

rudolfkoenig · 06 Dezember 2015, 21:04:04

Ab sofort gibt es ein 00_ZWCUL.pm.
Ist fuer den Benutzer nicht ganz so schoen, wie 00_CUL.pm aufbohren, ich habs aber einfacher, und keiner der CUL-Anwender wird genervt.

Achtung fuer SVN Lader: ZWDongle und ZWave wurden geaendert, und es gibt ein ZWLib.pm

Z.Zt. empfohlene Konfig (natuerlich auf lokale Gegebenheiten angepasst):

Code Auswählen

attr global autoload_undefined_devices 1
attr global logfile -
attr global modpath .
attr global motd none
attr global mseclog 1
attr global statefile log/fhem.state.zwcul
attr global verbose 3

define telnetPort telnet 7074
define autocreate autocreate

define zwc ZWCUL /dev/cu.usbmodemfd141 00000000 01
attr zwc verbose 5

Das besondere ist 00000000 (homeId), damit wird in culfw Monitoring bestellt (zm). Damit sollten ZWave Geraete beim Empfang von Nachrichten automatisch angelegt werden (wie man das von FS20 gewohnt ist), und man kann sie auch sofort schalten, da classes automatisch mit der empfangegen Klasse erweitert wird. Oder man setzt classes selbst.

Get funktioniert nicht, Senden ist primitiv (hardcoded flag 41), inclusion, etc funktioniert nicht. Ich habe auch mit einem "richtigen" homeid noch nicht experimentiert, damit sollte culfw ein ACK schicken. Achtung: Beim WakeUp devices wird ungefragt ein "wakeup:noMoreBlabla" versendet, das muss ich noch ausbauen. 100k wird nicht unterstuetzt. Es ist also noch viel zu tun.

A.Harrenberg · 06 Dezember 2015, 21:21:32

Hallo Rudi,

uih, da hast Du aber schon mal wieder einen großen Schritt vorwärts gemacht!

Werde mir das dann auch mal ansehen, wobei ich ja eigentlich nicht will das da Geräte angelegt werden. Wenn ich eine homeID setze, passiert das dann nicht? Was ist in dem Fall mit Nachrichten mit falscher CS?

Das "gleichzeitige" Loggen hätte natürlich riesige Vorteile und würde mir auch erst mal reichen ,-)

Gruß,
Andreas.

rudolfkoenig · 07 Dezember 2015, 07:53:42

Was hast du gegen Geraete-Anlegen? Ist nur eine Test-Konfiguration, die entfernt werden kann.
Es werden auch keine FileLogs angelegt, nur die ZWave-Definitionen. Das allerdings auch fuer zufaellig empfangenen Muell. Ich finde es nett die vom ZWave dekodierten Pakete zu haben.

Wir koennen aber ein ZWCUL Attribut einbauen, um das ZWave-Stack aus dem Spiel zu lassen.

A.Harrenberg · 07 Dezember 2015, 08:19:18

Hallo Rudi,

ich werde das mal in meinem Testsystem ausprobieren und dann im Produktivsystem einsetzen, da habe ich ja die Übertragungsprobleme welche ich durch das Sniffen mal etwas untersuchen wollte.
Falls es einfach sein sollte das mit einem Attribut schaltbar zu machen würde ich das zum sniffen bevorzugen, ansonsten ist es aber wahrscheinlich wirklich nicht so schlimm das die Geräte angelegt werden.

Du schreibst das auch für "zufällig empfangenen Müll" Geräte angelegt werden, passiert das auch wenn die Checksumme nicht stimmt? Mit passender Checksumme dürfte doch gar nicht mehr soo viel Datenmüll ankommen, oder?

Ich müsste aber erst mal das Produktivsystem auf einen "echten" Rechner ausprobieren um sicherzustellen das es nicht doch ein Problem mit der virtuellen Maschine ist. Nach den ersten Ergebnisse des Sniffens (hier) würde ich eher sagen Bug in FHEM oder Problem mit USB in virtueller Maschine...

Gruß,
Andreas.