UPGRADE IP 9 verfügbar!
Timberwolf VISU jetzt mit NEUEM Layout Editor
Freie Anordnung, Reihenfolge und Größe der Widgets - viele weitere Verbesserungen
Infos im Wiki: https://elabnet.atlassian.net/l/cp/06SeuHRJ

NEU! Insider & Leistungsmerkmale FÜR ALLE freigeschaltet
Damit kann nun jeder das Upgrade vornehmen und VISU & IFTTT testen. Alle Info hier: viewtopic.php?f=8&t=5074

[FR] LE: Logikbaustein HTTP(S) Request

Hier bitte Eure Diskussionen und Feature Requests zu neuen Logikmodulen und Funktionen des Logik-Editors
Antworten

Ersteller
alexbeer
Reactions:
Beiträge: 394
Registriert: Mi Sep 12, 2018 1:11 am
Wohnort: NRW
Hat sich bedankt: 212 Mal
Danksagung erhalten: 251 Mal

LE: Logikbaustein HTTP(S) Request

#1

Beitrag von alexbeer »

Hallo,
basierend auf dem Thread viewtopic.php?f=24&t=1848&start=20#p19867 hier ein FR für einen Logikbaustein, mit dem HTTP Requests erzeugt werden können.

Ziel
Mit diesem Logikbaustein soll der Aufruf von externen APIs / web services ermöglicht werden. Die Response muss in einem Objekt entgegengenommen werden und für weitere Verarbeitungen (z.B. parsen) zu Verfügung stehen. Die weitere Verarbeitung der Response stelle ich mir jedoch in einem separaten Logikbaustein (z.B. "Text-Parser") vor.

Aufbau des "HTTP(S) Request - Logikbausteins" stelle ich mir wie folgt vor:
Input
  • "Request URL" - kann entweder manuell vorgegeben werden oder über ein Eingangsobjekt dynamisch übergeben werden
  • "Request Methode" - Auswahlliste: get / post / put / ...
  • "Request URL Parameter" - Parameter, die an Request-URL per manuellem Eintrag oder Inputobjekt angehangen werden können
  • "Request Body" - Body-Daten die für den Aufruf erforderlich sind, z.B. raw-Data (JavaScript, Json, XML, ...)
  • "Authentifizierung" - Parameter, für die Authentifizierung: none / Basic Auth / Api Key / ...
  • "Request Header" - Möglichkeit zur Mitgabe von Key - Value - Metadaten
Output
  • "Response" - als ein Output-Objekt (raw / Json / ...) zur weiteren Verarbeitung speichern.

Beispiele für Nutzung
  • Aufruf der openweathermap-API
  • Aufruf der SONOS HTTP API, um z.B. via Text-to-Speach Meldungen vom Bus auf den Sonos Lautsprechern auszugeben.
  • ...

Kommentare / Erweiterungen
Gerne nehme ich hier noch Anregungen für weitere Funktionen, Verbesserungen, Einschränkungen auf.

Edit:
Link zu FR für Json Parser eingefügt
Zuletzt geändert von alexbeer am Di Jan 07, 2020 1:26 am, insgesamt 5-mal geändert.
VG Alex
Timberwolf122 (TWS 2500) // Wartungs-VPN: offen // Reboot: jederzeit

Ersteller
alexbeer
Reactions:
Beiträge: 394
Registriert: Mi Sep 12, 2018 1:11 am
Wohnort: NRW
Hat sich bedankt: 212 Mal
Danksagung erhalten: 251 Mal

#2

Beitrag von alexbeer »

Gerade gesehen, dass es da schon einen FR für den HTTP Request gibt: viewtopic.php?f=24&t=87
@mods:
Vielleicht kann man die FRs zusammenführen...
VG Alex
Timberwolf122 (TWS 2500) // Wartungs-VPN: offen // Reboot: jederzeit

Dante
Reactions:
Beiträge: 157
Registriert: So Aug 12, 2018 10:42 am
Hat sich bedankt: 8 Mal
Danksagung erhalten: 78 Mal

#3

Beitrag von Dante »

Ich würde es grundsätzlich nicht auf HTTP(S) beschränken.

Vielleicht könnte man diesen Baustein als Frontend für CURL ansehen, dann wären gleich viele unterstützte Protokolle möglich:
DICT, FILE, FTP, FTPS, GOPHER, HTTP, HTTPS, IMAP, IMAPS, LDAP, LDAPS, POP3, POP3S, RTMP, RTSP, SCP, SFTP, SMB, SMBS, SMTP, SMTPS, TELNET and TFTP

Über die Kommandozeilenparameter könnte man alles relevante übergeben, wäre aber natürlich nicht so "schön" wie mit eigenen Input-Feldern für die verschiedenen Parameter. Aber das könnte ja dann ein übergeordneter Baustein erledigen?!

Zu den vorgeschlagenen Input-Feldern:
  • Request URL - ✓
  • Request Methode - ✓ v.a. GET / POST (ob der Rest notwendig/sinnvoll ist?!)
  • Request Header - ✓
  • Request URL Parameter - sollte das nicht in der Request URL gleich enthalten sein? Ggf. davor von Baustein(en) zusammengesetzt werden? Weil, wo fängt man sonst an - ein Parameter, zwei, drei, ... würde ich eher weglassen
  • Request Body - wie oft braucht man das wirklich? wohl hauptsächlich für die Daten beim POST-Request
  • Authentifizierung - per API-Key läuft in der Regel ja über einen URL-Parameter - ansonsten könnte man diese vllt. auch mit der alten URL-Variante: https://user:password@host/path/ übergeben. Dann könnte man sich das Input-Feld sparen
Output-Felder:
  • Response Body - ✓ ist einfach Text, weitere Verarbeitung durch den Text-Parser oben
  • Response Header - zusätzlich um ggf. dort liegende Daten (wie z.B. auch Cookies) weiterverarbeiten zu können
  • Response Status - z.B. HTTP-Status Code 200 / 404 / 403 etc.
  • Response Error - zur Behandlung von Anfragefehlern (nicht erreichbar, ungültige URL, etc) - könnten beispielsweise die Exit-Codes von CURL sein
Viele Grüße,
Thomas

timberwolf146 / Timberwolf Server 2500 Indian Gold + PBM / Version 1.6.0 IP3 (Wartungs-VPN offen / Reboot jederzeit möglich)

EarlBacid
Reactions:
Beiträge: 371
Registriert: So Aug 26, 2018 5:59 pm
Wohnort: Herborn
Hat sich bedankt: 134 Mal
Danksagung erhalten: 235 Mal

#4

Beitrag von EarlBacid »

Wie im "Nachbarthread" zum parsen von JSON viewtopic.php?f=9&t=1873 bereits diskutiert,müssen wir uns sinnvollerweise an die Objektstruktur im TWS halten, was ja auch sinnig ist, um das potential voll ausspielen zu können.

Weil Bilder mehr als tausend Worte sagen, habe ich das ganze mal aufgezeichnet, wie meine Vorstellung von so etwas aussieht:
Bild

Das Bild zeigt das bisherige System des Dispatchers, der alle einzelnen bisherigen und zukünftigen Schnittstellen und Module miteinander verbindet.

Bezüglich der Kommunikation nach außen, schwebt mit ein neues "IP Modul" vor, in dem man diverse IP-Objekte anlegen kann. diese Objekte haben dann diverse Ein-, Ausgänge und Parameter worüber sie gesteuert und getriggert werden sowie ihre verschiedenen Rückmeldungen zurück an den Dispatcher liefern.
Das sähe dann ungefähr folgendermaßen aus:
Bild

In dieses System würde auch passen, wenn das IP Modul nicht nur als Client fungieren kann um Daten von anderen System abzuholen(oder zu pushen), sondern auch als Server:
Bild

Am Ende hätte man dann entweder direkt die Werte (Im Falle eines Server IP-Objekts) oder eben die diverse Objekte incl. einem Text Objekt, dass den gesamten Response Text enthält.

Dieser Text muss nun durch den Parser, welchen ich im dazugehörigen FR im Nachbarthread erkläre: viewtopic.php?f=9&t=1873.

Eure Meinung dazu?

VG
Earl
Wiregate#1504 + PBM -
Timberwolf 950Q #233 / VPN aktiv / Reboot OK
EFH mit KNX, 1-Wire, DMX, PV und Strom über MQTT
Docker: MQTT Broker, Unifi WLAN Controller, NodeJS, CometVisu

Robert_Mini
Reactions:
Beiträge: 3741
Registriert: So Aug 12, 2018 8:44 am
Hat sich bedankt: 1164 Mal
Danksagung erhalten: 2058 Mal

#5

Beitrag von Robert_Mini »

Kurz: Super.
Robert
Timberwolf Server 2500 / #117 (VPN offen + reboot nach Rückfrage) / zusätzlich: 3500M/#935, 3500L/#1297

SchlaubySchlu
Reactions:
Beiträge: 211
Registriert: Mo Aug 13, 2018 9:32 pm
Wohnort: Allgäu
Hat sich bedankt: 106 Mal
Danksagung erhalten: 91 Mal

#6

Beitrag von SchlaubySchlu »

So etwas wäre meiner Meinung nach echt top...

Wie ich das verstanden habe, sollte es für mich mit solch einer Funktion möglich werden die Daten meines Holzkessel die er alle 500ms über IP / Telnet sendet einzulesen und weiter zu verarbeiten.
Das wäre mega genial, den aktuell scheitere ich mit meinem Kenntnissen wie ich die Daten mit dem TWS "einlesen" und weiterverarbeiten kann :-(

@ Stefan, oder gibt es da schon eine andere Möglichkeit die ich noch nicht kenne?

Gruß
Ralf
Zuletzt geändert von SchlaubySchlu am Sa Feb 01, 2020 10:00 am, insgesamt 1-mal geändert.
Timberwolf Server 2600 #196, VPN offen, Reboot nach Vereinbarung, BM 729

StefanW
Elaborated Networks
Reactions:
Beiträge: 9689
Registriert: So Aug 12, 2018 9:27 am
Wohnort: Frauenneuharting
Hat sich bedankt: 4831 Mal
Danksagung erhalten: 7633 Mal
Kontaktdaten:

#7

Beitrag von StefanW »

Hallo Ralf,

ich kann das so nicht beurteilen, wenn ich das Protokoll nicht kenne. Es kommt auf jedes Bit an, ob etwas funktioniert oder nicht.

Daher: Bitte das Protokoll suchen und hier posten. Das bedeutet nicht, dass wir das umsetzen, aber wir können das berücksichtigen hinsichtlich dessen, an was wir da arbeiten.

lg

Stefan
Stefan Werner
Product Owner für Timberwolf Server, 1-Wire und BlitzART
Bitte WIKI lesen. Allg. Support nur im Forum. Bitte keine PN
Zu Preisen, Lizenzen, Garantie, HW-Defekt an service at elabnet dot de

Link zu Impressum und Datenschutzerklärung oben.

SchlaubySchlu
Reactions:
Beiträge: 211
Registriert: Mo Aug 13, 2018 9:32 pm
Wohnort: Allgäu
Hat sich bedankt: 106 Mal
Danksagung erhalten: 91 Mal

#8

Beitrag von SchlaubySchlu »

Hallo Stefan,

bei dem Holzkessel handelt es sich um einen Rennergy, der ist ein umgelabelter Hargassner dessen Touchsteuerung einen LAN Anschluss hat. Über diesen kann über Telnet (ohne Passwort) die Kesseldaten abgerufen, bzw. sendet der Kessel diese von alleine alle nach Aufbau der Telnet-Verbindung.
Das ganze sieht dann wie folgt aus

pm 79.9 122.9 20.7 79.6 73.4 37.3 11.1 39.6 31.1 20 20 57.5 39 31 22 21 100 100 5 5 100 100 9 7 -7 0 100 85 28.7 27.4 20 20 120 30 27 17 21 -20 -20 20 20 -20 0 0 20 20 100 39.0 76.8 75 0 0 0 0 0 0 0 20.4 78.0 9.1 0 0 0 0 0 0 0 -20 0 20 20 -20 1 1 1 1 1 1 1 20 20 20 20 20 20 20 -20 1 15.9 0 0 0 2 -20 58 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 4 1 6 0 0 0 0 0 0 0 0 0 0 0 0 39 39 33014.5 11164.9 3395.0 1067.8 32.1 5250.8 0 0 39.1 0 0 1 1 3 1 0 0 0 0 0 0 -20 0 0 0 0 0 0 0 0 0 0 0 0 7.99 0 -20 -20 -20 -20 -20 12.70 629 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 -20 -20 2106 0003 0000 0003 0000 0000 0000 0000

und wiederholt sich alle 500ms.

Dabei stellt jeder Wert einen Parameter des Holzkessel dar und ist abhängig vom Kessel (Stückholz, Pallet usw.). Was jeder Parameter bedeutet ist zum Teil schon bekannt (wurde in anderen Foren schon erörtert).
Theoretisch könnte man verschiedene Parameter über die Verbindung auch verändern, aber so weit möchte ich nicht gehen da die Regelung im Ofen ganz gut läuft.

Gruß
Ralf
Timberwolf Server 2600 #196, VPN offen, Reboot nach Vereinbarung, BM 729

StefanW
Elaborated Networks
Reactions:
Beiträge: 9689
Registriert: So Aug 12, 2018 9:27 am
Wohnort: Frauenneuharting
Hat sich bedankt: 4831 Mal
Danksagung erhalten: 7633 Mal
Kontaktdaten:

#9

Beitrag von StefanW »

Danke Ralf,

es ist gut zu wissen, was alles geparsed werden soll

Stefan
Stefan Werner
Product Owner für Timberwolf Server, 1-Wire und BlitzART
Bitte WIKI lesen. Allg. Support nur im Forum. Bitte keine PN
Zu Preisen, Lizenzen, Garantie, HW-Defekt an service at elabnet dot de

Link zu Impressum und Datenschutzerklärung oben.

gbglace
Reactions:
Beiträge: 3585
Registriert: So Aug 12, 2018 10:20 am
Hat sich bedankt: 1253 Mal
Danksagung erhalten: 1649 Mal

#10

Beitrag von gbglace »

Ich glaube das sind alles Aufgaben für einen reinen Communitybaustein. So lange so ein Hersteller keine direkte Kooperation mit Elabnet eingeht, bist Du als Entwickler einer Kopplungssoftware permanent dabei diese Protokolle reverse zu engenieren. Weil jetzt baut Elabnet da ggf einen Protokollparser im nächsten Jahr baut sich dann die Heizung was anderes und dann kommt der nächste TWS-Kunde und denkt sich na super der TWS kann das, kauft sich daher auch die Heizung und dann Pustekuchen funzt nicht mehr. Das sind unkalkulierbare Aufwände.

Und wenn man dann eigentlich schon sieht das die ganzen Werte so offen unverschlüsselt übers LAN geschickt werden sieht man direkt das man besser dem Heizi heizen lässt und sich nicht so eine Anlage mit LAN oder gar noch Internet Cloud Service sich anbieten lassen sollte.
Grüße
Göran

#1 Timberwolf 2600 Velvet Red TWS #225 / VPN aktiv / Reboot OK
#2 Timberwolf 2600 Organic Silver TWS #438 / VPN aktiv / Reboot OK
#3 PBM 3 Kanäle, #4 Modbus-Extension
Antworten

Zurück zu „Feature Requests & Diskussionen Timberwolf Logik (Module & Editor)“