[Gelöst] Wie zwei Strings vergleichen

[blaubaerli]

Hallo zusammen,

leider kommt hier die "Diskussion" ja nicht wirklich in Schwung.

Mir fehlt im Moment schlicht überhaupt die Möglichkeit auf spezifische Inhalte eines Levels vom Datentyp "string" zu reagieren.

Speziell im neuen MQTT-Umfeld läuft viel über "Text"-Informationen. Die anderen Datentypen scheinen mir in meinen aktuellen Tests mal versorgt. Mit einer Custom-Logik bin ich auch in der Lage, mir "Strings" zu generieren, die ich dann beim "Publish" nutzen kann.

Aber das Dekodieren eines beim "Subscribe" erhaltenen Strings klappt halt schlicht aktuell bei mir nicht (Ist das system, oder jensbedingt? ). Ein Shelly-Fensterkontakt liefert "open" oder "close". Bisher keine Chance. Auch Rückmeldeobjekte lassen sich da im Moment nicht abbilden.

Als Einstiegslösung schwebt mir da derzeit z.B. ein neues Modul der folgenden Form vor:

["GetEntry","$Input_Wert","$Suchmodus",["String_1","String_2",...,"String_n"], "$Output"]

Wobei $Output dann 0 wenn der über "$Input_Wert" gelieferte Wert nicht gefunden wurde und 1,2,n bei entsprechendem Fund.
"$Suchmodus" dann noch für solche Optionen großkleinschriftneutrale Suche oder eben nicht.

Der Ansatz hat allerdings den Hinkefuß, dass all diejenigen die Strings dekodieren müssen, sich dann womöglich zunächst mit den Custom-Logiken beschäftigen müssten.

Denkt mal drüber nach und über Feedback und einen Diskussionsbeginn würde ich mich freuen.

Beste Grüße
Jens

[Dragonos2000]

Ich hab mich da mangels Zeit momentan nicht weiter drin vertiefen können, daher kam von mir nichts mehr. (es stehen gerade so spannende Dinge, wie Parkett schleifen an)...
Dein Ansatz trifft recht gut, was ich im Sinn hatte, geht in der Funktionalität mit den Suchmodi aber auch schon darüber hinaus. Mir hätte ein
["Compare","$Input_Wert","Such_String","$Output"]
schon genügt, wobei das Ergebnis nur 0 oder 1 sein kann.

Vom Einsatz her sehe ich es wie Du: Speziell mit MQTT ist ein solcher Baustein ein "Muss", um mit den Daten umgehen zu können, weil da viel Strings kommen.

[Dragonos2000]

Entweder habe ich noch ein totales Brett vor dem Kopf, oder es klappt wirklich noch nicht.
Der Ansatz nutzt halt den Limiter. Will nicht. Egal, ob ich den Level "$In_Compare" nun als Input definiere und dann einen String-Parameter mitgebe, oder ob ich den nur intern definiere und nicht als Input rausführe.
Hast das schon irgendwer funktionstüchtig umgesetzt?

Ne wenig Möglichkeit gefunden, Strings in einer Logik zu verarbeiten...
Mein Usecase mit dem Sting als Parameter war der, dass ich mir einen Baustein gebaut hab', der aus boolschen Zuständen Textmeldungen macht. Und diese Texte habe ich per Paramter gesetzt. Der verwendte Multiplexer konnte damit umgehen...

Einen anderen Usecase habe ich noch mit Cron-Definitionen: Diese statt im Code per Parameter einstellbar zu machen. Habe ich aber noch nicht gestestet.

[blaubaerli]

Hallo Jochen,

Ne wenig Möglichkeit gefunden, Strings in einer Logik zu verarbeiten...
Mein Usecase mit dem Sting als Parameter war der, dass ich mir einen Baustein gebaut hab', der aus boolschen Zuständen Textmeldungen macht. Und diese Texte habe ich per Paramter gesetzt. Der verwendte Multiplexer konnte damit umgehen...

Strings für den Publish zusammenzubauen, bedient die eine Richtung. Das geht aktuell mit Bordmitteln.

In der Knowledge Base - 4.6.6 Verwendung von Standard Logikbausteinen in Custom Logik]Knowledgebase[/url] haben wir ja eigentlich ein Hilfsmittel mit dem auch der Stringvergleich ggf. möglich sein sollte.

05-06-_2021_20-45-28.jpg

Das scheint aber mit Strings eben nicht zu klappen. Ich weiß nicht, ob das ein BUG ist der gefixt gehört. Aber das bedürfte der Analyse/Prüfung durch ElabNET.

Beste Grüße
Jens

[Dragonos2000]

Bin gerade wieder in dem Thema "vergleichen zweier Strings" aufgelaufen...geht noch nicht,oder? Ich hab' keinen Ansatz wie...
Wenn es da nicht bereits eine andere Möglichkeit gibt, würde ich etwas in folgender Art vorschlagen:
["Compare","$Input_Wert","Such_String","$Output",Mode]

$Ouput (bool):
false = mismatch/nicht enthalten
true = match / enthalten

Mode (integer):
0 = exakte Übereinstimmung
1= enthält Suchstring an beliebiger Stelle

Meinungen? Finde es eigentlich relativ wichtig in Bezug auf MQTT und HTTP API, oder habe nur ich den Bedarf ?

[danik]

Meinungen? Finde es eigentlich relativ wichtig in Bezug auf MQTT und HTTP API, oder habe nur ich den Bedarf ?

Hi, sehe da auch Bedarf mit Verbreitung der genannten Punkte von Dir. Auch das Senden von String in Logiken. Geht m.E. ohne Custom-Logik noch nicht.

Gruss
Dani

[Dragonos2000]

Es hätte auch den Vorteil, dass man sich notfalls auch Custom Typkonvertierungen erstellen könnte, wenn die System seitige automatische Konvertierung nicht greift...

[Dragonos2000]

Jens hatte ja auch einen ähnlichen Vorschlag gemacht. Zusammengefasst haben wir folgende zwei konkreten Vorschläge, die sich nur geringfügig unterscheiden (Variablen habe ich aus den original Vorschlägen übernommen, denke sollte selbsterklärend sein):

["Compare","$Input_Wert","Such_String","$Output",Mode]
["GetEntry","$Input_Wert","$Suchmodus",["String_1","String_2",...,"String_n"], "$Output"]

Beim Suchmodus die Ansätze:

1. Exakte Übereinstimmung
2. Suchstring enthalten
3. Groß-/Kleinschreibung ignorieren

3) macht wohl am ehesten mit 2) Sinn und ich würde diese daher stets kombinieren, also insgesamt wieder 2 Varianten:

1. Exakte Übereinstimmung
2. Suchstring enthalten und Groß-/Kleinschreibung dabei ignorieren

Ließe sich m.E. als fertiger Logikbaustein bereitstellen, so daß auch diejenigen es nutzen könnten, die keine Affinität zu Custom-Logiken haben.
Welchen der beiden Vorschläge haltet Ihr für sinnvoller? Mir würde der erste reichen und der wäre sicherlich auch einfacher zu implementieren.

[Dragonos2000]

Hmm...die Resonanz ist doch sehr verhalten- da lohnt es nicht, einen FR drauß zu machen und es ist verständlich, wenn ElabNet sich in diesem Thema nicht reinhängt.

Anscheinend hab nur ich den Bedarf oder der Usecase ist nicht transparent.

[StefanW]

Hallo Jochen,

die Erfahrung zeigt, das manches braucht, bis es breiter angenommen wird. Es sind gerade eine Menge Nutzer mit den CometVisu Tests beschäftigt.

Ich beobachte den Thread und die Ideen durchaus. Es kommt auch demnächst etwas zum Thema "String" in die Logik.

lg

Stefan