Geloest :Razberry neighborlist update

Begonnen von Wolfgang Hochweller, 01 Juli 2016, 12:43:18

Vorheriges Thema - Nächstes Thema

Wolfgang Hochweller

Kann ich irgendwie feststellen, ob die Ausfuehrung diese Kommandos irgendetwas bewirkt ?
Mein Eindruck ist, das es das nicht tut; es aendert sich jedenfalls nie etwas.
Problematisch wird das dann, wenn ich ein Device zur Inklusion in die Naehe des Razberry bringen muss.
Wenn die neighborlist dann nie geaendert wird,  funktioniert das ganze System nur bedingt.

rudolfkoenig

Das Thema ist deutlich komplizierter, als man denkt:
- es gibt kein "neighborlist update", sondern "set XXX neighborUpdate" und "get XXX neighborList" :)
- neighborList enthaelt nur eine Liste von Nachbarn, ohne Wertung fuer die "Guete".
- nach welchem Algo der Transferweg ausgesucht wird, ist uns nicht bekannt
- wenn man die Funktelegramme per CUL beobachtet, dann sieht man bis zu vier Versuche, erst direkt, dann einfach oder doppelt indirekt ueber die Nachbarn.
- in einem mit einem CUL protokollierten Fall waren die Wege (Routes) immer gleich, auch nachdem ich (weil ich den Weg fuer kaputt gehalten habe) mehrere neighborUpdates durchgefuehrt habe.
- bei neueren Geraeten ist diese Liste auch halbwegs (ganz?) egal: falls es direkt nicht klappt, wird sofort mit den sog. "ExplorerFrames" versucht, dabei wird der Weg "selbstaendig" gesucht, was auch immer das heisst.

Ich waere fuer Praezisierung oder Details dankbar.

Wolfgang Hochweller

Meine Beobachtung sagt mir, dass ich nicht in der Lage bin, die neighborlist eines Devices zu aendern.
Mit im Extremfall fatalen Folgen : Ist die Liste einmal leer, dann bleibt sie dass auch.
Damit ist dieses Device nicht mehr in der Lage, etwas zu schicken.
Selbst wenn ich es vom Gateway noch erreichen koennte, hilft das nichts.

Welche neighborlist ein Device bei der Inklusion erhaelt scheint auch mehr oder weniger Zufall zu sein.
Ich habe direkt nacheinander 2 identische Devices inkludiert. Beides gleich erfolgreich, aber das eine von beiden erhielt eine
leere Liste, waehrend das andere saemtliche zu diesem Zeitpunkt verfuegbaren Nachbarn bekam.
Mit den ersten kann ich daher gar nicht kommunizieren, mit dem zweiten schon, bis ich es dann an seinen endgueltigen Platz in der
Garage bringe. In seiner Liste sind ja nur Devices , die bei der Inklusion die Nachbarn waren;  damit ist auch dieses Device 'tot'.
Da helfen dann auch ExploreFrames nicht weiter.

Das "set XXX neighborUpdate" hat offenbar Null Effekt ( zumindest aendert sich die Liste nie ), was mir dann doch verdaechtig erscheint.


Wolfgang Hochweller

#3
Immer dann, wenn bei 2 Devices die neighborlist etwas gemeinsam hat, funktioniert die Kommunikation problemlos; geht die Verbindung ueber mehrere Stationen, geht es meist auch gut, nur das Timing fuer das 'ACK' stimmt dann nicht mehr, Status geht dann meist  in 'TRANSMIT_NO_ACK'.
Allerdings verliert man dann die Gewissheit, ob etwas wirklich funktioniert hat, bzw. es wird sehr schwierig, wenn das Routing nur in einer Richtung funktioniert.
Beispeil : Ich habe in der Garage einen Philio Multisensor, der mir zuverlaessig Daten schickt. Aber auf Grund des verkorksten Routings bin ich nicht in der Lage, ihm oder den Nachbardevices in der Garage ein Kommando zu schicken.
Ich weiss also immer zuverlaessig, wann die Garage auf oder zu ist, aber auf- und zumachen geht nicht.

Ich habe verschiedenen Szenarien ausprobiert :

FHEM   -  Razberry  : Problem
FHEM -    UZB   : Problem
Domoticz (Openzwave)  -  Razberry  : Problem
Domoticz (Openzwave)  - UZB   : Problem

wobei Problem == Routingproblem


krikan

Ist Dir bekannt, dass batteriebetriebene Geräte nicht routen?
Du gibst leider die Nachbardevices in der Garage nicht an, so dass bei mir die obige Frage aufkommt.

Gruß, Christian

Wolfgang Hochweller

In der Garage befinden sich ausserdem noch ein Aeotec Smart Switch und ein Qubino 1D relay ( am Stromnetz ).
Beide haben eine unterirdische Reichweite ( die Garage ist etwa 8 m vom Gateway entfernt, aber mit Waenden dazwischen ),
und bringen fuer das Routing nichts, ich  habe schon Probleme, sie ueberhaupt zu erreichen.
Also habe ich noch einen Aeotec Repeater dazugefuegt.
Das bringt eine spuerbare Verbesserung, aber von kontrollierter Kommunikation kann keine Rede sein.

rudolfkoenig

Es gibt noch die herkoemmliche Methode von: "Antenne / Ausrichtung / relative Position verbessern".
Wobei die Antenne bei den ueblichen ZWave-Controllern auszutauschen in Bastelarbeit ausartet.

Wolfgang Hochweller

Mal sehen was passiert, wenn ich den Gateway in die Hausmitte versetze.
Was  mir ein bisschen Sorgen macht, ist das eigentlich alle Devices ( Repeater, Steckdosen, Schalter ) ein kritisches Reichweitenproblem haben.
Es kann doch nicht sein, dass das nur sicher funktioniert, wenn sich die Devices (optisch )sehen koennen.
Vielleicht muss ich auch mal untersuchen, wo der naechste LTE-Mast steht.
Das einzige Geraet, das da aus der Rolle faellt, ist der Multisensor von Philio; dessen Reichweite ist einfach super.

Wolfgang Hochweller

#8
Ich habe jetzt mal alles neu aufgesetzt, aber ohne echten Erfolg; ich komme mit den Z-wave Signalen nicht zuverlaessig vom Haus in die Garage und zurueck.
Um das zu praezisieren, es funktioniert auch nicht immer zuverlaessig, wenn die Devices nebeneinanderliegen.
Wenn ich den Aeotec Smart Switch inkludiere, kommt jedesmal etwas anderes heraus; mal ist die neighborlist emtpy, mal sind ein paar bekannte Devices zu finden, mal eine ganze Reihe mit Unknowns.
Selbst wenn alles gut aussieht, verlieren die Devices unkontrolliert ihre neighborlist, d.h. auf ein Mal sind alles Nodes als Unknown_x eingetragen.
Ob das jetzt ein FHEM-Problem, ein Zwave-Problem oder ein OpenZwave-problem ist, vermag ich nicht zu entscheiden.
Egal, was oder wer dafuer verantwortlich ist : Wenn dieses Setup so unzuverlaessig ist, hat FHEM/Z-Wave mit Sicherheit nur noch eine beschraenkte Lebensdauer.

MarkusAutomaticus

Zitat von: rudolfkoenig am 02 Juli 2016, 12:34:57
Es gibt noch die herkoemmliche Methode von: "Antenne / Ausrichtung / relative Position verbessern".
Wobei die Antenne bei den ueblichen ZWave-Controllern auszutauschen in Bastelarbeit ausartet.

Ich kann nur davor warnen, an der Antenne herumzubasteln, wenn man nicht 100% weiß, was man tut.
Ich habe dabei meinen RazBerry gekillt. Es war kein elektrisches sondern ein mechanisches Problem:
Die Antenne war zu starr/schwer und aufgrund der Hebelwirkung war ruckzuck ein Teil des SMD-Kondensators und des darunterliegenden Lötpads der Platine rausgebrochen.

Fazit: statt Reichweite vergrößert, auf ca. 2m verringert. 60€ verbrannt :'(
FHEM 5.8 |intel NUC Core i3: Ubuntu 22.04 | z-Wave: Aeon Labs USB Stick | Jeelink (v3c): LaCrosse-Sensoren | DuoFern Stick: Rademacher Gurtwickler | Philips Hue Bridge | CUNX: HomeMatic, EnOcean-Pigator