[Beantwortet] [V4.5 IP7] Datenfilter in Logik bzw. Zeitreihe

[hkettler]

Hallo,

ich möchte gerne sicherstellen, dass bestimmte ungültige Werte (in meinem Fall negative Wert) nicht ausgegeben werden bzw. nicht in die Zeitreihe geschrieben werden. Mit Limiter kann ich filtern z.B. auf 0-100, aber es würde aus aus einer "-1" eine "0" und aus einer "150" ein "100".

Gibt es Möglichkeiten Werte außerhalb des gültigen Wertebereichs in einer Logik *gar nicht* auszugeben bzw. beim Übertragen in eine Zeitreihe vollständig zu filtern?

viele Grüße,

Henning

[Robert_Mini]

Servus!

Für deinen Fall ginge das in einer Custom Logik.
- Limiter hat auch einen Ausgang, der Innerhalb/Außerhalb auswertet.
- Damit ein SendExplicit verknüpfen, so dass nur bei True gesendet wird
Fertig.

Lg
Robert

[eib-eg]

ich weis das von der ki geschriebene texte nicht gelesen werden
aber ich füge ihn dennoch mit ein wegen den erklärungen
der code ist im text enthalten und wurde von mir getestet

folgend ist der KI text
___________________________________

Servus Henning,

eine sehr gute und wichtige Frage! Der Ansatz von Robert_Mini ist der goldrichtige Weg. Dein Ziel ist es, Werte, die außerhalb eines definierten Bereichs liegen, nicht nur zu begrenzen, sondern komplett zu verwerfen, sodass sie gar nicht erst in die Zeitreihe geschrieben werden.

Die Herausforderung dabei ist, wie du korrekt beobachtet hast, dass der Limiter alleine den Wert nur "klemmt" (z.B. aus -1 eine 0 macht). Wir müssen ihn aber mit SendExplicit kombinieren, um den Sendevorgang selbst zu steuern.

Nach einigen Tests hat sich gezeigt, dass man eine kleine Falle der Logik-Engine (die "Ein-Zyklus-Verzögerung") umgehen muss, um eine 100% robuste Lösung zu erhalten. Eine einfache Kaskade reicht nicht aus.

Hier ist die finale, validierte Custom Logic, die genau das tut, was du möchtest. Sie ist so aufgebaut, dass sie auch in der Live-Ansicht des Logik-Editors immer den korrekten, letzten gültigen Wert anzeigt.

Die Architektur im Detail:

Prüfen (Limiter): Ein Limiter prüft, ob der eingehende Wert gültig ist. Das Ergebnis (true/false) wird in einer Logik-Variable gespeichert.

Entscheiden (Multiplexer): Eine Weiche entscheidet, welcher Wert für diesen Zyklus "gewinnt". Ist der neue Wert gültig, wird er durchgereicht. Ist er ungültig, wird der letzte gespeicherte gültige Wert beibehalten.

Bedingt Senden (SendExplicit): Nur wenn der Limiter in Schritt 1 "gültig" (true) gemeldet hat, wird der "Gewinner-Wert" aus Schritt 2 explizit an den Ausgang gesendet.

Speichern (Latch): Am Ende des Zyklus wird der "Gewinner-Wert" für den nächsten Durchlauf gespeichert. Dies verhindert die erwähnte Ein-Zyklus-Verzögerung.

Finale Custom Logic "Daten-Verwerfungsfilter"


{
"Level": [
[ "$P_Wert_In", "float", 0.0 ],
[ "$P_Min_Valid", "float", 0.0 ],
[ "$P_Max_Valid", "float", 100.0 ],
[ "$O_Gefilterter_Wert", "float", 0.0 ],
[ "$State_Last_Valid_Value", "float", 0.0 ],
[ "$Lgc_Wert_Ist_Gueltig", "bool", false ],
[ "$Konst_True", "bool", true ]
],
"Module": [
[ "Limiter", "$P_Wert_In", 0, "$Lgc_Wert_Ist_Gueltig", [ "$P_Min_Valid", "$P_Max_Valid" ] ],
[ "Multiplexer", [ "$State_Last_Valid_Value", "$P_Wert_In" ], "$O_Gefilterter_Wert", "$Lgc_Wert_Ist_Gueltig" ],
[ "SendExplicit", "$Lgc_Wert_Ist_Gueltig", "$O_Gefilterter_Wert", 0 ],
[ "Latch", "$O_Gefilterter_Wert", "$State_Last_Valid_Value", "$Konst_True", 0 ]
],
"Input": [
[ "1. Eingang: Zu filternder Wert", "Der Wert, der auf Gültigkeit geprüft wird (z.B. von einem Sensor).", "$P_Wert_In", "c" ],
[ "2. Parameter: Gültiges Minimum", "Werte unterhalb dieses Limits werden verworfen.", "$P_Min_Valid", "c" ],
[ "3. Parameter: Gültiges Maximum", "Werte oberhalb dieses Limits werden verworfen.", "$P_Max_Valid", "c" ]
],
"Output": [
[ "1. Ausgang: Gefilterter Wert", "Sendet den Wert nur, wenn er im gültigen Bereich liegt. Behält den letzten gültigen Wert.", "$O_Gefilterter_Wert", "x" ]
]
}





Anleitung zur Verwendung:

1. Erstelle eine neue "Eigene Logik (JSON)".

2. Kopiere den obigen Code vollständig hinein und speichere.

3. Verbinde deine Datenquelle mit dem Eingang "1. Eingang: Zu filternder Wert".

4. Passe bei Bedarf die Eingänge "2. Parameter: Gültiges Minimum" und "3. Parameter: Gültiges Maximum" an deine Anforderungen an.

5. Verbinde den Ausgang "1. Ausgang: Gefilterter Wert" mit deiner Zeitreihe. Der Trigger-Mode x am Ausgang ist hier entscheidend.

Damit ist sichergestellt, dass deine Zeitreihe sauber bleibt und nur Werte aufgezeichnet werden, die deinen Kriterien entsprechen.

__________________________________

KI text ende

viel ervolg beim testen
mfg eib-eg und die ki

[AndererStefan]

Hallo eib-eg

der Sprachtstil "deiner" KI wirkt auf mich befremdlich. Ich finde die persönliche Ansprache mit "du" und den vorgetäuschten menschlichen Stil komisch.

► Text zeigen

Ich habe den Code von oben mal der Meta Pro KI gegeben:

Gerne, ich analysiere den von Ihnen bereitgestellten Code.

Zusammenfassung der Funktion
Dieser Code implementiert einen "Gültigkeitsfilter" (manchmal auch als "Range Gate" oder "Spike Filter" bezeichnet). Seine Hauptaufgabe ist es, einen Eingangswert (z.B. von einem Sensor) nur dann weiterzugeben, wenn er sich innerhalb eines definierbaren Minimum- und Maximum-Bereichs befindet. Werte außerhalb dieses Bereichs werden verworfen. Die Logik merkt sich den letzten gültigen Wert und gibt diesen intern weiter, sendet aber nur dann ein Update an den Ausgang, wenn ein neuer, gültiger Wert empfangen wird.

Detaillierte Funktionsweise (Schritt für Schritt)
1. Validitätsprüfung (Limiter):
- Der Limiter-Baustein prüft, ob der ankommende Wert $P_Wert_In zwischen $P_Min_Valid und $P_Max_Valid (einschließlich der Grenzen) liegt.
- Das Ergebnis dieser Prüfung (ein true oder false) wird in der internen Variable $Lgc_Wert_Ist_Gueltig gespeichert.

2. Wertauswahl (Multiplexer):
- Der Multiplexer entscheidet, welcher Wert als nächstes verwendet wird. Als "Schalter" dient die Variable $Lgc_Wert_Ist_Gueltig.
- Fall 1 (Wert ist ungültig): Wenn $Lgc_Wert_Ist_Gueltig false ist, wählt der Multiplexer den Wert aus $State_Last_Valid_Value (dem Speicher für den letzten gültigen Wert).
- Fall 2 (Wert ist gültig): Wenn $Lgc_Wert_Ist_Gueltig true ist, wählt der Multiplexer den aktuellen, gültigen Eingangswert $P_Wert_In.
- Das Ergebnis dieser Auswahl wird in die Ausgangsvariable $O_Gefilterter_Wert geschrieben. Intern hält diese Variable also immer einen gültigen Wert.

3. Bedingtes Senden (SendExplicit):
- Dies ist ein entscheidender Teil der Logik. Der Ausgang $O_Gefilterter_Wert hat die Sendeoption "x", was bedeutet, dass er nur sendet, wenn der SendExplicit-Baustein es ihm befiehlt.
- Der SendExplicit-Baustein sendet den Wert nur, wenn seine Bedingung ($Lgc_Wert_Ist_Gueltig) true ist.
- Konsequenz: Der Ausgang wird nur dann aktualisiert, wenn ein neuer, gültiger Wert ankommt. Wenn ungültige Werte eintreffen, bleibt die Logik nach außen hin stumm.

4. Speichern des letzten gültigen Wertes (Latch):
- Der Latch-Baustein sorgt dafür, dass der letzte gültige Wert für den nächsten Durchlauf gespeichert wird.
- In jedem Zyklus wird der aktuelle Inhalt von $O_Gefilterter_Wert (der ja immer ein gültiger Wert ist, siehe Schritt 2) in die Speichervariable $State_Last_Valid_Value kopiert. So ist der "letzte gültige Wert" immer aktuell.

Praktisches Anwendungsbeispiel
Stellen Sie sich einen Temperatursensor vor, der gelegentlich fehlerhafte "Spikes" sendet (z.B. -127°C oder 3000°C). Diese Logik, zwischen Sensor und z.B. einer Heizungssteuerung platziert, würde:
- Normale Werte (z.B. zwischen 0°C und 40°C) einfach durchlassen.
- Einen fehlerhaften Wert von 3000°C als ungültig erkennen, ihn verwerfen und kein Update an die Heizungssteuerung senden. Die Steuerung würde weiterhin mit dem letzten korrekten Wert (z.B. 21°C) arbeiten und nicht fälschlicherweise abschalten.

Das Problem mit einer Logik zu lösen ist möglich, aber das ist ja etwas an der originalen Frage vorbei. Die ist m.E. eher ein Feature Request um direkt bei Verknüpfung eines Objektes für die Zeitreihe einen Filter konfigurieren zu können.

VG
Stefan

[eib-eg]

Hm
@AndererStefan
Warum hast du mit deiner ki den Code nicht erstellen lassen und bereitgestellt ?
Nur mal so in den Raum geworfen

Ui Feature Request
Mache eine Ausarbeitung und eine Umfrage

[gbglace]

Na der TE hat nur eine Frage gestellt und die zielte explizit auf eine spezielle Logik.

Den Dispatcher jetzt noch neben dem impliziten Format-Mapping um manuelle individuelle Filter zu erweitern klingt für so manchen User logisch das da zu wollen, aber ist am Ende nicht konsequent.

Denn was machst wenn Du genau jene Werte die in die TS geschreiben wurden auch an einer anderen Vernüpfung benötigst, dann baust da jedes Mal im Dispatcher wieder und wieder am selben Quellobjekt zum x. Zielobjekt solche Filter?
So etwas ergibt nur inkonsistente Daten.

Deutlich konsequenter ist es da aus dem Roh-Quellobjekt mit einer Logik ein DQ gesichertes Objekt zu machen und dann eben dieses im Dispatcher direkt an den x verschiedenen Stellen zu verwenden.

Der Dispatcher ist kein Quellsystem.
Wenn dann sollte man bei jenen ansetzen und auf DQ gesicherte Werte Filtern. bei einigen Subsystemen bietet der TWs ja die Filterung der Rohwerte, bevor sie an den Dispatcher ins interne Objektsystem gehen.

[Sun1453]

bei einigen Subsystemen bietet der TWs ja die Filterung der Rohwerte, bevor sie an den Dispatcher ins interne Objektsystem gehen.

Genau da muss die Erweiterung auch rein. Ist ja super bei einigen Systemen schon vorhanden.

[AndererStefan]

@AndererStefan
Warum hast du mit deiner ki den Code nicht erstellen lassen und bereitgestellt ?

Hatte ich, doch dann habe ich bemerkt, dass ich die Anforderung falsch verstanden hatte. Darauf hin hatte mich dann entschieden lieber den bereitgestellen Code prüfen/beschreiben zu lassen als eine vermutlich ähnliche Alternative erstellen zu lassen.

Aber bitte:

► Text zeigen

Ich benötige eine Custom Logik mit einer Datenfilter-Funktion.
Von einem Eingangswert (z.B. von einem Sensor) sollen nur Werte auf den Ausgang gegeben werden, die innerhalb eines definierbaren Gültigkeitsbereiches liegen. Der Gültigkeitsbereich soll als Parameter vorgegeben werden. Werte außerhalb dieses Bereichs sollen ignoriert (gefiltert) werden.

Verstanden. Das ist eine klare und sinnvolle Anforderung. Ich werde die Projekt-Datei entsprechend vorbereiten.
Zuerst formuliere ich Ihre Anforderung in eine strukturierte Form für den ANFORDERUNGEN-Abschnitt der Projekt-Datei:

Vorgeschlagene Anforderungen:

• Pkt 01: Die Logik soll einen Eingang für den zu filternden Wert (z.B. von einem Sensor) vom Typ float besitzen.
• Pkt 02: Die Logik soll zwei Eingänge zur Definition des Gültigkeitsbereichs besitzen: Gültig Minimum und Gültig Maximum, beide vom Typ float.
• Pkt 03: Die Logik soll einen Ausgang vom Typ float für den gefilterten Wert bereitstellen.
• Pkt 04: Liegt der Eingangswert innerhalb des Bereichs [Gültig Minimum, Gültig Maximum] (Grenzen inklusive), soll der Eingangswert an den Ausgang weitergegeben werden.
• Pkt 05: Liegt der Eingangswert außerhalb dieses Bereichs, soll der Ausgangswert nicht verändert werden und seinen zuletzt gültigen Wert beibehalten.

Die Rückfragen der KI mit "soll ich wirklich" und "passt alles" schneide ich mal weg und komme direkt zum Ergebnis.
Ich habe die Logik getestet und mit meinem (begrenzten) Fähigkeiten geprüft. Dennoch: Verwendung auf eigene Gefahr.

{
"Module": [
// Version: 1.0.0 - Datum: 2025-05-20
// --- START: Gültigkeitsprüfung (Ref. Pkt 04) ---
// Prüft, ob der Eingangswert innerhalb der definierten Grenzen liegt. Das Ergebnis wird in die boolesche Variable `$_wertIstGueltig` geschrieben.
["Limiter", "$in_Wert", 0, "$_wertIstGueltig", ["$in_GueltigMin", "$in_GueltigMax"]],
// --- ENDE: Gültigkeitsprüfung (Ref. Pkt 04) ---

// --- START: Wertübernahme bei Gültigkeit (Ref. Pkt 04, Pkt 05) ---
// Übernimmt den Eingangswert (`$in_Wert`) in die Ausgangsvariable (`$out_GefilterterWert`), aber nur, wenn `$_wertIstGueltig` TRUE ist.
// Andernfalls behält der Ausgang seinen letzten gültigen Wert.
["Latch", "$in_Wert", "$out_GefilterterWert", "$_wertIstGueltig", 0]
// --- ENDE: Wertübernahme bei Gültigkeit (Ref. Pkt 04, Pkt 05) ---
],
"Level": [
// Eingänge
["$in_Wert", "float", 0.0],
["$in_GueltigMin", "float", 0.0],
["$in_GueltigMax", "float", 100.0],
// Ausgänge
["$out_GefilterterWert", "float", 0.0],
// Interne Variablen
["$_wertIstGueltig", "bool", false]
],
"Input": [
["Wert", "Zu filternder Eingangswert (z.B. vom Sensor)", "$in_Wert", "a"],
["Gueltig Minimum", "Untere Grenze des Gültigkeitsbereichs", "$in_GueltigMin", "c"],
["Gueltig Maximum", "Obere Grenze des Gültigkeitsbereichs", "$in_GueltigMax", "c"]
],
"Output": [
["Gefilterter Wert", "Gibt den Eingangswert aus, wenn er gültig ist, ansonsten den letzten gültigen Wert.", "$out_GefilterterWert", "c"]
// LIZENZ (Prompt & Custom-Logik): Der Schöpfer überträgt die Nutzungsrechte gemäß der TOLL ("Timberwolf Open Logikblock License") die unter https://wrgt.news/TOLL zum Download zur Verfügung steht.
]
}

VG Stefan

[gbglace]

Ja die Filteroptionen in allen Quellsystemen haben wäre super, ist aber relativ aufwändig und kann mit dem Workaround Logik umgangen werden. Insofern ist es etwas was kommen wird aber nicht mit prio1. In einigen Systemen sind die UI-Elemente zum Einstieg in eine Filterdefinition ja schon vorhanden aber derzeit noch ohne Funktion. Also konzeptionell vergessen ist es auch nicht.

[Sun1453]

Zielstellung ist die Filter gut in allen Systemen zu haben, guter workaround bis dahin Daten über Logik Engine zu schieben und zu filtern.