Wie am besten mit einem HTTP Callback umgehen?

[CoolTux]

Hallo,

Mit der neuen Firmwareversion 1.0.3 der Nuki Bridge ist es möglich eine Callback URL mit an zugeben

/callback
The following endpoints provides methods to register up to 3 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, "state": 1, "stateName": "locked", "batteryCritical": false}

Example-Call
http://192.168.1.50:8080/callback/add?url=http%3A%2F%2F192.168.
0.20%3A8000%2Fnuki&token=123456

Meine Frage ist nun, wie kann ich das in FHEM einarbeiten, außer mit einem eigenen Server Socket. Gibt es da eine andere Lösung, will nicht ständig irgendwelche Ports belegen.



Grüße

[Loredo]

Habe ich bereits als FHEMWEB CGI Erweiterung in mehreren meiner Module eingebaut (z.B. GEOFANCY, HP1000 Wettermodul oder Pushover).

Gerade jüngst erst wieder im gestern veröffentlichten THINKINGCLEANER Modul zur Nutzung der dortigen Webhook Funktion. Dort dürfte es auch recht überschaubar zu begutachten sein. Die Frage über die FHEMWEB Instanzen bezog sich auch darauf



Gruß
Julian

[CoolTux]

Supi, vielen Dank Dir. Schaue ich mir gleich mal an.


Grüße

[Loredo]

Du musst allerdings schauen, ob du für jedes definierte Device später einen eigenen Webhook brauchst (oder willst), oder ob es möglich ist das jeweilige Fhem Gerät anhand einer übermittelten UUID o.ä. klar zu identifizieren und somit zu suchen. Das ThinkingCleaner Modul sendet eine solche UUID, weshalb ich bei einer bereits vorhandenen Registrierung eines CGIs die Registrierung eines weiteren nicht mehr zulasse. Beim HP1000 ist das genauso, da die URL wiederum von der Wetterstation ansich schon so vorgegeben ist, dass man eh nicht mehr als eine in FHEM benutzen kann.


In den Modulen Pushover und GEOFANCY ist diese Restriktion nicht drin, dort registriert jedes Device einen eigenen Infix für sich.

[CoolTux]

Ich bekomme eine eindeutige ID mit übermittelt wo ich dann entsprechend die korrekte Deviceinstanz ansprechen kann.

Habe mal eben überflogen. Kann es sein das der webhook zwar getriggert wird aber Du daraufhin beim entsprechenden Device ein statusRequest machst? Bei mir wäre es so das mit dem Trigger auch der komplette Datenstrom mit kommt den ich dann gleich verarbeiten kann.

Ich schaue nachher noch mal in Ruhe, mein Akku vom Lapi war gerade zu Ende 



Grüße

[Loredo]

Ja, leider liefert der ThinkingCleaner unsinniger Weise keine Werte mit und will nur bescheid geben, dass man sich die Werte jetzt gefälligst abholen kann... 


Wenn ich die Werte bekommen hätte, dann hätte ich die einfach in die von HttpUtils zur Antwortverarbeitung angesteuerte THINKINGCLEANER_ReceiveCommand() Funktion weitergereicht, um dann die Auswertung dort möglichst zentral zu machen.

[CoolTux]

Macht Sinn. Genau so will ich es ja auch machen.
Letzte Frage habe ich, wie gesagt bin nur kurz zum schauen gekommen. Kann nachher auch selber schauen. Machst Du einen extra Webhook auf oder benutzt Du schon eine vorhandene Webinstanz.

[Loredo]

Ich lasse den User eine vorhandene FHEM Instanz per Dropdown in den Attributen auswählen, damit die Selbstregistrierung des Moduls am ThinkingCleaner Gerät dann klappt. Grundsätzlich ist der Webhook aber über alle FHEMWEB Instanzen gleich erreichbar. Es geht dann also nur darum dem ThinkingCleaner die nach außen hin korrekte URL inkl. Port mitteilen zu können.


Nur beim HP1000 Modul ist der webname durch die Wetterstation fest vorgegeben, weshalb der User hier noch händisch eine geeignete FHEMWEB Instanz anlegen muss. Aus Modulsicht reagiere ich hier aber auch einfach auf alle FHEMWEB Instanzen gleich und habe einfach nur verhindert, dass mehrere HP1000 Devices überhaupt angelegt werden können.

[CoolTux]

Ich danke Dir sehr für Deine ausführliche Beschreibung. Werde mich dann die Tage damit mal auseinander setzen. Noch ist API Version ja Beta 


Grüße