Beiträge von Benzman81

det perfekt dargestellt und aufgelistet, danke dafür. Hab beim contiunous mode noch nen status falsch gesetzt. Evtl. behebt das nun die Probleme.

Wäre mega, wenn du deine letzten tests nun nochmal mit der neuen version auf dem branch "openersupport" testen könntest.

Dabei dann bitte folgendes nochmal genauerprüfen, kann das nämlich nicht nachstellen wenn der Webhook mit den Werten aus dem

Log rein kommt:

Zitat

NukiAPP Dauermodus auf ein

Dein Dauer modus auf ungesichert

Dein RingToOpen auf gesichert

Und eine Frage hab ich dann noch:

Wenn Du ringToOpen in der App aktivierst und dann den DauerModus in der App aktivierst und kurz danach dort wieder deaktivierst,

ist dann ringToOpen in der App mit einem laufenden Timer von vorher noch aktiv oder ist dann ring to open auch direkt aus? Bei mir behält er nämlich z.Z. den Status von vorher, sprich ich gehe davon aus, dass ringToOpen dann noch aktiv ist. Müsste ich dann noch anpassen falls sich die App hier anders verhält.

Nochmals vielen Dank für die Ausführlichen Tests!

det dass heißt das plugin dürfe bei dauerbetrieb AN nichts tun wenn ich ring to open deaktivieren drücke (schloss schließen). Richtig, oder? Erst muss der Dauermodus beendet werden...

Verstanden, gut erklärt.

Nastra alles gut, wie könnte ich böse sein Versuch ja auch nur das Plugin für alle Stabil zu bekommen. Ich habe auch nur das Handling der 503 Fehler explizit verbessert. Die Fehler die du bekommst (ETIMEDOUT und ESOCKETTIMEDOUT) hab ich nicht in mein Retry mit eingebaut. Ich bekomme diese Fehler nämlich nie, trotz zwei schlösser. Ich denk mal drüber nach und verbesser das dann. Wäre nett, wenn du dannach nochmals auf Fehler testen könntest. Meld mich dann wieder hier.

det

zu 1) Gibt es in der App nur einen Button "Ring to Open", der auch für den Dauermodus genutzt wird ? Falls es zwei gibt (so wie in meinem Plugin) dann meine ich, wenn in der APP der dauer modus aktiv ist, kannst du dann in der App den Button RingToOpen gesondert deaktivieren und was passiert dann mit dem Dauermodus? Ist er dann auch deaktiviert? Wenn es allerdings nur einen Button gibt, dann hängt das ja alles aneinander.

zu 2) erwarte ich dann die log wann immer du zeit hast.

Ok, hier sind einige Sachen komisch. Hab mir jetzt mal eine DummyBridge gemacht,

die so reagieren sollte wie die API es hergibt. Für mich scheint jetzt eigentlich

alles stimmig. Hab jetzt auch den ContinousMode und RingToOpen gesync, wenns so richtig

ist. Hoffe das passt so.

Der initiale Status nach Homebridge start sollte nun passen.

Hab aber einige Fragen zum Verhalten:

1) Was passiert in der Nuki App, wenn Continous ein ist ( und somit ja auch Ring to Open) und man

dann ring to open in der App deaktiviert. Geht dann Continous auch aus? So hab ich das jetzt nämlich

mal im Plugin implementiert, weil es für mich nur so sinn macht.

2) Kannst du mal im Homebridge log gucken, ob, wenn du in der App RingToOpen aktivierst ein

Callback ankommt (INFO Nuki WebHook... und HomeKit state change by webhoock complete ...) und ob auch

einer ankommt, wenn die App das nach demTimer wieder zurücksetzt. Wäre super wenn du dann den

entsprechenden output posten könntest.

Danke, dass du so toll testest.

det normalerweise sollte continous mode und ring to open so reagieren, wie in der nuki app. Wie würde das log interessieren, einmal wenn du ringtoopen aktivierst in HK und dann einmal den continous mode. Hast du gleiches verhalten auch in der Nuki App? Wie verhält es sich da?

Wenn man die zwei Einstellungen als Schalter macht, dann ist das ein Sicherheitsrisiko, da jemand ohne passcode mit deinem handy dann diese einstellungen aktivieren könnte und so ins haus kommt...

det so, dieser Fehler ist auch behoben, kannst morgen in Ruhe von weiteren berichten

det ich meinte die hardware version der bridge, haste die schon lange oder in letzter zeit neu gekauft.

Laut deinem log ist da noch ein fehler, beheb ich gleich, dann kannste morgen nochmal die neue version testen. Ist leider schwierig alles wenn man blind entwickelt :-/

Nastra ja, sollte dadurch besser mit mehreren Requests, somit mehr Smartlocks, zurecht kommen. Hab selbst auch zwei.

det  Nastra In dem Branch openersupport ist nun auch drin, dass, wenn bei einer lock action ein 503 Fehler kommt, ein retry mit delay gemacht wird. In der Readme hab ich dazu was geschrieben inkl Konfiguration. Wenn jetzt bei mir ein Callback lief und ich bei lockAction einen 503 bekommen hab, dann versucht der das nochmal, und führt dan die lockAction etwas später aus. Über die Konfiguration kann man das ein bisschen steuern.

det Der Fehler 'ReferenceError: newHomeKitStateLocked is not defined' sollte nun behoben sein. Die 'socket hang up' (ECONNRESET) kann ich nicht nachvollziehen. Normalerweise kommt sowas, wenn die Gegenstelle (NukiBridge) die Verbindung kappt. Nur als info für mich, hast du die Bridge V1 oder V2?

det An dem Fehler hatte ich ja noch nix gefixed, da wir das log dazu bisher nix sagte. Jetzt scheint es besser erkennbar zu sein. Ich guck mal nach dem Grund.

giss69 läuft bei mir ohne Probleme. Hast du einen Fehler/Log.

giss69 für das Plugin homebridge-nukiio ist dies der Fall und sollte funktionieren.

det Zuerst einmal hab ich die Readme in dem Branch angepasst um die Frage zu klären was der Status der einzelnen Schlösser bedeutet.

Es sollte aber genau so sein, wie du selbst erkannt hast. Die Beschriftung des Status kann man leider nicht anpassen.

Der Fehler, dass RingToOpen auf ungesichert und danach wieder zurück auf gesichert geht, sollte nun behoben sein (blind fix).

Der Fehler, dass das Plugin beim Start einen Fehler wirft, wenn die Bridge eine ungültige Antwort liefert (in dem Fall Status 503)

ist gewollt, da dort der Callback registriert werden muss.

Das beim Öffnen der Haustür (Summer hat gesummt) das Plugin abgestürzt könnte ich nirgends im lock to direkt erkennen. Kannst du

das Szenario nochmal sauber durchspielen und das Log nochmal posten und dazu schreiben wann du was ausgeführt/gemacht hast?

det danke für die ersten tests. Ich analysiere das mal.

Du bukommst für den opener drei schlösser, eines welches immer den buzzer betätigt, eines welches ring-to-open aktiviert/deaktiviert und eines welches den continous mode aktiviert/deaktiviert. Es sind alles schlösser, damit man die funtkionen mit siri nicht ohne sicherheitsschutz aktivieren kann. det

Nastra das plugin homebridge-nuki hat, so wie ich den code lese, ähnliche Probleme. Liegt aber im Endeffekt an der Bridge. Ich mach mir da aber z.Z. schon paar Gedanken, wie man das umgehen kann.

det support für Nuki opener ist nun im branch "openersupport". Ist aber komplett blind entwickelt, da keine Testmöglichkeit.

Zum installieren und testen kannst du zb folgendes nutzen:

npm install -g 'benzman81/homebridge-nukiio#openersupport' --unsafe-perm

Für tests und feedback wäre ich dankbar.