Beiträge von Benzman81

Lass doch alles weg wo optional steht, soviel ist das nicht. Hab noch nie was mit dem webinterface gemacht. Alle entwickler posten immer beispiel configs, einfach kopieren und werte anpassen

Danke Nastra und rel

Lars83 Ja, ausblenden in den Favoriten sollte passen.

bridge_url: ist url zur api deiner Bridge, z.B. "http://10.0.0.1:8080"

api_token: ist der token, den du in deiner Bridge eingestellt hat

webhook_server_ip_or_name: ist die IP oder der Name von dem Server wo Homebridge drauf läuft

Und die id des Schlosses bekommst du mit http://your-nuki-bridge-url/list?token=your-nuki-api-token . Dort steht die.

Lars83 evtl kannste es auch einfach drin lassen und nur nicht bzw bei bedarf nutzen. Glaube nicht, dass das problematisch ist.

Die nuki app bleibt davon unberührt. Ggf kannst du auch nativ den türkontakt in HK einbinden und nur das schloss nicht. Da ich aber kein Nuki v2 hab kann ich das nicht sagen.

Lars83 die bridge brauchst du, darüber kommuniziert das plugin mit nuki. Ob du dennoch den türkontakt nutzen kannst weiß ich nicht. Remotezugriff läuft bei mir dann mit HK da ich einen entsprechenden hub zubhajse habe (appletv und homepod).

Zitat von Lars83

Hallo ich habe bereits ein Nuki 2.0 mit Bridge und Türsensor alles eingebunden über Homekit .
Nun würde mich interessieren was der vor bzw Nachteil ist wenn man es über die HB einbindet?
Was gibt es zu beachten bzw was muss alles in der Config eingestellt oder angepasst werden?

Gesendet von iPhone mit Community

Nun ja, nativ bekommst du ein Schloss, welches auf und zu schließen kann und den türsensor. Hast du eine Tür mit Türfalle. Dann kannst du nur abschließen und tür aufschließen mit falle ziehen. Es gibt dan kein reines aufschließen mehr.
Mit meinem HB plugin bekommt man in dem Fall aber zwei Schlösser, eines zum reinen auf/abschließen und eines nur um die falle zu ziehen. Du hast dann also mehr Möglichkeiten. Allerdings kann die Bridge, und somit auch mein HB plugin, nicht mit dem Türkontakt arbeiten.

wie du das einrichtest, steht in der readme.

NEUE VERSION 0.10.0:

• Wenn man ein Schloss mit Falle hat, dann werden nun nicht mehr drei Schlösser in HK erstellt, sondern nur zwei. Eins für reines Lock/Unlock und eins nur um die Falle zu ziehen, welches immer geschlossen dargestellt wird. Dies wurde nun so umgesetzt, da die persönliche Erfahrung zeigt, dass man nur diese beiden braucht. Da ein Schloss entfernt wurde müssen alle Szenen/Automationen angepasst werden, die dieses Schloss verwendet haben.
• Wenn man ein Schloss mit Falle hat, dann wurde nun ein Schalter hinzugefügt, der das ziehen der Falle de-/aktiviert. Somit kann man über Automationen das gewünschte verhalten einstellen (z.B. Orts oder Zeit abhängig). Dies kann unabsichtliches ziehen der Falle verhindern.

det danke für die vielen tests, ohne dich wär das nicht möglich gewesen.

Zur Türklingel kann ich dir dieses Feature Request zum Hochvoten verlinken: Klingel Feedback in Bridge API

det @Natra der branch "openersupport" ist nun im "master" und in ppm mit version 0.8.0. Bis auf den Bug in Homebridge oder bei Apple mit iOS 13 ist somit alles funktional.

det also, hab beim state handling noch etwas behoben, wie oben erwähnt. Allerdings konnte ich dein gemeldetes verhalten nicht nachstellen. Bis gestern. Denn nun bin ich auch auf iOS 13 und krieg es auch hin, dass man manchmal eine Aktion gar nicht ausführen kann bzw. der status sofort zurückspringt. Dies rührt daher, dass mehrmals die setState Methode zum setzen des Status aufgerufen wird, wenn es nicht gemacht werden sollte. Hab dazu auch mal einen Bug bei HAPNodeJS gemeldet, da ich das in einem Mini-Beispiel-Plugin auch nachstellen kann, dass mehrmals setState aufgerufen wird. (Issue bei HAPNodeJS).

Hast du ggf. noch ein Device auf iOS 12 oder einen Mac mit Mojave laufen? Auf meinem Mac in der Home App kann ich nämlich das verhalten nicht nachstellen, genau wie vorher bevor ich auf iOS 13 gegangen bin. Falls du noch solch ein Device oder Mac hast, kannst du dann nochmal das Plugin updaten (nicht stören, dass es noch v0.8.0 ist ) und auf eines dieser Devices testen. Ich glaub nämlich, dass dann dort alles tut, wie bei mir.

Zitat von rel

Hallo, hab das Plugin am Laufen.

Mit iOS 13.1 gibt es eine neue Kachel. Die muss ich drücken, dann kommen 2 Regler, einmal Sperren/Entsperren und einmal Türfalle ziehen.

Was man aber bräuchte, wären eigentlich folgende 3 Dinge als Einzelkacheln:

1. Sperren/Entsperren

Abends (automatisch) die Tür sperren, also verschließen. Morgens (automatisch) entsperren, also aufschließen, damit der erste die Tür per Klinke öffnen und das Haus verlassen kann.

2. Entsperren und gleichzeitig Türfalle ziehen.

Man kommt nach Hause, Tür ist verschlossen, Schloß entsperrt und öffnet gleichzeitig durch Türfalle ziehen.

3. Nur Türfalle ziehen.

Man ist zu Hause, geht mal schnell raus (Müll wegbringen) und will wieder rein. Tür ist nicht verschlossen, also nur Türfalle ziehen.

Am liebsten wäre mir eine Funktion „Öffnen“, wo die Tür, abhängig vom Zustand, entweder

1. aufschließt und Türfalle zieht oder

2. nur Türfalle zieht,

ohne dass ich 2x drücken muss.

Jemand eine Idee, ob das möglich wäre?

Alles anzeigen

rel ich weiß, dass das mit meinem Plugin möglich wäre homebridge-nukiio. Genau die Fälle wollte ich nämlich auch abgedeckt haben.

det ich hab noch einen bug im ringToOpen gefunden, vielleicht hängt das zusammen. Ich meld mich mit einem Update.

det sowohl der erste, als auch der zweite teil zeigt, dass immer nur lockAction 3 aufgerufen wird. Dies passiert bei mir eigentlich nur, wenn das schloss für den buzzer aktiviert wird (der name den du für das schloss vergibst). Bei den beiden anderen wird eine andere action gesendet.

rel du hast einen token der web.nuki.io API verwendet. Das ist leider falsch. Du musst den Api Token nehmen, den du beim Einrichten deiner Nuki Bridge frei wählen kannst.

README:

• The API token, can be configured when setting up the bridge in the Nuki App

det  rel sorry für die Verspätung, irgendwie hab ich keine mail Benachrichtigung bekommen. Ich guck mal, was bei euch das schief geht.

det krieg ich einfach nicht nachgestellt. Hattest du das Plugin mal auf den neusten Stand gebracht vorher?

det danke erneut. Für das Problem mit dem Continous mode zurückstellen bräuchte ich ein längeres log ab dort, wo die lockAction zum aktivieren des continous modes kommt. Ich kann das nämlich nicht nachstellen. Dass sich Ring to Open nicht schließen lässt solange Dauermodus aktiv ist, ist ja richtig, geht ja in der App auch nicht.

Nastra richtig, aber es sollte schon noch der Branch openersupport verwendet werden, weil da auch der fix mit dem 503 fehler drin ist. Sobald der opener richtig funzt geht es in den

master und wird auch in npm release.

Nastra dass das andere Plugin "homebridge-nuki" z.Z. besser funzt liegt an zwei Sachen:

a) Das Plugin versucht alle Fehlerhaften Requests neu, ich bin da eher selektiv.

b) Das Plugin setzt keine Timeouts für die Requests und würde somit sehr lange auf Antwort warten.

Das bringt mich auch zu deinen Fehlern (ESOCKETTIMEDOUT und ETIMEDOUT). Du hast in deiner Config für mein

Plugin noch relativ alte Werte (waren auch bis eben falsch als Default in der Readme gelistet)drin.

"request_timeout_lockstate" ist im default 15000 und "request_timeout_lockaction" ist 45000.

Der Wert für "request_timeout_lockstate" wurde auch für alle anderen Requests außer der lockAction

verwendet, daher gibts schon Probleme beim Start des Plugins mit deinem Wert von 5000 beim Holen

der Callbacks. Jetzt gibts einen neuen dritten Parameter "request_timeout_other" mit dem Default 15000

für alles außer lockState und lockAction. Ich habe in meiner Config z.B. keine Werte angegeben und

nutze de defaults und bekomme mit Bridge Hardware Rev 1 keine ESOCKETTIMEDOUT und ETIMEDOUT.

Das hatte also nix mit mehreren Locks zu tun, sondern mit nicht praktikablen Timeout werten.

Wenn die diese nun korregierst oder raus nimmst, dann sollte es auch bei dir mit der Version

aus dem Branch "openersupport" passen

(fingers crossed)