[Beantwortet] [V4.1.1] Sollwert für Schwellwertschalter

[bbserv]

Hallo,

wer kann mir erklären wie man ein Objekt (Variable) erstellt, um einen Sollwert (Schwelle) für einen Schwellwertschalter (im Logik Manager) zu verwenden.
Ich meine damit eine externe Quelle ( keinen festen Parameter) den ich später erst mit einer Visu oder anders verwenden möchte.
Ich komme aus der SPS Welt, dort erstellt man eine Globale Variable die ich dann beliebg weiterverweden kann.
In den Video Tutorials werden immer nur vorhanden Objekte verknüpft, geht das auch anders?

Danke für die Hilfe

[gbglace]

PS Antwort gelöscht.

Es fehlen ja noch die notwendigen Angaben im Titel.

[Franky]

Hallo bbserv,

und herzlich willkommen im Forum (dein erster post). Ich bin relativ neu beim Timberwolf und habe mir auch von Forenmitgliedern, danke nochmal insbes. an @Robert_Mini helfen lassen.

An dieser Stelle ist es fair, auf die gute und permanent aktualisierte Doku link zu verweisen.

Füttert man diese Doku in eine LLM, kann man sich auch individiduell helfen lassen (mit allen Vor- und Nachteilen, die sowas mit sich bringt) (link).

Deine Anfrage wird dort bspw. so beantwortet (Achtung ausschließlich in die Richtung Custom-Logiken und nicht zu den normalen Logiken (zum Zusammenklicken in der GUI). Ich habe den Gemini Text überflogen und man kann ihn so stehen lassen, denke ich. Frag bei Fragen, die sich daraus ergeben, die Inhalte sind, wie gesagt alle aus dem Timberwolf-Wiki, das als Primärquelle (und zahlreicher wertvoller Forenbeiträge) immer herangezogen werden sollte.

=== gemini 2.5 pro Antwort START ===
Hallo,

gerne erkläre ich, wie das im Timberwolf Server (TWS) Logikeditor funktioniert. Dein Gedanke mit der globalen Variable aus der SPS-Welt ist richtig, die Umsetzung in der TWS Custom-Logik ist nur etwas anders strukturiert.

Du benötigst eine Kombination aus einer internen Variable (im Level-Array deklariert) und einem Eingang (im Input-Array definiert), die auf dieselbe interne Variable zugreifen.

Das Prinzip:

Interne Variable (Level): Hier deklarierst du eine Variable, die den Sollwert dauerhaft speichert (sie behält ihren Wert zwischen den Logik-Ausführungen, ähnlich einer statischen Variable). Wichtig ist hier auch ein Initialwert, der als Standard dient, bis der erste externe Wert kommt.
Eingang (Input): Du erstellst einen Eingang für deine Logikzelle (z.B. "Sollwert Extern"). Dieser Eingang wird später mit deinem externen Objekt (KNX GA, Visu-Objekt etc.) verbunden. Entscheidend ist: Dieser Input-Eintrag wird so konfiguriert, dass er auf die gleiche interne Variable schreibt, die du im Level-Array deklariert hast. Die Trigger-Option (z.B. "c" für "on change") bestimmt dabei, wann ein neuer externer Wert übernommen wird.EDIT: Korrektur: Wann die Logik getriggert=Durchlaufen wird
Logikmodul (Module): Dein Schwellwertschalter (Comparator) oder jedes andere Modul verwendet dann die interne Variable aus dem Level-Array als Schwellwert bzw. Datenquelle. Er greift immer auf den aktuellsten Wert dieser Variablen zu.


Beispiel:

Angenommen, du möchtest einen Temperaturwert ($TemperaturAktuell) mit einem einstellbaren Sollwert ($TemperaturSoll) vergleichen und ein boolesches Ergebnis ($HeizungAn) erhalten.

Code: Alles auswählen

[code]{
  // 1. Deklaration der internen Variablen
  "Level": [
    // Variable für den aktuellen Messwert (wird von einem anderen Eingang kommen)
    ["$TemperaturAktuell", "float", 0.0],
    // !!! Variable für den Sollwert - mit einem Startwert initialisiert !!!
    ["$TemperaturSoll", "float", 20.0],
    // Variable für das Ergebnis des Vergleichs
    ["$HeizungAn", "bool", false]
  ],

  // 3. Logikbaustein, der die interne Variable $TemperaturSoll verwendet
  "Module": [
    // Vergleicht, ob $TemperaturAktuell < $TemperaturSoll ist
    // Beachte: Comparator gibt TRUE aus, wenn Eingang > Schwelle.
    // Für "Heizung AN wenn Temp < Soll" müssen wir invertieren:
    // TRUE wenn -$TemperaturAktuell > -$TemperaturSoll
    // Oder einfacher: Eigene Logik für "<" bauen oder Ergebnis negieren.
    // Hier als Beispiel: Heizung AN, wenn $TemperaturAktuell >= $TemperaturSoll
    ["Comparator", "$TemperaturAktuell", "$HeizungAn", "$TemperaturSoll"]
    // Wenn du "<" brauchst, wäre eine Variante:
    // ["Comparator", "$TemperaturSoll", "$HeizungAn", "$TemperaturAktuell"] // TRUE wenn Soll > Aktuell
  ],

  // 2. Eingänge der Logikzelle
  "Input": [
    // Eingang für den aktuellen Temperaturwert
    ["Temp_Ist", "Aktuelle Temperatur", "$TemperaturAktuell", "c"],
    // !!! Eingang für den externen Sollwert !!!
    // Dieser Eingang schreibt den Wert vom verbundenen Objekt in die Variable $TemperaturSoll
    ["Temp_Soll_Ext", "Sollwert von Extern", "$TemperaturSoll", "c"]
    // Die Trigger-Option "c" (on change) ist hier meist sinnvoll.
  ],

  // Ausgang der Logikzelle
  "Output": [
    ["Heizung", "Heizungsanforderung", "$HeizungAn", "c"]
  ]
}

Erklärung:

Im Level-Array definieren wir $TemperaturSoll vom Typ float mit einem Startwert von 20.0. Dieser Wert wird verwendet, bis der Eingang Temp_Soll_Ext zum ersten Mal einen Wert erhält.

Im Input-Array definieren wir den Eingang Temp_Soll_Ext. Als drittes Argument geben wir $TemperaturSoll an. Das bedeutet: Wenn ein Objekt mit diesem Eingang verbunden wird und einen Wert sendet, wird dieser Wert in die interne Variable $TemperaturSoll geschrieben.

Im Module-Array greift der Comparator auf die interne Variable $TemperaturSoll zu, um den Vergleich durchzuführen. Er verwendet immer den aktuellsten Wert, der in $TemperaturSoll gespeichert ist (entweder der Initialwert oder der letzte Wert, der über den Eingang Temp_Soll_Ext kam).

Wie verwendest du das im Logik Manager?

Erstelle eine neue Custom-Logik und füge den obigen JSON-Code ein (oder passe ihn an).

Speichere die Logikzelle. Du siehst jetzt die Eingänge "Temp_Ist" und "Temp_Soll_Ext" sowie den Ausgang "Heizung".

Jetzt kommt der entscheidende Schritt, den du aus den Videos kennst:

Ziehe dein Objekt für den Ist-Wert (z.B. KNX GA vom Temperatursensor) auf den Eingang "Temp_Ist".

Ziehe dein Objekt für den Sollwert (z.B. eine KNX Gruppenadresse, die du per Visu beschreibst, oder ein Visu-Objekt direkt) auf den Eingang "Temp_Soll_Ext".

Verbinde den Ausgang "Heizung" mit dem Objekt, das geschaltet werden soll.

Jetzt wird jeder Wert, der an das mit "Temp_Soll_Ext" verbundene Objekt gesendet wird, automatisch in die interne Variable $TemperaturSoll übernommen und vom Comparator verwendet. Du hast somit deinen extern einstellbaren Sollwert realisiert.
=== gemini 2.5 pro Antwort ENDE ===

[bbserv]

Hallo Franky,

vielen Dank für die schnelle und umfangreiche Antwort.

Ich denke ich habe die Vorgehensweise jetzt verstanden, ich hatte versucht mit dem "Schwellwertmodul" in der Logikauswahl zu arbeiten.
Und dann vergeblich gesucht wie man ein Objekt (Variable) zu erstellen ohne Verknüpfung zu einer Schnittstelle.

Ich arbeite schon viele Jahre mit der PCworx Software, da hat sich die Vorgehensweise schon sehr eingebrannt.

Man muss doch sehr umdenken und die im Abläufe im TWS erst wieder verinnerlichen.


Nochmals Danke und eine schönen Feiertag

[gbglace]

@Franky
Da hat Gemini aber das Problem des Users im TWS nicht verstanden.

@bbserv
Ein Objekt ohne Systemquelle gibt es nicht.

Du kannst eine Logik bauen die einfach einen Input den Du als Konstante definierst bauen.Auf den Ausgang geht das 1:1 raus. in Verbindung mit Persistenz Modus sollte nun im Objektsystem des TWS ein Logikobjekt vorhanden sein welches Du dann an beliebiger Stelle verwenden kannst.

Wenn mal noch die TWS Systemobjekte verfügbar sind kannst da auch nach einem Reboot momentum suchen und das als Auslöser Trigger nehmen, dann ist auch nach einem massiven Reboot ein frischer Wert im Objektsystem vorhanden.

Ansonsten müsste man nochmal hier in größerer Runde über ein zusätzliches Objektsystem für solche User definierten Wertkonstanten reden und das als Featurerequest ausformulieren, wenn man merkt da besteht größeres allgemeines Interesse und Mehrwertpotenzial.

Wenn Du den Wert per Visu verändern definieren willst kannst natürlich auch direkt ein Visuobjekt anlegen und dort diese Konstante pflegen. Oder eben erstmal nur diese Logik und dann später das Visuobjekt zum Editieren/Anzeigen da dran verbinden.

[bbserv]

Hallo gbglace,

die Antwort von @Franky (Gemini) war schon richtig, da ich aus der SPS Welt komme bin ich gewöhnt eine globale Variable zu erstellen.
Diese kann ich dann mit einem Initialwert belegen (remanet oder Kaltstart Reboot) und von den Visu's oder andern Aufrufen ändern.
Den Vorteil sehe ich in der SPS Programmerierung das man nur eine Variable (Objekt) für verschiedene Schnittstellen (Zugriffe) hat.
Im TWS ist die Denkweise etwas anders, ein globales Objekt welches an den verschiedenen Schnittstellen verwendet werden kann würde ich natürlich auch nur begrüßen. Es würde die Anzahl an Objekten sicherlich etwas verringern und damit übersichtlicher werden.

Schönen Feiertag zusammen

J.B.

[Marino]

Aber das meint Göran doch.
Wenn Du nach seinem Beispiel eine Logik anlegst, die am Ausgang den Wert hat, den Du als Variable möchtest, dann ist das ein Objekt (z.B. Logik 100 O1, also Logik 100 Ausgang 1).
Das kannst Du dann anbinden, wo Du es brauchst (MQTT, andere Logik, o.ä.) und das ganze auch Mehrfach.

Deine globale Variable ist dann halt Logik 100 Ausgang 1. Wenn Du das änderst, ist es überall gleich. Du legst halt nur kein Variable direkt im Objektsystem an, sondern benötigst diesen Umweg.

[Parsley]

Hallo @bbserv und willkommen im Forum

Bitte deinen TWS nicht im Titel, sondern in deiner Signatur eintragen. Mindestens TWS Modell und ID, besser auch mit der Info ob du das Service VPN aktiviert hast.
Danke!

[gbglace]

@ Marino.

Stimmt und man kann da sogar in einer solcher Logik auch mehrere Variablen definieren., wenn man es als Customlogik baut. Da ist man ja nicht wirklich begrenzt in der Menge an Objekten. Und wie gesagt jeder Variable kann man da einen fixen Eingang und einen Variablen Eingang spendieren um sie dann auch per Visu manipulieren zu können.

Damit kann man sich dann Lösungen bauen wie eine Logik eine Variable, eine Logik alle Variablen eines Datentyps oder eine Logik für alle solcher Fixvalues.

In dem Moment ist es in einem Subsystem ein Objekt und steht allen anderen via dem Dispatcher zur Verfügung.