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

Begonnen von CoolTux, 18 Juli 2016, 23:50:11

Vorheriges Thema - Nächstes Thema

CoolTux

Zitat von: SeppiDeluxe am 26 Januar 2018, 15:46:48
Aber ich nehme dann deinen Ansatz mit der sekundaren FI und nagel die halt zu.

Danke dir


Nur dieser Ansatz ist der einzig richtige. Dafür ist FHEMWEB und allowed gemacht.
Schau Mal im Wiki da ist das an mehreren Stellen gut erklärt.
Wegen csrf Token brauchst Dir keinen Kopf zu machen.
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

Sascha_F

Hallo zusammen,

es ist schon eine ganze Zeit her und ggf. untergegangen, daher wollte ich noch einmal freundlich fragen, ob mir jemand bei meinem geschilderten Problem helfen kann  :)

Danke und viele Grüße
Sascha


Zitat von: Sascha_F am 16 November 2017, 01:33:10
Hallo zusammen!

Ich mal wieder ;)

Ich glaube, ich brauche eine Eingebung...

Vorweg - ich bekomme nach wie vor immer wieder Log-Einträge (jetzt nicht x-fach, aber mehrmals am Tag). Um es etwas übersichtlicher zu halten, habe ich die Ziffern hinter Device nachfolgend immer entfernt:

NUKIBridge (NukiBridge) - invalid json detected: HTTP 503 Unavailable
NUKIDevice (NUKIDevice) - invalid json detected: HTTP 503 Unavailable



Mein ganz anders Problem habe ich aber gerade mit Nuki (Device) in Verbindung mit einem DOIF. Der Plan sieht vor, dass die Beleuchtung im Windfang angeschaltet wird, sobald das Schloss aufgeschlossen wurde. Das DOIF sieht so aus:

([NUKIDevice:state] eq "unlocked" and [?{sunset("REAL",1800,"16:00","23:00")}-{sunrise("REAL",0,"05:45","06:00")}]) (set HM_377AFE start)

'start' => eventMap auf on-for-timer
'?' => war ein Versuch, damit bei Eintreten der 'sunset'-Bedingung nicht aufgrund dieser Bedingung ausgelöst wird

Das Problem ist, dass die Beleuchtung auch eingeschaltet wird, wenn um 22:30 h aus einem DOIF das Abschließen ausgelöst wird. Im NukiDevice habe ich es auch mit "event-on-change state" probiert, aber das hat auch nicht geholfen. Eigentlich dachte ich, dass sich der state (oder auch lockState) nur aufgrund des webhook ändern - und dieser nur ausgelöst wird, wenn auch tatsächlich etwas am NukiDevice 'passiert' ist...

Also ich dachte:

Ausgangslage
state/lockState = 'unlocked' [ändert sich auch nicht, also kein event-on-change state/lockState; DOIF sollte daher bei Erfüllen der 'sunset'-Bedingung nicht auslösen - passiert aber. Das '?' scheint nicht als "nicht auslösende Bedingung" zu funktionieren]

später (wenn 'sunset'-Bedingung bereits erfüllt)
22:30 h: Anderes DOIF cmd setzt 'set NukiDevice lock' [jetzt wechseln state/lockState auf 'locked'; event-on-change state triggert, aber DOIF-Bedingung dürfte nicht erfüllt sein, da nicht 'unlocked' - passiert aber]

Ich war mir erst nicht sicher, ob DOIF-Problem oder NUKI, aber meine anderen DOIFs laufen einwandfrei, sodass ich es mir nur mit dem webhook oder wie auch immer erklären kann...

Danke euch und viele Grüße
Sascha

Raimund Scheiber

#962
Hi,
ich verwende schon seit einigen Jahren FHEM und bin damit sehr zufrieden.
Seit ein paar Tagen habe ich auch eine NUKI-Bridge und zwei Smartlocks im Einsatz und natürlich - dank euren Moduls :) - in FHEM integriert.
Was mir auffällt: in den Logs der Smartlocks gibt es alle 20-30 Sekunden einen Eintrag, das finde ich schon etwas viel, vor allem wird das wohl die Akkulaufzeit der Schlösser etwas belasten?
2018-02-05_09:11:31 Tuer_Atelier name: Nuki_08DDB5D1
2018-02-05_09:11:31 Tuer_Atelier rssi: -52
2018-02-05_09:11:31 Tuer_Atelier paired: true
2018-02-05_09:11:57 Tuer_Atelier name: Nuki_08DDB5D1
2018-02-05_09:11:57 Tuer_Atelier rssi: -55
2018-02-05_09:11:57 Tuer_Atelier paired: true
2018-02-05_09:12:14 Tuer_Atelier name: Nuki_08DDB5D1
2018-02-05_09:12:14 Tuer_Atelier rssi: -54
2018-02-05_09:12:14 Tuer_Atelier paired: true
2018-02-05_09:12:30 Tuer_Atelier name: Nuki_08DDB5D1
2018-02-05_09:12:30 Tuer_Atelier rssi: -53
2018-02-05_09:12:30 Tuer_Atelier paired: true

Außerdem hatte ich gestern ein saublödes Phänomen: eines der Schlösser hat sich plötzlich geöffnet (unlatch), obwohl niemand was gemacht hat; laut Protokoll war es die NukiBridge.
Im FHEM-Log gibt es genau für diesen Zeitpunkt folgenden Eintrag:
2018.02.04 15:32:35 3: NUKIBridge (Nuki_Bridge) - invalid json detected: HTTP 503 Unavailable

(diese http 503 einträge habe ich allerdings öfters im log stehen)

deswegen:
1) wo kann man das Interval konfigurieren, mit dem die Bridge bzw. das Device abgefragt wird?
2) wo kommen die 503-er Fehler her?
3) hat jemand auch mal das Problem gehabt, dass ein Schloss von selbst aufgegangen ist? (Das ist für mich eigentlich ein No-Go und ich bin beim überlegen, ob ich das Ganze Nukizeugs wieder zurückschicken soll...)

lg
raimund

Sascha_F

Hi Raimund,

hast Du Auto-Unlock aktiviert? Ich hatte dieses nur im Zusammenhang damit.

Z.B. vom Auto zur Tür gegangen und per App die Tür geöffnet, da ich nicht auf den Auto-Unlock warten wollte - hatte aber vergessen, Auto-Unlock in der App dann (einmalig) zu deaktivieren.

Zweite denkbare Variante wäre, dass (auch i.V.m. Auto-Unlock) das Handy das GPS-Signal verloren hatte und dachte, es sei außerhalb des Geo-Fence. Nach dem feststellen der korrekten GPS-Daten wurde dann Auto-Unlock ausgelöst.

An den 503er kann es nicht liegen, denke ich - habe ich auch immer wieder im Log, aber leider auch keine Ahnung warum.

Viele Grüße
Sascha

Raimund Scheiber

Hi Sascha,
Auto-Unlock ist bei mir deaktiviert, weil ich das Schließen/Öffnen bewusst steuern möchte...

Der 503-er Fehler dürfte wohl bei mehreren Leuten vorhanden sein (zumindest im Forum sind einige Threads zu lesen) - diesen Fehler hätte ich auf alle Fälle gerne behoben.

lg
raimund

Sascha_F

Hallo zusammen,

Ich dachte immer, der 503er käme, wenn die Bridge per WLAN nicht erreichbar ist. Den ist nicht so, oder?

Vor 3 Tagen wurde in der Nachbarschaft das KDG-Kabel geschreddert = ich bin offline. WLAN und LAN laufen natürlich weiter.

Mein Log läuft seit dem mit 503er quasi voll.

503 bezieht sich also auf externe Kommunikation?

Viele Grüße
Sascha

MAC66666

#966
Hi,
bin gerade etwas verwirrt:

Überall lese ich nur 6-Stellige API-Token, wenn ich einen Generiere hat der 50 Stellen oder so... Funktioniert natürlich auch nicht:

NUKIBridge (NBridge) - invalid json detected: HTTP 401 Unauthorized

Ich habe hier schon hin und her gesucht... Wo bekomme ich denn einen richtigen Token her?

Schnell vergessen, habe es hinbekommen!

FHEM @ Ubuntu 20.04 VM@ Windows 2019 Hyper-V @ NVMe
MAXCube als CUL_MAX (Thermostate)
MAXCube als SlowRF (FS20, wird durch ESPs ersetzt, teilweise geschehen)
Einige ESPs mit ESPEasy, zwei GHoma und ein Sonoff Tasmota

Weisswurstverkäufer

Hallo,

ich habe seit einiger Zeit das Problem, dass mein Log mit diesen Meldungen überflutet wird:


2018.02.26 08:04:46 3: Forbidden device wz_avr for WEBhook_192.168.42.95_30216


und zwar für ziemlich viele Geräte, und das ziemlich oft.

ich habe den WEBhook damals nach der Anleitung hier für die Nuki Bridge eingerichtet und 192.168.42.95 ist auch die NUKI Bridge. Ich habe in meinem allowedWEBhook mal auf get,set und allowedDevices * gestellt, das "hilft" aber auch nicht. Mache ich irgendwas falsch, oder ist hier nicht mal die richtige Stelle für das Problem?

hartenthaler

#968
Ich habe eben mein neues Nuki-Schloss und die Hardware-Bridge installiert (funktioniert so weit alles gut) und die Bridge in fhem eingebunden. Den API-Key habe ich auf der Bridge Web-Seite von Nuki erzeugt.

Dann ist mir fhem nach kurzem abgestürzt:

2018.02.26 23:09:27 3: NUKIDevice (NukiBridge) - invalid json detected for http://192.168.x.xxx:8080/callback/list?token=0bc2xxxxxxxxxxxxxxxxxxxxxxxxxxxxx: HTTP 403 Forbidden
Can't use string ("NUKIDevice (NukiBridge) - invali"...) as a HASH ref while "strict refs" in use at ./FHEM/73_NUKIBridge.pm line 683.

Ein callback habe ich nicht eingerichtet, müsste ich aber anscheinend wohl, zumindest scheint das mit dem Fehler zusammen zu hängen. Habe aber im wiki nichts dazu gefunden und von den über 60 Seiten im Forum habe ich nur rund 10 durchgelesen. Wo ist das mit dem callback erklärt? Und warum stürzt fhem gleich ab, wenn ich callback nicht konfiguriere?

Und mein Schloss ist auch nicht automatisch gefunden und in fhem angelegt worden (nur die Bridge konnte ich als fhem-Device korrekt anlegen).

Und ich habe hier im Forum gefunden:
http://192.168.x.xxx:8080/info?token=0bc2xxxxxxxxxxxxx oder statt info auch log oder list. Diese Abfragen führen bei mir zu einem 403- forbidden Fehler. Stimmt also etwas an meinem API-Key nicht?

Danke Hermann
fhem 5.8 auf RaspberryPi 3 mit HMLAN und CCU2, ZWave, JeeLink, FHZ1000 für FS20, HMS, Fritz!Box, Fritz!DECT200, Harmony, Sonos, hue, netatmo, SSCam, Wetter- und Verkehrsmodule, Chat-Bot mit RiveScript/Telegram, IFTTT, pushover, ...

CoolTux

Guten Morgen Herman,

Entweder ist Dein Token falsch, oder Du hast die Bridge nicht so eingestellt das man überhaupt von aussen zugreifen darf. Man muss in der Bridge den Developermodus oder so aktivieren.

Das FHEM abgestürzt ist werde ich heute im Laufe des Tages fixen. Sowas darf gar nicht passieren.


Grüße
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

MAC66666

Ich habe derweil auch ein Problem, ich bekomme statt einem Tür auf oder Tür zu Icon nur noch "initialized" angezeigt:

defmod NUKIDevice89706097 NUKIDevice 89706097 IODev=NBridge
attr NUKIDevice89706097 IODev NBridge
attr NUKIDevice89706097 alias XYZ
attr NUKIDevice89706097 devStateIcon unlock:fts_door_open lock:fts_door
attr NUKIDevice89706097 eventMap lock:zu unlock:auf
attr NUKIDevice89706097 icon fts_door_open
attr NUKIDevice89706097 room Eingang,FAVORITEN,NUKI
attr NUKIDevice89706097 webCmd auf:zu


FHEM @ Ubuntu 20.04 VM@ Windows 2019 Hyper-V @ NVMe
MAXCube als CUL_MAX (Thermostate)
MAXCube als SlowRF (FS20, wird durch ESPs ersetzt, teilweise geschehen)
Einige ESPs mit ESPEasy, zwei GHoma und ein Sonoff Tasmota

CoolTux

Zitat von: MAC66666 am 27 Februar 2018, 08:15:59
Ich habe derweil auch ein Problem, ich bekomme statt einem Tür auf oder Tür zu Icon nur noch "initialized" angezeigt:

defmod NUKIDevice89706097 NUKIDevice 89706097 IODev=NBridge
attr NUKIDevice89706097 IODev NBridge
attr NUKIDevice89706097 alias XYZ
attr NUKIDevice89706097 devStateIcon unlock:fts_door_open lock:fts_door
attr NUKIDevice89706097 eventMap lock:zu unlock:auf
attr NUKIDevice89706097 icon fts_door_open
attr NUKIDevice89706097 room Eingang,FAVORITEN,NUKI
attr NUKIDevice89706097 webCmd auf:zu


Das bringt mir rein gar nichts. list vom Nuki Device und Bridge und gut wäre noch ein log mit verbose 5
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

MAC66666

OK, DHCP hat eine andere Adresse zugewiesen. Habe jetzt meinem Router mal klargemacht, dass das so nicht geht  ;)

Schade dass man der Bridge selbst keine feste IP zuweisen kann...
FHEM @ Ubuntu 20.04 VM@ Windows 2019 Hyper-V @ NVMe
MAXCube als CUL_MAX (Thermostate)
MAXCube als SlowRF (FS20, wird durch ESPs ersetzt, teilweise geschehen)
Einige ESPs mit ESPEasy, zwei GHoma und ein Sonoff Tasmota

CoolTux

Zitat von: MAC66666 am 27 Februar 2018, 11:41:27
OK, DHCP hat eine andere Adresse zugewiesen. Habe jetzt meinem Router mal klargemacht, dass das so nicht geht  ;)

Schade dass man der Bridge selbst keine feste IP zuweisen kann...

Sagen wir mal so, Du kannst keine statische festlegen aber Du kannst Deinem DHCP Server sagen er soll eine feste Zuordnung zur entsprechenden MAC machen.
Denke mal das es das ist was Du nun gemacht hast.
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

CoolTux

Es wird morgen Früh ein keines Update geben. Darin wird lediglich decode_json() Errors abgefangen das diese nicht mehr zu einem Crash führen.
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net