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

[casi]

Sieht soweit ok aus. Und wenn Du bei der Bridge nun get callBacklist ausführst kommt eine Fehlermeldung?

Es kommt immer noch die Meldung "No callback data available or error during processing"

Mach mal bitte bei der Bridge das Attribut verbose auf 5 setzen und dann ein get callBacklist und schaue ins Log was dazu steht.

habe verbose auf 5 gesetzt und neu gestartet...
Beim Hochfahren kam folgender log: (einmal steht dort error)

Code Auswählen Erweitern

2019.11.29 13:46:44 5: NUKIBridge (NukiBridge) - Response JSON: [{"deviceType": 0, "nukiId": 543210005, "name": "Nuki", "firmwareVersion": "2.6.4", "lastKnownState": {"mode": 2, "state": 3, "stateName": "unlocked", "batteryCritical": false, "timestamp": "2019-11-29T12:45:16+00:00"}}, {"deviceType": 2, "nukiId": 543210078, "name": "Opener", "firmwareVersion": "1.2.7", "lastKnownState": {"mode": 2, "state": 1, "stateName": "online", "batteryCritical": false, "timestamp": "2019-11-29T10:28:53+00:00"}}]
2019.11.29 13:46:44 5: NUKIBridge (NukiBridge) - Response ERROR:
2019.11.29 13:46:44 5: NUKIBridge (NukiBridge) - Response CODE: 200
2019.11.29 13:46:44 3: NUKIDevice (NukiBridge) - NukiId '543210005' already defined as 'NUKIDevice543210005'
2019.11.29 13:46:44 3: NUKIDevice (NukiBridge) - NukiId '543210078' already defined as 'NUKIDevice543210078'
2019.11.29 13:46:44 4: NUKIBridge (NukiBridge) - Send HTTP POST with URL http://192.168.178.150:8080/info?token=abcdef

Befehl get callbacklist ausgeführt, folgender log:

Code Auswählen Erweitern

2019.11.29 13:58:10 4: NUKIBridge (NukiBridge) - Send HTTP POST with URL http://192.168.178.150:8080/info?token=abcdef
2019.11.29 13:58:10 4: NUKIBridge (NukiBridge) - run NUKIBridge_Call
2019.11.29 13:58:10 4: NUKIBridge (NukiBridge) - Call InternalTimer for NUKIBridge_GetCheckBridgeAlive
2019.11.29 13:58:10 5: NUKIBridge (NukiBridge) - Response JSON: {"bridgeType": 1, "ids": {"hardwareId": 441180000, "serverId": 2299079111}, "versions": {"firmwareVersion": "2.4.8", "wifiFirmwareVersion": "2.1.4"}, "uptime": 578675, "currentTime": "2019-11-29T12:58:08+00:00", "wlanConnected": true, "serverConnected": true, "scanResults": [{"deviceType": 2, "nukiId": 543210078, "name": "Nuki_Opener_1CAAFFFF", "rssi": -73, "paired": true}, {"deviceType": 0, "nukiId": 543210005, "name": "Nuki_1AF3FFFF", "rssi": -55, "paired": true}]}
2019.11.29 13:58:10 5: NUKIBridge (NukiBridge) - Response ERROR:
2019.11.29 13:58:10 5: NUKIBridge (NukiBridge) - Response CODE: 200
2019.11.29 13:58:10 5: NUKIBridge (NukiBridge) - Bridge ist online
2019.11.29 13:58:10 4: NUKIDevice (NUKIDevice543210078) - Received scanResults for matching NukiID 543210078 at device NUKIDevice543210078
2019.11.29 13:58:10 4: NUKIDevice (NUKIDevice543210005) - Received scanResults for matching NukiID 543210005 at device NUKIDevice543210005
2019.11.29 13:58:18 5: NUKIBridge (NukiBridge) - Data: {"callbacks": []}
2019.11.29 13:58:18 4: NUKIBridge (NukiBridge) - Blocking HTTP Query finished
2019.11.29 13:58:18 4: NUKIBridge (NukiBridge) - Callback data is collected and processed

und immer noch die Meldung "No callback data available or error during processing"

[CoolTux]

Hat er Recht. Es sind keine Daten zum Callback vorhanden. Kannst du bitte eines der Weebhook Attribute noch mal setzen und dann im Log noch mal schauen.

[casi]

Hat er Recht. Es sind keine Daten zum Callback vorhanden. Kannst du bitte eines der Weebhook Attribute noch mal setzen und dann im Log noch mal schauen.

Oha, ich hatte die Attribute vorher einfach in die fhem.cfg geschrieben...
hat ihm wohl nicht gereicht!!  , trotz Hoch- und Runterfahren..
Habe nun im Device Nuki die Attribute nochmal über die FHEM Oberfläche gesetzt und siehe da, es kommt was zurück!
Allerdings doppelt:

Code Auswählen Erweitern

0 http://192.168.178.147:8086/fhem/NUKIDevice-543210005
1 http://192.168.178.147:8086/fhem/NUKIDevice-543210005

Ich denke ich mache dann "set NukiBridge callbackRemove 1" ?

Im log steht aber immer noch der response error:

Code Auswählen Erweitern

2019.11.29 14:49:49 5: NUKIBridge (NukiBridge) - Data: {"callbacks": [{"id": 0, "url": "http://192.168.178.147:8086/fhem/NUKIDevice-543210005"},{"id": 1, "url": "http://192.168.178.147:8086/fhem/NUKIDevice-543210005"}]}
2019.11.29 14:49:49 4: NUKIBridge (NukiBridge) - Blocking HTTP Query finished
2019.11.29 14:49:49 4: NUKIBridge (NukiBridge) - Callback data is collected and processed
2019.11.29 14:49:49 4: NUKIBridge (NukiBridge) - created Table with log file
2019.11.29 14:49:50 4: NUKIBridge (NukiBridge) - NUKIBridge_GetCheckBridgeAlive
2019.11.29 14:49:50 4: NUKIBridge (NukiBridge) - Send HTTP POST with URL http://192.168.178.150:8080/info?token=abcdef
2019.11.29 14:49:50 4: NUKIBridge (NukiBridge) - run NUKIBridge_Call
2019.11.29 14:49:50 4: NUKIBridge (NukiBridge) - Call InternalTimer for NUKIBridge_GetCheckBridgeAlive
2019.11.29 14:49:50 5: NUKIBridge (NukiBridge) - Response JSON: {"bridgeType": 1, "ids": {"hardwareId": 441180000, "serverId": 2299079111}, "versions": {"firmwareVersion": "2.4.8", "wifiFirmwareVersion": "2.1.4"}, "uptime": 581771, "currentTime": "2019-11-29T13:49:48+00:00", "wlanConnected": true, "serverConnected": true, "scanResults": [{"deviceType": 2, "nukiId": 543210078, "name": "Nuki_Opener_1CAAFFFF", "rssi": -73, "paired": true}, {"deviceType": 0, "nukiId": 543210005, "name": "Nuki_1AF3FFFF", "rssi": -55, "paired": true}]}
2019.11.29 14:49:50 5: NUKIBridge (NukiBridge) - Response ERROR:
2019.11.29 14:49:50 5: NUKIBridge (NukiBridge) - Response CODE: 200
2019.11.29 14:49:50 5: NUKIBridge (NukiBridge) - Bridge ist online
2019.11.29 14:49:50 4: NUKIDevice (NUKIDevice543210078) - Received scanResults for matching NukiID 543210078 at device NUKIDevice543210078
2019.11.29 14:49:50 4: NUKIDevice (NUKIDevice543210005) - Received scanResults for matching NukiID 543210005 at device NUKIDevice543210005

Zusatzfrage: wie kann ich jetzt mein WEBnuki absichern, wenn nicht mit Passwort?
Wie funktionieren allowedCommands oder allowedHttpMethods ?

Vielen Dank für deine Hilfe CoolTux 

[CoolTux]

Und wieder so ein typischer Fall warum ich sowas nicht mag wenn Leute die Konfig von Hand editieren. Aber egal.

Die Error Meldung ist keine. Die Debugmeldung sagt zwar Error, aber es fehlt dahinter ja der Fehler. Also gibt es keinen. Alles schick.

Absichern kannst mit einem allowed Device. Da kannst den Zugriff auf eine einzige IP beschränken zum Beispiel.

[casi]

Und wieder so ein typischer Fall warum ich sowas nicht mag wenn Leute die Konfig von Hand editieren. Aber egal.

Sorry, hab mal irgendwann so mit fhem angefangen....

Absichern kannst mit einem allowed Device. Da kannst den Zugriff auf eine einzige IP beschränken zum Beispiel.

Habe im WEBnuki das Attribut allowfrom und dann die IP Adresse der NukiBridge angelegt!
Scheint zu funktionieren!!
Vielen vielen Dank für deine Hilfe CoolTux!!

[OdfFhem]

@eddy242 bzw. @all

Seit ca. einer Woche habe ich nun die neue Firmware für die v2-Bridges am Start. Und bislang muss ich sagen, dass diese neue Version deutlich besser läuft - die Uptime erreicht Höchststände, die bislang als unerreichbar galten. Ebenfalls führen Aktionen ohne erzwungene Pause zum erwarteten Ziel.

Ob mit der neuen Firmware alle Probleme behoben sind, kann ich natürlich nicht sagen, aber wer eine v2-Bridge hat, sollte der neuen Version vielleicht eine Chance geben ...

[RappaSan]

Bei mir läuft seit einigen Tagen ebenfalls die neueste Beta-fw. für die v2 Bridge.
Bisher keinerlei Probleme, deutlich stabiler als vorher.
Fazit: Empfehlenswert.

[Thyraz]

Hallo zusammen.

Wie zuverlässig und läuft denn der Webhook zu FHEM und die Steuerung über FHEM?
Bin gerade am überlegen ob ich nun ein Zwave Schloss oder Nuki 2.0 + Bridge kaufe.

Nuki mit Handyannäherung sieht nach einer schönen Lösung aus, die man mit einem reinen Zwave / oder Homematic Schloss funktionell nicht so einfach erreicht.
Auch die Möglichkeit es zusätzlich zu FHEM auch noch direkt in HomeKit einzubinden sowie die Bluetooth Verbindung vom Handy nutzen zu können bringt Ausfallsicherheit.
Würde also im Moment stark zu Nuki tendieren.

Bin nur bei solchen "Startup-Produkten" aber dann schon öfters enttäuscht gewesen was die Zuverlässigkeit und Anbindung ans SmartHome angeht.
Daher die Frage ob Nuki es schafft hier als Positivbeispiel herauszustechen.

[OdfFhem]

@RappaSan

Ich setze übrigens keine Beta ein, sondern die offizielle 2.4.8.

Wichtig ist wohl noch, dass man darauf achten muss, nicht bei der Zwischenversion 2.3.0 hängenzubleiben.

[OdfFhem]

@Thyraz

Ich nutze die Nuki-Lösung und die macht bis jetzt das, was ich mir erwartet hatte.

Allerdings nutze ich derzeit keine Automatismen in diesem sicherheitskritischen Bereich. Zur Schloss-Steuerung verwende ich ausschließlich Keypad, Fob sowie die App; FHEM bekommt dann via Webhook zeitnah und zuverlässig Zustandsänderungen des Schlosses mitgeteilt. Falls man wollte, könnte man natürlich auch das Schloss von FHEM aus steuern.

Ob das jetzt aus Deiner Sicht ein Positivbeispiel ist, kann ich nicht genau sagen und Du wahrscheinlich erst, wenn es bei Dir im Einsatz ist ...

[Thyraz]

Habs jetzt einfach gewagt und das Nuki gekauft.
Macht erstmal einen sehr guten Eindruck, und das FHEM Modul inkl. Webhook lies sich einwandfrei einrichten.

Danke dafür Cooltux.

Nun erstmal testen wie zuverlässig die Autofunktionen laufen, oder ob ein Fob irgendwann doch Sinn macht.

[Thyraz]

Ich muss sagen das Ganze gefällt mir schon sehr gut nach der kurzen Zeit.

Da wir die Eltern oft zum Babysitten hier haben, würde sich das auch sehr gut machen als Zutrittserlaubnis für Dritte.
Dummerweise ist in unserem Mehrfamilienhaus eine Elcom Freisprecheinrichtung verbaut, welche nicht mit dem Nuki Opener kompatibel ist.

Ich hab allerdings den Elcom Bus soweit umgangen, dass ich eine alte Sprechstelle zerlegt und mit unserer Teilnehmeradresse an den Bus gehängt habe.
Da diese Sprechstelle noch einen manuellen Taster für den Türöffner hatte sowie ein Rufschaltrelais, welches beim Türklingeln aktiviert wird, könnte ich den Opener hier evtl. anschließen.
Allerdings findet man auf der Homepage nirgends Schaltpläne wie das Ding angeschlossen werden soll.

Hat das Teil einen potentialfreien Relaiskontakt, mit welchem ich den Türöffner auslösen könnte?
Und kann man eine Spannung die das Teil ausgibt (oder die Spannungsversorgung) über das Rufschaltrelais der Sprechstelle auf einen Eingang des Openers führen, so dass er das Klingeln erkennt?

An sich sollte das ja möglich sein, soweit ich das sehe ist der Opener ja nicht nur mit neueren Bus-basierten Systemen kompatibel, sondern auch mit gutem alten 12V Klingeldraht...


Ich könnte das natürlich auch mit FHEM und Relais + einem Input realisieren.
Aber wenn ich das dem Rest des Haushaltes und unseren Eltern zumute, wäre eine App für beide Türen (Haus + Wohnung) doch die schönere Lösung.

[Thyraz]

Ok, hab jeweils sehr schnell (innerhalb ein paar Stunden) Rückmeldung vom Support auf meine Fragen bekommen.
Daumen hoch dafür.

Passt wohl nicht zu 100% in den Thread, aber falls noch jemand den Opener selbst beschalten will statt ihn wie vorgesehen an unterstützte Systeme anzubinden ist das sicher hilfreich.
Die Doku des Openers schweigt ja zum internen Aufbau der Pinbeschaltung...


Man wählt als Intercom-Typ in der der App Generisch/Ananlog, damit der Opener im richtigen Modus arbeitet.
Folgende Adern sind dann interessant:

- Gelb (Ring-Signal) geht auf einen Optokoppler Eingang der scheinbar einen großen Spannungsbereich als High-Signal wertet.
  Ich hatte gefragt ob die 5V die ich vom USB-Netzteil des Openers abgreifen könnte reichen,
  wenn ich sie über einen Relaiskontakt (Das Rufschaltrelais meiner Sprechanlage) auf die gelbe Leitung führe, was bestätigt wurde.

- Blau (Türöffner) ist ein Solid-State-Relais-Kontakt der Blau mit Violett (GND) kurschließt.
 
- Violett (GND) Gelb und Blau teilen sich diesen Kontakt als gemeinsame Masse.

Die gemeinsame Masse kann etwas beschränkend sein, ein komplett potentialfreier Relaiskontakt wäre schöner,
aber ist bei der normalen Anwendung des Openers eben nicht nötig.

Es ist aber zumindest möglich vor den Opener Pin einen Verbraucher zu hängen und das Relais zum Masse schalten verwenden.
Notfalls eben ein Relais daüber schalten um die galvanische Trennung zu erreichen.

Damit sollte man auch auf nicht unterstützen Bussystemen zurecht kommen indem man die vorhandene (oder eine weitere parallel angeschlossene) Sprechstelle als "Bus-Gateway" missbraucht.

Btw. die Ring-to-Open Idee in Verbindung mit dem Geofence ist eine echt clevere Idee.

[Thyraz]

Hallo Leon,

hab mir gerade mal ein wenig die Module angeschaut und was nötig wäre den Opener mit einzubauen.

Im Moment ist es so, dass der Webhook pro Device in der Bridge hinterlegt wird.
In der Doku ist mir aufgefallen, dass der webhook eher generisch gedacht ist und für alle vorhandenen Nuki Devices aufgerufen wird.

Ich schätze mal, dass wenn jemand heute schon 2 SmartLocks in FHEM hätte, dies 2 Webhooks erzeugen würde und dann egal welches Schloss triggert beide Webhooks aufgerufen werden.

Welches Nuki Device den Webhookgetriggert hat, kann man dann in der Webhook Funktion, da die Nuki-ID von der Bdrige im JSON mit übergeben wird:

Code Auswählen Erweitern


/callback
The following endpoints provide methods to register up to 3 http (no https) url callbacks, which will be triggered once the lock state of one of the known Smart Locks changes.

The new lock state will be sent to the callback url by executing a POST request and posting a JSON list in the following format:

{"nukiId": 11, "deviceType": 0, "mode": 2, "state": 1, "stateName": "locked", "batteryCritical": false}


Ich denke man müsste die Callback Attribute + Registrierung dann wahrscheinlich von NUKIDevice nach NUKIBridge verschieben, oder?

edit: NUKIDevice_addExtension / NUKIDevice_removeExtension erstellen ja auch nur einen Endpoint (was beim löschen von nur einem NUKIDevice statt aller NUKIDevices evtl. aktuell zu auch Problemen führen könnte?), die könnte man auch gleich mit umziehen?

edit2: Weiß nicht wieviel Zeit ich über die Ferienzeit habe und ob du überhaupt Interesse daran hast, wenn dir hier jemand unter die Arme greift.
Würde den Opener jedenfalls gern in FHEM lauffähig bekommen.
Du kämpfst gefühlt jedenfalls an vielen Fronten gleichzeitig in FHEM.

Die Fragen zielen also darauf ab, ob meine Interpretationen nach schnellem Überfliegen des Codes soweit stimmig zu sein scheinen und die Änderungen für dich in Ordnung gehen.

Grüße,
Tobias

[CoolTux]

Hallo Tobias,

Für Hilfe bin ich immer sehr dankbar. Deine Aussage zum Webhook macht für mich Sinn, und dann sollte das in der Tat in die Bridge.
Ich will schon ein Jahr lang das Modul umbauen da die Umsetzung des 2 stufigen Konzepts nicht FHEM Konform ist. Ich komme einfach nur nicht dazu.
Wenn Du also Änderungen machen willst sehr gerne, kannst dann einfach einen Pull Request in Github hinterlegen.


Grüße
Marko