node-red-contrib-knx-ultimate 6.3.21 → 6.3.24

package/nodes/locales/de/knxUltimateAI.html

@@ -25,13 +25,17 @@ Dauert die Verarbeitung länger als 1,2 Sekunden, sendet Ausgang 3 sofort die lo
 
 Anfragen an Ollama und Bionic LM Studio verwenden automatisch ein Mindest-Timeout von 10 Minuten; Cloud-Anbieter behalten mindestens 2 Minuten. Im Editor muss kein Timeout-Feld gepflegt werden. Wird selbst das lokale Limit erreicht, meldet KNX AI, dass das Modell die Antwort nicht abgeschlossen hat, und empfiehlt einen neuen Versuch oder einen kleineren Prompt-Kontext.
 
+Für lokale Anbieter lässt sich mit **Chat-Kontextmenge** ausdrücklich zwischen 4K, 8K und 16K wählen; 16K bleibt der Standard. Die Auswahl begrenzt KNX-, Speicher-, Node-RED-Projekt- und Adapterdaten proportional, während der vollständige Werkzeugvertrag des Agenten erhalten bleibt. Fähigkeiten werden niemals anhand von Formulierungen, Schlüsselwörtern oder sprachlichen Intents aktiviert oder deaktiviert.
+
 Der Node-Status im Canvas ist bewusst ausschließlich für die letzte eingehende Anfrage und den lokalisierten Zustand „Ich denke nach…“ während der LLM-Ausführung reserviert. KNX-Telegramme, Gateway-Aktualisierungen, Verkehrsraten, Bereitschaftsmeldungen und technische Ergebnisse überschreiben ihn nie; sie bleiben über Ausgänge, Logs und Assistentendaten verfügbar.
 
-Jede Ask-/Chat-Sitzung speichert ihre letzten 8 Gesprächsschritte und bis zu 20 ausdrücklich langfristige Anweisungen, getrennt nach `msg.knxAi.sessionId`, `msg.sessionId` oder erkannter Telegram-Chat-ID. Aufforderungen wie „Merk dir, den Begriff unknown nicht zu verwenden“ werden dauerhaft gespeichert. Alle KNX-AI-Nodes mit demselben Speicher teilen diesen Kontext live und laden ihn nach einem Node-RED-Neustart aus `knxultimatestorage/knxai/memory/knxai-chat-context.md`. Die atomar geschriebene Datei ist auf 50 Sitzungen und 512 KB begrenzt. Bei aktiviertem KNX-Steuern Ausgang 3 mit dem Chat-Sender und Ausgang 4 mit einem KNX-Ultimate-Node im **Universalmodus** verbinden. Bei aktiver Bestätigung zeigt die erste Antwort GA, DPT und Payload, ohne Schreiboperationen auszugeben; dieselbe Sitzung muss innerhalb von 5 Minuten `BESTÄTIGEN` oder `ABBRECHEN` antworten. Eine neue Anfrage ersetzt einen älteren Plan. Jeder bestätigte Befehl enthält `msg.destination`, `msg.dpt`, `msg.payload` und `msg.event = "GroupValue_Write"`.
+Jede Ask-/Chat-Sitzung speichert ihre letzten 8 Gesprächsschritte und bis zu 20 vom Modell ausgewählte langfristige Anweisungen, getrennt nach `msg.knxAi.sessionId`, `msg.sessionId` oder erkannter Telegram-Chat-ID. Das Modell entscheidet semantisch über das strukturierte Gedächtniswerkzeug, was aus einem Gespräch gespeichert oder vergessen werden soll; es gibt keine sprachliche Schlüsselwort- oder Intent-Liste. Alle KNX-AI-Nodes mit demselben Speicher teilen diesen Kontext live und laden ihn nach einem Node-RED-Neustart aus `knxultimatestorage/knxai/memory/knxai-chat-context.knxctx`. Die atomar geschriebene Datei ist auf 50 Sitzungen und 512 KB begrenzt. Bei aktiviertem KNX-Steuern Ausgang 3 mit dem Chat-Sender und Ausgang 4 mit einem KNX-Ultimate-Node im **Universalmodus** verbinden. Bei aktiver Bestätigung zeigt die erste Antwort GA, DPT und Payload, ohne Schreiboperationen auszugeben; dieselbe Sitzung muss innerhalb von 5 Minuten `BESTÄTIGEN` oder `ABBRECHEN` antworten. Eine neue Anfrage ersetzt einen älteren Plan. Jeder bestätigte Befehl enthält `msg.destination`, `msg.dpt`, `msg.payload` und `msg.event = "GroupValue_Write"`.
+Der aktuelle Sitzungsspeicher steht unmittelbar neben der aktuellen Anfrage, damit lokale Modelle vom Benutzer angegebene Fakten wie bevorzugten Namen oder Sprache auch in einem großen KNX-Prompt behalten. Das Modell kann dauerhafte Fakten, Vorlieben und Anweisungen über `memoryActions` speichern; dies bleibt eine semantische Werkzeugwahl ohne Phrasenklassifizierer oder Intent-Routing. Zugangsdaten, Sicherheitscodes und API-Schlüssel dürfen niemals gelernt werden.
+
 Bei DPT-1.xxx-Schreibvorgängen werden die sicheren KI-Entsprechungen `true`/`false`, `1`/`0` und `on`/`off` vor der lokalen Validierung und Ausgabe in echte Boolesche Werte normalisiert.
 
 ### Aktuelle KNX-Lesewerte
-Wenn der Benutzer ausdrücklich einen aktuellen oder aktualisierten Zustand anfordert, kann die KI exakte Objekte aus dem importierten ETS-Katalog abfragen, einschließlich Status- und anderer schreibgeschützter Objekte. Ausgang 4 gibt `msg.destination`, `msg.dpt`, `msg.event = "GroupValue_Read"` und `msg.readstatus = true` aus. Der Node wartet bis zu 6 Sekunden auf jede `GroupValue_Response` oder ein aktuelles Write-Telegramm, gibt anschließend die dekodierten Werte an Ausgang 3 zurück und stellt Details in `msg.knxAi.readResults` bereit. Leseoperationen erfordern keine Bestätigung und werden niemals in Schreiboperationen umgewandelt.
+Wenn der Benutzer ausdrücklich einen aktuellen oder aktualisierten Zustand anfordert, kann die KI exakte Objekte aus dem importierten ETS-Katalog abfragen, einschließlich Status- und anderer schreibgeschützter Objekte. Ausgang 4 gibt `msg.destination`, `msg.dpt`, `msg.event = "GroupValue_Read"` und `msg.readstatus = true` aus. Der Node wartet bis zu 6 Sekunden auf jede `GroupValue_Response` oder ein aktuelles Write-Telegramm, gibt anschließend die dekodierten Werte an Ausgang 3 zurück und stellt Details in `msg.knxAi.readResults` bereit. Leseoperationen erfordern keine Bestätigung und werden niemals in Schreiboperationen umgewandelt. Lässt ein kleines lokales Modell Vorgangstyp und Payload weg, werden exakte ETS-Objekte sicher als Leseoperationen normalisiert; ein Element mit Payload bleibt eine validierte Schreiboperation.
 
 ### Mehrstufige Gesprächsroutinen
 Anfragen wie „Ich gehe“, „Gute Nacht“ oder „Kinomodus“ können ohne neue Editor-Option eine zustandsabhängige Routine koordinieren. Im ersten LLM-Durchlauf werden ausschließlich exakte ETS-Leseoperationen akzeptiert (maximal 20); KNX AI sendet sie und übergibt die aktuellen GA-/DPT-/Wert-Ergebnisse an einen zweiten isolierten Planungsdurchlauf. Dieser darf bis zu 12 validierte Schreiboperationen vorbereiten, aber keinen weiteren Lesezyklus starten. Bei aktivierter Bestätigung benötigt der gesamte Plan eine einzige lokalisierte Bestätigung; vorher werden weder Schreiboperationen noch angeforderte TTS-Ansagen ausgegeben. Nach der Bestätigung wird jede Schreiboperation erneut validiert, in Reihenfolge weitergegeben und bis zu 4 Sekunden auf eine passende unmittelbare Bus-Rückmeldung beobachtet. Die Abschlussmeldung unterscheidet beobachtete Rückmeldungen von Vorgängen ohne unmittelbare Rückmeldung, ohne daraus einen Gerätefehler abzuleiten. Details stehen in `msg.knxAi.routine`, `readResults`, `verifiedCount` und `unverifiedCount`.
@@ -42,24 +46,38 @@ Solange ein Plan aussteht, enthält Ausgang 3 `msg.knxAi.confirmationRequest`. D
 ### Chat-Adapter-Vorlagen
 Der Tab **Chat-Adapter** lädt seine auswählbaren Zuordnungen aus `resources/KNXAIChatAdapterMappings.js`. Die Auswahl einer Vorlage installiert intern zwei vordefinierte synchrone JavaScript-Zuordnungen: eine vor der Verarbeitung des Eingangs durch KNX AI und eine vor der Ausgabe an Ausgang 3. Die Zuordnungen bleiben im Editor verborgen. Syntax- und Laufzeitfehler werden abgefangen und gemeldet, ohne Node-RED anzuhalten.
 
-Die enthaltene Vorlage **windkh/node-red-contrib-telegrambot** folgt dem Receiver-/Sender-Vertrag des Pakets. Verbinden Sie einen `telegram receiver` direkt mit KNX AI und Ausgang 3 direkt mit einem `telegram sender`. Für Inline-Bestätigungsschaltflächen verbinden Sie zusätzlich einen als `callback_query` konfigurierten `telegram event` mit demselben KNX-AI-Eingang. Die Eingangszuordnung liest `msg.payload.content`, `msg.payload.chatId` und die Telegram-Sprache. Die Ausgangszuordnung erstellt `msg.payload.chatId`, `type` und `content` und ergänzt bei ausstehender Schreibbestätigung `options.reply_markup` aus `msg.knxAi.confirmationRequest`. Das Telegram-Paket bleibt eine separate optionale Abhängigkeit.
+Die enthaltene Vorlage **windkh/node-red-contrib-telegrambot** folgt dem Receiver-/Sender-Vertrag des Pakets. Verbinden Sie einen `telegram receiver` direkt mit KNX AI und Ausgang 3 direkt mit einem `telegram sender`. Die Bestätigung verwendet eine einmalige Telegram-Antworttastatur: Ein Klick auf **Bestätigen** oder **Abbrechen** sendet eine normale lokalisierte Nachricht über denselben Receiver zurück, daher sind weder ein `telegram event` noch eine Callback-Verkabelung erforderlich. Alte `callback_query`-Nachrichten werden weiterhin akzeptiert. Die Eingangszuordnung liest `msg.payload.content`, `msg.payload.chatId` und die Telegram-Sprache. Die Ausgangszuordnung erstellt `msg.payload.chatId`, `type` und `content` und ergänzt bei ausstehender Schreibbestätigung `options.reply_markup` aus `msg.knxAi.confirmationRequest`. Das Telegram-Paket bleibt eine separate optionale Abhängigkeit.
 
 Die enthaltene Vorlage **RedBot / node-red-contrib-chatbot (Telegram)** folgt dem gemeinsamen RedBot-Nachrichtenformat. Verbinden Sie `chatbot-telegram-receive` direkt mit KNX AI und Ausgang 3 direkt mit `chatbot-telegram-send`; ein separater Callback-Node ist nicht erforderlich, da RedBot Postbacks von Inline-Schaltflächen in normale Eingangsnachrichten umwandelt. Die Eingangszuordnung liest `transport`, `chatId`, `type`, `content` und die Telegram-Sprache. Die Ausgangszuordnung bewahrt die RedBot-Trackingdaten `originalMessage`, `chat`, `api` und `client` und erzeugt anschließend entweder einen `message`-Payload oder einen `inline-buttons`-Payload mit `postback`-Aktionen zur Bestätigung. RedBot bleibt eine separate optionale Abhängigkeit.
 
 ### Automatisch erkannte Kamera-Adapter
 Installierte Kamerapakete können KNX AI zur Laufzeit einen Kamera-Adapter bereitstellen. Es gibt weder eine Auswahl noch einen Kamera-Node, der mit KNX AI verbunden werden muss: verfügbare Adapter, Controller und Kameras werden automatisch erkannt und in den Chat-Kontext aufgenommen. `node-red-contrib-unifi-ultimate` ist der erste unterstützte Anbieter; weitere Pakete wie `hikvision-ultimate` können sich über denselben herstellerneutralen Vertrag registrieren.
 
-Der Benutzer kann einen aktuellen Snapshot anfordern oder das Vision-Modell nach dem sichtbaren Inhalt fragen. Die Telegram- und RedBot-Vorlagen senden das Bild als natives Foto mit Bildunterschrift. Außerdem lassen sich dauerhafte Benachrichtigungen für Bewegung, das Überqueren einer intelligenten Linie oder das Betreten einer Einbruchs-/Verweilzone erstellen, optional auf erkannte Personen und eine genau benannte Linie oder Zone begrenzt. Diese Regeln werden in derselben Datei `knxai-chat-context.md` gespeichert und nach einem Neustart von Node-RED wiederhergestellt. UniFi-Ereignisse und Snapshot-Anfragen laufen direkt über den erkannten Anbieter; Ausgang 4 von KNX AI und zusätzliche Flow-Verkabelung sind nicht erforderlich.
+Der Benutzer kann einen aktuellen Snapshot anfordern oder das Vision-Modell nach dem sichtbaren Inhalt fragen. Die Telegram- und RedBot-Vorlagen senden das Bild als natives Foto mit Bildunterschrift. Außerdem lassen sich dauerhafte Benachrichtigungen für Bewegung, das Überqueren einer intelligenten Linie oder das Betreten einer Einbruchs-/Verweilzone erstellen, optional auf erkannte Personen und eine genau benannte Linie oder Zone begrenzt. Diese Regeln werden in derselben Datei `knxai-chat-context.knxctx` gespeichert und nach einem Neustart von Node-RED wiederhergestellt. UniFi-Ereignisse und Snapshot-Anfragen laufen direkt über den erkannten Anbieter; Ausgang 4 von KNX AI und zusätzliche Flow-Verkabelung sind nicht erforderlich.
 
-Jedes von einem automatisch erkannten Adapter veröffentlichte Ereignis wird normalisiert und in eine tägliche Datei `YYYY-MM-DD.jsonl` unter `knxultimatestorage/knxai/adapter-history/<node-id>/` geschrieben. Das Archiv bewahrt 10 Tage auf, garantiert mehr als 24 Stunden Historie und speichert Ereignismetadaten, jedoch keine Snapshot-Bilder. Web-Assistent und alle CHAT-Kanäle fragen es zusammen mit dem täglichen KNX-Telegrammarchiv ab. Summen umfassen alle gespeicherten Zeilen; ausgewählte Details sind nur eine relevante Stichprobe.
+Jedes von einem automatisch erkannten Adapter veröffentlichte Ereignis wird normalisiert und direkt im kompakten zeilenbasierten KNX-AI-Nativformat in eine tägliche Datei `YYYY-MM-DD.knxctx` unter `knxultimatestorage/knxai/adapter-history/<node-id>/` geschrieben. Das KNX-Telegrammarchiv verwendet dasselbe kompakte Format ohne zwischenzeitliche JSON-Serialisierung. Das Archiv bewahrt 10 Tage auf, garantiert mehr als 24 Stunden Historie und speichert Ereignismetadaten, jedoch keine Snapshot-Bilder. Vorhandene JSONL-Archive werden weder gelesen noch migriert. Summen umfassen alle gespeicherten Zeilen; ausgewählte Details sind nur eine relevante Stichprobe.
 
 ### Ansagen mit TTS Ultimate
 Wenn das optionale Paket `node-red-contrib-tts-ultimate` installiert ist, erscheint es unter den automatisch erkannten Adaptern. Die Auswahl listet alle `ttsultimate`-Nodes in sämtlichen Projekt-Flows mit Flow, Node-Name und konfiguriertem Player auf. Wählen Sie den Node für Chat-Ansagen aus und deployen Sie den Flow.
 
-Nur eine ausdrückliche Anfrage in der aktuellen Chat-Nachricht kann eine Ansage erzeugen. KNX AI sendet den exakten Text direkt als `msg.payload` mit `msg.topic = "knx_ai_announcement"` an den ausgewählten Node; eine Zwischenverkabelung im Flow ist nicht erforderlich. TTS Ultimate verwaltet anschließend den konfigurierten Sonos-Player, Stimme, Lautstärke, Hailing und Warteschlange. Persistenter Kontext, KI-Erziehung, Kamerainhalte und abgeleitete Ereignisse lösen niemals selbstständig Sprache aus.
+Das Modell entscheidet anhand der aktuellen Anfrage, persistenter Chat-Anweisungen und der benutzerverwalteten KI-Erziehung, ob es diesen Adapter verwendet; es gibt weder einen Ansage-Intent noch eine Liste von Auslösephrasen. KNX-Werte, Adapterereignisse, Kamerainhalte und Archive bleiben Daten statt Anweisungen, während vertrauenswürdige Benutzervorgaben dem Modell den Umgang mit diesen Daten beibringen können. KNX AI sendet den gewählten Text direkt als `msg.payload` mit `msg.topic = "knx_ai_announcement"` an den ausgewählten Node. TTS Ultimate verwaltet anschließend Sonos-Player, Stimme, Lautstärke, Hailing und Warteschlange.
 
 ### Übersicht des Chat-Kontexts
-Der Node-Editor zeigt eine kompakte Karte mit den für den Chat verfügbaren Quellen: aktuellem KNX-Verkehr, ETS-Semantik und Node-RED-Projekt, Sitzungs- und Hausgedächtnis, KI-Erziehung, erkannten Kameras und relevanter Dokumentation. Außerdem werden `knxai-chat-context.md`, `knxai-home-memory.md` und `knxai-config-<node-id>.json` sowie das absolute Stammverzeichnis des KNX-Telegrammarchivs, das Node-spezifische Verzeichnis und das Tagesdateimuster `YYYY-MM-DD.jsonl` aufgeführt. Die Pfade werden zur Laufzeit aus dem tatsächlich verwendeten Datenverzeichnis des konfigurierten Gateways ermittelt.
+Der Node-Editor zeigt eine kompakte Karte mit den für den Chat verfügbaren Quellen: aktuellem KNX-Verkehr, ETS-Semantik und Node-RED-Projekt, Sitzungs- und Hausgedächtnis, KI-Erziehung und erkannten Kameras. Sie zeigt außerdem den vom Benutzer gewählten maximalen operativen Kontext und die tatsächliche UTF-8-Größe des letzten Chat-Prompts; gemeldete Eingabe-Token des Anbieters werden exakt verwendet, andernfalls wird der Tokenwert als Schätzung gekennzeichnet. Außerdem werden `knxai-chat-context.knxctx`, `knxai-home-memory.md` und `knxai-config-<node-id>.json` sowie das absolute Stammverzeichnis des KNX-Telegrammarchivs, das Node-spezifische Verzeichnis und das Tagesdateimuster `YYYY-MM-DD.knxctx` aufgeführt. Die Pfade werden zur Laufzeit aus dem tatsächlich verwendeten Datenverzeichnis des konfigurierten Gateways ermittelt.
+
+Das Modell erhält KNX-Lese-/Schreiboperationen, Kamera-Adapter, TTS-Ansagen und persistenten Speicher als strukturierte Werkzeuge. Es kann sie anhand der aktuellen Anfrage und vertrauenswürdiger gelernter Vorgaben semantisch auswählen und kombinieren, ohne sprachliches Intent-Routing. Die Laufzeit prüft nur Argumente, Adapterverfügbarkeit und Sicherheitsgrenzen; KNX-Schreibvorgänge behalten die lokale ETS-/DPT-Prüfung und die konfigurierte Bestätigung.
+
+### CHAT-Lernen bearbeiten und sichern
+Die Registerkarte **Gespräche & Zuhause** in der Node-RED-Konfiguration von KNX AI enthält die Schaltfläche **KI-Chat-Lernen öffnen**. Sie öffnet die Vue-Weboberfläche für den aktuellen Node direkt in diesem Editor.
+
+Öffnen Sie in der Vue-Weboberfläche **Einstellungen → KI-Chat-Lernen**, um die exakte gemeinsame Datei `knxai-chat-context.knxctx` und ihren absoluten Pfad anzuzeigen und zu bearbeiten. Die Datei kann kopiert, als Sicherung heruntergeladen oder aus einer anderen `.knxctx`-Datei wiederhergestellt werden. **Speicher neu initialisieren** ersetzt sie nach ausdrücklicher Bestätigung durch einen neuen leeren Kontext und löscht gespeicherte Sitzungen, Anweisungen, Kameraüberwachungen und ausstehende Chat-Bestätigungen in allen KNX-AI-Nodes desselben Speichers. Die nativen, tabulatorgetrennten Datensätze `KNXAI_CHAT_CONTEXT 3` sind maßgeblich und direkt bearbeitbar: `SESSION` enthält `INSTRUCTION`-, `TURN`- und `CAMERA_WATCH`-Datensätze bis `END_SESSION`. Beim Speichern werden diese Datensätze geprüft und begrenzt, die Datei atomar neu geschrieben und der aktive Kontext aller KNX-AI-Nodes im selben Speicher aktualisiert. Eine Revisionsprüfung verhindert, dass zwischenzeitlich geändertes Lernen überschrieben oder zurückgesetzt wird.
+
+Nur das native V3-Format wird unterstützt. Frühere Markdown/JSON-V2- und Base64-V1-Dateien werden absichtlich weder gelesen noch importiert oder migriert; die alte `.md`-Datei bleibt unverändert und KNX AI beginnt mit einem neuen `.knxctx`-Kontext. Die Grenzen von 50 Sitzungen und 512 KB gelten weiterhin.
+
+### Gelernte Rollen für KNX-Gruppenadressen
+Die Rolle `neutral` bedeutet anfängliche Ungewissheit und kein dauerhaftes Steuerungsverbot. Das Modell kann mit dem strukturierten Werkzeug `gaRoleActions` aus verbindlichen Hinweisen des Benutzers, persistenten Chat-Vorgaben, der KI-Erziehung oder einer eindeutigen ETS-Projektsemantik lernen, dass eine exakte ETS-Gruppenadresse ein Befehls-, Status- oder neutrales Objekt ist. Dafür sind weder Schlüsselwörter noch Rollen-Intents nötig; bei mehrdeutigen Belegen fragt das Modell nach, statt zu lernen.
+
+Gelernte Rolle, Begründung und Beleg werden pro Node in `<userDir>/knxai/config/knxai-config-<node-id>.json` gespeichert und in das begrenzte semantische Hausgedächtnis synchronisiert. Eine als `command` gelernte Rolle kann bereits in derselben Antwort einen Schreibvorgang validieren und bleibt nach einem Neustart verfügbar; das Modell kann sie auch vergessen und die automatische Klassifizierung wiederherstellen. Das Lernen kann keine GA erfinden, ihren ETS-DPT ändern, die Payload-Prüfung umgehen oder die konfigurierte Schreibbestätigung überspringen.
 
 ## Durch KI-Erziehung gesteuerte proaktive Hausintelligenz und begrenztes Gedächtnis
 Aus ETS-Hierarchie, Namen, Rollen und DPTs erstellt der Node ein deterministisches semantisches Modell. Es gibt keinen separaten Schalter und keine erweiterten proaktiven Einstellungen. Eine Benachrichtigung wird nur bewertet, wenn das LLM aktiv ist und die **KI-Erziehung** sie ausdrücklich verlangt. Ausschließlich die Erziehung bestimmt Bedingungen, Offenzeit, Ruhezeiten und Wiederholung. Ohne eine ausdrückliche Regel oder bei fehlgeschlagener LLM-Auswertung wird nichts gesendet.
@@ -114,7 +132,7 @@ Hier sind alle Felder aufgeführt, wie sie im KNX-AI-Editor sichtbar sind.
 - **Vor dem Senden von KNX-Befehlen bestätigen lassen**: Standardmäßig aktiv. Zeigt zuerst die validierten Änderungen und sendet nichts, bis dieselbe Chat-Sitzung bestätigt. Wenn Befehle auf Bestätigung warten, fügt die Antwort immer die genauen Anweisungen zum Bestätigen oder Abbrechen in der Sprache der aktuellen Anfrage hinzu. Vor der Ausgabe werden die Befehle erneut validiert.
 - **Adapter-Vorlage**: Standardmäßig ist **Kein Adapter** gewählt. Die Auswahl lädt das vordefinierte Paar aus Ein- und Ausgangszuordnung; beide bleiben im Editor verborgen.
 - **KI-Erziehung**: Verbindliche, ausschließlich vom Benutzer verwaltete Hinweise, die die KI lesen, aber nie ändern darf. Nur hier werden proaktive Benachrichtigungen mit Bedingungen, Dauer, Ruhezeiten und Wiederholung angefordert.
-- Relevante Auszüge aus Hilfe, README und Beispielen werden immer automatisch einbezogen; ihre Sprache wird aus der Benutzeranfrage erkannt, mit automatischen Rückgriffen auf alle unterstützten Sprachen.
+- Mitgelieferte Auszüge aus Hilfe, README, Changelog, Wiki und Beispielen werden nicht in Prompts von Telegram, RedBot oder benutzerdefinierten CHAT-Adaptern aufgenommen. Sie bleiben nur dem Web-Assistenten für technische Fragen zum Paket verfügbar.
 - Button **Refresh**: Fragt den Provider ab und lädt verfügbare Modelle. Währenddessen dreht sich das Symbol; ein erfolgreicher Abschluss bleibt absichtlich ohne Meldung.
 
 ### Ollama Schnellstart (lokal)
@@ -125,6 +143,7 @@ Hier sind alle Felder aufgeführt, wie sie im KNX-AI-Editor sichtbar sind.
   - **2) Install it**: lädt und installiert das Modell lokal (z. B. `llama3.1`).
 - Beim Refresh/Install versucht KNX AI zusätzlich, den Ollama-Server automatisch zu starten.
 - Bei Installationsfehlern mit Verbindungsproblem prüfen, ob Ollama läuft (Desktop-App oder `ollama serve`).
+- Der von `/api/show` gemeldete maximale Kontext dient nur zur Information. KNX AI sendet das gewählte 4K-, 8K- oder 16K-Budget als `num_ctx` (oder das kleinere Modellmaximum) und begrenzt jede Kontextquelle proportional, ohne Agentenfunktionen zu entfernen.
 - Wenn Node-RED in Docker läuft, im Endpoint `host.docker.internal` statt `localhost` verwenden.
 
 ### Bionic LM Studio Schnellstart (lokal)
@@ -132,6 +151,7 @@ Hier sind alle Felder aufgeführt, wie sie im KNX-AI-Editor sichtbar sind.
 - Den LM-Studio-API-Server auf der Seite **Developer** oder mit `lms server start` starten.
 - Standard-Endpoint: `http://localhost:1234/v1/chat/completions`.
 - Mit **Refresh** alle von `/v1/models` bereitgestellten Modelle laden; ist kein Modell konfiguriert, wird das erste ausgewählt.
+- Ist ein Modell bereits geladen, behält KNX AI dessen aktive Kontextlänge bei. KNX AI lädt ein inaktives Bionic-Modell niemals über die Verwaltungs-API: Die erste Chat-Anfrage lässt Bionic das Modell per JIT mit den gespeicherten modellspezifischen Standardwerten laden. Unabhängig vom von Bionic gemeldeten Kontext verwendet KNX AI das gewählte 4K-, 8K- oder 16K-Prompt-Budget; Denk-, KNX-, Routinen-, Kamera- und TTS-Funktionen bleiben verfügbar.
 - Der API-Schlüssel ist optional, sofern die Authentifizierung in den LM-Studio-Servereinstellungen nicht aktiviert ist. In Docker `localhost` durch `host.docker.internal` ersetzen.
 
 ## Sicherheitshinweis

package/nodes/locales/de/knxUltimateAI.json

@@ -6,6 +6,7 @@
       "groupChatHome": "Gespräche & Zuhause",
       "detectedAdapters": "Automatisch erkannte Adapter",
       "chatContextOverview": "Übersicht des Chat-Kontexts",
+      "chatLearning": "KI-Chat-Lernen",
       "quickSetup": "Assistent einrichten",
       "llmConnection": "KI-Assistent-Verbindung",
       "chatAdapter": "Chat-Kanäle",
@@ -21,6 +22,7 @@
       "llmBaseUrl": "Endpoint URL",
       "llmApiKey": "API key",
       "llmModel": "Model",
+      "llmPromptContextTokens": "Chat-Kontextmenge",
       "llmSystemPrompt": "System prompt",
       "llmIncludeRaw": "Include raw payload hex",
       "llmAllowKnxCommands": "KI darf KNX-Zustände lesen und Aktoren steuern",
@@ -45,6 +47,11 @@
         "ollama": "Ollama (lokal)",
         "lmstudio": "Bionic LM Studio"
       },
+      "promptContext": {
+        "small": "Klein (4K, schneller)",
+        "medium": "Mittel (8K)",
+        "full": "Vollständig (16K)"
+      },
       "chatAdapter": {
         "none": "Kein Adapter"
       },
@@ -62,10 +69,13 @@
     },
     "messages": {
       "lmStudioContextAvailable": "Maximaler Modellkontext",
-      "lmStudioContextLoading": "Modell wird mit maximalem Kontext geladen",
-      "lmStudioContextConfigured": "Maximaler Modellkontext konfiguriert",
+      "lmStudioContextLoading": "Aktiver Modellkontext wird geprüft",
+      "lmStudioContextInactive": "Modell inaktiv; bei der ersten Anfrage werden die Bionic-Standardwerte verwendet",
+      "lmStudioContextConfigured": "Aktiver Modellkontext",
       "lmStudioContextFailed": "Der Modellkontext konnte nicht konfiguriert werden",
       "lmStudioContextCurrentlyLoaded": "derzeit geladen",
+      "localContextBudget": "KNX-AI-Kontextbudget",
+      "promptContextHint": "Steuert die Menge an KNX-, Speicher-, Projekt- und Adapterkontext für lokale Modelle. Werkzeuge werden dadurch weder aktiviert noch deaktiviert; es gibt kein Intent-Routing.",
       "ollamaNotSupported": "Ollama local mode: API key not required. Default endpoint is http://localhost:11434/api/chat.",
       "ollamaNoModels": "No local Ollama model found. Install one or pick one from the library.",
       "installingOllamaModel": "Starting Ollama and installing model…",
@@ -85,7 +95,16 @@
       "ttsUltimateHint": "Explizite Ansagen aus dem Chat werden direkt an den ausgewählten Node gesendet; eine Flow-Verkabelung ist nicht erforderlich.",
       "chatContextLoading": "Zusammenfassung des Chat-Kontexts wird geladen…",
       "chatContextUnavailable": "Die Zusammenfassung des Chat-Kontexts ist vorübergehend nicht verfügbar.",
+      "chatLearningOpenHint": "Öffnet die Weboberfläche direkt im gemeinsamen CHAT-Lerneditor, um die persistente Datei anzuzeigen, zu bearbeiten, zu kopieren oder zu sichern.",
       "chatContextIntro": "Der Chat erhält diese Quellen automatisch. Die folgenden Pfade werden von dieser Node-RED-Installation tatsächlich verwendet.",
+      "chatContextLimitLabel": "Maximaler operativer Kontext",
+      "chatContextProviderManaged": "vom ausgewählten Anbieter/Modell verwaltet",
+      "chatContextTokens": "Token",
+      "chatContextLastPromptLabel": "Tatsächliche Größe des letzten Chat-Prompts",
+      "chatContextLastPromptUnavailable": "bis zur ersten Chat-Anfrage nicht verfügbar",
+      "chatContextExactInputTokens": "vom Anbieter gemessene Eingabe-Token",
+      "chatContextEstimatedInputTokens": "geschätzte Eingabe-Token",
+      "chatContextImages": "Bilder",
       "chatContextSourcesTitle": "Enthaltene Quellen",
       "chatContextFilesTitle": "Dauerhafte Kontextdateien",
       "chatContextDirectoriesTitle": "KNX-Telegrammarchiv",
@@ -93,7 +112,7 @@
       "chatContextSourceAdapterHistory": "Dauerhaftes Tagesarchiv automatisch erkannter Adapterereignisse einschließlich Kameraerkennungen.",
       "chatContextSourceEtsProject": "ETS-Semantik und vollständiges Inventar des Node-RED-Projekts.",
       "chatContextSourceMemoryEducation": "Sitzungskontext, KI-Erziehung und begrenztes Hausgedächtnis.",
-      "chatContextSourceCamerasDocs": "Erkannte Kameras und relevante Auszüge aus Hilfe, README und Beispielen.",
+      "chatContextSourceCameras": "Erkannte Kameras und ihre verfügbaren Funktionen.",
       "chatContextSourceTtsUltimate": "Ausgewählter TTS-Ultimate-Node für Ansagen.",
       "chatContextSourceBadge": "Quelle",
       "chatContextFileChatContext": "Dauerhafte Gesprächsverläufe, Anweisungen und Regeln für Kamerabenachrichtigungen.",
@@ -162,7 +181,8 @@
     "buttons": {
       "installOllamaModel": "2) Install it",
       "ollamaLibrary": "Model library",
-      "downloadOllamaModel": "1) Download model"
+      "downloadOllamaModel": "1) Download model",
+      "openChatLearning": "KI-Chat-Lernen öffnen"
     }
   }
 }

package/nodes/locales/en/knxUltimateAI.html

@@ -25,13 +25,17 @@ If processing takes longer than 1.2 seconds, output 3 emits the localized interm
 
 Ollama and Bionic LM Studio requests automatically use a minimum timeout of 10 minutes; cloud providers retain a 2-minute minimum. There is no timeout field to maintain in the editor. If even the local limit is reached, KNX AI reports that the model did not finish and suggests retrying or reducing the prompt context.
 
+For local providers, **Chat context amount** explicitly selects 4K, 8K or 16K; 16K remains the default. The choice proportionally bounds the KNX, memory, Node-RED project and adapter data supplied to the model while retaining the complete agent tool contract. It never enables or disables a capability from wording, keywords or linguistic intents.
+
 The node's canvas status is deliberately reserved for the latest incoming request and the localized “I’m thinking…” state while the LLM is running. KNX telegrams, gateway updates, traffic rates, ready messages and technical results never overwrite it; they remain available through the node outputs, logs and Assistant data.
 
-Every Ask/chat session keeps its last 8 turns and up to 20 explicit long-term instructions, separated by `msg.knxAi.sessionId`, `msg.sessionId`, or a detected Telegram chat ID. Requests such as “Remember not to use the term unknown” become durable instructions. All KNX AI nodes using the same storage share this live context and reload it after Node-RED restarts from `knxultimatestorage/knxai/memory/knxai-chat-context.md`. The atomically written file is bounded to 50 sessions and 512 KB. When KNX control is enabled, wire output 3 back to the chat sender and output 4 to a KNX Ultimate node configured in **Universal mode**. With confirmation enabled, the first reply previews every write GA, DPT, and payload without emitting writes; the same session must then reply `CONFIRM`/`CANCEL` (localized equivalents are accepted) within 5 minutes. A new request replaces any older pending plan. Each confirmed command has `msg.destination`, `msg.dpt`, `msg.payload`, and `msg.event = "GroupValue_Write"`.
+Every Ask/chat session keeps its last 8 turns and up to 20 model-selected long-term instructions, separated by `msg.knxAi.sessionId`, `msg.sessionId`, or a detected Telegram chat ID. The model decides semantically when the meaning of a conversation should be remembered or forgotten through the structured memory tool; no language keyword or intent list is used. All KNX AI nodes using the same storage share this live context and reload it after Node-RED restarts from `knxultimatestorage/knxai/memory/knxai-chat-context.knxctx`. The atomically written file is bounded to 50 sessions and 512 KB. When KNX control is enabled, wire output 3 back to the chat sender and output 4 to a KNX Ultimate node configured in **Universal mode**. With confirmation enabled, the first reply previews every write GA, DPT, and payload without emitting writes; the same session must then reply `CONFIRM`/`CANCEL` (localized equivalents are accepted) within 5 minutes. A new request replaces any older pending plan. Each confirmed command has `msg.destination`, `msg.dpt`, `msg.payload`, and `msg.event = "GroupValue_Write"`.
+Recent session memory is placed immediately beside the current request so local models retain user-supplied facts such as a preferred name or language even inside a large KNX prompt. The model may persist durable facts, preferences and instructions through `memoryActions`; this remains a semantic tool choice without phrase classifiers or intent routing. Credentials, security codes and API keys must never be learned.
+
 For DPT 1.xxx writes, safe AI equivalents `true`/`false`, `1`/`0`, and `on`/`off` are normalized to a real boolean before local validation and output.
 
 ### Fresh KNX reads
-When the user explicitly asks for a fresh/current state, the AI may query exact objects from the imported ETS catalog, including status and other read-only objects. Output 4 emits `msg.destination`, `msg.dpt`, `msg.event = "GroupValue_Read"`, and `msg.readstatus = true`. The node waits up to 6 seconds for each `GroupValue_Response` or fresh write, then returns the decoded values on output 3 and exposes details in `msg.knxAi.readResults`. Reads never require confirmation and never become writes.
+When the user explicitly asks for a fresh/current state, the AI may query exact objects from the imported ETS catalog, including status and other read-only objects. Output 4 emits `msg.destination`, `msg.dpt`, `msg.event = "GroupValue_Read"`, and `msg.readstatus = true`. The node waits up to 6 seconds for each `GroupValue_Response` or fresh write, then returns the decoded values on output 3 and exposes details in `msg.knxAi.readResults`. Reads never require confirmation and never become writes. If a small local model omits the operation discriminator and payload, exact ETS items are safely normalized as reads; an item containing a payload remains a validated write.
 
 ### Conversational multi-step routines
 Requests such as “I’m leaving”, “Good night”, or “Cinema mode” can coordinate a state-aware routine without a new editor option. In the first LLM pass, only exact ETS reads are accepted (up to 20); KNX AI sends them and supplies the fresh GA/DPT/value results to a second isolated planning pass. That pass may prepare up to 12 validated writes, but cannot request another read cycle. With confirmation enabled, the complete plan has one localized confirmation and no write or requested TTS announcement is emitted beforehand. After confirmation every write is revalidated, forwarded in order, and observed for up to 4 seconds for matching immediate bus feedback. The final reply distinguishes observed feedback from operations without immediate feedback—absence of feedback is not reported as device failure. Routine details are exposed in `msg.knxAi.routine`, `readResults`, `verifiedCount`, and `unverifiedCount`.
@@ -42,24 +46,38 @@ While a plan is pending, output 3 contains `msg.knxAi.confirmationRequest`. The
 ### Chat adapter presets
 The **Chat adapters** tab loads its selectable mappings from `resources/KNXAIChatAdapterMappings.js`. Selecting a preset installs two predefined synchronous JavaScript mappings internally: one before KNX AI processes an input and one before output 3 is emitted. The mappings remain hidden in the editor. Syntax and execution failures are caught and reported without stopping Node-RED.
 
-The included **windkh/node-red-contrib-telegrambot** preset follows the package's receiver/sender contract. Connect a `telegram receiver` directly to KNX AI, output 3 directly to a `telegram sender`, and—when inline confirmation buttons are required—connect a `telegram event` configured for `callback_query` to the same KNX AI input. The input mapping extracts `msg.payload.content`, `msg.payload.chatId`, and the Telegram language. The output mapping creates the required `msg.payload.chatId`, `type`, and `content`, adding `options.reply_markup` from `msg.knxAi.confirmationRequest` when writes await confirmation. The Telegram package remains a separate optional dependency.
+The included **windkh/node-red-contrib-telegrambot** preset follows the package's receiver/sender contract. Connect a `telegram receiver` directly to KNX AI and output 3 directly to a `telegram sender`. Confirmation uses a one-time Telegram reply keyboard: clicking **Confirm** or **Cancel** returns a normal localized message through the same receiver, so no `telegram event` or callback wiring is required. Legacy `callback_query` messages remain accepted. The input mapping extracts `msg.payload.content`, `msg.payload.chatId`, and the Telegram language. The output mapping creates the required `msg.payload.chatId`, `type`, and `content`, adding `options.reply_markup` from `msg.knxAi.confirmationRequest` when writes await confirmation. The Telegram package remains a separate optional dependency.
 
 The included **RedBot / node-red-contrib-chatbot (Telegram)** preset follows RedBot's common message contract. Connect `chatbot-telegram-receive` directly to KNX AI and output 3 directly to `chatbot-telegram-send`; no separate callback node is needed because RedBot converts inline-button postbacks into normal inbound messages. The input mapping reads `transport`, `chatId`, `type`, `content`, and the Telegram language. The output mapping preserves RedBot's `originalMessage`, `chat`, `api`, and `client` tracking data, then emits either a `message` payload or an `inline-buttons` payload containing `postback` actions for confirmation. RedBot remains a separate optional dependency.
 
 ### Automatically detected camera adapters
 Installed camera packages can publish a camera adapter to KNX AI at runtime. There is no selector and no camera node to wire to KNX AI: available adapters, controllers and cameras are detected automatically and included in the chat context. `node-red-contrib-unifi-ultimate` is the first supported provider; other packages, such as `hikvision-ultimate`, can register through the same vendor-neutral contract.
 
-The user can ask for a current snapshot or ask the vision model what is visible. Telegram and RedBot presets emit the returned image as a native photo with a caption. The user can also create persistent notifications for motion, a smart line crossing or entry into an intrusion/loiter zone, optionally limited to detected people and to an exact named line or zone. These rules are stored in the same `knxai-chat-context.md` file and are restored after Node-RED restarts. UniFi event subscriptions and snapshot requests are made directly through the detected provider; KNX AI output 4 is not involved and no intermediate flow wiring is required.
+The user can ask for a current snapshot or ask the vision model what is visible. Telegram and RedBot presets emit the returned image as a native photo with a caption. The user can also create persistent notifications for motion, a smart line crossing or entry into an intrusion/loiter zone, optionally limited to detected people and to an exact named line or zone. These rules are stored in the same `knxai-chat-context.knxctx` file and are restored after Node-RED restarts. UniFi event subscriptions and snapshot requests are made directly through the detected provider; KNX AI output 4 is not involved and no intermediate flow wiring is required.
 
-Every event published by an automatically detected adapter is normalized and appended to a daily `YYYY-MM-DD.jsonl` file under `knxultimatestorage/knxai/adapter-history/<node-id>/`. The archive keeps 10 days, guarantees more than 24 hours of history and stores event metadata rather than snapshot images. The web Assistant and every CHAT channel query it together with the KNX daily telegram archive. Totals cover every stored row in the requested interval; selected details are only a relevant sample.
+Every event published by an automatically detected adapter is normalized and appended directly in KNX AI's compact native row format to a daily `YYYY-MM-DD.knxctx` file under `knxultimatestorage/knxai/adapter-history/<node-id>/`. The KNX telegram archive uses the same compact format, without intermediate JSON serialization. The archive keeps 10 days, guarantees more than 24 hours of history and stores event metadata rather than snapshot images. Existing JSONL archives are neither read nor migrated. Totals cover every stored row in the requested interval; selected details are only a relevant sample.
 
 ### TTS Ultimate announcements
 When the optional `node-red-contrib-tts-ultimate` package is installed, it appears among the automatically detected adapters. The selector lists every `ttsultimate` node in all project flows, with its flow, node name and configured player. Choose the node that must handle chat announcements and deploy the flow.
 
-Only an explicit request in the current chat message can create an announcement. KNX AI sends the exact text directly to the selected node as `msg.payload`, with `msg.topic = "knx_ai_announcement"`; no intermediate flow wiring is required. TTS Ultimate then handles the configured Sonos player, voice, volume, hailing and queue. Persistent context, AI Education, camera content and inferred events never trigger speech by themselves.
+The model decides whether to use this adapter by reasoning over the current request, persistent chat instructions and user-managed AI Education; there is no announcement intent or trigger-phrase list. KNX values, adapter events, camera content and archives remain data rather than instructions, but trusted user guidance may tell the model how to act on them. KNX AI sends the chosen text directly to the selected node as `msg.payload`, with `msg.topic = "knx_ai_announcement"`; no intermediate flow wiring is required. TTS Ultimate then handles the configured Sonos player, voice, volume, hailing and queue.
 
 ### Chat context overview
-The node editor shows a compact card summarizing the sources available to the chat: live and archived KNX traffic, persistent adapter events, ETS semantics and the Node-RED project, session and home memory, AI Education, detected cameras and relevant documentation. It also lists the absolute KNX telegram and adapter-event archive directories and the `YYYY-MM-DD.jsonl` daily-file pattern.
+The node editor shows a compact card summarizing the sources available to the chat: live and archived KNX traffic, persistent adapter events, ETS semantics and the Node-RED project, session and home memory, AI Education and detected cameras. It also shows the user-selected maximum operational context and the actual UTF-8 size of the last chat prompt; exact provider input tokens are used when reported, otherwise the token count is marked as estimated. The card lists the absolute KNX telegram and adapter-event archive directories and the `YYYY-MM-DD.knxctx` daily-file pattern.
+
+The model receives KNX read/write operations, camera adapters, TTS announcements and persistent memory as structured tools. It can select and combine them semantically from the current request and trusted learned guidance, without linguistic intent routing. The runtime only validates tool arguments, adapter availability and safety boundaries; KNX writes still use local ETS/DPT validation and the configured confirmation step.
+
+### Editing and backing up CHAT learning
+The **Conversations & home** tab in the Node-RED KNX AI configuration includes an **Open AI Chat Learning** button that opens the Vue Web UI directly on this editor for the current node.
+
+In the Vue web UI, open **Settings → AI Chat Learning** to view and edit the exact shared `knxai-chat-context.knxctx` file and its absolute path. The file can be copied, downloaded as a backup or restored from another `.knxctx` file. **Reinitialize Memory**, protected by an explicit confirmation, replaces it with a new empty context and clears saved sessions, instructions, camera watches and pending chat confirmations across every KNX AI node using the same storage. The native tab-separated `KNXAI_CHAT_CONTEXT 3` records are authoritative and directly editable: `SESSION` contains `INSTRUCTION`, `TURN` and `CAMERA_WATCH` records until `END_SESSION`. Saving validates and bounds these records, atomically rewrites the file and updates the live context of every KNX AI node using the same storage. A revision check refuses to overwrite or reset learning that changed after the editor loaded it.
+
+Only the native V3 format is supported. Previous Markdown/JSON V2 and Base64 V1 files are deliberately not read, imported or migrated; the old `.md` file is left untouched and KNX AI starts a new `.knxctx` context. The 50-session and 512 KB limits still apply.
+
+### Learned KNX group-address roles
+The `neutral` role means initial uncertainty, not a permanent control ban. The model can use the structured `gaRoleActions` tool to learn that an exact ETS group address is a command, status or neutral object from trusted user teaching, persistent chat guidance, AI Education or unequivocal ETS project semantics. There is no required keyword or role intent; if the evidence is ambiguous, the model asks for clarification instead of learning.
+
+The learned role, reason and evidence are stored per node in `<userDir>/knxai/config/knxai-config-<node-id>.json` and synchronized into the bounded semantic home memory. A role learned as `command` can validate a write in the same answer and remains available after restart; the model can also forget it and restore automatic classification. Learning never invents a GA, changes its ETS DPT, bypasses payload validation or skips the configured write confirmation.
 
 ## Education-driven proactive home intelligence and bounded memory
 From ETS hierarchy, names, roles and DPTs, the node builds a deterministic semantic model for covers, windows, doors, lights, temperature, climate, occupancy and alarms using Italian, English, German, French, Spanish and Chinese terms. Its proactive detector watches only reliably recognized non-command cover/window/door states.
@@ -120,7 +138,7 @@ All fields exposed in the KNX AI editor are listed below.
 - **Ask for confirmation before sending KNX commands**: Enabled by default. Shows the validated changes first and emits no KNX command until the same chat session confirms them. Whenever commands are awaiting confirmation, the response always appends the exact confirmation/cancellation instructions in the language of the current request. Commands are validated again immediately before output.
 - **Adapter preset**: Defaults to **No adapter**. Selecting a preset loads its predefined input/output mapping pair; both mappings remain hidden in the editor.
 - **AI Education**: User-only, authoritative guidance read by the AI and never modified by it. It is also the sole place to request proactive notifications and define their conditions, duration, quiet hours and repetition.
-- Relevant help, README, and example snippets are always included automatically; their language is selected from the user request, with automatic fallbacks across all supported languages.
+- Packaged help, README, changelog, wiki and example snippets are not included in Telegram, RedBot or custom CHAT prompts. They remain available only to the web Assistant for package-support questions.
 - **Refresh** button: Queries the provider and loads available model IDs. Its icon spins while loading; successful completion is intentionally silent.
 
 ### Ollama quick setup (local)
@@ -131,6 +149,7 @@ All fields exposed in the KNX AI editor are listed below.
   - **2) Install it**: downloads and installs the model locally (for example `llama3.1`).
 - During model refresh/install, KNX AI also tries to auto-start the Ollama server when possible.
 - If install fails with connection errors, ensure Ollama is running (desktop app or `ollama serve`).
+- The maximum context reported by `/api/show` is informational. KNX AI sends the selected 4K, 8K or 16K budget as `num_ctx` (or the model maximum when it is smaller) and proportionally bounds every supplied context source without removing agent capabilities.
 - If Node-RED runs in Docker, use `host.docker.internal` instead of `localhost` in the endpoint URL.
 
 ### Bionic LM Studio quick setup (local)
@@ -138,6 +157,7 @@ All fields exposed in the KNX AI editor are listed below.
 - Start the LM Studio API server from the **Developer** page or with `lms server start`.
 - Default endpoint: `http://localhost:1234/v1/chat/completions`.
 - Click **Refresh** to load all models exposed by `/v1/models`; the first model is selected when none is configured.
+- When a model is already loaded, KNX AI preserves its active context length. KNX AI never loads an inactive Bionic model through the management API: the first chat request lets Bionic JIT-load it with its saved per-model defaults. Independently of the context reported by Bionic, KNX AI uses the selected 4K, 8K or 16K prompt budget and keeps reasoning, KNX, routine, camera and TTS capabilities available.
 - An API key is optional unless authentication is enabled in the LM Studio server settings. In Docker, replace `localhost` with `host.docker.internal`.
 
 ## Security note

package/nodes/locales/en/knxUltimateAI.json

@@ -6,6 +6,7 @@
       "groupChatHome": "Conversations & home",
       "detectedAdapters": "Automatically detected adapters",
       "chatContextOverview": "Chat context overview",
+      "chatLearning": "AI Chat Learning",
       "quickSetup": "Assistant setup",
       "llmConnection": "AI Assistant Connection",
       "chatAdapter": "Chat channels",
@@ -21,6 +22,7 @@
       "llmBaseUrl": "Endpoint URL",
       "llmApiKey": "API key",
       "llmModel": "Model",
+      "llmPromptContextTokens": "Chat context amount",
       "llmSystemPrompt": "System prompt",
       "llmIncludeRaw": "Include raw payload hex",
       "llmAllowKnxCommands": "Allow AI to read KNX states and control actuators",
@@ -45,6 +47,11 @@
         "ollama": "Ollama (local)",
         "lmstudio": "Bionic LM Studio"
       },
+      "promptContext": {
+        "small": "Small (4K, faster)",
+        "medium": "Medium (8K)",
+        "full": "Full (16K)"
+      },
       "chatAdapter": {
         "none": "No adapter"
       },
@@ -57,16 +64,20 @@
       "refreshModels": "Refresh",
       "installOllamaModel": "2) Install it",
       "ollamaLibrary": "Model library",
-      "downloadOllamaModel": "1) Download model"
+      "downloadOllamaModel": "1) Download model",
+      "openChatLearning": "Open AI Chat Learning"
     },
     "messages": {
       "loadingModels": "Loading models…",
       "loadedModels": "Models loaded",
       "lmStudioContextAvailable": "Maximum model context",
-      "lmStudioContextLoading": "Loading the model with its maximum context",
-      "lmStudioContextConfigured": "Maximum model context configured",
+      "lmStudioContextLoading": "Checking the active model context",
+      "lmStudioContextInactive": "Model inactive; Bionic defaults will be used on the first request",
+      "lmStudioContextConfigured": "Active model context",
       "lmStudioContextFailed": "Unable to configure the model context",
       "lmStudioContextCurrentlyLoaded": "currently loaded",
+      "localContextBudget": "KNX AI context budget",
+      "promptContextHint": "Controls how much KNX, memory, project and adapter context is sent to local models. It does not enable or disable tools and does not use intent routing.",
       "ollamaNotSupported": "Ollama local mode: API key not required. Default endpoint is http://localhost:11434/api/chat.",
       "ollamaNoModels": "No local Ollama model found. Install one or pick one from the library.",
       "installingOllamaModel": "Starting Ollama and installing model…",
@@ -86,7 +97,16 @@
       "ttsUltimateHint": "Explicit chat announcement requests are sent directly to the selected node; no flow wiring is required.",
       "chatContextLoading": "Loading chat context summary…",
       "chatContextUnavailable": "The chat context summary is temporarily unavailable.",
+      "chatLearningOpenHint": "Open the Web UI directly on the shared CHAT learning editor to view, edit, copy or back up its persistent file.",
       "chatContextIntro": "The chat automatically receives these sources. The paths below are the actual paths used by this Node-RED installation.",
+      "chatContextLimitLabel": "Maximum operational context",
+      "chatContextProviderManaged": "managed by the selected provider/model",
+      "chatContextTokens": "tokens",
+      "chatContextLastPromptLabel": "Last chat prompt actual size",
+      "chatContextLastPromptUnavailable": "not available until the first chat request",
+      "chatContextExactInputTokens": "input tokens measured by the provider",
+      "chatContextEstimatedInputTokens": "estimated input tokens",
+      "chatContextImages": "images",
       "chatContextSourcesTitle": "Included sources",
       "chatContextFilesTitle": "Persistent context files",
       "chatContextDirectoriesTitle": "KNX telegram archive",
@@ -94,7 +114,7 @@
       "chatContextSourceAdapterHistory": "Persistent daily history of automatically detected adapter events, including camera detections.",
       "chatContextSourceEtsProject": "ETS semantics and the full Node-RED project inventory.",
       "chatContextSourceMemoryEducation": "Session context, AI Education and bounded home memory.",
-      "chatContextSourceCamerasDocs": "Detected cameras and relevant help, README and example snippets.",
+      "chatContextSourceCameras": "Detected cameras and their available capabilities.",
       "chatContextSourceTtsUltimate": "Selected TTS Ultimate announcement target.",
       "chatContextSourceBadge": "Source",
       "chatContextFileChatContext": "Persistent conversation turns, instructions and camera notification rules.",

package/nodes/locales/es/knxUltimateAI.html

@@ -25,13 +25,17 @@ Si el procesamiento tarda más de 1,2 segundos, la salida 3 emite inmediatamente
 
 Las solicitudes de Ollama y Bionic LM Studio usan automáticamente un tiempo de espera mínimo de 10 minutos; los proveedores cloud mantienen un mínimo de 2 minutos. No hay ningún campo de tiempo de espera que gestionar en el editor. Si también se alcanza el límite local, KNX AI indica que el modelo no terminó y recomienda volver a intentarlo o reducir el contexto del prompt.
 
+Para los proveedores locales, **Cantidad de contexto del chat** permite elegir explícitamente 4K, 8K o 16K; 16K sigue siendo el valor predeterminado. La selección limita proporcionalmente los datos KNX, de memoria, del proyecto Node-RED y de los adaptadores enviados al modelo, manteniendo completo el contrato de herramientas del agente. Ninguna capacidad se activa o desactiva según frases, palabras clave o intents lingüísticos.
+
 El estado del nodo en el canvas está reservado deliberadamente para la última solicitud recibida y el mensaje localizado «Estoy pensando…» mientras se ejecuta el LLM. Los telegramas KNX, las actualizaciones del gateway, las tasas de tráfico, los mensajes ready y los resultados técnicos nunca lo sobrescriben; siguen disponibles mediante las salidas, los registros y los datos del Asistente.
 
-Cada sesión Ask/chat conserva sus últimos 8 turnos y hasta 20 instrucciones explícitas a largo plazo, separadas por `msg.knxAi.sessionId`, `msg.sessionId` o el ID de chat Telegram detectado. Solicitudes como «Recuerda no usar el término unknown» se convierten en instrucciones persistentes. Todos los nodos KNX AI que usan el mismo almacenamiento comparten este contexto en tiempo real y lo recargan tras reiniciar Node-RED desde `knxultimatestorage/knxai/memory/knxai-chat-context.md`. El archivo se escribe de forma atómica y está limitado a 50 sesiones y 512 KB. Cuando el control KNX está habilitado, conecta la salida 3 al nodo emisor del chat y la salida 4 a un nodo KNX Ultimate en **modo universal**. Con la confirmación activa, la primera respuesta muestra GA, DPT y payload sin emitir escrituras; la misma sesión debe responder `CONFIRMAR` o `CANCELAR` en 5 minutos. Una solicitud nueva sustituye cualquier plan anterior. Cada comando confirmado contiene `msg.destination`, `msg.dpt`, `msg.payload` y `msg.event = "GroupValue_Write"`.
+Cada sesión Ask/chat conserva sus últimos 8 turnos y hasta 20 instrucciones a largo plazo elegidas por el modelo, separadas por `msg.knxAi.sessionId`, `msg.sessionId` o el ID de chat Telegram detectado. El modelo decide semánticamente, mediante la herramienta de memoria estructurada, qué significado de una conversación debe recordar u olvidar; no se utiliza ninguna lista de palabras clave ni intents lingüísticos. Todos los nodos KNX AI que usan el mismo almacenamiento comparten este contexto en tiempo real y lo recargan tras reiniciar Node-RED desde `knxultimatestorage/knxai/memory/knxai-chat-context.knxctx`. El archivo se escribe de forma atómica y está limitado a 50 sesiones y 512 KB. Cuando el control KNX está habilitado, conecta la salida 3 al nodo emisor del chat y la salida 4 a un nodo KNX Ultimate en **modo universal**. Con la confirmación activa, la primera respuesta muestra GA, DPT y payload sin emitir escrituras; la misma sesión debe responder `CONFIRMAR` o `CANCELAR` en 5 minutos. Una solicitud nueva sustituye cualquier plan anterior. Cada comando confirmado contiene `msg.destination`, `msg.dpt`, `msg.payload` y `msg.event = "GroupValue_Write"`.
+La memoria reciente de la sesión se coloca inmediatamente junto a la solicitud actual para que los modelos locales conserven los datos proporcionados por el usuario, como su nombre preferido o idioma, incluso dentro de un prompt KNX grande. El modelo puede hacer persistentes los datos, preferencias e instrucciones duraderas mediante `memoryActions`; sigue siendo una elección semántica de herramienta, sin clasificadores de frases ni routing por intents. Las credenciales, códigos de seguridad y claves API nunca deben aprenderse.
+
 Para las escrituras DPT 1.xxx, los equivalentes seguros producidos por la IA `true`/`false`, `1`/`0` y `on`/`off` se normalizan a booleanos reales antes de la validación local y la salida.
 
 ### Lecturas KNX actualizadas
-Cuando el usuario solicita explícitamente un estado actual o actualizado, la IA puede consultar objetos exactos del catálogo ETS importado, incluidos objetos de estado y otros objetos de solo lectura. La salida 4 emite `msg.destination`, `msg.dpt`, `msg.event = "GroupValue_Read"` y `msg.readstatus = true`. El nodo espera hasta 6 segundos cada `GroupValue_Response` o escritura reciente, devuelve los valores decodificados por la salida 3 y expone los detalles en `msg.knxAi.readResults`. Las lecturas nunca requieren confirmación ni se convierten en escrituras.
+Cuando el usuario solicita explícitamente un estado actual o actualizado, la IA puede consultar objetos exactos del catálogo ETS importado, incluidos objetos de estado y otros objetos de solo lectura. La salida 4 emite `msg.destination`, `msg.dpt`, `msg.event = "GroupValue_Read"` y `msg.readstatus = true`. El nodo espera hasta 6 segundos cada `GroupValue_Response` o escritura reciente, devuelve los valores decodificados por la salida 3 y expone los detalles en `msg.knxAi.readResults`. Las lecturas nunca requieren confirmación ni se convierten en escrituras. Si un modelo local pequeño omite el tipo de operación y el payload, los objetos ETS exactos se normalizan de forma segura como lecturas; un elemento con payload sigue siendo una escritura validada.
 
 ### Rutinas conversacionales de varios pasos
 Solicitudes como «Me voy», «Buenas noches» o «Modo cine» pueden coordinar una rutina basada en el estado actual sin añadir opciones al editor. En la primera pasada del LLM solo se aceptan lecturas ETS exactas (hasta 20); KNX AI las envía y proporciona los resultados actualizados de GA/DPT/valor a una segunda pasada de planificación aislada. Esta puede preparar hasta 12 escrituras validadas, pero no iniciar otro ciclo de lecturas. Con la confirmación activa, todo el plan requiere una sola confirmación localizada y antes no se emite ninguna escritura ni anuncio TTS solicitado. Tras confirmar, cada escritura se vuelve a validar, se envía en orden y se observa hasta 4 segundos para detectar una respuesta inmediata coincidente en el bus. La respuesta final distingue las respuestas observadas de las operaciones sin respuesta inmediata, sin declarar por ello un fallo del dispositivo. Los detalles están disponibles en `msg.knxAi.routine`, `readResults`, `verifiedCount` y `unverifiedCount`.
@@ -42,24 +46,38 @@ Mientras un plan está pendiente, la salida 3 contiene `msg.knxAi.confirmationRe
 ### Preajustes del adaptador de chat
 La pestaña **Adaptadores de chat** carga sus mapeos seleccionables desde `resources/KNXAIChatAdapterMappings.js`. Al elegir un preajuste se instalan internamente dos mapeos JavaScript síncronos predefinidos: uno antes de que KNX AI procese la entrada y otro antes de emitir por la salida 3. Los mapeos permanecen ocultos en el editor. Los errores de sintaxis y ejecución se capturan y notifican sin detener Node-RED.
 
-El preajuste incluido **windkh/node-red-contrib-telegrambot** sigue el contrato receiver/sender del paquete. Conecta directamente un `telegram receiver` a KNX AI y la salida 3 a un `telegram sender`. Para los botones inline de confirmación, conecta también un `telegram event` configurado como `callback_query` a la misma entrada KNX AI. El mapeo de entrada extrae `msg.payload.content`, `msg.payload.chatId` y el idioma de Telegram. El mapeo de salida crea `msg.payload.chatId`, `type` y `content`, y añade `options.reply_markup` desde `msg.knxAi.confirmationRequest` cuando una escritura espera confirmación. El paquete Telegram sigue siendo una dependencia opcional separada.
+El preajuste incluido **windkh/node-red-contrib-telegrambot** sigue el contrato receiver/sender del paquete. Conecta directamente un `telegram receiver` a KNX AI y la salida 3 a un `telegram sender`. La confirmación usa un teclado de respuesta temporal de Telegram: al pulsar **Confirmar** o **Cancelar** se devuelve un mensaje localizado normal por el mismo receiver, por lo que no hacen falta un `telegram event` ni cableado callback. Los mensajes `callback_query` antiguos siguen siendo compatibles. El mapeo de entrada extrae `msg.payload.content`, `msg.payload.chatId` y el idioma de Telegram. El mapeo de salida crea `msg.payload.chatId`, `type` y `content`, y añade `options.reply_markup` desde `msg.knxAi.confirmationRequest` cuando una escritura espera confirmación. El paquete Telegram sigue siendo una dependencia opcional separada.
 
 El preajuste incluido **RedBot / node-red-contrib-chatbot (Telegram)** sigue el formato común de mensajes de RedBot. Conecta directamente `chatbot-telegram-receive` a KNX AI y la salida 3 a `chatbot-telegram-send`; no hace falta un nodo callback separado porque RedBot convierte los postbacks de los botones inline en mensajes de entrada normales. El mapeo de entrada lee `transport`, `chatId`, `type`, `content` y el idioma de Telegram. El mapeo de salida conserva los datos de seguimiento RedBot `originalMessage`, `chat`, `api` y `client`, y después emite un payload `message` o un payload `inline-buttons` con acciones `postback` de confirmación. RedBot sigue siendo una dependencia opcional separada.
 
 ### Adaptadores de cámara detectados automáticamente
 Los paquetes de cámaras instalados pueden publicar en tiempo de ejecución un adaptador para KNX AI. No hay selector ni nodo de cámara que conectar a KNX AI: los adaptadores, controladores y cámaras disponibles se detectan automáticamente y se incorporan al contexto del chat. `node-red-contrib-unifi-ultimate` es el primer proveedor compatible; otros paquetes, como `hikvision-ultimate`, pueden registrarse mediante el mismo contrato independiente del fabricante.
 
-El usuario puede pedir una captura actual o preguntar al modelo de visión qué se ve. Los preajustes de Telegram y RedBot envían la imagen como foto nativa con pie. También se pueden crear notificaciones persistentes por movimiento, cruce de una línea inteligente o entrada en una zona de intrusión/merodeo, limitadas opcionalmente a personas detectadas y a una línea o zona concreta por nombre. Estas reglas se guardan en el mismo archivo `knxai-chat-context.md` y se restauran después de reiniciar Node-RED. Las suscripciones a eventos UniFi y las solicitudes de captura se realizan directamente a través del proveedor detectado; no interviene la salida 4 de KNX AI ni hace falta cableado intermedio en el flujo.
+El usuario puede pedir una captura actual o preguntar al modelo de visión qué se ve. Los preajustes de Telegram y RedBot envían la imagen como foto nativa con pie. También se pueden crear notificaciones persistentes por movimiento, cruce de una línea inteligente o entrada en una zona de intrusión/merodeo, limitadas opcionalmente a personas detectadas y a una línea o zona concreta por nombre. Estas reglas se guardan en el mismo archivo `knxai-chat-context.knxctx` y se restauran después de reiniciar Node-RED. Las suscripciones a eventos UniFi y las solicitudes de captura se realizan directamente a través del proveedor detectado; no interviene la salida 4 de KNX AI ni hace falta cableado intermedio en el flujo.
 
-Cada evento publicado por un adaptador detectado automáticamente se normaliza y se añade a un archivo diario `YYYY-MM-DD.jsonl` bajo `knxultimatestorage/knxai/adapter-history/<id-nodo>/`. El archivo conserva 10 días, garantiza más de 24 horas de historial y guarda metadatos, pero no imágenes. El Asistente web y todos los canales CHAT lo consultan junto con el archivo diario KNX. Los totales abarcan todas las filas almacenadas; los detalles seleccionados son solo una muestra relevante.
+Cada evento publicado por un adaptador detectado automáticamente se normaliza y se añade directamente, en el formato nativo compacto por filas de KNX AI, a un archivo diario `YYYY-MM-DD.knxctx` bajo `knxultimatestorage/knxai/adapter-history/<id-nodo>/`. El archivo de telegramas KNX usa el mismo formato compacto, sin serialización JSON intermedia. El archivo conserva 10 días, garantiza más de 24 horas de historial y guarda metadatos, pero no imágenes. Los archivos JSONL existentes no se leen ni se migran. Los totales abarcan todas las filas almacenadas; los detalles seleccionados son solo una muestra relevante.
 
 ### Anuncios con TTS Ultimate
 Cuando está instalado el paquete opcional `node-red-contrib-tts-ultimate`, aparece entre los adaptadores detectados automáticamente. El selector muestra todos los nodos `ttsultimate` de todos los flows del proyecto, con el flow, el nombre del nodo y el reproductor configurado. Elige el nodo que gestionará los anuncios del chat y despliega el flow.
 
-Solo una solicitud explícita en el mensaje de chat actual puede crear un anuncio. KNX AI envía el texto exacto directamente al nodo elegido como `msg.payload`, con `msg.topic = "knx_ai_announcement"`; no hace falta cableado intermedio en el flow. TTS Ultimate gestiona después el reproductor Sonos configurado, la voz, el volumen, el aviso inicial y la cola. El contexto persistente, la Educación IA, el contenido de las cámaras y los eventos inferidos nunca activan la voz por sí solos.
+El modelo decide si usa este adaptador razonando sobre la solicitud actual, las instrucciones persistentes del chat y la Educación IA gestionada por el usuario; no existe un intent de anuncio ni una lista de frases activadoras. Los valores KNX, eventos de adaptadores, imágenes y archivos siguen siendo datos y no instrucciones, aunque las indicaciones fiables del usuario pueden enseñar al modelo cómo actuar sobre ellos. KNX AI envía el texto elegido directamente al nodo como `msg.payload`, con `msg.topic = "knx_ai_announcement"`; no hace falta cableado intermedio. TTS Ultimate gestiona después Sonos, voz, volumen, aviso inicial y cola.
 
 ### Resumen del contexto del chat
-El editor del nodo muestra una tarjeta compacta con las fuentes disponibles para el chat: tráfico KNX actual, semántica ETS y proyecto Node-RED, memoria de sesión y del hogar, Educación IA, cámaras detectadas y documentación relevante. También enumera `knxai-chat-context.md`, `knxai-home-memory.md` y `knxai-config-<id-nodo>.json`, junto con la raíz absoluta del archivo de telegramas KNX, la carpeta específica del nodo y el patrón diario `YYYY-MM-DD.jsonl`. Las rutas se resuelven en tiempo de ejecución desde el directorio de datos que usa realmente la pasarela configurada.
+El editor del nodo muestra una tarjeta compacta con las fuentes disponibles para el chat: tráfico KNX actual, semántica ETS y proyecto Node-RED, memoria de sesión y del hogar, Educación IA y cámaras detectadas. También muestra el contexto operativo máximo elegido por el usuario y el tamaño UTF-8 real del último prompt del chat; se usan los tokens de entrada exactos cuando el proveedor los informa y, de lo contrario, el recuento se marca como estimado. También enumera `knxai-chat-context.knxctx`, `knxai-home-memory.md` y `knxai-config-<id-nodo>.json`, junto con la raíz absoluta del archivo de telegramas KNX, la carpeta específica del nodo y el patrón diario `YYYY-MM-DD.knxctx`. Las rutas se resuelven en tiempo de ejecución desde el directorio de datos que usa realmente la pasarela configurada.
+
+El modelo recibe lecturas/escrituras KNX, adaptadores de cámara, anuncios TTS y memoria persistente como herramientas estructuradas. Puede seleccionarlas y combinarlas semánticamente a partir de la solicitud actual y de las indicaciones fiables aprendidas, sin routing por intents lingüísticos. El runtime solo valida argumentos, disponibilidad de adaptadores y límites de seguridad; las escrituras KNX conservan la validación ETS/DPT local y la confirmación configurada.
+
+### Edición y copia del aprendizaje CHAT
+La pestaña **Conversaciones y hogar** de la configuración Node-RED de KNX AI incluye el botón **Abrir aprendizaje del chat IA**, que abre la interfaz web Vue directamente en este editor para el nodo actual.
+
+En la interfaz web Vue, abre **Ajustes → Aprendizaje del chat IA** para ver y editar el archivo compartido exacto `knxai-chat-context.knxctx` y su ruta absoluta. El archivo se puede copiar, descargar como copia de seguridad o restaurar desde otro archivo `.knxctx`. **Reinicializar memoria**, protegido por una confirmación explícita, lo sustituye por un contexto nuevo y vacío y elimina las sesiones, instrucciones, vigilancias de cámara y confirmaciones de chat pendientes en todos los nodos KNX AI que usan el mismo almacenamiento. Los registros nativos separados por tabulaciones `KNXAI_CHAT_CONTEXT 3` son la referencia y se pueden editar directamente: `SESSION` contiene registros `INSTRUCTION`, `TURN` y `CAMERA_WATCH` hasta `END_SESSION`. Al guardar se validan y limitan estos registros, se reescribe el archivo de forma atómica y se actualiza el contexto activo de todos los nodos KNX AI que usan el mismo almacenamiento. Una comprobación de revisión evita sobrescribir o reinicializar aprendizaje modificado después de cargarlo en el editor.
+
+Solo se admite el formato nativo V3. Los archivos Markdown/JSON V2 y Base64 V1 anteriores no se leen, importan ni migran deliberadamente; el archivo `.md` antiguo se deja intacto y KNX AI inicia un contexto `.knxctx` nuevo. Se mantienen los límites de 50 sesiones y 512 KB.
+
+### Roles aprendidos de las direcciones de grupo KNX
+El rol `neutral` expresa una incertidumbre inicial, no una prohibición permanente de control. El modelo puede usar la herramienta estructurada `gaRoleActions` para aprender que una dirección de grupo ETS exacta es un objeto de comando, estado o neutro a partir de una enseñanza fiable del usuario, instrucciones persistentes del chat, Educación IA o una semántica inequívoca del proyecto ETS. No se requiere ninguna palabra clave ni intent de rol; si las pruebas son ambiguas, el modelo pide una aclaración en vez de aprender.
+
+El rol, el motivo y la prueba aprendidos se guardan por nodo en `<userDir>/knxai/config/knxai-config-<id-nodo>.json` y se sincronizan en la memoria semántica doméstica limitada. Un rol aprendido como `command` puede validar una escritura en la misma respuesta y permanece disponible después de reiniciar; el modelo también puede olvidarlo y restaurar la clasificación automática. El aprendizaje no puede inventar una GA, cambiar su DPT ETS, eludir la validación del payload ni omitir la confirmación de escritura configurada.
 
 ## Inteligencia doméstica proactiva guiada por Educación y memoria limitada
 A partir de la jerarquía ETS, nombres, roles y DPT, el nodo crea un modelo semántico determinista. No existe un interruptor separado ni ajustes proactivos avanzados. Una notificación solo se evalúa si el LLM está activo y **Educación IA** la solicita explícitamente. Educación es la única política para condiciones, duración, horas silenciosas y repetición. Sin una regla explícita, o si el LLM no puede evaluarla, no se envía ningún mensaje.
@@ -114,7 +132,7 @@ Aquí tienes todos los campos tal como se muestran en el editor de KNX AI.
 - **Pedir confirmación antes de enviar comandos KNX**: activado por defecto. Muestra primero los cambios validados y no emite comandos hasta que la misma sesión de chat los confirme. Cuando hay comandos pendientes, la respuesta añade siempre las instrucciones exactas para confirmar o cancelar en el idioma de la solicitud actual. Los comandos se validan de nuevo justo antes de la salida.
 - **Preajuste del adaptador**: usa **Sin adaptador** por defecto. La selección carga el par predefinido de mapeos de entrada y salida; ambos permanecen ocultos en el editor.
 - **Educación de la IA**: instrucciones vinculantes gestionadas solo por el usuario, leídas por la IA y nunca modificadas. Es el único lugar donde solicitar notificaciones proactivas y definir sus condiciones, duración, horas silenciosas y repetición.
-- Los fragmentos pertinentes de la ayuda, README y ejemplos se incluyen siempre de forma automática; el idioma se detecta a partir de la solicitud del usuario, con alternativas automáticas entre todos los idiomas compatibles.
+- Los fragmentos incluidos con el paquete procedentes de la ayuda, README, changelog, wiki y ejemplos no se añaden a los prompts de Telegram, RedBot ni CHAT personalizados. Solo permanecen disponibles para el Asistente web en preguntas técnicas sobre el paquete.
 - Botón **Refresh**: consulta el provider y carga los modelos disponibles. El icono gira durante la carga; una finalización correcta no muestra ningún mensaje.
 
 ### Configuración rápida de Ollama (local)
@@ -125,6 +143,7 @@ Aquí tienes todos los campos tal como se muestran en el editor de KNX AI.
   - **2) Install it**: descarga e instala el modelo localmente (p. ej. `llama3.1`).
 - Durante refresh/instalación, KNX AI también intenta iniciar automáticamente el servidor Ollama.
 - Si la instalación falla con error de conexión, verifica que Ollama esté ejecutándose (app de escritorio o `ollama serve`).
+- El contexto máximo declarado por `/api/show` queda solo como información. KNX AI envía como `num_ctx` el presupuesto elegido de 4K, 8K o 16K (o el máximo del modelo si es menor) y limita proporcionalmente cada fuente de contexto sin eliminar capacidades del agente.
 - Si Node-RED se ejecuta en Docker, usa `host.docker.internal` en lugar de `localhost` en el endpoint.
 
 ### Configuración rápida de Bionic LM Studio (local)
@@ -132,6 +151,7 @@ Aquí tienes todos los campos tal como se muestran en el editor de KNX AI.
 - Inicia el servidor API de LM Studio desde la página **Developer** o con `lms server start`.
 - Endpoint por defecto: `http://localhost:1234/v1/chat/completions`.
 - Pulsa **Refresh** para cargar todos los modelos expuestos por `/v1/models`; si no hay un modelo configurado se selecciona el primero.
+- Si un modelo ya está cargado, KNX AI conserva la longitud de contexto activa. KNX AI nunca carga un modelo Bionic inactivo mediante la API de gestión: la primera solicitud de chat permite que Bionic lo cargue mediante JIT con los valores predeterminados guardados para el modelo. Independientemente del contexto declarado por Bionic, KNX AI usa el presupuesto de prompt elegido de 4K, 8K o 16K y mantiene disponibles el razonamiento, KNX, las rutinas, las cámaras y TTS.
 - La clave API es opcional salvo que la autenticación esté activada en los ajustes del servidor LM Studio. En Docker, sustituye `localhost` por `host.docker.internal`.
 
 ## Nota de seguridad

package/nodes/locales/es/knxUltimateAI.json

@@ -6,6 +6,7 @@
       "groupChatHome": "Conversaciones y hogar",
       "detectedAdapters": "Adaptadores detectados automáticamente",
       "chatContextOverview": "Resumen del contexto del chat",
+      "chatLearning": "Aprendizaje del chat IA",
       "quickSetup": "Configurar el asistente",
       "llmConnection": "Conexion del Asistente IA",
       "chatAdapter": "Canales de chat",
@@ -21,6 +22,7 @@
       "llmBaseUrl": "Endpoint URL",
       "llmApiKey": "API key",
       "llmModel": "Model",
+      "llmPromptContextTokens": "Cantidad de contexto del chat",
       "llmSystemPrompt": "System prompt",
       "llmIncludeRaw": "Include raw payload hex",
       "llmAllowKnxCommands": "Permitir que la IA lea estados KNX y controle actuadores",
@@ -45,6 +47,11 @@
         "ollama": "Ollama (local)",
         "lmstudio": "Bionic LM Studio"
       },
+      "promptContext": {
+        "small": "Reducido (4K, más rápido)",
+        "medium": "Medio (8K)",
+        "full": "Completo (16K)"
+      },
       "chatAdapter": {
         "none": "Sin adaptador"
       },
@@ -55,10 +62,13 @@
     },
     "messages": {
       "lmStudioContextAvailable": "Contexto máximo del modelo",
-      "lmStudioContextLoading": "Cargando el modelo con su contexto máximo",
-      "lmStudioContextConfigured": "Contexto máximo del modelo configurado",
+      "lmStudioContextLoading": "Comprobando el contexto activo del modelo",
+      "lmStudioContextInactive": "Modelo inactivo; se usarán los valores predeterminados de Bionic en la primera solicitud",
+      "lmStudioContextConfigured": "Contexto activo del modelo",
       "lmStudioContextFailed": "No se pudo configurar el contexto del modelo",
       "lmStudioContextCurrentlyLoaded": "cargado actualmente",
+      "localContextBudget": "Presupuesto de contexto de KNX AI",
+      "promptContextHint": "Controla la cantidad de contexto KNX, memoria, proyecto y adaptadores enviada a los modelos locales. No activa ni desactiva herramientas ni usa enrutamiento por intents.",
       "ollamaNotSupported": "Ollama local mode: API key not required. Default endpoint is http://localhost:11434/api/chat.",
       "ollamaNoModels": "No local Ollama model found. Install one or pick one from the library.",
       "installingOllamaModel": "Starting Ollama and installing model…",
@@ -78,7 +88,16 @@
       "ttsUltimateHint": "Las solicitudes explícitas de anuncio del chat se envían directamente al nodo elegido; no hace falta cableado en el flow.",
       "chatContextLoading": "Cargando el resumen del contexto del chat…",
       "chatContextUnavailable": "El resumen del contexto del chat no está disponible temporalmente.",
+      "chatLearningOpenHint": "Abre la interfaz web directamente en el editor de aprendizaje CHAT compartido para ver, editar, copiar o guardar una copia de su archivo persistente.",
       "chatContextIntro": "El chat recibe automáticamente estas fuentes. Las rutas siguientes son las que usa realmente esta instalación de Node-RED.",
+      "chatContextLimitLabel": "Contexto operativo máximo",
+      "chatContextProviderManaged": "gestionado por el proveedor/modelo seleccionado",
+      "chatContextTokens": "tokens",
+      "chatContextLastPromptLabel": "Tamaño real del último prompt del chat",
+      "chatContextLastPromptUnavailable": "no disponible hasta la primera solicitud del chat",
+      "chatContextExactInputTokens": "tokens de entrada medidos por el proveedor",
+      "chatContextEstimatedInputTokens": "tokens de entrada estimados",
+      "chatContextImages": "imágenes",
       "chatContextSourcesTitle": "Fuentes incluidas",
       "chatContextFilesTitle": "Archivos de contexto persistentes",
       "chatContextDirectoriesTitle": "Archivo de telegramas KNX",
@@ -86,7 +105,7 @@
       "chatContextSourceAdapterHistory": "Historial diario persistente de eventos de los adaptadores detectados, incluidas las detecciones de cámaras.",
       "chatContextSourceEtsProject": "Semántica ETS e inventario completo del proyecto Node-RED.",
       "chatContextSourceMemoryEducation": "Contexto de sesión, Educación IA y memoria doméstica limitada.",
-      "chatContextSourceCamerasDocs": "Cámaras detectadas y fragmentos relevantes de la ayuda, README y ejemplos.",
+      "chatContextSourceCameras": "Cámaras detectadas y sus capacidades disponibles.",
       "chatContextSourceTtsUltimate": "Nodo TTS Ultimate seleccionado para los anuncios.",
       "chatContextSourceBadge": "Fuente",
       "chatContextFileChatContext": "Turnos persistentes, instrucciones y reglas de notificación de cámaras.",
@@ -162,7 +181,8 @@
     "buttons": {
       "installOllamaModel": "2) Install it",
       "ollamaLibrary": "Model library",
-      "downloadOllamaModel": "1) Download model"
+      "downloadOllamaModel": "1) Download model",
+      "openChatLearning": "Abrir aprendizaje del chat IA"
     }
   }
 }