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

package/nodes/locales/en/knxUltimateAI.html

@@ -1,7 +1,7 @@
 <script type="text/markdown" data-help-name="knxUltimateAI">
 This node listens to **all KNX telegrams** from the selected KNX Ultimate gateway, builds traffic statistics, detects anomalies, and can optionally query an LLM.
 
-The editor uses two horizontal tabs: **AI assistant** contains setup, knowledge/context and provider limits; **Conversations & home** contains chat input/output pins, proactive home and bounded memory.
+The editor uses two horizontal tabs: **AI assistant** contains setup, knowledge/context and provider limits; **Cerebrum (BETA)** contains chat input/output pins, proactive home and bounded memory.
 
 ## Outputs
 1. **Summary/Stats** (`msg.payload` JSON)
@@ -12,6 +12,8 @@ The editor uses two horizontal tabs: **AI assistant** contains setup, knowledge/
 
 Every message emitted by outputs 3 and 4 also contains a clone of the original input message in `msg.inputMessage`. This preserves the original payload, topic, chat metadata, and any other input properties for downstream nodes. Cloning and output errors are contained and reported instead of escaping into the Node-RED runtime.
 
+At node startup, output 3 emits a short Cerebrum supervision notice with `msg.boot = true`. When AI is enabled, the notice is generated by the selected model as a live inference test; `msg.knxAi.llmTest` is `passed`, while provider and model identify what answered. If AI is disabled or the call fails, the startup message is still emitted with an honest localized fallback and `llmTest` set to `disabled` or `failed`. This check never reads or writes KNX.
+
 ### Setup Doctor and safe first run
 The automatic **Setup Doctor** checks the selected gateway and ETS import, AI enablement, provider, model and API key, provider reachability, flow wiring, detected cameras and the optional TTS Ultimate connection. Its no-cost provider preflight calls only the provider's model-list endpoint: it never sends a chat request or consumes inference tokens. Cameras and TTS are optional, so leaving them unused does not reduce core readiness.
 
@@ -20,9 +22,9 @@ The inventory reports the exact number of unique KNX group-address signals, the
 Send `/start` or `/help` from a chat to receive a deterministic, localized welcome on the chat output (output 3), with personalized installation statistics and up to three safe suggestions. This onboarding does not call the LLM, read or write KNX, or generate TTS. With the Telegram preset, suggestions appear as reply-keyboard buttons and run only after the user explicitly selects or sends one. After that explicit selection, a starter suggestion may perform exact KNX reads when needed; KNX writes and routines, camera actions, TTS, persistent-memory changes and GA-role learning remain suppressed.
 
 ### Web Intelligence
-Web access is disabled by default. When **Allow the AI to use the Web** is enabled, the conversational model may choose the structured Web tool directly from the current request; no keywords, topic-specific logic or intent classifiers are used. Each user turn or proactive cycle can execute at most three Web operations in total. All real outbound Web operations share the configured rolling hourly budget.
+Web access is disabled by default. When **Allow the AI to use the Web** is enabled, the conversational model decides from each current request whether fresh public information is needed and may choose the structured Web tool without keywords, topic-specific logic or intent classifiers. Each user turn or user-created scheduled task run can execute at most three Web operations in total. All real outbound Web operations share the configured rolling hourly budget.
 
-**Allow proactive Web checks** is a separate opt-in. It also requires explicit user-authored instructions in **AI Education**, observes the configured minimum interval and starts only after KNX AI has learned a destination from at least one normal chat request. Without both permissions, no background Web operation occurs.
+KNX AI does not start a fixed background Web polling cycle. If an essential detail would materially change the answer or query—such as the subject, scope, place, time window or desired outcome—the model asks one concise clarification and performs no Web operation until the user answers. Future or recurring checks are created only from an explicit natural-language request through the scheduler.
 
 Every Web-backed answer contains runtime-validated citations with a sanitized source URL and retrieval time, plus publication time when available. External content is untrusted data, never instructions, and cannot override the assistant rules or permissions. Only bounded public HTTPS resources are accepted; private, local, link-local and cloud-metadata targets, unsafe redirects, authenticated browsing and cookies are blocked. If no source can be verified, KNX AI reports that limitation instead of generating an unsourced answer.
 
@@ -51,7 +53,12 @@ If processing takes longer than 1.2 seconds, output 3 emits the localized interm
 
 Every LLM chat request uses a provider-independent minimum timeout of 30 minutes. There is no timeout field to maintain in the editor. This is a maximum wait, not an artificial delay: faster models still finish as soon as their response is ready. If even this limit is reached, KNX AI reports that the model did not finish and suggests retrying or reducing the prompt context.
 
-For local providers, **Chat context amount** explicitly selects 4K, 8K, 16K or no KNX AI limit; 16K remains the default. With no KNX AI limit, KNX AI uses the model's declared or active context window without exceeding the model's physical maximum. The choice proportionally bounds the KNX, memory, Node-RED project and adapter data supplied to the model while retaining the complete agent tool contract. It never enables or disables a capability from wording, keywords or linguistic intents.
+KNX AI no longer exposes an application context-size selector. The complete selected ETS catalog stays inside the node and the model queries it through bounded local retrieval actions; only the retrieved objects enter the prompt. Search covers exact addresses, ETS names, aliases, hierarchy, areas, semantics, DPTs and value labels, with accent-insensitive and typo-tolerant ranking, plus exact lookup, area browsing and related command/status discovery. Without an explicit time range, KNX and adapter events cover the last 20 minutes. Packaged help, README, wiki, examples and changelog content are never embedded; the model may use the Web tool to consult public GitHub documentation when needed. Retrieved ETS data, the current request and archive rows each appear once, while only derived bus aggregates remain in the analysis block. Complete Function source is added only for an explicit Function-code review. KNX AI does not retry an oversized request by compacting the prompt.
+
+Before each request to a local model, KNX AI reserves answer space from the active 8K/16K window. It automatically bounds the newest conversation turns, exact archive rows, learned home memory, Web results, schedules, requested Function source, retrieved ETS objects and camera metadata. This is proactive prompt construction, not an oversized-request retry, and the complete selected ETS catalog remains available locally through retrieval.
+
+### ETS object access
+The **ETS object access** section reproduces the group-address selector used by IoT Bridge's MQTT profile. Filter the imported list, select all or none, and mark the currently shown addresses read-only in bulk or one row at a time. Only selected addresses are available to the model. Every selected address is active and readable; read-only addresses remain visible but local validation rejects every `GroupValue_Write` to them. There is no migration or legacy fallback: after upgrading, open each existing KNX AI node, save its explicit selection and Deploy; until then its AI catalog is empty.
 
 The node's canvas status is deliberately reserved for the latest incoming request and the localized “I’m thinking…” state while the LLM is running. KNX telegrams, gateway updates, traffic rates, ready messages and technical results never overwrite it; they remain available through the node outputs, logs and Assistant data.
 
@@ -85,7 +92,7 @@ Installed camera packages can publish a camera adapter to KNX AI at runtime. The
 
 The user can ask for a current snapshot or ask the vision model what is visible. Telegram and RedBot presets emit the returned image as a native photo with a caption. The user can also create persistent notifications for motion, a smart line crossing or entry into an intrusion/loiter zone, optionally limited to detected people and to an exact named line or zone. These rules are stored in the same `knxai-chat-context.knxctx` file and are restored after Node-RED restarts. UniFi event subscriptions and snapshot requests are made directly through the detected provider; KNX AI output 4 is not involved and no intermediate flow wiring is required.
 
-Every event published by an automatically detected adapter is normalized and appended directly in KNX AI's compact native row format to a daily `YYYY-MM-DD.knxctx` file under `knxultimatestorage/knxai/adapter-history/<node-id>/`. The KNX telegram archive uses the same compact format, without intermediate JSON serialization. The archive keeps 10 days, guarantees more than 24 hours of history and stores event metadata rather than snapshot images. Existing JSONL archives are neither read nor migrated. Totals cover every stored row in the requested interval; selected details are only a relevant sample.
+Every event published by an automatically detected adapter is normalized and appended directly in KNX AI's compact native row format to a daily `YYYY-MM-DD.knxctx` file under `knxultimatestorage/knxai/adapter-history/<node-id>/`. The KNX telegram archive uses the same compact format, without intermediate JSON serialization. The archive keeps 10 days, guarantees more than 24 hours of history and stores event metadata rather than snapshot images. Existing JSONL archives are neither read nor migrated. The prompt uses the newest exact rows in the supplied interval, automatically bounded for the active local-model window.
 
 ### TTS Ultimate announcements
 Wire output 5 to one or more `ttsultimate` nodes from the optional `node-red-contrib-tts-ultimate` package. Normal Node-RED wiring controls the destination and fan-out; use Link Out/Link In when the TTS node is on another flow tab. The previous TTS-node selector and internal injection have been removed. Existing output positions 1–4 are unchanged, but upgraded flows must physically connect output 5 before spoken announcements can reach TTS Ultimate.
@@ -93,27 +100,31 @@ Wire output 5 to one or more `ttsultimate` nodes from the optional `node-red-con
 The model decides whether to prepare an announcement by reasoning over the current request, persistent chat instructions and user-managed AI Education; there is no announcement intent or trigger-phrase list. KNX values, adapter events, camera content and archives remain data rather than instructions, but trusted user guidance may tell the model how to act on them. Output 5 emits the exact spoken text in `msg.payload`, sets `msg.topic = "knx_ai_announcement"`, and adds `msg.knxAi.type = "tts_announcement"` together with `msg.knxAi.sourceNodeId`, `msg.knxAi.sessionId`, and `msg.knxAi.reason`. TTS Ultimate then handles the configured player, voice, volume, hailing and queue.
 
 ### Chat context overview
-The node editor shows a compact card summarizing the sources available to the chat: live and archived KNX traffic, persistent adapter events, ETS semantics and the Node-RED project, session and home memory, AI Education, active plans and detected cameras. It also shows the user-selected maximum operational context and the actual UTF-8 size of the last chat prompt; exact provider input tokens are used when reported, otherwise the token count is marked as estimated. The card lists the absolute paths of the authoritative JSON/readable Markdown schedule files, plus the KNX telegram and adapter-event archive directories and the `YYYY-MM-DD.knxctx` daily-file pattern. AI Education is stored in the node configuration and therefore has no separate runtime file.
+The node editor shows a compact card summarizing the sources available to the chat: 20-minute or explicitly ranged KNX and adapter events, the complete locally searchable ETS catalog with only retrieved objects added to each prompt, on-demand Function source, session and home memory, AI Education, active plans and detected cameras. It also shows the model-reported maximum operational context and the actual UTF-8 size of the last chat prompt; exact provider input tokens are used when reported, otherwise the token count is marked as estimated. The card lists the absolute paths of the authoritative JSON/readable Markdown schedule files, plus the KNX telegram and adapter-event archive directories and the `YYYY-MM-DD.knxctx` daily-file pattern. A temporary `knxai-last-chat-prompt-<node-id>.txt` local debug file contains the latest exact system/user prompt text—including retrieval results and the retrieved ETS subset—is overwritten before every chat call and never contains API keys or HTTP headers. AI Education is stored in the node configuration and therefore has no separate runtime file.
 
-The model receives KNX read/write operations, camera adapters, TTS announcements, persistent memory, Web access and plans/reminders as structured tools. It can select and combine them semantically from the current request and trusted learned guidance, without linguistic intent routing. The runtime only validates tool arguments, camera-adapter availability and safety boundaries; KNX writes still use local ETS/DPT validation and the configured confirmation step.
+The model receives local ETS catalog retrieval, KNX read/write operations, camera adapters, TTS announcements, persistent memory, Web access and plans/reminders as structured tools. It can select and combine them semantically from the current request and trusted learned guidance, without linguistic intent routing. Catalog retrieval is deterministic and local; the runtime validates tool arguments, camera-adapter availability and safety boundaries, while KNX writes still use complete local ETS/DPT validation and the configured confirmation step.
 
 ### Editing and backing up CHAT learning
-The **Conversations & home** tab in the Node-RED KNX AI configuration includes an **Open AI Chat Learning** button that opens the Vue Web UI directly on this editor for the current node.
+The **Cerebrum (BETA)** tab in the Node-RED KNX AI configuration includes an **Open AI Chat Learning** button that opens the Vue Web UI directly on this editor for the current node.
 
-In the Vue web UI, open **Settings → AI Chat Learning** to view and edit the exact shared `knxai-chat-context.knxctx` file and its absolute path. The file can be copied, downloaded as a backup or restored from another `.knxctx` file. **Reinitialize Memory**, protected by an explicit confirmation, replaces it with a new empty context and clears saved sessions, instructions, camera watches and pending chat confirmations across every KNX AI node using the same storage. The native tab-separated `KNXAI_CHAT_CONTEXT 3` records are authoritative and directly editable: `SESSION` contains `INSTRUCTION`, `TURN` and `CAMERA_WATCH` records until `END_SESSION`. Saving validates and bounds these records, atomically rewrites the file and updates the live context of every KNX AI node using the same storage. A revision check refuses to overwrite or reset learning that changed after the editor loaded it.
+In the Vue web UI, open **Cerebrum → AI Chat Learning** to inspect the exact shared `knxai-chat-context.knxctx`. **Native file** exposes the authoritative editable records; **Simplified text** explains the same conversations, learned instructions and camera watches in a localized read-only view. Copy follows the selected view, while download and restore always use the complete native backup. **Reinitialize Memory**, protected by an explicit confirmation, replaces it with a new empty context and clears saved sessions, instructions, camera watches and pending chat confirmations across every KNX AI node using the same storage. Saving validates and bounds the native V3 records, atomically rewrites the file and updates every live KNX AI node sharing that storage. A revision check protects newer learning.
 
 Only the native V3 format is supported. Previous Markdown/JSON V2 and Base64 V1 files are deliberately not read, imported or migrated; the old `.md` file is left untouched and KNX AI starts a new `.knxctx` context. The 50-session and 512 KB limits still apply.
 
-### Learned KNX group-address roles
-The `neutral` role means initial uncertainty, not a permanent control ban. The model can use the structured `gaRoleActions` tool to learn that an exact ETS group address is a command, status or neutral object from trusted user teaching, persistent chat guidance, AI Education or unequivocal ETS project semantics. There is no required keyword or role intent; if the evidence is ambiguous, the model asks for clarification instead of learning.
+Open **Cerebrum → Cerebrum Memory** to inspect the shared `knxai-home-memory.md`. The **JSON** view contains the authoritative editable data, while **Simplified text** presents the same habits, occupant decisions, states, observations, notifications and known home objects as a localized read-only explanation. The browser remembers the selected view. Saving validates JSON; copy follows the current view, while download and restore remain complete backups. **Settings** contains only the strict KNX AI and Cerebrum backup import/export; it includes configuration, chat learning, home memory and schedule files.
 
-The learned role, reason and evidence are stored per node in `<userDir>/knxai/config/knxai-config-<node-id>.json` and synchronized into the bounded semantic home memory. A role learned as `command` can validate a write in the same answer and remains available after restart; the model can also forget it and restore automatic classification. Learning never invents a GA, changes its ETS DPT, bypasses payload validation or skips the configured write confirmation.
+### ETS object access
+ETS object access is the only operational authority. Every address selected in **ETS object access** is active and readable; a selected address is writable unless it is marked **Read only**. No inferred role classification is sent to the chat model or used to authorize a write.
 
 ## Education-driven proactive home intelligence and bounded memory
 From ETS hierarchy, names, roles and DPTs, the node builds a deterministic semantic model for covers, windows, doors, lights, temperature, climate, occupancy and alarms using Italian, English, German, French, Spanish and Chinese terms. Its proactive detector watches only reliably recognized non-command cover/window/door states.
 
 There is no separate switch or advanced proactive configuration. A candidate is evaluated only when the LLM is enabled and **AI Education** explicitly requests that notification. Education is the sole policy for conditions, open duration, quiet hours and repetition. The AI receives the current duration, local date/time and recent notification history; it decides whether to notify and when to reconsider the same open condition. Without an explicit Education rule, or when the LLM cannot evaluate it, no notification is sent.
 
+Cerebrum also learns bounded weekday/weekend time patterns from KNX writes and HUE, Matter or Home Assistant state changes. A pattern becomes eligible only after at least eight consistent observations spread across six distinct dates and a minimum 14-day span, with confidence of at least 0.70. Repeated telegrams on the same day cannot accelerate confirmation. If **AI Education** explicitly asks Cerebrum to anticipate learned habits, it may send one suggestion up to 30 minutes before the usual time. The suggestion is never an execution: KNX and Home Assistant actions still require the normal authorization and confirmation path, and the global limit of three proactive messages per hour still applies.
+
+Cerebrum passively observes bounded, sanitized outputs from useful Node-RED logic, HUE, Matter and Home Assistant event nodes through a runtime hook; no extra monitoring wires are required. Credentials, authorization headers, opaque media and binary payloads are discarded. For live Home Assistant state, add **Cerebrum Home Assistant** and wire `Cerebrum Home Assistant → API (ha-api) → Cerebrum Home Assistant`. Setup Doctor detects the Home Assistant add-on and reports the next missing step.
+
 The most recent chat session is remembered as the owner and receives spontaneous messages. Output 3 emits a localized message with `msg.knxAi.type = "proactive_notification"`; a synthetic `msg.inputMessage` preserves the session for the chat adapter. A hard safety limit of three proactive messages per hour prevents flooding. The node never emits output 4 or changes KNX autonomously; a subsequent user request still uses the normal validation and confirmation workflow.
 
 The shared learned reference is loaded at startup from `<userDir>/knxai/memory/knxai-home-memory.md`, rewritten atomically every 15 minutes and always hard-capped at 5 MB. It stores at most 120 significant observations, 80 aggregate habits, 80 notifications and 300 semantic ETS objects—never a raw unlimited telegram stream. Older low-priority entries are removed first.
@@ -167,12 +178,10 @@ All fields exposed in the KNX AI editor are listed below.
 - **Model**: Model ID/name.
 - **Reasoning effort**: Provider-agnostic preference for models that expose reasoning-effort control. **Automatic** sends no preference and preserves the model/provider default. Explicit choices are `none`, `minimal`, `low`, `medium`, `high`, `xhigh` and `max`; support depends on the request protocol and model, and KNX AI retries without the preference if it is rejected.
 - **Allow the AI to use the Web**: Off by default. Lets the model choose the general Web tool semantically and return verified, cited sources.
-- **Allow proactive Web checks**: Separate opt-in for background checks; it also requires explicit user-authored instructions in **AI Education**.
-- **Minimum proactive interval**: Minimum time between proactive cycles; it does not delay Web operations requested in an active user turn.
-- **Maximum Web calls per hour**: Rolling budget shared by interactive and proactive Web operations. Each turn or cycle can use at most three operations in total.
+- **Maximum Web calls per hour**: Rolling budget shared by conversations and user-created scheduled tasks. Each turn or scheduled run can use at most three operations in total.
 - **Telegram voice**: Available only with the **OpenAI-compatible** provider. It automatically reuses that provider's endpoint and API key with the built-in `gpt-4o-mini-transcribe`, `gpt-4o-mini-tts`, and `alloy` defaults; there are no separate voice settings.
 - **Chat model compatibility**: The selected model must support the configured Chat Completions endpoint. Legacy completion-only models such as `gpt-3.5-turbo-instruct` are excluded when the model list is refreshed. If the provider rejects a custom temperature or token-limit parameter, KNX AI retries after removing or replacing only that incompatible field.
-- **Allow AI to read KNX states and control actuators**: Enables output 4 and is off by default. Exact ETS catalog objects may be read; writes are accepted only for objects classified as `command`. Unknown, DPT-mismatched, invalid, or excessive operations and writes to status/neutral objects are rejected locally.
+- **Allow AI to read KNX states and control actuators**: Enables output 4 and is off by default. Every selected ETS object may be read; every selected object not marked **Read only** may be written. Unknown, DPT-mismatched, invalid or excessive operations and writes to read-only objects are rejected locally.
 - **Ask for confirmation before sending KNX commands**: Enabled by default. Shows the validated changes first and emits no KNX command until the same chat session confirms them. Whenever commands are awaiting confirmation, the response always appends the exact confirmation/cancellation instructions in the language of the current request. Commands are validated again immediately before output.
 - **Input/output message adapter**: Defaults to **No adapter**. Selecting an adapter loads its predefined input/output mapping pair; both mappings remain hidden in the editor.
 - **AI Education**: Fixed, authoritative node guidance edited only by the user and applied with Deploy. The model reads it but never writes it. Standing proactive-home policies belong here; facts and preferences requested in chat go to learned memory, while one-time or recurring plans, reminders, monitors and future commands go to the semantic scheduler without trigger phrases or intent routing.
@@ -187,7 +196,7 @@ All fields exposed in the KNX AI editor are listed below.
   - **2) Install it**: downloads and installs the model locally (for example `llama3.1`).
 - During model refresh/install, KNX AI also tries to auto-start the Ollama server when possible.
 - If install fails with connection errors, ensure Ollama is running (desktop app or `ollama serve`).
-- The maximum context reported by `/api/show` is informational. KNX AI sends the selected 4K, 8K or 16K budget as `num_ctx`; with no KNX AI limit it uses the context declared by the model, never beyond its physical maximum. Every supplied context source is bounded proportionally without removing agent capabilities.
+- The maximum context reported by `/api/show` is used directly as `num_ctx`. KNX AI applies no smaller prompt budget and sends the deduplicated operational prompt without size-based compaction, never beyond the model's declared physical maximum.
 - If Node-RED runs in Docker, use `host.docker.internal` instead of `localhost` in the endpoint URL.
 
 ### Bionic LM Studio quick setup (local)
@@ -195,7 +204,7 @@ All fields exposed in the KNX AI editor are listed below.
 - Start the LM Studio API server from the **Developer** page or with `lms server start`.
 - Default endpoint: `http://localhost:1234/v1/chat/completions`.
 - Click **Refresh** to load all models exposed by `/v1/models`; the first model is selected when none is configured.
-- When a model is already loaded, KNX AI preserves its active context length. KNX AI never loads an inactive Bionic model through the management API: the first chat request lets Bionic JIT-load it with its saved per-model defaults. KNX AI uses the selected 4K, 8K or 16K prompt budget, or the declared/active model window when no KNX AI limit is selected, without exceeding the model's physical maximum; reasoning, KNX, routine, camera and TTS capabilities remain available.
+- When a model is already loaded, KNX AI preserves its active context length. KNX AI never loads an inactive Bionic model through the management API: the first chat request lets Bionic JIT-load it with its saved per-model defaults. Every available prompt context is sent without an application size budget; if it does not fit the active model window, the request fails explicitly.
 - An API key is optional unless authentication is enabled in the LM Studio server settings. In Docker, replace `localhost` with `host.docker.internal`.
 
 ## Security note

package/nodes/locales/en/knxUltimateAI.json

@@ -3,13 +3,15 @@
     "title": "KNX AI (Traffic Analyzer)",
     "sections": {
       "groupAssistant": "AI assistant",
-      "groupChatHome": "Conversations & home",
+      "groupChatHome": "Cerebrum (BETA)",
       "setupDoctor": "Setup Doctor",
       "webIntelligence": "Web intelligence",
       "detectedAdapters": "Compatible nodes detected and used in chat",
       "chatContextOverview": "Chat context overview",
       "chatLearning": "AI Chat Learning",
+      "cerebrumMemory": "Cerebrum memory",
       "quickSetup": "Assistant setup",
+      "etsAccess": "ETS object access",
       "llmConnection": "AI Assistant Connection",
       "chatAdapter": "Chat input and output pins",
       "homeIntelligence": "AI Education & memory",
@@ -25,20 +27,17 @@
       "llmApiKey": "API key",
       "llmModel": "Model",
       "llmReasoningEffort": "Reasoning effort",
-      "llmPromptContextTokens": "Chat context amount",
+      "llmLocalContextTokens": "Local context window",
       "llmSystemPrompt": "System prompt",
       "llmIncludeRaw": "Include raw payload hex",
       "llmAllowKnxCommands": "Allow AI to read KNX states and control actuators",
       "llmRequireCommandConfirmation": "Ask for confirmation before sending KNX commands",
       "webAccessEnabled": "Allow the AI to use the Web",
-      "webProactiveEnabled": "Allow proactive Web checks",
-      "webProactiveIntervalMinutes": "Minimum proactive interval",
       "webMaxCallsPerHour": "Maximum Web calls per hour",
       "chatAdapterPreset": "Input/output message adapter",
       "chatInputCode": "Input mapping (chat → KNX AI)",
       "chatOutputCode": "Output mapping (KNX AI → chat)",
-      "aiEducation": "AI Education (user managed)",
-      "llmIncludeDocsSnippets": "Include documentation snippets (help/README/examples)"
+      "aiEducation": "AI Education (user managed)"
     },
     "outputs": {
       "summary": "Summary/Stats",
@@ -49,17 +48,11 @@
     },
     "selectlists": {
       "llmProvider": {
-        "openai_compat": "OpenAI-compatible (chat/completions)",
+        "openai_compat": "OpenAI / OpenAI-compatible",
         "anthropic": "Anthropic (Claude)",
         "ollama": "Ollama (local)",
         "lmstudio": "Bionic LM Studio"
       },
-      "promptContext": {
-        "small": "Small (4K, faster)",
-        "medium": "Medium (8K)",
-        "full": "Full (16K)",
-        "unlimited": "No KNX AI limit (use model context)"
-      },
       "reasoningEffort": {
         "default": "Automatic (model/provider default)",
         "none": "None",
@@ -70,16 +63,18 @@
         "xhigh": "Extra high",
         "max": "Maximum"
       },
+      "localContext": {
+        "maximum": "Maximum",
+        "k4": "4K",
+        "k8": "8K",
+        "k16": "16K",
+        "k32": "32K",
+        "k64": "64K",
+        "k128": "128K",
+        "k256": "256K"
+      },
       "chatAdapter": {
         "none": "No adapter"
-      },
-      "webProactiveInterval": {
-        "5": "5 minutes",
-        "10": "10 minutes",
-        "15": "15 minutes",
-        "30": "30 minutes",
-        "60": "1 hour",
-        "180": "3 hours"
       }
     },
     "buttons": {
@@ -88,7 +83,12 @@
       "installOllamaModel": "2) Install it",
       "ollamaLibrary": "Model library",
       "downloadOllamaModel": "1) Download model",
-      "openChatLearning": "Open AI Chat Learning"
+      "openChatLearning": "Open AI Chat Learning",
+      "openCerebrumMemory": "Open Cerebrum memory",
+      "etsSelectAll": "Select all",
+      "etsSelectNone": "Select none",
+      "etsReadOnlyAll": "Set read only",
+      "etsReadOnlyNone": "Clear read only"
     },
     "messages": {
       "setupDoctorLoading": "Analyzing this installation…",
@@ -100,9 +100,8 @@
       "setupDoctorWarn": "Check",
       "setupDoctorFail": "Fix",
       "setupDoctorInfo": "Optional",
-      "webAccessHint": "The model chooses this general Web tool semantically; no keywords or intent classifiers are used. External sites and the search service receive the query and this server’s public IP. Private KNX, camera, chat, memory and credential data are never added automatically.",
-      "webProactiveHint": "This separate opt-in also requires explicit instructions in AI Education and a destination learned from one normal chat request. The model decides what to check; existing tool permissions and KNX confirmation rules still apply.",
-      "webBudgetHint": "The rolling budget counts real outbound calls from chat and proactive checks.",
+      "webAccessHint": "The model chooses this general Web tool semantically for each clear chat or scheduled request. If essential scope is ambiguous, it asks the user before searching; no background polling, keywords or intent classifiers are used. External sites and the search service receive the query and this server’s public IP. Private KNX, camera, chat, memory and credential data are never added automatically.",
+      "webBudgetHint": "The rolling budget counts real outbound calls from conversations and user-created scheduled tasks.",
       "loadingModels": "Loading models…",
       "loadedModels": "Models loaded",
       "lmStudioContextAvailable": "Maximum model context",
@@ -111,9 +110,17 @@
       "lmStudioContextConfigured": "Active model context",
       "lmStudioContextFailed": "Unable to configure the model context",
       "lmStudioContextCurrentlyLoaded": "currently loaded",
-      "localContextBudget": "KNX AI context budget",
-      "promptContextHint": "Controls how much KNX, memory, project and adapter context is sent to local models. Choose ‘No KNX AI limit’ to use the model's declared or active context window. It does not enable or disable tools and does not use intent routing.",
+      "etsAccessHint": "Select the group addresses available to KNX AI. Every selected address is active and readable; every selected address not marked Read only is writable. Cloud providers receive the complete selected semantic ETS catalog; local models receive as much as fits their selected context window and can retrieve missing details locally.",
+      "etsFilterPlaceholder": "Filter by name, GA or DPT…",
+      "etsSelected": "selected",
+      "etsReadOnly": "Read only",
+      "etsReadOnlyBulk": "Read only for shown addresses",
+      "etsNoGateway": "Select a KNX gateway.",
+      "etsNoGa": "No group addresses found. Import the ETS list in the KNX gateway.",
+      "etsCsvError": "Unable to load the group address list from the gateway.",
       "reasoningEffortHint": "Optional preference for models that support reasoning effort. Automatic sends no preference; if a provider or model rejects the selected value, KNX AI retries without it.",
+      "localContextBudget": "Local context window",
+      "localContextHint": "Sets the maximum context sent to local models only. Maximum uses the selected model's known context window; unavailable sizes are hidden when the model limit is known. Cloud providers ignore this selector and receive the complete selected semantic ETS catalog.",
       "ollamaNotSupported": "Ollama local mode: API key not required. Default endpoint is http://localhost:11434/api/chat.",
       "ollamaNoModels": "No local Ollama model found. Install one or pick one from the library.",
       "installingOllamaModel": "Starting Ollama and installing model…",
@@ -131,6 +138,7 @@
       "chatContextLoading": "Loading chat context summary…",
       "chatContextUnavailable": "The chat context summary is temporarily unavailable.",
       "chatLearningOpenHint": "Open the Web UI directly on the shared CHAT learning editor to view, edit, copy or back up its persistent file.",
+      "cerebrumMemoryOpenHint": "Open the user-readable Cerebrum memory to inspect or edit learned habits, occupant decisions and cached home states.",
       "chatContextIntro": "The chat automatically receives these sources. The paths below are the actual paths used by this Node-RED installation.",
       "chatContextLimitLabel": "Maximum operational context",
       "chatContextProviderManaged": "managed by the selected provider/model",
@@ -143,9 +151,9 @@
       "chatContextSourcesTitle": "Included sources",
       "chatContextFilesTitle": "Persistent context files",
       "chatContextDirectoriesTitle": "KNX telegram archive",
-      "chatContextSourceKnxTraffic": "Live KNX summary, anomalies, topology and selected telegrams.",
-      "chatContextSourceAdapterHistory": "Persistent daily history of automatically detected adapter events, including camera detections.",
-      "chatContextSourceEtsProject": "ETS semantics and the full Node-RED project inventory.",
+      "chatContextSourceKnxTraffic": "Derived KNX analysis plus the latest exact events from the default 20-minute or explicit interval, automatically bounded for the active local-model window.",
+      "chatContextSourceAdapterHistory": "Latest exact adapter events from the same interval, automatically bounded for the active local-model window.",
+      "chatContextSourceEtsProject": "Complete selected semantic ETS catalog for cloud models. Local models receive the full catalog when it fits; otherwise they receive a window-sized manifest and exact model-requested details. Function source only for explicit code review.",
       "chatContextSourceMemoryEducation": "Session context, AI Education, bounded home memory and active plans.",
       "chatContextSourceCameras": "Detected cameras and their available capabilities.",
       "chatContextSourceBadge": "Source",
@@ -153,7 +161,8 @@
       "chatContextFileHomeMemory": "Bounded learned home memory only; AI Education remains in the node property.",
       "chatContextFileSchedules": "Authoritative persistent runtime state for this node's plans and reminders.",
       "chatContextFileSchedulesReadable": "Generated human-readable view of this node's plans and reminders.",
-      "chatContextFileAssistantConfig": "Persistent web Assistant configuration and semantic areas for this node.",
+      "chatContextFileAssistantConfig": "Persistent Cerebrum configuration and semantic areas for this node.",
+      "chatContextFileLastChatPrompt": "Temporary local copy of the latest system and user messages sent to the chat model; overwritten on every chat request.",
       "chatContextFileBadge": "File",
       "chatContextDirectoryRoot": "Telegram archive root",
       "chatContextDirectoryNode": "This node's telegram archive",

package/nodes/locales/es/knxUltimateAI.html

@@ -20,9 +20,9 @@ El inventario muestra el número exacto de señales KNX con dirección de grupo
 Envía `/start` o `/help` desde un chat para recibir en la salida de chat (salida 3) una bienvenida determinista y localizada, con estadísticas personalizadas de la instalación y hasta tres sugerencias seguras. Este onboarding no llama al LLM, no lee ni escribe KNX y no genera TTS. Con el preajuste de Telegram, las sugerencias aparecen como botones del teclado de respuesta y solo se ejecutan cuando el usuario selecciona o envía una de ellas de forma explícita. Tras esa selección explícita, una sugerencia inicial puede realizar lecturas KNX exactas cuando sean necesarias; las escrituras y rutinas KNX, las acciones de cámara, TTS, los cambios de memoria persistente y el aprendizaje de roles GA permanecen bloqueados.
 
 ### Inteligencia Web
-El acceso Web está desactivado de forma predeterminada. Cuando se activa **Permitir que la IA use la Web**, el modelo conversacional puede elegir la herramienta Web estructurada directamente a partir de la solicitud actual; no se usan palabras clave, lógica específica por tema ni clasificadores de intención. Cada turno del usuario o ciclo proactivo puede realizar como máximo tres operaciones Web en total. Todas las operaciones Web externas reales comparten el presupuesto horario deslizante configurado.
+El acceso Web está desactivado de forma predeterminada. Cuando se activa **Permitir que la IA use la Web**, el modelo conversacional decide en cada solicitud actual si necesita información pública actualizada y puede elegir la herramienta Web estructurada sin palabras clave, lógica específica por tema ni clasificadores de intención. Cada turno del usuario o ejecución de una tarea programada creada por el usuario puede realizar como máximo tres operaciones Web en total. Todas las operaciones Web externas reales comparten el presupuesto horario deslizante configurado.
 
-**Permitir comprobaciones Web proactivas** es una autorización independiente. También requiere instrucciones explícitas escritas por el usuario en **Educación IA**, respeta el intervalo mínimo configurado y solo empieza después de que KNX AI haya aprendido un chat destinatario a partir de al menos una solicitud normal. Sin ambas autorizaciones no se realiza ninguna operación Web en segundo plano.
+KNX AI no inicia ningún ciclo fijo de consultas Web en segundo plano. Si un detalle esencial cambiaría sustancialmente la respuesta o la consulta—por ejemplo el tema, el alcance, el lugar, el intervalo temporal o el resultado deseado—el modelo hace una única pregunta concisa y no realiza ninguna operación Web hasta que el usuario responda. Las comprobaciones futuras o recurrentes se crean únicamente a partir de una solicitud explícita en lenguaje natural mediante el planificador.
 
 Cada respuesta basada en la Web contiene citas validadas por el runtime, con la URL de origen saneada y la hora de consulta, además de la hora de publicación cuando está disponible. El contenido externo son datos no confiables, nunca instrucciones, y no puede sustituir las reglas ni los permisos del asistente. Solo se aceptan recursos HTTPS públicos y limitados; se bloquean los destinos privados, locales, link-local y de metadatos cloud, las redirecciones inseguras, la navegación autenticada y las cookies. Si no se puede verificar ninguna fuente, KNX AI informa de esa limitación en lugar de generar una respuesta sin fuentes.
 
@@ -51,7 +51,12 @@ Si el procesamiento tarda más de 1,2 segundos, la salida 3 emite inmediatamente
 
 Cada solicitud de chat LLM usa un tiempo de espera mínimo de 30 minutos, independientemente del proveedor. No hay ningún campo de tiempo de espera que gestionar en el editor. Es una espera máxima, no un retraso artificial: los modelos más rápidos siguen terminando en cuanto tienen lista la respuesta. Si también se alcanza este límite, KNX AI indica que el modelo no terminó y recomienda volver a intentarlo o reducir el contexto del prompt.
 
-Para los proveedores locales, **Cantidad de contexto del chat** permite elegir explícitamente 4K, 8K, 16K o sin límite de KNX AI; 16K sigue siendo el valor predeterminado. Sin límite de KNX AI se usa la ventana de contexto declarada o activa del modelo, sin superar nunca su máximo físico. La selección limita proporcionalmente los datos KNX, de memoria, del proyecto Node-RED y de los adaptadores enviados al modelo, manteniendo completo el contrato de herramientas del agente. Ninguna capacidad se activa o desactiva según frases, palabras clave o intents lingüísticos.
+KNX AI ya no ofrece un selector de tamaño de contexto en la aplicación. El catálogo ETS seleccionado completo permanece en el nodo y el modelo lo consulta mediante acciones limitadas de retrieval local; solo los objetos recuperados entran en el prompt. La búsqueda cubre direcciones exactas, nombres ETS, alias, jerarquía, áreas, semántica, DPT y etiquetas de valores, con ranking insensible a acentos y tolerante a errores, además de consulta exacta, navegación por áreas y descubrimiento de pares comando/estado. Sin un intervalo explícito, los eventos KNX y de adaptadores cubren los últimos 20 minutos. La ayuda, README, wiki, ejemplos y changelog incluidos nunca se incorporan; cuando sea necesario, el modelo puede consultar la documentación pública de GitHub mediante la herramienta Web. Los datos ETS recuperados, la solicitud actual y las filas del archivo aparecen una sola vez; en el bloque de análisis solo quedan agregados derivados del bus. El código Function completo solo se añade para una solicitud explícita de revisión. KNX AI no reintenta una solicitud demasiado grande compactando el prompt.
+
+Antes de cada solicitud a un modelo local, KNX AI reserva espacio para la respuesta en la ventana activa de 8K/16K. Limita automáticamente los turnos de conversación más recientes, las filas exactas del archivo, la memoria doméstica aprendida, los resultados Web, las planificaciones, el código Function solicitado, los objetos ETS recuperados y los metadatos de las cámaras. Es una construcción preventiva del prompt, no un reintento después de un error de tamaño, y el catálogo ETS seleccionado completo sigue disponible localmente mediante retrieval.
+
+### Acceso a objetos ETS
+Esta sección reproduce el selector de direcciones de grupo del perfil MQTT de IoT Bridge. Filtra la lista importada, selecciona todo o nada y aplica solo lectura a las direcciones visibles en bloque o fila por fila. Solo las direcciones seleccionadas están disponibles para el modelo. Todas las direcciones seleccionadas están activas y se pueden leer; las de solo lectura siguen visibles, pero la validación local rechaza todo `GroupValue_Write` hacia ellas. No existe migración ni fallback heredado: tras actualizar, abre cada nodo KNX AI existente, guarda su selección explícita y haz Deploy; hasta entonces, su catálogo de IA estará vacío.
 
 El estado del nodo en el canvas está reservado deliberadamente para la última solicitud recibida y el mensaje localizado «Estoy pensando…» mientras se ejecuta el LLM. Los telegramas KNX, las actualizaciones del gateway, las tasas de tráfico, los mensajes ready y los resultados técnicos nunca lo sobrescriben; siguen disponibles mediante las salidas, los registros y los datos del Asistente.
 
@@ -85,7 +90,7 @@ Los paquetes de cámaras instalados pueden publicar en tiempo de ejecución un a
 
 El usuario puede pedir una captura actual o preguntar al modelo de visión qué se ve. Los preajustes de Telegram y RedBot envían la imagen como foto nativa con pie. También se pueden crear notificaciones persistentes por movimiento, cruce de una línea inteligente o entrada en una zona de intrusión/merodeo, limitadas opcionalmente a personas detectadas y a una línea o zona concreta por nombre. Estas reglas se guardan en el mismo archivo `knxai-chat-context.knxctx` y se restauran después de reiniciar Node-RED. Las suscripciones a eventos UniFi y las solicitudes de captura se realizan directamente a través del proveedor detectado; no interviene la salida 4 de KNX AI ni hace falta cableado intermedio en el flujo.
 
-Cada evento publicado por un adaptador detectado automáticamente se normaliza y se añade directamente, en el formato nativo compacto por filas de KNX AI, a un archivo diario `YYYY-MM-DD.knxctx` bajo `knxultimatestorage/knxai/adapter-history/<id-nodo>/`. El archivo de telegramas KNX usa el mismo formato compacto, sin serialización JSON intermedia. El archivo conserva 10 días, garantiza más de 24 horas de historial y guarda metadatos, pero no imágenes. Los archivos JSONL existentes no se leen ni se migran. Los totales abarcan todas las filas almacenadas; los detalles seleccionados son solo una muestra relevante.
+Cada evento publicado por un adaptador detectado automáticamente se normaliza y se añade directamente, en el formato nativo compacto por filas de KNX AI, a un archivo diario `YYYY-MM-DD.knxctx` bajo `knxultimatestorage/knxai/adapter-history/<id-nodo>/`. El archivo de telegramas KNX usa el mismo formato compacto, sin serialización JSON intermedia. El archivo conserva 10 días, garantiza más de 24 horas de historial y guarda metadatos, pero no imágenes. Los archivos JSONL existentes no se leen ni se migran. El prompt usa las filas exactas más recientes del intervalo suministrado, limitadas automáticamente a la ventana activa del modelo local.
 
 ### Anuncios con TTS Ultimate
 Conecta la salida 5 a uno o más nodos `ttsultimate` del paquete opcional `node-red-contrib-tts-ultimate`. El cableado normal de Node-RED determina el destino y la distribución; usa Link Out/Link In si el nodo TTS está en otra pestaña del flow. Se han eliminado el selector anterior del nodo TTS y la inyección interna. Las posiciones de las salidas 1–4 no cambian, pero los flows actualizados deben conectar físicamente la salida 5 antes de que los anuncios de voz lleguen a TTS Ultimate.
@@ -93,9 +98,11 @@ Conecta la salida 5 a uno o más nodos `ttsultimate` del paquete opcional `node-
 El modelo decide si prepara un anuncio razonando sobre la solicitud actual, las instrucciones persistentes del chat y la Educación IA gestionada por el usuario; no existe un intent de anuncio ni una lista de frases activadoras. Los valores KNX, eventos de adaptadores, imágenes y archivos siguen siendo datos y no instrucciones, aunque las indicaciones fiables del usuario pueden enseñar al modelo cómo actuar sobre ellos. La salida 5 emite el texto exacto que se debe pronunciar en `msg.payload`, define `msg.topic = "knx_ai_announcement"` y añade `msg.knxAi.type = "tts_announcement"` junto con `msg.knxAi.sourceNodeId`, `msg.knxAi.sessionId` y `msg.knxAi.reason`. TTS Ultimate gestiona después el reproductor, la voz, el volumen, el aviso inicial y la cola.
 
 ### Resumen del contexto del chat
-El editor del nodo muestra una tarjeta compacta con las fuentes disponibles para el chat: tráfico KNX actual, semántica ETS y proyecto Node-RED, memoria de sesión y del hogar, Educación IA, planificaciones activas y cámaras detectadas. También muestra el contexto operativo máximo elegido por el usuario y el tamaño UTF-8 real del último prompt del chat; se usan los tokens de entrada exactos cuando el proveedor los informa y, de lo contrario, el recuento se marca como estimado. También enumera las rutas absolutas de los archivos de planificación JSON autoritativo y Markdown legible, junto con los archivos de telegramas KNX y eventos de adaptadores y el patrón diario `YYYY-MM-DD.knxctx`. La Educación IA se guarda en la configuración del nodo y, por tanto, no tiene un archivo de ejecución separado.
+El editor del nodo muestra una tarjeta compacta con las fuentes disponibles para el chat: eventos KNX y de adaptadores de los últimos 20 minutos o de un intervalo explícito, catálogo ETS seleccionado completo consultable localmente del que solo se añaden los objetos recuperados a cada prompt, código Function bajo demanda, memoria de sesión y del hogar, Educación IA, planificaciones activas y cámaras detectadas. También muestra el contexto operativo máximo declarado por el modelo y el tamaño UTF-8 real del último prompt del chat; se usan los tokens de entrada exactos cuando el proveedor los informa y, de lo contrario, el recuento se marca como estimado. También enumera las rutas absolutas de los archivos de planificación JSON autoritativo y Markdown legible, junto con los archivos de telegramas KNX y eventos de adaptadores y el patrón diario `YYYY-MM-DD.knxctx`. La Educación IA se guarda en la configuración del nodo y, por tanto, no tiene un archivo de ejecución separado.
 
-El modelo recibe lecturas/escrituras KNX, adaptadores de cámara, anuncios TTS, memoria persistente, acceso Web y planificaciones/recordatorios como herramientas estructuradas. Puede seleccionarlas y combinarlas semánticamente a partir de la solicitud actual y de las indicaciones fiables aprendidas, sin routing por intents lingüísticos. El runtime solo valida argumentos, disponibilidad de adaptadores de cámara y límites de seguridad; las escrituras KNX conservan la validación ETS/DPT local y la confirmación configurada.
+El modelo recibe retrieval local del catálogo ETS, lecturas/escrituras KNX, adaptadores de cámara, anuncios TTS, memoria persistente, acceso Web y planificaciones/recordatorios como herramientas estructuradas. Puede seleccionarlas y combinarlas semánticamente a partir de la solicitud actual y de las indicaciones fiables aprendidas, sin routing por intents lingüísticos. El retrieval del catálogo es determinista y local; el runtime valida argumentos, disponibilidad de adaptadores de cámara y límites de seguridad, mientras las escrituras KNX conservan la validación ETS/DPT local completa y la confirmación configurada.
+
+El archivo de depuración local temporal `knxai-last-chat-prompt-<id-nodo>.txt` contiene el último texto exacto de los mensajes system/user, se sobrescribe antes de cada llamada de chat y no contiene claves API ni cabeceras HTTP.
 
 ### Edición y copia del aprendizaje CHAT
 La pestaña **Conversaciones y hogar** de la configuración Node-RED de KNX AI incluye el botón **Abrir aprendizaje del chat IA**, que abre la interfaz web Vue directamente en este editor para el nodo actual.
@@ -104,10 +111,8 @@ En la interfaz web Vue, abre **Ajustes → Aprendizaje del chat IA** para ver y
 
 Solo se admite el formato nativo V3. Los archivos Markdown/JSON V2 y Base64 V1 anteriores no se leen, importan ni migran deliberadamente; el archivo `.md` antiguo se deja intacto y KNX AI inicia un contexto `.knxctx` nuevo. Se mantienen los límites de 50 sesiones y 512 KB.
 
-### Roles aprendidos de las direcciones de grupo KNX
-El rol `neutral` expresa una incertidumbre inicial, no una prohibición permanente de control. El modelo puede usar la herramienta estructurada `gaRoleActions` para aprender que una dirección de grupo ETS exacta es un objeto de comando, estado o neutro a partir de una enseñanza fiable del usuario, instrucciones persistentes del chat, Educación IA o una semántica inequívoca del proyecto ETS. No se requiere ninguna palabra clave ni intent de rol; si las pruebas son ambiguas, el modelo pide una aclaración en vez de aprender.
-
-El rol, el motivo y la prueba aprendidos se guardan por nodo en `<userDir>/knxai/config/knxai-config-<id-nodo>.json` y se sincronizan en la memoria semántica doméstica limitada. Un rol aprendido como `command` puede validar una escritura en la misma respuesta y permanece disponible después de reiniciar; el modelo también puede olvidarlo y restaurar la clasificación automática. El aprendizaje no puede inventar una GA, cambiar su DPT ETS, eludir la validación del payload ni omitir la confirmación de escritura configurada.
+### Acceso a objetos ETS
+El acceso a objetos ETS es la única autoridad operativa. Toda dirección seleccionada en **Acceso a objetos ETS** está activa y se puede leer; también se puede escribir salvo que esté marcada como **Solo lectura**. No se envía al modelo de chat ninguna clasificación de rol inferida ni se usa para autorizar una escritura.
 
 ## Inteligencia doméstica proactiva guiada por Educación y memoria limitada
 A partir de la jerarquía ETS, nombres, roles y DPT, el nodo crea un modelo semántico determinista. No existe un interruptor separado ni ajustes proactivos avanzados. Una notificación solo se evalúa si el LLM está activo y **Educación IA** la solicita explícitamente. Educación es la única política para condiciones, duración, horas silenciosas y repetición. Sin una regla explícita, o si el LLM no puede evaluarla, no se envía ningún mensaje.
@@ -161,12 +166,10 @@ Aquí tienes todos los campos tal como se muestran en el editor de KNX AI.
 - **Model**: ID/nombre de modelo.
 - **Esfuerzo de razonamiento**: preferencia independiente del proveedor para modelos que permiten controlar el esfuerzo de razonamiento. **Automático** no envía ninguna preferencia y conserva el valor predeterminado del modelo/proveedor. Las opciones explícitas son `none`, `minimal`, `low`, `medium`, `high`, `xhigh` y `max`; la compatibilidad depende del protocolo de solicitud y del modelo, y KNX AI reintenta sin la preferencia si se rechaza.
 - **Permitir que la IA use la Web**: desactivado de forma predeterminada. Permite al modelo elegir semánticamente la herramienta Web general y devolver fuentes verificadas y citadas.
-- **Permitir comprobaciones Web proactivas**: autorización independiente para comprobaciones en segundo plano; también requiere instrucciones explícitas escritas por el usuario en **Educación IA**.
-- **Intervalo mínimo de las comprobaciones proactivas**: tiempo mínimo entre ciclos proactivos; no retrasa las operaciones Web solicitadas durante un turno de usuario activo.
-- **Máximo de llamadas Web por hora**: presupuesto deslizante compartido por las operaciones Web interactivas y proactivas. Cada turno o ciclo puede usar como máximo tres operaciones en total.
+- **Máximo de llamadas Web por hora**: presupuesto deslizante compartido por las conversaciones y las tareas programadas creadas por el usuario. Cada turno o ejecución programada puede usar como máximo tres operaciones en total.
 - **Voz de Telegram**: disponible únicamente con el proveedor **OpenAI-compatible**. Reutiliza automáticamente su endpoint y clave API con los valores integrados `gpt-4o-mini-transcribe`, `gpt-4o-mini-tts` y `alloy`; no existen ajustes de voz separados.
 - **Compatibilidad del modelo de chat**: el modelo seleccionado debe admitir el endpoint Chat Completions configurado. Los modelos antiguos disponibles solo mediante completions, como `gpt-3.5-turbo-instruct`, se excluyen al actualizar la lista. Si el proveedor rechaza un valor personalizado de temperatura o el parámetro de límite de tokens, KNX AI vuelve a intentarlo eliminando o sustituyendo únicamente el campo incompatible.
-- **Permitir que la IA lea estados KNX y controle actuadores**: habilita la salida 4 y está desactivado por defecto. Los objetos exactos del catálogo ETS se pueden leer; solo se aceptan escrituras hacia objetos clasificados como `command`. Las operaciones desconocidas, con DPT distinto, inválidas o excesivas, y las escrituras hacia objetos de estado o neutrales, se rechazan localmente.
+- **Permitir que la IA lea estados KNX y controle actuadores**: habilita la salida 4 y está desactivado por defecto. Todos los objetos ETS seleccionados se pueden leer; todos los objetos seleccionados que no estén marcados como **Solo lectura** se pueden escribir. Las operaciones desconocidas, con DPT distinto, inválidas o excesivas, y las escrituras hacia objetos de solo lectura, se rechazan localmente.
 - **Pedir confirmación antes de enviar comandos KNX**: activado por defecto. Muestra primero los cambios validados y no emite comandos hasta que la misma sesión de chat los confirme. Cuando hay comandos pendientes, la respuesta añade siempre las instrucciones exactas para confirmar o cancelar en el idioma de la solicitud actual. Los comandos se validan de nuevo justo antes de la salida.
 - **Adaptador de mensajes de entrada/salida**: usa **Sin adaptador** por defecto. La selección carga el par predefinido de mapeos de entrada y salida; ambos permanecen ocultos en el editor.
 - **Educación de la IA**: instrucciones fijas y autoritativas del nodo, modificadas solo por el usuario y aplicadas con Deploy. El modelo las lee, pero nunca las escribe. Aquí se definen las políticas proactivas permanentes del hogar; los hechos y preferencias solicitados en el chat van a la memoria aprendida, mientras que las planificaciones, recordatorios, monitorizaciones y comandos futuros, únicos o recurrentes, van al planificador semántico sin frases activadoras ni routing por intents.
@@ -181,7 +184,7 @@ Aquí tienes todos los campos tal como se muestran en el editor de KNX AI.
   - **2) Install it**: descarga e instala el modelo localmente (p. ej. `llama3.1`).
 - Durante refresh/instalación, KNX AI también intenta iniciar automáticamente el servidor Ollama.
 - Si la instalación falla con error de conexión, verifica que Ollama esté ejecutándose (app de escritorio o `ollama serve`).
-- El contexto máximo declarado por `/api/show` queda solo como información. KNX AI envía como `num_ctx` el presupuesto elegido de 4K, 8K o 16K; sin límite de KNX AI usa el contexto declarado por el modelo, sin superar nunca su máximo físico. Cada fuente de contexto se limita proporcionalmente sin eliminar capacidades del agente.
+- El contexto máximo declarado por `/api/show` se usa directamente como `num_ctx`. KNX AI no aplica un presupuesto inferior y envía el prompt operativo sin duplicados ni compactación basada en el tamaño, sin superar nunca el máximo físico declarado por el modelo.
 - Si Node-RED se ejecuta en Docker, usa `host.docker.internal` en lugar de `localhost` en el endpoint.
 
 ### Configuración rápida de Bionic LM Studio (local)
@@ -189,7 +192,7 @@ Aquí tienes todos los campos tal como se muestran en el editor de KNX AI.
 - Inicia el servidor API de LM Studio desde la página **Developer** o con `lms server start`.
 - Endpoint por defecto: `http://localhost:1234/v1/chat/completions`.
 - Pulsa **Refresh** para cargar todos los modelos expuestos por `/v1/models`; si no hay un modelo configurado se selecciona el primero.
-- Si un modelo ya está cargado, KNX AI conserva la longitud de contexto activa. KNX AI nunca carga un modelo Bionic inactivo mediante la API de gestión: la primera solicitud de chat permite que Bionic lo cargue mediante JIT con los valores predeterminados guardados para el modelo. KNX AI usa el presupuesto de prompt elegido de 4K, 8K o 16K, o la ventana declarada o activa del modelo cuando se selecciona sin límite de KNX AI, sin superar su máximo físico; el razonamiento, KNX, las rutinas, las cámaras y TTS permanecen disponibles.
+- Si un modelo ya está cargado, KNX AI conserva la longitud de contexto activa. KNX AI nunca carga un modelo Bionic inactivo mediante la API de gestión: la primera solicitud de chat permite que Bionic lo cargue mediante JIT con los valores predeterminados guardados para el modelo. Todo el contexto disponible se envía sin presupuesto de aplicación; si no cabe en la ventana activa, la solicitud falla explícitamente.
 - La clave API es opcional salvo que la autenticación esté activada en los ajustes del servidor LM Studio. En Docker, sustituye `localhost` por `host.docker.internal`.
 
 ## Nota de seguridad