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] Modul zum parsen von Text (Json)

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

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

Modul zum parsen von Text (Json)

#1

Beitrag von alexbeer »

Ausgehend von dem FR "HTTP(S) Web Request" hier der Wunsch nach einem Logikbaustein, mit dem die Response eines HTTP Requests verarbeitet werden kann.

Ziel
Response eines HTTP Requests in seine Bestandteile zerlegen und beliebige Attribute Outputobjekten zuordnen.

Um das ganze verständlicher zu machen, ein Beispiel für eine mögliche Response zu dem Request:
api.openweathermap.org/data/2.5/weather?lat=35&lon=139

Code: Alles auswählen

{"coord": { "lon": 139,"lat": 35},
  "weather": [
    {
      "id": 800,
      "main": "Clear",
      "description": "clear sky",
      "icon": "01n"
    }
  ],
  "base": "stations",
  "main": {
    "temp": 281.52,
    "feels_like": 278.99,
    "temp_min": 280.15,
    "temp_max": 283.71,
    "pressure": 1016,
    "humidity": 93
  },
  "wind": {
    "speed": 0.47,
    "deg": 107.538
  },
  "clouds": {
    "all": 2
  },
  "dt": 1560350192,
  "sys": {
    "type": 3,
    "id": 2019346,
    "message": 0.0065,
    "country": "JP",
    "sunrise": 1560281377,
    "sunset": 1560333478
  },
  "timezone": 32400,
  "id": 1851632,
  "name": "Shuzenji",
  "cod": 200
}



Input
  • "Response" - eines HTTP Requests
Level
  • Definition der benötigten Variablen, um Attribute der Response zu "filtern", zB Temperatur
Modul
  • Jeder Variabel aus den Leveln ist nun der Pfad aus dem Eingangsobjekt zuzuweisen, zB.
    Level: "Temperatur"; Path:InputObj1.main.temp = 281.52 (ggf mit Live-Preview des Attribut-Wertes)
  • Das Response-Objekt kann natürlich auch Arrays enthalten, so dass die Pfad Zuordnung auch zB Path:InputObj1.preview.list[3].temp sein könnte,
  • Toll wäre, wenn man das Attribut aus dem InputObjekt anklicken könnte und der Pfad dann angezeigt/ kopiert wird, um ihn einfacher zuzuordnen.
  • Die bestehende Mapping - Funktionen optional anbieten
Output
  • Jede Level Variabel ist nun als OutputObjekt einem TWS-Objekt inkl. Datentyp zuzuordnen
Einschränkungen
Damit der Parser nicht zu komplex wird, schlage ich vor, dass wir uns (zunächst) auf Json beschränken. Wie seht ihr das?
Welche weiteren Einschränkungen machen Sinn, damit das ganze auch als Anwender einfach zu bedienen ist?
Zuletzt geändert von Dragonos2000 am Di Jan 07, 2020 5:29 pm, insgesamt 4-mal geändert.
VG Alex
Timberwolf122 (TWS 2500) // Wartungs-VPN: offen // Reboot: jederzeit

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

#2

Beitrag von EarlBacid »

nur mal so als Denkanstoß (habe es mir noch nicht zu Ende durchdacht): Ich wäre der Meinung, dass so etwas wie HTTP (oder vielleicht sogar allgemeiner IP) eher wie eine Schnittstelle zu behandeln wäre, die über den Dispatcher angesprochen wird. Sprich es gibt dann z.B. ein HTTP GET Objekt, das man mit dem Ausgang einer Logik verknüpft, und der Response wird wiederum mit einem Eingang einer anderen Logig Verknüpft.

Oder wenn man eben will, könnte man auch 1-Wire Werte wie HTTP versenden, oder wie HTTP von außen direkt einen DMX Kanal ansteuern. Je nachdem wie der Dispatcher halt für das jeweilige Objekt eingestellt ist.

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

pbm
Reactions:
Beiträge: 201
Registriert: Mo Dez 02, 2019 10:20 pm
Wohnort: Hannover
Hat sich bedankt: 116 Mal
Danksagung erhalten: 114 Mal

#3

Beitrag von pbm »

Moin,

das interessiert mich auch!

Nutze aktuell ne eigene Perl-Bastelei, um Werte aus der JSON Response eines Janitza UMG604 zu lesen.
Ist im Moment nur "Spielerei", aber ich plane in (naher oder ferner???) Zukunft, den Eigenverbrauch der noch anzuschaffenden PV Anlage zu optimieren.
Zusammen mit dem TWS und der Thermia Wärmepumpe. Ggf dann irgendwann mal erweitern mit ner Batterie.

In dem Zusammenhang wäre es sicher auch gut, Wetterdaten aus ner JSON Response mit einbeziehen.

Schöne Grüße
Peer
Schöne Grüße
Peer

TWS 2400 #466 // Wartungs-VPN: aktiv // Reboot: nach Rücksprache

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

#4

Beitrag von alexbeer »

@EarlBacid
Klingt interessant, aber ich fürchte, ich habe es noch nicht ganz verstanden.
Die Json-Response hat ja im Gegensatz zu XML - keine fest definierte Struktur.
Wie stellst du dir da ein DOS-Objekt-Definition inkl Attribut-Mapping vor?
Den Ansatz mit der IP-Schnittstelle im DOS finde ich auch interessant. Das sollten wir definitiv durchdenken!

Mein Gedankengang mit dem eigenständigen Logikbaustein basiert darauf, dass mit einem eigenen Baustein sehr viele Freiheitsgrade bestehen würden.
VG Alex
Timberwolf122 (TWS 2500) // Wartungs-VPN: offen // Reboot: jederzeit

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

#5

Beitrag von gbglace »

Einen solchen JSON in einem LE-Baustein zu interpretieren ist ein guter Einstieg.

Die Quelle von einem solchen JSON kann dann ja alles mögliche sein. MQTT produziert ja auch nur solche JSON.

In der technischen Schnittstelle zu der Technologie selbst ist ein solcher Mappingbaustein sicher noch falsch aufgehoben.
Für eine Instanz zwischen Technologieschnittstelle und LE kann ich mich aber auch erwärmen.

Im TWS Objekteditor hätte man also im Baum einmal die Ebene Technologie = MQTT oder HTTP GET und als Subsystem dann eben PV-Speicher von FirmaXY und definiert dort genau die jeweilige JSON Struktur, für jedes Objekt mit dem man arbeiten möchte.
Vorteil ist dann, dass im Output dann nicht alles LE-Objekte sind.

Der Weg in die andere Richtung dann analog.
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

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

#6

Beitrag von alexbeer »

Hi, den Vorteil mit einem Output-Objekt anstatt n Objekten ist gut. Das hätte ich auch so ähnlich implizit vorausgesetzt - nur nicht im DOS, sondern im LE
Bei dem Punkt:
definiert dort genau die jeweilige JSON Struktur
sehe ich jedoch die Herausforderung, da es bei JSON nicht DIE Struktur gibt und der Attributsname nicht eineindeutig sein muss.

Am Beispiel owm:

Code: Alles auswählen

<weatherdata>
<location>
<name>London</name>
<type/>
<country>GB</country>
<timezone>3600</timezone>
<location altitude="0" latitude="51.5085" longitude="-0.1258" 
geobase="geonames" geobaseid="2643743"/>
</location>
<meta>...</meta>
<sun rise="2015-06-30T10:08:46" set="2015-07-01T01:06:20"/>
<forecast>
 <time from="2015-06-30T09:00:00" to="2015-06-30T12:00:00">
 <symbol number="500" name="light rain" var="10n"/>
 <precipitation value="5" unit="3h" type="rain"/>
 <windDirection deg="253.5" code="WSW" name="West-southwest"/>
 <windSpeed mps="4.9" name="Gentle Breeze"/>
 <temperature unit="celsius" value="16.89" min="16.89" max="17.375"/>
 <pressure unit="hPa" value="989.51"/>
 <humidity value="96" unit="%"/>
 <clouds value="broken clouds" all="64" unit="%"/>
</time>
 <time from="2015-06-30T12:00:00" to="2015-06-30T15:00:00">
 <symbol number="500" name="light rain" var="10d"/>
 <precipitation value="99" unit="3h" type="rain"/>
 <windDirection deg="248.001" code="WSW" name="West-southwest"/>
 <windSpeed mps="4.86" name="Gentle Breeze"/>
 <temperature unit="celsius" value="17.23" min="17.23" max="17.614"/>
 <pressure unit="hPa" value="991.29"/>
 <humidity value="97" unit="%"/>
 <clouds value="scattered clouds" all="44" unit="%"/>
 </time>

...

</forecast>
Das Attribut <time =...> kommt so mit den untergeordneten Knoten mehrfach vor.
Aber Herausforderungen sind ja dazu da, gelöst zu werden. :)
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

#7

Beitrag von Dante »

Ich würde den Baustein auch allgemeiner konzipieren, damit er später verschiedene Formate verarbeiten kann.
Der Input sollte also völlig neutral einfach Text annehmen, woher dieser kommt (aus MQTT, einer Datenbank, dem Body eines HTTP-Response, dem Header eines HTTP-Response, einer SMS, eines KNX-Telegrams, ...) ist an dieser Stelle ganz egal!

Auch den Datentyp sollte flexibel sein - JSON könnte dann eins der ersten sein.

Man kann also den Datentyp einstellen, z.B.:
  • JSON
  • XML
  • HTML
  • CSV
  • Raw / Text
Davon könnte es später sogar noch weitere Subtypen geben, z.B. SOAP, CSV mit Tabs, HTTP-Header, ...
Der Datentyp könnte ja sogar wieder ein eigener Input sein.

Das man verschiedene Variablen aus dem Text in einem Baustein auswerten kann, sehe ich schwierig. Einfacher und verständlicher wäre es, dass ein Textparser einen Input-Text und einen Output hat. Einzige Einschränkung wäre dann die Auswertung von Texten mit einer beliebigen (nicht fest definierten) Anzahl an Werten - aber da ist das Handling dann auch sehr komplex.

Um den richtigen Wert aus dem Text zu extrahieren, gibt es dann einen Pfad dazu - dieser ist dann vom jeweiligen Datentyp abhängig und man könnte auf Standardfunktionen zurückgreifen, z.B.:

XML: XPath
XPath für XML-Beispiel von @alexbeer:

Code: Alles auswählen

//time[2]/windSpeed/@mps
JSON: Objektnotation
Beispiel für JSON von @alexbeer:

Code: Alles auswählen

main.temp
Raw / Text: Regular Expressions

etc.

Und auch dieser Pfad / Filter könnte wieder per Input in den Baustein reinlaufen und wäre damit wieder dynamisch.
Viele Grüße,
Thomas

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

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

#8

Beitrag von StefanW »

Hallo zusammen,

kurz ein paar Inputs von mir:

1. Earl hat Recht, das hat in der Logik nichts zu suchen (ich weiß, dass alle anderen es anders machen, aber wir machen es besser). Wir wollen eine starke und sehr schnelle Logik mit entsprechenden Eigenschaften. UNSERE Logik arbeitet nur auf der Basis von Objekten die fertig zugesandt werden. Die Logik soll eben NICHT stehen bleiben und auf das Ergebnis eines POLLs warten. Nur so bleibt die Sache auch si performant.

1A Bitte nicht vergessen, DIE ZENTRALE von allem ist der Dispatcher, nicht die Logik. Es können auch mehrere Logiken parallel betrieben werden, womöglich hat man später eine eigene Engine für verschiedene Spezialaufgaben. Ist von der Architektur kein Problem.

2. Alles was an Daten nicht von selber als Ereignisn kommt, sondern erst gepollt (oder angefordert) wird, wie 1-Wire, MODBUS, ggfls. MQTT (dort wo erst was anzufordern ist), Curl & Co, das wird in separaten Modulen gehandelt, die sich um das Pollen kümmern und die fertigen Werte dann als Ereignis in den Dispatcher einsteuern.

3. Wenn also was zu holen und zu parsen ist, dann ist das eine separate Technologie / Subsystem die Objekte erzeugt, die dann aber beliebig verknüpft werden können.

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.

pbm
Reactions:
Beiträge: 201
Registriert: Mo Dez 02, 2019 10:20 pm
Wohnort: Hannover
Hat sich bedankt: 116 Mal
Danksagung erhalten: 114 Mal

#9

Beitrag von pbm »

StefanW hat geschrieben: Di Jan 07, 2020 12:27 pm 3. Wenn also was zu holen und zu parsen ist, dann ist das eine separate Technologie / Subsystem die Objekte erzeugt, die dann aber beliebig verknüpft werden können.
Klingt gut!
Dann wäre der FR entsprechen anzupassen?!
Schöne Grüße
Peer

TWS 2400 #466 // Wartungs-VPN: aktiv // Reboot: nach Rücksprache

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

#10

Beitrag von alexbeer »

Hi,
danke für die Infos und die konstruktive Diskussion - finde ich klasse!
UNSERE Logik arbeitet nur auf der Basis von Objekten die fertig zugesandt werden.
ist für mich eine neue Erkenntnis - das könnte ggf noch mit in die KB aufgenommen werden.

Leider kann ich den initialen Post nicht mehr editieren.
Vielleicht kann ein Mod den Titel und auch die sonstigen Verweise auf den LE so editieren, dass die Anforderung neutraler formuliert ist.

In dem FR Reverse Workflow - oder von hinten durch den Server in die ETS ist ja schon angedacht, dass im DOS neue Objekte definiert werden.
Da fehlte mir noch die Abstraktionsfähigkeit, dem Dispatcher noch weitere Funktionen (wie das parsen von Objekten aus anderen Universen wie JSON) einzuimpfen.
Bin gespannt was da noch kommen wird!
VG Alex
VG Alex
Timberwolf122 (TWS 2500) // Wartungs-VPN: offen // Reboot: jederzeit
Antworten

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