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

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

Vorheriges Thema - Nächstes Thema

danillo

@Olaf: Ja, ich hab eine SW-Bridge. Hat damit aber auch schon mal funktioniert. Ich kann aber nicht sagen, seit wann es nicht mehr geht.

Mir ist jetzt noch folgendes Aufgefallen:
Internals:
   CHANGED
   DEF        99247689 IODev=NBridge1
   IODev      NBridge1
   NAME       NUKIDevice99247689
   NR         60
   NUKIID     99247689
   STATE      unlocked
   TYPE       NUKIDevice
   VERSION    0.6.1
   WEBHOOK_COUNTER 0
   WEBHOOK_PORT 8083
   WEBHOOK_REGISTER sent
   WEBHOOK_URI /fhem/NUKIDevice
   WEBHOOK_URL http://192.168.178.32:8083/fhem/NUKIDevice-99247689
   READINGS:
     2017-11-20 17:56:07   battery         ok
     2017-11-20 17:56:07   batteryCritical false
     2017-11-20 17:56:07   lockState       unlocked
     2017-11-20 18:00:38   name            Nuki_05EA6649
     2017-11-20 18:00:38   paired          true
     2017-11-20 18:00:38   rssi            -89
     2017-11-20 17:56:07   state           unlocked
     2017-11-20 17:58:27   success         true
   fhem:
     infix      NUKIDevice
   helper:
Attributes:
   IODev      NBridge1
   alias      P2
   event-on-change-reading state, battery, batteryCritical, lockstate
   room       NUKI
   verbose    0
   webhookFWinstance WEB
   webhookHttpHostname 192.168.178.32

WEBHOOK_URL http://192.168.178.32:8083/fhem/NUKIDevice-99247689
NAME       NUKIDevice99247689

Kann das die Ursache sein?

CoolTux

Hat damit nichts zu tun.
Mein Devicename ist WgtTuer und im Webhook steht auch NUKIDevice-12345
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

danillo

Main Alias ist P2.  :)
Aber zum Beispiel liefert list P2 kein Ergebnis, so wie list NUKIDevice-99247689. Nur list NUKIDevice99247689 liefert das gewünschte Ergebnis.

CoolTux

Zitat von: CoolTux am 20 November 2017, 18:18:11
Hat damit nichts zu tun.
Mein Devicename ist WgtTuer und im Webhook steht auch NUKIDevice-12345
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

danillo

#904
hmm,
also die Bridge fragt das kontinuierlich ab. Kann ich irgendwo sehen, ob die Bridge das auch wirklich macht? Oder muss ich mich mit dem Problem eher an Nuki wenden?
Ich habe jetzt nochmal über FHEM das Schloss angesteuert. Das Öffnen funktioniert einwandfrei.
battery ok 2017-11-20 19:06:40
batteryCritical false 2017-11-20 19:06:40
lockState locked 2017-11-20 19:05:38
name Nuki_05EA6649 2017-11-20 19:08:54
paired true 2017-11-20 19:08:54
rssi -75 2017-11-20 19:08:54
state locked 2017-11-20 19:05:38
success true 2017-11-20 19:06:40

Wie man sieht wird name, paired und rssi regelmäßig aktualisiert. battery und batteryCritical sowie success wurden nach dem Öffnen aktualisiert. Aber nicht lockState und state  ???

CoolTux

Warum sollte state oder lockState kontinuierlich aktuallisiert werden. Es reicht doch wenn dies bei Veränderungen gemacht wird.

Und der Status scheint auch korrekt zu sein. Wenn du zum Beispiel über FHEM sperrst dann kommt als erstes lock und wenn das Callback der Bridge kommt steht locked.
Hast Du ein statusRequest gemacht oder es so gelassen?
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

danillo

Das Schloss war von Hand abgeschlossen. (wurde nicht angezeigt)
Dann habe ich einen Statusrequest ausgeführt. (Jetzt wurde es korret als locked angezeigt.)19:05:38
Dann habe ich es per FHEM geöffnet. (also unlock gesendet)19:06:40
Das Schloss hat sich auch geöffnet.
Aber die Anzeige blieb bei locked.
Das ist das, was man oben sieht.

CoolTux

Irgendwas stimmt dann da nicht, es muss sofern die Bridge ein ok nach dem aufschließen oder zuschließen zurück gibt zu mindest ein lock oder unlock kommen. Das muss auf jeden Fall kommen, auch ohne statusRequest
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

Zitat von: olaf am 20 November 2017, 15:54:26
@danillo: bei mir klappt das mit dem Callback einwandfrei. Wie ich sehe, hast Du eine Software-Bridge. Ich habe eine Hardware-Bridge. Kann das daran liegen? Ich kenn die SW-Bridge nicht. Kann man da sehen, ob die "locked"-Meldung des Schlosses ankommt? Die 3 readings rssi, paired und name, die immer aktualisiert werden, resultieren nur aus einer zyklischen "Alive"-Abfrage des NUKI_Bridge Moduls. Diese ist nur vorgesehen, um zu sehen, ob die Bridge noch "connected" ist.

@CoolTux: Auf Github habe ich einen PR für meine Änderungen eingestellt. Kannst ja mal schauen.
Der Fehler 503 schlägt nun nicht mehr als json-error durch.
Weiterhin habe ich alle Anfragen an die Bridge/Schloss nun serialisiert und, wenn es eine Fehlermedung zurückgibt (503-unavailable, leere Antwort, http-timeout) wiederhole ich die Befehle solange, bis sie vom Schloss umgesetzt wurden. Damit vermeide ich, dass wichtige Befehle wie "lock" im Falle eines Fehlers einfach unter den Tisch fallen.

Eine Sache habe ich noch nicht im Griff, s. Anhang.
Kann man irgendwie zwischen Statusmeldungen des Schlosses aufgrund manueller Betätigung und Antworten auf fhem-Anfragen unterscheiden?

Ich habe Deinen Patch gestern ins master übernommen und werde es die Tage testen. Laden hat schon mal geklappt  ;D



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

olaf

Zitat von: CoolTux am 21 November 2017, 12:30:49
Ich habe Deinen Patch gestern ins master übernommen und werde es die Tage testen. Laden hat schon mal geklappt  ;D

Grüße

Danke. Ich bin gerade noch dem letzten (?) Problem auf der Spur (ganz unten in meinem Post) Wenn Du schon mal testen willst... oder Du wartest noch etwas. Ich schicke einen neuen PR.

Olaf

CoolTux

Bin nun zu Hause und habe mir das ganze mal angeschaut.
Hast Du das bei Dir so am laufen? Bei mir legt er ständig ein Notify an und löscht das wieder. Das muss ich mir mal anschauen. Das ist sehr suboptimal denn ich bekomme ständig den Hinweis für save, also das rote Fragezeichen.
Ich muss mir das ganze doch erstmal in Ruhe anschauen.
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

olaf

Das mit dem notify ist die Grundidee. Wenn der state von "processing" auf "connected" zurückgeht, ist die Bridge wieder aufnahmebereit und per notify löse ich den nächsten Befehl aus, der sich auf dem Stack angesammelt hat.
Das mit dem save bekomme ich nicht. Ich denke das liegt daran, dass ich in der cfg "attr global autosave 0" gesetzt habe. Ich mag es nicht, wenn immerzu in meiner cfg rumgeschrieben wird.
Aber ein guter Hinweis und vielleicht nicht für jeden Anwendungsfall geeignet. Ich denke mir mal was anderes aus.
Für weitere Hinweise bin ich dankbar ....

CoolTux

Zitat von: olaf am 21 November 2017, 19:42:41
Das mit dem notify ist die Grundidee. Wenn der state von "processing" auf "connected" zurückgeht, ist die Bridge wieder aufnahmebereit und per notify löse ich den nächsten Befehl aus, der sich auf dem Stack angesammelt hat.
Das mit dem save bekomme ich nicht. Ich denke das liegt daran, dass ich in der cfg "attr global autosave 0" gesetzt habe. Ich mag es nicht, wenn immerzu in meiner cfg rumgeschrieben wird.
Aber ein guter Hinweis und vielleicht nicht für jeden Anwendungsfall geeignet. Ich denke mir mal was anderes aus.
Für weitere Hinweise bin ich dankbar ....

Ich habe mal kurz geschaut. Prinzipiell ist es so das Attribute und notify und at und so Userdinge sind. Sprich der User entscheidet. Genau wie das auskommentierte attr event-on-change-reading. Dann haben fhem Befehle nichts im Modul zu suchen. Dafür ruft man wenn dann die eigentliche CommandFn auf.

Du kannst zwei Dinge machen. Entweder steuerst Du alles über den Funktionsfluss oder Du reagierst auf Events mit Hilfe der NotifyFn. Siehe dazu das Developer Guide im Wiki.
Die Grundidee und der Code sind ja soweit ok. Ich muss da aber noch mal ganz in Ruhe schaue. Zu mindest die Befehls Warteschlange ist doch super, da kann man dann nach dem auswerten des http Codes doch schauen. Kommt ein 50? glaube 2 war das dann soll der letzte Befehl noch mal gesendet werden, wenn nicht ist alles ok und es muss geschaut werden ob noch weitere Befehle im Array sind. Ich habe das selbige Prinzip im Tesla Modul verwendet, eventuell magst da Mal schauen, 46_TeslaPowerwall2AC.pm
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

olaf

Danke für die Hinweise.
Das mit dem notify-Gedanken werde ich beibehalten. Ich bau das Modul mal auf die notifyFn um.

CoolTux

Zur Info. Ich habe mich heute mal ran gesetzt und alle nonBlocking BridgeCall Aufrufe in eine Quere gesteckt die dann abgearbeitet wird. Das ganze kann ich aber erst sinnvoll heute Abend testen. Danach kann man sich dann Gedanken um das abfangen des 503 Fehlers machen und den erneuten Befehlsaufruf.



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