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.
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.
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.
Hi Rudi,
Zitat von: rudolfkoenig am 28 November 2015, 08:15:26
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...
Zitat von: rudolfkoenig am 28 November 2015, 08:15:26
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.
Zitat von: A.Harrenberg am 27 November 2015, 22:43:40
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.
ZitatWenn 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.
ZitatFü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?
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.
Zitat von: A.Harrenberg am 28 November 2015, 11:46:55
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.
Hi Christian
Zitat von: krikan am 28 November 2015, 13:27:20
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.
Zitat von: krikan am 28 November 2015, 13:27:20
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.
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.
Zitat von: A.Harrenberg am 28 November 2015, 16:50:53
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...
Hi Christian,
Zitat von: krikan am 28 November 2015, 17:18:41
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.
Zitat von: krikan am 28 November 2015, 17:18:41
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.
Zwei Herren behaupten in diesem (https://sensepost.com/cms/resources/conferences/2013/bh_zwave/Security%20Evaluation%20of%20Z-Wave_WP.pdf) 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.
Hi Rudi,
Zitat von: rudolfkoenig am 29 November 2015, 13:19:48
Zwei Herren behaupten in diesem (https://sensepost.com/cms/resources/conferences/2013/bh_zwave/Security%20Evaluation%20of%20Z-Wave_WP.pdf) 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.
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.
Hallo Rudi,
Zitat von: rudolfkoenig am 29 November 2015, 15:02:10
CC1110 = CC1101+Prozessor
ah, Danke!
Zitat von: rudolfkoenig am 29 November 2015, 15:02:10
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.
Zitat von: rudolfkoenig am 29 November 2015, 15:02:10
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.
Zitat von: A.Harrenberg am 29 November 2015, 12:42:43
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
Hi Christian,
ok, hast Du denn jetzt eine Möglichkeit das culfw auf den nanoCul zu bekommen oder musst Du warten bis das a_culfw portiert ist? Ich habe die Antwort von Locotus so verstanden das es "out of the box" erst mal nicht möglich ist.
Gruß,
Andreas.
Zitat von: A.Harrenberg am 30 November 2015, 10:03:09
ok, hast Du denn jetzt eine Möglichkeit das culfw auf den nanoCul zu bekommen oder musst Du warten bis das a_culfw portiert ist? Ich habe die Antwort von Locotus so verstanden das es "out of the box" erst mal nicht möglich ist.
Ja, muss für loctus-cul-Variante auf Portierung in a_culfw warten. Ich selbst versuche mich erst gar nicht daran. "Normaler" CUL kommt deshalb auch noch; ist ja bald Weihnachten ;) .
Hallo Rudi,
ich habe jetzt ein wenig Zwave "gesnifft" und mir kommen langsam Zweifel daran das es sich hier um ein Problem mit den Geräten bzw. der Reichweite handelt.
Das Problem mit dem USB der virtuellen Maschine werde ich noch prüfen, habe gerade ein altes Laptop mit kaputtem Akku rausgekramt und installiert das in den nächsten Tagen mal, aber ich bekomme den Verdacht das es im ZWave-Code einen Bug gibt oder ein anderes Modul uns da in die Suppe spuckt... ;-(
Laut dem Logfile von FHEM wurde der Code vom RFID-Pad erkannt und eine entsprechende Alarmmeldung (vom Gerät) verschickt und von FHEM bestätigt. Danach hat das Gerät dann angeblich 4 mal WUN geschickt, die jedesmal bestätigt wurden.
Dies passiert allerdings SEHR schnell:
19:46:23.561 / 19:46:23.566 / 19:46:23.571 / 19:46:23.584
Also angeblich 4 Übertragungen in nur 13 milisekunden! Gesnifft ist da aber nur EINE WUN mit EINER Bestätigung...
Ich bin mir nicht ganz sicher, aber ich halte es für ausgeschlossen das man diese 4 Nachrichten überhaupt in der Zeit senden kann.
2015.12.06 19:46:20.542 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 000400090a7105000000ff06060101
2015.12.06 19:46:20.542 5: SW: 06
2015.12.06 19:46:20.544 5: ZWDongle_0 dispatch 000400090a7105000000ff06060101
2015.12.06 19:46:20.544 4: ZWDongle_0 CMD:APPLICATION_COMMAND_HANDLER ID:09 ARG:0a7105000000ff06060101
2015.12.06 19:46:23.561 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 00040009028407
2015.12.06 19:46:23.561 5: SW: 06
2015.12.06 19:46:23.562 5: ZWDongle_0 dispatch 00040009028407
2015.12.06 19:46:23.562 4: ZWDongle_0 CMD:APPLICATION_COMMAND_HANDLER ID:09 ARG:028407
2015.12.06 19:46:23.566 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 00040009028407
2015.12.06 19:46:23.566 5: SW: 06
2015.12.06 19:46:23.567 5: ZWDongle_0 dispatch 00040009028407
2015.12.06 19:46:23.567 4: ZWDongle_0 CMD:APPLICATION_COMMAND_HANDLER ID:09 ARG:028407
2015.12.06 19:46:23.571 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 00040009028407
2015.12.06 19:46:23.573 5: SW: 06
2015.12.06 19:46:23.574 5: ZWDongle_0 dispatch 00040009028407
2015.12.06 19:46:23.574 4: ZWDongle_0 CMD:APPLICATION_COMMAND_HANDLER ID:09 ARG:028407
2015.12.06 19:46:23.584 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 00040009028407
2015.12.06 19:46:23.593 5: SW: 06
2015.12.06 19:46:23.594 5: ZWDongle_0 dispatch 00040009028407
2015.12.06 19:46:23.594 4: ZWDongle_0 CMD:APPLICATION_COMMAND_HANDLER ID:09 ARG:028407
2015.12.06 19:46:24.567 5: ZWDongle_Write 00 13090284082509
2015.12.06 19:46:24.567 5: SW: 010900130902840825094e
2015.12.06 19:46:24.569 5: ACK received, WaitForAck=>2 for 010900130902840825094e
2015.12.06 19:46:24.579 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 011301
2015.12.06 19:46:24.579 5: SW: 06
2015.12.06 19:46:24.580 5: ZWDongle_0 dispatch 011301
2015.12.06 19:46:24.602 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 001309000002
2015.12.06 19:46:24.602 5: SW: 06
2015.12.06 19:46:24.603 5: device ack reveived, removing 010900130902840825094e from dongle sendstack
2015.12.06 19:46:24.603 5: ZWDongle_0 dispatch 001309000002
2015.12.06 19:46:24.604 4: ZWDongle_0 CMD:ZW_SEND_DATA ID:00 ARG:0002
2015.12.06 19:46:24.604 4: ZWDongle_0 transmit OK for 09
zE173B78D09410114017105000000FF0606010180
zE173B78D0103010A0957
zE173B78D0941020C01840793
zE173B78D0103020A0954
zE173B78D01410D0C09840893
zE173B78D09030D0A015B
Ebenso habe ich auch bei einen Fall gesnifft bei dem FHEM nicht auf das Gerät reagiert hat, der CUL war hier sogar weiter vom Gerät weg als der USB-Stick von FHEM. Hier wurde die Nachricht drei Mal wiederholt, und kam einwandfrei am CUL an, FHEM hatte gar nichts im Log...
Ich hätte jetzt aber keine Idee wo bzw wie ich suchen soll...
Hast Du Ideen/Meinungen dazu?
Gruß,
Andreas.
Reichweite: ein CUL hat normalerweise eine "richtige" Antenne (auch wenn es ein Draht ist), die Antennen der 2 Dongles, die ich bisher gesehen habe, sind bzgl. Reichweite "schlecht" (Goodway) oder "sehr schlecht" (zme). Zusaetzlich koennte ein CC1101 auch besseren Empfang bieten, muss ja nicht zwei Frequenzen gleichzeitig ueberwachen. Das ist alles nur eine _moegliche_ Erklaerung einer besseren Reichweite.
Zeitliche Aufloesung: Ein "durchschnittliches" Paket mit 40kBaud dauert ca 4ms, mit 100kBaud 1.6ms. Deine Abstaende waren 5ms, 7ms, 20ms. Vielleicht verschwendet culfw die Zeit mit zccRX() oder sonstwo, und verpasst so Nachrichten. Bei mir funktioniert 100kBaud nicht, deswegen vermute ich, dass der 100k Empfang in culfw noch nicht korrekt ist.
USB/anderes Modul/Suppe: Ich kann mir weder USB noch ein anderes FHEM-Modul oder fhem.pl als Ursache fuer wiederholte Auslieferung von Daten vorstellen. Ein Firmware Problem eher.
Kannst du nicht dein RFID Leser auf 40k zwingen? Hat den zusaetzlichen Vorteil eines potentiell besseren Empfangs: wenn jemand doppelt so schnell spricht, kann man ihn auch schlechter verstehen :)
Hi Rudi,
Zitat von: rudolfkoenig am 07 Dezember 2015, 08:20:26
Reichweite: ein CUL hat normalerweise eine "richtige" Antenne (auch wenn es ein Draht ist), die Antennen der 2 Dongles, die ich bisher gesehen habe, sind bzgl. Reichweite "schlecht" (Goodway) oder "sehr schlecht" (zme). Zusaetzlich koennte ein CC1101 auch besseren Empfang bieten, muss ja nicht zwei Frequenzen gleichzeitig ueberwachen. Das ist alles nur eine _moegliche_ Erklaerung einer besseren Reichweite.
yep, ich stimme Dir zu, aber die Entfernungen sind nun wirklich nicht groß, RFID-Pad/Dongle ca. 3m (allerdings mit einer Mauer dazwischen), RFID-Pad/CUL ist ca. 4.5 m.
Zitat von: rudolfkoenig am 07 Dezember 2015, 08:20:26
Zeitliche Aufloesung: Ein "durchschnittliches" Paket mit 40kBaud dauert ca 4ms, mit 100kBaud 1.6ms. Deine Abstaende waren 5ms, 7ms, 20ms. Vielleicht verschwendet culfw die Zeit mit zccRX() oder sonstwo, und verpasst so Nachrichten. Bei mir funktioniert 100kBaud nicht, deswegen vermute ich, dass der 100k Empfang in culfw noch nicht korrekt ist.
[...]
Kannst du nicht dein RFID Leser auf 40k zwingen? Hat den zusaetzlichen Vorteil eines potentiell besseren Empfangs: wenn jemand doppelt so schnell spricht, kann man ihn auch schlechter verstehen :)
Das Netz mit dem RFID Leser ist auf 40k, daher ja meine Vermutung das die Übertragungen gar nicht in der Geschwindigkeit stattfinden können, immerhin ist da ja angeblich auch ein ACK dabei...
Das System lief ja eigentlich stabil ohne Auffälligkeiten. Dazwischen waren halt größere Umbauten in ZWave, aber auch der Umzug meines Systems auf eine virtuelle Maschine.
Zitat von: rudolfkoenig am 07 Dezember 2015, 08:20:26
USB/anderes Modul/Suppe: Ich kann mir weder USB noch ein anderes FHEM-Modul oder fhem.pl als Ursache fuer wiederholte Auslieferung von Daten vorstellen. Ein Firmware Problem eher.
Hmm, falls culfw evtl. Nachrichten verpasst wäre das natürlich fatal... Wenn ich davon ausgehen das dort alle Nachrichten angezeigt werden müsste es ja ein Firmwareproblem im ZWaveDongle sein, und das hätten andere sicherlich auch schon bemerkt.
Ich werde noch mal einen Test machen indem ich das ZWave-Dongle abschirme und dann sehe ob das RFID-Pad dann die Pakete wiederholt und ich die alle am culfw sehen kann. Ansonsten werde ich heute abend mal den Laptop weiter einrichten und dann das System mal dort weiterlaufen lassen und schauen sich dann was am Verhalten ändert.
Ich kann mir auch nicht wirklich vorstellen was einerseits ein mehrfaches Empfangen von Nachrichten, andererseits ein Ausbleiben einer Nachricht erklären kann. Wenn Du auch keine Idee hast dann warten wir mal ab was der Test auf dem echten Rechner ergibt.
Gruß,
Andreas.
P.S.: 100kBaud -> Gibt es andere Systeme (HM?) die mit 100kBaud auf dem Cul arbeiten? Dann könnte man dort mal nach den Parametern für Bandbreite etc. schauen.
ZitatGibt es andere Systeme (HM?) die mit 100kBaud auf dem Cul arbeiten?
HM und MAX sind 10 oder 20 kBaud (da bin ich unsicher).
RFR/FastRF ist 250kBaud.
Wo hast du G-FSK / bWidth etc her?
Hi Rudi,
die meisten Infos sind von hier:
http://www.rfwireless-world.com/Tutorials/z-wave-tutorial.html
Wobei ich aber die bandbreite auf den 325kHz (Voreinstellung von TI) belassen habe. Die "Deviation" müsste ich mir noch mal anschauen, ich denke das man hiermit den Empfang am ehesten beeinflussen kann. In der Spec wird 58 kHz angegeben, daher müsste theoretisch 58/2 -> 29 kHz eingestellt werden...
Gruß,
Andreas.
Hallo Rudi,
das mit dem ausprobieren auf dem Laptop klappt schon mal nicht... Das Ding stürzt schon im normalen Betrieb ab ,-(
Muss mal sehen ob ich jetzt meinen alten Server noch mal rauskrame und den nutzen kann.
Zitat von: rudolfkoenig am 07 Dezember 2015, 10:45:19
HM und MAX sind 10 oder 20 kBaud (da bin ich unsicher).
RFR/FastRF ist 250kBaud.
Wenn FastRF mit 250 kBaud auf dem CUL läuft, sollte es mit 100kBaud / ZWave doch auch keinen Engpass geben was Verarbeitungsgeschwindigkeit angeht...
Wird eigentlich irgendwo / irgendwie gemeldet falls der Buffer von dem CC "überläuft"? Ich gehe aber doch davon aus das der Atmel sich die Sachen dort per IRQ abholt, oder?
Gruß,
Andreas.
ZWAVE/HM/MAX/etc in culfw pollen den CC1101.
Ich stelle die Paketlaenge auf 255 ein, und bitte das CC1101 ein Pin zu setzen, falls 8 Bytes in RX-FIFO sind. Falls Pin gesetzt, lese die 8 Bytes, Byte 8 enthaelt die ZWave-Paketlaenge, danach lese ich die CC1101 solange, bis ich alle Daten habe. Danach faengt alles von vorne an.
Alles in rf_zwave_task(), was in Endlosschleife aufgerufen wird.
CUL 3.1 hatte Probleme mit FastRF, die anderen Modelle mWn nicht.
Hi Rudi,
Zitat von: rudolfkoenig am 07 Dezember 2015, 19:23:24
ZWAVE/HM/MAX/etc in culfw pollen den CC1101.
Ich stelle die Paketlaenge auf 255 ein, und bitte das CC1101 ein Pin zu setzen, falls 8 Bytes in RX-FIFO sind. Falls Pin gesetzt, lese die 8 Bytes, Byte 8 enthaelt die ZWave-Paketlaenge, danach lese ich die CC1101 solange, bis ich alle Daten habe. Danach faengt alles von vorne an.
Alles in rf_zwave_task(), was in Endlosschleife aufgerufen wird.
CUL 3.1 hatte Probleme mit FastRF, die anderen Modelle mWn nicht.
das wird jetzt hier vielleicht recht OT... ;-)
D.h. der Pin am CC löst keinen IRQ aus, sondern wird nur in rf_zwave_task() genutzt um das auslesen anzustossen. Was passiert denn wenn weniger Bytes kommen als in der Länge angegeben ist? Gibt es da auch eine Art Timeout? Sonst würden ja dann das die ersten Bytes der nächsten Nachricht ausgelesen werden und die CS würde nicht stimmen, die Pakete würden dann durcheinander kommen...
Gruß,
Andreas.
P.S.: Der Server läuft schon mal jetzt muss ich das FHEM da mal rüberkopieren...
Weiss ich nicht....
Hallo,
so, der Server läuft rudimentär, den CUL habe ich zum Sniffen mit eingebunden, allerdings nicht als zwcul, die Kiste will momentan irgendwie nicht mit dem Internet reden...
Aus den bisherigen Logs werde ich allerdings noch nicht so wirklich schlau ,-(
- Messages tauchen im CUL teilweise 50ms früher auf als in Zwave, da ist anscheinend eine relativ große Totzeit dazwischen.
- Mehrfache WUN kommen immer noch, auch wenn ich den RFID-Leser auf den Schreibtisch hole und die Neighborlist aktualisere
- Bisher habe ich einmal zwei WUN beim CUL gesehen während Zwave 4 gesehen hat, ansonsten immer eine bei CUL, 4 bei ZWave
- Wenn ZWave sendet ist die Antwort vom Gerät SOFORT da, d.h. die tauch bei CUL/RAW bereits in der gleichen Zeile auf -> Geräte antworten SEHR schnell...
- Die Acknowledge Nachrichten im Netz kommen mMn viel früher als das ACK in FHEM (auch wenn ich die Totzeit betrachte), daher vermute ich fast das "unser" ACK nur dem Controller gilt und der selbstätig eine Acknowledge Nachricht absetzt falls die empfangene Nachricht iO ist.
Erstes Fazit ist erst mal nur das es anscheinend nicht an der virtuellen Umgebung liegt, das Phänomen tritt auch auf einem echten Rechner auf.
Ich werde jetzt mal anfangen ein paar Sachen aus der Config zu löschen um zu sehen ob es evtl. an weiteren Modulen oder meinen Erweiterungen liegt.
Allerdings muss ich dann wieder "zurückbauen", sonst leidet der WAF.
Gruß,
Andreas
Hi,
hier mal ein Logausschnitt (jetzt wieder von der virtuellen Maschine)
40kBaud, RFID-Leser liegt ca. 0.5m neben dem Dongle, Routing findet anscheinend nicht statt
Hier kommt der Code vom Leser bei CUL an, quasi gleichzeitig gibt es eine Bestätigungsnachricht:
2015.12.07 21:59:18.866 5: CUL/RAW: /zE173B78D09410114017105000000FF0606010180
2015.12.07 21:59:18.866 4: CUL_Parse: CUL_1 zE173B78D09410114017105000000FF0606010180
2015.12.07 21:59:18.868 2: CUL_1: unknown message zE173B78D09410114017105000000FF0606010180
2015.12.07 21:59:18.876 5: CUL/RAW: /zE173B78D0103010A0957
2015.12.07 21:59:18.876 4: CUL_Parse: CUL_1 zE173B78D0103010A0957
2015.12.07 21:59:18.879 2: CUL_1: unknown message zE173B78D0103010A0957
Jetzt kommt der Code bei ZWave an und es wird ein ACK generiert:
2015.12.07 21:59:18.883 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 000400090a7105000000ff06060101
2015.12.07 21:59:18.883 5: SW: 06
2015.12.07 21:59:18.884 5: ZWDongle_0 dispatch 000400090a7105000000ff06060101
2015.12.07 21:59:18.884 4: ZWDongle_0 CMD:APPLICATION_COMMAND_HANDLER ID:09 ARG:0a7105000000ff06060101
Hier kommt die WUN bei CUL an, wieder quasi gleichzeitig die Bestätigungsnachricht:
2015.12.07 21:59:21.894 5: CUL/RAW: /zE173B78D0941020C01840793
zE173B78D0103020A0954
2015.12.07 21:59:21.894 4: CUL_Parse: CUL_1 zE173B78D0941020C01840793
2015.12.07 21:59:21.895 2: CUL_1: unknown message zE173B78D0941020C01840793
2015.12.07 21:59:21.896 4: CUL_Parse: CUL_1 zE173B78D0103020A0954
2015.12.07 21:59:21.897 2: CUL_1: unknown message zE173B78D0103020A0954
Jetzt kommt die WUN bei ZWave an und es wird ein ACK generiert.
Dann kommen drei weitere WUN/ACK die vom CUL nicht gesehen werden (weil sie nicht da sind?)
2015.12.07 21:59:21.897 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 00040009028407
2015.12.07 21:59:21.897 5: SW: 06
2015.12.07 21:59:21.898 5: ZWDongle_0 dispatch 00040009028407
2015.12.07 21:59:21.898 4: ZWDongle_0 CMD:APPLICATION_COMMAND_HANDLER ID:09 ARG:028407
2015.12.07 21:59:21.902 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 00040009028407
2015.12.07 21:59:21.902 5: SW: 06
2015.12.07 21:59:21.903 5: ZWDongle_0 dispatch 00040009028407
2015.12.07 21:59:21.903 4: ZWDongle_0 CMD:APPLICATION_COMMAND_HANDLER ID:09 ARG:028407
2015.12.07 21:59:21.907 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 00040009028407
2015.12.07 21:59:21.907 5: SW: 06
2015.12.07 21:59:21.908 5: ZWDongle_0 dispatch 00040009028407
2015.12.07 21:59:21.908 4: ZWDongle_0 CMD:APPLICATION_COMMAND_HANDLER ID:09 ARG:028407
2015.12.07 21:59:21.911 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 00040009028407
2015.12.07 21:59:21.911 5: SW: 06
2015.12.07 21:59:21.912 5: ZWDongle_0 dispatch 00040009028407
2015.12.07 21:59:21.912 4: ZWDongle_0 CMD:APPLICATION_COMMAND_HANDLER ID:09 ARG:028407
Jetzt wird die WUNMI von ZWave gesendet:
2015.12.07 21:59:22.902 5: ZWDongle_Write 00 13090284082509
2015.12.07 21:59:22.902 5: SW: 010900130902840825094e
2015.12.07 21:59:22.905 5: ACK received, WaitForAck=>2 for 010900130902840825094e
2015.12.07 21:59:22.920 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 011301
2015.12.07 21:59:22.920 5: SW: 06
2015.12.07 21:59:22.921 5: ZWDongle_0 dispatch 011301
Hier kommt die WUNMI bei CUL an, danach die Bestätigung vom Gerät:
2015.12.07 21:59:22.922 5: CUL/RAW: /zE173B78D01410C0C09840892
2015.12.07 21:59:22.922 4: CUL_Parse: CUL_1 zE173B78D01410C0C09840892
2015.12.07 21:59:22.924 2: CUL_1: unknown message zE173B78D01410C0C09840892
2015.12.07 21:59:22.926 5: CUL/RAW: /zE173B78D09030C0A015A
2015.12.07 21:59:22.926 4: CUL_Parse: CUL_1 zE173B78D09030C0A015A
2015.12.07 21:59:22.928 2: CUL_1: unknown message zE173B78D09030C0A015A
2015.12.07 21:59:22.945 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 001309000003
2015.12.07 21:59:22.945 5: SW: 06
2015.12.07 21:59:22.946 5: device ack reveived, removing 010900130902840825094e from dongle sendstack
2015.12.07 21:59:22.946 5: ZWDongle_0 dispatch 001309000003
2015.12.07 21:59:22.946 4: ZWDongle_0 CMD:ZW_SEND_DATA ID:00 ARG:0003
2015.12.07 21:59:22.946 4: ZWDongle_0 transmit OK for 09
Ehrlich gesagt glaube ich nicht das der CUL Nachrichten verschluckt...
Empfangsprobleme kann ich bei der Entfernung eigentlich auch ausschliessen...
Ich kann jetzt noch mal den Empfangsbuffer von ZWDongle mit Lognachrichten zupflastern, für weitere Ideen wäre ich dankbar.
Gruß,
Andreas.
Hallo Andreas,
leider kann ich nicht wirklich etwas hilfreiches beitragen, außer meiner Behauptung, dass es in Deinem System begründet ist. Ich logge ZWave im Produktivsystem mit verbose 5 und bin jetzt alle WUN im Dezember durchgegangen und kann solche Dopplungen nicht feststellen. Immer nur eine. Hast Du mal probiert bspw. den AEOTEC Sensor mit einzubinden? Hat der das Problem dann auch?
Gruß, Christian
Hi,
hier mal ein Log mit ein paar zusätzlichen Logmessages in ZWDongle.pm
2015.12.07 22:59:10.048 5: CUL/RAW: /zE173B78D0941020C01840793
2015.12.07 22:59:10.049 4: CUL_Parse: CUL_1 zE173B78D0941020C01840793
2015.12.07 22:59:10.051 2: CUL_1: unknown message zE173B78D0941020C01840793
2015.12.07 22:59:10.053 5: ZWDongle RAW buffer: 0110000400090a7105000000ff06
2015.12.07 22:59:10.055 5: ZWDongle RAW buffer: 0110000400090a7105000000ff0606
2015.12.07 22:59:10.058 5: ZWDongle RAW buffer: 0110000400090a7105000000ff060601
2015.12.07 22:59:10.059 5: ZWDongle RAW buffer: 0110000400090a7105000000ff06060104
2015.12.07 22:59:10.059 5: CUL/RAW: /zE173B78D0103020A0954
2015.12.07 22:59:10.059 4: CUL_Parse: CUL_1 zE173B78D0103020A0954
2015.12.07 22:59:10.066 2: CUL_1: unknown message zE173B78D0103020A0954
2015.12.07 22:59:10.066 5: ZWDongle RAW buffer: 0110000400090a7105000000ff0606010466
2015.12.07 22:59:10.066 4: ZWDongle_Read ZWDongle_0: sending ACK, processing 000400090a7105000000ff06060104
2015.12.07 22:59:10.067 5: SW: 06
2015.12.07 22:59:10.070 5: ZWDongle_0 dispatch 000400090a7105000000ff06060104
2015.12.07 22:59:10.071 4: ZWDongle_0 CMD:APPLICATION_COMMAND_HANDLER ID:09 ARG:0a7105000000ff06060104
2015.12.07 22:59:13.076 1: PERL WARNING: Use of uninitialized value $camret in concatenation (.) or string at ./FHEM/49_IPCAM.pm line 234.
2015.12.07 22:59:13.083 1: ProcessSendStack called
2015.12.07 22:59:13.086 5: ZWDongle RAW buffer: 0108000400090284077b0108000400090284077b0108000400090284077b0108000400090284077b
Hier kommt die WUN bei CUL an:
2015.12.07 22:59:10.051 2: CUL_1: unknown message zE173B78D0941020C01840793
Nachdem ZWave dann mit der auslesen der vorher gesendeten Nachricht fertig ist, befinden sich plötzlich 4 Nachrichten im ZWDongle buffer...
Und FHEM ist hier auch irgendwie 3 sekunden schlafen gegangen...
Alles SEHR merkwürdig!
@Krikan: Die Idee mit dem AEOTEC war mir eben auch gekommen, schaffe ich aber heute nicht mehr. im Testsystem ist mir das bisher auch nicht aufgefallen.
Gruß,
Andreas.
Hallo,
ich denke ich habe mein Mysterium gelöst, das ganze wird anscheinend durch das IP_CAM Modul verursacht.
Mir ist gestern aufgefallen das es keine Verzögerung/mehrfaches Empfangen gibt wenn ich einen "ungültigen" Code am RFID-Leser eingebe. Der wird ein anderer Befehl gesendet der dann in FHEM keine Notify triggert.
Ich habe dann mal meine Notify Definitionen auseinandergenommen da ich dachte das eines der verwendeten "sleep" blockieren würde, die habe ich aber alle schön in FHEM gemacht.
Letztendlich bin ich dann gerade auf das IP_CAM Modul gestossen, in dem Notify schalte ich die Bewegungserkennung der Kamera über das Modul aus, und das scheint FHEM zu blockieren. Hier muss ich mir jetzt eine andere Lösung einfallen lassen...
Weitere Erkenntnisse:
- Die ACK in ZWave sind nur für die Kommunikation mit dem Dongle, die "echten" Acknowledge Nachrichten werden vom Dongle selbstätig gesendet
- Der Dongle sendet anscheinend neu wenn er kein ACK bekommt, daher wohl die mehrfachen WUN im Buffer
Die drei Sekunden Pause hätten mir natürlich früher auffallen können, dann wäre ich sicherlich auch früher auf die Idee gekommen nach etwas blockierendem zu suchen und nicht auf Empfangsprobleme oder Bufferprobleme zu tippen.
Gruß,
Andreas.
ZitatDer Dongle sendet anscheinend neu wenn er kein ACK bekommt, daher wohl die mehrfachen WUN im Buffer
Das sollten wir in 00_ZWDongle fixen, sonst taucht das Problem bei anderen auch auf.
Ideen, wie ein Fix aussehen koennte? Eigentlich ist das ein klassisches Problem, weil das Wiederholen der Nachricht bei fehlenden Ack ueblich ist.
Hi,
keine Ahnung wie ein FIX aussehen könnte oder sollte...
Der Dongle macht ja alles richtig, FHEM ist blockiert und reagiert nicht. Allerdings wird dann jede Nachricht aus dem Buffer beim Dongle mit ACK bestätigt, wobei der die alten ja bereits "verworfen" hat und neu gesendet hat, d.h. da werden zu viele ACK geschickt die evtl. beim Dongle zu Verwirrung mit weiteren Nachrichten führen könnten.
Mir fällt gerade nichts ein mit dem man erkennen könnte das die weiteren Nachrichten nur Wiederholungen/Resends vom Dongle sind. Auf der Funkebene gibt es den Sequence-Counter der bei wiederholten Nachrichten gleich bleibt, d.h. da kann man einen Resend erkennen, bei der Kommunikation zwischen Dongle und FHEM fehlt da aber solch ein counter ,-(
Könnte man evtl. die Zeit zwischen zwei Aufrufen für das I/O (Receive) ermitteln und bei Überschreiten einer maximalen Zeit wenigstens eine Warnung im Log ausgeben die auf mögliche Blockade hinweist?
Mehr fällt mir dazu erst mal nicht ein.
Das war ja aber nur die eine Hälfte meines Problems, jetzt muss ich noch rauskriegen warum der RFID-Leser manchmal gar keine Verbindung zum Dongle bekommt und das recht offensichtlich auch nicht geroutet wird. Hier könnte es ein Problem sein das die Übertragung (mit ExplorerFrame) manchmal direkt funktioniert und die Routingtabelle dann den direkten Kontakt enthält. Wenn die Node dann keine direkte Verbindung bekommt kann die Node kein Routing bzw. ExplorerFrame auslösen, das kann mMn nur der Controller...
Ich bin mir da noch nicht ganz sicher wie das abläuft, aber in dem Fall könnten ExplorerFrames schlecht sein, da hier das Routing bei guten Verbindungen evtl. "abgeschaltet" wird und die Node es dann nicht mehr aktivieren kann. Ich muss mir die Erklärungen zu den ExplorerFrames noch mal genau durchlesen und schauen ob das zu dem Verhalten führen könnte.
Hier ist sicherlich noch eine Menge Analyse der Funknachrichten nötig.
Gruß,
Andreas.
Zitat von: A.Harrenberg am 08 Dezember 2015, 11:24:14
Mir fällt gerade nichts ein mit dem man erkennen könnte das die weiteren Nachrichten nur Wiederholungen/Resends vom Dongle sind. Auf der Funkebene gibt es den Sequence-Counter der bei wiederholten Nachrichten gleich bleibt, d.h. da kann man einen Resend erkennen, bei der Kommunikation zwischen Dongle und FHEM fehlt da aber solch ein counter ,-(
Könnte man evtl. die Zeit zwischen zwei Aufrufen für das I/O (Receive) ermitteln und bei Überschreiten einer maximalen Zeit wenigstens eine Warnung im Log ausgeben die auf mögliche Blockade hinweist?
Mehr fällt mir dazu erst mal nicht ein.
Wie bereits mal geschrieben: ozw und zway messen permanent Telegrammlaufzeiten und verwerfen mEn, wenn es zu lange dauert. Vielleicht hängt dies damit zusammen.
ZitatExplorerFrames
Jaja, hack nur auf "meinen" Explorer Frames (EF) rum ;)
Ich verstehe Deine Aussage zu EF aber auch nicht. Das Dongle versucht erst diverse "normale" Telegramme, bevor EF zum Einsatz kommen. EF schalten nichts ab, sondern versuchen über eine Art Rundruf über alle Geräte (die EF unterstützen) das Zielgerät zu erreichen und setzen die Routen quasi neu. Das löst nur eine erhebliche Funklast in größeren Netzen aus. Bei Deinem Netz mit 2? Geräten sollte das aber doch keine Katastrophe sein. Es sei denn, der Zwischenstecker kann keine EF. ozw handhabt das genauso wie FHEM: immer EF.
Was für einen vorsichtigeren EF-Einsatz spricht: zway nutzt EF nur beim Startup einige Zeit lang und mEn bei Änderungen im Netz. Anschließend wird wieder auf ohne EF-Telegramme geschaltet.
Gruß, Christian
Das Simpelste natürlich vergessen: Was passiert denn, wenn Du die EF bei den Geräten aussschaltest? Ist dann Dein Problem gelöst? Falls ja, ...
Hi Christian,
die Funklast mit ExplorerFrames ist mir ziemlich egal, das sollte kein Problem darstellen.
Meine Befürchtung ist:
- Routing Tabelle existiert, ZWDongle soll eigentlich routen (da Empfang grenzwertig)
- Durch ExplorerFrame oder direktes Senden stellt der Controller irgendwann mal fest das er die Node auch direkt erreichen kann und ändert die Routingtabelle entsprechend
- Neue Nachrichten werden dann direkt geschickt, Node hat ja keine eigene RoutingInfo und übernimmt direkte Route auch für sich
- Falls direktes Senden der Node jetzt fehlschlägt kommt Paket nicht an, da Node nicht aktiv routen kann
- Falls das direkte Senden des Controllers fehlschlägt kann er Routing/ExplorerFrame nutzen
Das Abschalten der ExplorerFrames im Netz hatte ich auch vor, vorher wollte ich aber mal erst mal schauen was da an Funktelegrammen unterwegs ist und wie geroutete Pakete überhaupt aussehen, bisher hatte ich nämlich noch keins...
Ob meine obige Befürchtung so haltbar ist, muss erst mal eine erneute Lekture des Pätz und die Analyse der Funknachrichten ergeben.
Problem bei der Sache ist für mich irgendwie nachzuvollziehen wie der Controller routen will, die "Routing Tabelle" ist ja im Prinzip erst mal nur eine "Nachbarschaftstabelle". In größeren Netzen sind ja meist mehrere Routen möglich, welche davon genutzt wird kann man ja anscheinend nicht auslesen.
Mir ist nicht klar wie ich dem Controller sage das er routen SOLL. Ich fürchte das ein Controller IMMER erst mal versucht das Gerät direkt zu erreichen, und erst wenn das nicht funktioniert auf Routing ausweicht. Mein Verständnis aus Sicht der Node ist das die sich die letzte (übertragene) Route merkt und damit sendet und selbst kein Fallback hat. (Ob Nodes ExplorerFrames senden dürfen ist mir nicht klar)
Ich werde da einfach noch ein wenig sniffen und analysieren und schauen ob man ein "Muster" erkennen kann.
Gruß,
Andreas.
Vermutlich ist analysieren der sicherste Weg. Ich habe zwar vermutlich geroutete Telegramme in den Logs, verstehe den Aufbau aber nicht.
Routing Slaves haben doch Teilinformationen der Routen. Dann gehst Du davon aus, dass immer nur eine Routing-Info gültig ist.
Nodes nutzen zumindest bei der netzweiten Inklusion Explorer Frames und aus Paetz 3.5.2 schließe ich, dass Nodes Explorer Frames eigenständig senden können.
Hi Chrisitian,
Zitat von: krikan am 08 Dezember 2015, 15:10:40
Vermutlich ist analysieren der sicherste Weg. Ich habe zwar vermutlich geroutete Telegramme in den Logs, verstehe den Aufbau aber nicht.
so ganz habe ich den Aufbau auch noch nicht verstanden, habe aber angefangen mir die Nachricht mit einem Perl-Script dekodieren zu lassen...
Und 100kBaud Nachrichten sehen leicht anders aus... (u.a. CRC16)
Zitat von: krikan am 08 Dezember 2015, 15:10:40
Routing Slaves haben doch Teilinformationen der Routen. Dann gehst Du davon aus, dass immer nur eine Routing-Info gültig ist.
Diese Teilinformation enthält aber mMn nach nur die letzte funktionierende Route...
Zitat von: krikan am 08 Dezember 2015, 15:10:40
Nodes nutzen zumindest bei der netzweiten Inklusion Explorer Frames und aus Paetz 3.5.2 schließe ich, dass Nodes Explorer Frames eigenständig senden können.
Das müsste ich dann noch mal nachlesen. Wenn aus der Analyse der Funknachrichten schon mal klar ist was ein ExplorerFrame ist kann man das ja mal analysieren, wobei ich den RFID-Leser eigentlich nicht ex-/inclludieren will da er dabei alle seine angelernten Codes/Tags vergisst. Da einige davon "außer Haus" sind wird es schwierig die wieder einzuprogrammieren...
Gruß,
Andreas.
Hi,
ich habe auf jeden Fall auch Empfangsprobleme... Hab' vergessen den Sender nach der Testsession am Schreibtisch an den normalen Ort zu hängen, daraufhin habe ich jetzt sehr viele Retransmits im Protokoll.
Ich habe in dem Netz mal testweise die ExplorerFrames ausgeschaltet und die Neighborlist neu abgefragt, ich hatte gestern aber keine Zeit mehr die Abfrage noch mal mit den "non-routers" zu machen um zu sehen ob die Steckdose den RFID-Leser auch (noch) drin hat, die non-routers werden ja bei der normalen Abfrage nicht gelistet.
Bisher habe ich dort aber noch keine geroutete Nachricht feststellen können...
ExplorerFrames habe ich zur "Vereinfachung" der Analyse jetzt zwar abgeschaltet, müssten aber eigentlich von allen Geräten (Dongle, Steckdose und RFID-Leser) unterstützt werden, zumindest wenn man sich auf die SDK Version verlässt.
Mal abwarten was jetzt im Log auftaucht.
Gruß,
Andreas.