super, dass war es. jetzt läufts.
Vielen Dank
Jetzt habe ich leider auch eine leere LWR:
Neighbours of device 65) Heizung (Heizkeller|UG) : [1,5,74,77,79,84,113,132,167,199,205,228]
Last working route used by device 65 : []
Last WRRT for device 65: 03:06:14 - 21 Aug. 18
??? Das Gerät arbeitet einwandfrei. Andere benutzen es sogar als Route.
@Ändy, @Gerhard,
also dieses " „Als inaktiv markieren: JA“? ist eine krasse Fehlübersetzung seitens Fibaro. WEnn man auf english umschaltet
steht dort nämlich “Mark if Dead” und das bedeutet ja was ganz anderes. Ob es für das Mesh Bedeutung hat wissen wir aber nicht.
Also ich hab das so intepretiert, dass diese Geräte als “tot” markiert werden und vom HC aus nicht mehr betrachtet werden. Erst wenn das Gerät selbst sich meldet “wakeup” z.B. dann wird es wieder als aktiv gekennzeichnet. Im anderen Fall würde man das Gerät ständig mit Abfragen (Temperatur, breaching, Stronmverbrauch…) und halt keine Antwort bekommen.
Ist aber alles nur eine Vermutung.
@andy
Genau das meine ich. “Gut !)” dass das auch mal ein anderer hat. Also da sieht man den Wert der Information. Es ist eher ein Hinweis wie das Netz funktionieren könnte, aber niemals die Basis für die Steuerung des Netzes. Ich denke aber dass diese Informationen aus der Tabelle sehr wohl vom HC zu Darstellung bzw. zur Auswertung von Geräten herangezogen werden und diese sind dann eben auch falsch.
@Ändy, @Gerhard,
ich habe weiter geforscht (zwar etwas verspätet aber, wenn Handwerker zu dir kommen sagt man nicht nein) und mit dem Zniffer ein paar routen geprüft.
Was ich nicht genau weiß, ist der Zeitpunkt wann routen aktualisiert werden. Eigentlich kann mir dass auch egal sein,
wichtig ist das Gerät findet überhaupt eine Route.
Besonders problematisch ist es bei Batteriegeräten. Eigentlich müssten die ihre Route bei einer Kommunikation
aktualisieren und beim nächsten WakeUp die Route dem HC2 mitteilen. Eigentlich, aber es ist nicht so, außer
ich habe was falsch gemacht oder Gerät ist nicht aufgewacht, etc.
Diese Route habe ich mit dem Zniffer geprüft:
Neighbours of device 94) TFS Waschkueche : [38,223,255,284,390,417,434,440]
Last working route used by device 94 : [1,238,390,434]
Last WRRT for device 94: 04:01:51 - 23 Aug. 18
-------------------------------------------------------------------------
Und wie die Kommunikation wirklich ablief, sieht man genau am Screenshot94.
Ich habe um die Kommunikation anzustoßen einfach ein Fenster auf und wieder zu gemacht.
Damit man das auch versteht muss man wissen dass der Zniffer mit NodeIDs arbeitet,
nicht mit parentIDs, deshalb habe ich die parentIDs also Master hier daneben geschrieben
nodeID — Master
23 ------- 94
102 ------ 390
77 ------- 272
73 ------- 255
01 ------- 01 (HC2)
Wenn man sich das jetzt anschaut, hat dass nichts mehr mit der LWR zu tun die das HC2 uns mitteilt. Auch nach
einem WakeUp, war keine Änderung der LWR ersichtlich.
Anders sieht es beim Screenshot183 aus. Das Gerät ist natürlich kein Batteriegerät
Neighbours of device 183) ZStecker Bügeleisen : [1,80,106,135,143,145,156,158,163,165,169,171,177,179,192,194,200,212,223,238,262,321,330,334,363,378,382,385,390,420,426,434,448]
Last working route used by device 183 : [1,223,417,70,192]
Last WRRT for device 183: 03:11:05 - 23 Aug. 18
----------------------------------------------------------------------
nodeID — Master
01 ------- 01 (HC2)
53 ------- 183
56 ------- 192
14 ------- 70
107 ------ 417
66 ------- 223
Also hier stimmt alles. Dies ist gerade meine (schlechteste) längste Route und die sieht auch wenn ich mir die Räume
anschaue recht abenteuerlich aus, aber es funktioniert.
Die Daten in den Screenshots sind relativ leicht zu diagnostizieren.
RSSI ist die Signalstärke
Hex Data:
Die ersten 4 Byte sind die HomeID.
Das nächste Byte ist die Sender ID.
Die nächsten 2 Byte gehören zur Rahmensteuerung.
Das nächste Byte ist die Länge des Rahmens.
Das nächste Byte ist die Empfänger ID.
Dann kommen Nutzdaten bis zum
2.letzten oder letzten Byte, das ist die Prüfsumme.
Auf alle Fälle bin ich jetzt sehr neugierig wann sich die Route für ID 94 im HC2 updatet.
Heute Nacht hat sich die LWR des devices mit der ID 94, im HC2 auf genau die IDs eingestellt
die ich gestern beim sniffen ermittelt habe.
Neighbours of device 94) TFS Waschkueche : [38,223,272,284,390,434,440]
Last working route used by device 94 : [1,255,272,390]
Last WRRT for device 94: 03:34:33 - 24 Aug. 18
Wie vermutet kann man davon ausgehen das die LWR, bei Batterie Geräten nicht zwangsläufig
dem entspricht was im HC2 angezeigt wird.
Ich hab auch noch eine Inkonsistenz entdeckt:
Neighbours of device 10) Bewegungsmelder (Außen|Außen) : [1]
Last working route used by device 10 : [1,132,77]
Last WRRT for device 10: 14:51:05 - 17 Aug. 18
Hier sind keine Nachbarn eingetragen aber laut LWR hat er einen.
Dies ist ein Fibaro-BM, welcher im Briefkasten sitzt. Der ist aus Stahlblech! Funktioniert aber ganz gut soweit. Temperatur wird auch immer schön aufgezeichnet. Aber die Bedingungen sind wohl nicht sehr günstig. Ich habe versuch ihn mehrfach aufzuwecken. Zumindest die LWR wurde schon seit etlichen Tagen nicht mehr aktualisiert.
Vielen Dank für eure Informationen,
Eine ganz wichtige Erkenntnis für mich: Die Route ist ja 4. bzw. 5 (lt. diverser z-wave Literatur) Hops beschränkt. Jetzt haben wir es definitiv, inclusive Zentrale und betreffende Id sind es 6 Geräte bzw. 4 Zwischenstationen.
Wir wissen jetzt auch, dass die Meshauswertung nur ein Report ist, der nach (geheimen) Fibaroregeln erstellt wird, und dass das Updating bei batteriebetriebenen Geräten länger als bei Netzgeräten dauert. Auch hat eine erfolgreiche Kommunikation zwischen Geräten nicht zwangsläufig ein direktes Update des Meshtable zur Folge.
@Jeep Mich würde noch brennend interessieren ob die Updatefunktion des Mesh im Fibaro Konigurationsmenue ähnlich unzuverlässige Ergebnisse liefert? Oder ob bei anstoßen der Funktion hier der Table sauber geschrieben wird.
Ich habe ja jetzt ein HCL in meine Mesh integriert und kann auch da sagen: ein Gerät das auf Anhieb nicht (nicht mehr) erkannt wird, kann nach einiger Zeit sehr wohl eine gültige und dauerhaft funktionierende Route finden. Neue Geräte die ich in der Nähe (also direkt) an einer Zentrale integriert habe, haben eigentlich auch funktioniert wenn ich diese weiter weg (so, dass sie nicht mehr direkt mit der zentral kommunizieren konnten) platziert habe. Haben die dann aber ein Route gespeichert und ich habe Sie wo anders (so dass die gelernte Route nicht funktionieren konnte) platziert, wurden sie manchmal nicht sofort integriert, aber nach einiger Zeit. Die API/devices-Auswertung hing immer zeitlich starkt hinterher.
@Gerhard,
ich habe vor meinen Tests eine “Komplette ZWave Netzrekonfiguration” angestoßen, was ich bisher noch nie gemacht hatte und
was man laut einigen Experten im Fibaro Forum ja auch nicht tun soll.
Das ganze hat keine Stunde gedauert aber bei allen Batteriedevices kamen die Fehlermeldungen “Getting new neighbor list failed”. Das hat sich über ein Tag mit diesen Meldungen hingezogen. Aber die Routen der anderen Geräte schienen mir OK, obwohl ich einen Tag später wieder Veränderungen entdeckt habe. Aber wir wissen ja zwischenzeitlich dass das eine Normalität ist (obwohl wir keine Möbel umgestellt haben), aber im UG habe ich ca. 20 Geräte und 3 dicke Türen. Da ist es normal das routen sich ändern.
@Ändy, @Gerhard,
hab hier noch ein paar Änderungen am Script gemacht so dass leere Nachbarn und Routen schneller erkannt werden.
Die problematische Zeile 26 oder davor war ein Überbleibsel eines copy/paste aus meinem anderen Script.
--[[
%% properties
--]]
-- File : RoutingInfo.lua
-- Version : 0.1.2
-- nach einer Vorlage aus dem Fibaro Forum (thanks @tinmann)
-- Build on FW 4.510 {08-2018 } Ändy, Gerhard, Jeep
--
-- Abkürzung : working route respose time = WRRT
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)
local html = true
local output = ''
if (html == false) then d = true
elseif ( html == true) then d = false;Debug('cyan','Daten werden im HTML Format ausgegeben - Bitte warten...')
end
for id = 1, #devices do
local mDevID = devices[id]
if mDevID ~= nil then
local name = fibaro:getName(mDevID+1)
if name == nil then
name = "No Name"
end
api.post('/devices/'.. mDevID ..'/action/getNeighborList')
thisDev = "Neighbours of device " .. mDevID ..') '..name ..' : '.. fibaro:getValue(mDevID, "neighborList")
if thisDev:find("%p[%p]") then Debug('red','Device '.. name..'('..mDevID..')'.. ' hat keine Nachbarn') end
if html then output = "<pre>"..output..thisDev.."</pre>" end
if d then Debug('withe', thisDev) end
thisDevRoute = "Last working route used by device " .. mDevID .. " : " .. fibaro:getValue(mDevID, "lastWorkingRoute")
if thisDevRoute:find("%p[%p]") then Debug('orange', 'Device ' ..name..'('..mDevID..')'.. ' hat keine Routen') end
if html then output = "<pre>"..output..thisDevRoute.."</pre>" end
if d then Debug('withe', thisDevRoute) end
thisDevTimeStamp = tonumber(fibaro:getValue(mDevID, "lastWorkingRouteResponseTimestamp"))
thisDevLWRRTime = "Last WRRT for device ".. mDevID .. ': '.. (os.date("%X - %d %b. %y", thisDevTimeStamp ))
if html then output = "<pre>"..output..thisDevLWRRTime.."</pre>"..id..'-- <br />' end
--if d then Debug('yellow', thisDevLWRRTime) end
if d then Debug('cyan', id..'--') end
fibaro:sleep(500)
end
end
Debug('cyan', output)
Moin zusammen! Habe mein HC2 komplett neu gemacht (noch nicht ganz fertig, aber läuft) jetzt läuft auch dein Script @Jeep, allerdings schmeißt es komische Dinge aus!?
Habe das HC2 FW.4.510 und das letzte Skript 0.1.2:
[DEBUG] 08:34:54: Daten werden im HTML Format ausgegeben - Bitte warten…
[DEBUG] 08:35:05: [1;31m2018-08-31 08:35:05.413686 [ error] API: Not found
[DEBUG] 08:35:12: [1;31m2018-08-31 08:35:12.171997 [ error] API: Not found
[DEBUG] 08:35:16: [1;31m2018-08-31 08:35:16.359660 [ error] API: Not found
[DEBUG] 08:35:16: Device No Name(190) hat keine Nachbarn <----hat definitiv einen Namen und funktioniert; Es ist eine Steckdose von:Name:
Netzknoten ID:046WK
Raum:Waschküche
Modulart:Z-Wave Gerät
Hersteller:Devolo
Version:1.14
Konfiguration:Modul konfiguriert
ID:190
Der Name der Untergeräte ist: Trockner
[DEBUG] 08:35:16: Device No Name(190) hat keine Routen
[DEBUG] 08:35:22: Device Thermostat KZ(303) hat keine Nachbarn
[DEBUG] 08:35:24: [1;31m2018-08-31 08:35:24.826711 [ error] API: Not found
[DEBUG] 08:35:25: [1;31m2018-08-31 08:35:25.903979 [ error] API: Not found
[DEBUG] 08:35:26: Device Fenster links KZ(329) hat keine Nachbarn
[DEBUG] 08:35:26: Device Fenster links KZ(329) hat keine Routen
[DEBUG] 08:35:32: Device Fenster Werkraum(380) hat keine Nachbarn
[DEBUG] 08:35:32: Device Fenster Werkraum(380) hat keine Routen
[DEBUG] 08:35:33: Device RM Flur oben(389) hat keine Nachbarn
[DEBUG] 08:35:37: Device Keyfob Svenja(415) hat keine Nachbarn
[DEBUG] 08:35:37: Device Keyfob Svenja(415) hat keine Routen
[DEBUG] 08:35:38: Device Keyfob Nicole(417) hat keine Nachbarn
[DEBUG] 08:35:38: Device Keyfob Nicole(417) hat keine Routen
[DEBUG] 08:35:38: [1;31m2018-08-31 08:35:38.805227 [ error] API: Not found
[DEBUG] 08:35:39: Device Keyfob Eltern(424) hat keine Nachbarn
[DEBUG] 08:35:39: Device Keyfob Eltern(424) hat keine Routen
[DEBUG] 08:35:41: Device Schalter Bett(432) hat keine Nachbarn
[DEBUG] 08:35:41: Device Schalter Bett(432) hat keine Routen
[DEBUG] 08:35:42:
Neighbours of device 29) Verstärker : [1,31,33,35,37,42,50,54,63,68,70,75,79,84,89,94,96,98,113,115,118,120,123,127,130,133,139,142,144,151,153,158,165,170,174,178,183,203,205,210,219,225,231,263,294,299,306,310,313,317,321,325,329,337,341,345,349,358,362,368,372,376,380,386,393,396,400,403,406,410,419,430]
Last working route used by device 29 : [1]
Last WRRT for device 29: 21:02:04 - 29 Aug. 18
auch hier sieht es komisch aus:
Neighbours of device 37) Licht Wohnzimmer0 : [29,31,33,35,42,46,50,54,63,68,70,75,79,84,89,94,96,98,113,115,118,120,123,127,130,133,139,142,144,151,153,158,165,174,178,183,190,203,205,210,215,219,225,231,263,294,299,306,310,313,325,329,337,341,345,349,358,362,368,376,380,389,393,396,406,410,419,426,430,434,436]
Last working route used by device 37 : [1]
Last WRRT for device 37: 03:22:39 - 31 Aug. 18
5–
Die Nachbarn fangen mit “29” an, aber LWR steht “1” …dieses Modul ist keine 3 Meter vom HC entfernt, daher sollte es auch die “1” sein
Sieht auch komisch aus (ist 3m entfernt aber eine dünne Mauer zwischen)…es ist ein Fibaro RM 002 :
Neighbours of device 389) RM Flur oben : []
Last working route used by device 389 : [1]
Last WRRT for device 389: 08:07:42 - 31 Aug. 18
70–
grüße Sven
@Sven,
es ist alles normal. Was das Script schmeißt, steht alles aktuell in Deinem HC2, das Script macht es nur sichtbar.
Und das ganze ist nicht statisch. Morgen kann alles anders aussehen. Keyfobs haben nicht immer Routen oder Nachbarn, da
die ja selbst als Controller arbeiten können.
Wenn ein Gerät keine Nachbarn anzeigt muss das nicht unbedíngt sein das es keine hat, nur das HC2 weiß nichts
davon.
In der Regel machen die Geräte die Routen unter sich aus, das HC2 weiß das in der Regel erst später.
Auch bei mir ist es so dass nahe liegende Geräte nicht immer die für uns ‘ersichtlich’ beste Route nehmen. Dass
wird wohl immer ein Geheimnis bleiben.
Der Devolo hat in der Regel viele Child-Nodes, ich versuche nur den Namen über den ersten Child zu ermitteln. Das ist
schon gut möglich dass dieser keinen Namen hat (oder hidden ist) und ist auch für die Liste egal.
Was mich aber richtig stört ist dass einige Devices einen API Fehler bringen. Warum bei mir nicht?
Noch ne Frage am Rande - warum musstest Du Dein HC2 neu konfigurieren?
@sven Die Api-Fehler würden mich auch interessieren. Vielleicht kannst du mal die Api\device -Ausgabe für eine der ID’s posten.
@jeep Gutes Update danke. Und sei mal nicht so bescheiden, das ist allein dein Script!
Meine Erfahrung ist, wenn man nicht so viel im Netz rumfummelt wird das ganze immer schlüssiger. Ist bei mir nur durch das zusätzliche HCL gerade nicht so der Fall.
Allerdings hat mein Netz jetzt erstmal Pause, bei mir gehts “ab in den Urlaub”
Bin mal gespannt wie sich das bei Sven entwickelt.
Das Script ist für mich eine super Sache um schlechte Verbindungen aufzudecken. Wie ja schon beschrieben ist ein älteres Datum (> 3 Tage) ein Zeichen sich das Gerät und die Umgebung mal näher anzuschauen. Dabei gibt es zwei Fälle:
-Batteriegerät hat kein Aufwachintervall. Das ist Standard z.B. Bei Keyfob, Button. Ein Fenstersensor hatte hier fälschlicherweise ein fehlendes Aufwachintervall und ich konnte dieses nachtragen. Werden die Geräte von Hand geweckt, bekommt man auch (irgendwann) die LWR angezeigt.
-Batteriegerät hat eine schlechte Z-Wave Anbindung. Die Platzierung eines Wallplugs zwischen diesem Gerät und der Zentrale hat dies behoben.
Ich frage mich immer noch welche Arten von Kommunikation und Auswertung das HC2 hier betreibt. Einerseits funktioniert das Device aber die Route wird nicht immer übertragen. Mir scheint, das HC muss hier “mitlauschen” und tut es aber nur zu bestimmten Zeiten und manchmal gibt es hier auch Fehler (leere [] LWR etc).
@jeep, die API-Fehler habe ich auch. Komisch dass Du sie nicht hast. Dachte das sei normal seit 4.510. Habe deine neue Version mal ausprobiert. Läuft, habe aber noch keine leere LWRs testen können. Ich habe auch wieder meine Infos zum Gerät miteingebaut (Raum und Bereich). Finde das einfach übersichtlicher. Ich meine Du hattest Bedenken wegen der max. Zeichenanzahl? Ich stelle es trotzdem mal hier rein:
--[[
%% properties
--]]
-- File : RoutingInfo.lua
-- Version : 0.1.2
-- nach einer Vorlage aus dem Fibaro Forum (thanks @tinmann)
-- Build on FW 4.510 {08-2018 } Ändy, Gerhard, Jeep
--
-- Abkürzung : working route respose time = WRRT
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 function getSNamebyID(sectionID)
--fibaro:debug (sectionID)
if sectionID > 0 then
local section = api.get("/sections/" .. tostring(sectionID))
return string.sub(tostring(section.name),1, 10)
end
return 'unassigned'
end
local function getSectionNameByDeviceID(DevID)
if DevID == nil then
return 'nil'
else
local sectionID = fibaro:getSectionID(DevID)
if sectionID == nil then
return 'nil'
else
return getSNamebyID(sectionID)
end
end
end
--local filter = {parentId = 1,interface = "battery", enabled = true, isPlugin = false }
local filter = {parentId = 1, enabled = true, isPlugin = false }
local devices = fibaro:getDevicesId(filter)
local html = true
local output = ''
if (html == false) then d = true
elseif ( html == true) then d = false;Debug('cyan','Daten werden im HTML Format ausgegeben - Bitte warten...')
end
for id = 1, #devices do
local mDevID = devices[id]
if mDevID ~= nil then
local name = fibaro:getName(mDevID+1)
if name == nil then
name = "No Name"
end
local room = fibaro:getRoomNameByDeviceID(mDevID+1)
if room == nil then
room = "No Name"
end
local section = getSectionNameByDeviceID(mDevID+1)
if section == nil then
section = "No Name"
end
api.post('/devices/'.. mDevID ..'/action/getNeighborList')
thisDev = "Neighbours of device " .. mDevID ..') '..name ..' (' .. room .. '|' .. section .. ') : ' .. fibaro:getValue(mDevID, "neighborList")
if thisDev:find("%p[%p]") then Debug('red','Device '.. name..'('..mDevID..')'.. ' hat keine Nachbarn') end
if html then output = "<pre>"..output..thisDev.."</pre>" end
if d then Debug('withe', thisDev) end
thisDevRoute = "Last working route used by device " .. mDevID .. " : " .. fibaro:getValue(mDevID, "lastWorkingRoute")
if thisDevRoute:find("%p[%p]") then Debug('orange', 'Device ' ..name..'('..mDevID..')'.. ' hat keine Routen') end
if html then output = "<pre>"..output..thisDevRoute.."</pre>" end
if d then Debug('withe', thisDevRoute) end
thisDevTimeStamp = tonumber(fibaro:getValue(mDevID, "lastWorkingRouteResponseTimestamp"))
thisDevLWRRTime = "Last WRRT for device ".. mDevID .. ': '.. (os.date("%X - %d %b. %y", thisDevTimeStamp ))
if html then output = "<pre>"..output..thisDevLWRRTime.."</pre>"..id..'-- <br />' end
--if d then Debug('yellow', thisDevLWRRTime) end
if d then Debug('cyan', id..'--') end
fibaro:sleep(500)
end
end
Debug('cyan', output)
@Ändy,
ja, API Fehler sind fast normal, man kann Sie mit aber (manchmal recht aufwändig) umgehen.
Den API Fehler den Du bekommst liegt an der fehlerhaften Fibaro Funktion “getRoomNameByDeviceID”. Die produziert immer einen API Fehler. Erdenkliche Abhilfe, das erste Slave Device einem Raum zuordnen.
@Ändy, @Gerhard
ich hab mal ein paar Änderungen eingearbeitet und hoffe dass ich die API Fehler (die vermutlich durch die section und room Ausgabe kamen,) weg habe.
Am Ende ist noch eine kleine Zusammenfassung. Die Zählung der direkten routen finde ich noch ein wenig schwammig, aber mir fiel nichts anderes ein.
--[[
%% properties
--]]
-- File : RoutingInfo.lua
-- Version : 0.1.3
-- nach einer Vorlage aus dem Fibaro Forum (thanks @tinmann)
-- Build on FW 4.510 {08-2018 } Ändy, Gerhard, Jeep
--
-- Abkürzung : working route respose time = WRRT
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 function getSNamebyID(sectionID)
--fibaro:debug (sectionID)
if tonumber(sectionID) > 0 then
local section = api.get("/sections/" .. tostring(sectionID))
return string.sub(tostring(section.name),1, 10)
end
return 'No section'
end
local function getSectionNameByDeviceID(DevID)
if DevID == nil then
return 'nil'
else
local sectionID = fibaro:getSectionID(DevID)
if sectionID == nil then
return 'nil'
else
return getSNamebyID(sectionID)
end
end
end
local filter = '/devices/?enabled=true&isPlugin=false'
local allDevices = api.get(filter)
local html = true
local output = ''
if (html == false) then d = true
elseif ( html == true) then d = false;Debug('cyan','Daten werden im HTML Format ausgegeben - Bitte warten...')
end
local nn,r,nr=0,0,0
local n=1 --nur Geräte mit parentId = 1
for id = 1, #allDevices do
if (allDevices[id].parentId == 1 ) then
local mDevID = allDevices[id].id
if mDevID ~= nil then
local name = fibaro:getName(mDevID+1)
if name == nil then
name = "No Name"
end
if(tonumber(allDevices[id+1].roomID) == 0) then
room = 'No room';
else
room = fibaro:getRoomNameByDeviceID(allDevices[id+1].id)
end
local section = getSectionNameByDeviceID(mDevID+1)
if section == nil then
section = "No Name"
end
api.post('/devices/'.. mDevID ..'/action/getNeighborList')
thisDev = "Neighbours of device " .. mDevID ..') '..name ..' (' .. room .. '|' .. section .. ') : ' .. fibaro:getValue(mDevID, "neighborList")
if thisDev:find("%p[%p]") then
Debug('red','Device '.. name..'('..mDevID..')'.. ' hat keine Nachbarn')
nn = nn + 1 end
if html then output = "<pre>"..output..thisDev.."</pre>" end
if d then Debug('withe', thisDev) end
local lwr = fibaro:getValue(mDevID, "lastWorkingRoute")
thisDevRoute = "Last working route used by device " .. mDevID .. " : " .. lwr
if thisDevRoute:find("%p[%p]") then
Debug('orange', 'Device ' ..name..'('..mDevID..')'.. ' hat keine Routen')
nr = nr +1
end
if string.len(lwr) == 3 then r = r +1 end
if html then output = "<pre>"..output..thisDevRoute.."</pre>" end
if d then Debug('withe', thisDevRoute) end
thisDevTimeStamp = tonumber(fibaro:getValue(mDevID, "lastWorkingRouteResponseTimestamp"))
thisDevLWRRTime = "Last WRRT for device ".. mDevID .. ': '.. (os.date("%X - %d %b. %y", thisDevTimeStamp ))
if html then output = "<pre>"..output..thisDevLWRRTime.."</pre>"..n..'-- <br />' end
--if d then Debug('yellow', thisDevLWRRTime) end
if d then Debug('cyan', n..'--') end
n =n+1
fibaro:sleep(100)
end
end
end --for
Debug('cyan', output)
Debug('green',"Direkte routen, [1] zum HC2: "..r)
Debug('red', "Devices ohne Nachbarn [] : "..nn)
Debug('orange',"Devices ohne routen [] : "..nr)
@jeep, klappt prima. Gefällt mir sehr gut. Vielen Dank.
Allerdings habe ich noch 2 dieser API-Fehlermeldungen, was mich aber nicht so sehr stört. Vorher waren es 4. Hält sich also in Grenzen. Ich hoffe, dass sich das alles beim nächsten Update erledigt.
[DEBUG] 18:41:16: Daten werden im HTML Format ausgegeben - Bitte warten…
[DEBUG] 18:41:18: [1;31m2018-09-03 18:41:18.516630 [ error] API: Not found
[DEBUG] 18:41:18: [1;31m2018-09-03 18:41:18.537702 [ error] API: Not found
[DEBUG] 18:41:23:
Hi Leute,
Habe gerade euer Mesh Skript getestet, funktioniert super!
Habe ebenfalls 2 API Meldungen, aber das ist egal.
Was ich etwas komisch finde, dass ich viele Devices habe die weder Nachbarn noch Routen haben!! (siehe Screenshot)
Was soll das bedeuten?
Oder besser, wie kann ich das lösen?
Hi pblacky,
wenn Geräte keine routen oder Nachbarn haben ist das erstmal nicht tragisch. Fernbedienungen oder Wallswitch zum Beispiel, sind ja meisten eigene Controller, die haben halt keine Routen oder Nachbarn. Auch wenn andere Geräte keine Routen haben, (bei mir ist es ein Türssensor) anzeigen heißt das nicht unbedingt das sie keine haben. nur das HC2 weiß nichts davon. Routing ist ein Bereich mit vielen unbekannten und Fibaro hat nicht alles öffentlich zugänglich gemacht, so dass ich hier ganz schön im Nebel stochere.
Aber ich bin schon froh dass Fibaro ab 4.5xx versucht die Routingdaten im HC2 zu hinterlegen.
Vor allem ändern die routen sich manchmal über Nacht. Es reicht oft eine Tür zu öffnen und am nächsten Tag hast Du eine andere Route. Wenn Du Dir den ganzen Thread durchliest wirst Du erkennen dass es nicht so einfach ist mit den routen. Habe einiges mit dem Zniffer überprüft: https://www.siio.de/board/thema/mesh-konfiguration-auslesen/page/5/#post-96985
Wenn Du Kommunikationsfehler hast oder vermutest liefert Dir das Script schon ein paar Infos.