node-red-contrib-knx-ultimate 6.3.24 → 6.3.26
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/CHANGELOG.md +14 -1
- package/examples/IoT Bridge - Modbus Flex Adapter.json +361 -0
- package/examples/KNX AI - Conversational Control with Confirmation.json +4 -2
- package/examples/KNX AI - Summary Anomalies and Ask.json +4 -0
- package/examples/KNX AI - Telegrambot Direct Chat.json +7 -5
- package/nodes/knxUltimate-config.js +13 -4
- package/nodes/knxUltimateAI.html +310 -124
- package/nodes/knxUltimateAI.js +1742 -264
- package/nodes/knxUltimateIoTBridge.html +349 -20
- package/nodes/knxUltimateIoTBridge.js +474 -44
- package/nodes/locales/de/knxUltimateAI.html +33 -7
- package/nodes/locales/de/knxUltimateAI.json +34 -15
- package/nodes/locales/de/knxUltimateIoTBridge.html +28 -2
- package/nodes/locales/de/knxUltimateIoTBridge.json +20 -2
- package/nodes/locales/en/knxUltimateAI.html +33 -7
- package/nodes/locales/en/knxUltimateAI.json +34 -15
- package/nodes/locales/en/knxUltimateIoTBridge.html +28 -2
- package/nodes/locales/en/knxUltimateIoTBridge.json +20 -2
- package/nodes/locales/es/knxUltimateAI.html +33 -7
- package/nodes/locales/es/knxUltimateAI.json +34 -15
- package/nodes/locales/es/knxUltimateIoTBridge.html +28 -2
- package/nodes/locales/es/knxUltimateIoTBridge.json +20 -2
- package/nodes/locales/fr/knxUltimateAI.html +33 -7
- package/nodes/locales/fr/knxUltimateAI.json +34 -15
- package/nodes/locales/fr/knxUltimateIoTBridge.html +28 -2
- package/nodes/locales/fr/knxUltimateIoTBridge.json +20 -2
- package/nodes/locales/it/knxUltimateAI.html +33 -7
- package/nodes/locales/it/knxUltimateAI.json +34 -15
- package/nodes/locales/it/knxUltimateIoTBridge.html +28 -2
- package/nodes/locales/it/knxUltimateIoTBridge.json +20 -2
- package/nodes/locales/zh-CN/knxUltimateAI.html +33 -7
- package/nodes/locales/zh-CN/knxUltimateAI.json +34 -15
- package/nodes/locales/zh-CN/knxUltimateIoTBridge.html +28 -2
- package/nodes/locales/zh-CN/knxUltimateIoTBridge.json +20 -2
- package/nodes/plugins/knxUltimateAI-vue/assets/app.css +1 -1
- package/nodes/plugins/knxUltimateAI-vue/assets/app.js +4 -4
- package/nodes/utils/knxAiTelegramVoice.js +475 -0
- package/nodes/utils/knxAiWebAccess.js +631 -0
- package/package.json +3 -3
- package/resources/KNXAIChatAdapterMappings.js +96 -2
|
@@ -79,6 +79,10 @@
|
|
|
79
79
|
"target": "Target",
|
|
80
80
|
"method": "HTTP method",
|
|
81
81
|
"modbusFunction": "Modbus function",
|
|
82
|
+
"modbusMessageFormat": "Modbus message format",
|
|
83
|
+
"modbusUnitId": "Unit ID",
|
|
84
|
+
"modbusArea": "Modbus area",
|
|
85
|
+
"modbusDataType": "Data type",
|
|
82
86
|
"scale": "Scale",
|
|
83
87
|
"offset": "Offset",
|
|
84
88
|
"timeout": "Timeout (ms)",
|
|
@@ -103,7 +107,7 @@
|
|
|
103
107
|
"target": "Topic, URL or register",
|
|
104
108
|
"target_mqtt": "Topic, e.g. knx/light/living",
|
|
105
109
|
"target_rest": "https://example/api/endpoint",
|
|
106
|
-
"target_modbus": "
|
|
110
|
+
"target_modbus": "Zero-based address (e.g. 0)",
|
|
107
111
|
"template": "{\"value\":{{value}}}",
|
|
108
112
|
"property": "Optional property/path",
|
|
109
113
|
"method": "POST",
|
|
@@ -114,7 +118,7 @@
|
|
|
114
118
|
"default": "Target",
|
|
115
119
|
"mqtt": "MQTT topic",
|
|
116
120
|
"rest": "REST URL",
|
|
117
|
-
"modbus": "Modbus
|
|
121
|
+
"modbus": "Modbus address (zero-based)"
|
|
118
122
|
},
|
|
119
123
|
"method": {
|
|
120
124
|
"default": "HTTP method",
|
|
@@ -125,6 +129,20 @@
|
|
|
125
129
|
"modbus": "Modbus function"
|
|
126
130
|
}
|
|
127
131
|
},
|
|
132
|
+
"modbus": {
|
|
133
|
+
"formatLegacy": "Legacy scalar message",
|
|
134
|
+
"formatFlex": "Flex Write compatible",
|
|
135
|
+
"areaCoil": "Coil (FC1 read / FC5 write)",
|
|
136
|
+
"areaDiscreteInput": "Discrete input (FC2 read only)",
|
|
137
|
+
"areaHoldingRegister": "Holding register (FC3 read / FC6 write)",
|
|
138
|
+
"areaInputRegister": "Input register (FC4 read only)",
|
|
139
|
+
"dataTypeBool": "Boolean",
|
|
140
|
+
"dataTypeUint16": "Unsigned 16-bit",
|
|
141
|
+
"dataTypeInt16": "Signed 16-bit",
|
|
142
|
+
"zeroBasedHint": "Use the zero-based protocol address (0–65535), not the 4xxxx reference printed by some manuals.",
|
|
143
|
+
"flexHint": "Flex emits msg.payload = {value,fc,unitid,address,quantity} for direct wiring to modbus-flex-write.",
|
|
144
|
+
"readOnlyHint": "Discrete inputs and input registers are read-only and can only use Modbus → KNX."
|
|
145
|
+
},
|
|
128
146
|
"labels": {
|
|
129
147
|
"outputKnxToIoT": "KNX → IoT stream",
|
|
130
148
|
"outputIoTToKnx": "IoT → KNX acknowledgements",
|
|
@@ -1,16 +1,33 @@
|
|
|
1
1
|
<script type="text/markdown" data-help-name="knxUltimateAI">
|
|
2
2
|
Este nodo escucha **todos los telegramas KNX** del gateway KNX Ultimate seleccionado, genera estadísticas de tráfico, detecta anomalías y puede consultar opcionalmente un LLM.
|
|
3
3
|
|
|
4
|
-
El editor utiliza dos pestañas horizontales: **Asistente IA** contiene configuración, conocimiento/contexto y límites del proveedor; **Conversaciones y hogar** contiene
|
|
4
|
+
El editor utiliza dos pestañas horizontales: **Asistente IA** contiene configuración, conocimiento/contexto y límites del proveedor; **Conversaciones y hogar** contiene los pines de entrada y salida del chat, hogar proactivo y memoria limitada.
|
|
5
5
|
|
|
6
6
|
## Salidas
|
|
7
7
|
1. **Resumen/Estadísticas** (`msg.payload` JSON)
|
|
8
8
|
2. **Anomalías** (`msg.payload` JSON)
|
|
9
9
|
3. **Asistente IA** (`msg.payload` texto, con `msg.summary`)
|
|
10
10
|
4. **Operaciones KNX** (un mensaje Universal Mode por cada lectura o escritura validada)
|
|
11
|
+
5. **TTS Ultimate** (un mensaje de anuncio por cada texto hablado elegido por el modelo)
|
|
11
12
|
|
|
12
13
|
Cada mensaje emitido por las salidas 3 y 4 también contiene una copia del mensaje de entrada original en `msg.inputMessage`. Así, el payload, el topic, los metadatos del chat y cualquier otra propiedad de entrada permanecen disponibles para los nodos posteriores. Los errores de clonación o envío se interceptan y notifican sin propagarse al runtime de Node-RED.
|
|
13
14
|
|
|
15
|
+
### Setup Doctor y primer inicio seguro
|
|
16
|
+
El **Setup Doctor** automático comprueba el gateway seleccionado y la importación ETS, la activación de IA, el proveedor, el modelo y la clave API, la conectividad con el proveedor, el cableado del flow, las cámaras detectadas y la conexión TTS Ultimate opcional. Su comprobación previa gratuita del proveedor solo llama al endpoint que enumera los modelos: nunca envía una solicitud de chat ni consume tokens de inferencia. Las cámaras y TTS son opcionales, por lo que no utilizarlos no reduce la preparación básica.
|
|
17
|
+
|
|
18
|
+
El inventario muestra el número exacto de señales KNX con dirección de grupo única, las áreas/grupos ETS y una estimación de las funciones lógicas. Deliberadamente no indica un número de dispositivos físicos, porque no puede obtenerse de forma fiable del CSV ETS. Setup Doctor lee el último flow desplegado: despliega cualquier cambio de proveedor, modelo, preajuste, gateway o cableado antes de pulsar **Actualizar** para repetir las comprobaciones.
|
|
19
|
+
|
|
20
|
+
Envía `/start` o `/help` desde un chat para recibir en la salida de chat (salida 3) una bienvenida determinista y localizada, con estadísticas personalizadas de la instalación y hasta tres sugerencias seguras. Este onboarding no llama al LLM, no lee ni escribe KNX y no genera TTS. Con el preajuste de Telegram, las sugerencias aparecen como botones del teclado de respuesta y solo se ejecutan cuando el usuario selecciona o envía una de ellas de forma explícita. Tras esa selección explícita, una sugerencia inicial puede realizar lecturas KNX exactas cuando sean necesarias; las escrituras y rutinas KNX, las acciones de cámara, TTS, los cambios de memoria persistente y el aprendizaje de roles GA permanecen bloqueados.
|
|
21
|
+
|
|
22
|
+
### Inteligencia Web
|
|
23
|
+
El acceso Web está desactivado de forma predeterminada. Cuando se activa **Permitir que la IA use la Web**, el modelo conversacional puede elegir la herramienta Web estructurada directamente a partir de la solicitud actual; no se usan palabras clave, lógica específica por tema ni clasificadores de intención. Cada turno del usuario o ciclo proactivo puede realizar como máximo tres operaciones Web en total. Todas las operaciones Web externas reales comparten el presupuesto horario deslizante configurado.
|
|
24
|
+
|
|
25
|
+
**Permitir comprobaciones Web proactivas** es una autorización independiente. También requiere instrucciones explícitas escritas por el usuario en **Educación IA**, respeta el intervalo mínimo configurado y solo empieza después de que KNX AI haya aprendido un chat destinatario a partir de al menos una solicitud normal. Sin ambas autorizaciones no se realiza ninguna operación Web en segundo plano.
|
|
26
|
+
|
|
27
|
+
Cada respuesta basada en la Web contiene citas validadas por el runtime, con la URL de origen saneada y la hora de consulta, además de la hora de publicación cuando está disponible. El contenido externo son datos no confiables, nunca instrucciones, y no puede sustituir las reglas ni los permisos del asistente. Solo se aceptan recursos HTTPS públicos y limitados; se bloquean los destinos privados, locales, link-local y de metadatos cloud, las redirecciones inseguras, la navegación autenticada y las cookies. Si no se puede verificar ninguna fuente, KNX AI informa de esa limitación en lugar de generar una respuesta sin fuentes.
|
|
28
|
+
|
|
29
|
+
Cuando hay resultados Web verificados, el modelo puede combinar las demás herramientas habilitadas si el chat actual o Educación IA lo autorizan. El acceso Web nunca amplía los permisos: la disponibilidad de cámaras, TTS y memoria, así como las lecturas y escrituras KNX, la validación local ETS/DPT y la confirmación configurada para escrituras KNX, permanecen sin cambios. Las solicitudes Web exponen la consulta y la IP pública de este servidor a sitios externos o al servicio de búsqueda; los datos KNX/ETS, el contenido de cámaras, los identificadores de chat, la memoria aprendida y las credenciales nunca se añaden automáticamente.
|
|
30
|
+
|
|
14
31
|
## Comandos (entrada)
|
|
15
32
|
Envía `msg.topic`:
|
|
16
33
|
- `summary` (o vacío): emite el resumen inmediatamente
|
|
@@ -43,11 +60,15 @@ Solicitudes como «Me voy», «Buenas noches» o «Modo cine» pueden coordinar
|
|
|
43
60
|
### Solicitud de confirmación para botones de chat
|
|
44
61
|
Mientras un plan está pendiente, la salida 3 contiene `msg.knxAi.confirmationRequest`. El objeto incluye `required`, `status`, `sessionId`, `expiresAt`, `commandCount` y dos elementos en `actions`. Usa `action.label` como texto del botón de Telegram, `action.callbackData` como callback y devuelve `action.message` a KNX AI para confirmar o cancelar sin escribir texto.
|
|
45
62
|
|
|
46
|
-
###
|
|
47
|
-
La
|
|
63
|
+
### Adaptadores de mensajes de entrada/salida
|
|
64
|
+
La sección **Pines de entrada y salida del chat** carga sus mapeos seleccionables desde `resources/KNXAIChatAdapterMappings.js`. Al elegir un adaptador 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.
|
|
48
65
|
|
|
49
66
|
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.
|
|
50
67
|
|
|
68
|
+
Con este preajuste, los mensajes de voz de Telegram (`msg.payload.type = "voice"`) solo se procesan automáticamente cuando **Provider** está configurado como **OpenAI-compatible**. Antes de descargar nada, KNX AI comprueba el proveedor, reutiliza su **Endpoint URL** y su **API key**, y deriva `/audio/transcriptions` y `/audio/speech` de esa misma conexión. El enlace `msg.payload.weblink`, que contiene el token, se usa solo para la descarga limitada y se elimina antes de que el mensaje llegue a las salidas o al LLM. La entrada OGG/Opus se transcribe con el valor integrado `gpt-4o-mini-transcribe`; una solicitud correcta recibe una respuesta nativa de Telegram en OGG/Opus generada con `gpt-4o-mini-tts` y `alloy`, conservando el texto y el teclado de confirmación. Si se selecciona otro proveedor, el usuario recibe una indicación localizada para elegir OpenAI-compatible o enviar texto. Si la síntesis no está disponible, falla o supera el límite de voz, se envía como alternativa la respuesta completa en texto. El audio descargado y el texto de respuesta se envían al mismo proveedor seleccionado. Los mensajes de texto, las fotos y los mapeos Telegram antiguos guardados siguen siendo compatibles.
|
|
69
|
+
|
|
70
|
+
La leyenda de cada respuesta de voz nativa comienza con el aviso localizado **Voz generada por IA**, visible para el destinatario de Telegram.
|
|
71
|
+
|
|
51
72
|
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.
|
|
52
73
|
|
|
53
74
|
### Adaptadores de cámara detectados automáticamente
|
|
@@ -58,14 +79,14 @@ El usuario puede pedir una captura actual o preguntar al modelo de visión qué
|
|
|
58
79
|
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.
|
|
59
80
|
|
|
60
81
|
### Anuncios con TTS Ultimate
|
|
61
|
-
|
|
82
|
+
Conecta la salida 5 a uno o más nodos `ttsultimate` del paquete opcional `node-red-contrib-tts-ultimate`. El cableado normal de Node-RED determina el destino y la distribución; usa Link Out/Link In si el nodo TTS está en otra pestaña del flow. Se han eliminado el selector anterior del nodo TTS y la inyección interna. Las posiciones de las salidas 1–4 no cambian, pero los flows actualizados deben conectar físicamente la salida 5 antes de que los anuncios de voz lleguen a TTS Ultimate.
|
|
62
83
|
|
|
63
|
-
El modelo decide si
|
|
84
|
+
El modelo decide si prepara un anuncio 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. La salida 5 emite el texto exacto que se debe pronunciar en `msg.payload`, define `msg.topic = "knx_ai_announcement"` y añade `msg.knxAi.type = "tts_announcement"` junto con `msg.knxAi.sourceNodeId`, `msg.knxAi.sessionId` y `msg.knxAi.reason`. TTS Ultimate gestiona después el reproductor, la voz, el volumen, el aviso inicial y la cola.
|
|
64
85
|
|
|
65
86
|
### Resumen del contexto del chat
|
|
66
87
|
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.
|
|
67
88
|
|
|
68
|
-
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.
|
|
89
|
+
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 de cámara y límites de seguridad; las escrituras KNX conservan la validación ETS/DPT local y la confirmación configurada.
|
|
69
90
|
|
|
70
91
|
### Edición y copia del aprendizaje CHAT
|
|
71
92
|
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.
|
|
@@ -127,10 +148,15 @@ Aquí tienes todos los campos tal como se muestran en el editor de KNX AI.
|
|
|
127
148
|
- **Endpoint URL**: URL endpoint chat/completions.
|
|
128
149
|
- **API key**: clave API (no requerida con Ollama local; opcional para Bionic LM Studio salvo que la autenticación del servidor esté activada).
|
|
129
150
|
- **Model**: ID/nombre de modelo.
|
|
151
|
+
- **Permitir que la IA use la Web**: desactivado de forma predeterminada. Permite al modelo elegir semánticamente la herramienta Web general y devolver fuentes verificadas y citadas.
|
|
152
|
+
- **Permitir comprobaciones Web proactivas**: autorización independiente para comprobaciones en segundo plano; también requiere instrucciones explícitas escritas por el usuario en **Educación IA**.
|
|
153
|
+
- **Intervalo mínimo de las comprobaciones proactivas**: tiempo mínimo entre ciclos proactivos; no retrasa las operaciones Web solicitadas durante un turno de usuario activo.
|
|
154
|
+
- **Máximo de llamadas Web por hora**: presupuesto deslizante compartido por las operaciones Web interactivas y proactivas. Cada turno o ciclo puede usar como máximo tres operaciones en total.
|
|
155
|
+
- **Voz de Telegram**: disponible únicamente con el proveedor **OpenAI-compatible**. Reutiliza automáticamente su endpoint y clave API con los valores integrados `gpt-4o-mini-transcribe`, `gpt-4o-mini-tts` y `alloy`; no existen ajustes de voz separados.
|
|
130
156
|
- **Compatibilidad del modelo de chat**: el modelo seleccionado debe admitir el endpoint Chat Completions configurado. Los modelos antiguos disponibles solo mediante completions, como `gpt-3.5-turbo-instruct`, se excluyen al actualizar la lista. Si el proveedor rechaza un valor personalizado de temperatura o el parámetro de límite de tokens, KNX AI vuelve a intentarlo eliminando o sustituyendo únicamente el campo incompatible.
|
|
131
157
|
- **Permitir que la IA lea estados KNX y controle actuadores**: habilita la salida 4 y está desactivado por defecto. Los objetos exactos del catálogo ETS se pueden leer; solo se aceptan escrituras hacia objetos clasificados como `command`. Las operaciones desconocidas, con DPT distinto, inválidas o excesivas, y las escrituras hacia objetos de estado o neutrales, se rechazan localmente.
|
|
132
158
|
- **Pedir confirmación antes de enviar comandos KNX**: activado por defecto. Muestra primero los cambios validados y no emite comandos hasta que la misma sesión de chat los confirme. Cuando hay comandos pendientes, la respuesta añade siempre las instrucciones exactas para confirmar o cancelar en el idioma de la solicitud actual. Los comandos se validan de nuevo justo antes de la salida.
|
|
133
|
-
- **
|
|
159
|
+
- **Adaptador de mensajes de entrada/salida**: usa **Sin adaptador** por defecto. La selección carga el par predefinido de mapeos de entrada y salida; ambos permanecen ocultos en el editor.
|
|
134
160
|
- **Educación de la IA**: instrucciones vinculantes gestionadas solo por el usuario, leídas por la IA y nunca modificadas. Es el único lugar donde solicitar notificaciones proactivas y definir sus condiciones, duración, horas silenciosas y repetición.
|
|
135
161
|
- Los fragmentos incluidos con el paquete procedentes de la ayuda, README, changelog, wiki y ejemplos no se añaden a los prompts de Telegram, RedBot ni CHAT personalizados. Solo permanecen disponibles para el Asistente web en preguntas técnicas sobre el paquete.
|
|
136
162
|
- Botón **Refresh**: consulta el provider y carga los modelos disponibles. El icono gira durante la carga; una finalización correcta no muestra ningún mensaje.
|
|
@@ -4,12 +4,14 @@
|
|
|
4
4
|
"sections": {
|
|
5
5
|
"groupAssistant": "Asistente IA",
|
|
6
6
|
"groupChatHome": "Conversaciones y hogar",
|
|
7
|
-
"
|
|
7
|
+
"setupDoctor": "Setup Doctor",
|
|
8
|
+
"webIntelligence": "Inteligencia Web",
|
|
9
|
+
"detectedAdapters": "Nodos compatibles detectados y utilizados en el chat",
|
|
8
10
|
"chatContextOverview": "Resumen del contexto del chat",
|
|
9
11
|
"chatLearning": "Aprendizaje del chat IA",
|
|
10
12
|
"quickSetup": "Configurar el asistente",
|
|
11
13
|
"llmConnection": "Conexion del Asistente IA",
|
|
12
|
-
"chatAdapter": "
|
|
14
|
+
"chatAdapter": "Pines de entrada y salida del chat",
|
|
13
15
|
"homeIntelligence": "Educación IA y memoria",
|
|
14
16
|
"advanced": "Proveedor y límites"
|
|
15
17
|
},
|
|
@@ -27,10 +29,13 @@
|
|
|
27
29
|
"llmIncludeRaw": "Include raw payload hex",
|
|
28
30
|
"llmAllowKnxCommands": "Permitir que la IA lea estados KNX y controle actuadores",
|
|
29
31
|
"llmRequireCommandConfirmation": "Pedir confirmación antes de enviar comandos KNX",
|
|
30
|
-
"
|
|
32
|
+
"webAccessEnabled": "Permitir que la IA use la Web",
|
|
33
|
+
"webProactiveEnabled": "Permitir comprobaciones Web proactivas",
|
|
34
|
+
"webProactiveIntervalMinutes": "Intervalo mínimo de las comprobaciones proactivas",
|
|
35
|
+
"webMaxCallsPerHour": "Máximo de llamadas Web por hora",
|
|
36
|
+
"chatAdapterPreset": "Adaptador de mensajes de entrada/salida",
|
|
31
37
|
"chatInputCode": "Mapeo de entrada (chat → KNX AI)",
|
|
32
38
|
"chatOutputCode": "Mapeo de salida (KNX AI → chat)",
|
|
33
|
-
"ttsUltimateNodeId": "Nodo TTS Ultimate para anuncios",
|
|
34
39
|
"aiEducation": "Educación IA (gestionada por el usuario)",
|
|
35
40
|
"llmIncludeDocsSnippets": "Include documentation snippets (help/README/examples)"
|
|
36
41
|
},
|
|
@@ -38,7 +43,8 @@
|
|
|
38
43
|
"summary": "Resumen/Estadísticas",
|
|
39
44
|
"anomalies": "Anomalías",
|
|
40
45
|
"assistant": "Asistente IA",
|
|
41
|
-
"knxCommands": "Operaciones KNX"
|
|
46
|
+
"knxCommands": "Operaciones KNX",
|
|
47
|
+
"ttsUltimate": "Anuncios TTS Ultimate"
|
|
42
48
|
},
|
|
43
49
|
"selectlists": {
|
|
44
50
|
"llmProvider": {
|
|
@@ -55,12 +61,28 @@
|
|
|
55
61
|
"chatAdapter": {
|
|
56
62
|
"none": "Sin adaptador"
|
|
57
63
|
},
|
|
58
|
-
"
|
|
59
|
-
"
|
|
60
|
-
"
|
|
64
|
+
"webProactiveInterval": {
|
|
65
|
+
"5": "5 minutos",
|
|
66
|
+
"10": "10 minutos",
|
|
67
|
+
"15": "15 minutos",
|
|
68
|
+
"30": "30 minutos",
|
|
69
|
+
"60": "1 hora",
|
|
70
|
+
"180": "3 horas"
|
|
61
71
|
}
|
|
62
72
|
},
|
|
63
73
|
"messages": {
|
|
74
|
+
"setupDoctorLoading": "Analizando esta instalación…",
|
|
75
|
+
"setupDoctorUnavailable": "Setup Doctor no está disponible temporalmente.",
|
|
76
|
+
"setupDoctorPromptsTitle": "Probar tu instalación",
|
|
77
|
+
"setupDoctorPromptsHint": "Cada sugerencia abre el Asistente Web con una consulta personalizada y segura. Nada se ejecuta automáticamente.",
|
|
78
|
+
"setupDoctorDeployHint": "Setup Doctor lee el último flow desplegado. Despliega los cambios y vuelve a comprobar.",
|
|
79
|
+
"setupDoctorPass": "OK",
|
|
80
|
+
"setupDoctorWarn": "Revisar",
|
|
81
|
+
"setupDoctorFail": "Corregir",
|
|
82
|
+
"setupDoctorInfo": "Opcional",
|
|
83
|
+
"webAccessHint": "El modelo elige semánticamente esta herramienta Web general; no se usan palabras clave ni clasificadores de intención. Los sitios externos y el servicio de búsqueda reciben la consulta y la IP pública de este servidor. Los datos privados de KNX, cámaras, chat, memoria y credenciales nunca se añaden automáticamente.",
|
|
84
|
+
"webProactiveHint": "Esta autorización independiente también requiere instrucciones explícitas en Educación IA y un chat destinatario aprendido de una solicitud normal. El modelo decide qué comprobar; siguen vigentes los permisos de las demás herramientas y las reglas de confirmación KNX.",
|
|
85
|
+
"webBudgetHint": "El presupuesto deslizante cuenta las llamadas externas reales del chat y de las comprobaciones proactivas.",
|
|
64
86
|
"lmStudioContextAvailable": "Contexto máximo del modelo",
|
|
65
87
|
"lmStudioContextLoading": "Comprobando el contexto activo del modelo",
|
|
66
88
|
"lmStudioContextInactive": "Modelo inactivo; se usarán los valores predeterminados de Bionic en la primera solicitud",
|
|
@@ -76,16 +98,13 @@
|
|
|
76
98
|
"installOllamaModelFailed": "Failed to install Ollama model",
|
|
77
99
|
"ollamaInstallSteps": "1) Open the model library and copy the model name (for example llama3.1). 2) Put the name in the Model field and click Install it.",
|
|
78
100
|
"ollamaStartedAuto": "Ollama server started automatically.",
|
|
79
|
-
"detectedAdaptersLoading": "Detectando
|
|
80
|
-
"detectedAdaptersNone": "No se detectó ningún
|
|
81
|
-
"detectedAdaptersUnavailable": "La detección
|
|
101
|
+
"detectedAdaptersLoading": "Detectando nodos compatibles instalados…",
|
|
102
|
+
"detectedAdaptersNone": "No se detectó ningún nodo compatible.",
|
|
103
|
+
"detectedAdaptersUnavailable": "La detección de nodos compatibles no está disponible temporalmente.",
|
|
82
104
|
"detectedAdapterDetected": "Detectado",
|
|
83
105
|
"detectedAdapterControllers": "Controladores",
|
|
84
106
|
"detectedAdapterCameras": "Cámaras",
|
|
85
107
|
"detectedAdapterNodes": "Nodos",
|
|
86
|
-
"ttsUltimateUnknownFlow": "Flow sin nombre",
|
|
87
|
-
"ttsUltimateUnavailable": "Nodo TTS Ultimate no disponible",
|
|
88
|
-
"ttsUltimateHint": "Las solicitudes explícitas de anuncio del chat se envían directamente al nodo elegido; no hace falta cableado en el flow.",
|
|
89
108
|
"chatContextLoading": "Cargando el resumen del contexto del chat…",
|
|
90
109
|
"chatContextUnavailable": "El resumen del contexto del chat no está disponible temporalmente.",
|
|
91
110
|
"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.",
|
|
@@ -106,7 +125,6 @@
|
|
|
106
125
|
"chatContextSourceEtsProject": "Semántica ETS e inventario completo del proyecto Node-RED.",
|
|
107
126
|
"chatContextSourceMemoryEducation": "Contexto de sesión, Educación IA y memoria doméstica limitada.",
|
|
108
127
|
"chatContextSourceCameras": "Cámaras detectadas y sus capacidades disponibles.",
|
|
109
|
-
"chatContextSourceTtsUltimate": "Nodo TTS Ultimate seleccionado para los anuncios.",
|
|
110
128
|
"chatContextSourceBadge": "Fuente",
|
|
111
129
|
"chatContextFileChatContext": "Turnos persistentes, instrucciones y reglas de notificación de cámaras.",
|
|
112
130
|
"chatContextFileHomeMemory": "Educación IA y memoria doméstica aprendida y limitada.",
|
|
@@ -179,6 +197,7 @@
|
|
|
179
197
|
}
|
|
180
198
|
},
|
|
181
199
|
"buttons": {
|
|
200
|
+
"refreshSetupDoctor": "Comprobar de nuevo",
|
|
182
201
|
"installOllamaModel": "2) Install it",
|
|
183
202
|
"ollamaLibrary": "Model library",
|
|
184
203
|
"downloadOllamaModel": "1) Download model",
|
|
@@ -45,7 +45,8 @@ El resto de esta ayuda describe el modo clásico **Bridge IoT**.
|
|
|
45
45
|
## Campos de mapeo
|
|
46
46
|
|
|
47
47
|
- **Dirección** — elige KNX→IoT, IoT→KNX o bidireccional.
|
|
48
|
-
- **Tipo de canal** — MQTT usa el target como topic; REST lo usa como URL base; Modbus
|
|
48
|
+
- **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).
|
|
49
|
+
- **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.
|
|
49
50
|
- **Escala y Offset** — aplicados a KNX→IoT; IoT→KNX usa la transformación inversa.
|
|
50
51
|
- **Template** — cadena opcional que reemplaza `{{value}}`, `{{ga}}`, `{{label}}`, `{{target}}`, `{{type}}`, `{{isoTimestamp}}`.
|
|
51
52
|
- **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**.
|
|
|
88
89
|
|
|
89
90
|
### Sincronización de registro Modbus
|
|
90
91
|
|
|
91
|
-
|
|
92
|
+
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.
|
|
93
|
+
|
|
94
|
+
|Área|Lectura|Escritura|Dirección permitida|
|
|
95
|
+
|--|--|--|--|
|
|
96
|
+
| Coil | FC1 | FC5 | Ambas direcciones |
|
|
97
|
+
| Discrete input | FC2 | — | Solo Modbus → KNX |
|
|
98
|
+
| Holding register | FC3 | FC6 | Ambas direcciones |
|
|
99
|
+
| Input register | FC4 | — | Solo Modbus → KNX |
|
|
100
|
+
|
|
101
|
+
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:
|
|
102
|
+
|
|
103
|
+
```
|
|
104
|
+
msg.payload = {
|
|
105
|
+
value: 215,
|
|
106
|
+
fc: 6,
|
|
107
|
+
unitid: 1,
|
|
108
|
+
address: 9,
|
|
109
|
+
quantity: 1
|
|
110
|
+
}
|
|
111
|
+
```
|
|
112
|
+
|
|
113
|
+
`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.
|
|
114
|
+
|
|
115
|
+
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.
|
|
116
|
+
|
|
117
|
+
`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.
|
|
92
118
|
|
|
93
119
|
## Flow de ejemplo
|
|
94
120
|
|
|
@@ -79,6 +79,10 @@
|
|
|
79
79
|
"target": "Destino",
|
|
80
80
|
"method": "Método HTTP",
|
|
81
81
|
"modbusFunction": "Función Modbus",
|
|
82
|
+
"modbusMessageFormat": "Formato del mensaje Modbus",
|
|
83
|
+
"modbusUnitId": "Unit ID",
|
|
84
|
+
"modbusArea": "Área Modbus",
|
|
85
|
+
"modbusDataType": "Tipo de dato",
|
|
82
86
|
"scale": "Escala",
|
|
83
87
|
"offset": "Offset",
|
|
84
88
|
"timeout": "Tiempo de espera (ms)",
|
|
@@ -103,7 +107,7 @@
|
|
|
103
107
|
"target": "Tema, URL o registro",
|
|
104
108
|
"target_mqtt": "Tema, p. ej. knx/light/living",
|
|
105
109
|
"target_rest": "https://example/api/endpoint",
|
|
106
|
-
"target_modbus": "
|
|
110
|
+
"target_modbus": "Dirección desde cero (p. ej. 0)",
|
|
107
111
|
"template": "{\"value\":{{value}}}",
|
|
108
112
|
"property": "Propiedad/ruta opcional",
|
|
109
113
|
"method": "POST",
|
|
@@ -114,7 +118,7 @@
|
|
|
114
118
|
"default": "Destino",
|
|
115
119
|
"mqtt": "Topic MQTT",
|
|
116
120
|
"rest": "URL REST",
|
|
117
|
-
"modbus": "
|
|
121
|
+
"modbus": "Dirección Modbus (desde cero)"
|
|
118
122
|
},
|
|
119
123
|
"method": {
|
|
120
124
|
"default": "Método HTTP",
|
|
@@ -125,6 +129,20 @@
|
|
|
125
129
|
"modbus": "Función Modbus"
|
|
126
130
|
}
|
|
127
131
|
},
|
|
132
|
+
"modbus": {
|
|
133
|
+
"formatLegacy": "Mensaje escalar heredado",
|
|
134
|
+
"formatFlex": "Compatible con Flex Write",
|
|
135
|
+
"areaCoil": "Coil (lectura FC1 / escritura FC5)",
|
|
136
|
+
"areaDiscreteInput": "Discrete input (lectura FC2 solamente)",
|
|
137
|
+
"areaHoldingRegister": "Holding register (lectura FC3 / escritura FC6)",
|
|
138
|
+
"areaInputRegister": "Input register (lectura FC4 solamente)",
|
|
139
|
+
"dataTypeBool": "Booleano",
|
|
140
|
+
"dataTypeUint16": "16 bits sin signo",
|
|
141
|
+
"dataTypeInt16": "16 bits con signo",
|
|
142
|
+
"zeroBasedHint": "Usa la dirección de protocolo desde cero (0–65535), no la referencia 4xxxx que aparece en algunos manuales.",
|
|
143
|
+
"flexHint": "Flex emite msg.payload = {value,fc,unitid,address,quantity}, conectable directamente a modbus-flex-write.",
|
|
144
|
+
"readOnlyHint": "Los discrete inputs e input registers son de solo lectura y únicamente admiten Modbus → KNX."
|
|
145
|
+
},
|
|
128
146
|
"labels": {
|
|
129
147
|
"outputKnxToIoT": "Flujo KNX → IoT",
|
|
130
148
|
"outputIoTToKnx": "Confirmaciones IoT → KNX",
|
|
@@ -1,16 +1,33 @@
|
|
|
1
1
|
<script type="text/markdown" data-help-name="knxUltimateAI">
|
|
2
2
|
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.
|
|
3
3
|
|
|
4
|
-
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
|
|
4
|
+
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.
|
|
5
5
|
|
|
6
6
|
## Sorties
|
|
7
7
|
1. **Résumé/Stats** (`msg.payload` JSON)
|
|
8
8
|
2. **Anomalies** (`msg.payload` JSON)
|
|
9
9
|
3. **Assistant IA** (`msg.payload` texte, avec `msg.summary`)
|
|
10
10
|
4. **Opérations KNX** (un message Universal Mode par lecture ou écriture validée)
|
|
11
|
+
5. **TTS Ultimate** (un message d'annonce par texte parlé choisi par le modèle)
|
|
11
12
|
|
|
12
13
|
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.
|
|
13
14
|
|
|
15
|
+
### Setup Doctor et premier démarrage sûr
|
|
16
|
+
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.
|
|
17
|
+
|
|
18
|
+
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.
|
|
19
|
+
|
|
20
|
+
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.
|
|
21
|
+
|
|
22
|
+
### Intelligence Web
|
|
23
|
+
L'accès Web est désactivé par défaut. Lorsque **Autoriser l'IA à utiliser le Web** est activé, le modèle conversationnel peut choisir l'outil Web structuré directement à partir de la demande courante ; aucun mot-clé, aucune logique propre à un sujet ni aucun classificateur d'intention n'est utilisé. Chaque demande utilisateur ou cycle proactif peut effectuer au maximum trois opérations Web au total. Toutes les opérations Web externes réelles partagent le budget horaire glissant configuré.
|
|
24
|
+
|
|
25
|
+
**Autoriser les vérifications Web proactives** est une autorisation distincte. Elle exige aussi des instructions explicites rédigées par l'utilisateur dans **Éducation de l'IA**, respecte l'intervalle minimal configuré et ne démarre qu'après que KNX AI a appris un chat destinataire depuis au moins une demande normale. Sans ces deux autorisations, aucune opération Web n'est effectuée en arrière-plan.
|
|
26
|
+
|
|
27
|
+
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.
|
|
28
|
+
|
|
29
|
+
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.
|
|
30
|
+
|
|
14
31
|
## Commandes (entrée)
|
|
15
32
|
Envoyez `msg.topic` :
|
|
16
33
|
- `summary` (ou vide) : envoie le résumé immédiatement
|
|
@@ -43,11 +60,15 @@ Des demandes comme « Je pars », « Bonne nuit » ou « Mode cinéma » peuvent
|
|
|
43
60
|
### Demande de confirmation pour les boutons du chat
|
|
44
61
|
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.
|
|
45
62
|
|
|
46
|
-
###
|
|
47
|
-
|
|
63
|
+
### Adaptateurs des messages d’entrée/sortie
|
|
64
|
+
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.
|
|
48
65
|
|
|
49
66
|
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.
|
|
50
67
|
|
|
68
|
+
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.
|
|
69
|
+
|
|
70
|
+
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.
|
|
71
|
+
|
|
51
72
|
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.
|
|
52
73
|
|
|
53
74
|
### Adaptateurs de caméra détectés automatiquement
|
|
@@ -58,14 +79,14 @@ L’utilisateur peut demander une capture actuelle ou demander au modèle de vis
|
|
|
58
79
|
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.
|
|
59
80
|
|
|
60
81
|
### Annonces avec TTS Ultimate
|
|
61
|
-
|
|
82
|
+
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.
|
|
62
83
|
|
|
63
|
-
Le modèle décide
|
|
84
|
+
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.
|
|
64
85
|
|
|
65
86
|
### Aperçu du contexte du chat
|
|
66
87
|
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.
|
|
67
88
|
|
|
68
|
-
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.
|
|
89
|
+
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 caméra et les limites de sécurité ; les écritures KNX conservent la validation ETS/DPT locale et la confirmation configurée.
|
|
69
90
|
|
|
70
91
|
### Modification et sauvegarde de l'apprentissage CHAT
|
|
71
92
|
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.
|
|
@@ -127,10 +148,15 @@ Voici tous les champs tels qu'affichés dans l'éditeur KNX AI.
|
|
|
127
148
|
- **Endpoint URL** : URL endpoint chat/completions.
|
|
128
149
|
- **API key** : clé API (non requise avec Ollama local ; facultative pour Bionic LM Studio sauf si l’authentification du serveur est activée).
|
|
129
150
|
- **Model** : ID/nom du modèle.
|
|
151
|
+
- **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.
|
|
152
|
+
- **Autoriser les vérifications Web proactives** : autorisation distincte pour les vérifications en arrière-plan ; elle exige aussi des instructions explicites rédigées par l'utilisateur dans **Éducation de l'IA**.
|
|
153
|
+
- **Intervalle minimal des vérifications proactives** : durée minimale entre les cycles proactifs ; elle ne retarde pas les opérations Web demandées pendant un échange utilisateur actif.
|
|
154
|
+
- **Nombre maximal d'appels Web par heure** : budget glissant partagé entre les opérations Web interactives et proactives. Chaque échange ou cycle peut utiliser au maximum trois opérations au total.
|
|
155
|
+
- **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.
|
|
130
156
|
- **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.
|
|
131
157
|
- **Autoriser l’IA à lire les états KNX et commander les actionneurs** : active la sortie 4 et reste désactivé par défaut. Les objets exacts du catalogue ETS peuvent être lus ; seules les écritures vers des objets classés `command` sont acceptées. Les opérations inconnues, avec DPT discordant, invalides ou trop nombreuses, ainsi que les écritures vers des objets d'état ou neutres, sont rejetées localement.
|
|
132
158
|
- **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.
|
|
133
|
-
- **
|
|
159
|
+
- **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.
|
|
134
160
|
- **Éducation de l’IA** : consignes autoritaires gérées uniquement par l'utilisateur, lues par l'IA et jamais modifiées. C’est le seul endroit où demander des notifications proactives et définir leurs conditions, durée, heures silencieuses et répétition.
|
|
135
161
|
- 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.
|
|
136
162
|
- 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.
|
|
@@ -4,12 +4,14 @@
|
|
|
4
4
|
"sections": {
|
|
5
5
|
"groupAssistant": "Assistant IA",
|
|
6
6
|
"groupChatHome": "Conversations et maison",
|
|
7
|
-
"
|
|
7
|
+
"setupDoctor": "Setup Doctor",
|
|
8
|
+
"webIntelligence": "Intelligence Web",
|
|
9
|
+
"detectedAdapters": "Nœuds compatibles détectés et utilisés dans le chat",
|
|
8
10
|
"chatContextOverview": "Aperçu du contexte du chat",
|
|
9
11
|
"chatLearning": "Apprentissage du chat IA",
|
|
10
12
|
"quickSetup": "Configurer l'assistant",
|
|
11
13
|
"llmConnection": "Connexion Assistant IA",
|
|
12
|
-
"chatAdapter": "
|
|
14
|
+
"chatAdapter": "Ports d’entrée et de sortie du chat",
|
|
13
15
|
"homeIntelligence": "Éducation IA et mémoire",
|
|
14
16
|
"advanced": "Fournisseur et limites"
|
|
15
17
|
},
|
|
@@ -27,10 +29,13 @@
|
|
|
27
29
|
"llmIncludeRaw": "Include raw payload hex",
|
|
28
30
|
"llmAllowKnxCommands": "Autoriser l’IA à lire les états KNX et commander les actionneurs",
|
|
29
31
|
"llmRequireCommandConfirmation": "Demander confirmation avant d’envoyer les commandes KNX",
|
|
30
|
-
"
|
|
32
|
+
"webAccessEnabled": "Autoriser l’IA à utiliser le Web",
|
|
33
|
+
"webProactiveEnabled": "Autoriser les vérifications Web proactives",
|
|
34
|
+
"webProactiveIntervalMinutes": "Intervalle minimal des vérifications proactives",
|
|
35
|
+
"webMaxCallsPerHour": "Nombre maximal d’appels Web par heure",
|
|
36
|
+
"chatAdapterPreset": "Adaptateur des messages d’entrée/sortie",
|
|
31
37
|
"chatInputCode": "Mappage d’entrée (chat → KNX AI)",
|
|
32
38
|
"chatOutputCode": "Mappage de sortie (KNX AI → chat)",
|
|
33
|
-
"ttsUltimateNodeId": "Nœud TTS Ultimate pour les annonces",
|
|
34
39
|
"aiEducation": "Éducation IA (gérée par l'utilisateur)",
|
|
35
40
|
"llmIncludeDocsSnippets": "Include documentation snippets (help/README/examples)"
|
|
36
41
|
},
|
|
@@ -38,7 +43,8 @@
|
|
|
38
43
|
"summary": "Résumé/Stats",
|
|
39
44
|
"anomalies": "Anomalies",
|
|
40
45
|
"assistant": "Assistant IA",
|
|
41
|
-
"knxCommands": "Opérations KNX"
|
|
46
|
+
"knxCommands": "Opérations KNX",
|
|
47
|
+
"ttsUltimate": "Annonces TTS Ultimate"
|
|
42
48
|
},
|
|
43
49
|
"selectlists": {
|
|
44
50
|
"llmProvider": {
|
|
@@ -55,12 +61,28 @@
|
|
|
55
61
|
"chatAdapter": {
|
|
56
62
|
"none": "Aucun adaptateur"
|
|
57
63
|
},
|
|
58
|
-
"
|
|
59
|
-
"
|
|
60
|
-
"
|
|
64
|
+
"webProactiveInterval": {
|
|
65
|
+
"5": "5 minutes",
|
|
66
|
+
"10": "10 minutes",
|
|
67
|
+
"15": "15 minutes",
|
|
68
|
+
"30": "30 minutes",
|
|
69
|
+
"60": "1 heure",
|
|
70
|
+
"180": "3 heures"
|
|
61
71
|
}
|
|
62
72
|
},
|
|
63
73
|
"messages": {
|
|
74
|
+
"setupDoctorLoading": "Analyse de cette installation…",
|
|
75
|
+
"setupDoctorUnavailable": "Setup Doctor est temporairement indisponible.",
|
|
76
|
+
"setupDoctorPromptsTitle": "Essayer votre installation",
|
|
77
|
+
"setupDoctorPromptsHint": "Chaque suggestion ouvre l’Assistant Web avec une demande personnalisée et sûre. Rien n’est exécuté automatiquement.",
|
|
78
|
+
"setupDoctorDeployHint": "Setup Doctor lit le dernier flow déployé. Déployez les modifications, puis revérifiez.",
|
|
79
|
+
"setupDoctorPass": "OK",
|
|
80
|
+
"setupDoctorWarn": "Vérifier",
|
|
81
|
+
"setupDoctorFail": "Corriger",
|
|
82
|
+
"setupDoctorInfo": "Optionnel",
|
|
83
|
+
"webAccessHint": "Le modèle choisit sémantiquement cet outil Web général ; aucun mot-clé ni classificateur d’intention n’est utilisé. Les sites externes et le service de recherche reçoivent la requête et l’adresse IP publique de ce serveur. Les données privées KNX, caméra, chat, mémoire et identifiants d’accès ne sont jamais ajoutées automatiquement.",
|
|
84
|
+
"webProactiveHint": "Cette autorisation distincte exige aussi des instructions explicites dans l’Éducation de l’IA et un chat destinataire appris depuis une demande normale. Le modèle décide quoi vérifier ; les autorisations des autres outils et les règles de confirmation KNX restent applicables.",
|
|
85
|
+
"webBudgetHint": "Le budget glissant compte les appels externes réels du chat et des vérifications proactives.",
|
|
64
86
|
"lmStudioContextAvailable": "Contexte maximal du modèle",
|
|
65
87
|
"lmStudioContextLoading": "Vérification du contexte actif du modèle",
|
|
66
88
|
"lmStudioContextInactive": "Modèle inactif ; les valeurs par défaut de Bionic seront utilisées à la première requête",
|
|
@@ -76,16 +98,13 @@
|
|
|
76
98
|
"installOllamaModelFailed": "Failed to install Ollama model",
|
|
77
99
|
"ollamaInstallSteps": "1) Open the model library and copy the model name (for example llama3.1). 2) Put the name in the Model field and click Install it.",
|
|
78
100
|
"ollamaStartedAuto": "Ollama server started automatically.",
|
|
79
|
-
"detectedAdaptersLoading": "Détection des
|
|
80
|
-
"detectedAdaptersNone": "Aucun
|
|
81
|
-
"detectedAdaptersUnavailable": "La détection
|
|
101
|
+
"detectedAdaptersLoading": "Détection des nœuds compatibles installés…",
|
|
102
|
+
"detectedAdaptersNone": "Aucun nœud compatible détecté.",
|
|
103
|
+
"detectedAdaptersUnavailable": "La détection des nœuds compatibles est temporairement indisponible.",
|
|
82
104
|
"detectedAdapterDetected": "Détecté",
|
|
83
105
|
"detectedAdapterControllers": "Contrôleurs",
|
|
84
106
|
"detectedAdapterCameras": "Caméras",
|
|
85
107
|
"detectedAdapterNodes": "Nœuds",
|
|
86
|
-
"ttsUltimateUnknownFlow": "Flow sans nom",
|
|
87
|
-
"ttsUltimateUnavailable": "Nœud TTS Ultimate indisponible",
|
|
88
|
-
"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.",
|
|
89
108
|
"chatContextLoading": "Chargement du résumé du contexte du chat…",
|
|
90
109
|
"chatContextUnavailable": "Le résumé du contexte du chat est temporairement indisponible.",
|
|
91
110
|
"chatLearningOpenHint": "Ouvre l’interface web directement dans l’éditeur d’apprentissage CHAT partagé pour afficher, modifier, copier ou sauvegarder son fichier persistant.",
|
|
@@ -106,7 +125,6 @@
|
|
|
106
125
|
"chatContextSourceEtsProject": "Sémantique ETS et inventaire complet du projet Node-RED.",
|
|
107
126
|
"chatContextSourceMemoryEducation": "Contexte de session, Éducation IA et mémoire domestique limitée.",
|
|
108
127
|
"chatContextSourceCameras": "Caméras détectées et leurs fonctionnalités disponibles.",
|
|
109
|
-
"chatContextSourceTtsUltimate": "Nœud TTS Ultimate sélectionné pour les annonces.",
|
|
110
128
|
"chatContextSourceBadge": "Source",
|
|
111
129
|
"chatContextFileChatContext": "Tours de conversation persistants, instructions et règles de notification des caméras.",
|
|
112
130
|
"chatContextFileHomeMemory": "Éducation IA et mémoire domestique apprise et limitée.",
|
|
@@ -179,6 +197,7 @@
|
|
|
179
197
|
}
|
|
180
198
|
},
|
|
181
199
|
"buttons": {
|
|
200
|
+
"refreshSetupDoctor": "Revérifier",
|
|
182
201
|
"installOllamaModel": "2) Install it",
|
|
183
202
|
"ollamaLibrary": "Model library",
|
|
184
203
|
"downloadOllamaModel": "1) Download model",
|