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

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",

package/nodes/locales/it/knxUltimateAI.html

@@ -1,16 +1,33 @@
 <script type="text/markdown" data-help-name="knxUltimateAI">
 Questo nodo ascolta **tutti i telegrammi KNX** dal gateway KNX Ultimate selezionato, costruisce statistiche di traffico, rileva anomalie e può interrogare opzionalmente un LLM.
 
-L'editor usa due schede orizzontali: **Assistente AI** contiene configurazione, conoscenza/contesto, provider e limiti; **Conversazioni e casa** contiene canali chat, casa proattiva e memoria limitata.
+L'editor usa due schede orizzontali: **Assistente AI** contiene configurazione, conoscenza/contesto, provider e limiti; **Conversazioni e casa** contiene i PIN di input e output della chat, casa proattiva e memoria limitata.
 
 ## Output
 1. **Summary/Statistiche** (`msg.payload` JSON)
 2. **Anomalie** (`msg.payload` JSON)
 3. **Assistente AI** (`msg.payload` testo, con `msg.summary`)
 4. **Operazioni KNX** (un messaggio Universal Mode per ogni lettura o scrittura validata)
+5. **TTS Ultimate** (un messaggio di annuncio per ogni testo parlato scelto dal modello)
 
 Ogni messaggio emesso dalle uscite 3 e 4 contiene anche una copia del messaggio originale in ingresso in `msg.inputMessage`. In questo modo payload, topic, metadati della chat e qualsiasi altra proprietà di ingresso restano disponibili per i nodi successivi. Gli errori di clonazione o di invio vengono intercettati e segnalati senza propagarsi al runtime di Node-RED.
 
+### Setup Doctor e primo avvio sicuro
+Il **Setup Doctor** automatico controlla gateway selezionato e importazione ETS, attivazione AI, provider, modello e chiave API, raggiungibilità del provider, collegamenti del flow, telecamere rilevate e collegamento TTS Ultimate opzionale. Il preflight del provider, senza costi, chiama soltanto l'endpoint che elenca i modelli: non invia mai una richiesta chat e non consuma token di inferenza. Telecamere e TTS sono opzionali, quindi non usarli non riduce la prontezza di base.
+
+L'inventario mostra il numero esatto di segnali KNX con indirizzo di gruppo univoco, le aree/i gruppi ETS e una stima delle funzioni logiche. Non dichiara volutamente il numero di dispositivi fisici, perché non è ricavabile in modo affidabile dal CSV ETS. Il Setup Doctor legge l'ultimo flow di cui è stato eseguito il deploy: dopo modifiche a provider, modello, preset, gateway o collegamenti, esegui quindi il deploy prima di fare clic su **Aggiorna** per ripetere i controlli.
+
+Invia `/start` o `/help` da una chat per ricevere sull'uscita chat (uscita 3) un benvenuto deterministico e localizzato, con statistiche personalizzate dell'impianto e fino a tre suggerimenti sicuri. Questo onboarding non chiama l'LLM, non legge o scrive KNX e non genera TTS. Con il preset Telegram, i suggerimenti appaiono come pulsanti della tastiera di risposta e vengono eseguiti solo dopo che l'utente ne seleziona o invia uno esplicitamente. Dopo questa selezione esplicita, un suggerimento iniziale può eseguire letture KNX esatte quando necessarie; restano invece inibiti scritture e routine KNX, azioni sulle telecamere, TTS, modifiche alla memoria persistente e apprendimento dei ruoli GA.
+
+### Intelligenza Web
+L'accesso Web è disattivato per impostazione predefinita. Quando **Consenti all'AI di usare il Web** è attivo, il modello conversazionale può scegliere il tool Web strutturato direttamente dalla richiesta corrente; non vengono usate parole chiave, logiche specifiche per argomento o classificatori d'intento. Ogni turno utente o ciclo proattivo può eseguire al massimo tre operazioni Web complessive. Tutte le operazioni Web esterne reali condividono il budget orario scorrevole configurato.
+
+**Consenti controlli Web proattivi** è un opt-in separato. Richiede anche istruzioni esplicite scritte dall'utente in **Educazione AI**, rispetta l'intervallo minimo configurato e parte solo dopo che KNX AI ha appreso una chat destinataria da almeno una normale richiesta in chat. Senza entrambe le autorizzazioni non avviene alcuna operazione Web in background.
+
+Ogni risposta basata sul Web contiene citazioni validate dal runtime con URL della fonte sanificato e ora di consultazione, oltre all'ora di pubblicazione quando disponibile. Il contenuto esterno è un dato non attendibile, mai un'istruzione, e non può sostituire le regole o i permessi dell'assistente. Sono accettate soltanto risorse HTTPS pubbliche e limitate; destinazioni private, locali, link-local e di metadata cloud, redirect non sicuri, navigazione autenticata e cookie vengono bloccati. Se nessuna fonte può essere verificata, KNX AI segnala il limite invece di generare una risposta priva di fonti.
+
+Dopo che sono disponibili risultati Web verificati, il modello può comporre gli altri tool abilitati quando la chat corrente o Educazione AI lo autorizzano. L'accesso Web non amplia mai i permessi: disponibilità di telecamere, TTS e memoria, così come letture e scritture KNX, validazione locale ETS/DPT e conferma configurata per le scritture KNX, restano invariate. Le richieste Web espongono la query e l'IP pubblico del server ai siti esterni o al servizio di ricerca; dati KNX/ETS, contenuti delle telecamere, identificativi chat, memoria appresa e credenziali non vengono mai aggiunti automaticamente.
+
 ## Comandi (input)
 Invia `msg.topic`:
 - `summary` (o vuoto): emette subito la summary
@@ -43,11 +60,15 @@ Richieste come «Sto uscendo», «Buonanotte» o «Modalità cinema» possono co
 ### Richiesta di conferma per pulsanti chat
 Quando un piano è in attesa, l'uscita 3 contiene `msg.knxAi.confirmationRequest`. L'oggetto include `required`, `status`, `sessionId`, `expiresAt`, `commandCount` e due elementi in `actions`. Usa `action.label` per il testo del pulsante Telegram, `action.callbackData` per il callback e reinvia `action.message` al nodo KNX AI per confermare o annullare senza digitare testo.
 
-### Preset adattatori chat
-La tab **Adattatori chat** carica le mappature selezionabili da `resources/KNXAIChatAdapterMappings.js`. Scegliendo un preset vengono installate internamente due mappature JavaScript sincrone predefinite: una eseguita prima che KNX AI elabori l'ingresso e una prima dell'emissione sull'uscita 3. Le mappature restano nascoste nell'editor. Errori di sintassi o esecuzione vengono intercettati e segnalati senza arrestare Node-RED.
+### Adattatori messaggi ingresso/uscita
+La sezione **Chat PIN Input e Output** carica le mappature selezionabili da `resources/KNXAIChatAdapterMappings.js`. Scegliendo un adattatore vengono installate internamente due mappature JavaScript sincrone predefinite: una eseguita prima che KNX AI elabori l'ingresso e una prima dell'emissione sull'uscita 3. Le mappature restano nascoste nell'editor. Errori di sintassi o esecuzione vengono intercettati e segnalati senza arrestare Node-RED.
 
 Il preset incluso **windkh/node-red-contrib-telegrambot** segue il contratto receiver/sender del pacchetto. Collega direttamente un `telegram receiver` a KNX AI e l'uscita 3 direttamente a un `telegram sender`. La conferma usa una tastiera Telegram temporanea: premendo **Conferma** o **Annulla** viene inviato un normale messaggio localizzato attraverso lo stesso receiver, quindi non servono `telegram event` né collegamenti callback. I vecchi messaggi `callback_query` restano accettati. La mappatura d'ingresso estrae `msg.payload.content`, `msg.payload.chatId` e la lingua Telegram. Quella d'uscita crea i campi richiesti `msg.payload.chatId`, `type` e `content`, aggiungendo `options.reply_markup` da `msg.knxAi.confirmationRequest` quando una scrittura attende conferma. Il pacchetto Telegram resta una dipendenza opzionale separata.
 
+Con questo preset, un messaggio vocale Telegram (`msg.payload.type = "voice"`) viene gestito automaticamente solo quando **Provider** è impostato su **OpenAI-compatible**. Prima di scaricare qualsiasi dato, KNX AI verifica il provider, riutilizza **URL endpoint** e **API key** già configurati e deriva `/audio/transcriptions` e `/audio/speech` dalla stessa connessione. Il collegamento `msg.payload.weblink`, che contiene il token, viene usato soltanto per il download limitato e rimosso prima che il messaggio raggiunga gli output o l'LLM. L'audio OGG/Opus viene trascritto con il default integrato `gpt-4o-mini-transcribe`; a una richiesta elaborata correttamente risponde con un vocale Telegram OGG/Opus generato con `gpt-4o-mini-tts` e `alloy`, conservando la didascalia testuale e l'eventuale tastiera di conferma. Se è selezionato un altro provider, l'utente riceve un'indicazione localizzata per scegliere OpenAI-compatible oppure inviare testo. Se la sintesi non è disponibile, fallisce o supera il limite vocale, viene inviato come fallback il testo completo. L'audio scaricato e il testo della risposta vengono inviati allo stesso provider selezionato. Messaggi di testo, foto e vecchie mappature Telegram salvate restano compatibili.
+
+La didascalia di ogni vocale nativo inizia con l'indicazione localizzata **Voce generata dall’IA**, visibile al destinatario Telegram.
+
 Il preset incluso **RedBot / node-red-contrib-chatbot (Telegram)** segue il formato comune dei messaggi RedBot. Collega direttamente `chatbot-telegram-receive` a KNX AI e l'uscita 3 direttamente a `chatbot-telegram-send`; non serve un nodo callback separato perché RedBot converte i postback dei pulsanti inline in normali messaggi in ingresso. La mappatura d'ingresso legge `transport`, `chatId`, `type`, `content` e la lingua Telegram. Quella d'uscita conserva i dati di tracciamento RedBot `originalMessage`, `chat`, `api` e `client`, quindi emette un payload `message` oppure un payload `inline-buttons` con azioni `postback` per la conferma. RedBot resta una dipendenza opzionale separata.
 
 ### Adapter telecamera rilevati automaticamente
@@ -58,14 +79,14 @@ L'utente può chiedere uno snapshot aggiornato oppure domandare al modello visio
 Ogni evento pubblicato da un adapter rilevato automaticamente viene normalizzato e aggiunto direttamente nel formato nativo compatto a righe di KNX AI a un file giornaliero `YYYY-MM-DD.knxctx` sotto `knxultimatestorage/knxai/adapter-history/<id-nodo>/`. L'archivio dei telegrammi KNX usa lo stesso formato compatto, senza serializzazione JSON intermedia. L'archivio conserva 10 giorni, garantisce più di 24 ore di storico e salva i metadati degli eventi, non le immagini. Gli archivi JSONL esistenti non vengono letti né migrati. I totali comprendono tutte le righe memorizzate nell'intervallo richiesto; i dettagli selezionati sono soltanto un campione pertinente.
 
 ### Annunci con TTS Ultimate
-Quando è installato il pacchetto opzionale `node-red-contrib-tts-ultimate`, questo compare tra gli adapter rilevati automaticamente. Il selettore elenca tutti i nodi `ttsultimate` presenti in tutti i flow del progetto, indicando flow, nome del nodo e player configurato. Scegli il nodo che deve gestire gli annunci della chat e fai il deploy del flow.
+Collega l'uscita 5 a uno o più nodi `ttsultimate` del pacchetto opzionale `node-red-contrib-tts-ultimate`. I normali collegamenti di Node-RED determinano destinazione e fan-out; usa Link Out/Link In quando il nodo TTS si trova in un'altra scheda del flow. Il precedente selettore del nodo TTS e l'iniezione interna sono stati rimossi. Le posizioni delle uscite 1–4 restano invariate, ma nei flow aggiornati occorre collegare fisicamente l'uscita 5 prima che gli annunci vocali possano raggiungere TTS Ultimate.
 
-Il modello decide se usare questo adapter ragionando sulla richiesta corrente, sulle istruzioni persistenti della chat e sull'Educazione AI gestita dall'utente: non esistono intent per gli annunci né liste di frasi di attivazione. Valori KNX, eventi degli adapter, immagini e archivi restano dati e non diventano istruzioni, ma le indicazioni autorevoli dell'utente possono insegnare al modello come agire su quei dati. KNX AI invia il testo scelto direttamente al nodo come `msg.payload`, con `msg.topic = "knx_ai_announcement"`; non servono collegamenti intermedi nel flow. TTS Ultimate gestisce poi player Sonos, voce, volume, hailing e coda.
+Il modello decide se preparare un annuncio ragionando sulla richiesta corrente, sulle istruzioni persistenti della chat e sull'Educazione AI gestita dall'utente: non esistono intent per gli annunci né liste di frasi di attivazione. Valori KNX, eventi degli adapter, immagini e archivi restano dati e non diventano istruzioni, ma le indicazioni autorevoli dell'utente possono insegnare al modello come agire su quei dati. L'uscita 5 emette il testo esatto da pronunciare in `msg.payload`, imposta `msg.topic = "knx_ai_announcement"` e aggiunge `msg.knxAi.type = "tts_announcement"` insieme a `msg.knxAi.sourceNodeId`, `msg.knxAi.sessionId` e `msg.knxAi.reason`. TTS Ultimate gestisce poi player, voce, volume, hailing e coda.
 
 ### Riepilogo del contesto della chat
 L'editor del nodo mostra una scheda compatta con le fonti disponibili alla chat: traffico KNX corrente e archiviato, eventi persistenti degli adapter, semantica ETS e progetto Node-RED, memoria di sessione e domestica, Educazione AI e telecamere rilevate. Mostra anche il contesto operativo massimo scelto dall'utente e il peso UTF-8 effettivo dell'ultimo prompt della chat; quando il provider comunica i token di input viene usato il valore esatto, altrimenti il conteggio è indicato come stima. La scheda elenca le directory assolute degli archivi KNX e degli eventi adapter e il formato giornaliero `YYYY-MM-DD.knxctx`.
 
-Il modello riceve letture e scritture KNX, adapter telecamera, annunci TTS e memoria persistente come strumenti strutturati. Può sceglierli e combinarli semanticamente partendo dalla richiesta corrente e dalle indicazioni autorevoli apprese, senza routing per intent linguistici. Il runtime valida soltanto argomenti, disponibilità degli adapter e confini di sicurezza; le scritture KNX conservano validazione ETS/DPT locale e conferma configurata.
+Il modello riceve letture e scritture KNX, adapter telecamera, annunci TTS e memoria persistente come strumenti strutturati. Può sceglierli e combinarli semanticamente partendo dalla richiesta corrente e dalle indicazioni autorevoli apprese, senza routing per intent linguistici. Il runtime valida soltanto argomenti, disponibilità degli adapter telecamera e confini di sicurezza; le scritture KNX conservano validazione ETS/DPT locale e conferma configurata.
 
 ### Modifica e backup dell'apprendimento CHAT
 La scheda **Conversazioni e casa** nella configurazione Node-RED di KNX AI include il pulsante **Apri Apprendimento AI Chat**, che apre la Web UI Vue direttamente su questo editor per il nodo corrente.
@@ -133,10 +154,15 @@ Di seguito sono elencati tutti i campi presenti nell'editor del nodo KNX AI.
 - **URL endpoint**: URL endpoint chat/completions.
 - **API key**: chiave API (non necessaria con Ollama locale; opzionale per Bionic LM Studio, salvo autenticazione attiva sul server).
 - **Modello**: ID/nome modello.
+- **Consenti all'AI di usare il Web**: disattivato per impostazione predefinita. Permette al modello di scegliere semanticamente il tool Web generale e restituire fonti verificate e citate.
+- **Consenti controlli Web proattivi**: opt-in separato per i controlli in background; richiede anche istruzioni esplicite scritte dall'utente in **Educazione AI**.
+- **Intervallo minimo dei controlli proattivi**: tempo minimo tra i cicli proattivi; non ritarda le operazioni Web richieste durante un turno utente attivo.
+- **Numero massimo di chiamate Web all'ora**: budget scorrevole condiviso dalle operazioni Web interattive e proattive. Ogni turno o ciclo può usare al massimo tre operazioni complessive.
+- **Voce Telegram**: disponibile soltanto con il provider **OpenAI-compatible**. Riutilizza automaticamente endpoint e API key di quel provider con i default integrati `gpt-4o-mini-transcribe`, `gpt-4o-mini-tts` e `alloy`; non esistono impostazioni vocali separate.
 - **Compatibilità modello chat**: il modello selezionato deve supportare l'endpoint Chat Completions configurato. I modelli legacy disponibili solo tramite completions, come `gpt-3.5-turbo-instruct`, vengono esclusi quando si aggiorna la lista. Se il provider rifiuta un valore personalizzato di temperature o il parametro del limite token, KNX AI riprova rimuovendo o sostituendo soltanto il campo incompatibile.
 - **Consenti all'AI di leggere stati KNX e comandare attuatori**: abilita l'uscita 4 ed è disattivato per default. Gli oggetti esatti del catalogo ETS possono essere letti; le scritture sono accettate solo per gli oggetti classificati come `command`. Operazioni sconosciute, con DPT discordante, non valide o eccessive e scritture verso oggetti di stato/neutrali vengono rifiutate localmente.
 - **Chiedi conferma prima di inviare comandi KNX**: attivo per default. Mostra prima le modifiche validate e non emette comandi KNX finché la stessa sessione chat non le conferma. Quando ci sono comandi in attesa, la risposta aggiunge sempre le istruzioni esatte per confermare o annullare nella lingua della richiesta corrente. I comandi vengono validati nuovamente subito prima dell'uscita.
-- **Preset adattatore**: parte da **Nessun adattatore**. La selezione carica la coppia predefinita di mappature ingresso/uscita; entrambe restano nascoste nell'editor.
+- **Adattatore messaggi ingresso/uscita**: parte da **Nessun adattatore**. La selezione carica la coppia predefinita di mappature ingresso/uscita; entrambe restano nascoste nell'editor.
 - **Educazione AI**: istruzioni autorevoli gestite soltanto dall'utente, lette dall'AI e mai modificate. È anche l'unico punto in cui richiedere notifiche proattive e definirne condizioni, durata, ore silenziose e ripetizione.
 - Gli estratti inclusi nel pacchetto da help, README, changelog, wiki ed esempi non vengono inviati nei prompt di Telegram, RedBot o CHAT personalizzate. Restano disponibili soltanto all'Assistente web per le domande tecniche sul pacchetto.
 - Pulsante **Aggiorna**: interroga il provider e popola i modelli disponibili. Durante il caricamento l'icona ruota; il completamento corretto non mostra messaggi.

package/nodes/locales/it/knxUltimateAI.json

@@ -4,12 +4,14 @@
     "sections": {
       "groupAssistant": "Assistente AI",
       "groupChatHome": "Conversazioni e casa",
-      "detectedAdapters": "Adapter rilevati automaticamente",
+      "setupDoctor": "Setup Doctor",
+      "webIntelligence": "Intelligenza Web",
+      "detectedAdapters": "Nodi compatibili rilevati ed usati in chat",
       "chatContextOverview": "Contesto disponibile alla chat",
       "chatLearning": "Apprendimento AI Chat",
       "quickSetup": "Configurazione assistente",
       "llmConnection": "Connessione Assistente AI",
-      "chatAdapter": "Canali chat",
+      "chatAdapter": "Chat PIN Input e Output",
       "homeIntelligence": "Educazione AI e memoria",
       "advanced": "Provider e limiti"
     },
@@ -27,10 +29,13 @@
       "llmIncludeRaw": "Includi payload raw in hex",
       "llmAllowKnxCommands": "Consenti all'AI di leggere stati KNX e comandare attuatori",
       "llmRequireCommandConfirmation": "Chiedi conferma prima di inviare comandi KNX",
-      "chatAdapterPreset": "Preset adattatore",
+      "webAccessEnabled": "Consenti all’AI di usare il Web",
+      "webProactiveEnabled": "Consenti controlli Web proattivi",
+      "webProactiveIntervalMinutes": "Intervallo minimo dei controlli proattivi",
+      "webMaxCallsPerHour": "Numero massimo di chiamate Web all’ora",
+      "chatAdapterPreset": "Adattatore messaggi ingresso/uscita",
       "chatInputCode": "Mappatura ingresso (chat → KNX AI)",
       "chatOutputCode": "Mappatura uscita (KNX AI → chat)",
-      "ttsUltimateNodeId": "Nodo TTS Ultimate per gli annunci",
       "aiEducation": "Educazione AI (gestita dall'utente)",
       "llmIncludeDocsSnippets": "Includi estratti documentazione (help/README/esempi)"
     },
@@ -38,7 +43,8 @@
       "summary": "Summary/Statistiche",
       "anomalies": "Anomalie",
       "assistant": "Assistente AI",
-      "knxCommands": "Operazioni KNX"
+      "knxCommands": "Operazioni KNX",
+      "ttsUltimate": "Annunci TTS Ultimate"
     },
     "selectlists": {
       "llmProvider": {
@@ -55,12 +61,17 @@
       "chatAdapter": {
         "none": "Nessun adattatore"
       },
-      "ttsUltimate": {
-        "select": "Seleziona un nodo TTS Ultimate",
-        "none": "Nessun nodo TTS Ultimate trovato"
+      "webProactiveInterval": {
+        "5": "5 minuti",
+        "10": "10 minuti",
+        "15": "15 minuti",
+        "30": "30 minuti",
+        "60": "1 ora",
+        "180": "3 ore"
       }
     },
     "buttons": {
+      "refreshSetupDoctor": "Ricontrolla",
       "refreshModels": "Aggiorna",
       "installOllamaModel": "2) Installalo",
       "ollamaLibrary": "Libreria modelli",
@@ -68,6 +79,18 @@
       "openChatLearning": "Apri Apprendimento AI Chat"
     },
     "messages": {
+      "setupDoctorLoading": "Sto analizzando questo impianto…",
+      "setupDoctorUnavailable": "Setup Doctor non è temporaneamente disponibile.",
+      "setupDoctorPromptsTitle": "Prova il tuo impianto",
+      "setupDoctorPromptsHint": "Ogni suggerimento apre l’Assistant Web con una richiesta personalizzata e sicura. Nulla viene eseguito automaticamente.",
+      "setupDoctorDeployHint": "Setup Doctor legge l’ultimo flow distribuito. Fai Deploy delle modifiche e poi ricontrolla.",
+      "setupDoctorPass": "OK",
+      "setupDoctorWarn": "Controlla",
+      "setupDoctorFail": "Correggi",
+      "setupDoctorInfo": "Opzionale",
+      "webAccessHint": "Il modello sceglie semanticamente questo tool Web generale; non vengono usate parole chiave né classificatori d’intento. I siti esterni e il servizio di ricerca ricevono la query e l’IP pubblico del server. Dati privati KNX, telecamere, chat, memoria e credenziali non vengono mai aggiunti automaticamente.",
+      "webProactiveHint": "Questo opt-in separato richiede anche istruzioni esplicite in Educazione AI e una chat destinataria appresa da una normale richiesta. Il modello decide cosa controllare; restano valide le autorizzazioni degli altri strumenti e le conferme KNX.",
+      "webBudgetHint": "Il budget scorrevole conteggia le chiamate esterne reali della chat e dei controlli proattivi.",
       "loadingModels": "Carico i modelli…",
       "loadedModels": "Modelli caricati",
       "lmStudioContextAvailable": "Contesto massimo del modello",
@@ -85,16 +108,13 @@
       "installOllamaModelFailed": "Installazione modello Ollama non riuscita",
       "ollamaInstallSteps": "1) Apri la libreria, scegli un modello e copiane il nome (es. llama3.1). 2) Inserisci il nome nel campo Modello e clicca Installalo.",
       "ollamaStartedAuto": "Server Ollama avviato automaticamente.",
-      "detectedAdaptersLoading": "Rilevamento degli adapter installati…",
-      "detectedAdaptersNone": "Nessun adapter automatico rilevato.",
-      "detectedAdaptersUnavailable": "Il rilevamento automatico degli adapter non è momentaneamente disponibile.",
+      "detectedAdaptersLoading": "Rilevamento dei nodi compatibili installati…",
+      "detectedAdaptersNone": "Nessun nodo compatibile rilevato.",
+      "detectedAdaptersUnavailable": "Il rilevamento dei nodi compatibili non è momentaneamente disponibile.",
       "detectedAdapterDetected": "Rilevato",
       "detectedAdapterControllers": "Controller",
       "detectedAdapterCameras": "Telecamere",
       "detectedAdapterNodes": "Nodi",
-      "ttsUltimateUnknownFlow": "Flow senza nome",
-      "ttsUltimateUnavailable": "Nodo TTS Ultimate non disponibile",
-      "ttsUltimateHint": "Le richieste esplicite di annuncio della chat vengono inviate direttamente al nodo scelto; non servono collegamenti nel flow.",
       "chatContextLoading": "Caricamento del riepilogo del contesto…",
       "chatContextUnavailable": "Il riepilogo del contesto della chat non è momentaneamente disponibile.",
       "chatLearningOpenHint": "Apri la Web UI direttamente nell’editor dell’apprendimento CHAT condiviso per visualizzare, modificare, copiare o salvare il suo file persistente.",
@@ -115,7 +135,6 @@
       "chatContextSourceEtsProject": "Semantica ETS e inventario completo del progetto Node-RED.",
       "chatContextSourceMemoryEducation": "Contesto di sessione, Educazione AI e memoria domestica limitata.",
       "chatContextSourceCameras": "Telecamere rilevate e relative funzionalità disponibili.",
-      "chatContextSourceTtsUltimate": "Nodo TTS Ultimate selezionato per gli annunci.",
       "chatContextSourceBadge": "Fonte",
       "chatContextFileChatContext": "Turni persistenti, istruzioni e regole di notifica delle telecamere.",
       "chatContextFileHomeMemory": "Educazione AI e memoria domestica appresa e limitata.",

package/nodes/locales/it/knxUltimateIoTBridge.html

@@ -45,7 +45,8 @@ Il resto di questo aiuto descrive la modalità classica **Bridge IoT**.
 ## Campi della mappatura
 
 - **Direzione** — scegli KNX→IoT, IoT→KNX oppure bidirezionale.
-- **Tipo canale** — per MQTT il target è il topic; per REST è l'URL base; per Modbus è il registro/indirizzo.
+- **Tipo canale** — per MQTT il target è il topic; per REST è l'URL base; per Modbus **Target** è l'indirizzo di protocollo zero-based (0–65535).
+- **Formato Modbus / Unit ID / Area / Tipo di dato** — per le nuove mappature scegli **Compatibile con Flex Write**, quindi imposta unità, area di memoria e `bool`, `uint16` o `int16`. Se il formato è assente resta attivo il contratto scalare legacy, così i flow esistenti continuano a funzionare.
 - **Scala & Offset** — applicati su KNX→IoT; IoT→KNX usa la trasformazione inversa.
 - **Template** — stringa opzionale con segnaposto `{{value}}`, `{{ga}}`, `{{label}}`, `{{target}}`, `{{type}}`, `{{isoTimestamp}}`.
 - **Timeout / Tentativi** — campi informativi esposti nel messaggio in uscita per i nodi successivi.
@@ -88,7 +89,32 @@ Il resto di questo aiuto descrive la modalità classica **Bridge IoT**.
 
 ### Sincronizzazione Modbus
 
-- Abbina il bridge ai nodi `node-red-contrib-modbus` (`modbus-flex-write`). L'uscita 1 fornisce `msg.address` e `msg.payload` già pronti.
+Il bridge è un adattatore di messaggi per `node-red-contrib-modbus`: non apre connessioni TCP/seriali e non interroga autonomamente il dispositivo. Installa una versione del pacchetto compatibile con il tuo runtime Node-RED, poi usa i suoi nodi client e di trasporto.
+
+|Area|Lettura|Scrittura|Direzione ammessa|
+|--|--|--|--|
+| Coil | FC1 | FC5 | Entrambe le direzioni |
+| Discrete input | FC2 | — | Solo Modbus → KNX |
+| Holding register | FC3 | FC6 | Entrambe le direzioni |
+| Input register | FC4 | — | Solo Modbus → KNX |
+
+Per una nuova mappatura seleziona `Formato = Compatibile con Flex Write`. Da KNX a Modbus, l'output 1 si collega direttamente a un nodo `modbus-flex-write` ed emette:
+
+```
+msg.payload = {
+  value: 215,
+  fc: 6,
+  unitid: 1,
+  address: 9,
+  quantity: 1
+}
+```
+
+`address` è sempre zero-based: se il manuale del dispositivo indica un holding register come `40010`, il relativo indirizzo di protocollo è comunemente `9`; verifica la convenzione nel manuale. Il bridge gestisce un bit o un singolo registro a 16 bit per mappatura. Al momento non combina più word, non decodifica valori a 32 bit/float e non gestisce l'ordine di byte/word.
+
+Da Modbus a KNX, collega l'uscita dati di un nodo `modbus-flex-getter` o `modbus-read` all'ingresso del bridge. Flex Getter fornisce la richiesta (`fc`, `unitid`, `address`, `quantity`) in `msg.modbusRequest`; Modbus Read la conserva in `msg.input.payload`. L'array dei valori restituiti può trovarsi in `msg.payload` oppure in `msg.values`. Il bridge supporta entrambe le forme, abbina tutte le mappature Flex comprese nella risposta e usa l'elemento corretto dell'array. Abilita **Keep Msg Properties** su Flex Getter. Scala e offset seguono `raw = KNX × scala + offset`; in ingresso viene applicata la trasformazione inversa.
+
+`Leggi valori KNX al deploy` legge soltanto KNX; pianifica le letture Modbus nel flow Modbus esterno. Le mappature legacy (comprese quelle senza `modbusMessageFormat`) continuano a emettere il precedente payload scalare con i metadati `msg.address`/`msg.modbusFunction` al livello principale.
 
 ## Flow di esempio
 

package/nodes/locales/it/knxUltimateIoTBridge.json

@@ -79,6 +79,10 @@
       "target": "Target",
       "method": "Metodo HTTP",
       "modbusFunction": "Funzione Modbus",
+      "modbusMessageFormat": "Formato messaggio Modbus",
+      "modbusUnitId": "Unit ID",
+      "modbusArea": "Area Modbus",
+      "modbusDataType": "Tipo di dato",
       "scale": "Scala",
       "offset": "Offset",
       "timeout": "Timeout (ms)",
@@ -103,7 +107,7 @@
       "target": "Topic, URL o registro",
       "target_mqtt": "Topic, es. knx/light/soggiorno",
       "target_rest": "https://example/api/endpoint",
-      "target_modbus": "Registro (es. 40001)",
+      "target_modbus": "Indirizzo zero-based (es. 0)",
       "template": "{\"value\":{{value}}}",
       "property": "Proprietà/percorso opzionale",
       "method": "POST",
@@ -114,7 +118,7 @@
         "default": "Target",
         "mqtt": "Topic MQTT",
         "rest": "URL REST",
-        "modbus": "Registro Modbus"
+        "modbus": "Indirizzo Modbus (zero-based)"
       },
       "method": {
         "default": "Metodo HTTP",
@@ -125,6 +129,20 @@
         "modbus": "Funzione Modbus"
       }
     },
+    "modbus": {
+      "formatLegacy": "Messaggio scalare legacy",
+      "formatFlex": "Compatibile con Flex Write",
+      "areaCoil": "Coil (lettura FC1 / scrittura FC5)",
+      "areaDiscreteInput": "Discrete input (lettura FC2, sola lettura)",
+      "areaHoldingRegister": "Holding register (lettura FC3 / scrittura FC6)",
+      "areaInputRegister": "Input register (lettura FC4, sola lettura)",
+      "dataTypeBool": "Booleano",
+      "dataTypeUint16": "16 bit senza segno",
+      "dataTypeInt16": "16 bit con segno",
+      "zeroBasedHint": "Usa l’indirizzo di protocollo zero-based (0–65535), non il riferimento 4xxxx riportato da alcuni manuali.",
+      "flexHint": "Flex emette msg.payload = {value,fc,unitid,address,quantity}, collegabile direttamente a modbus-flex-write.",
+      "readOnlyHint": "Discrete input e input register sono di sola lettura e possono usare solo Modbus → KNX."
+    },
     "labels": {
       "outputKnxToIoT": "Flusso KNX → IoT",
       "outputIoTToKnx": "Ack IoT → KNX",

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

@@ -1,16 +1,33 @@
 <script type="text/markdown" data-help-name="knxUltimateAI">
 此节点会监听所选 KNX Ultimate 网关上的**所有 KNX 电报**，生成流量统计、检测异常，并可选调用 LLM。
 
-编辑器使用两个水平标签页：**AI 助手**包含配置、知识/上下文以及提供商限制；**对话与家庭**包含聊天渠道、主动家庭和受限记忆。
+编辑器使用两个水平标签页：**AI 助手**包含配置、知识/上下文以及提供商限制；**对话与家庭**包含聊天输入/输出端口、主动家庭和受限记忆。
 
 ## 输出
 1. **摘要/统计**（`msg.payload` 为 JSON）
 2. **异常**（`msg.payload` 为 JSON）
 3. **AI 助手**（`msg.payload` 为文本，包含 `msg.summary`）
 4. **KNX 操作**（每个通过验证的读取或写入输出一条 Universal Mode 消息）
+5. **TTS Ultimate**（模型每选择一段语音播报，就输出一条播报消息）
 
 输出 3 和输出 4 发出的每条消息还会在 `msg.inputMessage` 中包含原始输入消息的副本。因此，原始 payload、topic、聊天元数据及其他输入属性都可供后续节点使用。克隆或输出错误会被捕获并报告，不会传播到 Node-RED 运行时。
 
+### Setup Doctor 与安全首次使用
+自动 **Setup Doctor** 会检查所选网关和 ETS 导入、AI 是否启用、提供商、模型和 API 密钥、提供商连通性、Flow 连线、已检测摄像头以及可选的 TTS Ultimate 连接。它的免费提供商预检仅调用模型列表端点：绝不发送聊天请求，也不消耗推理 token。摄像头和 TTS 均为可选项，不使用它们不会降低核心就绪度。
+
+设备清单会显示唯一 KNX 组地址信号的精确数量、ETS 区域/组以及逻辑功能的估算数量。它不会声称物理设备数量，因为无法从 ETS CSV 中可靠推导该数量。Setup Doctor 读取最近一次已部署的 Flow；因此，更改提供商、模型、预设、网关或连线后，必须先部署，再点击**刷新**重新检查。
+
+从聊天发送 `/start` 或 `/help`，即可在聊天输出（输出 3）收到确定性且已本地化的欢迎消息，其中包含个性化的安装统计和最多三条安全建议。此引导过程不调用 LLM，不读写 KNX，也不生成 TTS。使用 Telegram 预设时，建议会显示为回复键盘按钮，仅在用户明确选择或发送其中一条后才会执行。在用户明确选择后，初始建议可在需要时执行精确的 KNX 读取；KNX 写入和例程、摄像头操作、TTS、持久记忆更改以及 GA 角色学习仍会被禁止。
+
+### Web 智能
+Web 访问默认关闭。启用**允许 AI 使用 Web**后，对话模型可直接根据当前请求选择结构化 Web 工具；不使用关键词、特定主题逻辑或意图分类器。每个用户回合或主动检查周期最多执行三次 Web 操作。所有真实外部 Web 操作共享已配置的滚动小时预算。
+
+**允许主动 Web 检查**是独立授权。它还要求用户在 **AI 教育**中编写明确指令，遵守已配置的最短间隔，并且只有在 KNX AI 从至少一次普通聊天请求中记住接收方后才会启动。缺少任一授权时，都不会在后台执行 Web 操作。
+
+每条基于 Web 的回答都包含由运行时验证的引用，其中包括已清理的来源 URL 和检索时间，并在可用时提供发布时间。外部内容是不受信任的数据，绝不是指令，也不能取代助手规则或权限。仅接受大小受限的公开 HTTPS 资源；私有、本地、链路本地及云元数据目标、不安全重定向、已认证浏览和 Cookie 都会被阻止。如果无法验证任何来源，KNX AI 会说明此限制，而不会生成无来源的回答。
+
+获得已验证的 Web 结果后，如果当前聊天或 AI 教育已授权，模型可组合其他已启用工具。Web 访问绝不会扩大权限：摄像头、TTS 和记忆的可用性，以及 KNX 读写、本地 ETS/DPT 验证和已配置的 KNX 写入确认机制都保持不变。Web 请求会向外部网站或搜索服务公开查询内容及本服务器的公网 IP；KNX/ETS 数据、摄像头内容、聊天标识符、已学习记忆和凭据绝不会被自动加入。
+
 ## 命令（输入）
 发送 `msg.topic`：
 - `summary`（或空）：立即输出摘要
@@ -43,11 +60,15 @@ Canvas 上的节点状态专门用于显示最近收到的请求，以及 LLM
 ### 用于聊天按钮的确认请求
 计划等待确认时，输出 3 包含 `msg.knxAi.confirmationRequest`。该对象包括 `required`、`status`、`sessionId`、`expiresAt`、`commandCount`，以及 `actions` 中的两个项目。使用 `action.label` 作为 Telegram 按钮文本，使用 `action.callbackData` 作为回调，并将 `action.message` 发送回 KNX AI，即可在无需输入文本的情况下确认或取消。
 
-### 聊天适配器预设
-**聊天适配器**选项卡从 `resources/KNXAIChatAdapterMappings.js` 加载可选映射。选择预设会在内部安装两段预定义的同步 JavaScript 映射：一段在 KNX AI 处理输入前运行，另一段在输出 3 发出消息前运行。这些映射在编辑器中始终保持隐藏。语法和执行错误会被捕获并报告，不会停止 Node-RED。
+### 输入/输出消息适配器
+**聊天输入/输出端口**部分从 `resources/KNXAIChatAdapterMappings.js` 加载可选映射。选择适配器会在内部安装两段预定义的同步 JavaScript 映射：一段在 KNX AI 处理输入前运行，另一段在输出 3 发出消息前运行。这些映射在编辑器中始终保持隐藏。语法和执行错误会被捕获并报告，不会停止 Node-RED。
 
 随附的 **windkh/node-red-contrib-telegrambot** 预设遵循该包的 receiver/sender 消息约定。把 `telegram receiver` 直接连接到 KNX AI，并把输出 3 直接连接到 `telegram sender`。确认操作使用一次性 Telegram 回复键盘：点击**确认**或**取消**后，会通过同一个 receiver 返回普通的本地化消息，因此不需要 `telegram event` 或 callback 连线。旧的 `callback_query` 消息仍可接受。输入映射会提取 `msg.payload.content`、`msg.payload.chatId` 和 Telegram 语言；输出映射会创建所需的 `msg.payload.chatId`、`type` 和 `content`，并在写入等待确认时从 `msg.knxAi.confirmationRequest` 添加 `options.reply_markup`。Telegram 包仍是独立的可选依赖项。
 
+使用此预设时，只有将 **Provider** 设置为 **OpenAI-compatible**，Telegram 语音消息（`msg.payload.type = "voice"`）才会被自动处理。KNX AI 会在下载任何内容前验证提供商，直接复用其 **Endpoint URL** 和 **API key**，并从同一连接派生 `/audio/transcriptions` 与 `/audio/speech`。包含令牌的 `msg.payload.weblink` 仅用于受限下载，并会在消息到达输出或 LLM 之前删除。OGG/Opus 输入使用内置默认值 `gpt-4o-mini-transcribe` 转录；成功请求会收到由 `gpt-4o-mini-tts` 和 `alloy` 生成的原生 Telegram OGG/Opus 回复，同时保留文字说明和确认键盘。如果选择了其他提供商，用户会收到本地化提示，要求改选 OpenAI-compatible 或发送文字。如果语音合成不可用、失败或超过语音限制，则发送完整文字回复。下载的音频和生成的回复文本都会发送到同一个所选提供商。文字消息、照片以及较早保存的 Telegram 映射仍保持兼容。
+
+每条原生语音回复的文字说明都会以本地化的 **AI 生成的语音** 提示开头，Telegram 收件人可以看到该提示。
+
 随附的 **RedBot / node-red-contrib-chatbot (Telegram)** 预设遵循 RedBot 的通用消息格式。将 `chatbot-telegram-receive` 直接连接到 KNX AI，并将输出 3 直接连接到 `chatbot-telegram-send`；无需单独的 callback 节点，因为 RedBot 会把内联按钮的 postback 转换成普通入站消息。输入映射读取 `transport`、`chatId`、`type`、`content` 和 Telegram 语言。输出映射保留 RedBot 的 `originalMessage`、`chat`、`api` 和 `client` 跟踪数据，然后发送 `message` payload，或发送带有确认 `postback` 操作的 `inline-buttons` payload。RedBot 仍是独立的可选依赖项。
 
 ### 自动检测的摄像机适配器
@@ -58,14 +79,14 @@ Canvas 上的节点状态专门用于显示最近收到的请求，以及 LLM
 自动检测到的适配器发布的每个事件都会被标准化，并以 KNX AI 原生紧凑行格式直接追加到 `knxultimatestorage/knxai/adapter-history/<节点ID>/` 下的每日 `YYYY-MM-DD.knxctx` 文件。KNX 报文存档使用相同的紧凑格式，不经过中间 JSON 序列化。存档保留 10 天，保证超过 24 小时的历史，只保存事件元数据，不保存图像。现有 JSONL 存档不会被读取或迁移。总数涵盖所请求区间内的全部存档行；选出的详情仅是相关样本。
 
 ### 使用 TTS Ultimate 播报
-安装可选软件包 `node-red-contrib-tts-ultimate` 后，它会显示在自动检测的适配器中。选择器会列出项目所有 Flow 中的全部 `ttsultimate` 节点，并显示 Flow、节点名称和已配置的播放器。请选择负责聊天播报的节点，然后部署 Flow。
+将输出 5 连接到可选软件包 `node-red-contrib-tts-ultimate` 中的一个或多个 `ttsultimate` 节点。目标和分发由普通 Node-RED 连线决定；如果 TTS 节点位于另一个 Flow 标签页，请使用 Link Out/Link In。原有的 TTS 节点选择器和内部注入已被移除。输出 1–4 的位置保持不变，但升级后的 Flow 必须实际连接输出 5，语音播报才能到达 TTS Ultimate。
 
-模型会根据当前请求、持久聊天指令和用户管理的 AI 教育自行判断是否使用此适配器；系统没有播报 intent，也没有触发短语列表。KNX 数值、适配器事件、图像和存档始终是数据而不是指令，但可信的用户指导可以教会模型如何处理这些数据。KNX AI 会将选定文本作为 `msg.payload` 直接发送到所选节点，并设置 `msg.topic = "knx_ai_announcement"`；之后由 TTS Ultimate 处理 Sonos 播放器、语音、音量、提示音和队列。
+模型会根据当前请求、持久聊天指令和用户管理的 AI 教育自行判断是否准备播报；系统没有播报 intent，也没有触发短语列表。KNX 数值、适配器事件、图像和存档始终是数据而不是指令，但可信的用户指导可以教会模型如何处理这些数据。输出 5 在 `msg.payload` 中发送需要朗读的准确文本，设置 `msg.topic = "knx_ai_announcement"`，并添加 `msg.knxAi.type = "tts_announcement"`、`msg.knxAi.sourceNodeId`、`msg.knxAi.sessionId` 和 `msg.knxAi.reason`。之后由 TTS Ultimate 处理播放器、语音、音量、提示音和队列。
 
 ### 聊天上下文概览
 节点编辑器会显示一张紧凑卡片，汇总聊天可用的来源：当前 KNX 流量、ETS 语义与 Node-RED 项目、会话和家庭记忆、AI 教育及检测到的摄像机。卡片还会显示用户选择的最大运行上下文和上次聊天提示词的实际 UTF-8 大小；提供商返回输入令牌数时使用精确值，否则明确标为估算值。卡片还会列出 `knxai-chat-context.knxctx`、`knxai-home-memory.md` 和 `knxai-config-<节点-id>.json`，以及 KNX 报文归档的绝对根目录、该节点专用目录和每日文件模式 `YYYY-MM-DD.knxctx`。这些路径会在运行时根据已配置网关实际使用的数据目录解析。
 
-模型会把 KNX 读写、摄像机适配器、TTS 播报和持久记忆作为结构化工具。它可以依据当前请求和可信的已学习指导进行语义选择与组合，而不经过语言 intent 路由。运行时只验证工具参数、适配器可用性和安全边界；KNX 写入仍保留本地 ETS/DPT 校验和已配置的确认步骤。
+模型会把 KNX 读写、摄像机适配器、TTS 播报和持久记忆作为结构化工具。它可以依据当前请求和可信的已学习指导进行语义选择与组合，而不经过语言 intent 路由。运行时只验证工具参数、摄像机适配器可用性和安全边界；KNX 写入仍保留本地 ETS/DPT 校验和已配置的确认步骤。
 
 ### 编辑和备份聊天学习
 Node-RED 的 KNX AI 配置中，**对话与家庭**选项卡包含**打开 AI 聊天学习**按钮；它会为当前节点直接打开 Vue Web UI 中的此编辑器。
@@ -127,10 +148,15 @@ Node-RED 的 KNX AI 配置中，**对话与家庭**选项卡包含**打开 AI
 - **Endpoint URL**：chat/completions 接口 URL。
 - **API key**：API Key（本地 Ollama 可不填；Bionic LM Studio 在未启用服务器身份验证时也可不填）。
 - **Model**：模型 ID/名称。
+- **允许 AI 使用 Web**：默认关闭。允许模型按语义选择通用 Web 工具，并返回已验证、已引用的来源。
+- **允许主动 Web 检查**：用于后台检查的独立授权；还需要用户在 **AI 教育**中编写明确指令。
+- **主动检查的最短间隔**：主动检查周期之间的最短时间；不会延迟用户活动回合中请求的 Web 操作。
+- **每小时最多 Web 调用次数**：互动和主动 Web 操作共享的滚动预算。每个回合或周期最多使用三次操作。
+- **Telegram 语音**：仅在选择 **OpenAI-compatible** 提供商时可用。它会自动复用该提供商的端点和 API 密钥，并使用内置默认值 `gpt-4o-mini-transcribe`、`gpt-4o-mini-tts` 和 `alloy`；不再提供单独的语音设置。
 - **聊天模型兼容性**：所选模型必须支持已配置的 Chat Completions 端点。刷新模型列表时，会排除仅支持旧版 completions 的模型，例如 `gpt-3.5-turbo-instruct`。如果提供商拒绝自定义 temperature 值或令牌限制参数，KNX AI 会仅移除或替换不兼容字段后重试。
 - **允许 AI 读取 KNX 状态并控制执行器**：启用输出 4，默认关闭。可以读取 ETS 目录中的精确对象；仅接受写入明确标记为 `command` 的对象。未知、DPT 不匹配、无效或数量过多的操作，以及向状态或中性对象的写入，都会在本地被拒绝。
 - **发送 KNX 命令前请求确认**：默认启用。先显示已验证的修改，在同一聊天会话确认前不会发送任何 KNX 命令。有命令等待确认时，回复始终会使用当前请求的语言附加准确的确认或取消说明。命令会在输出前再次验证。
-- **适配器预设**：默认为**无适配器**。选择后会加载预定义的输入和输出映射；两者在编辑器中始终保持隐藏。
+- **输入/输出消息适配器**：默认为**无适配器**。选择后会加载预定义的输入和输出映射；两者在编辑器中始终保持隐藏。
 - **AI 教育**：仅由用户管理的权威指导，AI 可以读取但永远不能修改。主动通知及其条件、持续时间、静默时段和重复频率只能在这里定义。
 - 软件包附带的帮助、README、更新日志、Wiki 和示例片段不会加入 Telegram、RedBot 或自定义 CHAT 的提示词；仅网页助手在回答软件包技术问题时仍可使用这些内容。
 - **Refresh** 按钮：请求 provider 并加载可用模型 ID。加载期间图标会旋转；成功完成时不会显示额外消息。