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

[samh]

Leon,

jetzt haben wir die letzten Tage ja jede Menge Spaß gehabt und nun tut alles was es soll.

Hab noch mal Bridge und Device neu eingerichtet. Das hat's gebracht !
Webhook funtioniert und in allen Fällen wird der Status korrekt gesetzt.

Bin begeistert. Wenn NUKI uns die Info als Weihnachtgeschenk im Newsletter mal verraten hätte. 

Vielen herzlichen Dank an Dich.

Gruß Sam

[CoolTux]

Na siehste. Alles supi. Freue mich sehr das es klappt. Heute Abend mache ich dann die Sache rund. Also das Patch weg. Habe ja auch ne Menge aufgeräumt und Code bereinigt.



Grüße

[CoolTux]

Ich habe soeben in den GitHub Master Branch Version 0.4.5 geladen. Wäre schön wenn das so 2-3 Leute testen könnten. Gerade die Software Bridge User und ein Hardware Bridge User.

Danke

[fred_feuerstein]

Gerade eingespielt und getestet:

- per FHEM schalten: OK!
- per App schalten: OK, Status wird in FHEM gesetzt!
- per Api schalten: OK, Status wird in FHEM gesetzt!

von meiner Seite keine Probleme.

DANKE!

[CoolTux]

Ich danke Dir. Schon mal einer mit ner Hardware Bridge.



Grüße

[Stephan1965]

Hallo Leon,
ich habe gerade FHEM aktualisiert (und neu gestartet) und bekomme dann im FHEM Startbildschirm folgende Meldung:

Code Auswählen Erweitern

Messages collected while initializing FHEM:
configfile: webhookFWinstance can only use with hardware bridge
webhookHttpHostname can only use with hardware bridge

Ich habe eine Hardware Bridge.

Viele Grüße

Stephan

[CoolTux]

Hast du in der Bridge auch das Reading dafür?
Davon ganz ab nimm mal bitte die GitHub Version. Die FHEM Version ist etwas falschsagend bezüglich webhook. Ich Update die Tage.

[Sascha_F]

Hallo allerseits,

sorry! Bin leider ausgefallen, die letzte Zeit.

Nur zur Info: Bei mir ist die aktuell "nur" die Version des aktuellsten FHEM-Updates drauf. Die Meldung, welche Stephan1965 oben erwähnt hat, ist bei mir auch vorhanden.

Das wichtigste natürlich noch: Ein frohes und gesundes neues Jahr wünsche ich!

Viele Grüße
Sascha

[CoolTux]

Hallo Leute,

Da sich schon 2 Leute gemeldet haben werde ich heute Abend bereits die neuste Version ins FHEM SVN einchecken.
Kurze Frage an die Leute die die Meldung bekommen haben aber dennoch eine Hardware Bridge haben. Ist das Attribut trotzdem erhalten geblieben? Steht es noch im Smartlock Device drin?

[CoolTux]

@ALL
Ich habe soeben die Version 0.4.5 ins SVN eingecheckt. Support für Callback/Webhook für die Software Bridge. Ausserdem diverse Codebereinigungen und einige set Befehle werden nicht angezeigt wenn sie von der entsprechenden Bridge nicht unterstützt werden.



Grüße
Leon

[Sascha_F]

Hab ich was überlesen? Welches Attr meinst Du denn im Device?

[CoolTux]

Die beiden Attribute webhook*

[Sascha_F]

Oh, jetzt, wo Du es sagst!

Im Device:
webhook_counter 3
webhook_last 2017-01-12 07:17:04
webhook_register unregistered

Schaltvorgänge (App, FHEM und lock'n'go) werden aber registriert und in FHEM korrekt angezeigt - Bedienung über FHEM auch problemlos.

Viele Grüße
Sascha

[CaptainCarrot]

Servus,

ich lese hier schon ziemlich seit Beginn mit und habe ein Smartlock mit HW-Bridge im Einsatz, bisher hab ich nicht geschrieben, weil ihr mit dem Problemlösen schneller wart als ich mit der Integration meines NUKIs in FHEM . Finde ich total super, das Feedback wollte ich auch mal geben!
Bei der Webhook-Funktion war ich jetzt allerdings wohl auch bei der Implementierung mal einer der ersten, daher noch ein kleines Feedback dazu:

1. Es wäre praktisch, wenn man den PORT noch als attr setzen könnte, wenn man die Standard-Instanzen per Passwort gesichert hat muss man sonst basteln. Ich hatte das TabletWEB-Interface noch nicht gesichert, also läuft es jetzt darüber, würde das aber lieber über einen anderen Port auf mein "normales" intern ungesichertes Webinterface laufen lassen. Ist bei Neueinrichtungen kein Problem, aber bei bestehenden Systemen.

2. Ich musste ebenfalls Bridge und Smartlock nochmal löschen und neu anlegen, um die Webhooks zum funktionieren zu bringen, obwohl eigentlich alle attr und readings richtig aussahen. Scheinbar war aber der Webhook nicht erreichbar, das gab dann auf der Bridge den Error 503 und das Smartlock-Device hat den Webhook auch immer wieder neu in die Bridge eingetragen, der Stand da ständig 3 mal drin. Also vielleicht als Hinweis an alle, die ebenfalls ein schon etwas länger bestehendes NUKI-Schloss mit Webhooks versorgen wollen: Erst Locks und Bridge nochmal komplett neu anlegen.

Ansonsten: Weiter so, tolle Arbeit!

Viele Grüße
Joachim

[CoolTux]

Servus,

ich lese hier schon ziemlich seit Beginn mit und habe ein Smartlock mit HW-Bridge im Einsatz, bisher hab ich nicht geschrieben, weil ihr mit dem Problemlösen schneller wart als ich mit der Integration meines NUKIs in FHEM . Finde ich total super, das Feedback wollte ich auch mal geben!
Bei der Webhook-Funktion war ich jetzt allerdings wohl auch bei der Implementierung mal einer der ersten, daher noch ein kleines Feedback dazu:

1. Es wäre praktisch, wenn man den PORT noch als attr setzen könnte, wenn man die Standard-Instanzen per Passwort gesichert hat muss man sonst basteln. Ich hatte das TabletWEB-Interface noch nicht gesichert, also läuft es jetzt darüber, würde das aber lieber über einen anderen Port auf mein "normales" intern ungesichertes Webinterface laufen lassen. Ist bei Neueinrichtungen kein Problem, aber bei bestehenden Systemen.

2. Ich musste ebenfalls Bridge und Smartlock nochmal löschen und neu anlegen, um die Webhooks zum funktionieren zu bringen, obwohl eigentlich alle attr und readings richtig aussahen. Scheinbar war aber der Webhook nicht erreichbar, das gab dann auf der Bridge den Error 503 und das Smartlock-Device hat den Webhook auch immer wieder neu in die Bridge eingetragen, der Stand da ständig 3 mal drin. Also vielleicht als Hinweis an alle, die ebenfalls ein schon etwas länger bestehendes NUKI-Schloss mit Webhooks versorgen wollen: Erst Locks und Bridge nochmal komplett neu anlegen.

Ansonsten: Weiter so, tolle Arbeit!

Viele Grüße
Joachim

Hallo Joachim,

Das ändern des Webhook Ports hatte ich in früheren Versionen drin. Da man aber nun bequem alle vorhandenen FHEM WEB Instanzen auswählen kann ergibt sich der Port ja automatisch. Man kann ja nur den Port nehmen den die Webinstanz anbietet und den lese ich automatisch aus.
Wenn ich mir Punkt 1 bei Dir so durchlese, gehe ich davon aus das Du etwas im Modulcode angepasst hast um einen anderen Port aus zu wählen. Daraus ergibt sich aber ein Problem. Beim define eines jeden Smartlock Devices wird eine Art Marker gesetzt, Anhand dieses Markers wird erkannt ob das Device Berechtigt ist ein Webhookaufruf an zu nehmen. Hier wird dann wohl auch Dein 503 her gekommen sein.

Um zusammen zu fassen. Sobald ich eine FHEM Webinstanz ausgesucht habe (es werden alle vorhandenen aufgelistet) steht automatisch der Port fest, und dieser wird dann beim anlegen des webhooks ausgelesen.



Grüße
Leon