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

[eib-eg]

Die Tests sind meines Erachtens vom Vorgehen die gleichen.

Nachdem eine neue Version erstellt wurde, muss die ki von sich aus eine speicherbare Logik erstellen egal welche die auf dem neuen Wissensstand basiert.

Zum Schluss wird eine Syntax Demo mit allen verfügbaren Formeln erstellt und auf speicherbarkeit getestet

Das gelernte wird sofort getestet nach Vorgaben der ki wie getestet werden soll.

Sollten da wiederum Fehler vorhanden sein wird sofort der Fehler mit einer neuen Version und gehärtetem promt von vorne angefangen.

Dabei wird auf den tokenverbrauch geachtet bzw. sie meldet sich selber.


Ich kann gerne verschiedene Logiken dir geben als Test
Du gibst die Logik deiner ki
Lässt ihn analysieren und beschreiben
Diese Beschreibung gibst du einen neuen frischen und dummen ki
Und dann schaue ob sie ihn besser macht

[AndererStefan]

Hi,

ich habe in letzter Zeit privat keine Zeit mehr gehabt in dieser Hinsicht etwas auszuprobieren oder zu machen.

Die Frage kam mir auf, weil ich im Büro manchmal Ki benutze und die Ergebnisse manchmal schwankend und nicht reproduzierbar sind. (Nicht nur programmieren, auch textliche Arbeiten, Bilder erstellen,…)

Bei der Geschwindigkeit mit der sich die KI bei weiterentwickelt brauchst du ja eigentlich eine Art Benchmark oder Qualitätssicherung und sicher zustellen, dass nicht nur das gerade bearbeitete Skript besser wird, sondern auch keine der vorhergehenden Lösungen schlechter.

Und da stellte ich mir eben die Frage ob du wohl alle bisherigen Programmieraufgaben (nicht die Standardbausteine) zum Testen ausprobierst und schaust ob die KI unterschiedliche Ergebnisse produziert.

Ich muss gestehen, dass mur das nach deiner Antwort immer noch nicht klar ist

[Hermi]

Ich finde es echt faszinierend, wie Ihr hier vorgeht. Es macht richtig Spaß mitzulesen. Wenn man dann mit dem Ergebnis auch mit nur wenig Kenntnis und Erfahrung zu einer brauchbaren Lösung kommt ist das echt lobenswert.

Ich persönlich würde mich gerne mehr mit dem Aufbau von Logiken beschäftigen, habe aber leider im Moment absolut keine Zeit dazu. Dann ist es super, wenn man sich von einer KI leiten lassen kann und evtl. auch etwas erklärt bekommen.


Großes Lob von mir,
und Dankeschön

[eib-eg]

@Hermi

Du warst gedanklich der Auslöser warum ich mich mit den promt beschäftige.

Mehr kann ich dazu nicht sagen, nur danke.

[Hermi]

Du sprichst in Rätseln

[eib-eg]

Dann komm zum Treffen vorbei

Da werde ich viiiiel über den promt erzählen.

[eib-eg]

so wider neuerungen mit eingearbeitet
bei der aktuellen version 6.05.0 werden grafana sachen jetzt auch mit erstellt da die ki jetzt weis welche grafana version auf den wolf instaliert ist.
dies bezieht sich aber nicht auf selbst instalierte versionen, denn da müsste man dann nur der ki sagen bei welcher version die ist.
anleitung welches vorgehen, das sie alles richtig macht, gibt sie an den benutzer weiter.

egal ob 1wire oder knx livedaten oder zeitserien

es ist bzw wird jetzt ein sozusagen 2 gleisiger promt wobei das grafana am einfachsten ist, weil sie grafana sehr viel macht, das sie nur bestimmte sachen wissen muss und das bekommt sie durch den benutzer mitgeteilt.

tests haben ergeben
je genauer man es beschreibt um so schneller kommt man ä frau zum ergebnis

na dann würde ich sagen
lasst euch beim timberwolf-usertreffen im herbst 2025 (10. bis 12. oktober 2025) in adersberg überraschen

viewtopic.php?t=5917

[eib-eg]

wie einige vermutlich mitbekommen haben ist eine aktuellere version vorhenden
"Version": "6.08.5"
die durch diesen beitrag

viewtopic.php?t=6028

noch einmal gehärtet wurde

sowie Matthias ja den promt ja auch schon getestet hat

viewtopic.php?t=6022

[AndererStefan]

Moin @eib-eg ,

ich versuche mich gerade an einer einfachen (!) Steuerung eines "Stecker-Speichers", einer kleinen AC-gekoppelten Batterie (Zendure SolarFlow 2400 Pro). Die Batterie kann man offiziell ohne Hersteller-Cloud via lokalem MQTT steuern. Die notwendigen Steuer-Parameter sind der Modus ("charge") oder ("discharge") und die gewünschte Lade- und Entladeleistung (zwei unterschiedliche MQTT-Datenpunkte) in Watt. In den Standby wechselt die Batterie selber, wenn gewünschte Lade- oder Entladeleistung 0 W sind. Auch um die Einhaltung der eingestellen min./max. SOC kümmert sich die Batterie selber. Den aktuelle Strombezug/Einspeiseleistung bekomme ich vom Zähler via KNX - allerdings nur im Minutentakt (mit mehr will ich den Bus nicht belasten). Die Steuerung soll daher nicht aufs letzte Watt eine Nulleinspeisung versuchen, sondern soll "auf der jeweils sicheren Seite" daneben liegen. D.h. beim Entladen der Batterie ein Rest-Netzbezug von ca. 50W ist völlig i.O. und beim Laden eine Überschusseinspeisung von > 200W. Aus Effizienzgründen sollte die Ladung mit min. 400W und eine Entladung mit min. 200W erfolgen.

Ich gehe davon aus, dass es zukünftig tolle Energiemanagement-Lösungen geben wird, daher will ich kein eigenes Rad erfinden, sondern eine simple Übergangslösung. Ich habe meine Anforderungen mit einem LLM formulieren lassen und auch versucht den Code für die TWS-Logik zu erzeugen. syntaktisch ist der korrekt, tut aber nicht was er soll.

Bevor ich jetzt stundenlang versuche den LLM-Code auseinander zu nehmen und zu debuggen, dachte ich mir, ich gebe der "Version 6.08.5" mal eine Nuss zum knacken, wenn du magst

Hier ist der zusammen mit "MetaPro 2.0" formulierte Anforderungskatalog:

► Text zeigen

--- START: ANFORDERUNGEN ---

**Pkt 00: Zielsetzung**
Steuerung einer PV-Batterie basierend auf dem Messwert eines langsam aktualisierenden Stromzählers (Netzbezug). Die Steuerung soll stabil und sicher sein, ein Pendeln zwischen Lade- und Entladebetrieb vermeiden und die folgenden Hauptregeln strikt einhalten:
1. Die Batterie darf nicht aus dem Stromnetz geladen werden.
2. Aus der Batterie darf kein Strom ins Stromnetz eingespeist werden.

**Pkt 01: Grundprinzip & Zustände**
Die Logik operiert als eine Zustandsmaschine mit drei exklusiven Zuständen:
* **0: STANDBY:** Die Batterie ist im Leerlauf. Beide Leistungsausgänge (`$out_SollLeistungLaden`, `$out_SollLeistungEntladen`) werden auf 0 gesetzt.
* **1: LADEN:** Die Batterie wird aktiv geladen. Der `$out_Betriebsmodus` wird auf "charge" gesetzt. Nur `$out_SollLeistungLaden` gibt einen Wert > 0 aus.
* **2: ENTLADEN:** Die Batterie wird aktiv entladen. Der `$out_Betriebsmodus` wird auf "discharge" gesetzt. Nur `$out_SollLeistungEntladen` gibt einen Wert > 0 aus.

*Hinweis zur Nomenklatur:* Der Eingang `$in_Netzbezug` liefert positive Werte für Überschuss/Einspeisung und negative Werte für Netzbezug.

**Pkt 02: Zustandsübergänge (Hysterese-Logik)**
Die Wechsel zwischen den Zuständen werden durch das Über- oder Unterschreiten fester Leistungsschwellen am Netzzähler gesteuert.

* **Pkt 02.1: STANDBY -> LADEN:**
* Bedingung: `$in_Netzbezug >= 600 W` UND `$in_PVErzeugung > 50 W` UND SOC < 100%.
* **Pkt 02.2: LADEN -> STANDBY:**
* Bedingung: `$in_Netzbezug < 100 W` ODER SOC >= 100%.
* **Pkt 02.3: STANDBY -> ENTLADEN:**
* Bedingung: `$in_Netzbezug <= -250 W` UND SOC > 0%.
* **Pkt 02.4: ENTLADEN -> STANDBY:**
* Bedingung: `$in_Netzbezug > -50 W` ODER SOC <= 0%.

**Pkt 03: Berechnung des Leistungs-Zielwerts im Zustand LADEN**
* **Pkt 03.1: Ziel:** Es soll ein Rest-Überschuss von **200 W** am Zähler verbleiben.
* **Pkt 03.2: Formel:** `Ziel-Ladeleistung = $in_Netzbezug - 200 W`.
* **Pkt 03.3: Grenzen:** Die Ziel-Ladeleistung wird auf den Bereich von **400 W bis 1200 W** begrenzt.

**Pkt 04: Berechnung des Leistungs-Zielwerts im Zustand ENTLADEN**
* **Pkt 04.1: Ziel:** Es soll ein Rest-Bezug von **50 W** aus dem Netz verbleiben.
* **Pkt 04.2: Formel:** `Ziel-Entladeleistung = abs($in_Netzbezug) - 50 W`.
* **Pkt 04.3: Grenzen:** Die Ziel-Entladeleistung wird auf den Bereich von **200 W bis 800 W** begrenzt.

**Pkt 05: Asymmetrische & ereignisgesteuerte Leistungsanpassung (Dämpfung)**
* **Pkt 05.1: Ziel:** Starke Sprünge der Soll-Leistung sollen gedämpft werden.
* **Pkt 05.2: Trigger:** Die Leistungsanpassung erfolgt ausschließlich bei einer Aktualisierung des `$in_Netzbezug`-Wertes.
* **Pkt 05.3: Funktionsprinzip:** Der neu berechnete Leistungs-Zielwert (aus Pkt 03/04) wird mit dem zuletzt ausgegebenen Sollwert verglichen.
* **Leistungserhöhung (Zielwert > aktueller Sollwert):** Die Erhöhung erfolgt gedämpft. Der neue Sollwert wird `aktueller Sollwert + ((Zielwert - aktueller Sollwert) * Dämpfungsfaktor)` betragen. Als Dämpfungsfaktor wird `0.33` verwendet.
* **Leistungsreduktion (Zielwert < aktueller Sollwert):** Die Reduktion erfolgt **sofort**. Der neue Sollwert wird direkt auf den niedrigeren Zielwert gesetzt.
* **Pkt 05.4: Aktivierung:** Diese Logik ist in den Zuständen LADEN und ENTLADEN aktiv. Im Zustand STANDBY ist die Soll-Leistung immer 0. Der berechnete Wert wird an den jeweils aktiven Leistungsausgang (`$out_SollLeistungLaden` oder `$out_SollLeistungEntladen`) weitergeleitet.

**Pkt 06: Ein- und Ausgänge**
* **Eingänge:**
* `$in_Netzbezug` (float, W): Leistung am Zähler (+Einspeisung / -Bezug).
* `$in_PVErzeugung` (float, W): Aktuelle PV-Erzeugungsleistung.
* `$in_SOC` (float, %): Ladezustand der Batterie (0-100).
* **Ausgänge:**
* `$out_Betriebsmodus` (string): ("charge", "discharge").
* `$out_SollLeistungLaden` (float, W): Angeforderte Ladeleistung.
* `$out_SollLeistungEntladen` (float, W): Angeforderte Entladeleistung.
* `$out_LogikStatus` (integer): Aktueller Zustand der Logik (0, 1, 2).
* *Hinweis:* Es ist sicherzustellen, dass immer nur einer der beiden Leistungsausgänge einen Wert > 0 hat.

--- ENDE: ANFORDERUNGEN ---

VG
Stefan

[eib-eg]

Werde aktuell nicht so schnell dazukommen es der ki zu geben.

Zeitlich bin ich aktuell sehr eingespannt durch viele neue Heizungen anzuschließen einstellen sowie erklären und Wartungen noch neben bei. Kurse von verschiedenen Herstellern sind ja auch dazwischen gekommen.
Werde aber versuchen es möglichst zeitnah zu erledigen.

Die Vorbereitungen für das Treffen im Oktober in Adersberg laufen ja auch noch.