Seite 1 von 4
Modul zum parsen von Text (Json)
Verfasst: Mo Jan 06, 2020 11:40 pm
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
}
- "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?
Re: LE: Logikbaustein Text (Json) Parser
Verfasst: Di Jan 07, 2020 12:27 am
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
Re: LE: Logikbaustein Text (Json) Parser
Verfasst: Di Jan 07, 2020 12:29 am
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
Re: LE: Logikbaustein Text (Json) Parser
Verfasst: Di Jan 07, 2020 12:57 am
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.
Re: LE: Logikbaustein Text (Json) Parser
Verfasst: Di Jan 07, 2020 6:20 am
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.
Re: LE: Logikbaustein Text (Json) Parser
Verfasst: Di Jan 07, 2020 8:37 am
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.
Re: LE: Logikbaustein Text (Json) Parser
Verfasst: Di Jan 07, 2020 9:23 am
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:
JSON: Objektnotation
Beispiel für JSON von
@alexbeer:
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.
Re: LE: Logikbaustein Text (Json) Parser
Verfasst: Di Jan 07, 2020 12:27 pm
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
Re: LE: Logikbaustein Text (Json) Parser
Verfasst: Di Jan 07, 2020 3:42 pm
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?!
Re: LE: Logikbaustein Text (Json) Parser
Verfasst: Di Jan 07, 2020 4:40 pm
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