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

[jhaeberle]

Also bei mir scheint es auch noch zu gehen und ich habe keine Zahlungsdaten hinterlegt.

Telekom DSL in DE.

Auch nach ab- und wieder anmelden geht es noch, allerdings werde ich da auch erst mal auf eine Anmeldeseite ai.google.dev geleitet, kann die aistudio URL aber wieder aufrufen.

[AndererStefan]

Hm,
ich habe nur einen "Alibi"-Google-Account. Keine Zahlungsdaten, keine Altersverifikation (!), keine Nutzerdaten, kein verbundenes Smartphone etc... - Eventuell liegt es dann daran. Die Dokumentation nennt neben der Region nämlich das Alter >= 18 Jahre als Vorraussetzung.
Meine IP-Lokalisierung ist jedenfalls in Deutschland.

Viele Grüße
Stefan

[AndererStefan]

Okay, es liegt am Alter.
Ich habe ein Platzhalter (01.01.2000) verwendet, wegen Datensparsamkeit und so, das glaubt Google mir scheinbar nicht.

Ich habe noch einen anderen Dummy-Account mit einem anderen Datum bei dem ich scheinbar besser gelogen habe und keine Altersverifikation benötige. Dort kann ich Gemini weiter nutzen.

VG Stefan

[AndererStefan]

Hi,

nach langer Fehlersuche... diese beiden Regeln aus dem Prompt-Template "LLM_V1.04" verursachen ein Problem:
**Syntax:** Auskommentierter Code soll valide JSON-Syntax haben (`"$Var"`). Beschreibender Text nicht (`$Var`).
**JSON-Syntax (eingebetteter Code):** Der eingebettete Code muss strikt valider JSON entsprechen. **Keine nachgestellten Kommas** nach dem letzten Element in Arrays (`[...]`) oder Objekten (`{...}`).

In striktem json gibt es nachdem was ich verstanden haben gar keine Kommentare. Das verlanlasst die KI (gemini 2.5) Anführungszeichen um Kommentare zu setzen was zu Syntaxfehlern im TWS führt. Man muss der KI vermitteln, dass Kommentare eine Sonderstellung haben und vom Parser ignoriert werden.

Der Initialisierungscode ist fehlerhaft. In json gibt es keine Kommentare. Du setzt die Kommentare aufgrund der anforderung einer strikten json-Prüfung in Anführungszeichen. Das macht diese jedoch zu einem Element, das der Parser zu interpretieren versucht.
Du musste die Kommentare ohne Anführungszeichen setzen. Der Parser ignoriert die Kommentare. D.h. Auch für die Komma-Regel sind die Kommentare zu ignorieren.

Code: Alles auswählen

Regel 1.1 (JSON Validität Syntax)
*   **Syntax:** Prüfe den *gesamten* eingebetteten `CUSTOM LOGIC JSON CODE` auf für den Timberwolf-Server **valide JSON-Syntax**. Dies bedeutet Standard-JSON-Syntax, wobei Zeilen, die mit `//` beginnen, als Kommentare behandelt und vom Parser ignoriert werden. Sie zählen nicht als JSON-Elemente und beeinflussen nicht die Komma-Setzung für vorherige/nachfolgende Elemente in Arrays oder Objekten. Bei Syntaxfehlern (abgesehen von korrekt formatierten Kommentaren): **STOPP**, handle gemäß Regel 4 (Problem: JSON Syntax Error).

Code: Alles auswählen

Regel 2, Fall A, Punkt A.2
A.2. **Anforderungen/Texte anpassen:** Arbeite die Änderung in den relevanten Text-Abschnitten (`ANFORDERUNGEN`, Kommentare im Code, Beschreibungen in `Input`/`Output`) ein. Achte auf Einhaltung der FORMATIERUNGSREGELN.

Code: Alles auswählen

Regel 3, Voraussetzungen für Ausgabe
*   Eine vollständige Prüfung gemäß **Regel 1** wurde unmittelbar zuvor erfolgreich abgeschlossen (keine offenen Konflikte, valider JSON-Code gemäß Timberwolf-Spezifikation).

Code: Alles auswählen

Regel 3, Finale Prüfung vor Ausgabe
*   Verifiziere ein letztes Mal die **JSON-Validität** (gemäß Timberwolf-Spezifikation) des eingebetteten Codes (Regel 1.1 Syntax-Check).

Code: Alles auswählen

Regel 4, Problem benennen
*   `JSON Syntax Error:` Fehler im eingebetteten Code (nicht konform mit Timberwolf-spezifischer JSON-Syntax, z.B. falsche Kommasetzung, ungültige Kommentare).

Code: Alles auswählen

FORMATIERUNGSREGELN, Kommentare (im Code), Punkt "Allgemein"
*   **Allgemein:** Kommentare beginnen mit `//` und stehen immer auf eigener Zeile *vor* dem kommentierten JSON-Element oder, im Falle von Arrays mit Moduldefinitionen oder Statemachine-Übergängen, am Ende der Zeile des jeweiligen Array-Elements. Kommentare werden vom Timberwolf JSON-Parser ignoriert und zählen nicht als JSON-Elemente (d.h. sie beeinflussen nicht die Komma-Setzung).
...
*   **JSON-Syntax (eingebetteter Code):** Der eingebettete Code muss der vom Timberwolf-Server erwarteten JSON-Syntax entsprechen. Dies ist Standard-JSON, mit der Erweiterung, dass Zeilen, die mit `//` beginnen, als Kommentare ignoriert werden. **Keine nachgestellten Kommas** nach dem letzten *echten* Element in Arrays (`[...]`) oder Objekten (`{...}`). Kommentare beeinflussen dies nicht.

Code: Alles auswählen

KODIERUNGS- & STRUKTURRICHTLINIEN
*   **Kommentare im JSON:** Stelle sicher, dass Kommentare gemäß den FORMATIERUNGSREGELN platziert und formatiert werden.
    *   Kommentare beginnen mit `//` und werden vom Timberwolf-Parser ignoriert.
    *   Verwende Block-Kommentare (`// --- START: [Blockname] (Optional: Ref. Anforderung X) ---` etc.) für die logischen Abschnitte im `Module`-Array.
    *   Kommentiere Statemachine-Übergangsregeln am Zeilenende.
    *   Andere Kommentare auf eigener Zeile davor.
    ...
Der eingebettete JSON-Code muss immer der vom Timberwolf-Server erwarteten Syntax entsprechen und direkt in den Logikeditor einfügbar sein (nachdem er aus dem Prompt kopiert wurde).

Sind die daraus resultierenden Änderungen.

VG Stefan

[Franky]

@AndererStefan Waren das "nur" Syntaxfehler, die beim Speichern der Logik vom Editor im TWS angemeckert werden? Oder hattest Du dadurch noch andere Seiteneffekte, also Fehlverhalten in ausführbarem Logikcode ?

Auf jeden Fall hast du einen "guten" Fehler im Prompt gefunden! Danke Dir...


Franky

[AndererStefan]

Hi,

das Problem waren vornehmlich die Syntax-Fehler.
Ich habe selber sehr lange gebraucht um die zu sehen, weil ich mich inhaltlich noch so gut wie gar nicht mit der TWS-Logik auseinandergesetzt habe. Und das entfernen der Anführungszeichen brachte ja auch noch keinen Erfolg, weil zusätzlich auch noch das überzählige Komma gefunden werden wollte.
Nach dem Problem mit den Syntax-Fehler musste ich noch dafür sorgen, dass die KI keine ausgedachten "not"-Module benutzt. Danach war die Logik speicherbar.

@StefanW Bei der Gelegenheit hätte ich für die Fehlermeldungen bei der Syntax-Prüfung ich einen Verbesserungswunsch:
Es gibt das rote Kästchen mit einem "x" für Fehler, das ist auch gut erkennbar.
Aber es gibt auch ein kleines schwarzes "i" vor der Zeilennummer - das ist sehr leicht zu übersehen. Es würde helfen, wenn es rot wäre.


Ob alles richtig funktioniert, weiß ich aber noch nicht. Es ist eine komlizierte Logik zur Aktivierung eines Kondensations-Entfeuchters bei hoher Raumfeuchte und PV-Überschuss. Bei sehr hoher Raumfeuchte soll der PV-Überschuss ignoriert und der Entfeuchter immer aktiviert werden. Dann gibt es auch noch Timer für Mindest-Lauf- und Pausenzeiten und Hysterese-Schwellen. Die Grundfunktion (Einschalten bei Überschuss und hoher Feuchte) hat zumindest schon mal geklappt.

VG
Stefan

[eib-eg]

@AndererStefan
Also mein ai promt hat das alles schon intus
War gestern bis heute in der Früh am pc
Es ist noch nicht final
Aber wenn es zu 90% fertig ist wirst sogar du überrascht sein wie einfach dies zu Händeln ist

Habe jetzt ca 30 verschiedene Logiken erstellen lassen
Von denen wurden nur 2 nicht auf Anhieb beim ersten Mal gespeichert
Und genau darauf bin ich aus das die ai alle Fehler vor dem speichern überprüft und zuvor beseitigt
Ich weis noch nicht wie ich diese Woche dazukomme
Aber wenn du die von der ai erstellte Referenz Datei benützt hast du schon mal 80% beseitigt

Noch ein schönes restwochenende

[AndererStefan]

Hallo Georg,

ich bin bereits laufend überrascht
Ich finde beide Konzepte mit ihren unterschiedlichen Ansätzen sehr interessant und bin gespannt welcher sich als "besser" herausstellen wird.

Die Variante mit dem Reference-Dokument ist mehr "straight-forward" und übersichtlicher (für uns Menschen). Die Methode mit dem "Meta-Master Prompt" fasziniert mich aufgrund der Meta-Befehle und der Selbstreferenzen. Es könnte sich als zu groß als nicht skalierbar/kontrollierbar herausstellen. Aber die Idee alles (Regeln, Aufgabenstellung, Code) in einem Prompt zu sichern und somit reproduzierbar und fortsetzbar zu machen, ist spannend.

Ich werde es Gemini auch mal mit dem Reference-Dokument probieren lassen und schauen, wie sich die Lösungen unterscheiden.

VG
Stefan

[eib-eg]

Die ai lernt jedes Mal dazu
Aktuell sind alle Logiken in der referenzdatei vorhanden aber noch nicht online
Sowie zu 95% aller regeln
Wobei
Die Regeln müssen in der referenzdatei vorhanden sein und die ai aufgefordert werden das sie diese auch zwingend einhält
Lies mal die von der ai geschriebenen Beiträge die ich eingestellt habe
Da steht einiges drinn
Genauso auf dein Problem bezogen
Dies wurde durch ausgiebige Tests festgestellt
Der Fehler der dabei angezeigt wird im wolf hat die ai festgestellt das es sich nicht zwingend um die Teile handelt in der er angezeigt wird
Was dabei sehr geholfen hat bei der Fehlersuche war die Warnungen und fehleranzeigen im wolf also der Taster zur Anzeige
Diese in Kombination der ai gegeben fanden wir die Fehler viel schneller
Genauso sagte ich der ai sie solle mal bewusst Fehler machen mit der Vorgabe sie soll zuvor sagen welcher Fehler eintritt und dann verglichen
Bei genauerer Betrachtung stellten wir fest das hier die meisten lernefekte waren
Diese widerum in die referenzdatei eingebracht bringt eigentlich von meiner Denke her einer jeden ai was

Mein Ziel ist es der ai über den wolf alle Anleitungen zu geben
Hintergedanke
Verkauf der Wölfe zu expandieren

So
Nun lang genug geschrieben

[AndererStefan]

So,

die Variante mit dem Reference-Dok (v4.6.2) hat auf Anhieb lauffähigen Code produziert. Ein erster Test zeigte jedoch, dass die Zeittrigger für Mindestlaufzeiten und Mindestpausen nicht funktionieren. Kurze Versuche das zu fixen führten schnell zu einem Code, der auf der Ausführungsfrequenz der Custom Logic aufbauen sollte. - Das war mir zu krude und ich habe abgebrochen.

(Ich möchte meinen Code hier nicht gemeinsam debuggen, dafür fehlt mir auch die Zeit. Ich bin mit einer lauffähigen Lösung bereits zufrieden .
Aber @eib-eg , falls du dir das mit deiner KI gemeinsam anzuschauen möchtest, kann ich dir meine Anforderungsbeschreibung und das Ergebnis schicken).

Ich habe die Gemini-KIs gegenseitig Ihre Lösungen prüfen und bewerten lassen. Es ist interessant wie unterschiedlich die Art der Antworten ist. Die KI die auf dem Meta-Promt basiert ("MetaPro") antwortet m.E. "freundlicher" und konstruktiver als die KI die auf dem Reference-Dokument v4.6.2 ("RefDoc") basiert.

Der vollständige Vergleich ist eine Menge Text und wegen Markup hier im Forum ohne manuelle Überarbeitung schlecht lesbar. Ich zitiere daher nur die beiden Fazit:

MetaPro

► Text zeigen

Empfehlungen / Fazit:

• Wenn die TWS-interne Flankenerkennung für 't'-Outputs zuverlässig ist und Comparator Mode 0 für Gleichheit kein Problem darstellt: "RefDoc" ist die elegantere, kompaktere und wahrscheinlich performantere Lösung. Die Struktur und Namensgebung sind vorbildlich.

• Wenn maximale Portabilität und Konformität mit explizit dokumentierten Standardmethoden Priorität haben: "MetaPro" ist solider, da es weniger auf implizites Verhalten oder weniger gebräuchliche Moduloptionen für kritische Funktionen setzt. Die explizite Flankenerkennung im Alarm ist robuster gegenüber Unklarheiten in der TWS-Implementierung.

Verbesserungspotenzial für MetaPro:

• Könnte Comparator Mode 6 für Hysterese übernehmen, um Code zu reduzieren.

• Könnte direkte Invertierung (-$Variable) an Moduleingängen nutzen, wo sinnvoll, um Multiplexer für NOT zu sparen.

• Strukturierung und Namensgebung von "RefDoc" könnten als Inspiration dienen.

Verbesserungspotenzial für RefDoc:

• Verwendung von Limiter für Gleichheitsprüfungen wäre sicherer.

• Wenn die TWS-Flankenerkennung für 't' unklar ist, sollte eine explizite Flankenerkennung wie in "MetaPro" erwogen werden.

Beide Ansätze haben Stärken. "RefDoc" glänzt durch Kompaktheit und elegante Nutzung von Modul-Features, während "MetaPro" auf explizitere und oft breiter dokumentierte Standard-Patterns setzt. Die beste Wahl hängt von den genauen Eigenschaften der Ziel-TWS-Version und den Prioritäten des Entwicklers ab.

RefDoc

► Text zeigen

Fazit und Empfehlung:
Die Lösung von Entwickler "RefDoc" ist klar überlegen. Sie ist korrekt, erfüllt alle Anforderungen, ist gut strukturiert, vergleichsweise einfach zu lesen und zu warten und nutzt die Timberwolf-Module effizient. Sie demonstriert ein gutes Verständnis der Modulfunktionen und üblicher Entwurfsmuster.

Die Lösung von Entwickler "MetaPro" weist schwerwiegende Fehler in der Kernlogik der Hysterese auf. Selbst wenn diese Fehler behoben würden, ist die Lösung unnötig komplex, schwer lesbar und fehleranfälliger durch den sehr kleinteiligen Aufbau und die umständliche Realisierung von Basisfunktionen. Der Ansatz, NOT explizit mit einem Multiplexer zu bauen, ist zwar möglich, aber an Stellen, wo eine Negation im Input eines Logikmoduls (And, Or etc.) möglich ist (wie bei RefDoc -$Calc_PV_Available_Raw), ist dies die deutlich elegantere und lesbarere Variante. Für eine separate NOT-Variable ist Multiplexer oder Comparator Mode 0 gegen 0 der Weg.

Empfehlung: Die Lösung von "RefDoc" sollte verwendet werden. Die Lösung von "MetaPro" müsste grundlegend überarbeitet werden, um korrekt zu funktionieren, und selbst dann wäre sie strukturell im Nachteil.

Tatsache ist... die Lösung von MetaPro funktioniert soweit bereits.

VG
Stefan, der viel zu viel Zeit mit Gemini verbringt