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

package/nodes/locales/de/knxUltimateAI.html

@@ -1,16 +1,33 @@
 <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-Kanäle, proaktives Zuhause und begrenztes Gedächtnis.
+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, 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.
+
+**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.
+
+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.
+
 ## Befehle (Eingang)
 Sende `msg.topic`:
 - `summary` (oder leer): Summary sofort senden
@@ -43,11 +60,15 @@ Anfragen wie „Ich gehe“, „Gute Nacht“ oder „Kinomodus“ können ohne
 ### 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.
 
-### Chat-Adapter-Vorlagen
-Der Tab **Chat-Adapter** lädt seine auswählbaren Zuordnungen aus `resources/KNXAIChatAdapterMappings.js`. Die Auswahl einer Vorlage 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.
+### 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. Die Eingangszuordnung liest `transport`, `chatId`, `type`, `content` und die Telegram-Sprache. Die Ausgangszuordnung bewahrt die RedBot-Trackingdaten `originalMessage`, `chat`, `api` und `client` und erzeugt anschließend entweder einen `message`-Payload oder einen `inline-buttons`-Payload mit `postback`-Aktionen zur Bestätigung. RedBot bleibt eine separate optionale Abhängigkeit.
 
 ### Automatisch erkannte Kamera-Adapter
@@ -58,14 +79,14 @@ Der Benutzer kann einen aktuellen Snapshot anfordern oder das Vision-Modell nach
 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.
 
 ### Ansagen mit TTS Ultimate
-Wenn das optionale Paket `node-red-contrib-tts-ultimate` installiert ist, erscheint es unter den automatisch erkannten Adaptern. Die Auswahl listet alle `ttsultimate`-Nodes in sämtlichen Projekt-Flows mit Flow, Node-Name und konfiguriertem Player auf. Wählen Sie den Node für Chat-Ansagen aus und deployen Sie den Flow.
+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 diesen Adapter verwendet; 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. KNX AI sendet den gewählten Text direkt als `msg.payload` mit `msg.topic = "knx_ai_announcement"` an den ausgewählten Node. TTS Ultimate verwaltet anschließend Sonos-Player, Stimme, Lautstärke, Hailing und Warteschlange.
+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 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. Außerdem werden `knxai-chat-context.knxctx`, `knxai-home-memory.md` und `knxai-config-<node-id>.json` sowie das absolute Stammverzeichnis des KNX-Telegrammarchivs, das Node-spezifische Verzeichnis und das Tagesdateimuster `YYYY-MM-DD.knxctx` aufgeführt. Die Pfade werden zur Laufzeit aus dem tatsächlich verwendeten Datenverzeichnis des konfigurierten Gateways ermittelt.
 
-Das Modell erhält KNX-Lese-/Schreiboperationen, Kamera-Adapter, TTS-Ansagen und persistenten Speicher 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, Adapterverfügbarkeit und Sicherheitsgrenzen; KNX-Schreibvorgänge behalten die lokale ETS-/DPT-Prüfung und die konfigurierte Bestätigung.
+Das Modell erhält KNX-Lese-/Schreiboperationen, Kamera-Adapter, TTS-Ansagen und persistenten Speicher 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.
 
 ### 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.
@@ -127,10 +148,15 @@ Hier sind alle Felder aufgeführt, wie sie im KNX-AI-Editor sichtbar sind.
 - **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.
+- **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.
+- **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.
 - **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-Vorlage**: Standardmäßig ist **Kein Adapter** gewählt. Die Auswahl lädt das vordefinierte Paar aus Ein- und Ausgangszuordnung; beide bleiben im Editor verborgen.
+- **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**: Verbindliche, ausschließlich vom Benutzer verwaltete Hinweise, die die KI lesen, aber nie ändern darf. Nur hier werden proaktive Benachrichtigungen mit Bedingungen, Dauer, Ruhezeiten und Wiederholung angefordert.
 - 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.

package/nodes/locales/de/knxUltimateAI.json

@@ -4,12 +4,14 @@
     "sections": {
       "groupAssistant": "KI-Assistent",
       "groupChatHome": "Gespräche & Zuhause",
-      "detectedAdapters": "Automatisch erkannte Adapter",
+      "setupDoctor": "Setup Doctor",
+      "webIntelligence": "Web-Intelligenz",
+      "detectedAdapters": "Erkannte und im Chat verwendete kompatible Nodes",
       "chatContextOverview": "Übersicht des Chat-Kontexts",
       "chatLearning": "KI-Chat-Lernen",
       "quickSetup": "Assistent einrichten",
       "llmConnection": "KI-Assistent-Verbindung",
-      "chatAdapter": "Chat-Kanäle",
+      "chatAdapter": "Chat-Pins für Ein- und Ausgang",
       "homeIntelligence": "KI-Erziehung & Gedächtnis",
       "advanced": "Anbieter & Grenzen"
     },
@@ -27,10 +29,13 @@
       "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",
-      "chatAdapterPreset": "Adapter-Vorlage",
+      "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)",
-      "ttsUltimateNodeId": "TTS-Ultimate-Node für Ansagen",
       "aiEducation": "KI-Erziehung (vom Benutzer verwaltet)",
       "llmIncludeDocsSnippets": "Include documentation snippets (help/README/examples)"
     },
@@ -38,7 +43,8 @@
       "summary": "Zusammenfassung/Statistik",
       "anomalies": "Anomalien",
       "assistant": "KI-Assistent",
-      "knxCommands": "KNX-Operationen"
+      "knxCommands": "KNX-Operationen",
+      "ttsUltimate": "TTS-Ultimate-Ansagen"
     },
     "selectlists": {
       "llmProvider": {
@@ -55,9 +61,13 @@
       "chatAdapter": {
         "none": "Kein Adapter"
       },
-      "ttsUltimate": {
-        "select": "TTS-Ultimate-Node auswählen",
-        "none": "Kein TTS-Ultimate-Node gefunden"
+      "webProactiveInterval": {
+        "5": "5 Minuten",
+        "10": "10 Minuten",
+        "15": "15 Minuten",
+        "30": "30 Minuten",
+        "60": "1 Stunde",
+        "180": "3 Stunden"
       }
     },
     "placeholder": {
@@ -68,6 +78,18 @@
       "aiEducation": "Beispiel: Benachrichtige meinen letzten Chat, wenn ein Fenster 30 Minuten offen bleibt. Zwischen 23:00 und 07:00 keine Meldungen."
     },
     "messages": {
+      "setupDoctorLoading": "Diese Installation wird analysiert…",
+      "setupDoctorUnavailable": "Setup Doctor ist vorübergehend nicht verfügbar.",
+      "setupDoctorPromptsTitle": "Installation ausprobieren",
+      "setupDoctorPromptsHint": "Jeder Vorschlag öffnet den Web-Assistenten mit einer personalisierten, sicheren Anfrage. Nichts wird automatisch ausgeführt.",
+      "setupDoctorDeployHint": "Setup Doctor liest den zuletzt bereitgestellten Flow. Änderungen bereitstellen und danach erneut prüfen.",
+      "setupDoctorPass": "OK",
+      "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.",
       "lmStudioContextAvailable": "Maximaler Modellkontext",
       "lmStudioContextLoading": "Aktiver Modellkontext wird geprüft",
       "lmStudioContextInactive": "Modell inaktiv; bei der ersten Anfrage werden die Bionic-Standardwerte verwendet",
@@ -83,16 +105,13 @@
       "installOllamaModelFailed": "Failed to install Ollama model",
       "ollamaInstallSteps": "1) Open the model library and copy the model name (for example llama3.1). 2) Put the name in the Model field and click Install it.",
       "ollamaStartedAuto": "Ollama server started automatically.",
-      "detectedAdaptersLoading": "Installierte Adapter werden erkannt…",
-      "detectedAdaptersNone": "Kein automatischer Adapter erkannt.",
-      "detectedAdaptersUnavailable": "Die automatische Adaptererkennung ist vorübergehend nicht verfügbar.",
+      "detectedAdaptersLoading": "Installierte kompatible Nodes werden erkannt…",
+      "detectedAdaptersNone": "Kein kompatibler Node erkannt.",
+      "detectedAdaptersUnavailable": "Die Erkennung kompatibler Nodes ist vorübergehend nicht verfügbar.",
       "detectedAdapterDetected": "Erkannt",
       "detectedAdapterControllers": "Controller",
       "detectedAdapterCameras": "Kameras",
       "detectedAdapterNodes": "Nodes",
-      "ttsUltimateUnknownFlow": "Flow ohne Namen",
-      "ttsUltimateUnavailable": "TTS-Ultimate-Node nicht verfügbar",
-      "ttsUltimateHint": "Explizite Ansagen aus dem Chat werden direkt an den ausgewählten Node gesendet; eine Flow-Verkabelung ist nicht erforderlich.",
       "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.",
@@ -113,7 +132,6 @@
       "chatContextSourceEtsProject": "ETS-Semantik und vollständiges Inventar des Node-RED-Projekts.",
       "chatContextSourceMemoryEducation": "Sitzungskontext, KI-Erziehung und begrenztes Hausgedächtnis.",
       "chatContextSourceCameras": "Erkannte Kameras und ihre verfügbaren Funktionen.",
-      "chatContextSourceTtsUltimate": "Ausgewählter TTS-Ultimate-Node für Ansagen.",
       "chatContextSourceBadge": "Quelle",
       "chatContextFileChatContext": "Dauerhafte Gesprächsverläufe, Anweisungen und Regeln für Kamerabenachrichtigungen.",
       "chatContextFileHomeMemory": "KI-Erziehung und begrenztes gelerntes Hausgedächtnis.",
@@ -179,6 +197,7 @@
       }
     },
     "buttons": {
+      "refreshSetupDoctor": "Erneut prüfen",
       "installOllamaModel": "2) Install it",
       "ollamaLibrary": "Model library",
       "downloadOllamaModel": "1) Download model",

package/nodes/locales/de/knxUltimateIoTBridge.html

@@ -45,7 +45,8 @@ Der Rest dieser Hilfe beschreibt den klassischen **IoT-Bridge**-Modus.
 ## Zuordnungsfelder
 
 - **Richtung** — wählen Sie KNX→IoT, IoT→KNX oder bidirektional.
-- **Kanaltyp** — MQTT verwendet das Target als Topic, REST als Basis-URL, Modbus als Registerkennung.
+- **Kanaltyp** — MQTT verwendet das Target als Topic, REST als Basis-URL; bei Modbus ist **Target** die nullbasierte Protokolladresse (0–65535).
+- **Modbus-Format / Unit-ID / Bereich / Datentyp** — wählen Sie für neue Zuordnungen **Mit Flex Write kompatibel** und danach Einheit, Speicherbereich sowie `bool`, `uint16` oder `int16`. Fehlt das Format, bleibt der alte Skalarvertrag aktiv, damit bestehende Flows weiter funktionieren.
 - **Skalierung & Offset** — werden für KNX→IoT angewandt; IoT→KNX nutzt die inverse Transformation.
 - **Template** — optionale Zeichenkette mit Platzhaltern `{{value}}`, `{{ga}}`, `{{label}}`, `{{target}}`, `{{type}}`, `{{isoTimestamp}}`.
 - **Timeout / Wiederholungen** — Informationsfelder im Output zur Steuerung von Retries und Zeitfenstern in nachfolgenden Nodes.
@@ -88,7 +89,32 @@ Der Rest dieser Hilfe beschreibt den klassischen **IoT-Bridge**-Modus.
 
 ### Modbus-Register-Sync
 
-- Kombinieren Sie den Bridge mit `modbus-flex-write`-Nodes aus `node-red-contrib-modbus`. Ausgang 1 enthält die Modbus-Adresse in `msg.address` und den Wert in `msg.payload`.
+Die Bridge ist ein Nachrichtenadapter für `node-red-contrib-modbus`; sie öffnet selbst keine TCP-/serielle Verbindung und fragt kein Gerät ab. Installieren Sie eine mit Ihrer Node-RED-Laufzeit kompatible Paketversion und verwenden Sie dann dessen Client- und Transport-Nodes.
+
+|Bereich|Lesen|Schreiben|Zulässige Richtung|
+|--|--|--|--|
+| Coil | FC1 | FC5 | Beide Richtungen |
+| Discrete Input | FC2 | — | Nur Modbus → KNX |
+| Holding Register | FC3 | FC6 | Beide Richtungen |
+| Input Register | FC4 | — | Nur Modbus → KNX |
+
+Wählen Sie bei einer neuen Zuordnung `Format = Mit Flex Write kompatibel`. Für KNX → Modbus kann Ausgang 1 direkt mit einem `modbus-flex-write`-Node verbunden werden und gibt Folgendes aus:
+
+```
+msg.payload = {
+  value: 215,
+  fc: 6,
+  unitid: 1,
+  address: 9,
+  quantity: 1
+}
+```
+
+`address` ist immer nullbasiert: bezeichnet ein Gerätehandbuch ein Holding Register als `40010`, lautet seine Protokolladresse üblicherweise `9`; prüfen Sie die Konvention des Handbuchs. Die Bridge unterstützt pro Zuordnung ein Bit oder ein einzelnes 16-Bit-Register. Mehrere Wörter, 32-Bit-/Float-Werte und Byte-/Wortreihenfolge werden derzeit nicht verarbeitet.
+
+Für Modbus → KNX verbinden Sie den Datenausgang eines `modbus-flex-getter`- oder `modbus-read`-Nodes mit dem Eingang der Bridge. Flex Getter stellt die Anfrage (`fc`, `unitid`, `address`, `quantity`) in `msg.modbusRequest` bereit; Modbus Read behält sie in `msg.input.payload`. Das zurückgegebene Werte-Array kann in `msg.payload` oder `msg.values` liegen. Die Bridge unterstützt beide Nachrichtenformen, ordnet alle von der Antwort abgedeckten Flex-Zuordnungen zu und verwendet das passende Array-Element. Aktivieren Sie **Keep Msg Properties** am Flex Getter. Skalierung und Offset folgen `raw = KNX × Skalierung + Offset`; eingehend wird die inverse Umrechnung angewendet.
+
+`KNX-Werte beim Deploy lesen` liest nur KNX; planen Sie Modbus-Lesevorgänge im externen Modbus-Flow. Legacy-Zuordnungen (einschließlich solcher ohne `modbusMessageFormat`) geben weiterhin den bisherigen skalaren Payload mit `msg.address`/`msg.modbusFunction` auf oberster Ebene aus.
 
 ## Beispiel-Flow
 

package/nodes/locales/de/knxUltimateIoTBridge.json

@@ -79,6 +79,10 @@
       "target": "Ziel",
       "method": "HTTP-Methode",
       "modbusFunction": "Modbus-Funktion",
+      "modbusMessageFormat": "Modbus-Nachrichtenformat",
+      "modbusUnitId": "Unit-ID",
+      "modbusArea": "Modbus-Bereich",
+      "modbusDataType": "Datentyp",
       "scale": "Skalierung",
       "offset": "Offset",
       "timeout": "Zeitüberschreitung (ms)",
@@ -103,7 +107,7 @@
       "target": "Topic, URL oder Register",
       "target_mqtt": "Topic, z. B. knx/light/living",
       "target_rest": "https://example/api/endpoint",
-      "target_modbus": "Register (z. B. 40001)",
+      "target_modbus": "Nullbasierte Adresse (z. B. 0)",
       "template": "{\"value\":{{value}}}",
       "property": "Optionale Eigenschaft/Pfad",
       "method": "POST",
@@ -114,7 +118,7 @@
         "default": "Ziel",
         "mqtt": "MQTT-Topic",
         "rest": "REST-URL",
-        "modbus": "Modbus-Register"
+        "modbus": "Modbus-Adresse (nullbasiert)"
       },
       "method": {
         "default": "HTTP-Methode",
@@ -125,6 +129,20 @@
         "modbus": "Modbus-Funktion"
       }
     },
+    "modbus": {
+      "formatLegacy": "Legacy-Skalar-Nachricht",
+      "formatFlex": "Mit Flex Write kompatibel",
+      "areaCoil": "Coil (FC1 lesen / FC5 schreiben)",
+      "areaDiscreteInput": "Discrete Input (FC2 lesen, schreibgeschützt)",
+      "areaHoldingRegister": "Holding Register (FC3 lesen / FC6 schreiben)",
+      "areaInputRegister": "Input Register (FC4 lesen, schreibgeschützt)",
+      "dataTypeBool": "Boolesch",
+      "dataTypeUint16": "16 Bit ohne Vorzeichen",
+      "dataTypeInt16": "16 Bit mit Vorzeichen",
+      "zeroBasedHint": "Verwende die nullbasierte Protokolladresse (0–65535), nicht die in manchen Handbüchern angegebene 4xxxx-Referenz.",
+      "flexHint": "Flex gibt msg.payload = {value,fc,unitid,address,quantity} zur direkten Verbindung mit modbus-flex-write aus.",
+      "readOnlyHint": "Discrete Inputs und Input Register sind schreibgeschützt und können nur Modbus → KNX verwenden."
+    },
     "labels": {
       "outputKnxToIoT": "Strom KNX → IoT",
       "outputIoTToKnx": "Bestätigungen IoT → KNX",

package/nodes/locales/en/knxUltimateAI.html

@@ -1,16 +1,33 @@
 <script type="text/markdown" data-help-name="knxUltimateAI">
 This node listens to **all KNX telegrams** from the selected KNX Ultimate gateway, builds traffic statistics, detects anomalies, and can optionally query an LLM.
 
-The editor uses two horizontal tabs: **AI assistant** contains setup, knowledge/context and provider limits; **Conversations & home** contains chat channels, proactive home and bounded memory.
+The editor uses two horizontal tabs: **AI assistant** contains setup, knowledge/context and provider limits; **Conversations & home** contains chat input/output pins, proactive home and bounded memory.
 
 ## Outputs
 1. **Summary/Stats** (`msg.payload` JSON)
 2. **Anomalies** (`msg.payload` JSON)
 3. **AI Assistant** (`msg.payload` text, with `msg.summary`)
 4. **KNX operations** (one Universal Mode message per validated read or write)
+5. **TTS Ultimate** (one announcement message per model-selected spoken message)
 
 Every message emitted by outputs 3 and 4 also contains a clone of the original input message in `msg.inputMessage`. This preserves the original payload, topic, chat metadata, and any other input properties for downstream nodes. Cloning and output errors are contained and reported instead of escaping into the Node-RED runtime.
 
+### Setup Doctor and safe first run
+The automatic **Setup Doctor** checks the selected gateway and ETS import, AI enablement, provider, model and API key, provider reachability, flow wiring, detected cameras and the optional TTS Ultimate connection. Its no-cost provider preflight calls only the provider's model-list endpoint: it never sends a chat request or consumes inference tokens. Cameras and TTS are optional, so leaving them unused does not reduce core readiness.
+
+The inventory reports the exact number of unique KNX group-address signals, the ETS areas/groups and an approximate number of logical functions. It deliberately does not claim a physical-device count, because that cannot be derived reliably from the ETS CSV. Setup Doctor reads the last deployed flow, so deploy provider, model, preset, gateway or wiring changes before clicking **Refresh** to repeat the checks.
+
+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.
+
+**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.
+
+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.
+
+After verified Web results are available, the model may compose other enabled tools when authorized by the current chat or AI Education. Web access never expands permissions: camera, TTS and memory availability, as well as KNX reads and writes, local ETS/DPT validation and the configured KNX write confirmation, remain unchanged. Web requests expose the query and this server's public IP to external sites or the search service; KNX/ETS data, camera content, chat identifiers, learned memory and credentials are never added automatically.
+
 ## Commands (input)
 Send `msg.topic`:
 - `summary` (or empty): emit summary immediately
@@ -43,11 +60,15 @@ Requests such as “I’m leaving”, “Good night”, or “Cinema mode” can
 ### Confirmation request for chat buttons
 While a plan is pending, output 3 contains `msg.knxAi.confirmationRequest`. The object includes `required`, `status`, `sessionId`, `expiresAt`, `commandCount`, and two entries in `actions`. Use `action.label` as the Telegram button text, `action.callbackData` as its callback, and send `action.message` back to KNX AI to confirm or cancel without typed text.
 
-### Chat adapter presets
-The **Chat adapters** tab loads its selectable mappings from `resources/KNXAIChatAdapterMappings.js`. Selecting a preset installs two predefined synchronous JavaScript mappings internally: one before KNX AI processes an input and one before output 3 is emitted. The mappings remain hidden in the editor. Syntax and execution failures are caught and reported without stopping Node-RED.
+### Input/output message adapters
+The **Chat input and output pins** section loads its selectable mappings from `resources/KNXAIChatAdapterMappings.js`. Selecting an adapter installs two predefined synchronous JavaScript mappings internally: one before KNX AI processes an input and one before output 3 is emitted. The mappings remain hidden in the editor. Syntax and execution failures are caught and reported without stopping Node-RED.
 
 The included **windkh/node-red-contrib-telegrambot** preset follows the package's receiver/sender contract. Connect a `telegram receiver` directly to KNX AI and output 3 directly to a `telegram sender`. Confirmation uses a one-time Telegram reply keyboard: clicking **Confirm** or **Cancel** returns a normal localized message through the same receiver, so no `telegram event` or callback wiring is required. Legacy `callback_query` messages remain accepted. The input mapping extracts `msg.payload.content`, `msg.payload.chatId`, and the Telegram language. The output mapping creates the required `msg.payload.chatId`, `type`, and `content`, adding `options.reply_markup` from `msg.knxAi.confirmationRequest` when writes await confirmation. The Telegram package remains a separate optional dependency.
 
+With this preset, a Telegram voice message (`msg.payload.type = "voice"`) is handled automatically only when **Provider** is set to **OpenAI-compatible**. KNX AI verifies the provider before downloading anything, reuses its configured **Endpoint URL** and **API key**, and derives `/audio/transcriptions` and `/audio/speech` from that same connection. The token-bearing `msg.payload.weblink` is used only for the bounded download and is removed before the message reaches outputs or the LLM. OGG/Opus input is transcribed with the built-in `gpt-4o-mini-transcribe` default; a successful request receives a native Telegram OGG/Opus reply generated with `gpt-4o-mini-tts` and `alloy`, while the text caption and any confirmation keyboard are preserved. If another provider is selected, the user receives a localized instruction to select OpenAI-compatible or send text. If synthesis is unavailable, fails, or exceeds the speech limit, the complete answer is sent as text. The downloaded audio and generated reply text are sent to the same selected provider. Text messages, photos, and older saved Telegram mappings remain compatible.
+
+Every native voice caption begins with a localized **AI-generated voice** disclosure for the Telegram recipient.
+
 The included **RedBot / node-red-contrib-chatbot (Telegram)** preset follows RedBot's common message contract. Connect `chatbot-telegram-receive` directly to KNX AI and output 3 directly to `chatbot-telegram-send`; no separate callback node is needed because RedBot converts inline-button postbacks into normal inbound messages. The input mapping reads `transport`, `chatId`, `type`, `content`, and the Telegram language. The output mapping preserves RedBot's `originalMessage`, `chat`, `api`, and `client` tracking data, then emits either a `message` payload or an `inline-buttons` payload containing `postback` actions for confirmation. RedBot remains a separate optional dependency.
 
 ### Automatically detected camera adapters
@@ -58,14 +79,14 @@ The user can ask for a current snapshot or ask the vision model what is visible.
 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.
 
 ### TTS Ultimate announcements
-When the optional `node-red-contrib-tts-ultimate` package is installed, it appears among the automatically detected adapters. The selector lists every `ttsultimate` node in all project flows, with its flow, node name and configured player. Choose the node that must handle chat announcements and deploy the flow.
+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.
 
-The model decides whether to use this adapter 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. KNX AI sends the chosen text directly to the selected node as `msg.payload`, with `msg.topic = "knx_ai_announcement"`; no intermediate flow wiring is required. TTS Ultimate then handles the configured Sonos player, voice, volume, hailing and queue.
+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 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 KNX telegram and adapter-event archive directories and the `YYYY-MM-DD.knxctx` daily-file pattern.
 
-The model receives KNX read/write operations, camera adapters, TTS announcements and persistent memory 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, adapter availability and safety boundaries; KNX writes still use local ETS/DPT validation and the configured confirmation step.
+The model receives KNX read/write operations, camera adapters, TTS announcements and persistent memory 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.
 
 ### 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.
@@ -133,10 +154,15 @@ All fields exposed in the KNX AI editor are listed below.
 - **Endpoint URL**: Chat/completions endpoint URL.
 - **API key**: API key (not required for local Ollama; optional for Bionic LM Studio unless server authentication is enabled).
 - **Model**: Model ID/name.
+- **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.
+- **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.
 - **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.
-- **Adapter preset**: Defaults to **No adapter**. Selecting a preset loads its predefined input/output mapping pair; both mappings remain hidden in the editor.
+- **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**: User-only, authoritative guidance read by the AI and never modified by it. It is also the sole place to request proactive notifications and define their conditions, duration, quiet hours and repetition.
 - Packaged help, README, changelog, wiki and example snippets are not included in Telegram, RedBot or custom CHAT prompts. They remain available only to the web Assistant for package-support questions.
 - **Refresh** button: Queries the provider and loads available model IDs. Its icon spins while loading; successful completion is intentionally silent.

package/nodes/locales/en/knxUltimateAI.json

@@ -4,12 +4,14 @@
     "sections": {
       "groupAssistant": "AI assistant",
       "groupChatHome": "Conversations & home",
-      "detectedAdapters": "Automatically detected adapters",
+      "setupDoctor": "Setup Doctor",
+      "webIntelligence": "Web intelligence",
+      "detectedAdapters": "Compatible nodes detected and used in chat",
       "chatContextOverview": "Chat context overview",
       "chatLearning": "AI Chat Learning",
       "quickSetup": "Assistant setup",
       "llmConnection": "AI Assistant Connection",
-      "chatAdapter": "Chat channels",
+      "chatAdapter": "Chat input and output pins",
       "homeIntelligence": "AI Education & memory",
       "advanced": "Provider & limits"
     },
@@ -27,10 +29,13 @@
       "llmIncludeRaw": "Include raw payload hex",
       "llmAllowKnxCommands": "Allow AI to read KNX states and control actuators",
       "llmRequireCommandConfirmation": "Ask for confirmation before sending KNX commands",
-      "chatAdapterPreset": "Adapter preset",
+      "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)",
-      "ttsUltimateNodeId": "TTS Ultimate announcement node",
       "aiEducation": "AI Education (user managed)",
       "llmIncludeDocsSnippets": "Include documentation snippets (help/README/examples)"
     },
@@ -38,7 +43,8 @@
       "summary": "Summary/Stats",
       "anomalies": "Anomalies",
       "assistant": "AI Assistant",
-      "knxCommands": "KNX operations"
+      "knxCommands": "KNX operations",
+      "ttsUltimate": "TTS Ultimate announcements"
     },
     "selectlists": {
       "llmProvider": {
@@ -55,12 +61,17 @@
       "chatAdapter": {
         "none": "No adapter"
       },
-      "ttsUltimate": {
-        "select": "Select a TTS Ultimate node",
-        "none": "No TTS Ultimate node found"
+      "webProactiveInterval": {
+        "5": "5 minutes",
+        "10": "10 minutes",
+        "15": "15 minutes",
+        "30": "30 minutes",
+        "60": "1 hour",
+        "180": "3 hours"
       }
     },
     "buttons": {
+      "refreshSetupDoctor": "Check again",
       "refreshModels": "Refresh",
       "installOllamaModel": "2) Install it",
       "ollamaLibrary": "Model library",
@@ -68,6 +79,18 @@
       "openChatLearning": "Open AI Chat Learning"
     },
     "messages": {
+      "setupDoctorLoading": "Analyzing this installation…",
+      "setupDoctorUnavailable": "Setup Doctor is temporarily unavailable.",
+      "setupDoctorPromptsTitle": "Try your installation",
+      "setupDoctorPromptsHint": "Each suggestion opens the Web Assistant with a personalized, safe prompt. Nothing is executed automatically.",
+      "setupDoctorDeployHint": "Setup Doctor reads the last deployed flow. Deploy editor changes, then check again.",
+      "setupDoctorPass": "OK",
+      "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.",
       "loadingModels": "Loading models…",
       "loadedModels": "Models loaded",
       "lmStudioContextAvailable": "Maximum model context",
@@ -85,16 +108,13 @@
       "installOllamaModelFailed": "Failed to install Ollama model",
       "ollamaInstallSteps": "1) Open the model library and copy the model name (for example llama3.1). 2) Put the name in the Model field and click Install it.",
       "ollamaStartedAuto": "Ollama server started automatically.",
-      "detectedAdaptersLoading": "Detecting installed adapters…",
-      "detectedAdaptersNone": "No automatic adapter detected.",
-      "detectedAdaptersUnavailable": "Automatic adapter detection is temporarily unavailable.",
+      "detectedAdaptersLoading": "Detecting installed compatible nodes…",
+      "detectedAdaptersNone": "No compatible node detected.",
+      "detectedAdaptersUnavailable": "Compatible-node detection is temporarily unavailable.",
       "detectedAdapterDetected": "Detected",
       "detectedAdapterControllers": "Controllers",
       "detectedAdapterCameras": "Cameras",
       "detectedAdapterNodes": "Nodes",
-      "ttsUltimateUnknownFlow": "Flow without name",
-      "ttsUltimateUnavailable": "Unavailable TTS Ultimate node",
-      "ttsUltimateHint": "Explicit chat announcement requests are sent directly to the selected node; no flow wiring is required.",
       "chatContextLoading": "Loading chat context summary…",
       "chatContextUnavailable": "The chat context summary is temporarily unavailable.",
       "chatLearningOpenHint": "Open the Web UI directly on the shared CHAT learning editor to view, edit, copy or back up its persistent file.",
@@ -115,7 +135,6 @@
       "chatContextSourceEtsProject": "ETS semantics and the full Node-RED project inventory.",
       "chatContextSourceMemoryEducation": "Session context, AI Education and bounded home memory.",
       "chatContextSourceCameras": "Detected cameras and their available capabilities.",
-      "chatContextSourceTtsUltimate": "Selected TTS Ultimate announcement target.",
       "chatContextSourceBadge": "Source",
       "chatContextFileChatContext": "Persistent conversation turns, instructions and camera notification rules.",
       "chatContextFileHomeMemory": "AI Education and bounded learned home memory.",

package/nodes/locales/en/knxUltimateIoTBridge.html

@@ -45,7 +45,8 @@ The rest of this help describes the classic **IoT bridge** mode.
 ## Mapping Fields
 
 - **Direction** — choose KNX→IoT, IoT→KNX or bidirectional.
-- **Channel type** — MQTT uses the target as topic; REST uses it as the base URL; Modbus expects a register identifier.
+- **Channel type** — MQTT uses the target as topic; REST uses it as the base URL; for Modbus, **Target** is the zero-based protocol address (0–65535).
+- **Modbus format / Unit ID / Area / Data type** — choose **Flex Write compatible** for new mappings, then select the unit, memory area and `bool`, `uint16` or `int16`. A missing format remains the legacy scalar contract so existing flows keep working.
 - **Scale & Offset** — applied to KNX→IoT; IoT→KNX applies the inverse transform.
 - **Template** — optional string replacing `{{value}}`, `{{ga}}`, `{{label}}`, `{{target}}`, `{{type}}`, `{{isoTimestamp}}`.
 - **Timeout / Retries** — informational fields exposed in the emitted message for downstream nodes to act on.
@@ -88,7 +89,32 @@ The rest of this help describes the classic **IoT bridge** mode.
 
 ### Modbus register sync
 
-- Pair the MQTT - IoT with `node-red-contrib-modbus` `modbus-flex-write` nodes. Output 1 carries the Modbus address in `msg.address` and the value in `msg.payload`.
+The bridge is a message adapter for `node-red-contrib-modbus`; it does not open a TCP/serial connection and does not poll a device. Install a version of that package compatible with your Node-RED runtime, then use its client and transport nodes.
+
+|Area|Read|Write|Allowed direction|
+|--|--|--|--|
+| Coil | FC1 | FC5 | Either direction |
+| Discrete input | FC2 | — | Modbus → KNX only |
+| Holding register | FC3 | FC6 | Either direction |
+| Input register | FC4 | — | Modbus → KNX only |
+
+For a new mapping select `Format = Flex Write compatible`. On KNX → Modbus, Output 1 can be wired directly to a `modbus-flex-write` node and emits:
+
+```
+msg.payload = {
+  value: 215,
+  fc: 6,
+  unitid: 1,
+  address: 9,
+  quantity: 1
+}
+```
+
+`address` is always zero-based: if a device manual labels a holding register as `40010`, its protocol address is commonly `9`; verify the convention in that manual. The bridge supports one bit or one 16-bit register per mapping. It does not currently combine words, decode 32-bit/float values or manage byte/word order.
+
+For Modbus → KNX, wire the data output of a `modbus-flex-getter` or `modbus-read` node to the bridge input. A Flex Getter provides the request (`fc`, `unitid`, `address`, `quantity`) in `msg.modbusRequest`; a Modbus Read node preserves it in `msg.input.payload`. The returned values array may be in `msg.payload` or `msg.values`. The bridge supports both message shapes, matches every Flex mapping covered by the response and uses the appropriate array element. Enable **Keep Msg Properties** on Flex Getter. Scale and offset are applied as `raw = KNX × scale + offset`; the incoming path applies the inverse transformation.
+
+`Read KNX values on deploy` reads KNX only; schedule Modbus reads in the external Modbus flow. Legacy mappings (including mappings without `modbusMessageFormat`) continue to emit the previous scalar payload plus top-level `msg.address`/`msg.modbusFunction` metadata.
 
 ## Sample Flow