Test Adapter Nuki-extended v2.0.x
-
Ich habe eine Frage zu der Schließ-Historie deines Adapters. Gibt es das nur als ioB Kachel, ober findet man das auch irgendwo in den Tiefen der Datenpunkte als json Tabelle?
Ja ich weiß, ich stehe auf Tabellen - Die Schließ-Historie von deinem Adapter sieht ganz hübsch aus, nur leider passt die vom Design soo gar nicht zu meinem VIS.
Gibt da jetzt schon eine Möglichkeit die ich ggf. übersehen habe oder wäre das etwas was man unter Umständen für die Zukunft mal mit einbauen könnte?
-
@JB_Sullivan Der Datenpiunkt den Du suchst heißt logs wenn ich mich nicht täusche
-
Ja logs habe ich schon gefunden, aber ich persönlich kann damit nichts anfangen, weil ich nicht weiß wie ich das Tabellarisch aufbereiten soll. Da sind mir fertig json Tabellen lieber - die kann man im VIS einfach in ein Widget schieben und schwupp ist die Tabelle fertig.
Für so tiefgreifende Ding wie Logs in Tabellen umbasteln, bin ich leider zu doof
-
@JB_Sullivan Ja,
logs, z.B.nuki-extended.0.smartlocks.wohnungstür.logs. Ist aber keine "vis Tabelle", sondern die Log-Daten im JSON-Format. Du musst die parsen, bevor du die nutzen kannst, aber keine Ahnung, wie das mit vis geht (ich benutze vis nicht).Also mit javascript:
const logs = JSON.parse(getState('nuki-extended.0.smartlocks.wohnungstür.logs')); -
@cash sagte in Test Adapter Nuki-extended v2.0.x:
Der Adapter bekommt die Änderungen div. Datenpunkte von Nuki nicht mit.
Die Nuki Web API meldet die Änderungen nicht, daher ist ein polling notwendig. Ähnlich wie bei der Hue Bridge, falls du die nutzt.
Die Nuki Bridge API schickt Änderungen, aber die Web API eben nicht.Bedeutet, dass du ein Polling im Adapter einstellen musst. Im Standard ist 0 eingestellt, also kein Polling. Was steht denn im Log, wenn du den Adapter startest?
Polling Nuki Web API with a frequency of 60s. -
@Zefau Ist dann aber die Rolle für den LOG DP nicht falsch - müsste die nicht auf history anstatt auf state stehen?
-
@Zefau 63 Sekunden ist bei mir eingestellt. Erscheint auch im Log beim Adapterstart. Ich hätte schwören können das ich dort 60 Sekunden eingestellt hatte. Hatte mich schon gewundert das beim Adapterstart dort immer 63 Sekunden stand
Polling ist mir bekannt. Welche Datenpunkte vom Opener werden denn per Callback verarbeitet? Wie ich schon schrieb werden ja einige Datenpunkte aktualisiert. Ich würde erwarte wenn das Polling nicht funktioniert das ich einen Error im Log bekomme oder?
-
@cash sagte in Test Adapter Nuki-extended v2.0.x:
Welche Datenpunkte vom Opener werden denn per Callback verarbeitet?
Das sind leider nicht viele, siehe https://developer.nuki.io/page/nuki-bridge-http-api-1-10/4#heading--callback:
{“nukiId”: 11, “deviceType”: 0, “mode”: 2, “state”: 1, “stateName”: “locked”, “batteryCritical”: false}Mehr nicht, der Rest kommt von der Web API, die gepollt werden muss.
Sofern das Polling nicht funktioniert / fehlschlägt erscheint ein Fehler im Log.
Der Datenpunktnuki-extended.0.info.webApiLastzeigt an, wann zuletzt aktualisiert wurde (undnuki-extended.0.info.webApiSync, ob überhaupt aktualisiert wird). -
@JB_Sullivan sagte in Test Adapter Nuki-extended v2.0.x:
müsste die nicht auf history anstatt auf state stehen?
Jo, mit den Rollen habe ich es nicht so. Ich werde das mal anpassen.
-
@Zefau entsprechende Datenpunkte sind aktuell. Der LastWebApi ist weniger als eine Minute alt. Im Log sind keine Fehler somit eigentlich ok. Trotzdem werden die Datenpunkte nicht aktualisiert wenn ich die Daten per Nuki-App ändere. Egal auf welchen Wert ich z. B. DoubleButtonPressAction vom Opener ändere der Wert im Adapter ändert sich nicht. Wie schon geschrieben ändere ich im Adapter den Wert wird dieser korrekt übertragen..
-
@cash ok, vielen Dank für das Feedback, ich prüfe das morgen nochmal
-
Ich habe heute mal angefangen ein VIS Bildchen für das Schloss zu basteln. Dabei ist mir aufgefallen, das Status Änderungen die durch die Smartphone App ausgeführt wurden, gar nicht, oder extrem Zeit verzögert im Adapter ankommen und dann dementsprechend spät visualisiert werden.
Manchmal kommt es auch zu einer Mix Situation - Also der Zustand "Öffnung" wird durchgeführt, die Tür springt auf, was wiederum durch den Magnetkontakten auch erkannt und dem zufolge beide Zustände in der Handy App korrekt angezeigt werden.
Im Adapter kommt aber nur einer der beiden Zustände richtig an. Der Datenpunkt " nuki-extended.0.smartlocks.haustür.state.closed" (BtW - wie bekommt man den DP in diese Rot/weiße Forums Anzeige?) bleibt dort auf true stehen, obwohl die Tür offen steht und es in der Handy App auch so erkannt wurde.
Hier mal ein erster Entwurf was man ggf. alles Visualisieren könnte.
-
@JB_Sullivan sagte in Test Adapter Nuki-extended v2.0.x:
Dabei ist mir aufgefallen, das Status Änderungen die durch die Smartphone App ausgeführt wurden, gar nicht, oder extrem Zeit verzögert im Adapter ankommen und dann dementsprechend spät visualisiert werden.
Klingt so, als wäre der Callback nicht richtig gesetzt.
Starte mal den Adapter neu und poste das Log der ersten Einträge.
-
Der Status vom Magnetkontakt wird nicht per Callback geliefert sondern nur per Web-Api. So ist zumindest meine Beobachtung.
-
Bitte schön
nuki-extended.0 2020-03-05 21:55:09.193 info (3816) Listening for Nuki events on port 51989. nuki-extended.0 2020-03-05 21:55:09.192 info (3816) Polling Nuki Web API deactivated. nuki-extended.0 2020-03-05 21:55:09.175 debug (3816) Callback (with URL http://xx.xxx.xx.xxx:51989/nuki-api-bridge) already attached to Nuki Bridge with name Bridge. nuki-extended.0 2020-03-05 21:55:09.155 debug (3816) Retrieved current callbacks from Nuki Bridge with name Bridge. nuki-extended.0 2020-03-05 21:55:08.502 debug (3816) system.adapter.admin.0: logging true javascript.0 2020-03-05 21:55:08.485 debug (2192) system.adapter.admin.0: logging true nuki-extended.0 2020-03-05 21:55:07.853 info (3816) starting. Version 2.2.2 in C:/iobroker/GLT/node_modules/iobroker.nuki-extended, node: v10.17.0 nuki-extended.0 2020-03-05 21:55:07.737 debug (3816) statesDB connected nuki-extended.0 2020-03-05 21:55:07.737 debug (3816) States connected to redis: 127.0.0.1:9000 nuki-extended.0 2020-03-05 21:55:07.730 debug (3816) States create System PubSub Client nuki-extended.0 2020-03-05 21:55:07.728 debug (3816) States create User PubSub Client nuki-extended.0 2020-03-05 21:55:07.723 debug (3816) Redis States: Use Redis connection: 127.0.0.1:9000 nuki-extended.0 2020-03-05 21:55:07.722 debug (3816) objectDB connected nuki-extended.0 2020-03-05 21:55:07.718 debug (3816) Objects connected to redis: 127.0.0.1:9001 nuki-extended.0 2020-03-05 21:55:07.706 debug (3816) Objects client initialize lua scripts nuki-extended.0 2020-03-05 21:55:07.705 debug (3816) Objects create User PubSub Client nuki-extended.0 2020-03-05 21:55:07.705 debug (3816) Objects create System PubSub Client nuki-extended.0 2020-03-05 21:55:07.702 debug (3816) Objects client ready ... initialize now nuki-extended.0 2020-03-05 21:55:07.678 debug (3816) Redis Objects: Use Redis connection: 127.0.0.1:9001 -
@JB_Sullivan sieht alles gut aus im Log. Also Änderungen am Schloss sollten zeitnah bei dir eingehen. Was steht denn im Log, wenn du das Schloss (nicht die Tür) ver- oder aufschließt?
@cash sagte in Test Adapter Nuki-extended v2.0.x:
Der Status vom Magnetkontakt wird nicht per Callback geliefert sondern nur per Web-Api. So ist zumindest meine Beobachtung.
Jo, das ist richtig.
-
So, hier jetzt das LOG während eines normalen Schließvorgang.
nuki-extended.0 2020-03-06 15:57:05.712 debug (7852) Updating device smartlocks.XYZXYZXYZ with payload: {"smartlockId":XYZXYZXYZ,"accountId":XYZXYZXYZ,"authId":XYZXYZXYZ,"name":"XYZXYZXYZ","favorite":true,"config":{"name":"XYZXYZXYZ","latitude":XYZXYZXYZ nuki-extended.0 2020-03-06 15:57:05.711 debug (7852) getWebApi(): [{"smartlockId":XYZXYZXYZ,"accountId":XYZXYZXYZ,"type":0,"authId":XYZXYZXYZ,"name":"XYZXYZXYZ","favorite":true,"config":{"name":"XYZXYZXYZ","latitude":XYZXYZXYZ,"longitude":XYZXYZXYZ,"a nuki-extended.0 2020-03-06 15:57:05.629 debug (7852) Updating device smartlocks.XYZXYZXYZ with payload: {"nukiId":XYZXYZXYZ,"state":{"deviceType":0,"mode":2,"state":3,"batteryCritical":false,"timestamp":"2020-03-06T14:57:05+00:00","locked":3},"nuk nuki-extended.0 2020-03-06 15:57:05.628 debug (7852) Received payload via callback: {"nukiId":XYZXYZXYZ,"state":{"deviceType":0,"mode":2,"state":3,"stateName":"unlocked","batteryCritical":false,"timestamp":"2020-03-06T14:57:05+00:00"}} nuki-extended.0 2020-03-06 15:56:52.396 debug (7852) Updating device smartlocks.XYZXYZXYZ with payload: {"smartlockId":XYZXYZXYZ,"accountId":XYZXYZXYZ,"authId":XYZXYZXYZ,"name":"XYZXYZXYZ","favorite":true,"config":{"name":"XYZXYZXYZ","latitude":XYZXYZXYZ nuki-extended.0 2020-03-06 15:56:52.396 debug (7852) getWebApi(): [{"smartlockId":XYZXYZXYZ,"accountId":XYZXYZXYZ,"type":0,"authId":XYZXYZXYZ,"name":"XYZXYZXYZ","favorite":true,"config":{"name":"XYZXYZXYZ","latitude":XYZXYZXYZ,"longitude":XYZXYZXYZ,"a nuki-extended.0 2020-03-06 15:56:52.276 debug (7852) Updating device smartlocks.XYZXYZXYZ with payload: {"nukiId":XYZXYZXYZ,"state":{"deviceType":0,"mode":2,"state":3,"batteryCritical":false,"timestamp":"2020-03-06T14:56:52+00:00","locked":3},"nuk nuki-extended.0 2020-03-06 15:56:52.276 debug (7852) Received payload via callback: {"nukiId":XYZXYZXYZ,"state":{"deviceType":0,"mode":2,"state":3,"stateName":"unlocked","batteryCritical":false,"timestamp":"2020-03-06T14:56:52+00:00"}} nuki-extended.0 2020-03-06 15:56:46.909 info (7852) Successfully triggered action -UNLATCH- on Nuki Smartlock XYZXYZXYZ (via Bridge API). nuki-extended.0 2020-03-06 15:56:39.121 debug (7852) State of nuki-extended.0.smartlocks.XYZXYZXYZ._ACTION.UNLATCH has changed {"val":0,"ack":true,"ts":1583506599116,"q":0,"from":"system.adapter.nuki-extended.0","user":"system.user.admin","lc":158 nuki-extended.0 2020-03-06 15:56:39.116 debug (7852) Action applied on Bridge API. nuki-extended.0 2020-03-06 15:56:39.116 info (7852) Trigger action -UNLATCH- on Nuki Smartlock XYZXYZXYZ (via Bridge API). nuki-extended.0 2020-03-06 15:56:39.115 debug (7852) State of nuki-extended.0.smartlocks.XYZXYZXYZ._ACTION.UNLATCH has changed {"val":true,"ack":false,"ts":1583506599105,"q":0,"from":"system.adapter.web.0","user":"system.user.admin","lc":158350659 -
@JB_Sullivan dann funktioniert der Adapter bei dir korrekt.
Wie cash schon schrieb: Der Magnetkontakt wird leider nicht durch den Callback aktualisiert, sondern durch die Web API.
-
Moin zusammen,
Ich habe nun folgendes Problem,
wenn ich per Skript die Klingel abstellen möchte, stellt dieses den Wert der doorbellSupression auf 7, allerdings springt dieser nach sehr kurzer Zeit wieder um auf 0(Never).In der App ändert sich nichts, hier ist der Wert 3 eingestellt.
Gleiches mit anderen werten und wenn ich diese manuell umstelle.Weiß jemand woran das liegen könnte?
Gruß Peter -
OK - Danke erstmal für die Antwort.
Eine Frage habe ich dann noch - der Aufruf der "NUKI-Kachel" aus ioB Admin - hast DU diese Seite erstellt, oder ist das etwas was das Schloss bzw. die Bridge als Webinterface integriert hat?
Ich frage deshalb, weil die Aktualisierung stark hinter den realen Schließungen hinterher hinkt. Wie du auf dem Screenshot siehst, war die letzte Aktion um 00:12 Uhr. Seitdem sind im App Protokoll vier neue Aktionen hinzu gekommen, die aber (noch) nicht in der - ich nenne es mal Webinterface Liste - auftauchen.
Vielleicht kannst du auch hier noch etwas zum Thema json Tabellen beitragen, denn die dort von mir genannten Beispiele beziehen sich vornehmlich auf Tabellen deiner Adapter (roomba & Nuki). In anderen Adaptern wie z.B. dem BackItUp und dem mihome-vaccum kommen diese json Tabellen quasi Mundgerecht im DP an.
Ich weiß ich sollte bei GIT einen feature request aufmachen, aber irgendwie bekomme ich das nicht gebacken. Hier der Link zu dem Forums Beitrag den ich meine.
https://forum.iobroker.net/topic/15965/wie-wird-das-widget-json-table-eingestellt-formatiert/31
..... und dann schiebe ich gleich noch eine Frage hinterher:
Kann man bei den Stati evtl. noch einen Datenpunkt einbauen, der dort immer denjenigen User anzeigt der als letztes das Schloss geöffnet hat - meinetwegen auch als Nummer 1,2,3,4, und nicht als Namen?
Dann konnte man diesen Datenpunkt über ein Skript z.B. für einen Alexa Begrüßungstext weiter verarbeiten - nur so eine Idee am Rand. Ich denke die User Identifikation über NUKI ist allemal besser als über Radar2, TR-64 und den neuen fb-checkpresence Adapter.
Entweder man hat das Schoss mit seinem Smartphone oder mit einem FOB gekoppelt und diese entsprechend namentlich definiert. Für die "zuHause" Erkennung könnte man den NUKI Datenpunkt dann zusätzlich, in was für ein Skript auch immer, einbauen.
