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

package/nodes/locales/fr/knxUltimateAI.html

@@ -25,13 +25,17 @@ Si le traitement dure plus de 1,2 seconde, la sortie 3 émet immédiatement le m
 
 Les requêtes Ollama et Bionic LM Studio utilisent automatiquement un délai minimal de 10 minutes ; les fournisseurs cloud conservent un minimum de 2 minutes. Aucun champ de délai n’est à gérer dans l’éditeur. Si même la limite locale est atteinte, KNX AI indique que le modèle n’a pas terminé et conseille de réessayer ou de réduire le contexte du prompt.
 
+Pour les fournisseurs locaux, **Quantité de contexte du chat** permet de choisir explicitement 4K, 8K ou 16K ; 16K reste la valeur par défaut. Ce choix limite proportionnellement les données KNX, de mémoire, du projet Node-RED et des adaptateurs fournies au modèle, tout en conservant le contrat complet des outils de l’agent. Aucune capacité n’est activée ou désactivée selon une formulation, des mots-clés ou des intents linguistiques.
+
 L’état du nœud sur le canvas est volontairement réservé à la dernière demande reçue et au message localisé « Je réfléchis… » pendant l’exécution du LLM. Les télégrammes KNX, mises à jour de la passerelle, débits de trafic, messages ready et résultats techniques ne l’écrasent jamais ; ils restent disponibles via les sorties, les journaux et les données de l’Assistant.
 
-Chaque session Ask/chat conserve ses 8 derniers échanges et jusqu'à 20 instructions explicites à long terme, séparées par `msg.knxAi.sessionId`, `msg.sessionId` ou l’ID de chat Telegram détecté. Les demandes telles que « Souviens-toi de ne pas employer le terme unknown » deviennent des instructions persistantes. Tous les nœuds KNX AI utilisant le même stockage partagent ce contexte en direct et le rechargent après un redémarrage de Node-RED depuis `knxultimatestorage/knxai/memory/knxai-chat-context.md`. Le fichier, écrit de façon atomique, est limité à 50 sessions et 512 Ko. Lorsque le contrôle KNX est activé, reliez la sortie 3 au nœud d'envoi du chat et la sortie 4 à un nœud KNX Ultimate en **mode universel**. Avec la confirmation active, la première réponse affiche GA, DPT et payload sans émettre d’écriture ; la même session doit répondre `CONFIRMER` ou `ANNULER` dans les 5 minutes. Une nouvelle demande remplace tout plan précédent. Chaque commande confirmée contient `msg.destination`, `msg.dpt`, `msg.payload` et `msg.event = "GroupValue_Write"`.
+Chaque session Ask/chat conserve ses 8 derniers échanges et jusqu'à 20 instructions à long terme choisies par le modèle, séparées par `msg.knxAi.sessionId`, `msg.sessionId` ou l’ID de chat Telegram détecté. Le modèle décide sémantiquement, grâce à l’outil de mémoire structurée, ce que le sens d’une conversation doit mémoriser ou oublier ; aucune liste de mots-clés ni d’intents linguistiques n’est utilisée. Tous les nœuds KNX AI utilisant le même stockage partagent ce contexte en direct et le rechargent après un redémarrage de Node-RED depuis `knxultimatestorage/knxai/memory/knxai-chat-context.knxctx`. Le fichier, écrit de façon atomique, est limité à 50 sessions et 512 Ko. Lorsque le contrôle KNX est activé, reliez la sortie 3 au nœud d'envoi du chat et la sortie 4 à un nœud KNX Ultimate en **mode universel**. Avec la confirmation active, la première réponse affiche GA, DPT et payload sans émettre d’écriture ; la même session doit répondre `CONFIRMER` ou `ANNULER` dans les 5 minutes. Une nouvelle demande remplace tout plan précédent. Chaque commande confirmée contient `msg.destination`, `msg.dpt`, `msg.payload` et `msg.event = "GroupValue_Write"`.
+La mémoire récente de la session est placée juste à côté de la demande actuelle afin que les modèles locaux conservent les faits fournis par l'utilisateur, comme son nom préféré ou sa langue, même dans un long prompt KNX. Le modèle peut rendre persistants les faits, préférences et instructions durables via `memoryActions` ; cela reste un choix sémantique d'outil, sans classificateur de phrases ni routage par intents. Les identifiants, codes de sécurité et clés API ne doivent jamais être appris.
+
 Pour les écritures DPT 1.xxx, les équivalents sûrs produits par l’IA `true`/`false`, `1`/`0` et `on`/`off` sont normalisés en véritables booléens avant la validation locale et la sortie.
 
 ### Lectures KNX actualisées
-Lorsque l’utilisateur demande explicitement un état actuel ou actualisé, l’IA peut interroger les objets exacts du catalogue ETS importé, y compris les objets d’état et autres objets en lecture seule. La sortie 4 émet `msg.destination`, `msg.dpt`, `msg.event = "GroupValue_Read"` et `msg.readstatus = true`. Le nœud attend jusqu’à 6 secondes chaque `GroupValue_Response` ou écriture récente, puis renvoie les valeurs décodées sur la sortie 3 et les détails dans `msg.knxAi.readResults`. Les lectures ne nécessitent jamais de confirmation et ne sont jamais transformées en écritures.
+Lorsque l’utilisateur demande explicitement un état actuel ou actualisé, l’IA peut interroger les objets exacts du catalogue ETS importé, y compris les objets d’état et autres objets en lecture seule. La sortie 4 émet `msg.destination`, `msg.dpt`, `msg.event = "GroupValue_Read"` et `msg.readstatus = true`. Le nœud attend jusqu’à 6 secondes chaque `GroupValue_Response` ou écriture récente, puis renvoie les valeurs décodées sur la sortie 3 et les détails dans `msg.knxAi.readResults`. Les lectures ne nécessitent jamais de confirmation et ne sont jamais transformées en écritures. Si un petit modèle local omet le type d’opération et le payload, les objets ETS exacts sont normalisés en toute sécurité comme lectures ; un élément contenant un payload reste une écriture validée.
 
 ### Routines conversationnelles multi-étapes
 Des demandes comme « Je pars », « Bonne nuit » ou « Mode cinéma » peuvent coordonner une routine tenant compte de l’état courant sans nouvelle option dans l’éditeur. Au premier passage LLM, seules les lectures ETS exactes sont acceptées (20 au maximum) ; KNX AI les envoie puis fournit les résultats actualisés GA/DPT/valeur à un second passage de planification isolé. Celui-ci peut préparer jusqu’à 12 écritures validées, sans lancer un nouveau cycle de lecture. Lorsque la confirmation est active, le plan complet ne demande qu’une confirmation localisée et aucune écriture ni annonce TTS demandée n’est émise auparavant. Après confirmation, chaque écriture est revalidée, transmise dans l’ordre et observée jusqu’à 4 secondes pour détecter un retour immédiat correspondant sur le bus. La réponse finale distingue les retours observés des opérations sans retour immédiat, sans déclarer pour autant une panne de l’appareil. Les détails figurent dans `msg.knxAi.routine`, `readResults`, `verifiedCount` et `unverifiedCount`.
@@ -42,24 +46,38 @@ Lorsqu'un plan est en attente, la sortie 3 contient `msg.knxAi.confirmationReque
 ### Préréglages d’adaptateur de chat
 L’onglet **Adaptateurs de chat** charge ses mappages sélectionnables depuis `resources/KNXAIChatAdapterMappings.js`. Le choix d’un préréglage installe en interne deux mappages JavaScript synchrones prédéfinis : un avant le traitement de l’entrée par KNX AI et un avant l’émission sur la sortie 3. Les mappages restent masqués dans l’éditeur. Les erreurs de syntaxe et d’exécution sont interceptées et signalées sans arrêter Node-RED.
 
-Le préréglage inclus **windkh/node-red-contrib-telegrambot** suit le contrat receiver/sender du paquet. Connectez directement un `telegram receiver` à KNX AI et la sortie 3 à un `telegram sender`. Pour les boutons de confirmation inline, connectez aussi un `telegram event` configuré pour `callback_query` à la même entrée KNX AI. Le mappage d’entrée extrait `msg.payload.content`, `msg.payload.chatId` et la langue Telegram. Le mappage de sortie crée `msg.payload.chatId`, `type` et `content`, puis ajoute `options.reply_markup` depuis `msg.knxAi.confirmationRequest` lorsqu’une écriture attend confirmation. Le paquet Telegram reste une dépendance optionnelle distincte.
+Le préréglage inclus **windkh/node-red-contrib-telegrambot** suit le contrat receiver/sender du paquet. Connectez directement un `telegram receiver` à KNX AI et la sortie 3 à un `telegram sender`. La confirmation utilise un clavier de réponse Telegram temporaire : un appui sur **Confirmer** ou **Annuler** renvoie un message localisé normal par le même receiver ; aucun `telegram event` ni câblage de callback n’est nécessaire. Les anciens messages `callback_query` restent acceptés. Le mappage d’entrée extrait `msg.payload.content`, `msg.payload.chatId` et la langue Telegram. Le mappage de sortie crée `msg.payload.chatId`, `type` et `content`, puis ajoute `options.reply_markup` depuis `msg.knxAi.confirmationRequest` lorsqu’une écriture attend confirmation. Le paquet Telegram reste une dépendance optionnelle distincte.
 
 Le préréglage inclus **RedBot / node-red-contrib-chatbot (Telegram)** suit le format de message commun de RedBot. Connectez directement `chatbot-telegram-receive` à KNX AI et la sortie 3 à `chatbot-telegram-send` ; aucun nœud de callback séparé n’est nécessaire, car RedBot convertit les postbacks des boutons inline en messages entrants ordinaires. Le mappage d’entrée lit `transport`, `chatId`, `type`, `content` et la langue Telegram. Le mappage de sortie conserve les données de suivi RedBot `originalMessage`, `chat`, `api` et `client`, puis émet soit un payload `message`, soit un payload `inline-buttons` avec des actions `postback` de confirmation. RedBot reste une dépendance optionnelle distincte.
 
 ### Adaptateurs de caméra détectés automatiquement
 Les paquets de caméra installés peuvent publier à l’exécution un adaptateur pour KNX AI. Il n’existe aucun sélecteur ni nœud caméra à relier à KNX AI : les adaptateurs, contrôleurs et caméras disponibles sont détectés automatiquement et ajoutés au contexte du chat. `node-red-contrib-unifi-ultimate` est le premier fournisseur pris en charge ; d’autres paquets, tels que `hikvision-ultimate`, peuvent s’enregistrer avec le même contrat indépendant du fabricant.
 
-L’utilisateur peut demander une capture actuelle ou demander au modèle de vision ce qui est visible. Les préréglages Telegram et RedBot envoient l’image comme photo native avec une légende. L’utilisateur peut aussi créer des notifications persistantes pour un mouvement, le franchissement d’une ligne intelligente ou l’entrée dans une zone d’intrusion/de stationnement, avec une limitation facultative aux personnes détectées et à une ligne ou zone nommée précise. Ces règles sont stockées dans le même fichier `knxai-chat-context.md` et restaurées après les redémarrages de Node-RED. Les abonnements aux événements UniFi et les demandes de capture passent directement par le fournisseur détecté ; la sortie 4 de KNX AI et un câblage intermédiaire ne sont pas nécessaires.
+L’utilisateur peut demander une capture actuelle ou demander au modèle de vision ce qui est visible. Les préréglages Telegram et RedBot envoient l’image comme photo native avec une légende. L’utilisateur peut aussi créer des notifications persistantes pour un mouvement, le franchissement d’une ligne intelligente ou l’entrée dans une zone d’intrusion/de stationnement, avec une limitation facultative aux personnes détectées et à une ligne ou zone nommée précise. Ces règles sont stockées dans le même fichier `knxai-chat-context.knxctx` et restaurées après les redémarrages de Node-RED. Les abonnements aux événements UniFi et les demandes de capture passent directement par le fournisseur détecté ; la sortie 4 de KNX AI et un câblage intermédiaire ne sont pas nécessaires.
 
-Chaque événement publié par un adaptateur détecté automatiquement est normalisé puis ajouté à un fichier quotidien `YYYY-MM-DD.jsonl` sous `knxultimatestorage/knxai/adapter-history/<id-nœud>/`. L’archive conserve 10 jours, garantit plus de 24 heures d’historique et stocke les métadonnées, mais pas les images. L’Assistant web et tous les canaux CHAT l’interrogent avec l’archive quotidienne KNX. Les totaux couvrent toutes les lignes stockées ; les détails sélectionnés ne sont qu’un échantillon pertinent.
+Chaque événement publié par un adaptateur détecté automatiquement est normalisé puis ajouté directement, dans le format natif compact par lignes de KNX AI, à un fichier quotidien `YYYY-MM-DD.knxctx` sous `knxultimatestorage/knxai/adapter-history/<id-nœud>/`. L’archive des télégrammes KNX utilise le même format compact, sans sérialisation JSON intermédiaire. L’archive conserve 10 jours, garantit plus de 24 heures d’historique et stocke les métadonnées, mais pas les images. Les archives JSONL existantes ne sont ni lues ni migrées. Les totaux couvrent toutes les lignes stockées ; les détails sélectionnés ne sont qu’un échantillon pertinent.
 
 ### Annonces avec TTS Ultimate
 Lorsque le paquet facultatif `node-red-contrib-tts-ultimate` est installé, il apparaît parmi les adaptateurs détectés automatiquement. Le sélecteur recense tous les nœuds `ttsultimate` de tous les flows du projet, avec le flow, le nom du nœud et le lecteur configuré. Sélectionnez le nœud chargé des annonces du chat, puis déployez le flow.
 
-Seule une demande explicite dans le message de chat actuel peut créer une annonce. KNX AI envoie le texte exact directement au nœud choisi dans `msg.payload`, avec `msg.topic = "knx_ai_announcement"` ; aucun câblage intermédiaire n’est nécessaire. TTS Ultimate gère ensuite le lecteur Sonos configuré, la voix, le volume, le signal d’introduction et la file d’attente. Le contexte persistant, l’Éducation IA, le contenu des caméras et les événements déduits ne déclenchent jamais la parole de manière autonome.
+Le modèle décide d’utiliser cet adaptateur en raisonnant sur la demande actuelle, les instructions persistantes du chat et l’Éducation IA gérée par l’utilisateur ; il n’existe ni intent d’annonce ni liste de phrases déclencheuses. Les valeurs KNX, événements d’adaptateur, images et archives restent des données et non des instructions, mais les consignes fiables de l’utilisateur peuvent apprendre au modèle comment agir sur ces données. KNX AI envoie le texte choisi directement au nœud dans `msg.payload`, avec `msg.topic = "knx_ai_announcement"`. TTS Ultimate gère ensuite le lecteur Sonos, la voix, le volume, le signal et la file d’attente.
 
 ### Aperçu du contexte du chat
-L’éditeur du nœud affiche une carte compacte résumant les sources disponibles pour le chat : trafic KNX actuel, sémantique ETS et projet Node-RED, mémoire de session et de la maison, Éducation IA, caméras détectées et documentation pertinente. Elle répertorie aussi `knxai-chat-context.md`, `knxai-home-memory.md` et `knxai-config-<id-nœud>.json`, ainsi que la racine absolue de l’archive des télégrammes KNX, le dossier propre au nœud et le format quotidien `YYYY-MM-DD.jsonl`. Les chemins sont déterminés à l’exécution depuis le répertoire de données réellement utilisé par la passerelle configurée.
+L’éditeur du nœud affiche une carte compacte résumant les sources disponibles pour le chat : trafic KNX actuel, sémantique ETS et projet Node-RED, mémoire de session et de la maison, Éducation IA et caméras détectées. Elle affiche aussi le contexte opérationnel maximal choisi par l’utilisateur et la taille UTF-8 réelle du dernier prompt du chat ; les jetons d’entrée exacts du fournisseur sont utilisés lorsqu’ils sont fournis, sinon leur nombre est signalé comme estimé. Elle répertorie aussi `knxai-chat-context.knxctx`, `knxai-home-memory.md` et `knxai-config-<id-nœud>.json`, ainsi que la racine absolue de l’archive des télégrammes KNX, le dossier propre au nœud et le format quotidien `YYYY-MM-DD.knxctx`. Les chemins sont déterminés à l’exécution depuis le répertoire de données réellement utilisé par la passerelle configurée.
+
+Le modèle reçoit les lectures/écritures KNX, les adaptateurs caméra, les annonces TTS et la mémoire persistante comme outils structurés. Il peut les sélectionner et les combiner sémantiquement à partir de la demande actuelle et des consignes fiables apprises, sans routage par intents linguistiques. Le runtime ne valide que les arguments, la disponibilité des adaptateurs et les limites de sécurité ; les écritures KNX conservent la validation ETS/DPT locale et la confirmation configurée.
+
+### Modification et sauvegarde de l'apprentissage CHAT
+L'onglet **Conversations et maison** de la configuration Node-RED de KNX AI contient le bouton **Ouvrir l'apprentissage du chat IA**, qui ouvre l'interface web Vue directement sur cet éditeur pour le nœud actuel.
+
+Dans l'interface web Vue, ouvrez **Paramètres → Apprentissage du chat IA** pour afficher et modifier le fichier partagé exact `knxai-chat-context.knxctx` ainsi que son chemin absolu. Le fichier peut être copié, téléchargé comme sauvegarde ou restauré depuis un autre fichier `.knxctx`. **Réinitialiser la mémoire**, protégé par une confirmation explicite, le remplace par un nouveau contexte vide et efface les sessions, instructions, surveillances de caméra et confirmations de chat en attente dans tous les nœuds KNX AI utilisant le même stockage. Les enregistrements natifs séparés par tabulations `KNXAI_CHAT_CONTEXT 3` font autorité et sont directement modifiables : `SESSION` contient les enregistrements `INSTRUCTION`, `TURN` et `CAMERA_WATCH` jusqu'à `END_SESSION`. L'enregistrement valide et limite ces enregistrements, réécrit le fichier de manière atomique et met à jour le contexte actif de tous les nœuds KNX AI utilisant le même stockage. Un contrôle de révision refuse d'écraser ou de réinitialiser un apprentissage modifié après son chargement dans l'éditeur.
+
+Seul le format natif V3 est pris en charge. Les anciens fichiers Markdown/JSON V2 et Base64 V1 ne sont volontairement ni lus, ni importés, ni migrés ; l'ancien fichier `.md` reste intact et KNX AI démarre un nouveau contexte `.knxctx`. Les limites de 50 sessions et 512 Ko restent applicables.
+
+### Rôles appris des adresses de groupe KNX
+Le rôle `neutral` représente une incertitude initiale, pas une interdiction permanente de commande. Le modèle peut utiliser l’outil structuré `gaRoleActions` pour apprendre qu’une adresse de groupe ETS exacte est un objet de commande, d’état ou neutre à partir d’un enseignement fiable de l’utilisateur, de consignes persistantes du chat, de l’Éducation IA ou d’une sémantique non équivoque du projet ETS. Aucun mot-clé ni intent de rôle n’est requis ; si les preuves sont ambiguës, le modèle demande une précision au lieu d’apprendre.
+
+Le rôle, la justification et la preuve appris sont enregistrés par nœud dans `<userDir>/knxai/config/knxai-config-<id-nœud>.json` et synchronisés dans la mémoire sémantique domestique limitée. Un rôle appris comme `command` peut valider une écriture dans la même réponse et reste disponible après redémarrage ; le modèle peut aussi l’oublier et rétablir la classification automatique. L’apprentissage ne peut pas inventer une GA, modifier son DPT ETS, contourner la validation du payload ni ignorer la confirmation d’écriture configurée.
 
 ## Intelligence domestique proactive guidée par l’Éducation et mémoire limitée
 À partir de la hiérarchie ETS, des noms, rôles et DPT, le nœud crée un modèle sémantique déterministe. Il n’existe ni interrupteur séparé ni paramètres proactifs avancés. Une notification n’est évaluée que si le LLM est actif et si **Éducation IA** la demande explicitement. L’Éducation définit seule les conditions, la durée, les heures silencieuses et la répétition. Sans règle explicite, ou si le LLM ne peut pas l’évaluer, aucun message n’est envoyé.
@@ -114,7 +132,7 @@ Voici tous les champs tels qu'affichés dans l'éditeur KNX AI.
 - **Demander confirmation avant d’envoyer les commandes KNX** : activé par défaut. Affiche d'abord les modifications validées et n'émet aucune commande tant que la même session de chat ne les confirme pas. Lorsque des commandes attendent une confirmation, la réponse ajoute toujours les instructions exactes de confirmation ou d'annulation dans la langue de la demande courante. Les commandes sont à nouveau validées juste avant la sortie.
 - **Préréglage d’adaptateur** : utilise **Aucun adaptateur** par défaut. La sélection charge la paire prédéfinie de mappages entrée/sortie ; les deux restent masqués dans l’éditeur.
 - **Éducation de l’IA** : consignes autoritaires gérées uniquement par l'utilisateur, lues par l'IA et jamais modifiées. C’est le seul endroit où demander des notifications proactives et définir leurs conditions, durée, heures silencieuses et répétition.
-- Les extraits pertinents de l’aide, du README et des exemples sont toujours inclus automatiquement ; leur langue est déterminée à partir de la demande de l’utilisateur, avec des replis automatiques sur toutes les langues prises en charge.
+- Les extraits fournis avec le paquet depuis l’aide, le README, le changelog, le wiki et les exemples ne sont pas inclus dans les prompts Telegram, RedBot ou CHAT personnalisés. Ils restent disponibles uniquement pour l’Assistant web lors des questions techniques sur le paquet.
 - Bouton **Refresh** : interroge le provider et charge les modèles disponibles. Son icône tourne pendant le chargement ; une réussite ne produit volontairement aucun message.
 
 ### Démarrage rapide Ollama (local)
@@ -125,6 +143,7 @@ Voici tous les champs tels qu'affichés dans l'éditeur KNX AI.
   - **2) Install it** : télécharge et installe le modèle localement (ex. `llama3.1`).
 - Pendant refresh/install, KNX AI tente aussi de démarrer automatiquement le serveur Ollama.
 - Si l'installation échoue avec une erreur de connexion, vérifier qu'Ollama est lancé (app desktop ou `ollama serve`).
+- Le contexte maximal déclaré par `/api/show` reste informatif. KNX AI envoie le budget choisi de 4K, 8K ou 16K comme `num_ctx` (ou le maximum du modèle s’il est inférieur) et limite proportionnellement chaque source de contexte sans retirer de capacités à l’agent.
 - Si Node-RED tourne dans Docker, utiliser `host.docker.internal` au lieu de `localhost` dans l'endpoint.
 
 ### Démarrage rapide Bionic LM Studio (local)
@@ -132,6 +151,7 @@ Voici tous les champs tels qu'affichés dans l'éditeur KNX AI.
 - Démarrer le serveur API LM Studio depuis la page **Developer** ou avec `lms server start`.
 - Endpoint par défaut : `http://localhost:1234/v1/chat/completions`.
 - Cliquer sur **Refresh** pour charger tous les modèles exposés par `/v1/models` ; le premier est sélectionné si aucun modèle n’est configuré.
+- Lorsqu’un modèle est déjà chargé, KNX AI conserve la longueur de contexte active. KNX AI ne charge jamais un modèle Bionic inactif via l’API de gestion : la première requête de chat laisse Bionic le charger en JIT avec les valeurs par défaut enregistrées pour ce modèle. Indépendamment du contexte déclaré par Bionic, KNX AI utilise le budget de prompt choisi de 4K, 8K ou 16K et conserve les capacités de raisonnement, KNX, routines, caméras et TTS.
 - La clé API est facultative sauf si l’authentification est activée dans les paramètres du serveur LM Studio. Dans Docker, remplacer `localhost` par `host.docker.internal`.
 
 ## Note sécurité

package/nodes/locales/fr/knxUltimateAI.json

@@ -6,6 +6,7 @@
       "groupChatHome": "Conversations et maison",
       "detectedAdapters": "Adaptateurs détectés automatiquement",
       "chatContextOverview": "Aperçu du contexte du chat",
+      "chatLearning": "Apprentissage du chat IA",
       "quickSetup": "Configurer l'assistant",
       "llmConnection": "Connexion Assistant IA",
       "chatAdapter": "Canaux de chat",
@@ -21,6 +22,7 @@
       "llmBaseUrl": "Endpoint URL",
       "llmApiKey": "API key",
       "llmModel": "Model",
+      "llmPromptContextTokens": "Quantité de contexte du chat",
       "llmSystemPrompt": "System prompt",
       "llmIncludeRaw": "Include raw payload hex",
       "llmAllowKnxCommands": "Autoriser l’IA à lire les états KNX et commander les actionneurs",
@@ -45,6 +47,11 @@
         "ollama": "Ollama (local)",
         "lmstudio": "Bionic LM Studio"
       },
+      "promptContext": {
+        "small": "Réduit (4K, plus rapide)",
+        "medium": "Moyen (8K)",
+        "full": "Complet (16K)"
+      },
       "chatAdapter": {
         "none": "Aucun adaptateur"
       },
@@ -55,10 +62,13 @@
     },
     "messages": {
       "lmStudioContextAvailable": "Contexte maximal du modèle",
-      "lmStudioContextLoading": "Chargement du modèle avec son contexte maximal",
-      "lmStudioContextConfigured": "Contexte maximal du modèle configuré",
+      "lmStudioContextLoading": "Vérification du contexte actif du modèle",
+      "lmStudioContextInactive": "Modèle inactif ; les valeurs par défaut de Bionic seront utilisées à la première requête",
+      "lmStudioContextConfigured": "Contexte actif du modèle",
       "lmStudioContextFailed": "Impossible de configurer le contexte du modèle",
       "lmStudioContextCurrentlyLoaded": "actuellement chargé",
+      "localContextBudget": "Budget de contexte KNX AI",
+      "promptContextHint": "Contrôle la quantité de contexte KNX, mémoire, projet et adaptateurs envoyée aux modèles locaux. Cela n’active ni ne désactive les outils et n’utilise aucun routage par intent.",
       "ollamaNotSupported": "Ollama local mode: API key not required. Default endpoint is http://localhost:11434/api/chat.",
       "ollamaNoModels": "No local Ollama model found. Install one or pick one from the library.",
       "installingOllamaModel": "Starting Ollama and installing model…",
@@ -78,7 +88,16 @@
       "ttsUltimateHint": "Les demandes explicites d’annonce du chat sont envoyées directement au nœud sélectionné ; aucun câblage de flow n’est nécessaire.",
       "chatContextLoading": "Chargement du résumé du contexte du chat…",
       "chatContextUnavailable": "Le résumé du contexte du chat est temporairement indisponible.",
+      "chatLearningOpenHint": "Ouvre l’interface web directement dans l’éditeur d’apprentissage CHAT partagé pour afficher, modifier, copier ou sauvegarder son fichier persistant.",
       "chatContextIntro": "Le chat reçoit automatiquement ces sources. Les chemins ci-dessous sont ceux réellement utilisés par cette installation Node-RED.",
+      "chatContextLimitLabel": "Contexte opérationnel maximal",
+      "chatContextProviderManaged": "géré par le fournisseur/modèle sélectionné",
+      "chatContextTokens": "jetons",
+      "chatContextLastPromptLabel": "Taille réelle du dernier prompt du chat",
+      "chatContextLastPromptUnavailable": "indisponible jusqu'à la première demande du chat",
+      "chatContextExactInputTokens": "jetons d'entrée mesurés par le fournisseur",
+      "chatContextEstimatedInputTokens": "jetons d'entrée estimés",
+      "chatContextImages": "images",
       "chatContextSourcesTitle": "Sources incluses",
       "chatContextFilesTitle": "Fichiers de contexte persistants",
       "chatContextDirectoriesTitle": "Archive des télégrammes KNX",
@@ -86,7 +105,7 @@
       "chatContextSourceAdapterHistory": "Historique quotidien persistant des événements des adaptateurs détectés, y compris les détections des caméras.",
       "chatContextSourceEtsProject": "Sémantique ETS et inventaire complet du projet Node-RED.",
       "chatContextSourceMemoryEducation": "Contexte de session, Éducation IA et mémoire domestique limitée.",
-      "chatContextSourceCamerasDocs": "Caméras détectées et extraits pertinents de l'aide, du README et des exemples.",
+      "chatContextSourceCameras": "Caméras détectées et leurs fonctionnalités disponibles.",
       "chatContextSourceTtsUltimate": "Nœud TTS Ultimate sélectionné pour les annonces.",
       "chatContextSourceBadge": "Source",
       "chatContextFileChatContext": "Tours de conversation persistants, instructions et règles de notification des caméras.",
@@ -162,7 +181,8 @@
     "buttons": {
       "installOllamaModel": "2) Install it",
       "ollamaLibrary": "Model library",
-      "downloadOllamaModel": "1) Download model"
+      "downloadOllamaModel": "1) Download model",
+      "openChatLearning": "Ouvrir l’apprentissage du chat IA"
     }
   }
 }

package/nodes/locales/it/knxUltimateAI.html

@@ -25,13 +25,17 @@ Se l'elaborazione dura più di 1,2 secondi, l'uscita 3 emette subito il messaggi
 
 Le richieste Ollama e Bionic LM Studio usano automaticamente un timeout minimo di 10 minuti; i provider cloud mantengono un minimo di 2 minuti. Non esiste un campo timeout da gestire nell'editor. Se viene raggiunto anche il limite locale, KNX AI segnala che il modello non ha completato la risposta e suggerisce di riprovare o ridurre il contesto del prompt.
 
+Per i provider locali, **Quantità contesto chat** permette di scegliere esplicitamente 4K, 8K o 16K; 16K resta il valore predefinito. La scelta limita proporzionalmente i dati KNX, memoria, progetto Node-RED e adapter forniti al modello, mantenendo completo il contratto degli strumenti dell’agente. Nessuna funzione viene abilitata o disabilitata in base a formulazioni, parole chiave o intent linguistici.
+
 Lo stato del nodo sul canvas è riservato intenzionalmente all'ultima richiesta in ingresso e al messaggio localizzato «Sto pensando…» mentre l'LLM è in esecuzione. Telegrammi KNX, aggiornamenti del gateway, frequenze del traffico, messaggi ready e risultati tecnici non lo sovrascrivono mai; restano disponibili tramite uscite, log e dati dell'Assistente.
 
-Ogni sessione Ask/chat conserva gli ultimi 8 turni e fino a 20 istruzioni esplicite a lungo termine, separate per `msg.knxAi.sessionId`, `msg.sessionId` o chat ID Telegram rilevato. Richieste come «Ricordati di non usare il termine unknown» diventano istruzioni persistenti. Tutti i nodi KNX AI che usano lo stesso storage condividono questo context in tempo reale e lo ricaricano dopo un riavvio di Node-RED da `knxultimatestorage/knxai/memory/knxai-chat-context.md`. Il file, scritto atomicamente, è limitato a 50 sessioni e 512 KB. Quando il controllo KNX è abilitato, collega l'uscita 3 al nodo di risposta della chat e l'uscita 4 a un nodo KNX Ultimate configurato in **Modalità Universale**. Con la conferma attiva, la prima risposta mostra GA, DPT e payload delle scritture senza emetterle; la stessa sessione deve poi rispondere `CONFERMA`/`ANNULLA` entro 5 minuti. Una nuova richiesta sostituisce l'eventuale piano precedente. Ogni comando confermato contiene `msg.destination`, `msg.dpt`, `msg.payload` e `msg.event = "GroupValue_Write"`.
+Ogni sessione Ask/chat conserva gli ultimi 8 turni e fino a 20 istruzioni a lungo termine scelte dal modello, separate per `msg.knxAi.sessionId`, `msg.sessionId` o chat ID Telegram rilevato. È il modello a decidere semanticamente quando il significato di una conversazione vada ricordato o dimenticato tramite lo strumento di memoria strutturato: non esistono liste di parole chiave o intent linguistici. Tutti i nodi KNX AI che usano lo stesso storage condividono questo context in tempo reale e lo ricaricano dopo un riavvio di Node-RED da `knxultimatestorage/knxai/memory/knxai-chat-context.knxctx`. Il file, scritto atomicamente, è limitato a 50 sessioni e 512 KB. Quando il controllo KNX è abilitato, collega l'uscita 3 al nodo di risposta della chat e l'uscita 4 a un nodo KNX Ultimate configurato in **Modalità Universale**. Con la conferma attiva, la prima risposta mostra GA, DPT e payload delle scritture senza emetterle; la stessa sessione deve poi rispondere `CONFERMA`/`ANNULLA` entro 5 minuti. Una nuova richiesta sostituisce l'eventuale piano precedente. Ogni comando confermato contiene `msg.destination`, `msg.dpt`, `msg.payload` e `msg.event = "GroupValue_Write"`.
+La memoria recente della sessione viene collocata immediatamente accanto alla richiesta corrente, così i modelli locali mantengono fatti forniti dall'utente, come nome preferito o lingua, anche dentro un prompt KNX molto grande. Il modello può rendere persistenti fatti, preferenze e istruzioni durevoli tramite `memoryActions`; resta una scelta semantica dello strumento, senza classificatori di frasi o routing per intent. Credenziali, codici di sicurezza e API key non devono mai essere appresi.
+
 Per le scritture DPT 1.xxx, gli equivalenti sicuri prodotti dall'AI `true`/`false`, `1`/`0` e `on`/`off` vengono normalizzati in un vero booleano prima della validazione locale e dell'uscita.
 
 ### Letture KNX aggiornate
-Quando l'utente chiede esplicitamente uno stato attuale o aggiornato, l'AI può interrogare gli oggetti esatti del catalogo ETS importato, compresi gli oggetti di stato e di sola lettura. L'uscita 4 emette `msg.destination`, `msg.dpt`, `msg.event = "GroupValue_Read"` e `msg.readstatus = true`. Il nodo attende fino a 6 secondi ogni `GroupValue_Response` o scrittura fresca, poi restituisce i valori decodificati sull'uscita 3 e i dettagli in `msg.knxAi.readResults`. Le letture non richiedono mai conferma e non vengono mai trasformate in scritture.
+Quando l'utente chiede esplicitamente uno stato attuale o aggiornato, l'AI può interrogare gli oggetti esatti del catalogo ETS importato, compresi gli oggetti di stato e di sola lettura. L'uscita 4 emette `msg.destination`, `msg.dpt`, `msg.event = "GroupValue_Read"` e `msg.readstatus = true`. Il nodo attende fino a 6 secondi ogni `GroupValue_Response` o scrittura fresca, poi restituisce i valori decodificati sull'uscita 3 e i dettagli in `msg.knxAi.readResults`. Le letture non richiedono mai conferma e non vengono mai trasformate in scritture. Se un piccolo modello locale omette il tipo di operazione e il payload, gli oggetti ETS esatti vengono normalizzati in modo sicuro come letture; un elemento con payload resta una scrittura validata.
 
 ### Routine conversazionali multi-step
 Richieste come «Sto uscendo», «Buonanotte» o «Modalità cinema» possono coordinare una routine basata sullo stato corrente senza aggiungere opzioni all'editor. Nel primo passaggio LLM vengono accettate soltanto letture ETS esatte (massimo 20); KNX AI le invia e passa i risultati aggiornati GA/DPT/valore a un secondo passaggio di pianificazione isolato. Quest'ultimo può preparare fino a 12 scritture validate, ma non può avviare un altro ciclo di letture. Con la conferma attiva, l'intero piano richiede una sola conferma localizzata e nessuna scrittura o annuncio TTS richiesto viene emesso prima. Dopo la conferma ogni scrittura viene rivalidata, inoltrata in ordine e osservata fino a 4 secondi per un feedback immediato corrispondente sul bus. La risposta finale distingue il feedback osservato dalle operazioni senza feedback immediato, senza considerare queste ultime come dispositivi guasti. I dettagli sono disponibili in `msg.knxAi.routine`, `readResults`, `verifiedCount` e `unverifiedCount`.
@@ -42,24 +46,38 @@ Quando un piano è in attesa, l'uscita 3 contiene `msg.knxAi.confirmationRequest
 ### Preset adattatori chat
 La tab **Adattatori chat** carica le mappature selezionabili da `resources/KNXAIChatAdapterMappings.js`. Scegliendo un preset vengono installate internamente due mappature JavaScript sincrone predefinite: una eseguita prima che KNX AI elabori l'ingresso e una prima dell'emissione sull'uscita 3. Le mappature restano nascoste nell'editor. Errori di sintassi o esecuzione vengono intercettati e segnalati senza arrestare Node-RED.
 
-Il preset incluso **windkh/node-red-contrib-telegrambot** segue il contratto receiver/sender del pacchetto. Collega direttamente un `telegram receiver` a KNX AI e l'uscita 3 direttamente a un `telegram sender`; per usare i pulsanti inline di conferma, collega allo stesso ingresso KNX AI anche un `telegram event` configurato come `callback_query`. La mappatura d'ingresso estrae `msg.payload.content`, `msg.payload.chatId` e la lingua Telegram. Quella d'uscita crea i campi richiesti `msg.payload.chatId`, `type` e `content`, aggiungendo `options.reply_markup` da `msg.knxAi.confirmationRequest` quando una scrittura attende conferma. Il pacchetto Telegram resta una dipendenza opzionale separata.
+Il preset incluso **windkh/node-red-contrib-telegrambot** segue il contratto receiver/sender del pacchetto. Collega direttamente un `telegram receiver` a KNX AI e l'uscita 3 direttamente a un `telegram sender`. La conferma usa una tastiera Telegram temporanea: premendo **Conferma** o **Annulla** viene inviato un normale messaggio localizzato attraverso lo stesso receiver, quindi non servono `telegram event` né collegamenti callback. I vecchi messaggi `callback_query` restano accettati. La mappatura d'ingresso estrae `msg.payload.content`, `msg.payload.chatId` e la lingua Telegram. Quella d'uscita crea i campi richiesti `msg.payload.chatId`, `type` e `content`, aggiungendo `options.reply_markup` da `msg.knxAi.confirmationRequest` quando una scrittura attende conferma. Il pacchetto Telegram resta una dipendenza opzionale separata.
 
 Il preset incluso **RedBot / node-red-contrib-chatbot (Telegram)** segue il formato comune dei messaggi RedBot. Collega direttamente `chatbot-telegram-receive` a KNX AI e l'uscita 3 direttamente a `chatbot-telegram-send`; non serve un nodo callback separato perché RedBot converte i postback dei pulsanti inline in normali messaggi in ingresso. La mappatura d'ingresso legge `transport`, `chatId`, `type`, `content` e la lingua Telegram. Quella d'uscita conserva i dati di tracciamento RedBot `originalMessage`, `chat`, `api` e `client`, quindi emette un payload `message` oppure un payload `inline-buttons` con azioni `postback` per la conferma. RedBot resta una dipendenza opzionale separata.
 
 ### Adapter telecamera rilevati automaticamente
 I pacchetti di telecamere installati possono pubblicare a runtime un adapter per KNX AI. Non esistono selettori né nodi telecamera da collegare a KNX AI: adapter, controller e telecamere disponibili vengono rilevati automaticamente e inseriti nel contesto della chat. `node-red-contrib-unifi-ultimate` è il primo provider supportato; altri pacchetti, come `hikvision-ultimate`, possono registrarsi tramite lo stesso contratto indipendente dal produttore.
 
-L'utente può chiedere uno snapshot aggiornato oppure domandare al modello vision che cosa è visibile. I preset Telegram e RedBot inviano l'immagine come foto nativa con didascalia. L'utente può anche creare notifiche persistenti per movimento, attraversamento di una linea intelligente o ingresso in una zona di intrusione/stazionamento, limitandole facoltativamente alle persone rilevate e a una linea o zona nominata esatta. Le regole vengono salvate nello stesso file `knxai-chat-context.md` e ripristinate dopo i riavvii di Node-RED. Le sottoscrizioni agli eventi UniFi e le richieste snapshot avvengono direttamente tramite il provider rilevato: l'uscita 4 di KNX AI non è coinvolta e non servono collegamenti intermedi nel flow.
+L'utente può chiedere uno snapshot aggiornato oppure domandare al modello vision che cosa è visibile. I preset Telegram e RedBot inviano l'immagine come foto nativa con didascalia. L'utente può anche creare notifiche persistenti per movimento, attraversamento di una linea intelligente o ingresso in una zona di intrusione/stazionamento, limitandole facoltativamente alle persone rilevate e a una linea o zona nominata esatta. Le regole vengono salvate nello stesso file `knxai-chat-context.knxctx` e ripristinate dopo i riavvii di Node-RED. Le sottoscrizioni agli eventi UniFi e le richieste snapshot avvengono direttamente tramite il provider rilevato: l'uscita 4 di KNX AI non è coinvolta e non servono collegamenti intermedi nel flow.
 
-Ogni evento pubblicato da un adapter rilevato automaticamente viene normalizzato e aggiunto a un file giornaliero `YYYY-MM-DD.jsonl` sotto `knxultimatestorage/knxai/adapter-history/<id-nodo>/`. L'archivio conserva 10 giorni, garantisce più di 24 ore di storico e salva i metadati degli eventi, non le immagini. Assistente web e canali CHAT lo interrogano insieme all'archivio giornaliero KNX. I totali comprendono tutte le righe memorizzate nell'intervallo richiesto; i dettagli selezionati sono soltanto un campione pertinente.
+Ogni evento pubblicato da un adapter rilevato automaticamente viene normalizzato e aggiunto direttamente nel formato nativo compatto a righe di KNX AI a un file giornaliero `YYYY-MM-DD.knxctx` sotto `knxultimatestorage/knxai/adapter-history/<id-nodo>/`. L'archivio dei telegrammi KNX usa lo stesso formato compatto, senza serializzazione JSON intermedia. L'archivio conserva 10 giorni, garantisce più di 24 ore di storico e salva i metadati degli eventi, non le immagini. Gli archivi JSONL esistenti non vengono letti né migrati. I totali comprendono tutte le righe memorizzate nell'intervallo richiesto; i dettagli selezionati sono soltanto un campione pertinente.
 
 ### Annunci con TTS Ultimate
 Quando è installato il pacchetto opzionale `node-red-contrib-tts-ultimate`, questo compare tra gli adapter rilevati automaticamente. Il selettore elenca tutti i nodi `ttsultimate` presenti in tutti i flow del progetto, indicando flow, nome del nodo e player configurato. Scegli il nodo che deve gestire gli annunci della chat e fai il deploy del flow.
 
-Solo una richiesta esplicita nel messaggio corrente della chat può creare un annuncio. KNX AI invia il testo esatto direttamente al nodo scelto come `msg.payload`, con `msg.topic = "knx_ai_announcement"`; non servono collegamenti intermedi nel flow. TTS Ultimate gestisce poi il player Sonos configurato, voce, volume, hailing e coda. Contesto persistente, Educazione AI, contenuto delle telecamere ed eventi dedotti non attivano mai autonomamente la voce.
+Il modello decide se usare questo adapter ragionando sulla richiesta corrente, sulle istruzioni persistenti della chat e sull'Educazione AI gestita dall'utente: non esistono intent per gli annunci né liste di frasi di attivazione. Valori KNX, eventi degli adapter, immagini e archivi restano dati e non diventano istruzioni, ma le indicazioni autorevoli dell'utente possono insegnare al modello come agire su quei dati. KNX AI invia il testo scelto direttamente al nodo come `msg.payload`, con `msg.topic = "knx_ai_announcement"`; non servono collegamenti intermedi nel flow. TTS Ultimate gestisce poi player Sonos, voce, volume, hailing e coda.
 
 ### Riepilogo del contesto della chat
-L'editor del nodo mostra una scheda compatta con le fonti disponibili alla chat: traffico KNX corrente e archiviato, eventi persistenti degli adapter, semantica ETS e progetto Node-RED, memoria di sessione e domestica, Educazione AI, telecamere rilevate e documentazione pertinente. Elenca anche le directory assolute degli archivi KNX e degli eventi adapter e il formato giornaliero `YYYY-MM-DD.jsonl`.
+L'editor del nodo mostra una scheda compatta con le fonti disponibili alla chat: traffico KNX corrente e archiviato, eventi persistenti degli adapter, semantica ETS e progetto Node-RED, memoria di sessione e domestica, Educazione AI e telecamere rilevate. Mostra anche il contesto operativo massimo scelto dall'utente e il peso UTF-8 effettivo dell'ultimo prompt della chat; quando il provider comunica i token di input viene usato il valore esatto, altrimenti il conteggio è indicato come stima. La scheda elenca le directory assolute degli archivi KNX e degli eventi adapter e il formato giornaliero `YYYY-MM-DD.knxctx`.
+
+Il modello riceve letture e scritture KNX, adapter telecamera, annunci TTS e memoria persistente come strumenti strutturati. Può sceglierli e combinarli semanticamente partendo dalla richiesta corrente e dalle indicazioni autorevoli apprese, senza routing per intent linguistici. Il runtime valida soltanto argomenti, disponibilità degli adapter e confini di sicurezza; le scritture KNX conservano validazione ETS/DPT locale e conferma configurata.
+
+### Modifica e backup dell'apprendimento CHAT
+La scheda **Conversazioni e casa** nella configurazione Node-RED di KNX AI include il pulsante **Apri Apprendimento AI Chat**, che apre la Web UI Vue direttamente su questo editor per il nodo corrente.
+
+Nella UI web Vue, apri **Impostazioni → Apprendimento AI Chat** per visualizzare e modificare il file condiviso esatto `knxai-chat-context.knxctx` e il suo percorso assoluto. Il file può essere copiato, scaricato come backup o ripristinato da un altro file `.knxctx`. **Re-inizializza memoria**, protetto da una conferma esplicita, lo sostituisce con un nuovo contesto vuoto e cancella sessioni, istruzioni, sorveglianze telecamera e conferme chat pendenti in ogni nodo KNX AI che usa lo stesso archivio. I record nativi separati da tabulazioni `KNXAI_CHAT_CONTEXT 3` sono autorevoli e direttamente modificabili: `SESSION` contiene record `INSTRUCTION`, `TURN` e `CAMERA_WATCH` fino a `END_SESSION`. Il salvataggio valida e limita questi record, riscrive atomicamente il file e aggiorna il contesto attivo di ogni nodo KNX AI che usa lo stesso archivio. Un controllo di revisione impedisce di sovrascrivere o azzerare l'apprendimento cambiato dopo il caricamento nell'editor.
+
+È supportato soltanto il formato nativo V3. I precedenti file Markdown/JSON V2 e Base64 V1 non vengono volutamente letti, importati né migrati; il vecchio file `.md` resta intatto e KNX AI avvia un nuovo contesto `.knxctx`. Restano validi i limiti di 50 sessioni e 512 KB.
+
+### Ruoli appresi dei group address KNX
+Il ruolo `neutral` indica un'incertezza iniziale, non un divieto permanente di controllo. Il modello può usare lo strumento strutturato `gaRoleActions` per imparare che un group address ETS esatto è un oggetto di comando, stato o neutro partendo dall'insegnamento autorevole dell'utente, dalle indicazioni persistenti della chat, dall'Educazione AI o da una semantica inequivocabile del progetto ETS. Non servono parole chiave né intent di ruolo; se le prove sono ambigue, il modello chiede un chiarimento invece di imparare.
+
+Ruolo, motivazione e prova appresi vengono salvati per nodo in `<userDir>/knxai/config/knxai-config-<id-nodo>.json` e sincronizzati nella memoria semantica domestica limitata. Un ruolo appreso come `command` può rendere valida una scrittura già nella stessa risposta e resta disponibile dopo il riavvio; il modello può anche dimenticarlo e ripristinare la classificazione automatica. L'apprendimento non può inventare un GA, cambiarne il DPT ETS, aggirare la validazione del payload o saltare la conferma di scrittura configurata.
 
 ## Intelligenza domestica proattiva guidata dall'Educazione e memoria limitata
 Da gerarchia ETS, nomi, ruoli e DPT, il nodo crea un modello semantico deterministico per persiane, finestre, porte, luci, temperatura, clima, presenza e allarmi usando termini italiani, inglesi, tedeschi, francesi, spagnoli e cinesi. Il rilevatore proattivo osserva soltanto stati non di comando di persiane, finestre e porte riconosciuti con sufficiente affidabilità.
@@ -120,7 +138,7 @@ Di seguito sono elencati tutti i campi presenti nell'editor del nodo KNX AI.
 - **Chiedi conferma prima di inviare comandi KNX**: attivo per default. Mostra prima le modifiche validate e non emette comandi KNX finché la stessa sessione chat non le conferma. Quando ci sono comandi in attesa, la risposta aggiunge sempre le istruzioni esatte per confermare o annullare nella lingua della richiesta corrente. I comandi vengono validati nuovamente subito prima dell'uscita.
 - **Preset adattatore**: parte da **Nessun adattatore**. La selezione carica la coppia predefinita di mappature ingresso/uscita; entrambe restano nascoste nell'editor.
 - **Educazione AI**: istruzioni autorevoli gestite soltanto dall'utente, lette dall'AI e mai modificate. È anche l'unico punto in cui richiedere notifiche proattive e definirne condizioni, durata, ore silenziose e ripetizione.
-- Gli estratti pertinenti di help, README ed esempi vengono sempre inclusi automaticamente; la lingua viene ricavata dalla richiesta dell'utente, con fallback automatici fra tutte le lingue supportate.
+- Gli estratti inclusi nel pacchetto da help, README, changelog, wiki ed esempi non vengono inviati nei prompt di Telegram, RedBot o CHAT personalizzate. Restano disponibili soltanto all'Assistente web per le domande tecniche sul pacchetto.
 - Pulsante **Aggiorna**: interroga il provider e popola i modelli disponibili. Durante il caricamento l'icona ruota; il completamento corretto non mostra messaggi.
 
 ### Setup rapido Ollama (locale)
@@ -131,6 +149,7 @@ Di seguito sono elencati tutti i campi presenti nell'editor del nodo KNX AI.
   - **2) Installalo**: scarica e installa localmente il modello (esempio `llama3.1`).
 - Durante refresh/installazione, KNX AI prova anche ad avviare automaticamente il server Ollama quando possibile.
 - Se l'installazione fallisce per errore di connessione, verifica che Ollama sia avviato (app desktop o `ollama serve`).
+- Il contesto massimo dichiarato da `/api/show` resta informativo. KNX AI invia come `num_ctx` il budget scelto di 4K, 8K o 16K (oppure il massimo del modello se inferiore) e limita proporzionalmente ogni fonte di contesto senza rimuovere capacità dell'agente.
 - Se Node-RED gira in Docker, usa `host.docker.internal` al posto di `localhost` nell'endpoint.
 
 ### Setup rapido Bionic LM Studio (locale)
@@ -138,6 +157,7 @@ Di seguito sono elencati tutti i campi presenti nell'editor del nodo KNX AI.
 - Avvia il server API di LM Studio dalla pagina **Developer** oppure con `lms server start`.
 - Endpoint predefinito: `http://localhost:1234/v1/chat/completions`.
 - Premi **Aggiorna** per caricare tutti i modelli esposti da `/v1/models`; se non è configurato un modello viene selezionato il primo.
+- Se un modello è già caricato, KNX AI conserva la lunghezza del contesto attiva. KNX AI non carica mai un modello Bionic inattivo tramite l'API di gestione: la prima richiesta chat lascia che Bionic lo carichi JIT con i valori predefiniti salvati per il modello. Indipendentemente dal contesto dichiarato da Bionic, KNX AI usa il budget prompt scelto di 4K, 8K o 16K e mantiene disponibili ragionamento, KNX, routine, telecamere e TTS.
 - La API key è opzionale, salvo autenticazione attiva nelle impostazioni del server LM Studio. In Docker sostituisci `localhost` con `host.docker.internal`.
 
 ## Nota sicurezza

package/nodes/locales/it/knxUltimateAI.json

@@ -6,6 +6,7 @@
       "groupChatHome": "Conversazioni e casa",
       "detectedAdapters": "Adapter rilevati automaticamente",
       "chatContextOverview": "Contesto disponibile alla chat",
+      "chatLearning": "Apprendimento AI Chat",
       "quickSetup": "Configurazione assistente",
       "llmConnection": "Connessione Assistente AI",
       "chatAdapter": "Canali chat",
@@ -21,6 +22,7 @@
       "llmBaseUrl": "URL endpoint",
       "llmApiKey": "API key",
       "llmModel": "Modello",
+      "llmPromptContextTokens": "Quantità contesto chat",
       "llmSystemPrompt": "Prompt di sistema",
       "llmIncludeRaw": "Includi payload raw in hex",
       "llmAllowKnxCommands": "Consenti all'AI di leggere stati KNX e comandare attuatori",
@@ -45,6 +47,11 @@
         "ollama": "Ollama (locale)",
         "lmstudio": "Bionic LM Studio"
       },
+      "promptContext": {
+        "small": "Ridotto (4K, più veloce)",
+        "medium": "Medio (8K)",
+        "full": "Completo (16K)"
+      },
       "chatAdapter": {
         "none": "Nessun adattatore"
       },
@@ -57,16 +64,20 @@
       "refreshModels": "Aggiorna",
       "installOllamaModel": "2) Installalo",
       "ollamaLibrary": "Libreria modelli",
-      "downloadOllamaModel": "1) Scarica il modello"
+      "downloadOllamaModel": "1) Scarica il modello",
+      "openChatLearning": "Apri Apprendimento AI Chat"
     },
     "messages": {
       "loadingModels": "Carico i modelli…",
       "loadedModels": "Modelli caricati",
       "lmStudioContextAvailable": "Contesto massimo del modello",
-      "lmStudioContextLoading": "Caricamento del modello con il contesto massimo",
-      "lmStudioContextConfigured": "Contesto massimo del modello configurato",
+      "lmStudioContextLoading": "Verifica del contesto attivo del modello",
+      "lmStudioContextInactive": "Modello inattivo; alla prima richiesta verranno usati i valori predefiniti di Bionic",
+      "lmStudioContextConfigured": "Contesto attivo del modello",
       "lmStudioContextFailed": "Impossibile configurare il contesto del modello",
       "lmStudioContextCurrentlyLoaded": "attualmente caricato",
+      "localContextBudget": "Budget contesto KNX AI",
+      "promptContextHint": "Controlla la quantità di contesto KNX, memoria, progetto e adapter inviata ai modelli locali. Non abilita o disabilita strumenti e non usa intent linguistici.",
       "ollamaNotSupported": "Modalita locale Ollama: API key non richiesta. Endpoint predefinito: http://localhost:11434/api/chat.",
       "ollamaNoModels": "Nessun modello Ollama locale trovato. Installa un modello o scegli dalla libreria.",
       "installingOllamaModel": "Avvio Ollama e installo il modello…",
@@ -86,7 +97,16 @@
       "ttsUltimateHint": "Le richieste esplicite di annuncio della chat vengono inviate direttamente al nodo scelto; non servono collegamenti nel flow.",
       "chatContextLoading": "Caricamento del riepilogo del contesto…",
       "chatContextUnavailable": "Il riepilogo del contesto della chat non è momentaneamente disponibile.",
+      "chatLearningOpenHint": "Apri la Web UI direttamente nell’editor dell’apprendimento CHAT condiviso per visualizzare, modificare, copiare o salvare il suo file persistente.",
       "chatContextIntro": "La chat riceve automaticamente queste fonti. I percorsi sottostanti sono quelli effettivi usati da questa installazione Node-RED.",
+      "chatContextLimitLabel": "Contesto operativo massimo",
+      "chatContextProviderManaged": "gestito dal provider/modello selezionato",
+      "chatContextTokens": "token",
+      "chatContextLastPromptLabel": "Peso effettivo dell'ultimo prompt della chat",
+      "chatContextLastPromptUnavailable": "non disponibile fino alla prima richiesta della chat",
+      "chatContextExactInputTokens": "token di input misurati dal provider",
+      "chatContextEstimatedInputTokens": "token di input stimati",
+      "chatContextImages": "immagini",
       "chatContextSourcesTitle": "Fonti incluse",
       "chatContextFilesTitle": "File persistenti di contesto",
       "chatContextDirectoriesTitle": "Archivio telegrammi KNX",
@@ -94,7 +114,7 @@
       "chatContextSourceAdapterHistory": "Storico giornaliero persistente degli eventi degli adapter rilevati, comprese le rilevazioni delle telecamere.",
       "chatContextSourceEtsProject": "Semantica ETS e inventario completo del progetto Node-RED.",
       "chatContextSourceMemoryEducation": "Contesto di sessione, Educazione AI e memoria domestica limitata.",
-      "chatContextSourceCamerasDocs": "Telecamere rilevate ed estratti pertinenti da help, README ed esempi.",
+      "chatContextSourceCameras": "Telecamere rilevate e relative funzionalità disponibili.",
       "chatContextSourceTtsUltimate": "Nodo TTS Ultimate selezionato per gli annunci.",
       "chatContextSourceBadge": "Fonte",
       "chatContextFileChatContext": "Turni persistenti, istruzioni e regole di notifica delle telecamere.",

package/nodes/locales/zh-CN/knxUltimateAI.html

@@ -25,13 +25,17 @@
 
 Ollama 和 Bionic LM Studio 请求会自动使用至少 10 分钟的超时时间；云端提供商仍使用至少 2 分钟。编辑器中无需维护超时字段。即使达到本地模型限制，KNX AI 也会说明模型未完成响应，并建议重试或缩减提示上下文。
 
+对于本地提供商，**聊天上下文量**可明确选择 4K、8K 或 16K；默认仍为 16K。该选择会按比例限制发送给模型的 KNX、记忆、Node-RED 项目和适配器数据，同时保留完整的代理工具协议。任何能力都不会因措辞、关键词或语言 intent 而被启用或禁用。
+
 Canvas 上的节点状态专门用于显示最近收到的请求，以及 LLM 运行期间本地化的“我正在思考…”状态。KNX 报文、网关更新、流量速率、ready 消息和技术结果绝不会覆盖该状态；这些信息仍可通过节点输出、日志和助手数据查看。
 
-每个 Ask/聊天会话都会保留最近 8 轮对话和最多 20 条明确的长期指令，并按 `msg.knxAi.sessionId`、`msg.sessionId` 或检测到的 Telegram 聊天 ID 隔离。像“请记住不要在回答中使用 unknown 这个词”这样的请求会成为持久指令。使用相同存储的所有 KNX AI 节点实时共享此上下文，并在 Node-RED 重启后从 `knxultimatestorage/knxai/memory/knxai-chat-context.md` 重新加载。该文件采用原子写入，最多保存 50 个会话且不超过 512 KB。启用 KNX 控制后，将输出 3 连接到聊天发送节点，将输出 4 连接到配置为**通用模式**的 KNX Ultimate 节点。启用确认后，第一条回复会显示 GA、DPT 和 payload，但不会发送写入；同一会话必须在 5 分钟内回复“确认”或“取消”。新请求会替换旧的待处理计划。每条已确认命令都包含 `msg.destination`、`msg.dpt`、`msg.payload` 和 `msg.event = "GroupValue_Write"`。
+每个 Ask/聊天会话都会保留最近 8 轮对话和最多 20 条由模型选择的长期指令，并按 `msg.knxAi.sessionId`、`msg.sessionId` 或检测到的 Telegram 聊天 ID 隔离。模型通过结构化记忆工具，按语义判断一段对话的含义应被记住还是遗忘；系统不使用语言关键词或 intent 列表。使用相同存储的所有 KNX AI 节点实时共享此上下文，并在 Node-RED 重启后从 `knxultimatestorage/knxai/memory/knxai-chat-context.knxctx` 重新加载。该文件采用原子写入，最多保存 50 个会话且不超过 512 KB。启用 KNX 控制后，将输出 3 连接到聊天发送节点，将输出 4 连接到配置为**通用模式**的 KNX Ultimate 节点。启用确认后，第一条回复会显示 GA、DPT 和 payload，但不会发送写入；同一会话必须在 5 分钟内回复“确认”或“取消”。新请求会替换旧的待处理计划。每条已确认命令都包含 `msg.destination`、`msg.dpt`、`msg.payload` 和 `msg.event = "GroupValue_Write"`。
+最近的会话记忆会紧邻当前请求放置，使本地模型即使面对很大的 KNX 提示，也能保留用户提供的事实，例如首选姓名或语言。模型可以通过 `memoryActions` 持久保存耐久的事实、偏好和指令；这仍是没有短语分类器或 intent 路由的语义工具选择。凭据、安全代码和 API 密钥绝不能被学习。
+
 对于 DPT 1.xxx 写入，AI 生成的安全等价值 `true`/`false`、`1`/`0` 和 `on`/`off` 会在本地校验和输出前统一转换为真正的布尔值。
 
 ### 最新 KNX 读取
-当用户明确要求当前或最新状态时，AI 可以查询已导入 ETS 目录中的精确对象，包括状态对象和其他只读对象。输出 4 会发送 `msg.destination`、`msg.dpt`、`msg.event = "GroupValue_Read"` 和 `msg.readstatus = true`。节点会为每个 `GroupValue_Response` 或最新写入等待最多 6 秒，然后在输出 3 返回解码值，并在 `msg.knxAi.readResults` 中提供详细信息。读取从不需要确认，也绝不会转换为写入。
+当用户明确要求当前或最新状态时，AI 可以查询已导入 ETS 目录中的精确对象，包括状态对象和其他只读对象。输出 4 会发送 `msg.destination`、`msg.dpt`、`msg.event = "GroupValue_Read"` 和 `msg.readstatus = true`。节点会为每个 `GroupValue_Response` 或最新写入等待最多 6 秒，然后在输出 3 返回解码值，并在 `msg.knxAi.readResults` 中提供详细信息。读取从不需要确认，也绝不会转换为写入。如果小型本地模型省略操作类型和 payload，精确的 ETS 对象会被安全规范化为读取；包含 payload 的项目仍作为经过验证的写入处理。
 
 ### 多步骤对话例行程序
 “我要离家”“晚安”或“影院模式”等请求可以在不增加编辑器选项的情况下，根据当前状态协调例行程序。第一次 LLM 处理仅接受精确的 ETS 读取（最多 20 个）；KNX AI 发送读取，并把最新的 GA/DPT/值结果交给隔离的第二次规划处理。第二次处理最多可准备 12 个已验证写入，但不能再次发起读取循环。启用确认时，整个计划只需一次本地化确认；确认前不会发送任何写入或所请求的 TTS 播报。确认后，每个写入都会重新验证、按顺序转发，并在最多 4 秒内观察总线上匹配的即时反馈。最终回复会区分已观察到反馈的操作与没有即时反馈的操作，但不会把后者报告为设备故障。详细信息位于 `msg.knxAi.routine`、`readResults`、`verifiedCount` 和 `unverifiedCount`。
@@ -42,24 +46,38 @@ Canvas 上的节点状态专门用于显示最近收到的请求，以及 LLM
 ### 聊天适配器预设
 **聊天适配器**选项卡从 `resources/KNXAIChatAdapterMappings.js` 加载可选映射。选择预设会在内部安装两段预定义的同步 JavaScript 映射：一段在 KNX AI 处理输入前运行，另一段在输出 3 发出消息前运行。这些映射在编辑器中始终保持隐藏。语法和执行错误会被捕获并报告，不会停止 Node-RED。
 
-随附的 **windkh/node-red-contrib-telegrambot** 预设遵循该包的 receiver/sender 消息约定。把 `telegram receiver` 直接连接到 KNX AI，并把输出 3 直接连接到 `telegram sender`。如需内联确认按钮，还要把配置为 `callback_query` 的 `telegram event` 连接到同一个 KNX AI 输入。输入映射会提取 `msg.payload.content`、`msg.payload.chatId` 和 Telegram 语言；输出映射会创建所需的 `msg.payload.chatId`、`type` 和 `content`，并在写入等待确认时从 `msg.knxAi.confirmationRequest` 添加 `options.reply_markup`。Telegram 包仍是独立的可选依赖项。
+随附的 **windkh/node-red-contrib-telegrambot** 预设遵循该包的 receiver/sender 消息约定。把 `telegram receiver` 直接连接到 KNX AI，并把输出 3 直接连接到 `telegram sender`。确认操作使用一次性 Telegram 回复键盘：点击**确认**或**取消**后，会通过同一个 receiver 返回普通的本地化消息，因此不需要 `telegram event` 或 callback 连线。旧的 `callback_query` 消息仍可接受。输入映射会提取 `msg.payload.content`、`msg.payload.chatId` 和 Telegram 语言；输出映射会创建所需的 `msg.payload.chatId`、`type` 和 `content`，并在写入等待确认时从 `msg.knxAi.confirmationRequest` 添加 `options.reply_markup`。Telegram 包仍是独立的可选依赖项。
 
 随附的 **RedBot / node-red-contrib-chatbot (Telegram)** 预设遵循 RedBot 的通用消息格式。将 `chatbot-telegram-receive` 直接连接到 KNX AI，并将输出 3 直接连接到 `chatbot-telegram-send`；无需单独的 callback 节点，因为 RedBot 会把内联按钮的 postback 转换成普通入站消息。输入映射读取 `transport`、`chatId`、`type`、`content` 和 Telegram 语言。输出映射保留 RedBot 的 `originalMessage`、`chat`、`api` 和 `client` 跟踪数据，然后发送 `message` payload，或发送带有确认 `postback` 操作的 `inline-buttons` payload。RedBot 仍是独立的可选依赖项。
 
 ### 自动检测的摄像机适配器
 已安装的摄像机软件包可以在运行时向 KNX AI 发布适配器。无需选择器，也无需将摄像机节点连接到 KNX AI：可用的适配器、控制器和摄像机会被自动检测并加入聊天上下文。`node-red-contrib-unifi-ultimate` 是首个受支持的提供方；`hikvision-ultimate` 等其他软件包可通过同一套厂商无关协议注册。
 
-用户可以请求当前快照，或询问视觉模型画面中可见的内容。Telegram 和 RedBot 预设会把图像作为带说明文字的原生照片发送。用户还可以为移动、智能越线或进入入侵/徘徊区域创建持久通知，并可按检测到的人员以及指定名称的线或区域进行限制。这些规则保存在同一个 `knxai-chat-context.md` 文件中，并在 Node-RED 重启后恢复。UniFi 事件订阅和快照请求直接通过检测到的提供方完成；不会使用 KNX AI 输出 4，也不需要中间 Flow 连线。
+用户可以请求当前快照，或询问视觉模型画面中可见的内容。Telegram 和 RedBot 预设会把图像作为带说明文字的原生照片发送。用户还可以为移动、智能越线或进入入侵/徘徊区域创建持久通知，并可按检测到的人员以及指定名称的线或区域进行限制。这些规则保存在同一个 `knxai-chat-context.knxctx` 文件中，并在 Node-RED 重启后恢复。UniFi 事件订阅和快照请求直接通过检测到的提供方完成；不会使用 KNX AI 输出 4，也不需要中间 Flow 连线。
 
-自动检测到的适配器发布的每个事件都会被标准化，并追加到 `knxultimatestorage/knxai/adapter-history/<节点ID>/` 下的每日 `YYYY-MM-DD.jsonl` 文件。存档保留 10 天，保证超过 24 小时的历史，只保存事件元数据，不保存图像。Web 助手和所有 CHAT 渠道会同时查询它与每日 KNX 报文存档。总数涵盖所请求区间内的全部存档行；选出的详情仅是相关样本。
+自动检测到的适配器发布的每个事件都会被标准化，并以 KNX AI 原生紧凑行格式直接追加到 `knxultimatestorage/knxai/adapter-history/<节点ID>/` 下的每日 `YYYY-MM-DD.knxctx` 文件。KNX 报文存档使用相同的紧凑格式，不经过中间 JSON 序列化。存档保留 10 天，保证超过 24 小时的历史，只保存事件元数据，不保存图像。现有 JSONL 存档不会被读取或迁移。总数涵盖所请求区间内的全部存档行；选出的详情仅是相关样本。
 
 ### 使用 TTS Ultimate 播报
 安装可选软件包 `node-red-contrib-tts-ultimate` 后，它会显示在自动检测的适配器中。选择器会列出项目所有 Flow 中的全部 `ttsultimate` 节点，并显示 Flow、节点名称和已配置的播放器。请选择负责聊天播报的节点，然后部署 Flow。
 
-只有当前聊天消息中的明确请求才能创建播报。KNX AI 会将准确文本作为 `msg.payload` 直接发送到所选节点，并设置 `msg.topic = "knx_ai_announcement"`；无需在 Flow 中增加中间连线。之后由 TTS Ultimate 处理已配置的 Sonos 播放器、语音、音量、提示音和队列。持久上下文、AI 教育、摄像机内容和推断事件绝不会自行触发语音。
+模型会根据当前请求、持久聊天指令和用户管理的 AI 教育自行判断是否使用此适配器；系统没有播报 intent，也没有触发短语列表。KNX 数值、适配器事件、图像和存档始终是数据而不是指令，但可信的用户指导可以教会模型如何处理这些数据。KNX AI 会将选定文本作为 `msg.payload` 直接发送到所选节点，并设置 `msg.topic = "knx_ai_announcement"`；之后由 TTS Ultimate 处理 Sonos 播放器、语音、音量、提示音和队列。
 
 ### 聊天上下文概览
-节点编辑器会显示一张紧凑卡片，汇总聊天可用的来源：当前 KNX 流量、ETS 语义与 Node-RED 项目、会话和家庭记忆、AI 教育、检测到的摄像机及相关文档。卡片还会列出 `knxai-chat-context.md`、`knxai-home-memory.md` 和 `knxai-config-<节点-id>.json`，以及 KNX 报文归档的绝对根目录、该节点专用目录和每日文件模式 `YYYY-MM-DD.jsonl`。这些路径会在运行时根据已配置网关实际使用的数据目录解析。
+节点编辑器会显示一张紧凑卡片，汇总聊天可用的来源：当前 KNX 流量、ETS 语义与 Node-RED 项目、会话和家庭记忆、AI 教育及检测到的摄像机。卡片还会显示用户选择的最大运行上下文和上次聊天提示词的实际 UTF-8 大小；提供商返回输入令牌数时使用精确值，否则明确标为估算值。卡片还会列出 `knxai-chat-context.knxctx`、`knxai-home-memory.md` 和 `knxai-config-<节点-id>.json`，以及 KNX 报文归档的绝对根目录、该节点专用目录和每日文件模式 `YYYY-MM-DD.knxctx`。这些路径会在运行时根据已配置网关实际使用的数据目录解析。
+
+模型会把 KNX 读写、摄像机适配器、TTS 播报和持久记忆作为结构化工具。它可以依据当前请求和可信的已学习指导进行语义选择与组合，而不经过语言 intent 路由。运行时只验证工具参数、适配器可用性和安全边界；KNX 写入仍保留本地 ETS/DPT 校验和已配置的确认步骤。
+
+### 编辑和备份聊天学习
+Node-RED 的 KNX AI 配置中，**对话与家庭**选项卡包含**打开 AI 聊天学习**按钮；它会为当前节点直接打开 Vue Web UI 中的此编辑器。
+
+在 Vue Web UI 中打开**设置 → AI 聊天学习**，即可查看和编辑准确的共享文件 `knxai-chat-context.knxctx` 及其绝对路径。可复制该文件、下载备份，或从另一个 `.knxctx` 文件恢复。**重新初始化记忆**操作受明确确认保护；它会用新的空白上下文替换该文件，并清除使用同一存储的所有 KNX AI 节点中的已保存会话、指令、摄像机监视和待处理聊天确认。以制表符分隔的原生 `KNXAI_CHAT_CONTEXT 3` 记录是权威数据，并可直接编辑：`SESSION` 包含 `INSTRUCTION`、`TURN` 和 `CAMERA_WATCH` 记录，直至 `END_SESSION`。保存时会验证并限制这些记录、以原子方式重写文件，并立即更新所有相关节点的活动上下文。修订检查会拒绝覆盖或重置编辑器加载后又发生变化的学习内容。
+
+仅支持原生 V3 格式。旧版 Markdown/JSON V2 和 Base64 V1 文件不会被读取、导入或迁移；旧的 `.md` 文件保持不变，KNX AI 会启动新的 `.knxctx` 上下文。仍保留 50 个会话和 512 KB 的限制。
+
+### 学习到的 KNX 组地址角色
+`neutral` 角色表示初始不确定性，而不是永久禁止控制。模型可以使用结构化工具 `gaRoleActions`，根据可信的用户教学、持久聊天指导、AI 教育或明确无歧义的 ETS 项目语义，学习某个准确的 ETS 组地址属于命令、状态或中性对象。无需固定关键词或角色 intent；如果证据不明确，模型会先询问澄清，而不会擅自学习。
+
+学习到的角色、原因和证据会按节点保存到 `<userDir>/knxai/config/knxai-config-<节点-id>.json`，并同步到受限的家庭语义记忆。学习为 `command` 的角色可以在同一条回复中使写入通过验证，并在重启后继续可用；模型也可以忘记它并恢复自动分类。学习过程不能虚构 GA、修改其 ETS DPT、绕过 payload 校验或跳过已配置的写入确认。
 
 ## 由 AI 教育驱动的主动家庭智能与有限记忆
 节点会根据 ETS 层级、名称、角色和 DPT 建立确定性的语义模型。不再提供单独的开关或高级主动通知设置。只有启用 LLM 且 **AI 教育**明确要求时，系统才会评估通知。条件、持续时间、静默时段和重复频率完全由 AI 教育定义。没有明确规则或 LLM 无法评估时，不会发送任何消息。
@@ -114,7 +132,7 @@ Canvas 上的节点状态专门用于显示最近收到的请求，以及 LLM
 - **发送 KNX 命令前请求确认**：默认启用。先显示已验证的修改，在同一聊天会话确认前不会发送任何 KNX 命令。有命令等待确认时，回复始终会使用当前请求的语言附加准确的确认或取消说明。命令会在输出前再次验证。
 - **适配器预设**：默认为**无适配器**。选择后会加载预定义的输入和输出映射；两者在编辑器中始终保持隐藏。
 - **AI 教育**：仅由用户管理的权威指导，AI 可以读取但永远不能修改。主动通知及其条件、持续时间、静默时段和重复频率只能在这里定义。
-- 相关的帮助、README 和示例片段始终会自动包含；系统会从用户请求中自动识别语言，并在所有受支持语言之间自动回退。
+- 软件包附带的帮助、README、更新日志、Wiki 和示例片段不会加入 Telegram、RedBot 或自定义 CHAT 的提示词；仅网页助手在回答软件包技术问题时仍可使用这些内容。
 - **Refresh** 按钮：请求 provider 并加载可用模型 ID。加载期间图标会旋转；成功完成时不会显示额外消息。
 
 ### Ollama 快速配置（本地）
@@ -125,6 +143,7 @@ Canvas 上的节点状态专门用于显示最近收到的请求，以及 LLM
   - **2) Install it**：在本机下载并安装模型（例如 `llama3.1`）。
 - 在刷新/安装模型时，KNX AI 也会在可能情况下尝试自动启动 Ollama 服务。
 - 若安装因连接错误失败，请确认 Ollama 已运行（桌面应用或 `ollama serve`）。
+- `/api/show` 报告的最大上下文仅用于显示。KNX AI 会将所选的 4K、8K 或 16K 预算作为 `num_ctx` 发送（若模型最大值更小则使用该值），并按比例限制每个上下文来源，同时保留代理能力。
 - 若 Node-RED 运行在 Docker 中，endpoint 请使用 `host.docker.internal` 替代 `localhost`。
 
 ### Bionic LM Studio 快速配置（本地）
@@ -132,6 +151,7 @@ Canvas 上的节点状态专门用于显示最近收到的请求，以及 LLM
 - 在 LM Studio 的 **Developer** 页面启动 API 服务，或运行 `lms server start`。
 - 默认 endpoint：`http://localhost:1234/v1/chat/completions`。
 - 点击 **Refresh** 加载 `/v1/models` 提供的全部模型；未配置模型时会自动选择第一个。
+- 如果模型已加载，KNX AI 会保留其当前上下文长度。KNX AI 不会通过管理 API 加载未运行的 Bionic 模型：首次聊天请求会让 Bionic 根据该模型已保存的默认值进行 JIT 加载。无论 Bionic 报告的上下文是多少，KNX AI 都会使用所选的 4K、8K 或 16K 提示预算，并保留推理、KNX、例程、摄像头和 TTS 能力。
 - 除非在 LM Studio 服务设置中启用了身份验证，否则 API Key 可留空。在 Docker 中请将 `localhost` 替换为 `host.docker.internal`。
 
 ## 安全说明

package/nodes/locales/zh-CN/knxUltimateAI.json

@@ -6,6 +6,7 @@
       "groupChatHome": "对话与家庭",
       "detectedAdapters": "自动检测到的适配器",
       "chatContextOverview": "聊天上下文概览",
+      "chatLearning": "AI 聊天学习",
       "quickSetup": "助手配置",
       "llmConnection": "AI 助手连接",
       "chatAdapter": "聊天渠道",
@@ -21,6 +22,7 @@
       "llmBaseUrl": "Endpoint URL",
       "llmApiKey": "API key",
       "llmModel": "Model",
+      "llmPromptContextTokens": "聊天上下文量",
       "llmSystemPrompt": "System prompt",
       "llmIncludeRaw": "Include raw payload hex",
       "llmAllowKnxCommands": "允许 AI 读取 KNX 状态并控制执行器",
@@ -45,6 +47,11 @@
         "ollama": "Ollama（本地）",
         "lmstudio": "Bionic LM Studio"
       },
+      "promptContext": {
+        "small": "精简（4K，更快）",
+        "medium": "中等（8K）",
+        "full": "完整（16K）"
+      },
       "chatAdapter": {
         "none": "无适配器"
       },
@@ -55,10 +62,13 @@
     },
     "messages": {
       "lmStudioContextAvailable": "模型最大上下文",
-      "lmStudioContextLoading": "正在以最大上下文加载模型",
-      "lmStudioContextConfigured": "已配置模型最大上下文",
+      "lmStudioContextLoading": "正在检查模型的当前上下文",
+      "lmStudioContextInactive": "模型未运行；首次请求时将使用 Bionic 默认值",
+      "lmStudioContextConfigured": "模型当前上下文",
       "lmStudioContextFailed": "无法配置模型上下文",
       "lmStudioContextCurrentlyLoaded": "当前已加载",
+      "localContextBudget": "KNX AI 上下文预算",
+      "promptContextHint": "控制发送给本地模型的 KNX、记忆、项目和适配器上下文量。它不会启用或禁用工具，也不使用 intent 路由。",
       "ollamaNotSupported": "Ollama local mode: API key not required. Default endpoint is http://localhost:11434/api/chat.",
       "ollamaNoModels": "No local Ollama model found. Install one or pick one from the library.",
       "installingOllamaModel": "Starting Ollama and installing model…",
@@ -78,7 +88,16 @@
       "ttsUltimateHint": "聊天中的明确播报请求会直接发送到所选节点，无需在 Flow 中额外连线。",
       "chatContextLoading": "正在加载聊天上下文摘要…",
       "chatContextUnavailable": "聊天上下文摘要暂时不可用。",
+      "chatLearningOpenHint": "直接在 Web UI 中打开共享 CHAT 学习编辑器，以查看、编辑、复制或备份其持久文件。",
       "chatContextIntro": "聊天会自动接收这些来源。以下路径是此 Node-RED 安装实际使用的路径。",
+      "chatContextLimitLabel": "最大运行上下文",
+      "chatContextProviderManaged": "由所选提供商/模型管理",
+      "chatContextTokens": "令牌",
+      "chatContextLastPromptLabel": "上次聊天提示词的实际大小",
+      "chatContextLastPromptUnavailable": "首次聊天请求前不可用",
+      "chatContextExactInputTokens": "提供商测量的输入令牌",
+      "chatContextEstimatedInputTokens": "估算输入令牌",
+      "chatContextImages": "图像",
       "chatContextSourcesTitle": "包含的来源",
       "chatContextFilesTitle": "持久化上下文文件",
       "chatContextDirectoriesTitle": "KNX 报文归档",
@@ -86,7 +105,7 @@
       "chatContextSourceAdapterHistory": "自动检测到的适配器事件的持久每日历史记录，包括摄像机检测事件。",
       "chatContextSourceEtsProject": "ETS 语义和完整的 Node-RED 项目清单。",
       "chatContextSourceMemoryEducation": "会话上下文、AI 教育和有界家庭记忆。",
-      "chatContextSourceCamerasDocs": "检测到的摄像机以及相关帮助、README 和示例片段。",
+      "chatContextSourceCameras": "检测到的摄像机及其可用功能。",
       "chatContextSourceTtsUltimate": "已选择用于播报的 TTS Ultimate 节点。",
       "chatContextSourceBadge": "来源",
       "chatContextFileChatContext": "持久化对话轮次、指令和摄像机通知规则。",
@@ -162,7 +181,8 @@
     "buttons": {
       "installOllamaModel": "2) Install it",
       "ollamaLibrary": "Model library",
-      "downloadOllamaModel": "1) Download model"
+      "downloadOllamaModel": "1) Download model",
+      "openChatLearning": "打开 AI 聊天学习"
     }
   }
 }