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

package/nodes/locales/es/knxUltimateAI.html

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

package/nodes/locales/es/knxUltimateAI.json

@@ -6,6 +6,7 @@
       "groupChatHome": "Conversaciones y hogar",
       "detectedAdapters": "Adaptadores detectados automáticamente",
       "chatContextOverview": "Resumen del contexto del chat",
+      "chatLearning": "Aprendizaje del chat IA",
       "quickSetup": "Configurar el asistente",
       "llmConnection": "Conexion del Asistente IA",
       "chatAdapter": "Canales de chat",
@@ -21,6 +22,7 @@
       "llmBaseUrl": "Endpoint URL",
       "llmApiKey": "API key",
       "llmModel": "Model",
+      "llmPromptContextTokens": "Cantidad de contexto del chat",
       "llmSystemPrompt": "System prompt",
       "llmIncludeRaw": "Include raw payload hex",
       "llmAllowKnxCommands": "Permitir que la IA lea estados KNX y controle actuadores",
@@ -45,6 +47,11 @@
         "ollama": "Ollama (local)",
         "lmstudio": "Bionic LM Studio"
       },
+      "promptContext": {
+        "small": "Reducido (4K, más rápido)",
+        "medium": "Medio (8K)",
+        "full": "Completo (16K)"
+      },
       "chatAdapter": {
         "none": "Sin adaptador"
       },
@@ -61,6 +68,7 @@
       "lmStudioContextFailed": "No se pudo configurar el contexto del modelo",
       "lmStudioContextCurrentlyLoaded": "cargado actualmente",
       "localContextBudget": "Presupuesto de contexto de KNX AI",
+      "promptContextHint": "Controla la cantidad de contexto KNX, memoria, proyecto y adaptadores enviada a los modelos locales. No activa ni desactiva herramientas ni usa enrutamiento por intents.",
       "ollamaNotSupported": "Ollama local mode: API key not required. Default endpoint is http://localhost:11434/api/chat.",
       "ollamaNoModels": "No local Ollama model found. Install one or pick one from the library.",
       "installingOllamaModel": "Starting Ollama and installing model…",
@@ -80,6 +88,7 @@
       "ttsUltimateHint": "Las solicitudes explícitas de anuncio del chat se envían directamente al nodo elegido; no hace falta cableado en el flow.",
       "chatContextLoading": "Cargando el resumen del contexto del chat…",
       "chatContextUnavailable": "El resumen del contexto del chat no está disponible temporalmente.",
+      "chatLearningOpenHint": "Abre la interfaz web directamente en el editor de aprendizaje CHAT compartido para ver, editar, copiar o guardar una copia de su archivo persistente.",
       "chatContextIntro": "El chat recibe automáticamente estas fuentes. Las rutas siguientes son las que usa realmente esta instalación de Node-RED.",
       "chatContextLimitLabel": "Contexto operativo máximo",
       "chatContextProviderManaged": "gestionado por el proveedor/modelo seleccionado",
@@ -172,7 +181,8 @@
     "buttons": {
       "installOllamaModel": "2) Install it",
       "ollamaLibrary": "Model library",
-      "downloadOllamaModel": "1) Download model"
+      "downloadOllamaModel": "1) Download model",
+      "openChatLearning": "Abrir aprendizaje del chat IA"
     }
   }
 }

package/nodes/locales/es/knxUltimateIoTBridge.html

@@ -45,7 +45,8 @@ El resto de esta ayuda describe el modo clásico **Bridge IoT**.
 ## Campos de mapeo
 
 - **Dirección** — elige KNX→IoT, IoT→KNX o bidireccional.
-- **Tipo de canal** — MQTT usa el target como topic; REST lo usa como URL base; Modbus espera un identificador de registro.
+- **Tipo de canal** — MQTT usa el target como topic; REST lo usa como URL base; para Modbus, **Target** es la dirección de protocolo desde cero (0–65535).
+- **Formato Modbus / Unit ID / Área / Tipo de dato** — para los mapeos nuevos elige **Compatible con Flex Write** y después la unidad, el área de memoria y `bool`, `uint16` o `int16`. Si falta el formato se mantiene el contrato escalar heredado, por lo que los flows existentes siguen funcionando.
 - **Escala y Offset** — aplicados a KNX→IoT; IoT→KNX usa la transformación inversa.
 - **Template** — cadena opcional que reemplaza `{{value}}`, `{{ga}}`, `{{label}}`, `{{target}}`, `{{type}}`, `{{isoTimestamp}}`.
 - **Timeout / Reintentos** — campos informativos expuestos en el mensaje para que los nodos posteriores gestionen reintentos/ventanas.
@@ -88,7 +89,32 @@ El resto de esta ayuda describe el modo clásico **Bridge IoT**.
 
 ### Sincronización de registro Modbus
 
-- Empareja el bridge con nodos `modbus-flex-write` de `node-red-contrib-modbus`. La salida 1 transporta la dirección Modbus en `msg.address` y el valor en `msg.payload`.
+El bridge es un adaptador de mensajes para `node-red-contrib-modbus`: no abre conexiones TCP/serie ni consulta dispositivos por sí mismo. Instala una versión del paquete compatible con tu runtime Node-RED y utiliza después sus nodos cliente y de transporte.
+
+|Área|Lectura|Escritura|Dirección permitida|
+|--|--|--|--|
+| Coil | FC1 | FC5 | Ambas direcciones |
+| Discrete input | FC2 | — | Solo Modbus → KNX |
+| Holding register | FC3 | FC6 | Ambas direcciones |
+| Input register | FC4 | — | Solo Modbus → KNX |
+
+Para un mapeo nuevo selecciona `Formato = Compatible con Flex Write`. De KNX a Modbus, la salida 1 puede conectarse directamente a un nodo `modbus-flex-write` y emite:
+
+```
+msg.payload = {
+  value: 215,
+  fc: 6,
+  unitid: 1,
+  address: 9,
+  quantity: 1
+}
+```
+
+`address` siempre empieza en cero: si el manual del dispositivo etiqueta un holding register como `40010`, su dirección de protocolo suele ser `9`; comprueba la convención del manual. El bridge admite un bit o un único registro de 16 bits por mapeo. Por ahora no combina palabras, no decodifica valores de 32 bits/float ni gestiona el orden de bytes/palabras.
+
+De Modbus a KNX, conecta la salida de datos de un nodo `modbus-flex-getter` o `modbus-read` a la entrada del bridge. Flex Getter proporciona la petición (`fc`, `unitid`, `address`, `quantity`) en `msg.modbusRequest`; Modbus Read la conserva en `msg.input.payload`. El array de valores devuelto puede estar en `msg.payload` o en `msg.values`. El bridge admite ambas formas de mensaje, relaciona todos los mapeos Flex cubiertos por la respuesta y usa el elemento correcto del array. Activa **Keep Msg Properties** en Flex Getter. Escala y offset siguen `raw = KNX × escala + offset`; en la entrada se aplica la transformación inversa.
+
+`Leer valores KNX al desplegar` solo lee KNX; programa las lecturas Modbus en el flow Modbus externo. Los mapeos heredados (incluidos los que no tienen `modbusMessageFormat`) continúan emitiendo el payload escalar anterior con los metadatos `msg.address`/`msg.modbusFunction` en el nivel superior.
 
 ## Flow de ejemplo
 

package/nodes/locales/es/knxUltimateIoTBridge.json

@@ -79,6 +79,10 @@
       "target": "Destino",
       "method": "Método HTTP",
       "modbusFunction": "Función Modbus",
+      "modbusMessageFormat": "Formato del mensaje Modbus",
+      "modbusUnitId": "Unit ID",
+      "modbusArea": "Área Modbus",
+      "modbusDataType": "Tipo de dato",
       "scale": "Escala",
       "offset": "Offset",
       "timeout": "Tiempo de espera (ms)",
@@ -103,7 +107,7 @@
       "target": "Tema, URL o registro",
       "target_mqtt": "Tema, p. ej. knx/light/living",
       "target_rest": "https://example/api/endpoint",
-      "target_modbus": "Registro (p. ej. 40001)",
+      "target_modbus": "Dirección desde cero (p. ej. 0)",
       "template": "{\"value\":{{value}}}",
       "property": "Propiedad/ruta opcional",
       "method": "POST",
@@ -114,7 +118,7 @@
         "default": "Destino",
         "mqtt": "Topic MQTT",
         "rest": "URL REST",
-        "modbus": "Registro Modbus"
+        "modbus": "Dirección Modbus (desde cero)"
       },
       "method": {
         "default": "Método HTTP",
@@ -125,6 +129,20 @@
         "modbus": "Función Modbus"
       }
     },
+    "modbus": {
+      "formatLegacy": "Mensaje escalar heredado",
+      "formatFlex": "Compatible con Flex Write",
+      "areaCoil": "Coil (lectura FC1 / escritura FC5)",
+      "areaDiscreteInput": "Discrete input (lectura FC2 solamente)",
+      "areaHoldingRegister": "Holding register (lectura FC3 / escritura FC6)",
+      "areaInputRegister": "Input register (lectura FC4 solamente)",
+      "dataTypeBool": "Booleano",
+      "dataTypeUint16": "16 bits sin signo",
+      "dataTypeInt16": "16 bits con signo",
+      "zeroBasedHint": "Usa la dirección de protocolo desde cero (0–65535), no la referencia 4xxxx que aparece en algunos manuales.",
+      "flexHint": "Flex emite msg.payload = {value,fc,unitid,address,quantity}, conectable directamente a modbus-flex-write.",
+      "readOnlyHint": "Los discrete inputs e input registers son de solo lectura y únicamente admiten Modbus → KNX."
+    },
     "labels": {
       "outputKnxToIoT": "Flujo KNX → IoT",
       "outputIoTToKnx": "Confirmaciones IoT → KNX",

package/nodes/locales/fr/knxUltimateAI.html

@@ -25,9 +25,13 @@ 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
@@ -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 et caméras détectées. Elle affiche aussi le contexte opérationnel maximal 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.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é.
@@ -125,7 +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 toujours `num_ctx = 16384` (ou le maximum du modèle s'il est inférieur) et utilise la même vue sémantique de 16K sélectionnée par pertinence, évitant une allocation KV cache surdimensionnée sans retirer de capacités à l'agent.
+- 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)
@@ -133,7 +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 limite toujours son propre prompt à une vue sémantique de 16K sélectionnée par pertinence ; cela évite d’envoyer l’ensemble complet de 131K sans supprimer les capacités de raisonnement, KNX, routines, caméras ou TTS.
+- 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"
       },
@@ -61,6 +68,7 @@
       "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…",
@@ -80,6 +88,7 @@
       "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é",
@@ -172,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/fr/knxUltimateIoTBridge.html

@@ -45,7 +45,8 @@ Le reste de cette aide décrit le mode classique **Passerelle IoT**.
 ## Champs de correspondance
 
 - **Direction** — choisir KNX→IoT, IoT→KNX ou bidirectionnel.
-- **Type de canal** — MQTT utilise la cible comme topic, REST comme URL de base, Modbus comme identifiant de registre.
+- **Type de canal** — MQTT utilise la cible comme topic, REST comme URL de base ; pour Modbus, **Target** est l'adresse de protocole à base zéro (0–65535).
+- **Format Modbus / Unit ID / Zone / Type de donnée** — pour les nouvelles correspondances, choisissez **Compatible avec Flex Write**, puis l'unité, la zone mémoire et `bool`, `uint16` ou `int16`. En l'absence de format, l'ancien contrat scalaire reste actif afin de préserver les flows existants.
 - **Échelle & offset** — appliqués pour KNX→IoT ; IoT→KNX applique la transformation inverse.
 - **Template** — chaîne optionnelle remplaçant `{{value}}`, `{{ga}}`, `{{label}}`, `{{target}}`, `{{type}}`, `{{isoTimestamp}}`.
 - **Timeout / Tentatives** — informations exposées sur le message pour aider les nœuds en aval à gérer les reprises.
@@ -88,7 +89,32 @@ Le reste de cette aide décrit le mode classique **Passerelle IoT**.
 
 ### Synchronisation de registre Modbus
 
-- Associez la passerelle aux nœuds `modbus-flex-write` du paquet `node-red-contrib-modbus`. La sortie 1 transporte l’adresse Modbus dans `msg.address` et la valeur dans `msg.payload`.
+La passerelle est un adaptateur de messages pour `node-red-contrib-modbus` ; elle n'ouvre pas de connexion TCP/série et n'interroge pas elle-même un appareil. Installez une version du paquet compatible avec votre runtime Node-RED, puis utilisez ses nœuds client et transport.
+
+|Zone|Lecture|Écriture|Direction autorisée|
+|--|--|--|--|
+| Coil | FC1 | FC5 | Les deux directions |
+| Discrete input | FC2 | — | Modbus → KNX uniquement |
+| Holding register | FC3 | FC6 | Les deux directions |
+| Input register | FC4 | — | Modbus → KNX uniquement |
+
+Pour une nouvelle correspondance, sélectionnez `Format = Compatible avec Flex Write`. De KNX vers Modbus, la sortie 1 se raccorde directement à un nœud `modbus-flex-write` et émet :
+
+```
+msg.payload = {
+  value: 215,
+  fc: 6,
+  unitid: 1,
+  address: 9,
+  quantity: 1
+}
+```
+
+`address` est toujours à base zéro : si le manuel de l'appareil désigne un holding register par `40010`, son adresse de protocole est généralement `9` ; vérifiez la convention du manuel. La passerelle prend en charge un bit ou un seul registre 16 bits par correspondance. Elle ne combine pas encore plusieurs mots, ne décode pas les valeurs 32 bits/float et ne gère pas l'ordre des octets/mots.
+
+De Modbus vers KNX, reliez la sortie de données d'un nœud `modbus-flex-getter` ou `modbus-read` à l'entrée de la passerelle. Flex Getter fournit la requête (`fc`, `unitid`, `address`, `quantity`) dans `msg.modbusRequest` ; Modbus Read la conserve dans `msg.input.payload`. Le tableau de valeurs retourné peut se trouver dans `msg.payload` ou `msg.values`. La passerelle accepte les deux formes de message, associe toutes les correspondances Flex couvertes par la réponse et utilise le bon élément du tableau. Activez **Keep Msg Properties** sur Flex Getter. L'échelle et le décalage suivent `raw = KNX × échelle + décalage` ; le chemin entrant applique la transformation inverse.
+
+`Lire les valeurs KNX au déploiement` lit uniquement KNX ; planifiez les lectures Modbus dans le flow Modbus externe. Les correspondances historiques (y compris celles sans `modbusMessageFormat`) continuent d'émettre l'ancien payload scalaire avec les métadonnées `msg.address`/`msg.modbusFunction` au premier niveau.
 
 ## Flow d’exemple
 

package/nodes/locales/fr/knxUltimateIoTBridge.json

@@ -79,6 +79,10 @@
       "target": "Cible",
       "method": "Méthode HTTP",
       "modbusFunction": "Fonction Modbus",
+      "modbusMessageFormat": "Format du message Modbus",
+      "modbusUnitId": "Unit ID",
+      "modbusArea": "Zone Modbus",
+      "modbusDataType": "Type de donnée",
       "scale": "Échelle",
       "offset": "Décalage",
       "timeout": "Délai (ms)",
@@ -103,7 +107,7 @@
       "target": "Topic, URL ou registre",
       "target_mqtt": "Topic, ex. knx/light/salon",
       "target_rest": "https://example/api/endpoint",
-      "target_modbus": "Registre (ex. 40001)",
+      "target_modbus": "Adresse à base zéro (ex. 0)",
       "template": "{\"value\":{{value}}}",
       "property": "Propriété/chemin optionnel",
       "method": "POST",
@@ -114,7 +118,7 @@
         "default": "Cible",
         "mqtt": "Topic MQTT",
         "rest": "URL REST",
-        "modbus": "Registre Modbus"
+        "modbus": "Adresse Modbus (base zéro)"
       },
       "method": {
         "default": "Méthode HTTP",
@@ -125,6 +129,20 @@
         "modbus": "Fonction Modbus"
       }
     },
+    "modbus": {
+      "formatLegacy": "Message scalaire historique",
+      "formatFlex": "Compatible avec Flex Write",
+      "areaCoil": "Coil (lecture FC1 / écriture FC5)",
+      "areaDiscreteInput": "Discrete input (lecture FC2 uniquement)",
+      "areaHoldingRegister": "Holding register (lecture FC3 / écriture FC6)",
+      "areaInputRegister": "Input register (lecture FC4 uniquement)",
+      "dataTypeBool": "Booléen",
+      "dataTypeUint16": "16 bits non signé",
+      "dataTypeInt16": "16 bits signé",
+      "zeroBasedHint": "Utilisez l’adresse de protocole à base zéro (0–65535), et non la référence 4xxxx indiquée dans certains manuels.",
+      "flexHint": "Flex émet msg.payload = {value,fc,unitid,address,quantity}, directement raccordable à modbus-flex-write.",
+      "readOnlyHint": "Les discrete inputs et input registers sont en lecture seule et acceptent uniquement Modbus → KNX."
+    },
     "labels": {
       "outputKnxToIoT": "Flux KNX → IoT",
       "outputIoTToKnx": "Accusés IoT → KNX",