mehrere WakeUpNotifications -> Empfangsproblem? Routingproblem?

[A.Harrenberg]

Hi,

in letzter Zeit habe ich anscheinend Empfangsprobleme mit meinem RFID-Pad. Da ich dies zum Entschärfen der Alarmanlage nutze ist das natürlich nicht besonders gut für den WAF wenn die Alarmanlage sich nicht abschalten lässt und dann losheult...

Ich habe jetzt einen ZWave-Steckdosenschalter als Router zwischen Controller und RFID-Pad platziert und die Neighborlist erneuert, dennoch scheint es mir das hier noch keine Besserung eingetreten ist. Anfänglich stand die WakeUpNotification noch auf "255" Broadcast, da dies ja nicht geroutet wird habe ich das auf "1" (Controller ID) geändert.

Wenn ich nun ein TAG einlese wird der TAG gemeldet, danach wird vom RFID-PAD eine WakeUpNotification gesendet. Diese empfange ich jetzt aber 3 oder 4 Mal direkt hintereinander, auch wenn der Steckdosenschalter nicht eingesteckt ist.

Für mich sieht es erst einmal so aus als ob der Steckdosenschalter nicht als Router agiert (wie kann man soetwas überhaupt feststellen?)
Das mehrfache Empfangen der WUN kann ich mir nur damit erklären das das ACK vom Controller nicht beim RFID-PAD ankommt und der dann mehrfach versucht bis endlich ein ACK zurückkommt.

Irgendwer eine Idee was hier abgeht?

Das ganze läuft auf einer virtuellen Maschine und der ZWaveDongle und ein Homematic USBcfg Stick werden vom Host an die virtuelle Maschine weitergereicht. Ich kann leider nicht ausschliessen das dies mit ein Grund für das merkwürdige Verhalten ist. Zumindest der HMLAN beschwert sich wegen zu großer Delays, ich glaube aber das dort nicht per API sondern auf LowLevel-Ebene gesteuert wird.

Code Auswählen Erweitern

2015.11.27 22:28:39.946 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 000400090a7105000000ff06060101
2015.11.27 22:28:39.948 4: ZWDongle_0 CMD:APPLICATION_COMMAND_HANDLER ID:09 ARG:0a7105000000ff06060101
2015.11.27 22:28:42.967 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 00040009028407
2015.11.27 22:28:42.968 4: ZWDongle_0 CMD:APPLICATION_COMMAND_HANDLER ID:09 ARG:028407
2015.11.27 22:28:42.971 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 00040009028407
2015.11.27 22:28:42.972 4: ZWDongle_0 CMD:APPLICATION_COMMAND_HANDLER ID:09 ARG:028407
2015.11.27 22:28:42.975 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 00040009028407
2015.11.27 22:28:42.976 4: ZWDongle_0 CMD:APPLICATION_COMMAND_HANDLER ID:09 ARG:028407
2015.11.27 22:28:42.980 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 00040009028407
2015.11.27 22:28:42.981 4: ZWDongle_0 CMD:APPLICATION_COMMAND_HANDLER ID:09 ARG:028407
2015.11.27 22:28:43.993 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 011301
2015.11.27 22:28:44.008 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 001309000002
2015.11.27 22:28:44.009 4: ZWDongle_0 CMD:ZW_SEND_DATA ID:00 ARG:0002
2015.11.27 22:28:44.009 4: ZWDongle_0 transmit OK for 09


Gruß,
Andreas.

[rudolfkoenig]

Waere ein Fall fuer einen low-level ZWave Sniffer.

Die VM-Theorie koennte man mit einer Installation ohne VM pruefen.
Ich halte es fuer unwahrscheinlich.

[A.Harrenberg]

Hi Rudi,

Waere ein Fall fuer einen low-level ZWave Sniffer.

ja, so ein Ding würde mich auch ungemein interessieren, vor allem was da auf Protrokollebene noch so alles passiert...

Die VM-Theorie koennte man mit einer Installation ohne VM pruefen.
Ich halte es fuer unwahrscheinlich.

Ich halte es beim ZWaveDongle auch für wenig wahrscheinlich, für eine Neuinstallation auf einem "echten" Rechner fehlt mir nur gerade ein verfügbarer "echter" Rechner...

Hast Du denn eine Idee wie ich prüfen kann ob das Ding überhaupt über den Steckdosenschalter geroutet wird? Die Routinginfos sind mMn im Protokollteil der Nachricht enthalten die wir über die API gar nicht lesen/sehen können, oder?

Gruß,
Andreas.

[krikan]

Anfänglich stand die WakeUpNotification noch auf "255" Broadcast, da dies ja nicht geroutet wird habe ich das auf "1" (Controller ID) geändert.

Blöde Frage  :Sicher? Im Wiki hast Du die Umstellung auf Controller von Anfang an beschrieben.

Wenn ich nun ein TAG einlese wird der TAG gemeldet, danach wird vom RFID-PAD eine WakeUpNotification gesendet. Diese empfange ich jetzt aber 3 oder 4 Mal direkt hintereinander, auch wenn der Steckdosenschalter nicht eingesteckt ist.

Normalerweise würde ich auf Assozierung mit mehreren Assogroup tippen. Aber laut ozw hat der Schlage nur eine.

Für mich sieht es erst einmal so aus als ob der Steckdosenschalter nicht als Router agiert (wie kann man soetwas überhaupt feststellen?)

Auf Rudi hoffen (Sniffer).

Hast Du mal resetet?

[A.Harrenberg]

Hi,

also die WUN habe ich mit 255 ausgelesen, mag sein das ich beim endgültigen Inkludieren in das Produktnetz vergessen habe das umzustellen.

Und ja, der hat nur eine AssociationGroup und die ist laut Anleitung für die Meldungen der ALARM class bzw. USERCODE class und sollte nichts mit den WUN zu tun haben.
Das "lustige" ist ja das ich aktuell je nach Laune der Gerätschaften 1-4 WUN bekomme...

Ja, so ein Sniffer hätte schon was

Und nein, ich habe nicht resettet und will das auch nicht. Die ganzen Codes wieder in das RFID-PAD einhacken ist doch recht umständlich...

Gruß,
Andreas.

[krikan]

Und ja, der hat nur eine AssociationGroup und die ist laut Anleitung für die Meldungen der ALARM class bzw. USERCODE class und sollte nichts mit den WUN zu tun haben.

Ich hätte jetzt behauptet, dass die WUN nicht ankommt, wenn ein Gerät nicht mit dem Controller assoziiert ist. Aber Du könntest Recht haben, dass das für WUN evtl. uninteressant ist. Hast Du dazu Erfahrungen/Infos?

mWn gibt es keine Möglichkeit die zuletzt genutzte Route auszulesen; habe nichts gefunden. Wäre für neigborList auch interessant.

[A.Harrenberg]

Hi Christian

Ich hätte jetzt behauptet, dass die WUN nicht ankommt, wenn ein Gerät nicht mit dem Controller assoziiert ist. Aber Du könntest Recht haben, dass das für WUN evtl. uninteressant ist. Hast Du dazu Erfahrungen/Infos?

ich bin mir nicht sicher ob wir hier nicht etwas aneinander vorbeireden...

Für die WakeUpNotification gibt man EIN Ziel an z.B. Controller ID oder 255 für Broadcast, das ist prinzipielle eine Art Association, taucht aber nicht unter Association auf, das dies eine Funktion der Wake_UP Klasse ist.
Für die eigentlichen Nachrichte des RIFD-Pad, also Lock/Unlock gibt es dann eine "echte" AssociationGroup, hier ist auch die Controller-ID eingetragen.
Also die WUN kam mit 255 genausogut oder schlecht am Controller an wie mit gesetzter Controller-ID.

mWn gibt es keine Möglichkeit die zuletzt genutzte Route auszulesen; habe nichts gefunden. Wäre für neigborList auch interessant.

Ich glaub' ich lese mir den Teil im Pätz noch mal durch... "Unser" Problem ist hier wahrscheinlich das da auf Protokollebene viel mehr Informationen über die Route(n) übertragen werden die wir nicht sehen/auslesen können.

Mein Verständnis ist das der Controller aus den neighborlists die Routen generiert und diese dann bei den Nodes setzt. (siehe z.B. auch S.208 in dem 400'er Document...) Dort steht das der Controller die kürzeste Route zwischen zwei Nodes (ich denke das hier auch Node-Controller möglich ist) und überträgt diese Route dann an die Node.

So eine Route müsste mMn aus 4 Byte (oder mehr Byte) bestehen um die "Hops" aufzunehmen. Standard ist meine ich das 4 Routing Schritte unterstützt werden.

Ich bin etwas unentschlossen ob ich mal so ein "AssignReturnRoute" manuell setzen sollte... Falls ich mir dabei das Netz zerschiesse ist der WAF endgültig im negativen Bereich... Außerdem muss ich dafür das Ding sicherlich wieder in den "Always on" Modus setzen.

Gruß,
Andreas.

[A.Harrenberg]

Hi,

das Dokument wird immer interessanter...

S.14 beschreibt die Implementierung eines Routing Slaves: So ein Node hat KEINE vollständige Routing Tabelle (was immer dann unvollständig bedeutet...), falls Routing nötig ist muss der Controller die Route berechnen.

Ich werde mal einen chinesischen Kollegen wegen des Dokumentes fragen...

Gruß,
Andreas.

[krikan]

S.14 beschreibt die Implementierung eines Routing Slaves: So ein Node hat KEINE vollständige Routing Tabelle (was immer dann unvollständig bedeutet...),

Ja, so etwas schwammiges steht auch im Pätz auf Pos. 1000 (Frage mich bitte nicht nach der Seite ) Kollegiale Hilfe wäre gut.

An dem anderen Thema WUN bin ich noch dran und mache Tests zu meinem Verständnis...

[A.Harrenberg]

Hi Christian,

Ja, so etwas schwammiges steht auch im Pätz auf Pos. 1000 (Frage mich bitte nicht nach der Seite ) Kollegiale Hilfe wäre gut.

wenn Du die Bemerkung in Kapitel 3.2.2 meinst, die ist dann auf S.87 (keine Ahnung ob es mehr als eine Auflage von dem Buch gibt)
Ich bin mir nur nicht sicher worauf Du bei "kollegialer Hilfe" hinaus willst. Von Pätz an uns?

Ich habe übrigens das RFID-Pad doch noch mal von der Wand abgenommen und in direkter Nähe zum Dongle getestet, auch dort gibt es eine unterschiedliche Anzahl an WUN. Es scheint mir daher kein direktes Reichweitenproblem zu sein. Ein mehrfaches Empfangen der eigentlichen Befehle ist mir bisher noch nicht aufgefallen, es scheint sich also nur um die WUN zu handeln.

An dem anderen Thema WUN bin ich noch dran und mache Tests zu meinem Verständnis...

Was testest Du denn da? Oder anders gefragt was willst Du mit Deinen Tests herausfinden?

@Rudi: Was für Hardware würde man denn für so einen "Sniffer" eigentlich benötigen?

Gruß,
Andreas.

[rudolfkoenig]

Zwei Herren behaupten in diesem Dokument, dass mit einem CC1110 sie ZWave Nachrichten empfangen haben. Sie haben mir netterweise auch die Registerbelegung zugeschickt, das komplette Firmware wollten sie mir aber nicht zur Verfuegung stellen. Der Tranceiver der CC1110 befindet sich auf dem beruechtigten CUL in Form einer CC1101, leider habe ich es nach einem kurzen Test nicht hingekriegt, damit ZWave Nachrichten abzufangen. Vermutlich muss ich mich laenger mit der Materie beschaeftigen.     

[A.Harrenberg]

Hi Rudi,

Zwei Herren behaupten in diesem Dokument, dass mit einem CC1110 sie ZWave Nachrichten empfangen haben. Sie haben mir netterweise auch die Registerbelegung zugeschickt, das komplette Firmware wollten sie mir aber nicht zur Verfuegung stellen. Der Tranceiver der CC1110 befindet sich auf dem beruechtigten CUL in Form einer CC1101, leider habe ich es nach einem kurzen Test nicht hingekriegt, damit ZWave Nachrichten abzufangen. Vermutlich muss ich mich laenger mit der Materie beschaeftigen.   

ok, schade das nicht die Firmware freigegeben wurde. Was hat es denn mit diesem Z-Force Projekt auf sich? Da kriegt man eine Exe und zwei BIN-Files als Firmware...

Stimmen die Nummern der CC so wie Du oben geschrieben hast? Laut Dokument wurde ein CC1110 benutzt, Du sagst das der auf einem CC1101 drauf sei??

Ich könnte mir jetzt zwar so ein Ding kaufen (was dann mit sma-Antenne und Gehäuse auf 75 Euro hinausläuft), ohne funktionierende Firmware ist das aber wohl wenig sinnvoll... Siehst Du denn eine realistische Chance da in absehbarer Zeit noch mal was dran zu machen? Welchen Stand hatte denn Dein kurzer Test?

Gruß,
Andreas.

[rudolfkoenig]

CC1110 = CC1101+Prozessor

Entweder willst du am Firmware mitbasteln/selbst hinkriegen: dann ist ein CUL eine hervorragende Grundlage, da compiler/FHEM-Einbindung/etc dokumentiert ist. Zum Debuggen reicht Draht, Abschirmung/Gehaeuse braucht man auch nicht. Oder du willst nur die "Fruechte" ernten, dann macht es aber keinen Sinn etwas auf Vorrat zu kaufen. Ich wuerde an deine Stelle nur dann damit anfangen, wenn ich etwa eine Woche Zeit uebrig haette oder ich CC1101+MCU kennen wuerde.

Mein Test hat gezeigt, dass ich kontinuirlichen Bit-Muell kriege. Ich muss jetzt verstehen, wie der CC1101 konfiguriert, ist, und ob ich auf Paketmode hoffen kann, oder selbst per MCU filtern muss. Und wenn letzteres, dann wie/was.

[A.Harrenberg]

Hallo Rudi,

CC1110 = CC1101+Prozessor

ah, Danke!

Entweder willst du am Firmware mitbasteln/selbst hinkriegen: dann ist ein CUL eine hervorragende Grundlage, da compiler/FHEM-Einbindung/etc dokumentiert ist. Zum Debuggen reicht Draht, Abschirmung/Gehaeuse braucht man auch nicht. Oder du willst nur die "Fruechte" ernten, dann macht es aber keinen Sinn etwas auf Vorrat zu kaufen. Ich wuerde an deine Stelle nur dann damit anfangen, wenn ich etwa eine Woche Zeit uebrig haette oder ich CC1101+MCU kennen wuerde.

Hmm, im Allgemeinen bin ich ja schon bereit mich auch in Sachen einzuarbeiten und dann auch mitzuarbeiten, hier bin ich aber unentschlossen. Ich habe einige eingerostete Kenntnisse in C und habe auch schon mal mit einem Atmel für Servoansteurung rumgespielt, ein CC1101 kenne ich aber gar nicht. Von daher brauche ich sicherlich deutlich länger als die von Dir angesetzte Woche Einarbeitung.

Vielleicht fange ich erst mal an die Dokumente zum CC1101 zu lesen, wenn ich da nur Hauptbahnhof verstehe lasse ich es.

Mein Test hat gezeigt, dass ich kontinuirlichen Bit-Muell kriege. Ich muss jetzt verstehen, wie der CC1101 konfiguriert, ist, und ob ich auf Paketmode hoffen kann, oder selbst per MCU filtern muss. Und wenn letzteres, dann wie/was.

"Kontinuierlicher Bit-Müll" hört sich jetzt erst mal noch nicht vielversprechend an... ,-)

Na ich schaue mir dann mal die Sachen zum CC1101 an.

Vielen Dank,
Andreas.

[krikan]

Was testest Du denn da? Oder anders gefragt was willst Du mit Deinen Tests herausfinden?

Hallo Andreas,
versuche herauszufinden, wo mein Gedankenfehler bei der WUN iZm Association/wakeupInterval liegt. Werde da demnächst mit Rudis Zwave@culw mal experimentieren und vorher nichts verraten  .
Gruß, Christian