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

Begonnen von CoolTux, 18 Juli 2016, 23:50:11

Vorheriges Thema - Nächstes Thema
Drucken
Nach unten Seiten 1 ... 88 89 90 91 92 ... 120
Benutzer-Aktionen

ulli

#1335
13 November 2019, 18:03:20
Hallo, ich habe das Problem dass ich das Nuki Lock anhand von dem lightscene Modul, welches den Anwesenheitsstatus ermöglicht, steuern möchte.
Das Schalten über die Szenen funktioniert, nur habe ich das Problem das die Szene das Schloss z.b. auf sperrt obwohl es schon den unlocked Status hat.
Grund ist der dass der set Befehl Unlock nicht dem Status unlocked entspricht. Hat das Problem schon einer gelöst?

eddy242

#1336
18 November 2019, 11:41:24
Hallo zusammen,

Bei mir bekomme ich den Webhook nicht zum Laufen. Ich habe eine FHEM WEB Instanz ohne TLS angelegt und per allowed lediglich auf die beiden Nuki Devices Bridge und Smartlock freigegeben (get, set). Über einen Browser kann ich auf dieses FHEMWEB (Name WEBNUKI) zugreifen. Was mich etwas stutzig macht ist die in den INTERNALS ,,errechnete" URL, die auf das NUKIDevice-476030020 zeigt. Mein device heisst nuki_haustuer und selbst im Zustand nach Autocreate wäre der Name NUKIDevice476030020 (also ohne den Strich) gewesen, also kein Match zur URL. Umbenennen in die Version mit Strich geht nicht Wegen fhem Namenskonvention.

Was kann/soll ich noch posten um das Debugging zu erleichtern? Danke für Eure Hilfe.



Code Auswählen


  CFGFN     
   DEF        476030020 IODev=nuki_bridge
   FUUID      5dd1701e-f33f-0759-c4b2-1643840f8bf88235
   IODev      nuki_bridge
   NAME       nuki_haustuer
   NR         1757
   NUKIID     476030020
   STATE      unlocked
   TYPE       NUKIDevice
   VERSION    0.6.4
   WEBHOOK_COUNTER 6
   WEBHOOK_LAST 2019-11-18 05:39:37
   WEBHOOK_PORT 9081
   WEBHOOK_REGISTER sent
   WEBHOOK_URI /WEBNUKI/NUKIDevice
   WEBHOOK_URL http://fhem.ah.home:9081/WEBNUKI/NUKIDevice-476030020
   Helper:
     DBLOG:
       battery:
         logdb:
           TIME       1574051977.21216
           VALUE      ok
       batteryCritical:
         logdb:
           TIME       1574051977.21216
           VALUE      0
       batteryState:
         logdb:
           TIME       1574051977.21216
           VALUE      ok
       lockState:
         logdb:
           TIME       1574051977.21216
           VALUE      unlocked
       name:
         logdb:
           TIME       1574073036.14708
           VALUE      Nuki_1C5FA444
       paired:
         logdb:
           TIME       1574073036.14708
           VALUE      1
       rssi:
         logdb:
           TIME       1574073036.14708
           VALUE      -54
       state:
         logdb:
           TIME       1574051977.21216
           VALUE      unlocked
       success:
         logdb:
           TIME       1574007686.21882
           VALUE      1
   READINGS:
     2019-11-18 05:39:37   battery         ok
     2019-11-18 05:39:37   batteryCritical 0
     2019-11-18 05:39:37   batteryState    ok
     2019-11-18 05:39:37   lockState       unlocked
     2019-11-18 11:30:36   name            Nuki_1C5FA444
     2019-11-18 11:30:36   paired          1
     2019-11-18 11:30:36   rssi            -54
     2019-11-18 05:39:37   state           unlocked
     2019-11-17 17:21:26   success         1
   fhem:
     infix      NUKIDevice
   helper:
     fromAutocreate 1
Attributes:
   DbLogExclude .*
   DbLogInclude .*
   IODev      nuki_bridge
   alias      Haustür
   devStateIcon open:fts_door_right_open@red locked:fts_door_right@green unlocked:fts_door_right@yellow
   group      Sicherheit
   icon       nuki_lock
   room       ControlCenter,Erdgeschoss
   webhookFWinstance WEBNUKI
   webhookHttpHostname fhem.ah.home

CoolTux

#1337
18 November 2019, 11:44:53
fhem.ah.home

Kann die Bridge das auflösen? Sprich gibt es einen Nameserver und ist dieser der Bridge bekannt (zum Beispiel über DHCP)?
Versuch mal als ersten Schritt die IP statt des FQDN


Grüße
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

eddy242

#1338
18 November 2019, 12:21:26
Danke für das schnelle Feedback. Hab's gegen die IP ersetzt und per CallbackRemove die alte CB mit FQDN entfernt. Funktioniert immer noch nicht.

Was kann ich posten um Dir bei der Analyse zu helfen? Danke!!!

OdfFhem

#1339
18 November 2019, 12:31:08
@eddy242

Ich habe Deine Angaben mal mit meinen verglichen und das Muster ist identisch - also auch NUKIDevice mit "-".

Was ich noch nicht ganz verstehe: bei Dir wird der WEBHOOK doch erfolgreich genutzt:
Code Auswählen

  WEBHOOK_COUNTER 6
  WEBHOOK_LAST 2019-11-18 05:39:37


Was genau funktioniert denn nicht?

CoolTux

#1340
18 November 2019, 12:34:03
Zitat von: OdfFhem am 18 November 2019, 12:31:08
@eddy242

Ich habe Deine Angaben mal mit meinen verglichen und das Muster ist identisch - also auch NUKIDevice mit "-".

Was ich noch nicht ganz verstehe: bei Dir wird der WEBHOOK doch erfolgreich genutzt:
Code Auswählen

  WEBHOOK_COUNTER 6
  WEBHOOK_LAST 2019-11-18 05:39:37



Hast Recht. Danke Dir fürs genau schauen. In der Tat wird der Webhook laut Counter und Timestamp sowie laut reading state verwendet.
Was genau funktioniert denn nicht?
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

eddy242

#1341
18 November 2019, 12:41:52
Nun meine Errwatungshaltung war, dass das FHEM Smartlock-Device einen Statusupdate bekommt (reading lockState), egal auf welche Weise das Schloss betätigt wurde (HomeKit, App, Schlüssel, FHEM). Das passiert jedoch nicht, auch nach einer längeren Wartezeit bleibt der Zustand unverändert. Das Absetzen eines getStatusRequests hilft, dann wird der aktuelle Status gesetzt.

CoolTux

#1342
18 November 2019, 12:47:19
Zitat von: eddy242 am 18 November 2019, 12:41:52
Nun meine Errwatungshaltung war, dass das FHEM Smartlock-Device einen Statusupdate bekommt (reading lockState), egal auf welche Weise das Schloss betätigt wurde (HomeKit, App, Schlüssel, FHEM). Das passiert jedoch nicht, auch nach einer längeren Wartezeit bleibt der Zustand unverändert. Das Absetzen eines getStatusRequests hilft, dann wird der aktuelle Status gesetzt.

Stell bitte einmal beim Device den verbose auf 4 und dann schalte am Schloß selbst oder über die App. Warte so um die 10s und dann schauen wir uns das Log mal an.
Poste bitte vor der ganzen Aktion einmal ein list vom Device und nach der Aktion + 10s ein list.
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

OdfFhem

#1343
18 November 2019, 12:58:43
@eddy242

Das von Dir geschilderte Verhalten ist wohl sehr verbreitet, da die Nuki-Hardware schnell "überlastet" ist.
Beispiel: Ein unlock bei verschlossener Tür und unmittelbar danach ein lock (im Normalfall von der anderen Türseite) führt dazu, dass der FHEM-Status beim unlocked bleibt; das (in zu kurzem Abstand auftretende) locked wurde quasi "verschluckt" - also gar nicht oder zumindest nicht erfolgreich versendet.

Im Zusammenhang mit NUKI treten auch gerne folgende "Warnungen" auf:
Code Auswählen

2019.11.11 02:53:07 3: NUKIBridge (<FHEM-NAME>) - invalid json detected: HTTP 503 Unavailable

2019.11.11 08:44:07 3: NUKIDevice (<FHEM-NAME>) - invalid json detected: HTTP 503 Unavailable


Welche Firmware-Versionen bei Bridge bzw. Lock hast Du denn?

eddy242

#1344
18 November 2019, 14:33:20
List vorher:
Code Auswählen

Internals:
   CFGFN     
   DEF        476030020 IODev=nuki_bridge
   FUUID      5dd1701e-f33f-0759-c4b2-1643840f8bf88235
   IODev      nuki_bridge
   NAME       nuki_haustuer
   NR         1757
   NUKIID     476030020
   STATE      unlocked
   TYPE       NUKIDevice
   VERSION    0.6.4
   WEBHOOK_COUNTER 6
   WEBHOOK_LAST 2019-11-18 14:02:18
   WEBHOOK_PORT 9081
   WEBHOOK_REGISTER sent
   WEBHOOK_URI /WEBNUKI/NUKIDevice
   WEBHOOK_URL http://192.168.178.20:9081/WEBNUKI/NUKIDevice-476030020
   Helper:
     DBLOG:
       battery:
         logdb:
           TIME       1574082138.61199
           VALUE      ok
       batteryCritical:
         logdb:
           TIME       1574082138.61199
           VALUE      0
       batteryState:
         logdb:
           TIME       1574082138.61199
           VALUE      ok
       lockState:
         logdb:
           TIME       1574082138.61199
           VALUE      unlocked
       name:
         logdb:
           TIME       1574082328.52834
           VALUE      Nuki_1C5FA444
       paired:
         logdb:
           TIME       1574082328.52834
           VALUE      1
       rssi:
         logdb:
           TIME       1574082328.52834
           VALUE      -51
       state:
         logdb:
           TIME       1574082138.61199
           VALUE      unlocked
       success:
         logdb:
           TIME       1574075800.51071
           VALUE      1
   READINGS:
     2019-11-18 14:02:18   battery         ok
     2019-11-18 14:02:18   batteryCritical 0
     2019-11-18 14:02:18   batteryState    ok
     2019-11-18 14:02:18   lockState       unlocked
     2019-11-18 14:05:28   name            Nuki_1C5FA444
     2019-11-18 14:05:28   paired          1
     2019-11-18 14:05:28   rssi            -51
     2019-11-18 14:02:18   state           unlocked
     2019-11-18 12:16:40   success         1
   fhem:
     infix      NUKIDevice
   helper:
     fromAutocreate 1
Attributes:
   DbLogExclude .*
   DbLogInclude .*
   IODev      nuki_bridge
   alias      Haustür
   devStateIcon open:fts_door_right_open@red locked:fts_door_right@green unlocked:fts_door_right@yellow
   group      Sicherheit
   icon       nuki_lock
   room       ControlCenter,Erdgeschoss
   webhookFWinstance WEBNUKI
   webhookHttpHostname 192.168.178.20


Jetzt auf Verbose 4
Gerät ist in der Realität unlocked, in FHEM auch unlocked
kurz vor 14:09 via NUKI app locked
Code Auswählen
2019.11.18 14:09:08 4: NUKIDevice (nuki_haustuer) - Received webhook for matching NukiId at device nuki_haustuer

Gerät ist in der Realität locked, in FHEM auch locked (!!!)

kurz vor 14:10:40 via NUKI app unlocked
Code Auswählen
2019.11.18 14:10:49 4: NUKIDevice (nuki_haustuer) - Received webhook for matching NukiId at device nuki_haustuer
Gerät ist in der Realität unlocked, in FHEM auch unlocked.

jetzt das ganze Spiel nochmal

kurz vor 14:24 via NUKI app locked
Code Auswählen
2019.11.18 14:24:43 4: NUKIDevice (nuki_haustuer) - Received webhook for matching NukiId at device nuki_haustuer
Gerät ist in der Realität locked, in FHEM auch locked.

kurz 14:26 via NUKI app unlocked
Bis 14:29 gewartet, es kommt KEIN Eintrag im Logfile zu einem Received Webhook
Gerät ist in der Realität unlocked, in FHEM aber locked.


Vielleicht ist es wie @OdfFhem sagt und ich habe es vorher zu schnell hintereinander gemacht? Andererseits waren 2min dazwischen. Homekit hat die Notify brav auf das iPhone gesendet.

List nachher:

Code Auswählen

Internals:
   CFGFN     
   DEF        476030020 IODev=nuki_bridge
   FUUID      5dd1701e-f33f-0759-c4b2-1643840f8bf88235
   IODev      nuki_bridge
   NAME       nuki_haustuer
   NR         1757
   NUKIID     476030020
   STATE      unlocked
   TYPE       NUKIDevice
   VERSION    0.6.4
   WEBHOOK_COUNTER 8
   WEBHOOK_LAST 2019-11-18 14:10:49
   WEBHOOK_PORT 9081
   WEBHOOK_REGISTER sent
   WEBHOOK_URI /WEBNUKI/NUKIDevice
   WEBHOOK_URL http://192.168.178.20:9081/WEBNUKI/NUKIDevice-476030020
   Helper:
     DBLOG:
       battery:
         logdb:
           TIME       1574082649.56157
           VALUE      ok
       batteryCritical:
         logdb:
           TIME       1574082649.56157
           VALUE      0
       batteryState:
         logdb:
           TIME       1574082649.56157
           VALUE      ok
       lockState:
         logdb:
           TIME       1574082649.56157
           VALUE      unlocked
       name:
         logdb:
           TIME       1574082718.91023
           VALUE      Nuki_1C5FA444
       paired:
         logdb:
           TIME       1574082718.91023
           VALUE      1
       rssi:
         logdb:
           TIME       1574082718.91023
           VALUE      -51
       state:
         logdb:
           TIME       1574082649.56157
           VALUE      unlocked
       success:
         logdb:
           TIME       1574075800.51071
           VALUE      1
   READINGS:
     2019-11-18 14:10:49   battery         ok
     2019-11-18 14:10:49   batteryCritical 0
     2019-11-18 14:10:49   batteryState    ok
     2019-11-18 14:10:49   lockState       unlocked
     2019-11-18 14:11:58   name            Nuki_1C5FA444
     2019-11-18 14:11:58   paired          1
     2019-11-18 14:11:58   rssi            -51
     2019-11-18 14:10:49   state           unlocked
     2019-11-18 12:16:40   success         1
   fhem:
     infix      NUKIDevice
   helper:
     fromAutocreate 1
Attributes:
   DbLogExclude .*
   DbLogInclude .*
   IODev      nuki_bridge
   alias      Haustür
   devStateIcon open:fts_door_right_open@red locked:fts_door_right@green unlocked:fts_door_right@yellow
   group      Sicherheit
   icon       nuki_lock
   room       ControlCenter,Erdgeschoss
   verbose    4
   webhookFWinstance WEBNUKI
   webhookHttpHostname 192.168.178.20

CoolTux

#1345
18 November 2019, 14:36:23
Scheint erstmal generell Funktion zu haben. Wie stark ist Dein FHEM belastet? Hast Du viele Events oder so?
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

eddy242

#1346
18 November 2019, 15:01:08
Ist eine größere FHEM Installation wo schon einiges los ist, die meisten Devices, die viele (nutzlose) Events generieren, sind mit event-min-interval etc runtergedämpft. Fhem läuft containerized auf leistungstarker HW, durchschnittlich ist die CPU bei >20 Containern eher bei 20%, im Peak mal 60%, aber fernab von Vollauslastung. Das Heimnetz ist eigentlich auch ganz gut geölt und zeigt keine Probleme. WLAN Access points sind von Unifi, die NUKI Bridge hat guten Empfang. Sonst läuft FHEM auch rund, keine Unregelmäßigkeiten. Ich lege jetzt mal ein DOIF an das alle 20min pollt aber das ist ja nicht Sinn der Sache.

Was mir noch auffiel, kann es an der Bridge liegen. Der letzte von mir bewusst ausgelöste Neustart war gesten Nachmittag, jetzt ist die Uptime 1721, d.h. vorhin beim experimentieren muss sich das Ding rebootet haben, obwohl ich nichts dergleichen veranlasst habe. Kann das die Spur sein?
Code Auswählen
get nuki_bridge logFile macht gar nichts (sollte da ein Popup kommen?)

Code Auswählen

Internals:
   BRIDGEAPI  1.6
   DEF        nukibridge.ah.home XXXXX
   FUUID      5dd03016-f33f-0759-18dd-a93f3a06b7460d18
   HOST       nukibridge.ah.home
   NAME       nuki_bridge
   NR         468
   PORT       8080
   STATE      connected
   TOKEN      EOUpkh
   TYPE       NUKIBridge
   VERSION    0.6.4
   READINGS:
     2019-11-17 17:06:54   0_name          Haust�r
     2019-11-17 17:06:54   0_nukiId        476030020
     2019-11-18 14:57:08   bridgeType      Hardware
     2019-11-18 14:57:08   currentTime     2019-11-18T13:57:13+00:00
     2019-11-18 14:57:08   firmwareVersion 2.2.13
     2019-11-18 14:57:08   hardwareId      444324306
     2019-11-17 17:36:25   lastError       read from http://nukibridge.ah.home:8080 timed out
     2019-11-18 14:57:08   serverConnected 1
     2019-11-18 14:57:08   serverId        801476865
     2019-11-17 17:06:54   smartlockCount  1
     2019-11-18 14:57:08   state           connected
     2019-11-18 14:57:08   uptime          1721
     2019-11-18 14:57:08   wifiFirmwareVersion 2.0.0
   helper:
     aliveCount 0
Attributes:
   DbLogExclude .*
   devStateIcon connected:nuki_bridge@green .*:nuki_bridge@red
   group      ServerConnections,Sicherheit
   icon       nuki_bridge
   room       Server

CoolTux

#1347
18 November 2019, 15:15:05
Zitat von: eddy242 am 18 November 2019, 15:01:08
Ist eine größere FHEM Installation wo schon einiges los ist, die meisten Devices, die viele (nutzlose) Events generieren, sind mit event-min-interval etc runtergedämpft. Fhem läuft containerized auf leistungstarker HW, durchschnittlich ist die CPU bei >20 Containern eher bei 20%, im Peak mal 60%, aber fernab von Vollauslastung. Das Heimnetz ist eigentlich auch ganz gut geölt und zeigt keine Probleme. WLAN Access points sind von Unifi, die NUKI Bridge hat guten Empfang. Sonst läuft FHEM auch rund, keine Unregelmäßigkeiten. Ich lege jetzt mal ein DOIF an das alle 20min pollt aber das ist ja nicht Sinn der Sache.

Was mir noch auffiel, kann es an der Bridge liegen. Der letzte von mir bewusst ausgelöste Neustart war gesten Nachmittag, jetzt ist die Uptime 1721, d.h. vorhin beim experimentieren muss sich das Ding rebootet haben, obwohl ich nichts dergleichen veranlasst habe. Kann das die Spur sein?
Code Auswählen
get nuki_bridge logFile macht gar nichts (sollte da ein Popup kommen?)

Code Auswählen

Internals:
   BRIDGEAPI  1.6
   DEF        nukibridge.ah.home XXXXX
   FUUID      5dd03016-f33f-0759-18dd-a93f3a06b7460d18
   HOST       nukibridge.ah.home
   NAME       nuki_bridge
   NR         468
   PORT       8080
   STATE      connected
   TOKEN      EOUpkh
   TYPE       NUKIBridge
   VERSION    0.6.4
   READINGS:
     2019-11-17 17:06:54   0_name          Haust�r
     2019-11-17 17:06:54   0_nukiId        476030020
     2019-11-18 14:57:08   bridgeType      Hardware
     2019-11-18 14:57:08   currentTime     2019-11-18T13:57:13+00:00
     2019-11-18 14:57:08   firmwareVersion 2.2.13
     2019-11-18 14:57:08   hardwareId      444324306
     2019-11-17 17:36:25   lastError       read from http://nukibridge.ah.home:8080 timed out
     2019-11-18 14:57:08   serverConnected 1
     2019-11-18 14:57:08   serverId        801476865
     2019-11-17 17:06:54   smartlockCount  1
     2019-11-18 14:57:08   state           connected
     2019-11-18 14:57:08   uptime          1721
     2019-11-18 14:57:08   wifiFirmwareVersion 2.0.0
   helper:
     aliveCount 0
Attributes:
   DbLogExclude .*
   devStateIcon connected:nuki_bridge@green .*:nuki_bridge@red
   group      ServerConnections,Sicherheit
   icon       nuki_bridge
   room       Server


Das Logfile wurde aus der API geschmissen. Muss ich noch ausbessern.
Container meinst Du bestimmt Docker oder? Da kenne ich mich nicht so aus aber in meinem LX Container läuft es ohne Probleme.

Das Neustarten der Bridge wäre ein Ansatz. Eigentlich sollte sie es nicht einfach so machen.
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

eddy242

#1348
19 November 2019, 21:11:42
Hallo zusammen,

ich habe die Uptime der Bridge mal mitgeloggt, abgesehen von den Experimenten gestern habe ich nichts gemacht. Das kann doch nicht normal sein dass das Ding alle paar Stunden, teils schneller, rebootet? Kann einer von Euch das bitte mal bei sich prüfen?

eddy242

#1349
22 November 2019, 12:05:21
Hallo CoolTux,

kannst Du da bitte mal einen Blick drauf werfen. Ich habe die Uptime der Bridge nun seit mehreren Tagen mitgeloggt und konstant nach ca 1h macht sie einen Reboot, außer nachts, wenn das SmartLock im Nachtmodus ist. Gestern habe ich den FHEM Webhook entfernt und siehe da die Reboots hören auf. Kannst Du Dir vorstellen, ob es da einen Zusammenhang mit der Implementierung des Hooks gibt? Danke!
Drucken
Nach oben Seiten 1 ... 88 89 90 91 92 ... 120
Benutzer-Aktionen