ZWave @ culfw

[rudolfkoenig]

culfw ab 1.66 (gerade eingecheckt) kann ZWave@40kHz empfangen.

 

Es funktioniert z.Zt nur das Lesen, und das auch ohne FHEM Support.
Konfiguriert habe ich es fuer CUL_V3 und CUL_V4.
Lesen aktivieren (z.Bsp. im screen/etc): zr<return>

Aufbau einer Zeile:
zHHHHHHHHSSFFffLLTTPP*CC
z: Praefix von culfw. Rest ist genau das, was per Funk empfangen wurde.
H: Homeid
S: Source
F: Flag?
f: flag?
L: Length
T: Target
P: Payload
C: Checksum

Daten mit falscher Checksum werden nicht ausgegeben.
Folgendes ist ein Mitschnitt von "set Lampe off; get Lampe version". HomeId habe ich nachtraeglich verfremdet,  Checksum aber nicht angepasst.

Code: [Auswählen]

z1234567801410A0D192501001F
z1234567819030A0A017E
z1234567801410B0C198611AC
z1234567819030B0A017F
z12345678194102110186120602400101FF
z123456780103020A1976

Gerade gelernt: Telegramme werden bei fehlender Quittierung bis zu 3-mal versendet.

Habe ich schon gesagt ?

Vielen Dank an Behrang Fouladi und Sahand Ghanoun!

[krikan]

  Prima! Danke für Deine Arbeit; ging nun ja überraschend schnell. Jetzt brauch ich wohl doch noch einen CUL.

[A.Harrenberg]

Hi,

uih, das ging jetzt aber schnell... ,-)
Und jetzt sind gerade alle miniCuls ausverkauft... Christian hat sich wohl den vorletzten gesichert ,-)

Ich hatte gerade eben überlegt einen bei Busware zu kaufen, die senden aber nicht an Packstationen und im Weihnachtstrubel in der Schlange bei der Paketausgabe in der Post zu stehen macht keinen Spaß, daher hatte ich das erst mal zurückgestellt.

Jetzt seh' ich den Thread und werde mich wohl umentscheiden und einen bestellen... Aber dafür lohnt sich das ja doch wieder.

Super, vielen Dank!
 Andreas.
 

[A.Harrenberg]

Hi Rudi,

Aufbau einer Zeile:
zHHHHHHHHSSFFffLLTTPP*CC

jetzt gilt es mal die Flags zu dekodieren, die Payload kennen wir ja schon ;-) Mein Cul ist bestellt...
Der Aufbau einer "ACK" Meldung ist auch noch nicht so wirklich offensichtlich, anscheindend wird hier u.A. das "f"-Flag (Msg-Counter??) zurückgemeldet.

Daten mit falscher Checksum werden nicht ausgegeben.

Ich habe jetzt noch nicht in den Code geschaut, aber könnte man das einstellbar machen damit auch solche Pakete ausgegeben werden? Bei Übertragungsproblemen würde ich gerne sehen wenn da kaputte Pakete rumschwirren.

Folgendes ist ein Mitschnitt von "set Lampe off; get Lampe version". HomeId habe ich nachtraeglich verfremdet,  Checksum aber nicht angepasst.

Code: [Auswählen]

z1234567801410A0D192501001F
z1234567819030A0A017E
z1234567801410B0C198611AC
z1234567819030B0A017F
z12345678194102110186120602400101FF
z123456780103020A1976


Was mich hier gerade wundert und brennend interessiert ist, wo da die Routinginformationen sind? Die beiden Flags reichen dazu nicht aus, ich meine im Pätz gelesen zu haben das dazu auch diese 29byte wie in der Neighborlist verwendet. Es könnte aber sein das der Controller erkennt das eine direkte Kommunikation möglich ist und dann diese 29byte "spart". Es könnte auch sein das dies mit Explorerframes noch mal anders aussieht.

Rudi, könntest Du vielleicht noch mal so nett sein und so ein kleinen Schnippsel machen wenn Explorerframes ausgeschaltet sind und/oder bei einem Gerät das geroutet wird (falls Du eins hast)?

Ach ist das alles spannend ,-)

Gruß,
 Andreas.

[rudolfkoenig]

Da ich nicht so recht weiss, wie ich das machen soll, investiere ich meine Zeit lieber in die Integration in FHEM und in Senden. Ich will dir nicht die Freude eigener Entdeckungen nehmen

Da wir z.Zt nur 40kBaud unterstuetzen: weiss jemand, ob die anderen Datenraten relevant sind, z.Bsp. beim Includieren? Hat jemand Geraete, die mit einer andere Datenrate funken? Ich habe laut nodeInfo nur welche mit 40kBaud. Ich wuesste z.Zt. nicht, wie man mit der CC1101 mehrere Datenraten parallel empfangen koennte.

[A.Harrenberg]

Hi Rudi

Da ich nicht so recht weiss, wie ich das machen soll, investiere ich meine Zeit lieber in die Integration in FHEM und in Senden. Ich will dir nicht die Freude eigener Entdeckungen nehmen

ok, die Integration in FHEM hat da sicherlich einen größeren Stellenwert. Aber was ist dein Ziel dabei? Willst Du das als echten Dongle-Ersatz implementieren? Dann müssten doch so einige der Controllerbefehle implementiert werden... Und das dürfte mit dem bisherigen Wissen nahezu unmöglich sein. Aber das "sniffen" düfte unser Wissen hier deutlich verbessern ,-)

Da wir z.Zt nur 40kBaud unterstuetzen: weiss jemand, ob die anderen Datenraten relevant sind, z.Bsp. beim Includieren? Hat jemand Geraete, die mit einer andere Datenrate funken? Ich habe laut nodeInfo nur welche mit 40kBaud. Ich wuesste z.Zt. nicht, wie man mit der CC1101 mehrere Datenraten parallel empfangen koennte.

Hmm, ich habe noch nicht so genau geschaut, aber 9.6kBaud dürfte keins meiner Geräte unterstützen, und die 100kBaud sind glaube ich noch nicht im Feld aufgetaucht, oder? Ich müsste auch mal schauen ob der UZB überhaupt 100kBaud unterstützen würde...

Soweit ich das in der Doku zum CC1101 gesehen habe ist das gleichzeitige Empfangen verschiedener Datenrate eher nicht möglich. Die Frage ist ob man an der Präambel erkennen kann welche Datenrate das ist und den CC schnell genug umprogrammieren kann damit er das Paket sauber empfangen kann. Das geht dann aber schon ganz schön ins "Eingemachte" ,-)

Na ich warte dann erst mal bis mein CUL ankommt, dann muss ich mich auch erst mal damit beschäftigen den Compiler etc. aufzusetzen und das Ding zu flashen. Dann kann ich mal schauen was da so passiert. Ich kann dann auch mal schauen ob man die Checksummenprüfung nicht abschalten kann, sollte mMn eigentlich möglich sein.

Gruß,
 Andreas.

[rudolfkoenig]

Willst Du das als echten Dongle-Ersatz implementieren?

Klar. Damit waere das backup Problem geloest, und man koennte am Stick ordentliche Antennen verwenden.

Dann müssten doch so einige der Controllerbefehle implementiert werden

An welche denkst du denn?

Ich kann dann auch mal schauen ob man die Checksummenprüfung nicht abschalten kann

Eine Herausforderung fuer Experten: in culfw/clib/rf_zwave.c den richtigen if auskommentieren
Uebrigens ein 8-bit XOR Checksum ist wirklich nicht soo sicher, bitkipper an gleicher Stelle in 2 oder 4 Bytes werden durchgelassen.

[krikan]

Da wir z.Zt nur 40kBaud unterstuetzen: weiss jemand, ob die anderen Datenraten relevant sind, z.Bsp. beim Includieren? Hat jemand Geraete, die mit einer andere Datenrate funken? Ich habe laut nodeInfo nur welche mit 40kBaud. Ich wuesste z.Zt. nicht, wie man mit der CC1101 mehrere Datenraten parallel empfangen koennte.

Alle ZWave+ Geräte müssen laut Zertifizierungbedingungen die 100k unterstützen (also auch der UZB1). In einigen Geräte-Anleitung wird die explizit erwähnt (bspw. mein Testsensor Philio PST02-1A). Widersprüchlich sind die Angaben, wann die 100k zum Zuge kommen. Bei Philio steht, nur wenn alle Geräte im Netz 100k haben. Vesternet behauptet nur auf der Route müssen alle 100k haben. Müssen wir  wohl selbst analysieren.
Die 9600 sollten überholt sein. Alle auf dem Markt befindlichen Geräte haben mWn mindestens 40k.
Liefert die nodeInfo überhaupt Ergebnisse zu 100k? Ich habe dazu noch nirgends Infos gefunden.

[A.Harrenberg]

Hi Rudi,

An welche denkst du denn?

Na mindestens mal Inclusion/Exclusion wären ja nötig...
Und was das ganze ACK, Routing und ExplorerFrames angeht ist da sicherlich auch einiges nötig um das als Controller im Netz laufen zu lassen.

Eine Herausforderung fuer Experten: in culfw/clib/rf_zwave.c den richtigen if auskommentieren
Uebrigens ein 8-bit XOR Checksum ist wirklich nicht soo sicher, bitkipper an gleicher Stelle in 2 oder 4 Bytes werden durchgelassen.

Habe da noch nicht in den Code geschaut, d.h. Du filterst nach Checksumme aus, ich dachte der Chip verwirft Pakete mit Checksumme automatisch.
Und ja, die einfache Checksumme ist nicht besonders sicher, darum gibt es ja diese CRC_16 Klasse mit der man die Payload dann ein wenig sicherer "einpacken" kann, allerdings auf Kosten einiger Bytes die dann der payload fehlen...

Gruß,
 Andreas.

[rudolfkoenig]

Und was das ganze ACK, Routing und ExplorerFrames angeht ist da sicherlich auch einiges nötig um das als Controller im Netz laufen zu lassen.

Erstens man muss nicht alles sofort haben, und zweitens man will ja schliesslich was zum Spielen fuer die langen Winterabende haben Dein Security-Code ist uebrigens ab sofort auch praktisch relevant.

[A.Harrenberg]

Hi,

Erstens man muss nicht alles sofort haben, und zweitens man will ja schliesslich was zum Spielen fuer die langen Winterabende haben Dein Security-Code ist uebrigens ab sofort auch praktisch relevant.

klar muss nicht alles sofort da sein, aber ich fürchte das der Winter nicht ganz ausreicht das zu implementieren ,-)
Aber vielleicht ist es auch gar nicht soo komplex wie ich befürchte. Jedenfalls ist jetzt so ein INS Dokument noch interessanter...

Inwieweit der Security-Code auch für die "Controller"-Seite passt müssen wir dann mal sehen, die "low-level" Funktionen sind aber recht generisch gehalten, das sollte also gehen.

Mit so einem NanoCul könnte man auch erst mal eine "Node" implementieren ,-)

Gruß,
 Andreas.

[krikan]

Zu 100k:
Unser "Supporter" AEOTEC macht hier die 100k am Chipsatz fest: http://aeotec.com/z-wave-500-series-module-chip. Und schreibt auch etwas von 3x 100k channels; mEn habe ich das auch irgenswo anders mit näherer Erläuterung gelesen.

[rudolfkoenig]

Das mit 100k/9600 vertagen wir erstmal.

Es geht weiter:
ziHHHHHHHHCC setzt homeid und controllerNodeId (RAM only!)
zi ohne Argument liefert den aktuellen homeId und controllerId zurueck.
zr: gibt empfangene Nachricht nur dann aus, wenn homeId/controllerId/checksum ok ist. Sendet in diesem Fall nach 1ms ein ACK zurueck.
zm: monitor mode: homeId/controllerId/checksum ist egal
zsXX*: Nachricht senden. XX* muss alles enthalten, von homeId bis checksum.

Ich kann meine Lampe wiederholt ein und ausschalten, und auch ACK scheint zu tun: die Lampe sendet seine Nachrichten in zr Modus auch nur einmal, in zm sind es jeweils 3 Telegramme.

Resend gibts noch nicht. Ueberlege ob ich die resends in FHEM (extra Modul?) oder in culfw machen soll. Leider ist culfw inzwischen ziemlich voll, die CoAutoren sind verschwenderisch mit den ueppigen Resourcen der "grossen" Atmel umgegangen.

[A.Harrenberg]

Hi Rudi,

Es geht weiter:

Ich kann meine Lampe wiederholt ein und ausschalten, und auch ACK scheint zu tun: die Lampe sendet seine Nachrichten in zr Modus auch nur einmal, in zm sind es jeweils 3 Telegramme.

wenn Du so weiter machst bist Du noch vor Weihnachten fertig ;-)
Was sagt denn der "eigentliche" Controller des Netzwerks wenn da jemand mit "seiner" ID/HomeID sendet, oder hast Du denn dann ausgesteckt?
Dann hast Du aber auch das ACK schon entschlüsselt, oder?

Resend gibts noch nicht. Ueberlege ob ich die resends in FHEM (extra Modul?) oder in culfw machen soll. Leider ist culfw inzwischen ziemlich voll, die CoAutoren sind verschwenderisch mit den ueppigen Resourcen der "grossen" Atmel umgegangen.

Oh oh, der V3 hat aber noch was frei, oder?

Gruß,
 Andreas.

[rudolfkoenig]

Dann hast Du aber auch das ACK schon entschlüsselt, oder?

Das ist uebertrieben, ich habe nur brav kopiert. Vermutlich funktioniert es noch nicht in allen Faellen.

Oh oh, der V3 hat aber noch was frei, oder?

Eher weniger als beim V4 (mit dem ich rumspiele), da fuer V3 auch MBUS konfiguriert ist. V3 hat "nur" soviel Programmspeicher wie der V4 (32k-4k), aber mehr RAM (2.5k statt 1k).

Bei der V4 sind z.Zt. noch 1792 Bytes frei, bei der V3 -758. Aeh. Oops.

Habe ZWave bei CUL_V3 auskommentiert, da bleiben immerhin noch 124 Bytes frei.
Habe die diversen Optionen gemessen: KOPP_FC:3.3k, MBUS:2.5k, SOMFY: 1.7k, MAX:1.7k, HomeMatic: 1.4k
Habe eine CUL_V3_ZWAVE Variante erstellt ohne KOPP_FC und MBUS.
Und aus CUL_V4 KOPP_FC entfernt. Bin gespannt, ob das auffaellt.