node-red-contrib-knx-ultimate 6.3.22 → 6.3.25

package/nodes/locales/de/knxUltimateAI.html

@@ -25,9 +25,13 @@ 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
@@ -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 und erkannten Kameras. Sie zeigt außerdem den 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.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.
@@ -125,7 +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 immer `num_ctx = 16384` (oder das kleinere Modellmaximum) und verwendet dieselbe relevanzbasierte semantische 16K-Ansicht. So wird keine übergroße KV-Cache-Zuweisung erzeugt, ohne Agentenfunktionen zu entfernen.
+- 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)
@@ -133,7 +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 begrenzt KNX AI den eigenen Prompt immer auf eine nach Relevanz ausgewählte semantische 16K-Ansicht; dadurch wird nicht der gesamte 131K-Datensatz gesendet, ohne Denk-, KNX-, Routinen-, Kamera- oder TTS-Funktionen zu entfernen.
+- 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"
       },
@@ -68,6 +75,7 @@
       "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…",
@@ -87,6 +95,7 @@
       "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",
@@ -172,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/de/knxUltimateIoTBridge.html

@@ -45,7 +45,8 @@ Der Rest dieser Hilfe beschreibt den klassischen **IoT-Bridge**-Modus.
 ## Zuordnungsfelder
 
 - **Richtung** — wählen Sie KNX→IoT, IoT→KNX oder bidirektional.
-- **Kanaltyp** — MQTT verwendet das Target als Topic, REST als Basis-URL, Modbus als Registerkennung.
+- **Kanaltyp** — MQTT verwendet das Target als Topic, REST als Basis-URL; bei Modbus ist **Target** die nullbasierte Protokolladresse (0–65535).
+- **Modbus-Format / Unit-ID / Bereich / Datentyp** — wählen Sie für neue Zuordnungen **Mit Flex Write kompatibel** und danach Einheit, Speicherbereich sowie `bool`, `uint16` oder `int16`. Fehlt das Format, bleibt der alte Skalarvertrag aktiv, damit bestehende Flows weiter funktionieren.
 - **Skalierung & Offset** — werden für KNX→IoT angewandt; IoT→KNX nutzt die inverse Transformation.
 - **Template** — optionale Zeichenkette mit Platzhaltern `{{value}}`, `{{ga}}`, `{{label}}`, `{{target}}`, `{{type}}`, `{{isoTimestamp}}`.
 - **Timeout / Wiederholungen** — Informationsfelder im Output zur Steuerung von Retries und Zeitfenstern in nachfolgenden Nodes.
@@ -88,7 +89,32 @@ Der Rest dieser Hilfe beschreibt den klassischen **IoT-Bridge**-Modus.
 
 ### Modbus-Register-Sync
 
-- Kombinieren Sie den Bridge mit `modbus-flex-write`-Nodes aus `node-red-contrib-modbus`. Ausgang 1 enthält die Modbus-Adresse in `msg.address` und den Wert in `msg.payload`.
+Die Bridge ist ein Nachrichtenadapter für `node-red-contrib-modbus`; sie öffnet selbst keine TCP-/serielle Verbindung und fragt kein Gerät ab. Installieren Sie eine mit Ihrer Node-RED-Laufzeit kompatible Paketversion und verwenden Sie dann dessen Client- und Transport-Nodes.
+
+|Bereich|Lesen|Schreiben|Zulässige Richtung|
+|--|--|--|--|
+| Coil | FC1 | FC5 | Beide Richtungen |
+| Discrete Input | FC2 | — | Nur Modbus → KNX |
+| Holding Register | FC3 | FC6 | Beide Richtungen |
+| Input Register | FC4 | — | Nur Modbus → KNX |
+
+Wählen Sie bei einer neuen Zuordnung `Format = Mit Flex Write kompatibel`. Für KNX → Modbus kann Ausgang 1 direkt mit einem `modbus-flex-write`-Node verbunden werden und gibt Folgendes aus:
+
+```
+msg.payload = {
+  value: 215,
+  fc: 6,
+  unitid: 1,
+  address: 9,
+  quantity: 1
+}
+```
+
+`address` ist immer nullbasiert: bezeichnet ein Gerätehandbuch ein Holding Register als `40010`, lautet seine Protokolladresse üblicherweise `9`; prüfen Sie die Konvention des Handbuchs. Die Bridge unterstützt pro Zuordnung ein Bit oder ein einzelnes 16-Bit-Register. Mehrere Wörter, 32-Bit-/Float-Werte und Byte-/Wortreihenfolge werden derzeit nicht verarbeitet.
+
+Für Modbus → KNX verbinden Sie den Datenausgang eines `modbus-flex-getter`- oder `modbus-read`-Nodes mit dem Eingang der Bridge. Flex Getter stellt die Anfrage (`fc`, `unitid`, `address`, `quantity`) in `msg.modbusRequest` bereit; Modbus Read behält sie in `msg.input.payload`. Das zurückgegebene Werte-Array kann in `msg.payload` oder `msg.values` liegen. Die Bridge unterstützt beide Nachrichtenformen, ordnet alle von der Antwort abgedeckten Flex-Zuordnungen zu und verwendet das passende Array-Element. Aktivieren Sie **Keep Msg Properties** am Flex Getter. Skalierung und Offset folgen `raw = KNX × Skalierung + Offset`; eingehend wird die inverse Umrechnung angewendet.
+
+`KNX-Werte beim Deploy lesen` liest nur KNX; planen Sie Modbus-Lesevorgänge im externen Modbus-Flow. Legacy-Zuordnungen (einschließlich solcher ohne `modbusMessageFormat`) geben weiterhin den bisherigen skalaren Payload mit `msg.address`/`msg.modbusFunction` auf oberster Ebene aus.
 
 ## Beispiel-Flow
 

package/nodes/locales/de/knxUltimateIoTBridge.json

@@ -79,6 +79,10 @@
       "target": "Ziel",
       "method": "HTTP-Methode",
       "modbusFunction": "Modbus-Funktion",
+      "modbusMessageFormat": "Modbus-Nachrichtenformat",
+      "modbusUnitId": "Unit-ID",
+      "modbusArea": "Modbus-Bereich",
+      "modbusDataType": "Datentyp",
       "scale": "Skalierung",
       "offset": "Offset",
       "timeout": "Zeitüberschreitung (ms)",
@@ -103,7 +107,7 @@
       "target": "Topic, URL oder Register",
       "target_mqtt": "Topic, z. B. knx/light/living",
       "target_rest": "https://example/api/endpoint",
-      "target_modbus": "Register (z. B. 40001)",
+      "target_modbus": "Nullbasierte Adresse (z. B. 0)",
       "template": "{\"value\":{{value}}}",
       "property": "Optionale Eigenschaft/Pfad",
       "method": "POST",
@@ -114,7 +118,7 @@
         "default": "Ziel",
         "mqtt": "MQTT-Topic",
         "rest": "REST-URL",
-        "modbus": "Modbus-Register"
+        "modbus": "Modbus-Adresse (nullbasiert)"
       },
       "method": {
         "default": "HTTP-Methode",
@@ -125,6 +129,20 @@
         "modbus": "Modbus-Funktion"
       }
     },
+    "modbus": {
+      "formatLegacy": "Legacy-Skalar-Nachricht",
+      "formatFlex": "Mit Flex Write kompatibel",
+      "areaCoil": "Coil (FC1 lesen / FC5 schreiben)",
+      "areaDiscreteInput": "Discrete Input (FC2 lesen, schreibgeschützt)",
+      "areaHoldingRegister": "Holding Register (FC3 lesen / FC6 schreiben)",
+      "areaInputRegister": "Input Register (FC4 lesen, schreibgeschützt)",
+      "dataTypeBool": "Boolesch",
+      "dataTypeUint16": "16 Bit ohne Vorzeichen",
+      "dataTypeInt16": "16 Bit mit Vorzeichen",
+      "zeroBasedHint": "Verwende die nullbasierte Protokolladresse (0–65535), nicht die in manchen Handbüchern angegebene 4xxxx-Referenz.",
+      "flexHint": "Flex gibt msg.payload = {value,fc,unitid,address,quantity} zur direkten Verbindung mit modbus-flex-write aus.",
+      "readOnlyHint": "Discrete Inputs und Input Register sind schreibgeschützt und können nur Modbus → KNX verwenden."
+    },
     "labels": {
       "outputKnxToIoT": "Strom KNX → IoT",
       "outputIoTToKnx": "Bestätigungen IoT → KNX",

package/nodes/locales/en/knxUltimateAI.html

@@ -25,9 +25,13 @@ 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
@@ -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 and detected cameras. It also shows the 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.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.
@@ -131,7 +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 always sends `num_ctx = 16384` (or the model maximum when it is smaller) and uses the same relevance-selected 16K semantic prompt, avoiding oversized KV-cache allocation without removing agent capabilities.
+- 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)
@@ -139,7 +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 always limits its own prompt to a relevance-selected 16K semantic view; this avoids sending the full 131K data set without removing reasoning, KNX, routine, camera or TTS capabilities.
+- 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,7 +64,8 @@
       "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…",
@@ -69,6 +77,7 @@
       "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…",
@@ -88,6 +97,7 @@
       "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",

package/nodes/locales/en/knxUltimateIoTBridge.html

@@ -45,7 +45,8 @@ The rest of this help describes the classic **IoT bridge** mode.
 ## Mapping Fields
 
 - **Direction** — choose KNX→IoT, IoT→KNX or bidirectional.
-- **Channel type** — MQTT uses the target as topic; REST uses it as the base URL; Modbus expects a register identifier.
+- **Channel type** — MQTT uses the target as topic; REST uses it as the base URL; for Modbus, **Target** is the zero-based protocol address (0–65535).
+- **Modbus format / Unit ID / Area / Data type** — choose **Flex Write compatible** for new mappings, then select the unit, memory area and `bool`, `uint16` or `int16`. A missing format remains the legacy scalar contract so existing flows keep working.
 - **Scale & Offset** — applied to KNX→IoT; IoT→KNX applies the inverse transform.
 - **Template** — optional string replacing `{{value}}`, `{{ga}}`, `{{label}}`, `{{target}}`, `{{type}}`, `{{isoTimestamp}}`.
 - **Timeout / Retries** — informational fields exposed in the emitted message for downstream nodes to act on.
@@ -88,7 +89,32 @@ The rest of this help describes the classic **IoT bridge** mode.
 
 ### Modbus register sync
 
-- Pair the MQTT - IoT with `node-red-contrib-modbus` `modbus-flex-write` nodes. Output 1 carries the Modbus address in `msg.address` and the value in `msg.payload`.
+The bridge is a message adapter for `node-red-contrib-modbus`; it does not open a TCP/serial connection and does not poll a device. Install a version of that package compatible with your Node-RED runtime, then use its client and transport nodes.
+
+|Area|Read|Write|Allowed direction|
+|--|--|--|--|
+| Coil | FC1 | FC5 | Either direction |
+| Discrete input | FC2 | — | Modbus → KNX only |
+| Holding register | FC3 | FC6 | Either direction |
+| Input register | FC4 | — | Modbus → KNX only |
+
+For a new mapping select `Format = Flex Write compatible`. On KNX → Modbus, Output 1 can be wired directly to a `modbus-flex-write` node and emits:
+
+```
+msg.payload = {
+  value: 215,
+  fc: 6,
+  unitid: 1,
+  address: 9,
+  quantity: 1
+}
+```
+
+`address` is always zero-based: if a device manual labels a holding register as `40010`, its protocol address is commonly `9`; verify the convention in that manual. The bridge supports one bit or one 16-bit register per mapping. It does not currently combine words, decode 32-bit/float values or manage byte/word order.
+
+For Modbus → KNX, wire the data output of a `modbus-flex-getter` or `modbus-read` node to the bridge input. A Flex Getter provides the request (`fc`, `unitid`, `address`, `quantity`) in `msg.modbusRequest`; a Modbus Read node preserves it in `msg.input.payload`. The returned values array may be in `msg.payload` or `msg.values`. The bridge supports both message shapes, matches every Flex mapping covered by the response and uses the appropriate array element. Enable **Keep Msg Properties** on Flex Getter. Scale and offset are applied as `raw = KNX × scale + offset`; the incoming path applies the inverse transformation.
+
+`Read KNX values on deploy` reads KNX only; schedule Modbus reads in the external Modbus flow. Legacy mappings (including mappings without `modbusMessageFormat`) continue to emit the previous scalar payload plus top-level `msg.address`/`msg.modbusFunction` metadata.
 
 ## Sample Flow
 

package/nodes/locales/en/knxUltimateIoTBridge.json

@@ -79,6 +79,10 @@
       "target": "Target",
       "method": "HTTP method",
       "modbusFunction": "Modbus function",
+      "modbusMessageFormat": "Modbus message format",
+      "modbusUnitId": "Unit ID",
+      "modbusArea": "Modbus area",
+      "modbusDataType": "Data type",
       "scale": "Scale",
       "offset": "Offset",
       "timeout": "Timeout (ms)",
@@ -103,7 +107,7 @@
       "target": "Topic, URL or register",
       "target_mqtt": "Topic, e.g. knx/light/living",
       "target_rest": "https://example/api/endpoint",
-      "target_modbus": "Register (e.g. 40001)",
+      "target_modbus": "Zero-based address (e.g. 0)",
       "template": "{\"value\":{{value}}}",
       "property": "Optional property/path",
       "method": "POST",
@@ -114,7 +118,7 @@
         "default": "Target",
         "mqtt": "MQTT topic",
         "rest": "REST URL",
-        "modbus": "Modbus register"
+        "modbus": "Modbus address (zero-based)"
       },
       "method": {
         "default": "HTTP method",
@@ -125,6 +129,20 @@
         "modbus": "Modbus function"
       }
     },
+    "modbus": {
+      "formatLegacy": "Legacy scalar message",
+      "formatFlex": "Flex Write compatible",
+      "areaCoil": "Coil (FC1 read / FC5 write)",
+      "areaDiscreteInput": "Discrete input (FC2 read only)",
+      "areaHoldingRegister": "Holding register (FC3 read / FC6 write)",
+      "areaInputRegister": "Input register (FC4 read only)",
+      "dataTypeBool": "Boolean",
+      "dataTypeUint16": "Unsigned 16-bit",
+      "dataTypeInt16": "Signed 16-bit",
+      "zeroBasedHint": "Use the zero-based protocol address (0–65535), not the 4xxxx reference printed by some manuals.",
+      "flexHint": "Flex emits msg.payload = {value,fc,unitid,address,quantity} for direct wiring to modbus-flex-write.",
+      "readOnlyHint": "Discrete inputs and input registers are read-only and can only use Modbus → KNX."
+    },
     "labels": {
       "outputKnxToIoT": "KNX → IoT stream",
       "outputIoTToKnx": "IoT → KNX acknowledgements",