FHEM Forum

FHEM - Hausautomations-Systeme => ZWave => Thema gestartet von: rudolfkoenig am 29 November 2015, 21:15:36

Titel: ZWave @ culfw
Beitrag von: rudolfkoenig am 29 November 2015, 21:15:36
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.

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!
Titel: Antw:ZWave @ culfw
Beitrag von: krikan am 29 November 2015, 21:20:09
 :) Prima! Danke für Deine Arbeit; ging nun ja überraschend schnell. Jetzt brauch ich wohl doch noch einen CUL.
Titel: Antw:ZWave @ culfw
Beitrag von: A.Harrenberg am 29 November 2015, 22:20:58
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.
Titel: Antw:ZWave @ culfw
Beitrag von: A.Harrenberg am 30 November 2015, 07:47:51
Hi Rudi,
Zitat von: rudolfkoenig am 29 November 2015, 21:15:36
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.

Zitat von: rudolfkoenig am 29 November 2015, 21:15:36
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.

Zitat von: rudolfkoenig am 29 November 2015, 21:15:36
Folgendes ist ein Mitschnitt von "set Lampe off; get Lampe version". HomeId habe ich nachtraeglich verfremdet,  Checksum aber nicht angepasst.
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.
Titel: Antw:ZWave @ culfw
Beitrag von: rudolfkoenig am 30 November 2015, 09:37:08
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.
Titel: Antw:ZWave @ culfw
Beitrag von: A.Harrenberg am 30 November 2015, 10:00:12
Hi Rudi
Zitat von: rudolfkoenig am 30 November 2015, 09:37:08
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 ,-)

Zitat von: rudolfkoenig am 30 November 2015, 09:37:08
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.

Titel: Antw:ZWave @ culfw
Beitrag von: rudolfkoenig am 30 November 2015, 10:19:45
ZitatWillst Du das als echten Dongle-Ersatz implementieren?
Klar. Damit waere das backup Problem geloest, und man koennte am Stick ordentliche Antennen verwenden.

ZitatDann müssten doch so einige der Controllerbefehle implementiert werden
An welche denkst du denn?

ZitatIch 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.
Titel: Antw:ZWave @ culfw
Beitrag von: krikan am 30 November 2015, 10:29:45
Zitat von: rudolfkoenig am 30 November 2015, 09:37:08
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.
Titel: Antw:ZWave @ culfw
Beitrag von: A.Harrenberg am 30 November 2015, 10:32:38
Hi Rudi,
Zitat von: rudolfkoenig am 30 November 2015, 10:19:45
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.

Zitat von: rudolfkoenig am 30 November 2015, 10:19:45
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.
Titel: Antw:ZWave @ culfw
Beitrag von: rudolfkoenig am 30 November 2015, 11:14:02
ZitatUnd 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.
Titel: Antw:ZWave @ culfw
Beitrag von: A.Harrenberg am 30 November 2015, 11:39:38
Hi,
Zitat von: rudolfkoenig am 30 November 2015, 11:14:02
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.
Titel: Antw:ZWave @ culfw
Beitrag von: krikan am 30 November 2015, 12:10:58
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.
Titel: Antw:ZWave @ culfw
Beitrag von: rudolfkoenig am 30 November 2015, 19:49:33
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.
Titel: Antw:ZWave @ culfw
Beitrag von: A.Harrenberg am 30 November 2015, 20:08:56
Hi Rudi,
Zitat von: rudolfkoenig am 30 November 2015, 19:49:33
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?

Zitat von: rudolfkoenig am 30 November 2015, 19:49:33
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.
Titel: Antw:ZWave @ culfw
Beitrag von: rudolfkoenig am 30 November 2015, 21:11:50
ZitatDann 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.

ZitatOh 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.
Titel: Antw:ZWave @ culfw
Beitrag von: A.Harrenberg am 30 November 2015, 21:32:57
Hi Rudi,
Zitat von: rudolfkoenig am 30 November 2015, 21:11:50
Das ist uebertrieben, ich habe nur brav kopiert. Vermutlich funktioniert es noch nicht in allen Faellen.
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.
oh, war mir nicht bewusst, ich dachte der V3 hätte auch mehr Programmspeicher, hab' ich wohl zu oberflächlich gelesen.
Kann man nicht eine reine ZWave-only Variante machen? Das geht doch eh' nicht gleichzeitig, oder irre ich mich hier?

Na dann warte ich mal sehnsüchtig auf meinen CUL, dann muss ich mir nur noch das ganze AVR Zeug installieren und dann kann ich mal schauen was mein RFID-Pad dazu treibt die Nachricht so oft zu wiederholen bzw. ob man irgendwie sehen kann ob die Nachricht geroutet wurde.

Gruß,
Andreas.
Titel: Antw:ZWave @ culfw
Beitrag von: A.Harrenberg am 03 Dezember 2015, 22:16:44
Hi Christian,
Zitat von: krikan am 30 November 2015, 10:29:45
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.
also nur UZB1 mit dem AEOTEC Mulitisensor 6 völlig alleine im Netz -> AEOTEC meldet nur 40kBaud.

Zitat von: krikan am 30 November 2015, 10:29:45
Liefert die nodeInfo überhaupt Ergebnisse zu 100k? Ich habe dazu noch nirgends Infos gefunden.
Daran wird es wohl eher liegen, in FHEM ist anscheinend nur eine Abfrage für 40kBaud implementiert, ich habe aber auch in OZW nicht zu 100kBaud gefunden.
Ich werde mir bei Gelegenheit mal die NIF genauer ansehen ob da jetzt irgendwo ein "neues" Bit gesetzt wird ,-)

Gruß,
Andreas.
Titel: Antw:ZWave @ culfw
Beitrag von: krikan am 03 Dezember 2015, 22:25:41
ZitatAEOTEC meldet nur 40kBaud
Wo hast Du das nachgeschaut? In FHEM oder? In ozw und allen anderen Quellen habe ich auch schon erfolglos nach Infos gesucht.
Ich kämpfe gerade noch mit CULflash, um endlich Rohdaten zu sehen. Aber der gewöhnliche WinUser hat damit so seine Probleme  :-[
Titel: Antw:ZWave @ culfw
Beitrag von: A.Harrenberg am 03 Dezember 2015, 22:32:27
Hi,

nur die Rückmeldung in FHEM, habe dann nur kurz in den Code von FHEM und OZW geschaut, die scheinen auf den ersten Blick das gleiche auszuwerten. Daher würde ich davon ausgehen das OZW auch keine 100 kBaud melden kann.

CULflash, d.h. Du hast Deinen Cul schon. Ich bin neidisch... Meiner kommt dann irgendwann morgen über Tag (mit Hermes...) das bedeutet dann das ich da am Samstag weiß der Geier wohin latschen kann um das Ding abzuholen.

Habe mir aber auch gerade das CUL-SVN runtergezogen und wollte auch gerade schauen was ich für den Atmel so alles an Compiler brauche.

Das "andere" Spielzeug soll auch morgen ankommen, gibt also genug zu tun ,-)

Gruß,
Andreas.
Titel: Antw:ZWave @ culfw
Beitrag von: rudolfkoenig am 04 Dezember 2015, 08:31:12
ZitatIch kämpfe gerade noch mit CULflash, um endlich Rohdaten zu sehen. Aber der gewöhnliche WinUser hat damit so seine Probleme.

Ich habe CUL_V3_ZWAVE zu CULflash gerade hinzugefuegt :)

Man muss nicht CULflash verwenden, das war hauptsaechlich fuer die FritzBox interessant, weil komplett eingerichtet. Fuer "normale" Unix-Distributionen muss man vorher dfu-programmer mit root-sbit (oder vergleichbares) installieren, und das ist vermutlich aufwendiger/riskanter(?), als einen der auf culfw.de beschriebenen Methoden direkt auszufuehren.
Vorteile von CULflash: wenn einmal eingerichtet, dann bequemer, und holt den letzten "nightly-build", d.h. man muss nicht in SVN wuehlen, der .hex auf culfw.de ist nicht aktuell.

Fuer den Normaluser zu aufwendig, fuer Experimentierer wie ihr koennte sich lohnen.
Titel: Antw:ZWave @ culfw
Beitrag von: krikan am 04 Dezember 2015, 08:43:15
Zitat von: rudolfkoenig am 04 Dezember 2015, 08:31:12
mit root-sbit (oder vergleichbares) installieren
Das root-sbit könnte es gewesen sein. Nach 1,5 Stunden Linuxexperimenten habe ich jedoch aufgegeben und schließlich in 5 Minuten mit Win geflasht. :-[

Muss ich bei Aufruf von screen bzw. der Angabe der Schnittstelle 40k irgendwie berücksichtigen?

Zitat
der .hex auf culfw.de ist nicht aktuell.
Habe ich gesehen, da auch Changed usw. älter. Pflegst Du die Seite auch noch komplett allein?
Titel: Antw:ZWave @ culfw
Beitrag von: A.Harrenberg am 04 Dezember 2015, 09:44:03
Hi Rudi,
CULflash habe ich mir bisher gar nicht angeschaut, da war bisher überall nur dfu-programmer erwähnt...
Zitat von: rudolfkoenig am 04 Dezember 2015, 08:31:12
Vorteile von CULflash: wenn einmal eingerichtet, dann bequemer, und holt den letzten "nightly-build", d.h. man muss nicht in SVN wuehlen, der .hex auf culfw.de ist nicht aktuell.

Fuer den Normaluser zu aufwendig, fuer Experimentierer wie ihr koennte sich lohnen.
Holt der sich dann IMMER das letzte hex vom nightly-build oder nutzt der das lokale SVN?

Ich kann mir schon vorstellen das ich da vielleicht an der einen oder anderen Stelle mal was zum debuggen oder so an culfw ändere. Ich hätte jetzt einfach mit dem SVN und den vorhandenen makefiles gearbeitet oder spricht da etwas dagegen?

Gruß,
Andreas.
Titel: Antw:ZWave @ culfw
Beitrag von: rudolfkoenig am 04 Dezember 2015, 11:34:00
@Christian: screen kann man einfach aufrufen: screen /dev/ttyACM0, aber du kannst das Geschehen auch mit hyperterm/etc unter Windows beobachten. Baudrate, etc ist egal. Du siehst nicht, was du eintippst, es sei denn du hast im Terminalprogram local echo konfiguriert.
Oder ab naechste Woche mit einem FHEM Modul.
Klar pflege ich culfw.de alleine, genauso wie (noch) fhem.de. Allerdings ist auf fhem.de deutlich mehr automatisiert (upload, CHANGED, MAINTAINER, commandref, etc).

@Andreas: fhemupdate (siehe fhem/contrib/fhemupdate.pl, laedt die Daten fuer update in FHEM von SVN auf fhem.de) kopiert alle .hex Dateien auf fhem.de, und CULflash holt sie direkt von da vor dem flashen. Wenn du vorhast culfw selbst zu modifizieren, dann ist CULflash der falsche Weg.
Titel: Antw:ZWave @ culfw
Beitrag von: A.Harrenberg am 04 Dezember 2015, 11:50:42
Hi Rudi,

ok, also bleibe ich bei dem Ansatz SVN und dfu-programmer. Ob ich dann wirklich culfw modifiziere wird sich dann zeigen...
Danke für die Erklärung der Hintergründe.

Gruß,
Andreas.
Titel: Antw:ZWave @ culfw
Beitrag von: krikan am 04 Dezember 2015, 20:24:22
ZitatzHHHHHHHHSSFFffLLTTPP*CC
Gibt es schon nähere Kenntnis zum Inhalt/Aufbau von FFff (Frame Control) im Funktelegramm?. Im Paetz gibt es zwar eine Tabelle mit einer kurzen Übersicht der Bedeutung der einzelnen Bits der 2 Byte Rahmensteuerung für Singlecast. Leider ist das recht oberflächlich, so dass Analyse anhand der Angaben vermutlich lange dauert.

Das hier ist bspw.  ein "get <device> basicStatus" für einen nicht erreichbaren Sensor (Sirene im Metallkochtopf 8))

zxxxxxxxxx0151050C062002B2
zxxxxxxxxx018101100600201A04200244
zxxxxxxxxx018101100600201A04200244
zxxxxxxxxx018101100600201A04200244
zxxxxxxxxx0151060C062002B1
zxxxxxxxxx01450214062000FA4000000000200223

Mir ist noch nicht klar, was der Unterschied zwischen den verschiedenen Telegrammen /normal, geroutet, Exploerer Frames?) ist und ob sich nichts anderes dazwischen  gemogelt hat.
Titel: Antw:ZWave @ culfw
Beitrag von: A.Harrenberg am 05 Dezember 2015, 00:02:20
Hi Christian,
das sieht schon recht interessant aus, ziemlich viele verschiedene  Messages für ein "2002".
Ich denke wir werden noch einige Versuche brauchen bis wir das alles dekodiert haben. Mein Stick ist auch angekommen, ich kann aber erst ab Sonntag ernsthaft damit spielen.
Ich denke es ist wichtig das wir zu jeder Messung auch die Aktuelle Routing Tabelle haben, um die Nachricht mit einer möglichen Route vergleichen zu können.
Mal sehen ob ich den Stick morgen früh noch geflasht bekomme bevor ich weg muss.
Gruß, Andreas.
Titel: Antw:ZWave @ culfw
Beitrag von: rudolfkoenig am 05 Dezember 2015, 07:59:22
Bei den Flags ist mir aufgefallen, dass die erste Stelle von ff 0 ist, und die Zweite bei jede neue Nachricht eins hochgezaehlt wird, geht also von 0 bis f. Bei Resend bleibt ff gleich. Ein ACK mit FF:03 und gleiches ff wird von meiner AN158 akzeptiert. Theorie: Bit 1 (ich meine damit die Zweite von "hinten") ist gesetzt bei einem ACK. Bit 0 scheint immer gesetzt zu sein.

Nach Studium des Metallkochtopf-Logs:
    HHHHHHHHH SS FF ff LL TT                  PP*  CS
  z xxxxxxxxx 01 51 05 0C 06                  2002 B2             
  z xxxxxxxxx 01 81 01 10 06 00201A04         2002 44     
  z xxxxxxxxx 01 81 01 10 06 00201A04         2002 44     
  z xxxxxxxxx 01 81 01 10 06 00201A04         2002 44     
  z xxxxxxxxx 01 51 06 0C 06                  2002 B1             
  z xxxxxxxxx 01 45 02 14 06 2000FA4000000000 2002 23

- das Hochzaehlen von ff gilt nur fuer Nachrichten mit gleicher FF bzw. gleicher "Art"
- sind 20, 1A oder 04 "neighbors"? Wenn nicht: woher weiss ein Router, dass er der Router fuer diese Nachricht ist?

Auf meiner Liste steht aber erst ein Perl Modul, damit wir msec Logs und etwas Dekodierung haben. Rumraten koennt ihr genausogut oder besser als ich :)
Titel: Antw:ZWave @ culfw
Beitrag von: krikan am 05 Dezember 2015, 08:53:27
Die Infos haben wir:

Byte 1:
Bit 0..3 = Kopftyp
Bit 4     = Datenrate (9600 versus 40k)
Bit 5     = Low-Power Indikator
Bit 6     = Bestätigung oder Kommando
Bit 7     = geroutet

Byte 2:
Bit 0..3 = Sequenznummer
Bit 4..   = Wakeup-Beam-Steuerung

ZitatTheorie: Bit 1 (ich meine damit die Zweite von "hinten")
Passt.

Zitatsind 20, 1A oder 04 "neighbors"?
01, 04, 12, 1F (RAW:01800900024000000000000000000000000000000000000000000000000000). 12 und 1F sind WakeUp-Geräte. Keine Ahnung, was das bedeutet!? Probiere noch mal systematisch.

ZitatAuf meiner Liste steht aber erst ein Perl Modul
Aber gerne  :) screen wird nicht mein Freund...
Titel: Antw:ZWave @ culfw
Beitrag von: A.Harrenberg am 05 Dezember 2015, 09:39:35
Hi,

so, mein Stick ist geflasht, ABER...
Meine Testgeräte scheinen alle auf 100kBaud zu laufen...

Außer Nachricht beim Auslösen der Inklusion sehe ich da gar nichts. Aus dem "Produktiv"-Netz bestehend aus dem RFID-Pad und einem Steckdosenschalter sehe ich die Nachrichten, d.h. der Stick ist in Ordnung...

So wird das nicht viel mit "sniffen" ;-(

@Rudi: Kannst Du mir auf die Schnelle verraten wo die Einstellungen für den CC1101 bzgl. Frequenz gemacht werden? Ich bin mir aber absolut nicht sicher ob dann icht evtl. die Modulation unterschiedlich ist... ,-(

Gruß,
Andreas.
Titel: [Makefile] Antw:ZWave @ culfw
Beitrag von: A.Harrenberg am 05 Dezember 2015, 09:44:42
Hi Rudi,

ich habe mal die Option "usbprogram_v3_zwave" (und usbprogram_v2_max) im Makefile ergänzt...
Ich dachte ich werde später gefragt welches V3 ich haben will, war aber nicht und dann hatte ich erst einmal einen "normalen" Stick ohne Zwave.

Gruß,
Andreas.
Titel: Antw:ZWave @ culfw
Beitrag von: A.Harrenberg am 05 Dezember 2015, 10:22:36
Hi Rudi,
Zitat von: A.Harrenberg am 05 Dezember 2015, 09:39:35
@Rudi: Kannst Du mir auf die Schnelle verraten wo die Einstellungen für den CC1101 bzgl. Frequenz gemacht werden? Ich bin mir aber absolut nicht sicher ob dann icht evtl. die Modulation unterschiedlich ist... ,-(
denke ich habe die relevante Stelle in rf_zwave.c gefunden, allerdings ist das nicht sooo einfach. Nur das ändern der Datenrate bringt da erst mal nix, werde mal ein wenig mit der Modulation "spielen", aber das sind 'ne Menge Möglichkeiten die man da kombinieren kann.

Gruß,
Andreas.
Titel: Antw:ZWave @ culfw
Beitrag von: krikan am 05 Dezember 2015, 10:27:13
Zitat von: A.Harrenberg am 05 Dezember 2015, 09:39:35
Meine Testgeräte scheinen alle auf 100kBaud zu laufen...
Was sind das für Geräte im Testnetz? Alle Zwave+ bzw. 5er-Chipsatz?
Titel: Antw:ZWave @ culfw
Beitrag von: A.Harrenberg am 05 Dezember 2015, 11:40:39
Hi Christian,
Zitat von: krikan am 05 Dezember 2015, 10:27:13
Was sind das für Geräte im Testnetz? Alle Zwave+ bzw. 5er-Chipsatz?

USB1
Aeotec Multisensor 6
Aeotec DSD31 Siren Gen5
Greenwave NS310-F (Steckdosenschalter)

Der Greenwave meldet sich schon mal nicht als Zwave+, was mich jetzt natürlich bezüglich der 100kBaud etwas stutzig macht. 5er-Chipsatz bedeutet doch auch Zwave+ und 100kBaud ist meinem Wissen nach nur mit 5er-Chipsatz möglich, oder?

Nicht das ich hier doch einen anderen Effekt habe und unnötigerweise seit 3 Stunden den Stick mit allen möglichen und unmöglichen Settings flashe...

Vielleicht sollte ich doch noch mal auf die normalen Parameter zurückgehen und das am Windowsrechner probieren...

Gruß,
Andreas.
Titel: Antw:ZWave @ culfw
Beitrag von: krikan am 05 Dezember 2015, 11:50:28
Zitat von: A.Harrenberg am 05 Dezember 2015, 11:40:39
Der Greenwave meldet sich schon mal nicht als Zwave+, was mich jetzt natürlich bezüglich der 100kBaud etwas stutzig macht. 5er-Chipsatz bedeutet doch auch Zwave+ und 100kBaud ist meinem Wissen nach nur mit 5er-Chipsatz möglich, oder?
Vermutlich gibt es 100k seit dem 4er Chipsatz. Ergibt sich indirekt aus dem 4er zwapi, wo 100k bereits erwähnt werden. Und würde dann wieder passen. Den Unterschied 4er und 5er muss ich noch mal raussuchen.
Nur Zwave+ gibt es mMn erst ab 5er Chipsatz.
Jetzt kommt meine Frage: wie finden wir den Chipsatz des Greenwave heraus? Kenne die Funktion nur für Controller.
Titel: Antw:ZWave @ culfw
Beitrag von: krikan am 05 Dezember 2015, 12:03:35
Zitat von: krikan am 05 Dezember 2015, 11:50:28
Vermutlich gibt es 100k seit dem 4er Chipsatz. Ergibt sich indirekt aus dem 4er INS, wo 100k bereits erwähnt werden. Und würde dann wieder passen. Den Unterschied 4er und 5er muss ich noch mal raussuchen.
100k ab 4er: http://tane.nl/shop/doc/SigmaApril11.pdf und Philio hat das auch in den Gerätebeschreibungen der 4er Sensoren drin.

ZitatJetzt kommt meine Frage: wie finden wir den Chipsatz des Greenwave heraus? Kenne die Funktion nur für Controller.
Evtl. über den Umweg SDK. Welches SDK meldet der Greenwave?
Titel: Antw:ZWave @ culfw
Beitrag von: A.Harrenberg am 05 Dezember 2015, 12:24:09
Hi Christian,

ich wollte jetzt gerade schon aufschrauben ;-) aber das sind blöde Spezialschrauben in tiefen Schächten. Ich habe zwar solche Einsätze als Bits, die sind dafür daber zu kurz...

Das Ding meldet sich bei get version mit Lib 3 Prot 3.41 App 4.27.

Die 3.41 hast Du im Wiki mit SDK 6.02.00 übersetzt, ich finde jedoch keine Quelle mit dieser Aussage.

Gruß,
Andreas.
Titel: Antw:ZWave @ culfw
Beitrag von: krikan am 05 Dezember 2015, 12:38:36
Zitat von: A.Harrenberg am 05 Dezember 2015, 12:24:09
Das Ding meldet sich bei get version mit Lib 3 Prot 3.41 App 4.27.
Ja, SDK 6.02.00 -> 400er Chip -> 100k -> also alle Geräte im Netz 100k -> wirst nichts sniffen können, es sei denn Du/Rudi progammiert etwas. Oder Du hast noch ein Gerät mit älterem SDK als SDK 6, das Du einbinden kannst.
Suche die sdkids.xml von zway, daraus ergibt sich das SDK.
Titel: Antw:ZWave @ culfw
Beitrag von: A.Harrenberg am 05 Dezember 2015, 12:44:03
Hi Christian,

tja, dachte nicht das neue Geräte auch mal schlecht sein könnten...

Zitat von: krikan am 05 Dezember 2015, 12:38:36
Ja, SDK 6.02.00 -> 400er Chip -> 100k -> also alle Geräte im Netz 100k -> wirst nichts sniffen können, es sei denn Du/Rudi progammiert etwas. Oder Du hast noch ein Gerät mit älterem SDK als SDK 6, dass Du einbinden kannst
Suche die sdkids.xml von zway, daraus ergibt sich das SDK.

Ich habe eine SDKid.xml gefunden aber anscheinend ist die nicht auf dem neuesten Stand, muss noch mal genauer suchen, ist aber jetzt auch nicht mehr so wichtig.

Das Problem an der Sache ist das da außer der Datenrate anscheinend auch so einige andere Sachen umgestellt werden müssen. Ich habe da jetzt schon mal die für mich sinnvollsten Parameter probiert, ich kriege aber auch nichts, bzw. nur ab und zu Datenmüll.

Ich schau mal was die andere Steckdose für ein SDK hat, dann kann ich die ja vielleicht tauschen...

Gruß,
Andreas.
Titel: Antw:ZWave @ culfw
Beitrag von: krikan am 05 Dezember 2015, 12:59:08
Zitat von: A.Harrenberg am 05 Dezember 2015, 12:44:03
tja, dachte nicht das neue Geräte auch mal schlecht sein könnten...
Gleiches Problem hier  ;). Hätte gerne etwas mit SDK 5, damit ich mal prüfen kann, ob das Explorer Frames im betreffenden Netz komplett verhindert. Das befürchte ich http://wiki.zwaveeurope.com/index.php?title=SDK_Versions_and_Explorer_Frames ; würde aber einiges erklären:
ZitatIf the network consists of devices of SDK 5 but contains some devices of SDK 4.5x it will still run on the principles of the SDK. If the network only consists of devices with SDK 4.5x this network will self organize on the principles of this SDK and use its enhanced function.

Hatte ich es schon erwähnt: Rudi, ZWave@CUL ist klasse. Danke.
Wir treiben Deinen Thread schnell ins Off; überlege, ob ich etwas ins Wiki packe, aber das ist doch sehr im Fluss udn übergreifend...
Titel: Antw:ZWave @ culfw
Beitrag von: rudolfkoenig am 05 Dezember 2015, 13:26:13
ZitatHatte ich es schon erwähnt: Rudi, ZWave@CUL ist klasse. Danke.
Ich kann gerade den Gemuetszustand von Andreas gut vorstellen :)

Apropos 100kBaud: ich habe bei meinem letzten Session beide meiner homeIds gesehen, dabei hat das Testsystem nur neue Geraete: zme/uzb, kfob2 und Aeotec SmartSwitch 6. Ich wollte das jetzt verifizieren, und sehe nur noch das alte Goodway (soweit ich sehe, da alles), aber keine Kommunikation im Testsystem.
Titel: Antw:ZWave @ culfw
Beitrag von: rudolfkoenig am 05 Dezember 2015, 13:50:20
Mit einem richtig berechneten Befehl (lasst euch oben inspirieren, in culfw/tools gibts ein zwave_cs.pl) konnte ich den AS6 schalten , und die ACK erschien im culfw. Seitdem ist die zme-as6 Kommunikation in culfw sichtbar.
Die KFOB-Telegramme kann ich immer noch nicht sehen.
Titel: Antw:ZWave @ culfw
Beitrag von: A.Harrenberg am 05 Dezember 2015, 14:36:05
Hi Rudi,
Zitat von: rudolfkoenig am 05 Dezember 2015, 13:26:13
Ich kann gerade den Gemuetszustand von Andreas gut vorstellen :)
wieso? Was vermutest Du? Ich bin noch voller Hoffnung und Tatendrang ,-)
Ich seh' das mit den 100kBaud mal als Herausforderung...

Zitat von: rudolfkoenig am 05 Dezember 2015, 13:26:13
Apropos 100kBaud: ich habe bei meinem letzten Session beide meiner homeIds gesehen, dabei hat das Testsystem nur neue Geraete: zme/uzb, kfob2 und Aeotec SmartSwitch 6. Ich wollte das jetzt verifizieren, und sehe nur noch das alte Goodway (soweit ich sehe, da alles), aber keine Kommunikation im Testsystem.
Wäre dann also so wie bei mir, das Produktivsystem läuft anscheinend auf 40Kbaud, da sehe ich auch alles (sind nur zwei Geräte...).

Zitat von: rudolfkoenig am 05 Dezember 2015, 13:50:20
Mit einem richtig berechneten Befehl (lasst euch oben inspirieren, in culfw/tools gibts ein zwave_cs.pl) konnte ich den AS6 schalten , und die ACK erschien im culfw. Seitdem ist die zme-as6 Kommunikation in culfw sichtbar.
Die KFOB-Telegramme kann ich immer noch nicht sehen.
Äh, willst Du sagen nachdem Du da einmal was hingeschickt hast siehst Du das Gerät? Das wäre aber irgendwie "schräg"... Hast Du das mit der Controller-ID gemacht?
Ah, jetzt verstehe ich die Logik dahinter, das Gerät erhält einmal einen Befehl mit 40kBaud und taktet sich dann wahrscheinlich (dauerhaft?) runter.
Hmm, dann muss ich mein Netzwerk wohl auch mal mit solchen Fake-Nachrichten ausbremsen, wobei die Parameter für die 100kBaud auch schon ganz interessant wären. Momentan gehen mir da aber etwas die Ideen aus was ich noch an den Einstellungen ändern könnte.

Na, morgen geht es weiter ;-)

Gruß,
Andreas.

Titel: Antw:ZWave @ culfw
Beitrag von: krikan am 05 Dezember 2015, 14:52:59
Zitat von: A.Harrenberg am 05 Dezember 2015, 14:36:05
Hi Rudi,wieso? Was vermutest Du? Ich bin noch voller Hoffnung und Tatendrang ,-)
Rudi hat vermutlich mein Geschimpfe wegen screen/Linuxproblemen gehört und das verwechselt ;-)
Mach ruhig an den 100k weiter und vergiss bitte das Türschloss nicht.  :)

Mein Produktivsystem läuft anscheinend auch auf 40k. Ist eine Mischbestückung 40k/100k Devices. Selbst bei direkter Erreichbarkeit des Gerätes mit 100k von ZWDongle läuft es mit 40k; sehe zumindest etwas. Verstehe das nicht.
Titel: Antw:ZWave @ culfw
Beitrag von: A.Harrenberg am 05 Dezember 2015, 15:00:46
Hi,

habe gerade mal die Greenwave Steckdose mit einer Fake-Nachricht unter 40kBaud eingeschaltet, jetzt ist die tatsächlich weiterhin sichtbar. Die anderen 100kBaud Geräte sind aber anscheinend auf 100kBaud geblieben.

Das Schloss ist angekommen, allerdings ist das ein Set ohne Zylinder, das wird für Realtests nicht gehen da der keine Anschläge lernen kann. Da werde ich mich wohl auch noch mal um einen Zylinder bemühen (Ein Schlosseinsatz brauche ich ja auch noch...)

Was die 100 kBaud angeht muss ich da noch mal in Ruhe ran gehen, da gibt es leider recht viele Freiheitsgrade ,-)
Und ich muss mal sehen ob man die Parameter nicht vielleicht doch im Betrieb verändern kann, jedesmal neu flashen ist schon recht nervig. Durch Rudi's Trick ist die "Dringlichkeit" für 100kBaud jetzt erst mal etwas gesunken. ,-)

Gruß,
Andreas.
Titel: Antw:ZWave @ culfw
Beitrag von: krikan am 05 Dezember 2015, 15:12:48
Zitat von: A.Harrenberg am 05 Dezember 2015, 15:00:46
Durch Rudi's Trick ist die "Dringlichkeit" für 100kBaud jetzt erst mal etwas gesunken. ,-)
Auch wieder richtig. Wir haben noch genug Baustellen. (Schiebe die Controllerbefehle bzw. Doku permanent vor mir her.)

Aus Deinen Ergebnissen muss man dann doch schließen, das 100k und 40k gleichzeitig laufen!? Hätte ich derzeit bei mir nicht so gesehen.
Titel: Antw:ZWave @ culfw
Beitrag von: krikan am 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?
Titel: Antw:ZWave @ culfw
Beitrag von: A.Harrenberg am 06 Dezember 2015, 11:50:20
Hi,

so, ich kann jetzt 100kBaud empfangen!  ;D

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 (http://www.rfwireless-world.com/Tutorials/z-wave-tutorial.html).

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.
Titel: Antw:ZWave @ culfw
Beitrag von: A.Harrenberg am 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.
Titel: Antw:ZWave @ culfw
Beitrag von: A.Harrenberg am 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.
Titel: Antw:ZWave @ culfw
Beitrag 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?
Titel: Antw:ZWave @ culfw
Beitrag von: A.Harrenberg am 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.
Titel: Antw:ZWave @ culfw
Beitrag von: krikan am 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.
Titel: Antw:ZWave @ culfw
Beitrag von: A.Harrenberg am 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.
Titel: Antw:ZWave @ culfw
Beitrag von: rudolfkoenig am 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.
Titel: Antw:ZWave @ culfw
Beitrag von: A.Harrenberg am 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.



Titel: Antw:ZWave @ culfw
Beitrag von: A.Harrenberg am 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.
Titel: Antw:ZWave @ culfw
Beitrag von: rudolfkoenig am 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):
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.
Titel: Antw:ZWave @ culfw
Beitrag von: A.Harrenberg am 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.

Titel: Antw:ZWave @ culfw
Beitrag von: rudolfkoenig am 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.
Titel: Antw:ZWave @ culfw
Beitrag von: A.Harrenberg am 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 (http://forum.fhem.de/index.php/topic,44778.msg370523.html#msg370523)) würde ich eher sagen Bug in FHEM oder Problem mit USB in virtueller Maschine...

Gruß,
Andreas.

Titel: Antw:ZWave @ culfw
Beitrag von: krikan am 07 Dezember 2015, 11:01:47
Zitat von: rudolfkoenig am 06 Dezember 2015, 21:04:04
Ab sofort gibt es ein 00_ZWCUL.pm.
Danke.
Mein Verständnisproblem:
Eigentlich würde ich gerne in meinem Produktivsystem zu jeder Nachricht im Log auch das Gesniffte sehen; d.h. USB-Dongle und CUL gleichzeitig anschließen. Wenn ich das richtig verstehe, ist das wegen der "empfohlenen" Config aber schwierig; und ich sollte besser das Testsystem zum mitsniffen des Produktivsystems nutzen. Richtig?
Vorgestern war es so, dass ich genau das (unformatiert) ohne 00_ZWCUL.pm hatte. Das machte die Analyse recht einfach. (Am Rande: Gestern habe ich es nicht mehr hinbekommen, da schoss der Jeelink immer quer)
Titel: Antw:ZWave @ culfw
Beitrag von: A.Harrenberg am 07 Dezember 2015, 11:24:29
Hi,
Zitat von: krikan am 07 Dezember 2015, 11:01:47
Mein Verständnisproblem:
Eigentlich würde ich gerne in meinem Produktivsystem zu jeder Nachricht im Log auch das Gesniffte sehen; d.h. USB-Dongle und CUL gleichzeitig anschließen. Wenn ich das richtig verstehe, ist das wegen der "empfohlenen" Config aber schwierig; und ich sollte besser das Testsystem zum mitsniffen des Produktivsystems nutzen. Richtig?
hmm, jetzt habe ich ein Verständnisproblem, ich sehe nicht wieso die "empfohlene" Config das gleichzeitige Betreiben von Dongle und CUL behindern sollte.

Zitat von: krikan am 07 Dezember 2015, 11:01:47
Vorgestern war es so, dass ich genau das (unformatiert) ohne 00_ZWCUL.pm hatte. Das machte die Analyse recht einfach. (Am Rande: Gestern habe ich es nicht mehr hinbekommen, da schoss der Jeelink immer quer)
Nächste Frage, wie hast Du das denn vorgestern gemacht? Ich habe da momentan nur den Output von Screen, da fehlt natürlich jeglicher Zeitstempel...

Gruß,
Andreas.
Titel: Antw:ZWave @ culfw
Beitrag von: krikan am 07 Dezember 2015, 11:37:08
Zitat von: A.Harrenberg am 07 Dezember 2015, 11:24:29
Hi,hmm, jetzt habe ich ein Verständnisproblem, ich sehe nicht wieso die "empfohlene" Config das gleichzeitige Betreiben von Dongle und CUL behindern sollte.
Ganz einfach: Dann habe ich es mißverstanden. Ich dachte, dass das im Produktivsystem einiges durcheinander würfelt (geändertes statefile,..) und DAS kann ich mir nicht erlauben.

ZitatNächste Frage, wie hast Du das denn vorgestern gemacht? Ich habe da momentan nur den Output von Screen, da fehlt natürlich jeglicher Zeitstempel...
Nächste (dumme) Antwort: keine Ahnung. Ich hatte den CUL definiert und irgendwann tauchten die Outputs im verbose 5 log auf; immer schön direkt bei den Nachrichten des normalen ZWDongle. Also ideal. Gestern habe ich es auf die Schnelle nicht geschafft. (Hintergrund: mangelnde Linux-/FHEM-kenntnisse 8))
Titel: Antw:ZWave @ culfw
Beitrag von: rudolfkoenig am 07 Dezember 2015, 11:48:22
Lass das Produktivsystem unberuehrt, und starte daneben eine zweite Instanz mit ZWCUL.
Danach muss man womoeglich zwei Dateien analysieren, ist aber keine Katastrophe, wenn das ZWCUL System abstuertzt. Ist aber z.Zt. wg. wakeupNoMoreInformation noch ein Problem, also bitte warten. Ich werde auch noch ein Attribut fuer "Geraet nicht anlegen" einbauen.
Titel: Antw:ZWave @ culfw
Beitrag von: A.Harrenberg am 07 Dezember 2015, 11:58:43
Hi,

oh, das mit dem Statefile hatte ich gar nicht gesehen, dachte das wäre die Def für ein Logfile gewesen...

Hmm, schade, ich hätte ja schon gerne EIN File für die Analyse, aber zusätzliche Probleme im "Produktivnetz" kann ich mir nicht erlauben.
Vielleicht kann man ein kleines Programm schreiben was die beiden Files "ineinander" sortiert :-)

Dumme Frage: Kann man so ohne weiteres zwei FHEM Instanzen nebeneinander auf einem Rechner laufen lassen? Da müsste doch neben dem Telnet-Port auch die Web-Ports alle unterschiedlich definiert werden, oder?

Gruß,
Andreas.
Titel: Antw:ZWave @ culfw
Beitrag von: rudolfkoenig am 07 Dezember 2015, 12:14:00
ZitatVielleicht kann man ein kleines Programm schreiben was die beiden Files "ineinander" sortiert :-)
sort file1 file2 > file3

Titel: Antw:ZWave @ culfw
Beitrag von: A.Harrenberg am 07 Dezember 2015, 12:53:39
Hi Rudi,
Zitat von: rudolfkoenig am 07 Dezember 2015, 12:14:00
sort file1 file2 > file3
oha, so einfach... :-)
Danke, wieder was nützliches gelernt!

Gruß,
Andreas.
Titel: Antw:ZWave @ culfw
Beitrag von: rudolfkoenig am 07 Dezember 2015, 18:56:02
Fuer die, fuer die mehrere FHEMs auf einem Rechner suspekt sind, gibts jetzt ein noDispatch Attribut. Weiterhin wird im Monitor-Mode (siehe get zwcul homeId) wakeupNoMoreInformation nicht mehr gesendet.
Titel: Antw:ZWave @ culfw
Beitrag von: A.Harrenberg am 08 Dezember 2015, 22:31:24
Hi Rudi,
Zitat von: rudolfkoenig am 07 Dezember 2015, 18:56:02
Fuer die, fuer die mehrere FHEMs auf einem Rechner suspekt sind, gibts jetzt ein noDispatch Attribut. Weiterhin wird im Monitor-Mode (siehe get zwcul homeId) wakeupNoMoreInformation nicht mehr gesendet.
was macht denn das Attribut?

Gruß,
Andreas.
Titel: Antw:ZWave @ culfw
Beitrag von: A.Harrenberg am 08 Dezember 2015, 22:46:45
Hi,

hier mal ein merkwürdiges Log aus meinem 100 kBaud System (allerdings auf 40 kBaud gesnifft!)

Ich habe dort mal den Steckdosenschalter (id=AE) rausgezogen und dann versucht in auszuschalten. Anscheinend geht der Controller wenn er das Gerät nicht erreicht auch auf 40 kBaud runter, daher tauchen die Nachrichten dann am CUL auf:


2015.12.08 22:26:17.685 5: CUL/RAW: /zE015DFED0151030DAE250100EC
2015.12.08 22:26:17.824 5: CUL/RAW: /zE015DFED0151040DAE250100EB
2015.12.08 22:26:18.240 5: CUL/RAW: /zE015DFED01810710AE1010AD25010088
2015.12.08 22:26:18.253 5: CUL/RAW: /zE015DFED01810710AE1011AD25010089
2015.12.08 22:26:18.280 5: CUL/RAW: /zE015DFED01810710AE1011AD25010089
2015.12.08 22:26:18.342 5: CUL/RAW: /zE015DFED01810710AE1011AD25010089
2015.12.08 22:26:18.372 5: CUL/RAW: /zE015DFEDAEC1070D01151FADFB
2015.12.08 22:26:18.382 5: CUL/RAW: /zE015DFED0103070AAD9A
2015.12.08 22:26:19.058 5: CUL/RAW: /zE015DFED0151050DAE250100EA
2015.12.08 22:26:19.086 5: CUL/RAW: /zE015DFED01450815AE2000FA400000000025010071
2015.12.08 22:26:19.635 5: CUL/RAW: /zE015DFED01450815AE2000FA31AD000000250100AD

Das sind jetzt (fast) alles Nachrichten mit dem Befehl "250100"
Die ersten beiden ungeroutet, dann kommen anscheinend 4 Stück die wohl über Gerät "ae" geroutet werden sollen. Hier gibt es erst ein "1010AD", dann "1011AD"...

Das nächste Paket ist dann aber SEHR interessant, da nach unserer bisheriger Dekodierung die Nachricht "E015DFEDAEC1070D01151FADFB" VON dem (immer noch) ausgesteckten Steckdosenschalter kommen würde... Der Controller antwortet sogar brav mit "ack"

Dann kommen zwei längere Nachrichten mit einer Headertype "45"...
In dem Testnetz sind ExplorerFrames noch aktiv, da dies laut Pätz als "letzte" Massnahme eingesetzt werden soll könnte man jetzt vermuten das Headertype 45 mit zusätzlichen Daten da drin ExplorerFrames sind.

Meine bisherigen Dekodierungen machen ich mit dem angehängten perl script, das erwartet alles inklusive dem z davor (stammt noch von dem screen ...)
Mangels Informationen ist das bisher noch nicht wirklich viel und auch nicht wirklich elegant gelöst.

Gruß,
Andreas.
Titel: Antw:ZWave @ culfw
Beitrag von: rudolfkoenig am 09 Dezember 2015, 09:02:57
Zitatwas macht denn das Attribut?
Steht im commandref ("prohibit dispatching messages or creating ZWave devices"), d.h. es macht dein zwave_decode.pl ueberfluessig, weil damit ein ZWCUL auch in einem produktiven FHEM mitlaufen kann.

@Christian: hast du mehr Details zu deinem Antwort #27?
- ich finde komisch, Baudrate als Info in den Daten per Funk zu schicken: wer das Bit dekodieren konnte, den interessiert es nicht mehr.
- was bedeutet "Kopftyp"? Ich habe bisher 0 (bei ACK), und sonst 4 oder 5 gesehen.
- geroutet scheint bei mir immer gesetzt zu sein. Ist das EF?
- Wo kommt ein Wake-Up Beam zum Einsatz? Beim FLiR? Wie schaut so'n Beam aus?
Titel: Antw:ZWave @ culfw
Beitrag von: krikan am 09 Dezember 2015, 09:55:29
Zitat von: rudolfkoenig am 09 Dezember 2015, 09:02:57
@Christian: hast du mehr Details zu deinem Antwort #27?
Das habe ich aus Paetz; mehr Infos stehen dort auch nicht und auch per kurzer Internetrecherche kann ich nichts finden.

Alles andere kann ich nur mutmaßen, habe bisher nicht viel getestet.
Zitat- ich finde komisch, Baudrate als Info in den Daten per Funk zu schicken: wer das Bit dekodieren konnte, den interessiert es nicht mehr.
Ja, steht aber definitiv so in der Quelle.
Zitatgeroutet scheint bei mir immer gesetzt zu sein. Ist das EF?
Kann ich mir nicht vorstellen. EF ist, wie Andreas schrieb, nur die letzte Möglichkeit. Tippe eher auf 45 für EF (siehe Kochtopftest und Andreas Log)
Geroutet wird doch fast alles; das könnten wir näher testen, indem wir alle Transmit-Options beim Senden probieren und mitloggen.
ZitatWo kommt ein Wake-Up Beam zum Einsatz? Beim FLiR? Wie schaut so'n Beam aus?
Bei FLIRS, korrekt. Ist aus ZWave/ZWDongle-Sicht bisher anscheinend transparent gewesen, da es auf Protokollebene abläuft. Habe aber kein FLIRS-Gerät, um Aufbau zu loggen.

Andreas oben angehängte .pl ist für mich ganz praktisch, da ich so direkt den Aufbau der Bits in den screen-Telegrammen erkenne. Aus den FHEM-Logs (hex-Werte) ist das für mich schwieriger; kann man das nicht vorübergehend auch irgendwie in FHEM einbauen? Ich denke, wir müssen schrittweise Einzelanalysen machen. Aufbauen würde ich dabei auf dem bekannten Aufbau von FFff, da mir nichts besseres einfällt bzw. per Internet-Recherche untergekommen ist.



Titel: Antw:ZWave @ culfw
Beitrag von: A.Harrenberg am 09 Dezember 2015, 10:34:55
Hi Rudi,
Zitat von: rudolfkoenig am 09 Dezember 2015, 09:02:57
Steht im commandref ("prohibit dispatching messages or creating ZWave devices"), d.h. es macht dein zwave_decode.pl ueberfluessig, weil damit ein ZWCUL auch in einem produktiven FHEM mitlaufen kann.
sorry, manchmal habe ich Tomaten auf den Augen und den Rest vom Gemüse im Kopf... Ich hatte nicht begriffen was das "dispatch" sein soll, aber das ist das dispatch mit dem die Befehle dann geparst werden... Jetzt macht das auch Sinn... Ich dachte es hätte irgendetwas damit zu damit sich zwei Instanzen von FHEM nicht in die Quere kommen.

Zitat von: rudolfkoenig am 09 Dezember 2015, 09:02:57
@Christian: hast du mehr Details zu deinem Antwort #27?
- ich finde komisch, Baudrate als Info in den Daten per Funk zu schicken: wer das Bit dekodieren konnte, den interessiert es nicht mehr.
- was bedeutet "Kopftyp"? Ich habe bisher 0 (bei ACK), und sonst 4 oder 5 gesehen.
- geroutet scheint bei mir immer gesetzt zu sein. Ist das EF?
- Wo kommt ein Wake-Up Beam zum Einsatz? Beim FLiR? Wie schaut so'n Beam aus?
Baudrate: Meine Info (aus dem ITU-Dokument) ist das hier keine Baudrate sondern eine "reduzierte Geschwindigkeit" gemeldet wird. Das Flag soll gesetzt sein sobald die Geschwindigkeit kleiner ist als eigentlich von den Geräten unterstützt. Ich denke das dies bei Empfangsproblemen genutzt wird um "runterzuschalten", dem Gerät aber auch anzuzeigen das eigentlich mehr geht und das Gerät es dann vielleicht auch in der höheren Geschwindigkeit versucht.
Kopftyp: Hier habe ich nur die Info:
1 = Single Cast
2 = Multi Cast
3 = Acknoweldge Meldung
Ich muss noch mal schauen, aber ich denke das 4-6 nicht genutzt werden sollen (passiert aber...)
Routing: Bit 7 gesetzt, mehr Info habe ich da auch noch nicht.

Ich kann euch heute abend mal das ITU Dokument schicken wenn Ihr das nicht bereits selbst gefunden habt. Zwave soll ja darauf aufbauen, wobei z.B. Kopftypen auftauchen die in dem Dokument als "do not use" gekennzeichnet sind.

Gruß,
Andreas.
Titel: Antw:ZWave @ culfw
Beitrag von: rudolfkoenig am 09 Dezember 2015, 13:34:24
ZitatAndreas oben angehängte .pl ist für mich ganz praktisch, da ich so direkt den Aufbau der Bits in den screen-Telegrammen erkenne.

Ok, ich habe sowas aenliches in ZWCUL eingebaut. Benoetigt wird ein verbose 5 fuer ZWCUL (global verbose 5 reicht nicht). Ich habe eine Zwischensteckdose ausgesteckt, und ein "set off" abgesetzt. Danach war ich etwas beeindruckt:
2015.12.09 13:23:53.802 5: xxxxxxxx S:01 F:41 f:06 L:0d T:19 P:250100 C:13
2015.12.09 13:23:53.802 5:    F:01000001 singleCast ackReq
2015.12.09 13:23:53.802 5:    f:00000110 seqNum:6
2015.12.09 13:23:53.889 5: xxxxxxxx S:01 F:41 f:06 L:0d T:19 P:250100 C:13
2015.12.09 13:23:53.889 5:    F:01000001 singleCast ackReq
2015.12.09 13:23:53.889 5:    f:00000110 seqNum:6
2015.12.09 13:23:53.975 5: xxxxxxxx S:01 F:41 f:06 L:0d T:19 P:250100 C:13
2015.12.09 13:23:53.975 5:    F:01000001 singleCast ackReq
2015.12.09 13:23:53.975 5:    f:00000110 seqNum:6
2015.12.09 13:23:54.022 5: xxxxxxxx S:01 F:81 f:0a L:10 T:19 R:00100c P:250100 C:de
2015.12.09 13:23:54.022 5:    F:10000001 singleCast routed, rf:00 hopCount:1, hops:0c
2015.12.09 13:23:54.022 5:    f:00001010 seqNum:10
2015.12.09 13:23:54.029 5: xxxxxxxx S:01 F:81 f:0a L:10 T:19 R:00110c P:250100 C:df
2015.12.09 13:23:54.029 5:    F:10000001 singleCast routed, rf:00 hopCount:1, hops:0c
2015.12.09 13:23:54.029 5:    f:00001010 seqNum:10
2015.12.09 13:23:54.078 5: xxxxxxxx S:01 F:81 f:0a L:10 T:19 R:00110c P:250100 C:df
2015.12.09 13:23:54.078 5:    F:10000001 singleCast routed, rf:00 hopCount:1, hops:0c
2015.12.09 13:23:54.078 5:    f:00001010 seqNum:10
2015.12.09 13:23:54.166 5: xxxxxxxx S:01 F:81 f:0a L:10 T:19 R:00110c P:250100 C:df
2015.12.09 13:23:54.166 5:    F:10000001 singleCast routed, rf:00 hopCount:1, hops:0c
2015.12.09 13:23:54.166 5:    f:00001010 seqNum:10
2015.12.09 13:23:54.191 5: xxxxxxxx S:19 F:c1 f:0a L:0d T:01 R:151f0c P: C:bd
2015.12.09 13:23:54.191 5:    F:11000001 singleCast ackReq routed, rf:15 hopCount:1, hops:0c
2015.12.09 13:23:54.191 5:    f:00001010 seqNum:10
2015.12.09 13:23:54.216 5: xxxxxxxx S:01 F:81 f:0b L:10 T:19 R:00100b P:250100 C:d8
2015.12.09 13:23:54.216 5:    F:10000001 singleCast routed, rf:00 hopCount:1, hops:0b
2015.12.09 13:23:54.216 5:    f:00001011 seqNum:11
2015.12.09 13:23:54.220 5: xxxxxxxx S:01 F:03 f:0a L:0a T:0c P: C:6b
2015.12.09 13:23:54.220 5:    F:00000011 ack
2015.12.09 13:23:54.220 5:    f:00001010 seqNum:10
2015.12.09 13:23:54.242 5: xxxxxxxx S:01 F:81 f:0b L:10 T:19 R:00100b P:250100 C:d8
2015.12.09 13:23:54.242 5:    F:10000001 singleCast routed, rf:00 hopCount:1, hops:0b
2015.12.09 13:23:54.242 5:    f:00001011 seqNum:11
2015.12.09 13:23:54.290 5: xxxxxxxx S:01 F:81 f:0b L:10 T:19 R:00100b P:250100 C:d8
2015.12.09 13:23:54.290 5:    F:10000001 singleCast routed, rf:00 hopCount:1, hops:0b
2015.12.09 13:23:54.290 5:    f:00001011 seqNum:11
2015.12.09 13:23:54.320 5: xxxxxxxx S:01 F:81 f:01 L:10 T:19 R:00100c P:250100 C:d5
2015.12.09 13:23:54.320 5:    F:10000001 singleCast routed, rf:00 hopCount:1, hops:0c
2015.12.09 13:23:54.320 5:    f:00000001 seqNum:1
2015.12.09 13:23:54.328 5: xxxxxxxx S:01 F:81 f:01 L:10 T:19 R:00110c P:250100 C:d4
2015.12.09 13:23:54.328 5:    F:10000001 singleCast routed, rf:00 hopCount:1, hops:0c
2015.12.09 13:23:54.328 5:    f:00000001 seqNum:1
2015.12.09 13:23:54.376 5: xxxxxxxx S:01 F:81 f:01 L:10 T:19 R:00110c P:250100 C:d4
2015.12.09 13:23:54.376 5:    F:10000001 singleCast routed, rf:00 hopCount:1, hops:0c
2015.12.09 13:23:54.376 5:    f:00000001 seqNum:1
2015.12.09 13:23:54.402 5: xxxxxxxx S:01 F:81 f:0b L:10 T:19 R:00110b P:250100 C:d9
2015.12.09 13:23:54.402 5:    F:10000001 singleCast routed, rf:00 hopCount:1, hops:0b
2015.12.09 13:23:54.402 5:    f:00001011 seqNum:11
2015.12.09 13:23:54.427 5: xxxxxxxx S:19 F:c1 f:01 L:0d T:01 R:151f0b P: C:b1
2015.12.09 13:23:54.428 5:    F:11000001 singleCast ackReq routed, rf:15 hopCount:1, hops:0b
2015.12.09 13:23:54.428 5:    f:00000001 seqNum:1
2015.12.09 13:23:54.433 5: xxxxxxxx S:01 F:03 f:01 L:0a T:0b P: C:67
2015.12.09 13:23:54.433 5:    F:00000011 ack
2015.12.09 13:23:54.433 5:    f:00000001 seqNum:1
2015.12.09 13:23:54.462 5: xxxxxxxx S:01 F:81 f:01 L:10 T:19 R:00110c P:250100 C:d4
2015.12.09 13:23:54.462 5:    F:10000001 singleCast routed, rf:00 hopCount:1, hops:0c
2015.12.09 13:23:54.462 5:    f:00000001 seqNum:1
2015.12.09 13:23:54.487 5: xxxxxxxx S:19 F:c1 f:01 L:0d T:01 R:151f0c P: C:b6
2015.12.09 13:23:54.487 5:    F:11000001 singleCast ackReq routed, rf:15 hopCount:1, hops:0c
2015.12.09 13:23:54.487 5:    f:00000001 seqNum:1
2015.12.09 13:23:54.493 5: xxxxxxxx S:01 F:03 f:01 L:0a T:0c P: C:60
2015.12.09 13:23:54.493 5:    F:00000011 ack
2015.12.09 13:23:54.493 5:    f:00000001 seqNum:1
2015.12.09 13:23:54.539 5: xxxxxxxx S:01 F:81 f:02 L:11 T:19 R:00200c0b P:250100 C:ec
2015.12.09 13:23:54.539 5:    F:10000001 singleCast routed, rf:00 hopCount:2, hops:0c 0b
2015.12.09 13:23:54.539 5:    f:00000010 seqNum:2
2015.12.09 13:23:54.547 5: xxxxxxxx S:01 F:81 f:02 L:11 T:19 R:00210c0b P:250100 C:ed
2015.12.09 13:23:54.547 5:    F:10000001 singleCast routed, rf:00 hopCount:2, hops:0c 0b
2015.12.09 13:23:54.547 5:    f:00000010 seqNum:2
2015.12.09 13:23:54.555 5: xxxxxxxx S:01 F:81 f:02 L:11 T:19 R:00220c0b P:250100 C:ee
2015.12.09 13:23:54.555 5:    F:10000001 singleCast routed, rf:00 hopCount:2, hops:0c 0b
2015.12.09 13:23:54.555 5:    f:00000010 seqNum:2
2015.12.09 13:23:54.583 5: xxxxxxxx S:01 F:81 f:02 L:11 T:19 R:00220c0b P:250100 C:ee
2015.12.09 13:23:54.583 5:    F:10000001 singleCast routed, rf:00 hopCount:2, hops:0c 0b
2015.12.09 13:23:54.583 5:    f:00000010 seqNum:2
2015.12.09 13:23:54.610 5: xxxxxxxx S:01 F:81 f:02 L:11 T:19 R:00220c0b P:250100 C:ee
2015.12.09 13:23:54.610 5:    F:10000001 singleCast routed, rf:00 hopCount:2, hops:0c 0b
2015.12.09 13:23:54.610 5:    f:00000010 seqNum:2
2015.12.09 13:23:54.636 5: xxxxxxxx S:19 F:81 f:02 L:0e T:01 R:25200c0b P: C:f2
2015.12.09 13:23:54.636 5:    F:10000001 singleCast routed, rf:25 hopCount:2, hops:0c 0b
2015.12.09 13:23:54.636 5:    f:00000010 seqNum:2
2015.12.09 13:23:54.643 5: xxxxxxxx S:19 F:c1 f:02 L:0e T:01 R:252f0c0b P: C:bd
2015.12.09 13:23:54.643 5:    F:11000001 singleCast ackReq routed, rf:25 hopCount:2, hops:0c 0b
2015.12.09 13:23:54.643 5:    f:00000010 seqNum:2
2015.12.09 13:23:54.649 5: xxxxxxxx S:01 F:03 f:02 L:0a T:0c P: C:63
2015.12.09 13:23:54.649 5:    F:00000011 ack
2015.12.09 13:23:54.649 5:    f:00000010 seqNum:2
2015.12.09 13:23:54.730 5: xxxxxxxx S:01 F:81 f:03 L:10 T:19 R:00100b P:250100 C:d0
2015.12.09 13:23:54.730 5:    F:10000001 singleCast routed, rf:00 hopCount:1, hops:0b
2015.12.09 13:23:54.731 5:    f:00000011 seqNum:3
2015.12.09 13:23:54.738 5: xxxxxxxx S:01 F:81 f:03 L:10 T:19 R:00110b P:250100 C:d1
2015.12.09 13:23:54.738 5:    F:10000001 singleCast routed, rf:00 hopCount:1, hops:0b
2015.12.09 13:23:54.738 5:    f:00000011 seqNum:3
2015.12.09 13:23:54.786 5: xxxxxxxx S:01 F:81 f:03 L:10 T:19 R:00110b P:250100 C:d1
2015.12.09 13:23:54.786 5:    F:10000001 singleCast routed, rf:00 hopCount:1, hops:0b
2015.12.09 13:23:54.786 5:    f:00000011 seqNum:3
2015.12.09 13:23:54.854 5: xxxxxxxx S:01 F:81 f:03 L:10 T:19 R:00110b P:250100 C:d1
2015.12.09 13:23:54.854 5:    F:10000001 singleCast routed, rf:00 hopCount:1, hops:0b
2015.12.09 13:23:54.854 5:    f:00000011 seqNum:3
2015.12.09 13:23:54.880 5: xxxxxxxx S:19 F:c1 f:03 L:0d T:01 R:151f0b P: C:b3
2015.12.09 13:23:54.880 5:    F:11000001 singleCast ackReq routed, rf:15 hopCount:1, hops:0b
2015.12.09 13:23:54.880 5:    f:00000011 seqNum:3
2015.12.09 13:23:54.886 5: xxxxxxxx S:01 F:03 f:03 L:0a T:0b P: C:65
2015.12.09 13:23:54.886 5:    F:00000011 ack
2015.12.09 13:23:54.886 5:    f:00000011 seqNum:3
2015.12.09 13:23:54.931 5: xxxxxxxx S:01 F:81 f:04 L:11 T:19 R:00200b0c P:250100 C:ea
2015.12.09 13:23:54.931 5:    F:10000001 singleCast routed, rf:00 hopCount:2, hops:0b 0c
2015.12.09 13:23:54.931 5:    f:00000100 seqNum:4
2015.12.09 13:23:54.938 5: xxxxxxxx S:01 F:81 f:04 L:11 T:19 R:00210b0c P:250100 C:eb
2015.12.09 13:23:54.938 5:    F:10000001 singleCast routed, rf:00 hopCount:2, hops:0b 0c
2015.12.09 13:23:54.938 5:    f:00000100 seqNum:4
2015.12.09 13:23:54.946 5: xxxxxxxx S:01 F:81 f:04 L:11 T:19 R:00220b0c P:250100 C:e8
2015.12.09 13:23:54.947 5:    F:10000001 singleCast routed, rf:00 hopCount:2, hops:0b 0c
2015.12.09 13:23:54.947 5:    f:00000100 seqNum:4
2015.12.09 13:23:54.974 5: xxxxxxxx S:01 F:81 f:04 L:11 T:19 R:00220b0c P:250100 C:e8
2015.12.09 13:23:54.974 5:    F:10000001 singleCast routed, rf:00 hopCount:2, hops:0b 0c
2015.12.09 13:23:54.974 5:    f:00000100 seqNum:4
2015.12.09 13:23:55.042 5: xxxxxxxx S:01 F:81 f:04 L:11 T:19 R:00220b0c P:250100 C:e8
2015.12.09 13:23:55.042 5:    F:10000001 singleCast routed, rf:00 hopCount:2, hops:0b 0c
2015.12.09 13:23:55.042 5:    f:00000100 seqNum:4
2015.12.09 13:23:55.067 5: xxxxxxxx S:19 F:81 f:04 L:0e T:01 R:25200b0c P: C:f4
2015.12.09 13:23:55.067 5:    F:10000001 singleCast routed, rf:25 hopCount:2, hops:0b 0c
2015.12.09 13:23:55.067 5:    f:00000100 seqNum:4
2015.12.09 13:23:55.075 5: xxxxxxxx S:19 F:c1 f:04 L:0e T:01 R:252f0b0c P: C:bb
2015.12.09 13:23:55.075 5:    F:11000001 singleCast ackReq routed, rf:25 hopCount:2, hops:0b 0c
2015.12.09 13:23:55.075 5:    f:00000100 seqNum:4
2015.12.09 13:23:55.081 5: xxxxxxxx S:01 F:03 f:04 L:0a T:0b P: C:62
2015.12.09 13:23:55.081 5:    F:00000011 ack
2015.12.09 13:23:55.081 5:    f:00000100 seqNum:4


Ich haette jetzt gerne mehr Details zu rf.
Titel: Antw:ZWave @ culfw
Beitrag von: A.Harrenberg am 09 Dezember 2015, 13:57:34
Hi Rudi,
Zitat von: rudolfkoenig am 09 Dezember 2015, 13:34:24
Ok, ich habe sowas aenliches in ZWCUL eingebaut. Benoetigt wird ein verbose 5 fuer ZWCUL (global verbose 5 reicht nicht). Ich habe eine Zwischensteckdose ausgesteckt, und ein "set off" abgesetzt.
Danach war ich etwas beeindruckt:
wie immer bist Du zu schnell für uns... ,-)
Bei Dir ist da noch viel mehr los als bei mir, da sind einfach mehr Optionen für das Routing als bei nur zwei Geräten.

Zitat von: rudolfkoenig am 09 Dezember 2015, 13:34:24
Ich haette jetzt gerne mehr Details zu rf.
Ich auch ,-)
Wie bestimmst Du "hopCount"? Die oberen 4 bit vom Byte nach dem rf?

Sind Deine Geräte in der Lage ExplorerFrames zu verarbeiten? Das fehlt mir bei Deiner Liste am Ende nämlich. Angeblich macht Zwave ja drei Versuche (je Route) und es werden bis zu drei Routen probiert (-> 9 Versuche) und dann als letzte Lösung ExplorerFrames...

Ich kann leider erst wieder ab Donnerstag weiter testen. ;-(

Gruß,
Andreas.
Titel: Antw:ZWave @ culfw
Beitrag von: krikan am 09 Dezember 2015, 17:27:31
Zitat von: A.Harrenberg am 09 Dezember 2015, 13:57:34
Hi Rudi,wie immer bist Du zu schnell für uns... ,-)
Da stimme ich zu!  :) Jetzt habe ich mühevoll die morgendlichen Debug-Änderungen nachvollzogen, da sehe ich, dass gerade schon wieder neue Erkenntnisse im svn sind..  ;) Seufz
ITU bringt mir zumindest ein paar neue Erkenntnisse, obwohl vieles zu sehr in die Tiefe geht.
Titel: Antw:ZWave @ culfw
Beitrag von: krikan am 09 Dezember 2015, 17:58:36
Die Code-Zeile ist im letzten Check-In r10141 doppelt drin:
+        (($hF & 0x10)==0x10 ? " lowSpeed" : "").
Titel: Antw:ZWave @ culfw
Beitrag von: rudolfkoenig am 09 Dezember 2015, 18:11:30
Danke, habs entfernt. Habe evtl. das explorer-Flag gefunden, damit kommen noch zusaetzlich 8 Bytes in payload, die ich nicht interpretieren kann. Beispiel:
2015.12.09 16:59:57.786 5: xxxxxxxx S:35 F:45 f:08 L:24 T:01  E:2000fa4000000000 P:320221740000000000000000000000000000 C:97
2015.12.09 16:59:57.786 5:    F:01000101 singleCast explorer ackReq
2015.12.09 16:59:57.786 5:    f:00001000 seqNum:8


Weiterhin kann man in ZWDongle fuer set/get die FHEM-Namen angeben (wo sinnvoll), also sowas wie "get zwd neighborList Lamp". Das manuelle lookup hat mich genervt.
Titel: Antw:ZWave @ culfw
Beitrag von: krikan am 09 Dezember 2015, 18:20:52
Zitat von: rudolfkoenig am 09 Dezember 2015, 18:11:30
Das manuelle lookup hat mich genervt.
Danke, mich auch schon länger. Wollte nicht fragen, damit ich nicht als Feature-Request-Hero geführt werde...

ZitatIch haette jetzt gerne mehr Details zu rf.
Hast Du rf bewußt als Bezeichnung gewählt? Bestimmt, aber wie kommst Du darauf (Quellen)?
Im ITU-Dok gibt es auch RF, das dürfte aber wohl nur zufällig gleich sein!?
Titel: Antw:ZWave @ culfw
Beitrag von: rudolfkoenig am 09 Dezember 2015, 18:33:47
ZitatHast Du rf bewußt als Bezeichnung gewählt?
rf steht fuer Routing-Flag, Eigenkreation. Habe bisher keine Doku gelesen, wird wohl langsam Zeit. Achtung bei Routing: Hinter hopsCount ist ein nibble, was noch nicht separat ausgegeben wird, steht nur im R: an 4. Stelle.
Titel: Antw:ZWave @ culfw
Beitrag von: krikan am 09 Dezember 2015, 21:59:58
ZitatHabe evtl. das explorer-Flag gefunden, damit kommen noch zusaetzlich 8 Bytes in payload, die ich nicht interpretieren kann.
Das unterstütze ich nach mehreren Tests. Zusätzliche Bytes sind mir auch unklar.
Im ITU-T G.9959 steht etwas von verschiedenen Layern und channel configurations, was ich bei kurzem Überfliegen noch nicht verstanden habe. Evtl. kann man daraus noch etwas schließen. EF sind mMn aber nicht explizit erwähnt.

Ich habe aber das Problem, dass ich nur die vom Controller verschickten Telegramme sehe; die Telegramme von den Geräten tauchen im log nicht auf (auch bei 40k Geräten). Mir ist nicht klar, wie ich das ändern kann. Hast Du eine Ahnung, was ich falsch mache?
list von ZWCUL:
Internals:
   CFGFN
   Clients    :ZWave:STACKABLE_CC:
   DEF        /dev/serial/by-id/usb-busware.de_CUL868-if00 00000000 01
   DeviceName /dev/serial/by-id/usb-busware.de_CUL868-if00
   FD         4
   NAME       zw
   NR         319
   PARTIAL
   RAWMSG     zE345C45201450414042000FA4000000000250222
   STATE      Initialized
   TYPE       ZWCUL
   VERSION    V 1.66 CUL868
   homeId     00000000
   homeIdSet  00000000
   nodeIdHex  01
   zw_MSGCNT  87
   zw_TIME    2015-12-09 21:22:45
   Matchlist:
     1:ZWave    .*
     2:STACKABLE_CC ^\*
   Readings:
     2015-12-09 21:22:45   state           Initialized
Attributes:
   noDispatch 1
   verbose    5
Titel: Antw:ZWave @ culfw
Beitrag von: krikan am 10 Dezember 2015, 05:53:36
Zitat von: krikan am 09 Dezember 2015, 21:59:58
Ich habe aber das Problem, dass ich nur die vom Controller verschickten Telegramme sehe; die Telegramme von den Geräten tauchen im log nicht auf (auch bei 40k Geräten). Mir ist nicht klar, wie ich das ändern kann. Hast Du eine Ahnung, was ich falsch mache?
Es geht doch. Habe die ganze Nacht loggen lassen und jetzt sind auch Geraetetelegramme zu sehen. Verstehe aber immer noch nicht, warum vorher nichts zu sehen war. Kann es sein, das etwas verloren geht, wenn der Server-Computer unter Hoechstlast läuft?
Titel: Antw:ZWave @ culfw
Beitrag von: rudolfkoenig am 10 Dezember 2015, 08:35:51
ZitatKann es sein, das etwas verloren geht, wenn der Server-Computer unter Hoechstlast läuft?
Der Begriff Hoechstlast ist dehnbar, ich glaube aber nicht dran. culfw schreibt die Pakete in einem USB-Puffer von 64-Bytes. Wenn die nicht abgeholt werden, dann kommt nix mehr dazu. Sobald man sie abholt, geht es wieder weiter. Im Sinne der genauen Zeitstempel waere es wuenschenswert, das FHEM ab und zu drankommt. Falls du FHEM-Module einsaetzt, die sich gerne blockieren, dann waere es sinnvoll ZWCUL auf einem separaten FHEM-Instanz zu betreiben und damit meine ich nicht einen neuen Rechner.

Wg. unsichtbare Telegramme: die zway.me Fernbedienung Telegramme an den Goodway USB-Stick (und die Antworten) sehe ich auch nicht. Kann der  Goodway WD6001 (version: Z-Wave 3.28/SDK 5.03) ueberhaupt 100k? Ich muss vermutlich die Chips auf der Platine untersuchen. Goodway selbst scheint den Stick nicht mehr zu kennen.
Titel: Antw:ZWave @ culfw
Beitrag von: krikan am 10 Dezember 2015, 08:56:07
Zitat von: rudolfkoenig am 10 Dezember 2015, 08:35:51Kann der  Goodway WD6001 (version: Z-Wave 3.28/SDK 5.03) ueberhaupt 100k?
Nein, wenn man von SDK auf Chipsatz schließen kann, was sich aus der Doku von Sigma mMn ergibt, sollte es 3er Chipsatz sein und der kann kein 100k.
Beim Dongle kannst Du den Chipsatz aber direkt abfragen. Steht in "get <ZWdongle> nodelist" (0x02) im raw-Telegramm (ZW_VERSION liefert Übersetzungshilfe)
Zitat
Falls du FHEM-Module einsaetzt, die sich gerne blockieren, dann waere es sinnvoll ZWCUL auf einem separaten FHEM-Instanz zu betreiben und damit meine ich nicht einen neuen Rechner.
Da die Hauptlast von einem eigenen blocking Modul kommt (das ich immer noch durch EMCD ersetzen will), kann ich das nicht ausschließen, aber sehe es in den Logs nicht und habe es vorher nicht festgestellt. Aber das ist jetzt wohl der KO und werde Deinen Rat befolgen.

Titel: Antw:ZWave @ culfw
Beitrag von: krikan am 10 Dezember 2015, 09:07:07
ZitatGoodway WD6001 (version: Z-Wave 3.28/SDK 5.03)
Der dürfte mit SDK 5.x auch keine EF können. Wenn Deine Feststellungen zu EF auf dem Controller beruhen, würde mich das schon wundern. Hoffe, das ist nicht so.
Titel: Antw:ZWave @ culfw
Beitrag von: A.Harrenberg am 10 Dezember 2015, 09:24:02
Hi Rudi,
Zitat von: rudolfkoenig am 10 Dezember 2015, 08:35:51
Der Begriff Hoechstlast ist dehnbar, ich glaube aber nicht dran. culfw schreibt die Pakete in einem USB-Puffer von 64-Bytes. Wenn die nicht abgeholt werden, dann kommt nix mehr dazu. Sobald man sie abholt, geht es wieder weiter. Im Sinne der genauen Zeitstempel waere es wuenschenswert, das FHEM ab und zu drankommt. Falls du FHEM-Module einsaetzt, die sich gerne blockieren, dann waere es sinnvoll ZWCUL auf einem separaten FHEM-Instanz zu betreiben und damit meine ich nicht einen neuen Rechner.
eines meiner Probleme mit dem RFID-Leser war (oder ist imemr noch) das blockierend IP_CAM Modul. Gibt es eigentlich eine Art "Watchdog" für FHEM der Warnungen auspuckt wenn z.B. länger als 0.x Sekunden nicht getriggert wird/wurde? Oder irgendeine andere Methode mit der man soetwas erkennen kann?

Zitat von: rudolfkoenig am 10 Dezember 2015, 08:35:51
Wg. unsichtbare Telegramme: die zway.me Fernbedienung Telegramme an den Goodway USB-Stick (und die Antworten) sehe ich auch nicht. Kann der  Goodway WD6001 (version: Z-Wave 3.28/SDK 5.03) ueberhaupt 100k? Ich muss vermutlich die Chips auf der Platine untersuchen. Goodway selbst scheint den Stick nicht mehr zu kennen.
Wegen der 100k bin ich kurz davor mir einen zweiten CUL zu kaufen... Für 9.6k bräuchte man theoretisch ja sogar noch einen dritten... Es gibt zwar wahrscheinlich kaum Geräte die nur 9.6k können, ich bin mir aber nicht sicher ob 100k/40k Geräte im Fehlerfall nicht sogar noch mal auf 9.6k runterschalten. Die 100k gehen ja auf jeden Fall auf 40k runter.

An sowas hier (Zwave_Radio_Chip (http://www.si-vision.com/en/ips/zwave)) kommt man ja wahrscheinlich nicht ran... Zumindest finde ich den Chip nirgends.

@Krikan: Diese blöden SDK Nummern nerven... Gibt es eine gute Liste die Du mal nennen könntest? Ich finde meist nur listen in denen genau meine SDK / Lib-Version nicht drin ist. Ich hatte mal geschaut und ich meine beim Pätz gelesen zu haben das EF ab SDK 4.5x drin ist.

Gruß,
Andreas.
Titel: Antw:ZWave @ culfw
Beitrag von: rudolfkoenig am 10 Dezember 2015, 10:12:43
ZitatWenn Deine Feststellungen zu EF auf dem Controller beruhen, würde mich das schon wundern.
EF kam von dem Aeon Switch, der sein ZME Dongle vermisst hat. Hat zunaechst 3-mal eine "normale" Meldung abgesetzt, und zum Schluss eine mit EF.

ZitatGibt es eigentlich eine Art "Watchdog" für FHEM der Warnungen auspuckt wenn z.B. länger als 0.x Sekunden nicht getriggert wird/wurde?
Sowas gibts im HM Umfeld, ich meine es heisst apptime. HM braucht es, weil HM@culfw die Acks in Perl generiert, und HMLAN alle 30s ein keepalive braucht. Deswegen generieren wir die Acks bei ZWave@culfw im Firmware  :)
Titel: Antw:ZWave @ culfw
Beitrag von: A.Harrenberg am 10 Dezember 2015, 10:51:12
Hi,
Zitat von: rudolfkoenig am 10 Dezember 2015, 10:12:43
Sowas gibts im HM Umfeld, ich meine es heisst apptime. HM braucht es, weil HM@culfw die Acks in Perl generiert, und HMLAN alle 30s ein keepalive braucht. Deswegen generieren wir die Acks bei ZWave@culfw im Firmware  :)
danke werde mal schauen ob ich das nutzen kann.

Noch was anderes, weiß einer von euch ob auf dem RaZberry wirklich nur der Transceiver drauf ist und man an die Pins drankommt?

Der müsste dann ja auch das Funkprotokoll ausgeben und die höheren Layer müssten in SW realisiert sein... Ich denke ich muss mir das mal etwas genauer ansehen. Wäre eine Alternative zu mehreren CUL wenn man da direkt an die HW kommt.

Gruß,
Andreas.
Titel: Antw:ZWave @ culfw
Beitrag von: krikan am 10 Dezember 2015, 11:57:42
Zitat von: A.Harrenberg am 10 Dezember 2015, 09:24:02
Wegen der 100k bin ich kurz davor mir einen zweiten CUL zu kaufen...
Genau darum hoffe ich auf Ankunft von Locuts miniCul. Locutus/Björn haben ZWave bereits in a-culfw aufgenommen.
Bei mir habe ich den Eindruck, dass die 100k-Geräte sehr häufig ins Routing eingebunden sind; selbst wenn ich es aus den Abständen nicht vermuten würde.

ZitatGibt es eine gute Liste die Du mal nennen könntest?
Ja, die berühmte sdkids.xml.
Und Du solltest mal mit zway (http://razberry.z-wave.me/z-way-server/) eine aktuelle Firmware auf Deinen UZB flashen; dann findest Du die neueste.  :)
Titel: Antw:ZWave @ culfw
Beitrag von: rudolfkoenig am 10 Dezember 2015, 15:29:07
Habe das ITU Dokument grob durchgelesen, und ein paar Flags angepasst. Routing ist da nicht beschrieben, aber beams. Und alles andere, was wir auch schon wissen :)
Weiterhin kann man jetzt auf 100k schalten mit "attr ZWCUL dataRate 100k", leider funktioniert das bei mir immer noch nicht, keine Ahnung, wieso.
Titel: Antw:ZWave @ culfw
Beitrag von: A.Harrenberg am 10 Dezember 2015, 15:55:44
Hi Rudi,
Zitat von: rudolfkoenig am 10 Dezember 2015, 15:29:07
Habe das ITU Dokument grob durchgelesen, und ein paar Flags angepasst. Routing ist da nicht beschrieben, aber beams. Und alles andere, was wir auch schon wissen :)
Du willst damit sagen das wir diese Quelle jetzt ignorieren können weil alles interessante bereits integriert ist? ;-)

Zitat von: rudolfkoenig am 10 Dezember 2015, 15:29:07
Weiterhin kann man jetzt auf 100k schalten mit "attr ZWCUL dataRate 100k", leider funktioniert das bei mir immer noch nicht, keine Ahnung, wieso.
Ich werde mal schauen ob ich da heute abend ein wenig probieren kann und werde dann ggf. noch mal mit den Parametern vom CC experimentieren. In einer Quelle (die ich mir natürlich nicht gemerkt habe) war als "deviation" 0 angegeben. Erster Versuch wäre daher mal diese 0 mit den 400kHz Bandbreite...

Gruß,
Andreas.
Titel: Antw:ZWave @ culfw
Beitrag von: A.Harrenberg am 10 Dezember 2015, 19:52:12
Hallo Rudi,

bist Du Dir hier sicher oder ist da was durcheinander geraten...

  if($s100 && $rmsg =~ '^z(........)(..)(..)(..)(..)(..)(..)(.*)(....)$') {
    ($H,$S,$F,$f,$L,$sn,$T,$P,$C) = ($1,$2,$3,$4,$5,$6,$7,$8,$9);

  } elsif(!$s100 && $rmsg =~ '^z(........)(..)(..)(.)(.)(..)(..)(.*)(..)$') {
    ($H,$S,$F,$f,$sn,$L,$T,$P,$C) = ($1,$2,$3,$4,$5,$6,$7,$8,$9);


Für die 100k sind da zu viele "." : ERROR: Unknown packet ze015dfed0103010bab36a8
Die Nachricht ist dafür zu kurz, mit Nibbles für $4 und $5 passt das wieder...

Aber Du hast da auch noch verschiedene Reihenfolgen in den Variablen -> $sn und $L vertauscht, hier würde ich auch dazu tendieren das die 40K Reihenfolge stimmt...

Gruß,
Andreas.

P.S.: Ich kann standardmäßig 100k lesen...

Titel: Antw:ZWave @ culfw
Beitrag von: A.Harrenberg am 10 Dezember 2015, 21:01:31
Hallo Rudi,

kannst Du mal diese Parameter für 100kBaud probieren?

#define ZWAVE_100k_SIZE (8*2)
  CC1100_FREQ2,     0x21, // 0D Frequency control word, high byte 869.85 MHz
  CC1100_FREQ1,     0x74, // 0E
  CC1100_FREQ0,     0xAD, // 0F
  CC1100_MDMCFG4,   0x4b, // 10 Modem configuration               bW 406kHz
  CC1100_MDMCFG3,   0xf8, // 11 Modem configuration               dr 100kBaud
  CC1100_MDMCFG2,   0x06, // 12 Modem configuration               GFSK/16sync
  CC1100_MDMCFG1,   0x72, // 13 Modem configuration               24 preamble
  CC1100_DEVIATN,   0x41  // 15 Modem deviation setting           dev:28 kHz -> 2*28 ~ 57 kHz

Das funktioniert bei mir einwandfrei, ich kann mit dem Bewegungssensor in die letzte Ecke von der Wohnung gehen und erhalte einwandfreie Protokolle.

Gruß,
Andreas.
Titel: Antw:ZWave @ culfw
Beitrag von: rudolfkoenig am 10 Dezember 2015, 22:19:19
Zitatbist Du Dir hier sicher oder ist da was durcheinander geraten...
Kann gut sein, ich habe halt fleissig das ITU Dokument abgeschrieben, und ich kann 100k nicht testen. Im ITU steht drin, dass mit 100k seqNum nicht mehr ein nibble, sondern ein extra Byte nach len ist. Bitte Korrektur schicken, falls das nicht dem Realitaet entspricht.

Zitatkannst Du mal diese Parameter für 100kBaud probieren?
Habs gemacht, kein Unterschied. Weder den as6 in 100k Modus, noch den KFOB kann ich empfangen.

Komisch: die zwave.me Fernbedienung kann ich mit culfw@40k auch nicht empfangen, und da sie zum goodway gehoert, kann sie hoechstens 40k sein, insofern haben wir noch ein generelles Problem bei Fernbedienungen. Seufz.
Titel: Antw:ZWave @ culfw
Beitrag von: rudolfkoenig am 10 Dezember 2015, 22:29:32
Sorry, gerade gefunden: bei nicht gesetzten dataRate gabs unter 40k Probleme. Das habe ich gefixt.
Titel: Antw:ZWave @ culfw
Beitrag von: A.Harrenberg am 10 Dezember 2015, 22:40:59
Hallo Rudi,

kann es sein das Du beim Lesen der ITU "Channel configuration" und "Datarate" durcheinander geworfen hast?

Ich finde einen etwas anderen Aufbau  (mit getrenntem Byte für Sequencenumber) nur für Channel configuration 3, die haben wir aber nicht! Wir haben auch mit 100kBaud nur Channel configuration 1 oder 2.
[Rec. ITU-T G.9959 (01/2015) Seite 41, 42, 44]

Übersicht über Channel configuration / Datarate ist auf Seite 10 zu finden.
(Welche Version von dem Dokument hast Du denn eigentlich?)

Ich bin daher der Meinung das dies für 40k / 100k gleich sein muss. Einzig die Checksumme ist unterschiedlich 40k -> CS, 100k -> CRC_16
Und wie Du an dem Beispiel sehen konntest z.B. so eine ACK Nachricht ansonsten zu kurz..

Gruß,
Andreas.
Titel: Antw:ZWave @ culfw
Beitrag von: A.Harrenberg am 11 Dezember 2015, 08:02:12
Hi Rudi,

ich habe mir das jetzt so abgeändert:
  if($s100 && $rmsg =~ '^z(........)(..)(..)(.)(.)(..)(..)(.*)(....)$') {
    ($H,$S,$F,$f,$sn,$L,$T,$P,$C) = ($1,$2,$3,$4,$5,$6,$7,$8,$9);

  } elsif(!$s100 && $rmsg =~ '^z(........)(..)(..)(.)(.)(..)(..)(.*)(..)$') {
    ($H,$S,$F,$f,$sn,$L,$T,$P,$C) = ($1,$2,$3,$4,$5,$6,$7,$8,$9);

-> identisch außer Checksumme.

Und beim Parsen habe ich mir den Block für die 100kBaud auskommentiert:
      # ($s100 ?
      #   ((($hF & 0x40)==0x20 ? " lowPower":"").
      #    (($hF & 0x80)==0x40 ? " ackReq":"").
      #    (($hf&0x7)==0 ? " "               :
      #     ($hf&0x7)==1 ? " shortBeam"      :
      #     ($hf&0x7)==2 ? " longBeam"       :
      #     ($hf&0x7)==4 ? " fragmentedBeam" : " unknownBeam"))
      # :
      ((($hF & 0x10)==0x10 ? " speedModified":"").
         (($hF & 0x20)==0x20 ? " lowPower":"").
         (($hF & 0x40)==0x40 ? " ackReq":"").
         (($hF & 0x80)==0x80 ? " routed, rf:$rf hopCount:$hc, hops:$hops":"").
         ((($hf>>1)&3)==0 ? " "          :
          (($hf>>1)&3)==1 ? " shortBeam" :
          (($hf>>1)&3)==2 ? " longBeam"  :" unknownBeam"));

Sieht für mich erst mal ok aus, allerdings habe ich jetzt noch nicht so viele Pakete angeschaut und geroutete Nachrichten hatte ich da jetzt auch noch nicht dabei. (Kriege ich nur hin wenn ich z.B. den Steckdosenschalter rausziehe, dann fällt das Netz aber auf 40K zurück...)

Gruß,
Andreas.

P.S.: Demnächst dann auch als Patchdatei... ,-)
P.P.S.: Ganz optimal sind die 100K Parameter anscheinend auch nicht, bei mir tauchen zwischendurch immer wieder recht lange falsche Nachrichten auf...
Titel: Antw:ZWave @ culfw
Beitrag von: A.Harrenberg am 11 Dezember 2015, 09:12:02
Hi Rudi,

irgendwas stimmt da mit dem Parsen der einzelnen Befehle für FHEMWEB noch nicht, in dem DropDown werden die Befehle alle mit Komma getrennt hintereinander ausgegeben und nicht als einzelne DropDown-Zeilen.

Siehe Anhang/Bild
(http://forum.fhem.de/index.php?action=dlattach;topic=44905.0;attach=41869;image)

Auf Anhieb finde ich aber nicht was da anders ist als in ZWave.pm.
Die (manuelle) Befehlseingabe funktioniert aber einwandfrei.

Gruß,
Andreas.
Titel: Antw:ZWave @ culfw
Beitrag von: rudolfkoenig am 11 Dezember 2015, 11:54:07
Zitatin dem DropDown werden die Befehle alle mit Komma getrennt hintereinander ausgegeben
Danke, habs gefixt.

Zitatkann es sein das Du beim Lesen der ITU "Channel configuration" und "Datarate" durcheinander geworfen hast?
Yepp, habe bei der Beschriftung der Tabelle nicht nachgedacht. Da Channel Configuration 3 nur in Japan und Korea zum tragen kommt, habe ich den entsprechenden Kode entfernt, und dein regexp Vorschlag uebernommen. Hast du eine Idee, wieso ich keine Pakete von meinen Fernbedienungen empfange? Funktioniert das bei dir?

ZitatGanz optimal sind die 100K Parameter anscheinend auch nicht, bei mir tauchen zwischendurch immer wieder recht lange falsche Nachrichten auf...
Das gibts bei 40k auch, nur seltener. Kannst du mir bitte 2-3 komplette 100k Nachrichten schicken, damit ich die Checksummenberechnung testen kann? Dann wuerde ich die Checksummen-Pruefung auch fuer Monitor-Mode aktivieren.
Titel: Antw:ZWave @ culfw
Beitrag von: A.Harrenberg am 11 Dezember 2015, 13:18:27
Hi Rudi,
Zitat von: rudolfkoenig am 11 Dezember 2015, 11:54:07
Hast du eine Idee, wieso ich keine Pakete von meinen Fernbedienungen empfange? Funktioniert das bei dir?
da kann ich leider nichts zu sagen da ich keine ZWave Fernbedienung habe.

Das einzige was mir dazu gerade einfällt ist das die vielleicht Beams verwenden, bzw. eine andere Anzahl an Präambel Paketen und deswegen nichts vom Chip gemeldet wird.

Ich habe das jetzt nicht noch mal ausprobiert, aber man könnte noch mal die Sync/Präambel im CC ausschalten und sehen was dann so alles ankommt. Problem dabei ist das dann kontinuirlich Müll ankommt... Die Frage wäre ob man dann dort die Präambel und das SyncByte erkennen würde, das wird ja ansonsten direkt vom CC entfernt. Das macht man dann am besten nur per Screen... Mal schauen ob ich heute abend Zeit finde das mal zu probieren, ansonsten frühestens Sonntag.

Zitat von: rudolfkoenig am 11 Dezember 2015, 11:54:07
Das gibts bei 40k auch, nur seltener. Kannst du mir bitte 2-3 komplette 100k Nachrichten schicken, damit ich die Checksummenberechnung testen kann? Dann wuerde ich die Checksummen-Pruefung auch fuer Monitor-Mode aktivieren.
Kann ich Dir erst heute abend schicken, auf die Test-Maschine habe ich aktuell keinen Remotezugriff, aber die Berechnung die ich für die CRC_16 Klasse gemacht habe funktioniert. Die ersten Pakete hatte ich händisch mit dem Code geprüft und die CRC war identisch.
Mir ist jetzt auf Anhieb nicht mehr geläufig wie generisch ich das umgesetzt habe, aber es würde sich wohl anbieten das auch in die ZWlib.pm auszulagern.

Gruß,
Andreas.
Titel: Antw:ZWave @ culfw
Beitrag von: krikan am 11 Dezember 2015, 14:28:51
Zitat von: rudolfkoenig am 11 Dezember 2015, 11:54:07
Hast du eine Idee, wieso ich keine Pakete von meinen Fernbedienungen empfange? Funktioniert das bei dir?
Sprichst Du vom KFOB-S oder von der alten DÜWI.
Erstes könnte ich mal testen.
Wenn es um die uralte DÜWI geht, dann ist die Frage, ob die überhaupt schon 40k kann oder noch bei 9600 war.
Titel: Antw:ZWave @ culfw
Beitrag von: rudolfkoenig am 11 Dezember 2015, 14:55:31
ZitatSprichst Du vom KFOB-S oder von der alten DÜWI.
Eigentlich von beiden:


KFOB-S an zme:
zwd nodeInfo_51 => ROUTING_SLAVE SWITCH_REMOTE sleeping frequentListening:0 beaming:16 routing 40kBaud Vers:4 Security:0

DÜWI mit zwave.me Firmware an goodway:
zwd nodeInfo_22 => ROUTING_SLAVE SWITCH_REMOTE sleeping frequentListening:0 beaming:16 routing 40kBaud Vers:4 Security:0

Titel: Antw:ZWave @ culfw
Beitrag von: krikan am 11 Dezember 2015, 19:22:25
Kurztest mit 100k:
KFOB-S sehe ich auch nichts.
Bei Netzgespeisten Geräten (Sirene und  LED) sehe ich Telegramme sporadisch. 2dbi-Antenne verbessert es ein wenig.

@Andreas: Siehst Du den AEOTEC Multisensor?
Titel: Antw:ZWave @ culfw
Beitrag von: A.Harrenberg am 11 Dezember 2015, 19:37:03
Hi,

hier mal ein kurzer Logausschnitt mit dem AEOTEC Multisensor 6 und dem CUL auf 100kBaud:

2015.12.11 19:34:00.092 4: ZWCUL_ReadAnswer arg:Clear regexp:wontmatch
2015.12.11 19:34:00.592 5: ZWCUL_ReadAnswer: select timeout
2015.12.11 19:34:00.592 5: SW: V
2015.12.11 19:34:00.594 4: ZWCUL_ReadAnswer arg:Version regexp:^V
2015.12.11 19:34:00.955 4: ZWCUL_ReadAnswer for Version: V 1.66 CUL868
2015.12.11 19:34:00.955 5: SW: zi0000000001
2015.12.11 19:34:00.956 5: SW: zm1
2015.12.11 19:34:15.272 5: ZWCul: ze015dfedab410115017105000000ff070300000283
2015.12.11 19:34:15.272 5: e015dfed S:ab F:41 f:0 SN:1 L:15 T:01 P:7105000000ff07030000 C:0283
2015.12.11 19:34:15.272 5:    F: singleCast ackReq
2015.12.11 19:34:15.280 5: ZWCul: ze015dfed0103010bab36a8
2015.12.11 19:34:15.280 5: e015dfed S:01 F:03 f:0 SN:1 L:0b T:ab P: C:36a8
2015.12.11 19:34:15.280 5:    F: ack
2015.12.11 19:34:15.294 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 000400ab0a7105000000ff07030000
2015.12.11 19:34:15.294 5: SW: 06
2015.12.11 19:34:15.295 5: ZWDongle_0 dispatch 000400ab0a7105000000ff07030000
2015.12.11 19:34:15.295 4: ZWDongle_0 CMD:APPLICATION_COMMAND_HANDLER ID:ab ARG:0a7105000000ff07030000
2015.12.11 19:34:23.385 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 004984ab120421015e86725985737184803031707aef5a
2015.12.11 19:34:23.385 5: SW: 06
2015.12.11 19:34:23.386 5: ZWDongle_0 dispatch 004984ab120421015e86725985737184803031707aef5a
2015.12.11 19:34:23.387 4: ZWDongle_0 CMD:ZW_APPLICATION_UPDATE ID:ab ARG:120421015e86725985737184803031707aef5a
2015.12.11 19:34:23.788 5: ZWDongle_Write 0013ab02840825ab (e015dfed)
2015.12.11 19:34:23.788 5: SW: 01090013ab02840825ab4e
2015.12.11 19:34:23.792 5: ACK received, WaitForAck=>2 for 01090013ab02840825ab4e
2015.12.11 19:34:23.801 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 011301
2015.12.11 19:34:23.801 5: SW: 06
2015.12.11 19:34:23.802 5: ZWDongle_0 dispatch 011301
2015.12.11 19:34:23.807 5: ZWCul: ze015dfed01410e0dab84086eb5
2015.12.11 19:34:23.807 5: e015dfed S:01 F:41 f:0 SN:e L:0d T:ab P:8408 C:6eb5
2015.12.11 19:34:23.807 5:    F: singleCast ackReq
2015.12.11 19:34:23.815 5: ZWCul: ze015dfedab030e0b0162f3
2015.12.11 19:34:23.815 5: e015dfed S:ab F:03 f:0 SN:e L:0b T:01 P: C:62f3
2015.12.11 19:34:23.815 5:    F: ack
2015.12.11 19:34:23.834 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 0013ab000002
2015.12.11 19:34:23.834 5: SW: 06
2015.12.11 19:34:23.835 5: device ack reveived, removing 01090013ab02840825ab4e from dongle sendstack
2015.12.11 19:34:23.835 5: ZWDongle_0 dispatch 0013ab000002
2015.12.11 19:34:23.835 4: ZWDongle_0 CMD:ZW_SEND_DATA ID:00 ARG:0002
2015.12.11 19:34:23.835 4: ZWDongle_0 transmit OK for ab
2015.12.11 19:34:24.279 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 000404ab028407
2015.12.11 19:34:24.279 5: SW: 06
2015.12.11 19:34:24.280 5: ZWDongle_0 dispatch 000404ab028407
2015.12.11 19:34:24.280 4: ZWDongle_0 CMD:APPLICATION_COMMAND_HANDLER ID:ab ARG:028407
2015.12.11 19:34:24.681 5: ZWDongle_Write 0013ab02840825ab (e015dfed)
2015.12.11 19:34:24.681 5: SW: 01090013ab02840825ab4e
2015.12.11 19:34:24.684 5: ACK received, WaitForAck=>2 for 01090013ab02840825ab4e
2015.12.11 19:34:24.699 5: ZWCul: ze015dfed01410f0dab8408c4e4
2015.12.11 19:34:24.699 5: e015dfed S:01 F:41 f:0 SN:f L:0d T:ab P:8408 C:c4e4
2015.12.11 19:34:24.699 5:    F: singleCast ackReq
2015.12.11 19:34:24.706 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 011301
2015.12.11 19:34:24.706 5: SW: 06
2015.12.11 19:34:24.708 5: ZWDongle_0 dispatch 011301
2015.12.11 19:34:24.766 5: ZWCul: ze015dfed01410f0dab8408c4e4
2015.12.11 19:34:24.766 5: e015dfed S:01 F:41 f:0 SN:f L:0d T:ab P:8408 C:c4e4
2015.12.11 19:34:24.766 5:    F: singleCast ackReq
2015.12.11 19:34:24.867 5: ZWCul: ze015dfed0141010dab84080b4c
2015.12.11 19:34:24.867 5: e015dfed S:01 F:41 f:0 SN:1 L:0d T:ab P:8408 C:0b4c
2015.12.11 19:34:24.867 5:    F: singleCast ackReq
2015.12.11 19:34:24.919 5: ZWCul: ze015dfed0141010dab84080b4c
2015.12.11 19:34:24.919 5: e015dfed S:01 F:41 f:0 SN:1 L:0d T:ab P:8408 C:0b4c
2015.12.11 19:34:24.919 5:    F: singleCast ackReq
2015.12.11 19:34:26.710 4: no response from device, removing 01090013ab02840825ab4e from dongle sendstack
2015.12.11 19:34:29.005 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 0013ab0101ae
2015.12.11 19:34:29.005 5: SW: 06
2015.12.11 19:34:29.006 5: ZWDongle_0 dispatch 0013ab0101ae
2015.12.11 19:34:29.007 4: ZWDongle_0 CMD:ZW_SEND_DATA ID:01 ARG:01ae
2015.12.11 19:34:29.007 2: ZWDongle_0 transmit NO_ACK for ab
2015.12.11 19:34:49.147 2: ZWave get ZWave_SENSOR_MULTILEVEL_171 version
2015.12.11 19:34:53.636 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 004984ab120421015e86725985737184803031707aef5a
2015.12.11 19:34:53.636 5: SW: 06
2015.12.11 19:34:53.637 5: ZWDongle_0 dispatch 004984ab120421015e86725985737184803031707aef5a
2015.12.11 19:34:53.637 4: ZWDongle_0 CMD:ZW_APPLICATION_UPDATE ID:ab ARG:120421015e86725985737184803031707aef5a
2015.12.11 19:34:53.637 5: ZWDongle_Write 0013ab02861125ab (e015dfed)
2015.12.11 19:34:53.637 5: SW: 01090013ab02861125ab55
2015.12.11 19:34:53.640 5: ACK received, WaitForAck=>2 for 01090013ab02861125ab55
2015.12.11 19:34:53.657 5: ZWCul: ze015dfed0141020dab861100e4
2015.12.11 19:34:53.657 5: e015dfed S:01 F:41 f:0 SN:2 L:0d T:ab P:8611 C:00e4
2015.12.11 19:34:53.657 5:    F: singleCast ackReq
2015.12.11 19:34:53.667 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 011301
2015.12.11 19:34:53.667 5: SW: 06
2015.12.11 19:34:53.668 5: ZWDongle_0 dispatch 011301
2015.12.11 19:34:53.668 5: ZWCul: ze015dfedab03020b011792
2015.12.11 19:34:53.668 5: e015dfed S:ab F:03 f:0 SN:2 L:0b T:01 P: C:1792
2015.12.11 19:34:53.668 5:    F: ack
2015.12.11 19:34:53.674 5: ZWCul: ze015dfedab410214018612030405010664000a78
2015.12.11 19:34:53.674 5: e015dfed S:ab F:41 f:0 SN:2 L:14 T:01 P:861203040501066400 C:0a78
2015.12.11 19:34:53.674 5:    F: singleCast ackReq
2015.12.11 19:34:53.683 5: ZWCul: ze015dfed0103020bab6ff8
2015.12.11 19:34:53.683 5: e015dfed S:01 F:03 f:0 SN:2 L:0b T:ab P: C:6ff8
2015.12.11 19:34:53.683 5:    F: ack
2015.12.11 19:34:53.693 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 0013ab000003
2015.12.11 19:34:53.693 5: SW: 06
2015.12.11 19:34:53.694 5: device ack reveived, removing 01090013ab02861125ab55 from dongle sendstack
2015.12.11 19:34:53.694 5: ZWDongle_0 dispatch 0013ab000003
2015.12.11 19:34:53.694 4: ZWDongle_0 CMD:ZW_SEND_DATA ID:00 ARG:0003
2015.12.11 19:34:53.694 4: ZWDongle_0 transmit OK for ab
2015.12.11 19:34:53.742 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 000400ab09861203040501066400
2015.12.11 19:34:53.742 5: SW: 06
2015.12.11 19:34:53.743 5: ZWDongle_0 dispatch 000400ab09861203040501066400
2015.12.11 19:34:53.743 4: ZWDongle_0 CMD:APPLICATION_COMMAND_HANDLER ID:ab ARG:09861203040501066400
2015.12.11 19:34:54.139 5: ZWDongle_Write 0013ab02840825ab (e015dfed)
2015.12.11 19:34:54.139 5: SW: 01090013ab02840825ab4e
2015.12.11 19:34:54.143 5: ACK received, WaitForAck=>2 for 01090013ab02840825ab4e
2015.12.11 19:34:54.157 5: ZWCul: ze015dfed0141030dab84084fcf
2015.12.11 19:34:54.157 5: e015dfed S:01 F:41 f:0 SN:3 L:0d T:ab P:8408 C:4fcf
2015.12.11 19:34:54.157 5:    F: singleCast ackReq
2015.12.11 19:34:54.158 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 011301
2015.12.11 19:34:54.158 5: SW: 06
2015.12.11 19:34:54.160 5: ZWDongle_0 dispatch 011301
2015.12.11 19:34:54.165 5: ZWCul: ze015dfedab03030b0120a2
2015.12.11 19:34:54.165 5: e015dfed S:ab F:03 f:0 SN:3 L:0b T:01 P: C:20a2
2015.12.11 19:34:54.165 5:    F: ack
2015.12.11 19:34:54.187 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 0013ab000003
2015.12.11 19:34:54.187 5: SW: 06
2015.12.11 19:34:54.188 5: device ack reveived, removing 01090013ab02840825ab4e from dongle sendstack
2015.12.11 19:34:54.188 5: ZWDongle_0 dispatch 0013ab000003
2015.12.11 19:34:54.188 4: ZWDongle_0 CMD:ZW_SEND_DATA ID:00 ARG:0003
2015.12.11 19:34:54.188 4: ZWDongle_0 transmit OK for ab
2015.12.11 19:34:54.541 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 000404ab028407
2015.12.11 19:34:54.541 5: SW: 06
2015.12.11 19:34:54.542 5: ZWDongle_0 dispatch 000404ab028407
2015.12.11 19:34:54.542 4: ZWDongle_0 CMD:APPLICATION_COMMAND_HANDLER ID:ab ARG:028407
2015.12.11 19:34:54.943 5: ZWDongle_Write 0013ab02840825ab (e015dfed)
2015.12.11 19:34:54.943 5: SW: 01090013ab02840825ab4e
2015.12.11 19:34:54.946 5: ACK received, WaitForAck=>2 for 01090013ab02840825ab4e
2015.12.11 19:34:54.957 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 011301
2015.12.11 19:34:54.957 5: SW: 06
2015.12.11 19:34:54.958 5: ZWDongle_0 dispatch 011301
2015.12.11 19:34:54.959 5: ZWCul: ze015dfed0141040dab8408281b
2015.12.11 19:34:54.959 5: e015dfed S:01 F:41 f:0 SN:4 L:0d T:ab P:8408 C:281b
2015.12.11 19:34:54.959 5:    F: singleCast ackReq
2015.12.11 19:34:54.997 5: ZWCul: ze015dfed0141040dab8408281b
2015.12.11 19:34:54.997 5: e015dfed S:01 F:41 f:0 SN:4 L:0d T:ab P:8408 C:281b
2015.12.11 19:34:54.997 5:    F: singleCast ackReq
2015.12.11 19:34:55.071 5: ZWCul: ze015dfed0141050dab8408824a
2015.12.11 19:34:55.071 5: e015dfed S:01 F:41 f:0 SN:5 L:0d T:ab P:8408 C:824a
2015.12.11 19:34:55.071 5:    F: singleCast ackReq
2015.12.11 19:34:55.123 5: ZWCul: ze015dfed0141050dab8408824a
2015.12.11 19:34:55.123 5: e015dfed S:01 F:41 f:0 SN:5 L:0d T:ab P:8408 C:824a
2015.12.11 19:34:55.123 5:    F: singleCast ackReq
2015.12.11 19:34:56.959 4: no response from device, removing 01090013ab02840825ab4e from dongle sendstack
2015.12.11 19:34:59.204 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 0013ab0101a8
2015.12.11 19:34:59.204 5: SW: 06
2015.12.11 19:34:59.206 5: ZWDongle_0 dispatch 0013ab0101a8
2015.12.11 19:34:59.206 4: ZWDongle_0 CMD:ZW_SEND_DATA ID:01 ARG:01a8
2015.12.11 19:34:59.206 2: ZWDongle_0 transmit NO_ACK for ab

Irgendwo da drin ist auch ein NO_ACK, das ist aber weil das Ding so tierisch schnell einschläft... WNMI_delay war schon auf 0.4 sekunden... Hab' es jetzt mal auf 0.3 gesetzt.

@Krikan: Damit dürfte Deine Frage beantwortet sein ,-) Das Ding ist momentan aber auch nur 0.4m vom CUL entfernt, gestern war ich aber am anderen Ende der Wohnung, da ging es auch.

Gruß,
Andreas.
Titel: Antw:ZWave @ culfw
Beitrag von: krikan am 12 Dezember 2015, 17:04:01
Längerer Test mit KFOB-S:
Habe jetzt mal gleichzeitig 40k und 100k mitgeschnitten. Telegramme sehe ich bei 100k, wenn ich Befehle vom Controller an den KFOB-S schicke; aber nur den Versand des Befehls an KFOB und das ACK vom KFOB zurück. Die Antwort des KFOB auf die Abfrage (wakeupIntverval und Co.) sowie das ACK des Controllers sehe ich danach nicht mehr.
Titel: Antw:ZWave @ culfw
Beitrag von: A.Harrenberg am 13 Dezember 2015, 18:01:05
Hi,

habe mich noch mal durch die Doku vom CC1100 gewühlt, meine Idee mit den verschiedenen (langen) Beams oder Preamblen kann ich nach der Lektüre nicht bestätigen. Die werden vom Chip immer weggefiltert und sind wohl standardmäßig immer 01010101 Folgen (0x55). Das Syncwort soll laut ITU 0xF0 sein.

Im CC sind aber 0xaa und 0x0f eingestellt was invertiert ist. Soetwas war auch in dem Dokument von den beiden erwähnt die mit dem Empfänger das mit der Security untersucht hatten. Da es mit diesen Werten bei mir geht (und mit den invertierten nicht) sollte das so in Ordnung sein.

Allerdings habe ich glaube ich letztes Mal die Parameter nicht richtig angeschaut und da ist immer noch 2-FSK statt GFSK eingeschaltet -> MDMCFG2 0x06 -> 0x16 wäre "richtiger". Interessanterweise funktioniert bei mir beides...

Das Register AGCCTRL2 steuert die Empfindlichkeit ab der Preamble/Sync erkannt werden. Momentaner Wert ist 0x03 was 33dB entspricht.
0x00 wäre 24dB und 0x07 42dB. Die Anleitung schweigt sich aber über die Richtung aus...

Evtl. könnt Ihr ja mal mit 0x00 und 0x07 testen ob das einen Einfluß macht.

Gruß,
Andreas.
Titel: Antw:ZWave @ culfw
Beitrag von: krikan am 13 Dezember 2015, 18:10:11
Zitat von: A.Harrenberg am 13 Dezember 2015, 18:01:05
Evtl. könnt Ihr ja mal mit 0x00 und 0x07 testen ob das einen Einfluß macht.
Hallo Andreas!
Bin grundsätzlich für Tests immer bereit, wenn Du mir verrätst, wie das geht...
Gruß, Christian
Titel: Antw:ZWave @ culfw
Beitrag von: A.Harrenberg am 13 Dezember 2015, 22:02:17
Hi Christian,

zum Testen müsstest Du kompilieren und neu flashen...

Prinzipiell musst Du in rf_zwave.c am Anfang vom Code einfach die Definition für CC1100_AGCCTRL2 von 0x03 mal auf 0x00 oder 0x07 ändern.

Hast Du denn die Möglichkeit das zu kompilieren? Ich kann aber auch mal die beiden HEX-Files erzeugen und posten.
Ich mach das gleich mal (vom anderen Rechner aus...)

Gruß,
Andreas.
Titel: Antw:ZWave @ culfw
Beitrag von: A.Harrenberg am 13 Dezember 2015, 22:11:36
Hi,

hier mal die beiden Versionen (für CUL_V3) mit 0x00 bzw. 0x07 als Parameter für AGCCTRL.

Mir ist aber gerade eingefallen das da ich da auch noch ein Delay im Code verringert habe. Das hatte bei mir keinen EInfluß, habe aber vergessen es zurückzusetzen.

Gruß,
Andreas.
Titel: Antw:ZWave @ culfw
Beitrag von: krikan am 14 Dezember 2015, 22:44:04
Hallo Andreas!
Habe beide Varianten getestet. Sehe keinen Unterschied in den empfangenen Telegrammen. Alles gleich. KFOB-S taucht nicht auf  und Rest sehe ich unverändert.
Gruß, Christian
Titel: Antw:ZWave @ culfw
Beitrag von: A.Harrenberg am 14 Dezember 2015, 23:12:20
Hi,

schade, dann gehen mir aber langsam die Ideen aus...

Aber von anderen 100kBaud Geräten siehst Du alle Nachrichten, oder? Es sind wirklich nur die Fernbedienungen betroffen?

Kannst Du vielleicht mal ein Log posten auf dem ZWDongle, 40kBaud CUL und 100kBaud CUL alle gleichzeitig aktiv sind?

Gruß,
Andreas.
Titel: Antw:ZWave @ culfw
Beitrag von: krikan am 14 Dezember 2015, 23:23:57
Zitat von: A.Harrenberg am 14 Dezember 2015, 23:12:20
Aber von anderen 100kBaud Geräten siehst Du alle Nachrichten, oder? Es sind wirklich nur die Fernbedienungen betroffen?
Für mich sieht es so aus, als wären nur Fernbedienungen betroffen. Von den anderen 100k-Geräten sehe ich regelmäßig Telegramme; denke auch (fast) alle. Ab und an scheint etwas nicht empfangen zu werden, aber eher untergeordnet.

ZitatKannst Du vielleicht mal ein Log posten auf dem ZWDongle, 40kBaud CUL und 100kBaud CUL alle gleichzeitig aktiv sind?
Mache ich, aber bitte etwas Geduld bis morgen.
Titel: Antw:ZWave @ culfw
Beitrag von: A.Harrenberg am 15 Dezember 2015, 07:34:09
Hi Christian,

keine Eile, ich habe hier ja auch noch das Danalock zu stehen... Dafür fehlen noch 5 Befehlsklassen in FHEM... Gibt also genügend zu tun ,-)

Du hast nicht zufällig Informationen zu "NETWORK_SCHEDULE 0x53"? Scheint bei OZW auch nicht implementiert zu sein ,-(

Gruß,
Andreas.
Titel: Antw:ZWave @ culfw
Beitrag von: krikan am 15 Dezember 2015, 07:46:30
Führe mal ein Firmwareupdate für den Deinen Multisensor 6 durch.
Titel: Antw:ZWave @ culfw
Beitrag von: A.Harrenberg am 15 Dezember 2015, 07:55:00
Hi Christian,

danke für den Tip, muss mir das mal genauer anschauen, sieht vielversprechend aus. ,-)

Gruß,
Andreas.
Titel: Antw:ZWave @ culfw
Beitrag von: rudolfkoenig am 23 Dezember 2015, 17:58:23
Ich versuche die Knoepfe meiner Fernbedienung (ZWave.me) mit ZWCUL zu empfangen, und ich brauche Psychologen.

Die Fernbedienung ist mit dem Goodway Dongle gepaart, der ja nur 40k (und 9.6k?) koennen soll. Die Fernbedienung wird als "sleeping frequentListening:0 beaming:16 routing 40kBaud Vers:4 Security:0" von nodeInfo gemeldet. Ich kann mit dem ZWCUL perfekt ein "get remo battery" protokollieren, und auch zuverlaessig(!) die Tasten 1-on und 1-off. Aber weder 1-Status (die mittlere) noch irgendeine der anderen 10 on/off/status tasten. Der Goodway empfaengt dagegen alles. Alle Tasten sind identisch konfiguriert nach meinem Fernbedienungs-HOWTO.

Habt ihr irgendeine Idee, wieso ich nicht alle Tasten mit ZWCUL empfange?
Titel: Antw:ZWave @ culfw
Beitrag von: A.Harrenberg am 23 Dezember 2015, 18:13:21
Hi Rudi,
Zitat von: rudolfkoenig am 23 Dezember 2015, 17:58:23
Ich versuche die Knoepfe meiner Fernbedienung (ZWave.me) mit ZWCUL zu empfangen, und ich brauche Psychologen.
wie wäre es mit Feng-Shui oder auspendeln? :-)

Zitat von: rudolfkoenig am 23 Dezember 2015, 17:58:23
Die Fernbedienung ist mit dem Goodway Dongle gepaart, der ja nur 40k (und 9.6k?) koennen soll. Die Fernbedienung wird als "sleeping frequentListening:0 beaming:16 routing 40kBaud Vers:4 Security:0" von nodeInfo gemeldet. Ich kann mit dem ZWCUL perfekt ein "get remo battery" protokollieren, und auch zuverlaessig(!) die Tasten 1-on und 1-off. Aber weder 1-Status (die mittlere) noch irgendeine der anderen 10 on/off/status tasten. Der Goodway empfaengt dagegen alles. Alle Tasten sind identisch konfiguriert nach meinem Fernbedienungs-HOWTO.

Habt ihr irgendeine Idee, wieso ich nicht alle Tasten mit ZWCUL empfange?
Nee. Leider nicht, ich hatte mir das schon so etliche Gedanken gemacht als Ihr gemeldet habt das ihr von der Fernbedienung mit 100kBaud nichts empfangt. Das jetzt einige Tasten zuverlässig kommen, andere aber gar nicht macht die Sache nicht gerade eindeutiger, eher mysteriöser...

Was mich an den Einstellungen für den CC stutzig macht ist die invertierung der Preambel und des Syncwortes, das stand aber auch so in dem Dokument von den beiden die das mit der Security untersucht haben.

Ich bin mir auch nicht ganz so sicher was die Frequenzen angeht. Sind die angegegeben Frequenzen jeweils die mittlere und die "Deviation" ist symetrisch (so verstehe ich es) oder ist die Angabe vielleicht doch eine Grundfrequenz? Da die Bandbreite aber mit 300 bzw. 400 kHz recht großzügig ist, sollte das keinen Unterschied machen, der CC passt sich ja angeblich etwas an die Frequenz an.

Aber noch mal, nee, keine wirkliche Idee...

Frohes Fest schon mal und nicht zu viel grübeln,
Andreas.
Titel: Antw:ZWave @ culfw
Beitrag von: krikan am 23 Dezember 2015, 19:08:49
Zitat von: rudolfkoenig am 23 Dezember 2015, 17:58:23
Habt ihr irgendeine Idee, wieso ich nicht alle Tasten mit ZWCUL empfange?
Sorry, auch von mir nur Ideenlosigkeit.
Meine obigen Sniff-Versuche zum KFOB-S habe ich noch mal länger probiert und sehe eigenlich nichts. Ab und an taucht mal ein großes Telegramm auf, das ich als kaputt deklarieren würde und auch kein System erkenne. Irgendetwas muss bei den Fernbedienungen eben anders sein.  >:(

Btw: nodeInfo enthält noch Macken bei "beaming" und vermutlich auch "frequentListing". Ich probiere seit 1 Woche immer wieder das Schema zu erkennen, bin aber zu blöd, obwohl ich es erkennen sollte: Habe Rohtelegramm, Auswertung aus AEOTEC Updateprogramm und Angaben zu den Bitmustern. Daraus könnte man auch auf 100k schließen. Probiere noch mal und stelle es sonst in einem separaten Thread ein.
Titel: Antw:ZWave @ culfw
Beitrag von: rudolfkoenig am 23 Dezember 2015, 20:42:49
Habe an ZWCUL.pm @ "normalmodus" (also mit gesetzten homeId) weitergebaut:
- gemeldetes ack wird jetzt auch akzeptiert / keine sinnlose Meldung 10 Sekunden nach set.
- get funktioniert jetzt.
Ein "set as6 versionClassRequest" laeuft mit 16 Sub-Sets problemlos in ca 1.5 Sekunden durch.

ZWCUL TODO
#   implement resend in firmware
#   fix remotes
#   implement inclusion/exclusion
#   implement neighborUpdate: 010404010c0001 010604000c0040 010700 0105
#   implement static routing
#   implement/understand explorer frames
#   check security

Wo koennten wir Info zu der neighborupdate Klasse (01...) bekommen?

Sollen wir Multicast implementieren? Vorteil: viele Geraete auf einmal schalten. Nachteil: kein Ack und kein Routing. Wird Multicast von einem der anderen ZWave-Systemen implementiert? Wie koennte der Syntax in FHEM dafuer ausschauen?

Hat jemand eine Ahnung, wozu man im AeonSS6 die CLOCK Klasse sinnvoll nutzen koennte?
Habt ihr irgendwo in ZWave was aehnliches zu den FS20/Homematic on-for-timer gesehen?
Titel: Antw:ZWave @ culfw
Beitrag von: krikan am 23 Dezember 2015, 21:08:32
Zitat von: rudolfkoenig am 23 Dezember 2015, 20:42:49
Wo koennten wir Info zu der neighborupdate Klasse (01...) bekommen?
Bist Du sicher, dass das neigborupdate ist? Der AEOTEC-Updater deklariert das als nodeInfo, wenn ich es korrekt verstehe.

ZitatSollen wir Multicast implementieren? Vorteil: viele Geraete auf einmal schalten. Nachteil: kein Ack und kein Routing.
Persönlich sehe ich keinen Vorteil/Einsatzzweck für mich. Aber für den Einblick in Kommunikation ist es sicher nicht schlecht; Explorer Frames sollen laut ozw im Grunde Multicast-Nachrichten sein; das konnte ich bisher aber so nicht erkennen.
Zitat
Wird Multicast von einem der anderen ZWave-Systemen implementiert?
In ozw mWn nicht. Bei Zway finde ich nichts dazu.
Zitat
Habt ihr irgendwo in ZWave was aehnliches zu den FS20/Homematic on-for-timer gesehen?
Du meinst, dass das Endgerät den Timer selbst hat und ausführt? Nein. Evtl. ähnliches über MULTILEVEL SWITCH (Level Change).
Titel: Antw:ZWave @ culfw
Beitrag von: rudolfkoenig am 23 Dezember 2015, 21:23:03
ZitatBist Du sicher, dass das neigborupdate ist?
Na wie wir sie nennen, ist mir egal, ich habe halt die im Kommentar gespeicherten Nachrichten bei einem neighborUpdate haufenweise gesehen. Und sonst keine Nachrichten mit einer anderen Klasse.

Ich wuesste auch gerne, wer meinem Sensor gesagt hat, dass er 2-mal um die Ecke routen soll, bzw. wie ich das wiederum korrigiere. Gehe ich richtig in der Annahme, dass im ZWDongle ausser der neighborList keine anderen Daten da sind? Wie sucht er die optimale Routing-Strecke aus?

ZitatEvtl. ähnliches über MULTILEVEL SWITCH (Level Change).
Stimmt, ist leider begrenzt auf 2 Stunden. Ich muss mal damit rumspielen, bin gespannt was ein Zwischenstecker aus dim-Kommandos macht.
Titel: Antw:ZWave @ culfw
Beitrag von: krikan am 23 Dezember 2015, 21:39:10
Zitat von: rudolfkoenig am 23 Dezember 2015, 21:23:03
Ich wuesste auch gerne, wer meinem Sensor gesagt hat, dass er 2-mal um die Ecke routen soll, bzw. wie ich das wiederum korrigiere.
Das begreife ich eben auch nicht. Bei mir gehen die Routen fast immer über die Sirene, obwohl der direkte Weg viel kürzer wäre. Sirene ist 100k wie Controller während restliche Router und Enddevice 40k. Korrektur ?? Auch x-Mal neigborUpdate führen zu keiner Änderung.

ZitatGehe ich richtig in der Annahme, dass im ZWDongle ausser der neighborList keine anderen Daten da sind? Wie sucht er die optimale Routing-Strecke aus?
Zu der Annahme tendiere ich mittlerweile auch, aber keine Idee wie das optimale Routing läuft. Habe dazu noch nirgendwo etwas Erhellendes gefunden.

Im Endeffekt: Auch keine richtige Ahnung mangels vernünftiger Doku (AEOTEC Updater spricht bei Class 01 auch über ein unbekanntes Dokument SDS10264-2 ...)
Titel: Antw:ZWave @ culfw
Beitrag von: rudolfkoenig am 27 Dezember 2015, 13:57:19
Habe culfw/ZWCUL angepasst, damit 100k besser funktioniert: ich kann jetzt auch auf 100k mehrere "set as6 versionClassRequest" (also 16 get Abfragen direkt hintereinander) ohne Probleme absetzen. 40k funktioniert auch noch. Ich habe bwidth bei 40k auf 325k gesetzt, und wir senden "nur" 12 preambel bytes, wie in ZAD12837-1 bzw. ITU-G.9959 beschrieben. Bei 100k muessten wir 40 preambel bytes senden, das CC1101 kan aber nur maximal 24, scheint trotzdem zu funktionieren. Modulation habe ich bei 100k auf GFSK gesetzt.

Die KFOB kann ich auf 100k jetzt empfangen, die zwave.me Fernbedienung ist weiterhin komisch (nur die erste Taste ist mit dem CUL empfangbar).

Weiterhin wird der Checksum ab sofort im culfw immer geprueft: sowohl bei 40k als auch bei 100k, und auch im monitor mode.

Mein Problem ist 9.6k (zu aktivieren mit zm9/zr9): da kann ich nicht empfangen, senden habe ich gar nicht probiert. Ist deswegen ein Problem, weil Inclusion/Exclusion auf 9.6k laeuft, hatte naemlich weder auf 40k noch auf 100k irgendetwas gesehen, weder beim Goodway, noch beim ZWave.
Falls jemand (Andreas?) meine CC1101-Parameter fuer 9.6k pruefen koennte, waere ich dankbar.

Wenn ich auf dem as6 den Knopf druecke, dann kann ich auf dem ZWCUL nichts empfangen, der zme Dongle meldet ZW_APPLICATION_UPDATE (das ist doch ein NIF?), ich vermute, der as6 sendet das auf 9.6k. Der Dongle mit "set zme sendNIF 1" sendet auf 40k und "gleichzeitig" auf 100k, vermutlich auch auf 9.6k, das sehe ich aber nicht.
Titel: Antw:ZWave @ culfw
Beitrag von: rudolfkoenig am 27 Dezember 2015, 14:58:21
Habe bWidth bei 40k auf 101k zurueckgesetzt, da der Empfang mit 325 merkbar schlechter geworden ist.
Weiterhin kann man ab sofort mit CwAADD Register AA in der CC1101 mit DD direkt beschreiben: beim Experimentieren mit den Registern muss man nicht staendig neu Flashen.
Titel: Antw:ZWave @ culfw
Beitrag von: A.Harrenberg am 28 Dezember 2015, 22:11:59
Hi Rudi,
Zitat von: rudolfkoenig am 27 Dezember 2015, 13:57:19
Habe culfw/ZWCUL angepasst, damit 100k besser funktioniert
[...]
Die KFOB kann ich auf 100k jetzt empfangen
was hast Du denn angepasst?

Zitat von: rudolfkoenig am 27 Dezember 2015, 13:57:19
Mein Problem ist 9.6k (zu aktivieren mit zm9/zr9): da kann ich nicht empfangen, senden habe ich gar nicht probiert. Ist deswegen ein Problem, weil Inclusion/Exclusion auf 9.6k laeuft, hatte naemlich weder auf 40k noch auf 100k irgendetwas gesehen, weder beim Goodway, noch beim ZWave.
Falls jemand (Andreas?) meine CC1101-Parameter fuer 9.6k pruefen koennte, waere ich dankbar.
Hmm, ich habe jetzt heute abend schon so einige Variationen durchprobiert, komme aber auch an keine Nachrichten...

Laut dem Dokument von Fouladi/Ghanoun ist bei 9.6 GFSK aktiv...
Mich wundert weiterhin der Kommentar in diesem Dokument das ALLE Bits im 40k-Frame negiert sind. Die Preambel/Sync Werte für 40k/100k sind ja ggü. den Werten in der ITU auch invertiert.

Habe sowohl mal mit GFSK als auch mit den normalen Werten für die Preambel/Synce rumprobiert und nichts empfangen können.
An den übrigen Parametern habe ich jetzt erst mal nichts auffälliges gesehen, die scheinen soweit in Ordnung zu sein.

Muss mal sehen ob ich morgen noch mal Zeit dafür finde. Der "Cw"-Befehl hilft da beim ausprobieren schon mal weiter ,-)

Gruß,
Andreas.
Titel: Antw:ZWave @ culfw
Beitrag von: rudolfkoenig am 29 Dezember 2015, 09:33:54
Zitatwas hast Du denn angepasst?
Die GFSK Modulierung. Und ich habe die Drahtantenne auf dem CUL (zu kurz/duenn/schlecht aufgeloetet) ausgetauscht.

ZitatLaut dem Dokument von Fouladi/Ghanoun ist bei 9.6 GFSK aktiv...
Ich sehe im Dokument FSK. Ich habe die beiden vor eine Woche angeschrieben, ohne Antwort bisher.
Falls demnaechst kein Wunder passiert, dann versuche ich das Senden@9.6k mit SlowRF zu protokollieren.
Titel: Antw:ZWave @ culfw
Beitrag von: A.Harrenberg am 29 Dezember 2015, 10:04:33
Hi Rudi,
Zitat von: rudolfkoenig am 29 Dezember 2015, 09:33:54
Die GFSK Modulierung. Und ich habe die Drahtantenne auf dem CUL (zu kurz/duenn/schlecht aufgeloetet) ausgetauscht.
??? Das war doch schon GFSK oder habe ich mich da so vertan?

Zu kurze Antenne? Ich habe meine nicht nachgemessen, da sich mein Testequipment momentan aber im Umkreis von 1m um die Dongles und den CUL befindet ist Empfangsleistung bei mir kein Problem...

Zitat von: rudolfkoenig am 29 Dezember 2015, 09:33:54
Ich sehe im Dokument FSK. Ich habe die beiden vor eine Woche angeschrieben, ohne Antwort bisher.
Falls demnaechst kein Wunder passiert, dann versuche ich das Senden@9.6k mit SlowRF zu protokollieren.
Im Text unter der Tabelle steht das sie Unterschiede zu den offiziellen Angaben festgestellt haben, unter anderem steht da dann GSFK für 9.6 kBaud und das ALLE Bits für 40k invertiert sein sollen...

Hattest Du nicht schon mal die Register von denen geschickt bekommen oder habe ich da was falsch abgespeichert?

Gruß,
Andreas.
Titel: Antw:ZWave @ culfw
Beitrag von: rudolfkoenig am 29 Dezember 2015, 11:29:37
Alle bisherigen Drahtantennen von busware hatten eine mAn ungenaue Laenge, und ich meine mit 1.5mm2 Draht bessere Ergebnisse zu haben als mit einem Duennen. Aber das wird off-topic.

ZitatALLE Bits für 40k invertiert sein sollen
Danke, das muss man verinnerlichen: _beide_ SYNC Parameter muessen invertiert sein. Jetzt funktioniert auch 9.6k, jedenfalls Empfang, Senden habe ich noch nicht getestet. Habe die Aenderungen  eingecheckt. Die beiden haben mir nur die Parameter fuer 40k gegeben. So schaut der NIF der as6 aus:
2015.12.29 10:42:48.866 5: xxxxxxxx S:36 F:01 f:0 SN:a L:22 T:00 P:fefe2c63feeffea1dad9cc8fd8cd7e7aa68d79858c10a57d C:e9
2015.12.29 10:42:48.866 5:    F: singleCast


Der Raetsel meiner zwave.me Fernbedienung wandelt sich: sie schickt auf 9600 an irgendwelche komische Adresse mit "falschen" checkSum merkwuerdige Daten. Der Sequence-Number aendert sich im aufeinanderfolgenden Paketen auch nicht. T: im ACK kann ich auch nicht erklaeren, immerhin kommt das mit "richtigen" checkSum.
2015.12.29 11:09:01.734 5: xxxxxxxx S:16 F:41 f:0 SN:1 L:11 T:fe P:9ff2fffddffeff C:92
2015.12.29 11:09:01.734 5:    F: singleCast ackReq
2015.12.29 11:09:01.754 5: xxxxxxxx S:01 F:03 f:0 SN:1 L:0a T:e9 P: C:85
2015.12.29 11:09:01.754 5:    F: ack
Der Goodway meldet diese Daten als "07600d0002200100" also MULTI_CHANNEL CMD_ENCAP (600d), EndPoint 02, basicSet:00 (200100). Nein, Verschluesselung ist nicht aktiviert. Ergebnis: vorher hatte ich ein Problem (ich empfange nichts), jetzt 5 Fragen: Wie rechnet man den Checksum (92 ist nach bisheriger Methode falsch), wer ist der Addressat (fe?), wieso aendert sich SN nicht (bleibt 1), wie dekodiert man die Daten, wieso geht der Ack an e9.

Hat jemand was Aufhellendes?
Titel: Antw:ZWave @ culfw
Beitrag von: A.Harrenberg am 29 Dezember 2015, 11:45:18
Hi Rudi,

hmm, ich habe gestern selbstverständlich mit den umgedrehten Syncparametern (aa/55 und f0/0f) probiert, sogar in allen 4 möglichen Kombinationen und kein einziges Nachrichtenpaket empfangen. Aber schön wenn es bei Dir jetzt geht.

Zu dem Rest kann ich jetzt auch nicht viel sagen (bin ja eigentlich auch auf der Arbeit...), nur ein paar wilde Ideen...

Mir fällt auf das Antwort an e9 geht, das wäre aber oberhalb der maximalen Node-Anzahl (ebenso wie das fe), könnte das evtl. eine besondere Form eines Broadcasts sein?

Thema Checsum: Ich habe sowas im Hinterkopf das im ITU was gestanden hätte das bei 9.6 keine CS gebildet wird??? Jedenfalls war da eine Besonderheit.

Gruß,
Andreas.
Titel: Antw:ZWave @ culfw
Beitrag von: rudolfkoenig am 29 Dezember 2015, 12:00:45
Zitatkein einziges Nachrichtenpaket empfangen.
Ich gehe davon aus, dass Du "^ 0xff" beim Emfang nicht deaktiviert hast.
Apropos... Ich leider auch nur die Haelfte. Und schon erklaert sich der Raetsel der "komischen" zwave.me Pakete. Die Fernbedienung sendet ganz normal auf 9600, alle bits/bytes sind verstaendlich und im Klartext.

Danke fuer die psychologische Beratung :)
Titel: Antw:ZWave @ culfw
Beitrag von: A.Harrenberg am 29 Dezember 2015, 12:09:16
Hi Rudi,
Zitat von: rudolfkoenig am 29 Dezember 2015, 12:00:45
Ich gehe davon aus, dass Du "^ 0xff" beim Emfang nicht deaktiviert hast.
nein, hatte ich nicht, ich hatte nach so etwas gesucht, aber nicht gefunden... ,-(

Schön wenn es jetzt funktioniert und die Pakete jetzt auch "verständlicher" sind ,-)

Mahlzeit,
Andreas.
Titel: Antw:ZWave @ culfw
Beitrag von: krikan am 29 Dezember 2015, 15:06:55
Klasse, dass jetzt alle Datenraten funktionieren.

Könnt ihr mir bitte Nachhilfe geben bzw. mein Verständnis kontrollieren:
9.6, 40k und 100k sind in einem Z-Wave-Netz immer gleichzeitig aktiv. Damit braucht man zum vollständigen Sniffen des Funkverkehrs im Netz 3 Culs gleichzeitig.
Ein Cul kann dynamisch zwischen den Datenraten umgeschaltet werden. Dadurch wäre beim Senden für verschiedene Datenraten ein Cul genug; es würden nur nicht alle Telegramme empfangen, wenn die gerade am Cul eingestellt Datenrate nicht passt.
Z-Wave-Sticks können hingegen alle 3 Datenraten gleichzeitig senden/empfangen.

Danke und Gruß, Christian
Titel: Antw:ZWave @ culfw
Beitrag von: A.Harrenberg am 29 Dezember 2015, 15:35:50
Hi Christian,

ja, so ist auch mein Verständnis. Mir ist nur nicht klar wie die ZWave-Dongles das mit den unterschiedlichen Datenraten machen. Aufgrund der verschiedenen Frequenz für 100kBaud gehe ich davon aus das in so einem ZWave-Chip mehrere Empfänger parallel arbeiten. Keine Ahnung ob es solche CC-Chps mit mehreren unabhängig programmierbaren Empfängern gibt. Die müssten dann aber auch unabhängige Emfangsbuffer haben...

Oder man muss mal ausrechnen wie schnell so ein Chip die Frequenz und die Datenrate "umschaltet", wie lange er braucht um eine Preamble zu erkennen und wie viele Preamblen in dieser zeit "vorbei" rauschen. Vielleicht würde das zeitlich ja sogar ausreichen...

Gruß,
Andreas.
Titel: Antw:ZWave @ culfw
Beitrag von: rudolfkoenig am 29 Dezember 2015, 15:44:02
@Christian: Alles richtig, soweit ich es verstanden habe.
Mein Ziel ist das ZWDongle mit ZWCUL zu ersetzen. Dabei wuerde ich fuer die Inklusion auf 9600 schalten, und danach alle Geraete auf 40k oder 100k "zwingen". Bin noch nicht sicher, dass das so klappen wird. Wenn Andreas den gleichzeitigen Empfang hinkriegen wuerde, dann waere alles viel einfacher. Ich bin aber extrem skeptisch.
Titel: Antw:ZWave @ culfw
Beitrag von: A.Harrenberg am 29 Dezember 2015, 16:09:31
Hi,

ich glaube auch nicht wirklich das man mit dem "einfachen" CC1100 einen gleichzeitigen Empfang sicherstellen kann. Ich muss mal rechnen wie lange so eine komplette Preambel in den verschiedenen Datenraten dauert, und dann mal in den Datenblättern zum CC wühlen was da zum Thema Umschaltzeiten steht.

Das kann ja nur funktionieren wenn man in der kürzesten Zeit der drei Datenraten alle drei Modi umschalten kann UND auch noch die Preambel sicher erkennen kann. Dazu müsste es dann aber auch ein Ausgangssignal oder Register geben das aktiv wird sobal diese Preambel erkannt wird, daran kann ich mich jetzt auch Anhieb nicht erinnern.

Ansonsten müssen wir uns nach "besserer" Hardware umsehen, wie gesagt, keine Ahnung ob es Chips aus dieser Reihe gibt die das in HW können.

Gruß,
Andreas.
Titel: Antw:ZWave @ culfw
Beitrag von: A.Harrenberg am 29 Dezember 2015, 17:55:26
Hi Rudi,
Zitat von: A.Harrenberg am 29 Dezember 2015, 11:45:18
Thema Checsum: Ich habe sowas im Hinterkopf das im ITU was gestanden hätte das bei 9.6 keine CS gebildet wird??? Jedenfalls war da eine Besonderheit.
ITU Dokument von 2015:
S. 46 -> 8bit CS für Datenrate R1, R2
S. 47 -> 16bit CRC für Datenrate R3

Ich hatte das EOF im Kopf, und das wird NUR bei R1 gesendet (hat dann aber nichts mehr mit dem Protokoll zu tun).

Also alles in Ordnung ,-)

Gruß,
Andreas.
Titel: Antw:ZWave @ culfw
Beitrag von: A.Harrenberg am 29 Dezember 2015, 22:50:22
Hi,

also mal ein "kurzer" Stand zu dem was ich bzgl. Mehrfrequenzmöglichkeit rausgebkommen habe:

9.6kBaud -> 19.2 kBit/s -> mind. 10 Preambeln -> mind. 80 bit -> mind. 8.3 ms
40kBaud -> 40 kBit/s -> mind. 10 Preambeln -> mind. 80 bit -> mind. 2 ms
100kBaud -> 100 kBit/s -> mind. 40 Preambeln -> mind. 320 bit -> mind. 3.2 ms
           CC1101 kann nur 24 Preambeln senden -> max.  192 bit -> max. 1.92 ms

D.h. ein "Scannen" aller drei Datenraten darf maximal 1.5 ms dauern damit es überhaupt funktionieren kann.

Ein Umschalten "Idle to RX with calibration" benötigt bereits ~800 us "Transition time", das wäre schon mal deutlich zu lange, damit würde ja das reine Umschalten für drei Datenraten bereits mehr als die verfügbare Zeit dauern...
Es gibt aber anscheinend wohl die Möglichkeit diese Kalibrierwerte auszulesen und dann z.B. im CUL abzulegen und beim Umschalten keine Kalibrierung durchzuführen sondern diese Werte vorher zurückzuschreiben. Dann kommt man in die Größenordnung von ~ 150 us. Schon besser...

Die Frage wäre dann noch wie man die Preambel erkennen kann... Der CC hat da einiges zu bieten, allerdings verstehe ich leider auch nicht alles davon, bzw. kann nicht sagen ob sich das sinnvoll verwenden lassen würde. Die Preambel besteht aus 010101... bzw. 101010... Folgen, je nach Datenrate, jedenfalls immer schön abwechselnd.

Im CC gibt es einen Zähler den man aktivieren kann, dieser erhöht bei jedem Wechsel der Bits den Zähler um 1 und verringert ihn um 8 falls zwei gleiche Bits hintereinander kommen. Erreicht der Wert eine Schwelle, kann diese zur "Freigabe" der Erkennung des Syncwortes genutzt werden. Diesen Zähler könnte man nun evtl. auch nutzen, aber zum einen scheint sich der nur beim Wechsel von Idle->RX und am Paketende zu resetten, zum anderen dauert es in 9.6 Modus zu lange... Wenn man von den 10 Preambeln wenigstens 2 als "Freigabe" nutzen möchte, müsste man im 9.6 Modus ja bereits ~1.6ms warten -> zu langsam...

Empfangsstärke RSSI, hierzu finden sich in der DN505 (Design Note 505) Angaben zu den Zeiten nach denen man ersten Wert erwarten darf, der sich dann allerdings auch noch weiter ändern kann falls der Empfänger sich in der Verstärkung noch anpasst. Die Werte sind abhänging von Datenrate und Bandbreite, die Beispielwerte zeigen aber schon mal die Größenordnung:

Mindestzeit für 1 Update bei     1 kBaud ~280 us, falls der AGC eingeregelt ist ~140 us
Mindestzeit für 1 Update bei   38 kBaud ~160 us, falls der AGC eingeregelt ist ~  80 us
Mindestzeit für 1 Update bei 250 kBaud ~  40 us, falls der AGC eingeregelt ist ~    8 us

D.h. auch hier wird es eng, falls sich der Wert erst nach 2-3 Updates eingependelt haben sollte.

Also Gedankenspiel:
150 us : Ändern der Frequenz/Datenrate auf 9.6K mit vorher gespeicherten Kalibrierwerten
400 us : Stabilisierung RSSI für 9.6k
150 us : Ändern der Frequenz/Datenrate auf 40K mit vorher gespeicherten Kalibrierwerten
300 us : Stabilisierung RSSI für 40k
150 us : Ändern der Frequenz/Datenrate auf 100K mit vorher gespeicherten Kalibrierwerten
100 us : Stabilisierung RSSI für 10k

1250 us = 1.25 ms gesamtzeit für einen Durchlauf, dazu kommen natürlich noch die Programmlaufzeiten, das sollten aber nur wenige us sein, oder verschätze ich mich hier?
Evtl. wird das umschalten aber auch "schneller" da nur zwischen zwei Frequenzen umgeschaltet wird. Die Änderung der Datenrate/Bandbreite dürfte aber dennoch EInfluß auf die RSSI Werte haben.

Soweit zur Theorie... Aber wer könnte dass in die Praxis umsetzen? Momentan sehe ich mich weder zeitlich noch fachlich dazu in der Lage...

Gruß,
Andreas.
Titel: Antw:ZWave @ culfw
Beitrag von: rudolfkoenig am 30 Dezember 2015, 15:01:56
Dann hier mal ein "einfaches" Problem: Senden@9600 funktioniert nicht. Ich habe es mit G-FSK und 2-FSK versucht. Im ITU Dokument steht was vom EOF bei R1, was als "manchester code violations" besteht. Wie sendet man sowas? Ich habe versucht ein Byte (0x00) mehr zu senden, und beim Senden dieses Bytes die Codierung von Manchester auf NRZ zu stellen. Ohne Erfolg. Seufz.

Uebrigens bei der Inclusion wird (wenn ich es richtig sehe) "nur" mit Hilfe von 0103 nodeId und homeId gesetzt. Und bei der Exclusion werden mit dem gleichen Befehl die beiden Werte auf 0 gesetzt. Waehrend beider Vorgaenge sendet der Controller alle 2 Sekunden 010801, keine Ahnung, wozu. Alles auf 9600.
Titel: Antw:ZWave @ culfw
Beitrag von: krikan am 30 Dezember 2015, 15:15:36
Zitat von: rudolfkoenig am 30 Dezember 2015, 15:01:56
Uebrigens bei der Inclusion wird (wenn ich es richtig sehe) "nur" mit Hilfe von 0103 nodeId und homeId gesetzt. Und bei der Exclusion werden mit dem gleichen Befehl die beiden Werte auf 0 gesetzt. Waehrend beider Vorgaenge sendet der Controller alle 2 Sekunden 010801, keine Ahnung, wozu. Alles auf 9600.
Laut meinem derzeitigen Lieblingstool (Aeotec Updater):
01= ZWAVE_CMD_CLASS (Z-wave protocol Command Class)
Befehl 03 = ASSIGN_ID
Befehl 08 = TRANSFER_PRESENTATION (????)

Beim Rest auf Andreas hoffen...
Titel: Antw:ZWave @ culfw
Beitrag von: A.Harrenberg am 30 Dezember 2015, 15:26:15
Hi Rudi,
Zitat von: rudolfkoenig am 30 Dezember 2015, 15:01:56
Dann hier mal ein "einfaches" Problem: Senden@9600 funktioniert nicht. Ich habe es mit G-FSK und 2-FSK versucht. Im ITU Dokument steht was vom EOF bei R1, was als "manchester code violations" besteht. Wie sendet man sowas? Ich habe versucht ein Byte (0x00) mehr zu senden, und beim Senden dieses Bytes die Codierung von Manchester auf NRZ zu stellen. Ohne Erfolg. Seufz.
oh, das ist aber wirklich ein "einfaches" Problem...
Wie hast Du denn beim Senden des Bytes Manchester ausgeschaltet? Du schreibst doch nur Bytes in den FIFO und "weisst" gar nicht genau wann das Byte dran ist... Außerdem bin ich nicht wirklich sicher ob sich das theoretisch überhaupt während einer Übertragung umschalten lässt...
Ich schau noch mal in die Doku von dem CC rein, aber so aus dem Gedächtnis ist mir da jetzt nichts bewusst was der CC automatisch anhängen könnte (außer einer CS).
Ich überlege gerade ob es möglich wäre die Daten selbst auf Manchester zu codieren und dann mit NRZ zu senden, dann sollte auch die "violation" möglich sein.

Tja, scheint doch mehr ein "echtes" Problem zu sein...

Gruß,
Andreas.
Titel: Antw:ZWave @ culfw
Beitrag von: rudolfkoenig am 30 Dezember 2015, 15:58:28
ZitatLaut meinem derzeitigen Lieblingstool (Aeotec Updater):
Ist ab sofort auch mein Lieblingstool :)

ZitatWie hast Du denn beim Senden des Bytes Manchester ausgeschaltet?
FIFOTHR auf 1, PKTLEN eins mehr als noetig, Daten wie bisher schreiben, danach Bit pollen bis 0, dann Manchaster aus, und 0 senden. Ist eingecheckt. Alernative ist noch SlowRF. Wuerg.
Titel: Antw:ZWave @ culfw
Beitrag von: A.Harrenberg am 30 Dezember 2015, 16:06:42
Hi,

das Kodieren auf Manchester und senden mit NRZ dürfte auch nicht funktionieren, da dann ja Preambel und Sync im falschen Format gesendet werden...

Ich bin aber extrem skeptisch was das umschalten der Modulation innerhalb des sendens angeht.
Könntest Du das testweise mal (ohne zusätliches byte) für 40K machen und sehen ob dann das Senden nicht mehr geht? Dann wäre es zumindest ein Hinweis das die Umschaltung funktioniert.

Da Manchester aber auf einer "clock" beruht dürfte das extrem empfindlich sein was das Timing beim Umschalten angeht.

Was macht den SlowRF (anders)? Und wieso "würg"?
Gruß,
Andreas.
Titel: Antw:ZWave @ culfw
Beitrag von: rudolfkoenig am 30 Dezember 2015, 16:09:17
Mit Slowrf darf man die Flanken einzeln mit dem Atmel setzen. So laeuft FS20 & co.
Titel: Antw:ZWave @ culfw
Beitrag von: A.Harrenberg am 30 Dezember 2015, 18:17:59
Hi Rudi,
Zitat von: rudolfkoenig am 30 Dezember 2015, 16:09:17
Mit Slowrf darf man die Flanken einzeln mit dem Atmel setzen. So laeuft FS20 & co.
ist wohl eher "muss" als "darf"...

Mein erneuter kurzer Blick in das Manual vom CC hat leider nichts neues erbracht. Der CC kann höchstens eine 16bit CRC beim Senden anhängen, eine Art EOF gibt es da nicht.
So langsam geht das aber schon ganz schön ins "Eingemachte" von dem CC. Als nächstes kann man sich dann wahrscheinlich mal mit der Statemachine von dem Ding befassen...

Noch mal zu dem Senden von 0x00 ohne Manchester, es soll ja ein Pattern ohne Transitions erzeugt werden, dazu ist mMn nötig das man das letzte Bit der Übertragung 8 mal wiederholt, also entweder 0x00 oder 0xff, je nach letztem Bit.

Was das Timing des Umschaltens angeht schaue ich noch mal ob es Angaben über den Zeitversatz zwischen FIFO und Senden angeht. Ich meine nämlich da etwas gelesen zu haben das beim Empfangen da ein Versatz von bis zu 9 Bytes auftritt, wobei ich da momentan nicht wüsste woher diese große Verzögerung kommen soll und wo da noch ein interner FIFO wäre...

Gruß,
Andreas.
Titel: Antw:ZWave @ culfw
Beitrag von: A.Harrenberg am 30 Dezember 2015, 18:35:21
Hi,

also der "Versatz" (Latenz) den ich meinte gilt anscheinend nur für den "synchronous serial mode", der wird aber nicht genutzt, sondern FIFO. Und der Versatz wäre auch nur 9 BIT (nicht Byte) beim Empfangen und 8 bit beim Senden.

Gruß,
Andreas.
Titel: Antw:ZWave @ culfw
Beitrag von: A.Harrenberg am 05 Januar 2016, 21:48:26
Hi Rudi,

ein paar Punkte:

- Bist Du mit 9.6k eigentlich schon was weiter gekommen? Meine Geräte senden auch bei "nicht erreichbarkeit" (ausgesteckter Steckdosensschalter) nicht auf 9.6k, ich sehe nur was während der Inklusion.

- Ich hab' jetzt auch ein ZWay zum gegentesten hier, ist aber nur eingeschränkt tauglich... ,-(

- Das DanaLock wird von ZWay als FLIRS erkannt, was auch Sinn macht. Darüber hatte ich mir bisher keine Gedanken gemacht. Momentan ist das Ding an ZWay angelernt, brauchts Du da evtl. mal einen NIF von dem Gerät? Dann könnte ich bei Gelegenheit noch mal in FHEM anlernen (oder mit CUL sniffen?)

Gruß,
Andreas.
Titel: Antw:ZWave @ culfw
Beitrag von: rudolfkoenig am 06 Januar 2016, 07:36:40
FLIRS waere bei mir low Prio (habe keine Geraete, und es ist kompliziert), Senden@9.6k dagegen hoch, sonst kann ein CUL kein vollwaertiger Dongle Ersatz sein. Da die Ideen, die ich habe (Senden in SlowRF implementieren oder Paketmodus per Logic-Analyzer debuggen) aufwendig sind, ruht die Sache erstmal. Falls jemand helfen moechte...
Titel: Antw:ZWave @ culfw
Beitrag von: A.Harrenberg am 06 Januar 2016, 07:57:08
Hi Rudi,

bin mir gar nicht sicher ob FLIRS wirklich besondere Behandlung benötigt, mein Verständnis ist das so ein Ding oft genug aufwacht um einen Beam zu erkennen. Ich werde jedenfalls bei Gelegenheit mal NIF und Inklusion mitschneiden.

Was das 9.6k angeht kann ich demnächst auch mal wieder ein wenig experimentieren. Eine Idee wäre noch beim Senden Preambel/Sync und Manchester auszuschalten, die Manchestercodierung dann in SW zu machen, und das ganze dann inklusive der Preambel, dem Sync, der Payload und der "Code violation" dann "normal" in 19.2 zu senden. Wobei die "Code violation" dann natürlich nicht mit der Manchestercodierung gemacht werden darf.

Ich bin mir aber nicht sicher ob Preambel/Sync auch mit Manchester codiert werden, oder ob die für alle codierungen gleich sind, gehe aber davon aus.

Man bräuchte mal einen Empfänger an dem man das de-modulierte Signal mit einem Scope oder Logic-Analyzer auslesen kann...

Gruß,
Andreas.
Titel: Antw:ZWave @ culfw
Beitrag von: rudolfkoenig am 06 Januar 2016, 08:07:17
Zitatbin mir gar nicht sicher ob FLIRS wirklich besondere Behandlung benötigt
Ich schon, oder ich habe FLIRS nicht verstanden. Da muss man doch lange Beams senden, entweder ununterbrochen oder in Intervallen.Ich will dich aber nicht abhalten.

Zitat
Man bräuchte mal einen Empfänger an dem man das de-modulierte Signal mit einem Scope oder Logic-Analyzer auslesen kann...
Sehe ich auch so. Gibts nicht sowas fuer DVB-T Sitcks? Will keine Unsummen fuer diesen Fall ausgeben. Was Vergleichbares fuer Arme ist culfw mit X18 bzw. culfw/tools/timer.c . Bin nicht sicher, ob es mit 19200 zurechkommt, selbst mit 9600 hat es nie wirklich gut funktioniert.
Titel: Antw:ZWave @ culfw
Beitrag von: A.Harrenberg am 06 Januar 2016, 09:02:38
Hi Rudi,
Zitat von: rudolfkoenig am 06 Januar 2016, 08:07:17
Ich schon, oder ich habe FLIRS nicht verstanden. Da muss man doch lange Beams senden, entweder ununterbrochen oder in Intervallen.Ich will dich aber nicht abhalten.
ich wollte das ja nicht implementieren, 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".

Zitat von: rudolfkoenig am 06 Januar 2016, 08:07:17
Sehe ich auch so. Gibts nicht sowas fuer DVB-T Sitcks? Will keine Unsummen fuer diesen Fall ausgeben. Was Vergleichbares fuer Arme ist culfw mit X18 bzw. culfw/tools/timer.c . Bin nicht sicher, ob es mit 19200 zurechkommt, selbst mit 9600 hat es nie wirklich gut funktioniert.
Ganz so einfach wird das wahrscheinlich nicht sein, da man ja die Frequenzwechsel mitbekommen will...
Erster Schritt aus meiner Sicht ist mal den Empfang auf 19.2 ohne Manchester, Preambel, Sync, RSSI-Schwelle umstellen und dann mal schauen ob da ein Datenpaket drin zu erkennen ist. Dann mal extern Manchester decodieren und schauen ob das wirklich ein Datenpaket war.

Wenn das funktioniert, dann müsste es umgekehrt auch mit dem Senden funktionieren.

Siehst Du denn mit Deinen Geräte Kommunikation auf 9.6k wenn Du z.B. ein Gerät aussteckst/abschirmst oder sonstwie unerreichbar machst? Meine Geräte scheinen alle nur bis auf 40k runter zu gehen und dann aufzuhören, ich habe aber auch alles nur neuere Geräte...

Gruß,
Andreas.
Titel: Antw:ZWave @ culfw
Beitrag von: krikan am 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....
Titel: Antw:ZWave @ culfw
Beitrag von: A.Harrenberg am 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.
Titel: Antw:ZWave @ culfw
Beitrag von: krikan am 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.

Titel: Antw:ZWave @ culfw
Beitrag von: A.Harrenberg am 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.
Titel: Antw:ZWave @ culfw
Beitrag von: A.Harrenberg am 06 Januar 2016, 18:53:22
Hallo Christian,

hier die NodeInfo von dem Danalock, das ist aber 0x41 und nicht 0x42...
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.
Titel: Antw:ZWave @ culfw
Beitrag von: krikan am 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.  ;)
Titel: Antw:ZWave @ culfw
Beitrag von: A.Harrenberg am 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.
Titel: Antw:ZWave @ culfw
Beitrag von: A.Harrenberg am 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.
Titel: Antw:ZWave @ culfw
Beitrag von: A.Harrenberg am 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.
Titel: Antw:ZWave @ culfw
Beitrag von: A.Harrenberg am 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.

Titel: [PATCH] ZWave @ culfw
Beitrag von: A.Harrenberg am 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.
Titel: Antw:ZWave @ culfw
Beitrag von: A.Harrenberg am 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.
Titel: Antw:ZWave @ culfw
Beitrag 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.

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.
Titel: Antw:ZWave @ culfw
Beitrag von: A.Harrenberg am 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.
Titel: Antw:ZWave @ culfw
Beitrag von: rudolfkoenig am 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.
Titel: Antw:ZWave @ culfw
Beitrag von: krikan am 10 Januar 2016, 19:10:12
Zitat von: rudolfkoenig am 10 Januar 2016, 18:54:45
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.
Das baut mich nicht gerade auf. Wenn Du es schon nicht verstehst...

ZitatWenn 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.
Das zway-Log für den UZB1 ist dazu komplett schweigsam; im Gegensatz zu den anderen Befehlen, die sauber dokumentiert/geloggt sind. Zudem hat zme das Thema wohl selbst nicht richtig im Griff. Außerdem ist das bei ZME sowieso proprietär; hattest Du mEn auch angefragt und so beantwortet bekommen (zwave.de-Forum?)

Mir ist aber überhaupt nicht klar, wie ich mit dem derzeitigen Stand schon ein Backup/Umzug meines alten Sticks auf den Cul hinbekomme? Ist das überhaupt schon möglich?. Wenn ich nur mit dem Cul arbeite, verstehe ich es ja halbwegs.
Titel: Antw:ZWave @ culfw
Beitrag von: A.Harrenberg am 10 Januar 2016, 19:22:51
Hi Rudi,
Zitat von: rudolfkoenig am 10 Januar 2016, 18:54:45
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.
meine Theorie dazu ist das es kein Bit für 100k sondern das 40k mit dem "slow" Flag sendet, was ja bedeutet das man mehr kann. Ich habe mir das aber noch nicht richtig angesehen und die Beschreibung war ja eigentlich das es langsamer ist als BEIDE Seiten können, und woher weiß man das (vorher)?

Zitat von: rudolfkoenig am 10 Januar 2016, 18:54:45
Mit einem parallelen Empfang aller Datenraten mit dem CUL rechne ich nicht.
Ich gebe die Hoffnung da noch nicht (ganz) auf...

Zitat von: rudolfkoenig am 10 Januar 2016, 18:54:45
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.
Da mein Testsystem und das Produktivsystem beiden den UZB1 verwenden hätte ich sofortigen Ersatz zur Hand ;-) Falls sich das Backup auch auf den RazBerry übertragen lassen sollte stünde sogar noch ein weiteres System zur Verfügung.
Die Frage ist ja eigentlich was in dem Stick eigentlich gespeichert ist was sich nicht auch wieder aufbauen lässt (mit neighborUpdate, ExplorerFrames, etc.). Welche Node-IDs inkludiert ist ja in der FHEM-config leicht zu finden.

Zitat von: rudolfkoenig am 10 Januar 2016, 18:54:45
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.
Ja, dieses Zuweisen einer Route an einen Node würde mich interessieren, dann könnte ich meinen RFID Leser mal "zwingen" über den Steckdosenschalter zu routen.
(Und meinem anderen Steckdosenschalter mal sagen das er nicht über die Sirene die neben im eingesteckt ist routen muss...)

Zitat von: rudolfkoenig am 10 Januar 2016, 18:54:45
addNodeId kann man zum bequemeren Austausch eines Geraetes verwenden. Oder wenn man eine bestimmte Systematik bei der Nummernvergabe hat. Und zum Experimentieren :)
Äh, heisst das jetzt doch das man einem Gerät nachträglich eine andere ID geben kann?

Zitat von: rudolfkoenig am 10 Januar 2016, 18:54:45
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.
Den NodeInfoBlock muss ich mir auch noch mal genauer ansehen. Da muss ja eigentlich alles drin stehen was für das Netzwerk interessant ist.

Gruß,
Andreas.
Titel: Antw:ZWave @ culfw
Beitrag von: rudolfkoenig am 10 Januar 2016, 19:48:35
ZitatUmzug meines alten Sticks auf den Cul
Das empfehle ich noch nicht, da noch ein paar Features fehlen, siehe TODO in 00_ZWCUL.pm. Ich glaube, dass es keine prinzipiellen Huerden sind, nur Fleissarbeit. Beim Umstieg muss man:
- ein ZWCUL mit der alten homeId spezifizieren.
- falls noetig, routing Information fuer bestimmte Knoten setzen (das ist noch nicht implementiert)
- oder (falls wir das auch implementieren) ein "neighborUpdate" starten.

Voraussetzung ist, das alle Geraete auf der gleichen Frequenz senden. Da ist natuerlich nicht lustig, wenn manche Geraete nur 9600 koennen. Und es kann zu Problemen fuehren, falls man manche Geraete von 100k auf 40k oder andersherum umgewoehnen muss. Falls wir dafuer keine Befehle finden, dann kann es doch spannend bleiben :)

Zitatkein Bit für 100k sondern das 40k mit dem "slow" Flag sendet
Kannst du das nochmal langsam erklaeren? Wo ist ein slow flag?

ZitatDie Frage ist ja eigentlich was in dem Stick eigentlich gespeichert ist was sich nicht auch wieder aufbauen lässt
Na in der FHEM-Config steht alles drin, der Haken ist nur, dass wir das nicht dem ZWDongle beibringen koennen. Fuer ZWCUL habe ich alle Informationen parat, bis auf Routing, was mAn nicht so tragisch ist.

ZitatÄh, heisst das jetzt doch das man einem Gerät nachträglich eine andere ID geben kann?
Nein, das funktioniert nur beim Inkludieren, und da auch nur auf 9600.
Titel: Antw:ZWave @ culfw
Beitrag von: A.Harrenberg am 12 Januar 2016, 07:41:26
Hi Rudi,
Zitat von: rudolfkoenig am 10 Januar 2016, 19:48:35
Kannst du das nochmal langsam erklaeren? Wo ist ein slow flag?
das normale "Speed" flag: ITU-T G.9959 (01/2015)

Zitat8.1.3.3.4 Speed modified subfield (Channel configurations 1, 2 only)
The speed modified subfield is 1 bit in length. It shall be set to 1 if an MPDU is sent at a lower speed than supported by the Src and Dst. The field shall not be used for routed and multicast MPDUs. The field shall be set to 0 if the MPDU is sent at the highest speed supported by the source and destination.
Auch noch mal identisch in Kapitel A.4.2.3.4.

Wenn man das in einer 40K Nachricht setzt sollte das ja bedeutet das (beide) schneller können, also 100K. Woher der Controller/Sender allerdings weiss das die andere Seite schneller kann weiß ich auch nicht.

Gruß,
Andreas.

Titel: Antw:ZWave @ culfw
Beitrag von: rudolfkoenig am 12 Januar 2016, 10:29:36
ZitatWenn man das in einer 40K Nachricht setzt sollte das ja bedeutet das (beide) schneller können, also 100K.
Das waere eine komische Art der Kommunikation, allerdings habe ich auch nicht verstanden, wozu das 40k Bit selbst gut sein soll, schliesslich ist das nach dem Empfang mAn irrelevant.
Titel: Antw:ZWave @ culfw
Beitrag von: A.Harrenberg am 12 Januar 2016, 11:18:29
Hi Rudi,
Zitat von: rudolfkoenig am 12 Januar 2016, 10:29:36
Das waere eine komische Art der Kommunikation, allerdings habe ich auch nicht verstanden, wozu das 40k Bit selbst gut sein soll, schliesslich ist das nach dem Empfang mAn irrelevant.
ich zitiere nur die G.9959, wobei wir ja auch schon wissen das ZWave sich nicht in allen Punkten daran hält (invertierung bei 9.6k...).

Ich habe mir die Bitfelder (F und f) und den NIF noch nicht genauer angeschaut sondern hatte das nur noch im Kopf, weil ich es auch etwas merkwürdig fand.

Gruß,
Andreas.
Titel: Antw:ZWave @ culfw
Beitrag von: A.Harrenberg am 25 Januar 2016, 22:06:42
Hallo Rudi,
ich hätte da mal wieder ein Problem... Seit neuestem versucht der ZWCul mein System zu übernehmen... :-)
Sobald ich das Danalock einbinden inkludieren will nimmt FHEM mit meinem mal den ZWCul statt dem ZWDongle, und das obwohl der State von ZWCul "disconnected" ist, das Ding hatte ich nämlich rausgezogen um weiterarbeiten zu können...

2016.01.25 21:59:11.051 4: ZWDongle set ZWDongle_0 addNode onNwSec
2016.01.25 21:59:11.051 5: ZWDongle_Write 004ac107 ()
2016.01.25 21:59:11.051 5: SW: 0105004ac10776
2016.01.25 21:59:11.258 5: ACK received, removing 0105004ac10776 from dongle sendstack
2016.01.25 21:59:11.282 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 004a07010000
2016.01.25 21:59:11.282 5: SW: 06
2016.01.25 21:59:11.283 5: ZWDongle_0 dispatch 004a07010000
2016.01.25 21:59:11.283 4: ZWDongle_0 CMD:ZW_ADD_NODE_TO_NETWORK ID:01 ARG:0000
2016.01.25 21:59:11.283 4: ZWDongle_0 ZW_ADD_NODE_TO_NETWORK learnReady
2016.01.25 21:59:18.057 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 004a0702d80a0440035e72985a807322
2016.01.25 21:59:18.057 5: SW: 06
2016.01.25 21:59:18.058 5: ZWDongle_0 dispatch 004a0702d80a0440035e72985a807322
2016.01.25 21:59:18.058 4: ZWDongle_0 CMD:ZW_ADD_NODE_TO_NETWORK ID:02 ARG:d80a0440035e72985a807322
2016.01.25 21:59:18.058 4: ZWDongle_0 ZW_ADD_NODE_TO_NETWORK nodeFound
2016.01.25 21:59:18.107 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 004a0703d80a0440035e72985a807322
2016.01.25 21:59:18.107 5: SW: 06
2016.01.25 21:59:18.108 5: ZWDongle_0 dispatch 004a0703d80a0440035e72985a807322
2016.01.25 21:59:18.108 4: ZWDongle_0 CMD:ZW_ADD_NODE_TO_NETWORK ID:03 ARG:d80a0440035e72985a807322
2016.01.25 21:59:18.135 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 004a0705d80a0440035e72985a807322
2016.01.25 21:59:18.135 5: SW: 06
2016.01.25 21:59:18.136 5: ZWDongle_0 dispatch 004a0705d80a0440035e72985a807322
2016.01.25 21:59:18.136 4: ZWDongle_0 CMD:ZW_ADD_NODE_TO_NETWORK ID:05 ARG:d80a0440035e72985a807322
2016.01.25 21:59:18.136 2: ZWAVE Starting secure init
2016.01.25 21:59:18.136 5: ZWCUL_Write e015dfed 0013d80398040025d8
2016.01.25 21:59:18.136 5: SW: zse015dfed0141040dd898040035
2016.01.25 21:59:28.138 2: ZWave: No ACK from ZWave_ENTRY_CONTROL_216 after 10s for sent:13d80398040025d8

Wenn ich den ZWCul auf "disable" setze ist der Spuk vorbei, aber so ist das doch sicherlich nicht geplant...
Ich bin mir aber auch nicht sicher ob das nicht irgendwie mir meinem Code zusammenhängt, da ich ja teilweise auch direkt in addToSendStack schreibe und auch recht viel mit den hashes herumjongliere... Bei den Tests am WE war aber noch alles "normal", da hab' ich das Danalock zig-Mal inkludiert.

Hast Du eine Idee wo das ganze falsch abbiegt? (Und ob ich schuld bin??)

Gruß,
Andreas.
Titel: Antw:ZWave @ culfw
Beitrag von: rudolfkoenig am 26 Januar 2016, 07:57:53
Ich vermute, dass das IODev nicht (mehr?) richtig gesetzt ist.

ZWDongle_Define prueft, dass nur ZWDongle/ZWCUL/FHEM2FHEM mit passenden homeId zugewiesen wird, aber wenn es einmal gesetzt ist, dann wird das Geraet behalten, da ein Attribut erzeugt wird, was nach einem Neustart dem define drankommt.
Titel: Antw:ZWave @ culfw
Beitrag von: A.Harrenberg am 26 Januar 2016, 08:54:33
Hi Rudi,

werde ich heute abend mal nachsehen. Mir ist gestern abend noch aufgefallen das ZWCul mir den ZWDongle als Node_01 angelegt hat... ,-)

Finde ich eigentlich merkwürdig, da ich bisher nie eine HomeId für den ZWCul gesetzt habe, und ohne die sollte sowas doch eigentlich nicht möglihc sein, es sei denn die Nachricht vom ZWDongle gerät in die Queue vom ZWCul.

Ich schaue heute abend nach und berichte.

Danke,
Andreas.
Titel: Antw:ZWave @ culfw
Beitrag von: A.Harrenberg am 26 Januar 2016, 18:33:31
Hi Rudi,

IoDev ist gesetzt, der Fehler kommt anscheinend durch meinen Umbau mit zwave_parseHook. Irgendwie hantiere ich das anscheinend mit einem falschen Hash, ich finde aber gerade den Fehler nicht...
Ich hab' in den nächsten Tagen nicht so viel Zeit zum debuggen, aber da der Fehler nur auftritt wenn man mehr als ein ZWave-Device hat dürfte sich der "Schaden" hoffentlich im Rahmen halten.

Ich verstehe nur nicht wieso das während der gesamten Umbauphase einwandfrei funktioniert hat und jetzt mit einem Mal schief läuft...

Sorry,
Andreas.
Titel: Antw:ZWave @ culfw
Beitrag von: A.Harrenberg am 26 Januar 2016, 18:39:07
Hi Rudi,

kaum geschrieben schon was entdeckt...
Irgendwie hat jetzt mein ZWCul (m)eine homeId bekommen...
Internals:
   Clients    :ZWave:STACKABLE_CC:
   DEF        /dev/ttyACM2@115200 00000000 01
   DeviceName /dev/ttyACM2@115200
   FD         20
   NAME       zwc
   NR         23
   PARTIAL
   RAWMSG     zR4D
   STATE      Initialized
   TYPE       ZWCUL
   VERSION    V 1.66 CUL868
   baudRate   9600
   homeId     e015dfed
   homeIdSet  00000000
   initString zm1
   monitor    1
   nodeIdHex  01
   removeNode 1
   zwc_MSGCNT 2894
   zwc_TIME   2016-01-26 18:30:22
   Matchlist:
     1:ZWave    .*
     2:STACKABLE_CC ^\*
   Readings:
     2016-01-25 19:35:38   homeId          HomeId:00000000 CtrlNodeId:01
     2016-01-26 18:30:22   state           Initialized
Attributes:
   dataRate   100k
   disable    0
   noDispatch 1
   room       ZWave
   verbose    5

Ich habe die nie gesetzt, wie kommt die da hin?
get homeId liefert mir auch 00000000 zurück...

Wie krieg' ich die homeId wieder weg?
Wieso habe ich da noch ein homeIdSset?

Gruß,
Andreas.
Titel: Antw:ZWave @ culfw
Beitrag von: rudolfkoenig am 26 Januar 2016, 18:49:27
homeIdSet ist das, was man in der Definition angibt.

homeId wird vom zuletzt empfangenen Paket gesetzt, damit das Anlegen von Geraeten funktioniert, aber nur, falls noDispatch nicht gesetzt ist. Ich kann deine Ausgabe nur so vorstellen, dass du FHEM gestartet hast, und danach noDispatch gesetzt hast. Sonst waere es ein Bug, und ich weiss noch nicht, wo/was ich aendern muss, um es zu fixen.
Titel: Antw:ZWave @ culfw
Beitrag von: A.Harrenberg am 26 Januar 2016, 21:23:27
Hi Rudi,

ich werde den ZWCul nachher mal löschen und neu anlegen und schauen ob der wieder eine homeId bekommt.

Das ganze ist aber dennoch merkwürdig. Ich habe ganz zu Anfang das "noDispatch" noch nicht aktiv gehabt, das ist jetzt aber schon ein paar Wochen her... Und seitdem habe ich unzählige Male FHEM neu gestartet oder die Geräte neu inkludiert.

Und ich an den Code-Änderungen liegt es wahrscheinlich auch nicht, beim alten und neuen Code wird der gleiche Hash verwendet, der allerdings mit Hilfe der homeId ermittelt wird:
my $dh = $modules{ZWave}{deftptr}{"$homeId $1"}

Mir war ja auch aufgefallen das der mir der ZWCul eine Node angelegt hat...

Na ja, ich werde beobachten und berichten.

Macht es vielleicht Sinn zu verhindern das zwei ZWave-IoDevices mit der gleichen homeId (automatisch) angelegt werden und man die gleiche homeId nur zulässt wenn sie beim define angegeben wurde?

Gruß,
Andreas.
Titel: Antw:ZWave @ culfw
Beitrag von: rudolfkoenig am 27 Januar 2016, 09:54:34
Mit gleichen homeIds kann man groessere Bereiche mit abgesetzten (d.h. via LAN angebundenen) CULs abdecken.
Es macht aber vermutlich wenig Sinn, ein ZWCUL im Monitor-Mode ohne noDispatch zusammen mit anderen Empfaenger (ZWDongle/ZWCUL) zu betreiben.

Kannst du bitte pruefen, ob das Problem mit von Anfang an gesetzten noDispatch auch auftritt? Wenn ja, dann muss ich was fixen, ansonsten tendiere ich dazu, dass noDispatch bei monitor-mode zum Standard wird, und das aktuelle Verhalten mit einem neuen Attribut ("intruderMode"?) aktiviert werden muss.
Titel: Antw:ZWave @ culfw
Beitrag von: A.Harrenberg am 27 Januar 2016, 10:49:23
Hi Rudi,
Zitat von: rudolfkoenig am 27 Januar 2016, 09:54:34
Mit gleichen homeIds kann man groessere Bereiche mit abgesetzten (d.h. via LAN angebundenen) CULs abdecken.
Hmm, ich stelle mir das aber "gefährlich" vor wenn je nach Empfangslage der "andere" Dongle auch empfängt und dann evtl antwortet. Das dürfte ein ziemliches durcheinander werden... Als sekundärer Controller mit einer anderen ID könnte das funktionieren...

Zitat von: rudolfkoenig am 27 Januar 2016, 09:54:34
Es macht aber vermutlich wenig Sinn, ein ZWCUL im Monitor-Mode ohne noDispatch zusammen mit anderen Empfaenger (ZWDongle/ZWCUL) zu betreiben.
Yep, Zustimmung.

Zitat von: rudolfkoenig am 27 Januar 2016, 09:54:34
Kannst du bitte pruefen, ob das Problem mit von Anfang an gesetzten noDispatch auch auftritt? Wenn ja, dann muss ich was fixen, ansonsten tendiere ich dazu, dass noDispatch bei monitor-mode zum Standard wird, und das aktuelle Verhalten mit einem neuen Attribut ("intruderMode"?) aktiviert werden muss.
Ich habe den ZWCul gestern abend gelöscht und neu angelegt und sofort nach dem Anlegen das noDispatch gesetzt. Bis jetzt ist noch alles in Ordnung.

Ich hab' die Nacht noch etwas darüber gegrübelt, und bin zu dem Schluß gekommen das es evtl. durch (Perl)Syntax-Probleme während meiner Tests ausgelöst worden sein könnte. Wenn man FHEM neu startet bzw. das Modul neu lädt und z.B. eine "}" vergessen hat kommt der Code ganz schön durcheinander, vielleicht habe ich durch soetwas den noDispatch außer Kraft gesetzt...

Ich beobachte mal weiter, wäre aber dafür das im Monitormode das noDispatch der Default ist.

Danke,
Andreas.
Titel: Antw:ZWave @ culfw
Beitrag von: rudolfkoenig am 31 Januar 2016, 12:40:04
Habe noDispatch durch intruderMode ausgetauscht. intruderMode muss im monitor-Mode (homeId = 00000000) gesetzt sein, damit Events an das ZWave Modul weitergereicht werden.
Titel: Antw:ZWave @ culfw
Beitrag von: A.Harrenberg am 31 Januar 2016, 21:13:40
Hi Rudi,
Zitat von: rudolfkoenig am 31 Januar 2016, 12:40:04
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
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.
Titel: Antw:ZWave @ culfw
Beitrag von: rudolfkoenig am 01 Februar 2016, 07:55:52
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 :)
Titel: Antw:ZWave @ culfw
Beitrag von: A.Harrenberg am 01 Februar 2016, 21:59:04
Hi Rudi,
Zitat von: rudolfkoenig am 01 Februar 2016, 07:55:52
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.


Titel: Antw:ZWave @ culfw
Beitrag von: rudolfkoenig am 01 Februar 2016, 23:02:10
ZitatBefehle 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.
Titel: Antw:ZWave @ culfw
Beitrag von: A.Harrenberg am 02 Februar 2016, 07:07:41
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.
Titel: Antw:ZWave @ culfw
Beitrag von: Thyraz am 03 Februar 2016, 20:08:33
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...

Titel: Antw:ZWave @ culfw
Beitrag von: rudolfkoenig am 03 Februar 2016, 22:13:46
ZitatEin 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.
Titel: Antw:ZWave @ culfw
Beitrag von: Thyraz am 04 Februar 2016, 08:20:11
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...
Titel: Antw:ZWave @ culfw
Beitrag von: rudolfkoenig am 04 Februar 2016, 09:10:43
ZitatDas 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?
Titel: Antw:ZWave @ culfw
Beitrag von: Thyraz am 04 Februar 2016, 10:34:13
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).
Titel: Antw:ZWave @ culfw
Beitrag von: rudolfkoenig am 12 Februar 2016, 21:22:41
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.
Titel: Antw:ZWave @ culfw
Beitrag von: rudolfkoenig am 13 Februar 2016, 23:26:37
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
Titel: Antw:ZWave @ culfw
Beitrag von: A.Harrenberg am 21 Februar 2016, 18:42:15
Hi Rudi,

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

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?
Titel: Antw:ZWave @ culfw
Beitrag von: krikan am 21 Februar 2016, 18:48:18
Zitat von: A.Harrenberg am 21 Februar 2016, 18:42:15
  • 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  8).
Titel: Antw:ZWave @ culfw
Beitrag von: rudolfkoenig am 21 Februar 2016, 19:16:32
Zitatkö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?
Waere etwas irrefuehrend: culfw Version ist die ganze Zeit 1.66. Ja, ich weiss, nicht sehr praktisch.

Zitathast Du eine Art Roadmap für die Entwicklung des ZWCul?
Ja, steht in 00_ZWCul.pm vorne, unter TODO
#   static routing: to and from the device
#   automatic routing via neighborUpdate
#   explorer frames
#   check security
#   multicast
Static routing ist halb fertig: ich habs programmiert, traue dem Ergebnis noch nicht, siehe meinen letzten Beitrag.

Zitathast Du gesagt das die "anderen" kein Interesse an der Entwicklung haben.
Sorry, hatte wirklich den Eindruck, dass ihr ZWCul nur fuer debuggen benoetigt, und das ist fertig.
Das ist aber wirklich kein Vorwurf, nicht jeder muss/soll meine Spinnereien wichtig finden.

Zitatwürde ich vorschlagen einen "Spin-Off" von ZWCul zu machen, ZWCulNode
- Um ZWave-Clients ala  AskSinLib zu implementieren ist ein ZWCulNode nicht notwendig.
- Fuer ein OTA-Firmware-Update zu implementieren waere es auch nicht wirklich nuetzlich
-> ich habe den Sinn nicht verstanden :(


ZitatUsertreffen in der Region Köln im Mai, bestünden Chancen auf Deine Anwesenheit?
Chancen gibt immer, und Mai ist ja weit weg. Das war noch keine Zusage :)
Titel: Antw:ZWave @ culfw
Beitrag von: A.Harrenberg am 21 Februar 2016, 19:46:35
Hi,
Zitat von: rudolfkoenig am 21 Februar 2016, 19:16:32
Waere etwas irrefuehrend: culfw Version ist die ganze Zeit 1.66. Ja, ich weiss, nicht sehr praktisch.
ok, Christian hat ja auch schon einen berechtigten Einwand gebracht, das zu pflegen ist natürlich aufwändig da man natürlich auch noch ein aktuellen Ankündigungspost braucht.

Zitat von: rudolfkoenig am 21 Februar 2016, 19:16:32
Ja, steht in 00_ZWCul.pm vorne, unter TODO
#   static routing: to and from the device
#   automatic routing via neighborUpdate
#   explorer frames
#   check security
#   multicast
auch ok, da hatte ich anscheinend noch nie hingeschaut.

Kannst Du mal kurz erläutern was Du mit "check security" meinst? Da sollte es doch eigentlich gar nichts besonderes zu beachten geben, oder willst Du auch die eigentlich erforderlichen Timer implementieren?

Zitat von: rudolfkoenig am 21 Februar 2016, 19:16:32
Static routing ist halb fertig: ich habs programmiert, traue dem Ergebnis noch nicht, siehe meinen letzten Beitrag.
Sorry, hatte wirklich den Eindruck, dass ihr ZWCul nur fuer debuggen benoetigt, und das ist fertig.
Das ist aber wirklich kein Vorwurf, nicht jeder muss/soll meine Spinnereien wichtig finden.
Hab' das auch überhaupt nicht als Vorwurf verstanden, wollte nur sagen das ich da wenige Ansatz habe was zu machen. Debug/Sniffing ist schon das Hauptziel gewesen, aber das habe ich bis jetzt auch noch nicht so wirklich durchgeführt. Bin aktuell auch gerade beruflich recht stark eingespannt sodass ich gerade auch wenig Zeit für FHEM/ZWave habe. ;-(
Eigentlich würde ich da gerne noch mal versuchen die unterschiedlichen Baudraten in den Griff zu bekommen.
Jetzt weiss ich zumindest aber schon mal wo die ToDo stehen :-)

Zitat von: rudolfkoenig am 21 Februar 2016, 19:16:32
- Um ZWave-Clients ala  AskSinLib zu implementieren ist ein ZWCulNode nicht notwendig.
- Fuer ein OTA-Firmware-Update zu implementieren waere es auch nicht wirklich nuetzlich
-> ich habe den Sinn nicht verstanden :(
Ok, schlecht ausgedrückt, ich wollte kein ZWCulNode in FHEM implementieren, sondern einen nanoCul mit spezieller culfw als ZWaveNode haben. Also ein eigenständige Arduinogerät das sich ganz normal als Node in ein ZWave Netzwerk einbinden lässt. Ich hoffe das war jetzt klarer und macht auch mehr Sinn ,-)

AskSinLib kannte ich bisher nicht, habe nur mal ganz kurz danach geschaut, sieht doch ähnlich aus, nur eben für HM.

Zitat von: rudolfkoenig am 21 Februar 2016, 19:16:32
Chancen gibt immer, und Mai ist ja weit weg. Das war noch keine Zusage :)
Klar, ich kann jetzt auch noch nicht sagen wann ich im Mai Zeit haben werde. Außerdem bin ich im März zwei Wochen weg und quasi den ganzen April...

Gruß,
Andreas.
Titel: Antw:ZWave @ culfw
Beitrag von: rudolfkoenig am 22 Februar 2016, 09:20:55
ZitatKannst Du mal kurz erläutern was Du mit "check security" meinst? Da sollte es doch eigentlich gar nichts besonderes zu beachten geben, oder willst Du auch die eigentlich erforderlichen Timer implementieren?
Ich wollte nur pruefen, ob es geht. Sollte theoretisch funktionieren (deswegen habe ich auch nur check security geschrieben), es koennte allerdings auch sein, dass mit Security auch auf Funk-Ebene was anders gemacht wird.
Titel: Antw:ZWave @ culfw
Beitrag von: A.Harrenberg am 22 Februar 2016, 18:48:40
Hi Rudi,

ah, ok, das kann ich sicherlich bei Gelegenheit mal ausprobieren. Ich erwarte da aber auch keine Besonderheiten.

Gruß,
Andreas.
Titel: Antw:ZWave @ culfw
Beitrag von: krikan am 09 Juni 2016, 22:27:18
So, da ich meinen Raspi wiederbelebt habe, ein Log für die Forschung von einem 1000ms-FLIRS-Device:
2016.06.09 21:43:57.814 2: ZWave get ZWave_RM_Flur_EG swbStatus
2016.06.09 21:43:57.815 5: ZWDongle_Write 001341022502251f (e345c452)
2016.06.09 21:43:57.815 5: SW: 0109001341022502251fbb
2016.06.09 21:43:57.818 5: ACK received, WaitForAck=>2 for 0109001341022502251fbb
2016.06.09 21:43:57.819 4: ZWDongle_Read ZWDongle_0: rcvd 011301 (answer ZW_SEND_DATA), sending ACK
2016.06.09 21:43:57.819 5: SW: 06
2016.06.09 21:43:57.821 5: ZWDongle_0 dispatch 011301
2016.06.09 21:43:59.064 5: e345c452 S:01 F:41 f:0 SN:3 L:0c T:41 P:2502 C:e6
2016.06.09 21:43:59.065 5:    F: singleCast ackReq
2016.06.09 21:43:59.074 5: e345c452 S:41 F:03 f:0 SN:3 L:0a T:01 P: C:85
2016.06.09 21:43:59.075 5:    F: ack
2016.06.09 21:43:59.075 4: ZWDongle_Read ZWDongle_0: rcvd 00131f00 (request ZW_SEND_DATA), sending ACK
2016.06.09 21:43:59.076 5: SW: 06
2016.06.09 21:43:59.077 5: device ack reveived, removing 0109001341022502251fbb from dongle sendstack
2016.06.09 21:43:59.077 5: ZWDongle_0 dispatch 00131f00
2016.06.09 21:43:59.077 4: CMD:ZW_SEND_DATA ID:00 ARG: CB:1f
2016.06.09 21:43:59.078 4: ZWDongle_0 transmit OK for CB 1f, target ZWave_RM_Flur_EG
2016.06.09 21:43:59.083 5: e345c452 S:41 F:41 f:4 SN:1 L:0d T:01 P:250300 C:a4
2016.06.09 21:43:59.083 5:    F: singleCast ackReq longBeam
2016.06.09 21:43:59.084 4: ZWDongle_Read ZWDongle_0: rcvd 0004004103250300 (request APPLICATION_COMMAND_HANDLER), sending ACK
2016.06.09 21:43:59.085 5: SW: 06
2016.06.09 21:43:59.086 5: ZWDongle_0 dispatch 0004004103250300
2016.06.09 21:43:59.086 4: CMD:APPLICATION_COMMAND_HANDLER ID:41 ARG:03250300 CB:00
2016.06.09 21:43:59.153 5: e345c452 S:01 F:03 f:0 SN:1 L:0a T:41 P: C:87
2016.06.09 21:43:59.153 5:    F: ack


Trotz 100k-Chipsatz sendet der Rauchmelder immer mit 40k.
Titel: Antw:ZWave @ culfw
Beitrag von: A.Harrenberg am 10 Juni 2016, 08:03:08
Hi, soweit ich weiß senden FLIRS Geräte immer mit 40k. Ich denke das Timing mit FLIRS ist bei 100k nicht möglich.

Gruß,
Andreas.
Titel: Antw:ZWave @ culfw
Beitrag von: krikan am 12 August 2016, 18:59:17
Kann ich irgendwie das Logging im MonitorMode so einstellen, dass nur Nachrichten für eine bestimmte HomeId geloggt werden?
Titel: Antw:ZWave @ culfw
Beitrag von: rudolfkoenig am 13 August 2016, 13:40:44
ZitatKann ich irgendwie das Logging im MonitorMode so einstellen, dass nur Nachrichten für eine bestimmte HomeId geloggt werden?
Ich gehe davon aus, das du nur loggen, und die Nachrichten nicht vom 10_ZWave.pm verarbeiten willst.

Z.Zt. ist das nur per Hack moeglich: homeId auf das gewuenschte ID setzen, und danach { $defs{ZWCUL_1}{monitor} = 1 } ausfuehren. Entweder manuell nach jedem Neustart, oder per notify auf global:INITIALIZED.

Titel: Antw:ZWave @ culfw
Beitrag von: krikan am 13 August 2016, 16:13:46
Ja, nur Logs. Danke.

Wenn ich das richtig verstehe, muss ich beim MonitorMode die Checksumme der Nachrichten nachtraeglich kontrollieren (i.e. no checksum filtering will be done). Das habe ich bisher ignoriert.

Zudem habe ich das Problem, dass immer wieder Nachrichten verschluckt werden. Typischerweise ACK; aber leider auch die wichtigen Telegramme. Logge daher gleichzeitig mit 2 Fhem-Instanzen mit Cul auf 40k, was jedoch auch nicht zu 100% führt. Keine Ahnung, ob das an Win10  liegt und auf Linux nicht auftritt.
Titel: Antw:ZWave @ culfw
Beitrag von: rudolfkoenig am 14 August 2016, 12:17:05
Checksum wird (seit laengerem) in culfw in jedem Fall geprueft, also auch bei homeId 00000000, und Nachrichten mit falschen Checksum werden nicht gemeldet. Ich habe die Doku angepasst.

Dass deine Verluste an Windows liegen, glaube ich nicht, auch wenn ich und Windows keine Freunde sind. Eher an anderen Faktoren, wie den fuer ZWave nicht perfekten RF-Chip, und unsere unvollkommene Firmware.

Wenn du das Problem reproduzieren, oder genauer beschreiben kannst, dann kann ich versuchen bei der naechsten culfw Aenderung danach zu suchen. Ich will fuer Verschluesselung Pakete laenger als 64 Bytes zulassen.
Titel: Antw:ZWave @ culfw
Beitrag von: krikan am 14 August 2016, 12:46:40
ZitatWenn du das Problem reproduzieren, oder genauer beschreiben kannst, dann kann ich versuchen bei der naechsten culfw Aenderung danach zu suchen. Ich will fuer Verschluesselung Pakete laenger als 64 Bytes zulassen.
Bisher erkenne ich überhaupt kein Schema.
Habe gestern abend entnervt Loggen wegen eines neuen, erstmalig aufgetreten Problems vorübergehend unterbrochen:
Das Loggen brach immer wieder nach einigen Minuten komplett ohne Fehlermeldung ab. FHEM lief aber noch. Reaktivieren lies sich das Loggen reproduzierbar mit erneutem Setzen des Attributes dataRate 40k.
Titel: Antw:ZWave @ culfw
Beitrag von: krikan am 23 Mai 2017, 16:49:20
Am Rande: In der 3. Aufl. vom Paetz gibt es eine leicht erweiterte Erläuterung zu den Explorer Frames und Angaben zum Aufbau eines EF.
Titel: Antw:ZWave @ culfw
Beitrag von: rudolfkoenig am 23 Mai 2017, 18:42:07
Kennst du eine Moeglichkeit an diese Beschriebung zu kommen, ohne dass ich ein weiteres Exemplar von dem Buch kaufe?
Titel: ZWave @ culfw
Beitrag von: RaspiLED am 23 Mai 2017, 19:35:14
Hallo Rudolf,
Meinst Du dies hier?
https://www.amazon.de/Z-Wave-Die-Funktechnologie-Smart-Home/dp/3738601945
Ich sponsere Dir das gerne!
Gruß Arnd


Raspi2 mit FHEM, CUL, Signalduino, MySensors, HomeBridge, Presence, Bravia, ...
Titel: Antw:ZWave @ culfw
Beitrag von: rudolfkoenig am 23 Mai 2017, 19:49:53
Danke, nicht mehr noetig. Wg. ein paar Zeilen Info ist mir ein ganzes Buch doch zuviel, es reicht mir, wenn ich mitlesen darf. Ich hoffe, der Autor hat nichts dagegen, den ersten Exemplar hat er mir ja auf der Messe in Frankfurt noch selbst spendiert.
Titel: Antw:ZWave @ culfw
Beitrag von: A.Harrenberg am 02 Juni 2017, 23:11:53
Hi Rudi, hi Christian,

habe gerade etwas mit dem 8fach Taster und Z-Way rumgespielt... Dachte Z-Way könnte den schon mit Security S2 inkludieren und wollte mir das ansehen. Z-Way kann das aber (noch) nicht... ;-(

Aber mir ist was Interessantes beim Inkludieren aufgefallen.
Das hier ist das Log von dem 4xfach CUL, "mCUL" war in dem Fall auf 40k eingestellt, die anderen Namen sind selbsterklärend.
Die Home-ID von dem Z-Way System ist 0xd2c779a3 (die von meinem Testsystem 0xe015dfed und mein Produktivsystem hat 0xe173b78d).

Die Inklusion beginnt damit das der Controller auf 40k ein Explorer Frame verschickt und dann auf 9k6 noch eine Nachricht.

Dann scheint der Taster seinen NIF zu schicken, allerdings mit einer anderen Home-ID, der Controller antwortet dann aber mit DIESER Home-ID, schickt aber die "richtige" HomeID zurück. Ab da ist dann alles mit der richtigen Home-ID.

Hatte bisher nicht drüber nachgedacht und bin eigentlich davon ausgegangen das die Node die Home-ID nutzt in den vorher empfangenen Nachrichten ist, wenn man drüber nachdenkt kann es aber mehrere Netze geben und die Node kann nicht wissen welches Netz gerade für die Inklusion bereit ist.

Man lernt immer wieder mal was dazu ,-)
Im Log kann man dann auch schön sehen das danach außer den ACK nur noch einmal ein NOP (0x00) mit 9k6 übertragen wird und die Kommunikation danach mit 100k weitergeht.

2017.06.02 22:32:40.406 5: mCUL d2c779a3 S:01 F:05 f:0 SN:4 L:16 T:ff  E:2000fa4000000000 P:01220100 C:61
2017.06.02 22:32:40.406 5:    F: singleCast explorer
2017.06.02 22:32:42.226 5: z9.6 d2c779a3 S:01 F:01 f:0 SN:4 L:0d T:ff P:010801 C:ce
2017.06.02 22:32:42.226 5:    F: singleCast
2017.06.02 22:32:43.049 5: z9.6 e035a20e S:00 F:01 f:0 SN:1 L:22 T:ff P:0101539c0101065e858e705b595586725a73809f846cef26 C:03
2017.06.02 22:32:43.049 5:    F: singleCast
2017.06.02 22:32:43.095 5: z9.6 e035a20e S:01 F:41 f:0 SN:5 L:11 T:00 P:010303d2c779a3 C:1c
2017.06.02 22:32:43.095 5:    F: singleCast ackReq
2017.06.02 22:32:43.119 5: z9.6 e035a20e S:00 F:03 f:0 SN:5 L:0a T:01 P: C:8b
2017.06.02 22:32:43.119 5:    F: ack
2017.06.02 22:32:43.147 5: z9.6 d2c779a3 S:01 F:41 f:0 SN:6 L:0b T:03 P:00 C:7e
2017.06.02 22:32:43.147 5:    F: singleCast ackReq
2017.06.02 22:32:43.175 5: z9.6 d2c779a3 S:03 F:03 f:0 SN:6 L:0a T:01 P: C:3d
2017.06.02 22:32:43.175 5:    F: ack
2017.06.02 22:32:43.237 5: z100k d2c779a3 S:01 F:41 f:0 SN:7 L:11 T:03 P:010401010003 C:33d1
2017.06.02 22:32:43.237 5:    F: singleCast ackReq
2017.06.02 22:32:43.244 5: z100k d2c779a3 S:03 F:03 f:0 SN:7 L:0b T:01 P: C:d194
2017.06.02 22:32:43.244 5:    F: ack
2017.06.02 22:32:43.255 5: z100k d2c779a3 S:03 F:41 f:0 SN:2 L:0f T:01 P:01186006 C:8ba4
2017.06.02 22:32:43.255 5:    F: singleCast ackReq
2017.06.02 22:32:43.262 5: z100k d2c779a3 S:01 F:03 f:0 SN:2 L:0b T:03 P: C:5ea5
2017.06.02 22:32:43.262 5:    F: ack
2017.06.02 22:32:43.270 5: z100k d2c779a3 S:03 F:41 f:0 SN:3 L:0e T:01 P:010700 C:b0d5
2017.06.02 22:32:43.270 5:    F: singleCast ackReq
2017.06.02 22:32:43.277 5: z100k d2c779a3 S:01 F:03 f:0 SN:3 L:0b T:03 P: C:6995
2017.06.02 22:32:43.277 5:    F: ack
2017.06.02 22:32:43.286 5: z100k d2c779a3 S:01 F:41 f:0 SN:8 L:0d T:03 P:0105 C:2b0c
2017.06.02 22:32:43.286 5:    F: singleCast ackReq
2017.06.02 22:32:43.290 5: z100k d2c779a3 S:03 F:03 f:0 SN:8 L:0b T:01 P: C:fda5
2017.06.02 22:32:43.290 5:    F: ack
2017.06.02 22:32:43.302 5: z100k d2c779a3 S:03 F:41 f:0 SN:4 L:0f T:01 P:01060101 C:3a1f
2017.06.02 22:32:43.302 5:    F: singleCast ackReq
2017.06.02 22:32:43.307 5: z100k d2c779a3 S:01 F:03 f:0 SN:4 L:0b T:03 P: C:ec05
2017.06.02 22:32:43.307 5:    F: ack
...


Gruß,
Andreas.
Titel: Antw:ZWave @ culfw
Beitrag von: rudolfkoenig am 03 Juni 2017, 14:40:53
Bei meinen Experimenten mit ZWCUL wurde bisher fuer solche Zwecke homeId 00000000 und nodeId 00 verwendet.

Ich glaube in deinem Fall eher an einem Bug: das Geraet hat seine alte homeId nicht ganz vergessen. Passt leider nicht zu dieser Theorie, dass der ZWave-Dongle trotzdem reagiert. Mit ZWCUL im "normalen" Modus (also nicht monitor) wuerde das Pairing nicht klappen, da ZWCUL dann nur auf 00000000 und die eigene homeId hoert. Seufz.
Titel: Antw:ZWave @ culfw
Beitrag von: A.Harrenberg am 03 Juni 2017, 15:56:00
Hallo Rudi,

das war keine meiner "alten/anderen" Home-IDs (die hatte ich deswegen extra dazugeschrieben).

Das Gerät scheint sich eine zufällige Home-ID auszudenken:
2017.06.03 15:34:37.711 4: ZWDongle_0 ZW_ADD_NODE_TO_NETWORK learnReady

2017.06.03 15:34:37.770 5: mCUL e015dfed S:01 F:05 f:0 SN:a L:16 T:ff  E:2000fa3109000000 P:01220000 C:1e
2017.06.03 15:34:37.770 5:    F: singleCast explorer
2017.06.03 15:34:37.830 5: mCUL e015dfed S:01 F:05 f:0 SN:a L:16 T:ff  E:2000fa3117000000 P:01220000 C:00
2017.06.03 15:34:37.830 5:    F: singleCast explorer
2017.06.03 15:34:39.527 5: z9.6 e015dfed S:01 F:01 f:0 SN:8 L:0d T:ff P:010801 C:ca
2017.06.03 15:34:39.527 5:    F: singleCast
2017.06.03 15:34:39.945 5: z9.6 c8aa6638 S:00 F:01 f:0 SN:1 L:22 T:ff P:0101539c0101065e858e705b595586725a73809f846cef26 C:46
2017.06.03 15:34:39.945 5:    F: singleCast
2017.06.03 15:34:39.965 4: ZWDongle_Read ZWDongle_0: rcvd 004a04020000 (request ZW_ADD_NODE_TO_NETWORK), sending ACK
2017.06.03 15:34:39.965 5: SW: 06
2017.06.03 15:34:39.966 4: CMD:ZW_ADD_NODE_TO_NETWORK ID:02 ARG:0000 CB:04
2017.06.03 15:34:39.967 4: ZWDongle_0 ZW_ADD_NODE_TO_NETWORK nodeFound
2017.06.03 15:34:39.990 5: z9.6 c8aa6638 S:01 F:41 f:0 SN:9 L:11 T:00 P:01036fe015dfed C:31
2017.06.03 15:34:39.990 5:    F: singleCast ackReq
2017.06.03 15:34:40.019 5: z9.6 c8aa6638 S:00 F:03 f:0 SN:9 L:0a T:01 P: C:c2
2017.06.03 15:34:40.019 5:    F: ack
2017.06.03 15:34:40.047 5: z9.6 e015dfed S:01 F:41 f:0 SN:a L:0b T:6f P:00 C:16
2017.06.03 15:34:40.047 5:    F: singleCast ackReq
2017.06.03 15:34:40.074 5: z9.6 e015dfed S:6f F:03 f:0 SN:a L:0a T:01 P: C:55
2017.06.03 15:34:40.074 5:    F: ack
2017.06.03 15:34:40.288 5: z100k e015dfed S:01 F:41 f:0 SN:b L:1e T:6f P:01040e81014000000000800100000040010003 C:9b13
2017.06.03 15:34:40.288 5:    F: singleCast ackReq
2017.06.03 15:34:40.288 5: z100k e015dfed S:6f F:03 f:0 SN:b L:0b T:01 P: C:33bd
2017.06.03 15:34:40.288 5:    F: ack

Ich habe das Ding jetzt noch mal an meinem Testsystem inkludiert und dabei hat es 0xc8aa6638 als Home-ID genutzt. Ich denke nicht das es sich dabei um einen Bug handelt, das müsste man noch mal mit ein paar weiteren Geräte austesten, vor allen Dingen aber auch neueren Geräte mit einem aktuellen SDK.

Dann sollten wir ZWCul bei Gelegenheit mal dahin erweitern das es damit auch zurecht kommt. Dürfte aber eine niedrige Prio haben, solange wir nicht alle drei Datenraten zeitgleich hinbekommen und jemand einen CUL zu mehr als zum sniffen/Debuggen einsetzen will.

Hier bin ich zwar schon etwas weitergekommen, habe aber Bedenken das diese Lösung sich praktikabel realisieren lässt, da die Erkennungsrate einer Übertragung, wenn das Ding in der Mitte zwischen den beiden Frequenzen lauscht, doch recht fragil ist...
Selbst im Nahfeld geht das RSSI da nur 10-15 dB aus dem Rauschteppich raus, die Schwelle so einzustellen das dann ein GDO Pin aktiv wird ohne Pakete zu verpassen und übermäßig "Fehlalarm" zu geben ist nahezu unmöglich.

Ich warte aber noch auf ein kleines Interface (so ein mini-SDK Nachbau) das man mit dem RF-Studio Programm steuern kann, dann kann ich hoffentlich etwas schneller probieren als jetzt. Momentan muss ich das mit dem LogicAnalyser auf dem SPI aufzeichnen, als CSV exportieren, in Excel konvertieren und einige Berechnungen machen und kann mir das dann ansehen. Die "Turn-around" Zeiten davon sind nicht besonders hoch...

Gruß,
Andreas.



Titel: Antw:ZWave @ culfw
Beitrag von: eisler am 29 März 2018, 16:50:55

Hallo,

aktuelle FHEM Version, CUL Version: V 1.67

beim "addNode on" bekomme ich folgende Meldung:

2018.03.29 16:44:18 4 : ZWCUL set ZWCUL_1 addNode on
2018.03.29 16:44:18 3 : ZWCUL going to assigning new node id 02
2018.03.29 16:44:18 5 : SW: zm9
2018-03-29 16:44:18 ZWCUL ZWCUL_1 addNode on
2018.03.29 16:44:18 5 : ZWCUL_1: dispatch ? (zm9 is unknown) Use one of A B b C e F G h i K k L l M m N R T t U u V W X x Y Z
2018-03-29 16:44:18 ZWCUL ZWCUL_1 UNKNOWNCODE ? (zm9 is unknown) Use one of A B b C e F G h i K k L l M m N R T t U u V W X x Y Z
2018.03.29 16:44:18 3 : ZWCUL_1: Unknown code ? (zm9 is unknown) Use one of A B b C e F G h i K k L l M m N R T t U u V W X x Y Z, help me!
2018.03.29 16:44:18 1 : ERROR: Unknown packet ? (zm9 is unknown) use one of a b b c e f g h i k k l l m m n r t t u u v w x x y z


Woher kommt das "zm9" ?

Grüße
Stephan
Titel: Antw:ZWave @ culfw
Beitrag von: rudolfkoenig am 29 März 2018, 17:17:42
Ein ZWCUL Benutzer. Staun :)

zm9 bedeutet Monitoring auf 9600 Baud, und kommt vom ZWCUL.pm.
Und die Fehlermeldung kommt, weil dein Firmware ZWave nicht kennt.
Und: bitte kein addNode mit monitoring, ist nicht unterstuetzt. Entweder Monitoring, oder "Normalbetrieb" mit addNode, etc.
Titel: Antw:ZWave @ culfw
Beitrag von: eisler am 29 März 2018, 18:12:02
ok.

ich dachte CUL Firmware V 1.67 kann ZWave zusammen mit dem ZWCUL FHEM Modul.
Wie komme ich denn zu dem monitoring? Habe ich mit

define ZWCUL_1 ZWCUL /dev/ttyACM0@9600 12345678 01

keinen "Normalbetrieb"?

Grüße
Stephan

Titel: Antw:ZWave @ culfw
Beitrag von: rudolfkoenig am 29 März 2018, 18:47:42
Zitatich dachte CUL Firmware V 1.67 kann ZWave zusammen mit dem ZWCUL FHEM Modul.
Im Prinzip schon, aber ZWave ist nur in der CUL_V3_ZWAVE und CUL_V4 Variante enthalten. Siehe culfw/Devices/CUL/board.h

ZitatWie komme ich denn zu dem monitoring?
HomeId muss 00000000 sein.
Sorry, meine vorherige Aussage ist falsch: bei addNode wird auch im Normalmode auf zm9 geschaltet, da die Alternative (zr) nach dem HomeId filtert, und das kennt das Geraet, was inkludiert werden soll, erst spaeter.
Titel: Antw:ZWave @ culfw
Beitrag von: eisler am 03 April 2018, 10:34:17
CUL Version 3.4 mit CUL_V3_ZWAVE.hex geflasht.

Test mit AEOTEC Door/Window Sensor 6
Der Sensor sieht aus wie wenn er angelernt wurde tauch aber im FHEM nicht auf.

Grüße
Stephan


2018.04.03 10:14:34 3: Setting ZWCUL_1 serial parameters to 9600,8,N,1
2018.04.03 10:14:34 4: ZWCUL_ReadAnswer arg:Clear regexp:wontmatch
2018.04.03 10:14:34 5: ZWCUL_ReadAnswer: select timeout
2018.04.03 10:14:34 5: SW: V
2018.04.03 10:14:34 4: ZWCUL_ReadAnswer arg:Version regexp:^V
2018.04.03 10:14:34 4: ZWCUL_ReadAnswer for Version: V 1.67 CUL868
2018.04.03 10:14:34 5: SW: zi8888888801
2018.04.03 10:14:34 5: SW: zr4
2018.04.03 10:14:34 1: /dev/ttyACM0 reappeared (ZWCUL_1)
2018.04.03 10:14:54 4: ZWCUL set ZWCUL_1 addNode on
2018.04.03 10:14:54 3: ZWCUL going to assigning new node id 02
2018.04.03 10:14:54 5: SW: zm9
2018.04.03 10:14:55 5: ZWCUL_1 ca89f3b0 S:0d F:01 f:0 SN:d L:14 T:01 P:32022134000000000000 C:ce
2018.04.03 10:14:55 5:    F: singleCast
2018.04.03 10:14:55 5: ZWCUL_1: dispatch 00040d0d0a32022134000000000000
2018.04.03 10:14:56 4: CMD:APPLICATION_COMMAND_HANDLER ID:0d ARG:0a32022134000000000000 CB:0d
2018.04.03 10:14:56 4: ZWave: unknown message 00040d0d0a32022134000000000000 for ID 0d
2018.04.03 10:14:58 5: ZWCUL_1 d0e1bd2e S:00 F:01 f:0 SN:1 L:1f T:ff P:0101539c0107015e308084708559718672737a5aef C:8a
2018.04.03 10:14:58 5:    F: singleCast
2018.04.03 10:14:58 5: ZWCUL_Write 88888888 0013000801030288888888####
2018.04.03 10:14:58 5: SW: zs88888888014101110001030288888888af
2018.04.03 10:14:59 5: ZWCUL_1 d0e1bd2e S:00 F:03 f:0 SN:1 L:0a T:01 P: C:54
2018.04.03 10:14:59 5:    F: ack
2018.04.03 10:14:59 5: SW: zr4
2018.04.03 10:14:59 5: ZWCUL_1: dispatch 004a000302####07##5e308084708559718672737a5aef
2018.04.03 10:14:59 3: ZWCUL_1: Unknown code 004a000302####07##5e308084708559718672737a5aef, help me!
2018.04.03 10:14:59 5: ZWCUL_1 fw-resend nr 2
2018.04.03 10:14:59 5: ZWCUL_1 fw-resend nr 3
Titel: Antw:ZWave @ culfw
Beitrag von: rudolfkoenig am 04 April 2018, 21:26:57
Danke fuer den Hinweis, daran sieht man, dass ich seit zwei Jahren nicht mehr ernsthaft mit ZWCUL gearbeitet habe, und offensichtlich auch sonst keiner ZWCUL verwendet. Bei der Anpassung in ZWave.pm vor einem Jahr wegen STACKABLE habe ich die Pruefung der Input-Daten verschaerft, aber ZWCUL dabei vergessen. Ich habe jetzt ZWCUL nachgezogen, ich hoffe, es klappt besser.
Titel: Antw:ZWave @ culfw
Beitrag von: Beta-User am 06 April 2018, 15:43:46
Zitat von: rudolfkoenig am 04 April 2018, 21:26:57
... und offensichtlich auch sonst keiner ZWCUL verwendet. Bei der Anpassung in ZWave.pm vor einem Jahr wegen STACKABLE...
Zur Info: Ich hatte vor einiger Zeit mal den erfolglosen Versuch unternommen, einen 2-fach Fibaro-Switch mit ZWCUL und einem MapleCUN@STACKABLE ans Laufen zu bekommen. Da ich sonst weder ein passendes IO habe noch weitere Z-Wave-Hardware, habe ich das erst mal sein gelassen.

Wenn Interesse besteht, kann ich gerne den Tester für ZWCUL und STACKABLE machen, in jedem Fall werde ich jetzt nochmal einen Anlauf nehmen, ob das jetzt "einfach so" funktioniert!

Meine Defs:

define MapleStack2 STACKABLE mapleCUN2
define z100k ZWCUL FHEM:DEVIO:MapleStack2:9600 64757433 01
attr z100k dataRate 100k
define MapleStack3 STACKABLE z100k
define z40k ZWCUL FHEM:DEVIO:MapleStack3:9600 00000000 01
attr z40k dataRate 9600

(Transceiver1 ist 868@HM, Transceiver2 mit 433MHz steht auf SlowRF, die Benennung@9600 hat historische Gründe...)

Für Hilfe bin ich selbstredend dankbar, Firmware des Maple ist 1.26.irgendwas, Z-Wave-Unterstützung sollte also vorhanden sein.

Gruß, Beta-User
Titel: Antw:ZWave @ culfw
Beitrag von: eisler am 12 April 2018, 13:31:30
anlernen, auch secure funktioniert jetzt mit er neuen ZWCUL Version problemlos.  :)

Grüße
Stephan
Titel: Antw:ZWave @ culfw
Beitrag von: rudolfkoenig am 12 April 2018, 14:38:36
Danke fuer das Feedback.
Ich dachte bisher, dass Secure-Inclusion mit ZWCUL nicht geht, weil die Nachrichten beim Secure-Inclusion teilweise laenger als 64Byte lang sind, und das dafuer noetige sliding-window-Verfahren im culfw/zwave noch nicht implementiert ist.
Titel: Antw:ZWave @ culfw
Beitrag von: Christian. am 19 Januar 2019, 08:51:12
Hallo zusammen,

ich würde ZWCUL gern zur Diagnose als Monitor für den Funkverkehr verwenden, habe aber ein Problem bei der Einbindung des Moduls. Beim define erfragt das Modul die Versionsnummer vom CUL (ZWCUL Revision 16552, Zeile 138). Über die Leitung scheint bei mir aber vor dem V (0x56) immer noch ein Byte 0xE0 zu gehen. Deshalb scheitert die Moduldefinition:


2019.01.19 08:04:33 3: Setting zwcul serial parameters to 38400,8,N,1
2019.01.19 08:04:33 4: ZWCUL_ReadAnswer arg:Clear regexp:wontmatch
2019.01.19 08:04:33 5: SW: V
2019.01.19 08:04:33 4: ZWCUL_ReadAnswer arg:Version regexp:^V
2019.01.19 08:04:34 5: SW: V
2019.01.19 08:04:34 4: ZWCUL_ReadAnswer arg:Version regexp:^V
2019.01.19 08:04:35 5: SW: V
2019.01.19 08:04:35 4: ZWCUL_ReadAnswer arg:Version regexp:^V
2019.01.19 08:04:35 5: zwcul: dispatch ? (ÓV is unknown) Use one of A B C E e F f G h i K k l M m R T t U V W X x Y Z z


Die Anbindung des Arduinos über das Modul CUL (anstatt ZWCUL) funktioniert. Wenn ich manuell per Terminal ein V sende, bekomme ich die Versionsnummer als Antwort:
V 1.67 nanoCUL868
Ich vermute deshalb das Problem innerhalb des Perl-Codes, möglicherweise in ZWCUL.

Die culfw-Version ist 1.67. Ich habe zwei unterschiedliche Arduinos getestet, den USB-Port gewechselt, es unter Windows und Linux probiert und neben der aktuellen FHEM-Version auch das Release 5.9 und 5.8 probiert. Das Verhalten bleibt dabei immer unverändert. Die einzige Konstante ist noch die PC-Hardware.

Ist ZWCUL in der aktuellen Version grundsätzlich funktionsfähig? Hat jemand eine Idee, woran es liegen könnte?
Titel: Antw:ZWave @ culfw
Beitrag von: rudolfkoenig am 19 Januar 2019, 09:17:47
ZitatIst ZWCUL in der aktuellen Version grundsätzlich funktionsfähig?
ZWCUL habe ich seit laengerem nicht angefasst, es spricht aber nichts dagegen, dass es funktioniert.
Wenn es "neue" Probleme gibt, dann definitiv nicht an dieser Stelle.
Versuch mal das Geraet als CUL zu definieren, dieses Modul wird aktuell tausendfach eingesetzt.
Ich tippe auf eine Hardware (nanoCUL?) Besonderheit.
Titel: Antw:ZWave @ culfw
Beitrag von: Christian. am 19 Januar 2019, 09:31:17
Danke für die schnelle Antwort.

Ich habe die Lösung gefunden: Der Timeout in Zeile 129
$hash->{RA_Timeout} = 0.5; # Clear the pipe
ist für mein System zu niedrig. Ab einem Wert von 1.5 gibt es keine Kommunikationsprobleme bei der Moduldefinition mehr.

Da ich ZWCUL nur einmalig provisorisch einbinden möchte, bin ich schon damit zufrieden, den Wert manuell im ZWCUL-Code anzupassen. Ich frage mich allerdings schon, was es mit dem Timeout auf sich hat, in welcher Weise mein System speziell ist und ob der Wert konfigurierbar sein sollte...
Titel: Antw:ZWave @ culfw
Beitrag von: dmq am 03 März 2019, 14:58:06
Hi,

ich habe diesen + weitere Thread(s) teils intensiv gelesen dann aber auch wieder etwas überflogen - ich habe mir den MapleCUN mit 9600 40k 100k Z-Wave Stackable mit ZWCUL angelegt. Ich bekomme auch die Z-Wave Telegramme meines Netzes.

Ist irgendwo eine Beschreibung für die folgenden Inhalte vorhanden:

S:
F:
f:
SN:
L:
T:
R:
P:
C:

+ ggf. weitere?

Bei der Analyse kann man ja schon einiges erahnen - aber falls es dokumentiert ist, wäre ich über einen Link sehr dankbar.

Wo wären bspw. der Payload - bspw. die Ausgabe eines Sensors und wie ist es kodiert?

Danke vielmals
Titel: Antw:ZWave @ culfw
Beitrag von: rudolfkoenig am 03 März 2019, 16:11:43
ZitatIst irgendwo eine Beschreibung für die folgenden Inhalte vorhanden:
In ITU.G9959, ab Abschnitt 8.1.2.1.1.1.
Erweiterungen wie Explorer Frames sind da aber mW nicht beschrieben, und ich kenne diese auch nicht.

ZitatWo wären bspw. der Payload - bspw. die Ausgabe eines Sensors und wie ist es kodiert?
Z.Bsp. in SDS13781

Ist dein Ziel eine Clean-Room Implementation eines ZWave Stacks?
Titel: Antw:ZWave @ culfw
Beitrag von: dmq am 03 März 2019, 17:03:54
ZitatIn ITU.G9959, ab Abschnitt 8.1.2.1.1.1.
Erweiterungen wie Explorer Frames sind da aber mW nicht beschrieben, und ich kenne diese auch nicht.

Super, danke. Das gucke ich mir an.

ZitatZ.Bsp. in SDS13781

Ist dein Ziel eine Clean-Room Implementation eines ZWave Stacks?

Nein, ich ärgere mich gerade mit SECURITY und WakeUp Geräten herum. Ich habe ein Keyfob welches SECURITY unterstützt ich es aber nicht zum laufen bekomme. Ich würde daher gerne eine Replay-Attack fahren, um mir damit endgültig zu beweisen, die Dinger besser los zu werden. Selbst harmlose Sachen wie Licht schalten fühlen sich dann für mich nicht mehr gut an :)

Zusätzlich würde ich mein Netzwerk natürlich gerne viel lieber mit dieser Implementierung hier betreiben - aber ich denke da gibt es (noch) zu viele Einschränkungen und zu wenig Mitstreiter.
Titel: Antw:ZWave @ culfw
Beitrag von: rudolfkoenig am 03 März 2019, 17:27:20
ZitatIch würde daher gerne eine Replay-Attack fahren, um mir damit endgültig zu beweisen, die Dinger besser los zu werden.
Wenn Du das hinkriegst, kannst vmtl. mit dem Verfahren Geld verdienen.

Zitataber ich denke da gibt es (noch) zu viele Einschränkungen und zu wenig Mitstreiter.
Sehe ich auch so.
Titel: Antw:ZWave @ culfw
Beitrag von: dmq am 03 März 2019, 17:29:32
ZitatWenn Du das hinkriegst, kannst vmtl. mit dem Verfahren Geld verdienen.

Ich meine jetzt auf das Klartext Z-Wave. Siehst Du da große Herausforderungen, die ich momentan nicht sehe?

Titel: Antw:ZWave @ culfw
Beitrag von: A.Harrenberg am 03 März 2019, 17:36:34
Hi,

ich kann da leider aus beruflichen Gründen nicht mehr wirklich unterstüzten, aber eine Replay-Attacke ist eher unwahrscheinlich. Die einzige Schwachstelle von S0-Security ist das man den Schlüssel während der Inklusion abgreifen könnte da dieser nur mit einem festen (und bekannten) Schlüssel gesichert ist. Danach ist es eine "Challenge and Response" mit einer Checksumme die nur auf das gesamte Paket passt. Damit ohne den Schlüssel irgendwas anstellen zu wollen ist unwahrscheinlich solange man keinen Quantencomputer zum Knacken der Verschlüsselung besitzt...

Die Probleme mit Security und Batteriebetriebenen Geräten sind u.a. der Architektur des Sendestacks der ZWave-Implementierung von Fhem geschuldet. Ich habe mich jetzt lange nicht mehr darum kümmern können, aber ohne ein re-design wird das schwierig bleiben.

Das ganze wird mit S2-Security sicherlich nicht einfacher und ich habe es mit meinen damaligen Versuchen nicht geschafft das Verschlüsselungsverfahren nachzuvollziehen.

So wie es momentan aussieht werde ich auch noch ein paar Monate nicht dazu kommen daran weiter zu arbeiten. ;-(

Gruß,
Andreas.
Titel: Antw:ZWave @ culfw
Beitrag von: rudolfkoenig am 03 März 2019, 17:47:58
ZitatIch meine jetzt auf das Klartext Z-Wave.
Mein Hinweis bezog sich auf die verschluesselte Verbindung. Wenn mit "Klartext Z-Wave." die unverschluesselte Variante gemeint ist, dann geht das viel einfacher: HomeId setzen (egal ob in ZWDongle oder ZWCUL), ein ZWave Geraet mit passenden Klassen definieren, und beliebige Befehle senden. Damit der eigentliche Kontroller nicht dazwischenfunkt, kann man dem Angreifer-Controller eine unbesetzte nodeId zuweisen.

Titel: Antw:ZWave @ culfw
Beitrag von: dmq am 03 März 2019, 17:58:39
Hi Andreas, Hi Rudolf,

danke für deine bisherige Arbeit Andreas, Rudolf ohnehin :)

ZitatSo wie es momentan aussieht werde ich auch noch ein paar Monate nicht dazu kommen daran weiter zu arbeiten.

Das ist natürlich sehr schade - vom Gefühl her war Z-Wave und SECURITY in FHEM Andreas Harrenberg :) Ich bin seit heute morgen mal alle Themen in der Hinsicht am durchwühlen. Entwicklungstechnisch ist das zeitbedingt momentan auch eine Nummer zu groß für mich :( Ich bräuchte dafür auch erst einmal einen ganz schönen Anlauf.

Ich glaube ich habe mich eben etwas sperrig ausgedrückt. Ich plane keine Replay-Attacke auf S0 / S2. Ich habe einen Keyfob der S0 unterstützt (siehe 1) - aber ich kriege es nicht ans laufen. Nun wollte ich für mich persönlich einschätzen, wie schwierig ein Replay-Angriff bzw. die Snifferei auf den Klartext ist.

ZitatMein Hinweis bezog sich auf die verschluesselte Verbindung. Wenn mit "Klartext Z-Wave." die unverschluesselte Variante gemeint ist, dann geht das viel einfacher: HomeId setzen (egal ob in ZWDongle oder ZWCUL), ein ZWave Geraet mit passenden Klassen definieren, und beliebige Befehle senden. Damit der eigentliche Kontroller nicht dazwischenfunkt, kann man dem Angreifer-Controller eine unbesetzte nodeId zuweisen.

Oder so, das ist in der Tat einfacher :) Aber das macht es umso schlimmer :(

Danke euch und schönen Abend,
dmq

(1): https://forum.fhem.de/index.php/topic,98073.0.html
Titel: Antw:ZWave @ culfw
Beitrag von: dmq am 03 März 2019, 18:57:58
Zitatdann geht das viel einfacher

Noch mal danke - das ist leider wirklich vernichtend einfach. Auf die Idee wäre ich jetzt tatsächlich nicht in erster Linie gekommen. War eher auf dem "RAW" Trip.
Titel: Antw:ZWave @ culfw
Beitrag von: A.Harrenberg am 03 März 2019, 20:12:08
Hi,

na ja, was hast Du erwartet? Das ist ein unverschlüsseltes Protokoll das mittlerweile offengelegt ist. "Damals" war das alles noch etwas schwieriger da man alles "reverse engineering" musste oder auf ältere Unterlagen, die "geleaked" waren, angewiesen war.

Seit April 2018 dürfen neuen Geräte nur noch mit S2-Security zertifiziert werden, d.h. das wird sich jetzt ziemlich schnell verbreiten. Allerdings muss dann auch S2 in Fhem implementiert werden, wobei die Geräte eigentlich auch auf S0 rückwärtskompatibel sein sollten.

ZWave ist damit sicherlich das sicherste Funkprotokoll im Homebereich. Die Szenarien zur Abfangen von Schlüsseln, Re-play attacken etc. sind sicherlich denkbar, aber nicht wirklich wahrscheinlich. Heutzutage wird sicherlicher eher die Haustür eingetreten als versucht das Schloss zu hacken... Aber das ist meine persönliche Meinung.

Gruß,
Andreas.
Titel: Antw:ZWave @ culfw
Beitrag von: dmq am 03 März 2019, 20:42:02
Hi,

Zitatna ja, was hast Du erwartet?

Ja, leider genau das. Ich hatte nun leider auch bereits Rauchmelder etc. in der Hand, wo SECURITY drauf stand, die sich aber nicht mit SECURITY integrieren liessen. Und viele WakeUP Geräte sind sicherheitssensibel (Bewegungsmelder, Rauchmelder, Keyfobs). Wenn das nicht robust integrierbar ist, schalten die Leute die Sicherheit aus.

ZitatZWave ist damit sicherlich das sicherste Funkprotokoll im Homebereich.

Von der Spezifikation bin ich bei Dir - das war auch damals für mich der Grund, mir Komponenten auf der Basis anzuschaffen. Auch bereits mit S0 damals die beste Spezifikation im Vergleich. Aber wie gesagt, wenn sich die Komponenten dann nicht integrieren / betreiben lassen...

ZitatSeit April 2018 dürfen neuen Geräte nur noch mit S2-Security zertifiziert werden, d.h. das wird sich jetzt ziemlich schnell verbreiten. Allerdings muss dann auch S2 in Fhem implementiert werden, wobei die Geräte eigentlich auch auf S0 rückwärtskompatibel sein sollten.

Bzw. die Inklusion wird wahrscheinlich auch noch gänzlich ohne SECURITY gehen befürchte ich. Ich hoffe sehr, dass sich jemand findet, der S2 und vllt. auch die WakeUp-Implementierung in FHEM beisteuert bzw. überarbeitet. Ich würde helfen, wo ich kann - auch Sponsoring (Geräte, vllt. könnte man auch eine Wallet oder so anlegen).

ZitatDie Szenarien zur Abfangen von Schlüsseln, Re-play attacken etc. sind sicherlich denkbar, aber nicht wirklich wahrscheinlich.

Auch hier bin ich bei Dir - die Übertragungsleistung wird sollte für den Austausch ja meistens auch korrekterweise noch herunter geregelt werden. Aber ich stehe dieses Wochenende nun schon zum 3. Mal vor dem Szenario wo ich Probleme mit der S0 Integration von Z-Wave Geräten habe und das wird auch anderen so gehen. Ich denke die wenigsten sagen sich aber danach, dass sie die Komponenten dann besser nicht einsetzen.

ZitatHeutzutage wird sicherlicher eher die Haustür eingetreten als versucht das Schloss zu hacken... Aber das ist meine persönliche Meinung.

Ja, das mag sein. Ich bin nur ein Verfechter von Security + Privacy by Default. Es gibt ja noch viele andere Szenarien außerhalb des Einbruchs: CO-Melder, Rauchmelder etc.

Viele Grüße,
dmq

edit: lt. Z-Shave Sicherheitsanalyse findet das herunterregeln bei S0 doch nicht in den meisten Fällen statt. Wollte ich so nicht im Raum stehen lassen.
Titel: Antw:ZWave @ culfw
Beitrag von: dmq am 03 März 2019, 20:57:13
ZitatZWave ist damit sicherlich das sicherste Funkprotokoll im Homebereich.

Wobei man das auch nochmal aktuell gegenüberstellen sollte. Ich stelle mal folgende Protokolle in den Ring :)

BT5 Security Level 4
Thread
Zigbee High Security mOde