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

package/nodes/locales/de/knxUltimateAI.html

@@ -20,9 +20,9 @@ Das Inventar meldet die exakte Anzahl eindeutiger KNX-Gruppenadress-Signale, die
 Sende `/start` oder `/help` in einem Chat, um am Chat-Ausgang (Ausgang 3) eine deterministische, lokalisierte Begrüßung mit personalisierten Anlagenstatistiken und bis zu drei sicheren Vorschlägen zu erhalten. Dieses Onboarding ruft weder das LLM auf noch liest oder schreibt es KNX oder erzeugt TTS. Mit dem Telegram-Preset erscheinen die Vorschläge als Antworttastatur und werden erst ausgeführt, nachdem der Benutzer einen davon ausdrücklich auswählt oder sendet. Nach dieser ausdrücklichen Auswahl darf ein Startvorschlag bei Bedarf exakte KNX-Leseoperationen ausführen; KNX-Schreiboperationen und -Routinen, Kameraaktionen, TTS, Änderungen am dauerhaften Gedächtnis und das Lernen von GA-Rollen bleiben unterdrückt.
 
 ### Web-Intelligenz
-Der Webzugriff ist standardmäßig deaktiviert. Wenn **Der KI die Nutzung des Webs erlauben** aktiviert ist, kann das Konversationsmodell das strukturierte Web-Tool direkt anhand der aktuellen Anfrage auswählen; es werden keine Schlüsselwörter, themenspezifische Logik oder Intent-Klassifikatoren verwendet. Jeder Benutzerdialog oder proaktive Zyklus darf insgesamt höchstens drei Web-Operationen ausführen. Alle echten externen Web-Operationen teilen sich das konfigurierte gleitende Stundenbudget.
+Der Webzugriff ist standardmäßig deaktiviert. Wenn **Der KI die Nutzung des Webs erlauben** aktiviert ist, entscheidet das Konversationsmodell bei jeder aktuellen Anfrage, ob neue öffentliche Informationen benötigt werden, und kann das strukturierte Web-Tool ohne Schlüsselwörter, themenspezifische Logik oder Intent-Klassifikatoren auswählen. Jeder Benutzerdialog oder Lauf einer vom Benutzer erstellten geplanten Aufgabe darf insgesamt höchstens drei Web-Operationen ausführen. Alle echten externen Web-Operationen teilen sich das konfigurierte gleitende Stundenbudget.
 
-**Proaktive Web-Prüfungen erlauben** ist eine separate Freigabe. Zusätzlich sind ausdrückliche, vom Benutzer verfasste Anweisungen in der **KI-Erziehung** erforderlich, das konfigurierte Mindestintervall wird eingehalten und der Start erfolgt erst, nachdem KNX AI aus mindestens einer normalen Chat-Anfrage ein Chat-Ziel gelernt hat. Ohne beide Freigaben erfolgt keine Web-Operation im Hintergrund.
+KNX AI startet keinen festen Web-Polling-Zyklus im Hintergrund. Würde ein wesentliches Detail die Antwort oder Anfrage erheblich verändern—etwa Thema, Umfang, Ort, Zeitfenster oder gewünschtes Ergebnis—stellt das Modell eine kurze Rückfrage und führt bis zur Antwort des Benutzers keine Web-Operation aus. Zukünftige oder wiederkehrende Prüfungen entstehen nur aus einer ausdrücklichen natürlichsprachlichen Anfrage über den Scheduler.
 
 Jede Web-gestützte Antwort enthält laufzeitvalidierte Quellenangaben mit bereinigter Quell-URL und Abrufzeit sowie, sofern vorhanden, der Veröffentlichungszeit. Externe Inhalte sind nicht vertrauenswürdige Daten, niemals Anweisungen, und können Regeln oder Berechtigungen des Assistenten nicht überschreiben. Zulässig sind nur begrenzte öffentliche HTTPS-Ressourcen; private, lokale, Link-Local- und Cloud-Metadaten-Ziele, unsichere Weiterleitungen, authentifiziertes Browsing und Cookies werden blockiert. Kann keine Quelle verifiziert werden, meldet KNX AI diese Einschränkung, statt eine unbelegte Antwort zu erzeugen.
 
@@ -51,7 +51,12 @@ Dauert die Verarbeitung länger als 1,2 Sekunden, sendet Ausgang 3 sofort die lo
 
 Jede LLM-Chat-Anfrage verwendet unabhängig vom Anbieter ein Mindest-Timeout von 30 Minuten. Im Editor muss kein Timeout-Feld gepflegt werden. Dies ist eine maximale Wartezeit, keine künstliche Verzögerung: Schnellere Modelle sind weiterhin fertig, sobald ihre Antwort bereitsteht. Wird selbst dieses Limit erreicht, meldet KNX AI, dass das Modell die Antwort nicht abgeschlossen hat, und empfiehlt einen neuen Versuch oder einen kleineren Prompt-Kontext.
 
-Für lokale Anbieter lässt sich mit **Chat-Kontextmenge** ausdrücklich zwischen 4K, 8K, 16K und keinem KNX-AI-Limit wählen; 16K bleibt der Standard. Ohne KNX-AI-Limit wird das gemeldete oder aktive Kontextfenster des Modells verwendet, jedoch niemals dessen physisches Maximum überschritten. Die Auswahl begrenzt KNX-, Speicher-, Node-RED-Projekt- und Adapterdaten proportional, während der vollständige Werkzeugvertrag des Agenten erhalten bleibt. Fähigkeiten werden niemals anhand von Formulierungen, Schlüsselwörtern oder sprachlichen Intents aktiviert oder deaktiviert.
+KNX AI bietet keine anwendungsseitige Auswahl der Kontextgröße mehr. Der vollständige ausgewählte ETS-Katalog bleibt im Node und wird vom Modell über begrenzte lokale Retrieval-Aktionen abgefragt; nur gefundene Objekte gelangen in den Prompt. Die Suche umfasst exakte Adressen, ETS-Namen, Aliase, Hierarchie, Bereiche, Semantik, DPTs und Wertbezeichnungen mit akzentunabhängiger, fehlertoleranter Rangfolge sowie exakte Abfrage, Bereichsnavigation und die Suche nach zusammengehörigen Befehls-/Statusobjekten. Ohne expliziten Zeitraum umfassen KNX- und Adapterereignisse die letzten 20 Minuten. Mitgelieferte Hilfe, README, Wiki, Beispiele und Changelog werden nie eingebettet; bei Bedarf kann das Modell die öffentliche GitHub-Dokumentation über das Web-Werkzeug abrufen. Abgerufene ETS-Daten, die aktuelle Anfrage und Archivzeilen erscheinen jeweils nur einmal; im Analyseblock bleiben nur abgeleitete Bus-Aggregate. Vollständiger Function-Quelltext wird nur bei einer ausdrücklichen Function-Codeprüfung hinzugefügt. KNX AI wiederholt übergroße Anfragen nicht mit einem komprimierten Prompt.
+
+Vor jeder Anfrage an ein lokales Modell reserviert KNX AI Antwortplatz im aktiven 8K-/16K-Fenster. Die neuesten Gesprächsrunden, exakten Archivzeilen, das gelernte Hausgedächtnis, Web-Ergebnisse, Zeitpläne, angeforderter Function-Quelltext, abgerufene ETS-Objekte und Kamerametadaten werden automatisch begrenzt. Dies ist eine vorbeugende Prompt-Erstellung und kein erneuter Versuch nach einem Größenfehler; der vollständige ausgewählte ETS-Katalog bleibt lokal per Retrieval verfügbar.
+
+### Zugriff auf ETS-Objekte
+Dieser Abschnitt übernimmt den Gruppenadress-Selektor des MQTT-Profils der IoT Bridge. Die importierte Liste kann gefiltert, vollständig ausgewählt oder abgewählt und für sichtbare Zeilen einzeln oder gesammelt auf Nur-Lesen gesetzt werden. Nur ausgewählte Adressen stehen dem Modell zur Verfügung. Jede ausgewählte Adresse ist aktiv und lesbar; Nur-Lesen-Adressen bleiben sichtbar, aber die lokale Validierung blockiert jedes `GroupValue_Write` auf sie. Es gibt weder Migration noch Legacy-Fallback: Nach dem Update muss jeder vorhandene KNX-AI-Knoten geöffnet, ausdrücklich konfiguriert, gespeichert und bereitgestellt werden; bis dahin ist sein AI-Katalog leer.
 
 Der Node-Status im Canvas ist bewusst ausschließlich für die letzte eingehende Anfrage und den lokalisierten Zustand „Ich denke nach…“ während der LLM-Ausführung reserviert. KNX-Telegramme, Gateway-Aktualisierungen, Verkehrsraten, Bereitschaftsmeldungen und technische Ergebnisse überschreiben ihn nie; sie bleiben über Ausgänge, Logs und Assistentendaten verfügbar.
 
@@ -85,7 +90,7 @@ Installierte Kamerapakete können KNX AI zur Laufzeit einen Kamera-Adapter berei
 
 Der Benutzer kann einen aktuellen Snapshot anfordern oder das Vision-Modell nach dem sichtbaren Inhalt fragen. Die Telegram- und RedBot-Vorlagen senden das Bild als natives Foto mit Bildunterschrift. Außerdem lassen sich dauerhafte Benachrichtigungen für Bewegung, das Überqueren einer intelligenten Linie oder das Betreten einer Einbruchs-/Verweilzone erstellen, optional auf erkannte Personen und eine genau benannte Linie oder Zone begrenzt. Diese Regeln werden in derselben Datei `knxai-chat-context.knxctx` gespeichert und nach einem Neustart von Node-RED wiederhergestellt. UniFi-Ereignisse und Snapshot-Anfragen laufen direkt über den erkannten Anbieter; Ausgang 4 von KNX AI und zusätzliche Flow-Verkabelung sind nicht erforderlich.
 
-Jedes von einem automatisch erkannten Adapter veröffentlichte Ereignis wird normalisiert und direkt im kompakten zeilenbasierten KNX-AI-Nativformat in eine tägliche Datei `YYYY-MM-DD.knxctx` unter `knxultimatestorage/knxai/adapter-history/<node-id>/` geschrieben. Das KNX-Telegrammarchiv verwendet dasselbe kompakte Format ohne zwischenzeitliche JSON-Serialisierung. Das Archiv bewahrt 10 Tage auf, garantiert mehr als 24 Stunden Historie und speichert Ereignismetadaten, jedoch keine Snapshot-Bilder. Vorhandene JSONL-Archive werden weder gelesen noch migriert. Summen umfassen alle gespeicherten Zeilen; ausgewählte Details sind nur eine relevante Stichprobe.
+Jedes von einem automatisch erkannten Adapter veröffentlichte Ereignis wird normalisiert und direkt im kompakten zeilenbasierten KNX-AI-Nativformat in eine tägliche Datei `YYYY-MM-DD.knxctx` unter `knxultimatestorage/knxai/adapter-history/<node-id>/` geschrieben. Das KNX-Telegrammarchiv verwendet dasselbe kompakte Format ohne zwischenzeitliche JSON-Serialisierung. Das Archiv bewahrt 10 Tage auf, garantiert mehr als 24 Stunden Historie und speichert Ereignismetadaten, jedoch keine Snapshot-Bilder. Vorhandene JSONL-Archive werden weder gelesen noch migriert. Der Prompt verwendet die neuesten exakten Zeilen des gelieferten Zeitraums, automatisch begrenzt auf das aktive lokale Modellfenster.
 
 ### Ansagen mit TTS Ultimate
 Verbinden Sie Ausgang 5 mit einem oder mehreren `ttsultimate`-Nodes aus dem optionalen Paket `node-red-contrib-tts-ultimate`. Die normale Node-RED-Verkabelung bestimmt Ziel und Verteilung; liegt der TTS-Node auf einer anderen Flow-Registerkarte, verwenden Sie Link Out/Link In. Die bisherige TTS-Node-Auswahl und die interne Einspeisung wurden entfernt. Die Positionen der Ausgänge 1–4 bleiben unverändert, aktualisierte Flows müssen Ausgang 5 jedoch physisch verbinden, bevor Sprachansagen TTS Ultimate erreichen.
@@ -93,9 +98,11 @@ Verbinden Sie Ausgang 5 mit einem oder mehreren `ttsultimate`-Nodes aus dem opti
 Das Modell entscheidet anhand der aktuellen Anfrage, persistenter Chat-Anweisungen und der benutzerverwalteten KI-Erziehung, ob es eine Ansage vorbereitet; es gibt weder einen Ansage-Intent noch eine Liste von Auslösephrasen. KNX-Werte, Adapterereignisse, Kamerainhalte und Archive bleiben Daten statt Anweisungen, während vertrauenswürdige Benutzervorgaben dem Modell den Umgang mit diesen Daten beibringen können. Ausgang 5 gibt den exakt zu sprechenden Text in `msg.payload` aus, setzt `msg.topic = "knx_ai_announcement"` und ergänzt `msg.knxAi.type = "tts_announcement"` sowie `msg.knxAi.sourceNodeId`, `msg.knxAi.sessionId` und `msg.knxAi.reason`. TTS Ultimate verwaltet anschließend Player, Stimme, Lautstärke, Hailing und Warteschlange.
 
 ### Übersicht des Chat-Kontexts
-Der Node-Editor zeigt eine kompakte Karte mit den für den Chat verfügbaren Quellen: aktuellem KNX-Verkehr, ETS-Semantik und Node-RED-Projekt, Sitzungs- und Hausgedächtnis, KI-Erziehung, aktiven Plänen und erkannten Kameras. Sie zeigt außerdem den vom Benutzer gewählten maximalen operativen Kontext und die tatsächliche UTF-8-Größe des letzten Chat-Prompts; gemeldete Eingabe-Token des Anbieters werden exakt verwendet, andernfalls wird der Tokenwert als Schätzung gekennzeichnet. Aufgeführt werden auch die absoluten Pfade der verbindlichen JSON-/lesbaren Markdown-Planungsdateien sowie die KNX-Telegramm- und Adapterereignisarchive mit dem Tagesdateimuster `YYYY-MM-DD.knxctx`. Die KI-Erziehung wird in der Node-Konfiguration gespeichert und hat daher keine eigene Laufzeitdatei.
+Der Node-Editor zeigt eine kompakte Karte mit den für den Chat verfügbaren Quellen: KNX- und Adapterereignissen der letzten 20 Minuten oder eines expliziten Zeitraums, dem vollständigen lokal durchsuchbaren ETS-Katalog, von dem nur abgerufene Objekte in den jeweiligen Prompt gelangen, Function-Quelltext bei Bedarf, Sitzungs- und Hausgedächtnis, KI-Erziehung, aktiven Plänen und erkannten Kameras. Sie zeigt außerdem den vom Modell gemeldeten maximalen operativen Kontext und die tatsächliche UTF-8-Größe des letzten Chat-Prompts; gemeldete Eingabe-Token des Anbieters werden exakt verwendet, andernfalls wird der Tokenwert als Schätzung gekennzeichnet. Aufgeführt werden auch die absoluten Pfade der verbindlichen JSON-/lesbaren Markdown-Planungsdateien sowie die KNX-Telegramm- und Adapterereignisarchive mit dem Tagesdateimuster `YYYY-MM-DD.knxctx`. Die KI-Erziehung wird in der Node-Konfiguration gespeichert und hat daher keine eigene Laufzeitdatei.
 
-Das Modell erhält KNX-Lese-/Schreiboperationen, Kamera-Adapter, TTS-Ansagen, persistenten Speicher, Webzugriff und Pläne/Erinnerungen als strukturierte Werkzeuge. Es kann sie anhand der aktuellen Anfrage und vertrauenswürdiger gelernter Vorgaben semantisch auswählen und kombinieren, ohne sprachliches Intent-Routing. Die Laufzeit prüft nur Argumente, die Verfügbarkeit von Kamera-Adaptern und Sicherheitsgrenzen; KNX-Schreibvorgänge behalten die lokale ETS-/DPT-Prüfung und die konfigurierte Bestätigung.
+Das Modell erhält lokale ETS-Katalogsuche, KNX-Lese-/Schreiboperationen, Kamera-Adapter, TTS-Ansagen, persistenten Speicher, Webzugriff und Pläne/Erinnerungen als strukturierte Werkzeuge. Es kann sie anhand der aktuellen Anfrage und vertrauenswürdiger gelernter Vorgaben semantisch auswählen und kombinieren, ohne sprachliches Intent-Routing. Die Katalogsuche ist deterministisch und lokal; die Laufzeit prüft Argumente, die Verfügbarkeit von Kamera-Adaptern und Sicherheitsgrenzen, während KNX-Schreibvorgänge die vollständige lokale ETS-/DPT-Prüfung und die konfigurierte Bestätigung behalten.
+
+Die temporäre lokale Debugdatei `knxai-last-chat-prompt-<node-id>.txt` enthält den letzten exakten System-/Benutzer-Prompttext, wird vor jedem Chataufruf überschrieben und enthält keine API-Schlüssel oder HTTP-Header.
 
 ### CHAT-Lernen bearbeiten und sichern
 Die Registerkarte **Gespräche & Zuhause** in der Node-RED-Konfiguration von KNX AI enthält die Schaltfläche **KI-Chat-Lernen öffnen**. Sie öffnet die Vue-Weboberfläche für den aktuellen Node direkt in diesem Editor.
@@ -104,10 +111,8 @@ Die Registerkarte **Gespräche & Zuhause** in der Node-RED-Konfiguration von KNX
 
 Nur das native V3-Format wird unterstützt. Frühere Markdown/JSON-V2- und Base64-V1-Dateien werden absichtlich weder gelesen noch importiert oder migriert; die alte `.md`-Datei bleibt unverändert und KNX AI beginnt mit einem neuen `.knxctx`-Kontext. Die Grenzen von 50 Sitzungen und 512 KB gelten weiterhin.
 
-### Gelernte Rollen für KNX-Gruppenadressen
-Die Rolle `neutral` bedeutet anfängliche Ungewissheit und kein dauerhaftes Steuerungsverbot. Das Modell kann mit dem strukturierten Werkzeug `gaRoleActions` aus verbindlichen Hinweisen des Benutzers, persistenten Chat-Vorgaben, der KI-Erziehung oder einer eindeutigen ETS-Projektsemantik lernen, dass eine exakte ETS-Gruppenadresse ein Befehls-, Status- oder neutrales Objekt ist. Dafür sind weder Schlüsselwörter noch Rollen-Intents nötig; bei mehrdeutigen Belegen fragt das Modell nach, statt zu lernen.
-
-Gelernte Rolle, Begründung und Beleg werden pro Node in `<userDir>/knxai/config/knxai-config-<node-id>.json` gespeichert und in das begrenzte semantische Hausgedächtnis synchronisiert. Eine als `command` gelernte Rolle kann bereits in derselben Antwort einen Schreibvorgang validieren und bleibt nach einem Neustart verfügbar; das Modell kann sie auch vergessen und die automatische Klassifizierung wiederherstellen. Das Lernen kann keine GA erfinden, ihren ETS-DPT ändern, die Payload-Prüfung umgehen oder die konfigurierte Schreibbestätigung überspringen.
+### ETS-Objektzugriff
+Der ETS-Objektzugriff ist die einzige operative Autorität. Jede unter **ETS-Objektzugriff** ausgewählte Adresse ist aktiv und lesbar; sie ist auch schreibbar, sofern sie nicht als **Nur Lesen** markiert ist. Es wird keine abgeleitete Rollenklassifizierung an das Chatmodell gesendet oder zur Freigabe eines Schreibvorgangs verwendet.
 
 ## Durch KI-Erziehung gesteuerte proaktive Hausintelligenz und begrenztes Gedächtnis
 Aus ETS-Hierarchie, Namen, Rollen und DPTs erstellt der Node ein deterministisches semantisches Modell. Es gibt keinen separaten Schalter und keine erweiterten proaktiven Einstellungen. Eine Benachrichtigung wird nur bewertet, wenn das LLM aktiv ist und die **KI-Erziehung** sie ausdrücklich verlangt. Ausschließlich die Erziehung bestimmt Bedingungen, Offenzeit, Ruhezeiten und Wiederholung. Ohne eine ausdrückliche Regel oder bei fehlgeschlagener LLM-Auswertung wird nichts gesendet.
@@ -161,12 +166,10 @@ Hier sind alle Felder aufgeführt, wie sie im KNX-AI-Editor sichtbar sind.
 - **Model**: Modell-ID/Name.
 - **Denkaufwand**: Anbieterunabhängige Vorgabe für Modelle, die eine Steuerung des Denkaufwands anbieten. **Automatisch** sendet keine Vorgabe und behält den Modell-/Anbieterstandard bei. Explizit wählbar sind `none`, `minimal`, `low`, `medium`, `high`, `xhigh` und `max`; die Unterstützung hängt von Anfrageprotokoll und Modell ab. Wird der Wert abgelehnt, versucht KNX AI es ohne diese Vorgabe erneut.
 - **Der KI die Nutzung des Webs erlauben**: Standardmäßig deaktiviert. Das Modell darf das allgemeine Web-Tool semantisch auswählen und verifizierte, zitierte Quellen zurückgeben.
-- **Proaktive Web-Prüfungen erlauben**: Separate Freigabe für Hintergrundprüfungen; zusätzlich sind ausdrückliche, vom Benutzer verfasste Anweisungen in der **KI-Erziehung** erforderlich.
-- **Mindestintervall für proaktive Prüfungen**: Mindestzeit zwischen proaktiven Zyklen; Web-Operationen in einem aktiven Benutzerturn werden dadurch nicht verzögert.
-- **Maximale Web-Aufrufe pro Stunde**: Gleitendes Budget für interaktive und proaktive Web-Operationen. Jeder Turn oder Zyklus darf insgesamt höchstens drei Operationen verwenden.
+- **Maximale Web-Aufrufe pro Stunde**: Gleitendes Budget für Unterhaltungen und vom Benutzer erstellte geplante Aufgaben. Jeder Turn oder geplante Lauf darf insgesamt höchstens drei Operationen verwenden.
 - **Telegram-Sprache**: Nur mit dem Provider **OpenAI-compatible** verfügbar. Endpunkt und API-Schlüssel dieses Providers werden automatisch mit den integrierten Standards `gpt-4o-mini-transcribe`, `gpt-4o-mini-tts` und `alloy` verwendet; separate Spracheinstellungen gibt es nicht.
 - **Chatmodell-Kompatibilität**: Das ausgewählte Modell muss den konfigurierten Chat-Completions-Endpunkt unterstützen. Ältere reine Completions-Modelle wie `gpt-3.5-turbo-instruct` werden beim Aktualisieren der Modellliste ausgeschlossen. Lehnt der Anbieter einen benutzerdefinierten Temperaturwert oder den Token-Limit-Parameter ab, wiederholt KNX AI die Anfrage und entfernt oder ersetzt nur das inkompatible Feld.
-- **KI darf KNX-Zustände lesen und Aktoren steuern**: Aktiviert Ausgang 4 und ist standardmäßig aus. Exakte ETS-Katalogobjekte dürfen gelesen werden; Schreiboperationen werden ausschließlich für Objekte mit Rolle `command` akzeptiert. Unbekannte, DPT-falsche, ungültige oder überzählige Operationen sowie Schreiboperationen auf Status-/Neutralobjekte werden lokal abgewiesen.
+- **KI darf KNX-Zustände lesen und Aktoren steuern**: Aktiviert Ausgang 4 und ist standardmäßig aus. Jedes ausgewählte ETS-Objekt darf gelesen werden; jedes ausgewählte Objekt ohne Markierung **Nur Lesen** darf geschrieben werden. Unbekannte, DPT-falsche, ungültige oder überzählige Operationen sowie Schreiboperationen auf Nur-Lesen-Objekte werden lokal abgewiesen.
 - **Vor dem Senden von KNX-Befehlen bestätigen lassen**: Standardmäßig aktiv. Zeigt zuerst die validierten Änderungen und sendet nichts, bis dieselbe Chat-Sitzung bestätigt. Wenn Befehle auf Bestätigung warten, fügt die Antwort immer die genauen Anweisungen zum Bestätigen oder Abbrechen in der Sprache der aktuellen Anfrage hinzu. Vor der Ausgabe werden die Befehle erneut validiert.
 - **Adapter für Ein-/Ausgangsnachrichten**: Standardmäßig ist **Kein Adapter** gewählt. Die Auswahl lädt das vordefinierte Paar aus Ein- und Ausgangszuordnung; beide bleiben im Editor verborgen.
 - **KI-Erziehung**: Feste, verbindliche Node-Vorgaben, die nur der Benutzer bearbeitet und mit Deploy anwendet. Das Modell liest, aber schreibt sie niemals. Dauerhafte proaktive Hausregeln gehören hierher; im Chat angeforderte Fakten und Präferenzen gehen in das gelernte Gedächtnis, einmalige oder wiederkehrende Pläne, Erinnerungen, Überwachungen und zukünftige Befehle in den semantischen Scheduler – ohne Auslösephrasen oder Intent-Routing.
@@ -181,7 +184,7 @@ Hier sind alle Felder aufgeführt, wie sie im KNX-AI-Editor sichtbar sind.
   - **2) Install it**: lädt und installiert das Modell lokal (z. B. `llama3.1`).
 - Beim Refresh/Install versucht KNX AI zusätzlich, den Ollama-Server automatisch zu starten.
 - Bei Installationsfehlern mit Verbindungsproblem prüfen, ob Ollama läuft (Desktop-App oder `ollama serve`).
-- Der von `/api/show` gemeldete maximale Kontext dient nur zur Information. KNX AI sendet das gewählte 4K-, 8K- oder 16K-Budget als `num_ctx`; ohne KNX-AI-Limit wird der vom Modell gemeldete Kontext verwendet, niemals über dessen physisches Maximum hinaus. Jede Kontextquelle wird proportional begrenzt, ohne Agentenfunktionen zu entfernen.
+- Der von `/api/show` gemeldete maximale Kontext wird direkt als `num_ctx` verwendet. KNX AI wendet kein kleineres Prompt-Budget an und sendet den deduplizierten operativen Prompt ohne größenabhängige Komprimierung, niemals über das gemeldete physische Maximum hinaus.
 - Wenn Node-RED in Docker läuft, im Endpoint `host.docker.internal` statt `localhost` verwenden.
 
 ### Bionic LM Studio Schnellstart (lokal)
@@ -189,7 +192,7 @@ Hier sind alle Felder aufgeführt, wie sie im KNX-AI-Editor sichtbar sind.
 - Den LM-Studio-API-Server auf der Seite **Developer** oder mit `lms server start` starten.
 - Standard-Endpoint: `http://localhost:1234/v1/chat/completions`.
 - Mit **Refresh** alle von `/v1/models` bereitgestellten Modelle laden; ist kein Modell konfiguriert, wird das erste ausgewählt.
-- Ist ein Modell bereits geladen, behält KNX AI dessen aktive Kontextlänge bei. KNX AI lädt ein inaktives Bionic-Modell niemals über die Verwaltungs-API: Die erste Chat-Anfrage lässt Bionic das Modell per JIT mit den gespeicherten modellspezifischen Standardwerten laden. KNX AI verwendet das gewählte 4K-, 8K- oder 16K-Prompt-Budget oder ohne KNX-AI-Limit das gemeldete beziehungsweise aktive Modellfenster, ohne dessen physisches Maximum zu überschreiten; Denk-, KNX-, Routinen-, Kamera- und TTS-Funktionen bleiben verfügbar.
+- Ist ein Modell bereits geladen, behält KNX AI dessen aktive Kontextlänge bei. KNX AI lädt ein inaktives Bionic-Modell niemals über die Verwaltungs-API: Die erste Chat-Anfrage lässt Bionic das Modell per JIT mit den gespeicherten modellspezifischen Standardwerten laden. Der gesamte verfügbare Prompt-Kontext wird ohne Anwendungsbudget gesendet; passt er nicht in das aktive Modellfenster, schlägt die Anfrage ausdrücklich fehl.
 - Der API-Schlüssel ist optional, sofern die Authentifizierung in den LM-Studio-Servereinstellungen nicht aktiviert ist. In Docker `localhost` durch `host.docker.internal` ersetzen.
 
 ## Sicherheitshinweis

package/nodes/locales/de/knxUltimateAI.json

@@ -10,6 +10,7 @@
       "chatContextOverview": "Übersicht des Chat-Kontexts",
       "chatLearning": "KI-Chat-Lernen",
       "quickSetup": "Assistent einrichten",
+      "etsAccess": "Zugriff auf ETS-Objekte",
       "llmConnection": "KI-Assistent-Verbindung",
       "chatAdapter": "Chat-Pins für Ein- und Ausgang",
       "homeIntelligence": "KI-Erziehung & Gedächtnis",
@@ -25,20 +26,17 @@
       "llmApiKey": "API key",
       "llmModel": "Model",
       "llmReasoningEffort": "Denkaufwand",
-      "llmPromptContextTokens": "Chat-Kontextmenge",
+      "llmLocalContextTokens": "Lokales Kontextfenster",
       "llmSystemPrompt": "System prompt",
       "llmIncludeRaw": "Include raw payload hex",
       "llmAllowKnxCommands": "KI darf KNX-Zustände lesen und Aktoren steuern",
       "llmRequireCommandConfirmation": "Vor dem Senden von KNX-Befehlen bestätigen lassen",
       "webAccessEnabled": "Der KI die Nutzung des Webs erlauben",
-      "webProactiveEnabled": "Proaktive Web-Prüfungen erlauben",
-      "webProactiveIntervalMinutes": "Mindestintervall für proaktive Prüfungen",
       "webMaxCallsPerHour": "Maximale Web-Aufrufe pro Stunde",
       "chatAdapterPreset": "Adapter für Ein-/Ausgangsnachrichten",
       "chatInputCode": "Eingangszuordnung (Chat → KNX AI)",
       "chatOutputCode": "Ausgangszuordnung (KNX AI → Chat)",
-      "aiEducation": "KI-Erziehung (vom Benutzer verwaltet)",
-      "llmIncludeDocsSnippets": "Include documentation snippets (help/README/examples)"
+      "aiEducation": "KI-Erziehung (vom Benutzer verwaltet)"
     },
     "outputs": {
       "summary": "Zusammenfassung/Statistik",
@@ -49,17 +47,11 @@
     },
     "selectlists": {
       "llmProvider": {
-        "openai_compat": "OpenAI-compatible (chat/completions)",
+        "openai_compat": "OpenAI / OpenAI-kompatibel",
         "anthropic": "Anthropic (Claude)",
         "ollama": "Ollama (lokal)",
         "lmstudio": "Bionic LM Studio"
       },
-      "promptContext": {
-        "small": "Klein (4K, schneller)",
-        "medium": "Mittel (8K)",
-        "full": "Vollständig (16K)",
-        "unlimited": "Kein KNX-AI-Limit (Modellkontext verwenden)"
-      },
       "reasoningEffort": {
         "default": "Automatisch (Modell-/Anbieterstandard)",
         "none": "Keiner",
@@ -70,16 +62,18 @@
         "xhigh": "Sehr hoch",
         "max": "Maximal"
       },
+      "localContext": {
+        "maximum": "Maximum",
+        "k4": "4K",
+        "k8": "8K",
+        "k16": "16K",
+        "k32": "32K",
+        "k64": "64K",
+        "k128": "128K",
+        "k256": "256K"
+      },
       "chatAdapter": {
         "none": "Kein Adapter"
-      },
-      "webProactiveInterval": {
-        "5": "5 Minuten",
-        "10": "10 Minuten",
-        "15": "15 Minuten",
-        "30": "30 Minuten",
-        "60": "1 Stunde",
-        "180": "3 Stunden"
       }
     },
     "placeholder": {
@@ -99,18 +93,25 @@
       "setupDoctorWarn": "Prüfen",
       "setupDoctorFail": "Beheben",
       "setupDoctorInfo": "Optional",
-      "webAccessHint": "Das Modell wählt dieses allgemeine Web-Tool semantisch aus; Schlüsselwörter oder Intent-Klassifikatoren werden nicht verwendet. Externe Websites und der Suchdienst erhalten die Anfrage und die öffentliche IP dieses Servers. Private KNX-, Kamera-, Chat-, Speicher- und Zugangsdaten werden nie automatisch hinzugefügt.",
-      "webProactiveHint": "Diese separate Freigabe erfordert zusätzlich ausdrückliche Anweisungen in der KI-Erziehung und ein aus einer normalen Chat-Anfrage gelerntes Ziel. Das Modell entscheidet, was geprüft wird; bestehende Tool-Berechtigungen und KNX-Bestätigungsregeln gelten weiterhin.",
-      "webBudgetHint": "Das gleitende Budget zählt echte externe Aufrufe aus Chat und proaktiven Prüfungen.",
+      "webAccessHint": "Das Modell wählt dieses allgemeine Web-Tool semantisch für jede klare Chat- oder geplante Anfrage. Fehlt ein wesentlicher Umfang, fragt es vor der Suche beim Benutzer nach; Hintergrund-Polling, Schlüsselwörter oder Intent-Klassifikatoren werden nicht verwendet. Externe Websites und der Suchdienst erhalten die Anfrage und die öffentliche IP dieses Servers. Private KNX-, Kamera-, Chat-, Speicher- und Zugangsdaten werden nie automatisch hinzugefügt.",
+      "webBudgetHint": "Das gleitende Budget zählt echte externe Aufrufe aus Unterhaltungen und vom Benutzer erstellten geplanten Aufgaben.",
       "lmStudioContextAvailable": "Maximaler Modellkontext",
       "lmStudioContextLoading": "Aktiver Modellkontext wird geprüft",
       "lmStudioContextInactive": "Modell inaktiv; bei der ersten Anfrage werden die Bionic-Standardwerte verwendet",
       "lmStudioContextConfigured": "Aktiver Modellkontext",
       "lmStudioContextFailed": "Der Modellkontext konnte nicht konfiguriert werden",
       "lmStudioContextCurrentlyLoaded": "derzeit geladen",
-      "localContextBudget": "KNX-AI-Kontextbudget",
-      "promptContextHint": "Steuert die Menge an KNX-, Speicher-, Projekt- und Adapterkontext für lokale Modelle. Mit „Kein KNX-AI-Limit“ wird das gemeldete oder aktive Kontextfenster des Modells verwendet. Werkzeuge werden dadurch weder aktiviert noch deaktiviert; es gibt kein Intent-Routing.",
+      "etsAccessHint": "Wähle die für KNX AI verfügbaren Gruppenadressen. Jede ausgewählte Adresse ist aktiv und lesbar; jede ausgewählte Adresse ohne Markierung Nur Lesen ist schreibbar. Cloud-Anbieter erhalten den vollständigen ausgewählten semantischen ETS-Katalog; lokale Modelle erhalten so viel, wie in das gewählte Kontextfenster passt, und können fehlende Details lokal abrufen.",
+      "etsFilterPlaceholder": "Nach Name, GA oder DPT filtern…",
+      "etsSelected": "ausgewählt",
+      "etsReadOnly": "Nur lesen",
+      "etsReadOnlyBulk": "Nur lesen für angezeigte Adressen",
+      "etsNoGateway": "Wähle ein KNX-Gateway aus.",
+      "etsNoGa": "Keine Gruppenadressen gefunden. Importiere die ETS-Liste im KNX-Gateway.",
+      "etsCsvError": "Die Gruppenadressliste konnte nicht vom Gateway geladen werden.",
       "reasoningEffortHint": "Optionale Vorgabe für Modelle, die einen Denkaufwand unterstützen. Automatisch sendet keine Vorgabe; lehnt der Anbieter oder das Modell den gewählten Wert ab, versucht KNX AI es ohne diesen erneut.",
+      "localContextBudget": "Lokales Kontextfenster",
+      "localContextHint": "Legt den maximalen Kontext nur für lokale Modelle fest. Maximum verwendet das bekannte Kontextfenster des ausgewählten Modells; nicht verfügbare Größen werden ausgeblendet. Cloud-Anbieter ignorieren diese Auswahl und erhalten den vollständigen ausgewählten semantischen ETS-Katalog.",
       "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…",
@@ -140,9 +141,9 @@
       "chatContextSourcesTitle": "Enthaltene Quellen",
       "chatContextFilesTitle": "Dauerhafte Kontextdateien",
       "chatContextDirectoriesTitle": "KNX-Telegrammarchiv",
-      "chatContextSourceKnxTraffic": "Aktuelle KNX-Zusammenfassung, Anomalien, Topologie und ausgewählte Telegramme.",
-      "chatContextSourceAdapterHistory": "Dauerhaftes Tagesarchiv automatisch erkannter Adapterereignisse einschließlich Kameraerkennungen.",
-      "chatContextSourceEtsProject": "ETS-Semantik und vollständiges Inventar des Node-RED-Projekts.",
+      "chatContextSourceKnxTraffic": "Abgeleitete KNX-Analyse plus die neuesten exakten Ereignisse aus dem standardmäßigen 20-Minuten- oder expliziten Zeitraum, automatisch an das aktive lokale Modellfenster angepasst.",
+      "chatContextSourceAdapterHistory": "Neueste exakte Adapterereignisse aus demselben Zeitraum, automatisch an das aktive lokale Modellfenster angepasst.",
+      "chatContextSourceEtsProject": "Vollständiger ausgewählter semantischer ETS-Katalog für Cloud-Modelle. Lokale Modelle erhalten den vollständigen Katalog, wenn er in das Fenster passt, andernfalls einen fenstergroßen Index und die vom Modell angeforderten exakten Details. Function-Quelltext nur bei ausdrücklicher Codeprüfung.",
       "chatContextSourceMemoryEducation": "Sitzungskontext, KI-Erziehung, begrenztes Hausgedächtnis und aktive Pläne.",
       "chatContextSourceCameras": "Erkannte Kameras und ihre verfügbaren Funktionen.",
       "chatContextSourceBadge": "Quelle",
@@ -151,6 +152,7 @@
       "chatContextFileSchedules": "Verbindlicher dauerhafter Laufzeitstatus der Pläne und Erinnerungen dieses Nodes.",
       "chatContextFileSchedulesReadable": "Erzeugte menschenlesbare Ansicht der Pläne und Erinnerungen dieses Nodes.",
       "chatContextFileAssistantConfig": "Dauerhafte Konfiguration des Web-Assistenten und semantische Bereiche dieses Nodes.",
+      "chatContextFileLastChatPrompt": "Temporäre lokale Kopie der letzten System- und Benutzernachricht an das Chatmodell; wird bei jeder Chatanfrage überschrieben.",
       "chatContextFileBadge": "Datei",
       "chatContextDirectoryRoot": "Stammverzeichnis des Telegrammarchivs",
       "chatContextDirectoryNode": "Telegrammarchiv dieses Nodes",
@@ -216,7 +218,11 @@
       "installOllamaModel": "2) Install it",
       "ollamaLibrary": "Model library",
       "downloadOllamaModel": "1) Download model",
-      "openChatLearning": "KI-Chat-Lernen öffnen"
+      "openChatLearning": "KI-Chat-Lernen öffnen",
+      "etsSelectAll": "Alle auswählen",
+      "etsSelectNone": "Alle abwählen",
+      "etsReadOnlyAll": "Nur lesen setzen",
+      "etsReadOnlyNone": "Nur lesen entfernen"
     }
   }
 }

package/nodes/locales/en/knxUltimateAI.html

@@ -20,9 +20,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 +51,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 +90,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,9 +98,9 @@ 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.
@@ -104,10 +109,8 @@ In the Vue web UI, open **Settings → AI Chat Learning** to view and edit the e
 
 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.
-
-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.
@@ -167,12 +170,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 +188,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 +196,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

@@ -10,6 +10,7 @@
       "chatContextOverview": "Chat context overview",
       "chatLearning": "AI Chat Learning",
       "quickSetup": "Assistant setup",
+      "etsAccess": "ETS object access",
       "llmConnection": "AI Assistant Connection",
       "chatAdapter": "Chat input and output pins",
       "homeIntelligence": "AI Education & memory",
@@ -25,20 +26,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 +47,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 +62,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 +82,11 @@
       "installOllamaModel": "2) Install it",
       "ollamaLibrary": "Model library",
       "downloadOllamaModel": "1) Download model",
-      "openChatLearning": "Open AI Chat Learning"
+      "openChatLearning": "Open AI Chat Learning",
+      "etsSelectAll": "Select all",
+      "etsSelectNone": "Select none",
+      "etsReadOnlyAll": "Set read only",
+      "etsReadOnlyNone": "Clear read only"
     },
     "messages": {
       "setupDoctorLoading": "Analyzing this installation…",
@@ -100,9 +98,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 +108,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…",
@@ -143,9 +148,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",
@@ -154,6 +159,7 @@
       "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.",
+      "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",