ElabNET Technik Forum

Dante hat geschrieben: ↑Di Jan 07, 2020 9:23 am 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.

Dante hat geschrieben: ↑Mi Jan 15, 2020 2:29 pm Hab mir zu dem Thema noch mal ein paar Gedanken gemacht und hier gibt es jetzt verschiedene Umsetzungsvarianten bzw. Positionen. Ich hab die jetzt mal versucht in einer Grafik zusammenzufassen und dabei ist mir noch eine weitere Variante in den Sinn gekommen (als Eingangsfunktion - evtl. hat die ja auch schon jemand irgendwo vorgeschlagen) und weiterer Baustein dazugekommen (Textconverter/-manipulator):



Ich persönlich fände den Textparser als eigene Technologie sehr umständlich. Da ich die Operationen daraus in einer Logik ggf. mehrfach anwenden muss - wenn ich dann jedesmal in einen anderen Bereich des TWS springen muss um den Parser dort anzupassen, würde mich das wohl Wahnsinnig machen.
Beim IP-Modul sehe's dagegen als sinnvoll an, einerseits architekturbedingt wie von @StefanW angemerkt und andererseits, da es sich halt einfach um Endpunkte handelt - entweder als Start oder als Ziel einer Logik.

Was denkt ihr?

Dragonos2000 hat geschrieben: ↑Do Mai 27, 2021 11:14 pm Es funktioniert tatsächlich mit dem String als Parameter

{
    "Level": [
        ["$In_val","string","close"],
        ["$In_Compare","string","close"],
        ["$SensorStatus","bool",false],
        ["$ConstTrue", "bool",true],
        ["$ConstFalse", "bool",false]
    ],
    "Module": [
        ["Limiter","$In_val",0,"$SensorStatus",["$In_Compare","$In_Compare"]]
    ],
    "Input": [
        ["In","Statuswert des Fensterkontaktes","$In_val","c"],
        ["2Compare","Vergleichswert","$In_Compare","c"]
    ],
    "Output": [
        ["offen","wahr wenn offen","$SensorStatus","c"]
    ]
}