Ke$ch hab nen satz in der doku ergänzt: The cache directory is used to cache the state of the locks. It must point to a validand empty directory and the user that runs homebridge must have write access.
Das Verzeichnis /var/homebridge/persist/ ist bei dir warscheinlich das persist verzeichnis von homebridge. Fall ja, nimm ein anderes, denn das ist nicht leer.
Zeig mal dein log. Von da wo Homebridge startet, bis es "fertig" gestartet ist.
Hier meine json Benzman81 .
CodeAlles anzeigen{ "bridge": { "name": "Homebridge", "username": "xxxxxxxxxx", "port": xxxxxx, "pin": "xxxxxx" }, "description": "Home Smart Home", "platforms": [{ "platform": "config", "name": "Config", "port": 8080, "auth": "form", "theme": "red", "restart": "sudo -n systemctl restart homebridge", "temp": "/sys/class/thermal/thermal_zone0/temp", "sudo": true, "log": { "method": "custom", "command": "journalctl -o cat -n 500 -f -u homebridge" } }, { "platform": "RademacherHomePilot", "name": "RademacherHomePilot", "url": "xxxxxx" }, { "platform": "TuyaLan", "devices": [{ "name": "xxxxxx", "type": "SimpleLight", "manufacturer": "AISIRER", "model": "MINI SMART WIFI PLUG", "id": "xxxxxxx", "key": "xxxxxx" }, { "name": "xxxxxx", "type": "SimpleLight", "manufacturer": "AISIRER", "model": "MINI SMART WIFI PLUG", "id": "xxxxx", "key": "xxxxxx" } ] }, { "platform": "NukiBridge", "bridge_url": "http://192.168.1.xx:8080", "api_token": "xxxxx", "request_timeout_lockstate": 30000, "request_timeout_lockaction": 60000, "request_timeout_other": 30000, "cache_directory": "./.node-persist/storage", "webhook_server_ip_or_name": "192.168.1.44", "webhook_port": 51827, "lock_state_mode": 0, "lockaction_maxtries": 3, "lockaction_retrydelay": 3000, "add_maintainance_buttons": false, "locks": [{ "id": "xxxxxx", "name": "Nuki 2.0", "usesDoorLatch": true, "priority": 1 }] } ], "accessories": [{ "accessory": "Weather", "apikey": "xxxxxxx", "locationByCoordinates": "lat=xx.xxxxx&lon=x.xxxxxx", "name": "Temperatur" }, { "accessory": "Weather", "apikey": "xxxxxx", "locationByCoordinates": "lat=xx.xxxxx&lon=x.xxxxx", "name": "Sonne", "type": "sun", "pollingInterval": 10 }, { "accessory": "Weather", "apikey": "xxxxxxx", "locationByCoordinates": "lat=xx.xxxxx&lon=x.xxxxx", "name": "Wind", "type": "windspeed" }, { "accessory": "Weather", "apikey": "xxxxxxxx", "locationByCoordinates": "lat=xx.xxxxx&lon=x.xxxxx", "name": "Wolken", "type": "clouds" }, { "accessory": "Weather", "apikey": "xxxxx", "locationByCoordinates": "lat=xx.xxxx&lon=x.xxxxx", "name": "Temp-Min", "type": "min" }, { "accessory": "Weather", "apikey": "xxxxxx", "locationByCoordinates": "lat=xx.xxxxx&lon=x.xxxxx", "name": "Temp-Max", "type": "max" } ] }
Sieht gut aus, wüsste nicht, wieso nix bei dir in HK oder zumindest im log angezeigt wird.
Ke$ch also dass man nirgends was sieht ist komisch. Poste mal die komplette config!datei.
Dennis_BE da ich mein schloss weder über die bridge noch über nuki-web nach außen freigebe, kann ich dazu nix sagen. Das homebridge-http-webhook plugin funktioniert tadellos mit IFTTT.
DJay Historisch ist es so, dass mein Plugin quasi das erste für das Nuki war. Als der Opener kam, hat lukas.roegner dann quasi ein plugin mit opener und und schloss erstellt und ich hab den opener dann nachgezogen. Somit wollen beide eigentlich das gleiche und unterscheiden sich in den Feinheiten. Neben dem von lukas.roegner erwähnten unterschied, dass ich auf die Antwort einer Aktion erst warte bevor ich feedback an Home zurückgebe gibt es noch einen unterschied im Error-Handling. Ich bin da etwas restriktiver und wiederhole Aktionen nur bei bestimmten Fehlern und nicht bei allen arten von Fehlern. Außerdem implementiere ich Features, die meiner Ansicht nach Nuki selbst implementieren sollte oder welche einen Sicherheitsleck bedeuten nicht. Sollte man zwei Schlösser haben, kann man bei mir außerdem noch eine Priorität vergeben und zu regeln, welches schloss zuerst aufgeschlossen werden soll. Alles in allem haben beide Plugins ihre Daseinsberechtigung und ihre eigenen Vor- und Nachteile, denke ich.
Per Bridge leider noch nicht möglich, aber es gibt feature requests dazu bei nuki.
Version 0.0.56 sollte es fixen. Bitte testen. Bei mir läuft nun alles wieder. DJay
Wie jetzt wenn mir bei npm ein Update angeboten wird gehe ich auf @latest und wenn das Update nicht so läuft wie möchte dann gehe ich wieder zurück auf @0.1.1 so habe ich es gemacht und wie meinst du es jetzt
Ja passt. auf @latest sollte man aber nicht gehen, wenn man drauf angewiesen ist, z.B. für Kaffee 
oder Türen, denn wenn der Entwickler über Nacht was kaputt macht und man zufällig nächtlich ein Restart der Bridge macht, dann bekommt man den Fehler ungewollt rein. Wenn man bewusst eine neue Version testen will, dann ist das was anderes, nur mit @latest kommt unbewusst ggf. was neues rein mit einem Neustart.
Sorry 
werd mich heute abend drum kümmern. kleiner tipp, wenn ihr plugins mit expliziter versionsnummer installiert, dann kann euch das nicht passieren
naboo hardewareId und serverId sind von der Bridge, somit wäre nukiId das richtige.
aber Status in Homebridge ist:
[NukiBridge] [INFO Nuki WebHook Server] No lock found for nukiId '109300017'.
die Nuki Id ist aber eine ganz andere. Woher kommt die 109300017???
Die Ids findest du hier: http://bridgeIp:port/info?token=deinToken
hallo,
Ausgabe ist:
Code{"callbacks": [{"id": 0, "url": "http://192.168.2.19:51827/"}]}
und ist 192.168.2.19 der server auf dem Homebridge läuft? ist die IP immer gleich?
naboo ist in der Home App der status auch ungeändert. Falls ja, dann deutet dies auf falsch konfigurierte callbacks hin.
Öffne mal http://bridgeIp:port/callback/list?token=deinToken und gucke, ob da nur ein callback drin ist und ob die url auch auf den Rechner zeigt, der Homebridge ausführt. Die Ausgabe sollte so aussehen:
{"callbacks": [{"id": 1, "url": "http://deinHomebridgeServer:51827/"}]}naboo hast due in der bridge auch den Entwicklermodus aktiviert? Dort kann man auch port und token anpassen check das mal. Solange das nicht über den browser erreichbar ist kann auch das plugin nix machen.
naboo in der fritz musst du keinen port freigeben, soll ja intern erreichbar sein und nicht aus dem internet!
naboo kannst du im browser http://192.168.2.12:80/info?token=deinBridgeToken aufrufen? Falls nicht sind ip oder port falsch.
DJay Als Software Entwickler kann ich dir sagen, dass "verbindliche" zusagen nicht immer seriös sind. Da wir heute in einer Agilen Welt leben kommt schnell mal was "wichtigeres" und schon wird anders priorisiert. In unserer Firma haben wir uns von verbindlichen Zusagen verabschiedet, wobei auch Featurewünsche aufgenommen und "gevoted" werden. Heißt aber nicht, dass ein Feature implementiert wird. Bei aktuell 1917 Benutzer im Nuki Developer Forum sind ca. 50 Votes zum ziemlich wenig für hohe Priorität. Da sind eigentliche Anwender Features oder Integrationen in SmartHome Systeme oder Übernachtungssysteme weitaus wichtiger, denke ich. Just wait and keep calm
DJay leider weiß ich nicht mehr. Aber transparent sind die, finde ich. Man kann Feature Requests erstellen, so dass diese gevoted werden können. So sieht man dort eigentlich sehr transparent, dass dieses Feature zur Zeit aus Anwendersicht an dritter Stelle steht. Zuerst wird dann wahrscheinlich die Magnetkontakt für das Schloss integriert. Was die intern draus machen sieht man natürlich nicht.
naboo das verzeichnis cache_directory muss schreibrecht für den homebridge user haben.