[DISKUSSION] Eure Wünsche an HTTP-/REST-API SERVER und welche Geräte nutzt ihr

[blaubaerli]

Hallo Stefan,

ich habe da aktuell auf unseren iPhones die App „GeoFency“ im Einsatz. Das habe ich mit der neuen Funktion schon im Einsatz. Klappt prima! Das hatte ich vorher über KNX-Obbjekte und im Umweg über einen URL der CometVisu gelöst.

Zweites Szenario ist die Integration meiner Mobotix T24-Türstation. Da muss ich noch was fummeln.

Beste Grüße
Jens

[jhaeberle]

Wow! Starke Sache, das hört sich Mega an.

Ein Rest-API zum Zugriff auf den Wolf wäre MEGA. Die Sicherheitsrisiken, die damit einhergehen können, sind mir aber auch klar!

Cool wäre es tatsächlich, wenn man eine Liste der Logiken sowie einzelne Logiken lesen und schreiben könnte. Ebenso neu anlegen und Zuordnungen von Objekten machen könnte
Auch das Objektsystem per REST auslesen zu können wär hilfreich. Alle Subsysteme
Die Visu strukturiert auslesen (zu Dokuzwecken) - für's Schreiben hab ich hier grad eher keine Fanatasie…
Zugriff (gefiltert) auf den Busmonitor
Zeitserienkonfig auslesen, anlegen und Zuordnen

Eine Rest-API für den Wolf wär der Hammer…

[StefanW]

Ein Rest-API zum Zugriff auf den Wolf wäre MEGA. Die Sicherheitsrisiken, die damit einhergehen können, sind mir aber auch klar!

Hi, das was Du bescheibst, ist nicht dieses Thema. Es geht nicht darum, dass die Verwaltung des Timberwolf Servers per Rest-API nach außen geöffnet wird, zumal das sehr komplex wäre und kaum jemand was damit anfangen könnte.

Hier geht es um ein Subsystem für das Objektsystem, damit darum, dass man

1. Trigger über Webhooks setzen kann
2. Ein oder mehrere Werte in entsprechenen Objekten setzen kann
3. Auch ein oder mehrere Werte aus Objekten abfragen kann

Nur, damit wir nicht aneinander vorbei reden.

lg

Stefan

[jhaeberle]

Hallo @StefanW ,

sehr schade. Aber das, was du beschreibst, ist in meinen Augen kein Rest-API.

[DirkN]

Hallo,

das klingt vielversprechend.
Auf den ersten Blick sollte dann auch die Anbindung der aktuellen EKey-Generation möglich sein. Die können ja Trigger auf bestimmte Finger auslösen.
Eventuell lassen sich damit auch URL-Aufrufe wie "Tor öffnen" per Shortcut auf dem Android-Desktop umsetzen.

VG Dirk

[StefanW]

Aber das, was du beschreibst, ist in meinen Augen kein Rest-API.

Mit dieser Logik wäre die REST-API-Schnittstelle eines Wetterdienstes, über die Wetterdaten und Prognosen abrufbar sind, dann auch keine Rest-API, weil man den Server des Wetterdienstes darüber nicht steuern und das Klimamodell ("Logik") nicht verändern kann?

Rest-API bedeutet eine Datenaustauschschnittstelle. Es gibt keine allgemeingültige Definition, welcher Art die Daten sind und was damit möglich ist.

sehr schade

Nein, es ist konsequent.

Der Timberwolf Server hat ein Objektsystem. Die Steuerung des Servers selbst soll ebenfalls darüber - hier dann "Systemobjekte" erfolgen. So wie es diese seit zwei Wochen für Anforderung Backup und Rückmeldungen gibt.

Weil das den Sinn hat, dass durch die universelle Verknüpfbarkeit die Steuerung solcher Systemfunktionen, im Moment Backup, aus jedem Subsystem erfolgen kann. Damit aus der VISU genauso über einen Shelly per MQTT und genauso von einem KNX-Glastaster - oder von allen dreien gemeinsam.

Hätten wir nun eine Rest-API gebaut um Systemfunktionen anzusteuern, dass wäre eine solche Ansteuerung auf Rest-API begrenzt. Hätte jetzt bei Backup nicht gut geholfen, weil dann eben aus VISU usw. nicht direkt ansteuerbar. Außer von hinten durch die Brust ins Auge mit dem Ansteuern eines externen Servers aus der VISU, der dann per Rest-API auf das Backup einwirkt.

Da machen wir es doch lieber so, wie das - übrigens schon immer - geplant war, dass es zur Steuerung des Timberwolf Servers Systemobjekte geben soll, die dann dafür von jedem Subsystem aus nutzbar sind und damit für viele Protokolle offen stehen.

Weil das ist das Konzept des Timberwolf Servers. No Limits. Weil damit alles mit allem geht.


Was wir hier machen ist, dass der Nutzer die Möglichkeit bekommt, seine eigene Rest-API zu definieren für alles, was das Objektsystem hergibt. Das kann sehr umfassend sein. Wer möchte, kann alle seine KNX-Funktionen damit über eine Rest-API nach außen exposen. In beide Richtungen. Auch über komplexe Json Strukturen.

REST-API ist definiert als

1. Client-Server
2. Zustandslose Verbindung (mit einem Request und einem Response ist alles erledigt)
3. Daten können gecached sein
4. Es sind mehrere Sichten verfügbar
5. Kann auf mehrere Schichten aufsetzen
6. Effizient und Skalierbar
7. Nutzt standardisierte HTTP-Methoden wie GET, POST, PUT sowie HTTPS-Verschlüsselung und standardisierte Authentifizierung / Autorisierung

Dies alles wird mit dem neuen Subsystem erfüllt.

Stefan

[StefanW]

Hi Dirk,

das klingt vielversprechend.

Jep, ist sehr universell einsetzbar.

Auf den ersten Blick sollte dann auch die Anbindung der aktuellen EKey-Generation möglich sein.

Ja, auch auf den zweite Blick (weil bisherige Versuche im Labor sehen gut aus).

Die können ja Trigger auf bestimmte Finger auslösen.

Richtig, muss man eben für jeden Finger einrichten.

Eventuell lassen sich damit auch URL-Aufrufe wie "Tor öffnen" per Shortcut auf dem Android-Desktop umsetzen.

Richtig. Sollte kaum Grenzen geben.

lg

Stefan

[jhaeberle]

Hallo Stefan,

danke für die Belehrung

Was wir hier machen ist, dass der Nutzer die Möglichkeit bekommt, seine eigene Rest-API zu definieren für alles, was das Objektsystem hergibt. Das kann sehr umfassend sein. Wer möchte, kann alle seine KNX-Funktionen damit über eine Rest-API nach außen exposen. In beide Richtungen. Auch über komplexe Json Strukturen.

Na, das deckt ja meine Wünsche/Vorstellungen zu 100% ab.

Keineswegs käme es mir in den Sinn, Systemfunktionen des Wolfes ausschliesslich über Rest-API haben zu wollen. Aber eine alternative Möglichkeit, auf das System zuzugreifen. Allerdings lesend und schreibend.

Gruß
Jochen

[blaubaerli]

Hallo Stefan,

es ist fast schon wieder peinlich. Habe jetzt noch mal mit meiner alten Mobotix T24 getestet. Die kann wohl offensichtlich schlicht kein HTTPS-Ziel erreichen.

Ich kann der in einem "Netzwerkmeldungs-Profil" einen Ziel-Host und eine Portnummer mitgeben, aber eben nicht das Kommunikationsprotokoll. Die versucht nun also mittels HTTP auf 443 mit dem TWS zu kommunizieren und kommt mit einem 400er zurück.

Ich will hier keine Lanze für das alte Gerät brechen, nur über die Erfahrungen berichten, die ich beim Integrationsversuch eines "altertümlichen" Gerätes sammeln durfte.

In wie fern das repräsentativ für am Markt verfügbare Geräte wäre kann ich natürlich nicht einschätzen.

Beste Grüße
Jens

[StefanW]

Hi Jens,

ob wir auch http per Port 80 unterstützen können, muss man prüfen, bekommt man schon vom Nachdenken etwas Bauchweh.

Ich habe das weitergeleitet. Es gibt sicherlich mehr ältere Devices, die https nicht unterstützen, schon auch von der Rechenleistung her.

lg

Stefan