Hallo,
Ich mache mal diesen neuen Thread auf, da der alte schon recht voll ist.
Hier (https://forum.fhem.de/index.php/topic,55756.0.html) könnt ihr im alten Thread stöbern.
Ich habe den Module ein komplettes rewrite gegönnt. Sie folgen nun der neuen Analogie die Module unter lib/ ab zulegen. Desweiteren habe ich versucht sie in "Schön" zu bringen.
In dieser Version ist auch die Unterstützung für das neue SmartLock 3.0 enthalten.Ich werde versuchen in laufe der Zeit die Module auf die aktuelle API Version von Nuki zu bringen. Eine kleine Liste der Features:
- automatisches erkennen der Bridge und aktivieren der API über das Bridge Modul
- automatisches auslesen des API Token und einbinden in FHEM
- aktivieren/deaktivieren der Veröffentlichung der lokalen Bridge IP und Bridge Port unter der Discovery URL
Ihr könnt bereits eine erste Version Testen. Ich würde mich über 2-3 Leute sehr freuen. Ich habe bereits einige Tests erfolgreich absolvieren können.
Wer testen möchte bitte täglich ins Log schauen ob alles sauber gelaufen ist.
Ihr könnt die folgende URL als Update Repo für update hinzufügen.
update add https://git.cooltux.net/FHEM/mod-NUKI/raw/branch/devel/controls_NukiSmart.txtdann macht ihr ein
updateund vor dem neustart löscht ihr bitte alle Reading der NUKIBridge und NUKIDevice Devices in FHEM
deletereading <NUKIBRIDGE> .*
deletereading <NUKIDEVICE> .*danach dann
shutdown restartViel Spaß beim testen
Wer sich für die Entwicklung und/oder deren Fortschritt interessiert kann sich gerne hier umsehen
https://git.cooltux.net/FHEM/mod-NUKI/milestones
Grüße
Moin CoolTux,
habe wie oben beschrieben bei mir eingebaut. Nach update habe ich folgende Meldungen im Log:
l2021.11.27 09:32:44 1: FHEM::Meta::__GetUpdatedata: ERROR: FHEM/73_NUKIBridge.pm belongs to source repository "fhem". Ignoring identical file name from source repository NukiSmart
2021.11.27 09:32:44 1: FHEM::Meta::__GetUpdatedata: ERROR: FHEM/74_NUKIDevice.pm belongs to source repository "fhem". Ignoring identical file name from source repository NukiSmart
Anlegen der NUKIBridge (NUKI der ersten Generation) klappt ohne Probleme und NUKIDevice wird automatisch erzeugt. Ich beobachte weiter.
Gruss
Enno
Zitat von: enno am 27 November 2021, 10:00:39
Moin CoolTux,
habe wie oben beschrieben bei mir eingebaut. Nach update habe ich folgende Meldungen im Log:
l2021.11.27 09:32:44 1: FHEM::Meta::__GetUpdatedata: ERROR: FHEM/73_NUKIBridge.pm belongs to source repository "fhem". Ignoring identical file name from source repository NukiSmart
2021.11.27 09:32:44 1: FHEM::Meta::__GetUpdatedata: ERROR: FHEM/74_NUKIDevice.pm belongs to source repository "fhem". Ignoring identical file name from source repository NukiSmart
Anlegen der NUKIBridge (NUKI der ersten Generation) klappt ohne Probleme und NUKIDevice wird automatisch erzeugt. Ich beobachte weiter.
Gruss
Enno
Das ist nicht weiter schlimm. Wieso das als ERROR ins Meta von Julian eingebaut wurde verstehe ich ehrlich gesagt nicht. Das verschwindet wieder wenn Du das Repo später wieder entfernst. Also alles gut.
Danke Dir fürs testen.
Grüße
Moin,
bei mir funktioniert es auch. Vielen Dank fürs implementieren.
EDIT: Was mir aufgefallen ist, das Schloss ist über die Bridge angebunden, steht aber in FHEM mit dem reading für paired = false drin. Hat sich da was geändert in der API? Meines Wissens sind ja nur die Devicetypes dazugekommen... https://developer.nuki.io/page/nuki-bridge-http-api-1-13/4/
Gibt es schon Aussagen zum Pro bezüglich Batterielaufzeit? Ich habe jetzt natürlich viel mit der API gespielt und einige "unnötige" Schließvorgänge angetriggert, aber aktuell sehe ich da keinen Monat Laufzeit.
Schloss geladen am 22.11 -> 100% stand 27.11 -> 42% Akku. Meldungen im Batteriebericht sind: viele Schließvorgänge und viel Bluetooth-Aktivität.
Mal abwarten, vielleicht brauch es ein zwei Zyklen bis es sich einpendelt.
Wie lange hält das Nuki 2.0 mit FHEM Integration?
Zitat von: the-vince am 27 November 2021, 12:40:53
Moin,
bei mir funktioniert es auch. Vielen Dank fürs implementieren.
EDIT: Was mir aufgefallen ist, das Schloss ist über die Bridge angebunden, steht aber in FHEM mit dem reading für paired = false drin. Hat sich da was geändert in der API? Meines Wissens sind ja nur die Devicetypes dazugekommen... https://developer.nuki.io/page/nuki-bridge-http-api-1-13/4/
Ich muss gestehen das ich gar nicht weiß ob es jemals so war. Da es sich aber um ein Schloss Attribut handelt würde ich sagen es geht da mehr um so Sachen wie den Door Sensor. Denn der wird sicherlich direkt gepeert werden mit dem Schloß.
Ich habe soeben eine Version ins devel Repo gepusht mit welcher das Discovery nun gehen sollte. Auf Grund meiner Umgebung musste ich einiges simulieren. Bilde mir aber ein das ich es hinbekommen habe.
Vielleicht mag ja einer mal testen in einer Testumgebung. Ihr müsst sowohl die Nuki Devices wie auch die Nuki Bridge löschen.
Danach legt Ihr die Bridge ohne Host und Token an, also:
define myNukiBridge NUKIBridge
Und dann heißt es warten und genau den state beobachten und durchlesen. Wenn ein ganz langer Text da erscheint müsst Ihr zur Bridge gehen und einmal kurz auf den Knopf drücken.
Grüße
Marko
define myNukiBridge NUKIBridge und dann schnell genug an der Bridge den Button drücken wenn sie blinkt. Beim ersten Versuch war ich zu langsam. Dann klappt es. Im reading "paired" steht jetzt true.
Frage zum Webhook: Denn gebe ich im Attribut weiterin manuell ein, oder findet er das auch sebst?
Gruss
Enno
Zitat von: enno am 27 November 2021, 19:58:27
define myNukiBridge NUKIBridge und dann schnell genug an der Bridge den Button drücken wenn sie blinkt. Beim ersten Versuch war ich zu langsam. Dann klappt es. Im reading "paired" steht jetzt true.
Frage zum Webhook: Denn gebe ich im Attribut weiterin manuell ein, oder findet er das auch sebst?
Gruss
Enno
Der muss weiterhin manuell vergeben werden. Das Modul kann nicht wissen welche FHEMWEB Instanz Du nehmen möchtest.
Freut mich das es funktioniert. Das mit dem paired ist seltsam.
Ich habe heute durch Zufall eine neue Türgegensprechanlage bekommen, welche Nuki Opener kompatibel ist. Der Opener kommt am Freitag. Ich werde also nächste Woche berichten können wie gut das ganze dann so läuft.
Hi,
Hab Dein Modul heute mit dem Schloss 3.0 erweitert, vorher hatte ich nur einen Opener.
Bisher funktioniert alles super, hatte nur vergessen, die Bridge und das Schloss zu verbinden, da ich im fhem schon das Schloss angezeigt bekommen hatte, konnte es dann nur nicht steuern ;-)
Hallo Marko,
wird das Modul in Verbindung mit Nuki 2 nicht mehr optimiert?
Bei mir, wie bei einigen Anderen hier, besteht das Problem dass das Schloss seinen Zustand im FHEM nur dann ändert, wenn man es über FHEM bedient.
Bedient man das Schloss über die App, oder wird es durch Auto-open bedient, so bekommt das FHEM nichts davon mit.
Ich wär für eine Optimierung wirklich dankbar und würde mich auch für Betatests anbieten.
Danke und Gruß
Alex
Zitat von: Nighthawk am 04 Dezember 2021, 20:57:18
Hallo Marko,
wird das Modul in Verbindung mit Nuki 2 nicht mehr optimiert?
Bei mir, wie bei einigen Anderen hier, besteht das Problem dass das Schloss seinen Zustand im FHEM nur dann ändert, wenn man es über FHEM bedient.
Bedient man das Schloss über die App, oder wird es durch Auto-open bedient, so bekommt das FHEM nichts davon mit.
Ich wär für eine Optimierung wirklich dankbar und würde mich auch für Betatests anbieten.
Danke und Gruß
Alex
Hallo Alex,
Da muss eigentlich nichts optimiert werden meines Wissens nach. Selbst mein 1er lief noch bis vor ein paar Tagen ohne Probleme. Wenn Du die aktuelle SVN Version hast müsste eigentlich schon im Logfile bei ein Eintrag sein wie
2021.12.01 07:34:46 3: NUKIBridge WEBHOOK (NukiBridge) - Received webhook for matching NukiId at device NukiBridge
Bedeutet das der Callback sauber funktioniert. Tut er das bei Euch nicht dann macht mal ein list callback und löscht alle dort enthaltenen Callbacks über die Callback id. Danach Callback mittels Attribut neu anlegen lassen. Dazu einfach noch mal auf attr webhookFWinstance klicken im Webinterface.
Grüße
Moin CoolTux,
ich habe nach eine update all und einem restart jetzt ein Bug gefunden. Denke ich.
Das Smartlock3pro erhält jetzt immer im Wechsel das korrekte Reading (smartlock3) und dann das alte Reading (smartlock), inklusive falscher Name als Reading.
Der log sieht ein bisschen so aus als wäre ständig das auto discovery am werk.
Entsprechend lassen sich keine Befehle mehr ausführen. Ein Verbose 5 liefert einen Haufen:
2021.12.05 10:37:07 5: NUKIBridge (NukiBridge) - 2 == 2 and 2 > 0
sowie:
2021.12.05 10:37:07 5: NUKIBridge (NukiBridge) - return msg: {"deviceType": 4, "nukiId": XXX, "name": "Home", "firmwareVersion": "3.0.40", "lastKnownState": {"mode": 2, "state": 3, "stateName": "unlocked", "batteryCritical": false, "batteryCharging": false, "batteryChargeState": 62, "timestamp": "2021-12-05T08:40:45+00:00"}} and tail: ]
2021.12.05 10:37:07 5: NUKIBridge (NukiBridge) - Nach Sub: Laenge JSON: 272 Content: {"deviceType": 4, "nukiId": XXX, "name": "Home", "firmwareVersion": "3.0.40", "lastKnownState": {"mode": 2, "state": 3, "stateName": "unlocked", "batteryCritical": false, "batteryCharging": false, "batteryChargeState": 62, "timestamp": "2021-12-05T08:40:45+00:00"}} Tail: ]
2021.12.05 10:37:07 5: NUKIBridge (NukiBridge) - Decoding JSON message. Length: 272 Content: {"deviceType": 4, "nukiId": xxx, "name": "Home", "firmwareVersion": "3.0.40", "lastKnownState": {"mode": 2, "state": 3, "stateName": "unlocked", "batteryCritical": false, "batteryCharging": false, "batteryChargeState": 62, "timestamp": "2021-12-05T08:40:45+00:00"}}
2021.12.05 10:37:07 5: NUKIBridge (NukiBridge) - Vor Sub: Laenge JSON: 272 Content: {"deviceType": 4, "nukiId": xxx, "name": "Home", "firmwareVersion": "3.0.40", "lastKnownState": {"mode": 2, "state": 3, "stateName": "unlocked", "batteryCritical": false, "batteryCharging": false, "batteryChargeState": 62, "timestamp": "2021-12-05T08:40:45+00:00"}} Tail: ]
2021.12.05 10:37:07 5: NukiBridge: dispatch {"deviceType": 4, "nukiId": xxx, "name": "Home", "firmwareVersion": "3.0.40", "lastKnownState": {"mode": 2, "state": 3, "stateName": "unlocked", "batteryCritical": false, "batteryCharging": false, "batteryChargeState": 62, "timestamp": "2021-12-05T08:40:45+00:00"}}
2021.12.05 10:37:07 5: NUKIDevice (NukiBridge) - Parse with result: {"deviceType": 4, "nukiId": xxx, "name": "Home", "firmwareVersion": "3.0.40", "lastKnownState": {"mode": 2, "state": 3, "stateName": "unlocked", "batteryCritical": false, "batteryCharging": false, "batteryChargeState": 62, "timestamp": "2021-12-05T08:40:45+00:00"}}
2021.12.05 10:37:07 5: NUKIDevice (Home) - lockAction readings set for Home
2021.12.05 10:37:07 4: NUKIDevice (Home) - find logical device: Home
und dann diese Log Einträge:
2021.12.05 10:36:37 5: NUKIBridge (NukiBridge) - return msg: {"deviceType": 0, "nukiId": xxx, "name": "Nuki_xxx", "rssi": -43, "paired": false} and tail: , {"deviceType": 2, "nukiId": xxx, "name": "Nuki_Opener_xxx", "rssi": -46, "paired": true}]}
2021.12.05 10:36:37 5: NUKIBridge (NukiBridge) - Decoding JSON message. Length: 93 Content: {"deviceType": 0, "nukiId": xxx, "name": "Nuki_xxx", "rssi": -43, "paired": false}
2021.12.05 10:36:37 5: NUKIBridge (NukiBridge) - Vor Sub: Laenge JSON: 93 Content: {"deviceType": 0, "nukiId": xxx, "name": "Nuki_xxx", "rssi": -43, "paired": false} Tail: , {"deviceType": 2, "nukiId": xxx, "name": "Nuki_Opener_xxx", "rssi": -46, "paired": true}]}
2021.12.05 10:36:37 5: NukiBridge: dispatch {"deviceType": 0, "nukiId": xxx, "name": "Nuki_xxx", "rssi": -43, "paired": false}
2021.12.05 10:36:37 5: NUKIDevice (NukiBridge) - Parse with result: {"deviceType": 0, "nukiId": xxx, "name": "Nuki_xxx", "rssi": -43, "paired": false}
2021.12.05 10:36:37 5: NUKIDevice (Home) - lockAction readings set for Home
2021.12.05 10:36:37 4: NUKIDevice (Home) - find logical device: Home
2021.12.05 10:36:37 5: NUKIBridge (NukiBridge) - Garbage character before message: ,
2021.12.05 10:36:37 5: NUKIBridge (NukiBridge) - Garbage character before message:
Sieht also ein bisschen so aus als würde die Bridge ein zweites Gerät mit selber ID bekanntgeben?! Ich weiß mir da aber nicht so richtig zu helfen.
Zitat von: the-vince am 05 Dezember 2021, 10:59:02
Moin CoolTux,
ich habe nach eine update all und einem restart jetzt ein Bug gefunden. Denke ich.
Das Smartlock3pro erhält jetzt immer im Wechsel das korrekte Reading (smartlock3) und dann das alte Reading (smartlock), inklusive falscher Name als Reading.
Der log sieht ein bisschen so aus als wäre ständig das auto discovery am werk.
Entsprechend lassen sich keine Befehle mehr ausführen. Ein Verbose 5 liefert einen Haufen:
2021.12.05 10:37:07 5: NUKIBridge (NukiBridge) - 2 == 2 and 2 > 0
sowie:
2021.12.05 10:37:07 5: NUKIBridge (NukiBridge) - return msg: {"deviceType": 4, "nukiId": XXX, "name": "Home", "firmwareVersion": "3.0.40", "lastKnownState": {"mode": 2, "state": 3, "stateName": "unlocked", "batteryCritical": false, "batteryCharging": false, "batteryChargeState": 62, "timestamp": "2021-12-05T08:40:45+00:00"}} and tail: ]
2021.12.05 10:37:07 5: NUKIBridge (NukiBridge) - Nach Sub: Laenge JSON: 272 Content: {"deviceType": 4, "nukiId": XXX, "name": "Home", "firmwareVersion": "3.0.40", "lastKnownState": {"mode": 2, "state": 3, "stateName": "unlocked", "batteryCritical": false, "batteryCharging": false, "batteryChargeState": 62, "timestamp": "2021-12-05T08:40:45+00:00"}} Tail: ]
2021.12.05 10:37:07 5: NUKIBridge (NukiBridge) - Decoding JSON message. Length: 272 Content: {"deviceType": 4, "nukiId": xxx, "name": "Home", "firmwareVersion": "3.0.40", "lastKnownState": {"mode": 2, "state": 3, "stateName": "unlocked", "batteryCritical": false, "batteryCharging": false, "batteryChargeState": 62, "timestamp": "2021-12-05T08:40:45+00:00"}}
2021.12.05 10:37:07 5: NUKIBridge (NukiBridge) - Vor Sub: Laenge JSON: 272 Content: {"deviceType": 4, "nukiId": xxx, "name": "Home", "firmwareVersion": "3.0.40", "lastKnownState": {"mode": 2, "state": 3, "stateName": "unlocked", "batteryCritical": false, "batteryCharging": false, "batteryChargeState": 62, "timestamp": "2021-12-05T08:40:45+00:00"}} Tail: ]
2021.12.05 10:37:07 5: NukiBridge: dispatch {"deviceType": 4, "nukiId": xxx, "name": "Home", "firmwareVersion": "3.0.40", "lastKnownState": {"mode": 2, "state": 3, "stateName": "unlocked", "batteryCritical": false, "batteryCharging": false, "batteryChargeState": 62, "timestamp": "2021-12-05T08:40:45+00:00"}}
2021.12.05 10:37:07 5: NUKIDevice (NukiBridge) - Parse with result: {"deviceType": 4, "nukiId": xxx, "name": "Home", "firmwareVersion": "3.0.40", "lastKnownState": {"mode": 2, "state": 3, "stateName": "unlocked", "batteryCritical": false, "batteryCharging": false, "batteryChargeState": 62, "timestamp": "2021-12-05T08:40:45+00:00"}}
2021.12.05 10:37:07 5: NUKIDevice (Home) - lockAction readings set for Home
2021.12.05 10:37:07 4: NUKIDevice (Home) - find logical device: Home
und dann diese Log Einträge:
2021.12.05 10:36:37 5: NUKIBridge (NukiBridge) - return msg: {"deviceType": 0, "nukiId": xxx, "name": "Nuki_xxx", "rssi": -43, "paired": false} and tail: , {"deviceType": 2, "nukiId": xxx, "name": "Nuki_Opener_xxx", "rssi": -46, "paired": true}]}
2021.12.05 10:36:37 5: NUKIBridge (NukiBridge) - Decoding JSON message. Length: 93 Content: {"deviceType": 0, "nukiId": xxx, "name": "Nuki_xxx", "rssi": -43, "paired": false}
2021.12.05 10:36:37 5: NUKIBridge (NukiBridge) - Vor Sub: Laenge JSON: 93 Content: {"deviceType": 0, "nukiId": xxx, "name": "Nuki_xxx", "rssi": -43, "paired": false} Tail: , {"deviceType": 2, "nukiId": xxx, "name": "Nuki_Opener_xxx", "rssi": -46, "paired": true}]}
2021.12.05 10:36:37 5: NukiBridge: dispatch {"deviceType": 0, "nukiId": xxx, "name": "Nuki_xxx", "rssi": -43, "paired": false}
2021.12.05 10:36:37 5: NUKIDevice (NukiBridge) - Parse with result: {"deviceType": 0, "nukiId": xxx, "name": "Nuki_xxx", "rssi": -43, "paired": false}
2021.12.05 10:36:37 5: NUKIDevice (Home) - lockAction readings set for Home
2021.12.05 10:36:37 4: NUKIDevice (Home) - find logical device: Home
2021.12.05 10:36:37 5: NUKIBridge (NukiBridge) - Garbage character before message: ,
2021.12.05 10:36:37 5: NUKIBridge (NukiBridge) - Garbage character before message:
Sieht also ein bisschen so aus als würde die Bridge ein zweites Gerät mit selber ID bekanntgeben?! Ich weiß mir da aber nicht so richtig zu helfen.
;D ;D
Du hast da ein Bug gefunden und der ist auch schon gemeldet worden. Allerdings ist das kein Bug im Modul sondern leider in der API der Nuki Bridge.
Es gibt unterschiedliche Ausgaben für die Endpunkte /list und /info bei den Smartlock 3.0 und 3.0 Pro Geräten.
Zitat von: CoolTux am 05 Dezember 2021, 11:19:16
;D ;D
Du hast da ein Bug gefunden und der ist auch schon gemeldet worden. Allerdings ist das kein Bug im Modul sondern leider in der API der Nuki Bridge.
Es gibt unterschiedliche Ausgaben für die Endpunkte /list und /info bei den Smartlock 3.0 und 3.0 Pro Geräten.
Ach ja... Softwaretesting kann der zahlende Endkunde sowieso viel effizienter als die eigenen Entwickler... Entwickler sind auch so teuer. ::)
Zitat von: the-vince am 05 Dezember 2021, 11:43:33
Ach ja... Softwaretesting kann der zahlende Endkunde sowieso viel effizienter als die eigenen Entwickler... Entwickler sind auch so teuer. ::)
Ich habe aber einen Würgarround erstellt. Kommt morgen per Update. Ist auch gleich das Pre-Release von Version 2.
Hallo Marko,
Danke für den Fingerzeig :D
Ein list callback habe ich nicht gefunden, ein get Callbacklist hatte bei mir "none" geliefert.
Nach dem Neudefinieren der webhookFWinstance bekomme ich jetzt tatsächlich den Zusatand des Türsensors, wie auch den Zustand des Schlosses mit (locked, unlocked).
Wird auch ein Event erzeugt wenn man öffnet (also unlatch über die App ausführt)?
Danke und Gruß
Alex
Hallo Alex,
Schön daß es nun geht. Ob es einen Event gibt kann ich gerade nicht sagen. Also generell gibt es einen aber erst als Callback wenn die Tür geöffnet wurde.
Grüße
Ich habe eine Vorabversion von Version 2 ins SVN geladen so das wir mehr "Tester" haben. Kommt nachher um 8 Uhr per update
Das überbügelt dann die normale Version die bisher mit FHEM ausgeliefert wird?
Wenn ja, gibts da was zu beachten nach dem Update, oder sollte das einfach ohne Änderung seitens des Users funktionieren?
Es ist ein normales FHEM Update, also ja es überbügelt die derzeitige Version.
Zu beachten gibt es nichts weiter. Sollte genau so gehen wie bisher.
Hi Zusammen,
ich habe festgestellt, dass das Reading doorsensorStateName nicht mehr aktualisiert wird, dafür das Reading doorsensorState den Text enthält, der vor der neuen Version ein Zahlenwert war. Ich triggerte bisher auf den Zahlenwert, derzeit nicht möglich. Gibt es da eine Möglichkeit die alte Logik zu erhalten?
Gruss
wscheff
Zitat von: Wscheff am 07 Dezember 2021, 17:18:58
Hi Zusammen,
ich habe festgestellt, dass das Reading doorsensorStateName nicht mehr aktualisiert wird, dafür das Reading doorsensorState den Text enthält, der vor der neuen Version ein Zahlenwert war. Ich triggerte bisher auf den Zahlenwert, derzeit nicht möglich. Gibt es da eine Möglichkeit die alte Logik zu erhalten?
Gruss
wscheff
Oh ja sorry, ich habe da ein paar eindeutigere Readings zugeordnet. Aber immer hin wissen wir nun das es noch andere User gibt ;D
Ändere einfach Deinen Trigger und das alte Reading kannst Du löschen.
Zitat von: CoolTux am 07 Dezember 2021, 17:24:49
Oh ja sorry, ich habe da ein paar eindeutigere Readings zugeordnet. Aber immer hin wissen wir nun das es noch andere User gibt ;D
Ändere einfach Deinen Trigger und das alte Reading kannst Du löschen.
also keine Chance die alte Zahlenlogik zu erhalten?
ich trigger mit den Zahlen. da muss ich einige Doifs umschreiben :(
Zitat von: CoolTux am 06 Dezember 2021, 11:25:15
Es ist ein normales FHEM Update, also ja es überbügelt die derzeitige Version.
Zu beachten gibt es nichts weiter. Sollte genau so gehen wie bisher.
Für mich gings leider nicht wie bisher weiter. Ich habe einen Rollback auf die alte Version gemacht und bin bis auf Weiteres beim Testen raus.
Gruss
wscheff
https://git.cooltux.net/FHEM/mod-NUKI/releases
Ich bin dann mal fertig und die aktuelle Version wird morgen früh offiziell per Update kommen.
Zitat von: the-vince am 05 Dezember 2021, 10:59:02
Moin CoolTux,
ich habe nach eine update all und einem restart jetzt ein Bug gefunden. Denke ich.
Das Smartlock3pro erhält jetzt immer im Wechsel das korrekte Reading (smartlock3) und dann das alte Reading (smartlock), inklusive falscher Name als Reading.
Der log sieht ein bisschen so aus als wäre ständig das auto discovery am werk.
Entsprechend lassen sich keine Befehle mehr ausführen. Ein Verbose 5 liefert einen Haufen:
2021.12.05 10:37:07 5: NUKIBridge (NukiBridge) - 2 == 2 and 2 > 0
sowie:
2021.12.05 10:37:07 5: NUKIBridge (NukiBridge) - return msg: {"deviceType": 4, "nukiId": XXX, "name": "Home", "firmwareVersion": "3.0.40", "lastKnownState": {"mode": 2, "state": 3, "stateName": "unlocked", "batteryCritical": false, "batteryCharging": false, "batteryChargeState": 62, "timestamp": "2021-12-05T08:40:45+00:00"}} and tail: ]
2021.12.05 10:37:07 5: NUKIBridge (NukiBridge) - Nach Sub: Laenge JSON: 272 Content: {"deviceType": 4, "nukiId": XXX, "name": "Home", "firmwareVersion": "3.0.40", "lastKnownState": {"mode": 2, "state": 3, "stateName": "unlocked", "batteryCritical": false, "batteryCharging": false, "batteryChargeState": 62, "timestamp": "2021-12-05T08:40:45+00:00"}} Tail: ]
2021.12.05 10:37:07 5: NUKIBridge (NukiBridge) - Decoding JSON message. Length: 272 Content: {"deviceType": 4, "nukiId": xxx, "name": "Home", "firmwareVersion": "3.0.40", "lastKnownState": {"mode": 2, "state": 3, "stateName": "unlocked", "batteryCritical": false, "batteryCharging": false, "batteryChargeState": 62, "timestamp": "2021-12-05T08:40:45+00:00"}}
2021.12.05 10:37:07 5: NUKIBridge (NukiBridge) - Vor Sub: Laenge JSON: 272 Content: {"deviceType": 4, "nukiId": xxx, "name": "Home", "firmwareVersion": "3.0.40", "lastKnownState": {"mode": 2, "state": 3, "stateName": "unlocked", "batteryCritical": false, "batteryCharging": false, "batteryChargeState": 62, "timestamp": "2021-12-05T08:40:45+00:00"}} Tail: ]
2021.12.05 10:37:07 5: NukiBridge: dispatch {"deviceType": 4, "nukiId": xxx, "name": "Home", "firmwareVersion": "3.0.40", "lastKnownState": {"mode": 2, "state": 3, "stateName": "unlocked", "batteryCritical": false, "batteryCharging": false, "batteryChargeState": 62, "timestamp": "2021-12-05T08:40:45+00:00"}}
2021.12.05 10:37:07 5: NUKIDevice (NukiBridge) - Parse with result: {"deviceType": 4, "nukiId": xxx, "name": "Home", "firmwareVersion": "3.0.40", "lastKnownState": {"mode": 2, "state": 3, "stateName": "unlocked", "batteryCritical": false, "batteryCharging": false, "batteryChargeState": 62, "timestamp": "2021-12-05T08:40:45+00:00"}}
2021.12.05 10:37:07 5: NUKIDevice (Home) - lockAction readings set for Home
2021.12.05 10:37:07 4: NUKIDevice (Home) - find logical device: Home
und dann diese Log Einträge:
2021.12.05 10:36:37 5: NUKIBridge (NukiBridge) - return msg: {"deviceType": 0, "nukiId": xxx, "name": "Nuki_xxx", "rssi": -43, "paired": false} and tail: , {"deviceType": 2, "nukiId": xxx, "name": "Nuki_Opener_xxx", "rssi": -46, "paired": true}]}
2021.12.05 10:36:37 5: NUKIBridge (NukiBridge) - Decoding JSON message. Length: 93 Content: {"deviceType": 0, "nukiId": xxx, "name": "Nuki_xxx", "rssi": -43, "paired": false}
2021.12.05 10:36:37 5: NUKIBridge (NukiBridge) - Vor Sub: Laenge JSON: 93 Content: {"deviceType": 0, "nukiId": xxx, "name": "Nuki_xxx", "rssi": -43, "paired": false} Tail: , {"deviceType": 2, "nukiId": xxx, "name": "Nuki_Opener_xxx", "rssi": -46, "paired": true}]}
2021.12.05 10:36:37 5: NukiBridge: dispatch {"deviceType": 0, "nukiId": xxx, "name": "Nuki_xxx", "rssi": -43, "paired": false}
2021.12.05 10:36:37 5: NUKIDevice (NukiBridge) - Parse with result: {"deviceType": 0, "nukiId": xxx, "name": "Nuki_xxx", "rssi": -43, "paired": false}
2021.12.05 10:36:37 5: NUKIDevice (Home) - lockAction readings set for Home
2021.12.05 10:36:37 4: NUKIDevice (Home) - find logical device: Home
2021.12.05 10:36:37 5: NUKIBridge (NukiBridge) - Garbage character before message: ,
2021.12.05 10:36:37 5: NUKIBridge (NukiBridge) - Garbage character before message:
Sieht also ein bisschen so aus als würde die Bridge ein zweites Gerät mit selber ID bekanntgeben?! Ich weiß mir da aber nicht so richtig zu helfen.
Ich habe eben Bescheid bekommen das der Fehler in der neuen Bridge Firmware behoben wurde. Die Firmware gibt es wohl seit 2-3 Tagen.
Hi zusammen,
bisher hatte ich nur den Opener und hatte diese Funktion https://forum.fhem.de/index.php/topic,55756.msg1090459.html#msg1090459 (https://forum.fhem.de/index.php/topic,55756.msg1090459.html#msg1090459) eingerichtet und mir ein Foto bei jedem Klingeln schicken lassen.
Jetzt will das mit dem Schloss(3.0) zusammen nicht mehr, entweder bekomme ich gar kein Bild, oder alle Minute eins.
rto ist bei mir immer an. Gibt`s hier eine Änderung, warum das ganze nicht mehr funktionieren will?
Moin,
Ich werde nun aus beiden Threads nicht wirklich schlau.
Ich habe vor, mir das Nuki 3.0 PRO zuzulegen, ich habe keine Bridge, wollte mir diese auch nicht zulegen, sondern nur das Smart Lock. Funktioniert es mit FHEM und dem Modul hier oder braucht man dafür zwangsläufig die Bridge?
Gruß
Zivi
Du brauchst die Bridge.
Zitat von: CoolTux am 11 Januar 2022, 18:52:17
Du brauchst die Bridge.
Alles klar, danke dir!
Gruß
Zivi
Zitat von: CoolTux am 11 Januar 2022, 18:52:17
Du brauchst die Bridge.
Also das 3.0 Pro und die Bridge? Ist das nicht doppelt gemoppelt?
Gruß
Marco
Kommt drauf an was Du machen/haben willst.
Wenn es Dir nur damrum geht über das Internet mittels der Cloud Dein Schloß zu bedienen dann ja. Willst Du die HTTP API verwenden um mittels FHEM das Schloß zu bedienen und andere Nuki Produkte wie den Opener, dann nein.
Hallo,
seit meinem letzten Update hab ich bei jedem Tür öffnen und schließen folgende Einträge im Logfile:
2022.01.15 17:32:49.053 3: NUKIBridge WEBHOOK (NukiBridge) - Received webhook for matching NukiId at IODev NukiBridge
Diese hatte ich vorher nicht. Laut Wiki sollte bei verbose 3 auch nur gesendete Meldungen protokolliert werden.
Zusätzlich hatte ich heute einmalig folgenden Eintrag im Log:
2022.01.15 17:38:19.165 3: NUKIBridge (NukiBridge) - JSON error while request: malformed JSON string, neither tag, array, object, number, string or atom, at character offset 0 (before "HTTP 503 Unavailable") at lib/FHEM/Devices/Nuki/Bridge.pm line 870.
Was hat das zu bedeuten?
Die erste Meldung dient zur Hilfe für den Webhook. Somit kann man sofort sehen ob der Callback funktioniert.
Beim der zweiten Meldung brachte die Bridge eine Meldung in Form eines HTTP Fehlers anstatt eines erwarteten JSON String.
Zitat von: CoolTux am 16 Januar 2022, 04:08:54
Die erste Meldung dient zur Hilfe für den Webhook. Somit kann man sofort sehen ob der Callback funktioniert.
Beim der zweiten Meldung brachte die Bridge eine Meldung in Form eines HTTP Fehlers anstatt eines erwarteten JSON String.
Braucht man diese Meldung zum Webhook denn wirklich bei Verbose 3?
Für mich ist das eher nur ein Hinweis. Während die zweite Meldung ein Error ist, aber auch Verbose 3.
Ich denke es ist evtl kontraproduktiv Hinweise und Fehler im gleichen Log-Level zu haben.
Gerade zum Thema Callback würde so viel im Forum nachgefragt das ich die Meldung extra so angesetzt habe. Für mich als Maintainer sehe ich da eher ein Ansatz weniger schnell Angefragt zu werden.
Zitat von: CoolTux am 17 Januar 2022, 02:00:55
Gerade zum Thema Callback würde so viel im Forum nachgefragt das ich die Meldung extra so angesetzt habe. Für mich als Maintainer sehe ich da eher ein Ansatz weniger schnell Angefragt zu werden.
Mich hat es erstmal verwirrt, als plötzlich diese Zeilen im Logfile aufgetaucht sind. Ich bin der Meinung, dass weniger mehr ist. Fehlermeldungen ja klar, die gehören ins Logfile, ob aber der Webhook funktioniert, wenn ich die Tür öffne und schließe, sehe ich ja an den entsprechenden Readings. Sollte da was nicht funktionieren, kann man im Bedarfsfall erstmal Verbose höher einstellen.
Ich persönliche finde daher die Meldung bei Verbose 3 nicht so schön, da Error und Hinweis beide in Verbose 3 kommen. Würde ich auf Verbose 2 einstellen, hätte ich auch die Error-Meldung nicht bekommen. Aber, wenn es so viele Nachfragen dazu gab und es für dich als Maintainer so besser ist, kann ich gut damit leben. ;)
Für so ein tolles, dazu noch kostenloses Spitzenprodukt wie FHEM mit all seinen Modulen, der tollen Community, usw. nehm ich gern diesen Eintrag im Logfile in Kauf ;)
Danke für die Aufklärung!
Ich habe die Nuki-Bridge und das Nuki-Smartlock 3 in FHEM eingebunden. Jetzt habe ich die Vermutung das sich, durch die zyklichen Abfragen alle 30 Sekunden, die Batterien schneller entleeren. Leider finde ich keine Möglichkeit den Intervall zu ändern. Im wesentlichen interessiert mich nur der "state" des Schlosses zur Weiterverarbeitung. Hätte da jemand einen Tipp?
Die Abfragen werden nicht auf das Schloss gemacht sondern einzig und allein auf die Bridge. Darauf wurde geachtet. Wie oft dann die Bridge sich aktuelle Daten vom Schloß holt kann ich aber nicht sagen. Auf jeden Fall hat die Abfrage keinen sonderlichen Einfluss auf den Batterieverbrauch.
Moin Marko,
ich bin mit deinem Modul sehr zufrieden. Leider fehlt mir aber immer wieder die Information wer die Tür geöffnet hat. Leider ist diese Information ja aus der API nicht zu bekommen. Hast du mal daran gedacht eine Möglichkeit einzubauen, die fehlende Information über WebAPI zu holen? Vorschlag wird auch hier gemacht.
https://developer.nuki.io/t/add-user-to-bridge-http-api-notifications/151/34
Gruss
Enno
Habe mir jetzt aus einem anderen FHEM "Baukasten" eine Abfrage gestrickt:
defmod NUKI_WEB JsonMod https://api.nuki.io/smartlock/log
attr NUKI_WEB DbLogExclude .*
attr NUKI_WEB httpHeader Authorization: Bearer [KEY]
attr NUKI_WEB readingList complete();;
Die Daten rufe ich ab, wenn Nuki aufgeschlossen wurde und werte dann das Reading "0.name" aus.
Gruss
Enno
Hallo,
ich habe vor einigen Tagen ein Update gemacht und bekomme nun folgende Fehlermeldung beim Start:
Compilation failed in require at ./FHEM/73_NUKIBridge.pm line 44, <$fh> line 617.
Attempt to reload FHEM/Devices/Nuki/Bridge.pm aborted.
Hat jemand eine Idee?
Gruß
Jaykoert
Zitat von: Jaykoert am 09 März 2022, 11:39:31
Hallo,
ich habe vor einigen Tagen ein Update gemacht und bekomme nun folgende Fehlermeldung beim Start:
Compilation failed in require at ./FHEM/73_NUKIBridge.pm line 44, <$fh> line 617.
Attempt to reload FHEM/Devices/Nuki/Bridge.pm aborted.
Hat jemand eine Idee?
Gruß
Jaykoert
Schau mal ob Du unter /opt/fhem/lib/FHEM/Devices/Nuki etwas zu stehen hast
Ja, eine Bridge und eine Device.pm.
Zitat von: Jaykoert am 09 März 2022, 11:39:31
Hallo,
ich habe vor einigen Tagen ein Update gemacht und bekomme nun folgende Fehlermeldung beim Start:
Compilation failed in require at ./FHEM/73_NUKIBridge.pm line 44, <$fh> line 617.
Attempt to reload FHEM/Devices/Nuki/Bridge.pm aborted.
Hat jemand eine Idee?
Gruß
Jaykoert
Steht da zufällig noch mehr? Gib mal bitte ein paar Zeilen vor und nach der zitierten Meldung.
Hallo zusammen,
ich habe es jetzt hinbekommen. Vielleicht stößt ja jemand auf einen ähnlichen Fehler.
Mit verbose=0 war die Fehlermeldung etwas umfangreicher:
Compilation failed in require at ./FHEM/74_NUKIDevice.pm line 33, <$fh> line
623. BEGIN failed--compilation aborted at lib/FHEM/Devices/Nuki/Device.pm
line 31, <$fh> line 623. 2022.03.09 17:17:52.876 0: Can't locate
experimental.pm in @INC (you may need to install the experimental module)
(@INC contains: ./lib ./FHEM .
/Library/Perl/5.18/darwin-thread-multi-2level /Library/Perl/5.18
/Network/Library/Perl/5.18/darwin-thread-multi-2level
/Network/Library/Perl/5.18
/Library/Perl/Updates/5.18.2/darwin-thread-multi-2level
/Library/Perl/Updates/5.18.2
/System/Library/Perl/5.18/darwin-thread-multi-2level
/System/Library/Perl/5.18
/System/Library/Perl/Extras/5.18/darwin-thread-multi-2level
/System/Library/Perl/Extras/5.18 ./FHEM/lib) at
lib/FHEM/Devices/Nuki/Device.pm line 31, <$fh> line 623.
Bei mir auf meinem 2011er MacMini ist OS X El Capitan 10.11.6 installiert und damit gebündelt Perl 5.18.
Das war nicht sehr einfach zu aktualisieren. Mit ActiveState (auf perl.org) verlinkt, konnte ich auf 5.28.1 aktualisieren, auch so, dass es beim Starten als Default verwendet wird.
Nun funktioniert auch wieder das Nuki-Modul.
Danke auch an Marko für die Unterstützung.
Gruß
Jaykoert
Ich kriege andauernd immer wieder 503 Errors und das Nuki öffnet nicht.
Alle anderen Aktionen, die durch den Fingerscan ausgelöst werden, werden immer sauber abgearbeitet, nur das Schloss öffnet nicht.
Teilweise beim 2. mal dann erfolgreich, teilweise 3-4 und mehr Versuche mit entsprechendem Abstand dazwischen.
Was ist das?
Habe das Gefühl, dass es jede Woche schlimmer wird.
2022.04.07 17:32:28 3: NUKIBridge WEBHOOK (NukiBridge) - Received webhook for matching NukiId at IODev NukiBridge
2022.04.07 17:32:36 3: NUKIBridge (NukiBridge) - JSON error while request: malformed JSON string, neither tag, array, object, number, string or atom, at character offset 0 (before "HTTP 503 Unavailable") at lib/FHEM/Devices/Nuki/Bridge.pm line 870.
2022.04.07 17:32:37 3: NUKIBridge (NukiBridge) - JSON error while request: malformed JSON string, neither tag, array, object, number, string or atom, at character offset 0 (before "HTTP 503 Unavailable") at lib/FHEM/Devices/Nuki/Bridge.pm line 870.
Zitat von: enno am 30 Januar 2022, 11:59:59
Habe mir jetzt aus einem anderen FHEM "Baukasten" eine Abfrage gestrickt:
defmod NUKI_WEB JsonMod https://api.nuki.io/smartlock/log
attr NUKI_WEB DbLogExclude .*
attr NUKI_WEB httpHeader Authorization: Bearer [KEY]
attr NUKI_WEB readingList complete();;
Die Daten rufe ich ab, wenn Nuki aufgeschlossen wurde und werte dann das Reading "0.name" aus.
Gruss
Enno
Hallo Enno, ist das alles oder muss da noch irgendwie meine Nuki-ID mit rein?
LG
Ralf
Moin Ralf,
bei https://web.nuki.io muss das Gerät auch zu sehen sein. Ich hatte das Gerät dort hinzugefügt, so dass das Web drauf zugreifen kann.
Gruss
Enno
Wo genau muss ich welchen Key hinterlegen, um auf NUKI-WEB zuzugreifen?
defmod NUKI_WEB JsonMod https://api.nuki.io/smartlock/log
attr NUKI_WEB DbLogExclude .*
attr NUKI_WEB httpHeader Authorization: Bearer [KEY]
attr NUKI_WEB readingList complete();;
Moin,
auf https://web.nuki.io zu "API" gehen, dort ein "API Token generieren". Den Platzhalter [Key] durch dieses Token ersetzen.
Sieht dann ungefähr so aus:
attr NUKI_WEB httpHeader Authorization: Bearer b07df51e52deeb4637478552e8dbf1df4589be2b3d897f547a94a61a2abcdefghcea568a9b7be12345
Gruss
Enno
Zitat von: enno am 23 Mai 2022, 19:46:08
Moin,
auf https://web.nuki.io zu "API" gehen, dort ein "API Token generieren". Den Platzhalter [Key] durch dieses Token ersetzen.
Sieht dann ungefähr so aus:
attr NUKI_WEB httpHeader Authorization: Bearer b07df51e52deeb4637478552e8dbf1df4589be2b3d897f547a94a61a2abcdefghcea568a9b7be12345
Gruss
Enno
Hi Enno,
ich bekomme folgendes Reading:
detailMessage
Your access token is not authorizedLG Ralf
Hat etwas gedauert. Nach dem ersten Öffnen und Schließen kamen die Readings.
Vorher hatte ich Nuki-Web gelöscht und noch einmal neu angelegt.
Danke für deine Mühe und das Teilen des Wissens.
So kann ich nämlich eine "Anwesenheitskontrolle" durchführen und gewisse Dinge schalten.
Liebe Grüße
Ralf
Zitat von: CoolTux am 13 Januar 2022, 15:32:25
Kommt drauf an was Du machen/haben willst.
Wenn es Dir nur damrum geht über das Internet mittels der Cloud Dein Schloß zu bedienen dann ja. Willst Du die HTTP API verwenden um mittels FHEM das Schloß zu bedienen und andere Nuki Produkte wie den Opener, dann nein.
Ich wollt jetzt auch mal mit Nuki einsteigen und es primär mit FHEM bedienen; dazu brauche ich offensichtlich auf jeden Fall die Bridge - und es würde das 3.0 ohne Pro reichen.
Frage: Was würde mir das 3.0
Pro zusätzlich bringen außer dem Akkupack und dem Alu-Design - und den Mehrkosten natürlich ;D
Hi,
ich hätte da eine Frage zum Auto unlock. Das hatte bei mir bis jetzt eigentlich ganz gut funktioniert. Seit ein paar Monaten geht nix mehr. Ich kannes zwar über die Nuki App Öffnen, aber das Auto Unlock funktioniert nicht mehr. Ich habe gestern nochmal Versucht aus meinem 100m Geofence Radius rauszulaufen. Danach bekomme ich dir Meldung Von zuhause entfernt, Auto Unlock ist aktiviert und wartet bis man wieder in der nähe ist. Wenn ich mich jetzt wieder in mein Geofence Radius nähere und in innerhalb meiner Grenze bin sollte er ja BT an machen und warten bis ich mich meinem Schloss nähere. Tut sie aber nicht. Stattdesen bekomme ich die Meldung. Auto unlock wurde abgebrochen. Hat den jemand so ein ähnliches Problem? App Version ist:2.12.4
Noch eine andere Frage. Wäre es möglich diese Auto Unlock funktion nur mit Fhem zu machen. Also ohne die App? D.h. ich programmiere selbst meine Bedingung, wenn ich in der Nähe bin aber hierzu müsste ich irgendwie mein Handy und Nuki über BT koppeln lassen. Und soweit ich das sehe gibt es keine Möglichekit in dem Nuki Modul BT zu koppeln?...
Hallo,
ich habe jetzt erfolgreich mein Nuki 3.0 mit der Bridge in FHEM eingebunden.
Frage: Kann mir bitte mal jemand kurz erklären, wozu man den Webhook benötigt und wer da mit wem kommuniziert ;)
OT: Habe mich lange nicht an das Nuki herangetraut, aber jetzt muss ich sagen, die Technik und das Produkt sind schon sehr ausgereift, echt top. Hatte mal kurz das Danalock, war mir aber zu "kompliziert" dessen FHEM-Anbindung
Webhook - > FHEM bekommt Aktionen am Schloss "sofort" (=fast sofort) mit.
Ist das hier bereits bekannt:
https://developer.nuki.io/t/bridge-beta-fw-1-22-1-2-14-0-with-new-encrypted-bridge-http-api-token/15816
Evtl ja Mal ein Anlass, den token auch in fhem verschlüsselt übertragen zu lassen und nicht "plain" wie heute.
2022.08.10 09:32:52 3: NUKIBridge WEBHOOK (myNukiBridge) - Received webhook for matching NukiId at IODev myNukiBridge
2022.08.10 09:32:52 3: NUKIBridge WEBHOOK (myNukiBridge) - Received webhook for matching NukiId at IODev myNukiBridge
Warum wird der immer zweimal protokolliert ???
Habe festgestellt, dass der Umlaut "ü" im Namen meines Nuki-Geräts "Eingangstüre" zu Problemen in FHEM führt.
Konkret gibt es alle paar Sekunden eine Meldung "Connection lost, trying a reconnect every 5 seconds" bei FHEM-Ansichten, wo das Gerät drauf ist. In der Browserkonsole steht der Fehler "Could not decode a text frame as UTF-8.":
Rcvd:
fhemweb.js:1333 WebSocket connection to 'ws://10.0.0.6:8083/fhem?XHR=1&inform=type%3Dstatus%3Bfilter%3Droom%3DHome%3Bsince%3D1662831297.6231601%3Bfmt%3DJSON&fw_id=20534×tamp=1662831329402' failed: Could not decode a text frame as UTF-8.
FW_longpoll @ fhemweb.js:1333
patchedCallback @ VM37:132
fhemweb.js:576 19:35:54.372 ERRMSG:Connection lost, trying a reconnect every 5 seconds.<
fhemweb.js:576 19:35:59.282 ERRMSG:<
Seit ich das Gerät auf "Eingangstuere" in Nuki umbenannt habe geht es wieder. Ich lasse es jetzt mal bei mir so, aber vielleicht gibt es ja eine nachhaltigere Lösung. In FHEM versuche ich Umlaute für Devices eh zu vermeiden, aber in diesem Fall kommt der Name halt direkt von Nuki.
Hallo Forum,
Seit letzter Woche funktionieren die Nuki-Geräte gar nicht mehr. Muss seit einem der letzten Updates passiert sein. Leider kann ich den genauen Zeitpunkt nicht definieren.
Bei einem Neustart bootet fhem quasi im Kreis.
Ich wusste mir nicht anders zu helfen als die NUKI-pm-Module zu löschen; die Nuki-Geräte inkl. Bridge aus der fhem.cfg zu entfernen und dann neu zu starten.
Jetzt kann ich den Befehl zu Bridge-Erstellung im fhem aufrufen:
define NBridge1 NUKIBridge 192.168.3.156 412885
aber sie taucht anschließend nicht auf.
Im Log erscheinen folgende Meldungen
2022.09.26 10:14:29.638 3: NUKIBridge (NBridge1) - defined with host 192.168.3.xxxx on port 8080, Token xxxxxx
2022.09.26 10:14:29.638 2: NUKIBridge (NBridge1) - Registering NUKIBridge for webhook URI /NUKIBridge-192.168.3.xxx ...
2022.09.26 10:14:30.065 2: autocreate: define WohnungTuer NUKIDevice 803083229 4
2022.09.26 10:14:30.071 3: NUKIDevice (WohnungTuer) - I/O device is NBridge1
2022.09.26 10:14:30.071 3: NUKIDevice (WohnungTuer) - defined with NukiId: xxxxxx
2022.09.26 10:14:30.072 3: NUKIDevice (WohnungTuer) - change model
2022.09.26 10:14:30.073 2: NUKIDevice (WohnungTuer) - GetUpdate Call IOWrite
2022.09.26 10:14:30.252 2: autocreate: define Haustuer NUKIDevice 813116668 4
2022.09.26 10:14:30.259 3: NUKIDevice (Haustuer) - I/O device is NBridge1
2022.09.26 10:14:30.259 3: NUKIDevice (Haustuer) - defined with NukiId: xxxxx
2022.09.26 10:14:30.260 3: NUKIDevice (Haustuer) - change model
2022.09.26 10:14:30.261 2: NUKIDevice (Haustuer) - GetUpdate Call IOWrite
2022.09.26 10:14:30.561 3: NUKIBridge (NBridge1) - URL ist: http://192.168.3.20:8083/fhem/NUKIBridge-192.168.3.156
encountered object '0', but neither allow_blessed, convert_blessed nor allow_tags settings are enabled (or TO_JSON/FREEZE method missing) at lib/FHEM/Devices/Nuki/Bridge.pm line 878.
2022.09.26 10:14:30.960 1: PERL WARNING: Perl exited with active threads:
1 running and unjoined
0 finished and unjoined
0 running and detached
Fhem und OS habe ich gestern das letzte Mal geupdatet - ohne Verbesserung. Meine perl-Version ist die 5.32.1.
Ich bin etwas ratlos...
Gruß,
klinki
Bin auch ratlos. Sowohl Bridge als auch 2 Geräte wurden angelegt. Die letzte Meldung muss ich mir genauer anschauen. Kommt mir seltsam vor
Die Fehlermeldung hat was mit encode_json zu tun. Wieso das bei Dir kommt ist mir aber ein rätsel da ich genau die selbe perl Version habe wie Du.
hm...die letzten Änderungen an meinem fhem betrafen das Modul "WOLF_ISM8I". Das Modul kann nicht disabled werden - deshalb habe ich es auskommentiert. Siehe da: Die Nukis sind wieder da und tun was sie sollen. Ohne Fehlermeldung.
Das ist jetzt ein bisschen doof: Ich habe ziemlich viel an der Heizungssteuerung herumgebastelt und kann dies nur schwer aufgeben...
Aber jetzt ist zumindest mal die Fehlerquelle eingegrenzt. Erfahrungsgemäß ist es ja immer die letzte Änderung.
Der Tipp mit der Problematik im JSON-Modul war der entscheidende. Danke Dir!
Mein Bauchgefuehl sagt, dass das verwendete Perl JSON Bibliothek nicht mit threads, was im WOLF_ISM8I Modul verwendet wird, harmoniert.
Koenntest Du bitte testweise die gemeldete Zeile 878 in lib/FHEM/Devices/Nuki/Bridge.pm ($json = encode_json($decode_json);) durch
$json = main::toJSON($decode_json);
austauschen, und berichten?
Apropos: es waere interessant zu wissen, welche der vielen moeglichen JSON Bibliotheken verwendet wird.
fhem startet wieder, es werden aber Fehler geloggt:
2022.09.26 13:25:16.361 1: PERL WARNING: Argument "toJSON: Cannot encode 0" isn't numeric in numeric eq (==) at lib/FHEM/Devices/Nuki/Device.pm line 589.
2022.09.26 13:25:16.361 1: PERL WARNING: Argument "toJSON: Cannot encode 0" isn't numeric in numeric eq (==) at lib/FHEM/Devices/Nuki/Device.pm line 593.
2
und:
2022.09.26 13:28:41.701 1: PERL WARNING: Perl exited with active threads:
1 running and unjoined
0 finished and unjoined
0 running and detached
Dennoch scheinen Nuki und Wolf zu laufen.
Zitat2022.09.26 13:25:16.361 1: PERL WARNING: Argument "toJSON: Cannot encode 0" isn't numeric in numeric eq (==) at lib/FHEM/Devices/Nuki/Device.pm line 593.
D.h. dass durch Verwendung des WOLF Moduls in den Datenstrukturen etwas reingekommt, was laut Pruefung keine Zahl, eine Referenz, aber nicht ARRAY oder HASH ist. Das stoert sowohl meinen primitiven JSON-Konverter, aber auch das "professionelle" JSON Modul.
Koenntest bitte in der gleichen Datei (Bridge.pm) vor toJSON / encode_json Folgendes einfuegen:
use Data::Dumper;
Log 1, "NUKIJSON: ".Dumper($decode_json);und berichten?
Sorry, aber ich habe leider nicht viel Ahnung von Perl. Dein "Log 1" hat nicht funktioniert. Ich habe mich an Log-Methode des Moduls orientiert und folgendes eingefügt: use Data::Dumper;
::Log3($name,3, Dumper($decode_json));
$json = main::toJSON($decode_json);
Hier die Ausgabe:
2022.09.26 14:20:39.077 3: $VAR1 = {
'state' => 3,
'success' => bless( do{\(my $o = 1)}, 'JSON::PP::Boolean' ),
'mode' => 2,
'batteryChargeState' => 72,
'batteryCharging' => bless( do{\(my $o = 0)}, 'JSON::PP::Boolean' ),
'stateName' => 'unlocked',
'nukiId' => 813116668,
'batteryCritical' => $VAR1->{'batteryCharging'}
};
2022.09.26 14:20:39.086 1: PERL WARNING: Argument "toJSON: Cannot encode 0" isn't numeric in numeric eq (==) at lib/FHEM/Devices/Nuki/Device.pm line 589.
2022.09.26 14:20:39.086 1: PERL WARNING: Argument "toJSON: Cannot encode 0" isn't numeric in numeric eq (==) at lib/FHEM/Devices/Nuki/Device.pm line 593.
Ich verstehe nicht ganz wieso er JSON::PP verwendet. Das ist das allerletzte Fallback wenn gar keine anderen JSON Module zu finden sind.
Zitat von: Klinki am 26 September 2022, 12:33:35
hm...die letzten Änderungen an meinem fhem betrafen das Modul "WOLF_ISM8I". Das Modul kann nicht disabled werden - deshalb habe ich es auskommentiert. Siehe da: Die Nukis sind wieder da und tun was sie sollen. Ohne Fehlermeldung.
Das ist jetzt ein bisschen doof: Ich habe ziemlich viel an der Heizungssteuerung herumgebastelt und kann dies nur schwer aufgeben...
Aber jetzt ist zumindest mal die Fehlerquelle eingegrenzt. Erfahrungsgemäß ist es ja immer die letzte Änderung.
Der Tipp mit der Problematik im JSON-Modul war der entscheidende. Danke Dir!
Das Modul ist aber nicht offiziell, oder? Wo hast Du das her?
Hatte im Forum eine Hinweis darauf gefunden und bin dann auf GitHub gelandet: https://github.com/qyqsoft/ISM8I (https://github.com/qyqsoft/ISM8I)
Trinidad ist wohl der Autor und hat eine eigene Seite: https://tips-und-mehr.de/wolf-heizanlagen-mit-ism8i-schnittstellenmodul-ueberwachen-und-in-fhem-auswerten/ (https://tips-und-mehr.de/wolf-heizanlagen-mit-ism8i-schnittstellenmodul-ueberwachen-und-in-fhem-auswerten/)
Der Thread ist dieser hier: https://forum.fhem.de/index.php/topic,72063.0.html (https://forum.fhem.de/index.php/topic,72063.0.html)
ZitatHier die Ausgabe:
Danke. Verstehe aber immer noch nicht, wieso JSON::PP, wenn das WOLF Modul geladen ist, sein selbst dekodiertes Objekt nicht wieder nach JSON konvertieren kann.
Die Loesung koennte daraus bestehen, eine andere JSON Bibliothek zu verwenden (JSON::MaybeXS, Cpanel::JSON::XS, JSON::XS).
Ich muss gestehen das ich in diesem Wolf Modul nichts in Bezug auf JSON finden kann. Ich bin da glaube blind.
Vermutlich liegt es an bignum, jedenfalls wird das hier so suggeriert: https://www.perlmonks.org/?node_id=1138449
Das ganze Modul beinhaltet, obwohl in der main laufend, keine Ein Ein Deutigen Funktionsnamen mit entsprechenden Präfix, möglich das es gleichlautende Funktionsnamen gibt.
Ich denke der erste Schritt sollte sein den Author zu bitten sein Modul entsprechend Konform um zu schreiben.
Zitat von: rudolfkoenig am 26 September 2022, 15:02:26
Vermutlich liegt es an bignum, jedenfalls wird das hier so suggeriert: https://www.perlmonks.org/?node_id=1138449
Jepp das scheint in der Tat das Problem recht gut zu beschreiben.
ZitatIch denke der erste Schritt sollte sein den Author zu bitten sein Modul entsprechend Konform um zu schreiben.
Loest das Problem aber nicht.
Folgendes:
use Data::Dumper;
use JSON::PP;
use bignum;
my $dec = decode_json('{ "t":true, "f":false}');
$dec->{x} = 1000;
print Dumper($dec),"\n";
print encode_json($dec),"\n";
erzeugt:
Zitat$VAR1 = {
'f' => bless( do{\(my $o = 0)}, 'JSON::PP::Boolean' ),
't' => bless( do{\(my $o = 1)}, 'JSON::PP::Boolean' ),
'x' => bless( {
'sign' => '+',
'value' => bless( [
'1000'
], 'Math::BigInt::Calc' )
}, 'Math::BigInt' )
};
encountered object '1000', but neither allow_blessed, convert_blessed nor allow_tags settings are enabled (or TO_JSON/FREEZE method missing) at t.pl line 8.
Womoeglich hilft ein strategisch gut platziertes "no bignum", oder die Verwendung einer der anderen JSON-Parser.
Ich habe zwei Issues im Git des Users aufgemacht. Schauen wir einmal.
Bis dahin wird wohl eines der Module deaktiviert werden müssen.
oder so...wollte den Author gerade anschreiben ;)
Wenn man weiß was es ist lässt sich damit leben.
Danke euch vielmals für eure Mühe und Unterstützung!
mal eine Frage, ich habe seit Do. ein Nuki 3.0 Pro, aber keine Bridge. Wollte das jetzt im Fhem installieren.
Wie muss ich das Nuki dann einbinden ohne Bridge.?
Zitat von: moonsorrox am 04 Oktober 2022, 00:07:07
mal eine Frage, ich habe seit Do. ein Nuki 3.0 Pro, aber keine Bridge. Wollte das jetzt im Fhem installieren.
Wie muss ich das Nuki dann einbinden ohne Bridge.?
Geht nur mit Bridge.
wird sich da etwas ändern oder ist das so garnicht möglich.?
Laut Nuki unterstützt das 3.0 Pro die Api nicht, also wird das schwierig. Es gibt aber noch eine alternative in fhem. Nennt sich nukihub. Damit sollte es mit geringen Kosten kein Problem sein. Suche den Theard mal eben raus.
https://forum.fhem.de/index.php/topic,127057.0.html
https://support.nuki.io/hc/de/articles/4407671333521--Integration-of-Nuki-in-other-Smart-Home-systems
vielen Dank das werde ich mir mal anschauen, bleibt mir ja ohne Bridge nichts anders übrig und extra eine Bridge kaufen werde ich nicht machen. Habe ja lange gewartet auf das 3.0pro :)
was mir da noch so einfällt evtl. kann man eine virtuelle Bridge erstellen.? So wie auch ein virtuelle Vccu.
@CoolTux
Wäre soetwas denkbar oder garnicht möglich.?
Zitat von: moonsorrox am 05 Oktober 2022, 16:46:33
was mir da noch so einfällt evtl. kann man eine virtuelle Bridge erstellen.? So wie auch ein virtuelle Vccu.
@CoolTux
Wäre soetwas denkbar oder garnicht möglich.?
Nicht das ich wüsste.
Trinidad hat wohl die Issues vom Git beseitigt.
Das Problem besteht bei mir aber weiterhin. Ist es möglich, dass Nuki sowie ISM8I die gleichen Kommunikationswege (Dateisystem, Socket, o.Ä.) benutzen?
Es ist prinzipiell egal ob Nuki oder das Wolf-Modul auskommentiert werden. Nur wenn beide aktiv sind, gibt es das Problem.
Ein "netstat -an" brachte mir zumindest keine Hinweise.
Gruß,
Klinki
Zitat von: Klinki am 07 Oktober 2022, 08:19:47
Trinidad hat wohl die Issues vom Git beseitigt.
Das Problem besteht bei mir aber weiterhin. Ist es möglich, dass Nuki sowie ISM8I die gleichen Kommunikationswege (Dateisystem, Socket, o.Ä.) benutzen?
Es ist prinzipiell egal ob Nuki oder das Wolf-Modul auskommentiert werden. Nur wenn beide aktiv sind, gibt es das Problem.
Ein "netstat -an" brachte mir zumindest keine Hinweise.
Gruß,
Klinki
Es ist ein Bug in einer vom ISM8I Modul verwendeten Perlbibliothek.
Mögliche Lösungen wurden dem Autor des Moduls genannt
Hallo Cooltux,
kann ich das generierte Nuki Device ohne Probleme per "rename" ändern?
Mein Device heißt Haustür, und fhem macht da ein Haust_r draus.
LG und danke für das Modul!
Zitat von: Esjay am 16 Oktober 2022, 12:09:04
Hallo Cooltux,
kann ich das generierte Nuki Device ohne Probleme per "rename" ändern?
Mein Device heißt Haustür, und fhem macht da ein Haust_r draus.
LG und danke für das Modul!
Ja das kannst Du machen. Kein Thema
ich bin mir nicht sicher ob ich hier richtig bin.
Habe ein Nuki 1. Gen mit einer Bridge am laufen und kann per Fhem steuern.
Bridge API VERSION v2.0.2
Nuki Device VERSION v2.0.2
Das Device wird definiert durch "18573xxxx IODev=Door_Bridge"
Ich habe ein Nuki 3.0 (nix pro) über die App mit der Bridge verbunden, das läuft alles.
Allerdings findet Bridge API in Fhem nicht das neue Device bei der Abfrage. Ein manuelles define laut Wiki funktioniert nicht.
Passt die Version nicht?
Woher kam die Nuki Device ID?
Das define ist sehr veraltet.
Am besten Du entfernst mal das Nuki Device und lässt es komplett neu anlegen.
In der Bridge sollte das mit set getDeviceList funktionieren.
Vielen Dank.
Das hat funktioniert, nachdem ich dann auch die Bridge komplett neuangelegt habe.
Hallo CoolTux,
herzlichen Dank für deine Module.
Ich nutze ein Smart Lock 3 und eine Bridge. In dem FHEM-Nuki-Device wird ein Umlaut nicht richtig dargestellt:
name Haust�r 2023-01-15 15:23:44
UTF-Problematik o.ä.? Wie kann ich das beheben?
Ich schaue es mir die Tage mal an. Ist ja nur ein kosmetisches Problem.
Grüße
ZitatIst ja nur ein kosmetisches Problem.
Na ja, bei mir hat ein Umlaut im Namen zu Websocket-Fehlern geführt und ständiges "Connection lost" im Frontend. Erst nachdem ich das Gerät in Nuki umbenannt habe, hatte ich wieder Ruhe. Siehe Antwort #61 in diesem Thread.
Zitat von: Gary am 15 Januar 2023, 16:11:16
Na ja, bei mir hat ein Umlaut im Namen zu Websocket-Fehlern geführt und ständiges "Connection lost" im Frontend. Erst nachdem ich das Gerät in FHEM umbenannt habe, hatte ich wieder Ruhe. Siehe Antwort #61 in diesem Thread.
Das ist richtig. Umlaute haben im Devicenamen auch nichts zu suchen. Dachte eigentlich das ich das so gemacht habe das wenn automatisch angelegt es kein Umlaut in den Devicenamen schaft. Oder hast Du es von Hand in der cfg angelegt?
Wurde automatisch mit Umlaut angelegt und ich habe das Device danach in der Nuki App umbenannt und den Umlaut rausgenommen.
Um meinen Fall zu konkretisieren:
Mein Device-Name hatte nie und hat keinen Umlaut im Namen (FL_Haustuer). Es handelt sich lediglich um das Reading "name" im Device, welches den Namen, den das Schloss im Nuki-Kosmos hat, wohl beinhaltet.
Hi Leute, benötigt ich für das SmartLock 3.0 Pro ebenfalls die Bridge oder kann ich das Schloss direkt per wLan ansprechen?
Danke und Grüße
Zitat von: SimonHipp am 01 Februar 2023, 20:29:36
Hi Leute, benötigt ich für das SmartLock 3.0 Pro ebenfalls die Bridge oder kann ich das Schloss direkt per wLan ansprechen?
Danke und Grüße
Geht nur mit Bridge
Zitat von: SimonHipp am 01 Februar 2023, 20:29:36
Hi Leute, benötigt ich für das SmartLock 3.0 Pro ebenfalls die Bridge oder kann ich das Schloss direkt per wLan ansprechen?
Danke und Grüße
Das 3.0 Pro erlaubt keinen Zugriff auf die Api, daher wie Cooltux schon richtig gesagt hat, ist die Bridge notwendig. Schau mal hier, vielleicht kannst du deine Anforderungen auch damit umsetzen.
https://forum.fhem.de/index.php/topic,127057.0.html
Grüße
Hallo.
Über die Suche bin ich leider nicht fündig geworden. Gibt es eine Möglichkeit die Klingelunterdrückung des Nuki Openers über FHEM an und aus zu schalten?
Oder geht das nur über die App?
Ebenso die Klingeltöne des Openers selbst, gibt es da die Möglichkeit diese über FHEM einzustellen?
Zitat von: Esjay am 03 Februar 2023, 09:29:09Zitat von: SimonHipp am 01 Februar 2023, 20:29:36Hi Leute, benötigt ich für das SmartLock 3.0 Pro ebenfalls die Bridge oder kann ich das Schloss direkt per wLan ansprechen?
Danke und Grüße
Das 3.0 Pro erlaubt keinen Zugriff auf die Api, daher wie Cooltux schon richtig gesagt hat, ist die Bridge notwendig. Schau mal hier, vielleicht kannst du deine Anforderungen auch damit umsetzen.
https://forum.fhem.de/index.php/topic,127057.0.html
Grüße
Da das Pro mittlerweile MQTT kann, ist keine mehr Bridge notwendig. Man benötigt dann auch dieses Modul nicht. Die Einbindung ist viel einfacher, schneller und direkter.
Scheint es laut API nicht zu geben
https://developer.nuki.io/page/nuki-bridge-http-api-1-13/4
Grüße
Hat jemand das Nuki 3.0 Pro schon direkt per MQTT eingebunden.
Bei mir läuft das erstmal, nur bis auf Lock und Unlock konnte ich bisher noch nix an das Teil senden.
Grundsätzlich würde das ja reichen, da ich erstmal nur zeitgesteuert die Türe verschließen und öffnen will, aber vielleicht geht da noch mehr :-)
Internals:
.FhemMetaInternals 1
CID SL3P_xxxxxxxx
DEF SL3P_xxxxxxxx
FUUID 645aert1-fxxf-bvv5-fzzc-fdfdfdfdfdfdfd
FVERSION 10_MQTT2_DEVICE.pm:0.268600/2022-12-16
IODev myBroker
LASTInputDev myBroker
MSGCNT 144
NAME MQTT2_SL3P_xxxxxxxx
NR 1595
STATE 3
TYPE MQTT2_DEVICE
eventCount 157
myBroker_CONN myBroker_aaa.bbb.ccc.ddd_52433
myBroker_MSGCNT 144
myBroker_TIME 2023-05-12 06:24:32
.DT:
DEVICETOPIC MQTT2_SL3P_xxxxxxxx
.attraggr:
.attrminint:
READINGS:
2023-05-11 17:38:09 IODev myBroker
2023-05-12 02:01:09 batteryChargeState 69
2023-05-12 02:01:09 batteryCharging false
2023-05-12 02:01:09 batteryCritical false
2023-05-11 18:22:09 commandResponse 0
2023-05-12 02:01:05 connected true
2023-05-12 02:01:08 deviceType 4
2023-05-12 02:01:09 doorsensorBatteryCritical false
2023-05-12 02:01:09 doorsensorState 0
2023-05-12 02:01:09 firmware 3.6.9
2023-05-12 02:01:09 keypadBatteryCritical false
2023-05-12 06:24:31 lockActionEvent 1,2,0,0,1
2023-05-12 02:01:09 mode 2
2023-05-12 02:01:09 name NukiLock
2023-05-12 02:01:09 serverConnected true
2023-05-12 06:24:32 state 3
2023-05-12 06:24:32 timestamp 2023-05-12T04:24:33Z
hmccu:
Attributes:
DbLogExclude .*
alias NukiLock
StateFormat
Battery: [$name:batteryChargeState] % ([$name:batteryChargeState:t])<br>
State: [$name:state] S ([$name:state:t])<br>
Connected: [$name:connected] C ([$name:connected:t])
devStateIcon 1:hm_keymatic@red 2:hm_keymatic@blue 3:hm_keymatic@green 4:hm_keymatic@blue 5:hm_keymatic@orange 6:hm_keymatic@white 7:hm_keymatic@yellow
icon hm_keymatic
readingList SL3P_xxxxxxxx:nuki/xxxxxxxx/connected:.* connected
SL3P_xxxxxxxx:nuki/xxxxxxxx/deviceType:.* deviceType
SL3P_xxxxxxxx:nuki/xxxxxxxx/name:.* name
SL3P_xxxxxxxx:nuki/xxxxxxxx/firmware:.* firmware
SL3P_xxxxxxxx:nuki/xxxxxxxx/serverConnected:.* serverConnected
SL3P_xxxxxxxx:nuki/xxxxxxxx/state:.* state
SL3P_xxxxxxxx:nuki/xxxxxxxx/mode:.* mode
SL3P_xxxxxxxx:nuki/xxxxxxxx/doorsensorState:.* doorsensorState
SL3P_xxxxxxxx:nuki/xxxxxxxx/batteryCritical:.* batteryCritical
SL3P_xxxxxxxx:nuki/xxxxxxxx/batteryChargeState:.* batteryChargeState
SL3P_xxxxxxxx:nuki/xxxxxxxx/batteryCharging:.* batteryCharging
SL3P_xxxxxxxx:nuki/xxxxxxxx/keypadBatteryCritical:.* keypadBatteryCritical
SL3P_xxxxxxxx:nuki/xxxxxxxx/doorsensorBatteryCritical:.* doorsensorBatteryCritical
SL3P_xxxxxxxx:nuki/xxxxxxxx/lockActionEvent:.* lockActionEvent
SL3P_xxxxxxxx:nuki/xxxxxxxx/timestamp:.* timestamp
SL3P_xxxxxxxx:nuki/xxxxxxxx/commandResponse:.* commandResponse
room Aussenbereich,Security,Übersicht
setList auf:noArg nuki/xxxxxxxx/lockAction 1
zu:noArg nuki/xxxxxxxx/lockAction 2
Gruß
Andreas
Unlatch geht natürlich auch. Meine setlist
attr NukiLock setList unlock nuki/xxxxxxx/lockAction 1\
lock nuki/xxxxxxx/lock true\
unlatch nuki/xxxxxxx/lockAction 3
Das wäre aber ggf. etwas für einen anderen Thread.
Was willst du mehr machen?
Zitat von: marvin78 am 12 Mai 2023, 10:17:16Unlatch geht natürlich auch. Meine setlist
Danke :-)
Zitat von: marvin78 am 12 Mai 2023, 10:17:16Was willst du mehr machen?
Stimmt - nach aufschließen, zuschließen und Türe öffnen, bleibt ja eigentlich nix mehr :-)
Alles andere wie z.B. Batteriewarnung, kann man ja anders machen.
... anderer Thread? Welchen meinst Du?
Gruß
Andreas
Zitat von: Loetkolben am 12 Mai 2023, 11:01:37... anderer Thread? Welchen meinst Du?
Es gibt ggf. noch keinen. Aber die MQTT Api gehört sicher nicht in diesen Thread. Auch wenn der Titel nicht clever gewählt ist, geht es ja hier eigentlich um eine andere API und insbesondere das Modul dazu.
Hallo,
sehe ich es eigentlich richtig, dass ich keine Callbacks via SSL erhalte?
Also wenn meine Web-Instanz auf https läuft kein Callback funktioniert?
Wie wäre hier der Workaround, eine eigene Instanz für Nuki erstellen, die im ungesicherten http läuft?
Gruß Deco
Zitat von: Deco am 12 Mai 2023, 15:14:42Hallo,
sehe ich es eigentlich richtig, dass ich keine Callbacks via SSL erhalte?
Also wenn meine Web-Instanz auf https läuft kein Callback funktioniert?
Wie wäre hier der Workaround, eine eigene Instanz für Nuki erstellen, die im ungesicherten http läuft?
Gruß Deco
Jepp, genau so. Ist ja alles intern in Deinem Netz.
Ok, danke.
Kurzes OT:
Ist es denn überhabt notwendig/sinnvoll SSL zu aktivieren, wenn fhem nicht von außen erreichbar ist?
Ich hatte es aktiviert, da man ja zur Konfiguration auch über den PC darauf zugreift, der sich ja wiederum durchaus nebenbei im Internet bewegt (irgendwelche man-in-the-middle Gedanken von mitsniffenden Bösewichten :-\ ).
Wenn dann höchstens Cross Site Scripting. Aber da hilft auch kein SSL.
Es ist aber nie verkehrt https zu verwenden. Immer. In diesem Fall geht es leider nicht, daher zweite Fhemweb Instanz und diese entsprechend absichern. Dabei lernt man ja auch.
Ich habe übrigens seit ein paar Tagen die alte fhem-Instanz auf https umgestellt. Was soll ich sagen, merkwürdiger Weise läuft bisher NUKI ohne Veränderung reibungslos ???
Also ich meine damit, dass fleißig der Status des Schlosses und der Tür von der Bridge an fhem gemeldet wird, obwohl im list der callbacks eindeutig nur eine Adresse eingetragen ist, und die enthält den alten Pfad http (ohne "s").
Das kann ich momentan ehrlich gesagt noch nicht ganz nachvollziehen.
Die fhem Oberfläche ist via http jedenfalls nicht mehr erreichbar (so soll es ja auch sein).
EDIT:
In der fhem-Instanz ist SSL aktivert und sie ist passwortgeschützt. Beides kennt Nuki nicht (callback läuft auf http, Passwort nie irgendwo eingetragen). Dennoch funktionieren die callbacks wie gehabt. Der Status der Tür und des Schlosses wird übertragen und ich kann via fhem die Türen öffnen.
Hat jemand eine Erklärung wieso das funktioniert? Nach meinem Verständnis dürfte das doch gar nicht (mehr) funktionieren, da die Kommunikation ins leere laufen müsste ???
Gruß Deco
Hallo!
Habe mir auch ein Nuki 3 Pro zugelegt.
Hätte gern in FHEM / Tablet UI den aktuellen Zustand visualisert.
Geht das mit dem 3 Pro irgendwie?
Bin noch recht neu in FHEM und wäre für ein paar Codeschnipsel sehr dankbar.
MQTT im Nuki aktivieren?
Und dann?
Wie bekomme ich die Readings in FHEM angezeigt.
Nutze einen Linux Mosquitto Server mit MQTT, also nicht den FHEM eigenen.
Hat sich erledigt!
Weis jemand, ob man beim Opener die Klingelerkenung abgreifen kann?
Wie genau meinst Du das? Du siehst in FHEM wenn jemand klingelt.
Ah okay, dann geht wohl die Erkennung nicht :'(
EDIT: Kalte Lötstelle :-[ jetzt geht es!
Hallo Marvin,
Ist es eigentlich geplant auch die Infos vom Keypad hinzu zu fügen?
Gruß
Alex
Zitat von: Nighthawk am 31 Juli 2023, 08:03:37Hallo Marvin,
Ist es eigentlich geplant auch die Infos vom Keypad hinzu zu fügen?
Gruß
Alex
+1
Zitat von: marvin78 am 12 Mai 2023, 10:17:16Unlatch geht natürlich auch. Meine setlist
attr NukiLock setList unlock nuki/xxxxxxx/lockAction 1\
lock nuki/xxxxxxx/lock true\
unlatch nuki/xxxxxxx/lockAction 3
Das wäre aber ggf. etwas für einen anderen Thread.
Was willst du mehr machen?
Ich will mich mal hier dranhängen, um folgende wichtige Frage loszuwerden: Wie stehts denn um die Akkulaufzeit bei Anbindung via MQTT per wifi, d.h. ohne Bridge?
Danke & Grüße
Hallo zusammen,
erst einmal vielen Dank an den Ersteller des Moduls. Das ist wirklich sehr hilfreich. Eine Frage habe ich da allerdings, besser gesagt eine Bitte um Hilfestellung. Ich habe in meinem FHEM folgende Anzeige (siehe Anhang).
Offenbar wird bei mir das "ü" von Tür nicht richtig angezeigt. Ich habe schon die Suchfunktion benutzt, aber nichts dazu gefunden. Wie bekomme ich da ein "normales" Zeichen rein? Optimalerweise ein "ü", aber mit einem "ue" könnte ich auch leben.
In der fhem.cfg finde ich das Attribut "name" nicht. Daher vermute ich, dass es direkt aus dem Modul so geliefert wird. Lässt sich das irgendwie ändern? Ich möchte jetzt nicht amateurhaft zu viel im Modul des Erstellers ändern, bin aber auf Anweisung durchaus bereit an der richtigen Stelle Änderungen vorzunehmen (falls überhaupt notwendig).
Du hast beim einrichten des Nukis mit Deinem Handy mal einen Namen vergeben. Schau mal ob Du den in der App nachträglich ändern kannst. name ist ein Reading und wird aus den Daten welches vom Nuki kommt befüllt.
Hi CoolTux, danke für Deine Antwort. Was ist aber, wenn ich in meiner Nuki - App gerne ein "ü" sehen möchte (dort also tür und nicht tuer?). Letztendlich müsste man doch nur an irgendeiner Stelle im Modul Sonderzeichen abfangen, oder?
Ja das ist richtig. Man könnte hier Sonderzeichen abfangen. Aktuell komme ich aber leider nicht dazu. Sorry
Hallo CoolTux,
das ist natürlich absolut nachvollziehbar. Ich bin Dir auf jeden Fall dankbar für Deine bisherige Arbeit.
Wenn ich mich mal an dem Modul versuche und eine Lösung finden sollte, hättest Du dann irgendwann kurz Zeit, um das Ganze zu verifizieren? Das fände ich total klasse.
Ja na klar nehme ich mir dann gerne die Zeit zum verifizieren.
Grüße
Hallo zusammen,
ich habe seit kurzem ein Nuki Smartlock 3 (ohne Pro), eine Nuki Bridge und das Keypad 2.0.
Die Einbindung mittels dem Modul in Fhem hat auch geklappt und das Steuern funktioniert.
Allerdings hätte ich eine Frage:
In der Web-Api ist im Protokoll ja ersichtlich wenn am Keypad ein unbekannter Finger oder/und Codes aufgelegt/eingegeben wurde.
Ist es irgendwie möglich dies mit einzubauen?
Hintergrund ist, dass ich mir bei unbekanntem Finger/Code ein Bild der Außencam per PushNachricht schicken lassen
möchte.
Gruß
Tim
Das ist die Web API, nicht die Bridge API. Das sind 2 paar Schuhe 😊
Zitat von: CoolTux am 20 Oktober 2023, 21:02:45Das ist die Web API, nicht die Bridge API. Das sind 2 paar Schuhe 😊
Gibt es Erfahrungen, in wie weit der Hersteller evtl. Funktionen in die Bridge-Api hinzufügt, wenn man dies anfragt?
Für mich wäre z.b. sehr interessant vom Opener die Klingelunterdrückung via FHEM an und abzuschalten, was leider über die API auch nicht geht und in der App nur über mehrere Untermenüs einstellbar ist.
Da habe ich leider keinerlei Erfahrung.
Vielleicht wäre es eine Idee, hier mal ein paar Wünsche zu sammeln, welche Funktionen der App in der Api fehlen, aber nützlich für FHEM wären und dann dies mal gesammelt an den Hersteller zu senden. Wie sagt man so schön "Fragen kostet nix".
Finde sowas generell immer eine tolle Idee
Zitat von: CoolTux am 21 Oktober 2023, 07:26:19Finde sowas generell immer eine tolle Idee
Na dann fang ich mal an ;)
Ich hätte gern:
- über FHEM Klingelunterdrückung des Opener ab- und anschaltbar; als Reading den Status der jeweiligen Unterdrückung
- in FHEM ein Readings wer über Auto-Unlock das Nuki-Schloss geöffnet hat (wie im Protokoll)
Zitat von: CoolTux am 20 Oktober 2023, 10:20:05Ja na klar nehme ich mir dann gerne die Zeit zum verifizieren.
Grüße
Hi, Respekt an der Arbeit von Cooltux, danke. Ich habe in meinem Modul folgendes eingebaut um die Umlaute in den readings zu ersetzen:
sub ReplaceUmlaute {
my $string = shift;
my %umlaute = (
"ä" => "ae",
"Ä" => "Ae",
"ü" => "ue",
"Ü" => "Ue",
"ö" => "oe",
"Ö" => "Oe",
"ß" => "ss"
);
my $umlautkeys = join( "|", keys(%umlaute) );
$string =~ s/($umlautkeys)/$umlaute{$1}/g;
return $string;
}
Vielleicht findet es ja seinen Weg ins offizielle Modul.
Lg