NEWS
Test Adapter Nuki-extended v2.0.x
-
@cash lösch den Datenpunkt mal und starte den Adapter neu.
Mapping im Datenpunkt sollte nun wie folgt aussehen:
{ "0":"NEVER", "1":"CONTINUOUS", "2":"RTO", "3":"CONTINUOUS+RTO", "4":"DOORBELL", "5":"CONTINUOUS + DOORBELL", "6":"RTO + DOORBELL", "7":"CONTINUOUS + RTO + DOORBELL" }
-
@JB_Sullivan sagte in Test Adapter Nuki-extended v2.0.x:
IP Bereich liest sich ungewöhnlich aber das ist Absicht - aber es gibt keine Beschränkungen. Kann man denn davon ausgehen das Port 8080 richtig ist?
Ich habe irgendwo was gelesen, das das auth Verfahren nicht über einen Repeater hinweg funktioniert. Kann das die Ursache für "hat die Verbindung abgeleht".Port 8080 ist Standard. Wie sich ein Repeater in diesem Zusammenhang verhält weiß ich nicht. Versuch's halt mal ohne.
-
@Zefau Perfekt. Jetzt funktioniert es... Vielen Dank.
-
So, jetzt habe ich es hin bekommen
- hier ein paar ergänzende Informationen für jemanden der so wie ich, ebenfalls erst später zu NUKI dazu gestoßen ist.
Der Aufruf für die Bridge API
http://<ip>:<port>/auth
ist eigentlich nicht mehr notwendig, weil in der Android App ( Version 2.6.5) , wie ich finde sehr versteckt, der Token unter den Bridge Daten bei den Entwickleroptionen angegeben ist. Das blöde ist, das man das in der Regel nicht mehr zu Gesicht bekommt, wenn man die Bridge bereits eingerichtet hatte.
Man muss die Bridge erneut pairen. War das Erfolgreich, bekommt man ein lustiges Bildchen wo der Verbindungsausfbau dargestellt ist.
SERVER <---> Bridge <---> Schloss
Klickt man hier auf Bridge, bekommt man folgendes Bildchen zu sehen. Hier müssen bei den Entwickleroptionen die beiden Schieberegler aktiviert sein.
........ und schon sieht man die Bridge API
Man kann aber auch den alten Weg gehen, jedoch ist es dann SUPER WICHTIG, das weder die APP, noch die Webseite (https://web.nuki.io/) geöffnet sein darf !!!
-
...... und jetzt bräuchte ich Bitte, zur Inspiration, ein paar VIS Bilder was man mit dem Adapter alles so machen/darstellen/anzeigen lassen kann (Screenshots reichen erstmal ; ) )
-
@Zefau Habe noch einige komische Verhalten festgestellt. Ich habe wie gestern schon erwähnt ein Script geschrieben was mir die doorbellSuppression bei abwesend auf alle unterdrückt stellt und sobald jemand nach Hause kommt wird es wieder zurück gestellt. Das funktioniert jetzt perfekt. Aber als ich nach Hause kam wurde durch die Nuki App durch Geofencing entsprechtend Ring to Open aktiviert. Als ich klingelte öffnete auch die Tür aber der Summer wurde sehr lange betätigt. Also nach geschaut in der App und dort stand auf einmal 3 Sekunden (der Standard-Wert). Eigentlich hatte ich immer 1 Sekunde drin (Diesen Datenpunkt habe ich in den Objekten leider nicht gefunden). Als ich danach mit dem Hund raus wollte habe ich wie üblich per Doppelklick auf den Opener den Continuou-Modus aktiviert. Leider kam keine Bestätigung. Also Kontrolle in der App und auch hier war auf einmal „keine Aktion“ bei Doppelklick aktiviert. Also wieder geändert und der Doppelklick funktionierte wieder.
Jetzt bin ich wieder zu Hause und sehe in den Objekten bei DoubleButtonPressAction das dort keine Funktion steht. In der App war aber noch Continuous für Doppelklick aktiviert. Also einfach mal in den Objekten eingetragen. Im Log sehe ich auch das er was gemacht hat. In der App steht nun auch weiterhin das richtige Wert aber dabei hat er mir wieder die Aktivierung vom Summer auf 3 Sekunden erhöht.
Kann es sein das mit jeder Änderung per ioBroker die gesamte Konfig übertragen wird? Und kann es sein das dies nur eine Einbahnstraße ist? Als letztes besteht die Möglichkeit den Datenpunkt für die Summer-Dauer noch hinzuzufügen?
Nachtrag das Feld gibt es und heißt electricstrikeDuration. Es steht im Adapter auf 3000 in der App auf 1 Sekunde. Ich werde den Wert mal auf 1000 anpassen.
-
@cash danke dir für's Testen. Es wird in der Tat die gesamte Konfiguration übertragen, weil sonst gar nichts geändert wird.
Ich werde das gerade nochmal testen, ob es auch anders geht.
-
@Zefau Das alles übertragen wird ist ja nicht weiter schlimm. Insgesamt habe ich den Eindruck das es auf jeden Fall sehr zuverlässig die Befehle überträgt. Blöd wäre halt nur wenn keine richtige Syncronisation stattfindet. IoBroker sollte schon die Änderungen die man per App macht mitbekommen.
Auch wenn ich eigentlich nie oder äußerst selten etwas ändere. Die normalen Sachen bekommt der Adapter auf jeden Fall mit und ich kann sie zuverlässig als Trigger nutzen. Wenn auch manchmal mit etwas delay. -
@cash die Aktualisierungsrate kannst du in der Adapter-Konfiguration unter
Konfiguration Web Nuki
(sollte eigl. Nuki Web heißen) einstellen. -
@cash hab's nochmal geprüft und durchprobiert. Ich muss die gesamte Config mitsenden, da sonst nicht vorhandene Einträge zurückgesetzt werden (also im Prinzip das Verhalten, was du beschreibst).
Auf welche Frequenz hast du das Aktualisierungsintervall eingestellt?
Ich hab sonst nochmal hinzugefügt, dass nach der Änderung der Config im ioBroker die gesamte Config aktualisiert wird. Kannst dir das Update gerne von Github ziehen.
-
@Zefau Intervall habe ich auf Standard. Wenn ich mich nicht täusche 60 Selunden wobei im Log beim Adapterstart daraus 63 Sekunden werden. Werde die Version von github installieren und weiter testen. Melde mich wenn mir etwas auffällt.
-
@Zefau Erster Test.
Ich kann eigentlich keine Änderung feststellen. Ändere ich einen Wert per Nuki App wird diese Änderung nicht in ioBroker angezeigt (5 Minuten gewartet). Ändere ich danach einen anderen Wert in ioBroker. Wird dieser Wert anschließend in der Nuki-App auch angezeigt. Und da alles übertragen wird, wird logischerweise auch die erste Änderung die ich in der Nuki App vorgenommen habe wieder mit den alten Wert überschrieben.
Der Adapter bekommt die Änderungen div. Datenpunkte von Nuki nicht mit. Andere Änderungen wie z. B. das aktivieren des Continuous-Mode bekommt der Adapter dagegen mit.
-
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.webApiLast
zeigt an, wann zuletzt aktualisiert wurde (undnuki-extended.0.info.webApiSync
, ob überhaupt aktualisiert wird).