[ NUKI Smartlock ] 73_NUKIBridge.pm und 74_NUKDevice.pm

[CoolTux]

Nein hast nichts falsch gemacht. Das werde ich demnächst mal abfabgen. Geht denn sonst alles soweit?

[Morpheus_1977]

Nein hast nichts falsch gemacht. Das werde ich demnächst mal abfabgen. Geht denn sonst alles soweit?

Ich denke schon, jedenfalls schließt und öffnet das Schloss über FHEM!
Komisch war nur das ich das Attribute genericDeviceType manuell mit attr NUKIDevice112944569 genericDeviceType lock setzen musste.
Das musste ich beim ersten mal nicht.

Naja und das mit dem Siri Problem steht auch noch offen. Das scheint an den HomebridgeMappings zu liegen. Diese wurden beim ersten anlegen der Bridge und des Device auch automatisch gesetzt, jetzt sind keine da und ich kenne mich damit überhaupt nicht aus.
Im Bereich homebridge/homekit bekomm ich leider keine weitere Hilfestellung.

Was bringen eigentlich die Attribute:
webhookFWinstance - zu verwendende Webinstanz (darf keine Passwortabfrage beinhalten)
webhookHttpHostname - IP oder FQDN des FHEM Servers

Ich hab die beiden mal einfach hinzugeügt....

Internals:
   DEF        112944569 IODev=NBridge1
   IODev      NBridge1
   NAME       NUKIDevice112944569
   NR         90
   NUKIID     112944569
   STATE      unlocked
   TYPE       NUKIDevice
   VERSION    0.6.0
   WEBHOOK_COUNTER 0
   WEBHOOK_PORT 8083
   WEBHOOK_REGISTER sent
   WEBHOOK_URI /fhem/NUKIDevice
   WEBHOOK_URL http://192.168.2.45:8083/fhem/NUKIDevice-112944569
   Readings:
     2017-02-10 13:06:06   battery         ok
     2017-02-10 13:06:06   batteryCritical false
     2017-02-10 13:06:06   lockState       unlocked
     2017-02-10 17:36:32   name            Nuki_06BB65B9
     2017-02-10 17:36:32   paired          true
     2017-02-10 17:36:32   rssi            -88
     2017-02-10 13:06:06   state           unlocked
     2017-02-10 13:06:06   success         true
   Fhem:
     infix      NUKIDevice
   Helper:
Attributes:
   IODev      NBridge1
   alias      Nuki Zuhause
   genericDeviceType lock
   room       Homekit,NUKI
   webhookFWinstance WEB
   webhookHttpHostname 192.168.2.45

Ich hoffe das ich die richtigen Daten gesetzt habe? Ohne zu wissen was sie bewirken denke ich sieht das ganz gut aus Oder?

[CoolTux]

Es sollten eigentlich automatisch alle Smartlocks, welche an der Bridge angemeldet sind, in FHEM angelegt werden. Wenn nicht mal set DEVICENAME autocreate

[Weisswurstverkäufer]

Hallo,

ich hätte einen Vorschlag bezüglich der SET-Befehle. Und zwar fände ich es gut, wenn man nicht direkt "set nukidevice {unlock,lock,...,statusRequest}, sondern die "lockActions" zweistufig machen würde. Also "set nukidevice lockAction lock".

Hintergrund: wenn man manuell über FHEMWEB einen statusRequest senden will hat man so ein gewisses Risiko sich leicht zu verklicken und die Tür versehentlich zu öffnen. Möglicherweise kommen ja auch noch andere API Aufrufe die keine lockAction sind dazu, dann wäre eine klare Trennung sowieso noch sinnvoller.

Meinungen dazu?

Gruß

[CoolTux]

Hallo,

ich hätte einen Vorschlag bezüglich der SET-Befehle. Und zwar fände ich es gut, wenn man nicht direkt "set nukidevice {unlock,lock,...,statusRequest}, sondern die "lockActions" zweistufig machen würde. Also "set nukidevice lockAction lock".

Hintergrund: wenn man manuell über FHEMWEB einen statusRequest senden will hat man so ein gewisses Risiko sich leicht zu verklicken und die Tür versehentlich zu öffnen. Möglicherweise kommen ja auch noch andere API Aufrufe die keine lockAction sind dazu, dann wäre eine klare Trennung sowieso noch sinnvoller.

Meinungen dazu?

Gruß

Gibt es Seitens der Anderen Meinungen dazu? Pro oder Contro Argumente?

[Andy89]

Gibt es Seitens der Anderen Meinungen dazu? Pro oder Contro Argumente?

ich bin auch eher für pro, damit man es nicht ausversehen tätigt. Wenn ich bei mir unlatch mache, geht die Tür auch automatisch 1-2cm auf, sodass ein Verriegeln nicht möglich ist, bzw es sinnfrei ist.

Aber auf der andere Seite mache ich über Fhemweb fast gar nichs mehr

[Morpheus_1977]

ich bin auch eher für pro, damit man es nicht ausversehen tätigt. Wenn ich bei mir unlatch mache, geht die Tür auch automatisch 1-2cm auf, sodass ein Verriegeln nicht möglich ist, bzw es sinnfrei ist.

Aber auf der andere Seite mache ich über Fhemweb fast gar nichs mehr

Darf ich draus schließen das du Nuki über Siri nutzt? Falls ja, wie sieht den dein Mapping aus? Bei mir funktioniert eben genau das leider nicht....
Gruß
Morpheus


Gesendet von iPhone mit Tapatalk

[Andy89]

Darf ich draus schließen das du Nuki über Siri nutzt? Falls ja, wie sieht den dein Mapping aus? Bei mir funktioniert eben genau das leider nicht....
Gruß
Morpheus


Gesendet von iPhone mit Tapatalk

nicht direkt. Ich hab zwar ein Mapping irgendwo her, aber ich nutz das eigentlich auch nicht. Aber Homekit beschwert sich immer wenn die Tür nicht abgeschlossen ist oder wenn sie geöffnet wird.

Code Auswählen Erweitern

LockCurrentState=lockState,values=/^lock/:SECURED;/^unlock/:UNSECURED LockTargetState=state,values=/^lock/:SECURED;/^unlock/:UNSECURED,cmds=SECURED:lock;UNSECURED:unlatch

Aber ich nutze entweder die Nuki App oder zu Hause FTUI,was direkt neben der Eingangstür hängt

[muehlberger]

Hallo zusammen,

ich nutze NUKI & HomeKit mittlerweile auch ganz gerne, allerdings ohne meine SIRI.

Mein Mapping sieht so aus:

Code Auswählen Erweitern

LockCurrentState=lockState,values=locked:1;unlocked:0;lock:1;unlock:0 LockTargetState=lockState,values=locked:1;unlocked:0,cmds=1:lock;0:unlock,cmd=

Das führt mich schon zur ersten Frage - der LockState scheint manchmal mit Lock, manchmal mit Locked ausgegeben werden. Ist das so Absicht?

Code Auswählen Erweitern

state
lock
2017-02-12 20:26:20
Nach einem SetStatusRequest jedoch

Code Auswählen Erweitern

state
locked
2017-02-12 20:26:49

Und wenn ich das NUKI direkt an der Tür per Druck auf den Knopf schalte, dann aktualisiert sich der State in FHEM und somit auch in HomeKit nicht. Auch hier ist ein StatusRequest nötig.

Ich nutze übrigens keine WebHooks.

Der Vollständigkeit halber:

Code Auswählen Erweitern

Internals:
   CFGFN
   DEF        65459745 IODev=NUKI
   IODev      NUKI
   NAME       NUKIDevice65459745
   NR         263
   NUKIID     65459745
   STATE      locked
   TYPE       NUKIDevice
   VERSION    0.6.0
   WEBHOOK_REGISTER unregistered
   Readings:
     2017-02-12 20:26:49   battery         ok
     2017-02-12 20:26:49   batteryCritical false
     2017-02-12 20:26:49   lockState       locked
     2017-02-12 20:28:53   name            Nuki_03E6D621
     2017-02-12 20:28:53   paired          true
     2017-02-12 20:28:53   rssi            -74
     2017-02-12 20:26:49   state           locked
     2017-02-12 20:26:49   success         true
   Fhem:
     infix      NUKIDevice
   Helper:
     fromAutocreate 1
Attributes:
   IODev      NUKI
   alias      Eingang
   genericDeviceType lock
   homebridgeMapping LockCurrentState=lockState,values=locked:1;unlocked:0;lock:1;unlock:0 LockTargetState=lockState,values=locked:1;unlocked:0,cmds=1:lock;0:unlock,cmd=
   room       Homekit,NUKI

und

Code Auswählen Erweitern

Internals:
   BRIDGEAPI  1.5
   CFGFN
   DEF        192.168.0.168 xxxxxx
   HOST       192.168.0.168
   NAME       NUKI
   NR         258
   PORT       8080
   STATE      connected
   TOKEN      xxxxxx
   TYPE       NUKIBridge
   VERSION    0.6.0
   Readings:
     2017-02-12 20:19:01   0_name          Eingang
     2017-02-12 20:19:01   0_nukiId        65459745
     2017-02-12 20:29:54   bridgeType      Hardware
     2017-02-12 20:29:54   currentTime     2017-02-12T19:29:56+00:00
     2017-02-12 20:29:54   firmwareVersion 1.4.20
     2017-02-12 20:29:54   hardwareId      82649465
     2017-02-12 20:29:54   serverConnected true
     2017-02-12 20:29:54   serverId        263279036
     2017-02-12 20:19:01   smartlockCount  1
     2017-02-12 20:29:54   state           connected
     2017-02-12 20:29:54   uptime          1726181
     2017-02-12 20:29:54   wifiFirmwareVersion 1.0.1
   Helper:
     aliveCount 0
Attributes:
   room       NUKI

ca. alle 30 Sekunden findet sich das hier im Eventlog von FHEM:

Code Auswählen Erweitern

2017-02-12 20:33:46 NUKIBridge NUKI connected
2017-02-12 20:33:46 NUKIBridge NUKI firmwareVersion: 1.4.20
2017-02-12 20:33:46 NUKIBridge NUKI wifiFirmwareVersion: 1.0.1
2017-02-12 20:33:46 NUKIBridge NUKI bridgeType: Hardware
2017-02-12 20:33:46 NUKIBridge NUKI hardwareId: 82649465
2017-02-12 20:33:46 NUKIBridge NUKI serverId: 263279036
2017-02-12 20:33:46 NUKIBridge NUKI uptime: 1726413
2017-02-12 20:33:46 NUKIBridge NUKI currentTime: 2017-02-12T19:33:48+00:00
2017-02-12 20:33:46 NUKIBridge NUKI serverConnected: true
2017-02-12 20:33:46 NUKIDevice NUKIDevice65459745 name: Nuki_03E6D621
2017-02-12 20:33:46 NUKIDevice NUKIDevice65459745 rssi: -76
2017-02-12 20:33:46 NUKIDevice NUKIDevice65459745 paired: true

bei einem manuellen StatusRequest das hier:

Code Auswählen Erweitern

2017-02-12 20:33:15 NUKIDevice NUKIDevice65459745 statusRequest
2017-02-12 20:33:16 NUKIDevice NUKIDevice65459745 batteryCritical: false
2017-02-12 20:33:16 NUKIDevice NUKIDevice65459745 lockState: unlocked
2017-02-12 20:33:16 NUKIDevice NUKIDevice65459745 unlocked
2017-02-12 20:33:16 NUKIDevice NUKIDevice65459745 battery: ok
2017-02-12 20:33:16 NUKIDevice NUKIDevice65459745 success: true

Soweit ich mich erinnere, hat beides (lock/locked und Status-Aktualisierung) schon mal geklappt. Hatte die Bridge und das Lock auch schon in FHEM gelöscht und wieder neu eingetragen - leider ohne Erfolg.

Hat jemand eine Idee oder Lösung? Wäre toll!

fg, muehlberger

[CoolTux]

Hallo zusammen,

ich nutze NUKI & HomeKit mittlerweile auch ganz gerne, allerdings ohne meine SIRI.

Das führt mich schon zur ersten Frage - der LockState scheint manchmal mit Lock, manchmal mit Locked ausgegeben werden. Ist das so Absicht?

Soweit ich mich erinnere, hat beides (lock/locked und Status-Aktualisierung) schon mal geklappt. Hatte die Bridge und das Lock auch schon in FHEM gelöscht und wieder neu eingetragen - leider ohne Erfolg.

Hat jemand eine Idee oder Lösung? Wäre toll!

fg, muehlberger

Wenn über FHEM ein Befehl abgesetzt wird, so zum Beispiel lock, dann bekommt man als Antwort lediglich ein success=true/false. Also schreibe ich den Befehl in einen helper und beim verarbeiten des Response wird geschaut ob ein helper da ist und wie der success aus sieht. Ist er true dann wurde der lock befehl von der Bridge empfangen. Es stellt aber noch nicht sicher ob das Schloß auch wirklich geschlossen hat, das macht erst der Callback von der Bridge und der gibt eine eindeutige Antwort "locked".
Sehe das lock als Bestättigung das die Bridge empfangen hat und das locked als Bestättigung das das Schloß wirklich verschlossen hat.
Da wir bei den ersten Versionen kein Callback hatten, konnte man nur Auswerten ob die Bride empfangen hat, wir mussten dann hoffen das das Schloß auch wirklich geschlossen hat.



Grüße

[muehlberger]

Ok - Danke für die Erklärung! Ist ja eh nicht tragisch, hatte mich nur gewundert .

Hast du eventuell auch noch einen tip für die status Aktualisierung?


Gesendet von iPhone mit Tapatalk

[CoolTux]

Ok - Danke für die Erklärung! Ist ja eh nicht tragisch, hatte mich nur gewundert .

Hast du eventuell auch noch einen tip für die status Aktualisierung?


Gesendet von iPhone mit Tapatalk

Nur mit Callback/Webhook

[math78]

Hallo,

kann man denn mit dem Modul auch auf WEB oder WEBHOOK mittels https zugreifen? Bei mir funktioniert Callback nur bei http. Falls nicht, könnte man das noch ergänzen?

Danke im Voraus.

Grüße

Matthias

[CoolTux]

Https geht wohl nicht. Das liegt aber nicht am Modul sondern an der API

[Sascha_F]

Hi zusammen,

nur mal eine kurze Rückmeldung meinerseits. Läuft bei mir alles einwandfrei. Wer mag, darf das gern als "Langzeittest" werten 

Viele Grüße