get ... config... -> Timeout

[A.Harrenberg]

Hi Christian,

Warum die Abfrageergebnisse bei verschiedenen Chipsätzen der Controller abweichen, ist mir weiterhin unklar.

Du hast in #28 aber auch gesagt das Du einer Node ein neighborUpdate gemacht hast und danach der Controller wieder dabei war, damit wäre der Chipsatz als alleiniger Verursacher ja eigentlich raus.

Da ich mich bisher mit Routen nicht beschäftigt habe, wie lese ich denn eine Route aus?

Die Neighborlist sagt ja noch nichts darüber aus wie die Route dann aussieht, besonders wenn es mehr als ein "Hop" wird. Soweit ich das verstanden habe "baut" der Controller sich seine Route anhand der Neighborlist, da er ja alle kennt, aber wie macht eine Node das?

Gruß,
Andreas.

[krikan]

Du hast in #28 aber auch gesagt das Du einer Node ein neighborUpdate gemacht hast und danach der Controller wieder dabei war, damit wäre der Chipsatz als alleiniger Verursacher ja eigentlich raus.

Der Controller war vor dem neigborUpdate drin und nachher auch noch. Mein Satz stand damit im Zusammenhang, dass FHEM "verdächtigt" wurde, nach einer Codeumstellung andere Ergebnisse zu liefern

Da ich mich bisher mit Routen nicht beschäftigt habe, wie lese ich denn eine Route aus?

Im Zusammenhang mit Explorer Frames habe ich danach gesucht, aber keine sinnvollen Infos gefunden. Also auch sehr wenig Ahnung. Kenne aber keine Funktion zum Auslesen, ausser die 0x80: GET_ROUTING_TABLE_LINE (400er Chipsatz: 0x80: GetRoutingInfo mit mehr Parametern). Und die oben genannten zum Löschen und Setzen, deren Sinn ich immer noch nicht verstanden habe und bisher als alte "Zöpfe" betrachtet habe.

@Toms01: Bisher von mir unterstellt: Der Betrieb mit ozw hat nach Wechsel zu FHEM keine Verbesserung Deines Problems gebracht. Ist das korrekt?

[A.Harrenberg]

Hi Christian,

Der Controller war vor dem neigborUpdate drin und nachher auch noch. Mein Satz stand damit im Zusammenhang, dass FHEM "verdächtigt" wurde, nach einer Codeumstellung andere Ergebnisse zu liefern

ok, dann habe ich das falsch verstanden.

Im Zusammenhang mit Explorer Frames habe ich danach gesucht, aber keine sinnvollen Infos gefunden. Also auch sehr wenig Ahnung. Kenne aber keine Funktion zum Auslesen, ausser die 0x80: GET_ROUTING_TABLE_LINE (400er Chipsatz: 0x80: GetRoutingInfo mit mehr Parametern). Und die oben genannten zum Löschen und Setzen, deren Sinn ich immer noch nicht verstanden habe und bisher als alte "Zöpfe" betrachtet habe.

Ok, das tröstet mich ein wenig das Du da auch keine weiteren Informationen hast. Ich denke ich schau mir noch mal die Erklärung von Paetz an, vielleicht kann man da noch was reindeuten ,-)

Gruß,
Andreas.

[krikan]

Ich denke ich schau mir noch mal die Erklärung von Paetz an, vielleicht kann man da noch was reindeuten ,-)

http://razberry.z-wave.me/docs/zwayDev.pdf unter 2.3 S. 27 steht auch etwas. Macht mich aber nicht schlauer.

[toms01]

@Toms01: Bisher von mir unterstellt: Der Betrieb mit ozw hat nach Wechsel zu FHEM keine Verbesserung Deines Problems gebracht. Ist das korrekt?

Das muss ich erst testen, da der Stick temporär zentral im Haus gelegen unter Domoticz/ozw läuft.
Sobald er an den FHEM-Platz umgezogen ist, ein "Netzwerk-Heal' ausgeführt wurde, kann ich das ausprobieren.
Alles andere funktioniert(e) ja.
Bin aber momentan arbeitstechnisch eingebunden, kann also noch 1-2 Tage dauern.

Aber nochmal zur Sicherheit: Ein bei einem batteriebetriebenen Gerät manuell ausgelöstes ZW_APPLICATION_UPDATE sollte definitiv durch das ganze Netz
geroutet werden können (ohne direkten Kontakt zum Controller), oder? Eventuell liegt es ja an den hinzugefügten AEOTEC Repeatern, vielleicht "verschlucken"
die ja irgendwelche Informationen.

[krikan]

Ein bei einem batteriebetriebenen Gerät manuell ausgelöstes ZW_APPLICATION_UPDATE sollte definitiv durch das ganze Netz
geroutet werden können (ohne direkten Kontakt zum Controller), oder?

Vermute nein. Warum auch? Durch das ganze Netz gehen ohne korrekt gesetzte Route bei einem Slave mWn nur Explorer Frames. Dann sind wir wieder bei falschen Routen....

Eventuell liegt es ja an den hinzugefügten AEOTEC Repeatern, vielleicht "verschlucken"
die ja irgendwelche Informationen.

Möglich. Hierzu gab es vor kurzem einen Thread in Bezug auf ZWave+ mit Antwort vom Hersteller. Müsstest Du mal suchen.

[toms01]

Vermute nein. Warum auch? Durch das ganze Netz gehen ohne korrekt gesetzte Route bei einem Slave mWn nur Explorer Frames. Dann sind wir wieder bei falschen Routen....

öhm, sorry - ich muss da einfach nochmal nachfragen, möchte das gern ansatzweise verstehen:

Wenn
- Fernbedienung korrekt assoziiert ist mit Controller
- Routen angenommen ok sind
- Fernbedienung kein direkten Kontakt (also nur indirekt über andere Nodes) mit Controller hat
müsste dann ZW_APPLICATION_UPDATE ankommen?

Sind dann Broadcasts an ID255 automatisch "Explorer Frames" oder wird da nur alles in der Neighborlist "abgearbeitet"?

[krikan]

@Thomas:
Keine Ahnung, ob ZW_APPLICATION_UPDATE per Broadcast läuft. Wird Broadcast geroutet? Falls ja, warum wurde dann NWI und Explorer Frames eingeführt, man hätte einfach Broadcast nutzen können?
In Doku findet sich bspw.:
"The routing slave can send unsolicited and non-routed broadcasts, singlecasts and multicasts.
Singlecasts can also be routed. [...] A received multicast or broadcast
results in a response route without routing."
Meine Vermutung daraus ist vermutlich klar, als Wissen würde ich es nicht bezeichnen.

@all
Abfrage der neigborList laut den mir vorliegenden Logs:
ozw, openhab: 80xy000003
zway: 80xy0000
funcId verstehe ich nun nicht mehr. ozw und openhab setzen die fest auf 03. zway setzt gar nichts. funcId=callbackId bin ich nicht mehr sicher.

[krikan]

@Thomas
Habe jetzt zu Hause noch mal meine gesammelten Notizen durchgeschaut:
- Broadcastnachrichten (Empfänger=alle Nodes) werden nicht geroutet. Jeder Node, der die Nachricht empfangen kann und will, kann sie verarbeiten. Mangels Routing eingeschränkte Reichweite.
- Explorer Frames / NWI  werden von allen Nodes mit Explorer Frames-Unterstützung verarbeitet und weitergeleitet.
- NIF wird in alter Doku (2002) als Broadcastnachricht bezeichnet. Ob APPLICATION_UPDATE auch per Broadcast oder Singlecast mit Routing abläuft, ist mir unbekannt. Tippe Broadcast, weil es zu Deinem Problem passen würde. Explorer Frames schließe ich aus.

Also Broadcast ungleich Explorer Frames.

[toms01]

Danke nochmals.

Habs hier
https://community.openhab.org/t/ge-switch-applicationupdate-message-to-trigger-rule/3562
in #2 gelesen. ApplicationUpdate wird nicht geroutet.

Also hab ich eigentlich kein Problem in diesem Sinne? Um neue Configs anzuschubsen bedarf es einfach Glück
um den Controller mit ApplicationUpdate zu erreichen?

Nachtrag:
Laut gedacht _kann_ das per Routing ja auch nicht funktionieren. Sonst würde ich ja nie eine Assoziation setzen können,
wenn das Ziel nicht bekannt ist

Nachtrag2:
Wie (besser wann) werden die Configs zu einem batteriebetriebenen Gerät gesendet?
Bei/nach einer Wakeup-Notification,oder? Diese wird auch manuell ausgelöst bei einem ApplicationUpdate vom Gerät.
Kommt das nicht an, dann werden die Configs spätestens bei dem gesetzen WakeupIntervall gesetzt.
Die Wakeup-Notification geht lt. Assoziation geroutet an den Controller. Falsch?

Nachtrag3:
Wobei man bei FHEM per WakeupIntervall ja setzen kann an wen die Meldung gehen soll.
Diese Zielsetzung habe ich übrigens bei z.B. Domoticz nicht gefunden, was wird dort als "Wakeup-Ziel"
angesehen? Der Default-Wert? Oftmals ja ID1 oder Broadcast

Nachtrag4:
Hierbei fragt sich, ob dann die Wakeup-Notification an ID1 auch per "Broadcast" versendet wird wie an ID255.
Dann wäre ja wieder nicht sichergestellt, dass diese Meldung auch ankommt.

[krikan]

Hallo Thomas!

Also hab ich eigentlich kein Problem in diesem Sinne? Um neue Configs anzuschubsen bedarf es einfach Glück
um den Controller mit ApplicationUpdate zu erreichen?

Nicht unbedingt Glück, sondern ausreichende Nähe zu Deinem Controller

Wie (besser wann) werden die Configs zu einem batteriebetriebenen Gerät gesendet?
Bei/nach einer Wakeup-Notification,oder?

Ja, siehe http://www.fhemwiki.de/wiki/Z-Wave#Ger.C3.A4te-Besonderheiten

Kommt das nicht an, dann werden die Configs spätestens bei dem gesetzen WakeupIntervall gesetzt.

Nein, gesendet ist gesendet. Die Daten gehen dann quasi verloren und Du musst die Config neu machen.

Die Wakeup-Notification geht lt. Assoziation geroutet an den Controller. Falsch?

Wakeup-Notification geht geroutet an Controller, wenn der als Empfänger der Nachricht eingestellt ist. Ist Broadcast 255 -was bei vielen Geräten standardmäßig eingestellt ist- nicht geändert, dann ungeroutet.
-> set <device> wakeupInterval

Diese Zielsetzung habe ich übrigens bei z.B. Domoticz nicht gefunden, was wird dort als "Wakeup-Ziel"
angesehen? Der Default-Wert? Oftmals ja ID1 oder Broadcast

Setzen vermutlich wmi automatisch auf Controller. ozw, openhab,... koppeln den User mehr von den ZWave-Interna ab. Das oben von Dir zitierte Healing, kann man auch mit FHEM machen; man muss es nur einrichten. Ich will z.B. nicht, dass so etwas automatisch abläuft; möchte die volle Kontrolle haben. Das ist auch einer der Gründe, warum ich bei FHEM gelandet bin. Ich werde hier nicht vom Programm bevormundet  .

Hierbei fragt sich, ob dann die Wakeup-Notification an ID1 auch per "Broadcast" versendet wird wie an ID255.

Nein, geroutet. Darum ist das auch immer stabiler. Ansonsten könnte man die batteriebetriebenen Geräte nur in Nähe des Controllers betreiben.

Jetzt die neugierige Frage: Kennst Du das FHEMWiki zu Zwave http://www.fhemwiki.de/wiki/Z-Wave? Vieles steht dazu mMn drin. Da ich aber einiges selbst geschrieben habe, ist es evtl. unverständlich, zu kurz, oder... Wenn Du Ergänzungs-/Verbesserungsvorschläge hast, kannst Du die im Wiki gerne aufnehmen bzw. ergänzen. Ich komme dazu momentan nicht.

Gruß, Christian

[toms01]

Hallo Christian,

danke für deine ausfühliche Antworten. Ja ich weiss - RTFM! - sorry dafür, aber das Problem mit dem Broadcast und dem eventuell
dann nicht-ankommen hatte ich dort nicht gefunden oder überlesen.

Ich schau nachher mal ob ich im wakeupIntervall eventuell den Broadcast habe, das würde ja das Ausbleiben der Wakeup-Notification
erklären und somit ist mein Problem gelöst.

Kurz noch zum Problem mit der Controller-Neighborlist:
Würde ihr das Verfahren zur Neighborlist dem des ozw-Projekts o.ä. anpassen, damit man wieder sehen kann welches Gerät
direkt mit dem Controller verbunden ist? Könnte man eine Neighborlist auch am Controller darstellen? (siehe gepostete
ozw-Topologie 1. Zeile)

[krikan]

Kurz noch zum Problem mit der Controller-Neighborlist:
Würde ihr das Verfahren zur Neighborlist dem des ozw-Projekts o.ä. anpassen, damit man wieder sehen kann welches Gerät
direkt mit dem Controller verbunden ist? Könnte man eine Neighborlist auch am Controller darstellen? (siehe gepostete
ozw-Topologie 1. Zeile)

Das ist Rudis Entscheidung. Wir könnten ihm zur Erleichterung und Entscheidungshilfe einen Patch liefern. Bin dann aber dafür alle Parameter wählbar zu machen. Letztlich zögere ich persönlich daran zu basteln, da mir immer noch der volle Einblick in ZW_GetRoutingInfo und den Parametern fehlt.

[A.Harrenberg]

Hi Christian, hi Thomas,

Das ist Rudis Entscheidung. Wir könnten ihm zur Erleichterung und Entscheidungshilfe einen Patch liefern. Bin dann aber dafür alle Parameter wählbar zu machen. Letztlich zögere ich persönlich daran zu basteln, da mir immer noch der volle Einblick in ZW_GetRoutingInfo und den Parametern fehlt.

das sollte ja machbar sein, die Frage ist wie immer nur die Umsetzung. Da es zwei Parameter mit zwei Möglichkeiten gibt müsste man 4 fest codierte Befehle daraus machen oder dem Benutzer ein Dropdown mit den 4 Möglichkeiten anbieten. Die Beschreibung der beiden Parameter ist jetzt nicht sooo eindeutig, aber mMn doch schon recht verständlich. Der erste Parameter bRemoveBad  sollte die Anzeige von eingetragenen aber nicht (mehr) funktionierenden Routen steuern, der zweite Parameter bRemoveNonReps die Anzeige der "non-Repeater" aka WakeUp-Geräte steuern. Warum beim zweiten Parameter dann auch der Controller ein- oder ausgeschaltet wird ist mir nicht klar.

Den "dritten" Parameter (funcID den ozw und openhab auf 03 setzen) würde ich da rauslassen. Ich habe da mal ein paar Tests mit gemacht und keinerlei Einfluß/Unterschied feststellen können.
Ich denke das diese funcId/CallBackFuntion nur für den internen Aufruf einer CallBackFunktion im GERÄT ist, und wir da über die API gar nicht dran kommen. (Wozu auch...)

Ich seh' aber schon das ich mich demnächst mal etwas mehr mit Routen beschäftigen muss... Nicht nur weil es da so wenige Informationen gibt, sondern auch aus praktischen Gründen da mein RFID-Pad in letzter Zeit häufiger ein Reichweitenproblem hat und ich da mal eine Steckdosenschalter als Router platzieren muss...

Gruß,
Andreas.

[krikan]

Hallo Andreas,

bin mit den 2 Parametern etwas unsicher. Suche mal "INS10682-9 400" für den 400er Chipsatz mit einer Suchmaschine. Demnach kann man bei der Abfrage auch noch wählen, ob nur 9600, 40k, 100k Geräte oder eben alle gemeldet werden. Wie verstehe ich nicht. Zu 9600 Abfrage hatte ich mal etwas gefunden; nur leider anscheinend nicht aufgeschrieben...

Den "dritten" Parameter (funcID den ozw und openhab auf 03 setzen) würde ich da rauslassen. Ich habe da mal ein paar Tests mit gemacht und keinerlei Einfluß/Unterschied feststellen können.
Ich denke das diese funcId/CallBackFuntion nur für den internen Aufruf einer CallBackFunktion im GERÄT ist, und wir da über die API gar nicht dran kommen. (Wozu auch...)

Könnte passen und schließe mich an. Z-way sollte wissen, wie es geht.

Gruß, Christian