Hallo,

ich teste gerade die LStream Bibliothek (https://support.industry.siemens.com/cs/de/de/view/109781165) für TIA V18 in der Version V1.6 um ein Json-Objekt zu deserialisieren.

Ich weiß nicht ob ich der erste bin der diese Funktion testet. Auf jeden Fall nehme ich ein json wie:

{"WertA":{"value":-123.456,"timestamp":1729491370.438688},"WertB":{"value":987.654,"timestamp":1729491370.555555}}

Wenn ich das deserialisiere ohne Option "search" also search:=false, dann wird das Objekt deserialisiert. So weit in Ordnung.

Nun möchte ich aber nicht das gesamte Objekt deserialisieren (da zu groß) sondern nur einzelne Werte daraus, z.B. Objekt "WertB" das Element "value". Das sollte laut Dokumentation funktionieren, in dem ich die Startwerte im DB selber setze, und beim Aufrufen die Option search:=true setze.

Ich trage das nun so ein wie dieser Wert beim Deserialisieren gefunden und im DB erstellt wurde. D.h.

Elem[0] type=0, key='WertB", value='NULL', depth=0

Elem[1] type=3, key='value", value='NULL',depth=1

Als Ergebnis werden mir nun im Datenbaustein alle keys überschrieben!!! mit einem leeren String '', als value wird überall "Key not found" eingetragen. Und im vorletzten Element meines Ziel-Arrays Array[0..10] of "LStream_typeElement" wird an Element[9] nur der letzte timestamp eingetragen, wo type, key, value, depth auf Initialwert stehen.

Wenn ich an Elem[1] mal testweise closingElement setze macht das auch keinen Unterschied.

Habe ich das mit search etwa falsch verstanden? Die Dokumentation ist ja arg dürftig. Ich würde zumindest davon ausgehen, dass wenn ich nach keys suche, mir die keys nicht überschrieben werden.

Puh, das hat garantiert noch nie jemand getestet:

Zeilen 38,39:

Falsche Berechnung der Anzahl Elemente in einem Array. Ein Array[0..10] besitzt 11 Elemente. Es wird hier ein Array mit Startindex 0 angenommen.

Zeile 76:

Es wird immer der Tree gelöscht, auch wenn search := true ist. Das kann also noch nie funktioniert haben. Korrektur hier z.B. durch IF #statCountOfTree > 0 AND NOT #statSearch THEN

Vermutlich mindestens in den Zeilen 487 und 510 müsste auch noch "AND NOT #statSearch" mit aufgenommen werden, damit nicht das letzte Element im Baum überschrieben wird. type wird aber weiterhin noch überschrieben, das habe ich auch noch nicht ganz verstanden was das alles soll. Würde mich nicht wundern wenn da noch mehr "Systemverhalten" vorhanden ist.

Für eine Version V1.6 ist das schon sportlich.

Ob da jemand drauf reagiert, wenn so anscheinend nicht einmal das Interesse bestand, die grundlegenden Funktionen zu testen. Vielleicht sollte Siemens überlegen, die Quellen in ein Projekt bei github/gitlab hochzuladen, das würde vermutlich die Qualität enorm steigern.

In den Komm-Libraries habe ich in dem Zusammenhang auch Fehler gefunden. Felder in http-headern sind case-insensitiv laut RFC 2616. Und ich habe bisher nur jeweils einen Baustein aus der Kom-Lib und einen aus der LStream Lib getestet, und beide ungetestet mit Fehlern.

Die Funktion mit dem Suchen einzelner Werte mit search=true ist auch nicht wirklich brauchbar.

Habe ich mein Beispiel:

{"WertA":{"value":-123.456,"timestamp":1729491370.438688},"WertB":{"value":987.654,"timestamp":1729491370.555555}}

Und ich suche nach value, wird das zwar gefunden, aber es ist nicht das Objekt relevant in dem sich value befinden, sondern es wird einfach die Reihenfolge angenommen.

Ich kann also einfach zwei mal nach value suchen, bekomme dann in der Reihe nach wie die Werte im Json aufgeführt sind die Werte. Der Kontext wird überhaupt nicht beachtet. Übertragt also der Server das Objekt WertB vor WertA, dann werden ganz andere Werte erfasst.