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

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

Vorheriges Thema - Nächstes Thema

fred_feuerstein

Ah. OK.

Dann lass ich die vorerst drin. Solange es keine Probleme verursacht. Bisher läuft es ja.
Gruß, Fred

FHEM auf Raspberry PI 3B+ im 7Zoll TouchDisplay Gehäuse, OS: Bullseye, mit Z-Wave RaZberry-Modul, 868CUL (WMBUS), LaCrosseCUL (Temp) und knapp 300 Devices aller Art

Cobra

#301
Hey CoolTux,

wie ich dir schon geschrieben hab bin ich jetzt auch stolzer Besitzer des SmartLocks und der Bridge, hat auch alles soweit geklappt beim Einrichten (vielen Dank für das tolle Modul  :) )

Habe jetzt jedoch ein kleines Problem. Das SmartLock hat ständig das Reading battery low, obwohl ich schon mehrfach mit neuen Batterien versucht habe. In der Nuki-App selbst finde ich keine Batterieanzeige aber auch keine Warnung dass die Batterien bald leer sind.

Kann es sein dass die ersten Batterien leer waren beim anlegen und er jetzt das Reading nicht mehr aktualisiert?

Hier noch die Infos über Bridge und SmartLock:


List Bridge:
Internals:
   CHANGED
   DEF        192.168.178.56 xxxxxx
   HOST       192.168.178.56
   INTERVAL   60
   NAME       NBridge1
   NR         810
   PORT       8080
   STATE      not connected
   TOKEN      xxxxxx
   TYPE       NUKIBridge
   VERSION    0.2.1
   Readings:
     2016-11-04 20:42:44   0_name          CobraTuer
     2016-11-04 20:42:44   0_nukiId        102844921
     2016-11-04 20:42:44   bridgeAPI       1.0.2
     2016-11-09 13:12:43   lastError       read from http://192.168.178.56:8080 timed out
     2016-11-04 20:42:44   smartlockCount  1
     2016-11-09 13:12:43   state           not connected
Attributes:
   group      Gateway
   room       9.6_System


Info:
{"bridgeType": 1, "ids": {"hardwareId": 95991041, "serverId": 1337010944}, "versions": {"firmwareVersion": "1.3.6", "wifiFirmwareVersion": "1.0.1"}, "uptime": 399653, "currentTime": "2016-11-09T12:16:09+00:00", "serverConnected": true, "scanResults": [{"nukiId": 102844921, "name": "Nuki_062149F9", "rssi": -79, "paired": true}]}

List SmartLock:
Internals:
   CHANGED
   DEF        102844921 IODev=NBridge1
   INTERVAL   20
   IODev      NBridge1
   NAME       NUKIDevice102844921
   NR         811
   NUKIID     102844921
   STATE      unlocked
   TYPE       NUKIDevice
   VERSION    0.2.1
   Readings:
     2016-11-09 13:16:25   battery         low
     2016-11-09 13:16:25   batteryCritical 0
     2016-11-09 13:16:25   lockState       unlocked
     2016-11-09 13:16:25   state           unlocked
     2016-11-09 13:16:25   success         1
   Helper:
Attributes:
   IODev      NBridge1
   alias      CobraTuer
   event-on-change-reading .*
   icon       hm_keymatic
   room       1.5_Flur


Info:
[{"nukiId": 102844921, "name": "CobraTuer", "lastKnownState": {"state": 3, "stateName": "unlocked", "batteryCritical": false, "timestamp": "2016-11-09T12:12:12+00:00"}}]

Trotz Zustand Disconnect funktioniert das steuern über FHEM.
Mit deiner neuen Version ändert sich bei mir aber auch kein Zustand und kein Batteriereading.

Sag Bescheid wenn du noch mehr Infos brauchst :-)

Gruß Cobra
RaspberryPI 3 mit Raspbian Jessie, HMLAN/HM-LAN-Gateway
Diverse HM-Komponenten, Netatmo, Hue, Sonos, Nuki, Alexa

CoolTux

Hallo Cobra,

Bitte Stelle mal die Bridge und das Smartlock auf verbose 5 und mach beim Smartlock ein statusRequest. Und dann das Log hier rein.
Den Status Low oder ok mache ich selbst auf Basis der Info batteryCritical. Die ist bei Dir 0 das ist ein Wert der nicht erwartet wird und daher eine Bedingung im else Zweig mit Low endet. Sollte da wohl besser ein elsif machen.


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

Cobra

#303
Hey CoolTux,

hier das Log nach dem statusRequest.
Nicht irritieren lassen, hab bei mir das Log umgedreht so dass die aktuellste Meldung immer oben ist :-)

2016.11.09 13:45:49 5: readings set for NUKIDevice102844921
2016.11.09 13:45:49 5: parse status message for NUKIDevice102844921
2016.11.09 13:45:49 4: NUKIBridge (NBridge1) - error while requesting: http://192.168.178.56:8080/lockState?token=xxxxxx&nukiId=102844921: empty answer received
2016.11.09 13:45:49 5: NUKIDevice (NUKIDevice102844921) - NUKIDevice_GetUpdate Call NUKIDevice_ReadFromNUKIBridge
2016.11.09 13:45:49 4: NUKIBridge (NBridge1) - Send HTTP POST with URL http://192.168.178.56:8080/lockState?token=xxxxxx&nukiId=102844921
2016.11.09 13:45:47 5: NUKIDevice (NUKIDevice102844921) - Call InternalTimer
2016.11.09 13:45:47 5: NUKIDevice (NUKIDevice102844921) - Call NUKIDevice_GetUpdate
2016.11.09 13:45:47 5: NUKIDevice (NUKIDevice102844921) - NUKIDevice_GetUpdate Call NUKIDevice_ReadFromNUKIBridge
2016.11.09 13:45:47 4: NUKIBridge (NBridge1) - Send HTTP POST with URL http://192.168.178.56:8080/lockState?token=xxxxxx&nukiId=102844921


Was komisch ist, wenn ich http://192.168.178.56:8080/lockState?token=xxxxxx&nukiId=102844921 in den Browser eingebe bekomme ich

{"state": 3, "stateName": "unlocked", "batteryCritical": false, "success": true}

Also keine 0 bei batteryCritical sondern false.
RaspberryPI 3 mit Raspbian Jessie, HMLAN/HM-LAN-Gateway
Diverse HM-Komponenten, Netatmo, Hue, Sonos, Nuki, Alexa

fred_feuerstein

hmm, bei mir steht im Device-Modul bei Battery OK und bei batteryCritical steht false.
Also genau wie es sein sollte, denke ich.

Keine Ahnung, warum da bei Dir eine 0 steht. Und battery low.
Gruß, Fred

FHEM auf Raspberry PI 3B+ im 7Zoll TouchDisplay Gehäuse, OS: Bullseye, mit Z-Wave RaZberry-Modul, 868CUL (WMBUS), LaCrosseCUL (Temp) und knapp 300 Devices aller Art

Steeeve

Zitat von: Cobra am 09 November 2016, 13:23:28
Habe jetzt jedoch ein kleines Problem. Das SmartLock hat ständig das Reading battery low, obwohl ich schon mehrfach mit neuen Batterien versucht habe. In der Nuki-App selbst finde ich keine Batterieanzeige aber auch keine Warnung dass die Batterien bald leer sind.

Kann es sein dass die ersten Batterien leer waren beim anlegen und er jetzt das Reading nicht mehr aktualisiert?
In der App wird rechts oben ein (i) abgezeigt wenn es besondere Meldungen gibt, zB Software Update, oder auch leere Batterie.

Aus dem Nuki Support Slack:
Do you have "Battery Dead" entries in your Smart Locks protocol? If yes, update the firmware to 1.2.3. If no, update the firmware too ;-)

lg
Steeeve


fred_feuerstein

ohnehin ist es am besten bei jeglichen Problemen, alle Firmware-Versionen der eingesetzten Hardware anzugeben.
Also Smartlock, Bridge, App-Software, FHEM-Modul, ... :)
Gruß, Fred

FHEM auf Raspberry PI 3B+ im 7Zoll TouchDisplay Gehäuse, OS: Bullseye, mit Z-Wave RaZberry-Modul, 868CUL (WMBUS), LaCrosseCUL (Temp) und knapp 300 Devices aller Art

CoolTux

Zitat von: Cobra am 09 November 2016, 13:49:00
Hey CoolTux,

hier das Log nach dem statusRequest.
Nicht irritieren lassen, hab bei mir das Log umgedreht so dass die aktuellste Meldung immer oben ist :-)

2016.11.09 13:45:49 5: readings set for NUKIDevice102844921
2016.11.09 13:45:49 5: parse status message for NUKIDevice102844921
2016.11.09 13:45:49 4: NUKIBridge (NBridge1) - error while requesting: http://192.168.178.56:8080/lockState?token=xxxxxx&nukiId=102844921: empty answer received
2016.11.09 13:45:49 5: NUKIDevice (NUKIDevice102844921) - NUKIDevice_GetUpdate Call NUKIDevice_ReadFromNUKIBridge
2016.11.09 13:45:49 4: NUKIBridge (NBridge1) - Send HTTP POST with URL http://192.168.178.56:8080/lockState?token=xxxxxx&nukiId=102844921
2016.11.09 13:45:47 5: NUKIDevice (NUKIDevice102844921) - Call InternalTimer
2016.11.09 13:45:47 5: NUKIDevice (NUKIDevice102844921) - Call NUKIDevice_GetUpdate
2016.11.09 13:45:47 5: NUKIDevice (NUKIDevice102844921) - NUKIDevice_GetUpdate Call NUKIDevice_ReadFromNUKIBridge
2016.11.09 13:45:47 4: NUKIBridge (NBridge1) - Send HTTP POST with URL http://192.168.178.56:8080/lockState?token=xxxxxx&nukiId=102844921


Was komisch ist, wenn ich http://192.168.178.56:8080/lockState?token=xxxxxx&nukiId=102844921 in den Browser eingebe bekomme ich

{"state": 3, "stateName": "unlocked", "batteryCritical": false, "success": true}

Also keine 0 bei batteryCritical sondern false.

Mist ich sollte mir angewöhnen RAW Messages ausgeben zu lassen. So bringt mir das ja nichts. Aber das Reading für lockState und so ändert sich wenn Du den Zustand des Schloßes änderst?

Ich habe den Code für die Batterie jetzt so geändert das ein false ok und ein true ein low ergibt. Alles andere ergibt ein value "parseError" im Reading.
Ich müsste mal den Code bei der 0.2.1er Version kurz umschreiben für Raw Messages. Melde mich dann wieder.
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

fred_feuerstein

ich muss einfach mal Danke sagen, CoolTux!

Und zwar für deinen unermüdlichen Einsatz, um das Modul voranzutreiben. Und dass, obwohl Du nicht mal selbst es benötigst ...

Einfach TOP!
Gruß, Fred

FHEM auf Raspberry PI 3B+ im 7Zoll TouchDisplay Gehäuse, OS: Bullseye, mit Z-Wave RaZberry-Modul, 868CUL (WMBUS), LaCrosseCUL (Temp) und knapp 300 Devices aller Art

CoolTux

Es macht Spaß und ich freue mich wenn es Euch was bringt.
Danke für Euren Dank.

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

CoolTux

So Cobra,

Bitte einmal die angehängte Datei ins FHEM/ kopieren und somit die alte überschreiben, danach ein reload 74_NUKIDevice eingeben und dann ein statusRequest bitte. Verbose 3 reicht aus.
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

Cobra

#311
Hey CoolTux,

hier die Meldung:
NUKIDevice (NUKIDevice102844921) - JSON: {"state": 3, "stateName": "unlocked", "batteryCritical": false, "success": true}

Als Reading hab ich immer noch batteryCritical 0
Reading für lockState ändert sich immer brav mit.

Ach ja, SmartLock hat die Firmeware 1.2.3

Gruß Cobra
RaspberryPI 3 mit Raspbian Jessie, HMLAN/HM-LAN-Gateway
Diverse HM-Komponenten, Netatmo, Hue, Sonos, Nuki, Alexa

CoolTux

Habe was lustiges entdeckt.

"batteryCritical": false, "success": true


Und jetzt schaue Dir mal Deine Readings batteryCritical und success an.
Und verrate mir mal was true und false in eigentlich sind aus Informatiker Sicht  ;D

Aber wie das kommt kann ich Dir noch nicht sagen. Aber ist lustig
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

Cobra

Stimmt, false könnte man ja auch als 0 bezeichnen  :o

Ist dann nur komisch dass false bei anderen auch als false im Reading angezeigt wird und bei mir setzt er dann die 0 rein
RaspberryPI 3 mit Raspbian Jessie, HMLAN/HM-LAN-Gateway
Diverse HM-Komponenten, Netatmo, Hue, Sonos, Nuki, Alexa

Steeeve

Zitat von: CoolTux am 09 November 2016, 17:37:06
Habe was lustiges entdeckt.

"batteryCritical": false, "success": true


Und jetzt schaue Dir mal Deine Readings batteryCritical und success an.
Und verrate mir mal was true und false in eigentlich sind aus Informatiker Sicht  ;D

Aber wie das kommt kann ich Dir noch nicht sagen. Aber ist lustig

Aber das passt doch, oder?
In dem Fall nicht kritisch, also ok und success:true bekommt man bei erfolgreicher Action, nicht?