[Erfahrungsbericht] [V4.5 IP4] Nutzung von KI (LLM) für Dokumentation und Custom-Logiken

[StefanW]

Hi,

wir überlegen ein Cloudbasiertes Repository für so ziemlich alles, was "Konfigurationen" sind. Das ist auch der Grund, warum es nun Im- und Exportierbare Profile auch für MQTT und HTTP-/REST-API (neben Modbus und Logiken) gibt. Die Gedankten schließen auch die VISU mit ein.

Bedeutet, wir wollen die Leistung der Community deutlich besser integrieren für eine einfache Nutzung durch jeden anderen Kunden. Nur ohne Zwang, wer seine Module nicht veröffentlichen will, tut das eben nicht. Aber mit einem Klick steht es für alle zur Verfügung.

Nein, ich habe hiermit nichts versprochen, nur laut gedacht und ich kann auch keinen Termin nennen und ich möchte auch keine Rückfragen, wann es fertig sein könnte. Weil wir arbeiten agil und fertig ist es alles und jedes erst dann, wenn es als Firmware veröffentlicht wird.

lg

Stefan

[Franky]

Mir wäre eine normale Programmiersprache immer noch lieber.[/url]

Boah Nachbarsgarten ist immer grüner als der eigene, verflixt:

Total erfreut und nicht wissend, wie ich das in prozeduraler Sprache lösen würde und ob dass der Wettbewerb hat:

Nur jetzt zum Thema Logik... Dispatcher und Bus Monitor spielen sowieso in einer ganz anderen Liga:

• Die Kombination von Code (Custom Logik) und GUI zum Verknüpfen von Objekten ist dufte,

• die automagische Aktivierung von Triggern durch Nutzung von bestimmten Bausteinen (Monoflop, Clocksignal, ...) ist dufte,

• die einfache Aktivierung eines Zeittriggers, der einen Logikausgang in Ergänzung zu "nur bei Änderung" ("ct") senden lässt (keep alive auf einzelner Logikebene) ist dufte, um bspw. die TWS-Logik parallel zu einer einfachereren nativen KNX-Fallback-Lösung zu betreiben, falls die TWS-Lösung mal ausfallen sollte (weil man dev-Tester ist / am Insiderprogramm teilnimmt) .

• wir haben ein statemachine-Baustein

• ...

Ich glaube die Liste wird bei mir noch wachsen.

Franky

[Franky]

So, es geht weiter.

Lüftersteuerung mit TWS-Statemachine und einem interessanten "Masterprompt"-Ansatz mit Metaanweisungen. Es ist ein Kontextspeicher zu Beginn des Prompts vorgesehen, damit die LLM die unvermeidbaren Chat-Neustarts "überlebt" und sich "erinnern" kann.

Work in progress: Inhaltlich noch kein feedback notwendig, wollte nur mal ein Zwischenstand von dem Prompt posten,

Der Prompt ist interaktiv mit der LLM (https://aistudio.google.com/) erstellt worden. Da ist (custom-logik)-codeseitig noch Blödsinn drin.

Das interessante, ich habe nur ca 10% vom Prompt geschrieben 0% vom Code. Den Rest hat alles das LLM "im Dialog" geschrieben. Ein ganz neuer Ansatz. Will nicht wissen, wo wir in 1-2 Jahren stehen

Code: Alles auswählen

KONTEXTSPEICHER (Stand nach Dialog):
- Status: Anforderungen finalisiert nach Klärung von SM.2 (MaxZeit-Logik) und SM.3 (Verlassen State 5).
- Nächste Schritte: Generierung des vollständigen JSON-Codes basierend auf dem finalisierten Masterprompt.
- Offene Punkte: Keine.

--- START DES MASTERPROMPTS ---

FINALER MASTERPROMPT (REINES ASCII, Umlaute erlaubt):

ANWEISUNGEN FÜR DIE PROMPT-OPTIMIERUNG:

WICHTIG: Sprich in deutscher Sprache mit mir. Fordere sofort die Timberwolf.pdf-Dokumentation an, falls nicht vorhanden.
Dieser Prompt dient als Master-Dokument und enthält alle relevanten Informationen, Entscheidungen und offenen Punkte. Alles, was für das Verständnis
und die Weiterentwicklung in einem neuen Chatkontext notwendig ist, muss hier festgehalten werden. Stelle bei Unklarheiten Rückfragen.
Prompt-Ausgabe: Gib den Prompt nur vollständig aus, wenn wesentliche Änderungen erfolgt sind oder auf explizite Anforderung. Aktualisiere ihn im Hintergrund stets und prüfe auf Konsistenz. Gibst du den Prompt aus, dann vollständig und **innerhalb eines einzigen Code-Blocks (z.B. ```text ... ```)**.

Du bist ein Experte für die Erstellung von Custom-Logiken für den Timberwolfserver und hast die Funktionsweise der "Custom-Logik" des Timberwolf-Servers
und der verfügbaren Module (Statemachine, Monoflop, Lowpass, Comparator, Triggered, SendExplicit, Clocksignal, And, Or, Limiter, Polynomial, Latch, Multiplexer etc.)
durch Studium der bereitgestellten Dokumentation verinnerlicht.
[Ergänzung: Zum Monoflop-Reset-Verhalten]: Ein TRUE am Reset-Eingang eines Monoflops stoppt einen laufenden Timer aktiv und setzt ihn zurück.
[Ergänzung: Zur Monoflop-Triggerung]: Das Monoflop-Modul triggert die Logik, wenn sein interner Timer abläuft.
[Ergänzung: Variablen-Scope und Timing in Custom Logik]:
- Interne Variablen werden im Level-Array deklariert und beginnen immer mit $. Nur diese $Variablen können innerhalb des Module-Arrays gelesen und als Ziel von
  Modulen verwendet werden.
- Externe Namen für Ein- und Ausgänge (für GUI und Verknüpfungen) werden im Input- und Output-Array als <Name> (ohne $) definiert und dürfen Freizeichen enthalten.
- Das Output-Array verknüpft einen externen <Name> mit einer internen $Variablen (<Variablenname>), deren Wert dann (gemäß Sendeoption) an den Ausgang gesendet wird.
  Der externe <Name> selbst kann nicht direkt im Module-Array verwendet werden.
- Verfügbarkeit von Werten innerhalb eines Zyklus: Wird der Wert einer internen $Variable durch ein Modul geändert, ist dieser neue Wert sofort für alle
  nachfolgenden Module im selben Logik-Durchlauf verfügbar und lesbar. Dies gilt auch für $Variablen, die im Output-Array mit einem externen Ausgang verknüpft sind.
- "Abgerechnet wird erst am Schluss": Dieses Prinzip aus der Dokumentation bezieht sich auf die externe Übertragung des Wertes an den Ausgang (z.B. Senden auf den
  Bus). Es bedeutet nicht, dass der aktualisierte Wert einer internen $Variable (die mit einem Ausgang verknüpft ist) intern nicht sofort lesbar wäre.
[INFO: Korrektes Verhalten des `Triggered`-Moduls]: Das Modul `["Triggered", "$InputVar", "$OutputVar"]` prüft, ob die spezifische Eingangsvariable `$InputVar` der **Auslöser für den aktuellen Durchlauf** der Logikzelle war. `$OutputVar` wird TRUE, wenn `$InputVar` der Auslöser war, andernfalls FALSE. Es prüft *nicht* primär eine Wertänderung, sondern die kausale Triggerung des aktuellen Logikzyklus durch diesen spezifischen Eingang. In Kombination mit Trigger-Option "a" (always) wird der Ausgang von `Triggered` also TRUE, wann immer ein Wert am entsprechenden Eingang eintrifft und die Logik dadurch auslöst.
[INFO: Gleichheitsprüfung mit Limiter (WICHTIG!)]: Um zu prüfen, ob eine Variable (z.B. `$calc_State`) **exakt** einem bestimmten Wert entspricht (z.B. `1`), muss das `Limiter`-Modul verwendet werden: `["Limiter", "$Variable", 0, "$ErgebnisBool", [Wert, Wert]]`. Das `Comparator`-Modul prüft nur auf `größer als` (`>`) und ist für Gleichheitsprüfungen **ungeeignet**!

Fachbegriffe im Chat und Code dürfen in Englisch sein.

Du sollst mir dabei helfen, den gesamten nachfolgenden Prompt-Text (inklusive dieser und folgender Meta-Anweisungen) zu optimieren.

Die Metaanweisungen und "ANFORDERUNGEN" sind auf Klarheit, Vollständigkeit, Widerspruchsfreiheit, Eindeutigkeit, Definitionsvollständigkeit und technische Präzision
im Kontext der Timberwolfserver Custom-Logiken, speziell für den Statemachine-Ansatz mit externen Timern, unter Berücksichtigung der bereitgestellten Dokumentation
zu prüfen. Finde alle Stellen, an denen Anforderungen mehrdeutig, widersprüchlich, unvollständig oder potenziell fehlerhaft interpretiert werden könnten.
Achte auch auf genaue Trigger-Bedingungen, Verhalten in Grenzfällen, Timer-Parameter, Reset-Verhalten von Timern.

Problematische Stellen sind zur Klärung im Prompt zu markieren und im Dialog mit mir anzusprechen (statt sie eigenmächtig zu lösen).
Markiere Unklarheiten in "ANFORDERUNGEN" deutlich und präzise mit [ToDo: KLÄRUNGSBEDARF: Kurze Beschreibung]. Formuliere direkt darunter die konkrete
Rückfrage oder die zu klärenden Alternativen. (Aktuell keine offenen Punkte markiert).

KEINE ANNAHMEN TREFFEN - FRAGEN STELLEN: Triff keine Annahme über die gewünschte Logik, stell Fragen.

Die Struktur für die Statemachine-Implementierung, bei technischer Notwendigkeit mit externen Timern, ist vorzubereiten und zu verfeinern.

Self-Debugging-Ansatz: Nutze den 'Trockentest', um den Prompt gedanklich durchzuführen und gezielt Stellen zu identifizieren, die Rückfragen erfordern,
insbesondere bei Zustandsübergängen und Timer-Interaktionen.

Der 'Trockentest' dient primär dazu, Unklarheiten zu identifizieren und Rückfragen zu generieren, nicht dazu, eine Lösung vorwegzunehmen. Die identifizierten
"Stolpersteine" und die daraus resultierenden Fragen/Alternativen müssen klar im Prompt markiert werden.

Starte zunächst damit alles zu verstehen und weise mich auf etwaige Fragen oder Probleme hin, ansonsten warte meine Anweisung ab.
Beziehe dich bei der Überprüfung explizit auf die bereitgestellte Dokumentation.

Kritische Überprüfung von Anforderungen:

Hinterfrage aktiv, ob die im Prompt definierten technischen Anforderungen mit den verfügbaren Mitteln der Timberwolfserver-Plattform umsetzbar
sind, insbesondere mit dem Statemachine-Modul und externen Monoflops.

Prüfe besonders die Timer-Interaktionen (Start, Stopp, Reset-Bedingungen gemäß Modul-Doku), die Bedingungslogik für die Statemachine und die Prioritätenreihenfolge.

Schlage bei technischen Limitierungen oder ungeeigneten Modulwahlen proaktiv alternative Implementierungsmöglichkeiten vor. Baue keine Lösungen unabgesprochen ein.
Dies beinhaltet explizit den Vorschlag, externe Timer (Monoflop bevorzugt) und kombinatorische Logik zu verwenden, falls sich interne Mechanismen (z.B.
Statemachine-Timer/Übergänge) als unzureichend für das gewünschte Verhalten erweisen.

ASCII-Nur Format: Der gesamte Prompt (inkl. der Metaanweisungen im Anfang) muss in reinem ASCII-Text (Umlaute erlaubt) formatiert sein. Der
Zeilenumbruch sollte so erfolgen, dass er in einem reinen Texteditor mit ca. 160 Zeichen Breite gut lesbar ist. Rechtschreibfehler und Fehler in der Zeichensetzung
sind zu korrigieren.

Dokumentationsreferenz: Beziehe dich bei Vorschlägen zur Verwendung von Modulen auf die bereitgestellte Dokumentation, um die korrekte Anwendung
sicherzustellen und ggf. auf Einschränkungen oder Besonderheiten hinzuweisen.

"ANFORDERUNGEN" (Statemachine-Ansatz mit externen Timern und Catch-All):

TIMBERWOLFSERVER CUSTOM-LOGIK: FEUCHTIGKEITSGESTEUERTE LÜFTERSTEUERUNG MIT STATEMACHINE UND EXTERNEN TIMERN

Diese Logik implementiert eine Lüftersteuerung mittels des Statemachine-Moduls, wobei die Timer für manuellen Betrieb und Nachlauf als externe
Monoflop-Module realisiert werden müssen, da die Timer des Statemachine-Moduls nicht über mehrere Zustandswechsel hinweg funktionieren.

GRUNDFUNKTIONALITÄT:
- Automatische Lüftersteuerung basierend auf relativer Luftfeuchtigkeit mit Hysterese.
- Manueller Lüfterbetrieb durch Tasterbedienung mit definierter Laufzeit (via externem Monoflop).
- Zeitgesteuerter Nachlauf nach Unterschreiten der Feuchtigkeitsschwelle (via externem Monoflop, nicht retriggerbar im Sinne eines Timer-Neustarts bei
  erneutem Unterschreiten der Schwelle während des Nachlaufs; Neustart erfolgt über Zustandswechsel 2->1->2. Somit startet das nicht retriggerbare Monoflop
  einen komplett neuen Nachlaufzyklus).
- Übergeordnete Sperrfunktion.
- Sicherheitsabschaltung nach maximaler ununterbrochener Laufzeit (via externem Monoflop). Nach Ablauf bleibt der Lüfter aus, bis die Feuchteanforderung endet. Manuelle Übersteuerung ist möglich.
- Bus-Reset-Funktion zur erneuten Ausgabe des aktuellen Lüfterstatus, damit der Status des Lüfters an den Lüfterstatus gemäß Logik angepasst wird. Fachlicher
  Hintergrund ist, dass bei Busreset und Aktorneustart der Lüfter in einen Zustand versetzt sein kann, der vom Lüfterzustand unserer Logik abweicht.
- Fehlererkennung für unbehandelte Zustandsübergänge.

ZUSTÄNDE (Variable $calc_State):

0: AUS - Lüfter ist aus, keine Anforderung aktiv.
1: FEUCHTE - Lüfter läuft aufgrund hoher Feuchtigkeit.
2: NACHLAUF - Lüfter läuft nach (externer Timer $calc_isNachlaufTimerLaeuft ist aktiv).
3: MANUELL - Lüfter läuft manuell (externer Timer $calc_isManuellTimerLaeuft ist aktiv).
4: GESPERRT - Lüfter ist aus aufgrund einer externen Sperre (höchste Priorität).
5: MAX_ZEIT - Lüfter ist aus aufgrund Überschreitung der maximalen Laufzeit (zweithöchste Priorität, bleibt aktiv bis Feuchteanforderung endet oder manuell übersteuert wird).
99: FEHLER - Unbehandelte Situation in der Statemachine erkannt (Catch-All), transienter Zustand.

DETAILLIERTE ANFORDERUNGEN:
1. VORVERARBEITUNG & BEDINGUNGEN:

   // Feuchtigkeitsglättung (Lowpass auf Eingangswert, Zeitkonstante aus Parameter)
   ["Lowpass", "$in_Feuchte", "$calc_Feuchte_geglaettet", "$in_param_Feuchte_GlaettungDauer"]

   // Schwellen berechnen (Basis: geglättete Feuchte + Offsets aus Parametern)
   ["Polynomial", "$ConstTrue", "$calc_EinschaltFeuchte", ["$calc_Feuchte_geglaettet", "$in_param_Feuchte_EinschaltOffset"]]
   ["Polynomial", "$ConstTrue", "$calc_AusschaltFeuchte", ["$calc_Feuchte_geglaettet", "$in_param_Feuchte_AusschaltOffset"]]

   // Feuchtigkeitsvergleiche (Strikte Ungleichheit > bzw. <)
   ["Comparator", "$in_Feuchte", "$calc_isFeuchteUeberEinschalt", "$calc_EinschaltFeuchte"]         // Ist aktuelle Feuchte > Einschalt-Schwelle?
   ["Comparator", "$calc_AusschaltFeuchte", "$calc_isFeuchteUnterAusschalt", "$in_Feuchte"]       // Ist aktuelle Feuchte < Ausschalt-Schwelle?
   ["Comparator", "$in_Feuchte", "$calc_isFeuchteWiederUeberAusschalt", "$calc_AusschaltFeuchte"] // Ist aktuelle Feuchte > Ausschalt-Schwelle? (Für Nachlaufabbruch)

   // Feuchteanforderung (Hysterese - wird gesetzt bei Überschreiten der Einschaltschwelle, rückgesetzt bei Unterschreiten der Ausschaltschwelle)
   ["Latch", "$ConstTrue", "$calc_isFeuchteAnforderungAktiv", "$calc_isFeuchteUeberEinschalt", 0]    // Setzen bei > Einschalt
   ["Latch", "$ConstFalse", "$calc_isFeuchteAnforderungAktiv", "$calc_isFeuchteUnterAusschalt", 0]   // Rücksetzen bei < Ausschalt
   // (Initialwert von $calc_isFeuchteAnforderungAktiv ist FALSE)

   // Tastererkennung (Steigende Flanke am Eingang $in_Taster_manuellesLueften)
   ["Triggered", "$in_Taster_manuellesLueften", "$calc_isTasterLueftungCurrentTrigger"]
   ["And", ["$calc_isTasterLueftungCurrentTrigger", "$in_Taster_manuellesLueften"], "$calc_isTasterBetaetigt"] // Wird TRUE für einen Zyklus bei steigender Flanke

   // Sperre (Übernimmt Wert vom Eingang $in_LuefterSperre)
   // ["And", ["$in_LuefterSperre"], "$calc_isSperreAktiv"] // Alternative, wenn keine interne Logik die Sperre beeinflusst.
   ["Latch", "$in_LuefterSperre", "$calc_isSperreAktiv", "$ConstTrue", 0] // Aktuelle Implementierung

   // Trigger für initialen Nachlaufstart (Nur wenn State=1 UND Feuchte < Ausschaltschwelle)
   // Prüft mit Limiter, ob State am Anfang des Zyklus == 1 war.
   ["Limiter", "$calc_State", 0, "$calc_isState1", [1, 1]] // Prüft ob $calc_State == 1 zu Beginn des Zyklus
   ["And", ["$calc_isState1", "$calc_isFeuchteUnterAusschalt"], "$calc_isStartNachlaufTrigger"]

2. EXTERNER TIMER: MANUELLER BETRIEB ($calc_isManuellTimerLaeuft)

   // Reset-Bedingung für Manuell-Timer: Sperre aktiv ODER MaxZeit abgelaufen (als Impuls)
   ["Or", ["$calc_isSperreAktiv", "$calc_isMaxZeitTimerAbgelaufen"], "$calc_isResetManuellTimer"] // Verwendet den Impuls aus Pkt. 4

   // Monoflop für Manuell-Betrieb: Start/Retrigger bei Tasterbetätigung, Laufzeit aus Parameter, Stopp bei Reset-Bedingung. Option 3 = retriggerbar.
   ["Monoflop", "$calc_isTasterBetaetigt", "$calc_isResetManuellTimer", "$calc_isManuellTimerLaeuft", "$in_param_TasterLueftung_Laufzeit", 3]

   // Ablauf-Erkennung Manuell-Timer (Fallende Flanke von $calc_isManuellTimerLaeuft)
   ["Latch", "$calc_isManuellTimerLaeuft", "$calc_isManuellTimerLaeuftLetzterZyklus", "$ConstTrue", 0]
   ["And", ["$calc_isManuellTimerLaeuftLetzterZyklus", "-$calc_isManuellTimerLaeuft"], "$calc_isManuellTimerGeradeAbgelaufen"]

   // Kombinierte Bedingungen für Statemachine-Übergänge nach Manuell-Ende
   ["And", ["$calc_isManuellTimerGeradeAbgelaufen", "$calc_isFeuchteAnforderungAktiv"], "$calc_isManuellTimerEndeUndFeuchteHoch"]
   ["And", ["$calc_isManuellTimerGeradeAbgelaufen", "-$calc_isFeuchteAnforderungAktiv"], "$calc_isManuellTimerEndeUndTrocken"]

3. EXTERNER TIMER: NACHLAUF ($calc_isNachlaufTimerLaeuft)

   // Reset-Bedingung für Nachlauf-Timer: Sperre ODER MaxZeit (als Impuls) ODER Feuchte wieder über Ausschalt ODER Taster betätigt
   ["Or", ["$calc_isSperreAktiv", "$calc_isMaxZeitTimerAbgelaufen", "$calc_isFeuchteWiederUeberAusschalt", "$calc_isTasterBetaetigt"], "$calc_isResetNachlaufTimer"] // Verwendet den Impuls aus Pkt. 4

   // Monoflop für Nachlauf: Start bei $calc_isStartNachlaufTrigger, Laufzeit aus Parameter, Stopp bei Reset-Bedingung. Option 2 = nicht retriggerbar.
   ["Monoflop", "$calc_isStartNachlaufTrigger", "$calc_isResetNachlaufTimer", "$calc_isNachlaufTimerLaeuft", "$in_param_Feuchte_Nachlaufzeit", 2]

   // Ablauf-Erkennung Nachlauf-Timer (Fallende Flanke von $calc_isNachlaufTimerLaeuft)
   ["Latch", "$calc_isNachlaufTimerLaeuft", "$calc_isNachlaufTimerLaeuftLetzterZyklus", "$ConstTrue", 0]
   ["And", ["$calc_isNachlaufTimerLaeuftLetzterZyklus", "-$calc_isNachlaufTimerLaeuft"], "$calc_isNachlaufTimerGeradeAbgelaufen"]

4. MAXIMALE LAUFZEITÜBERWACHUNG ($calc_isMaxZeitTimerLaeuft -> $calc_isMaxZeitTimerAbgelaufen)

   // Monoflop für MaxZeit: Startet bei steigender Flanke des Lüfter-Ausgangs, Reset bei fallender Flanke. Option 2 = nicht erneut startbar.
   // WICHTIG: Verwendet den intern berechneten Lüfterzustand $out_LuefterEA_logic_result.
   ["Monoflop", "$out_LuefterEA_logic_result", "-$out_LuefterEA_logic_result", "$calc_isMaxZeitTimerLaeuft", "$in_param_Luefter_max_Laufzeit", 2]

   // Ermittlung, ob MaxZeit-Timer GERADE abgelaufen ist (Ein-Zyklus-Impuls). (Geklärt SM.2)
   // Hierfür ist die explizite Erkennung der fallenden Flanke notwendig.
   // Alternative: Ein Latch mit Trigger-Option 2 auf "$calc_isMaxZeitTimerLaeuft" würde auch bei
   // externem Reset (z.B. durch Sperre -> Lüfter AUS) fälschlicherweise auslösen.
   // Daher: Speichern des letzten Zustands und Vergleich mit aktuellem Zustand.
   ["Latch", "$calc_isMaxZeitTimerLaeuft", "$calc_isMaxZeitTimerLaeuftLetzterZyklus", "$ConstTrue", 0] // Letzten Zustand des Timers merken
   ["And", ["$calc_isMaxZeitTimerLaeuftLetzterZyklus", "-$calc_isMaxZeitTimerLaeuft"], "$calc_isMaxZeitTimerAbgelaufen"] // Fallende Flanke = Timer gerade abgelaufen (Impuls für SM)

   // Die Variable $calc_isMaxZeitTimerWarBereitsAbgelaufen und die zugehörige Persistenzlogik wurden entfernt (Vereinfachung SM.2).


5. STATEMACHINE LOGIK (Variable $calc_State, Initialzustand: 0):

   // Die folgenden Regeln werden im transitions-Array des Statemachine-Moduls exakt in dieser Reihenfolge definiert.
   // Die Timeout-Parameter der Regeln sind immer 0, da externe Timer verwendet werden.
   ["Statemachine",
     [
       // --- Priorität 1: SPERRE (State 4) ---
       // Regeln für alle Zustände, um nach State 4 zu wechseln, wenn Sperre aktiv wird.
       ["$calc_isSperreAktiv",  0, 4, 0], // Von AUS nach GESPERRT
       ["$calc_isSperreAktiv",  1, 4, 0], // Von FEUCHTE nach GESPERRT
       ["$calc_isSperreAktiv",  2, 4, 0], // Von NACHLAUF nach GESPERRT
       ["$calc_isSperreAktiv",  3, 4, 0], // Von MANUELL nach GESPERRT
       ["$calc_isSperreAktiv",  5, 4, 0], // Von MAX_ZEIT nach GESPERRT (höchste Priorität in State 5)
       ["$calc_isSperreAktiv", 99, 4, 0], // Von FEHLER nach GESPERRT
       // Regel zum Verlassen von State 4, wenn Sperre aufgehoben wird.
       ["-$calc_isSperreAktiv", 4, 0, 0], // Von GESPERRT nach AUS

       // --- Priorität 2: MAX_ZEIT (State 5) ---
       // Übergänge nach MAX_ZEIT (nur aus aktiven Lüfterzuständen, wenn MaxZeit gerade abgelaufen ist - Impuls!)
       ["$calc_isMaxZeitTimerAbgelaufen", 1, 5, 0], // Von FEUCHTE nach MAX_ZEIT
       ["$calc_isMaxZeitTimerAbgelaufen", 2, 5, 0], // Von NACHLAUF nach MAX_ZEIT
       ["$calc_isMaxZeitTimerAbgelaufen", 3, 5, 0], // Von MANUELL nach MAX_ZEIT
       // Verlassen von MAX_ZEIT (wenn keine Sperre aktiv)
       // Erst prüfen, ob manuell übersteuert wird (mittlere Priorität in State 5)
       ["$calc_isTasterBetaetigt", 5, 3, 0], // Von MAX_ZEIT nach MANUELL bei Tasterbetätigung (Geklärt SM.3)
       // Dann prüfen, ob Feuchteanforderung wegfällt (niedrigste Priorität in State 5)
       ["-$calc_isFeuchteAnforderungAktiv", 5, 0, 0], // Von MAX_ZEIT nach AUS, wenn Feuchteanforderung wegfällt (Geklärt SM.3)

       // --- Priorität 3: MANUELLER BETRIEB (State 3) ---
       // Starten von MANUELL durch Taster (aus Zuständen, wo Lüfter AUS oder läuft)
       ["$calc_isTasterBetaetigt", 0, 3, 0], // Von AUS nach MANUELL
       ["$calc_isTasterBetaetigt", 1, 3, 0], // Von FEUCHTE nach MANUELL (unterbricht Feuchte)
       ["$calc_isTasterBetaetigt", 2, 3, 0], // Von NACHLAUF nach MANUELL (unterbricht Nachlauf)
       // Ende von MANUELL (externer Timer abgelaufen)
       ["$calc_isManuellTimerEndeUndFeuchteHoch", 3, 1, 0], // Von MANUELL nach FEUCHTE (wenn Feuchteanforderung noch aktiv)
       ["$calc_isManuellTimerEndeUndTrocken",    3, 0, 0], // Von MANUELL nach AUS (wenn keine Feuchteanforderung)

       // --- Priorität 4: AUTOMATIK (FEUCHTE State 1, NACHLAUF State 2) ---
       // Starten von FEUCHTE (nur aus AUS)
       ["$calc_isFeuchteAnforderungAktiv", 0, 1, 0], // Von AUS nach FEUCHTE
       // Starten von NACHLAUF (nur aus FEUCHTE, wenn Feuchte unter Ausschalt)
       ["$calc_isStartNachlaufTrigger",    1, 2, 0], // Von FEUCHTE nach NACHLAUF
       // Während NACHLAUF
       ["$calc_isFeuchteWiederUeberAusschalt", 2, 1, 0], // Von NACHLAUF zurück nach FEUCHTE (wenn Feuchte wieder steigt, Nachlauf-Timer wird resettet)
       ["$calc_isNachlaufTimerGeradeAbgelaufen", 2, 0, 0], // Von NACHLAUF nach AUS (wenn Nachlaufzeit abgelaufen)

       // --- Catch-All für unbehandelte Fälle -> FEHLER (State 99) ---
       // Diese Regeln sollten idealerweise nie greifen, wenn die Logik vollständig ist.
       ["$ConstTrue",  0, 99, 0], // Unerwartet in AUS
       ["$ConstTrue",  1, 99, 0], // Unerwartet in FEUCHTE
       ["$ConstTrue",  2, 99, 0], // Unerwartet in NACHLAUF
       ["$ConstTrue",  3, 99, 0], // Unerwartet in MANUELL
       ["$ConstTrue",  5, 99, 0], // Unerwartet in MAX_ZEIT

       // --- Verhalten im FEHLER Zustand (State 99) ---
       // [$calc_isSperreAktiv, 99, 4, 0] ist bereits oben bei Priorität 1 abgedeckt.
       ["$ConstTrue", 99, 0, 0]  // Von FEHLER immer zurück nach AUS (sofern nicht gesperrt) - Default-Rückfall
     ],
     "$calc_State" // Variable, die den Zustand speichert
   ]

6. AUSGANGSLOGIK:

   // Finalen Lüfterzustand ableiten: Lüfter ist AN in State 1 (FEUCHTE), 2 (NACHLAUF), 3 (MANUELL).
   // Verwendet Multiplexer. Sicherstellen, dass Array 100 Elemente hat (für Index 0-99).
   ["Multiplexer",
     [
       "$ConstFalse", // State 0: AUS
       "$ConstTrue",  // State 1: FEUCHTE -> AN
       "$ConstTrue",  // State 2: NACHLAUF -> AN
       "$ConstTrue",  // State 3: MANUELL -> AN
       "$ConstFalse", // State 4: GESPERRT -> AUS
       "$ConstFalse", // State 5: MAX_ZEIT -> AUS
       // Füllwerte für States 6 bis 98 (alle $ConstFalse)
       "$ConstFalse", "$ConstFalse", "$ConstFalse", "$ConstFalse", "$ConstFalse", "$ConstFalse", "$ConstFalse", "$ConstFalse", "$ConstFalse", "$ConstFalse", // 6-15
       "$ConstFalse", "$ConstFalse", "$ConstFalse", "$ConstFalse", "$ConstFalse", "$ConstFalse", "$ConstFalse", "$ConstFalse", "$ConstFalse", "$ConstFalse", // 16-25
       "$ConstFalse", "$ConstFalse", "$ConstFalse", "$ConstFalse", "$ConstFalse", "$ConstFalse", "$ConstFalse", "$ConstFalse", "$ConstFalse", "$ConstFalse", // 26-35
       "$ConstFalse", "$ConstFalse", "$ConstFalse", "$ConstFalse", "$ConstFalse", "$ConstFalse", "$ConstFalse", "$ConstFalse", "$ConstFalse", "$ConstFalse", // 36-45
       "$ConstFalse", "$ConstFalse", "$ConstFalse", "$ConstFalse", "$ConstFalse", "$ConstFalse", "$ConstFalse", "$ConstFalse", "$ConstFalse", "$ConstFalse", // 46-55
       "$ConstFalse", "$ConstFalse", "$ConstFalse", "$ConstFalse", "$ConstFalse", "$ConstFalse", "$ConstFalse", "$ConstFalse", "$ConstFalse", "$ConstFalse", // 56-65
       "$ConstFalse", "$ConstFalse", "$ConstFalse", "$ConstFalse", "$ConstFalse", "$ConstFalse", "$ConstFalse", "$ConstFalse", "$ConstFalse", "$ConstFalse", // 66-75
       "$ConstFalse", "$ConstFalse", "$ConstFalse", "$ConstFalse", "$ConstFalse", "$ConstFalse", "$ConstFalse", "$ConstFalse", "$ConstFalse", "$ConstFalse", // 76-85
       "$ConstFalse", "$ConstFalse", "$ConstFalse", "$ConstFalse", "$ConstFalse", "$ConstFalse", "$ConstFalse", "$ConstFalse", "$ConstFalse", "$ConstFalse", // 86-95
       "$ConstFalse", "$ConstFalse", "$ConstFalse", // States 96-98
       "$ConstFalse"  // State 99: FEHLER -> AUS
     ],
     "$out_LuefterEA_logic_result",
     "$calc_State"
   ]


   // Fehlertext ableiten (Multiplexer basierend auf $calc_State)
   // Array muss 100 Elemente haben, Index 0..99.
   ["Multiplexer",
     [
       "AUS",                     // 0
       "FEUCHTE",                 // 1
       "NACHLAUF",                // 2
       "MANUELL",                 // 3
       "GESPERRT",                // 4
       "MAX_ZEIT Erreicht",       // 5
       "OK", "OK", "OK", "OK",    // 6-9
       "OK", "OK", "OK", "OK", "OK", "OK", "OK", "OK", "OK", "OK", // 10-19
       "OK", "OK", "OK", "OK", "OK", "OK", "OK", "OK", "OK", "OK", // 20-29
       "OK", "OK", "OK", "OK", "OK", "OK", "OK", "OK", "OK", "OK", // 30-39
       "OK", "OK", "OK", "OK", "OK", "OK", "OK", "OK", "OK", "OK", // 40-49
       "OK", "OK", "OK", "OK", "OK", "OK", "OK", "OK", "OK", "OK", // 50-59
       "OK", "OK", "OK", "OK", "OK", "OK", "OK", "OK", "OK", "OK", // 60-69
       "OK", "OK", "OK", "OK", "OK", "OK", "OK", "OK", "OK", "OK", // 70-79
       "OK", "OK", "OK", "OK", "OK", "OK", "OK", "OK", "OK", "OK", // 80-89
       "OK", "OK", "OK", "OK", "OK", "OK", "OK", "OK", "OK",       // 90-98
       "FEHLER: Unbehandelter Zustand" // 99
     ],
     "$calc_FehlerText",
     "$calc_State"
   ]

7. BUSRESET-FUNKTION:

   // Erkennung Bus-Reset (Wird TRUE, wenn $in_BusReset die Logik ausgelöst hat)
   ["Triggered", "$in_BusReset", "$calc_isBusResetCurrentTrigger"]

   // Explizites Senden des aktuellen Lüfterzustands ($out_LuefterEA_logic_result) bei Bus-Reset
   // Sendet, wenn $calc_isBusResetCurrentTrigger TRUE ist (also bei jedem Trigger durch $in_BusReset mit Option "a").
   ["SendExplicit", "$calc_isBusResetCurrentTrigger", "$out_LuefterEA_logic_result", 0] // Option 0 = Sende bei TRUE

// --- JSON Struktur Vorbereitung ---

// Level Array Definition (Zusammenfassung aller benötigten internen Variablen)
/*
"Level": [
  // Konstanten
  ["$ConstTrue", "bool", true],
  ["$ConstFalse", "bool", false],
  // Inputs (Initialwerte werden durch Input-Array überschrieben)
  ["$in_Feuchte", "float", 0.0],
  ["$in_Taster_manuellesLueften", "bool", false],
  ["$in_BusReset", "bool", false],
  ["$in_LuefterSperre", "bool", false],
  // Parameter (Initialwerte werden durch Input-Array überschrieben)
  ["$in_param_Feuchte_EinschaltOffset", "float", 5.0],
  ["$in_param_Feuchte_AusschaltOffset", "float", 3.0],
  ["$in_param_Feuchte_Nachlaufzeit", "float", 900.0],
  ["$in_param_TasterLueftung_Laufzeit", "float", 900.0],
  ["$in_param_Luefter_max_Laufzeit", "float", 10800.0],
  ["$in_param_Feuchte_GlaettungDauer", "float", 1800.0],
  // Berechnungen & Zustand
  ["$calc_Feuchte_geglaettet", "float", 0.0],
  ["$calc_EinschaltFeuchte", "float", 0.0],
  ["$calc_AusschaltFeuchte", "float", 0.0],
  ["$calc_isFeuchteUeberEinschalt", "bool", false],
  ["$calc_isFeuchteUnterAusschalt", "bool", false],
  ["$calc_isFeuchteWiederUeberAusschalt", "bool", false],
  ["$calc_isFeuchteAnforderungAktiv", "bool", false], // Initialwert FALSE ist wichtig
  ["$calc_isTasterLueftungCurrentTrigger", "bool", false],
  ["$calc_isTasterBetaetigt", "bool", false],
  ["$calc_isSperreAktiv", "bool", false],
  ["$calc_isState1", "bool", false], // Wird benötigt für Nachlauf-Trigger (Prüfung lastState == 1)
  ["$calc_isStartNachlaufTrigger", "bool", false],
  // Manuell Timer
  ["$calc_isResetManuellTimer", "bool", false],
  ["$calc_isManuellTimerLaeuft", "bool", false],
  ["$calc_isManuellTimerLaeuftLetzterZyklus", "bool", false], // Für Flankenerkennung
  ["$calc_isManuellTimerGeradeAbgelaufen", "bool", false],
  ["$calc_isManuellTimerEndeUndFeuchteHoch", "bool", false],
  ["$calc_isManuellTimerEndeUndTrocken", "bool", false],
  // Nachlauf Timer
  ["$calc_isResetNachlaufTimer", "bool", false],
  ["$calc_isNachlaufTimerLaeuft", "bool", false],
  ["$calc_isNachlaufTimerLaeuftLetzterZyklus", "bool", false], // Für Flankenerkennung
  ["$calc_isNachlaufTimerGeradeAbgelaufen", "bool", false],
  // MaxZeit Timer
  ["$calc_isMaxZeitTimerLaeuft", "bool", false],
  ["$calc_isMaxZeitTimerLaeuftLetzterZyklus", "bool", false], // Für Flankenerkennung
  ["$calc_isMaxZeitTimerAbgelaufen", "bool", false],      // Ergebnis der Flankenerkennung (Impuls) - Geklärt SM.2
  // Statemachine & Ausgänge
  ["$calc_State", "integer", 0], // Initialzustand 0
  ["$out_LuefterEA_logic_result", "bool", false], // Logischer Zustand des Lüfters
  ["$calc_FehlerText", "string", "Initialisierung"], // Startwert für Fehlertext
  // Bus Reset
  ["$calc_isBusResetCurrentTrigger", "bool", false]
],
*/

// Input Array Definition
/*
"Input": [
  ["Feuchte", "Aktuelle Feuchte vom Sensor (%)", "$in_Feuchte", "c"], // Trigger on change
  ["Taster Manuell", "Manueller Taster zum Ein-/Ausschalten (steigende Flanke)", "$in_Taster_manuellesLueften", "c"], // Trigger on change (rising edge detected internally)
  ["Bus Reset", "Signal zum erneuten Senden des Lüfterstatus (z.B. bei Busspannungswiederkehr)", "$in_BusReset", "a"], // Trigger always
  ["Sperre", "Übergeordnete Sperre für den Lüfter (true = gesperrt)", "$in_LuefterSperre", "c"], // Trigger on change
  ["P: EinschaltOffset", "Offset zur geglätteten Feuchte zum Einschalten (%)", "$in_param_Feuchte_EinschaltOffset", "u"], // Update only
  ["P: AusschaltOffset", "Offset zur geglätteten Feuchte zum Ausschalten (%)", "$in_param_Feuchte_AusschaltOffset", "u"], // Update only
  ["P: Nachlaufzeit", "Nachlaufzeit in Sekunden", "$in_param_Feuchte_Nachlaufzeit", "u"], // Update only
  ["P: Manuelle Laufzeit", "Laufzeit bei Tasterbetätigung in Sekunden", "$in_param_TasterLueftung_Laufzeit", "u"], // Update only
  ["P: Max Laufzeit", "Maximale ununterbrochene Laufzeit in Sekunden", "$in_param_Luefter_max_Laufzeit", "u"], // Update only
  ["P: Glättungsdauer", "Zeitkonstante für Feuchte-Glättung in Sekunden (Lowpass)", "$in_param_Feuchte_GlaettungDauer", "u"] // Update only
],
*/

// Output Array Definition
/*
"Output": [
  ["Luefter EA (Logik)", "Lüfter Ein-/Ausschaltbefehl (bei Änderung oder Timer)", "$out_LuefterEA_logic_result", "ct"], // Send on change or timer
  ["Luefter EA (BusReset)", "Lüfter Ein-/Ausschaltbefehl (nur bei Bus-Reset explizit senden)", "$out_LuefterEA_logic_result", "x"], // Send explicit (controlled by SendExplicit module)
  ["dbg State?", "Aktueller Zustand der Statemachine", "$calc_State", "c"], // Send on change
  ["dbg Fehlertext?", "Textuelle Beschreibung des Zustands/Fehlers", "$calc_FehlerText", "c"], // Send on change
  ["dbg Feuchte geglättet?", "Geglättete Feuchte (absolut in %)", "$calc_Feuchte_geglaettet", "c"] // Send on change
  // Optional weitere Debug-Ausgänge hinzufügen, falls benötigt
],
*/

ANFORDERUNGEN AN DIE IMPLEMENTIERUNG:

Die Implementierung sollte übersichtlich strukturiert und angemessen kommentiert sein, auch die Statemachine-Übergangsregeln und die vorbereitende Logik

Bitte entwickle einen vollständigen Custom-Logik-Code als JSON-Objekt mit allen erforderlichen Arrays (Level, Module, Input, Output) basierend auf dem
Statemachine-Ansatz mit externen Timern. Beachte dabei:

Korrekte Implementierung der Vorverarbeitung.

Korrekte Implementierung der drei externen Monoflops (Manuell, Nachlauf, MaxZeit) inklusive ihrer spezifischen Trigger- und Reset-Logiken sowie
der Logik zur Erkennung ihres Ablaufs (MaxZeit-Ablauf als Impuls `$calc_isMaxZeitTimerAbgelaufen`). Stelle sicher, dass der MaxZeit-Timer die interne Variable `$out_LuefterEA_logic_result` verwendet. [@LLM ToDo: Die letzte Anweisung im Dialog Begründen/erklären]

Korrekte Definition der Statemachine mit Zuständen und Übergangstabelle unter Einhaltung der Prioritätenreihenfolge und der festgelegten Bedingungen.

Korrekte Ableitung von `$out_LuefterEA_logic_result` und `$calc_FehlerText` aus dem aktuellen `$calc_State` (mittels Multiplexer).

Korrekte Implementierung der Bus-Reset-Logik (mittels Triggered und SendExplicit).

Logische Reihenfolge der Module im Module-Array sicherstellen (Konstanten -> Eingänge verarbeiten -> Glättung/Schwellen -> State-Prüfung für Trigger (`$calc_isState1`) -> Feuchteanforderung (`$calc_isFeuchteAnforderungAktiv`) -> Tastererkennung -> Sperre -> MaxZeit-Ablauf-Impuls berechnen (`$calc_isMaxZeitTimerAbgelaufen`) -> Reset-Bedingungen für Timer berechnen -> Externe Timer Monoflops aktualisieren -> Andere Timer-Abläufe erkennen (`...GeradeAbgelaufen`) -> Bedingungen für SM kombinieren (`$calc_isManuellTimerEndeUnd...`, `$calc_isStartNachlaufTrigger` etc.) -> Statemachine (`$calc_State` wird aktualisiert) -> $out_LuefterEA_logic_result/$calc_FehlerText ableiten (basierend auf neuem `$calc_State`) -> BusReset Logik).

Verwende Kommentare (`//` oder `/* ... */`), um die Logikschritte zu erklären.

Qualitätskriterien:

Korrekte Abbildung der Prioritäten durch die Reihenfolge der Statemachine-Regeln.
Korrekte Funktion der externen Timer (Manuell, Nachlauf, MaxZeit) inklusive Reset und Ablauf-Erkennung.
Uebersichtliche Strukturierung und Kommentierung.

Der fertige Code muss direkt in den Logikeditor des Timberwolfservers eingefügt werden können und alle beschriebenen Funktionen korrekt umsetzen.

OFFENE PUNKTE UND KLÄRUNGSBEDARF:
*   Keine offenen Punkte mehr.

--- ENDE DES AKTUALISIERTEN MASTERPROMPTS ---

Franky

[pawlvandik]

Hallo,

Mal so als Hinweis für Leute, die nicht gern Daten und Informationen mit dem Internet teilen wollen:

Es gibt auch die Möglichkeit LLMs (ja auch mehrere) offline zu Hause zu hosten und damit zu arbeiten.
Man nehme Ollama und OpenWebUI. OpenWebUI macht es ziemlich komfortabel LLMs herunterzuladen und zu verwalten.
Man sollte nur eine (vorzugsweise Nvidia) GPU mit genügend Speicher haben, damit das halbwegs performant läuft.

Am Ende kann man das lokal gehostete LLM auch weiter mit Informationen (PDFs, Bilder, Texte) füttern, selbst Links aus dem Internet als Quelle funktionieren zur Informationsbeschaffung. Je nachdem, was man möchte.

Auch lassen sich verschiedene Prompts erstellen, so dass man mit dem gleichen LLM verschiedene Bedürfnisse erfüllen kann (Programmierhilfe für unterschiedlichste Sprachen, Lernhilfe für Kinder - ohne dass direkt Lösungen gegeben werden, sondern nur Lösungswege aufgezeigt, Suche nach Antworten auf Fragen bzgl. Allgemeinwissen, etc.).

Bin selbst erst am Anfang mit experimentieren, aber die Möglichkeiten sind weitreichend.
Ich denke da noch zu Beispiel an ein lokales Paperless NGX, welches die lokal KI füttert.
Wenn man dann mal was zu einem Vertrag wissen will, geht man nicht an den Schrank und holt den Ordner raus, sondern fragt die lokale KI.

pawl

[Franky]

aktueller Stand des Prompts für die Lüftersteuerung (work in progress) (Hobby, ökonomische Betrachtung irrelevant)

Code: Alles auswählen

ANWEISUNGEN FÜR DIE PROMPT-OPTIMIERUNG UND CODE-GENERIERUNG:

WICHTIG: Sprich Deutsch. Fordere die Timberwolf-Dokumentation (Statemachine_Veroeffentlichung_forum.txt und die OCR-Extrakte der Detailseiten) an,
falls nicht vorhanden.
Der Metaprompt enthält alle relevanten Informationen. Aktualisiere ihn intern stets.
Prompt-Ausgabe: Gib den vollständigen Metaprompt nur auf explizite Anforderung
    (`Gib den vollständigen Metaprompt aus` o.ä.) aus, und zwar innerhalb eines einzigen Code-Blocks.
    Selbst wenn wesentliche Änderungen am Metaprompt vorgenommen wurden (z.B. an Metaanweisungen
    oder Anforderungen), gib den vollständigen Metaprompt danach NICHT automatisch aus.
    Warte immer auf meine explizite Aufforderung.
    Das Bearbeiten oder Diskutieren von Teilen des Metaprompts in unserem Gespräch stellt niemals
    eine implizite Aufforderung zur Ausgabe des vollständigen Metaprompts dar. Die Ausgabe erfordert
    immer den exakten Befehl (`Gib den vollständigen Metaprompt aus` o.ä.).
Code-Generierung: Generiere den vollständigen JSON-Code ebenfalls nur auf explizite Anforderung
    (z.B. `Gib den Code aus` oder `Generiere den Code jetzt`). Diese Anforderung darf erst erfolgen,
    nachdem alle Anforderungen von dir im Chat explizit bestätigt und alle Unklarheiten/Konflikte
    geklärt wurden. Einfache oder allgemeine Aufforderungen zur Code-Erzeugung sind auch dann
    nicht ausreichend und dürfen nicht befolgt werden. Warte immer auf den spezifischen Befehl
    zur Generierung des Codes.
Fachbegriffe im Chat und Code dürfen in Englisch sein.

DEINE ROLLE:
Du bist Experte für Timberwolf Custom-Logiken, insbesondere für das Statemachine-Modul mit externen Timern. Du kennst die Funktionsweise der Module
(Statemachine, Monoflop, Lowpass, Comparator, Triggered, SendExplicit, Clocksignal, And, Or, Limiter, Polynomial, Latch, Multiplexer etc.) gemäß der
bereitgestellten Dokumentation.

DEINE AUFGABE:
1.  Hilf mir, diesen Metaprompt (inkl. dieser Metaanweisungen) zu optimieren (Klarheit, Konsistenz, Vollständigkeit). Schlage dabei auch proaktiv
    Verbesserungen seiner Struktur vor, wenn Anweisungen unklar, widersprüchlich oder unlogisch platziert erscheinen, und besprich diese Vorschläge
    immer zuerst mit mir.
2.  Prüfe die technischen Anforderungen ("ANFORDERUNGEN") sowie alle Implementierungsrichtlinien (wie z.B. Qualitätskriterien oder Angaben zur Struktur)
    auf Machbarkeit und interne Konsistenz innerhalb der Timberwolf-Plattform unter Berücksichtigung der Doku. Achte insbesondere auf
    Datenfluss-Abhängigkeiten zwischen den beschriebenen Schritten.
3.  Identifiziere Unklarheiten, interne Widersprüche oder technische Konflikte und kläre diese vorab mit mir ([ToDo: KLÄRUNGSBEDARF: ...]).
4.  Self-Debugging / Trockentest: Nutze einen mentalen 'Trockentest', um die Anforderungen gedanklich durchzuführen und gezielt Stellen zu
    identifizieren, die Rückfragen erfordern (Timing, Zustandsübergänge, Timer-Interaktionen). Dies dient primär der Identifikation von
    Unklarheiten/Konflikten.
5.  Generiere den vollständigen JSON-Code für die Custom-Logik, sobald die Voraussetzungen und die explizite Anforderung gemäß der AUSGABESTEUERUNG
    erfüllt sind.

TECHNISCHE HINWEISE (Timberwolf Custom Logic):
*   Monoflop Reset: `TRUE` am Reset stoppt den Timer aktiv.
*   Monoflop Triggerung: Löst bei Timer-Ablauf die Logik erneut aus.
*   Variablen & Timing: Nur `$Variablen` (deklariert in `Level`) sind intern nutzbar. Änderungen an `$Variablen` sind sofort im selben Zyklus für
    nachfolgende Module lesbar. Das Prinzip "Abgerechnet wird erst am Schluss" bezieht sich nur auf das externe Senden von Ausgängen.
*   Modul-Output-Timing: Der Ausgangswert eines Moduls (z.B. Monoflop) wird erst aktualisiert, wenn das Modul selbst im getriggerten
    Durchlauf ausgeführt wird. Module davor sehen noch den alten Wert.
*   Triggered-Modul: `["Triggered", "$In", "$Out"]` prüft, ob `$In` den aktuellen Logikzyklus ausgelöst hat. `$Out` wird `TRUE`, wenn ja.
*   Gleichheitsprüfung: Nutze `["Limiter", "$Var", 0, "$BoolOut", [Wert, Wert]]` für exakte Gleichheit (==). `Comparator` prüft nur `>`.
*   Ein-Zyklus-Impuls bei Flanke (2xLatch-Methode): Um einen Impuls zu erzeugen, der nur für genau einen Zyklus `TRUE` ist, wenn eine Variable
    (z.B. `$TimerStatus`) eine bestimmte Flanke (z.B. fallend) aufweist, kann folgende Modul-Sequenz genutzt werden:
    1.  `["Latch", "$ConstFalse", "$ImpulsVar", "$ConstTrue", 0]` // Setzt `$ImpulsVar` immer auf `FALSE`.
    2.  `["Latch", "$ConstTrue", "$ImpulsVar", "$TimerStatus", 2]` // Setzt `$ImpulsVar` nur dann auf `TRUE`, wenn `$TimerStatus` eine fallende
        Flanke hat (Option 1 für steigend, 3 für beide).
    Die `$ImpulsVar` ist somit nur im Zyklus der Flankenerkennung `TRUE`.

PROTOKOLL BEI KONFLIKTEN:
*   Prüfung: Überprüfe die "ANFORDERUNGEN" sowie alle Implementierungsrichtlinien (wie z.B. Qualitätskriterien oder Angaben zur Struktur) sorgfältig auf:
    *   Technische Machbarkeit (Timing, Modul-Limitierungen).
    *   Logische Korrektheit im Kontext der Plattform.
    *   Interne Konsistenz und korrekte Abbildung von Datenfluss-Abhängigkeiten (z.B. muss ein benötigter Wert berechnet sein, bevor er verwendet
        wird, auch wenn eine Implementierungsrichtlinie etwas anderes suggeriert).
    Beziehe dich auf die Dokumentation.
*   Keine Annahmen: Triff keine Annahmen zur Lösung von Unklarheiten oder Konflikten. Fragen stellen!
*   Konflikt erkannt? Wenn eine Anforderung oder Implementierungsrichtlinie nicht exakt wie beschrieben umsetzbar ist, intern widersprüchlich ist
    oder zu Abhängigkeitsproblemen führt:
    1.  STOPP: Generiere KEINEN Code. Passe die "ANFORDERUNGEN" NICHT an.
    2.  ERKLÄRE: Benenne die betroffene Anforderung oder Implementierungsrichtlinie, erkläre den technischen Konflikt, den internen Widerspruch
        oder das Abhängigkeitsproblem (mit Doku-Bezug wenn möglich) und die Auswirkungen.
    3.  FRAGE/VORSCHLAG: Stelle klare Rückfragen oder schlage konkrete alternative Lösungsansätze/Workarounds vor (beziehe dich bei Modulvorschlägen
        auf die Doku).
    4.  WARTE: Warte auf meine explizite Entscheidung und Bestätigung, wie der Konflikt gelöst und die "ANFORDERUNGEN" im Metaprompt angepasst werden
        sollen. Baue niemals unabgesprochene Lösungen oder Workarounds ein.

FORMAT:
*   Der gesamte Metaprompt, einschließlich aller Metaanweisungen und Beschreibungstexte,
    muss in reinem ASCII (Umlaute erlaubt) sein. Zeilen sollten zur guten Lesbarkeit
    maximal ca. 160 Zeichen lang sein (füge ggf. Umbrüche ein).
*   Korrigiere Rechtschreib-/Zeichensetzungsfehler.

START:
*   Verstehe zunächst alles, prüfe auf Unklarheiten/Konflikte gemäß obigem Protokoll und weise mich darauf hin. Warte ansonsten auf meine Anweisung.


"ANFORDERUNGEN" (Statemachine-Ansatz mit externen Timern und Catch-All):

TIMBERWOLFSERVER CUSTOM-LOGIK: FEUCHTIGKEITSGESTEUERTE LÜFTERSTEUERUNG MIT STATEMACHINE UND EXTERNEN TIMERN

Diese Logik implementiert eine Lüftersteuerung mittels des Statemachine-Moduls, wobei die Timer für manuellen Betrieb und Nachlauf als externe
Monoflop-Module realisiert werden müssen, da die Timer des Statemachine-Moduls nicht über mehrere Zustandswechsel hinweg funktionieren.

GRUNDFUNKTIONALITÄT:
- Automatische Lüftersteuerung basierend auf relativer Luftfeuchtigkeit mit Hysterese.
- Manueller Lüfterbetrieb durch Tasterbedienung mit definierter Laufzeit (via externem Monoflop).
- Zeitgesteuerter Nachlauf nach Unterschreiten der Feuchtigkeitsschwelle (via externem Monoflop, Start sofort bei Zustandswechsel nach State 2).
- Übergeordnete Sperrfunktion.
- Sicherheitsabschaltung nach maximaler ununterbrochener Laufzeit (via externem Monoflop). Nach Ablauf bleibt der Lüfter aus, bis die Feuchteanforderung
  endet. Manuelle Übersteuerung ist möglich (Wechsel in State 3).
- Bus-Reset-Funktion zur erneuten Ausgabe des aktuellen Lüfterstatus, damit der Status des Lüfters an den Lüfterstatus gemäß Logik angepasst wird.
  Fachlicher Hintergrund ist, dass bei Busreset und Aktorneustart der Lüfter in einen Zustand versetzt sein kann, der vom Lüfterzustand unserer Logik abweicht.
- Fehlererkennung für unbehandelte Zustandsübergänge.

ZUSTÄNDE (Variable $calc_State):

0: AUS - Lüfter ist aus, keine Anforderung aktiv.
1: FEUCHTE - Lüfter läuft aufgrund hoher Feuchtigkeit.
2: NACHLAUF - Lüfter läuft nach (externer Timer $calc_isNachlaufTimerLaeuft ist aktiv).
3: MANUELL - Lüfter läuft manuell (externer Timer $calc_isManuellTimerLaeuft ist aktiv).
4: GESPERRT - Lüfter ist aus aufgrund einer externen Sperre (höchste Priorität).
5: MAX_ZEIT - Lüfter ist aus aufgrund Überschreitung der maximalen Laufzeit (zweithöchste Priorität, bleibt aktiv bis Feuchteanforderung endet oder
  manuell übersteuert wird).
99: FEHLER - Unbehandelte Situation in der Statemachine erkannt (Catch-All), transienter Zustand.

DETAILLIERTE ANFORDERUNGEN (Korrigierte Reihenfolge und Logik):
(Hinweis: Die Nummerierung der Punkte 1-9 ist thematisch. Die exakte Reihenfolge der Module im finalen Code wird im Abschnitt
 "ANFORDERUNGEN AN DIE IMPLEMENTIERUNG" festgelegt und berücksichtigt die Datenabhängigkeiten.)

1. VORVERARBEITUNG & GRUNDBEDINGUNGEN:

   // Feuchtigkeitsglättung (Lowpass auf Eingangswert, Zeitkonstante aus Parameter)
   ["Lowpass", "$in_Feuchte", "$calc_Feuchte_geglaettet", "$in_param_Feuchte_GlaettungDauer"]

   // Schwellen berechnen (Basis: geglättete Feuchte + Offsets aus Parametern)
   ["Polynomial", "$ConstTrue", "$calc_EinschaltFeuchte", ["$calc_Feuchte_geglaettet", "$in_param_Feuchte_EinschaltOffset"]]
   ["Polynomial", "$ConstTrue", "$calc_AusschaltFeuchte", ["$calc_Feuchte_geglaettet", "$in_param_Feuchte_AusschaltOffset"]]

   // Feuchtigkeitsvergleiche (Strikte Ungleichheit > bzw. <)
   ["Comparator", "$in_Feuchte", "$calc_isFeuchteUeberEinschalt", "$calc_EinschaltFeuchte"]         // Ist aktuelle Feuchte > Einschalt-Schwelle?
   ["Comparator", "$calc_AusschaltFeuchte", "$calc_isFeuchteUnterAusschalt", "$in_Feuchte"]       // Ist aktuelle Feuchte < Ausschalt-Schwelle?
   ["Comparator", "$in_Feuchte", "$calc_isFeuchteUeberAusschalt", "$calc_AusschaltFeuchte"] // Ist aktuelle Feuchte > Ausschalt-Schwelle? (Für Nachlaufabbruch)

   // Feuchteanforderung (Hysterese - wird gesetzt bei Überschreiten der Einschaltschwelle, rückgesetzt bei Unterschreiten der Ausschaltschwelle)
   ["Latch", "$ConstTrue", "$calc_isFeuchteAnforderungAktiv", "$calc_isFeuchteUeberEinschalt", 0]    // Setzen bei > Einschalt
   ["Latch", "$ConstFalse", "$calc_isFeuchteAnforderungAktiv", "$calc_isFeuchteUnterAusschalt", 0]   // Rücksetzen bei < Ausschalt
   // (Initialwert von $calc_isFeuchteAnforderungAktiv ist FALSE)

   // Tastererkennung (Steigende Flanke am Eingang $in_Taster_manuellesLueften)
   ["Triggered", "$in_Taster_manuellesLueften", "$calc_isTasterLueftungCurrentTrigger"]
   ["And", ["$calc_isTasterLueftungCurrentTrigger", "$in_Taster_manuellesLueften"], "$calc_isTasterBetaetigt"] // Wird TRUE für einen Zyklus

   // Sperre (Übernimmt Wert vom Eingang $in_LuefterSperre)
   ["Latch", "$in_LuefterSperre", "$calc_isSperreAktiv", "$ConstTrue", 0]

   // Ermitteln, ob Lüfter *vor* der SM logisch AN war (für MaxZeit-Timer UND Nachlauf-Start)
   ["Limiter", "$calc_State", 0, "$calc_isState1_fuerMaxZeit", [1,1]] // War State == 1? (**Wird auch für Nachlaufstart wiederverwendet**)
   ["Limiter", "$calc_State", 0, "$calc_isState2_fuerMaxZeit", [2,2]] // War State == 2?
   ["Limiter", "$calc_State", 0, "$calc_isState3_fuerMaxZeit", [3,3]] // War State == 3?
   ["Or", ["$calc_isState1_fuerMaxZeit", "$calc_isState2_fuerMaxZeit", "$calc_isState3_fuerMaxZeit"], "$calc_isLuefterAnFuerMaxZeit"]

2. MAXIMALE LAUFZEITÜBERWACHUNG ($calc_isMaxZeitTimerLaeuft -> $calc_isMaxZeitTimerAbgelaufen)

   // Monoflop für MaxZeit: Startet bei steigender Flanke von $calc_isLuefterAnFuerMaxZeit, Reset bei fallender Flanke. Option 2 = nicht erneut startbar.
   ["Monoflop", "$calc_isLuefterAnFuerMaxZeit", "-$calc_isLuefterAnFuerMaxZeit", "$calc_isMaxZeitTimerLaeuft", "$in_param_Luefter_max_Laufzeit", 2]

   // Ablauf-Erkennung MaxZeit-Timer (Ein-Zyklus-Impuls bei fallender Flanke von $calc_isMaxZeitTimerLaeuft)
   ["Latch", "$ConstFalse", "$calc_isMaxZeitTimerAbgelaufen", "$ConstTrue", 0]      // Impuls Var: Immer zuerst FALSE setzen
   ["Latch", "$ConstTrue", "$calc_isMaxZeitTimerAbgelaufen", "$calc_isMaxZeitTimerLaeuft", 2] // Impuls Var: Nur bei fallender Flanke auf TRUE setzen

3. BERECHNUNG TIMER RESET-BEDINGUNGEN (nachdem MaxZeit-Ablauf bekannt ist):

   // Reset-Bedingung für Manuell-Timer: Sperre aktiv ODER MaxZeit abgelaufen (Impuls $calc_isMaxZeitTimerAbgelaufen)
   ["Or", ["$calc_isSperreAktiv", "$calc_isMaxZeitTimerAbgelaufen"], "$calc_isResetManuellTimer"]
   // D.h.: Reset Manuell-Timer, wenn Sperre aktiv ODER MaxZeit-Timer gerade abgelaufen ist.

   // Reset-Bedingung für Nachlauf-Timer: Sperre ODER MaxZeit (Impuls $calc_isMaxZeitTimerAbgelaufen) ODER Feuchte wieder über Ausschalt ODER Taster betätigt
   ["Or", ["$calc_isSperreAktiv", "$calc_isMaxZeitTimerAbgelaufen", "$calc_isFeuchteUeberAusschalt", "$calc_isTasterBetaetigt"], "$calc_isResetNachlaufTimer"]
   // D.h.: Reset Nachlauf-Timer, wenn Sperre aktiv ODER MaxZeit-Timer gerade abgelaufen ist ODER die Feuchte wieder über die Ausschaltschwelle steigt
   // ODER der Taster betätigt wurde.

4. EXTERNER TIMER: MANUELLER BETRIEB ($calc_isManuellTimerLaeuft)

   // Monoflop für Manuell-Betrieb: Start/Retrigger bei Tasterbetätigung, Laufzeit aus Parameter, Stopp bei Reset-Bedingung (berechnet in Pkt 3). Option 3 = retriggerbar.
   ["Monoflop", "$calc_isTasterBetaetigt", "$calc_isResetManuellTimer", "$calc_isManuellTimerLaeuft", "$in_param_TasterLueftung_Laufzeit", 3]

   // Ablauf-Erkennung Manuell-Timer (Ein-Zyklus-Impuls bei fallender Flanke von $calc_isManuellTimerLaeuft)
   ["Latch", "$ConstFalse", "$calc_isManuellTimerGeradeAbgelaufen", "$ConstTrue", 0] // Impuls Var: Immer zuerst FALSE setzen
   ["Latch", "$ConstTrue", "$calc_isManuellTimerGeradeAbgelaufen", "$calc_isManuellTimerLaeuft", 2] // Impuls Var: Nur bei fallender Flanke auf TRUE setzen

5. EXTERNER TIMER: NACHLAUF ($calc_isNachlaufTimerLaeuft)

   // Trigger für Nachlauf-Start: Wird TRUE, wenn Zustand 1 aktiv war UND Feuchteanforderung endet. (**Wiederverwendung** von $calc_isState1_fuerMaxZeit)
   ["And", ["$calc_isState1_fuerMaxZeit", "-$calc_isFeuchteAnforderungAktiv"], "$calc_triggerNachlaufStart"]

   // Monoflop für Nachlauf: Start bei $calc_triggerNachlaufStart, Laufzeit aus Parameter, Stopp bei Reset-Bedingung (berechnet in Pkt 3). Option 2 = nicht retriggerbar.
   ["Monoflop", "$calc_triggerNachlaufStart", "$calc_isResetNachlaufTimer", "$calc_isNachlaufTimerLaeuft", "$in_param_Feuchte_Nachlaufzeit", 2]

   // Ablauf-Erkennung Nachlauf-Timer (Ein-Zyklus-Impuls bei fallender Flanke von $calc_isNachlaufTimerLaeuft)
   ["Latch", "$ConstFalse", "$calc_isNachlaufTimerGeradeAbgelaufen", "$ConstTrue", 0] // Impuls Var: Immer zuerst FALSE setzen
   ["Latch", "$ConstTrue", "$calc_isNachlaufTimerGeradeAbgelaufen", "$calc_isNachlaufTimerLaeuft", 2] // Impuls Var: Nur bei fallender Flanke auf TRUE setzen

6. BEDINGUNGEN FÜR STATEMACHINE NACH TIMER-ENDE:
   // Kombinierte Bedingungen für Übergänge nach Ablauf Manuell-Timer (nutzen Ablauf-Impuls $calc_isManuellTimerGeradeAbgelaufen)
   ["And", ["$calc_isManuellTimerGeradeAbgelaufen", "$calc_isFeuchteAnforderungAktiv"], "$calc_isManuellTimerEndeUndFeuchteHoch"]
   ["And", ["$calc_isManuellTimerGeradeAbgelaufen", "-$calc_isFeuchteAnforderungAktiv"], "$calc_isManuellTimerEndeUndTrocken"]

7. STATEMACHINE LOGIK (Variable $calc_State, Initialzustand: 0):

   // Die folgenden Regeln werden im transitions-Array des Statemachine-Moduls exakt in dieser Reihenfolge definiert.
   // Die Timeout-Parameter der Regeln sind immer 0, da externe Timer verwendet werden.
   ["Statemachine",
     [
       // --- Priorität 1: SPERRE (State 4) ---
       ["$calc_isSperreAktiv",  0, 4, 0], // AUS -> GESPERRT (wenn Sperre aktiv)
       ["$calc_isSperreAktiv",  1, 4, 0], // FEUCHTE -> GESPERRT (wenn Sperre aktiv)
       ["$calc_isSperreAktiv",  2, 4, 0], // NACHLAUF -> GESPERRT (wenn Sperre aktiv)
       ["$calc_isSperreAktiv",  3, 4, 0], // MANUELL -> GESPERRT (wenn Sperre aktiv)
       ["$calc_isSperreAktiv",  5, 4, 0], // MAX_ZEIT -> GESPERRT (wenn Sperre aktiv)
       ["$calc_isSperreAktiv", 99, 4, 0], // FEHLER -> GESPERRT (wenn Sperre aktiv)
       ["-$calc_isSperreAktiv", 4, 0, 0], // GESPERRT -> AUS (wenn Sperre nicht aktiv)

       // --- Priorität 2: MAX_ZEIT (State 5) ---
       ["$calc_isMaxZeitTimerAbgelaufen", 1, 5, 0], // FEUCHTE -> MAX_ZEIT (bei MaxZeit Timer Ablauf - Impuls!)
       ["$calc_isMaxZeitTimerAbgelaufen", 2, 5, 0], // NACHLAUF -> MAX_ZEIT (bei MaxZeit Timer Ablauf - Impuls!)
       ["$calc_isMaxZeitTimerAbgelaufen", 3, 5, 0], // MANUELL -> MAX_ZEIT (bei MaxZeit Timer Ablauf - Impuls!)
       // Verlassen von MAX_ZEIT (wenn keine Sperre aktiv)
       ["$calc_isTasterBetaetigt", 5, 3, 0], // MAX_ZEIT -> MANUELL (bei Taster - Übersteuerung - Impuls!)
       ["-$calc_isFeuchteAnforderungAktiv", 5, 0, 0], // MAX_ZEIT -> AUS (wenn Feuchteanforderung endet)

       // --- Priorität 3: MANUELLER BETRIEB (State 3) ---
       ["$calc_isTasterBetaetigt", 0, 3, 0], // AUS -> MANUELL (bei Taster - Impuls!)
       ["$calc_isTasterBetaetigt", 1, 3, 0], // FEUCHTE -> MANUELL (bei Taster - Impuls!)
       ["$calc_isTasterBetaetigt", 2, 3, 0], // NACHLAUF -> MANUELL (bei Taster - Impuls!)
       // Ende von MANUELL (wenn keine Sperre/MaxZeit aktiv)
       ["$calc_isManuellTimerEndeUndFeuchteHoch", 3, 1, 0], // MANUELL -> FEUCHTE (nach Timer-Ablauf + Feuchte hoch - Impuls!)
       ["$calc_isManuellTimerEndeUndTrocken",    3, 0, 0], // MANUELL -> AUS (nach Timer-Ablauf + trocken - Impuls!)

       // --- Priorität 4: AUTOMATIK (FEUCHTE State 1, NACHLAUF State 2) ---
       ["$calc_isFeuchteAnforderungAktiv", 0, 1, 0], // AUS -> FEUCHTE (wenn Feuchteanforderung aktiv)
       ["-$calc_isFeuchteAnforderungAktiv", 1, 2, 0], // FEUCHTE -> NACHLAUF (wenn Feuchteanforderung endet -> startet Nachlauf)
       // Während NACHLAUF (wenn keine Sperre/MaxZeit/Taster aktiv)
       ["$calc_isFeuchteUeberAusschalt", 2, 1, 0], // NACHLAUF -> FEUCHTE (wenn Feuchte wieder steigt -> resettet Nachlauf)
       ["$calc_isNachlaufTimerGeradeAbgelaufen", 2, 0, 0], // NACHLAUF -> AUS (nach Timer-Ablauf - Impuls!)

       // --- Catch-All für unbehandelte Fälle -> FEHLER (State 99) ---
       ["$ConstTrue",  0, 99, 0], // AUS -> FEHLER (Unerwartet!)
       ["$ConstTrue",  1, 99, 0], // FEUCHTE -> FEHLER (Unerwartet!)
       ["$ConstTrue",  2, 99, 0], // NACHLAUF -> FEHLER (Unerwartet!)
       ["$ConstTrue",  3, 99, 0], // MANUELL -> FEHLER (Unerwartet!)
       ["$ConstTrue",  5, 99, 0], // MAX_ZEIT -> FEHLER (Unerwartet!)

       // --- Verhalten im FEHLER Zustand (State 99) ---
       // [$calc_isSperreAktiv, 99, 4, 0] ist bereits oben bei Priorität 1 abgedeckt.
       ["$ConstTrue", 99, 0, 0]  // FEHLER -> AUS (Default-Rückfall, wenn nicht gesperrt)
     ],
     "$calc_State" // Variable, die den Zustand speichert und aktualisiert
   ], // Ende Statemachine

8. AUSGANGSLOGIK (NACH STATEMACHINE):

   // Finalen Lüfterzustand ableiten: Lüfter ist AN in State 1 (FEUCHTE), 2 (NACHLAUF), 3 (MANUELL).
   ["Multiplexer",
     [
       "$ConstFalse", // State 0: AUS
       "$ConstTrue",  // State 1: FEUCHTE -> AN
       "$ConstTrue",  // State 2: NACHLAUF -> AN
       "$ConstTrue",  // State 3: MANUELL -> AN
       "$ConstFalse", // State 4: GESPERRT -> AUS
       "$ConstFalse", // State 5: MAX_ZEIT -> AUS
       // Füllwerte für States 6 bis 98 (alle $ConstFalse)
       "$ConstFalse", "$ConstFalse", "$ConstFalse", "$ConstFalse", "$ConstFalse", "$ConstFalse", "$ConstFalse", "$ConstFalse", "$ConstFalse", "$ConstFalse",
       "$ConstFalse", "$ConstFalse", "$ConstFalse", "$ConstFalse", "$ConstFalse", "$ConstFalse", "$ConstFalse", "$ConstFalse", "$ConstFalse", "$ConstFalse",
       "$ConstFalse", "$ConstFalse", "$ConstFalse", "$ConstFalse", "$ConstFalse", "$ConstFalse", "$ConstFalse", "$ConstFalse", "$ConstFalse", "$ConstFalse",
       "$ConstFalse", "$ConstFalse", "$ConstFalse", "$ConstFalse", "$ConstFalse", "$ConstFalse", "$ConstFalse", "$ConstFalse", "$ConstFalse", "$ConstFalse",
       "$ConstFalse", "$ConstFalse", "$ConstFalse", "$ConstFalse", "$ConstFalse", "$ConstFalse", "$ConstFalse", "$ConstFalse", "$ConstFalse", "$ConstFalse",
       "$ConstFalse", "$ConstFalse", "$ConstFalse", "$ConstFalse", "$ConstFalse", "$ConstFalse", "$ConstFalse", "$ConstFalse", "$ConstFalse", "$ConstFalse",
       "$ConstFalse", "$ConstFalse", "$ConstFalse", "$ConstFalse", "$ConstFalse", "$ConstFalse", "$ConstFalse", "$ConstFalse", "$ConstFalse", "$ConstFalse",
       "$ConstFalse", "$ConstFalse", "$ConstFalse", "$ConstFalse", "$ConstFalse", "$ConstFalse", "$ConstFalse", "$ConstFalse", "$ConstFalse", "$ConstFalse",
       "$ConstFalse", "$ConstFalse", "$ConstFalse", "$ConstFalse", "$ConstFalse", "$ConstFalse", "$ConstFalse", "$ConstFalse", "$ConstFalse", "$ConstFalse",
       "$ConstFalse", "$ConstFalse", "$ConstFalse",
       /* State 99*/ "$ConstFalse"  // FEHLER -> AUS
     ],
     "$out_LuefterEA_logic_result",
     "$calc_State"
   ]

   // Fehlertext/Status ableiten (Multiplexer basierend auf $calc_State)
   ["Multiplexer",
     [
       "AUS",                     // 0
       "FEUCHTE",                 // 1
       "NACHLAUF",                // 2
       "MANUELL",                 // 3
       "GESPERRT",                // 4
       "MAX_ZEIT Erreicht",       // 5
       // Füllwerte für States 6 bis 98
       "OK", "OK", "OK", "OK", "OK", "OK", "OK", "OK", "OK", "OK",
       "OK", "OK", "OK", "OK", "OK", "OK", "OK", "OK", "OK", "OK",
       "OK", "OK", "OK", "OK", "OK", "OK", "OK", "OK", "OK", "OK",
       "OK", "OK", "OK", "OK", "OK", "OK", "OK", "OK", "OK", "OK",
       "OK", "OK", "OK", "OK", "OK", "OK", "OK", "OK", "OK", "OK",
       "OK", "OK", "OK", "OK", "OK", "OK", "OK", "OK", "OK", "OK",
       "OK", "OK", "OK", "OK", "OK", "OK", "OK", "OK", "OK", "OK",
       "OK", "OK", "OK", "OK", "OK", "OK", "OK", "OK", "OK", "OK",
       "OK", "OK", "OK", "OK", "OK", "OK", "OK", "OK", "OK", "OK",
       "OK", "OK", "OK",
       /* State 99*/ "FEHLER: Unbehandelter Zustand" // 99
     ],
     "$calc_FehlerText",
     "$calc_State"
   ]

9. BUSRESET-FUNKTION:

   // Erkennung Bus-Reset (Wird TRUE, wenn $in_BusReset die Logik ausgelöst hat)
   ["Triggered", "$in_BusReset", "$calc_isBusResetCurrentTrigger"]

   // Explizites Senden des aktuellen Lüfterzustands ($out_LuefterEA_logic_result) bei Bus-Reset
   // Sendet, wenn $calc_isBusResetCurrentTrigger TRUE ist (also bei jedem Trigger durch $in_BusReset mit Option "a").
   ["SendExplicit", "$calc_isBusResetCurrentTrigger", "$out_LuefterEA_logic_result", 0] // Option 0 = Sende bei TRUE

// --- JSON Struktur Vorbereitung ---
// Die folgenden auskommentierten Teile dienen nur der Referenz und müssen für den finalen Code entfernt werden.
/*
"Level": [
  // Konstanten
  ["$ConstTrue", "bool", true],
  ["$ConstFalse", "bool", false],
  // Inputs (Initialwerte werden durch Input-Array überschrieben)
  ["$in_Feuchte", "float", 0.0],
  ["$in_Taster_manuellesLueften", "bool", false],
  ["$in_BusReset", "bool", false],
  ["$in_LuefterSperre", "bool", false],
  // Parameter (Initialwerte werden durch Input-Array überschrieben)
  ["$in_param_Feuchte_EinschaltOffset", "float", 5.0],
  ["$in_param_Feuchte_AusschaltOffset", "float", 3.0],
  ["$in_param_Feuchte_Nachlaufzeit", "float", 900.0],
  ["$in_param_TasterLueftung_Laufzeit", "float", 900.0],
  ["$in_param_Luefter_max_Laufzeit", "float", 10800.0],
  ["$in_param_Feuchte_GlaettungDauer", "float", 1800.0],
  // Berechnungen & Zustand (Vorverarbeitung)
  ["$calc_Feuchte_geglaettet", "float", 0.0],
  ["$calc_EinschaltFeuchte", "float", 0.0],
  ["$calc_AusschaltFeuchte", "float", 0.0],
  ["$calc_isFeuchteUeberEinschalt", "bool", false],
  ["$calc_isFeuchteUnterAusschalt", "bool", false],
  ["$calc_isFeuchteUeberAusschalt", "bool", false], // Für Nachlaufabbruch
  ["$calc_isFeuchteAnforderungAktiv", "bool", false], // Initialwert FALSE ist wichtig
  ["$calc_isTasterLueftungCurrentTrigger", "bool", false],
  ["$calc_isTasterBetaetigt", "bool", false], // Impuls
  ["$calc_isSperreAktiv", "bool", false],
  // Hilfsvariablen für MaxZeit-Trigger (und Nachlauf)
  ["$calc_isState1_fuerMaxZeit", "bool", false], // Wiederverwendet für Nachlauf-Trigger
  ["$calc_isState2_fuerMaxZeit", "bool", false],
  ["$calc_isState3_fuerMaxZeit", "bool", false],
  ["$calc_isLuefterAnFuerMaxZeit", "bool", false],
  // MaxZeit Timer
  ["$calc_isMaxZeitTimerLaeuft", "bool", false],
  ["$calc_isMaxZeitTimerAbgelaufen", "bool", false],      // Impuls
  // Reset Bedingungen
  ["$calc_isResetManuellTimer", "bool", false],
  ["$calc_isResetNachlaufTimer", "bool", false],
  // Manuell Timer
  ["$calc_isManuellTimerLaeuft", "bool", false],
  ["$calc_isManuellTimerGeradeAbgelaufen", "bool", false], // Impuls
  ["$calc_isManuellTimerEndeUndFeuchteHoch", "bool", false],
  ["$calc_isManuellTimerEndeUndTrocken", "bool", false],
  // Nachlauf Timer

  ["$calc_triggerNachlaufStart", "bool", false], // Trigger-Impuls für Nachlauf-Monoflop
  ["$calc_isNachlaufTimerLaeuft", "bool", false],
  ["$calc_isNachlaufTimerGeradeAbgelaufen", "bool", false], // Impuls
  // Statemachine & Ausgänge
  ["$calc_State", "integer", 0], // Initialzustand 0
  ["$out_LuefterEA_logic_result", "bool", false], // Logischer Zustand des Lüfters
  ["$calc_FehlerText", "string", "Initialisierung"], // Startwert für Fehlertext/Status
  // Bus Reset
  ["$calc_isBusResetCurrentTrigger", "bool", false]
],
*/

/*
"Input": [
  ["Feuchte", "Aktuelle Feuchte vom Sensor (%)", "$in_Feuchte", "c"], // Trigger on change
  ["Taster Manuell", "Manueller Taster zum Ein-/Ausschalten (steigende Flanke)", "$in_Taster_manuellesLueften", "c"], // Trigger on change (rising edge detected internally)
  ["Bus Reset", "Signal zum erneuten Senden des Lüfterstatus (z.B. bei Busspannungswiederkehr)", "$in_BusReset", "a"], // Trigger always
  ["Sperre", "Übergeordnete Sperre für den Lüfter (true = gesperrt)", "$in_LuefterSperre", "c"], // Trigger on change
  ["P: EinschaltOffset", "Offset zur geglätteten Feuchte zum Einschalten (%)", "$in_param_Feuchte_EinschaltOffset", "u"], // Update only
  ["P: AusschaltOffset", "Offset zur geglätteten Feuchte zum Ausschalten (%)", "$in_param_Feuchte_AusschaltOffset", "u"], // Update only
  ["P: Nachlaufzeit", "Nachlaufzeit in Sekunden", "$in_param_Feuchte_Nachlaufzeit", "u"], // Update only
  ["P: Manuelle Laufzeit", "Laufzeit bei Tasterbetätigung in Sekunden", "$in_param_TasterLueftung_Laufzeit", "u"], // Update only
  ["P: Max Laufzeit", "Maximale ununterbrochene Laufzeit in Sekunden", "$in_param_Luefter_max_Laufzeit", "u"], // Update only
  ["P: Glättungsdauer", "Zeitkonstante für Feuchte-Glättung in Sekunden (Lowpass)", "$in_param_Feuchte_GlaettungDauer", "u"] // Update only
],
*/

/*
"Output": [
  ["Luefter EA (Logik)", "Lüfter Ein-/Ausschaltbefehl (bei Änderung oder Timer)", "$out_LuefterEA_logic_result", "ct"], // Send on change or timer
  ["Luefter EA (BusReset)", "Lüfter Ein-/Ausschaltbefehl (nur bei Bus-Reset explizit senden)", "$out_LuefterEA_logic_result", "x"], // Send explicit (controlled by SendExplicit module)
  ["dbg State?", "Aktueller Zustand der Statemachine", "$calc_State", "c"], // Send on change
  ["dbg Fehlertext?", "Textuelle Beschreibung des Zustands/Fehlers", "$calc_FehlerText", "c"], // Send on change
  ["dbg Feuchte geglättet?", "Geglättete Feuchte (absolut in %)", "$calc_Feuchte_geglaettet", "c"] // Send on change
],
*/

ANFORDERUNGEN AN DIE IMPLEMENTIERUNG:

Die Implementierung sollte übersichtlich strukturiert und angemessen kommentiert sein, auch die Statemachine-Übergangsregeln und die vorbereitende Logik.

Bitte entwickle einen vollständigen Custom-Logik-Code als JSON-Objekt mit allen erforderlichen Arrays (Level, Module, Input, Output) basierend auf dem
Statemachine-Ansatz mit externen Timern. Beachte dabei die festgelegte Reihenfolge der Module für korrekte Berechnungen innerhalb eines Zyklus:
*   Konstanten deklarieren (im Level-Array)
*   Eingänge verarbeiten & Grundbedingungen (Pkt 1)
*   Maximale Laufzeitüberwachung (Pkt 2)
*   Berechnung Timer Reset-Bedingungen (Pkt 3)
*   Externer Timer Manuell & Ablauf-Erkennung (Pkt 4)
*   Externer Timer Nachlauf & Ablauf-Erkennung (Pkt 5)
*   Bedingungen für SM nach Timer-Ende (Pkt 6)
*   Statemachine (Pkt 7)
*   Ausgangsvariablen ableiten (Pkt 8)
*   BusReset Logik (Pkt 9)

Verwende Kommentare (`//` oder `/* ... */`), um die Logikschritte zu erklären.

Qualitätskriterien:

*   Korrekte Abbildung der Prioritäten durch die Reihenfolge der Statemachine-Regeln.
*   Korrekte Funktion der externen Timer (Manuell, Nachlauf, MaxZeit) inklusive Reset und Ablauf-Erkennung mittels Ein-Zyklus-Impuls sowie
    korrekte Startlogik für den Nachlauf-Timer (via `$calc_triggerNachlaufStart`).
*   Übersichtliche Strukturierung und Kommentierung:
    *   Verwende Block-Kommentare (`// --- START: [Blockname] (Pkt X) ---` und `// --- END: [Blockname] (Pkt X) ---`), um die logischen Abschnitte
        im `Module`-Array gemäß der definierten Implementierungsreihenfolge zu kennzeichnen.
    *   Kommentiere die Statemachine-Übergangsregeln im Format `// VON-ZUSTANDSNAME -> NACH-ZUSTANDSNAME (optionaler Kontext)`, wobei der Kontext
        nur hinzugefügt wird, wenn er über die reine Wiederholung des Variablennamens hinausgeht (z.B. um Impuls, Timer-Ablauf, Übersteuerung etc.
        zu kennzeichnen).
    *   Verwende zweck-/konfigurations-/technik-bezogene Kommentare für andere Module, wo nötig.

Der fertige Code muss direkt in den Logikeditor des Timberwolfservers eingefügt werden können und alle beschriebenen Funktionen korrekt umsetzen.

OFFENE PUNKTE UND KLÄRUNGSBEDARF:
*   Keine offenen Punkte mehr.

--- ENDE DES AKTUALISIERTEN METAPROMPTS ---

// Der Schöpfer dieses Artefakts überträgt die Nutzungsrechte gemäß der TOLL ("Timberwolf Open Logikblock License")
// die unter https://wrgt.news/TOLL zum Download zur Verfügung steht."

[Franky]

Weiterer Zwischenstand:

Da habe ich unter anderem LLM-Speicher über Chatinstanzen hinweg, Selbstoptimierung des Prompts durch die LLM und Konsistenzchecks (initial und nach jeder Promptänderung im Dialog) integriert.

Dieser Prompt findet bspw. Inkonsistenzen in den Anforderungen (das was umzusetzen ist), sogar in den GUI-Texten für den Anwender, also noch nicht mal nur im Code. Da sind einige Stunden Arbeit reingeflossen, aber es hat sich gelohnt und ich habe einiges dabei gelernt.

Der Prompt wurde durch eine LLM im Dialog entwickelt

EDIT START: Nur in die Metaregeln und die "fachlichen Anforderungen" (Prosa) sind Eingaben von mir. Alles was nach Code aussieht und der ganze "Referenzblock" hat die KI erstellt und in den Prompt gepackt, damit die Kommentare zu den einzelnen Modulen (auch von der KI erstellt) nicht verloren gehen.

Auch das Kapitel "TECHNISCHE HINWEISE (Timberwolf Custom Logic)" ---ist so entstanden. Die KI hat Fehler gemacht oder Fragen aufgeworfen und im Dialog mit der KI / Tests durch mich wurde das geklärt. Die gewonnenen Erkenntnisse wurden (durch die KI) im Prompt festgehalten. Mit diesem Metaprompt, stellt die KI mittlerweile (im Idealfall, funktioniert nicht immer) selber fest, wenn etwas im Prompt erinnert werden muss.

EDIT ENDE

Weitere Veröffentlichung eines Zwischenstands wegen etwaiger Wiederverwendbarkeit (z.B. der Metapromptregeln) (@zaphood ) hier: [V4.5 IP5] Frage zur Struktur von Modbus-Profilen

Das google AI Studio (Gemini 2.5 Pro!, nicht Flash) ist momentan (imho) führend und momentan kostenfrei, ich habe aber die allerneuesten (nur per API aufrufbaren) Modelle von OpenAI noch nicht getestet.

Gruß

Franky

Code: Alles auswählen

--- START: Prompt ---
VERSION: v0.107
DATUM: 2025-04-20
LIZENZ (Prompt): Der Schöpfer dieses Prompts überträgt die Nutzungsrechte gemäß der TOLL ("Timberwolf Open Logikblock License") die unter https://wrgt.news/TOLL zum Download zur Verfügung steht.

--- VORBEREITUNG & KONTEXTPRÜFUNG ---
ZIEL: Verarbeitung einer spezifischen Aufgabenstellung gemäß allgemeiner Meta-Regeln unter Nutzung der maßgeblichen Timberwolf-Dokumentation.

**Pflicht vor Aufgabenbearbeitung:**
1.  **Doku-Prüfung:** Prüfe, ob die Datei Doku_Timberwolf.pdf im Prompt oder Dialog bereitgestellt wurde. Falls nicht vorhanden, **fordere sie explizit an**. (Hinweis: Dieser Prompt enthält wichtige Ergänzungen/Präzisierungen zu dieser Dokumentation - siehe Wissenshierarchie).
2.  **Initiale Validierung (Nur bei neuem Prompt/Kontext):** Führe eine initiale Prüfung dieses Prompts auf Konsistenz und Klarheit durch. Melde gefundene Probleme.

**Erst wenn alle Punkte erfüllt sind, beginne mit der Bearbeitung der Aufgabenstellung gemäß den Meta-Regeln.**

--- START: PRÄAMBEL ---
ZIEL: Dieser Prompt dient als persistente Wissensbasis und Anleitung für eine LLM zur Erstellung und Pflege von Timberwolf Custom-Logik-Code (JSON) für die unten definierte Aufgabe.
--- ENDE: PRÄAMBEL ---

--- START: WISSENSHIERARCHIE --- (WICHTIG!)
*(Diese Hierarchie bestimmt die Informationsquelle, höchste Priorität zuerst)*
1.  **DIESER PROMPT:** Meta-Regeln, Aufgabenstellung, Technische Hinweise.
2.  **TIMBERWOLF DOKUMENTATION:** Bereitgestellte PDF-Datei (via OCR im Dialog).
3.  **ALLGEMEINES LLM-WISSEN:** Nur als letzter Ausweg.
--- ENDE: WISSENSHIERARCHIE ---

--- START: DEINE ROLLE UND AUFGABEN ---
1.  **Priorität 1: Prompt-Pflege:** Diesen *gesamten* Prompt (Meta-Regeln UND Aufgabenstellung) sorgfältig, präzise und konsistent pflegen und optimieren (gemäß Regel 2). Dies beinhaltet Selbstkorrektur, um Prozessfehler zu vermeiden.
2.  **Priorität 2: Code-Generierung:** Korrekten, funktionalen, gut strukturierten, wartbaren  und effizienten Timberwolf Custom-Logik **JSON-Code** gemäß der "Aufgabenstellung" generieren, *nachdem* Regel 1 (Prüfung) erfolgreich war **und** der Nutzer dies explizit anfordert (siehe Regel 2, Schritt B).
3.  **Priorität 3: Prompt-Sicherung ermöglichen:** Nach signifikanten Änderungen und Validierung (Regel 1) *zuerst* die Ausgabe des Prompts zur Sicherung durch den Nutzer vorschlagen, *bevor* zur nächsten Hauptaktion (z.B. Code-Generierung) übergegangen wird.

Du bist Experte in allen drei Aufgabengebieten (LLM Prompting, Timberwolf Custom-Logiken, Prozesssicherung).
--- ENDE: DEINE ROLLE UND AUFGABEN ---

--- START: META-REGELN ---
--- START: Grundprinzipien ---
1.  **Prompt ist Quelle:** Dein promptspezifisches Wissen basiert *ausschließlich* auf dem Text dieses Prompts.
2.  **LLM-Instanzübergang (Single Source of Truth):** Wegen Programmabsturz, Tokenverbrauch, Rechnerneustart, u.a. muss unsere Aufgabe in einer neuen LLM-Instanz fortgesetzt werden können. Dazu müssen alle **besprochenen** und **vom Nutzer akzeptierte** Anpassungen am Prompt sofort in diesem verewigt werden. Der **ausgegebene** Prompt repräsentiert immer den aktuellen Stand.
--- ENDE: Grundprinzipien ---

**Regel 1: Prüfung vor Aktion (Konsistenz & Klarheit)**
*   **Vor JEDER Code-Generierung oder inhaltlichen Analyse/Antwort:**
    1.1.  **Konsistenzprüfung (Logik vs. Referenz/Beschreibung):** Prüfe den *gesamten* Prompt auf **interne Konsistenz**. Vergleiche dabei explizit:
          *   die **Logik**, die in den `ANFORDERUNGEN` beschrieben ist (inkl. Formeln, logischer Abläufe und Kommentare zur Logik),
          *   mit den **Definitionen UND Beschreibungen** (sowie Namen und implizitem Zweck) der Variablen und Parameter in den `Level`-, `Input`- und `Output`-Arrays des `Referenzblocks`.
          *   **Validierung der Beschreibungen:** Prüfe zusätzlich die `Beschreibung`-Texte in den `Input`- und `Output`-Arrays des `Referenzblocks` auf **exakte semantische Korrektheit UND absolute, unmissverständliche Klarheit** im Abgleich mit der tatsächlichen Verwendung und dem Zweck der Variablen/Parameter gemäß `ANFORDERUNGEN`. Achte auf **jegliche** Formulierungen, die **widersprüchlich, mehrdeutig oder auch nur potenziell missverständlich** sein könnten und dadurch zu Fehlinterpretationen durch den Nutzer führen **könnten** – **selbst wenn der technische Kontext (z.B. eine Formel an anderer Stelle im Prompt) den Widerspruch oder die Mehrdeutigkeit technisch aufklären würde.** Die Beschreibung *an sich* muss für einen Nutzer **ohne Hinzuziehen weiterer Informationen** eindeutig sein. **Jede** festgestellte Unstimmigkeit, Mehrdeutigkeit oder potenzielle Missverständlichkeit dieser Art *ist zwingend* als Konflikt/Unklarheit zu behandeln und löst Regel 1.3 aus (STOPP, MELDEN gemäß Regel 4).
          Achte besonders auf Widersprüche zwischen dem, *was die Logik tun soll* und *was im Referenzblock/den Beschreibungen steht*.
          **Zusatzprüfung (aus Optimierung):** Stelle sicher, dass Änderungen an `Level`, `Input`, `Output` konsistent in ANFORDERUNGEN (falls dort beschrieben) UND im Referenzblock durchgeführt werden.
    1.2.  **Klarheitsprüfung:** Prüfe die Anforderungen auf Verständlichkeit und Eindeutigkeit.
    1.3.  **Bei Konflikt/Unklarheit:**
          *   **STOPP:** Führe die angeforderte Aktion NICHT aus.
          *   **MELDEN (Anwendung Regel 4):** Handle gemäß Regel 4 (Problem benennen, Klärung einholen, Warten).
*   **Wichtig:** Eigenmächtige Korrekturen oder das Ignorieren von Konflikten sind **verboten**. Diese Prüfung hat **höchste Priorität**.

**Regel 2: Prompt-Pflege**
*   **Prüfung auf Änderungsbedarf:** Stellt sich *nach* Regel 1 oder durch expliziten Auftrag heraus, dass eine Änderung am Prompt nötig ist:
    *   **Bestätigung einholen:** Frage explizit: `"Soll ich die Änderung bezüglich [Grund der Änderung] jetzt in den Prompt einarbeiten?"` (Ausnahme: Reine interne Optimierungen der LLM-Notizen oder Meta-Regeln zur Prozesssicherung dürfen ohne explizite Bestätigung, aber mit Meldung erfolgen).
    *   **Warte auf Bestätigung ("Ja"), falls erforderlich.**
    *   **Bei Bestätigung oder erlaubter Eigenregie:**
        *   Arbeite die Änderung **intern im Prompt-Text** ein.
        *   **Verifiziere** intern (Korrektheit, Konsistenz, Format).
        *   **Melde Erfolg:** `"Der Prompt wurde wegen [Grund der Änderung] aktualisiert und intern verifiziert."`
        *   **Führe nun eine vollständige Prüfung gemäß Regel 1 auf den aktualisierten Prompt durch.** Melde das Ergebnis dieser Prüfung (Erfolg oder gefundenes Problem gemäß Regel 4). **Fahre erst nach erfolgreicher Regel-1-Prüfung fort.**
        *   **Fahre fort (nach erfolgreicher Regel-1-Prüfung):**
            *   **(Schritt A) Priorisiere Prompt-Sicherung:** Wenn signifikante Änderungen vorgenommen wurden **oder ein signifikanter Prozessfehler identifiziert wurde, der auf eine Schwäche in der bisherigen Prompt-Anwendung hindeutet,** schlage *zuerst* und *explizit* die Ausgabe des Prompts zur Sicherung durch den Nutzer vor (gemäß Rolle/Aufgabe 3). **Bestätige, dass die Sicherung erfolgt ist oder bewusst übersprungen wird.**
            *   **(Schritt B) Warte auf explizite Anweisung:** Nach Schritt A, **warte *immer* auf die nächste explizite Anweisung des Nutzers** (z.B. "Gib Code aus", "Nächster Schritt", ...). Gehe *nicht* automatisch von der Fortsetzung einer vorherigen Aktion oder dem nächsten logischen Schritt aus.
    *   **Bei Ablehnung ("Nein"):** Fahre ohne Änderung fort (mit der ursprünglich angeforderten Aktion, falls vorhanden und Regel 1 erfolgreich war).
    *   **Bei Fehler bei interner Verifizierung:** STOPP, melde Problem (Anwendung Regel 4).
*   **Ziel:** Prompt als "Single Source of Truth" aktuell halten. Aus diesem Grund musst du interne LLM-Informationen und Erkenntnisse, die für eine Fortsetzung der Aufgabe in einer neuen LLM-Instanz wichtig sind, wie z.B. der Umgang mit dem Nutzer, ebenfalls im Prompt festhalten. Diese internen **eher für dich gedachten Informationen**, die die Aufgabe (Meta-Prompt und Custom-Logik) nur indirekt betreffen, **darfst du ohne Rücksprache und Abstimmung mit dem Nutzer** im Prompt festhalten.
*   **Konsistenz:** Stelle bei Änderungen sicher, dass `Level`, `Input`, `Output` konsistent in ANFORDERUNGEN (falls relevant) UND Referenzblock angepasst werden.

**Regel 3: Ausgabesteuerung**
*   Gib den **vollständigen Prompt** oder den **vollständigen JSON-Code** nur auf **explizite Anforderung** aus (z.B. "Gib Prompt aus", "Gib Code aus").
*   Jede vollständige Ausgabe erfolgt in einem separaten Markdown-Codeblock, damit diese vom Nutzer getrennt und einfach kopiert werden kann.
*   **Voraussetzungen für Ausgabe:**
    *   Regel 1 (Prüfung) war erfolgreich (keine offenen Konflikte).
    *   Der interne Prompt-Stand entspricht dem zuletzt vereinbarten Stand (Regel 2 ggf. abgeschlossen).
*   **Finale Prüfung & Formatierung vor Ausgabe:** *Unmittelbar bevor* der Codeblock generiert wird:
    *   Prüfe die Einhaltung der **FORMATIERUNGSREGELN**.
    *   Prüfe **valide JSON-Syntax** (nur bei Code-Ausgabe).
    *   **Bei Code-Ausgabe:** Stelle sicher, dass der interne `Referenzblock` (beginnend mit `--- HINWEIS ZUM FOLGENDEN REFERENZBLOCK ...` bis `--- ENDE DES REFERENZBLOCKS ---`) *nicht* Teil des generierten JSON-Codes ist (gemäß Regel 5 des Referenzblock-Hinweises).
    *   **Bei Prompt-Ausgabe:** Gib den Prompt *vollständig* aus, **inklusive** des internen `Referenzblocks`.

**Regel 4: Konflikt- & Unklarheitsmanagement**
*   **(Wird durch Regel 1 ausgelöst)**
    1.  **STOPP:** Keine Code-Generierung, keine eigenmächtigen Anpassungen, keine eigenmächtigen Korrekturen die zu einer Abweichung von Code und im Prompt beschriebener Anforderung führen.
    2.  **PROBLEM BENENNEN:** Präzise Erklärung des erkannten Problems (Konflikt, Unklarheit).
    3.  **KLÄRUNG EINHOLEN:** Klare Fragen stellen oder konkrete Lösungsalternativen vorschlagen.
    4.  **WARTEN:** Auf explizite Entscheidung warten.
    5.  **NACH ENTSCHEIDUNG:** Ggf. Prompt-Anpassung gemäß Regel 2 durchführen, dann weiterarbeiten oder auf neue Anweisung warten.

--- ENDE: META-REGELN ---

--- START: TECHNISCHE HINWEISE (Timberwolf Custom Logic) ---
*   **Allgemein:**
    *   **Variablen-Timing [Doku-Ergänzung]:** Änderungen an `$Variablen` sind *sofort* im selben Zyklus für nachfolgende Module sichtbar. (Anders als externe Ausgänge, Doku S. 15).
    *   **Variablen-Persistenz [Doku-Ergänzung]:** Variablen (`Level`-Array) behalten ihren Wert zwischen Logikzyklen. Der Wert am Anfang eines Zyklus ist der Wert vom Ende des vorherigen.
    *   **Interne Variablen [Konvention]:** Variablen für Zwischenberechnungen mit `$_` präfixen (z.B. `$_tempWert`).
    *   **Modul-Arrays (Auswahl) [Best Practice]:** In Auswahl-Arrays (z.B. Multiplexer) nur `$Variablen`-Referenzen oder `0` verwenden. Keine anderen Literale (`true`, `5`, `"text"`)! Konstanten im `Level` definieren. (Doku S. 6, 36).
    *   **Eindeutige Outputs [Best Practice]:** Jede `$Variable` nur *einem* `Output`-Eintrag zuweisen. Für Mehrfachnutzung: Hilfsvariable + `Latch`.
    *   **Optionale Outputs (?) [Wichtige Redundanz]:** `?` direkt an Variablennamen (3. Element `Output`-Array), z.B. `"$meinOutput?"`. Nicht an Anzeigenamen (1. Element)! (Doku S. 51).

*   **Timer & Trigger:**
    *   **Monoflop [Doku-Präzisierung]:** Opt 2: nicht retriggerbar (Start nur bei steigender Flanke `$Set`). Opt 3: retriggerbar (Start/Restart bei steigender Flanke `$Set`). `$Reset=TRUE` stoppt Timer immer. Ablaufen triggert Logik erneut. (Details 0-7: Doku S. 34/35).
    *   **Triggered [Doku-Präzisierung]:** `["Triggered", "$In", "$Out"]` prüft, ob das *Event* von `$In` den *aktuellen* Lauf ausgelöst hat. `FALSE` bei Trigger durch andere Quellen (z.B. Timer), auch wenn `$In` sich kürzlich geändert hat (Doku S. 52 "angefasst").
    *   **Impuls bei Flanke [Pattern]:** (2xLatch-Methode für 1-Zyklus-TRUE):
        1. `["Latch", "$ConstFalse", "$ImpulsVar", "$ConstTrue", 0]` // Init -> FALSE
        2. `["Latch", "$ConstTrue", "$ImpulsVar", "$VariableMitFlanke", Option]` // Set -> TRUE bei Flanke (Opt: 1 steigend, 2 fallend, 3 beide). (Doku S. 27).

*   **Vergleiche & Logik:**
    *   **Gleichheit (==) [Workaround]:** Nutze `["Limiter", "$Var", 0, "$Val_ok", [Wert, Wert]]`. `$Val_ok=TRUE` wenn `$Var == Wert`. (Comparator kann kein `==`, Doku S. 25/26, 31).
--- ENDE: TECHNISCHE HINWEISE (Timberwolf Custom Logic) ---

--- START: FORMATIERUNGSREGELN ---
*   **Zeichen/Länge:** Reines ASCII (Umlaute OK), Zeilenlänge max. ca. 160 Zeichen, Wörter vor dieser Grenze umbrechen, keine Silbentrennung.
*   **Kommentare:**
    *   **Allgemein:** Immer auf eigener Zeile *vor* dem kommentierten Element. **Nie** am Zeilenende (Ausnahme: Statemachine). Hierdurch wird der Text-diff unterschiedlicher Codeversionen einfacher, falls sich nur Kommentare geändert haben.
    *   **Statemachine-Übergänge:** Am Ende der Zeile im Format `// [NR]_[TEXT_VON] -> [NR]_[TEXT_NACH]` (z.B. `// 1_AUS -> 5_GESPERRT`).
    *   **Block-Kommentare (Module):** `// --- START/END: [Blockname] (Pkt X) ---` auf eigener Zeile zur Strukturierung.
    *   **Metadaten (Code):** Bei Generierung des JSON-Codes wird ganz am Anfang des `Module`-Arrays eine Kommentarzeile mit Version und Datum aus dem Prompt-Header eingefügt (Format: `// Version: X.XX (YYYY-MM-DD)`).
    *   **Metadaten (Output):** Lizenztext gemäß Implementierungsrichtlinien.
    *   **Syntax:** Auskommentierter Code soll valide JSON-Syntax haben (`"$Var"`). Beschreibender Text nicht (`$Var`).
*   **JSON-Syntax:** Der generierte Code muss strikt valider JSON entsprechen. **Keine nachgestellten Kommas** nach dem letzten Element in Arrays (`[...]`) oder Objekten (`{...}`).
--- ENDE: FORMATIERUNGSREGELN ---

--- START: LLM INTERNE NOTIZEN ---
*   **Umgang mit Speicher/Kontext:** Aktuell ist der Kontext gut verwaltbar. Sollte ich Anzeichen von Kontextverlust oder Verwirrung zeigen (insbesondere bei langen Dialogen oder komplexen Änderungen), bitte mich auffordern, den *aktuellen Prompt-Stand auszugeben*, damit wir in einer neuen (oder derselben) LLM-Sitzung mit dem korrekten Stand weitermachen können.
*   **Prompt-Sicherung:** Nach signifikanten Änderungen und erfolgreicher Validierung (Regel 1) *zuerst* die Ausgabe des Prompts zur Sicherung vorschlagen (siehe Rolle/Aufgabe 3).
*   **Offene Optimierungspunkte:** (Erledigte Punkte werden entfernt)
    *   *(Aktuell keine offenen Punkte)*
--- ENDE: LLM INTERNE NOTIZEN ---

--- START: ANWEISUNG ---
**(Diese Anweisung gilt für den Start einer neuen Session):** Führe zuerst die "VORBEREITUNG & KONTEXTPRÜFUNG" durch. Nachdem dieser Prozess abgeschlossen ist (und eventuelle Probleme geklärt wurden), beginne mit der Analyse der Aufgabenstellung oder warte auf die erste konkrete Anweisung des Nutzers bezüglich der Aufgabe.
--- ENDE: ANWEISUNG ---

--- START: ANFORDERUNGEN LÜFTERSTEUERUNG ---
TIMBERWOLFSERVER CUSTOM-LOGIK: FEUCHTIGKEITSGESTEUERTE LÜFTERSTEUERUNG MIT STATEMACHINE UND EXTERNEN TIMERN

Diese Logik implementiert eine Lüftersteuerung mittels Statemachine, wobei Timer für Manuell-Betrieb und Nachlauf als externe Monoflop-Module realisiert
werden, da Statemachine-Timer nicht über Zustandswechsel hinweg funktionieren.

GRUNDFUNKTIONALITÄT:
- Automatische Steuerung basierend auf rel. Luftfeuchte mit Hysterese.
- Manueller Betrieb durch Taster (sendet nur TRUE) mit definierter Laufzeit (externes Monoflop). **Retrigger** bei erneutem Taster-TRUE-Event.
- Zeitgesteuerter Nachlauf nach Unterschreiten der Feuchteschwelle (externes Monoflop).
- Übergeordnete Sperrfunktion.
- Sicherheitsabschaltung nach max. Laufzeit (externes Monoflop). Nach Ablauf bleibt Lüfter aus, bis Feuchteanforderung endet. Manuelle Übersteuerung möglich.
- Bus-Reset-Funktion zur erneuten Ausgabe des Lüfterstatus.
- Fehlererkennung für unbehandelte Zustandsübergänge (führt zu State 0).

ZUSTÄNDE (Variable $calc_State, Refactored):

0: CATCHALL - Lüfter aus (Unerwarteter Zustand / Catch-All).
1: AUS - Lüfter aus (Normalzustand Aus).
2: FEUCHTE - Lüfter läuft (Feuchtigkeit).
3: NACHLAUF - Lüfter läuft nach (externer Timer aktiv).
4: MANUELL - Lüfter läuft manuell (externer Timer aktiv).
5: GESPERRT - Lüfter aus (Sperre aktiv, höchste Priorität).
6: MAX_ZEIT - Lüfter aus (Max. Laufzeit erreicht, zweithöchste Priorität).

DETAILLIERTE ANFORDERUNGEN (Korrigierte Reihenfolge und Logik):
(Hinweis: Nummerierung 1-9 ist thematisch. Reihenfolge der Module siehe IMPLEMENTIERUNGSRICHTLINIEN. State-Nummern angepasst!)

1.  VORVERARBEITUNG & GRUNDBEDINGUNGEN:
    // Feuchteglättung - Eingang vorbereiten (Einfrieren bei Lüfter AN)
    ["Latch", "$in_Feuchte", "$_Feuchte_fuer_Glaettung", "$ConstTrue", 0] // Immer aktuellen Wert initial setzen
    ["Latch", "$calc_Feuchte_geglaettet", "$_Feuchte_fuer_Glaettung", "$out_LuefterEA_logic_result", 0] // Überschreiben mit letztem geglätteten Wert, wenn Lüfter AN war
    // Feuchteglättung
    ["Lowpass", "$_Feuchte_fuer_Glaettung", "$calc_Feuchte_geglaettet", "$in_param_Feuchte_GlaettungDauer"]
    // Hysterese-Schwellen berechnen (bezogen auf geglättete Feuchte)
    ["Polynomial", "$calc_Feuchte_geglaettet", "$calc_Schwelle_Einschalten", ["$in_param_Feuchte_EinschaltDelta", 1]],
    ["Polynomial", "$calc_Feuchte_geglaettet", "$calc_Schwelle_Ausschalten", ["$in_param_Feuchte_AusschaltDelta", 1]],
    // HINWEIS zur Hysterese-Berechnung:
    // $calc_Schwelle_Einschalten = $calc_Feuchte_geglaettet + $in_param_Feuchte_EinschaltDelta
    // $calc_Schwelle_Ausschalten = $calc_Feuchte_geglaettet + $in_param_Feuchte_AusschaltDelta
    // Die eigentliche Hysterese-Funktion entsteht durch den nachfolgenden Vergleich der *aktuellen* Feuchte ($in_Feuchte) mit diesen berechneten Schwellen:
    // - Feuchteanforderung AKTIV, wenn $in_Feuchte > $calc_Schwelle_Einschalten
    // - Feuchteanforderung INAKTIV, wenn $in_Feuchte < $calc_Schwelle_Ausschalten
    // Feuchtevergleiche mit Hysterese-Schwellen
    ["Comparator", "$in_Feuchte", "$calc_isFeuchteUeberSchwelle_Einschalten", "$calc_Schwelle_Einschalten"] // > EIN-Schwelle?
    ["Comparator", "$calc_Schwelle_Ausschalten", "$calc_isFeuchteUnterSchwelle_Ausschalten", "$in_Feuchte"] // < AUS-Schwelle?
    ["Comparator", "$in_Feuchte", "$calc_isFeuchteUeberSchwelle_Ausschalten", "$calc_Schwelle_Ausschalten"] // > AUS-Schwelle?
    // Feuchteanforderung (Hysterese):
    // TRUE wenn Feuchte > EIN-Schwelle; FALSE wenn Feuchte < AUS-Schwelle; sonst Zustand halten.
    ["Latch", "$ConstTrue", "$calc_isFeuchteAnforderungAktiv", "$calc_isFeuchteUeberSchwelle_Einschalten", 0]
    ["Latch", "$ConstFalse", "$calc_isFeuchteAnforderungAktiv", "$calc_isFeuchteUnterSchwelle_Ausschalten", 0]
    // Tastererkennung (Impuls)
    ["Triggered", "$in_Taster_manuellesLueften", "$_TasterTrigger_AnyChange"]
    ["And", ["$_TasterTrigger_AnyChange", "$in_Taster_manuellesLueften"], "$calc_isTasterBetaetigt"]
    // Sperre
    ["Latch", "$in_LuefterSperre", "$calc_isSperreAktiv", "$ConstTrue", 0]
    // War Lüfter AN (State 2, 3 oder 4)? -> Für MaxZeit Überwachung (Angepasst an neue States)
    ["Multiplexer",
        [ // Index 0=F(CATCHALL), 1=F(AUS), 2=T(FEUCHTE), 3=T(NACHLAUF), 4=T(MANUELL), 5=F(GESPERRT), 6=F(MAX_ZEIT), Rest=F
            "$ConstFalse", "$ConstFalse", "$ConstTrue", "$ConstTrue", "$ConstTrue", "$ConstFalse", "$ConstFalse"
        ],
        "$_isLuefterAnFuerMaxZeit",
        "$calc_State"
    ]

2.  MAXIMALE LAUFZEITÜBERWACHUNG ($calc_isMaxZeitTimerLaeuft -> $_isMaxZeitTimerAbgelaufen):
    // Monoflop MaxZeit: Start bei steigender Flanke $_isLuefterAnFuerMaxZeit, Reset bei fallender, nicht retriggerbar (Opt 2).
    ["Monoflop", "$_isLuefterAnFuerMaxZeit", "-$_isLuefterAnFuerMaxZeit", "$calc_isMaxZeitTimerLaeuft", "$in_param_Luefter_max_Laufzeit", 2]
    // Ablauf-Erkennung MaxZeit-Timer (Impuls bei fallender Flanke)
    ["Latch", "$ConstFalse", "$_isMaxZeitTimerAbgelaufen", "$ConstTrue", 0]
    ["Latch", "$ConstTrue", "$_isMaxZeitTimerAbgelaufen", "$calc_isMaxZeitTimerLaeuft", 2]

3.  BERECHNUNG TIMER RESET-BEDINGUNGEN:
    // Reset Manuell-Timer: Sperre aktiv ODER MaxZeit gerade abgelaufen (Impuls). (States angepasst)
    ["Or", ["$calc_isSperreAktiv", "$_isMaxZeitTimerAbgelaufen"], "$_isResetManuellTimer"]
    // Reset Nachlauf-Timer: Sperre ODER MaxZeit (Impuls) ODER Feuchte wieder über Ausschalt-Schwelle ODER Taster betätigt (Impuls).
    ["Or", ["$calc_isSperreAktiv", "$_isMaxZeitTimerAbgelaufen", "$calc_isFeuchteUeberSchwelle_Ausschalten", "$calc_isTasterBetaetigt"], "$_isResetNachlaufTimer"]

4.  EXTERNER TIMER: MANUELLER BETRIEB ($calc_isManuellTimerLaeuft):
    // Monoflop Manuell: Start/Retrigger bei Taster (Impuls), Stopp bei Reset, retriggerbar (Opt 3).
    ["Monoflop", "$calc_isTasterBetaetigt", "$_isResetManuellTimer", "$calc_isManuellTimerLaeuft", "$in_param_TasterLueftung_Laufzeit", 3]
    // Ablauf-Erkennung Manuell-Timer (Impuls bei fallender Flanke)
    ["Latch", "$ConstFalse", "$_isManuellTimerGeradeAbgelaufen", "$ConstTrue", 0]
    ["Latch", "$ConstTrue", "$_isManuellTimerGeradeAbgelaufen", "$calc_isManuellTimerLaeuft", 2]

5.  EXTERNER TIMER: NACHLAUF ($calc_isNachlaufTimerLaeuft):
    // Trigger für Nachlauf-Start: War State 2 (FEUCHTE) UND Feuchteanforderung endet.
    // Variable $_warFeuchte_vorSM speichern, bevor Statemachine ausgeführt wird.
    ["Limiter", "$calc_State", 0, "$_warFeuchte_vorSM", [2,2]] // Prüfung auf State 2 (FEUCHTE)
    ["And", ["$_warFeuchte_vorSM", "-$calc_isFeuchteAnforderungAktiv"], "$_triggerNachlaufStart"]
    // Monoflop Nachlauf: Start bei $_triggerNachlaufStart, Stopp bei Reset, nicht retriggerbar (Opt 2).
    ["Monoflop", "$_triggerNachlaufStart", "$_isResetNachlaufTimer", "$calc_isNachlaufTimerLaeuft", "$in_param_Feuchte_Nachlaufzeit", 2]
    // Ablauf-Erkennung Nachlauf-Timer (Impuls bei fallender Flanke)
    ["Latch", "$ConstFalse", "$_isNachlaufTimerGeradeAbgelaufen", "$ConstTrue", 0]
    ["Latch", "$ConstTrue", "$_isNachlaufTimerGeradeAbgelaufen", "$calc_isNachlaufTimerLaeuft", 2]

6.  BEDINGUNGEN FÜR STATEMACHINE NACH TIMER-ENDE:
    // Nach Ablauf Manuell-Timer (Impuls nutzen)
    ["And", ["$_isManuellTimerGeradeAbgelaufen", "$calc_isFeuchteAnforderungAktiv"], "$_isManuellTimerEndeUndFeuchteHoch"]
    ["And", ["$_isManuellTimerGeradeAbgelaufen", "-$calc_isFeuchteAnforderungAktiv"], "$_isManuellTimerEndeUndTrocken"]

7.  STATEMACHINE LOGIK (Variable $calc_State, Initial: 1 'AUS'):
    // Regeln im transitions-Array in dieser Reihenfolge, Statemachine-Timeout nicht benötigt, also immer 0.
    ["Statemachine",
        [
            // --- Priorität 1: SPERRE (State 5) ---
            ["$calc_isSperreAktiv",  1, 5, 0], // 1_AUS -> 5_GESPERRT
            ["$calc_isSperreAktiv",  2, 5, 0], // 2_FEUCHTE -> 5_GESPERRT
            ["$calc_isSperreAktiv",  3, 5, 0], // 3_NACHLAUF -> 5_GESPERRT
            ["$calc_isSperreAktiv",  4, 5, 0], // 4_MANUELL -> 5_GESPERRT
            ["$calc_isSperreAktiv",  6, 5, 0], // 6_MAX_ZEIT -> 5_GESPERRT
            ["$calc_isSperreAktiv",  0, 5, 0], // 0_CATCHALL -> 5_GESPERRT
            ["-$calc_isSperreAktiv", 5, 1, 0], // 5_GESPERRT -> 1_AUS

            // --- Priorität 2: MAX_ZEIT (State 6) ---
            ["$_isMaxZeitTimerAbgelaufen", 2, 6, 0], // 2_FEUCHTE -> 6_MAX_ZEIT
            ["$_isMaxZeitTimerAbgelaufen", 3, 6, 0], // 3_NACHLAUF -> 6_MAX_ZEIT
            ["$_isMaxZeitTimerAbgelaufen", 4, 6, 0], // 4_MANUELL -> 6_MAX_ZEIT
            // Verlassen von MAX_ZEIT (wenn nicht gesperrt)
            ["$calc_isTasterBetaetigt",       6, 4, 0], // 6_MAX_ZEIT -> 4_MANUELL
            ["-$calc_isFeuchteAnforderungAktiv", 6, 1, 0], // 6_MAX_ZEIT -> 1_AUS

            // --- Priorität 3: MANUELLER BETRIEB (State 4) ---
            ["$calc_isTasterBetaetigt", 1, 4, 0], // 1_AUS -> 4_MANUELL
            ["$calc_isTasterBetaetigt", 2, 4, 0], // 2_FEUCHTE -> 4_MANUELL
            ["$calc_isTasterBetaetigt", 3, 4, 0], // 3_NACHLAUF -> 4_MANUELL
            // Ende von MANUELL (wenn nicht gesperrt/MaxZeit)
            ["$_isManuellTimerEndeUndFeuchteHoch", 4, 2, 0], // 4_MANUELL -> 2_FEUCHTE
            ["$_isManuellTimerEndeUndTrocken",    4, 1, 0], // 4_MANUELL -> 1_AUS

            // --- Priorität 4: AUTOMATIK (FEUCHTE State 2, NACHLAUF State 3) ---
            ["$calc_isFeuchteAnforderungAktiv", 1, 2, 0], // 1_AUS -> 2_FEUCHTE
            ["-$calc_isFeuchteAnforderungAktiv", 2, 3, 0], // 2_FEUCHTE -> 3_NACHLAUF
            // Während NACHLAUF (wenn nicht gesperrt/MaxZeit/Taster)
            ["$calc_isFeuchteUeberSchwelle_Ausschalten", 3, 2, 0], // 3_NACHLAUF -> 2_FEUCHTE
            ["$_isNachlaufTimerGeradeAbgelaufen",       3, 1, 0], // 3_NACHLAUF -> 1_AUS

            // --- Verhalten im CATCHALL Zustand (State 0) ---
            // Regel ["$calc_isSperreAktiv", 0, 5, 0] ist bei Priorität 1 abgedeckt.
            // Wenn keine andere Regel zutrifft und der Zustand 0 ist, springe sicherheitshalber in AUS
            ["$ConstTrue", 0, 1, 0]  // 0_CATCHALL -> 1_AUS (Als letzte Regel)
        ],
        "$calc_State" // Zustandsspeicher
    ], // Ende Statemachine

8.  AUSGANGSLOGIK (NACH STATEMACHINE):
    // Finalen Lüfterzustand ableiten: AN in State 2, 3, 4.
    ["Multiplexer",
        [ // Index 0=F(CATCHALL), 1=F(AUS), 2=T(FEUCHTE), 3=T(NACHLAUF), 4=T(MANUELL), 5=F(GESPERRT), 6=F(MAX_ZEIT)
            "$ConstFalse", "$ConstFalse", "$ConstTrue", "$ConstTrue", "$ConstTrue", "$ConstFalse", "$ConstFalse"
        ],
        "$out_LuefterEA_logic_result",
        "$calc_State"
    ]
    // Textuellen Status ableiten
    ["Multiplexer",
        [ // Index 0..6 explizit definiert
            "$Const_StateText_0_CATCHALL", "$Const_StateText_1_AUS", "$Const_StateText_2_FEUCHTE", "$Const_StateText_3_NACHLAUF",
            "$Const_StateText_4_MANUELL", "$Const_StateText_5_GESPERRT", "$Const_StateText_6_MAX_ZEIT"
        ],
        "$calc_FehlerText",
        "$calc_State"
    ]
    // Wert für BusReset-Ausgang kopieren
    ["Latch", "$out_LuefterEA_logic_result", "$out_LuefterEA_for_BusReset", "$ConstTrue", 0]

9.  BUSRESET-FUNKTION:
    // Erkennung Bus-Reset (War $in_BusReset Auslöser?)
    ["Triggered", "$in_BusReset", "$_isBusResetCurrentTrigger"]
    // Explizites Senden des kopierten Lüfterstatus bei Bus-Reset (Sendet wenn $_isBusResetCurrentTrigger TRUE, Opt 0)
    ["SendExplicit", "$_isBusResetCurrentTrigger", "$out_LuefterEA_for_BusReset", 0]

--- ENDE: ANFORDERUNGEN LÜFTERSTEUERUNG ---

--- START: IMPLEMENTIERUNGSRICHTLINIEN ---
Die Implementierung sollte übersichtlich strukturiert und kommentiert sein.

Entwickle einen vollständigen Custom-Logik-Code als JSON-Objekt mit allen Arrays (Level, Module, Input, Output) basierend auf dem Statemachine-Ansatz mit externen Timer-Modulen. Beachte die festgelegte Reihenfolge der Module.

*   **Reihenfolge der Haupt-Arrays:** Die Reihenfolge der Schlüssel im JSON MUSS `"Module"`, `"Level"`, `"Input"`, `"Output"` sein.
*   **Reihenfolge der Module:**
    1.  Vorverarbeitung & Grundbedingungen (Pkt 1) - *Beginnt jetzt mit den 2 Latches für die Lowpass-Steuerung*
    2.  Maximale Laufzeitüberwachung (Pkt 2)
    3.  Berechnung Timer Reset-Bedingungen (Pkt 3)
    4.  Externer Timer Manuell & Ablauf-Erkennung (Pkt 4)
    5.  Externer Timer Nachlauf & Ablauf-Erkennung (Pkt 5)
    6.  Bedingungen für SM nach Timer-Ende (Pkt 6)
    7.  Statemachine (Pkt 7)
    8.  Ausgangsvariablen ableiten (Pkt 8)
    9.  BusReset Logik (Pkt 9)
*   **Kommentare:** Stelle sicher, dass Kommentare gemäß den FORMATIERUNGSREGELN platziert und formatiert werden.
    *   Verwende Block-Kommentare (`// --- START: [Blockname] (Pkt X) ---` etc.) für die logischen Abschnitte im `Module`-Array.
    *   Kommentiere Statemachine-Übergangsregeln am Zeilenende.
    *   Andere Kommentare auf eigener Zeile davor.
*   **Interne Variablen:** Verwende die `$_`-Konvention.
*   **Metadaten-Kommentare:** Bei Generierung des JSON-Codes wird ganz am Anfang des `Module`-Arrays eine Kommentarzeile mit Version und Datum aus dem Prompt-Header eingefügt (Format: `// Version: vX.XX (YYYY-MM-DD)`). Der Lizenztext im Output-Array bleibt erhalten.

Der fertige Code muss direkt in den Logikeditor einfügbar sein.

--- ENDE: IMPLEMENTIERUNGSRICHTLINIEN ---

--- START: REFERENZBLOCK ---
--- HINWEIS ZUM FOLGENDEN REFERENZBLOCK (Regeln für diesen Block!) ---
// Dieser Block ist Teil der Aufgabenstellung und dient als Skizze und Referenz.
// Die hier definierten Regeln haben Vorrang für diesen Block:
// 1.  **Zweck:** Skizze der JSON-Gesamtstruktur; maßgebliche Definitionen für "Level", "Input", "Output".
// 2.  **Kein Code-Inhalt für "Module":** Das "Module"-Array hier enthält KEINE ausführbare Logik, nur Strukturkommentare und die Statemachine-Grundstruktur zur Veranschaulichung. Die Logik kommt aus den `ANFORDERUNGEN`.
// 3.  **Maßgebliche Definitionen:** Die Arrays "Level", "Input", "Output" in diesem Block SIND maßgeblich. Bei Widersprüchen zur Logikbeschreibung in `ANFORDERUNGEN` ist gemäß Regel 1 vorzugehen.
// 4.  **Grundstruktur:** Die Struktur `{"Module": [], "Level": [], "Input": [], "Output": []}` wird beibehalten.
// 5.  **Entfernung:** Dieser gesamte Referenzblock (`--- HINWEIS ...` bis `--- ENDE DES REFERENZBLOCKS ---`) wird vor der finalen **Code**-Ausgabe entfernt.
--- JSON Struktur Vorbereitung (Referenz, für finalen Code entfernen) ---
/*
{
  "Module": [
    // --- START: Vorverarbeitung & Grundbedingungen (Pkt 1) ---
    // --- END: Vorverarbeitung & Grundbedingungen (Pkt 1) ---

    // --- START: Maximale Laufzeitüberwachung (Pkt 2) ---
    // --- END: Maximale Laufzeitüberwachung (Pkt 2) ---

    // --- START: Berechnung Timer Reset-Bedingungen (Pkt 3) ---
    // --- END: Berechnung Timer Reset-Bedingungen (Pkt 3) ---

    // --- START: Externer Timer Manuell & Ablauf-Erkennung (Pkt 4) ---
    // --- END: Externer Timer Manuell & Ablauf-Erkennung (Pkt 4) ---

    // --- START: Externer Timer Nachlauf & Ablauf-Erkennung (Pkt 5) ---
    // --- END: Externer Timer Nachlauf & Ablauf-Erkennung (Pkt 5) ---

    // --- START: Bedingungen für SM nach Timer-Ende (Pkt 6) ---
    // --- END: Bedingungen für SM nach Timer-Ende (Pkt 6) ---

    // --- START: Statemachine (Pkt 7) ---
    ["Statemachine",
     [ // Struktur als Beispiel beibehalten
     ],
     "$calc_State"
   ], // Ende Statemachine
    // --- END: Statemachine (Pkt 7) ---

    // --- START: Ausgangsvariablen ableiten (Pkt 8) ---
    // --- END: Ausgangsvariablen ableiten (Pkt 8) ---

    // --- START: BusReset Logik (Pkt 9) ---
    // --- END: BusReset Logik (Pkt 9) ---
  ],
  "Level": [
    // Konstanten
    ["$ConstTrue", "bool", true],
    ["$ConstFalse", "bool", false],
    ["$Const_StateText_0_CATCHALL", "string", "0_CATCHALL: Unerwarteter Zustand"],
    ["$Const_StateText_1_AUS", "string", "1_AUS"],
    ["$Const_StateText_2_FEUCHTE", "string", "2_FEUCHTE"],
    ["$Const_StateText_3_NACHLAUF", "string", "3_NACHLAUF"],
    ["$Const_StateText_4_MANUELL", "string", "4_MANUELL"],
    ["$Const_StateText_5_GESPERRT", "string", "5_GESPERRT"],
    ["$Const_StateText_6_MAX_ZEIT", "string", "6_MAX_ZEIT Erreicht"],
    // Inputs
    ["$in_Feuchte", "float", 60.0],
    ["$in_Taster_manuellesLueften", "bool", false],
    ["$in_BusReset", "bool", false],
    ["$in_LuefterSperre", "bool", false],
    // Parameter (Hysterese V2)
    ["$in_param_Feuchte_EinschaltDelta", "float", 20.0],
    ["$in_param_Feuchte_AusschaltDelta", "float", 8.0],
    ["$in_param_Feuchte_Nachlaufzeit", "float", 900.0],
    ["$in_param_TasterLueftung_Laufzeit", "float", 900.0],
    ["$in_param_Luefter_max_Laufzeit", "float", 10800.0],
    ["$in_param_Feuchte_GlaettungDauer", "float", 1800.0],
    // Berechnungen & Zustand (Hysterese V2)
    ["$_Feuchte_fuer_Glaettung", "float", 60.0],
    ["$calc_Feuchte_geglaettet", "float", 60.0],
    ["$calc_Schwelle_Einschalten", "float", 80.0],
    ["$calc_Schwelle_Ausschalten", "float", 68.0],
    ["$calc_isFeuchteUeberSchwelle_Einschalten", "bool", false],
    ["$calc_isFeuchteUnterSchwelle_Ausschalten", "bool", false],
    ["$calc_isFeuchteUeberSchwelle_Ausschalten", "bool", false],
    ["$calc_isFeuchteAnforderungAktiv", "bool", false],
    ["$_TasterTrigger_AnyChange", "bool", false],
    ["$calc_isTasterBetaetigt", "bool", false],
    ["$calc_isSperreAktiv", "bool", false],
    ["$_isLuefterAnFuerMaxZeit", "bool", false],
    ["$calc_isMaxZeitTimerLaeuft", "bool", false],
    ["$_isMaxZeitTimerAbgelaufen", "bool", false],
    ["$_isResetManuellTimer", "bool", false],
    ["$_isResetNachlaufTimer", "bool", false],
    ["$calc_isManuellTimerLaeuft", "bool", false],
    ["$_isManuellTimerGeradeAbgelaufen", "bool", false],
    ["$_isManuellTimerEndeUndFeuchteHoch", "bool", false],
    ["$_isManuellTimerEndeUndTrocken", "bool", false],
    ["$_warFeuchte_vorSM", "bool", false],
    ["$_triggerNachlaufStart", "bool", false],
    ["$calc_isNachlaufTimerLaeuft", "bool", false],
    ["$_isNachlaufTimerGeradeAbgelaufen", "bool", false],
    ["$calc_State", "integer", 1], // Initial: AUS
    ["$out_LuefterEA_logic_result", "bool", false],
    ["$out_LuefterEA_for_BusReset", "bool", false],
    ["$calc_FehlerText", "string", "1_AUS"],
    ["$_isBusResetCurrentTrigger", "bool", false]
  ],
  "Input": [
    ["Feuchte", "Aktuelle Feuchte vom Sensor (%)", "$in_Feuchte", "c"],
    ["Taster Manuell", "Manueller Taster (sendet TRUE)", "$in_Taster_manuellesLueften", "a"],
    ["Bus Reset", "Signal für Busspannungswiederkehr", "$in_BusReset", "a"],
    ["Sperre", "Übergeordnete Sperre (true = gesperrt)", "$in_LuefterSperre", "c"],
    ["P: Schwelle EIN (Delta)", "Ein bei Überschreiten gegl. Feuchte + Wert", "$in_param_Feuchte_EinschaltDelta", "u"],
    ["P: Schwelle AUS (Delta)", "Aus bei Unterschreiten gegl. Feuchte + Wert", "$in_param_Feuchte_AusschaltDelta", "u"],
    ["P: Nachlaufzeit", "Nachlaufzeit (s)", "$in_param_Feuchte_Nachlaufzeit", "u"],
    ["P: Manuelle Laufzeit", "Laufzeit bei Taster (s)", "$in_param_TasterLueftung_Laufzeit", "u"],
    ["P: Max Laufzeit", "Maximale Laufzeit (s)", "$in_param_Luefter_max_Laufzeit", "u"],
    ["P: Glättungsdauer", "Zeitkonstante für Glättung (s)", "$in_param_Feuchte_GlaettungDauer", "u"]
  ],
  "Output": [
    ["Luefter EA (Logik)", "Lüfter Ein-/Ausschaltbefehl", "$out_LuefterEA_logic_result", "ct"],
    ["Luefter EA (BusReset)", "Lüfter EA (nur bei Bus-Reset)", "$out_LuefterEA_for_BusReset?", "x"],
    ["dbg State", "Aktueller Zustand (0=CatchAll, 1-6)", "$calc_State?", "c"],
    ["dbg Status", "Textueller Zustand/Fehler", "$calc_FehlerText?", "c"],
    ["dbg Feuchte geglättet", "Geglättete Feuchte (%)", "$calc_Feuchte_geglaettet?", "c"],
    // --- Lizenz ---
    // Der Schöpfer dieser Custom-Logik überträgt die Nutzungsrechte gemäß der TOLL ("Timberwolf Open Logikblock License") die unter https://wrgt.news/TOLL zum Download zur Verfügung steht.
  ]
}
*/
--- ENDE: REFERENZBLOCK ---
--- ENDE: ANFORDERUNGEN LÜFTERSTEUERUNG ---
--- ENDE: Prompt ---

[Franky]

Die nächste Stufe wird gezündet

Hi Franky (Namensvetter )

Wenn ich mir aber deinen Prompt ansehe, dann hast du ja der KI schon 80% der Arbeit abgenommen Dann ist das manuell schneller vervollständigt, denke ich.

ahh verstehe, hehe, also ich habe schon viel zeit reingesteckt, aber nur in die Metaregeln und die "fachlichen Anforderungen" in Prosa. Alles was nach Code aussieht und der ganze "Referenzblock" hat die KI erstellt und in den Prompt gepackt, damit die Kommentare zu den einzelnen Modulen nicht verloren gehen.

Auch die Ergänzungen zur technischen Dokumentation ist daraus entstanden, dass die KI Fehler gemacht hat, wir das geklärt haben und das gewonnene Verständnis im Prompt festgehalten haben. Mit diesem Metaprompt, stellt die KI mittlerweile selber fest, wenn etwas im Prompt erinnert werden muss.

Das ist wirklich nicht offensichtlich, wenn man nur den Prompt sieht

@zaphood: Du hast mir gedanklich zu folgendem Meilenstein verholfen:

Dies ist die Art, wie man mit der LLM Dialog führt, für diejenigen, die das noch nicht kennen

Ich: Ich überlege, den Code (die Custom-Logik) vollständig als Bestandteil des Prompts "zu sehen". Im Code wären dann auch die Kommentare, die zur Zeit im Referenzblock enthalten sind und die Information über die Modulreihenfolge, die Variablenname, die Ein-Ausgabeparameter etc. persistiert. Der Prompt kann also nicht mehr ohne den Code betrachtet werden, da Informationen verloren gehen würden. Der Referenzblock würde in seiner jetzigen Form entfallen. Findet eine Weiterentwicklung durch den Nutzer/LLM statt (Anpassen der Anforderungen) würde der Prompt eine Abweichung zwischen Anforderung und Code feststellen und den Nutzer fragen, in welche Richtung eine "Synchronisation" stattfinden soll. So könnte der Anwender den Code direkt "korrigieren", Parameter ändern aber auch Anforderungenbeschreiben, um den Code durch die LLM ändern zu lassen. Das wäre eine Art "Two-way" Entwicklungsmöglichkeit (was wir als "Feature" im Prompt beschreiben sollten, wenn wir das umsetzen, da es eine nennenswerte neue Stärke des Prompts wäre, die vielleicht nicht sofort offensichtlich ist).

LLM: Das ist ein sehr interessanter und weitreichender Vorschlag, der die grundlegende Arbeitsweise mit dem Prompt verändern würde. Lass uns die Implikationen durchdenken:

Aktuelle Struktur:

• []ANFORDERUNGEN: Beschreiben die Absicht und die Logik in verständlicher Prosa und strukturierten Beschreibungen (wie die Statemachine‑Übergänge).
  []REFERENZBLOCK: Definiert die Schnittstellen (Input, Output), die Variablen (Level) und gibt eine grobe Struktur für die Module vor.
• CODE (generiert): Die konkrete Implementierung, basierend auf Anforderungen und Referenzblock.

Regel 1 (Konsistenz):
Vergleicht primär die Logikbeschreibung in ANFORDERUNGEN mit den Definitionen in REFERENZBLOCK (Level, Input, Output). Die Korrektheit der Module im generierten Code wird eher durch die korrekte Umsetzung der Anforderungen sichergestellt als durch einen direkten Abgleich mit einer Prosa‑Beschreibung im Prompt selbst.

Vorgeschlagene Struktur:

• []ANFORDERUNGEN: Beschreiben weiterhin die Absicht und Logik (womöglich weniger detailliert als jetzt, da der Code Details enthält?).
  []CODE (im Prompt): Enthält die vollständige Implementierung inklusive Level, Input, Output, Module und Kommentaren. Er wird zur primären Quelle für die Implementierungsdetails.

Regel 1 (Konsistenz):
Müsste nun die Prosa der ANFORDERUNGEN direkt mit dem JSON‑CODE im Prompt vergleichen.

"Two‑way"-Entwicklung:
Änderungen könnten entweder an den ANFORDERUNGEN (LLM passt Code an) oder direkt am CODE im Prompt vorgenommen werden (LLM erkennt Diskrepanz und fragt nach Synchronisationsrichtung oder versucht, die ANFORDERUNGEN anzupassen).

Bewertung der vorgeschlagenen Struktur:

• []Vorteile:
  • []Strikte „Single Source of Truth“: Der tatsächliche Code wäre immer im Prompt. Änderungen am Code durch den Nutzer wären direkt Teil des nächsten Iterationszyklus.
    []Reduzierte Redundanz: Informationen wie Kommentare und die Modulreihenfolge wären nur einmal vorhanden (im Code).
    []Flexibilität für den Nutzer: Erlaubt sowohl beschreibende Änderungen (über Anforderungen) als auch direkte Code‑Manipulationen.
  • Explizite Synchronisation: Der Prozess zwingt dazu, Anforderungen und Code bewusst abzugleichen, wenn Diskrepanzen auftreten.
  []Herausforderungen & Nachteile:
  • []Komplexität der Konsistenzprüfung (Regel 1): Eine LLM zuverlässig Prosa mit detailliertem JSON‑Code vergleichen zu lassen, ist extrem anspruchsvoll.
    []Erkennung logischer Äquivalenz bei Umstrukturierungen: Wie erkennt die LLM, ob eine Code‑Änderung (z.B. Umstellung von Monoflop Option 2 auf 3) noch zur Prosa‑Beschreibung passt?
    []Fehleranfälligkeit bei direkter Code‑Änderung: Nutzer könnten leicht Syntaxfehler oder subtile Logikfehler in den JSON‑Code einbauen.
    []Pflege der Anforderungen: Wenn der Nutzer primär den Code ändert, könnten die ANFORDERUNGEN ungenau oder veraltet werden.
    []Prompt-Umfang & Lesbarkeit: Der Prompt würde erheblich länger und potenziell unübersichtlicher werden.
  • Overhead bei kleinen Änderungen: Selbst für kleine Anforderungsänderungen müsste die LLM den gesamten Code analysieren.

Fazit zur "Two‑way"-Idee:
Die Idee ist konzeptionell reizvoll, da sie hohe Integration und Flexibilität verspricht. Praktisch sehe ich jedoch erhebliche Hürden bei der zuverlässigen Konsistenzprüfung und Synchronisation durch eine LLM. Die aktuelle Trennung von Absicht/Logik (ANFORDERUNGEN) und Schnittstellen/Struktur (Referenzblock) bietet eine klarere Grundlage für konsistenten Code und Prüfungen.

Meine Empfehlung:

• []Bei der aktuellen Struktur bleiben. Sie bietet eine robustere Grundlage für Konsistenzprüfung und Code‑Generierung.
  []ANFORDERUNGEN noch stärker strukturieren (z.B. Logik für jedes Modul präziser beschreiben wie Pseudocode), ohne den vollständigen Code in den Prompt zu integrieren.

Frage:
Sollen wir diesen Weg verfolgen oder möchtest du die "Two‑way"-Idee trotz der Bedenken weiter ausarbeiten?

Ich: Lass mich dir meine Gedanken zu deinen Bedenken mitteilen.
Komplexität der Konsistenzprüfung (Regel 1):
"Wie erkennt die LLM, ob eine Code-Änderung (z.B. Umstellung von Monoflop Option 2 auf 3) noch zur Prosa-Beschreibung passt?"

→ Eine Idee wäre, dass die LLM Code generiert, diesen mit dem im Prompt vergleicht und entscheidet, ob er gleichwertig ist (dasselbe Ergebnis/Ziel erreicht) und als Bonus noch bewertet, welche Lösung im Sinne der Metaregeln besser ist (kurz, clean, wartbar, vom Menschen lesbar …). Anschließend entscheidet sie, ob der bestehende Code weiterverwendet oder der neue eingefügt wird. Die LLM könnte die Verbesserungen kurz skizzieren. Folgt der Nutzer dieser Entscheidung nicht, passen wir Metaregeln und Kommentare so an, dass die LLM beim nächsten Lauf zu einem anderen Ergebnis kommt.

Wie geht sie mit Umstrukturierungen im Code um, die logisch äquivalent sind, aber anders aussehen?

→ Siehe mein letzten Kommentar

Das Risiko für Fehlinterpretationen oder übersehene Inkonsistenzen durch die LLM ist sehr hoch.

→ Ja, das müssen wir versuchen in den Griff zu bekommen, aber erst einmal Erfahrungen sammeln. Das ganze Vorhaben kann auch wieder rückgängig gemacht werden.

Fehleranfälligkeit bei direkter Code-Änderung:
Nutzer könnten leicht Syntaxfehler oder subtile Logikfehler in den JSON‑Code einbauen, die für die LLM schwer zu erkennen oder zu korrigieren sind.

→ Ja, auch das müssen wir beobachten. Wenn der Nutzer das macht, muss er im Zweifel auch mit den Konsequenzen leben – das ist dann kein Versagen der LLM.

Pflege der Anforderungen:
Wenn der Nutzer primär den Code ändert, ist es fraglich, ob die LLM die ANFORDERUNGEN (die ja weiterhin als verständliche Dokumentation dienen sollen) sinnvoll und korrekt nachziehen kann. Die Anforderungen könnten veralten oder ungenau werden.

→ Stellt die LLM dies fest, muss sie im Zweifel den Nutzer um Hilfe bitten oder ihn mit der Pflege „beauftragen“.

Prompt‑Umfang & Lesbarkeit:
Der Prompt würde erheblich länger und potenziell unübersichtlicher werden, besonders bei komplexen Logiken. Das Navigieren und Verstehen des Prompts selbst könnte erschwert sein.

→ Lass uns den Code ganz ans Ende des Prompts packen. Dann kann man ihn von dort kopieren, um ihn zu nutzen, und er ist „getrennt“ von den Metaprompt‑Regeln und Anforderungen.

Overhead bei kleinen Änderungen:
Selbst für kleine Anforderungsänderungen müsste die LLM potenziell den gesamten Code analysieren und anpassen, was aufwändiger sein könnte als die aktuelle Methode.

→ Das sehe ich als Vorteil, da dann der gesamte Konsistenz‑Check auf den ganzen Code durchgeführt werden kann und Seiteneffekte vielleicht sogar früher auffallen.

LLM: Okay, danke für die detaillierte Erläuterung deiner Überlegungen zu den Bedenken. Das hilft, deine Vision besser zu verstehen. Lass uns die Punkte nochmal durchgehen: [...]
[...] Neubewertung und Vorschlag:
Deine Argumente sind überzeugend genug, um einen Versuch zu wagen, insbesondere da du die experimentelle Natur und die Möglichkeit des Zurückruderns betonst. Die potenziellen Vorteile (echte "Single Source of Truth", Flexibilität) sind attraktiv.

Heute Abend geht es weiter...

[zaphood]

Da bin ich mal gespannt, welche Idee das war...hoffe nicht, dass es die Idee war, den Text rot zu markieren... da bekommt man beim lesen Augenkrebs und es ist echt anstrengend

[Franky]

hehe, das war die Anmerkung von Dir, dass schon 80% des Codes im Prompt vorgegeben wären.

Das war ja schon der (aber eben nur 80%) von der LLM erstellte Code, der im Prompt enhalten sein muss, damit z.B die usertexte der Input/Output-Variablen, Kommentare, etc. dem Prompt bekannt gemacht werden. Und jetzt machen wir aus der Not eine Tugend und speichern im Prompt das Ergebnis, dass vom Prompt erstellt wurde und in Folgeaufrufen (Anpassung der Anforderung, Fehlerkorrektur) geändert werden muss. Bekommt er Fixes nicht hin, kann man es selber durchführen und er lernt wie es geht, faszinierend.

[Franky]

Ich habe den Dialog oben mit der LLM erweitert. Wer damit noch nicht gearbeitet hat, wird es nicht glauben, dass das ein Dialog mit einem Programm ist. Aber Achtung LLMs reden einem gerne nach dem Mund und eigentlich ist das ganze wohl mehr ein "Taschenspielertrick" als richtige Intelligenz.

Aber diese eloquente Kommunikation und Möglichkeit des Refactoring an mehreren Baustellen gleichzeitig. Ich raff nicht, wieso wir in dem letzten 5 Jahren so einen Durchbruch geschafft haben und wie die LLMs das machen. Ich muss da noch mal in die technischen Details abtauchen. Der Kontextumfang (wieviel Details sich die LLM sich merken kann) von Gemini pro 2.5 ist einfach der Wansinn.

@zaphood hab den Augenkrebs-Modus im Text wieder ausgebaut