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

package/nodes/locales/it/knxUltimateAI.html

@@ -1,204 +1,5 @@
-<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 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 decide da ogni richiesta corrente se servono informazioni pubbliche aggiornate e può scegliere il tool Web strutturato senza parole chiave, logiche specifiche per argomento o classificatori d'intento. Ogni turno utente o esecuzione di una pianificazione creata dall'utente può effettuare al massimo tre operazioni Web complessive. Tutte le operazioni Web esterne reali condividono il budget orario scorrevole configurato.
-
-KNX AI non avvia alcun ciclo fisso di polling Web in background. Se un dettaglio essenziale cambierebbe in modo sostanziale la risposta o la query—per esempio argomento, ambito, luogo, intervallo temporale o risultato desiderato—il modello pone una sola domanda concisa e non esegue operazioni Web finché l'utente non risponde. I controlli futuri o ricorrenti vengono creati soltanto da una richiesta esplicita in linguaggio naturale tramite lo scheduler.
-
-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.
-
-### Pianificazioni e promemoria in linguaggio naturale
-Nel normale linguaggio della chat, l'utente può chiedere a KNX AI di creare, elencare o annullare un promemoria, un monitoraggio o un futuro comando domestico, una sola volta oppure con ripetizione. Il modello sceglie semanticamente lo strumento strutturato di pianificazione `scheduleActions` partendo dalla richiesta completa e conserva l'obiettivo e tutte le condizioni come istruzione in linguaggio umano. Non esistono parole chiave per le pianificazioni, liste di frasi trigger o classificatori di intent rigidi: la formulazione e la lingua non limitano la funzione.
-
-Le pianificazioni appartengono alla sessione chat e persistono per singolo nodo KNX AI anche dopo il riavvio di Node-RED. Lo stato di runtime autorevole è `<userDir>/knxai/schedules/knxai-schedules-<node-id>.json`; KNX AI genera anche `<userDir>/knxai/schedules/knxai-schedules-<node-id>.md` come vista leggibile. Un piano può essere eseguito una volta, ripetersi a intervalli di almeno cinque minuti e avere una scadenza facoltativa. Il modello può elencare o annullare solo le pianificazioni attive appartenenti alla chat corrente, salvo richiesta esplicita dell'utente di annullarle tutte per quella chat.
-
-Quando arriva il momento di eseguire un'attività, KNX AI avvia un passaggio separato del modello usando l'istruzione in linguaggio umano salvata come autorizzazione attendibile dell'utente. Un monitoraggio resta silenzioso se la condizione non è soddisfatta. Al momento dell'esecuzione valgono ancora i permessi esistenti: un monitoraggio meteo richiede **Consenti all'AI di usare il Web** e usa lo stesso budget Web, un risultato parlato esce dall'uscita 5 e richiede quindi un nodo TTS Ultimate collegato, mentre gli strumenti telecamera restano limitati agli adapter rilevati. Una scrittura KNX pianificata conserva tutti i controlli ETS/DPT e, se abilitata, mostra l'anteprima alla stessa sessione chat e attende la conferma prima di emettere qualsiasi messaggio dall'uscita 4.
-
-Per esempio, l'utente può scrivere: «Per i prossimi cinque giorni, controlla ogni 30 minuti le previsioni per Cortemaggiore e usa TTS Ultimate solo se sono previsti temporali». KNX AI può conservare l'intera condizione e la durata in un unico monitoraggio ricorrente; restano necessari i permessi Web e il collegamento TTS descritti sopra.
-
-## Comandi (input)
-Invia `msg.topic`:
-- `summary` (o vuoto): emette subito la summary
-- `reset`: azzera storico, contatori, memoria domestica appresa, tutti i context CHAT persistenti e ogni pianificazione di questo nodo; l'Educazione AI configurata nel nodo resta invariata
-- `ask`: invia una domanda all'LLM configurato
-- `confirm` / `cancel`: conferma o annulla i comandi KNX in attesa senza richiamare l'LLM
-- `clear_chat`: azzera turni recenti, istruzioni persistenti e comandi in attesa della sessione corrente e annulla le sue pianificazioni attive; le altre sessioni ed Educazione AI restano invariate
-
-Per `ask`, passa la domanda in `msg.prompt` (consigliato), in `msg.payload` (stringa), oppure nei comuni campi Telegram `msg.payload.content` / `msg.payload.text`.
-
-Se l'elaborazione dura più di 1,2 secondi, l'uscita 3 emette subito il messaggio intermedio localizzato «Sto pensando…», con `msg.knxAi.type = "thinking"` e `msg.knxAi.transient = true`. L'adattatore chat lo invia allo stesso utente, mentre la risposta finale arriva normalmente appena pronta. Questo messaggio di avanzamento non viene mai salvato nel contesto della conversazione né nella memoria appresa.
-
-Ogni richiesta chat LLM usa un timeout minimo di 30 minuti, indipendente dal provider. Non esiste un campo timeout da gestire nell'editor. È un'attesa massima, non un ritardo artificiale: i modelli più veloci terminano comunque appena la risposta è pronta. Se viene raggiunto anche questo limite, KNX AI segnala che il modello non ha completato la risposta e suggerisce di riprovare o ridurre il contesto del prompt.
-
-KNX AI non espone più alcun selettore applicativo per la grandezza del contesto. Il catalogo ETS selezionato completo resta nel nodo e il modello lo interroga tramite azioni di retrieval locale limitate; nel prompt entrano soltanto gli oggetti recuperati. La ricerca considera indirizzi esatti, nomi ETS, alias, gerarchia, aree, semantica, DPT ed etichette dei valori, con ordinamento insensibile agli accenti e tollerante ai refusi, oltre a ricerca esatta, navigazione per area e scoperta delle coppie comando/stato. Senza un intervallo esplicito, gli eventi KNX e adapter coprono gli ultimi 20 minuti. Help, README, wiki, esempi e changelog inclusi nel pacchetto non vengono mai incorporati: quando serve, il modello può consultare la documentazione pubblica su GitHub tramite il tool Web. I dati ETS recuperati, la richiesta corrente e le righe di archivio compaiono una sola volta; nel blocco di analisi restano soltanto aggregati derivati del bus. I sorgenti Function completi vengono aggiunti solo per una richiesta esplicita di revisione del codice Function. KNX AI non riprova una richiesta troppo grande compattando il prompt.
-
-Prima di ogni richiesta a un modello locale, KNX AI riserva lo spazio per la risposta nella finestra attiva da 8K/16K. Limita automaticamente i turni di conversazione più recenti, le righe esatte degli archivi, la memoria domestica appresa, i risultati Web, le pianificazioni, i sorgenti Function richiesti, gli oggetti ETS recuperati e i metadati delle telecamere. È una costruzione preventiva del prompt, non un nuovo tentativo dopo un errore, e il catalogo ETS selezionato completo resta disponibile localmente tramite retrieval.
-
-### Accesso agli oggetti ETS
-La sezione **Accesso agli oggetti ETS** riproduce il selettore degli indirizzi di gruppo del profilo MQTT di IoT Bridge. Puoi filtrare la lista importata, selezionare tutto o nulla e impostare la sola lettura sugli indirizzi visibili in blocco o riga per riga. Solo gli indirizzi selezionati sono disponibili al modello. Ogni indirizzo selezionato è attivo e leggibile; quelli in sola lettura restano visibili, ma la validazione locale rifiuta ogni `GroupValue_Write` verso di loro. Non esiste migrazione né fallback legacy: dopo l'aggiornamento devi aprire ogni nodo KNX AI esistente, salvare la selezione esplicita e fare Deploy; fino a quel momento il suo catalogo AI è vuoto.
-
-Lo stato del nodo sul canvas è riservato intenzionalmente all'ultima richiesta in ingresso e al messaggio localizzato «Sto pensando…» mentre l'LLM è in esecuzione. Telegrammi KNX, aggiornamenti del gateway, frequenze del traffico, messaggi ready e risultati tecnici non lo sovrascrivono mai; restano disponibili tramite uscite, log e dati dell'Assistente.
-
-Ogni sessione Ask/chat conserva gli ultimi 8 turni e fino a 20 istruzioni a lungo termine scelte dal modello, separate per `msg.knxAi.sessionId`, `msg.sessionId` o chat ID Telegram rilevato. È il modello a decidere semanticamente quando il significato di una conversazione vada ricordato o dimenticato tramite lo strumento di memoria strutturato: non esistono liste di parole chiave o intent linguistici. Tutti i nodi KNX AI che usano lo stesso storage condividono questo context in tempo reale e lo ricaricano dopo un riavvio di Node-RED da `knxultimatestorage/knxai/memory/knxai-chat-context.knxctx`. Il file, scritto atomicamente, è limitato a 50 sessioni e 512 KB. Quando il controllo KNX è abilitato, collega l'uscita 3 al nodo di risposta della chat e l'uscita 4 a un nodo KNX Ultimate configurato in **Modalità Universale**. Con la conferma attiva, la prima risposta mostra GA, DPT e payload delle scritture senza emetterle; la stessa sessione deve poi rispondere `CONFERMA`/`ANNULLA` entro 5 minuti. Una nuova richiesta sostituisce l'eventuale piano precedente. Ogni comando confermato contiene `msg.destination`, `msg.dpt`, `msg.payload` e `msg.event = "GroupValue_Write"`.
-La memoria recente della sessione viene collocata immediatamente accanto alla richiesta corrente, così i modelli locali mantengono fatti forniti dall'utente, come nome preferito o lingua, anche dentro un prompt KNX molto grande. Il modello può rendere persistenti fatti, preferenze e istruzioni durevoli tramite `memoryActions`; resta una scelta semantica dello strumento, senza classificatori di frasi o routing per intent. Credenziali, codici di sicurezza e API key non devono mai essere appresi.
-
-Per le scritture DPT 1.xxx, gli equivalenti sicuri prodotti dall'AI `true`/`false`, `1`/`0` e `on`/`off` vengono normalizzati in un vero booleano prima della validazione locale e dell'uscita.
-
-### Letture KNX aggiornate
-Quando l'utente chiede esplicitamente uno stato attuale o aggiornato, l'AI può interrogare gli oggetti esatti del catalogo ETS importato, compresi gli oggetti di stato e di sola lettura. L'uscita 4 emette `msg.destination`, `msg.dpt`, `msg.event = "GroupValue_Read"` e `msg.readstatus = true`. Il nodo attende fino a 6 secondi ogni `GroupValue_Response` o scrittura fresca, poi restituisce i valori decodificati sull'uscita 3 e i dettagli in `msg.knxAi.readResults`. Le letture non richiedono mai conferma e non vengono mai trasformate in scritture. Se un piccolo modello locale omette il tipo di operazione e il payload, gli oggetti ETS esatti vengono normalizzati in modo sicuro come letture; un elemento con payload resta una scrittura validata.
-
-### Routine conversazionali multi-step
-Richieste come «Sto uscendo», «Buonanotte» o «Modalità cinema» possono coordinare una routine basata sullo stato corrente senza aggiungere opzioni all'editor. Nel primo passaggio LLM vengono accettate soltanto letture ETS esatte (massimo 20); KNX AI le invia e passa i risultati aggiornati GA/DPT/valore a un secondo passaggio di pianificazione isolato. Quest'ultimo può preparare fino a 12 scritture validate, ma non può avviare un altro ciclo di letture. Con la conferma attiva, l'intero piano richiede una sola conferma localizzata e nessuna scrittura o annuncio TTS richiesto viene emesso prima. Dopo la conferma ogni scrittura viene rivalidata, inoltrata in ordine e osservata fino a 4 secondi per un feedback immediato corrispondente sul bus. La risposta finale distingue il feedback osservato dalle operazioni senza feedback immediato, senza considerare queste ultime come dispositivi guasti. I dettagli sono disponibili in `msg.knxAi.routine`, `readResults`, `verifiedCount` e `unverifiedCount`.
-
-### 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.
-
-### 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. Testo e postback usano il payload RedBot `message`. Un vocale Telegram nativo arriva come `type = "audio"` con il `Buffer` OGG/Opus già scaricato da RedBot: KNX AI applica i limiti di dimensione e durata senza scaricarlo una seconda volta, lo trascrive con lo stesso provider OpenAI-compatible descritto sopra e risponde con un payload RedBot `audio` nativo, didascalia testuale e indicazione localizzata della voce generata dall'IA. Quando una scrittura KNX richiede conferma, la risposta resta intenzionalmente un payload testuale `inline-buttons`, perché RedBot non può allegare quei pulsanti allo stesso messaggio vocale. La mappatura d'uscita conserva i dati di tracciamento RedBot `originalMessage`, `chat`, `api` e `client`; anche le vecchie mappature RedBot salvate vengono aggiornate a runtime. RedBot resta una dipendenza opzionale separata.
-
-### Adapter telecamera rilevati automaticamente
-I pacchetti di telecamere installati possono pubblicare a runtime un adapter per KNX AI. Non esistono selettori né nodi telecamera da collegare a KNX AI: adapter, controller e telecamere disponibili vengono rilevati automaticamente e inseriti nel contesto della chat. `node-red-contrib-unifi-ultimate` è il primo provider supportato; altri pacchetti, come `hikvision-ultimate`, possono registrarsi tramite lo stesso contratto indipendente dal produttore.
-
-L'utente può chiedere uno snapshot aggiornato oppure domandare al modello vision che cosa è visibile. I preset Telegram e RedBot inviano l'immagine come foto nativa con didascalia. L'utente può anche creare notifiche persistenti per movimento, attraversamento di una linea intelligente o ingresso in una zona di intrusione/stazionamento, limitandole facoltativamente alle persone rilevate e a una linea o zona nominata esatta. Le regole vengono salvate nello stesso file `knxai-chat-context.knxctx` e ripristinate dopo i riavvii di Node-RED. Le sottoscrizioni agli eventi UniFi e le richieste snapshot avvengono direttamente tramite il provider rilevato: l'uscita 4 di KNX AI non è coinvolta e non servono collegamenti intermedi nel flow.
-
-Ogni evento pubblicato da un adapter rilevato automaticamente viene normalizzato e aggiunto 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. Nel prompt entrano le righe esatte più recenti dell'intervallo fornito, limitate automaticamente alla finestra attiva del modello locale.
-
-### Annunci con TTS Ultimate
-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 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: eventi KNX e adapter degli ultimi 20 minuti o dell'intervallo esplicito, catalogo ETS selezionato completo ricercabile localmente con i soli oggetti recuperati aggiunti a ciascun prompt, sorgenti Function su richiesta, memoria di sessione e domestica, Educazione AI, pianificazioni attive e telecamere rilevate. Mostra anche il contesto operativo massimo dichiarato dal modello 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 i percorsi assoluti dei file delle pianificazioni, JSON autorevole e Markdown leggibile, oltre alle directory degli archivi KNX e degli eventi adapter e al formato giornaliero `YYYY-MM-DD.knxctx`. Il file di debug locale temporaneo `knxai-last-chat-prompt-<id-nodo>.txt` contiene l'ultimo testo esatto dei messaggi system/user, inclusi i risultati del retrieval e il sottoinsieme ETS recuperato, viene sovrascritto prima di ogni chiamata chat e non contiene API key né header HTTP. L'Educazione AI è salvata nella configurazione del nodo e quindi non ha un file di runtime separato.
-
-Il modello riceve retrieval locale del catalogo ETS, letture e scritture KNX, adapter telecamera, annunci TTS, memoria persistente, accesso Web e pianificazioni/promemoria come strumenti strutturati. Può sceglierli e combinarli semanticamente partendo dalla richiesta corrente e dalle indicazioni autorevoli apprese, senza routing per intent linguistici. Il retrieval del catalogo è deterministico e locale; il runtime valida argomenti, disponibilità degli adapter telecamera e confini di sicurezza, mentre le scritture KNX conservano la validazione completa ETS/DPT locale e la conferma configurata.
-
-### Modifica e backup dell'apprendimento CHAT
-La scheda **Conversazioni e casa** nella configurazione Node-RED di KNX AI include il pulsante **Apri Apprendimento AI Chat**, che apre la Web UI Vue direttamente su questo editor per il nodo corrente.
-
-Nella UI web Vue, apri **Impostazioni → Apprendimento AI Chat** per visualizzare e modificare il file condiviso esatto `knxai-chat-context.knxctx` e il suo percorso assoluto. Il file può essere copiato, scaricato come backup o ripristinato da un altro file `.knxctx`. **Re-inizializza memoria**, protetto da una conferma esplicita, lo sostituisce con un nuovo contesto vuoto e cancella sessioni, istruzioni, sorveglianze telecamera e conferme chat pendenti in ogni nodo KNX AI che usa lo stesso archivio. I record nativi separati da tabulazioni `KNXAI_CHAT_CONTEXT 3` sono autorevoli e direttamente modificabili: `SESSION` contiene record `INSTRUCTION`, `TURN` e `CAMERA_WATCH` fino a `END_SESSION`. Il salvataggio valida e limita questi record, riscrive atomicamente il file e aggiorna il contesto attivo di ogni nodo KNX AI che usa lo stesso archivio. Un controllo di revisione impedisce di sovrascrivere o azzerare l'apprendimento cambiato dopo il caricamento nell'editor.
-
-È supportato soltanto il formato nativo V3. I precedenti file Markdown/JSON V2 e Base64 V1 non vengono volutamente letti, importati né migrati; il vecchio file `.md` resta intatto e KNX AI avvia un nuovo contesto `.knxctx`. Restano validi i limiti di 50 sessioni e 512 KB.
-
-### Accesso agli oggetti ETS
-L'accesso agli oggetti ETS è l'unica autorità operativa. Ogni indirizzo selezionato in **Accesso agli oggetti ETS** è attivo e leggibile; è anche scrivibile, a meno che sia marcato **Sola lettura**. Nessuna classificazione di ruolo dedotta viene inviata al modello della chat o usata per autorizzare una scrittura.
-
-## Intelligenza domestica proattiva guidata dall'Educazione e memoria limitata
-Da gerarchia ETS, nomi, ruoli e DPT, il nodo crea un modello semantico deterministico per persiane, finestre, porte, luci, temperatura, clima, presenza e allarmi usando termini italiani, inglesi, tedeschi, francesi, spagnoli e cinesi. Il rilevatore proattivo osserva soltanto stati non di comando di persiane, finestre e porte riconosciuti con sufficiente affidabilità.
-
-Non esistono un interruttore o impostazioni proattive avanzate separate. Una condizione viene valutata soltanto quando l'LLM è attivo e **Educazione AI** richiede esplicitamente quella notifica. L'Educazione è l'unica policy per condizioni, durata dell'apertura, ore silenziose e ripetizione. L'AI riceve durata attuale, data/ora locale e storico recente delle notifiche; decide se avvisare e quando rivalutare la stessa apertura. Senza una regola esplicita nell'Educazione, o se l'LLM non riesce a valutarla, non viene inviato alcun messaggio.
-
-L'ultima sessione chat viene ricordata come proprietario e riceve i messaggi spontanei. L'uscita 3 emette un messaggio localizzato con `msg.knxAi.type = "proactive_notification"`; un `msg.inputMessage` sintetico conserva la sessione per l'adattatore chat. Un limite rigido di tre notifiche proattive all'ora evita abusi. Il nodo non emette mai l'uscita 4 e non modifica autonomamente KNX; un'eventuale richiesta successiva passa sempre dalla normale validazione e conferma.
-
-Il riferimento appreso condiviso viene caricato all'avvio da `<userDir>/knxai/memory/knxai-home-memory.md`, riscritto atomicamente ogni 15 minuti e sempre limitato rigidamente a 5 MB. Conserva al massimo 120 osservazioni significative, 80 abitudini aggregate, 80 notifiche e 300 oggetti ETS semantici, mai un flusso illimitato di telegrammi raw. Gli elementi vecchi e meno importanti vengono eliminati per primi.
-
-**Educazione AI** è limitata a 16.000 caratteri ed è una proprietà fissa salvata con il nodo nel flow Node-RED. Solo l'utente la modifica nell'editor e la applica con Deploy. Il modello la legge come istruzione autorevole, ma non può mai scriverla o sovrascriverla. Fatti e preferenze richiesti in chat appartengono alla memoria appresa della chat; pianificazioni, promemoria, monitoraggi e comandi futuri, singoli o ricorrenti, appartengono allo scheduler semantico. Il file della memoria appresa non contiene intenzionalmente il testo dell'Educazione.
-
-## Esempio pratico di configurazione
-Inserisci l'intera policy di notifica in **Educazione AI** (`aiEducation`):
-
-```text
-Chiamami Massimo e rispondi nella stessa lingua che uso.
-Mantieni le risposte brevi, salvo quando chiedo dettagli tecnici.
-Avvisa la mia ultima chat quando una persiana, finestra o porta resta aperta per almeno 120 minuti.
-Non avvisarmi tra le 23:00 e le 07:00 e non ripetere lo stesso avviso prima di sei ore.
-La persiana dello studio può restare aperta durante il giorno: non avvisarmi.
-Quando "luce soggiorno" è ambiguo, chiedimi quale luce intendo.
-Non dire mai che un attuatore è cambiato finché un oggetto di stato KNX non lo conferma.
-```
-
-Con questa Educazione:
-
-1. Se lo stato della persiana del soggiorno rimane aperto per 120 minuti fuori dalle ore silenziose indicate, l'uscita 3 può emettere una `proactive_notification` localizzata verso l'ultima sessione chat.
-2. Se rimane aperta la persiana dello studio, l'LLM legge l'Educazione e sopprime quella notifica candidata.
-3. Se Massimo chiede poi di chiudere la persiana del soggiorno, KNX AI prepara il comando ETS esatto e applica comunque la normale validazione e conferma prima dell'uscita 4.
-
-Usa gerarchie e nomi oggetto ETS descrittivi, con ruoli di stato/comando corretti. L'Educazione può personalizzare decisioni e formulazione, ma non può autorizzare un group address inventato, cambiare un DPT o aggirare la validazione KNX.
-
-## Workflow rapido: controllo KNX
-1. Importa il CSV ETS nel gateway e configura provider, modello e credenziali LLM.
-2. Abilita **Assistente LLM** e **lettura stati e controllo attuatori KNX**; lascia attiva la conferma.
-3. Collega l'ingresso della chat al nodo KNX AI mantenendo un ID sessione/chat stabile.
-4. Collega l'uscita 3 alla risposta della chat e l'uscita 4 a KNX Ultimate in **Modalità Universale**.
-5. L'utente invia una richiesta; gli stati aggiornati vengono letti subito, mentre per le scritture l'AI mostra prima GA, DPT e valore senza scrivere sul bus.
-6. Entro 5 minuti, la stessa chat risponde esattamente `CONFERMA` oppure `ANNULLA`.
-7. Solo `CONFERMA` rivalida ed emette i comandi sull'uscita 4; verifica l'esecuzione tramite una GA di stato.
-
-## Campi di configurazione
-Di seguito sono elencati tutti i campi presenti nell'editor del nodo KNX AI.
-
-### Generale
-- **Gateway**: gateway/config node KNX Ultimate usato come sorgente telegrammi.
-- **Nome**: nome del nodo e intestazione dashboard.
-- **Topic**: topic base usato negli output del nodo.
-- Pulsante **Open KNX AI Web**: apre la dashboard web completa (`/knxUltimateAI/sidebar/page`).
-
-### Assistente AI
-- **Abilita assistente LLM**: abilita funzioni Ask/chat.
-- **Provider**: backend LLM (OpenAI-compatible, Anthropic, Ollama o Bionic LM Studio).
-- **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.
-- **Impegno di ragionamento**: preferenza indipendente dal provider per i modelli che espongono il controllo dell’impegno di ragionamento. **Automatico** non invia alcuna preferenza e conserva il valore predefinito del modello/provider. Le scelte esplicite sono `none`, `minimal`, `low`, `medium`, `high`, `xhigh` e `max`; il supporto dipende dal protocollo di richiesta e dal modello, e KNX AI riprova senza la preferenza se viene rifiutata.
-- **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.
-- **Numero massimo di chiamate Web all'ora**: budget scorrevole condiviso dalle conversazioni e dalle pianificazioni create dall'utente. Ogni turno o esecuzione pianificata 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. Ogni oggetto ETS selezionato può essere letto; ogni oggetto selezionato non marcato **Sola lettura** può essere scritto. Operazioni sconosciute, con DPT discordante, non valide o eccessive e scritture verso oggetti in sola lettura 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.
-- **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 fisse e autorevoli del nodo, modificate soltanto dall'utente e applicate con Deploy. Il modello le legge ma non le scrive mai. Qui vanno le regole proattive domestiche permanenti; fatti e preferenze richiesti in chat vanno nella memoria appresa, mentre pianificazioni, promemoria, monitoraggi e comandi futuri, singoli o ricorrenti, vanno nello scheduler semantico senza frasi di attivazione né routing per intent.
-- Gli estratti inclusi nel pacchetto da help, README, changelog, wiki ed esempi non vengono inviati nei prompt di Telegram, RedBot o CHAT personalizzate. Restano disponibili soltanto all'Assistente web per le domande tecniche sul pacchetto.
-- Pulsante **Aggiorna**: interroga il provider e popola i modelli disponibili. Durante il caricamento l'icona ruota; il completamento corretto non mostra messaggi.
-
-### Setup rapido Ollama (locale)
-- Seleziona **Provider = Ollama**.
-- Endpoint predefinito: `http://localhost:11434/api/chat`.
-- Se non trovi modelli locali, usa:
-  - **1) Scarica il modello**: apre la pagina **Libreria modelli**.
-  - **2) Installalo**: scarica e installa localmente il modello (esempio `llama3.1`).
-- Durante refresh/installazione, KNX AI prova anche ad avviare automaticamente il server Ollama quando possibile.
-- Se l'installazione fallisce per errore di connessione, verifica che Ollama sia avviato (app desktop o `ollama serve`).
-- Il contesto massimo dichiarato da `/api/show` viene usato direttamente come `num_ctx`. KNX AI non applica un budget inferiore e invia il prompt operativo deduplicato senza compattazione basata sulla dimensione, senza oltrepassare il massimo fisico dichiarato dal modello.
-- Se Node-RED gira in Docker, usa `host.docker.internal` al posto di `localhost` nell'endpoint.
-
-### Setup rapido Bionic LM Studio (locale)
-- Seleziona **Provider = Bionic LM Studio**.
-- Avvia il server API di LM Studio dalla pagina **Developer** oppure con `lms server start`.
-- Endpoint predefinito: `http://localhost:1234/v1/chat/completions`.
-- Premi **Aggiorna** per caricare tutti i modelli esposti da `/v1/models`; se non è configurato un modello viene selezionato il primo.
-- Se un modello è già caricato, KNX AI conserva la lunghezza del contesto attiva. KNX AI non carica mai un modello Bionic inattivo tramite l'API di gestione: la prima richiesta chat lascia che Bionic lo carichi JIT con i valori predefiniti salvati per il modello. Tutto il contesto disponibile viene inviato senza un budget applicativo; se non entra nella finestra attiva, la richiesta fallisce esplicitamente.
-- La API key è opzionale, salvo autenticazione attiva nelle impostazioni del server LM Studio. In Docker sostituisci `localhost` con `host.docker.internal`.
-
-## Nota sicurezza
-Se l'LLM è abilitato, il contesto traffico KNX può essere inviato all'endpoint configurato. Per privacy on-prem, usa provider locali. Un comando emesso sull'uscita 4 ha superato la validazione locale ed è stato inoltrato al flow, ma non prova che l'attuatore lo abbia eseguito. Per la conferma usa una GA di stato KNX.
+<script type="text/html" data-help-name="knxUltimateAI">
+  <p><b>Questo è un nodo legacy nascosto, mantenuto soltanto per i flow esistenti.</b></p>
+  <p>Per le nuove installazioni usa il nodo standalone <b>Cerebrum Ultimate</b> del package <code>node-red-contrib-cerebrum-ultimate</code>. Ha sostituito questo nodo e usa KNX Ultimate come integrazione compatibile opzionale.</p>
+  <p><a href="https://github.com/Supergiovane/node-red-contrib-cerebrum-ultimate#readme" target="_blank">Apri la documentazione di Cerebrum Ultimate</a>.</p>
 </script>

package/nodes/locales/it/knxUltimateAI.json

@@ -1,14 +1,15 @@
 {
   "knxUltimateAI": {
-    "title": "KNX AI (Analisi Traffico)",
+    "title": "Nodo AI legacy — usa Cerebrum Ultimate",
     "sections": {
       "groupAssistant": "Assistente AI",
-      "groupChatHome": "Conversazioni e casa",
+      "groupChatHome": "Cerebrum (BETA)",
       "setupDoctor": "Setup Doctor",
       "webIntelligence": "Intelligenza Web",
       "detectedAdapters": "Nodi compatibili rilevati ed usati in chat",
       "chatContextOverview": "Contesto disponibile alla chat",
       "chatLearning": "Apprendimento AI Chat",
+      "cerebrumMemory": "Memoria Cerebrum",
       "quickSetup": "Configurazione assistente",
       "etsAccess": "Accesso agli oggetti ETS",
       "llmConnection": "Connessione Assistente AI",
@@ -34,8 +35,8 @@
       "webAccessEnabled": "Consenti all’AI di usare il Web",
       "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)",
+      "chatInputCode": "Mappatura ingresso (chat → Cerebrum Ultimate)",
+      "chatOutputCode": "Mappatura uscita (Cerebrum Ultimate → chat)",
       "aiEducation": "Educazione AI (gestita dall'utente)"
     },
     "outputs": {
@@ -83,6 +84,7 @@
       "ollamaLibrary": "Libreria modelli",
       "downloadOllamaModel": "1) Scarica il modello",
       "openChatLearning": "Apri Apprendimento AI Chat",
+      "openCerebrumMemory": "Apri memoria Cerebrum",
       "etsSelectAll": "Seleziona tutti",
       "etsSelectNone": "Deseleziona tutti",
       "etsReadOnlyAll": "Imposta sola lettura",
@@ -108,7 +110,7 @@
       "lmStudioContextConfigured": "Contesto attivo del modello",
       "lmStudioContextFailed": "Impossibile configurare il contesto del modello",
       "lmStudioContextCurrentlyLoaded": "attualmente caricato",
-      "etsAccessHint": "Seleziona gli indirizzi di gruppo disponibili a KNX AI. Ogni indirizzo selezionato è attivo e leggibile; ogni indirizzo selezionato non marcato Sola lettura è scrivibile. I provider cloud ricevono l'intero catalogo ETS semantico selezionato; i modelli locali ricevono ciò che entra nella finestra di contesto scelta e possono recuperare localmente i dettagli mancanti.",
+      "etsAccessHint": "Seleziona gli indirizzi di gruppo disponibili a Cerebrum Ultimate. Ogni indirizzo selezionato è attivo e leggibile; ogni indirizzo selezionato non marcato Sola lettura è scrivibile. I provider cloud ricevono l'intero catalogo ETS semantico selezionato; i modelli locali ricevono ciò che entra nella finestra di contesto scelta e possono recuperare localmente i dettagli mancanti.",
       "etsFilterPlaceholder": "Filtra per nome, GA o DPT…",
       "etsSelected": "selezionati",
       "etsReadOnly": "Sola lettura",
@@ -116,7 +118,7 @@
       "etsNoGateway": "Seleziona un gateway KNX.",
       "etsNoGa": "Nessun indirizzo di gruppo trovato. Importa la lista ETS nel gateway KNX.",
       "etsCsvError": "Impossibile caricare la lista degli indirizzi di gruppo dal gateway.",
-      "reasoningEffortHint": "Preferenza facoltativa per i modelli che supportano l'impegno di ragionamento. Automatico non invia alcuna preferenza; se il provider o il modello rifiuta il valore scelto, KNX AI riprova senza di esso.",
+      "reasoningEffortHint": "Preferenza facoltativa per i modelli che supportano l'impegno di ragionamento. Automatico non invia alcuna preferenza; se il provider o il modello rifiuta il valore scelto, Cerebrum Ultimate riprova senza di esso.",
       "localContextBudget": "Finestra contesto locale",
       "localContextHint": "Imposta il contesto massimo inviato soltanto ai modelli locali. Massimo usa la finestra nota del modello selezionato; le dimensioni non disponibili vengono nascoste quando il limite del modello è noto. I provider cloud ignorano questa selezione e ricevono l'intero catalogo ETS semantico selezionato.",
       "ollamaNotSupported": "Modalita locale Ollama: API key non richiesta. Endpoint predefinito: http://localhost:11434/api/chat.",
@@ -136,6 +138,7 @@
       "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.",
+      "cerebrumMemoryOpenHint": "Apri la memoria Cerebrum leggibile dall’utente per esaminare o modificare abitudini, decisioni degli occupanti e stati della casa.",
       "chatContextIntro": "La chat riceve automaticamente queste fonti. I percorsi sottostanti sono quelli effettivi usati da questa installazione Node-RED.",
       "chatContextLimitLabel": "Contesto operativo massimo",
       "chatContextProviderManaged": "gestito dal provider/modello selezionato",
@@ -158,7 +161,7 @@
       "chatContextFileHomeMemory": "Solo memoria domestica appresa e limitata; l'Educazione AI resta nella proprietà del nodo.",
       "chatContextFileSchedules": "Stato di runtime persistente e autorevole delle pianificazioni e dei promemoria di questo nodo.",
       "chatContextFileSchedulesReadable": "Vista leggibile generata delle pianificazioni e dei promemoria di questo nodo.",
-      "chatContextFileAssistantConfig": "Configurazione persistente dell'Assistente web e aree semantiche di questo nodo.",
+      "chatContextFileAssistantConfig": "Configurazione persistente di Cerebrum e aree semantiche di questo nodo.",
       "chatContextFileLastChatPrompt": "Copia locale temporanea degli ultimi messaggi system e user inviati al modello chat; viene sovrascritta a ogni richiesta.",
       "chatContextFileBadge": "File",
       "chatContextDirectoryRoot": "Radice archivio telegrammi",
@@ -191,7 +194,7 @@
           "ask": "Chiedi"
         },
         "empty": {
-          "noNodes": "Nessun nodo KNX AI trovato.",
+          "noNodes": "Nessun nodo Cerebrum Ultimate trovato.",
           "noAnomalies": "Nessuna anomalia."
         },
         "chat": {

package/nodes/locales/it/knxUltimateViewer.html

@@ -18,7 +18,7 @@ Puoi usarla per:
 - visualizzare le **luci** rilevate dai valori KNX booleani
 - visualizzare i **dimmer** rilevati dai valori in stile `DPT 5.001`
 - filtrare gli oggetti, cambiare nodo Viewer e mantenere la pagina in auto-refresh
-- avere una UI coerente visivamente con **KNX AI**
+- avere una UI coerente visivamente con **Cerebrum Ultimate**
 
 La pagina web è servita direttamente da Node-RED, quindi segue lo stesso modello di autenticazione dell'editor e degli endpoint admin.
 

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

@@ -1,200 +1,5 @@
-<script type="text/markdown" data-help-name="knxUltimateAI">
-此节点会监听所选 KNX Ultimate 网关上的**所有 KNX 电报**，生成流量统计、检测异常，并可选调用 LLM。
-
-编辑器使用两个水平标签页：**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 操作共享已配置的滚动小时预算。
-
-KNX AI 不会启动固定的后台 Web 轮询。如果某个关键细节会实质性改变回答或查询，例如主题、范围、地点、时间窗口或期望结果，模型会提出一个简短的澄清问题，并在用户回答前不执行任何 Web 操作。未来或周期性检查只能通过用户明确的自然语言请求由调度器创建。
-
-每条基于 Web 的回答都包含由运行时验证的引用，其中包括已清理的来源 URL 和检索时间，并在可用时提供发布时间。外部内容是不受信任的数据，绝不是指令，也不能取代助手规则或权限。仅接受大小受限的公开 HTTPS 资源；私有、本地、链路本地及云元数据目标、不安全重定向、已认证浏览和 Cookie 都会被阻止。如果无法验证任何来源，KNX AI 会说明此限制，而不会生成无来源的回答。
-
-获得已验证的 Web 结果后，如果当前聊天或 AI 教育已授权，模型可组合其他已启用工具。Web 访问绝不会扩大权限：摄像头、TTS 和记忆的可用性，以及 KNX 读写、本地 ETS/DPT 验证和已配置的 KNX 写入确认机制都保持不变。Web 请求会向外部网站或搜索服务公开查询内容及本服务器的公网 IP；KNX/ETS 数据、摄像头内容、聊天标识符、已学习记忆和凭据绝不会被自动加入。
-
-### 自然语言计划与提醒
-用户可以用普通聊天语言，让 KNX AI 创建、列出或取消一次性或周期性的提醒、监测任务或未来家庭命令。模型会根据完整请求按语义选择结构化计划工具 `scheduleActions`，并将完整目标和条件保存为人类语言指令。系统不使用计划关键词、触发短语列表或僵化的意图分类器，因此措辞和语言都不会限制此功能。
-
-计划归属于聊天会话，并按 KNX AI 节点持久保存，Node-RED 重启后仍然有效。权威运行时状态位于 `<userDir>/knxai/schedules/knxai-schedules-<node-id>.json`；KNX AI 还会生成 `<userDir>/knxai/schedules/knxai-schedules-<node-id>.md` 作为易读视图。计划可以只运行一次，也可以至少每五分钟重复一次，并可选择设置到期时间。模型只能列出或取消当前聊天所拥有的活动计划，除非用户明确要求取消该聊天的全部计划。
-
-任务到期时，KNX AI 会启动一次独立的模型处理，并把已保存的人类语言指令作为可信的用户授权。监测条件未满足时不会发送消息。执行时仍须遵守现有权限：天气监测需要启用**允许 AI 使用 Web**并使用同一 Web 预算；语音结果从输出 5 发出，因此必须连接 TTS Ultimate 节点；摄像机工具仍仅限检测到的适配器。计划中的 KNX 写入仍须通过精确的 ETS/DPT 检查；启用确认后，会先向同一聊天会话显示预览，确认前输出 4 不会发出任何写入。
-
-例如，用户可以说：“接下来五天，每 30 分钟检查 Cortemaggiore 的天气预报，仅在预计有雷暴时使用 TTS Ultimate 播报。”KNX AI 可以把完整条件和期限保存为一个周期性监测任务；上述 Web 权限和 TTS 连接要求仍然适用。
-
-## 命令（输入）
-发送 `msg.topic`：
-- `summary`（或空）：立即输出摘要
-- `reset`：清空内部历史、计数器、已学习的家庭记忆、所有持久聊天上下文及此节点的全部计划；节点中配置的 AI 教育保持不变
-- `ask`：向已配置的 LLM 提问
-- `confirm` / `cancel`：无需再次调用 LLM，即可确认或取消待处理的 KNX 命令
-- `clear_chat`：清除当前会话的最近对话、持久指令和待处理命令，并取消该会话的活动计划；其他会话和 AI 教育保持不变
-
-`ask` 的问题建议放在 `msg.prompt`，也可放在 `msg.payload`（字符串）或常见 Telegram 字段 `msg.payload.content` / `msg.payload.text`。
-
-如果处理时间超过 1.2 秒，输出 3 会立即发送本地化的中间消息“我正在思考…”，并设置 `msg.knxAi.type = "thinking"` 和 `msg.knxAi.transient = true`。聊天适配器会将其发送给同一用户，最终答案准备好后仍会正常送达。此进度消息绝不会写入对话上下文或学习记忆。
-
-每个 LLM 聊天请求都使用与提供商无关的至少 30 分钟超时。编辑器中无需维护超时字段。这是最长等待时间，并非人为延迟；较快的模型仍会在响应准备好后立即完成。即使达到此限制，KNX AI 也会说明模型未完成响应，并建议重试或缩减提示上下文。
-
-KNX AI 不再提供应用级上下文大小选项。完整的已选 ETS 目录保留在节点内，由模型通过有界的本地检索动作查询；只有检索到的对象才进入提示词。搜索覆盖精确地址、ETS 名称、别名、层级、区域、语义、DPT 和数值标签，并支持忽略重音、容忍拼写错误的排序，以及精确查询、区域浏览和命令/状态配对发现。未明确指定时间范围时，KNX 与适配器事件仅覆盖最近 20 分钟。随包提供的帮助、README、Wiki、示例和变更日志不会嵌入提示词；需要时，模型可通过 Web 工具查询 GitHub 上的公开文档。检索到的 ETS 数据、当前请求和存档行各只出现一次，分析块仅保留派生的总线聚合信息。只有用户明确要求审查 Function 代码时，才加入完整的 Function 源码。KNX AI 不会通过压缩提示词来重试超大请求。
-
-每次向本地模型发起请求前，KNX AI 都会在当前 8K/16K 窗口中预留回答空间。系统会自动限制最近的对话轮次、精确存档行、已学习的家庭记忆、Web 结果、计划任务、按需提供的 Function 源码、已检索的 ETS 对象和摄像机元数据。这是在请求前构建有界提示词，并非发生超限错误后的重试；完整的已选 ETS 目录仍可通过本地检索使用。
-
-### ETS 对象访问
-此部分复用 IoT Bridge MQTT 配置中的组地址选择器。可以筛选导入列表、全选或全不选，并对当前显示的地址批量或逐行设置只读。只有选中的地址可供模型使用。每个选中的地址都处于活动状态且可读取；只读地址仍然可见，但本地验证会拒绝对其执行任何 `GroupValue_Write`。不存在迁移或旧版回退：升级后必须打开每个现有 KNX AI 节点，保存明确选择并部署；在此之前，其 AI 目录为空。
-
-Canvas 上的节点状态专门用于显示最近收到的请求，以及 LLM 运行期间本地化的“我正在思考…”状态。KNX 报文、网关更新、流量速率、ready 消息和技术结果绝不会覆盖该状态；这些信息仍可通过节点输出、日志和助手数据查看。
-
-每个 Ask/聊天会话都会保留最近 8 轮对话和最多 20 条由模型选择的长期指令，并按 `msg.knxAi.sessionId`、`msg.sessionId` 或检测到的 Telegram 聊天 ID 隔离。模型通过结构化记忆工具，按语义判断一段对话的含义应被记住还是遗忘；系统不使用语言关键词或 intent 列表。使用相同存储的所有 KNX AI 节点实时共享此上下文，并在 Node-RED 重启后从 `knxultimatestorage/knxai/memory/knxai-chat-context.knxctx` 重新加载。该文件采用原子写入，最多保存 50 个会话且不超过 512 KB。启用 KNX 控制后，将输出 3 连接到聊天发送节点，将输出 4 连接到配置为**通用模式**的 KNX Ultimate 节点。启用确认后，第一条回复会显示 GA、DPT 和 payload，但不会发送写入；同一会话必须在 5 分钟内回复“确认”或“取消”。新请求会替换旧的待处理计划。每条已确认命令都包含 `msg.destination`、`msg.dpt`、`msg.payload` 和 `msg.event = "GroupValue_Write"`。
-最近的会话记忆会紧邻当前请求放置，使本地模型即使面对很大的 KNX 提示，也能保留用户提供的事实，例如首选姓名或语言。模型可以通过 `memoryActions` 持久保存耐久的事实、偏好和指令；这仍是没有短语分类器或 intent 路由的语义工具选择。凭据、安全代码和 API 密钥绝不能被学习。
-
-对于 DPT 1.xxx 写入，AI 生成的安全等价值 `true`/`false`、`1`/`0` 和 `on`/`off` 会在本地校验和输出前统一转换为真正的布尔值。
-
-### 最新 KNX 读取
-当用户明确要求当前或最新状态时，AI 可以查询已导入 ETS 目录中的精确对象，包括状态对象和其他只读对象。输出 4 会发送 `msg.destination`、`msg.dpt`、`msg.event = "GroupValue_Read"` 和 `msg.readstatus = true`。节点会为每个 `GroupValue_Response` 或最新写入等待最多 6 秒，然后在输出 3 返回解码值，并在 `msg.knxAi.readResults` 中提供详细信息。读取从不需要确认，也绝不会转换为写入。如果小型本地模型省略操作类型和 payload，精确的 ETS 对象会被安全规范化为读取；包含 payload 的项目仍作为经过验证的写入处理。
-
-### 多步骤对话例行程序
-“我要离家”“晚安”或“影院模式”等请求可以在不增加编辑器选项的情况下，根据当前状态协调例行程序。第一次 LLM 处理仅接受精确的 ETS 读取（最多 20 个）；KNX AI 发送读取，并把最新的 GA/DPT/值结果交给隔离的第二次规划处理。第二次处理最多可准备 12 个已验证写入，但不能再次发起读取循环。启用确认时，整个计划只需一次本地化确认；确认前不会发送任何写入或所请求的 TTS 播报。确认后，每个写入都会重新验证、按顺序转发，并在最多 4 秒内观察总线上匹配的即时反馈。最终回复会区分已观察到反馈的操作与没有即时反馈的操作，但不会把后者报告为设备故障。详细信息位于 `msg.knxAi.routine`、`readResults`、`verifiedCount` 和 `unverifiedCount`。
-
-### 用于聊天按钮的确认请求
-计划等待确认时，输出 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。
-
-随附的 **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 转换成普通入站消息。文本和 postback 使用 RedBot 的 `message` payload。Telegram 原生语音以 `type = "audio"` 到达，其中包含已由 RedBot 下载的 OGG/Opus `Buffer`；KNX AI 无需再次下载即可执行大小和时长限制，使用上文所述的同一个 OpenAI-compatible 提供商进行转录，并返回带文字说明和本地化 AI 生成语音提示的原生 RedBot `audio` payload。当 KNX 写入需要确认时，回复会有意保留为文本 `inline-buttons` payload，因为 RedBot 无法把这些按钮附加到同一条语音消息。输出映射会保留 RedBot 的 `originalMessage`、`chat`、`api` 和 `client` 跟踪数据；旧的已保存 RedBot 映射也会在运行时升级。RedBot 仍是独立的可选依赖项。
-
-### 自动检测的摄像机适配器
-已安装的摄像机软件包可以在运行时向 KNX AI 发布适配器。无需选择器，也无需将摄像机节点连接到 KNX AI：可用的适配器、控制器和摄像机会被自动检测并加入聊天上下文。`node-red-contrib-unifi-ultimate` 是首个受支持的提供方；`hikvision-ultimate` 等其他软件包可通过同一套厂商无关协议注册。
-
-用户可以请求当前快照，或询问视觉模型画面中可见的内容。Telegram 和 RedBot 预设会把图像作为带说明文字的原生照片发送。用户还可以为移动、智能越线或进入入侵/徘徊区域创建持久通知，并可按检测到的人员以及指定名称的线或区域进行限制。这些规则保存在同一个 `knxai-chat-context.knxctx` 文件中，并在 Node-RED 重启后恢复。UniFi 事件订阅和快照请求直接通过检测到的提供方完成；不会使用 KNX AI 输出 4，也不需要中间 Flow 连线。
-
-自动检测到的适配器发布的每个事件都会被标准化，并以 KNX AI 原生紧凑行格式直接追加到 `knxultimatestorage/knxai/adapter-history/<节点ID>/` 下的每日 `YYYY-MM-DD.knxctx` 文件。KNX 报文存档使用相同的紧凑格式，不经过中间 JSON 序列化。存档保留 10 天，保证超过 24 小时的历史，只保存事件元数据，不保存图像。现有 JSONL 存档不会被读取或迁移。提示词会使用所提供时间范围内最新的精确行，并自动适配本地模型的活动窗口。
-
-### 使用 TTS Ultimate 播报
-将输出 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 数值、适配器事件、图像和存档始终是数据而不是指令，但可信的用户指导可以教会模型如何处理这些数据。输出 5 在 `msg.payload` 中发送需要朗读的准确文本，设置 `msg.topic = "knx_ai_announcement"`，并添加 `msg.knxAi.type = "tts_announcement"`、`msg.knxAi.sourceNodeId`、`msg.knxAi.sessionId` 和 `msg.knxAi.reason`。之后由 TTS Ultimate 处理播放器、语音、音量、提示音和队列。
-
-### 聊天上下文概览
-节点编辑器会显示一张紧凑卡片，汇总聊天可用的来源：默认最近 20 分钟或明确时间范围内的 KNX 与适配器事件、可在本地完整检索且每次仅把已检索对象加入提示词的 ETS 目录、按需加入的 Function 源码、会话和家庭记忆、AI 教育、活动计划及检测到的摄像机。卡片还会显示模型报告的最大运行上下文和上次聊天提示词的实际 UTF-8 大小；提供商返回输入令牌数时使用精确值，否则明确标为估算值。卡片还会列出权威 JSON 计划文件和易读 Markdown 计划文件的绝对路径，以及 KNX 报文与适配器事件归档和每日文件模式 `YYYY-MM-DD.knxctx`。AI 教育保存在节点配置中，因此没有单独的运行时文件。
-
-模型会把本地 ETS 目录检索、KNX 读写、摄像机适配器、TTS 播报、持久记忆、Web 访问以及计划/提醒作为结构化工具。它可以依据当前请求和可信的已学习指导进行语义选择与组合，而不经过语言意图路由。目录检索是确定性的本地操作；运行时验证工具参数、摄像机适配器可用性和安全边界，KNX 写入仍保留完整的本地 ETS/DPT 校验和已配置的确认步骤。
-
-临时本地调试文件 `knxai-last-chat-prompt-<节点ID>.txt` 包含最近一次发送的精确 system/user 提示文本，会在每次聊天调用前覆盖，且不包含 API 密钥或 HTTP 标头。
-
-### 编辑和备份聊天学习
-Node-RED 的 KNX AI 配置中，**对话与家庭**选项卡包含**打开 AI 聊天学习**按钮；它会为当前节点直接打开 Vue Web UI 中的此编辑器。
-
-在 Vue Web UI 中打开**设置 → AI 聊天学习**，即可查看和编辑准确的共享文件 `knxai-chat-context.knxctx` 及其绝对路径。可复制该文件、下载备份，或从另一个 `.knxctx` 文件恢复。**重新初始化记忆**操作受明确确认保护；它会用新的空白上下文替换该文件，并清除使用同一存储的所有 KNX AI 节点中的已保存会话、指令、摄像机监视和待处理聊天确认。以制表符分隔的原生 `KNXAI_CHAT_CONTEXT 3` 记录是权威数据，并可直接编辑：`SESSION` 包含 `INSTRUCTION`、`TURN` 和 `CAMERA_WATCH` 记录，直至 `END_SESSION`。保存时会验证并限制这些记录、以原子方式重写文件，并立即更新所有相关节点的活动上下文。修订检查会拒绝覆盖或重置编辑器加载后又发生变化的学习内容。
-
-仅支持原生 V3 格式。旧版 Markdown/JSON V2 和 Base64 V1 文件不会被读取、导入或迁移；旧的 `.md` 文件保持不变，KNX AI 会启动新的 `.knxctx` 上下文。仍保留 50 个会话和 512 KB 的限制。
-
-### ETS 对象访问
-ETS 对象访问是唯一的操作权限依据。**ETS 对象访问**中选中的每个地址都处于活动状态且可读取；除非标记为**只读**，否则也可写入。聊天模型不会收到任何推断出的角色分类，写入授权也不再依赖角色。
-
-## 由 AI 教育驱动的主动家庭智能与有限记忆
-节点会根据 ETS 层级、名称、角色和 DPT 建立确定性的语义模型。不再提供单独的开关或高级主动通知设置。只有启用 LLM 且 **AI 教育**明确要求时，系统才会评估通知。条件、持续时间、静默时段和重复频率完全由 AI 教育定义。没有明确规则或 LLM 无法评估时，不会发送任何消息。
-
-最近一次聊天会话会被记为主人并接收主动消息。输出 3 会设置 `msg.knxAi.type = "proactive_notification"`，`msg.inputMessage` 为聊天适配器保留该会话。每小时最多三条主动通知可防止消息泛滥。节点绝不会主动使用输出 4，也不会自行修改 KNX。
-
-共享的学习参考文件会在启动时从 `<userDir>/knxai/memory/knxai-home-memory.md` 加载，每 15 分钟以原子方式重写，并始终严格限制为 5 MB。最多保留 120 条重要观察、80 条聚合习惯、80 条通知和 300 个 ETS 语义对象，绝不会保存无限的原始报文流。较旧且优先级较低的项目会先被删除。
-
-**AI 教育**最多 16,000 个字符，是随节点保存在 Node-RED 流程中的固定属性。只有用户能在编辑器中修改，并通过 Deploy 应用。模型会将其作为权威指导读取，但绝不能写入或覆盖。聊天中要求记住的事实和偏好属于学习到的聊天记忆；一次性或周期性的计划、提醒、监测和未来命令属于语义调度器。学习记忆文件有意不包含 AI 教育文本。
-
-## 实用配置示例
-请将完整的通知策略写入 **AI 教育** (`aiEducation`)：
-
-```text
-称呼我为 Alex，并使用与我相同的语言回答。
-除非我要求技术细节，否则回答要简短。
-卷帘、窗户或门保持打开至少 120 分钟时，通知我最近的聊天。
-23:00 到 07:00 之间不要通知，同一提醒在六小时内不要重复。
-书房卷帘白天可以保持开启：不要因此通知我。
-如果“客厅灯”指向多个灯，请先询问我具体是哪一个。
-在 KNX 状态对象确认之前，绝不要声称执行器已经改变。
-```
-
-使用这些设置后，客厅卷帘开启 120 分钟时，输出 3 可以发送本地化的 `proactive_notification`；而书房卷帘的候选通知会根据 AI 教育被抑制。如果 Alex 随后要求关闭客厅卷帘，KNX AI 会准备准确的 ETS 命令，但在输出 4 前仍执行正常的验证与确认。
-
-请使用清晰的 ETS 层级和对象名称，并正确设置状态/命令角色。AI 教育可以个性化决策和措辞，但不能虚构组地址、更改 DPT 或绕过 KNX 验证。
-
-## 快速工作流程：KNX 控制
-1. 将 ETS CSV 导入网关，并配置 LLM 提供商、模型和凭据。
-2. 启用 **LLM 助手**和 **读取 KNX 状态并控制执行器**；保持确认选项启用。
-3. 将聊天输入连接到 KNX AI，并保留稳定的会话/聊天 ID。
-4. 将输出 3 连接到聊天回复，将输出 4 连接到处于**通用模式**的 KNX Ultimate。
-5. 用户发送请求；当前状态会立即读取，而写入会先显示 GA、DPT 和值，不会立即写入总线。
-6. 同一聊天必须在 5 分钟内准确回复“确认”或“取消”。
-7. 只有“确认”会重新验证并在输出 4 发送命令；请通过 KNX 状态 GA 验证执行结果。
-
-## 配置字段
-以下是编辑器里用户可见的全部字段名称。
-
-### 通用
-- **Gateway**：作为电报来源的 KNX Ultimate 网关/配置节点。
-- **Name**：节点名称与仪表板标题。
-- **Topic**：节点输出使用的基础 topic。
-- **Open KNX AI Web** 按钮：打开网页仪表板（`/knxUltimateAI/sidebar/page`）。
-
-### AI 助手
-- **Enable LLM assistant**：启用 Ask/chat 功能。
-- **Provider**：LLM 后端（OpenAI-compatible、Anthropic、Ollama 或 Bionic LM Studio）。
-- **Endpoint URL**：chat/completions 接口 URL。
-- **API key**：API Key（本地 Ollama 可不填；Bionic LM Studio 在未启用服务器身份验证时也可不填）。
-- **Model**：模型 ID/名称。
-- **推理强度**：适用于支持推理强度控制的模型，且不依赖具体提供商。选择**自动**时不发送偏好，并保留模型/提供商的默认值。可明确选择 `none`、`minimal`、`low`、`medium`、`high`、`xhigh` 或 `max`；实际支持情况取决于请求协议和模型。如果该值被拒绝，KNX AI 会在不发送此偏好的情况下重试。
-- **允许 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 对象都可读取；所有未标记为**只读**的选中对象都可写入。未知、DPT 不匹配、无效或数量过多的操作，以及向只读对象的写入，都会在本地被拒绝。
-- **发送 KNX 命令前请求确认**：默认启用。先显示已验证的修改，在同一聊天会话确认前不会发送任何 KNX 命令。有命令等待确认时，回复始终会使用当前请求的语言附加准确的确认或取消说明。命令会在输出前再次验证。
-- **输入/输出消息适配器**：默认为**无适配器**。选择后会加载预定义的输入和输出映射；两者在编辑器中始终保持隐藏。
-- **AI 教育**：固定且权威的节点指导，仅由用户修改并通过 Deploy 应用。模型会读取，但绝不会写入。长期主动家庭策略在这里定义；聊天中要求记住的事实和偏好进入学习记忆，一次性或周期性的计划、提醒、监测和未来命令进入语义调度器，无需触发短语或 intent 路由。
-- 软件包附带的帮助、README、更新日志、Wiki 和示例片段不会加入 Telegram、RedBot 或自定义 CHAT 的提示词；仅网页助手在回答软件包技术问题时仍可使用这些内容。
-- **Refresh** 按钮：请求 provider 并加载可用模型 ID。加载期间图标会旋转；成功完成时不会显示额外消息。
-
-### Ollama 快速配置（本地）
-- 选择 **Provider = Ollama**。
-- 默认 endpoint：`http://localhost:11434/api/chat`。
-- 若未发现本地模型：
-  - **1) Download model**：打开 **Model library** 页面。
-  - **2) Install it**：在本机下载并安装模型（例如 `llama3.1`）。
-- 在刷新/安装模型时，KNX AI 也会在可能情况下尝试自动启动 Ollama 服务。
-- 若安装因连接错误失败，请确认 Ollama 已运行（桌面应用或 `ollama serve`）。
-- `/api/show` 报告的最大上下文会直接作为 `num_ctx` 使用。KNX AI 不应用更小的提示预算，并发送去重后的运行提示词，不进行基于大小的压缩，同时不会超过模型声明的物理上限。
-- 若 Node-RED 运行在 Docker 中，endpoint 请使用 `host.docker.internal` 替代 `localhost`。
-
-### Bionic LM Studio 快速配置（本地）
-- 选择 **Provider = Bionic LM Studio**。
-- 在 LM Studio 的 **Developer** 页面启动 API 服务，或运行 `lms server start`。
-- 默认 endpoint：`http://localhost:1234/v1/chat/completions`。
-- 点击 **Refresh** 加载 `/v1/models` 提供的全部模型；未配置模型时会自动选择第一个。
-- 如果模型已加载，KNX AI 会保留其当前上下文长度。KNX AI 不会通过管理 API 加载未运行的 Bionic 模型：首次聊天请求会让 Bionic 根据该模型已保存的默认值进行 JIT 加载。所有可用提示上下文都不受应用预算限制；如果无法放入当前窗口，请求会明确失败。
-- 除非在 LM Studio 服务设置中启用了身份验证，否则 API Key 可留空。在 Docker 中请将 `localhost` 替换为 `host.docker.internal`。
-
-## 安全说明
-启用 LLM 后，KNX 流量上下文可能发送到所配置的 endpoint。若需严格本地化，请使用本地 provider。输出 4 上的命令仅表示已通过本地验证并转发到 flow，并不能证明执行器已执行；需要确认时请使用 KNX 状态 GA。
+<script type="text/html" data-help-name="knxUltimateAI">
+  <p><b>这是一个隐藏的旧版节点，仅为现有 flow 保留。</b></p>
+  <p>新安装请使用 <code>node-red-contrib-cerebrum-ultimate</code> 软件包中的独立 <b>Cerebrum Ultimate</b> 节点。它已取代此节点，并将 KNX Ultimate 作为可选兼容集成。</p>
+  <p><a href="https://github.com/Supergiovane/node-red-contrib-cerebrum-ultimate#readme" target="_blank">打开 Cerebrum Ultimate 文档</a>。</p>
 </script>