node-red-contrib-knx-ultimate 6.4.1 → 7.0.0

package/nodes/locales/es/knxUltimateAI.json

@@ -1,6 +1,6 @@
 {
   "knxUltimateAI": {
-    "title": "KNX AI (Traffic Analyzer)",
+    "title": "Nodo de IA heredado — usa Cerebrum Ultimate",
     "sections": {
       "groupAssistant": "Asistente IA",
       "groupChatHome": "Cerebrum (BETA)",
@@ -35,8 +35,8 @@
       "webAccessEnabled": "Permitir que la IA use la Web",
       "webMaxCallsPerHour": "Máximo de llamadas Web por hora",
       "chatAdapterPreset": "Adaptador de mensajes de entrada/salida",
-      "chatInputCode": "Mapeo de entrada (chat → KNX AI)",
-      "chatOutputCode": "Mapeo de salida (KNX AI → chat)",
+      "chatInputCode": "Mapeo de entrada (chat → Cerebrum Ultimate)",
+      "chatOutputCode": "Mapeo de salida (Cerebrum Ultimate → chat)",
       "aiEducation": "Educación IA (gestionada por el usuario)"
     },
     "outputs": {
@@ -95,7 +95,7 @@
       "lmStudioContextConfigured": "Contexto activo del modelo",
       "lmStudioContextFailed": "No se pudo configurar el contexto del modelo",
       "lmStudioContextCurrentlyLoaded": "cargado actualmente",
-      "etsAccessHint": "Selecciona las direcciones de grupo disponibles para KNX AI. Todas las direcciones seleccionadas están activas y se pueden leer; todas las direcciones seleccionadas no marcadas como Solo lectura se pueden escribir. Los proveedores cloud reciben todo el catálogo ETS semántico seleccionado; los modelos locales reciben lo que cabe en la ventana de contexto elegida y pueden recuperar localmente los detalles que falten.",
+      "etsAccessHint": "Selecciona las direcciones de grupo disponibles para Cerebrum Ultimate. Todas las direcciones seleccionadas están activas y se pueden leer; todas las direcciones seleccionadas no marcadas como Solo lectura se pueden escribir. Los proveedores cloud reciben todo el catálogo ETS semántico seleccionado; los modelos locales reciben lo que cabe en la ventana de contexto elegida y pueden recuperar localmente los detalles que falten.",
       "etsFilterPlaceholder": "Filtrar por nombre, GA o DPT…",
       "etsSelected": "seleccionadas",
       "etsReadOnly": "Solo lectura",
@@ -103,7 +103,7 @@
       "etsNoGateway": "Selecciona una pasarela KNX.",
       "etsNoGa": "No se encontraron direcciones de grupo. Importa la lista ETS en la pasarela KNX.",
       "etsCsvError": "No se pudo cargar la lista de direcciones de grupo desde la pasarela.",
-      "reasoningEffortHint": "Preferencia opcional para los modelos que admiten esfuerzo de razonamiento. Automático no envía ninguna preferencia; si el proveedor o el modelo rechaza el valor elegido, KNX AI reintenta sin él.",
+      "reasoningEffortHint": "Preferencia opcional para los modelos que admiten esfuerzo de razonamiento. Automático no envía ninguna preferencia; si el proveedor o el modelo rechaza el valor elegido, Cerebrum Ultimate reintenta sin él.",
       "localContextBudget": "Ventana de contexto local",
       "localContextHint": "Establece el contexto máximo solo para modelos locales. Máximo usa la ventana conocida del modelo y oculta los tamaños no disponibles. Los proveedores cloud ignoran este selector y reciben todo el catálogo ETS semántico seleccionado.",
       "ollamaNotSupported": "Ollama local mode: API key not required. Default endpoint is http://localhost:11434/api/chat.",
@@ -179,7 +179,7 @@
           "ask": "Preguntar"
         },
         "empty": {
-          "noNodes": "No se encontraron nodos KNX AI.",
+          "noNodes": "No se encontraron nodos Cerebrum Ultimate.",
           "noAnomalies": "Sin anomalías."
         },
         "chat": {

package/nodes/locales/es/knxUltimateViewer.html

@@ -18,7 +18,7 @@ Se puede usar para:
 - visualizar en vivo las **luces** detectadas a partir de valores KNX booleanos
 - visualizar los **dimmers** detectados a partir de valores tipo `DPT 5.001`
 - filtrar elementos, cambiar entre nodos Viewer y mantener el auto-refresh activo
-- disponer de una interfaz visual coherente con **KNX AI**
+- disponer de una interfaz visual coherente con **Cerebrum Ultimate**
 
 La página web es servida directamente por Node-RED, por lo que sigue el mismo modelo de autenticación que el editor y los endpoints de administración.
 

package/nodes/locales/fr/knxUltimateAI.html

@@ -1,200 +1,5 @@
-<script type="text/markdown" data-help-name="knxUltimateAI">
-Ce nœud écoute **tous les télégrammes KNX** du gateway KNX Ultimate sélectionné, produit des statistiques de trafic, détecte des anomalies et peut interroger un LLM de façon optionnelle.
-
-L'éditeur utilise deux onglets horizontaux : **Assistant IA** contient la configuration, les connaissances/le contexte et les limites du fournisseur ; **Conversations et maison** contient les ports d’entrée et de sortie du chat, la maison proactive et la mémoire limitée.
-
-## Sorties
-1. **Résumé/Stats** (`msg.payload` JSON)
-2. **Anomalies** (`msg.payload` JSON)
-3. **Assistant IA** (`msg.payload` texte, avec `msg.summary`)
-4. **Opérations KNX** (un message Universal Mode par lecture ou écriture validée)
-5. **TTS Ultimate** (un message d'annonce par texte parlé choisi par le modèle)
-
-Chaque message émis par les sorties 3 et 4 contient également une copie du message d'entrée original dans `msg.inputMessage`. Le payload, le topic, les métadonnées du chat et toutes les autres propriétés d'entrée restent ainsi disponibles pour les nœuds suivants. Les erreurs de clonage ou d'envoi sont interceptées et signalées sans se propager au runtime Node-RED.
-
-### Setup Doctor et premier démarrage sûr
-Le **Setup Doctor** automatique vérifie le gateway sélectionné et l'import ETS, l'activation de l'IA, le fournisseur, le modèle et la clé API, l'accessibilité du fournisseur, le câblage du flow, les caméras détectées et la connexion TTS Ultimate optionnelle. Son précontrôle gratuit du fournisseur appelle uniquement l'endpoint qui répertorie les modèles : il n'envoie jamais de requête de chat et ne consomme aucun token d'inférence. Les caméras et TTS sont optionnels ; ne pas les utiliser ne réduit donc pas l'état de préparation principal.
-
-L'inventaire indique le nombre exact de signaux KNX à adresse de groupe unique, les zones/groupes ETS et une estimation des fonctions logiques. Il n'annonce volontairement aucun nombre d'appareils physiques, car celui-ci ne peut pas être déduit de façon fiable du CSV ETS. Le Setup Doctor lit le dernier flow déployé : déployez donc toute modification du fournisseur, du modèle, du préréglage, du gateway ou du câblage avant de cliquer sur **Actualiser** pour relancer les contrôles.
-
-Envoyez `/start` ou `/help` depuis un chat pour recevoir sur la sortie chat (sortie 3) un accueil déterministe et localisé, avec des statistiques personnalisées de l'installation et jusqu'à trois suggestions sûres. Cet onboarding n'appelle pas le LLM, ne lit ni n'écrit KNX et ne génère aucun TTS. Avec le préréglage Telegram, les suggestions apparaissent sous forme de boutons du clavier de réponse et ne sont exécutées qu'après la sélection ou l'envoi explicite de l'une d'elles par l'utilisateur. Après cette sélection explicite, une suggestion de démarrage peut effectuer des lectures KNX exactes si nécessaire ; les écritures et routines KNX, les actions de caméra, le TTS, les modifications de la mémoire persistante et l'apprentissage des rôles GA restent bloqués.
-
-### Intelligence Web
-L'accès Web est désactivé par défaut. Lorsque **Autoriser l'IA à utiliser le Web** est activé, le modèle conversationnel décide pour chaque demande courante si des informations publiques à jour sont nécessaires et peut choisir l'outil Web structuré sans mot-clé, logique propre à un sujet ni classificateur d'intention. Chaque demande utilisateur ou exécution d'une tâche planifiée créée par l'utilisateur peut effectuer au maximum trois opérations Web au total. Toutes les opérations Web externes réelles partagent le budget horaire glissant configuré.
-
-KNX AI ne démarre aucun cycle fixe de polling Web en arrière-plan. Si un détail essentiel modifierait sensiblement la réponse ou la requête—par exemple le sujet, la portée, le lieu, la période ou le résultat attendu—le modèle pose une seule question concise et n'effectue aucune opération Web avant la réponse de l'utilisateur. Les vérifications futures ou récurrentes sont créées uniquement à partir d'une demande explicite en langage naturel via le planificateur.
-
-Toute réponse fondée sur le Web contient des citations validées par le runtime, avec une URL source assainie et l'heure de consultation, ainsi que l'heure de publication lorsqu'elle est disponible. Le contenu externe est une donnée non fiable, jamais une instruction, et ne peut remplacer les règles ou autorisations de l'assistant. Seules des ressources HTTPS publiques et limitées sont acceptées ; les destinations privées, locales, link-local et de métadonnées cloud, les redirections non sûres, la navigation authentifiée et les cookies sont bloqués. Si aucune source ne peut être vérifiée, KNX AI signale cette limite au lieu de générer une réponse sans source.
-
-Lorsque des résultats Web vérifiés sont disponibles, le modèle peut composer les autres outils activés si le chat courant ou l'Éducation de l'IA l'y autorise. L'accès Web n'étend jamais les autorisations : la disponibilité des caméras, du TTS et de la mémoire, ainsi que les lectures et écritures KNX, la validation locale ETS/DPT et la confirmation configurée des écritures KNX restent inchangées. Les requêtes Web exposent la requête et l'adresse IP publique de ce serveur aux sites externes ou au service de recherche ; les données KNX/ETS, images de caméra, identifiants de chat, mémoire apprise et identifiants d'accès ne sont jamais ajoutés automatiquement.
-
-### Planifications et rappels en langage naturel
-Dans le langage normal du chat, l'utilisateur peut demander à KNX AI de créer, lister ou annuler un rappel, une surveillance ou une future commande domotique, ponctuelle ou récurrente. Le modèle choisit sémantiquement l'outil structuré de planification `scheduleActions` à partir de la demande complète et conserve tout l'objectif et ses conditions sous forme d'instruction en langage humain. Il n'existe ni mots-clés de planification, ni liste de phrases déclencheuses, ni classificateur d'intention rigide : la formulation et la langue ne limitent pas cette fonction.
-
-Les planifications appartiennent à la session de chat et persistent pour chaque nœud KNX AI après les redémarrages de Node-RED. Leur état d'exécution faisant autorité est `<userDir>/knxai/schedules/knxai-schedules-<node-id>.json` ; KNX AI génère aussi `<userDir>/knxai/schedules/knxai-schedules-<node-id>.md` comme vue lisible. Un plan peut s'exécuter une fois, se répéter à un intervalle d'au moins cinq minutes et expirer facultativement. Le modèle peut lister ou annuler uniquement les planifications actives appartenant au chat courant, sauf demande explicite d'annuler toutes les planifications de ce chat.
-
-Lorsqu'une tâche arrive à échéance, KNX AI lance un passage séparé du modèle avec l'instruction en langage humain enregistrée comme autorité utilisateur fiable. Une surveillance reste silencieuse si sa condition n'est pas remplie. Les autorisations existantes s'appliquent toujours à l'exécution : une surveillance météo exige **Autoriser l'IA à utiliser le Web** et utilise le même budget Web, un résultat parlé sort par la sortie 5 et nécessite donc un nœud TTS Ultimate câblé, et les outils caméra restent limités aux adaptateurs détectés. Une écriture KNX planifiée conserve les contrôles ETS/DPT exacts et, si la confirmation est activée, présente d'abord un aperçu à la même session de chat ; la sortie 4 n'émet rien avant la confirmation.
-
-Par exemple, l'utilisateur peut écrire : « Pendant les cinq prochains jours, vérifie toutes les 30 minutes les prévisions pour Cortemaggiore et utilise TTS Ultimate uniquement si des orages sont prévus. » KNX AI peut conserver cette condition et cette durée complètes dans une seule surveillance récurrente ; les exigences Web et TTS ci-dessus restent applicables.
-
-## Commandes (entrée)
-Envoyez `msg.topic` :
-- `summary` (ou vide) : envoie le résumé immédiatement
-- `reset` : efface l'historique, les compteurs, la mémoire domestique apprise, tous les contextes de chat persistants et toutes les planifications de ce nœud ; l'Éducation IA configurée dans le nœud reste inchangée
-- `ask` : envoie une question au LLM configuré
-- `confirm` / `cancel` : confirme ou annule les commandes KNX en attente sans rappeler le LLM
-- `clear_chat` : efface les échanges récents, les instructions persistantes et les commandes en attente de la session courante, puis annule ses planifications actives ; les autres sessions et l'Éducation IA restent inchangées
-
-Pour `ask`, mettez la question dans `msg.prompt` (recommandé), `msg.payload` (chaîne), ou les champs Telegram courants `msg.payload.content` / `msg.payload.text`.
-
-Si le traitement dure plus de 1,2 seconde, la sortie 3 émet immédiatement le message intermédiaire localisé « Je réfléchis… », avec `msg.knxAi.type = "thinking"` et `msg.knxAi.transient = true`. L’adaptateur de chat l’envoie au même utilisateur, puis la réponse finale arrive normalement dès qu’elle est prête. Ce message de progression n’est jamais enregistré dans le contexte de conversation ni dans la mémoire apprise.
-
-Chaque requête de chat LLM utilise un délai d’attente minimal de 30 minutes, indépendamment du fournisseur. Aucun champ de délai n’est à gérer dans l’éditeur. Il s’agit d’une attente maximale, et non d’un délai artificiel : les modèles plus rapides terminent toujours dès que leur réponse est prête. Si même cette limite 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.
-
-KNX AI ne propose plus de sélecteur applicatif pour la taille du contexte. Le catalogue ETS sélectionné complet reste dans le nœud et le modèle l’interroge via des actions de retrieval local limitées ; seuls les objets récupérés entrent dans le prompt. La recherche couvre les adresses exactes, noms ETS, alias, hiérarchie, zones, sémantique, DPT et libellés de valeurs, avec un classement insensible aux accents et tolérant aux fautes, ainsi que la consultation exacte, la navigation par zone et la découverte des couples commande/état. Sans intervalle explicite, les événements KNX et adaptateurs couvrent les 20 dernières minutes. L’aide, le README, le wiki, les exemples et le changelog fournis ne sont jamais intégrés ; si nécessaire, le modèle peut consulter la documentation GitHub publique via l’outil Web. Les données ETS récupérées, la requête courante et les lignes d’archive n’apparaissent qu’une fois ; le bloc d’analyse ne conserve que les agrégats dérivés du bus. Le source Function complet n’est ajouté que pour une demande explicite de revue de code Function. KNX AI ne réessaie pas une requête trop volumineuse en compactant le prompt.
-
-Avant chaque requête à un modèle local, KNX AI réserve de la place pour la réponse dans la fenêtre active de 8K/16K. Il limite automatiquement les tours de conversation les plus récents, les lignes exactes des archives, la mémoire apprise de la maison, les résultats Web, les planifications, le source Function demandé, les objets ETS récupérés et les métadonnées des caméras. Il s’agit d’une construction préventive du prompt, et non d’une nouvelle tentative après une erreur de taille ; le catalogue ETS sélectionné complet reste disponible localement par retrieval.
-
-### Accès aux objets ETS
-Cette section reprend le sélecteur d’adresses de groupe du profil MQTT d’IoT Bridge. Filtrez la liste importée, sélectionnez tout ou rien et appliquez la lecture seule aux adresses visibles en bloc ou ligne par ligne. Seules les adresses sélectionnées sont accessibles au modèle. Toute adresse sélectionnée est active et lisible ; les adresses en lecture seule restent visibles, mais la validation locale refuse tout `GroupValue_Write` vers elles. Il n’existe ni migration ni repli hérité : après la mise à jour, ouvrez chaque nœud KNX AI existant, enregistrez sa sélection explicite et déployez ; jusque-là, son catalogue IA est vide.
-
-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 à 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. 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`.
-
-### Demande de confirmation pour les boutons du chat
-Lorsqu'un plan est en attente, la sortie 3 contient `msg.knxAi.confirmationRequest`. L'objet comprend `required`, `status`, `sessionId`, `expiresAt`, `commandCount` et deux éléments dans `actions`. Utilisez `action.label` comme texte du bouton Telegram, `action.callbackData` comme callback et renvoyez `action.message` à KNX AI pour confirmer ou annuler sans saisir de texte.
-
-### Adaptateurs des messages d’entrée/sortie
-La section **Ports d’entrée et de sortie du chat** charge ses mappages sélectionnables depuis `resources/KNXAIChatAdapterMappings.js`. Le choix d’un adaptateur 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`. 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.
-
-Avec ce préréglage, un message vocal Telegram (`msg.payload.type = "voice"`) n’est traité automatiquement que lorsque **Provider** est réglé sur **OpenAI-compatible**. Avant tout téléchargement, KNX AI vérifie le fournisseur, réutilise son **Endpoint URL** et sa **API key**, puis dérive `/audio/transcriptions` et `/audio/speech` de cette même connexion. Le lien `msg.payload.weblink`, qui contient le jeton, sert uniquement au téléchargement limité et est supprimé avant que le message n’atteigne les sorties ou le LLM. L’entrée OGG/Opus est transcrite avec la valeur intégrée `gpt-4o-mini-transcribe` ; une demande réussie reçoit une réponse Telegram OGG/Opus native générée avec `gpt-4o-mini-tts` et `alloy`, tout en conservant la légende et l’éventuel clavier de confirmation. Si un autre fournisseur est sélectionné, l’utilisateur reçoit une instruction localisée lui demandant de choisir OpenAI-compatible ou d’envoyer du texte. Si la synthèse est indisponible, échoue ou dépasse la limite vocale, la réponse complète est envoyée sous forme de texte. L’audio téléchargé et le texte de réponse sont transmis au même fournisseur sélectionné. Les messages texte, les photos et les anciens mappages Telegram enregistrés restent compatibles.
-
-La légende de chaque réponse vocale native commence par la mention localisée **Voix générée par l’IA**, visible par le destinataire Telegram.
-
-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 texte et les postbacks utilisent le payload RedBot `message`. Un message vocal Telegram natif arrive avec `type = "audio"` et le `Buffer` OGG/Opus déjà téléchargé par RedBot : KNX AI applique les limites de taille et de durée sans second téléchargement, le transcrit avec le même fournisseur OpenAI-compatible décrit ci-dessus et répond avec un payload RedBot `audio` natif, sa légende textuelle et la mention localisée de voix générée par l’IA. Lorsqu’une écriture KNX exige une confirmation, la réponse reste volontairement un payload texte `inline-buttons`, car RedBot ne peut pas joindre ces boutons au même message vocal. Le mappage de sortie conserve les données de suivi RedBot `originalMessage`, `chat`, `api` et `client` ; les anciens mappages RedBot enregistrés sont également mis à niveau à l’exécution. 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.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é 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. Le prompt utilise les lignes exactes les plus récentes de l’intervalle fourni, automatiquement limitées à la fenêtre active du modèle local.
-
-### Annonces avec TTS Ultimate
-Reliez la sortie 5 à un ou plusieurs nœuds `ttsultimate` du paquet facultatif `node-red-contrib-tts-ultimate`. Le câblage Node-RED habituel détermine la destination et la diffusion ; utilisez Link Out/Link In si le nœud TTS se trouve dans un autre onglet de flow. L'ancien sélecteur de nœud TTS et l'injection interne ont été supprimés. Les positions des sorties 1 à 4 restent inchangées, mais les flows mis à niveau doivent relier physiquement la sortie 5 avant que les annonces vocales puissent atteindre TTS Ultimate.
-
-Le modèle décide de préparer ou non une annonce 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. La sortie 5 émet le texte exact à prononcer dans `msg.payload`, définit `msg.topic = "knx_ai_announcement"` et ajoute `msg.knxAi.type = "tts_announcement"` avec `msg.knxAi.sourceNodeId`, `msg.knxAi.sessionId` et `msg.knxAi.reason`. TTS Ultimate gère ensuite le lecteur, 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 : événements KNX et adaptateurs des 20 dernières minutes ou d’un intervalle explicite, catalogue ETS sélectionné complet consultable localement dont seuls les objets récupérés sont ajoutés à chaque prompt, source Function à la demande, mémoire de session et de la maison, Éducation IA, planifications actives et caméras détectées. Elle affiche aussi le contexte opérationnel maximal déclaré par le modèle 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 les chemins absolus des fichiers de planification JSON faisant autorité et Markdown lisible, ainsi que les archives des télégrammes KNX et des événements d’adaptateurs avec le format quotidien `YYYY-MM-DD.knxctx`. L’Éducation IA est enregistrée dans la configuration du nœud et ne possède donc aucun fichier d’exécution distinct.
-
-Le modèle reçoit le retrieval local du catalogue ETS, les lectures/écritures KNX, les adaptateurs caméra, les annonces TTS, la mémoire persistante, l'accès Web et les planifications/rappels 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 retrieval du catalogue est déterministe et local ; le runtime valide les arguments, la disponibilité des adaptateurs caméra et les limites de sécurité, tandis que les écritures KNX conservent la validation ETS/DPT locale complète et la confirmation configurée.
-
-Le fichier de débogage local temporaire `knxai-last-chat-prompt-<id-nœud>.txt` contient le dernier texte exact des messages système/utilisateur, est remplacé avant chaque appel de chat et ne contient ni clé API ni en-tête HTTP.
-
-### 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.
-
-### Accès aux objets ETS
-L’accès aux objets ETS est la seule autorité opérationnelle. Toute adresse sélectionnée dans **Accès aux objets ETS** est active et lisible ; elle est également inscriptible sauf si elle est marquée **Lecture seule**. Aucune classification de rôle déduite n’est envoyée au modèle de chat ni utilisée pour autoriser une écriture.
-
-## 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é.
-
-La dernière session de chat est mémorisée comme propriétaire et reçoit les messages spontanés. La sortie 3 émet `msg.knxAi.type = "proactive_notification"` et `msg.inputMessage` conserve la session pour l’adaptateur de chat. Une limite stricte de trois notifications proactives par heure évite les rafales. La sortie 4 n’est jamais utilisée de façon proactive et KNX n’est jamais modifié de manière autonome.
-
-La référence apprise partagée est chargée au démarrage depuis `<userDir>/knxai/memory/knxai-home-memory.md`, réécrite atomiquement toutes les 15 minutes et toujours strictement limitée à 5 Mo. Elle conserve au maximum 120 observations importantes, 80 habitudes agrégées, 80 notifications et 300 objets ETS sémantiques, jamais un flux illimité de télégrammes bruts. Les éléments anciens et moins prioritaires sont supprimés en premier.
-
-**Éducation IA** est limitée à 16 000 caractères et constitue une propriété fixe enregistrée avec le nœud dans le flow Node-RED. Seul l’utilisateur la modifie dans l’éditeur et l’applique avec Deploy. Le modèle la lit comme une consigne faisant autorité, mais ne peut jamais l’écrire ni l’écraser. Les faits et préférences demandés dans le chat appartiennent à la mémoire apprise du chat ; les planifications, rappels, surveillances et commandes futures, ponctuels ou récurrents, appartiennent au planificateur sémantique. Le fichier de mémoire apprise ne contient volontairement pas le texte de l’Éducation.
-
-## Exemple pratique de configuration
-Placez toute la politique de notification dans **Éducation IA** (`aiEducation`) :
-
-```text
-Appelle-moi Alex et réponds dans la même langue que moi.
-Réponds brièvement, sauf si je demande des détails techniques.
-Préviens mon dernier chat lorsqu’un volet, une fenêtre ou une porte reste ouvert au moins 120 minutes.
-Ne me préviens pas entre 23:00 et 07:00 et ne répète pas la même alerte avant six heures.
-Le volet du bureau peut rester ouvert le jour : ne m’envoie pas de notification.
-Si « lumière du salon » est ambigu, demande-moi quel éclairage je veux dire.
-N’affirme jamais qu’un actionneur a changé avant confirmation par un objet d’état KNX.
-```
-
-Avec ces réglages, la sortie 3 peut émettre une `proactive_notification` localisée après 120 minutes pour le volet du salon, tandis que l’Éducation supprime la notification du volet du bureau. Si Alex demande ensuite de fermer le volet du salon, KNX AI prépare la commande ETS exacte, mais conserve la validation et la confirmation normales avant la sortie 4.
-
-Utilisez des hiérarchies et noms d’objet ETS explicites, avec des rôles état/commande corrects. L’Éducation personnalise les décisions et la formulation, mais ne peut ni inventer une adresse de groupe, ni changer un DPT, ni contourner la validation KNX.
-
-## Workflow rapide : contrôle KNX
-1. Importez le CSV ETS dans la passerelle et configurez le fournisseur, le modèle et les identifiants LLM.
-2. Activez **Assistant LLM** et **lecture des états KNX et commande des actionneurs** ; laissez la confirmation activée.
-3. Connectez l'entrée du chat à KNX AI en conservant un identifiant de session/chat stable.
-4. Connectez la sortie 3 à la réponse du chat et la sortie 4 à KNX Ultimate en **mode universel**.
-5. L'utilisateur envoie une demande ; les états actuels sont lus immédiatement, tandis que les écritures affichent d'abord GA, DPT et valeur sans écrire sur le bus.
-6. Dans les 5 minutes, le même chat répond exactement `CONFIRMER` ou `ANNULER`.
-7. Seul `CONFIRMER` revalide et émet les commandes sur la sortie 4 ; vérifiez l'exécution avec une GA d'état KNX.
-
-## Champs de configuration
-Voici tous les champs tels qu'affichés dans l'éditeur KNX AI.
-
-### Général
-- **Gateway** : gateway/config node KNX Ultimate utilisé comme source des télégrammes.
-- **Name** : nom du nœud et titre du dashboard.
-- **Topic** : topic de base utilisé dans les sorties.
-- Bouton **Open KNX AI Web** : ouvre le dashboard web (`/knxUltimateAI/sidebar/page`).
-
-### Assistant IA
-- **Enable LLM assistant** : active les fonctions Ask/chat.
-- **Provider** : backend LLM (OpenAI-compatible, Anthropic, Ollama ou Bionic LM Studio).
-- **Endpoint URL** : URL endpoint chat/completions.
-- **API key** : clé API (non requise avec Ollama local ; facultative pour Bionic LM Studio sauf si l’authentification du serveur est activée).
-- **Model** : ID/nom du modèle.
-- **Effort de raisonnement** : préférence indépendante du fournisseur pour les modèles qui permettent de régler l’effort de raisonnement. **Automatique** n’envoie aucune préférence et conserve la valeur par défaut du modèle/fournisseur. Les choix explicites sont `none`, `minimal`, `low`, `medium`, `high`, `xhigh` et `max` ; leur prise en charge dépend du protocole de requête et du modèle, et KNX AI réessaie sans la préférence si elle est refusée.
-- **Autoriser l'IA à utiliser le Web** : désactivé par défaut. Permet au modèle de choisir sémantiquement l'outil Web général et de fournir des sources vérifiées et citées.
-- **Nombre maximal d'appels Web par heure** : budget glissant partagé entre les conversations et les tâches planifiées créées par l'utilisateur. Chaque échange ou exécution planifiée peut utiliser au maximum trois opérations au total.
-- **Voix Telegram** : disponible uniquement avec le fournisseur **OpenAI-compatible**. Elle réutilise automatiquement son endpoint et sa clé API avec les valeurs intégrées `gpt-4o-mini-transcribe`, `gpt-4o-mini-tts` et `alloy` ; il n’existe aucun réglage vocal distinct.
-- **Compatibilité du modèle de chat** : le modèle sélectionné doit prendre en charge l'endpoint Chat Completions configuré. Les anciens modèles réservés aux completions, comme `gpt-3.5-turbo-instruct`, sont exclus lors de l'actualisation de la liste. Si le fournisseur refuse une valeur de température personnalisée ou le paramètre de limite de tokens, KNX AI réessaie en supprimant ou remplaçant uniquement le champ incompatible.
-- **Autoriser l’IA à lire les états KNX et commander les actionneurs** : active la sortie 4 et reste désactivé par défaut. Tout objet ETS sélectionné peut être lu ; tout objet sélectionné non marqué **Lecture seule** peut être écrit. Les opérations inconnues, avec DPT discordant, invalides ou trop nombreuses, ainsi que les écritures vers des objets en lecture seule, sont rejetées localement.
-- **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.
-- **Adaptateur des messages d’entrée/sortie** : 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 fixes du nœud faisant autorité, modifiées uniquement par l’utilisateur et appliquées avec Deploy. Le modèle les lit mais ne les écrit jamais. Les politiques domotiques proactives permanentes se définissent ici ; les faits et préférences demandés dans le chat vont dans la mémoire apprise, tandis que les planifications, rappels, surveillances et commandes futures, ponctuels ou récurrents, vont dans le planificateur sémantique sans phrase déclencheuse ni routage par intent.
-- 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)
-- Choisir **Provider = Ollama**.
-- Endpoint par défaut : `http://localhost:11434/api/chat`.
-- Si aucun modèle local n'est trouvé :
-  - **1) Download model** : ouvre la page **Model library**.
-  - **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` est utilisé directement comme `num_ctx`. KNX AI n'applique aucun budget inférieur et envoie le prompt opérationnel dédupliqué sans compaction liée à la taille, sans jamais dépasser le maximum physique déclaré par le modèle.
-- Si Node-RED tourne dans Docker, utiliser `host.docker.internal` au lieu de `localhost` dans l'endpoint.
-
-### Démarrage rapide Bionic LM Studio (local)
-- Choisir **Provider = Bionic LM Studio**.
-- 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. Tout le contexte disponible est envoyé sans budget applicatif ; s'il ne tient pas dans la fenêtre active, la requête échoue explicitement.
-- 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é
-Si le LLM est activé, le contexte trafic KNX peut être envoyé à l'endpoint configuré. Pour un usage strictement on-premise, utilisez un provider local. Une commande émise en sortie 4 a passé la validation locale et a été transmise au flow, sans prouver son exécution par l'actionneur. Utilisez une GA d'état KNX pour la confirmation.
+<script type="text/html" data-help-name="knxUltimateAI">
+  <p><b>Il s’agit d’un nœud historique masqué, conservé uniquement pour les flows existants.</b></p>
+  <p>Pour toute nouvelle installation, utilisez le nœud autonome <b>Cerebrum Ultimate</b> du paquet <code>node-red-contrib-cerebrum-ultimate</code>. Il remplace ce nœud et utilise KNX Ultimate comme intégration compatible facultative.</p>
+  <p><a href="https://github.com/Supergiovane/node-red-contrib-cerebrum-ultimate#readme" target="_blank">Ouvrir la documentation de Cerebrum Ultimate</a>.</p>
 </script>

package/nodes/locales/fr/knxUltimateAI.json

@@ -1,6 +1,6 @@
 {
   "knxUltimateAI": {
-    "title": "KNX AI (Traffic Analyzer)",
+    "title": "Nœud IA historique — utiliser Cerebrum Ultimate",
     "sections": {
       "groupAssistant": "Assistant IA",
       "groupChatHome": "Cerebrum (BETA)",
@@ -35,8 +35,8 @@
       "webAccessEnabled": "Autoriser l’IA à utiliser le Web",
       "webMaxCallsPerHour": "Nombre maximal d’appels Web par heure",
       "chatAdapterPreset": "Adaptateur des messages d’entrée/sortie",
-      "chatInputCode": "Mappage d’entrée (chat → KNX AI)",
-      "chatOutputCode": "Mappage de sortie (KNX AI → chat)",
+      "chatInputCode": "Mappage d’entrée (chat → Cerebrum Ultimate)",
+      "chatOutputCode": "Mappage de sortie (Cerebrum Ultimate → chat)",
       "aiEducation": "Éducation IA (gérée par l'utilisateur)"
     },
     "outputs": {
@@ -95,7 +95,7 @@
       "lmStudioContextConfigured": "Contexte actif du modèle",
       "lmStudioContextFailed": "Impossible de configurer le contexte du modèle",
       "lmStudioContextCurrentlyLoaded": "actuellement chargé",
-      "etsAccessHint": "Sélectionnez les adresses de groupe disponibles pour KNX AI. Toute adresse sélectionnée est active et lisible ; toute adresse sélectionnée non marquée Lecture seule est inscriptible. Les fournisseurs cloud reçoivent tout le catalogue ETS sémantique sélectionné ; les modèles locaux reçoivent ce qui tient dans la fenêtre de contexte choisie et peuvent récupérer localement les détails manquants.",
+      "etsAccessHint": "Sélectionnez les adresses de groupe disponibles pour Cerebrum Ultimate. Toute adresse sélectionnée est active et lisible ; toute adresse sélectionnée non marquée Lecture seule est inscriptible. Les fournisseurs cloud reçoivent tout le catalogue ETS sémantique sélectionné ; les modèles locaux reçoivent ce qui tient dans la fenêtre de contexte choisie et peuvent récupérer localement les détails manquants.",
       "etsFilterPlaceholder": "Filtrer par nom, GA ou DPT…",
       "etsSelected": "sélectionnées",
       "etsReadOnly": "Lecture seule",
@@ -103,7 +103,7 @@
       "etsNoGateway": "Sélectionnez une passerelle KNX.",
       "etsNoGa": "Aucune adresse de groupe trouvée. Importez la liste ETS dans la passerelle KNX.",
       "etsCsvError": "Impossible de charger la liste des adresses de groupe depuis la passerelle.",
-      "reasoningEffortHint": "Préférence facultative pour les modèles prenant en charge l'effort de raisonnement. Automatique n'envoie aucune préférence ; si le fournisseur ou le modèle refuse la valeur choisie, KNX AI réessaie sans elle.",
+      "reasoningEffortHint": "Préférence facultative pour les modèles prenant en charge l'effort de raisonnement. Automatique n'envoie aucune préférence ; si le fournisseur ou le modèle refuse la valeur choisie, Cerebrum Ultimate réessaie sans elle.",
       "localContextBudget": "Fenêtre de contexte locale",
       "localContextHint": "Définit le contexte maximal uniquement pour les modèles locaux. Maximum utilise la fenêtre connue du modèle et masque les tailles indisponibles. Les fournisseurs cloud ignorent ce sélecteur et reçoivent tout le catalogue ETS sémantique sélectionné.",
       "ollamaNotSupported": "Ollama local mode: API key not required. Default endpoint is http://localhost:11434/api/chat.",
@@ -179,7 +179,7 @@
           "ask": "Demander"
         },
         "empty": {
-          "noNodes": "Aucun nœud KNX AI trouvé.",
+          "noNodes": "Aucun nœud Cerebrum Ultimate trouvé.",
           "noAnomalies": "Aucune anomalie."
         },
         "chat": {

package/nodes/locales/fr/knxUltimateViewer.html

@@ -18,7 +18,7 @@ Elle permet de :
 - visualiser en direct les **lumières** détectées à partir de valeurs KNX booléennes
 - visualiser les **variateurs** détectés à partir de valeurs de type `DPT 5.001`
 - filtrer les éléments, changer de nœud Viewer et garder l'auto-refresh actif
-- profiter d'une interface cohérente visuellement avec **KNX AI**
+- profiter d'une interface cohérente visuellement avec **Cerebrum Ultimate**
 
 La page web est servie directement par Node-RED et suit donc le même modèle d'authentification que l'éditeur et les endpoints d'administration.