Beiträge von Benzman81

  • homebridge-people

    Zitat von Nastra

    vielleicht kannst du uns noch aufklären wo genau der unterschied zwischen People und People Plus jetzt ist. Außer das People mit IP Adressen und People Plus mit Mac Adresse arbeitet? Kommt doch schlussendlich auf das gleiche raus, vorausgesetzt ich habe feste IP Adressen im Netzwerk oder übersehe ich da was?

    Würd ich auch sagen, da die Handys ja das WLAN aus Akku-schon-gründen deaktivieren im WLAN, wär komisch, wenn die dennoch verfügbar wären.

    Zitat von Nastra

    Was sind diese Webhooks genau bzw. wofür werden diese genutzt?

    Das kann genutzt werden, damit irgendein Service oder eine App im People Plugin eine Statusänderung bewirken kann, z.B. IFTTT bei verlassen eines Geofences.

    Zitat von Nastra

    Welches Geo nutzt du? iConnectHue über homebridge-hue?

    Schon viel versucht: Apple Home App, IFTTT, Locative, etc. keiner zuverlässiger als der andere. Bin im Moment bei IFTTT hängen geblieben.

  • homebridge-people

    Wollt auch mal meine Infos dazugeben, da ich die Umstellung auf Platform und einen großen Umbau des People Plugins gemacht hatte.


    Das Ursprung People Plugin konnte nur mit WLAN arbeiten. Per WLAN eine An-/Abwesenheit zu ermitteln ist jedoch nicht immer gut. A) kommt es bei Ankunft evtl. zu einer Verzögerung wenn Handy in der Tasche ist oder so, und B) muss beim Verlassen ein so hier (15min default) wert gewartet werden, weil die Handys auch das WLAN im standby verlassen. Bei meiner Frau musste ich das auf 20 min setzen, da ihr iPhone sich seltener Connected als meins im Standby. Dies kann viele Ursachen haben, z.B. auch die installierten Apps.

    Aus diesem Grund wurde die Funktionalität von Webhooks eingebaut, damit man zusätzlich oder ausschließtlich darauf basierend die Anwesenheitserkennung lösen kann. Wenn man ausschließslich GEO nutzt, dann kann man auch die von Apple verwenden.


    Meine Erfahrung ist, das WLAN die Anwesenheit vor der Tür sehr schnell erkennt, die Abwesenheit halt erst nach den 15-20 min. GEO, egal welche App, erkennt Ankunft und Verlassen des Bereiches ziemlich gut, jedoch habe ich hier auch Fälle wo der GEO nicht triggert. Daher hab ich WLAN und GEO aktiv, so dass am besten der GEO das Verlassen schaltet, und im schlimmsten Fall das WLAN verlassen nach 15-20 min zieht. Ich habe auch in meiner ganzen Wohnung iBeacons und damit gespielt. Leider gibt es hier keine App, die Zuverlässig An- und Abwesenheit mitbekommt.


    Alles in allem muss ich sagen, dass ich mit People Plugin und/oder GEO auf jeden Fall keine Sicherheitsrelevanten Geräte zur Zeit schalten wollen würde. Nur lichter aus/an oder ähnliches. Einfach weil es nicht zu 100% funzt.


    Ich selbst verwende Nuki als Schlösser und die Nuki App ist was das betrifft einfach zuverlässiger.


    Ich hoffe die Infos helfen ein wenig.

  • homebridge-nukiio

    Zitat von Nastra

    Bin auch am überlegen ob ich eventuell mir Nuki zulege, bräuchte aber 2 Stk da ich einen Panzerriegel in der Tür habe.

    Hab auch zwei schlösser, synchron wird das nicht gehen, da die Bridge nur eine BT Verbindung aufbauen kann. Evlt. würde es mit zwei bridges mit je einem schloss funzen.

  • homebridge-nukiio

    Zitat von Wilfhelm2

    ergebnis: {"callbacks": [{"id": 0, "url": "http://192.xxx.x.xxx:51827/"},{"id": 1, "url": "http://192.xxx.x.xxx:51872:51827/"}]}

    lösch mal alle callbacks via http://x.x.x.x:8080/callback/remove?token=deinToken&id=0 im Browser.

    Zitat von Wilfhelm2

    und weil ich das dann einfach alles nochmal teste/durchführe, bekomme ich jetzt von nuki bei request


    {"success": false, "message": "too many callbacks registered"} zurück. was -eigentlich- auch ok sein sollte, da ja vorher schon einmal erfolgreich gemacht.

    Eigentlich erkennt das Plugin bei gleichbleibender Webhook IP und Port, dass dieser Callback schon da ist, und würde diesen dann nicht nochmal hinzufügen

    Zitat von Wilfhelm2

    Request for lock state aborted. This is no problem and might happen due to canceled request or due to long response time of the Nuki bridge. Using cached value isLocked = 'true'.

    Dieser Fehler ist selten und tritt wirklich nur auf, wenn Nuki lange braucht.

    Zitat von Wilfhelm2

    hab ich kein cache, den nuki bräuchte?

    wird automatisch angelegt, musst dich um nix kümmern

    Zitat von Wilfhelm2

    timeout zeiten zu lang/kurz (ist default) ?

    Die Default werte stammen aus eigener Erfahrung. Hier kann es je nach Umgebung zu Abweichungen kommen, deswegen ist die konfigurierbar.

    Zitat von Wilfhelm2

    wenn ich das nuki jetzt per browser (von ferne) öffnen/schließen will, bekomme ich im browser den hinweis: "smartlock aktion fehlgeschlagen"

    Wie machst du das aus der ferne per browser? via VPN?

  • homebridge-nukiio

    Zitat von det

    öffnen/schliessen mit Handy und Geo beim verassen oder kommen funktioniert?

    Ja

    Zitat von det

    integrationin HB funktioniert nur mit Bridge (hier ist Android verboten)?

    Soweit ich weiß, sollte auch die Android Bridge funzen, da diese mitlerweile auch die Callbacks unterstützt.

    Zitat von det

    was ist gemeint mit GEO von Apple?

    Du kannst 3rd Party apps nutzen zur Ausführung von Aktionen via Geolocation oder die Apple Home App. Letzterer ist hier gemeint.

    Zitat von det

    Wann kommen die Nachricht welche man bestätigen muss?

    Wenn man via Apple Home App die Geolocation in Verbindung mit sicherheitsrelevanten Geräten, z.B. Schlösser, nutzt, dann führ Apple diese Aktionen nicht direkt aus, sondern man bekommt eine Meldung auf dem Handy, die man dan bestätigen muss.

    Zitat von det

    Wozu der Delay Switch benötigt wird, konnte ich noch nicht nachvollziehen

    Dazu kann ich nix sagen.

  • homebridge-nukiio

    Bei einem nicht freien port wäre die meldung eindeutig (irgendwas mit isInUse oder so.

    Bei einem nicht freien port wäre die meldung eindeutig (irgendwas mit isInUse oder so.


    Der fehler "ECONNREFUSED 192.xxx.x.xxx:80" deutet eher dadrauf hin, dass die ip und der port der bridge nicht stimmen. Ist denn port 80 richtig? Im standard ist es 8080.

  • homebridge-nukiio

    In der url http://deineipdernukibridge zu finden unter http://deineIpDerNukiBridge:port/list?token=deintoken musst du natürlich die richtige ip deiner nuki bridge mit entsprechendemmport und token eintragen ?

  • homebridge-nukiio

    Zitat von Maz

    Also nochmal zur ID. Ich habe angenommen das diese in der nuki App unter verbindungsstatus zu finden ist. Die habe ich auch eingetragen. Damit habe ich aber keine aktuellen lock states bekommen sondern diesen Fehler.

    Code
    [2/28/2017, 6:34:09 PM] [Nuki] [INFO Nuki WebHook Server] No lock found for nukiId 'xxxxxx'

    und die Nuki ID aus dieser Meldung habe ich eingetragen in die config bei ID. das war es was ich die ganze Zeit sage. Ich bin sonst nirgends auf diese Id gestoßen. Und in der Anleitung habe ich das auch nicht verstanden.

    in de aktuellen redme sollte es nun klarer sein ?

  • homebridge-nukiio

    Kann das sein, das du den config block innerhalb des keys accessesories eingetranen hadt und nicht unterhalb von platforms?

  • homebridge-nukiio

    Also, es ist eine platform, somit muss man nicht direkt accessesories definieren. Diese werden automatisch ais den definierten Schlössern erzeugt.


    Bridge url = http://deineIpDerNukiBridge:port

    Token = bekommt man in der nuki app beim einrichten der bridge mit developer mode

    webhook server ip oder name = ip oder name des servers auf dem homebridge läuft

    webhook port = der port den der interne server für webhooks verwenden soll ( sollte ein freier port sein)

    lock id = nuki id deines schlosses, zu finden unter http://deineIpDerNukiBridge:port/list?token=deintoken


    Hoffe das hilft.