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

[fred_feuerstein]

hab jetzt die 0.4.4pre5 vom Bridge-Modul zusammen mit der 0.4.0 vom Device-Modul vom 18.12. getestet.
Der Status wird aktualisiert und man kann sowohl über die App, als auch über die Api, als auch über fhem schliessen und öffen.
Hab nur bei den Readings von der Bridge wieder sowas:
lastError: Internal error, 503    2017-01-06 23:51:08

Bin mir nun nicht sicher, ob das die ganze Zeit mit der 0.4.0 vom Bridge-Modul auch war.

Ich packe nun das 0.4.0 nochmal drauf. Dann sehe ich ja, ob noch aktuellere "Internal error, 503" Meldungen kommen.

unabhängig davon ist irgendwas anders:
Beim neuen Bridge Modul wurden immer alle readings alle paar Sekunden zusammen mit dem State aktualisiert.
Beim alten Modul immer nur der state "connected", die anderen Readings nur wenn nötig scheinbar.

Hm. ich bleibe erstmal bei der 0.4.0

[CoolTux]

Ich habe mir eine andere Art für das alive Check überlegt. Ich lasse für den check ein /info abrufen. Dadurch kommt das neue aktuallisieren.
Aber Du solltest wenn dann nur mit dem passenden Device Modul testen. Ich warte noch kurz was Sam sagt und gebe das dann auf GitHub frei.

[samh]

Guten Morgen,

hab gestern nicht mehr mitbekommen, dass Ihr noch so aktiv gewesen seid.
Also... hier bei mir funktioniert es nun wie ich es erwarte. Alle Kommandos and das NUKI werden ausgeführt und zeitnah
der Status abgedatet.

Allerdings bekommt FHEM wohl nichts davon mit, wenn ich das Schloss manuell betätige.
Irgendwie wird sehr oft gecheckt, ob die Bridge lebt. Aber das was eigentlich interessant ist, das Schloss, wird wenig beachtet.

Könntest Du nicht statt dem Info ein List absetzen, die aktuellen Zustände der NUKIDevices damit holen und updaten.
Das die Bridge alive ist, wäre doch dann implizit, oder ?

Gruß Sam

Log der aktuellen PRE Module

Code Auswählen Erweitern


2017.01.07 08:53:56 4: NUKIBridge (NBridge1) - Call InternalTimer for NUKIBridge_GetCheckBridgeAlive
2017.01.07 08:53:56 5: NUKIBridge (NBridge1) - Response JSON: {"bridgeType":2,"ids":{"serverId":vvvvvvvvvv},"versions":{"appVersion":"0.2.14"},"uptime":192968,"currentTime":"2017-01-07T07:53:59Z","serverConnected":true,"scanResults":[{"nukiId":ZZZZZZZZZ,"name":"Nuki_CCCCCCC","rssi":-81,"paired":true}]}
2017.01.07 08:53:56 5: NUKIBridge (NBridge1) - Response ERROR:
2017.01.07 08:53:56 5: NUKIBridge (NBridge1) - Response CODE: 200
2017.01.07 08:53:56 5: NUKIBridge (NBridge1) - Bridge ist online
2017.01.07 08:53:59 4: NUKIDevice (NUKI_HT_vorn) - NUKIDevice_ReadFromNUKIBridge check Bridge connected
2017.01.07 08:53:59 4: NUKIDevice (NUKI_HT_vorn) - NUKIDevice_ReadFromNUKIBridge Bridge is connected call IOWrite
2017.01.07 08:53:59 4: NUKIBridge (NBridge1) - Send HTTP POST with URL http://192.168.XXX.XXX:8080/lockAction?token=YYYYYYYYYY&action=2&nukiId=ZZZZZZZZZ

Das"sucess":true soll für das Setzen des Status sorgen ?
2017.01.07 08:54:10 5: NUKIBridge (NBridge1) - Response JSON: {"batteryCritical":false,"success":true}

2017.01.07 08:54:10 5: NUKIBridge (NBridge1) - Response ERROR:
2017.01.07 08:54:10 5: NUKIBridge (NBridge1) - Response CODE: 200
2017.01.07 08:54:10 5: NUKIDevice (NUKI_HT_vorn) - parse status message for NUKI_HT_vorn
2017.01.07 08:54:10 4: NUKIDevice (NUKI_HT_vorn) - NUKIDevice_ReadFromNUKIBridge check Bridge connected
2017.01.07 08:54:10 4: NUKIDevice (NUKI_HT_vorn) - NUKIDevice_ReadFromNUKIBridge Bridge is connected call IOWrite
2017.01.07 08:54:10 4: NUKIBridge (NBridge1) - Send HTTP POST with URL http://192.168.XXX.XXX:8080/lockState?token=YYYYYYYYYY&nukiId=ZZZZZZZZZ
2017.01.07 08:54:10 5: NUKIDevice (NUKI_HT_vorn) - readings set for NUKI_HT_vorn
2017.01.07 08:54:11 5: NUKIBridge (NBridge1) - Response JSON: {"batteryCritical":false,"state":1,"stateName":"locked","success":true}
2017.01.07 08:54:11 5: NUKIBridge (NBridge1) - Response ERROR:
2017.01.07 08:54:11 5: NUKIBridge (NBridge1) - Response CODE: 200
2017.01.07 08:54:11 5: NUKIDevice (NUKI_HT_vorn) - parse status message for NUKI_HT_vorn
2017.01.07 08:54:11 5: NUKIDevice (NUKI_HT_vorn) - readings set for NUKI_HT_vorn
2017.01.07 08:54:27 4: NUKIBridge (NBridge1) - NUKIBridge_GetCheckBridgeAlive
2017.01.07 08:54:27 4: NUKIBridge (NBridge1) - Send HTTP POST with URL http://192.168.XXX.XXX:8080/info?token=YYYYYYYYYY
2017.01.07 08:54:27 4: NUKIBridge (NBridge1) - Call InternalTimer for NUKIBridge_GetCheckBridgeAlive
2017.01.07 08:54:27 5: NUKIBridge (NBridge1) - Response JSON: {"bridgeType":2,"ids":{"serverId":vvvvvvvvvv},"versions":{"appVersion":"0.2.14"},"uptime":192999,"currentTime":"2017-01-07T07:54:30Z","serverConnected":true,"scanResults":[{"nukiId":ZZZZZZZZZ,"name":"Nuki_CCCCCCC","rssi":-77,"paired":true}]}
2017.01.07 08:54:27 5: NUKIBridge (NBridge1) - Response ERROR:
2017.01.07 08:54:27 5: NUKIBridge (NBridge1) - Response CODE: 200
2017.01.07 08:54:27 5: NUKIBridge (NBridge1) - Bridge ist online
2017.01.07 08:54:34 4: NUKIDevice (NUKI_HT_vorn) - NUKIDevice_ReadFromNUKIBridge check Bridge connected
2017.01.07 08:54:34 4: NUKIDevice (NUKI_HT_vorn) - NUKIDevice_ReadFromNUKIBridge Bridge is connected call IOWrite
2017.01.07 08:54:34 4: NUKIBridge (NBridge1) - Send HTTP POST with URL http://192.168.XXX.XXX:8080/lockAction?token=YYYYYYYYYY&action=1&nukiId=ZZZZZZZZZ
2017.01.07 08:54:44 5: NUKIBridge (NBridge1) - Response JSON: {"batteryCritical":false,"success":true}
2017.01.07 08:54:44 5: NUKIBridge (NBridge1) - Response ERROR:
2017.01.07 08:54:44 5: NUKIBridge (NBridge1) - Response CODE: 200
2017.01.07 08:54:44 5: NUKIDevice (NUKI_HT_vorn) - parse status message for NUKI_HT_vorn
2017.01.07 08:54:44 4: NUKIDevice (NUKI_HT_vorn) - NUKIDevice_ReadFromNUKIBridge check Bridge connected
2017.01.07 08:54:44 4: NUKIDevice (NUKI_HT_vorn) - NUKIDevice_ReadFromNUKIBridge Bridge is connected call IOWrite
2017.01.07 08:54:44 4: NUKIBridge (NBridge1) - Send HTTP POST with URL http://192.168.XXX.XXX:8080/lockState?token=YYYYYYYYYY&nukiId=ZZZZZZZZZ
2017.01.07 08:54:44 5: NUKIDevice (NUKI_HT_vorn) - readings set for NUKI_HT_vorn
2017.01.07 08:54:45 5: NUKIBridge (NBridge1) - Response JSON: {"batteryCritical":false,"state":3,"stateName":"unlocked","success":true}
2017.01.07 08:54:45 5: NUKIBridge (NBridge1) - Response ERROR:
2017.01.07 08:54:45 5: NUKIBridge (NBridge1) - Response CODE: 200
2017.01.07 08:54:45 5: NUKIDevice (NUKI_HT_vorn) - parse status message for NUKI_HT_vorn
2017.01.07 08:54:45 5: NUKIDevice (NUKI_HT_vorn) - readings set for NUKI_HT_vorn
2017.01.07 08:54:47 4: NUKIBridge (NBridge1) - NUKIBridge_GetCheckBridgeAlive
2017.01.07 08:54:47 4: NUKIBridge (NBridge1) - Send HTTP POST with URL http://192.168.XXX.XXX:8080/info?token=YYYYYYYYYY
2017.01.07 08:54:47 4: NUKIBridge (NBridge1) - Call InternalTimer for NUKIBridge_GetCheckBridgeAlive
2017.01.07 08:54:47 5: NUKIBridge (NBridge1) - Response JSON: {"bridgeType":2,"ids":{"serverId":vvvvvvvvvv},"versions":{"appVersion":"0.2.14"},"uptime":193019,"currentTime":"2017-01-07T07:54:50Z","serverConnected":true,"scanResults":[{"nukiId":ZZZZZZZZZ,"name":"Nuki_CCCCCCC","rssi":-76,"paired":true}]}
2017.01.07 08:54:47 5: NUKIBridge (NBridge1) - Response ERROR:
2017.01.07 08:54:47 5: NUKIBridge (NBridge1) - Response CODE: 200
2017.01.07 08:54:47 5: NUKIBridge (NBridge1) - Bridge ist online


[CoolTux]

Hallo Sam,

Genau das ist leider das Problem. Damit fing das ganze Theater ja an.
Ein Check des Status der Bridge brachte die Hardware Bridge zum erliegen. Das Teil ist einfach nicht dafür ausgelegt parallele Anfragen ab zu arbeiten. Mir wurde empfohlen auf Single um zu steigen.
Da die Hardware Bridge einen Webhook liefert ist das ja nun nicht mehr das Problem. Bei der Software Bridge habe ich momentan diese Möglichkeit leider nicht

Jetzt hier beim schreiben kommt mir aber eine Idee die wir beide mal versuchen können. Da wir ja unterscheiden können welcher Bridgetype vorhanden ist kann ich versuchen auf Basis dessen eine Abfrage mit Intervall ein zu bauen. Am besten noch mit dem expliziten setzen eines Attributes verbunden.

Ich werde mich die Tage mal daran machen.

@ALL
Ich gebe nun die neue Version vorerst über Github frei. Bitte auch mal als Hardware Bridge Besitzer testen. Danke.

[samh]

Danke für die Info.

Das NUKIDevice selbst sendet keinen StatusRequest in einem bestimmten Intervall, um mit zu bekommen,
ob sich der Status (manuell) des Schlosses geändert hat ?

Gruß Sam

[CoolTux]

Nein das macht es nicht. Aber genau das werde ich mal testweise einbauen. Aber nur für Software Bridges.

[fred_feuerstein]

Wenn du das unterscheiden kannst, wäre es gut die Sache für die Hardware bridge so zu lassen, wie bei der 0.4.0.
Das läuft bei mir und den anderen hardware-bridge Usern wie schon gesagt seit dem 18.12.  perfekt.  Ich fand das mit den möglichst wenig abfragen wegen dem webhook klasse.

>> gesendet mit OnePlus 3T via Tapatalk <<

[CoolTux]

Das bleibt auf jeden Fall so. Keine Sorge. Wir können ja super unterscheiden.
Magst Du die neuen Versionen vom Git testen?

[fred_feuerstein]

Klar. Mache ich später.

>> gesendet mit OnePlus 3T via Tapatalk <<

[CoolTux]

DAAAANKE

[fred_feuerstein]

Wir haben alle danke bei dir zu sagen

>> gesendet mit OnePlus 3T via Tapatalk <<

[fred_feuerstein]

Also ich habe nun die 0.4.4. aus dem Master-Branch getestet.

Es schaltet und zeigt den Status an (ist es eigentlich richtig und notwendig, dass ich nach einem solchen Austausch der Version den Callback über das Bridge Modul lösche und über das Device neu erstelle? Mache ich bisher immer)

Was mir aufgefallen ist:
- Die Schaltvorgänge dauern länger, also nach Klick bspw. in der App dauert es länger, bis das Schloss was macht. So, als hätte die Bridge gerade was besseres zu tun.
- Beim Device wird nur noch Lockstate und State aktualisiert. Battery, batteryCritical und Success bekommt kein Update.
- BridgeModul erhält alle Readings in den Abfrageintervallen und nicht nur State Connected.

Weißt Du, wo diese "Internal error, 503" bei last error hin und wieder kommen?

Ich lasse es mal eine Weile laufen mit den Modul Versionen. Dann mal schauen.

LG
fred

[CoolTux]

Also ich habe nun die 0.4.4. aus dem Master-Branch getestet.

Es schaltet und zeigt den Status an (ist es eigentlich richtig und notwendig, dass ich nach einem solchen Austausch der Version den Callback über das Bridge Modul lösche und über das Device neu erstelle? Mache ich bisher immer)

Was mir aufgefallen ist:
- Die Schaltvorgänge dauern länger, also nach Klick bspw. in der App dauert es länger, bis das Schloss was macht. So, als hätte die Bridge gerade was besseres zu tun.
- Beim Device wird nur noch Lockstate und State aktualisiert. Battery, batteryCritical und Success bekommt kein Update.
- BridgeModul erhält alle Readings in den Abfrageintervallen und nicht nur State Connected.

Weißt Du, wo diese "Internal error, 503" bei last error hin und wieder kommen?

Ich lasse es mal eine Weile laufen mit den Modul Versionen. Dann mal schauen.

LG
fred

Schaltvorgänge dauern länger.
Versuche mal bitte bei der Bridge disable 1 als Attribut zu setzen. Warte dann eine Minute und schalte noch mal. Geht es dann schneller?

Lockstate und state
Das muss ich mir anschauen. Es klingt so als wenn Dein Callback nicht korrekt funktioniert. Das schaue ich mir nachher an.

Bridgemodul alle Readings
Das sollte nicht sein. Es sollten nicht alle Readings aktuallisiert werden. Nur die die bei einem set info auch aktuallisiert werden. Infos zur Anzahl und Namen der Schlößer zum Beispiel sollten nicht aktualisiert werden.

Und ich bräuchte Logausgaben bitte.

[CoolTux]

Ich ha e gerade noch ein paar Zeilen gefunden die ich einsparen und wo ich was umbauen kann. So sollten die Abläufe zum erfassen eines Schaltvorganges besser dem Bridgetype angepasst sein.

[fred_feuerstein]

nach disable und warten dauert es unwesentlich kürzer.

Lockstate und State.
Es ist so, zuerst werden die beiden aktualisiert. die anderen readings werden erst nach Seitenreload aktualisiert angezeigt, und success wird nicht immer aktualisiert.
Ich verstehe es auch gerade nicht.

Werde es mal weiter laufen lassen und beobachten.