wiederverwendbares Mapping a la ReadingsGroup

[ntruchsess]

also ein API ist erst mal nur ein Interface, kein konkretes Device. Das würde ich als mit 'use' einbindbares perl-modul implementieren, dass die FHEM-internas komplett abkapselt. Natürlich wurd man das im ersten Schritt über ein FHEM-device konfigurieren, aber diese implementierende Seite des API wäre dann vom Design her austauschbar (sonst würde man sich den Weg zu einfacheren Konfigurationskonzepten schon zu Begin verbauen).

Auf dem API setzen dann z.B. Protokolle wie Websockets auf. Da das API ein perl-api (und nicht ein remote-protokoll) ist, können natürlich auch andere als FHEM-devices implementierte Frontends oder Schnittstellen wie MQTT darauf zugreifen und es zugänglich machen. Als Nutzer einer solchen Schnittstelle (das kann dann auch ein auf MQTT zugreifender Developer sein) muss man dafür kein Wissen über die FHEM-internen Datenstrukturen haben.

Wenn es um Websockets geht, dann natürlich primär über JSON (xml wäre genauso denkbar...). Meinen als schlankes in die FHEM-main-loop integriertes Device implementierten Websocket-stack habe ich protokollunabhängig designed, da kann man dann beliebige APIs mit geringem Aufwand reinpluggen und ohne Einschränkungen zugänglich machen.

Gruß,

Norbert

[Dr. Boris Neubert]

Hallo,

mich stört daran, dass man bei der Verwendung von Websockets die Kommunikation/das Protokoll ausprogrammieren muss. Ich habe mir im Vergleich dazu eben SOAP::Lite angesehen (http://www.perl.com/pub/2001/01/soap.html). Da bräuchte man in FHEM ein API-Package mit Wrappern für die offenzulegenden Funktionen und könnte diese dann auf dem Client genau so aufrufen, fast ohne zu merken, dass der Code gar nicht selben FHEM-Prozess sondern in einem ganz anderen Programm auf einem ganz anderen Rechner läuft. Leider ist SOAP nicht bidirektional, so dass der Client pollen müsste, um Notifies zu erhalten. Ich bin in diesen Themen leider nicht bewandert. Gibt es da ein Bestes aus beiden Welten?

Viele Grüße
Boris

[Dr. Boris Neubert]

Hallo,

ich antworte mir mal selbst.

Es scheint so, dass das in Prototypen hier schon verwendete Websockets die Methode der Wahl ist. Für RPC gibt es z.B. JSON::RPC (JSON-RPC 2.0). Leider ist die Integration nicht so transparent möglich, wie bei SOAP::Lite.

Viele Grüße
Boris

[ntruchsess]

Prinzipiell könnte man natürlich auch SOAP (=Protokol) über Websockets (=Transport) sprechen. Allerdings ist SOAP ein sehr geschwätziges Protokol, bringt also relativ viel Overhead mit sich. (Und es gibt für die Kombination eh noch kein fertig nutzbares perl-modul).

JSON-RPC 2.0 als Protokoll um die API remote zu nutzen finde ich auch gut. Das macht es zukünftigen Verwendern leichter als was selbstgestricktes.

Das ganze ist bei mir jetzt leider ein paar Wochen liegengeblieben. Ich bin über Weihnachten zu vielem, nur nicht zum Programmieren gekommen

- Norbert

[Dr. Boris Neubert]

Hallo Norbert,

ggf. können wir unsere Aktivitäten bündeln und eine FHEM/JSONAPI.pm entwickeln, das es uns ermöglicht, isolierte Komponenten (FHEMWEB - Javascript im Browser, Subprocess - Aufrufendes Modul, ...) immer mit dem gleichen Protokoll miteinander sprechen zu lassen.

Siehe

http://forum.fhem.de/index.php/topic,34320.msg271321.html#msg271321

Grüße
Boris

[justme1968]

der thread ist leider wieder ziemlich alt geworden aber ich möchte ihn trotzdem noch mal aus der versenkung holen.

edit: ich habe das ganze in einen eigenen thread verschoben: http://forum.fhem.de/index.php/topic,39236.0.html.

gruss
  andre