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

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

Vorheriges Thema - Nächstes Thema

Sascha_F

Hi fabtie,

nur zur Sicherheit: Das Lock hast Du aber über die Bridge anlegen lassen und nicht selbst definiert, oder (denn jetzt wird das Lock mit dem in der App vergebenen Namen angelegt).

Viele Grüße
Sascha

fabtie

Hallo Sascha, ja ich habe das Lock von der Bridge anlegen lassen. Gestern hieß es noch NUKIDevice_123456 und heute Haust_r (Haustür in der App). Ich muss auch nicht manuell das Webhook ausfüllen. Wenn ich nach dem Bridge Anlegen get Callbacklist ausführe erhalte ich automatisch entsprechende Antwort (http://'ip-fhem':8083/fhem/NUKIBridge-'IPBridge'). Wenn ich WebhookFWinstance und Hostname noch eintrage bekomme ich die Zeile doppelt. Eine Zeile habe ich jetzt wieder gelöscht.
Grüße
Fabian
FHEM auf RPi3|HM-CUL und piVCCU, 20x HM-IP | ZigBee/HUE über conbeeII-Stick, 17x ZigBee

CoolTux

Zitat von: fabtie am 21 Januar 2020, 22:44:01
Ja, korrekt. Schalten im Device über set lock/unlock funktioniert.
Dann ändert sich sogar auch der state, allerdings nicht in locked oder unlocked sondern in lock oder unlock.

Zeige mal bitte ein list vom Bridge Device. Und zeige das Ergebnis von get callbackList
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

fabtie

Moin, hier mein List:

Internals:
   BRIDGEAPI  1.9
   CFGFN     
   DEF        'BridgeIP' abc123
   FUUID      5e27630e-f33f-3d64-6f0f-9d75ea687aa7a461
   FVERSION   73_NUKIBridge.pm:v1.9.16-s20994/2020-01-16
   HOST       'BridgeIP'
   NAME       NBridge1
   NOTIFYDEV  global,NBridge1
   NR         184
   NTFY_ORDER 50-NBridge1
   PORT       8080
   STATE      connected
   TOKEN      abc123
   TYPE       NUKIBridge
   VERSION    v1.9.16
   WEBHOOK_COUNTER 0
   WEBHOOK_PORT 8083
   WEBHOOK_REGISTER sent
   WEBHOOK_URI /fhem/NUKIBridge-'BridgeIP'
   WEBHOOK_URL http://'FhemIP':8083/fhem/NUKIBridge-'BridgeIP'
   READINGS:
     2020-01-22 08:04:40   bridgeType      Hardware
     2020-01-22 08:04:40   currentTime     2020-01-22T07:04:40+00:00
     2020-01-22 08:04:40   firmwareVersion 1.13.1
     2020-01-22 08:04:40   hardwareId      324204985
     2020-01-22 08:04:40   serverConnected 1
     2020-01-22 08:04:40   serverId        2028750935
     2020-01-22 08:04:40   state           connected
     2020-01-22 08:04:40   uptime          40999
     2020-01-22 08:04:40   wifiFirmwareVersion 1.2.0
   fhem:
     infix      NUKIBridge
   helper:
     iowrite    0
     actionQueue:
Attributes:
   room       NUKI
   webhookFWinstance WEB
   webhookHttpHostname 'FhemIP'

Das callback siehe Anhang.

Ich hatte gerade noch bemerkt, dass ich bei den letzten Versuchen unter webhookHttpHostname die BridgeIP statt der FhemIP hatte. Das callback war aber korrekt. Ich habe das jetzt nochmal angepasst und FHEM neugestartet, habe aber immer noch das gleiche Verhalten wie zuvor.
Nach einem Neustart werden übrigens einmalig alle Readings des Device aktualisiert und das Device zeigt den richtigen state locked/unlocked an.

Ich hoffe das hilft. Danke.
FHEM auf RPi3|HM-CUL und piVCCU, 20x HM-IP | ZigBee/HUE über conbeeII-Stick, 17x ZigBee

CoolTux

Sieht OK aus. Und die angegebene Webinstanz ist http und nicht Passwort geschützt?
Hast du mal alle Callbacks gelöscht und dann auf der grünen Wiese neu angelegt?
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

fabtie

Danke CoolToux, die PW geschützte WEBinstanz war es.  >:(
Auch wenn ich mir ziemlich sicher bin, dass ich gestern auch die andere Instanz getestet hatte. Aber vermutlich hatte ich da dann einen anderen Fehler drin.
Auf jeden Fall tut jetzt wieder alles wie vorher. Vielen vielen Dank!!!
Grüße Fabian
FHEM auf RPi3|HM-CUL und piVCCU, 20x HM-IP | ZigBee/HUE über conbeeII-Stick, 17x ZigBee

daniel2311

Hallo zusammen,
kann es sein, dass es das Reading LockState an einem NukiDevice nicht mehr gibt?
Der State an sich ist richtig.
Ich hatte kürzlich etwas umgestellt und das ganze lief nicht mehr richtig. Jetzt läuft es, die Hooks funktionieren wieder, aber der WatchDog geht nicht mehr und ich habe gesehen, dass ich dort auf LockState-Events reagiere.
Bug oder habe ich etwas nicht mitbekommen?

CoolTux

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

daniel2311

Super vielen Dank - ich denke, ich nutze dann stateName oder state, was wäre sinnvoller?

CoolTux

Ich würde state nehmen da dort der tatsächliche Zustand ausgehend von FHEM drin steht.
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

choenig

Zitat von: CoolTux am 25 Januar 2020, 17:30:22
Jepp gibt es nicht mehr.

Laut meiner commandref existiert das noch ;)


lockState - aktueller Schließstatus uncalibrated, locked, unlocked, unlocked (lock 'n' go), unlatched, locking, unlocking, unlatching, motor blocked, undefined.


... und nicht nur da ...


# grep lockState *
74_NUKIDevice.pm:my %lockStates = (
74_NUKIDevice.pm:        IOWrite( $hash, 'lockState', undef, $hash->{NUKIID},
74_NUKIDevice.pm:            IOWrite( $hash, 'lockState', undef, $hash->{NUKIID} )
74_NUKIDevice.pm:            IOWrite( $hash, 'lockState', undef, $hash->{NUKIID},
74_NUKIDevice.pm:            ( $v =~ m/^[0-9]$/ ? $lockStates{$v}{ $hash->{DEVICETYPE} } : $v ) )
74_NUKIDevice.pm:    <li>lockState - current lock status uncalibrated, locked, unlocked, unlocked (lock 'n' go), unlatched, locking, unlocking, unlatching, motor blocked, undefined.</li>
74_NUKIDevice.pm:    <li>lockState - aktueller Schlie&szlig;status uncalibrated, locked, unlocked, unlocked (lock 'n' go), unlatched, locking, unlocking, unlatching, motor blocked, undefined.</li>


ABER:

Habe ich die Ankündigung irgendwo überlesen, dass das entfernt wurde?

LG
Christian

CoolTux

Zitat von: choenig am 26 Januar 2020, 10:02:41
Laut meiner commandref existiert das noch ;)


lockState - aktueller Schließstatus uncalibrated, locked, unlocked, unlocked (lock 'n' go), unlatched, locking, unlocking, unlatching, motor blocked, undefined.


... und nicht nur da ...


# grep lockState *
74_NUKIDevice.pm:my %lockStates = (
74_NUKIDevice.pm:        IOWrite( $hash, 'lockState', undef, $hash->{NUKIID},
74_NUKIDevice.pm:            IOWrite( $hash, 'lockState', undef, $hash->{NUKIID} )
74_NUKIDevice.pm:            IOWrite( $hash, 'lockState', undef, $hash->{NUKIID},
74_NUKIDevice.pm:            ( $v =~ m/^[0-9]$/ ? $lockStates{$v}{ $hash->{DEVICETYPE} } : $v ) )
74_NUKIDevice.pm:    <li>lockState - current lock status uncalibrated, locked, unlocked, unlocked (lock 'n' go), unlatched, locking, unlocking, unlatching, motor blocked, undefined.</li>
74_NUKIDevice.pm:    <li>lockState - aktueller Schlie&szlig;status uncalibrated, locked, unlocked, unlocked (lock 'n' go), unlatched, locking, unlocking, unlatching, motor blocked, undefined.</li>


ABER:

Habe ich die Ankündigung irgendwo überlesen, dass das entfernt wurde?

LG
Christian

Schaue ich mir die Tage mal an.
Bei IOWrite ist es eindeutig kein Reading sondern ein CMD der an das IO Device gesendet wird. Das mit dem grep ist aber etwas in Richtung Reading. Ich muss mal schauen wieso das nicht greift.
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

Claus1985

Hi CoolTux,

danke für das geniale Modul!
Habe seit dem Update (vorhin FHEM vollständig geupdated) eine Fehlermeldung bzgl.
der Webhooks:
NUKIDevicexxx unknown attribute webhookFWinstance. Type
NUKIDevicexxx unknown attribute webhookHttpHostname. Type

Gibt es eine Möglichkeit das zu fixen ohne Schloss und Bridge zu entfernen und neu
einzufügen?

Danke und Gruß,

Claus

CoolTux

Zitat von: Claus1985 am 26 Januar 2020, 18:56:57
Hi CoolTux,

danke für das geniale Modul!
Habe seit dem Update (vorhin FHEM vollständig geupdated) eine Fehlermeldung bzgl.
der Webhooks:
NUKIDevicexxx unknown attribute webhookFWinstance. Type
NUKIDevicexxx unknown attribute webhookHttpHostname. Type

Gibt es eine Möglichkeit das zu fixen ohne Schloss und Bridge zu entfernen und neu
einzufügen?

Danke und Gruß,

Claus

Na klar. Einfach save drücken und gut ist. Beim nächsten Start sollte die Meldung dann nicht mehr kommen. Musst aber den webhook über die Bridge noch einrichten.
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

Claus1985

Super, danke für die schnelle Info! :-)
Muss ich Lockstate noch gegen State tauschen damit der Status nach wie vor übertragen werden kann?