NUKI Devices (SmartLock) aktualisieren den State/state in FHEM nicht mehr autom.

Begonnen von SebastianStorb, 22 November 2020, 21:41:22

Vorheriges Thema - Nächstes Thema

SebastianStorb

Kann jemand sagen, warum der STATE bzw. state sich nicht mehr automatisch aktualisiert? Ist in meiner Konfiguration etwas falsch (ich habe bereits mehrfach ohne Erfolg die NukiBridge in FHEM neu eingerichtet und die Bridge mehrfach neu gestartet)? Ich habe den Eindruck, dass es nach dem letzten Update der NukiBridge nicht mehr funktioniert. Oder seitdem ich eine 2. Bridge (NBridge2) über ein VPN Subnetz angebunden habe. Wenn ich mir die Daten hole (über status request) wird der korrekte Zustand aktualisiert und dann angezeigt.

In der App auf dem Handy wird die Version 2.9.10 als FW in den Devices angegeben und in der NukiBridge die 2.8.0. Sowohl API Schnellverbindung als auch HTTP API sind aktiviert.

Error code: ..timed out... (s. unten)

Internals:
   BRIDGEAPI  1.9
   DEF        192.168.1.55 #######
   FUUID      #########################################
   FVERSION   73_NUKIBridge.pm:v1.9.16-s20994/2020-01-16
   HOST       192.168.1.55
   NAME       NBridge1
   NOTIFYDEV  global,NBridge1
   NR         688
   NTFY_ORDER 50-NBridge1
   PORT       8080
   STATE      connected
   TOKEN      ######
   TYPE       NUKIBridge
   VERSION    v1.9.16
   WEBHOOK_COUNTER 0
   WEBHOOK_PORT 8083
   WEBHOOK_REGISTER sent
   WEBHOOK_URI /fhem/NUKIBridge-192.168.1.55
   WEBHOOK_URL http://192.168.1.100:8083/fhem/NUKIBridge-192.168.1.55
   READINGS:
     2020-11-22 21:03:02   bridgeType      Hardware
     2020-11-22 21:03:02   currentTime     2020-11-22T20:03:02+00:00
     2020-11-22 21:03:02   firmwareVersion 2.8.0
     2020-11-22 21:03:02   hardwareId      #########
     2020-11-22 20:08:32   lastError       read from http://192.168.1.55:8080 timed out
     2020-11-22 21:03:02   serverConnected 1
     2020-11-22 21:03:02   serverId        #########
     2020-11-22 21:03:02   state           connected
     2020-11-22 21:03:02   uptime          7419
     2020-11-22 21:03:02   wifiFirmwareVersion 2.2.0
   fhem:
     infix      NUKIBridge
   helper:
     iowrite    0
     actionQueue:
Attributes:
   room       NUKI
   webhookFWinstance WEB
   webhookHttpHostname 192.168.1.100


bridgeType
Hardware
2020-11-22 21:42:57
currentTime
2020-11-22T20:42:57+00:00
2020-11-22 21:42:57
firmwareVersion
2.8.0
2020-11-22 21:42:57
hardwareId
########
2020-11-22 21:42:57
lastError
read from http://192.168.1.55:8080 timed out
2020-11-22 21:39:26
serverConnected
1
2020-11-22 21:42:57
serverId
############
2020-11-22 21:42:57
state
connected
2020-11-22 21:42:57
uptime
217
2020-11-22 21:42:57
wifiFirmwareVersion
2.2.0
2020-11-22 21:42:57


Internals:
   BRIDGEAPI  1.9
   DEF        ########## 0
   DEVICETYPE 0
   FUUID      #######################################
   FVERSION   74_NUKIDevice.pm:v1.9.12-s21020/2020-01-20
   IODev      NBridge1
   LASTInputDev NBridge1
   MSGCNT     33
   NAME       Garten
   NBridge1_MSGCNT 33
   NBridge1_TIME 2020-11-22 21:05:03
   NOTIFYDEV  global,autocreate,Garten
   NR         691
   NTFY_ORDER 50-Garten
   NUKIID     ###########
   STATE      locked
   TYPE       NUKIDevice
   VERSION    v1.9.12
   READINGS:
     2020-11-22 20:49:03   batteryChargeState 74
     2020-11-22 20:49:03   batteryCharging 0
     2020-11-22 20:49:03   batteryState    ok
     2020-11-22 21:05:03   deviceType      smartlock
     2020-11-22 20:49:03   doorsensorState 2
     2020-11-22 20:49:03   doorsensorStateName door closed
     2020-11-22 20:49:03   mode            door mode
     2020-11-22 21:05:03   name            Nuki_#########
     2020-11-22 21:05:03   nukiId          #########
     2020-11-22 21:05:03   paired          true
     2020-11-22 21:05:03   rssi            -62
     2020-11-22 20:49:03   state           locked
     2020-11-22 20:49:03   stateName       locked
     2020-11-22 20:49:03   success         1
   helper:
Attributes:
   IODev      NBridge1
   model      smartlock
   room       NUKI



Internals:
   BRIDGEAPI  1.9
   DEF        ######### 0
   DEVICETYPE 0
   FUUID      ##########################################
   FVERSION   74_NUKIDevice.pm:v1.9.12-s21020/2020-01-20
   IODev      NBridge1
   LASTInputDev NBridge1
   MSGCNT     34
   NAME       Keller
   NBridge1_MSGCNT 34
   NBridge1_TIME 2020-11-22 21:06:03
   NOTIFYDEV  global,autocreate,Keller
   NR         689
   NTFY_ORDER 50-Keller
   NUKIID     ##########
   STATE      locked
   TYPE       NUKIDevice
   VERSION    v1.9.12
   READINGS:
     2020-11-22 19:07:19   batteryChargeState 44
     2020-11-22 19:07:19   batteryCharging 0
     2020-11-22 19:07:19   batteryState    ok
     2020-11-22 21:06:03   deviceType      smartlock
     2020-11-22 19:07:19   doorsensorState 2
     2020-11-22 19:07:19   doorsensorStateName door closed
     2020-11-22 19:07:19   mode            door mode
     2020-11-22 21:06:03   name            Nuki_#########
     2020-11-22 21:06:03   nukiId          #########
     2020-11-22 21:06:03   paired          true
     2020-11-22 21:06:03   rssi            -78
     2020-11-22 19:07:19   state           locked
     2020-11-22 19:07:19   stateName       locked
     2020-11-22 19:07:19   success         1
   helper:
Attributes:
   IODev      NBridge1
   model      smartlock
   room       NUKI


Verbose5 in der Bridge ergibt:
2020-11-22 21:54:28 NUKIBridge NBridge1 connected
2020-11-22 21:54:28 NUKIBridge NBridge1 firmwareVersion: 2.8.0
2020-11-22 21:54:28 NUKIBridge NBridge1 wifiFirmwareVersion: 2.2.0
2020-11-22 21:54:28 NUKIBridge NBridge1 bridgeType: Hardware
2020-11-22 21:54:28 NUKIBridge NBridge1 hardwareId: XXXXXXXXXXX
2020-11-22 21:54:28 NUKIBridge NBridge1 serverId: XXXXXXXXXXX
2020-11-22 21:54:28 NUKIBridge NBridge1 uptime: 908
2020-11-22 21:54:28 NUKIBridge NBridge1 currentTime: 2020-11-22T20:54:28+00:00
2020-11-22 21:54:28 NUKIBridge NBridge1 serverConnected: 1
[""] 2020-11-22 21:54:58 NUKIBridge NBridge1 connected
2020-11-22 21:54:58 NUKIBridge NBridge1 firmwareVersion: 2.8.0
2020-11-22 21:54:58 NUKIBridge NBridge1 wifiFirmwareVersion: 2.2.0
2020-11-22 21:54:58 NUKIBridge NBridge1 bridgeType: Hardware
2020-11-22 21:54:58 NUKIBridge NBridge1 hardwareId: XXXXXXXXX
2020-11-22 21:54:58 NUKIBridge NBridge1 serverId: XXXXXXXXX
2020-11-22 21:54:58 NUKIBridge NBridge1 uptime: 938
2020-11-22 21:54:58 NUKIBridge NBridge1 currentTime: 2020-11-22T20:54:58+00:00
2020-11-22 21:54:58 NUKIBridge NBridge1 serverConnected: 1


und im Log steht u.a.:
2020.11.22 21:56:26 4: NUKIBridge (NBridge1) - GetCheckBridgeAlive
2020.11.22 21:56:26 4: NUKIBridge (NBridge1) - created uri: http://192.168.1.55:8080/info?token=#####
2020.11.22 21:56:26 4: NUKIBridge (NBridge1) - Send HTTP POST with URL http://192.168.1.55:8080/info?token=###########
2020.11.22 21:56:26 4: NUKIBridge (NBridge1) - run Write
2020.11.22 21:56:26 4: NUKIBridge (NBridge1) - Call InternalTimer for GetCheckBridgeAlive
2020.11.22 21:56:27 4: NUKIBridge (NBridge1) - Response JSON: {"bridgeType": 1, "ids": {"hardwareId": ########, "serverId": ########}, "versions": {"firmwareVersion": "2.8.0", "wifiFirmwareVersion": "2.2.0"}, "uptime": 1028, "currentTime": "2020-11-22T20:56:28+00:00", "wlanConnected": true, "serverConnected": true, "scanResults": [{"deviceType": 0, "nukiId": ########, "name": "########", "rssi": -76, "paired": true}, {"deviceType": 0, "nukiId": ########, "name": "############", "rssi": -60, "paired": true}]}
2020.11.22 21:56:27 4: NUKIBridge (NBridge1) - Response ERROR:
2020.11.22 21:56:27 4: NUKIBridge (NBridge1) - Response CODE: 200
2020.11.22 21:56:27 5: NUKIBridge (NBridge1) - Bridge ist online
2020.11.22 21:56:27 5: NUKIBridge (NBridge1) - 1 == 1 and 1 > 0
2020.11.22 21:56:27 5: NUKIBridge (NBridge1) - 1 == 1 and 1 > 0

Manos

Ich habe genau das gleiche Problem!

Meine Settings sind identisch, FW Versionen usw identisch (Ausnahme: batteryChargeState  ;D)

ABER: ich habe gemerkt, das Problem liegt beim Status Update (locked / unlocked). Manchmal funktioniert, manchmal nicht wenn ich mit der Hand die Tuer verriegle!
Ich vermute es liegt an der Kalibrierung.
Im Gegenteil, der doorsensorState und doorsensorStateName (door open / door closed) funktionieren zuverlaessig!
Ich habe mein stateFormat etwas ausfuerlicher definitiert, dadurch konnte ich erkennen, dass die Updates kommen.

attr Home_Door stateFormat Status: doorsensorStateName - state <br> Online:paired Battery: batteryChargeState% - batteryState





Ich habe zusaetzlich auf mein NUKI

attr Home_Door event-min-interval 1
attr Home_Door event-on-change-reading state,stateName,batteryState,batteryChargeState,doorsensorState,doorsensorStateName,success



Uebrigens, etwas verwirrt mich bei der wiki ( https://wiki.fhem.de/wiki/NUKI ) was NUKIDevice betrifft. Das Beispiel:

NUKIDevice - Steuert das Nuki Smartlock

Das Nuki Modul verbindet FHEM über die Nuki Bridge mit einem Nuki Smartlock. Es ist dann möglich das Schloss zu ver- und entriegeln. In der Regel werden die Nuki Devices automatisch durch das Bridgemodul angelegt.

Definition
define <name> NUKIDevice <Nuki-Id> <IODev-Device>
Beispiel:

define Haustuer NUKIDevice 1 NBridge1
Diese Anweisung erstellt ein NUKIDevice mit Namen Haustuer, der NukiId 1 sowie dem IODev Device NBridge1. Nach dem Anlegen des Devices wird automatisch der aktuelle Zustand des Smartlocks aus der Bridge gelesen. Damit das NUKIDevice auch Statusänderungen mitbekommt, die beispielsweise aus der nativen NUKI-App oder der manuellen Betätigung des Devices herrühren, ist es notwendig, die Attribute webhookFWinstance und webhookHttpHostname zu setzen.

attr Haustuer webhookFWinstance WEB (Name der FHEMWEB Instanz)
attr Haustuer webhookHttpHostname 192.168.0.1 (IP/FQDN vom FHEM Server)
Zum Überprüfen kann die Funktion

get NUKIBridge callbackList
aufgerufen werden. Es sollte nur ein Callback eingetragen sein, der in dieser Form hinterlegt sein sollte.

0 http://192.168.0.1:8083/fhem/NUKIDevice-123456789


Haustuer ist das NUKIDevice laut diesem Beispiel.
attr Haustuer webhookFWinstance WEB (Name der FHEMWEB Instanz)
attr Haustuer webhookHttpHostname 192.168.0.1 (IP/FQDN vom FHEM Server)


Im Gegenteil, in meiner Version von FHEM, diese zwei Attributen kann ich nur fuer das NUKIBridge definieren:
attr NBridge1 webhookFWinstance WEB
attr NBridge1 webhookHttpHostname 192.168.188.202


HP Microserver GEN8 XEON, Ubuntu 22.04, FHEM, ConBee II, CCU2, CUL433, Tradfri, Luxtronik2, Volkszaehler (und wenig Ahnung...)

OdfFhem

@Manos

- event-min-interval funktioniert generell anders - siehe Wiki ...

- der NUKI-Modulstand ist neuer als der Wiki-Stand - siehe 'Device specific help' auf der FHEM-Detailseite zum Gerät

SebastianStorb

@ Manos
zu
ZitatIm Gegenteil, in meiner Version von FHEM, diese zwei Attributen kann ich nur fuer das NUKIBridge definieren:
attr NBridge1 webhookFWinstance WEB
attr NBridge1 webhookHttpHostname 192.168.188.202

Ja das ist bei mir auch so und korrekt bei Dir

zu
ZitatABER: ich habe gemerkt, das Problem liegt beim Status Update (locked / unlocked). Manchmal funktioniert, manchmal nicht wenn ich mit der Hand die Tuer verriegle!

ja das war bei mir auch so bevor ich in FHEM alles noch mal neu eingerichtet habe UND die Nuki-Bridge neu gestartet habe. (Ich glaube es liegt leider nicht an der Kalibrierung).

Daher habe ich das Problem heute dezidiert bei Nuki gemeldet - denn vor dem FW Update der Nuki Smart Lock und Bridge hatte ja alles problemlos bei mir funktioniert. Ich habe den Verdacht bei der Support Hotline geäußert, dass der State nicht mehr aktiv ins HTTP durchgegeben wird - eben nur korrekt angezeigt in der Nuki App und wenn über das FHEM Device mit set XXX status requeset aktiv abgefragt wird.
Ich werde jetzt mal ein doif schreiben, was mir vorübergehend die Abfrage alle 30 Sekunden macht. Mal sehen wie lange es die Batterie im Nuki Device mitmacht  ;D

SebastianStorb

define doif_Nuki_Keller_Request DOIF ([+60]) (set Keller statusRequest)

([+60]) (set Keller statusRequest)
attr do always


Ist zwar dämlich - funktioniert aber.

Manos

Ich habe festgestellt, mein NUKI status funktioniert.

Ich habe aber eine aeltere Firmware Version (2.8.15, siehe Bild)
NUKI will mir eine neuere Version anbieten (2.9.10) aber ich glaube, ich sollte lieber warten  ;D
Wie du auf die 2.9.12 gekommen bist, ist mir ein Rätzel...


Internals:
   BRIDGEAPI  1.9
   DEF        0
   DEVICETYPE 0
   FUUID     
   FVERSION   74_NUKIDevice.pm:v1.9.12-s21020/2020-01-20
   IODev      NBridge1
   LASTInputDev NBridge1
   MSGCNT     2563
   NAME       Home_Door
   NBridge1_MSGCNT 2563
   NBridge1_TIME 2020-12-03 21:32:26
   NOTIFYDEV  global,autocreate,Home_Door
   NR         63
   NTFY_ORDER 50-Home_Door
   NUKIID     
   STATE      Status: door closed - unlocked
Online:true Battery: 84% - ok
   TYPE       NUKIDevice
   VERSION    v1.9.12
   Helper:
     DBLOG:
       doorsensorState:
         Logdb:
           TIME       1607020642.92151
           VALUE      2
       doorsensorStateName:
         Logdb:
           TIME       1607020642.92151
           VALUE      door closed
       state:
         Logdb:
           TIME       1607027376.20254
           VALUE      unlocked
       stateName:
         Logdb:
           TIME       1607027376.20254
           VALUE      unlocked
   READINGS:
     2020-12-03 21:29:36   batteryChargeState 84
     2020-12-03 21:29:36   batteryCharging 0
     2020-12-03 21:29:36   batteryState    ok
     2020-12-03 21:32:26   deviceType      smartlock
     2020-12-03 21:29:36   doorsensorState 2
     2020-12-03 21:29:36   doorsensorStateName door closed
     2020-11-28 12:27:27   firmwareVersion 2.8.15
     2020-12-03 21:29:36   mode            door mode
     2020-12-03 21:32:26   name            Nuki_
     2020-12-03 21:32:26   nukiId         
     2020-12-03 21:32:26   paired          true
     2020-12-03 21:32:26   rssi            -44
     2020-12-03 21:29:36   state           unlocked
     2020-12-03 21:29:36   stateName       unlocked
     2020-12-03 00:25:02   success         1
   helper:
Attributes:
   DbLogExclude .*
   DbLogInclude state,stateName,batteryState,doorsensorState,doorsensorStateName
   IODev      NBridge1
   alias      Nuki_FrontDoor
   devStateIcon unlock:rc_YELLOW@yellow unlocked:rc_YELLOW@yellow lock:rc_GREEN@green locked:rc_GREEN@green unlatch:hue_room_frontdoor@red \
true:WLAN_Status.1 false:WLAN_Status.0 \
ok:batterie@green low:batterie@red
   event-min-interval 1
   event-on-change-reading state,stateName,batteryState,batteryChargeState,doorsensorState,doorsensorStateName,success
   icon       1_nuki
   model      smartlock
   room       NUKI,Outside_Perimeter
   stateFormat Status: doorsensorStateName - state
Online:paired Battery: batteryChargeState% - batteryState


HP Microserver GEN8 XEON, Ubuntu 22.04, FHEM, ConBee II, CCU2, CUL433, Tradfri, Luxtronik2, Volkszaehler (und wenig Ahnung...)

SebastianStorb

zu
Wie du auf die 2.9.12 gekommen bist, ist mir ein Rätz
Ja das war ein Fehler von mir: 2.9.10 ist die korrekte Version und funktioniert bei mir nicht.
zu
ich sollte lieber warten
Ja das sehe ich genau so wie Du.

übrigens funktioniert das doif nach ein paar Stunden nicht mehr und ich habe jetzt auf ein at umgestellt, was zur Zeit funktioniert.
define at_Nuki_Keller_Request at +*00:01:00 set Keller statusRequest

Interessanter Weise ist der Akkustand von 68% auf 60% gesunken, was aber auch an den gefallenen Außentemperaturen liegen könnte.

Shampooman

Hab das gleiche Problem. Seid ihr beim at geblieben? Oder gibts nen "Update"?

CoolTux

Mach mal bitte einen neuen Thread auf und poste da list von der Bridge und dem Device.
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

SebastianStorb

Das Problem ist mittlerweile in FHEM bei mir gelöst wobei ich nicht ganz genau sagen kann warum (Entweder wurde in NUKI oder in FHEM etwas geändert). Ich hatte festgestellt, dass es Readings gibt, die auch über AT nicht mehr aktualisiert werden - genau diese waren aber wichtig.

Zuerst hatte ich daher alle AT Befehle deaktiviert. Dannach habe ich einfach mal alle NUKI readings in allen Nuki Geräten von Hand gelöscht:

z.B.:
deletereading Nuki_Gartentür .*

Im Ergebnis hat dass Nuki (oder FHEM?) plötzlich anderer Readings erstellt und diese auch selber wieder ohne AT aktualisiert.

Soweit ich mich erinnern kann hatten sich die Readings leicht verändert bzw. sind weggefallen (Vergleiche Readings hier mit oben) Hierdurch konnten diese von meinen DOIF nicht mehr richtig ausgewertet werden und ich musste alle DOIFs anpassen, was recht viel Arbeit war. Jetzt läuft alles recht ordentlich.

IODev
READINGS:
     2022-02-08 09:12:40   IODev           NBridge1
     2022-02-08 21:59:03   batteryCharging false
     2022-02-08 21:59:03   batteryPercent  72
     2022-02-08 21:59:03   batteryState    ok
     2022-02-08 21:59:03   deviceType      smartlock
     2022-02-08 21:59:03   doorsensorState door closed
     2022-02-08 21:59:03   firmwareVersion 2.11.9
     2022-02-08 21:59:03   mode            door mode
     2022-02-08 21:59:03   name            Garten
     2022-02-08 21:59:03   nukiId          XXXXXXXX
     2022-02-08 21:59:03   state           locked
     2022-02-08 21:59:03   stateName       locked
     2022-02-08 09:13:20   success         1