node-red-contrib-knx-ultimate 6.3.22 → 6.3.24
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/CHANGELOG.md +14 -0
- package/examples/KNX AI - Telegrambot Direct Chat.json +1 -17
- package/nodes/knxUltimateAI.html +142 -15
- package/nodes/knxUltimateAI.js +734 -163
- package/nodes/locales/de/knxUltimateAI.html +26 -8
- package/nodes/locales/de/knxUltimateAI.json +11 -1
- package/nodes/locales/en/knxUltimateAI.html +26 -8
- package/nodes/locales/en/knxUltimateAI.json +11 -1
- package/nodes/locales/es/knxUltimateAI.html +26 -8
- package/nodes/locales/es/knxUltimateAI.json +11 -1
- package/nodes/locales/fr/knxUltimateAI.html +26 -8
- package/nodes/locales/fr/knxUltimateAI.json +11 -1
- package/nodes/locales/it/knxUltimateAI.html +26 -8
- package/nodes/locales/it/knxUltimateAI.json +11 -1
- package/nodes/locales/zh-CN/knxUltimateAI.html +26 -8
- package/nodes/locales/zh-CN/knxUltimateAI.json +11 -1
- package/nodes/plugins/knxUltimateAI-vue/assets/app.css +1 -1
- package/nodes/plugins/knxUltimateAI-vue/assets/app.js +4 -4
- package/nodes/utils/knxAiChatContext.js +181 -84
- package/nodes/utils/knxAiEventHistory.js +275 -0
- package/package.json +1 -1
- package/resources/KNXAIChatAdapterMappings.js +14 -12
|
@@ -25,9 +25,13 @@ Dauert die Verarbeitung länger als 1,2 Sekunden, sendet Ausgang 3 sofort die lo
|
|
|
25
25
|
|
|
26
26
|
Anfragen an Ollama und Bionic LM Studio verwenden automatisch ein Mindest-Timeout von 10 Minuten; Cloud-Anbieter behalten mindestens 2 Minuten. Im Editor muss kein Timeout-Feld gepflegt werden. Wird selbst das lokale Limit erreicht, meldet KNX AI, dass das Modell die Antwort nicht abgeschlossen hat, und empfiehlt einen neuen Versuch oder einen kleineren Prompt-Kontext.
|
|
27
27
|
|
|
28
|
+
Für lokale Anbieter lässt sich mit **Chat-Kontextmenge** ausdrücklich zwischen 4K, 8K und 16K wählen; 16K bleibt der Standard. Die Auswahl begrenzt KNX-, Speicher-, Node-RED-Projekt- und Adapterdaten proportional, während der vollständige Werkzeugvertrag des Agenten erhalten bleibt. Fähigkeiten werden niemals anhand von Formulierungen, Schlüsselwörtern oder sprachlichen Intents aktiviert oder deaktiviert.
|
|
29
|
+
|
|
28
30
|
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.
|
|
29
31
|
|
|
30
|
-
Jede Ask-/Chat-Sitzung speichert ihre letzten 8 Gesprächsschritte und bis zu 20
|
|
32
|
+
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"`.
|
|
33
|
+
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.
|
|
34
|
+
|
|
31
35
|
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.
|
|
32
36
|
|
|
33
37
|
### Aktuelle KNX-Lesewerte
|
|
@@ -42,24 +46,38 @@ Solange ein Plan aussteht, enthält Ausgang 3 `msg.knxAi.confirmationRequest`. D
|
|
|
42
46
|
### Chat-Adapter-Vorlagen
|
|
43
47
|
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.
|
|
44
48
|
|
|
45
|
-
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`.
|
|
49
|
+
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.
|
|
46
50
|
|
|
47
51
|
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.
|
|
48
52
|
|
|
49
53
|
### Automatisch erkannte Kamera-Adapter
|
|
50
54
|
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.
|
|
51
55
|
|
|
52
|
-
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.
|
|
56
|
+
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.
|
|
53
57
|
|
|
54
|
-
Jedes von einem automatisch erkannten Adapter veröffentlichte Ereignis wird normalisiert und in eine tägliche Datei `YYYY-MM-DD.
|
|
58
|
+
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.
|
|
55
59
|
|
|
56
60
|
### Ansagen mit TTS Ultimate
|
|
57
61
|
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.
|
|
58
62
|
|
|
59
|
-
|
|
63
|
+
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.
|
|
60
64
|
|
|
61
65
|
### Übersicht des Chat-Kontexts
|
|
62
|
-
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 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.
|
|
66
|
+
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.
|
|
67
|
+
|
|
68
|
+
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.
|
|
69
|
+
|
|
70
|
+
### CHAT-Lernen bearbeiten und sichern
|
|
71
|
+
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.
|
|
72
|
+
|
|
73
|
+
Ö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.
|
|
74
|
+
|
|
75
|
+
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.
|
|
76
|
+
|
|
77
|
+
### Gelernte Rollen für KNX-Gruppenadressen
|
|
78
|
+
Die Rolle `neutral` bedeutet anfängliche Ungewissheit und kein dauerhaftes Steuerungsverbot. Das Modell kann mit dem strukturierten Werkzeug `gaRoleActions` aus verbindlichen Hinweisen des Benutzers, persistenten Chat-Vorgaben, der KI-Erziehung oder einer eindeutigen ETS-Projektsemantik lernen, dass eine exakte ETS-Gruppenadresse ein Befehls-, Status- oder neutrales Objekt ist. Dafür sind weder Schlüsselwörter noch Rollen-Intents nötig; bei mehrdeutigen Belegen fragt das Modell nach, statt zu lernen.
|
|
79
|
+
|
|
80
|
+
Gelernte Rolle, Begründung und Beleg werden pro Node in `<userDir>/knxai/config/knxai-config-<node-id>.json` gespeichert und in das begrenzte semantische Hausgedächtnis synchronisiert. Eine als `command` gelernte Rolle kann bereits in derselben Antwort einen Schreibvorgang validieren und bleibt nach einem Neustart verfügbar; das Modell kann sie auch vergessen und die automatische Klassifizierung wiederherstellen. Das Lernen kann keine GA erfinden, ihren ETS-DPT ändern, die Payload-Prüfung umgehen oder die konfigurierte Schreibbestätigung überspringen.
|
|
63
81
|
|
|
64
82
|
## Durch KI-Erziehung gesteuerte proaktive Hausintelligenz und begrenztes Gedächtnis
|
|
65
83
|
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.
|
|
@@ -125,7 +143,7 @@ Hier sind alle Felder aufgeführt, wie sie im KNX-AI-Editor sichtbar sind.
|
|
|
125
143
|
- **2) Install it**: lädt und installiert das Modell lokal (z. B. `llama3.1`).
|
|
126
144
|
- Beim Refresh/Install versucht KNX AI zusätzlich, den Ollama-Server automatisch zu starten.
|
|
127
145
|
- Bei Installationsfehlern mit Verbindungsproblem prüfen, ob Ollama läuft (Desktop-App oder `ollama serve`).
|
|
128
|
-
- Der von `/api/show` gemeldete maximale Kontext dient nur zur Information. KNX AI sendet
|
|
146
|
+
- Der von `/api/show` gemeldete maximale Kontext dient nur zur Information. KNX AI sendet das gewählte 4K-, 8K- oder 16K-Budget als `num_ctx` (oder das kleinere Modellmaximum) und begrenzt jede Kontextquelle proportional, ohne Agentenfunktionen zu entfernen.
|
|
129
147
|
- Wenn Node-RED in Docker läuft, im Endpoint `host.docker.internal` statt `localhost` verwenden.
|
|
130
148
|
|
|
131
149
|
### Bionic LM Studio Schnellstart (lokal)
|
|
@@ -133,7 +151,7 @@ Hier sind alle Felder aufgeführt, wie sie im KNX-AI-Editor sichtbar sind.
|
|
|
133
151
|
- Den LM-Studio-API-Server auf der Seite **Developer** oder mit `lms server start` starten.
|
|
134
152
|
- Standard-Endpoint: `http://localhost:1234/v1/chat/completions`.
|
|
135
153
|
- Mit **Refresh** alle von `/v1/models` bereitgestellten Modelle laden; ist kein Modell konfiguriert, wird das erste ausgewählt.
|
|
136
|
-
- 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. Unabhängig vom von Bionic gemeldeten Kontext
|
|
154
|
+
- 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. Unabhängig vom von Bionic gemeldeten Kontext verwendet KNX AI das gewählte 4K-, 8K- oder 16K-Prompt-Budget; Denk-, KNX-, Routinen-, Kamera- und TTS-Funktionen bleiben verfügbar.
|
|
137
155
|
- 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.
|
|
138
156
|
|
|
139
157
|
## Sicherheitshinweis
|
|
@@ -6,6 +6,7 @@
|
|
|
6
6
|
"groupChatHome": "Gespräche & Zuhause",
|
|
7
7
|
"detectedAdapters": "Automatisch erkannte Adapter",
|
|
8
8
|
"chatContextOverview": "Übersicht des Chat-Kontexts",
|
|
9
|
+
"chatLearning": "KI-Chat-Lernen",
|
|
9
10
|
"quickSetup": "Assistent einrichten",
|
|
10
11
|
"llmConnection": "KI-Assistent-Verbindung",
|
|
11
12
|
"chatAdapter": "Chat-Kanäle",
|
|
@@ -21,6 +22,7 @@
|
|
|
21
22
|
"llmBaseUrl": "Endpoint URL",
|
|
22
23
|
"llmApiKey": "API key",
|
|
23
24
|
"llmModel": "Model",
|
|
25
|
+
"llmPromptContextTokens": "Chat-Kontextmenge",
|
|
24
26
|
"llmSystemPrompt": "System prompt",
|
|
25
27
|
"llmIncludeRaw": "Include raw payload hex",
|
|
26
28
|
"llmAllowKnxCommands": "KI darf KNX-Zustände lesen und Aktoren steuern",
|
|
@@ -45,6 +47,11 @@
|
|
|
45
47
|
"ollama": "Ollama (lokal)",
|
|
46
48
|
"lmstudio": "Bionic LM Studio"
|
|
47
49
|
},
|
|
50
|
+
"promptContext": {
|
|
51
|
+
"small": "Klein (4K, schneller)",
|
|
52
|
+
"medium": "Mittel (8K)",
|
|
53
|
+
"full": "Vollständig (16K)"
|
|
54
|
+
},
|
|
48
55
|
"chatAdapter": {
|
|
49
56
|
"none": "Kein Adapter"
|
|
50
57
|
},
|
|
@@ -68,6 +75,7 @@
|
|
|
68
75
|
"lmStudioContextFailed": "Der Modellkontext konnte nicht konfiguriert werden",
|
|
69
76
|
"lmStudioContextCurrentlyLoaded": "derzeit geladen",
|
|
70
77
|
"localContextBudget": "KNX-AI-Kontextbudget",
|
|
78
|
+
"promptContextHint": "Steuert die Menge an KNX-, Speicher-, Projekt- und Adapterkontext für lokale Modelle. Werkzeuge werden dadurch weder aktiviert noch deaktiviert; es gibt kein Intent-Routing.",
|
|
71
79
|
"ollamaNotSupported": "Ollama local mode: API key not required. Default endpoint is http://localhost:11434/api/chat.",
|
|
72
80
|
"ollamaNoModels": "No local Ollama model found. Install one or pick one from the library.",
|
|
73
81
|
"installingOllamaModel": "Starting Ollama and installing model…",
|
|
@@ -87,6 +95,7 @@
|
|
|
87
95
|
"ttsUltimateHint": "Explizite Ansagen aus dem Chat werden direkt an den ausgewählten Node gesendet; eine Flow-Verkabelung ist nicht erforderlich.",
|
|
88
96
|
"chatContextLoading": "Zusammenfassung des Chat-Kontexts wird geladen…",
|
|
89
97
|
"chatContextUnavailable": "Die Zusammenfassung des Chat-Kontexts ist vorübergehend nicht verfügbar.",
|
|
98
|
+
"chatLearningOpenHint": "Öffnet die Weboberfläche direkt im gemeinsamen CHAT-Lerneditor, um die persistente Datei anzuzeigen, zu bearbeiten, zu kopieren oder zu sichern.",
|
|
90
99
|
"chatContextIntro": "Der Chat erhält diese Quellen automatisch. Die folgenden Pfade werden von dieser Node-RED-Installation tatsächlich verwendet.",
|
|
91
100
|
"chatContextLimitLabel": "Maximaler operativer Kontext",
|
|
92
101
|
"chatContextProviderManaged": "vom ausgewählten Anbieter/Modell verwaltet",
|
|
@@ -172,7 +181,8 @@
|
|
|
172
181
|
"buttons": {
|
|
173
182
|
"installOllamaModel": "2) Install it",
|
|
174
183
|
"ollamaLibrary": "Model library",
|
|
175
|
-
"downloadOllamaModel": "1) Download model"
|
|
184
|
+
"downloadOllamaModel": "1) Download model",
|
|
185
|
+
"openChatLearning": "KI-Chat-Lernen öffnen"
|
|
176
186
|
}
|
|
177
187
|
}
|
|
178
188
|
}
|
|
@@ -25,9 +25,13 @@ If processing takes longer than 1.2 seconds, output 3 emits the localized interm
|
|
|
25
25
|
|
|
26
26
|
Ollama and Bionic LM Studio requests automatically use a minimum timeout of 10 minutes; cloud providers retain a 2-minute minimum. There is no timeout field to maintain in the editor. If even the local limit is reached, KNX AI reports that the model did not finish and suggests retrying or reducing the prompt context.
|
|
27
27
|
|
|
28
|
+
For local providers, **Chat context amount** explicitly selects 4K, 8K or 16K; 16K remains the default. The choice proportionally bounds the KNX, memory, Node-RED project and adapter data supplied to the model while retaining the complete agent tool contract. It never enables or disables a capability from wording, keywords or linguistic intents.
|
|
29
|
+
|
|
28
30
|
The node's canvas status is deliberately reserved for the latest incoming request and the localized “I’m thinking…” state while the LLM is running. KNX telegrams, gateway updates, traffic rates, ready messages and technical results never overwrite it; they remain available through the node outputs, logs and Assistant data.
|
|
29
31
|
|
|
30
|
-
Every Ask/chat session keeps its last 8 turns and up to 20
|
|
32
|
+
Every Ask/chat session keeps its last 8 turns and up to 20 model-selected long-term instructions, separated by `msg.knxAi.sessionId`, `msg.sessionId`, or a detected Telegram chat ID. The model decides semantically when the meaning of a conversation should be remembered or forgotten through the structured memory tool; no language keyword or intent list is used. All KNX AI nodes using the same storage share this live context and reload it after Node-RED restarts from `knxultimatestorage/knxai/memory/knxai-chat-context.knxctx`. The atomically written file is bounded to 50 sessions and 512 KB. When KNX control is enabled, wire output 3 back to the chat sender and output 4 to a KNX Ultimate node configured in **Universal mode**. With confirmation enabled, the first reply previews every write GA, DPT, and payload without emitting writes; the same session must then reply `CONFIRM`/`CANCEL` (localized equivalents are accepted) within 5 minutes. A new request replaces any older pending plan. Each confirmed command has `msg.destination`, `msg.dpt`, `msg.payload`, and `msg.event = "GroupValue_Write"`.
|
|
33
|
+
Recent session memory is placed immediately beside the current request so local models retain user-supplied facts such as a preferred name or language even inside a large KNX prompt. The model may persist durable facts, preferences and instructions through `memoryActions`; this remains a semantic tool choice without phrase classifiers or intent routing. Credentials, security codes and API keys must never be learned.
|
|
34
|
+
|
|
31
35
|
For DPT 1.xxx writes, safe AI equivalents `true`/`false`, `1`/`0`, and `on`/`off` are normalized to a real boolean before local validation and output.
|
|
32
36
|
|
|
33
37
|
### Fresh KNX reads
|
|
@@ -42,24 +46,38 @@ While a plan is pending, output 3 contains `msg.knxAi.confirmationRequest`. The
|
|
|
42
46
|
### Chat adapter presets
|
|
43
47
|
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.
|
|
44
48
|
|
|
45
|
-
The included **windkh/node-red-contrib-telegrambot** preset follows the package's receiver/sender contract. Connect a `telegram receiver` directly to KNX AI
|
|
49
|
+
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.
|
|
46
50
|
|
|
47
51
|
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.
|
|
48
52
|
|
|
49
53
|
### Automatically detected camera adapters
|
|
50
54
|
Installed camera packages can publish a camera adapter to KNX AI at runtime. There is no selector and no camera node to wire to KNX AI: available adapters, controllers and cameras are detected automatically and included in the chat context. `node-red-contrib-unifi-ultimate` is the first supported provider; other packages, such as `hikvision-ultimate`, can register through the same vendor-neutral contract.
|
|
51
55
|
|
|
52
|
-
The user can ask for a current snapshot or ask the vision model what is visible. Telegram and RedBot presets emit the returned image as a native photo with a caption. The user can also create persistent notifications for motion, a smart line crossing or entry into an intrusion/loiter zone, optionally limited to detected people and to an exact named line or zone. These rules are stored in the same `knxai-chat-context.
|
|
56
|
+
The user can ask for a current snapshot or ask the vision model what is visible. Telegram and RedBot presets emit the returned image as a native photo with a caption. The user can also create persistent notifications for motion, a smart line crossing or entry into an intrusion/loiter zone, optionally limited to detected people and to an exact named line or zone. These rules are stored in the same `knxai-chat-context.knxctx` file and are restored after Node-RED restarts. UniFi event subscriptions and snapshot requests are made directly through the detected provider; KNX AI output 4 is not involved and no intermediate flow wiring is required.
|
|
53
57
|
|
|
54
|
-
Every event published by an automatically detected adapter is normalized and appended to a daily `YYYY-MM-DD.
|
|
58
|
+
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.
|
|
55
59
|
|
|
56
60
|
### TTS Ultimate announcements
|
|
57
61
|
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.
|
|
58
62
|
|
|
59
|
-
|
|
63
|
+
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.
|
|
60
64
|
|
|
61
65
|
### Chat context overview
|
|
62
|
-
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 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.
|
|
66
|
+
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.
|
|
67
|
+
|
|
68
|
+
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.
|
|
69
|
+
|
|
70
|
+
### Editing and backing up CHAT learning
|
|
71
|
+
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.
|
|
72
|
+
|
|
73
|
+
In the Vue web UI, open **Settings → AI Chat Learning** to view and edit the exact shared `knxai-chat-context.knxctx` file and its absolute path. The file can be copied, downloaded as a backup or restored from another `.knxctx` file. **Reinitialize Memory**, protected by an explicit confirmation, replaces it with a new empty context and clears saved sessions, instructions, camera watches and pending chat confirmations across every KNX AI node using the same storage. The native tab-separated `KNXAI_CHAT_CONTEXT 3` records are authoritative and directly editable: `SESSION` contains `INSTRUCTION`, `TURN` and `CAMERA_WATCH` records until `END_SESSION`. Saving validates and bounds these records, atomically rewrites the file and updates the live context of every KNX AI node using the same storage. A revision check refuses to overwrite or reset learning that changed after the editor loaded it.
|
|
74
|
+
|
|
75
|
+
Only the native V3 format is supported. Previous Markdown/JSON V2 and Base64 V1 files are deliberately not read, imported or migrated; the old `.md` file is left untouched and KNX AI starts a new `.knxctx` context. The 50-session and 512 KB limits still apply.
|
|
76
|
+
|
|
77
|
+
### Learned KNX group-address roles
|
|
78
|
+
The `neutral` role means initial uncertainty, not a permanent control ban. The model can use the structured `gaRoleActions` tool to learn that an exact ETS group address is a command, status or neutral object from trusted user teaching, persistent chat guidance, AI Education or unequivocal ETS project semantics. There is no required keyword or role intent; if the evidence is ambiguous, the model asks for clarification instead of learning.
|
|
79
|
+
|
|
80
|
+
The learned role, reason and evidence are stored per node in `<userDir>/knxai/config/knxai-config-<node-id>.json` and synchronized into the bounded semantic home memory. A role learned as `command` can validate a write in the same answer and remains available after restart; the model can also forget it and restore automatic classification. Learning never invents a GA, changes its ETS DPT, bypasses payload validation or skips the configured write confirmation.
|
|
63
81
|
|
|
64
82
|
## Education-driven proactive home intelligence and bounded memory
|
|
65
83
|
From ETS hierarchy, names, roles and DPTs, the node builds a deterministic semantic model for covers, windows, doors, lights, temperature, climate, occupancy and alarms using Italian, English, German, French, Spanish and Chinese terms. Its proactive detector watches only reliably recognized non-command cover/window/door states.
|
|
@@ -131,7 +149,7 @@ All fields exposed in the KNX AI editor are listed below.
|
|
|
131
149
|
- **2) Install it**: downloads and installs the model locally (for example `llama3.1`).
|
|
132
150
|
- During model refresh/install, KNX AI also tries to auto-start the Ollama server when possible.
|
|
133
151
|
- If install fails with connection errors, ensure Ollama is running (desktop app or `ollama serve`).
|
|
134
|
-
- The maximum context reported by `/api/show` is informational. KNX AI
|
|
152
|
+
- The maximum context reported by `/api/show` is informational. KNX AI sends the selected 4K, 8K or 16K budget as `num_ctx` (or the model maximum when it is smaller) and proportionally bounds every supplied context source without removing agent capabilities.
|
|
135
153
|
- If Node-RED runs in Docker, use `host.docker.internal` instead of `localhost` in the endpoint URL.
|
|
136
154
|
|
|
137
155
|
### Bionic LM Studio quick setup (local)
|
|
@@ -139,7 +157,7 @@ All fields exposed in the KNX AI editor are listed below.
|
|
|
139
157
|
- Start the LM Studio API server from the **Developer** page or with `lms server start`.
|
|
140
158
|
- Default endpoint: `http://localhost:1234/v1/chat/completions`.
|
|
141
159
|
- Click **Refresh** to load all models exposed by `/v1/models`; the first model is selected when none is configured.
|
|
142
|
-
- When a model is already loaded, KNX AI preserves its active context length. KNX AI never loads an inactive Bionic model through the management API: the first chat request lets Bionic JIT-load it with its saved per-model defaults. Independently of the context reported by Bionic, KNX AI
|
|
160
|
+
- When a model is already loaded, KNX AI preserves its active context length. KNX AI never loads an inactive Bionic model through the management API: the first chat request lets Bionic JIT-load it with its saved per-model defaults. Independently of the context reported by Bionic, KNX AI uses the selected 4K, 8K or 16K prompt budget and keeps reasoning, KNX, routine, camera and TTS capabilities available.
|
|
143
161
|
- An API key is optional unless authentication is enabled in the LM Studio server settings. In Docker, replace `localhost` with `host.docker.internal`.
|
|
144
162
|
|
|
145
163
|
## Security note
|
|
@@ -6,6 +6,7 @@
|
|
|
6
6
|
"groupChatHome": "Conversations & home",
|
|
7
7
|
"detectedAdapters": "Automatically detected adapters",
|
|
8
8
|
"chatContextOverview": "Chat context overview",
|
|
9
|
+
"chatLearning": "AI Chat Learning",
|
|
9
10
|
"quickSetup": "Assistant setup",
|
|
10
11
|
"llmConnection": "AI Assistant Connection",
|
|
11
12
|
"chatAdapter": "Chat channels",
|
|
@@ -21,6 +22,7 @@
|
|
|
21
22
|
"llmBaseUrl": "Endpoint URL",
|
|
22
23
|
"llmApiKey": "API key",
|
|
23
24
|
"llmModel": "Model",
|
|
25
|
+
"llmPromptContextTokens": "Chat context amount",
|
|
24
26
|
"llmSystemPrompt": "System prompt",
|
|
25
27
|
"llmIncludeRaw": "Include raw payload hex",
|
|
26
28
|
"llmAllowKnxCommands": "Allow AI to read KNX states and control actuators",
|
|
@@ -45,6 +47,11 @@
|
|
|
45
47
|
"ollama": "Ollama (local)",
|
|
46
48
|
"lmstudio": "Bionic LM Studio"
|
|
47
49
|
},
|
|
50
|
+
"promptContext": {
|
|
51
|
+
"small": "Small (4K, faster)",
|
|
52
|
+
"medium": "Medium (8K)",
|
|
53
|
+
"full": "Full (16K)"
|
|
54
|
+
},
|
|
48
55
|
"chatAdapter": {
|
|
49
56
|
"none": "No adapter"
|
|
50
57
|
},
|
|
@@ -57,7 +64,8 @@
|
|
|
57
64
|
"refreshModels": "Refresh",
|
|
58
65
|
"installOllamaModel": "2) Install it",
|
|
59
66
|
"ollamaLibrary": "Model library",
|
|
60
|
-
"downloadOllamaModel": "1) Download model"
|
|
67
|
+
"downloadOllamaModel": "1) Download model",
|
|
68
|
+
"openChatLearning": "Open AI Chat Learning"
|
|
61
69
|
},
|
|
62
70
|
"messages": {
|
|
63
71
|
"loadingModels": "Loading models…",
|
|
@@ -69,6 +77,7 @@
|
|
|
69
77
|
"lmStudioContextFailed": "Unable to configure the model context",
|
|
70
78
|
"lmStudioContextCurrentlyLoaded": "currently loaded",
|
|
71
79
|
"localContextBudget": "KNX AI context budget",
|
|
80
|
+
"promptContextHint": "Controls how much KNX, memory, project and adapter context is sent to local models. It does not enable or disable tools and does not use intent routing.",
|
|
72
81
|
"ollamaNotSupported": "Ollama local mode: API key not required. Default endpoint is http://localhost:11434/api/chat.",
|
|
73
82
|
"ollamaNoModels": "No local Ollama model found. Install one or pick one from the library.",
|
|
74
83
|
"installingOllamaModel": "Starting Ollama and installing model…",
|
|
@@ -88,6 +97,7 @@
|
|
|
88
97
|
"ttsUltimateHint": "Explicit chat announcement requests are sent directly to the selected node; no flow wiring is required.",
|
|
89
98
|
"chatContextLoading": "Loading chat context summary…",
|
|
90
99
|
"chatContextUnavailable": "The chat context summary is temporarily unavailable.",
|
|
100
|
+
"chatLearningOpenHint": "Open the Web UI directly on the shared CHAT learning editor to view, edit, copy or back up its persistent file.",
|
|
91
101
|
"chatContextIntro": "The chat automatically receives these sources. The paths below are the actual paths used by this Node-RED installation.",
|
|
92
102
|
"chatContextLimitLabel": "Maximum operational context",
|
|
93
103
|
"chatContextProviderManaged": "managed by the selected provider/model",
|
|
@@ -25,9 +25,13 @@ Si el procesamiento tarda más de 1,2 segundos, la salida 3 emite inmediatamente
|
|
|
25
25
|
|
|
26
26
|
Las solicitudes de Ollama y Bionic LM Studio usan automáticamente un tiempo de espera mínimo de 10 minutos; los proveedores cloud mantienen un mínimo de 2 minutos. No hay ningún campo de tiempo de espera que gestionar en el editor. Si también se alcanza el límite local, KNX AI indica que el modelo no terminó y recomienda volver a intentarlo o reducir el contexto del prompt.
|
|
27
27
|
|
|
28
|
+
Para los proveedores locales, **Cantidad de contexto del chat** permite elegir explícitamente 4K, 8K o 16K; 16K sigue siendo el valor predeterminado. La selección limita proporcionalmente los datos KNX, de memoria, del proyecto Node-RED y de los adaptadores enviados al modelo, manteniendo completo el contrato de herramientas del agente. Ninguna capacidad se activa o desactiva según frases, palabras clave o intents lingüísticos.
|
|
29
|
+
|
|
28
30
|
El estado del nodo en el canvas está reservado deliberadamente para la última solicitud recibida y el mensaje localizado «Estoy pensando…» mientras se ejecuta el LLM. Los telegramas KNX, las actualizaciones del gateway, las tasas de tráfico, los mensajes ready y los resultados técnicos nunca lo sobrescriben; siguen disponibles mediante las salidas, los registros y los datos del Asistente.
|
|
29
31
|
|
|
30
|
-
Cada sesión Ask/chat conserva sus últimos 8 turnos y hasta 20 instrucciones
|
|
32
|
+
Cada sesión Ask/chat conserva sus últimos 8 turnos y hasta 20 instrucciones a largo plazo elegidas por el modelo, separadas por `msg.knxAi.sessionId`, `msg.sessionId` o el ID de chat Telegram detectado. El modelo decide semánticamente, mediante la herramienta de memoria estructurada, qué significado de una conversación debe recordar u olvidar; no se utiliza ninguna lista de palabras clave ni intents lingüísticos. Todos los nodos KNX AI que usan el mismo almacenamiento comparten este contexto en tiempo real y lo recargan tras reiniciar Node-RED desde `knxultimatestorage/knxai/memory/knxai-chat-context.knxctx`. El archivo se escribe de forma atómica y está limitado a 50 sesiones y 512 KB. Cuando el control KNX está habilitado, conecta la salida 3 al nodo emisor del chat y la salida 4 a un nodo KNX Ultimate en **modo universal**. Con la confirmación activa, la primera respuesta muestra GA, DPT y payload sin emitir escrituras; la misma sesión debe responder `CONFIRMAR` o `CANCELAR` en 5 minutos. Una solicitud nueva sustituye cualquier plan anterior. Cada comando confirmado contiene `msg.destination`, `msg.dpt`, `msg.payload` y `msg.event = "GroupValue_Write"`.
|
|
33
|
+
La memoria reciente de la sesión se coloca inmediatamente junto a la solicitud actual para que los modelos locales conserven los datos proporcionados por el usuario, como su nombre preferido o idioma, incluso dentro de un prompt KNX grande. El modelo puede hacer persistentes los datos, preferencias e instrucciones duraderas mediante `memoryActions`; sigue siendo una elección semántica de herramienta, sin clasificadores de frases ni routing por intents. Las credenciales, códigos de seguridad y claves API nunca deben aprenderse.
|
|
34
|
+
|
|
31
35
|
Para las escrituras DPT 1.xxx, los equivalentes seguros producidos por la IA `true`/`false`, `1`/`0` y `on`/`off` se normalizan a booleanos reales antes de la validación local y la salida.
|
|
32
36
|
|
|
33
37
|
### Lecturas KNX actualizadas
|
|
@@ -42,24 +46,38 @@ Mientras un plan está pendiente, la salida 3 contiene `msg.knxAi.confirmationRe
|
|
|
42
46
|
### Preajustes del adaptador de chat
|
|
43
47
|
La pestaña **Adaptadores de chat** carga sus mapeos seleccionables desde `resources/KNXAIChatAdapterMappings.js`. Al elegir un preajuste se instalan internamente dos mapeos JavaScript síncronos predefinidos: uno antes de que KNX AI procese la entrada y otro antes de emitir por la salida 3. Los mapeos permanecen ocultos en el editor. Los errores de sintaxis y ejecución se capturan y notifican sin detener Node-RED.
|
|
44
48
|
|
|
45
|
-
El preajuste incluido **windkh/node-red-contrib-telegrambot** sigue el contrato receiver/sender del paquete. Conecta directamente un `telegram receiver` a KNX AI y la salida 3 a un `telegram sender`.
|
|
49
|
+
El preajuste incluido **windkh/node-red-contrib-telegrambot** sigue el contrato receiver/sender del paquete. Conecta directamente un `telegram receiver` a KNX AI y la salida 3 a un `telegram sender`. La confirmación usa un teclado de respuesta temporal de Telegram: al pulsar **Confirmar** o **Cancelar** se devuelve un mensaje localizado normal por el mismo receiver, por lo que no hacen falta un `telegram event` ni cableado callback. Los mensajes `callback_query` antiguos siguen siendo compatibles. El mapeo de entrada extrae `msg.payload.content`, `msg.payload.chatId` y el idioma de Telegram. El mapeo de salida crea `msg.payload.chatId`, `type` y `content`, y añade `options.reply_markup` desde `msg.knxAi.confirmationRequest` cuando una escritura espera confirmación. El paquete Telegram sigue siendo una dependencia opcional separada.
|
|
46
50
|
|
|
47
51
|
El preajuste incluido **RedBot / node-red-contrib-chatbot (Telegram)** sigue el formato común de mensajes de RedBot. Conecta directamente `chatbot-telegram-receive` a KNX AI y la salida 3 a `chatbot-telegram-send`; no hace falta un nodo callback separado porque RedBot convierte los postbacks de los botones inline en mensajes de entrada normales. El mapeo de entrada lee `transport`, `chatId`, `type`, `content` y el idioma de Telegram. El mapeo de salida conserva los datos de seguimiento RedBot `originalMessage`, `chat`, `api` y `client`, y después emite un payload `message` o un payload `inline-buttons` con acciones `postback` de confirmación. RedBot sigue siendo una dependencia opcional separada.
|
|
48
52
|
|
|
49
53
|
### Adaptadores de cámara detectados automáticamente
|
|
50
54
|
Los paquetes de cámaras instalados pueden publicar en tiempo de ejecución un adaptador para KNX AI. No hay selector ni nodo de cámara que conectar a KNX AI: los adaptadores, controladores y cámaras disponibles se detectan automáticamente y se incorporan al contexto del chat. `node-red-contrib-unifi-ultimate` es el primer proveedor compatible; otros paquetes, como `hikvision-ultimate`, pueden registrarse mediante el mismo contrato independiente del fabricante.
|
|
51
55
|
|
|
52
|
-
El usuario puede pedir una captura actual o preguntar al modelo de visión qué se ve. Los preajustes de Telegram y RedBot envían la imagen como foto nativa con pie. También se pueden crear notificaciones persistentes por movimiento, cruce de una línea inteligente o entrada en una zona de intrusión/merodeo, limitadas opcionalmente a personas detectadas y a una línea o zona concreta por nombre. Estas reglas se guardan en el mismo archivo `knxai-chat-context.
|
|
56
|
+
El usuario puede pedir una captura actual o preguntar al modelo de visión qué se ve. Los preajustes de Telegram y RedBot envían la imagen como foto nativa con pie. También se pueden crear notificaciones persistentes por movimiento, cruce de una línea inteligente o entrada en una zona de intrusión/merodeo, limitadas opcionalmente a personas detectadas y a una línea o zona concreta por nombre. Estas reglas se guardan en el mismo archivo `knxai-chat-context.knxctx` y se restauran después de reiniciar Node-RED. Las suscripciones a eventos UniFi y las solicitudes de captura se realizan directamente a través del proveedor detectado; no interviene la salida 4 de KNX AI ni hace falta cableado intermedio en el flujo.
|
|
53
57
|
|
|
54
|
-
Cada evento publicado por un adaptador detectado automáticamente se normaliza y se añade a un archivo diario `YYYY-MM-DD.
|
|
58
|
+
Cada evento publicado por un adaptador detectado automáticamente se normaliza y se añade directamente, en el formato nativo compacto por filas de KNX AI, a un archivo diario `YYYY-MM-DD.knxctx` bajo `knxultimatestorage/knxai/adapter-history/<id-nodo>/`. El archivo de telegramas KNX usa el mismo formato compacto, sin serialización JSON intermedia. El archivo conserva 10 días, garantiza más de 24 horas de historial y guarda metadatos, pero no imágenes. Los archivos JSONL existentes no se leen ni se migran. Los totales abarcan todas las filas almacenadas; los detalles seleccionados son solo una muestra relevante.
|
|
55
59
|
|
|
56
60
|
### Anuncios con TTS Ultimate
|
|
57
61
|
Cuando está instalado el paquete opcional `node-red-contrib-tts-ultimate`, aparece entre los adaptadores detectados automáticamente. El selector muestra todos los nodos `ttsultimate` de todos los flows del proyecto, con el flow, el nombre del nodo y el reproductor configurado. Elige el nodo que gestionará los anuncios del chat y despliega el flow.
|
|
58
62
|
|
|
59
|
-
|
|
63
|
+
El modelo decide si usa este adaptador razonando sobre la solicitud actual, las instrucciones persistentes del chat y la Educación IA gestionada por el usuario; no existe un intent de anuncio ni una lista de frases activadoras. Los valores KNX, eventos de adaptadores, imágenes y archivos siguen siendo datos y no instrucciones, aunque las indicaciones fiables del usuario pueden enseñar al modelo cómo actuar sobre ellos. KNX AI envía el texto elegido directamente al nodo como `msg.payload`, con `msg.topic = "knx_ai_announcement"`; no hace falta cableado intermedio. TTS Ultimate gestiona después Sonos, voz, volumen, aviso inicial y cola.
|
|
60
64
|
|
|
61
65
|
### Resumen del contexto del chat
|
|
62
|
-
El editor del nodo muestra una tarjeta compacta con las fuentes disponibles para el chat: tráfico KNX actual, semántica ETS y proyecto Node-RED, memoria de sesión y del hogar, Educación IA y cámaras detectadas. También muestra el contexto operativo máximo y el tamaño UTF-8 real del último prompt del chat; se usan los tokens de entrada exactos cuando el proveedor los informa y, de lo contrario, el recuento se marca como estimado. También enumera `knxai-chat-context.
|
|
66
|
+
El editor del nodo muestra una tarjeta compacta con las fuentes disponibles para el chat: tráfico KNX actual, semántica ETS y proyecto Node-RED, memoria de sesión y del hogar, Educación IA y cámaras detectadas. También muestra el contexto operativo máximo elegido por el usuario y el tamaño UTF-8 real del último prompt del chat; se usan los tokens de entrada exactos cuando el proveedor los informa y, de lo contrario, el recuento se marca como estimado. También enumera `knxai-chat-context.knxctx`, `knxai-home-memory.md` y `knxai-config-<id-nodo>.json`, junto con la raíz absoluta del archivo de telegramas KNX, la carpeta específica del nodo y el patrón diario `YYYY-MM-DD.knxctx`. Las rutas se resuelven en tiempo de ejecución desde el directorio de datos que usa realmente la pasarela configurada.
|
|
67
|
+
|
|
68
|
+
El modelo recibe lecturas/escrituras KNX, adaptadores de cámara, anuncios TTS y memoria persistente como herramientas estructuradas. Puede seleccionarlas y combinarlas semánticamente a partir de la solicitud actual y de las indicaciones fiables aprendidas, sin routing por intents lingüísticos. El runtime solo valida argumentos, disponibilidad de adaptadores y límites de seguridad; las escrituras KNX conservan la validación ETS/DPT local y la confirmación configurada.
|
|
69
|
+
|
|
70
|
+
### Edición y copia del aprendizaje CHAT
|
|
71
|
+
La pestaña **Conversaciones y hogar** de la configuración Node-RED de KNX AI incluye el botón **Abrir aprendizaje del chat IA**, que abre la interfaz web Vue directamente en este editor para el nodo actual.
|
|
72
|
+
|
|
73
|
+
En la interfaz web Vue, abre **Ajustes → Aprendizaje del chat IA** para ver y editar el archivo compartido exacto `knxai-chat-context.knxctx` y su ruta absoluta. El archivo se puede copiar, descargar como copia de seguridad o restaurar desde otro archivo `.knxctx`. **Reinicializar memoria**, protegido por una confirmación explícita, lo sustituye por un contexto nuevo y vacío y elimina las sesiones, instrucciones, vigilancias de cámara y confirmaciones de chat pendientes en todos los nodos KNX AI que usan el mismo almacenamiento. Los registros nativos separados por tabulaciones `KNXAI_CHAT_CONTEXT 3` son la referencia y se pueden editar directamente: `SESSION` contiene registros `INSTRUCTION`, `TURN` y `CAMERA_WATCH` hasta `END_SESSION`. Al guardar se validan y limitan estos registros, se reescribe el archivo de forma atómica y se actualiza el contexto activo de todos los nodos KNX AI que usan el mismo almacenamiento. Una comprobación de revisión evita sobrescribir o reinicializar aprendizaje modificado después de cargarlo en el editor.
|
|
74
|
+
|
|
75
|
+
Solo se admite el formato nativo V3. Los archivos Markdown/JSON V2 y Base64 V1 anteriores no se leen, importan ni migran deliberadamente; el archivo `.md` antiguo se deja intacto y KNX AI inicia un contexto `.knxctx` nuevo. Se mantienen los límites de 50 sesiones y 512 KB.
|
|
76
|
+
|
|
77
|
+
### Roles aprendidos de las direcciones de grupo KNX
|
|
78
|
+
El rol `neutral` expresa una incertidumbre inicial, no una prohibición permanente de control. El modelo puede usar la herramienta estructurada `gaRoleActions` para aprender que una dirección de grupo ETS exacta es un objeto de comando, estado o neutro a partir de una enseñanza fiable del usuario, instrucciones persistentes del chat, Educación IA o una semántica inequívoca del proyecto ETS. No se requiere ninguna palabra clave ni intent de rol; si las pruebas son ambiguas, el modelo pide una aclaración en vez de aprender.
|
|
79
|
+
|
|
80
|
+
El rol, el motivo y la prueba aprendidos se guardan por nodo en `<userDir>/knxai/config/knxai-config-<id-nodo>.json` y se sincronizan en la memoria semántica doméstica limitada. Un rol aprendido como `command` puede validar una escritura en la misma respuesta y permanece disponible después de reiniciar; el modelo también puede olvidarlo y restaurar la clasificación automática. El aprendizaje no puede inventar una GA, cambiar su DPT ETS, eludir la validación del payload ni omitir la confirmación de escritura configurada.
|
|
63
81
|
|
|
64
82
|
## Inteligencia doméstica proactiva guiada por Educación y memoria limitada
|
|
65
83
|
A partir de la jerarquía ETS, nombres, roles y DPT, el nodo crea un modelo semántico determinista. No existe un interruptor separado ni ajustes proactivos avanzados. Una notificación solo se evalúa si el LLM está activo y **Educación IA** la solicita explícitamente. Educación es la única política para condiciones, duración, horas silenciosas y repetición. Sin una regla explícita, o si el LLM no puede evaluarla, no se envía ningún mensaje.
|
|
@@ -125,7 +143,7 @@ Aquí tienes todos los campos tal como se muestran en el editor de KNX AI.
|
|
|
125
143
|
- **2) Install it**: descarga e instala el modelo localmente (p. ej. `llama3.1`).
|
|
126
144
|
- Durante refresh/instalación, KNX AI también intenta iniciar automáticamente el servidor Ollama.
|
|
127
145
|
- Si la instalación falla con error de conexión, verifica que Ollama esté ejecutándose (app de escritorio o `ollama serve`).
|
|
128
|
-
- El contexto máximo declarado por `/api/show` queda solo como información. KNX AI envía
|
|
146
|
+
- El contexto máximo declarado por `/api/show` queda solo como información. KNX AI envía como `num_ctx` el presupuesto elegido de 4K, 8K o 16K (o el máximo del modelo si es menor) y limita proporcionalmente cada fuente de contexto sin eliminar capacidades del agente.
|
|
129
147
|
- Si Node-RED se ejecuta en Docker, usa `host.docker.internal` en lugar de `localhost` en el endpoint.
|
|
130
148
|
|
|
131
149
|
### Configuración rápida de Bionic LM Studio (local)
|
|
@@ -133,7 +151,7 @@ Aquí tienes todos los campos tal como se muestran en el editor de KNX AI.
|
|
|
133
151
|
- Inicia el servidor API de LM Studio desde la página **Developer** o con `lms server start`.
|
|
134
152
|
- Endpoint por defecto: `http://localhost:1234/v1/chat/completions`.
|
|
135
153
|
- Pulsa **Refresh** para cargar todos los modelos expuestos por `/v1/models`; si no hay un modelo configurado se selecciona el primero.
|
|
136
|
-
- Si un modelo ya está cargado, KNX AI conserva la longitud de contexto activa. KNX AI nunca carga un modelo Bionic inactivo mediante la API de gestión: la primera solicitud de chat permite que Bionic lo cargue mediante JIT con los valores predeterminados guardados para el modelo. Independientemente del contexto declarado por Bionic, KNX AI
|
|
154
|
+
- Si un modelo ya está cargado, KNX AI conserva la longitud de contexto activa. KNX AI nunca carga un modelo Bionic inactivo mediante la API de gestión: la primera solicitud de chat permite que Bionic lo cargue mediante JIT con los valores predeterminados guardados para el modelo. Independientemente del contexto declarado por Bionic, KNX AI usa el presupuesto de prompt elegido de 4K, 8K o 16K y mantiene disponibles el razonamiento, KNX, las rutinas, las cámaras y TTS.
|
|
137
155
|
- La clave API es opcional salvo que la autenticación esté activada en los ajustes del servidor LM Studio. En Docker, sustituye `localhost` por `host.docker.internal`.
|
|
138
156
|
|
|
139
157
|
## Nota de seguridad
|
|
@@ -6,6 +6,7 @@
|
|
|
6
6
|
"groupChatHome": "Conversaciones y hogar",
|
|
7
7
|
"detectedAdapters": "Adaptadores detectados automáticamente",
|
|
8
8
|
"chatContextOverview": "Resumen del contexto del chat",
|
|
9
|
+
"chatLearning": "Aprendizaje del chat IA",
|
|
9
10
|
"quickSetup": "Configurar el asistente",
|
|
10
11
|
"llmConnection": "Conexion del Asistente IA",
|
|
11
12
|
"chatAdapter": "Canales de chat",
|
|
@@ -21,6 +22,7 @@
|
|
|
21
22
|
"llmBaseUrl": "Endpoint URL",
|
|
22
23
|
"llmApiKey": "API key",
|
|
23
24
|
"llmModel": "Model",
|
|
25
|
+
"llmPromptContextTokens": "Cantidad de contexto del chat",
|
|
24
26
|
"llmSystemPrompt": "System prompt",
|
|
25
27
|
"llmIncludeRaw": "Include raw payload hex",
|
|
26
28
|
"llmAllowKnxCommands": "Permitir que la IA lea estados KNX y controle actuadores",
|
|
@@ -45,6 +47,11 @@
|
|
|
45
47
|
"ollama": "Ollama (local)",
|
|
46
48
|
"lmstudio": "Bionic LM Studio"
|
|
47
49
|
},
|
|
50
|
+
"promptContext": {
|
|
51
|
+
"small": "Reducido (4K, más rápido)",
|
|
52
|
+
"medium": "Medio (8K)",
|
|
53
|
+
"full": "Completo (16K)"
|
|
54
|
+
},
|
|
48
55
|
"chatAdapter": {
|
|
49
56
|
"none": "Sin adaptador"
|
|
50
57
|
},
|
|
@@ -61,6 +68,7 @@
|
|
|
61
68
|
"lmStudioContextFailed": "No se pudo configurar el contexto del modelo",
|
|
62
69
|
"lmStudioContextCurrentlyLoaded": "cargado actualmente",
|
|
63
70
|
"localContextBudget": "Presupuesto de contexto de KNX AI",
|
|
71
|
+
"promptContextHint": "Controla la cantidad de contexto KNX, memoria, proyecto y adaptadores enviada a los modelos locales. No activa ni desactiva herramientas ni usa enrutamiento por intents.",
|
|
64
72
|
"ollamaNotSupported": "Ollama local mode: API key not required. Default endpoint is http://localhost:11434/api/chat.",
|
|
65
73
|
"ollamaNoModels": "No local Ollama model found. Install one or pick one from the library.",
|
|
66
74
|
"installingOllamaModel": "Starting Ollama and installing model…",
|
|
@@ -80,6 +88,7 @@
|
|
|
80
88
|
"ttsUltimateHint": "Las solicitudes explícitas de anuncio del chat se envían directamente al nodo elegido; no hace falta cableado en el flow.",
|
|
81
89
|
"chatContextLoading": "Cargando el resumen del contexto del chat…",
|
|
82
90
|
"chatContextUnavailable": "El resumen del contexto del chat no está disponible temporalmente.",
|
|
91
|
+
"chatLearningOpenHint": "Abre la interfaz web directamente en el editor de aprendizaje CHAT compartido para ver, editar, copiar o guardar una copia de su archivo persistente.",
|
|
83
92
|
"chatContextIntro": "El chat recibe automáticamente estas fuentes. Las rutas siguientes son las que usa realmente esta instalación de Node-RED.",
|
|
84
93
|
"chatContextLimitLabel": "Contexto operativo máximo",
|
|
85
94
|
"chatContextProviderManaged": "gestionado por el proveedor/modelo seleccionado",
|
|
@@ -172,7 +181,8 @@
|
|
|
172
181
|
"buttons": {
|
|
173
182
|
"installOllamaModel": "2) Install it",
|
|
174
183
|
"ollamaLibrary": "Model library",
|
|
175
|
-
"downloadOllamaModel": "1) Download model"
|
|
184
|
+
"downloadOllamaModel": "1) Download model",
|
|
185
|
+
"openChatLearning": "Abrir aprendizaje del chat IA"
|
|
176
186
|
}
|
|
177
187
|
}
|
|
178
188
|
}
|
|
@@ -25,9 +25,13 @@ Si le traitement dure plus de 1,2 seconde, la sortie 3 émet immédiatement le m
|
|
|
25
25
|
|
|
26
26
|
Les requêtes Ollama et Bionic LM Studio utilisent automatiquement un délai minimal de 10 minutes ; les fournisseurs cloud conservent un minimum de 2 minutes. Aucun champ de délai n’est à gérer dans l’éditeur. Si même la limite locale est atteinte, KNX AI indique que le modèle n’a pas terminé et conseille de réessayer ou de réduire le contexte du prompt.
|
|
27
27
|
|
|
28
|
+
Pour les fournisseurs locaux, **Quantité de contexte du chat** permet de choisir explicitement 4K, 8K ou 16K ; 16K reste la valeur par défaut. Ce choix limite proportionnellement les données KNX, de mémoire, du projet Node-RED et des adaptateurs fournies au modèle, tout en conservant le contrat complet des outils de l’agent. Aucune capacité n’est activée ou désactivée selon une formulation, des mots-clés ou des intents linguistiques.
|
|
29
|
+
|
|
28
30
|
L’état du nœud sur le canvas est volontairement réservé à la dernière demande reçue et au message localisé « Je réfléchis… » pendant l’exécution du LLM. Les télégrammes KNX, mises à jour de la passerelle, débits de trafic, messages ready et résultats techniques ne l’écrasent jamais ; ils restent disponibles via les sorties, les journaux et les données de l’Assistant.
|
|
29
31
|
|
|
30
|
-
Chaque session Ask/chat conserve ses 8 derniers échanges et jusqu'à 20 instructions
|
|
32
|
+
Chaque session Ask/chat conserve ses 8 derniers échanges et jusqu'à 20 instructions à long terme choisies par le modèle, séparées par `msg.knxAi.sessionId`, `msg.sessionId` ou l’ID de chat Telegram détecté. Le modèle décide sémantiquement, grâce à l’outil de mémoire structurée, ce que le sens d’une conversation doit mémoriser ou oublier ; aucune liste de mots-clés ni d’intents linguistiques n’est utilisée. Tous les nœuds KNX AI utilisant le même stockage partagent ce contexte en direct et le rechargent après un redémarrage de Node-RED depuis `knxultimatestorage/knxai/memory/knxai-chat-context.knxctx`. Le fichier, écrit de façon atomique, est limité à 50 sessions et 512 Ko. Lorsque le contrôle KNX est activé, reliez la sortie 3 au nœud d'envoi du chat et la sortie 4 à un nœud KNX Ultimate en **mode universel**. Avec la confirmation active, la première réponse affiche GA, DPT et payload sans émettre d’écriture ; la même session doit répondre `CONFIRMER` ou `ANNULER` dans les 5 minutes. Une nouvelle demande remplace tout plan précédent. Chaque commande confirmée contient `msg.destination`, `msg.dpt`, `msg.payload` et `msg.event = "GroupValue_Write"`.
|
|
33
|
+
La mémoire récente de la session est placée juste à côté de la demande actuelle afin que les modèles locaux conservent les faits fournis par l'utilisateur, comme son nom préféré ou sa langue, même dans un long prompt KNX. Le modèle peut rendre persistants les faits, préférences et instructions durables via `memoryActions` ; cela reste un choix sémantique d'outil, sans classificateur de phrases ni routage par intents. Les identifiants, codes de sécurité et clés API ne doivent jamais être appris.
|
|
34
|
+
|
|
31
35
|
Pour les écritures DPT 1.xxx, les équivalents sûrs produits par l’IA `true`/`false`, `1`/`0` et `on`/`off` sont normalisés en véritables booléens avant la validation locale et la sortie.
|
|
32
36
|
|
|
33
37
|
### Lectures KNX actualisées
|
|
@@ -42,24 +46,38 @@ Lorsqu'un plan est en attente, la sortie 3 contient `msg.knxAi.confirmationReque
|
|
|
42
46
|
### Préréglages d’adaptateur de chat
|
|
43
47
|
L’onglet **Adaptateurs de chat** charge ses mappages sélectionnables depuis `resources/KNXAIChatAdapterMappings.js`. Le choix d’un préréglage installe en interne deux mappages JavaScript synchrones prédéfinis : un avant le traitement de l’entrée par KNX AI et un avant l’émission sur la sortie 3. Les mappages restent masqués dans l’éditeur. Les erreurs de syntaxe et d’exécution sont interceptées et signalées sans arrêter Node-RED.
|
|
44
48
|
|
|
45
|
-
Le préréglage inclus **windkh/node-red-contrib-telegrambot** suit le contrat receiver/sender du paquet. Connectez directement un `telegram receiver` à KNX AI et la sortie 3 à un `telegram sender`.
|
|
49
|
+
Le préréglage inclus **windkh/node-red-contrib-telegrambot** suit le contrat receiver/sender du paquet. Connectez directement un `telegram receiver` à KNX AI et la sortie 3 à un `telegram sender`. La confirmation utilise un clavier de réponse Telegram temporaire : un appui sur **Confirmer** ou **Annuler** renvoie un message localisé normal par le même receiver ; aucun `telegram event` ni câblage de callback n’est nécessaire. Les anciens messages `callback_query` restent acceptés. Le mappage d’entrée extrait `msg.payload.content`, `msg.payload.chatId` et la langue Telegram. Le mappage de sortie crée `msg.payload.chatId`, `type` et `content`, puis ajoute `options.reply_markup` depuis `msg.knxAi.confirmationRequest` lorsqu’une écriture attend confirmation. Le paquet Telegram reste une dépendance optionnelle distincte.
|
|
46
50
|
|
|
47
51
|
Le préréglage inclus **RedBot / node-red-contrib-chatbot (Telegram)** suit le format de message commun de RedBot. Connectez directement `chatbot-telegram-receive` à KNX AI et la sortie 3 à `chatbot-telegram-send` ; aucun nœud de callback séparé n’est nécessaire, car RedBot convertit les postbacks des boutons inline en messages entrants ordinaires. Le mappage d’entrée lit `transport`, `chatId`, `type`, `content` et la langue Telegram. Le mappage de sortie conserve les données de suivi RedBot `originalMessage`, `chat`, `api` et `client`, puis émet soit un payload `message`, soit un payload `inline-buttons` avec des actions `postback` de confirmation. RedBot reste une dépendance optionnelle distincte.
|
|
48
52
|
|
|
49
53
|
### Adaptateurs de caméra détectés automatiquement
|
|
50
54
|
Les paquets de caméra installés peuvent publier à l’exécution un adaptateur pour KNX AI. Il n’existe aucun sélecteur ni nœud caméra à relier à KNX AI : les adaptateurs, contrôleurs et caméras disponibles sont détectés automatiquement et ajoutés au contexte du chat. `node-red-contrib-unifi-ultimate` est le premier fournisseur pris en charge ; d’autres paquets, tels que `hikvision-ultimate`, peuvent s’enregistrer avec le même contrat indépendant du fabricant.
|
|
51
55
|
|
|
52
|
-
L’utilisateur peut demander une capture actuelle ou demander au modèle de vision ce qui est visible. Les préréglages Telegram et RedBot envoient l’image comme photo native avec une légende. L’utilisateur peut aussi créer des notifications persistantes pour un mouvement, le franchissement d’une ligne intelligente ou l’entrée dans une zone d’intrusion/de stationnement, avec une limitation facultative aux personnes détectées et à une ligne ou zone nommée précise. Ces règles sont stockées dans le même fichier `knxai-chat-context.
|
|
56
|
+
L’utilisateur peut demander une capture actuelle ou demander au modèle de vision ce qui est visible. Les préréglages Telegram et RedBot envoient l’image comme photo native avec une légende. L’utilisateur peut aussi créer des notifications persistantes pour un mouvement, le franchissement d’une ligne intelligente ou l’entrée dans une zone d’intrusion/de stationnement, avec une limitation facultative aux personnes détectées et à une ligne ou zone nommée précise. Ces règles sont stockées dans le même fichier `knxai-chat-context.knxctx` et restaurées après les redémarrages de Node-RED. Les abonnements aux événements UniFi et les demandes de capture passent directement par le fournisseur détecté ; la sortie 4 de KNX AI et un câblage intermédiaire ne sont pas nécessaires.
|
|
53
57
|
|
|
54
|
-
Chaque événement publié par un adaptateur détecté automatiquement est normalisé puis ajouté à un fichier quotidien `YYYY-MM-DD.
|
|
58
|
+
Chaque événement publié par un adaptateur détecté automatiquement est normalisé puis ajouté directement, dans le format natif compact par lignes de KNX AI, à un fichier quotidien `YYYY-MM-DD.knxctx` sous `knxultimatestorage/knxai/adapter-history/<id-nœud>/`. L’archive des télégrammes KNX utilise le même format compact, sans sérialisation JSON intermédiaire. L’archive conserve 10 jours, garantit plus de 24 heures d’historique et stocke les métadonnées, mais pas les images. Les archives JSONL existantes ne sont ni lues ni migrées. Les totaux couvrent toutes les lignes stockées ; les détails sélectionnés ne sont qu’un échantillon pertinent.
|
|
55
59
|
|
|
56
60
|
### Annonces avec TTS Ultimate
|
|
57
61
|
Lorsque le paquet facultatif `node-red-contrib-tts-ultimate` est installé, il apparaît parmi les adaptateurs détectés automatiquement. Le sélecteur recense tous les nœuds `ttsultimate` de tous les flows du projet, avec le flow, le nom du nœud et le lecteur configuré. Sélectionnez le nœud chargé des annonces du chat, puis déployez le flow.
|
|
58
62
|
|
|
59
|
-
|
|
63
|
+
Le modèle décide d’utiliser cet adaptateur en raisonnant sur la demande actuelle, les instructions persistantes du chat et l’Éducation IA gérée par l’utilisateur ; il n’existe ni intent d’annonce ni liste de phrases déclencheuses. Les valeurs KNX, événements d’adaptateur, images et archives restent des données et non des instructions, mais les consignes fiables de l’utilisateur peuvent apprendre au modèle comment agir sur ces données. KNX AI envoie le texte choisi directement au nœud dans `msg.payload`, avec `msg.topic = "knx_ai_announcement"`. TTS Ultimate gère ensuite le lecteur Sonos, la voix, le volume, le signal et la file d’attente.
|
|
60
64
|
|
|
61
65
|
### Aperçu du contexte du chat
|
|
62
|
-
L’éditeur du nœud affiche une carte compacte résumant les sources disponibles pour le chat : trafic KNX actuel, sémantique ETS et projet Node-RED, mémoire de session et de la maison, Éducation IA et caméras détectées. Elle affiche aussi le contexte opérationnel maximal et la taille UTF-8 réelle du dernier prompt du chat ; les jetons d’entrée exacts du fournisseur sont utilisés lorsqu’ils sont fournis, sinon leur nombre est signalé comme estimé. Elle répertorie aussi `knxai-chat-context.
|
|
66
|
+
L’éditeur du nœud affiche une carte compacte résumant les sources disponibles pour le chat : trafic KNX actuel, sémantique ETS et projet Node-RED, mémoire de session et de la maison, Éducation IA et caméras détectées. Elle affiche aussi le contexte opérationnel maximal choisi par l’utilisateur et la taille UTF-8 réelle du dernier prompt du chat ; les jetons d’entrée exacts du fournisseur sont utilisés lorsqu’ils sont fournis, sinon leur nombre est signalé comme estimé. Elle répertorie aussi `knxai-chat-context.knxctx`, `knxai-home-memory.md` et `knxai-config-<id-nœud>.json`, ainsi que la racine absolue de l’archive des télégrammes KNX, le dossier propre au nœud et le format quotidien `YYYY-MM-DD.knxctx`. Les chemins sont déterminés à l’exécution depuis le répertoire de données réellement utilisé par la passerelle configurée.
|
|
67
|
+
|
|
68
|
+
Le modèle reçoit les lectures/écritures KNX, les adaptateurs caméra, les annonces TTS et la mémoire persistante comme outils structurés. Il peut les sélectionner et les combiner sémantiquement à partir de la demande actuelle et des consignes fiables apprises, sans routage par intents linguistiques. Le runtime ne valide que les arguments, la disponibilité des adaptateurs et les limites de sécurité ; les écritures KNX conservent la validation ETS/DPT locale et la confirmation configurée.
|
|
69
|
+
|
|
70
|
+
### Modification et sauvegarde de l'apprentissage CHAT
|
|
71
|
+
L'onglet **Conversations et maison** de la configuration Node-RED de KNX AI contient le bouton **Ouvrir l'apprentissage du chat IA**, qui ouvre l'interface web Vue directement sur cet éditeur pour le nœud actuel.
|
|
72
|
+
|
|
73
|
+
Dans l'interface web Vue, ouvrez **Paramètres → Apprentissage du chat IA** pour afficher et modifier le fichier partagé exact `knxai-chat-context.knxctx` ainsi que son chemin absolu. Le fichier peut être copié, téléchargé comme sauvegarde ou restauré depuis un autre fichier `.knxctx`. **Réinitialiser la mémoire**, protégé par une confirmation explicite, le remplace par un nouveau contexte vide et efface les sessions, instructions, surveillances de caméra et confirmations de chat en attente dans tous les nœuds KNX AI utilisant le même stockage. Les enregistrements natifs séparés par tabulations `KNXAI_CHAT_CONTEXT 3` font autorité et sont directement modifiables : `SESSION` contient les enregistrements `INSTRUCTION`, `TURN` et `CAMERA_WATCH` jusqu'à `END_SESSION`. L'enregistrement valide et limite ces enregistrements, réécrit le fichier de manière atomique et met à jour le contexte actif de tous les nœuds KNX AI utilisant le même stockage. Un contrôle de révision refuse d'écraser ou de réinitialiser un apprentissage modifié après son chargement dans l'éditeur.
|
|
74
|
+
|
|
75
|
+
Seul le format natif V3 est pris en charge. Les anciens fichiers Markdown/JSON V2 et Base64 V1 ne sont volontairement ni lus, ni importés, ni migrés ; l'ancien fichier `.md` reste intact et KNX AI démarre un nouveau contexte `.knxctx`. Les limites de 50 sessions et 512 Ko restent applicables.
|
|
76
|
+
|
|
77
|
+
### Rôles appris des adresses de groupe KNX
|
|
78
|
+
Le rôle `neutral` représente une incertitude initiale, pas une interdiction permanente de commande. Le modèle peut utiliser l’outil structuré `gaRoleActions` pour apprendre qu’une adresse de groupe ETS exacte est un objet de commande, d’état ou neutre à partir d’un enseignement fiable de l’utilisateur, de consignes persistantes du chat, de l’Éducation IA ou d’une sémantique non équivoque du projet ETS. Aucun mot-clé ni intent de rôle n’est requis ; si les preuves sont ambiguës, le modèle demande une précision au lieu d’apprendre.
|
|
79
|
+
|
|
80
|
+
Le rôle, la justification et la preuve appris sont enregistrés par nœud dans `<userDir>/knxai/config/knxai-config-<id-nœud>.json` et synchronisés dans la mémoire sémantique domestique limitée. Un rôle appris comme `command` peut valider une écriture dans la même réponse et reste disponible après redémarrage ; le modèle peut aussi l’oublier et rétablir la classification automatique. L’apprentissage ne peut pas inventer une GA, modifier son DPT ETS, contourner la validation du payload ni ignorer la confirmation d’écriture configurée.
|
|
63
81
|
|
|
64
82
|
## Intelligence domestique proactive guidée par l’Éducation et mémoire limitée
|
|
65
83
|
À partir de la hiérarchie ETS, des noms, rôles et DPT, le nœud crée un modèle sémantique déterministe. Il n’existe ni interrupteur séparé ni paramètres proactifs avancés. Une notification n’est évaluée que si le LLM est actif et si **Éducation IA** la demande explicitement. L’Éducation définit seule les conditions, la durée, les heures silencieuses et la répétition. Sans règle explicite, ou si le LLM ne peut pas l’évaluer, aucun message n’est envoyé.
|
|
@@ -125,7 +143,7 @@ Voici tous les champs tels qu'affichés dans l'éditeur KNX AI.
|
|
|
125
143
|
- **2) Install it** : télécharge et installe le modèle localement (ex. `llama3.1`).
|
|
126
144
|
- Pendant refresh/install, KNX AI tente aussi de démarrer automatiquement le serveur Ollama.
|
|
127
145
|
- Si l'installation échoue avec une erreur de connexion, vérifier qu'Ollama est lancé (app desktop ou `ollama serve`).
|
|
128
|
-
- Le contexte maximal déclaré par `/api/show` reste informatif. KNX AI envoie
|
|
146
|
+
- Le contexte maximal déclaré par `/api/show` reste informatif. KNX AI envoie le budget choisi de 4K, 8K ou 16K comme `num_ctx` (ou le maximum du modèle s’il est inférieur) et limite proportionnellement chaque source de contexte sans retirer de capacités à l’agent.
|
|
129
147
|
- Si Node-RED tourne dans Docker, utiliser `host.docker.internal` au lieu de `localhost` dans l'endpoint.
|
|
130
148
|
|
|
131
149
|
### Démarrage rapide Bionic LM Studio (local)
|
|
@@ -133,7 +151,7 @@ Voici tous les champs tels qu'affichés dans l'éditeur KNX AI.
|
|
|
133
151
|
- Démarrer le serveur API LM Studio depuis la page **Developer** ou avec `lms server start`.
|
|
134
152
|
- Endpoint par défaut : `http://localhost:1234/v1/chat/completions`.
|
|
135
153
|
- Cliquer sur **Refresh** pour charger tous les modèles exposés par `/v1/models` ; le premier est sélectionné si aucun modèle n’est configuré.
|
|
136
|
-
- Lorsqu’un modèle est déjà chargé, KNX AI conserve la longueur de contexte active. KNX AI ne charge jamais un modèle Bionic inactif via l’API de gestion : la première requête de chat laisse Bionic le charger en JIT avec les valeurs par défaut enregistrées pour ce modèle. Indépendamment du contexte déclaré par Bionic, KNX AI
|
|
154
|
+
- Lorsqu’un modèle est déjà chargé, KNX AI conserve la longueur de contexte active. KNX AI ne charge jamais un modèle Bionic inactif via l’API de gestion : la première requête de chat laisse Bionic le charger en JIT avec les valeurs par défaut enregistrées pour ce modèle. Indépendamment du contexte déclaré par Bionic, KNX AI utilise le budget de prompt choisi de 4K, 8K ou 16K et conserve les capacités de raisonnement, KNX, routines, caméras et TTS.
|
|
137
155
|
- La clé API est facultative sauf si l’authentification est activée dans les paramètres du serveur LM Studio. Dans Docker, remplacer `localhost` par `host.docker.internal`.
|
|
138
156
|
|
|
139
157
|
## Note sécurité
|