Hallo,
die neue API, ab Softwareversion 4.5x bietet ja Informationen über die Route die ein Gerät nimmt bis es zur Zentrale (z.B. HC2) kommt. Auch werden die benachbarten Geräte für jede ID aufgelistet.
Das Ausgabe sieht aber mit dem API Befehl “HC2_IP_Adresse/api/devices” wenn man den im Browser eingibt, sehr unübersichtlich aus. Hat da jemand was besseres?
Gruß
Gerhard
Hallo zusammen,
dieses Script ist nach einer Vorlage aus dem Fibaro Forum entstanden (danke an tinmann für den Beispiel Code).
Einiges ist mir auch noch nicht ganz klar aber ich werden die nächsten Tage mit dem Zniffer noch einiges prüfen müssen.
Aber dem Einen oder Anderen könnte das schon helfen.
Die erste Filterzeile ((Zeile15) geht nur über Batterie Geräte, die nächste über alle Geräte.
--[[
%% properties
%% events
%% globals
--]]
-- File: RoutingInfo.lua
-- nach einer Vorlage aus dem Fibaro Forum (thanks @tinmann)
-- Build on FW 4.510 {08-2018 } Jeep - Danke an Gerhard für den Anstoß.
--
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 devID, devName,
local output = ''
for id = 1, #devices do
local mDevID = tonumber(fibaro:getName(devices[id]))
local name = fibaro:getName(mDevID+1)
if name == nil then
name = "No Name"
end
fibaro:sleep(2000)
api.post('/devices/'.. mDevID ..'/action/getNeighborList')
thisDev = "Neighbours of device " .. mDevID ..')'..name ..' : '.. fibaro:getValue(mDevID, "neighborList")
output = "<pre>"..output..thisDev.."</pre>"
print("Neighbours of device " .. mDevID ..')'..name ..' : '.. fibaro:getValue(mDevID, "neighborList"))
api.post('/devices/'.. mDevID ..'/action/getLastWorkingRoute')
thisDevRoute = "Last working route used by device " .. mDevID .. " : " .. fibaro:getValue(mDevID, "lastWorkingRoute")
output = "<pre>"..output..thisDevRoute.."</pre>"
print("Last working route used by device " .. mDevID .. " : " .. fibaro:getValue(mDevID, "lastWorkingRoute"))
Debug('cyan', '-----------------------------------------------------------')
end
Debug('cyan', output)
SUPER JEEP,
danke fürs teilen. Ich habe gleich die große Variante gewählt. Zeile 15 auskommentiert und Zeile 16 aktiviert.
Läuft fehlerfrei durch.
Ich habe allerdings einige Geräte mit LastWorkingRoute =[], die habe ich schon bei der API-Auswertung entdeckt und im englischen Forum danach gefragt. Die Geräte selbst funktionieren. Da ich nicht der Einzige bin der das festgestellt hat haben wir mal eine Anfrage an den Fibaro-Support gestellt.
Ich habe auch festgestellt, dass Veränderungen im Netz nicht sofort dokumentiert werden. Auch wenn man die Geräte unter z-wave Konfiguration neu rekonfiguriert. Mir scheinen die Routen nach einer Veränderung erst nach ca. 48 Std komplett richtig im HC eingetragen zu sein. Auch habe ich festgestellt, wenn ich z.b. Switche mit in der Nähe des HC betrieben habe und dann die Switche weiter weg installiert habe, wurden Sie zuerst als “Dead Node” markiert aber nach 1 bis 2 Tagen dann dauerhaft ins Netz includiert.
Hier würde mich interessieren, da sich das Mesh ja “automatisch” überprüft ob man einen Zeitraum definieren kann wann das passiert?.
Nabend Jeep, ich habe heute erst nach 4.510 upgedated, aber wenn ich dein Skript nutze kommt:
[DEBUG] 17:12:53: [1;31m2018-08-15 17:12:53.990802 [ fatal] Unknown exception: /opt/fibaro/scenes/53.lua:23: attempt to perform arithmetic on local ‘mDevID’ (a nil value
habe es 1 zu ein kopiert aber auch mal Zeile 15 deaktiviert und 16 aktiviert, aber immer dieser Fehler
Hi Sven,
wann tritt der Fehler auf, sofort oder nach einer gewissen Zeit?
Zum debuggen füge mal zwischen 22 und 23 ein print(mDevID) ein.
Für mich sieht es so aus als ob Du ein Master Device ohne ID hast
und deshalb wird nil zurückgeliefert. Sehr seltsam.
Wenn es dass tatsächlich gibt, muss ich eine weitere Prüfung einbauen.
Hallo Sven,
das Problem liegt hier:
Wenn die Variable mDevID gleich nichts (nil) ist steigt das Script aus. Hatte ich auch. Es war glaube ich ein virtuelles device. Das hatte die parentid=1 und nichts in Id stehen. In Zeile 2 versuchst du dann 1 zu nichts zu addieren, das erzeugt den Fehler (mDevID+1)
Du hast wahrscheinlich auch die “große Version” mit Zeile 16 genommen. Ich habe da ein wenig geschummelt und für diesen Fall der Variablen einfach ein gültige ID (in meinem Fall 65) zugewiesen. Das ist jetzt nicht toll, aber hat auf die schnelle geholfen. Jeep hat da bestimmt noch eine bessere Lösung.
local output = ‘’
for id = 1, #devices do
local mDevID = tonumber(fibaro:getName(devices[id]))
if mDevID then
name = fibaro:getName(mDevID+1)
else
name = “No Name”
mDevID = 65
end
– local name = fibaro:getName(mDevID+1)
if name == nil then name = “No Name” end
fibaro:sleep(2000)
Wenn du in deinen Browser mal "HC_Ip_Adresse\api\devices " eintippst bekommst du den Schuldigen raus. Der hat bei {"id: " keinen Wert stehen. sowas wie
{“id”:,“name”:“gerhard.goetz@mail.de”,…
Ich hätte noch ein Frage an dich. Hast du noch ein HCL in dein Mesh eingebunden. Versuche ich gerade auch.
Gruß
Gerhard
Moin zusammen!
erst mal danke für eure Hilfe!
@jeep … der Fehler tritt direkt auf und nach Einbau von “print(mDevID)” kommt auch direkt ein nil
[DEBUG] 14:30:47: nil
[DEBUG] 14:30:47: [1;31m2018-08-16 14:30:47.590669 [ fatal] Unknown exception: /opt/fibaro/scenes/53.lua:24: attempt to perform arithmetic on local ‘mDevID’ (a nil value)
…leider funktioniert es auch mit deinen Tipps @Gerhard nicht…
[DEBUG] 14:39:18: nil
[DEBUG] 14:39:20: [1;31m2018-08-16 14:39:20.575728 [ error] API: Not found
[DEBUG] 14:39:20: [1;31m2018-08-16 14:39:20.576882 [ fatal] Unknown exception: /opt/fibaro/scenes/53.lua:37: attempt to concatenate a nil value
Das erste nil kommt von jeeps vorgeschlagener Zeile “print(mDevID)”
weiter Lösungsvorschläge werden gerne entgegen genommen!
@Gerhard…ich nutze mein HCL nicht im Mesh, sondern als IP-Gateway im Master (HC2) / Slave (HCL) Verbund
@sven,
Bevor du mit mDevID etwas machst sollte mDevID einen numerischen Wert haben. Meine Zeilen bedeuten ja soviel als “Wenn mDevId nicht existiert dann soll mDevID 65 sein” Da musst du natürlich eine in deinem System gültige Id nehmen.
Jeep häng ja die ganzen "output"s aneinander um das dann zum Schluss in der Farbe cyan auszugeben (letzte Zeile). Nichts (nil) kannst du nicht an den String dran hängen, so ähnlich wie division durch Null, das gibt dann den concatenate Fehler. Sorgst du dafür, dass mDevId einen gültigen Wert hat und damit auch “thisDevRoute” gibt’s keine Abstürze.
Hast du „HC_Ip_Adresse\api\devices “ schon probiert, da siehst du es sofort, könnte z.b das HCL sein das probleme macht. Ich weiß nicht wie sich das darstellt. Wenn du nur “sauber” includierte Fibaro Geräte hast läuft es durch. Du könntest auch die 1 in Zeile 21 in eine 2 oder 3 ändern, dann fängt es erst mit dem 2. oder 3. Gerät an das den Filterbedingungen entspricht. ID 1 = z.B immer das HC
Zum HCL: Du nutzt es nur als Zugang? Aus Sicheheitsgründen? oder verstehe ich IP-Gateway nicht richtig?
Interessantes Script. Danke fürs Teilen.
Ich bekomme auch mehrere nil IDs. Ich habe mir beholfen dies per If abzufragen und den Rest in dem Fall einfach zu überspringen.
Bin noch dabei die Ausgabe zu verstehen 
Neighbours of device 65)65.0 : [5,74,77,106,113,132,167,205,228]
Last working route used by device 65 : [1,79,77]
Bedeutet dies, das Gerät 65 über 2 Geräte 79 und 77 am HC2 (1) hängt? Oder wechselweise, also mal direkt oder mal über 79 oder 77?
Was ist mit Neighbour gemeint? Geräte die am gleichen Knoten hängen?
@Ändy,
bin auch noch am forschen, aber so ein bisschen was weiß ich jetzt schon. Leider stolpere ich manchmal über Ausgaben die meine zuvor erstellte Theorie widerlegen. Ich muss mir neben dem Zniffer noch einen 2 Stick zulegen damit ich die Daten grafisch überprüfen kann.
Zum Beispiel das:
Neighbours of device 212) LED Küche rechts : [1,9,11,16,31,59,70,74,80,82,84,106,126,135,137,143,145,149,156,158,163,165,169,171,177,179,183,185,192,198,226,238,244,255,257,262,268,279,321,330,334,338,342,349,359,363,378,382,385,420,426,434,448]
Last working route used by device 212 : [1,223,262,177,338]
Last WRRT for device 212: 03:12:13 - 16 Aug. 18
Das device 212 geht über 5 routen bis zum HC2. Laut ZWave Protokoll gibt es max. 4 hops.
Die physikalische Anordnung würde aber stimmen.
Dein device 65 kommuniziert demnach über den Nachbarn 77 zu 79 und dann zum HC2. Musst mal die physikalische Position der beiden Devices feststellen ob dass plausibel ist.
Ich stelle gleich eine neue Version ein die eine nicht vorhandene parent ID ignoriert.
Hier ist die Version die eine nicht existierende parent Id ignoriert.
Sollten noch Fehler auftauchen, bitte gleich melden.
Das Script gibt auch die Zeit aus wann die route zuletzt benutzt/aktualisiert wurde.
Leider bin ich bei der Debug-Ausgabe mit meinen 76 physikalischen Geräten an die
Speichergrenze des Debug-Fenster gestoßen.
Deshalb kann ich die die Zeit der Route nur in der HTML-Ausgabe anzeigen.
Fernbedienungen speichern keine Routinginformationen da die oft selbst als Gateway fungieren können.
--[[
%% properties
--]]
-- File : RoutingInfo.lua
-- Version : 0.1.1
-- nach einer Vorlage aus dem Fibaro Forum (thanks @tinmann)
-- Build on FW 4.510 {08-2018 } 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 = tonumber(fibaro:getName(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 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 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
Bedeutet dies, das Gerät 65 über 2 Geräte 79 und 77 am HC2 (1) hängt? Oder wechselweise, also mal direkt oder mal über 79 oder 77?
Was ist mit Neighbour gemeint? Geräte die am gleichen Knoten hängen?
Das ist schon die Route In deinem Beispiel 65 -> 77-> 79-> 1. Du solltest bei bei jeder Route als letztes 1 stehen haben. 1 Ist die Zentrale vermutlich HC2.
Anders wie bei einem PC-Netz in dem du ja Switche hast die intelligent verteilen gibt das Endgerät die route direkt mit. So geht das auch schneller. Wenn einer Route nicht funktioniert werden die Nachbarn ausprobiert. Das sind die Geräte die eine ID direkt sieht. Diese Route wird dann im Routing Tabel der Zentrale gespeichert. Diese Mesh Informationen werden dann zwischen Zentrale und Knoten synchronisiert. So lernt dann der Knoten wenn eine Route nicht mehr funktioniert hat. Er speichert die Route und gibt sie bei nächsten Aufbau mit der Zentrale wieder aus.
Bei Assotiationen funktioniert das auch ohne Zentrale. Deswegen ist auch die Anzahl der Knoten auf 5 beschränkt. Also Zentrale und Endgerät und 3 weitere “Zwischenstationen”. Das ganze muss ja im Endgerät gespeichert werden.
Sie dir mal mit “IP_des_HC\Api\devices” in deinem Browser an was die Zentrale so gepeichert hat.
Was ich noch nicht rausbekommen habe, die Anfrage läuft aber bei Fibaro, wann und wie das Hc das Mesh handelt. Verantwortlich dafür ist immer das Gerät mit der ParentId 1 (also die Pappschachtel) die hat ja meist keinen Namen deswegen ist Jeep auf die Idee verfallen die nächst Id zb. bei die 66 nach Namen und evtl Raum abzufragen. Was z.B bei meinen Foscams nicht funktioniert und Nil bringt bzw. den API not found Fehler weils die Id halt nicht gibt.
Auch habe ich Fibarogeräte bei denen die Schachtel ID 50 hat und das nächste Gerät z.B. 55 vor allen bei exludierten, resteteten und wieder includierten Geräten…
Ich bin mir relativ sicher, dass dieser Report den wir da abfragen und auswerten nicht der letzte aktuellste Stand des Mesh ist. Auch habe ich Veränderungen in Namen und Raum durchgeführt die “freiwillig” nach 2 Tagen noch nicht im Report sichtbar waren. Manchmal hat eine Mesh Rekonfiguration der ID geholfen oder ein Neustart der HC.
Ich hätte da noch einige Fragenzeichen aber so langsam wird mir das teilweise seltsame verhalten meine Netzes klar. Ich hab z.b einen weit entfernten Switch in meinem Schiebetor. Ich hatte die Anbindung schon aufgegeben als er nach 2 Tage plötzlich nicht mehr als Dead Node angezeigt wurde. Wenn ich mir die Route jetzt ansehe geht s in den Dachboden dann in Keller dann zum HC. Bei Neustart ist er gelegentlich DeadNode für ein paar Stunden, funktioniert aber ansonsten zuverlässig.
Irgendwie macht das das Z-wave Mesh ganz raffiniert wenn man nicht ständig über Konfiguration zwave das gesamte Netz rekonfiguriert. Ich habe nur noch nicht raus bekommen wie. Auch diese Zniffergeschichte misst halt auch nur von “ausserhalb”, deswegen seh ich das auch nur als Anhaltspunkt.
Ich würde mich wirklich freuen wenn sich hier ein paar Leute träfen mit den man sowas diskutieren kann und die nicht nur erwarten das man ihnen innerhalb von 5 Minuten ein VD schreibt, das ihnen ihr Problem löst, das sie morgen schon gar nicht mehr haben.
Im engl. Forum hab ich schon ein zwei Partner aber die sind mir wiederum zu schlau. Das funktioniert zwar dann aber ich weiß nicht warum und das hilft mir dann auch nicht wirklich weiter.
@Jeep
Hast du wegen der grafischen Darstellung des Mesh ein Idee?
Ich hab deinen "Cyan"output- string etwas anders formatiert und an Excel übergeben. Dort hab ich dann jede ID in ein Grafikobjekt gesetzt und will dann die LWR mit Pfeilen nachzeichnen, was dann des Mesh ergeben müsste.
Ich hab allerdings noch ein HCL eingefügt und einige IDs am HC2 excludiert und im HCL includiert, was natürlich das ganze Mesh durcheinander gebracht hat. So das ich beinahe täglich ein neues Mesh bekomme.
Auch habe ich IDs mit LWR [] und das sind auch noch welche die häufig in den LWRs der anderen IDs vorkommen. Wenn ich die Timestamp der LWR auswerte scheint die täglich neu zu sein. Bei manchen Geräten steht aber auch ein Datum von 1970.
Wie gesagt da ist aktuell einfach so viel Veränderung bei mir drin, dass ich eigentlich keine Schlüsse daraus ziehen kann. Ein Gerät (double Switch 2)hab ich allerdings gefunden das selbst einwandfrei funktioniert sich aber weigert andere zu Routen. Ich hatte keine Reserve mehr und musste Switche bestellen. Bin mal gespannt, wenn ich den Switch ersetze, was das für Auswirkungen auf das Netz hat.
@Jeep: Dank Dir für die neue Version. Läuft…
@Gerhard: Danke für die Ausführung. Hilf das ganze wieder ein bisschen besser zu verstehen.
Die Anzahl meiner Komponenten hält sich vermutlich im Gegensatz zu den meisten in Grenzen. 11 Netz- und 20 Batterie betriebene. Derzeit gibt es auch keine nennenswerten Probleme. Ich fände es einfach super wenn man das Netzwerk irgendwie darstellen könnte. Da interessiert mich einfach nur die Technik.
Ich habe mir die Konfiguration heute nochmal ausgeben lassen. Und siehe da: Heute Nacht hat sich das Netz offenbar rekonfiguriert. Die Routen haben sich tw. geändert.
Wie könnte man denn die Darstellung verbessern? Wie Gerhard schon bemerkt hat, bezieht sich der Knoten auf das Parent-Device (welches im allgemeinen unbenannt und versteckt ist -> Pappschachtel). Wäre es eine Möglichkeit dieses zu benennen?
Oder wenn Jeeps Skript das nächste Device sucht, nur die nehmen die nicht versteckt sind? Oft sind es bei mir auch die ersten Unterdevices, die versteckt und unbenutzt sind.
Wie benennt Ihr eigentlich Eure Devices? Ich stelle hier gerade fest, dass es von Vorteil wäre, z.B. EG oder OG vorne anzustellen um etwas mehr Info zu bekommen. Oder könnte man da das Skript noch etwas ausbauen indem es Räume und Sektionen zu den IDs ausgibt?
Übrigens gibt das HC-Toolkit eine schöne Liste mit allen IDs aus, in der man schneller suchen kann (HC2Config.txt).
Ein etwas merkwürdigen Fall (das angesprochene Device 65) habe ich in den Ausgaben entdeckt. Das Ist ein Fibaro Universal Binary Sensor, welcher im Keller meine Heizungsanlage überwacht, also netzbetrieben (Alle Eingänge verwendet: 2xIn, 4xTemp). Hier gibt es noch weitere Netz- und Batterie betriebene Geräte. Im EG keine Netz betriebene. Das HC2 steht im ersten Stock. Die Ausgabe schaut so aus:
Neighbours of device 65) 65.0 : [1,5,74,77,79,106,113,132,167,205,228]
Last working route used by device 65 : [1,142,77]
Last WRRT for device 65: 03:09:21 - 17 Aug. 18
Das 65.0 ist irgendein Bewegungsmelder der zum UBS gehört (Habe jedoch keine Ahnung was das ist, da ja eigentlich alle Eingänge verwendet werden. Egal). Das Gerät nimmt die Route: 65 (UBS) -> 77 (Wallplug Keller) -> 142 (Wallplug OG) -> 1 (HC2) wenn ich es richtig verstehe. Soweit alles ok…
Neighbours of device 5) Schachtpumpe : [7,65,74,77,79,84,87,106,132,142,144,146,155,159,167,179,187,190,205,219,228,232]
Last working route used by device 5 : [1,65]
Last WRRT for device 5: 03:09:48 - 17 Aug. 18
Die 5 ist ein Wallplug im Keller der eine Pumpe überwacht. Komischerweise nimmt dieses Gerät die Route über das 65 und dann direkt zum HC2: 5 (Wallplug) -> 65 (UBS) -> 1 (HC2). Warum nimmt das 65 dann nicht auch gleich den direkten Weg???
Hi @Ändy
Wie könnte man denn die Darstellung verbessern? Wie Gerhard schon bemerkt hat, bezieht sich der Knoten auf das Parent-Device (welches im allgemeinen unbenannt und versteckt ist -> Pappschachtel). Wäre es eine Möglichkeit dieses zu benennen?
Mach dir doch mal den Spaß und lass dir “ip_Hc\api\devices” im Browser anzeigen. Kopier das ganze vielleicht in Word da kannst du besser suchen and Formatieren.
Ich stelle hier gerade fest, dass es von Vorteil wäre, z.B. EG oder OG vorne anzustellen um etwas mehr Info zu bekommen. Oder könnte man da das Skript noch etwas ausbauen indem es Räume und Sektionen zu den IDs ausgibt?
Dann siehst du dass die Räume auch in einer Variablen stehen. Ich denke du kannst dir dann auch selber die Werte ausgeben, die dich interessieren. Problem ist vielleicht noch die Aufbereitung der Zeit. Hier werden die Sekunden seit dem 1.1.1970 gezählt. Ich kann dir bei Interesse die Formel posten.
Warum nimmt das 65 dann nicht auch gleich den direkten Weg??? Genau diese Frage stelle ich mir auch, habe aber festgestellt dass dies keineswegs statisch ist. Also über die Zeit wird das immer besser. Nur dadurch dass ich mit dem HCl zusätzlich gerade rumbastle, kann ich überhaupt keine Aussage mehr treffen. Ich muss erst mal alle so Einrichten wie ich es mir vorstelle und dann mal ein paar Wochen nicht am Netz rumfummeln und die Veränderung dokumentieren.
Wie und wann bzw. wie oft das Mesh sich rekonfiguriert wollte ich vom Fibaro-Support erfahren, aber ich hab wenig Hoffnung da konkrete Aussagen zu bekommen.Ich glaube aber festgestellt zu haben, dass die nicht optimale Route in deinem Beispiel vom Mesh selbst optimiert wird. Man darf nur nicht zu oft rekonfigurieren, denn dann wird je nach Einstellung die Route oder gar der ganze Table komplett verworfen und das Spiel geht von vorne los.
Hast du keine Geräte die dir eine leere Route liefern?
Neighbours of device 65) 65.0 : [1,5,74,77,79,106,113,132,167,205,228]
Last working route used by device 65 : []
So was z.B.?
Hast du noch andere als Fiabro Geräte z.B. Danfoss, Popp, Foscam? Dort meine ich ist der Aufbau der Geräte Informationen gelegentlich anders und dann scheitert das Skript von Jeep (hab aber die neue Version noch nicht ausprobiert, da ich wie gesagt Anpassungen in der Vorgängerversion gemacht habe)
Übrigens gibt das HC-Toolkit eine schöne Liste mit allen IDs aus, in der man schneller suchen kann (HC2Config.txt). Das wollte ich schon lange mal nutzen, bin da schön öfter darauf hingewiesen worden. Weiß du wo ich es finde?
Hallo @Gerhard,
deinen Link mit der api hab ich ausprobiert. Fand die Toolkitliste aber dann doch übersichtlicher. Trotzdem nochmal danke für den Hinweis.
Dann bleibt vorerst wohl nur der Weg bei Problemen gezielt nach einem bestimmten Gerät zu suchen und zu analysieren. Ich fänd auch was grafisches besser, evtl. in ASCII-Art? Vorerst wäre aber die genaue Bezeichnung der Devices und Platzierung in den Räumen schon hilfreich. Hab das halt nur bei den Devices gemacht, die ich auch brauche. Die hidden Devices hab ich da einfach vernachlässigt.
Das Toolkit gibt es offenbar leider nur in einem französischen Forum zum Runterladen nachdem man sich registriert hat. Ich hab es seinerzeit hier bekommen. Keine Ahnung ob es immer noch funktioniert mit der neuen Firmware.
Es gibt aber eine neue Version:
Vielleicht können @Matthias oder @pblacky es irgendwo zugänglich machen?
Ich meine aber Du kannst die alte Version auch unter help->check for update direkt aus der Anwendung updaten. Kann es mir ansonsten nicht erklären, warum ich eine aktuelle Version habe
Hallo Ändy,
ich meinte damit nur du kannst dir das Script ja selber erweitern
mit api.post(’/devices/’… mDevID …’/action/getNeighborList’) Zeile 29 im Script bekommst du ja die Nachbarliste
Wenn dich der Raum interessiert müsstest du das script halt mit
api.post(’/devices/’… mDevID …’/action/getroomID’) ergänzen
oder mit getdead alle DeadNotes anzeigen lassen.
¶{“id”:77,“name”:“MeGang”,“roomID”:64,“type”:“com.fibaro.FGMS001v2”,“baseType”:“com.fibaro.FGMS001”,“enabled”:true,“visible”:true,“isPlugin”:false,“parentId”:65,“remoteGatewayId”:0,“viewXml”:false,“configXml”:false,“interfaces”:[“battery”,“fibaroAlarm”,“fibaroAlarmArm”,“fibaroBreach”,“fibaroFirmwareUpdate”,“tamper”,“zwave”,“zwaveAlarm”,“zwaveMultiChannelAssociation”,“zwaveSceneActivation”,“zwaveWakeup”],“properties”:“pollingTimeSec”:0,“wakeUpTime”:900,“zwaveCompany”:“Fibargroup”,“zwaveInfo”:“3,4,5”,“zwaveVersion”:“3.2”,“alarmDelay”:“0”,“alarmExclude”:“true”,“alarmLevel”:“0”,“alarmTimeTimestamp”:“0”,“alarmType”:“2”,“armConditions”:"{“auto”:false,“devices”: “id”:77,“propertyName”:“value”,“propertyValue”:“0”}],“time”:0}",“armConfig”:“0”,“armDelay”:“0”,“armError”:"{}",“armTimeTimestamp”:“0”,“armed”:“false”,“batteryLevel”:“100”,“batteryLowNotification”:“true”,“configured”:true,“dead”:“false”,“deadReason”:"",“defInterval”:“0”,“deviceControlType”:“0”,“deviceIcon”:“90”,“emailNotificationID”:“0”,“emailNotificationType”:“0”,“endPointId”:“0”,“fibaroAlarm”:“false”,“firmwareUpdate”:"{“info”:"",“progress”:0,“status”:“UpToDate”,“updateVersion”:“3.2”}",“lastBreached”:“1533501663”,“log”:"",“logTemp”:"",“manufacturer”:"",“markAsDead”:“true”,“maxInterval”:“0”,“minInterval”:“0”,“model”:"",“nodeId”:“2”,“parametersTemplate”:“712”,“productInfo”:“1,15,8,1,16,1,3,2”,“pushNotificationID”:“0”,“pushNotificationType”:“0”,“remoteGatewayId”:“0”,“saveLogs”:“true”,“sceneActivation”:“0”,“serialNumber”:“h’000000000004b705”,“smsNotificationID”:“0”,“smsNotificationType”:“0”,“stepInterval”:“0”,“tamper”:“false”,“tamperMode”:“TAMPER”,“tamperOperatingModes”:"[“TAMPER”,“TAMPER_SEISMOMETER”,“TAMPER_ACCELEROMETER”]",“updateVersion”:"",“useTemplate”:“true”,“userDescription”:"",“value”:“false”},“actions”:{“abortUpdate”:1,“forceArm”:0,“meetArmConditions”:0,“reconfigure”:0,“rertyUpdate”:1,“sceneActivationSet”:0,“setArmed”:1,“setInterval”:1,“setTamperMode”:0,“startUpdate”:1,“updateFirmware”:1},“created”:1533506605,“modified”:1533506605,“sortOrder”:9}¶
Hallo zusammen,
ich habe das zweite Skript 1:1 kopiert und es läuft auch an.
Allerdings stoppt es bei mir nach der Ausgabe des ersten Devices, ohne dass eine Fehlermeldung im Debugfenster ausgegeben wird.
Irgend eine Idee, woran das liegen könnte?
Danke und Gruß
@Gerhard,
habe das Toolkit in der Dropbox abgelegt.
https://www.dropbox.com/s/hzxcoipli6n9f38/HCToolkit_1.3.2.0.zip?dl=0