Mesh Konfiguration auslesen

ggoetz56 · 18. August 2018 um 21:47

Als Beispiel anbei ein Auszug aus dem HC2Config vom HCToolkit. Dort kann man erkennen wie die IDs durcheinander geraten können. Ich frage mich, ob man dies durch eine geschickte Abfrage umgehen kann?
Da gibt es viele Möglichkeiten warum das nicht funktioniert. Wenn man tatsächlich ein Problem hat, bekommt man doch leicht heraus um welches Gerät es sich handelt. Ich würde da nichts mehr investieren. Ich finde das toll so.

Aber was sagt ihr denn dazu, dass diese Auswertungen nur teilweise was mit der Realität zu tun haben da die Datei die wir hier auswerten einfach nicht den wahren aktuellen Mesh enthält.

aendy · 19. August 2018 um 08:20

Aber was sagt ihr denn dazu, dass diese Auswertungen nur teilweise was mit der Realität zu tun haben da die Datei die wir hier auswerten einfach nicht den wahren aktuellen Mesh enthält.

Gibt’s denn schon konkrete Hinweise darauf? Könnte mir vorstellen, dass Fibaro das auch erst immer ausliest und dann bei den Geräten einträgt. In der Infobox steht manchmal so ein Text:

[07:39:27] 84: Requesting neighbor list from the node is in progress
[07:39:30] 84: New neighbor list received

Diese Uhrzeit steht dann übrigens auch so in der Scriptausgabe (+/- 1 Sek), weshalb ich mir vorstellen kann, dass Fibaro das nur immer aktualisiert, wenn mit dem Gerät kommuniziert wird. Die 84 war ein Fenster, welches ich betätigt habe.

Neighbours of device 84) Bettfenster : [65,79,108,113,142,167]
Last working route used by device 84 : [1,79]
Last WRRT for device 84: 07:39:31 - 19 Aug. 18

Eine Frage: Ist die Z-Wave Verwaltung überhaupt von Fibaro oder läuft da im Kern ein abgeschlossenes System der Z-Wave Alliance?

@jeep: Danke für den Hinweis. Einen RPi hab ich nicht. Hat sich somit erledigt.

jeep · 19. August 2018 um 11:24

@Ändy

Diese Uhrzeit steht dann übrigens auch so in der Scriptausgabe (+/- 1 Sek), weshalb ich mir vorstellen kann, dass Fibaro das nur immer aktualisiert, wenn mit dem Gerät kommuniziert wird. Die 84 war ein Fenster, welches ich betätigt habe.

Diese Vermutung teile ich mit Dir.

Eine Frage: Ist die Z-Wave Verwaltung überhaupt von Fibaro oder läuft da im Kern ein abgeschlossenes System der Z-Wave Alliance?

Die Zwave Verwaltung(senden,empfangen,ACK,routing, usw.) ist bestimmt nicht von Fibaro und befindet sich ausnahmslos im ZWave-Chip. Fibaro hat es auch nicht sehr gerne wenn man versucht internas über ihre Geräte im Forum zu diskutieren. Ich habe vor ein paar Tagen im Fibaro Forum dieses Statement (von petergebruers) gelesen: "I'd say routing is the secret sauce of Z-Wave." Und dass trifft bestimmt des Pudels Kern.

ggoetz56 · 19. August 2018 um 14:10

„I’d say routing is the secret sauce of Z-Wave.“
Ich glaube er hat das anders gemeint. Z-Wave Geräte funktionieren auch ohne Zentrale. Mit dem Routing an sich hat das HC nichts zu tun.

Ich habe ein Gerät ausgesteckt und die Route wurde in der API-Devices Auswertung 2 Tage falsch angezeigt (also über das ausgeschaltete Gerät) obwohl LWRRT laut API Device aktuell war. Reconfig des Mesh für betroffene Geräte hat nichts gebracht. Erst Neustart der Zentrale.
Ändere einen Namen eines Gerätes und frage Api Devices ab, dort tut sich nichts obwohl die Änderung in der GUI sauber angezeigt wird. Auch habe ich Geräte mit LWR [ ] also nichts. Die funktionieren und sind garantiert nicht in direkter Verbindung mit dem HC.

Ich denke wie dieser Table den wir hier auswerten zustande kommt ist ein großes Geheimnis von Fibaro und zwar weil die wissen dass er nicht stimmt. Und weil er benutzt wird um das HC und das Netz zu steuern und es deshalb Fehler gibt.

Ich habe sooft DeadNotes gehabt die nach Tagen plötzlich funktioniert haben in der Gui auch angzeigt wurden aber das Api war falsch. Das letzte war ein DanaLock das über das Hc nur funktioniert wenn ich einen Switch über die Türklinke gehängt habe. Ich habs dann aufgegeben. Es nur mit Bluetooth gesteuert. Nach einer Woche hat es sich über einen RGBW-Switch verbunden seitdem funktioniert es.

Ich glaube nicht an Geheimnis aber an Unkenntnis,. Wobei da nicht mal unbedingt Fibaroschuld sein muss. Ich hab im Us-Forum schon öfter die Meinung gehört dass ein bestimmtes Gerät eigentlich so gar kein Zwave Zertifikat hätte bekommen dürfen.

jeep · 19. August 2018 um 21:29

@Gerhard,
das ist mir schon klar was er gemeint hat und auch ich habe jede Menge PDFs von Sigma gelesen, aber “Routing” wird scheinbar doch
geheimgehalten. Hoffentlich nur für uns Enduser und nicht für die Hersteller.
Und wenn man sich das ganze noch mit dem Zniffer anschaut, ist man noch verwirrter. Denn leider kann ich das Notebook nicht immer dort positionieren wo die devices miteinander kommunizieren. Deshalb bekomme z.B. manchmal CRC_Fehler obwohl das Empfangende devices alles korrekt versteht. Oder ich sehe IDs die ich keinem device zuordnen kann. Was alles sehr merkwürdig ist.
Mittlerweile kann ich ZWave Telegramme teilweise lesen, (solange sie nicht secure sind) bin aber noch weit davon entfernt das routing zu verstehen.
Oft reicht eine offene oder geschlossene Tür um das routing zu verändern.

@Ändy
ich habe mir erst heute Deinen Screenshot mit den Anmerkungen aus dem HC2Toolkit angeschaut. Du beziehst Dich auf IDs die durcheinander geraten, aber das sind NodeIds und ich zähle ja die 1 zu den deviceIDs dazu. Oder habe ich Dich falsch verstanden? Dürfte auch nichts ausmachen wenn man statt der Nummer einen Namen vergibt. Die deviceID ändert sich dadurch nicht.

Habe noch nie eine Mesh Rekonfiguration machen müssen. Meine 76 Devices sind auf 3 Etagen plus Garten und Garage verteilt. Also ist das routing ja nicht so schlecht obwohl wir es (noch) nicht ganz verstehen.

Ein Problem das ich mit dem Razberry (damals mit FHEM) nicht hatte - fast alle Geräte kommunizierten mit 100Kbit/s (ZWave+) bis zum Gateway. Das HC2 muss erst mal den ZWave+ devices (das sind bei mir ca. 80%) sagen - hey das kann ich nicht, mach mal langsamer, versuch mal auf 40Kbit/s zu senden.
Ich habe immer noch einen Testaufbau mit Razberry und FHEM. Routing Maps konnten wir dort schon vor 2 Jahren.
Was ich damit sagen will, das HC2 ist schon lange nicht mehr “state of the art”. Zwave+ controller gibt es schon seit über 2 Jahren. Auf alle Fälle es bremst die Kommunikation im Netz und bei devices ohne + ist die Sendeleistung so wie so geringer. Ein HC3 ist also schon lange fällig.

aendy · 20. August 2018 um 09:52

ich habe mir erst heute Deinen Screenshot mit den Anmerkungen aus dem HC2Toolkit angeschaut. Du beziehst Dich auf IDs die durcheinander geraten, aber das sind NodeIds und ich zähle ja die 1 zu den deviceIDs dazu. Oder habe ich Dich falsch verstanden?

@jeep, ich hatte die NIDs markiert um auf die Zugehörigkeit zum Modul hinzuweisen. Anhand der NID hat man ja eine eindeutige Angabe egal in welcher Reihenfolge die IDs abgelegt sind. Aber wenn dies nur ein Ausnahmefall ist, ist es eh nicht so wild und vermutlich um ein vielfaches schwieriger dafür eine Auswertung zu schreiben. Da lerne ich lieber irgendwann das Gerät neu an.

@gerhard (Antwort im falschen Thema?), doch doch ich traue dem Script schon Wie gesagt, wenn dies eine Ausnahme darstellt, soll es mir Recht sein. Ich weiß ja jetzt Bescheid woher es kommt. Und der Rest funktioniert ja nun auch bei mir mit der zusätzlichen Zeile, egal ob das Parent mit Namen benannt oder eine Zahl hat. PS: Excel hab ich nicht.

Ich hab mir auch mittlerweile die Angabe des Raumes und des Bereichs für das jeweilige Gerät ausgeben lassen. Für den Bereich (Section) bin ich noch auf der Suche wie man den Klarnamen bekommt. Sowas wie fibaro:getRoomNameByDeviceID(mDevID+1) gibt’s wohl für Sections nicht? Ich finde jedenfalls nichts darüber. Ich würde außerdem noch gerne die Info ob Batterie betrieben oder nicht einbauen. Ideen dazu?

jeep · 20. August 2018 um 12:25

@Ändy

hier mal eine Funktion die das macht, habe in meinem Batterycheckscript auch so was ähnliches drin. Du musst der Function nur die SectionID übergeben.

local sectionID = fibaro:getSectionID(mDevID+1)

local function getSNamebyID(sectionID)
      if sectionID > 0 then
        local section = api.get("/sections/" .. tostring(sectionID))
        return string.sub(tostring(section.name),1, 5)
     end
   return ''  
end

Das würde Dir die ersten 5 Zeichen des Namens ausgeben.

aendy · 20. August 2018 um 14:51

Neighbours of device 144) Keyfob (Wohnzimmer|OG) : [1,5,77,79,108,113,132,142]
Last working route used by device 144 : [1,79]
Last WRRT for device 144: 14:51:06  - 17 Aug. 18

@jeep, super! Vielen Dank. Funktioniert perfekt.

Was kann man eigentlich mit der Neighbours Angabe anstellen? Ich muss zugeben die Bedeutung der “Nachbarn” noch nicht ganz verstanden zu haben. Manchmal hab ich nur einen, machmal ne ganze Latte. Kann man daraus eine Erkenntnis gewinnen, z.B. wie stabil oder ausgelastet das Netz ist?

ggoetz56 · 20. August 2018 um 15:28

Hallo Ändy,
die Nachbarn sind die ein Gerät direct sieht. Also die er direkt anfunken kann. Das braucht das Gerät, da es ja mal vorkommen kann das ein Gerät aus seiner LWR heraus fällt, sei es durch defekt, oder weil du einen Schrank umgestellt hast. Das mit dem Schrank ist ernst gemeint, Funkwellen nehmen oft seltsame Wege bzw, werden von Echos umgelenkt. Das ist jetz bei einem 800er Netz (zwave) nicht ganz so dramatisch wie bei einem 5000er (5GHz Wifi). Aber ich habe z.B. im Bad ein Thermostat an den ich, obwohl ziemlich nahe am HC, nicht direkt hinkomme.

Wenn jetzt so eine LWR kaputt geht sucht das Gerät seine Nachbarn ab und versucht von dort aus zum Hc zu kommen. Wenn du z.b. Assotiationen definiert hast brauchst du nicht mal eine Zentrale dafür. Dafür braucht es eben eine Nachbarnliste.

Insofern hat das HC auch nicht direkt was mit dem Routing zu tun, das machen die Geräte unter sich aus. Es sollte nur sauber im HC dokumentiert sein, was es halt definitiv nicht ist bzw. nicht über api\devices heraus zu bekommen ist. Das HC initiiert schon auch von sich aus ein Meshing aber nicht so, dass es den Geräten eine Route vorgibt, sondern eher dass es ein Gerät auffordert mal seine Nachbarn ab zu fragen und sich evtl eine aktuell bessere zu merken. Wann und wie es das macht ist dies angesprochene Fibarogeheimnis. Du selbst kannst es ja im Bereich Konfiguration/zwave/Mesh Netzwerk Rekonfiguration auch anstoßen.

jeep · 20. August 2018 um 20:48

@Ändy, @Gerhard,
ich versuche nur noch was zu ergänzen, wenn Ihr andere Meinungen habt, immer her damit. Vorab zu Ändys letzte Frage - eine Erkenntnis wie ausgelastet oder stabil das Netz ist, lässt sich mit der Neighbour list wohl kaum vorhersagen.
Steht bei Last working route used by device, nur die [1] drin, kann man vom Idealfall ausgehen, dass das Gerät keine routen benutzt und direkt mit dem Gateway kommuniziert.

Oft sieht man aber das:
Neighbours of device 417) Rollladen Buero : [1,9,11,16,31,38,70,74,80,84,143,163,198,223,226,244,255,262,272,284,321,378,397,410,420,426,434]
Last working route used by device 417 : [1,223,38]
Last WRRT for device 417: 03:15:09 - 20 Aug. 18
Die last working route used by device 417: hat 3 devices drin, die alle Nachbarn von 447 sind, auch die 1. Theoretisch könnte also 447 direkt mit 1 kommunizieren. Ich denke das beim letzten Verbindungsaufbau, keine saubere direkte Route zu 1 möglich war und das Netz hat sich eine neue Route gesucht. Oder gibt es eine andere Erklärung?

Das hier leuchtet eher ein:
Neighbours of device 295) Markise Motion : [106,143,163,187,192]
Last working route used by device 295 : [1,255,143]
Last WRRT for device 295: 03:27:37 - 20 Aug. 18
295 kann nicht zu 1 kommunizieren, also ist es korrekt das es sich den Weg übre die 143 bahnt.

oder gleiches hier für die 185:
Neighbours of device 185) Garage Dach : [59,126,177,179,238,262,330,338,342,359,363,448]
Last working route used by device 185 : [1,338]
Last WRRT for device 185: 03:10:55 - 18 Aug. 18

Das klingt für mich plausibel. Das HC2 mag nicht direkt was mit dem Routing zu tun haben, aber wenn es nicht mitbekommt das ich die Tür geöffnet habe sieht es in der GUI immer eine geschlossene Tür. Und der “value” wird nicht aktualisiert, scripte laufen ins leere. Ob die Neighbour Tabelle der Geräte im HC2 Sinn macht macht oder nicht sei dahingestellt.
Ich überlege schon ob dass vom HC2 initierte Meshing was mit dem Aufwachintervall von Batteriegeräten zu tun hat. Denn sind die nicht wach können die keine neue Route lernen. Die anderen devices sind ja immer wach.

Alles nur graue Theorie und wer dem Script nicht traut, der traut dem HC2 nicht, denn ich gebe nur das aus was im HC2 drin steht und ihr selbst über die api lesen könnt.

aendy · 20. August 2018 um 23:13

@Gerhard, @jeep,

vielen Dank für Eure Ausführungen. So manche Merkwürdigkeit in meinem Netz scheint langsam verständlich zu werden.

@jeep, vielleicht gibt es auch eine Bewertung der Signalqualität und deswegen wird nicht immer die direkte Route gewählt. Lieber um ein paar Ecken sicher, als eine störanfällige Übertragung zu riskieren.

Ich habe auch ein Beispiel für eine merkwürdige Route. Ein Sensative Festersensor:

Neighbours of device 146) Küchenfenster (Küche|OG) : [1,5,77,79,108,113,132,142]
Last working route used by device 146 : [1,65,77,142]
Last WRRT for device 146: 14:51:07 - 17 Aug. 18

Das irrwitzige dabei: Anstatt direkt zum HC zu gehen, wird ein Wallplug (142) auf halber Strecke angesprungen. Wär noch ok, aber von diesem aus geht es vom OG über 2 Stockwerke in den Keller auf den Wallplug des Trockners (77). Von hier durch 3 Mauern auf die andere Seite des Kellers zu einen UBS (65) im Heizkeller. Von hier wieder über 2 Stockwerke direkt zum HC2!
Was das auffällige an dem Fenstersensor ist, das Aufwachintervall ist 0s und ein manuelles Wecken klappt nicht. Mir ist das schon früher aufgefallen aber da er funktioniert habe ich es irgendwann aufgegeben. Bei den anderen Fenstersensoren habe ich ein Aufwachintervall per default. Außerdem steht man bei Betätigung genau zwischen Sensor und HC und verschlechtert vermutlich die Bedingungen.
Ich habe übrigens 2 Geräte die die Route seit 3 Tagen nicht verändert haben. Genau dieser Fenstersensor und eine KeyFOB, welche auch kein Aufwachintervall hat. Vor 3 Tagen habe ich das HC neugestartet! Ich vermute, diese Routen bleiben auch weiterhin unverändert bestehen, wenn man die Geräte nicht explizit aufweckt.

Also alles sehr interessant und wird weiter beobachtet. Vielen Dank nochmal für das Zustandekommen des Scriptes. Werde ich mit Sicherheit noch öfters laufen lassen.

filderer · 21. August 2018 um 09:40

@jeep,

sorry, für die verspätete Antwort. Ich war im verlängerten Wochenende.
Ja, ich habe die Firmware 4.510. Was die Gesamtanzahl der Geräte btrifft, muss ich leider passen.
Kann man das irgendwo vieleicht auslesen? Es sollten so 9 Rollershutter sein, diverse Wallplugs, Tür/Fentser Sensoren, Motionsensoren, Switches, Heizungsthermostate etc.
Ich habe das Script zwischenzeiltich nochmals neu kopiert, mit dem gleichen Ergebnis. Mir wird ein Rollershutter angezeigt und danach passiert nichts mehr.

VG Filderer

ggoetz56 · 21. August 2018 um 10:19

Hi Ändy,
das Problem an dem api\devices Table, den wir ja hier auswerten ist, dass er definitiv nicht stimmt bzw. nicht stimmen muss. Ich hab ja meine Tests und die Ergebnisse erläutert. Solange uns Fibaro nichts anderes zur Verfügung stellt ist das eher raten als wissen. Aber lass dein Netz mal so für ein paar Tage und werte täglich das Mesh aus und speicer das ab, dann kannst du Veränderungen erkennen.

@jeep
Deine Sniffer haben auch noch keine Erkenntnisse zur Zuverlässigkeit der Table gebracht?

ggoetz56 · 21. August 2018 um 10:30

@Filderer

die rote Zahl ist die Anzahl deiner Parentdevices.

--[[
%% properties
%% events
%% globals
--]]

-- File: RoutingInfo.lua
-- Build on FW 4.510 {08-2018 } Jeep -
-- @ gerhard

local Debug = function ( color, message )
  fibaro:debug(string.format('<%s style="font-family:Courier New;font-size:12px;color:%s;">%s', "span", color, message, "span"))
end
--local filter = {parentId = 1,interface = "battery", enabled = true, isPlugin = false } 
local filter = {parentId = 1, enabled = true, isPlugin = false } 
local devices = fibaro:getDevicesId(filter)

Debug('red',#devices)

ggoetz56 · 21. August 2018 um 12:04

vielleicht gibt es auch eine Bewertung der Signalqualität Ich glaube nicht das es die Feldstärke ist sondern schlicht die Geschwindigkeit. Deswegen gibt es auch ständig Veränderungen im Netz. Aber insgesamt finde ich die Routine die dort abläuft recht gut.

Man braucht nur etwas Geduld (bei mir so ca 2 Tage) dann geht manches wie von selbst. Und man darf in der Zwischenzeit nicht soviel rumfummeln, sonst stabiliisert sich das Netz nie. Ich hatte mal einen DÜWI repeater der mich schier wahnsinnig gemacht hat. Erst hat alles prima funktioniert. Nach nem halben Tag ging dann das Tor nicht mehr, hatte vom wahrscheinlichen Routing aber nichts damit zu tun, da es in genau der anderen Richtung vom HC lag. Dann ging der Keller nicht mehr. Das wahrscheinliche Routing über den DÜWI war aber ok. Erst als das entfernte Gerät. das ich über den Düwi erreichen wollte gesponnen hat, hab ich den Düwi rausgeschmissen. Gott sei dank war ich dann 2 Tage nicht zu Hause. Und siehe da alles (bis auf das Gerät für den ich mir den Düwi gekauft hatte) ging wieder.
Dann hab ich den Düwi wieder eingehängt und die gleichen Probleme wie vorher. Hab das ganze nochmal gestestet und wieder das gleiche. Irgendwie arbeitet der Düwi wie eine z-wave Zentrale und das hat mein Netz gar nicht vertragen. Vielleicht hätte ich ihn als Gateway eintragen müssen???

Aber das ist alles so spekulativ. Was man über das Routing lesen kann ist für mich alles nicht so eindeutig, vielleicht liegts auch an meinem englisch.

filderer · 21. August 2018 um 12:25

@Gerhard

Danke

aendy · 21. August 2018 um 12:26

@Gerhard, hast Du bei deinen Netz betriebenen Geräten “Als inaktiv markieren: JA”? Ich habe das Gefühl, dass das HC diese ganzen Informationen nur bekommt, wenn es die Geräte auch abfragen kann. Genauso wie die Batterie betrieben Geräte, welche erst aufgeweckt werden müssen um die Infos zu senden. Im Hintergrund läuft das Z-Wave Netzwerk auf Hardwareebene und ist scheinbar aktueller als das was wir sehen. Ich hab den Eindruck, dass Fibaro die Abfragen nur bei bestimmten Anlässen durchführt. Naja, das geht jetzt schon Richtung raten

Meine “Problemgeräte” habe ich heute wecken können und siehe da, die Routingangabe hat sich verändert.

@filderer, schau mal ob bei Dir die übergeordneten Geräte (Schachteln) benannt sind oder die IDs als Zahl drin stehen.

filderer · 21. August 2018 um 12:38

@Ändy,
die sind alle benannt. Bis auf der eine, der mir auch angezeigt wird.
Heißt das, dass ich allen wieder ihre ID zuordnen muss, anstattt des Klarnamens?

aendy · 21. August 2018 um 12:49

@filderer, füge folgende Zeile ein:

Zeile 26:
if mDevID == nil then mDevID = devices[id] end

Damit klappts bei mir.

ggoetz56 · 21. August 2018 um 13:15

@andi
Ich seh das auch so, dass der api\devices Table nur für aktive Module upgedated wird. Ich hab bei allen Netzbetriebenen “als inaktiv markieren” JA stehen.
Ich bin auch der Meinung dass Api\device nicht das eigentliche Routing widerspiegelt sondern nur eine Auswertung dessen ist, die Fibaro auf “geheimen” Wegen erstellt.

Da ja das Routing auch ohne Zentrale funktioniert bin ich mir überhaupt nicht sicher ob das HC zu jederzeit korrekt über die letzten Routen informiert ist. Müsste es auch nicht weil es ja eh keine Routen vorgeben kann. Ich glaube auch nicht dass irgendwelche Verzögerungen oder sonstige Unstimmigkeiten, (du willst ein Lampe nur dann schalten wenn ein motion Eye mehr Licht als 100 Lux anzeigt) dauert dann 10 Sekunden bzw. schaltet auch bei 1000 Lux Etwas mit dem Netz zu tun haben. Selbst bei “dead Notes” bin ich mir nicht sicher. Die lassen sich bei mir zwar nicht mehr übers HC ansprechen aber über Assotiationen. (Wobei Assotiationen hab ich ausgebaut da es das Ganze praktisch nicht mehr handelbar machte. Wenn das ganze mal steht WENN-- dann will ich das nochmal angehen, Aber wenn du nicht weißt warum eine Lampe plötzlich leuchtet oder ein Feuermelder alarmiert und dein Ereignispanel auch nichts davon weiß, bist du geneigt alles möglichst schlicht zu halten).

Der einzige im HC der seine Nachbar und die Routen kennen muss ist der z-wave 300er Chip im HC, aber ich denke der arbeitet genauso autark wie z.B. der 500er in einem Switch 2 und lässt sich dahingehen nicht programmieren, da er sonst nicht z-wave zertifiziert wäre.