node-red-contrib-knx-ultimate 6.1.1 → 6.2.1

package/nodes/locales/de/knxUltimateAI.html

@@ -1,18 +1,82 @@
 <script type="text/markdown" data-help-name="knxUltimateAI">
 Dieser Node überwacht **alle KNX-Telegramme** des ausgewählten KNX-Ultimate-Gateways, erstellt Verkehrsstatistiken, erkennt Anomalien und kann optional ein LLM befragen.
 
+Der Editor verwendet drei Hauptbereiche als Akkordeon: **KI-Assistent** enthält Einrichtung, Wissen/Kontext und Anbietergrenzen; **Gespräche & Zuhause** enthält Chat-Kanäle, proaktives Zuhause und begrenztes Gedächtnis; **KNX-Verkehrsanalyse** enthält Bus-Telegramme, Verlauf/Zusammenfassungen und Anomalien/Muster. Beim Öffnen eines Hauptbereichs werden alle zugehörigen Optionen gemeinsam angezeigt. Gespeicherte Feld-IDs und Werte bleiben unverändert.
+
 ## Ausgänge
 1. **Zusammenfassung/Statistik** (`msg.payload` JSON)
 2. **Anomalien** (`msg.payload` JSON)
 3. **KI-Assistent** (`msg.payload` Text, mit `msg.summary`)
+4. **KNX-Operationen** (eine Universal-Mode-Nachricht je validierter Lese- oder Schreiboperation)
+
+Jede an den Ausgängen 3 und 4 ausgegebene Nachricht enthält außerdem eine Kopie der ursprünglichen Eingangsnachricht in `msg.inputMessage`. Dadurch bleiben der ursprüngliche Payload, das Topic, die Chat-Metadaten und alle weiteren Eingangseigenschaften für nachfolgende Nodes verfügbar. Fehler beim Klonen oder Ausgeben werden abgefangen und gemeldet, statt in die Node-RED-Laufzeit zu gelangen.
 
 ## Befehle (Eingang)
 Sende `msg.topic`:
 - `summary` (oder leer): Summary sofort senden
-- `reset`: internen Verlauf/Zähler zurücksetzen
+- `reset`: internen Verlauf, Zähler und gelerntes Hausgedächtnis löschen; die KI-Erziehung bleibt unverändert
 - `ask`: Frage an das konfigurierte LLM senden
+- `confirm` / `cancel`: ausstehende KNX-Befehle ohne erneuten LLM-Aufruf bestätigen oder abbrechen
+- `clear_chat`: Gesprächsspeicher der aktuellen Sitzung löschen
+
+Für `ask` die Frage in `msg.prompt` (empfohlen), `msg.payload` (String) oder den üblichen Telegram-Feldern `msg.payload.content` / `msg.payload.text` übergeben.
+
+Bei aktiviertem KNX-Steuern werden die letzten Gesprächsschritte im RAM nach `msg.knxAi.sessionId`, `msg.sessionId` oder erkannter Telegram-Chat-ID getrennt. 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"`.
+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.
+
+### Bestätigungsanfrage für Chat-Schaltflächen
+Solange ein Plan aussteht, enthält Ausgang 3 `msg.knxAi.confirmationRequest`. Das Objekt enthält `required`, `status`, `sessionId`, `expiresAt`, `commandCount` und zwei Einträge in `actions`. Verwenden Sie `action.label` als Text der Telegram-Schaltfläche, `action.callbackData` als Callback und senden Sie `action.message` an KNX AI zurück, um ohne Texteingabe zu bestätigen oder abzubrechen.
+
+### Chat-Adapter-Vorlagen
+Der Tab **Chat-Adapter** lädt seine auswählbaren Zuordnungen aus `resources/KNXAIChatAdapterMappings.js`. Die Auswahl einer Vorlage fügt zwei bearbeitbare synchrone JavaScript-Zuordnungen in Textfeldern über die volle Breite ein: eine vor der Verarbeitung des Eingangs durch KNX AI und eine vor der Ausgabe an Ausgang 3. Geben Sie `msg` zurück, um fortzufahren, oder keinen Wert, um die Nachricht zu verwerfen. 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.
+
+## Proaktive Hausintelligenz und begrenztes Gedächtnis
+Der Unterbereich **Proaktives Zuhause & Gedächtnis** in **Gespräche & Zuhause** aktiviert proaktive Benachrichtigungen auf Wunsch des Benutzers. Aus ETS-Hierarchie, Namen, Rollen und DPTs erstellt der Node ein deterministisches semantisches Modell für Rollläden, Fenster, Türen, Licht, Temperatur, Klima, Anwesenheit und Alarme mit italienischen, englischen, deutschen, französischen, spanischen und chinesischen Begriffen. Der erste proaktive Detektor überwacht nur zuverlässig erkannte Nicht-Befehlszustände von Rollläden/Fenstern/Türen. Nach der konfigurierten Offenzeit und außerhalb der Ruhezeiten gibt Ausgang 3 eine lokalisierte Nachricht mit `msg.knxAi.type = "proactive_notification"` aus. Ausgang 4 wird niemals proaktiv verwendet und KNX wird nicht selbstständig verändert; eine spätere Benutzeranfrage durchläuft weiterhin die normale Validierung und Bestätigung.
+
+Die letzte Chat-Sitzung wird als Eigentümer gespeichert; alternativ kann **Hauptempfänger / Chat-ID** sie ausdrücklich festlegen. Ein synthetisches `msg.inputMessage` bewahrt den Empfänger, damit der Telegram-Adapter eine spontane Nachricht senden kann. Cooldown und höchstens drei proaktive Nachrichten pro Stunde verhindern eine Nachrichtenflut.
+
+Die gelernte Referenz wird beim Start aus `<userDir>/knxai/memory/knxai-home-memory-<node-id>.md` geladen, alle 15 Minuten atomar neu geschrieben und strikt auf konfigurierbare 64–1.024 KB begrenzt (standardmäßig 256 KB). Sie enthält höchstens 120 wichtige Beobachtungen, 80 aggregierte Gewohnheiten, 80 Benachrichtigungen und 300 semantische ETS-Objekte, niemals einen unbegrenzten Rohtelegrammstrom. Alte Einträge mit niedriger Priorität werden zuerst entfernt. **KI-Erziehung** ist auf 16.000 Zeichen begrenzt und stammt immer aus der Node-Konfiguration: Die KI darf sie als verbindliche Vorgabe lesen, aber weder ändern noch überschreiben. Ist eine Erziehung vorhanden, kann das LLM sie aber nicht auswerten, wird die mögliche Benachrichtigung unterdrückt, statt ihr möglicherweise zu widersprechen.
+
+## Praktisches Konfigurationsbeispiel
+Dieses Beispiel erstellt einen knappen Assistenten, der wichtige Öffnungen meldet, aber akzeptiert, dass der Rollladen im Büro offen bleiben darf:
+
+| Editor-Feld | Beispielwert | Wirkung |
+|---|---|---|
+| **Proaktive Hausbenachrichtigungen aktivieren** (`proactiveEnabled`) | aktiv | Zuverlässig erkannte offene Rollladen-/Fenster-/Türzustände werden bewertet. |
+| **Hauptempfänger / Chat-ID** (`proactiveRecipient`) | `123456789` | Spontane Nachrichten gehen an diesen Chat; leer bedeutet: letzte Ask-Sitzung merken. |
+| **Nach offener Dauer benachrichtigen** (`proactiveOpenMinutes`) | `120` | Nach zwei Stunden wird eine mögliche Meldung bewertet. |
+| **Ruhezeit Beginn / Ende** | `23:00` / `07:00` | Nachts werden keine proaktiven Nachrichten ausgegeben. |
+| **Wiederholungs-Cooldown** (`proactiveCooldownMinutes`) | `360` | Dasselbe Objekt meldet sich sechs Stunden lang nicht erneut. |
+| **Maximale Hausgedächtnis-Datei** (`homeMemoryMaxKb`) | `256` | Die Markdown-Referenz dieses Nodes bleibt unter 256 KB. |
+
+Beispiel für **KI-Erziehung** (`aiEducation`):
+
+```text
+Nenne mich Alex und antworte in derselben Sprache wie ich.
+Antworte kurz, außer ich bitte um technische Einzelheiten.
+Der Büro-Rollladen darf tagsüber offen bleiben: benachrichtige mich nicht.
+Melde andere Rollläden, Fenster oder Türen, die ungewöhnlich lange offen bleiben.
+Wenn „Wohnzimmerlicht“ mehrdeutig ist, frage nach der gemeinten Leuchte.
+Behaupte nie eine Aktoränderung, bevor ein KNX-Statusobjekt sie bestätigt.
+```
+
+Damit kann Ausgang 3 nach 120 Minuten eine lokalisierte `proactive_notification` für den Wohnzimmer-Rollladen ausgeben, während eine Meldung für den Büro-Rollladen durch die Erziehung unterdrückt wird. Bittet Alex danach um das Schließen, erstellt KNX AI den exakten ETS-Befehl, behält aber Validierung und Bestätigung vor Ausgang 4 bei.
+
+Verwenden Sie aussagekräftige ETS-Hierarchien und Objektnamen sowie korrekte Status-/Befehlsrollen. Die Erziehung personalisiert Entscheidungen und Formulierungen, kann aber keine Gruppenadresse erfinden, keinen DPT ändern und die KNX-Validierung nicht umgehen.
 
-Für `ask` die Frage in `msg.prompt` (empfohlen) oder `msg.payload` (String) übergeben.
+## Kurzer Ablauf: KNX-Steuerung
+1. Importieren Sie die ETS-CSV in das Gateway und konfigurieren Sie LLM-Anbieter, Modell und Zugangsdaten.
+2. Aktivieren Sie **LLM-Assistent** und **KNX-Zustände lesen und Aktoren steuern**; lassen Sie die Bestätigung aktiviert.
+3. Verbinden Sie den Chat-Eingang mit KNX AI und behalten Sie eine stabile Sitzungs-/Chat-ID bei.
+4. Verbinden Sie Ausgang 3 mit der Chat-Antwort und Ausgang 4 mit KNX Ultimate im **Universalmodus**.
+5. Der Benutzer sendet eine Anfrage; aktuelle Zustandsabfragen werden sofort gelesen, während Schreiboperationen zuerst GA, DPT und Wert ohne Bus-Schreibzugriff anzeigen.
+6. Innerhalb von 5 Minuten antwortet derselbe Chat exakt mit `BESTÄTIGEN` oder `ABBRECHEN`.
+7. Nur `BESTÄTIGEN` validiert erneut und gibt Befehle an Ausgang 4 aus; prüfen Sie die Ausführung über eine KNX-Status-GA.
 
 ## Konfigurationsfelder
 Hier sind alle Felder aufgeführt, wie sie im KNX-AI-Editor sichtbar sind.
@@ -53,7 +117,20 @@ Hier sind alle Felder aufgeführt, wie sie im KNX-AI-Editor sichtbar sind.
 - **Endpoint URL**: URL des Chat/Completions-Endpunkts.
 - **API key**: API-Schlüssel (für lokales Ollama nicht erforderlich).
 - **Model**: Modell-ID/Name.
+- **Chatmodell-Kompatibilität**: Das ausgewählte Modell muss den konfigurierten Chat-Completions-Endpunkt unterstützen. Ältere reine Completions-Modelle wie `gpt-3.5-turbo-instruct` werden beim Aktualisieren der Modellliste ausgeschlossen. Lehnt der Anbieter einen benutzerdefinierten Temperaturwert oder den Token-Limit-Parameter ab, wiederholt KNX AI die Anfrage und entfernt oder ersetzt nur das inkompatible Feld.
 - **System prompt**: Globale Instruktion für KNX-Analyse (Advanced).
+- **KI darf KNX-Zustände lesen und Aktoren steuern**: Aktiviert Ausgang 4 und ist standardmäßig aus. Exakte ETS-Katalogobjekte dürfen gelesen werden; Schreiboperationen werden ausschließlich für Objekte mit Rolle `command` akzeptiert. Unbekannte, DPT-falsche, ungültige oder überzählige Operationen sowie Schreiboperationen auf Status-/Neutralobjekte werden lokal abgewiesen.
+- **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**: Lädt ein Paar aus Ein- und Ausgangszuordnung aus der mitgelieferten Chat-Adapter-Datei. Die Auswahl ersetzt bewusst beide Textfelder; der Code bleibt danach bearbeitbar.
+- **Eingangszuordnung (Chat → KNX AI)**: Synchrones JavaScript vor der Verarbeitung des Eingangsbefehls.
+- **Ausgangszuordnung (KNX AI → Chat)**: Synchrones JavaScript ausschließlich für Nachrichten an Ausgang 3.
+- **Proaktive Hausbenachrichtigungen aktivieren**: Optionaler Detektor für zuverlässig erkannte offene Rollladen-/Fenster-/Türzustände; er schreibt nie selbstständig auf KNX.
+- **Hauptempfänger / Chat-ID**: Optionales Ziel für unaufgeforderte Chatnachrichten; andernfalls wird die letzte Ask-Sitzung gespeichert.
+- **Nach offener Dauer benachrichtigen (Minuten)**: Schwelle, bevor eine proaktive Nachricht erwogen wird.
+- **Ruhezeit Beginn / Ende**: Täglicher Zeitraum, in dem proaktive Nachrichten unterdrückt werden.
+- **KI-Erziehung**: Verbindliche, ausschließlich vom Benutzer verwaltete Hinweise, die die KI lesen, aber nie ändern darf.
+- **Wiederholungs-Cooldown (Minuten)**: Mindestintervall vor einer weiteren Meldung desselben Objekts.
+- **Maximale Hausgedächtnis-Datei (KB)**: Harte Grenze von 64 bis 1.024 KB; standardmäßig 256 KB.
 - Wenn das Festplattenarchiv aktiv ist, nutzt **Ask** standardmäßig dieses Archiv: explizite Datumsangaben/Zeitbereiche werden beachtet, sonst durchsucht der Assistent die letzten 24 Stunden plus aktuelle RAM-Events.
 - **Include raw payload hex**: Rohe Hex-Payload im Prompt einfügen.
 - **Node-RED-Projektinventar einbeziehen**: Nimmt das gesamte Node-RED-Projektinventar in den Prompt auf, einschließlich KNX-Nodes und anderer hilfreicher Nodes wie function/change/inject/template, wenn sie KNX-Logik oder Gruppenadressen enthalten.
@@ -84,5 +161,5 @@ Hier sind alle Felder aufgeführt, wie sie im KNX-AI-Editor sichtbar sind.
 - Wenn Node-RED in Docker läuft, im Endpoint `host.docker.internal` statt `localhost` verwenden.
 
 ## Sicherheitshinweis
-Bei aktiviertem LLM kann KNX-Traffic-Kontext an den konfigurierten Endpoint gesendet werden. Für striktes On-Premise lokale Provider verwenden.
+Bei aktiviertem LLM kann KNX-Traffic-Kontext an den konfigurierten Endpoint gesendet werden. Für striktes On-Premise lokale Provider verwenden. Ein Befehl an Ausgang 4 hat die lokale Validierung bestanden und wurde an den Flow weitergegeben; dies bestätigt nicht die Ausführung durch den Aktor. Dafür eine KNX-Status-GA verwenden.
 </script>

package/nodes/locales/de/knxUltimateAI.json

@@ -2,12 +2,19 @@
   "knxUltimateAI": {
     "title": "KNX AI (Traffic Analyzer)",
     "sections": {
-      "capture": "Capture",
-      "storage": "Speicher & Zusammenfassung",
-      "detection": "Erkennung & Warnungen",
+      "groupAssistant": "KI-Assistent",
+      "groupChatHome": "Gespräche & Zuhause",
+      "groupKnxAnalysis": "KNX-Verkehrsanalyse",
+      "quickSetup": "Assistent einrichten",
+      "capture": "Bus-Telegrammeingang",
+      "storage": "KNX-Verlauf & Zusammenfassungen",
+      "detection": "Anomalien & Muster",
       "llmConnection": "KI-Assistent-Verbindung",
-      "llmContext": "KI-Assistent-Kontext",
-      "advanced": "Erweiterte Einstellungen"
+      "llmContext": "KI-Wissen & Kontext",
+      "chatAdapter": "Chat-Kanäle",
+      "homeIntelligence": "Proaktives Zuhause & Gedächtnis",
+      "homeIntelligenceAdvanced": "Erweiterte proaktive Einstellungen",
+      "advanced": "Anbieter & Grenzen"
     },
     "properties": {
       "server": "Gateway",
@@ -39,26 +46,45 @@
       "llmSystemPrompt": "System prompt",
       "llmIncludeRaw": "Include raw payload hex",
       "llmIncludeFlowContext": "Node-RED-Projektinventar einbeziehen",
+      "llmAllowKnxCommands": "KI darf KNX-Zustände lesen und Aktoren steuern",
+      "llmRequireCommandConfirmation": "Vor dem Senden von KNX-Befehlen bestätigen lassen",
+      "chatAdapterPreset": "Adapter-Vorlage",
+      "chatInputCode": "Eingangszuordnung (Chat → KNX AI)",
+      "chatOutputCode": "Ausgangszuordnung (KNX AI → Chat)",
+      "proactiveEnabled": "Proaktive Hausbenachrichtigungen aktivieren",
+      "proactiveRecipient": "Hauptempfänger / Chat-ID",
+      "proactiveOpenMinutes": "Nach Offenstand benachrichtigen (Minuten)",
+      "proactiveCooldownMinutes": "Wiederholsperre (Minuten)",
+      "proactiveQuietStart": "Beginn der Ruhezeit",
+      "proactiveQuietEnd": "Ende der Ruhezeit",
+      "homeMemoryMaxKb": "Maximale Hausgedächtnisdatei (KB)",
+      "aiEducation": "KI-Erziehung (vom Benutzer verwaltet)",
       "llmIncludeDocsSnippets": "Include documentation snippets (help/README/examples)",
       "llmDocsLanguage": "Docs language"
     },
     "outputs": {
       "summary": "Zusammenfassung/Statistik",
       "anomalies": "Anomalien",
-      "assistant": "KI-Assistent"
+      "assistant": "KI-Assistent",
+      "knxCommands": "KNX-Operationen"
     },
     "selectlists": {
       "llmProvider": {
         "openai_compat": "OpenAI-compatible (chat/completions)",
         "anthropic": "Anthropic (Claude)",
         "ollama": "Ollama (local, beta)"
+      },
+      "chatAdapter": {
+        "none": "Kein Adapter"
       }
     },
     "placeholder": {
       "llmBaseUrl": "https://api.openai.com/v1/chat/completions (or your compatible endpoint)",
       "llmApiKey": "Paste API key (starts with sk-)",
       "llmModel": "e.g. gpt-4o-mini",
-      "llmSystemPrompt": "Optional. Leave empty for default."
+      "llmSystemPrompt": "Optional. Leave empty for default.",
+      "proactiveRecipient": "Optional: Telegram-Chat-ID; andernfalls wird die letzte Chat-Sitzung gespeichert",
+      "aiEducation": "Beispiel: Zwischen 23:00 und 07:00 nicht benachrichtigen. Der Rollladen im Büro darf nachts offen bleiben."
     },
     "messages": {
       "ollamaNotSupported": "Ollama local mode: API key not required. Default endpoint is http://localhost:11434/api/chat.",
@@ -67,7 +93,12 @@
       "installedOllamaModel": "Ollama model installed",
       "installOllamaModelFailed": "Failed to install Ollama model",
       "ollamaInstallSteps": "1) Open the model library and copy the model name (for example llama3.1). 2) Put the name in the Model field and click Install it.",
-      "ollamaStartedAuto": "Ollama server started automatically."
+      "ollamaStartedAuto": "Ollama server started automatically.",
+      "chatAdapterIntro": "Wählen Sie eine Vorlage, um den Code für Ein- und Ausgang einzufügen. Die Liste wird aus der mitgelieferten Chat-Adapter-Datei geladen; der erzeugte Code bleibt bearbeitbar.",
+      "chatAdapterCodeHelp": "Zuordnungen laufen synchron. Geben Sie msg zurück, um fortzufahren, oder keinen Wert, um die Nachricht zu verwerfen. Fehler werden abgefangen und gemeldet, ohne Node-RED anzuhalten.",
+      "homeIntelligenceIntro": "Der Node erstellt ein mehrsprachiges semantisches ETS-Modell und kann den Chat benachrichtigen, wenn ein zuverlässig erkannter Rollladen, ein Fenster oder eine Tür offen bleibt. Er sendet niemals selbstständig einen KNX-Befehl.",
+      "aiEducationHelp": "Nur der Benutzer kann diesen Abschnitt bearbeiten. Die KI liest ihn als verbindliche Vorgabe; gelernte Erinnerungen können ihn niemals überschreiben. Maximal 16.000 Zeichen.",
+      "homeMemoryLimitHelp": "Das Markdown-Gedächtnis wird alle 15 Minuten atomar neu geschrieben und bleibt stets auf 64 bis 1.024 KB begrenzt. Alte Beobachtungen werden vor Gewohnheiten und semantischen Objekten entfernt."
     },
     "sidebar": {
       "ui": {

package/nodes/locales/en/knxUltimateAI.html

@@ -1,18 +1,86 @@
 <script type="text/markdown" data-help-name="knxUltimateAI">
 This node listens to **all KNX telegrams** from the selected KNX Ultimate gateway, builds traffic statistics, detects anomalies, and can optionally query an LLM.
 
+The editor uses three main accordion sections: **AI assistant** contains setup, knowledge/context and provider limits; **Conversations & home** contains chat channels, proactive home and bounded memory; **KNX traffic analysis** contains bus telegram input, history/summaries and anomalies/patterns. Opening a main section shows all of its related options together. Saved field IDs and values remain unchanged.
+
 ## Outputs
 1. **Summary/Stats** (`msg.payload` JSON)
 2. **Anomalies** (`msg.payload` JSON)
 3. **AI Assistant** (`msg.payload` text, with `msg.summary`)
+4. **KNX operations** (one Universal Mode message per validated read or write)
+
+Every message emitted by outputs 3 and 4 also contains a clone of the original input message in `msg.inputMessage`. This preserves the original payload, topic, chat metadata, and any other input properties for downstream nodes. Cloning and output errors are contained and reported instead of escaping into the Node-RED runtime.
 
 ## Commands (input)
 Send `msg.topic`:
 - `summary` (or empty): emit summary immediately
-- `reset`: clear internal history/counters
+- `reset`: clear internal history, counters and learned home memory; AI Education remains unchanged
 - `ask`: send a question to the configured LLM
+- `confirm` / `cancel`: confirm or cancel pending KNX commands without calling the LLM
+- `clear_chat`: clear the conversation memory for the current session
+
+For `ask`, provide the question in `msg.prompt` (preferred), `msg.payload` (string), or the common Telegram fields `msg.payload.content` / `msg.payload.text`.
+
+When KNX control is enabled, recent turns are remembered in RAM per `msg.knxAi.sessionId`, `msg.sessionId`, or a detected Telegram chat ID. 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"`.
+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.
+
+### Confirmation request for chat buttons
+While a plan is pending, output 3 contains `msg.knxAi.confirmationRequest`. The object includes `required`, `status`, `sessionId`, `expiresAt`, `commandCount`, and two entries in `actions`. Use `action.label` as the Telegram button text, `action.callbackData` as its callback, and send `action.message` back to KNX AI to confirm or cancel without typed text.
+
+### Chat adapter presets
+The **Chat adapters** tab loads its selectable mappings from `resources/KNXAIChatAdapterMappings.js`. Selecting a preset inserts two editable synchronous JavaScript mappings in full-width text boxes: one before KNX AI processes an input and one before output 3 is emitted. Return `msg` to continue or no value to discard the message. 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.
+
+## Proactive home intelligence and bounded memory
+The **Proactive home & memory** subsection inside **Conversations & home** enables opt-in proactive notifications. 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. The first proactive detector watches only reliably recognized non-command cover/window/door states. After the configured open duration and outside quiet hours, output 3 emits a localized message with `msg.knxAi.type = "proactive_notification"`. It never emits output 4 or changes KNX autonomously; a subsequent user request still uses the normal validation and confirmation workflow.
+
+The most recent chat session is remembered as the owner, or **Primary recipient / chat ID** can set it explicitly. A synthetic `msg.inputMessage` preserves this recipient so the Telegram adapter can send an unsolicited notification. Cooldown and a maximum of three proactive messages per hour prevent flooding.
+
+The learned reference is loaded at startup from `<userDir>/knxai/memory/knxai-home-memory-<node-id>.md`, rewritten atomically every 15 minutes and hard-capped to the configured 64–1,024 KB (256 KB by default). It stores at most 120 significant observations, 80 aggregate habits, 80 notifications and 300 semantic ETS objects—never a raw unlimited telegram stream. Older low-priority entries are removed first. **AI Education** is limited to 16,000 characters and always comes from the node configuration: the AI can read it as authoritative guidance but cannot modify or overwrite it. When Education is present but the LLM cannot evaluate it, the candidate notification is suppressed rather than risking a contradiction.
+
+## Practical configuration example
+This example creates a concise assistant that notifies the owner about relevant openings but accepts that the office cover may stay open:
+
+| Editor field | Example value | Result |
+|---|---|---|
+| **Enable proactive home notifications** (`proactiveEnabled`) | enabled | The node evaluates reliably recognized open cover/window/door states. |
+| **Primary recipient / chat ID** (`proactiveRecipient`) | `123456789` | Unsolicited messages go to this chat. Leave it empty to remember the most recent Ask session. |
+| **Notify after open** (`proactiveOpenMinutes`) | `120` | A candidate notification is considered after two hours. |
+| **Quiet hours start / end** | `23:00` / `07:00` | No proactive message is emitted during the night. |
+| **Repeat cooldown** (`proactiveCooldownMinutes`) | `360` | The same object cannot notify again for six hours. |
+| **Maximum home-memory file** (`homeMemoryMaxKb`) | `256` | The per-node Markdown reference can never exceed 256 KB. |
+
+Example for **AI Education** (`aiEducation`):
+
+```text
+Call me Alex and answer in the same language I use.
+Keep replies short unless I ask for technical details.
+The office cover may remain open during the day: do not notify me about it.
+Notify me when another cover, window, or door remains open unusually long.
+When "living-room light" is ambiguous, ask which light I mean.
+Never say that an actuator changed until a KNX status object confirms it.
+```
+
+With these settings:
+
+1. If the living-room cover status remains open for 120 minutes outside quiet hours, output 3 can emit a localized `proactive_notification`.
+2. If the office cover remains open, the LLM reads Education and suppresses that candidate notification.
+3. If Alex later asks to close the living-room cover, KNX AI prepares the exact ETS command and still follows normal validation and confirmation before output 4.
+
+Use descriptive ETS hierarchy/object names and correct status/command roles. Education can personalize decisions and wording, but it cannot authorize an invented group address, change a DPT, or bypass KNX validation.
 
-For `ask`, provide the question in `msg.prompt` (preferred) or `msg.payload` (string).
+## Quick workflow: KNX control
+1. Import the ETS CSV into the gateway and configure the LLM provider, model, and credentials.
+2. Enable **LLM assistant** and **KNX state reads and actuator control**; leave confirmation enabled.
+3. Connect the chat input to KNX AI while preserving a stable session/chat ID.
+4. Connect output 3 to the chat reply and output 4 to KNX Ultimate in **Universal mode**.
+5. The user sends a request; fresh state requests are read immediately, while writes first show the proposed GA, DPT, and value without writing to the bus.
+6. Within 5 minutes, the same chat replies exactly `CONFIRM` or `CANCEL`.
+7. Only `CONFIRM` revalidates and emits commands on output 4; verify execution through a KNX status GA.
 
 ## Configuration fields
 All fields exposed in the KNX AI editor are listed below.
@@ -53,7 +121,20 @@ All fields exposed in the KNX AI editor are listed below.
 - **Endpoint URL**: Chat/completions endpoint URL.
 - **API key**: API key (not required for local Ollama).
 - **Model**: Model ID/name.
+- **Chat model compatibility**: The selected model must support the configured Chat Completions endpoint. Legacy completion-only models such as `gpt-3.5-turbo-instruct` are excluded when the model list is refreshed. If the provider rejects a custom temperature or token-limit parameter, KNX AI retries after removing or replacing only that incompatible field.
 - **System prompt**: Global instruction for KNX analysis behavior (Advanced).
+- **Allow AI to read KNX states and control actuators**: Enables output 4 and is off by default. Exact ETS catalog objects may be read; writes are accepted only for objects classified as `command`. Unknown, DPT-mismatched, invalid, or excessive operations and writes to status/neutral objects are rejected locally.
+- **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**: Loads an input/output mapping pair from the packaged chat-adapter file. Selecting a preset intentionally replaces both mapping text boxes; they remain editable afterwards.
+- **Input mapping (chat → KNX AI)**: Synchronous JavaScript applied before input command processing.
+- **Output mapping (KNX AI → chat)**: Synchronous JavaScript applied only to messages on output 3.
+- **Enable proactive home notifications**: Opt-in detector for reliably recognized open cover/window/door states; it never writes autonomously to KNX.
+- **Primary recipient / chat ID**: Optional destination for unsolicited chat messages; otherwise the most recent Ask session is remembered.
+- **Notify after open (minutes)**: Open-duration threshold before a proactive notification can be considered.
+- **Quiet hours start / end**: Daily interval in which proactive messages are suppressed.
+- **AI Education**: User-only, authoritative guidance read by the AI and never modified by it.
+- **Repeat cooldown (minutes)**: Minimum interval before the same object may notify again.
+- **Maximum home-memory file (KB)**: Hard size limit from 64 to 1,024 KB; 256 KB by default.
 - If disk archive is enabled, **Ask** uses the archive by default: explicit dates/ranges are honored, otherwise the assistant searches the last 24 hours plus current RAM events.
 - **Include raw payload hex**: Include raw telegram hex in prompt.
 - **Include Node-RED project inventory**: Include the whole Node-RED project inventory in the prompt, including KNX nodes and other useful nodes such as function/change/inject/template when they contain KNX-related logic or group addresses.
@@ -84,5 +165,5 @@ All fields exposed in the KNX AI editor are listed below.
 - If Node-RED runs in Docker, use `host.docker.internal` instead of `localhost` in the endpoint URL.
 
 ## Security note
-If LLM is enabled, KNX traffic context can be sent to the configured endpoint. Use local providers if you need strict on-prem data handling.
+If LLM is enabled, KNX traffic context can be sent to the configured endpoint. Use local providers if you need strict on-prem data handling. A command emitted on output 4 passed local validation and was forwarded to the flow; it is not proof that the actuator executed it. Use a KNX status GA when confirmation is required.
 </script>

package/nodes/locales/en/knxUltimateAI.json

@@ -2,12 +2,19 @@
   "knxUltimateAI": {
     "title": "KNX AI (Traffic Analyzer)",
     "sections": {
-      "capture": "Capture",
-      "storage": "Storage & Summary",
-      "detection": "Detection & Alerts",
+      "groupAssistant": "AI assistant",
+      "groupChatHome": "Conversations & home",
+      "groupKnxAnalysis": "KNX traffic analysis",
+      "quickSetup": "Assistant setup",
+      "capture": "Bus telegram input",
+      "storage": "KNX history & summaries",
+      "detection": "Anomalies & patterns",
       "llmConnection": "AI Assistant Connection",
-      "llmContext": "AI Assistant Context",
-      "advanced": "Advanced Tuning"
+      "llmContext": "AI knowledge & context",
+      "chatAdapter": "Chat channels",
+      "homeIntelligence": "Proactive home & memory",
+      "homeIntelligenceAdvanced": "Advanced proactive settings",
+      "advanced": "Provider & limits"
     },
     "properties": {
       "server": "Gateway",
@@ -39,19 +46,36 @@
       "llmSystemPrompt": "System prompt",
       "llmIncludeRaw": "Include raw payload hex",
       "llmIncludeFlowContext": "Include Node-RED project inventory",
+      "llmAllowKnxCommands": "Allow AI to read KNX states and control actuators",
+      "llmRequireCommandConfirmation": "Ask for confirmation before sending KNX commands",
+      "chatAdapterPreset": "Adapter preset",
+      "chatInputCode": "Input mapping (chat → KNX AI)",
+      "chatOutputCode": "Output mapping (KNX AI → chat)",
+      "proactiveEnabled": "Enable proactive home notifications",
+      "proactiveRecipient": "Primary recipient / chat ID",
+      "proactiveOpenMinutes": "Notify after open (minutes)",
+      "proactiveCooldownMinutes": "Repeat cooldown (minutes)",
+      "proactiveQuietStart": "Quiet hours start",
+      "proactiveQuietEnd": "Quiet hours end",
+      "homeMemoryMaxKb": "Maximum home-memory file (KB)",
+      "aiEducation": "AI Education (user managed)",
       "llmIncludeDocsSnippets": "Include documentation snippets (help/README/examples)",
       "llmDocsLanguage": "Docs language"
     },
     "outputs": {
       "summary": "Summary/Stats",
       "anomalies": "Anomalies",
-      "assistant": "AI Assistant"
+      "assistant": "AI Assistant",
+      "knxCommands": "KNX operations"
     },
     "selectlists": {
       "llmProvider": {
         "openai_compat": "OpenAI-compatible (chat/completions)",
         "anthropic": "Anthropic (Claude)",
         "ollama": "Ollama (local, beta)"
+      },
+      "chatAdapter": {
+        "none": "No adapter"
       }
     },
     "buttons": {
@@ -69,13 +93,20 @@
       "installedOllamaModel": "Ollama model installed",
       "installOllamaModelFailed": "Failed to install Ollama model",
       "ollamaInstallSteps": "1) Open the model library and copy the model name (for example llama3.1). 2) Put the name in the Model field and click Install it.",
-      "ollamaStartedAuto": "Ollama server started automatically."
+      "ollamaStartedAuto": "Ollama server started automatically.",
+      "chatAdapterIntro": "Choose a mapping preset to insert its input and output code. The list is loaded from the packaged chat-adapter mappings file; the generated code remains editable.",
+      "chatAdapterCodeHelp": "Mappings run synchronously. Return msg to continue or return no value to discard it. Errors are caught and reported without stopping Node-RED.",
+      "homeIntelligenceIntro": "The node builds a multilingual semantic ETS model and can notify the chat when a reliably recognized cover, window, or door remains open. It never sends a KNX command proactively.",
+      "aiEducationHelp": "Only the user can edit this section. The AI reads it as authoritative guidance, but learned-memory updates can never overwrite it. Maximum 16,000 characters.",
+      "homeMemoryLimitHelp": "The Markdown memory is rewritten atomically every 15 minutes and is always capped between 64 and 1,024 KB. Old observations are pruned before habits and semantic objects."
     },
     "placeholder": {
       "llmBaseUrl": "https://api.openai.com/v1/chat/completions (or your compatible endpoint)",
       "llmApiKey": "Paste API key (starts with sk-)",
       "llmModel": "e.g. gpt-4o-mini",
-      "llmSystemPrompt": "Optional. Leave empty for default."
+      "llmSystemPrompt": "Optional. Leave empty for default.",
+      "proactiveRecipient": "Optional: Telegram chat ID; otherwise the most recent chat session is remembered",
+      "aiEducation": "Example: Do not notify me between 23:00 and 07:00. The office shutter may remain open at night."
     },
     "sidebar": {
       "ui": {

package/nodes/locales/es/knxUltimateAI.html

@@ -1,18 +1,82 @@
 <script type="text/markdown" data-help-name="knxUltimateAI">
 Este nodo escucha **todos los telegramas KNX** del gateway KNX Ultimate seleccionado, genera estadísticas de tráfico, detecta anomalías y puede consultar opcionalmente un LLM.
 
+El editor utiliza tres secciones principales en acordeón: **Asistente IA** contiene configuración, conocimiento/contexto y límites del proveedor; **Conversaciones y hogar** contiene canales de chat, hogar proactivo y memoria limitada; **Análisis del tráfico KNX** contiene telegramas del bus, historial/resúmenes y anomalías/patrones. Al abrir una sección principal se muestran juntas todas sus opciones. Los ID y valores guardados permanecen intactos.
+
 ## Salidas
 1. **Resumen/Estadísticas** (`msg.payload` JSON)
 2. **Anomalías** (`msg.payload` JSON)
 3. **Asistente IA** (`msg.payload` texto, con `msg.summary`)
+4. **Operaciones KNX** (un mensaje Universal Mode por cada lectura o escritura validada)
+
+Cada mensaje emitido por las salidas 3 y 4 también contiene una copia del mensaje de entrada original en `msg.inputMessage`. Así, el payload, el topic, los metadatos del chat y cualquier otra propiedad de entrada permanecen disponibles para los nodos posteriores. Los errores de clonación o envío se interceptan y notifican sin propagarse al runtime de Node-RED.
 
 ## Comandos (entrada)
 Envía `msg.topic`:
 - `summary` (o vacío): emite el resumen inmediatamente
-- `reset`: limpia historial y contadores internos
+- `reset`: borra el historial, los contadores y la memoria del hogar aprendida; la Educación de la IA permanece sin cambios
 - `ask`: envía una pregunta al LLM configurado
+- `confirm` / `cancel`: confirma o cancela los comandos KNX pendientes sin volver a llamar al LLM
+- `clear_chat`: borra la memoria de conversación de la sesión actual
+
+Para `ask`, envía la pregunta en `msg.prompt` (recomendado), `msg.payload` (string), o los campos comunes de Telegram `msg.payload.content` / `msg.payload.text`.
+
+Cuando el control KNX está habilitado, los turnos recientes se guardan en RAM por `msg.knxAi.sessionId`, `msg.sessionId` o el ID de chat Telegram detectado. 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"`.
+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.
+
+### Solicitud de confirmación para botones de chat
+Mientras un plan está pendiente, la salida 3 contiene `msg.knxAi.confirmationRequest`. El objeto incluye `required`, `status`, `sessionId`, `expiresAt`, `commandCount` y dos elementos en `actions`. Usa `action.label` como texto del botón de Telegram, `action.callbackData` como callback y devuelve `action.message` a KNX AI para confirmar o cancelar sin escribir texto.
+
+### Preajustes del adaptador de chat
+La pestaña **Adaptadores de chat** carga sus mapeos seleccionables desde `resources/KNXAIChatAdapterMappings.js`. Al elegir un preajuste se insertan dos mapeos JavaScript síncronos y editables en cuadros de texto de ancho completo: uno antes de que KNX AI procese la entrada y otro antes de emitir por la salida 3. Devuelve `msg` para continuar o ningún valor para descartar el mensaje. 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.
+
+## Inteligencia doméstica proactiva y memoria limitada
+La subsección **Hogar proactivo y memoria** dentro de **Conversaciones y hogar** activa las notificaciones proactivas de forma opcional. A partir de la jerarquía ETS, nombres, roles y DPT, el nodo crea un modelo semántico determinista para persianas, ventanas, puertas, luces, temperatura, clima, presencia y alarmas usando términos italianos, ingleses, alemanes, franceses, españoles y chinos. El primer detector proactivo vigila únicamente estados que no sean de comando de persianas/ventanas/puertas reconocidos con suficiente fiabilidad. Tras el tiempo abierto configurado y fuera de las horas silenciosas, la salida 3 emite un mensaje localizado con `msg.knxAi.type = "proactive_notification"`. Nunca emite por la salida 4 ni modifica KNX de manera autónoma; una solicitud posterior del usuario sigue pasando por la validación y confirmación normales.
+
+La última sesión de chat se recuerda como propietario, o **Destinatario principal / ID de chat** permite definirla explícitamente. Un `msg.inputMessage` sintético conserva el destinatario para que el adaptador de Telegram pueda enviar una notificación espontánea. El tiempo de espera y el máximo de tres notificaciones proactivas por hora evitan inundar el chat.
+
+La referencia aprendida se carga al arrancar desde `<userDir>/knxai/memory/knxai-home-memory-<node-id>.md`, se reescribe atómicamente cada 15 minutos y queda estrictamente limitada entre 64 y 1.024 KB configurables (256 KB de forma predeterminada). Conserva como máximo 120 observaciones importantes, 80 hábitos agregados, 80 notificaciones y 300 objetos ETS semánticos, nunca un flujo ilimitado de telegramas raw. Los elementos antiguos y de menor prioridad se eliminan primero. **Educación IA** está limitada a 16.000 caracteres y siempre procede de la configuración del nodo: la IA puede leerla como instrucción autoritativa, pero no modificarla ni sobrescribirla. Si existe Educación pero el LLM no puede evaluarla, la notificación candidata se suprime en lugar de arriesgarse a contradecirla.
+
+## Ejemplo práctico de configuración
+Este ejemplo crea un asistente conciso que avisa sobre aperturas importantes, pero acepta que la persiana del despacho permanezca abierta:
+
+| Campo del editor | Valor de ejemplo | Resultado |
+|---|---|---|
+| **Activar notificaciones proactivas del hogar** (`proactiveEnabled`) | activado | El nodo evalúa estados abiertos fiables de persianas, ventanas y puertas. |
+| **Destinatario principal / ID de chat** (`proactiveRecipient`) | `123456789` | Los mensajes espontáneos van a este chat; déjalo vacío para recordar la última sesión Ask. |
+| **Avisar después de abierta** (`proactiveOpenMinutes`) | `120` | Se evalúa una posible notificación después de dos horas. |
+| **Inicio / fin de horas silenciosas** | `23:00` / `07:00` | No se emiten mensajes proactivos durante la noche. |
+| **Tiempo de espera de repetición** (`proactiveCooldownMinutes`) | `360` | El mismo objeto no vuelve a avisar durante seis horas. |
+| **Archivo máximo de memoria del hogar** (`homeMemoryMaxKb`) | `256` | La referencia Markdown de este nodo permanece por debajo de 256 KB. |
+
+Ejemplo para **Educación IA** (`aiEducation`):
+
+```text
+Llámame Alex y responde en el mismo idioma que uso.
+Responde brevemente, salvo que pida detalles técnicos.
+La persiana del despacho puede permanecer abierta durante el día: no me avises.
+Avísame si otra persiana, ventana o puerta permanece abierta demasiado tiempo.
+Si «luz del salón» es ambiguo, pregúntame a qué luz me refiero.
+Nunca afirmes que un actuador cambió hasta que lo confirme un objeto de estado KNX.
+```
+
+Con estos ajustes, la salida 3 puede emitir una `proactive_notification` localizada después de 120 minutos para la persiana del salón, mientras que Educación suprime el aviso de la persiana del despacho. Si Alex pide después cerrar la persiana del salón, KNX AI prepara el comando ETS exacto, pero mantiene la validación y confirmación normales antes de la salida 4.
+
+Usa jerarquías y nombres de objetos ETS descriptivos, con roles de estado/comando correctos. Educación personaliza decisiones y texto, pero no puede inventar una dirección de grupo, cambiar un DPT ni evitar la validación KNX.
 
-Para `ask`, envía la pregunta en `msg.prompt` (recomendado) o `msg.payload` (string).
+## Flujo rápido: control KNX
+1. Importa el CSV de ETS en el gateway y configura el proveedor, el modelo y las credenciales LLM.
+2. Activa **Asistente LLM** y **lectura de estados KNX y control de actuadores**; deja activada la confirmación.
+3. Conecta la entrada del chat a KNX AI manteniendo un ID de sesión/chat estable.
+4. Conecta la salida 3 a la respuesta del chat y la salida 4 a KNX Ultimate en **modo universal**.
+5. El usuario envía una solicitud; los estados actuales se leen inmediatamente, mientras que las escrituras muestran primero GA, DPT y valor sin escribir en el bus.
+6. En un plazo de 5 minutos, el mismo chat responde exactamente `CONFIRMAR` o `CANCELAR`.
+7. Solo `CONFIRMAR` vuelve a validar y emite los comandos por la salida 4; verifica la ejecución mediante una GA de estado KNX.
 
 ## Campos de configuración
 Aquí tienes todos los campos tal como se muestran en el editor de KNX AI.
@@ -53,7 +117,20 @@ Aquí tienes todos los campos tal como se muestran en el editor de KNX AI.
 - **Endpoint URL**: URL endpoint chat/completions.
 - **API key**: clave API (no requerida con Ollama local).
 - **Model**: ID/nombre de modelo.
+- **Compatibilidad del modelo de chat**: el modelo seleccionado debe admitir el endpoint Chat Completions configurado. Los modelos antiguos disponibles solo mediante completions, como `gpt-3.5-turbo-instruct`, se excluyen al actualizar la lista. Si el proveedor rechaza un valor personalizado de temperatura o el parámetro de límite de tokens, KNX AI vuelve a intentarlo eliminando o sustituyendo únicamente el campo incompatible.
 - **System prompt**: instrucción global para análisis KNX (Advanced).
+- **Permitir que la IA lea estados KNX y controle actuadores**: habilita la salida 4 y está desactivado por defecto. Los objetos exactos del catálogo ETS se pueden leer; solo se aceptan escrituras hacia objetos clasificados como `command`. Las operaciones desconocidas, con DPT distinto, inválidas o excesivas, y las escrituras hacia objetos de estado o neutrales, se rechazan localmente.
+- **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**: carga una pareja de mapeos entrada/salida desde el archivo de adaptadores de chat incluido. La selección sustituye intencionadamente ambos cuadros de texto; el código sigue siendo editable.
+- **Mapeo de entrada (chat → KNX AI)**: JavaScript síncrono aplicado antes de procesar el comando de entrada.
+- **Mapeo de salida (KNX AI → chat)**: JavaScript síncrono aplicado solo a los mensajes de la salida 3.
+- **Activar notificaciones proactivas del hogar**: detector opcional de estados abiertos de persiana/ventana/puerta reconocidos de forma fiable; nunca escribe de manera autónoma en KNX.
+- **Destinatario principal / ID de chat**: destino opcional de mensajes espontáneos; de lo contrario se recuerda la última sesión Ask.
+- **Avisar después de abierta (minutos)**: umbral de duración antes de considerar una notificación proactiva.
+- **Inicio / fin de horas silenciosas**: intervalo diario en el que se suprimen los mensajes proactivos.
+- **Educación de la IA**: instrucciones vinculantes gestionadas solo por el usuario, leídas por la IA y nunca modificadas.
+- **Tiempo de espera de repetición (minutos)**: intervalo mínimo antes de que el mismo objeto pueda volver a avisar.
+- **Archivo máximo de memoria del hogar (KB)**: límite estricto de 64 a 1.024 KB; 256 KB por defecto.
 - Si el archivo en disco esta activo, **Ask** lo usa por defecto: respeta fechas/rangos explicitos y, si no los indicas, busca en las ultimas 24 horas mas los eventos actuales en RAM.
 - **Include raw payload hex**: incluye payload hex raw en el prompt.
 - **Incluir inventario del proyecto Node-RED**: incluye en el prompt el inventario de todo el proyecto Node-RED, con nodos KNX y otros nodos utiles como function/change/inject/template cuando contienen logica KNX o direcciones de grupo.
@@ -84,5 +161,5 @@ Aquí tienes todos los campos tal como se muestran en el editor de KNX AI.
 - Si Node-RED se ejecuta en Docker, usa `host.docker.internal` en lugar de `localhost` en el endpoint.
 
 ## Nota de seguridad
-Si el LLM está habilitado, el contexto de tráfico KNX puede enviarse al endpoint configurado. Para privacidad on-premise, usa proveedores locales.
+Si el LLM está habilitado, el contexto de tráfico KNX puede enviarse al endpoint configurado. Para privacidad on-premise, usa proveedores locales. Un comando emitido por la salida 4 superó la validación local y fue enviado al flow, pero no confirma que el actuador lo ejecutara. Usa una GA de estado KNX para confirmarlo.
 </script>