NEWS
Test Adapter Nuki-extended v2.0.x
-
@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":158350659ioBroker auf Intel Core i3-5005U NUC und Windwos10 Pro
-
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.
ioBroker auf Intel Core i3-5005U NUC und Windwos10 Pro
-
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.
@JB_Sullivan sagte in Test Adapter Nuki-extended v2.0.x:
hast DU diese Seite erstellt, oder ist das etwas was das Schloss bzw. die Bridge als Webinterface integriert hat?
Ist von mir erstellt.
@JB_Sullivan sagte in Test Adapter Nuki-extended v2.0.x:
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.
Zieht er sich aus dem Datenpunkt
.logs.
@JB_Sullivan sagte in Test Adapter Nuki-extended v2.0.x:
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 nutze kein vis, daher habe ich so eine "json Tabelle" nicht erstellt.
@JB_Sullivan sagte in Test Adapter Nuki-extended v2.0.x:
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?
Hätte ich auch sehr gerne, wird aber leider nicht über den Callback mitgeliefert
Meine Adapter: https://zefau.github.io/iobroker/
-
@JB_Sullivan sagte in Test Adapter Nuki-extended v2.0.x:
hast DU diese Seite erstellt, oder ist das etwas was das Schloss bzw. die Bridge als Webinterface integriert hat?
Ist von mir erstellt.
@JB_Sullivan sagte in Test Adapter Nuki-extended v2.0.x:
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.
Zieht er sich aus dem Datenpunkt
.logs.
@JB_Sullivan sagte in Test Adapter Nuki-extended v2.0.x:
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 nutze kein vis, daher habe ich so eine "json Tabelle" nicht erstellt.
@JB_Sullivan sagte in Test Adapter Nuki-extended v2.0.x:
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?
Hätte ich auch sehr gerne, wird aber leider nicht über den Callback mitgeliefert
@Zefau sagte in Test Adapter Nuki-extended v2.0.x:
@JB_Sullivan sagte in Test Adapter Nuki-extended v2.0.x:
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?
Hätte ich auch sehr gerne, wird aber leider nicht über den Callback mitgeliefert
Hast du bei NUKI deveolpers schonmal nachgefragt, ob die planen so etwas ggf. nachzurüsten, ober ob es vielleicht sogar schon Aussagen zu dem Thema gibt?
Wenn nicht würde ich dort mal eine Anfrage stellen, ob so ein Datenpunkt nicht machbar ist. Damit ich keinen Blödsinn dort schreibe, über was müsste der Datenpunkt "rein" kommen - web-API oder Bridge-Http API?
ioBroker auf Intel Core i3-5005U NUC und Windwos10 Pro
-
@Zefau sagte in Test Adapter Nuki-extended v2.0.x:
@JB_Sullivan sagte in Test Adapter Nuki-extended v2.0.x:
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?
Hätte ich auch sehr gerne, wird aber leider nicht über den Callback mitgeliefert
Hast du bei NUKI deveolpers schonmal nachgefragt, ob die planen so etwas ggf. nachzurüsten, ober ob es vielleicht sogar schon Aussagen zu dem Thema gibt?
Wenn nicht würde ich dort mal eine Anfrage stellen, ob so ein Datenpunkt nicht machbar ist. Damit ich keinen Blödsinn dort schreibe, über was müsste der Datenpunkt "rein" kommen - web-API oder Bridge-Http API?
@JB_Sullivan Such doch dort im Forum mal. Da es gibt es nämlich schon eine Anforderung, die wenn ich mich nicht irre auch sehr viel Zuspruch hat. Und wenn Du auch noch abstimmst schadet es definitiv nicht
Hier die Anforderung:
-
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@Newpicsel Welche Version hast Du? Mit der aktuellen von github funktioniert es bei mir fast perfekt. Damit meine ich das ich alles per ioBroker ändern kann. Nur der Adapter bekommt die Änderungen die per App gemacht werden nicht mit. Deshalb ist es wichtig die Datenpunkte abzugleichen damit wenn Du z. B. Die Klingelunterdrückung aktivierst nicht aus versehen andere Sachen verstellst...
-
@Newpicsel Welche Version hast Du? Mit der aktuellen von github funktioniert es bei mir fast perfekt. Damit meine ich das ich alles per ioBroker ändern kann. Nur der Adapter bekommt die Änderungen die per App gemacht werden nicht mit. Deshalb ist es wichtig die Datenpunkte abzugleichen damit wenn Du z. B. Die Klingelunterdrückung aktivierst nicht aus versehen andere Sachen verstellst...
@cash ich hab die version 2.2.2 direkt über iob aktualisiert, GitHub hab ich grad gesehen wäre die 2.2.3 verfügbar! werde ich nachher mal testen.
Edit:
V 2.2.3 getestet, problem besteht weiterhin.
Zur sicherheit habe ich den kompletten nuki-extended ordner gelöscht und den adapter neu gestartet.
Habe mal andere einstellungen wie sounds getestet, hier gleiches problem, liegt also nicht nur an der klingelunterdrückung.
Ebenfalls steht der soundlevel bei mir auf -128, hier wird mir auch eine warnung im log ausgegeben:StatusCodeError: 400 - {"detailMessage":"The supplied value '-128' for parameter 'soundLevel' is not valid","stackTrace":[],"suppressedExceptions":[]}Dieser wert stellt sich auch automatisch wieder auf -128 wenn ich ihn änder.
Keine ahnung was ich übersehe, log ist sonst in ordnung würde ich sagen!nuki-extended.0 2020-03-07 12:32:11.138 debug (16308) Updating device smartlocks.wohnungstür with payload: {"smartlockId":487399285,"accountId":xxxxxxxx1,"authId":xxxxxx8,"name":"Haustür","favorite":false,"config":{"name":"Wohnungstür","latitude nuki-extended.0 2020-03-07 12:32:11.108 debug (16308) Updating device openers.eingangstür with payload: {"smartlockId":9075702938,"accountId":xxxxxxxx1,"authId":xxxxxx8,"name":"Opener","favorite":false,"config":{"name":"Opener","latitude":xx.404 nuki-extended.0 2020-03-07 12:32:11.106 debug (16308) getWebApi(): [{"smartlockId":9075702938,"accountId":xxxxxxxx1,"type":2,"authId":xxxxxxx8,"name":"Opener","favorite":false,"config":{"name":"Opener","latitude":xx.404556,"longitude":xx.048951," nuki-extended.0 2020-03-07 12:32:06.047 debug (16308) State of nuki-extended.0.openers.eingangstür.openerAdvancedConfig.soundLevel has changed {"val":-128,"ack":true,"ts":1583580725929,"q":0,"from":"system.adapter.nuki-extended.0","user":"system nuki-extended.0 2020-03-07 12:32:05.950 debug (16308) Updating device smartlocks.wohnungstür with payload: {"smartlockId":487399285,"accountId":xxxxxxxx1,"authId":xxxxxx8,"name":"Haustür","favorite":false,"config":{"name":"Wohnungstür","latitude nuki-extended.0 2020-03-07 12:32:05.910 debug (16308) Updating device openers.eingangstür with payload: {"smartlockId":9075702938,"accountId":xxxxxxxx1,"authId":xxxxxx8,"name":"Opener","favorite":false,"config":{"name":"Opener","latitude":53.404 nuki-extended.0 2020-03-07 12:32:05.909 debug (16308) getWebApi(): [{"smartlockId":9075702938,"accountId":xxxxxxxx1,"type":2,"authId":xxxxxx8,"name":"Opener","favorite":false,"config":{"name":"Opener","latitude":xx.404556,"longitude":xx.048951," nuki-extended.0 2020-03-07 12:32:05.737 info (16308) Listening for Nuki events on port 51989. nuki-extended.0 2020-03-07 12:32:05.736 info (16308) Polling Nuki Web API with a frequency of 5s. nuki-extended.0 2020-03-07 12:32:05.707 debug (16308) Callback (with URL http://xxx.xxx.xxx.62:51989/nuki-api-bridge) already attached to Nuki Bridge with name NukiBridge. nuki-extended.0 2020-03-07 12:32:05.705 debug (16308) Retrieved current callbacks from Nuki Bridge with name NukiBridge. nuki-extended.0 2020-03-07 12:32:04.893 debug (16308) Updating device smartlocks.wohnungstür with payload: {"deviceType":0,"nukiId":487399285,"name":"Wohnungstür","firmwareVersion":"2.6.6","bridge":"1883159507","state":{"mode":2,"state":3,"batte nuki-extended.0 2020-03-07 12:32:04.883 debug (16308) Updating device openers.eingangstür with payload: {"deviceType":2,"nukiId":485768346,"name":"Eingangstür","firmwareVersion":"1.3.1","bridge":"1883159507","state":{"mode":2,"state":1,"batteryC nuki-extended.0 2020-03-07 12:32:04.878 debug (16308) getBridgeApi() [forcePlainToken: true]: [{"deviceType":2,"nukiId":485768346,"name":"Eingangstür","firmwareVersion":"1.3.1","lastKnownState":{"mode":2,"state":1,"stateName":"online","batteryCr nuki-extended.0 2020-03-07 12:32:04.451 info (16308) starting. Version 2.2.3 in /opt/iobroker/node_modules/iobroker.nuki-extended, node: v10.17.0 nuki-extended.0 2020-03-07 12:32:03.553 debug (16308) statesDB connected nuki-extended.0 2020-03-07 12:32:03.552 debug (16308) States connected to redis: 127.0.0.1:9000 nuki-extended.0 2020-03-07 12:32:03.541 debug (16308) States create System PubSub Client nuki-extended.0 2020-03-07 12:32:03.538 debug (16308) States create User PubSub Client nuki-extended.0 2020-03-07 12:32:03.531 debug (16308) Redis States: Use Redis connection: 127.0.0.1:9000 nuki-extended.0 2020-03-07 12:32:03.528 debug (16308) objectDB connected nuki-extended.0 2020-03-07 12:32:03.522 debug (16308) Objects connected to redis: 127.0.0.1:9001 nuki-extended.0 2020-03-07 12:32:03.506 debug (16308) Objects client initialize lua scripts nuki-extended.0 2020-03-07 12:32:03.505 debug (16308) Objects create User PubSub Client nuki-extended.0 2020-03-07 12:32:03.504 debug (16308) Objects create System PubSub Client nuki-extended.0 2020-03-07 12:32:03.499 debug (16308) Objects client ready ... initialize now nuki-extended.0 2020-03-07 12:32:03.464 debug (16308) Redis Objects: Use Redis connection: 127.0.0.1:9001 -
Ich habe mal ein / zwei Frage zum Adapter.
- wer sortiert die Aktionen die am Schloss ausgeführt werden - das Schloss selber oder ioB Adapter?
Hintergrund der Frage ist die Sortierreihenfolge der Aktionen die offensichtlich falsch ist.
Hier sieht man sehr deutlich, das laut Liste die Tür geöffnet wurde, bevor überhaupt durch das Ipad der Befehl zum öffnen kam.
Korrekter Weise müsste es heißen1.) Tür von Ipad geöffnet
2.) Tür manuell geöffnet
3.) Tür manuell geschlossenSo wäre die Reihenfolge korrekt.
Die nächste Frage betrifft die Datenpunkte:
Warum wird mir für Door state & closed - jeweils ein Wert angezeigt der nicht mit der App überein stimmt. Die Datenpunkte sind frisch aktualisiert und der Zeitstempel ist Deckungsgleich mit der Zeit am Handy - OK den Screenshot vom Handy habe ich später gemacht, aber es hat in der Zwischenzeit keine Aktion mehr statt gefunden.
Ich habe das NUKI 2.0 mit dem Tür Magneten - vielleicht sollte man bei den Datenpunkten deutlicher herausstellen, welche Aktionen vom Schloss und welche vom Tür Magneten kommen. Irgendwie habe ich da immer meine Schwierigkeiten, weil offensichtlich die Aktualisierung der DP sehr träge erfolgt.
ioBroker auf Intel Core i3-5005U NUC und Windwos10 Pro
-
Ich habe mal ein / zwei Frage zum Adapter.
- wer sortiert die Aktionen die am Schloss ausgeführt werden - das Schloss selber oder ioB Adapter?
Hintergrund der Frage ist die Sortierreihenfolge der Aktionen die offensichtlich falsch ist.
Hier sieht man sehr deutlich, das laut Liste die Tür geöffnet wurde, bevor überhaupt durch das Ipad der Befehl zum öffnen kam.
Korrekter Weise müsste es heißen1.) Tür von Ipad geöffnet
2.) Tür manuell geöffnet
3.) Tür manuell geschlossenSo wäre die Reihenfolge korrekt.
Die nächste Frage betrifft die Datenpunkte:
Warum wird mir für Door state & closed - jeweils ein Wert angezeigt der nicht mit der App überein stimmt. Die Datenpunkte sind frisch aktualisiert und der Zeitstempel ist Deckungsgleich mit der Zeit am Handy - OK den Screenshot vom Handy habe ich später gemacht, aber es hat in der Zwischenzeit keine Aktion mehr statt gefunden.
Ich habe das NUKI 2.0 mit dem Tür Magneten - vielleicht sollte man bei den Datenpunkten deutlicher herausstellen, welche Aktionen vom Schloss und welche vom Tür Magneten kommen. Irgendwie habe ich da immer meine Schwierigkeiten, weil offensichtlich die Aktualisierung der DP sehr träge erfolgt.
@JB_Sullivan sagte in Test Adapter Nuki-extended v2.0.x:
wer sortiert die Aktionen die am Schloss ausgeführt werden - das Schloss selber oder ioB Adapter?
Ist durch Nuki Web vorgegeben, siehe https://web.nuki.io/de/#/admin/logs
Dort sollte das Log identisch zum Adapter sein.
@JB_Sullivan sagte in Test Adapter Nuki-extended v2.0.x:
Warum wird mir für Door state & closed - jeweils ein Wert angezeigt der nicht mit der App überein stimmt. Die Datenpunkte sind frisch aktualisiert und der Zeitstempel ist Deckungsgleich mit der Zeit am Handy - OK den Screenshot vom Handy habe ich später gemacht, aber es hat in der Zwischenzeit keine Aktion mehr statt gefunden.
Liegt daran, dass der Wert von Nuki Web und nicht der Bridge kommt. Die Bridge (und damit der Callback) liefert den Wert nicht. Hier gibt es einen offiziellen Feature Request, siehe https://developer.nuki.io/t/create-callback-for-door-sensor-status-in-bridge-api/1360/4
Meine Adapter: https://zefau.github.io/iobroker/
-
@JB_Sullivan sagte in Test Adapter Nuki-extended v2.0.x:
wer sortiert die Aktionen die am Schloss ausgeführt werden - das Schloss selber oder ioB Adapter?
Ist durch Nuki Web vorgegeben, siehe https://web.nuki.io/de/#/admin/logs
Dort sollte das Log identisch zum Adapter sein.
@JB_Sullivan sagte in Test Adapter Nuki-extended v2.0.x:
Warum wird mir für Door state & closed - jeweils ein Wert angezeigt der nicht mit der App überein stimmt. Die Datenpunkte sind frisch aktualisiert und der Zeitstempel ist Deckungsgleich mit der Zeit am Handy - OK den Screenshot vom Handy habe ich später gemacht, aber es hat in der Zwischenzeit keine Aktion mehr statt gefunden.
Liegt daran, dass der Wert von Nuki Web und nicht der Bridge kommt. Die Bridge (und damit der Callback) liefert den Wert nicht. Hier gibt es einen offiziellen Feature Request, siehe https://developer.nuki.io/t/create-callback-for-door-sensor-status-in-bridge-api/1360/4
@Zefau sagte in Test Adapter Nuki-extended v2.0.x:
Ist durch Nuki Web vorgegeben, siehe https://web.nuki.io/de/#/admin/logs
Dort sollte das Log identisch zum Adapter sein.Ah - OK, ja ist identisch - dann ist das aber von Seiten NUKI von der Logik her schon falsch.
ioBroker auf Intel Core i3-5005U NUC und Windwos10 Pro
-
@Zefau sagte in Test Adapter Nuki-extended v2.0.x:
Ist durch Nuki Web vorgegeben, siehe https://web.nuki.io/de/#/admin/logs
Dort sollte das Log identisch zum Adapter sein.Ah - OK, ja ist identisch - dann ist das aber von Seiten NUKI von der Logik her schon falsch.
-
@JB_Sullivan dann am besten im Developer Forum einen Thread aufmachen.
Habe ich gemacht und auch ziemlich schnell eine, naja sagen wir mal wenig befriedigende Antwort bekommen. Die NUKI Jungs scheinen eine eigene Logik zu verfolgen die für die breite Masse mitunter schwer nachzuvollziehen ist (das Gefühl habe ich wenn die anderen Beiträge dort so lese).
Das ist denen aber weitest gehend egal - Hauptsache sie verfolgen IHR Entwicklungskonzept weiter.
Hier die Antwort
Befehle werden in das Protokoll geschrieben, wenn sie abgeschlossen sind und nicht, wenn sie gestartet werden. Das Öffnen der Tür (vom Türsensor) wurde registriert und abgeschlossen, bevor der Befehl "Tür öffnen" (vom iPad) abgeschlossen wurde, daher ist dies korrekt und kein Fehler.ioBroker auf Intel Core i3-5005U NUC und Windwos10 Pro
-
Habe ich gemacht und auch ziemlich schnell eine, naja sagen wir mal wenig befriedigende Antwort bekommen. Die NUKI Jungs scheinen eine eigene Logik zu verfolgen die für die breite Masse mitunter schwer nachzuvollziehen ist (das Gefühl habe ich wenn die anderen Beiträge dort so lese).
Das ist denen aber weitest gehend egal - Hauptsache sie verfolgen IHR Entwicklungskonzept weiter.
Hier die Antwort
Befehle werden in das Protokoll geschrieben, wenn sie abgeschlossen sind und nicht, wenn sie gestartet werden. Das Öffnen der Tür (vom Türsensor) wurde registriert und abgeschlossen, bevor der Befehl "Tür öffnen" (vom iPad) abgeschlossen wurde, daher ist dies korrekt und kein Fehler.@JB_Sullivan Ich finde die Antwort schon nachvollziehbar und sie sagt ja nun aus das das ipad einfach zu langsam ist
-
@JB_Sullivan Ich finde die Antwort schon nachvollziehbar und sie sagt ja nun aus das das ipad einfach zu langsam ist
@cash
Ich würde nicht sagen, das dass Ipad zu langsam ist, sondern die interne NUKI Kommunikation. Ist mit allen mobilen Endgeräten das gleiche - also nicht Eier-Kram spezifisch.Die Erkennung das ich vor der Tür stehe, wird ja durch die Bluetooth Feldstärke und Geofence bzw. WiFi Feldstärke bestimmt.
Wird die Bedingung als positiv erkannt, wird die Tür geöffnet. Damit ist an dieser Stelle die Aufgabe des Ipad als Befehlsender erledigt.Dann öffne ich die Tür - Also Magnetkontakt AUF - erst jetzt, ist für das Schloss bzw. die Bridge der Befehl "Öffne Tür" beendet und es wird ein Log Eintrag erzeugt. Schließe ich nun die Tür hinter mir, kommt der zweite Log Eintrag.
Da die Tür ja automatisch aufspringt, wird das unterbrechen des Magnetkontakt quasi ebenfalls eigenständig erkannt. Erst dann erfolgt der LOG Eintrag das die Tür Öffnung angefordert wurde.
Entweder die Abhängigkeit ist miteinander verknüpft, oder die Rückmeldung NUKI -> Smartphone bzw. -> Bridge ist dermaßen Grotten langsam das es zu den unlogischen History einträgen kommt.
Für mich als Endanwender ist die "Logik" dahinter schwer nachvollziehbar.
ioBroker auf Intel Core i3-5005U NUC und Windwos10 Pro
-
@cash
Ich würde nicht sagen, das dass Ipad zu langsam ist, sondern die interne NUKI Kommunikation. Ist mit allen mobilen Endgeräten das gleiche - also nicht Eier-Kram spezifisch.Die Erkennung das ich vor der Tür stehe, wird ja durch die Bluetooth Feldstärke und Geofence bzw. WiFi Feldstärke bestimmt.
Wird die Bedingung als positiv erkannt, wird die Tür geöffnet. Damit ist an dieser Stelle die Aufgabe des Ipad als Befehlsender erledigt.Dann öffne ich die Tür - Also Magnetkontakt AUF - erst jetzt, ist für das Schloss bzw. die Bridge der Befehl "Öffne Tür" beendet und es wird ein Log Eintrag erzeugt. Schließe ich nun die Tür hinter mir, kommt der zweite Log Eintrag.
Da die Tür ja automatisch aufspringt, wird das unterbrechen des Magnetkontakt quasi ebenfalls eigenständig erkannt. Erst dann erfolgt der LOG Eintrag das die Tür Öffnung angefordert wurde.
Entweder die Abhängigkeit ist miteinander verknüpft, oder die Rückmeldung NUKI -> Smartphone bzw. -> Bridge ist dermaßen Grotten langsam das es zu den unlogischen History einträgen kommt.
Für mich als Endanwender ist die "Logik" dahinter schwer nachvollziehbar.
@JB_Sullivan ich vermute das ist technisch bedingt: Der Sensor funktioniert über Zigbee und ist in der Reaktion fast synchron. Das Öffnen der Tür funktioniert über den Callback und ist daher leicht zeitversetzt.
Da die Aktionen fehlschlagen können, wird nur ein Erfolg protokolliert. Daher entsteht am Ende ein Bild, welches inkonsistent ist.
Grundsätzlich gebe ich dir recht, dass es schwierig nachvollziehbar ist. Leider ist es nichts, was wir ändern können.
-
Moin zusammen,
Wollte nochmal ein Update zu meinem Problem posten, dieses hat sich „von selbst“ gelöst!
Ich habe nichts weiter unternommen oder geändert, allerdings ist nun die Version 2.2.5 draußen und ich denke, dass hier der Fehler behoben wurde.
Deshalb ein ganz großes danke an Zefau und eventuell beteiligten Personen, sowie an alle die hier fleißig Hilfestellung, Hinweise und Ideen einbringen, ich hab es schon mal irgendwo geschrieben aber kann es nicht oft genug sagen, ich finde es einfach mega und unglaublich was hier mit der Community und iobroker auf die Beine gestellt und umgesetzt wird, einfach nur Hammer!
Ohne euch wäre Smart Home alles andere als Smart!DANKE
-
Ich habe noch einen kleinen Fehler entdeckt - nach der Zeitumstellung.
Ich habe diesen im NUKI Developer Forum gepostet und nachfolgende Antwort bekommen.
Daher vermute ich, das sich dieser Fehler ggf. über etwas Programmierarbeit am Adapter beheben lässt.
Hier der Link zum NUKI DEVELOPER Forum - dann brauche ich nicht alles nochmal erklären.
https://developer.nuki.io/t/history-log-uber-json-zeitumstellung-falsch/5307
ioBroker auf Intel Core i3-5005U NUC und Windwos10 Pro
-
Ich habe noch einen kleinen Fehler entdeckt - nach der Zeitumstellung.
Ich habe diesen im NUKI Developer Forum gepostet und nachfolgende Antwort bekommen.
Daher vermute ich, das sich dieser Fehler ggf. über etwas Programmierarbeit am Adapter beheben lässt.
Hier der Link zum NUKI DEVELOPER Forum - dann brauche ich nicht alles nochmal erklären.
https://developer.nuki.io/t/history-log-uber-json-zeitumstellung-falsch/5307
@JB_Sullivan beziehst du dich auf den State
nuki-extended.0.smartlocks.xxx.logs?Der State wird direkt von der API geschrieben, ohne, dass der Adapter diesen irgendwie bearbeitet. Es handelt sich hier auch um sehr viele Datensätze, weshalb ich diesen gar nicht bearbeiten will, da dies starke Performance-Last erzeugt.
Du musst die Zeitdifferenz in der vis direkt umrechnen.
Support us
130
Online32.4k
Users81.3k
Topics1.3m
Posts