mehrere WakeUpNotifications -> Empfangsproblem? Routingproblem?

[A.Harrenberg]

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.

[rudolfkoenig]

Der 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.

[A.Harrenberg]

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.

[krikan]

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.

ExplorerFrames

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

[krikan]

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, ...

[A.Harrenberg]

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.

[krikan]

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.

[A.Harrenberg]

Hi Chrisitian,

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)

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...

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.

[A.Harrenberg]

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.