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

package/nodes/knxUltimateAIHomeAssistant.html

@@ -0,0 +1,40 @@
+<script type="text/javascript">
+    RED.nodes.registerType('knxUltimateAIHomeAssistant', {
+        category: "KNX Ultimate (legacy)",
+        color: '#41BDF5',
+        defaults: {
+            name: { value: "Legacy Home Assistant bridge" },
+            requestTimeoutMs: { value: 15000, validate: RED.validators.number() }
+        },
+        inputs: 1,
+        outputs: 1,
+        outputLabels: function () { return "ha-api request"; },
+        icon: "font-awesome/fa-home",
+        label: function () { return this.name || "Legacy Home Assistant bridge"; },
+        paletteLabel: "Legacy Home Assistant bridge"
+    });
+    try { RED.palette.remove('knxUltimateAIHomeAssistant'); } catch (error) { }
+</script>
+
+<script type="text/html" data-template-name="knxUltimateAIHomeAssistant">
+    <div class="form-tips" style="margin-bottom:10px;"><b>Legacy node:</b> for new installations use the Home Assistant bridge included with <a href="https://github.com/Supergiovane/node-red-contrib-cerebrum-ultimate#readme" target="_blank"><b>Cerebrum Ultimate</b></a>.</div>
+    <div class="form-row">
+        <label for="node-input-name"><i class="fa fa-tag"></i> Name</label>
+        <input type="text" id="node-input-name">
+    </div>
+    <div class="form-row">
+        <label for="node-input-requestTimeoutMs"><i class="fa fa-clock-o"></i> API timeout</label>
+        <input type="number" id="node-input-requestTimeoutMs" min="3000" max="60000" step="1000">
+    </div>
+    <div class="form-tips">
+        Connect this node's output to a Home Assistant <b>API</b> node (<code>ha-api</code>), then connect the API output back to this node's input. Home Assistant event nodes may also feed this input so Cerebrum can observe their state changes.
+    </div>
+</script>
+
+<script type="text/html" data-help-name="knxUltimateAIHomeAssistant">
+    <p>Connects Cerebrum to the Home Assistant Node-RED API node without storing Home Assistant credentials in KNX Ultimate.</p>
+    <h3>Required round trip</h3>
+    <p><code>Cerebrum Home Assistant → API (ha-api) → Cerebrum Home Assistant</code></p>
+    <p>The bridge sends dynamic WebSocket requests under <code>msg.payload</code>, correlates the returned message and exposes entity, state, service and event capabilities to the in-process Cerebrum registry.</p>
+    <p>Writes are only a provider capability. Cerebrum Ultimate must still apply its normal proposal, validation and confirmation policy before a Home Assistant service call can be executed.</p>
+</script>

package/nodes/knxUltimateAIHomeAssistant.js

@@ -0,0 +1,152 @@
+const {
+  getKnxAiHomeAutomationRegistry,
+  normalizeKnxAiHomeAutomationEvent
+} = require('./utils/knxAiCerebrum')
+
+const HOME_ASSISTANT_ADAPTER_ID = 'home-assistant'
+const DEFAULT_REQUEST_TIMEOUT_MS = 15000
+
+module.exports = function (RED) {
+  function knxUltimateAIHomeAssistant (config) {
+    RED.nodes.createNode(this, config)
+    const node = this
+    const registry = getKnxAiHomeAutomationRegistry()
+    const requestTimeoutMs = Math.max(3000, Math.min(60000, Number(config.requestTimeoutMs) || DEFAULT_REQUEST_TIMEOUT_MS))
+    const pendingRequests = new Map()
+    const listeners = new Set()
+    let requestSequence = 0
+    let closing = false
+
+    node.name = config.name || 'Cerebrum Home Assistant'
+
+    const updateStatus = ({ fill = 'grey', shape = 'ring', text = '' } = {}) => {
+      try { node.status({ fill, shape, text }) } catch (error) { /* ignore */ }
+    }
+
+    const notifyEvent = event => {
+      listeners.forEach(listener => {
+        try { listener(event) } catch (error) { /* ignore */ }
+      })
+    }
+
+    const sendApiRequest = data => new Promise((resolve, reject) => {
+      if (closing) return reject(new Error('Cerebrum Home Assistant is closing'))
+      requestSequence += 1
+      const requestId = `${node.id}:${Date.now()}:${requestSequence}`
+      const timer = setTimeout(() => {
+        pendingRequests.delete(requestId)
+        updateStatus({ fill: 'yellow', shape: 'ring', text: 'ha-api timeout' })
+        reject(new Error('Home Assistant ha-api request timed out; verify the round-trip wiring'))
+      }, requestTimeoutMs)
+      pendingRequests.set(requestId, { resolve, reject, timer })
+      node.send({
+        payload: {
+          protocol: 'websocket',
+          data,
+          location: 'payload',
+          locationType: 'msg'
+        },
+        knxAiCerebrum: {
+          requestId,
+          adapterId: HOME_ASSISTANT_ADAPTER_ID,
+          providerId: node.id,
+          direction: 'request'
+        }
+      })
+      updateStatus({ fill: 'blue', shape: 'dot', text: 'querying ha-api' })
+    })
+
+    const provider = {
+      id: node.id,
+      adapterId: HOME_ASSISTANT_ADAPTER_ID,
+      title: node.name,
+      capabilities: ['entities', 'events', 'services', 'states'],
+      listEntities: () => sendApiRequest({ type: 'get_states' }).then(result => Array.isArray(result) ? result : []),
+      getEntity: entityId => sendApiRequest({ type: 'get_states' }).then(result => {
+        const requested = String(entityId || '').trim().toLowerCase()
+        return (Array.isArray(result) ? result : []).find(entity => String(entity && entity.entity_id || '').trim().toLowerCase() === requested) || null
+      }),
+      listServices: () => sendApiRequest({ type: 'get_services' }),
+      callService: ({ domain, service, serviceData, target, authorization } = {}) => {
+        const safeDomain = String(domain || '').trim()
+        const safeService = String(service || '').trim()
+        if (!safeDomain || !safeService) return Promise.reject(new Error('Home Assistant domain and service are required'))
+        if (!authorization || authorization.confirmed !== true || authorization.source !== 'knxUltimateAI') {
+          return Promise.reject(new Error('Home Assistant service calls require an explicit Cerebrum Ultimate confirmation authorization'))
+        }
+        return sendApiRequest({
+          type: 'call_service',
+          domain: safeDomain,
+          service: safeService,
+          service_data: serviceData && typeof serviceData === 'object' ? serviceData : {},
+          target: target && typeof target === 'object' ? target : {}
+        })
+      },
+      subscribe: listener => {
+        if (typeof listener !== 'function') return () => {}
+        listeners.add(listener)
+        return () => listeners.delete(listener)
+      }
+    }
+
+    registry.registerAdapter({
+      id: HOME_ASSISTANT_ADAPTER_ID,
+      title: 'Home Assistant',
+      packageName: 'node-red-contrib-home-assistant-websocket',
+      capabilities: provider.capabilities
+    })
+    registry.registerProvider(provider)
+
+    node.on('input', function (msg, send, done) {
+      try {
+        const metadata = msg && msg.knxAiCerebrum && typeof msg.knxAiCerebrum === 'object' ? msg.knxAiCerebrum : {}
+        const requestId = String(metadata.requestId || '')
+        const pending = requestId ? pendingRequests.get(requestId) : null
+        if (pending) {
+          clearTimeout(pending.timer)
+          pendingRequests.delete(requestId)
+          if (msg && msg.error) pending.reject(new Error(String(msg.error.message || msg.error)))
+          else pending.resolve(msg ? msg.payload : undefined)
+          updateStatus({ fill: 'green', shape: 'dot', text: 'ha-api ready' })
+          if (typeof done === 'function') done()
+          return
+        }
+
+        const event = normalizeKnxAiHomeAutomationEvent(msg, {
+          adapterId: HOME_ASSISTANT_ADAPTER_ID,
+          providerId: node.id
+        })
+        if (event) {
+          notifyEvent(event)
+          updateStatus({ fill: 'green', shape: 'dot', text: event.entityId || event.eventType })
+        }
+        if (typeof done === 'function') done()
+      } catch (error) {
+        updateStatus({ fill: 'red', shape: 'dot', text: error.message || String(error) })
+        if (typeof done === 'function') done(error)
+        else node.error(error, msg)
+      }
+    })
+
+    node.on('close', function (done) {
+      closing = true
+      registry.unregisterProvider(node.id)
+      pendingRequests.forEach(pending => {
+        clearTimeout(pending.timer)
+        pending.reject(new Error('Cerebrum Home Assistant node closed'))
+      })
+      pendingRequests.clear()
+      listeners.clear()
+      if (typeof done === 'function') done()
+    })
+
+    updateStatus({ fill: 'yellow', shape: 'ring', text: 'wire output → ha-api → input' })
+  }
+
+  RED.nodes.registerType('knxUltimateAIHomeAssistant', knxUltimateAIHomeAssistant)
+}
+
+module.exports.__test = {
+  DEFAULT_REQUEST_TIMEOUT_MS,
+  HOME_ASSISTANT_ADAPTER_ID
+}

package/nodes/knxUltimateHueController.html

@@ -307,7 +307,7 @@
       category: 'KNX Ultimate HUE',
       color: '#C0C7E9',
       defaults: buildDefaults(),
-      // catalogDefaults is consumed by the KNX AI catalog. It intentionally
+      // catalogDefaults is consumed by the Cerebrum Ultimate catalog. It intentionally
       // describes only the stable public surface; the real persistence contract
       // remains the complete `defaults` union above.
       catalogDefaults: {

package/nodes/knxUltimateMatterBridge.html

@@ -135,7 +135,7 @@
 
     RED.nodes.registerType('knxUltimateMatterBridge', {
       category: 'KNX Ultimate Matter',
-      color: '#F3FFFF',
+      color: '#8FB1FA',
       defaults: gaDefaults,
       inputs: 0,
       outputs: 0,
@@ -672,4 +672,4 @@ section directly below, with copyable examples filtered to the selected device t
 
 - input: `msg.payload = { function: "onoff", value: true }` updates the Matter state without the KNX bus
 - output: every command from a Matter controller is forwarded as `msg` (topic = device name, payload = value, `msg.matter` = raw command)
-</script>
+</script>

package/nodes/knxUltimateMatterControllerDevice.html

@@ -10,7 +10,7 @@
 
     RED.nodes.registerType("knxUltimateMatterControllerDevice", {
       category: "KNX Ultimate Matter",
-      color: "#F3FFFF",
+      color: "#8FB1FA",
       defaults: {
         //buttonState: {value: true},
         server: { type: "knxUltimate-config", required: false },
@@ -295,9 +295,9 @@
           const normalizeConfigSelection = selectionApi && typeof selectionApi.normalizeSelection === 'function'
             ? selectionApi.normalizeSelection
             : (value, emptyValues) => {
-                const normalized = value === undefined || value === null ? '' : String(value).trim();
-                return emptyValues.has(normalized.toLowerCase()) ? '' : normalized;
-              };
+              const normalized = value === undefined || value === null ? '' : String(value).trim();
+              return emptyValues.has(normalized.toLowerCase()) ? '' : normalized;
+            };
           const resolveSelectedOrStoredSelection = selectionApi && typeof selectionApi.resolveSelectedOrStoredSelection === 'function'
             ? selectionApi.resolveSelectedOrStoredSelection
             : (selectedValue, storedValue, emptyValues) => normalizeConfigSelection(selectedValue, emptyValues) || normalizeConfigSelection(storedValue, emptyValues);
@@ -662,19 +662,19 @@
               hasColorFeatureMap
                 ? (colorFeatureMap & 0x10) !== 0
                 : (
-                    hasColorTemperatureType ||
-                    hasMatterAttribute(colorCluster, ['colorTemperatureMireds', 'colorTempPhysicalMinMireds', 'colorTempPhysicalMaxMireds']) ||
-                    hasMatterCommand(colorCluster, ['moveToColorTemperature'])
-                  )
+                  hasColorTemperatureType ||
+                  hasMatterAttribute(colorCluster, ['colorTemperatureMireds', 'colorTempPhysicalMinMireds', 'colorTempPhysicalMaxMireds']) ||
+                  hasMatterCommand(colorCluster, ['moveToColorTemperature'])
+                )
             );
             const hasColor = !!colorCluster && (
               !isTunableWhiteOnly && (
                 hasColorFeatureMap
                   ? (colorFeatureMap & 0x09) !== 0
                   : (
-                      hasColorType ||
-                      hasMatterCommand(colorCluster, ['moveToColor', 'moveToHue', 'moveToSaturation', 'moveToHueAndSaturation'])
-                    )
+                    hasColorType ||
+                    hasMatterCommand(colorCluster, ['moveToColor', 'moveToHue', 'moveToSaturation', 'moveToHueAndSaturation'])
+                  )
               )
             );
             return {
@@ -2834,4 +2834,4 @@ _Basic Matter effects_
 The Dimming function works in **KNX mode `start` and`stop` ** . To start dimming, send only one "start" KNX telegram. To stop dimming, send a "stop" KNX telegram. Please**remember that** , when you set your wall swiches properties.
 
 <br/>
-</script>
+</script>

package/nodes/locales/de/knxUltimateAI.html

@@ -1,200 +1,5 @@
-<script type="text/markdown" data-help-name="knxUltimateAI">
-Dieser Node überwacht **alle KNX-Telegramme** des ausgewählten KNX-Ultimate-Gateways, erstellt Verkehrsstatistiken, erkennt Anomalien und kann optional ein LLM befragen.
-
-Der Editor verwendet zwei horizontale Registerkarten: **KI-Assistent** enthält Einrichtung, Wissen/Kontext und Anbietergrenzen; **Gespräche & Zuhause** enthält Chat-Pins für Ein- und Ausgang, proaktives Zuhause und begrenztes Gedächtnis.
-
-## Ausgänge
-1. **Zusammenfassung/Statistik** (`msg.payload` JSON)
-2. **Anomalien** (`msg.payload` JSON)
-3. **KI-Assistent** (`msg.payload` Text, mit `msg.summary`)
-4. **KNX-Operationen** (eine Universal-Mode-Nachricht je validierter Lese- oder Schreiboperation)
-5. **TTS Ultimate** (eine Ansagenachricht je vom Modell gewählter Sprachausgabe)
-
-Jede an den Ausgängen 3 und 4 ausgegebene Nachricht enthält außerdem eine Kopie der ursprünglichen Eingangsnachricht in `msg.inputMessage`. Dadurch bleiben der ursprüngliche Payload, das Topic, die Chat-Metadaten und alle weiteren Eingangseigenschaften für nachfolgende Nodes verfügbar. Fehler beim Klonen oder Ausgeben werden abgefangen und gemeldet, statt in die Node-RED-Laufzeit zu gelangen.
-
-### Setup Doctor und sicherer erster Start
-Der automatische **Setup Doctor** prüft das ausgewählte Gateway und den ETS-Import, die KI-Aktivierung, Anbieter, Modell und API-Schlüssel, die Erreichbarkeit des Anbieters, die Flow-Verdrahtung, erkannte Kameras und die optionale TTS-Ultimate-Verbindung. Sein kostenloser Anbieter-Preflight ruft ausschließlich den Endpunkt für die Modellliste auf: Er sendet keine Chat-Anfrage und verbraucht keine Inferenz-Tokens. Kameras und TTS sind optional; ihre Nichtverwendung verringert daher nicht die Kernbereitschaft.
-
-Das Inventar meldet die exakte Anzahl eindeutiger KNX-Gruppenadress-Signale, die ETS-Bereiche/-Gruppen und eine geschätzte Anzahl logischer Funktionen. Eine Anzahl physischer Geräte wird bewusst nicht angegeben, da sie aus dem ETS-CSV nicht zuverlässig abgeleitet werden kann. Der Setup Doctor liest den zuletzt deployten Flow; Änderungen an Anbieter, Modell, Preset, Gateway oder Verdrahtung daher zuerst deployen und erst anschließend mit **Aktualisieren** erneut prüfen.
-
-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, 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.
-
-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.
-
-Sobald verifizierte Webergebnisse vorliegen, kann das Modell weitere aktivierte Tools kombinieren, wenn die aktuelle Chat-Anfrage oder die KI-Erziehung dies autorisiert. Webzugriff erweitert niemals Berechtigungen: Verfügbarkeit von Kamera, TTS und Gedächtnis sowie KNX-Lese- und Schreiboperationen, lokale ETS-/DPT-Validierung und die konfigurierte Bestätigung von KNX-Schreibvorgängen bleiben unverändert. Web-Anfragen legen externen Websites oder dem Suchdienst die Anfrage und die öffentliche IP dieses Servers offen; KNX-/ETS-Daten, Kamerainhalte, Chat-Kennungen, gelerntes Gedächtnis und Zugangsdaten werden nie automatisch hinzugefügt.
-
-### Pläne und Erinnerungen in natürlicher Sprache
-Im normalen Chat kann der Benutzer KNX AI bitten, eine einmalige oder wiederkehrende Erinnerung, Überwachung oder einen zukünftigen Hausbefehl anzulegen, aufzulisten oder abzubrechen. Das Modell wählt das strukturierte Planungswerkzeug `scheduleActions` semantisch aus der vollständigen Anfrage und speichert das vollständige Ziel mit seinen Bedingungen als Anweisung in natürlicher Sprache. Es gibt keine Planungs-Schlüsselwörter, Listen von Auslösephrasen oder starren Intent-Klassifikatoren; Formulierung und Sprache schränken die Funktion nicht ein.
-
-Pläne gehören zur Chat-Sitzung und bleiben pro KNX-AI-Node über Node-RED-Neustarts hinweg erhalten. Der verbindliche Laufzeitstatus liegt in `<userDir>/knxai/schedules/knxai-schedules-<node-id>.json`; zusätzlich erzeugt KNX AI `<userDir>/knxai/schedules/knxai-schedules-<node-id>.md` als lesbare Ansicht. Ein Plan kann einmal laufen, sich in Abständen von mindestens fünf Minuten wiederholen und optional ablaufen. Das Modell kann nur die aktiven Pläne des aktuellen Chats auflisten oder abbrechen, außer der Benutzer verlangt ausdrücklich, alle Pläne dieses Chats abzubrechen.
-
-Ist eine Aufgabe fällig, startet KNX AI einen getrennten Modelldurchlauf und verwendet die gespeicherte natürlichsprachige Anweisung als vertrauenswürdige Benutzerautorisierung. Eine Überwachung bleibt still, wenn ihre Bedingung nicht erfüllt ist. Bei der Ausführung gelten alle bestehenden Berechtigungen: Eine Wetterüberwachung benötigt **Der KI die Nutzung des Webs erlauben** und verwendet dasselbe Web-Budget, ein gesprochenes Ergebnis verlässt Ausgang 5 und benötigt deshalb einen verkabelten TTS-Ultimate-Node, und Kamerawerkzeuge bleiben auf erkannte Adapter beschränkt. Ein geplanter KNX-Schreibvorgang behält die exakten ETS-/DPT-Prüfungen bei und zeigt bei aktivierter Bestätigung derselben Chat-Sitzung zunächst eine Vorschau; Ausgang 4 sendet erst nach der Bestätigung.
-
-Der Benutzer kann zum Beispiel schreiben: „Prüfe in den nächsten fünf Tagen alle 30 Minuten die Vorhersage für Cortemaggiore und verwende TTS Ultimate nur, wenn Gewitter vorhergesagt sind.“ KNX AI kann diese vollständige Bedingung und Dauer als eine wiederkehrende Überwachung speichern; die genannten Web- und TTS-Voraussetzungen bleiben bestehen.
-
-## Befehle (Eingang)
-Sende `msg.topic`:
-- `summary` (oder leer): Summary sofort senden
-- `reset`: internen Verlauf, Zähler, gelerntes Hausgedächtnis, alle gespeicherten Chat-Kontexte und alle Pläne dieses Nodes löschen; die im Node konfigurierte KI-Erziehung bleibt unverändert
-- `ask`: Frage an das konfigurierte LLM senden
-- `confirm` / `cancel`: ausstehende KNX-Befehle ohne erneuten LLM-Aufruf bestätigen oder abbrechen
-- `clear_chat`: letzte Gesprächsschritte, dauerhafte Anweisungen und ausstehende Befehle der aktuellen Sitzung löschen und ihre aktiven Pläne abbrechen; andere Sitzungen und die KI-Erziehung bleiben unverändert
-
-Für `ask` die Frage in `msg.prompt` (empfohlen), `msg.payload` (String) oder den üblichen Telegram-Feldern `msg.payload.content` / `msg.payload.text` übergeben.
-
-Dauert die Verarbeitung länger als 1,2 Sekunden, sendet Ausgang 3 sofort die lokalisierte Zwischenmeldung „Ich denke nach…“ mit `msg.knxAi.type = "thinking"` und `msg.knxAi.transient = true`. Der Chat-Adapter übermittelt sie an denselben Benutzer; die endgültige Antwort folgt wie gewohnt, sobald sie bereit ist. Diese Fortschrittsmeldung wird weder im Gesprächskontext noch im gelernten Gedächtnis gespeichert.
-
-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.
-
-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.
-
-Jede Ask-/Chat-Sitzung speichert ihre letzten 8 Gesprächsschritte und bis zu 20 vom Modell ausgewählte langfristige Anweisungen, getrennt nach `msg.knxAi.sessionId`, `msg.sessionId` oder erkannter Telegram-Chat-ID. Das Modell entscheidet semantisch über das strukturierte Gedächtniswerkzeug, was aus einem Gespräch gespeichert oder vergessen werden soll; es gibt keine sprachliche Schlüsselwort- oder Intent-Liste. Alle KNX-AI-Nodes mit demselben Speicher teilen diesen Kontext live und laden ihn nach einem Node-RED-Neustart aus `knxultimatestorage/knxai/memory/knxai-chat-context.knxctx`. Die atomar geschriebene Datei ist auf 50 Sitzungen und 512 KB begrenzt. Bei aktiviertem KNX-Steuern Ausgang 3 mit dem Chat-Sender und Ausgang 4 mit einem KNX-Ultimate-Node im **Universalmodus** verbinden. Bei aktiver Bestätigung zeigt die erste Antwort GA, DPT und Payload, ohne Schreiboperationen auszugeben; dieselbe Sitzung muss innerhalb von 5 Minuten `BESTÄTIGEN` oder `ABBRECHEN` antworten. Eine neue Anfrage ersetzt einen älteren Plan. Jeder bestätigte Befehl enthält `msg.destination`, `msg.dpt`, `msg.payload` und `msg.event = "GroupValue_Write"`.
-Der aktuelle Sitzungsspeicher steht unmittelbar neben der aktuellen Anfrage, damit lokale Modelle vom Benutzer angegebene Fakten wie bevorzugten Namen oder Sprache auch in einem großen KNX-Prompt behalten. Das Modell kann dauerhafte Fakten, Vorlieben und Anweisungen über `memoryActions` speichern; dies bleibt eine semantische Werkzeugwahl ohne Phrasenklassifizierer oder Intent-Routing. Zugangsdaten, Sicherheitscodes und API-Schlüssel dürfen niemals gelernt werden.
-
-Bei DPT-1.xxx-Schreibvorgängen werden die sicheren KI-Entsprechungen `true`/`false`, `1`/`0` und `on`/`off` vor der lokalen Validierung und Ausgabe in echte Boolesche Werte normalisiert.
-
-### Aktuelle KNX-Lesewerte
-Wenn der Benutzer ausdrücklich einen aktuellen oder aktualisierten Zustand anfordert, kann die KI exakte Objekte aus dem importierten ETS-Katalog abfragen, einschließlich Status- und anderer schreibgeschützter Objekte. Ausgang 4 gibt `msg.destination`, `msg.dpt`, `msg.event = "GroupValue_Read"` und `msg.readstatus = true` aus. Der Node wartet bis zu 6 Sekunden auf jede `GroupValue_Response` oder ein aktuelles Write-Telegramm, gibt anschließend die dekodierten Werte an Ausgang 3 zurück und stellt Details in `msg.knxAi.readResults` bereit. Leseoperationen erfordern keine Bestätigung und werden niemals in Schreiboperationen umgewandelt. Lässt ein kleines lokales Modell Vorgangstyp und Payload weg, werden exakte ETS-Objekte sicher als Leseoperationen normalisiert; ein Element mit Payload bleibt eine validierte Schreiboperation.
-
-### Mehrstufige Gesprächsroutinen
-Anfragen wie „Ich gehe“, „Gute Nacht“ oder „Kinomodus“ können ohne neue Editor-Option eine zustandsabhängige Routine koordinieren. Im ersten LLM-Durchlauf werden ausschließlich exakte ETS-Leseoperationen akzeptiert (maximal 20); KNX AI sendet sie und übergibt die aktuellen GA-/DPT-/Wert-Ergebnisse an einen zweiten isolierten Planungsdurchlauf. Dieser darf bis zu 12 validierte Schreiboperationen vorbereiten, aber keinen weiteren Lesezyklus starten. Bei aktivierter Bestätigung benötigt der gesamte Plan eine einzige lokalisierte Bestätigung; vorher werden weder Schreiboperationen noch angeforderte TTS-Ansagen ausgegeben. Nach der Bestätigung wird jede Schreiboperation erneut validiert, in Reihenfolge weitergegeben und bis zu 4 Sekunden auf eine passende unmittelbare Bus-Rückmeldung beobachtet. Die Abschlussmeldung unterscheidet beobachtete Rückmeldungen von Vorgängen ohne unmittelbare Rückmeldung, ohne daraus einen Gerätefehler abzuleiten. Details stehen in `msg.knxAi.routine`, `readResults`, `verifiedCount` und `unverifiedCount`.
-
-### Bestätigungsanfrage für Chat-Schaltflächen
-Solange ein Plan aussteht, enthält Ausgang 3 `msg.knxAi.confirmationRequest`. Das Objekt enthält `required`, `status`, `sessionId`, `expiresAt`, `commandCount` und zwei Einträge in `actions`. Verwenden Sie `action.label` als Text der Telegram-Schaltfläche, `action.callbackData` als Callback und senden Sie `action.message` an KNX AI zurück, um ohne Texteingabe zu bestätigen oder abzubrechen.
-
-### Adapter für Ein-/Ausgangsnachrichten
-Der Bereich **Chat-Pins für Ein- und Ausgang** lädt seine auswählbaren Zuordnungen aus `resources/KNXAIChatAdapterMappings.js`. Die Auswahl eines Adapters installiert intern zwei vordefinierte synchrone JavaScript-Zuordnungen: eine vor der Verarbeitung des Eingangs durch KNX AI und eine vor der Ausgabe an Ausgang 3. Die Zuordnungen bleiben im Editor verborgen. Syntax- und Laufzeitfehler werden abgefangen und gemeldet, ohne Node-RED anzuhalten.
-
-Die enthaltene Vorlage **windkh/node-red-contrib-telegrambot** folgt dem Receiver-/Sender-Vertrag des Pakets. Verbinden Sie einen `telegram receiver` direkt mit KNX AI und Ausgang 3 direkt mit einem `telegram sender`. Die Bestätigung verwendet eine einmalige Telegram-Antworttastatur: Ein Klick auf **Bestätigen** oder **Abbrechen** sendet eine normale lokalisierte Nachricht über denselben Receiver zurück, daher sind weder ein `telegram event` noch eine Callback-Verkabelung erforderlich. Alte `callback_query`-Nachrichten werden weiterhin akzeptiert. Die Eingangszuordnung liest `msg.payload.content`, `msg.payload.chatId` und die Telegram-Sprache. Die Ausgangszuordnung erstellt `msg.payload.chatId`, `type` und `content` und ergänzt bei ausstehender Schreibbestätigung `options.reply_markup` aus `msg.knxAi.confirmationRequest`. Das Telegram-Paket bleibt eine separate optionale Abhängigkeit.
-
-Mit dieser Vorlage wird eine Telegram-Sprachnachricht (`msg.payload.type = "voice"`) nur dann automatisch verarbeitet, wenn **Provider** auf **OpenAI-compatible** eingestellt ist. KNX AI prüft den Provider vor jedem Download, verwendet dessen konfigurierte **Endpoint URL** und **API key** erneut und leitet `/audio/transcriptions` sowie `/audio/speech` aus derselben Verbindung ab. Der tokenhaltige Link `msg.payload.weblink` wird nur für den begrenzten Download verwendet und entfernt, bevor die Nachricht Ausgänge oder das LLM erreicht. OGG/Opus-Eingaben werden mit dem integrierten Standard `gpt-4o-mini-transcribe` transkribiert; eine erfolgreiche Anfrage erhält eine native Telegram-OGG/Opus-Antwort mit `gpt-4o-mini-tts` und `alloy`, wobei Textunterschrift und Bestätigungstastatur erhalten bleiben. Bei einem anderen Provider erhält der Benutzer einen lokalisierten Hinweis, OpenAI-compatible auszuwählen oder Text zu senden. Ist die Sprachsynthese nicht verfügbar, schlägt sie fehl oder überschreitet sie das Sprachlimit, wird die vollständige Antwort als Text gesendet. Heruntergeladenes Audio und Antworttext gehen an denselben ausgewählten Provider. Textnachrichten, Fotos und ältere gespeicherte Telegram-Zuordnungen bleiben kompatibel.
-
-Jede native Sprachantwort beginnt in der Bildunterschrift mit dem lokalisierten Hinweis **KI-generierte Stimme**, der für den Telegram-Empfänger sichtbar ist.
-
-Die enthaltene Vorlage **RedBot / node-red-contrib-chatbot (Telegram)** folgt dem gemeinsamen RedBot-Nachrichtenformat. Verbinden Sie `chatbot-telegram-receive` direkt mit KNX AI und Ausgang 3 direkt mit `chatbot-telegram-send`; ein separater Callback-Node ist nicht erforderlich, da RedBot Postbacks von Inline-Schaltflächen in normale Eingangsnachrichten umwandelt. Text und Postbacks verwenden RedBots `message`-Payload. Eine native Telegram-Sprachnachricht kommt als `type = "audio"` mit dem bereits von RedBot heruntergeladenen OGG/Opus-`Buffer` an: KNX AI wendet Größen- und Dauergrenzen ohne zweiten Download an, transkribiert sie mit demselben oben beschriebenen OpenAI-kompatiblen Provider und antwortet mit einem nativen RedBot-`audio`-Payload samt Textunterschrift und lokalisiertem Hinweis auf die KI-generierte Stimme. Wenn eine KNX-Schreibbestätigung erforderlich ist, bleibt die Antwort bewusst ein textbasierter `inline-buttons`-Payload, da RedBot diese Schaltflächen nicht an dieselbe Sprachnachricht anhängen kann. Die Ausgangszuordnung bewahrt die RedBot-Trackingdaten `originalMessage`, `chat`, `api` und `client`; ältere gespeicherte RedBot-Zuordnungen werden zur Laufzeit aktualisiert. RedBot bleibt eine separate optionale Abhängigkeit.
-
-### Automatisch erkannte Kamera-Adapter
-Installierte Kamerapakete können KNX AI zur Laufzeit einen Kamera-Adapter bereitstellen. Es gibt weder eine Auswahl noch einen Kamera-Node, der mit KNX AI verbunden werden muss: verfügbare Adapter, Controller und Kameras werden automatisch erkannt und in den Chat-Kontext aufgenommen. `node-red-contrib-unifi-ultimate` ist der erste unterstützte Anbieter; weitere Pakete wie `hikvision-ultimate` können sich über denselben herstellerneutralen Vertrag registrieren.
-
-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. 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.
-
-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: 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 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.
-
-Öffnen Sie in der Vue-Weboberfläche **Einstellungen → KI-Chat-Lernen**, um die exakte gemeinsame Datei `knxai-chat-context.knxctx` und ihren absoluten Pfad anzuzeigen und zu bearbeiten. Die Datei kann kopiert, als Sicherung heruntergeladen oder aus einer anderen `.knxctx`-Datei wiederhergestellt werden. **Speicher neu initialisieren** ersetzt sie nach ausdrücklicher Bestätigung durch einen neuen leeren Kontext und löscht gespeicherte Sitzungen, Anweisungen, Kameraüberwachungen und ausstehende Chat-Bestätigungen in allen KNX-AI-Nodes desselben Speichers. Die nativen, tabulatorgetrennten Datensätze `KNXAI_CHAT_CONTEXT 3` sind maßgeblich und direkt bearbeitbar: `SESSION` enthält `INSTRUCTION`-, `TURN`- und `CAMERA_WATCH`-Datensätze bis `END_SESSION`. Beim Speichern werden diese Datensätze geprüft und begrenzt, die Datei atomar neu geschrieben und der aktive Kontext aller KNX-AI-Nodes im selben Speicher aktualisiert. Eine Revisionsprüfung verhindert, dass zwischenzeitlich geändertes Lernen überschrieben oder zurückgesetzt wird.
-
-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.
-
-### 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.
-
-Die letzte Chat-Sitzung wird als Eigentümer gespeichert und empfängt spontane Nachrichten. Ausgang 3 gibt `msg.knxAi.type = "proactive_notification"` aus; `msg.inputMessage` bewahrt die Sitzung für den Chat-Adapter. Höchstens drei proaktive Nachrichten pro Stunde verhindern eine Nachrichtenflut. Ausgang 4 wird niemals proaktiv verwendet und KNX wird nicht selbstständig verändert.
-
-Die gemeinsame gelernte Referenz wird beim Start aus `<userDir>/knxai/memory/knxai-home-memory.md` geladen, alle 15 Minuten atomar neu geschrieben und immer strikt auf 5 MB begrenzt. Sie enthält höchstens 120 wichtige Beobachtungen, 80 aggregierte Gewohnheiten, 80 Benachrichtigungen und 300 semantische ETS-Objekte, niemals einen unbegrenzten Rohtelegrammstrom. Alte Einträge mit niedriger Priorität werden zuerst entfernt.
-
-**KI-Erziehung** ist auf 16.000 Zeichen begrenzt und eine feste Eigenschaft, die mit dem Node im Node-RED-Flow gespeichert wird. Nur der Benutzer ändert sie im Editor und wendet sie mit Deploy an. Das Modell liest sie als verbindliche Vorgabe, kann sie aber niemals schreiben oder überschreiben. Im Chat angeforderte Fakten und Präferenzen gehören in das gelernte Chat-Gedächtnis; einmalige oder wiederkehrende Pläne, Erinnerungen, Überwachungen und zukünftige Befehle gehören in den semantischen Scheduler. Die Datei des gelernten Gedächtnisses enthält den Text der KI-Erziehung absichtlich nicht.
-
-## Praktisches Konfigurationsbeispiel
-Schreiben Sie die vollständige Benachrichtigungsrichtlinie in die **KI-Erziehung** (`aiEducation`):
-
-```text
-Nenne mich Alex und antworte in derselben Sprache wie ich.
-Antworte kurz, außer ich bitte um technische Einzelheiten.
-Benachrichtige meinen letzten Chat, wenn ein Rollladen, Fenster oder eine Tür mindestens 120 Minuten offen bleibt.
-Zwischen 23:00 und 07:00 keine Meldungen; dieselbe Meldung frühestens nach sechs Stunden wiederholen.
-Der Büro-Rollladen darf tagsüber offen bleiben: benachrichtige mich nicht.
-Wenn „Wohnzimmerlicht“ mehrdeutig ist, frage nach der gemeinten Leuchte.
-Behaupte nie eine Aktoränderung, bevor ein KNX-Statusobjekt sie bestätigt.
-```
-
-Damit kann Ausgang 3 nach 120 Minuten eine lokalisierte `proactive_notification` für den Wohnzimmer-Rollladen ausgeben, während eine Meldung für den Büro-Rollladen durch die Erziehung unterdrückt wird. Bittet Alex danach um das Schließen, erstellt KNX AI den exakten ETS-Befehl, behält aber Validierung und Bestätigung vor Ausgang 4 bei.
-
-Verwenden Sie aussagekräftige ETS-Hierarchien und Objektnamen sowie korrekte Status-/Befehlsrollen. Die Erziehung personalisiert Entscheidungen und Formulierungen, kann aber keine Gruppenadresse erfinden, keinen DPT ändern und die KNX-Validierung nicht umgehen.
-
-## Kurzer Ablauf: KNX-Steuerung
-1. Importieren Sie die ETS-CSV in das Gateway und konfigurieren Sie LLM-Anbieter, Modell und Zugangsdaten.
-2. Aktivieren Sie **LLM-Assistent** und **KNX-Zustände lesen und Aktoren steuern**; lassen Sie die Bestätigung aktiviert.
-3. Verbinden Sie den Chat-Eingang mit KNX AI und behalten Sie eine stabile Sitzungs-/Chat-ID bei.
-4. Verbinden Sie Ausgang 3 mit der Chat-Antwort und Ausgang 4 mit KNX Ultimate im **Universalmodus**.
-5. Der Benutzer sendet eine Anfrage; aktuelle Zustandsabfragen werden sofort gelesen, während Schreiboperationen zuerst GA, DPT und Wert ohne Bus-Schreibzugriff anzeigen.
-6. Innerhalb von 5 Minuten antwortet derselbe Chat exakt mit `BESTÄTIGEN` oder `ABBRECHEN`.
-7. Nur `BESTÄTIGEN` validiert erneut und gibt Befehle an Ausgang 4 aus; prüfen Sie die Ausführung über eine KNX-Status-GA.
-
-## Konfigurationsfelder
-Hier sind alle Felder aufgeführt, wie sie im KNX-AI-Editor sichtbar sind.
-
-### Allgemein
-- **Gateway**: KNX-Ultimate Gateway/Config-Node als Telegrammquelle.
-- **Name**: Node-Name und Dashboard-Titel.
-- **Topic**: Basis-Topic der Node-Ausgänge.
-- Button **Open KNX AI Web**: Öffnet das Web-Dashboard (`/knxUltimateAI/sidebar/page`).
-
-### KI-Assistent
-- **Enable LLM assistant**: Aktiviert Ask/Chat-Funktionen.
-- **Provider**: LLM-Backend (OpenAI-compatible, Anthropic, Ollama oder Bionic LM Studio).
-- **Endpoint URL**: URL des Chat/Completions-Endpunkts.
-- **API key**: API-Schlüssel (für lokales Ollama nicht erforderlich; für Bionic LM Studio optional, sofern die Serverauthentifizierung deaktiviert ist).
-- **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.
-- **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. 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.
-- Mitgelieferte Auszüge aus Hilfe, README, Changelog, Wiki und Beispielen werden nicht in Prompts von Telegram, RedBot oder benutzerdefinierten CHAT-Adaptern aufgenommen. Sie bleiben nur dem Web-Assistenten für technische Fragen zum Paket verfügbar.
-- Button **Refresh**: Fragt den Provider ab und lädt verfügbare Modelle. Währenddessen dreht sich das Symbol; ein erfolgreicher Abschluss bleibt absichtlich ohne Meldung.
-
-### Ollama Schnellstart (lokal)
-- **Provider = Ollama** auswählen.
-- Standard-Endpoint: `http://localhost:11434/api/chat`.
-- Wenn keine lokalen Modelle gefunden werden:
-  - **1) Download model**: öffnet die Seite **Model library**.
-  - **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 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)
-- **Provider = Bionic LM Studio** auswählen.
-- 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. 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
-Bei aktiviertem LLM kann KNX-Traffic-Kontext an den konfigurierten Endpoint gesendet werden. Für striktes On-Premise lokale Provider verwenden. Ein Befehl an Ausgang 4 hat die lokale Validierung bestanden und wurde an den Flow weitergegeben; dies bestätigt nicht die Ausführung durch den Aktor. Dafür eine KNX-Status-GA verwenden.
+<script type="text/html" data-help-name="knxUltimateAI">
+  <p><b>Dies ist ein ausgeblendeter Legacy-Knoten, der nur für vorhandene Flows erhalten bleibt.</b></p>
+  <p>Für neue Installationen verwenden Sie den eigenständigen Knoten <b>Cerebrum Ultimate</b> aus <code>node-red-contrib-cerebrum-ultimate</code>. Er ersetzt diesen Knoten und verwendet KNX Ultimate als optionale kompatible Integration.</p>
+  <p><a href="https://github.com/Supergiovane/node-red-contrib-cerebrum-ultimate#readme" target="_blank">Dokumentation zu Cerebrum Ultimate öffnen</a>.</p>
 </script>

package/nodes/locales/de/knxUltimateAI.json

@@ -1,14 +1,15 @@
 {
   "knxUltimateAI": {
-    "title": "KNX AI (Traffic Analyzer)",
+    "title": "Legacy-KI-Knoten — Cerebrum Ultimate verwenden",
     "sections": {
       "groupAssistant": "KI-Assistent",
-      "groupChatHome": "Gespräche & Zuhause",
+      "groupChatHome": "Cerebrum (BETA)",
       "setupDoctor": "Setup Doctor",
       "webIntelligence": "Web-Intelligenz",
       "detectedAdapters": "Erkannte und im Chat verwendete kompatible Nodes",
       "chatContextOverview": "Übersicht des Chat-Kontexts",
       "chatLearning": "KI-Chat-Lernen",
+      "cerebrumMemory": "Cerebrum-Speicher",
       "quickSetup": "Assistent einrichten",
       "etsAccess": "Zugriff auf ETS-Objekte",
       "llmConnection": "KI-Assistent-Verbindung",
@@ -34,8 +35,8 @@
       "webAccessEnabled": "Der KI die Nutzung des Webs erlauben",
       "webMaxCallsPerHour": "Maximale Web-Aufrufe pro Stunde",
       "chatAdapterPreset": "Adapter für Ein-/Ausgangsnachrichten",
-      "chatInputCode": "Eingangszuordnung (Chat → KNX AI)",
-      "chatOutputCode": "Ausgangszuordnung (KNX AI → Chat)",
+      "chatInputCode": "Eingangszuordnung (Chat → Cerebrum Ultimate)",
+      "chatOutputCode": "Ausgangszuordnung (Cerebrum Ultimate → Chat)",
       "aiEducation": "KI-Erziehung (vom Benutzer verwaltet)"
     },
     "outputs": {
@@ -101,7 +102,7 @@
       "lmStudioContextConfigured": "Aktiver Modellkontext",
       "lmStudioContextFailed": "Der Modellkontext konnte nicht konfiguriert werden",
       "lmStudioContextCurrentlyLoaded": "derzeit geladen",
-      "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.",
+      "etsAccessHint": "Wähle die für Cerebrum Ultimate 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",
@@ -109,7 +110,7 @@
       "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.",
+      "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 Cerebrum Ultimate 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.",
@@ -129,6 +130,7 @@
       "chatContextLoading": "Zusammenfassung des Chat-Kontexts wird geladen…",
       "chatContextUnavailable": "Die Zusammenfassung des Chat-Kontexts ist vorübergehend nicht verfügbar.",
       "chatLearningOpenHint": "Öffnet die Weboberfläche direkt im gemeinsamen CHAT-Lerneditor, um die persistente Datei anzuzeigen, zu bearbeiten, zu kopieren oder zu sichern.",
+      "cerebrumMemoryOpenHint": "Öffnet den lesbaren Cerebrum-Speicher für gelernte Gewohnheiten, Entscheidungen der Bewohner und zwischengespeicherte Hauszustände.",
       "chatContextIntro": "Der Chat erhält diese Quellen automatisch. Die folgenden Pfade werden von dieser Node-RED-Installation tatsächlich verwendet.",
       "chatContextLimitLabel": "Maximaler operativer Kontext",
       "chatContextProviderManaged": "vom ausgewählten Anbieter/Modell verwaltet",
@@ -151,7 +153,7 @@
       "chatContextFileHomeMemory": "Nur begrenztes gelerntes Hausgedächtnis; die KI-Erziehung bleibt in der Node-Eigenschaft.",
       "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.",
+      "chatContextFileAssistantConfig": "Dauerhafte Cerebrum-Konfiguration 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",
@@ -177,7 +179,7 @@
           "ask": "Fragen"
         },
         "empty": {
-          "noNodes": "Keine KNX AI-Knoten gefunden.",
+          "noNodes": "Keine Cerebrum Ultimate-Knoten gefunden.",
           "noAnomalies": "Keine Anomalien."
         },
         "chat": {
@@ -219,6 +221,7 @@
       "ollamaLibrary": "Model library",
       "downloadOllamaModel": "1) Download model",
       "openChatLearning": "KI-Chat-Lernen öffnen",
+      "openCerebrumMemory": "Cerebrum-Speicher öffnen",
       "etsSelectAll": "Alle auswählen",
       "etsSelectNone": "Alle abwählen",
       "etsReadOnlyAll": "Nur lesen setzen",

package/nodes/locales/de/knxUltimateViewer.html

@@ -18,7 +18,7 @@ Sie kann verwendet werden, um:
 - **Lichter** aus booleschen KNX-Werten live anzuzeigen
 - **Dimmer** aus Werten im Stil `DPT 5.001` anzuzeigen
 - Einträge zu filtern, zwischen Viewer-Nodes zu wechseln und Auto-Refresh aktiv zu halten
-- eine optisch mit **KNX AI** abgestimmte Oberfläche zu nutzen
+- eine optisch mit **Cerebrum Ultimate** abgestimmte Oberfläche zu nutzen
 
 Die Webseite wird direkt von Node-RED bereitgestellt und folgt daher demselben Authentifizierungsmodell wie Editor und Admin-Endpunkte.