Problembehandlung

Der AI-Stack ist docker compose eins. Deshalb gibt es auch nur einen Ausgangspunkt für die Problembehandlung — herausfinden, welcher Container sich merkwürdig verhält, und dessen Logs ansehen.

cd /opt/kopens/plantpulse-ai-docker/bin
./doctor.sh      # 아무것도 바꾸지 않고 진찰만 합니다. 장애 중에 먼저 돌리십시오
./status.sh      # 무엇이 떠 있나
./health.sh      # 디스크 · 자원 · 서비스별 최근 로그까지

Der Stack startet nicht

Zuerst prüfen: sind beide Schwester-Repositories vorhanden?

ls /opt/kopens
# plantpulse-ai-docker
# plantpulse-ai-inference-server        ← 없으면 compose 가 뜨지 않습니다
# plantpulse-timeseries-insight-server  ← 없으면 compose 가 뜨지 않습니다

compose bindet die Dateien dieser beiden relativ per Bind-Mount ein (z. B. die Gateway-Konfiguration litellm-config.yaml). Fehlen sie, verweigert das Installationsprogramm den Start und gibt den Namen des fehlenden Repositories aus → Installationsübersicht.

Ist die Konfigurationsdatei vorhanden?

sudo test -f /etc/kopens/plantpulse-ai.env && echo 있음 || echo 없음

Falls nicht, führen Sie bin/install.sh erneut aus oder kopieren Sie compose/env.gb10.example an diesen Pfad.

🔴 Bearbeiten Sie compose/.env nicht. Niemand liest diese Datei — maßgeblich ist /etc/kopens/plantpulse-ai.env.

Hat die Vorab-Prüfung vor dem Start stattgefunden?

bin/up.sh · restart.sh · update.sh validieren die env-Datei, bevor compose hochfährt, und stoppen bei Abweichungen — ohne auch nur einen Container anzulegen. Im Stand 2026.10 sind zwei Fälle am häufigsten.

cd /opt/kopens/plantpulse-ai-docker
sudo bash bin/lint-env.sh     # 줄마다 제자리인지 — 바꾸지 않습니다

Ausgabe	Ursache	Maßnahme
`lines that do not belong in …` und je Zeile `release` · `profile` · `redundant` · `derived` · `unknown`	Eine env aus 2026.09 oder älter wurde unverändert übernommen — Image-Referenzen, GPU-Anteile, Werte identisch mit den Standardwerten · `PP_HOST` · verbliebene alte Platform-Kontozeilen	Mit der angezeigten `sed`-Zeile löschen. Vor dem Löschen beide Platform-Zugangsdatenwerte eintragen → Umgebungsvariablen konfigurieren
`renamed keys still use their old names`	Der alte Name `CH_*` ist noch vorhanden	Nicht löschen, sondern die angezeigte `sed` (nur der Name ändert sich) ausführen → siehe unten „CH_-Präfix“
`PP_HW_PROFILE is not set`	Zeile für die Hardware-Form fehlt	Bei GB10 `PP_HW_PROFILE=gb10` eintragen, bei AWS g7e `g7e`
`still has template placeholders`	`CHANGE_ME_*` ist noch vorhanden	Den angezeigten Schlüssel ausfüllen. Mit dem Wert aus der öffentlichen Vorlage startet der Stack nicht
`[FATAL] [platform-credentials] …`	Die Vorab-DB-Bereitstellung hat keine Platform-Zugangsdaten erhalten	Gleiche Ursache wie unten bei „Ein Container bleibt mit FATAL stehen“
`PI_INBOUND_API_KEY is empty and PI_INBOUND_AUTH_DISABLED is not true`	Der Inbound-Schlüssel ist leer	Siehe unten „Backend-Dienst verweigert den Start“
`PI_MEDIA_ENABLED=<value> — true 또는 false 만 받는다`	Für den Bild-/Ton-Schalter wurde ein abweichender Wert eingetragen	Mit `true` oder `false` korrigieren → Bild-/Tonerfassung
In der Zeilenliste `ASR_URL … media`	`ASR_URL` in der Host-env weicht vom Wert ab, den der Bild-/Tonschalter liefert	Diese Zeile löschen. Die Aufzeichnung zu aktivieren ist nur eine Zeile: `PI_MEDIA_ENABLED=true`

Zeilen, die als [warn] angezeigt werden (lines to tidy — the stack starts as is), blockieren den Start nicht — der alte Name MEDIA_INGEST_ENABLED (als Alias für diese Release, alias), ASR_URL mit demselben Wert wie der Schalter (media-same) sowie alte Zeilen mit demselben Wert wie der neue Name (oldname). Mit der zugehörigen sed-Zeile aufräumen. Da der Alias in 2026.11 entfernt wird, sollten Sie vorher umstellen.

Ob compose selbst benötigte Werte (PP_DATALAKE_ADMIN_URL · PP_DATALAKE_ADMIN_API_KEY · PP_HW_PROFILE usw.) leer sind, prüfen Sie so:

docker compose --env-file /etc/kopens/plantpulse-ai.env -f compose/docker-compose.yml config >/dev/null

Ein Container startet ständig neu

docker compose ps                              # 어느 것이 Restarting 인가
docker compose logs --tail=200 <컨테이너>       # 왜 죽는가

Häufige Ursache	Prüfung
GPU wird nicht erkannt	`nvidia-smi` · `docker compose logs plantpulse-llm`
Verbindung zur Platform-DB schlägt fehl	Siehe unten „Platform-DB“
Zu wenig Speicher	`docker stats` · `dmesg -T \| grep -i oom`
Portkonflikt	`ss -ltnp \| grep -E '80\|443\|4000\|5959\|5960\|7115\|8970'` — das Installationsprogramm hat möglicherweise bereits mit „Port wird von einem anderen Prozess belegt“ gewarnt → Service-Port-Übersicht
Platform-Zugangsdaten wurden nicht erhalten	Siehe unten „Ein Container bleibt mit FATAL stehen“
Backend-Dienst stoppt mit `inbound` · `INBOUND_API_KEY is empty`	Siehe unten „Backend-Dienst verweigert den Start“
Nur der Copilot verweigert den Start	Siehe unten „Nur der Copilot startet nicht“

Ein Container bleibt mit FATAL stehen — Platform-Zugangsdaten

Ab 2026.10 beziehen Copilot · Zeitreihen-Insight-API · LightRAG · RAG-API · Digital Thread · LiteLLM beim Start Konto und Passwort von der Platform. Gelingt dies nicht, starten sie nicht mit alten Werten, sondern bleiben mit FATAL stehen — wenn mehrere dieser sechs gleichzeitig wiederholt neu starten, prüfen Sie zuerst hier.

docker logs --tail=50 plantpulse-copilot-web 2>&1 | grep -iE 'credentials|fatal'
sudo grep -E '^PP_DATALAKE_ADMIN_(URL|API_KEY)=' /etc/kopens/plantpulse-ai.env
ls -l /etc/kopens/ca/root.crt /etc/kopens/ca/CA.crt

Ursache	Maßnahme
Nur eine von `PP_DATALAKE_ADMIN_URL` · `PP_DATALAKE_ADMIN_API_KEY` ist vorhanden	Beide eintragen. Fehlt eine, lehnt der Container ab
`/etc/kopens/ca/root.crt` fehlt	Den Platform-Trust-Anchor hinterlegen (denselben Inhalt auch als `CA.crt`). Es gibt keine Möglichkeit, die Zertifikatsprüfung abzuschalten
Schlüssel falsch oder AI-Host-IP nicht in der Platform-Allowlist (4xx)	`PP_DATALAKE_ADMIN_API_KEY` vom Platform-Host `/etc/kopens/plantpulse-platform.env` unverändert übernehmen und die AI-Host-IP in die Allowlist eintragen. Bei 4xx wird ohne Wiederholung sofort gestoppt
Platform `:4950` nicht erreichbar · 5xx	Nach kurzen Wiederholungsversuchen wird gestoppt. Zuerst prüfen, ob `curl -sk https://<플랫폼 호스트>:4950` erreichbar ist

Auch Host-Skripte (Vorab-DB-Bereitstellung, Vorab-Prüfung von install.sh START=1) beziehen dieselben Werte. Schlägt dies fehl, nennt eine [FATAL] [platform-credentials] …-Zeile den Grund und stoppt, bevor der Container startet — die Maßnahme entspricht der obigen Tabelle.

Bei Erfolg zeigt eine mit credentials: beginnende Logzeile nur Namen und Anzahl der Schlüssel an. Nach einer Korrektur der Werte mit bin/restart.sh neu erstellen → Installationsübersicht

Backend-Dienst verweigert den Start — Inbound-Schlüssel

RAG · Zeitreihen-Insight-API · Dokumentenverständnis · Vision · Digital Thread starten nicht, wenn der Inbound-Schlüssel leer ist (vor dem 2026.10-Re-Release liefen sie ohne Authentifizierung offen als healthy).

sudo grep -c '^PI_INBOUND_API_KEY=.' /etc/kopens/plantpulse-ai.env     # 1 이면 값이 있습니다
docker logs --tail=50 plantpulse-rag-api 2>&1 | grep -iE 'inbound|fatal'

Symptom	Ursache	Maßnahme
`bin/up.sh` legt keinen einzigen Container an und zeigt `[fail] PI_INBOUND_API_KEY is empty …`	In der env fehlt die Zeile oder der Wert ist leer — die Vorab-Prüfung stoppt	Mit `sudo bin/passwd.sh --generate PI_INBOUND_API_KEY` eintragen (nach Bearbeitung der Datei den Stack erneut hochfahren)
`[fail] PI_INBOUND_AUTH_DISABLED=<value> — write true or false`	Für den No-Auth-Schalter wurde ein abweichender Wert eingetragen	Mit `true` · `false` korrigieren oder die Zeile löschen
In den Logs eine Zeile wie `FATAL: RAG_INBOUND_API_KEY is empty — refusing to start …`	Ein leerer Schlüssel wurde in den Container eingebracht — compose wurde umgangen oder das Image separat gestartet	Wie oben den Schlüssel eintragen und mit `bin/restart.sh` neu erstellen
Der Stack startet, aber RAG- bzw. Zeitreihen-Aufrufe über Admin-Konsole/Chat liefern `401`	Nach einer Schlüsseländerung wurde nur ein Teil neu erstellt	Mit `bin/restart.sh` alles neu erstellen — siehe unten „Admin-Konsole zeigt 502 · upstream_auth“

Der einzige Weg, ohne Authentifizierung zu starten, ist der Entwicklungsschalter PI_INBOUND_AUTH_DISABLED=true, der ignoriert wird, sobald ein Schlüssel vorhanden ist ([note] … is ignored — PI_INBOUND_API_KEY is set and the key wins). Bei Produktionsinstallationen ist die richtige Lösung, den Schlüssel einzutragen → Umgebungsvariablen konfigurieren

Nur der Copilot startet nicht — Verschlüsselungsschlüssel für gespeicherte Zugangsdaten

Wenn der Rest des Stacks grün ist, aber nur plantpulse-copilot-web den Start verweigert, prüfen Sie PI_COPILOT_SECRET_KEY.

docker logs --tail=50 plantpulse-copilot-web 2>&1 | grep -iE 'SECRET_KEY|secrets'

Log	Ursache	Maßnahme
Zeigt eine Aufforderung, `PI_COPILOT_SECRET_KEY=…` einzutragen	Der Schlüssel fehlt oder hat die falsche Form — bei Hosts, die mit 2026.09 oder älter installiert wurden, fehlt die Zeile (das Installationsprogramm fügt sie bestehenden env-Dateien nicht hinzu)	Mit dem Wert `openssl rand -base64 32` eintragen und neu erstellen → Umgebungsvariablen konfigurieren
`Stored secrets cannot be decrypted`	Der Schlüssel wurde geändert, der alte Wert aber nicht bereitgestellt	Den alten Wert in `PI_COPILOT_SECRET_KEY_PREVIOUS` eintragen → Austauschverfahren. Ist der alte Wert verloren, die versiegelten Zeilen mit dem SQL-Befehl aus dem Log leeren und die Zugangsdaten über die Oberfläche erneut eingeben

Ist PI_DT_SECRET_KEY des Digital Thread leer, startet der Stack, aber nur das Connector-Register antwortet mit config_error (503). Die Vorab-Prüfung (bin/lint-env.sh) meldet fehlende Schlüssel als „Verschlüsselungsschlüssel für gespeicherte Zugangsdaten fehlt“.

Nach einer Konfigurationsänderung ignoriert der Copilot diese — CH_-Präfix

In 2026.10 wurde das Präfix der Copilot-Umgebungsvariablen von CH_ → CO_ geändert, ohne Fallback. Zeilen wie CH_API_V1_KEY · CH_LLM_MAX_COMPLETION_TOKENS · CH_OTEL_GENAI_CONTENT aus der alten env liest der Copilot nicht mehr. Wird die Zeile einfach gelöscht, kehrt der Wert zum Standard zurück — eine externe Integration, die z. B. über CH_API_V1_KEY angesprochen wurde, kommt dann über diesen Schlüssel nicht mehr durch.

Die Vorab-Prüfung erkennt diese Zeilen als renamed, stoppt den Start und zeigt je Zeile eine Zeile, die nur den Namen ändert (sed, Wert bleibt erhalten, ein Backup wird angelegt). Diese ausführen und mit bin/restart.sh plantpulse-copilot-web neu erstellen.

cd /opt/kopens/plantpulse-ai-docker
sudo bash bin/lint-env.sh 2>&1 | grep -A2 'renamed'

Sind alter und neuer Name beide vorhanden und unterscheiden sich im Wert, gewinnt der neue Name — prüfen Sie, welcher Wert korrekt ist, und löschen Sie die alte Zeile → Umgebungsvariablen konfigurieren

Nach dem Hochfahren fehlen Logs oder Schreibvorgänge schlagen fehl — Volume-Besitzrechte

Ab 2026.10 laufen alle Container außer plantpulse-dcgm als Non-Root (unsere Images verwenden uid 10001, gid 0). In schreibbare Volumes, die bei alten Installationen als root angelegt wurden (App-Logs, Zeitreihen-Finetuning-Gewichte, LightRAG, Qdrant, Neo4j, Phoenix-Speicher, vLLM-Cache, Proxy-Zertifikate), kann dann nicht mehr geschrieben werden. Der Fehler ist meist unauffällig (erscheint z. B. nur in der Konsole statt in der Logdatei), Qdrant stirbt sofort, und der Proxy kann den Zertifikatsschlüssel nicht lesen, protokolliert dies und stoppt.

bin/up.sh · restart.sh · update.sh passen die Besitzrechte vor dem Start einmalig mit bin/volumes-nonroot.sh an. Wenn Sie docker compose up manuell direkt aufgerufen haben, wurde dieser Schritt übersprungen.

cd /opt/kopens/plantpulse-ai-docker/bin
./volumes-nonroot.sh     # 이미 맞으면 아무것도 바꾸지 않습니다
./restart.sh

Gelingt die Anpassung nicht, wird 볼륨 소유권을 <uid:gid> 로 맞추지 못했다 ausgegeben und der Start gestoppt → Dienstbetrieb

Verbindung zur Platform-DB schlägt fehl

🔴 Der AI-Stack startet nicht PostgreSQL · Aster TSDB · Redis · RustFS selbst. Er nutzt die Platform-Installation gemeinsam. Fallen diese vier aus, stoppt auch AI.

# 플랫폼 호스트는 이 URL 의 호스트입니다 (PP_HOST 는 따로 적지 않습니다)
sudo grep -E '^PP_DATALAKE_ADMIN_URL=' /etc/kopens/plantpulse-ai.env

# 실제로 닿는가
nc -zv <플랫폼 호스트> 5432    # PostgreSQL
nc -zv <플랫폼 호스트> 9042    # Cassandra

Ist keine Verbindung möglich, liegt das Problem bei der Platform → Service-Port-Übersicht.

Platform-Konten stehen nicht in der env (2026.10)

Konto, Passwort und Port für PG · Aster TSDB · Redis · RustFS werden sowohl von Containern als auch von Host-Skripten beim Start von der Platform bezogen. Wird die Authentifizierung abgelehnt, prüfen Sie nicht die env, sondern die Werte der Platform sowie oben „Ein Container bleibt mit FATAL stehen“. Wurde das Passwort auf der Platform geändert, müssen die AI-Container neu gestartet werden, um den neuen Wert zu erhalten.

Admin-Konsole zeigt 502 · upstream_auth

Schlägt ein Menüpunkt der Konsolenoberfläche mit … rejected the console's inbound API key (401) - check <변수> fehl, hat der Dienst hinter der Konsole den Inbound-Schlüssel der Konsole abgelehnt — es handelt sich nicht um einen abgelaufenen Konsolen-Session. Frühere Versionen interpretierten dieses 401 als Session-Ablauf und leiteten nur zum Login-Bildschirm zurück (auch nach erneutem Login blieb das Problem bestehen).

Ursache ist meist, dass Backend und Konsole nicht mit demselben PI_INBOUND_API_KEY laufen. In den meisten Fällen wurde nur eine Seite neu erstellt oder nach einer Schlüsseländerung nur ein Teil neu gestartet — erstellen Sie daher den gesamten Stack neu.

cd /opt/kopens/plantpulse-ai-docker && bin/restart.sh

Die Adresse der Admin-Konsole lautet ab 2026.10 http://<AI 서버>:5959 · https://<AI 서버>:5960 (zuvor 9080).

LLM-Bildschirm zeigt 502 · llm_upstream

Schlägt ein LLM-Lesebildschirm der Konsole (API-Schlüssel, Logs, Modellregisterliste, Upstream-Status usw.) mit 502 und Grund llm_upstream fehl, hat das Gateway (LiteLLM) oder dessen DB einen 5xx-Fehler ausgegeben — nicht das Konsolen-Backend ist defekt. Das upstream_status in der Antwort ist der vom Gateway gelieferte Statuscode. Frühere Versionen leiteten diesen unverändert als 500 weiter, was wie ein Konsolenfehler aussah.

docker compose logs --tail=100 plantpulse-litellm    # 게이트웨이가 왜 5xx 를 냈나 (DB 접속 등)

Ist das Gateway überhaupt nicht erreichbar, steht im selben 502 als Grund llm_unreachable. Bei 4xx (Eingabefehler) wird der Grund des Gateways direkt im Bildschirm angezeigt.

Es kommt keine Antwort

Grenzen Sie der Reihe nach ein — Gateway → Modell → Bildschirm.

docker compose logs --tail=100 plantpulse-litellm    # 게이트웨이가 요청을 받았나
docker compose logs --tail=100 plantpulse-llm        # 모델이 답했나
docker compose logs --tail=100 plantpulse-copilot-web

Symptom	Häufige Ursache
Im Gateway-Log erscheint keine Anfrage	Gateway-Adresse/-Schlüssel im Bildschirm falsch
Gateway liefert 401	`PI_LLM_API_KEY` stimmt nicht überein
Nur externe Integration schlägt mit Modellnamenfehler fehl	Alter Name wird verwendet (`aura-35b` · `gpt-4o` · `text-embedding-3-large` usw.) — aktuell gelten `aura-lite` · `aura-embedding-4b` → API-Integrationsleitfaden
Modell braucht lange und bricht dann ab	GPU-Speicher knapp — `nvidia-smi`
„Es konnte keine Antwort erstellt werden … das Modell hat eine leere Antwort geliefert“	Auch nach Wiederholung lieferte das Modell eine leere Antwort (per API `502`). Bei Wiederholung Denkmodus und Generierungslimit prüfen → Umgebungsvariablen konfigurieren
„⚠ Die Antworterstellung wurde abgebrochen, da sich derselbe Inhalt wiederholte“	Das Modell wiederholte sich, der Copilot brach ab. Die Frage eingrenzen und erneut stellen

„Verbindung unterbrochen. Der Server erstellt die Antwort weiterhin…“

Es wurde während der Anfrage nur die Verbindung unterbrochen (z. B. Netzwechsel, Proxy-Abriss). Der Text im neuen Bildschirm lautet „Verbindung unterbrochen. Der Server erstellt die Antwort noch fertig und lädt sie hierher, sobald sie bereit ist.“ Der Server erstellt die Antwort vollständig und speichert sie; der Bildschirm zeigt diesen Hinweis an und fragt alle 5 Sekunden, bis zu 5 Minuten lang die Antwort dieses Gesprächs erneut ab und lädt sie bei Eintreffen. Sie müssen nur warten — auch auf dem Smartphone verhält es sich gleich. Wird sie innerhalb von 5 Minuten nicht gefunden, wechselt die Anzeige zu einer Fehlermeldung mit der Schaltfläche Erneut versuchen — prüfen Sie in diesem Fall zuerst, ob die Antwort beim erneuten Öffnen des Gesprächs gespeichert wurde.

Dokumente werden nicht gefunden (RAG)

docker compose logs --tail=100 plantpulse-rag-api
docker compose logs --tail=100 plantpulse-lightrag
curl -s http://127.0.0.1:6333/healthz     # Qdrant(벡터 색인)

Symptom	Zu prüfen
Der Chat antwortet nicht, sondern meldet nur «Die Dokumentensuche ist derzeit nicht verfügbar (MCP Gateway antwortet nicht) …»	Die Dokumentensuche des Chats läuft ausschließlich über das MCP Gateway. Prüfen, ob das Gateway läuft — `docker compose logs --tail=100 plantpulse-mcp-gateway-api`, im Copilot-Log `[MCP_GATEWAY] unreachable` · `[DOC_SEARCH_GUARD]`. Zur gleichen Zeit beginnen Antworten auf andere Fragen mit «Das Tool-Gateway ist nicht erreichbar …»
Der Chat antwortet nicht, sondern meldet nur «Das Dokumentensuche-Tool ist ausgeschaltet oder für dieses Konto nicht zugelassen …»	Das Gateway antwortet, aber `rag_search` erreicht das Modell nicht. Prüfen Sie in der AI-Verwaltungskonsole › MCP Gateway, ob unter Server der RAG Gateway und unter Tools `rag_search` eingeschaltet sind (beide sind von Anfang an eingeschaltet — sind sie aus, hat jemand sie ausgeschaltet). Ist es eingeschaltet, prüfen Sie die Chat-Tool-Berechtigung der Person (`tool:mcp`) und den Reiter «Berechtigungen» im Gateway → RAG — Dokumentensuche im Chat
Hochgeladenes Dokument erscheint nicht in der Suche	Ob der Indexierungslauf abgeschlossen ist — `plantpulse-rag-api`-Log · Grund für Übersprungen in der Sync History → RAG
Dokumenten-Upload schlägt fehl	`plantpulse-docling-serve` · `plantpulse-document-understanding-api`
Antwort zitiert ein falsches Dokument	Index veraltet — erneut hochladen und indexieren
Die KI sagt nur „in den Dokumenten nicht gefunden“	Kann normales Verhalten sein — ist die Suche ergebnislos, wird keine Antwort erfunden, sondern `retrieved: false` zurückgegeben. Prüfen Sie zuerst mit `rag_list_documents`, ob dieses Dokument indexiert ist
RAG `/health` ist `degraded`	`ingest` · `neo4j` · `qdrant` der Antwort ist nicht `ok`

Große PDFs schlagen während der Indexierung fehl

LightRAG extrahiert mit dem LLM Entitäten aus jedem Dokumentabschnitt. Wird ein Abschnitt nicht rechtzeitig fertig, gilt das gesamte Dokument als fehlgeschlagen, und die übrigen Abschnitte werden gar nicht erst versucht.

docker compose logs plantpulse-lightrag | grep -E 'Worker execution timeout|workers initialized'

Log	Bedeutung
`extract LLM func: Worker execution timeout after 480s`	Installation läuft noch mit dem alten Standardwert (240 Sekunden pro Aufruf)
`(Timeouts: Func: 3600s, Worker: 7200s, …)`	Aktueller Standardwert

Das Zeitbudget ist LIGHTRAG_LLM_TIMEOUT in /etc/kopens/plantpulse-ai.env (Standard 3600 Sekunden), das tatsächliche Limit ist das Doppelte davon. Wird die Indexierung in Zeiten abgebrochen, in denen Chat und Abfragen das Modell belasten, prüfen Sie diesen Wert. Nach einer Änderung ist nicht ein Neustart, sondern eine Neuerstellung (bin/restart.sh) erforderlich.

Erhöhen Sie nicht nur das Timeout

Die Ausgabeobergrenze pro Abschnitt (LIGHTRAG_LLM_MAX_TOKENS, Standard 32768) ist gekoppelt, was ein langes Budget sicher macht. Wird die Obergrenze entfernt und nur das Budget erhöht, kann eine einzige außer Kontrolle geratene Anfrage einen GPU-Slot eine Stunde lang belegen.

Dokument-/Bildwerkzeuge schlagen mit „refused to fetch“ fehl

Dokumentenverständnis- und Vision-Werkzeuge lehnen eine empfangene URL ab, wenn sie auf eine interne Adresse (Loopback, privates Netz, Link-Local) auflöst. Erscheint im Grund resolves to a non-public address, liegt dieser Fall vor.

Um einen internen Dateiserver bewusst freizugeben, tragen Sie dessen Hostnamen in FETCH_ALLOWED_HOSTS ein und erstellen Sie beide Dienste neu. Der Name muss exakt dem in der URL verwendeten Namen entsprechen (bei Portangabe nur dieser Port).

echo 'FETCH_ALLOWED_HOSTS=files.example.local' | sudo tee -a /etc/kopens/plantpulse-ai.env >/dev/null
cd /opt/kopens/plantpulse-ai-docker
bin/restart.sh plantpulse-document-understanding-api plantpulse-vision-api

→ Umgebungsvariablen konfigurieren · MCP-Werkzeugübersicht

Zeichnungen werden als normale Dokumente indexiert oder der Zeichnungsbildschirm erscheint nicht

Die Zeichnungserfassung ist standardmäßig deaktiviert (DRAWING_INGEST_ENABLED=false). Ist sie deaktiviert, hat rag-api überhaupt keine Zeichnungs-API, und DXF-/PDF-Zeichnungen werden nicht als Zeichnung gelesen.

docker exec plantpulse-rag-api printenv DRAWING_INGEST_ENABLED

Falls false, tragen Sie DRAWING_INGEST_ENABLED=true in die Host-env ein, erstellen Sie mit bin/restart.sh plantpulse-rag-api neu, und laden Sie die Zeichnungen erneut hoch — vor dem Aktivieren hochgeladene Dateien werden nicht rückwirkend als Zeichnung gelesen. Bei PDFs muss beim Hochladen der Dokumenttyp als „Zeichnung“ angegeben werden, damit sie als Zeichnung gelesen werden → Umgebungsvariablen konfigurieren

Meldung der Konsole	Bedeutung
`drawing is platform-managed — update it in the platform, not here` (`409`)	Es wurde versucht, eine als Platform-Anlagendokument eingegangene Zeichnung über die Konsole zu überschreiben (2026.10 Re-Release 3). Die Korrektur erfolgt auf der Platform
`drawing is platform-managed — delete it in the platform ledger, or exclude it from RAG (POST …/exclude)` (`409`)	Es wurde versucht, eine Zeichnung aus dem Platform-Hauptregister über die Konsole zu löschen. Das Löschen erfolgt im Platform-Hauptregister; um sie nur aus der Suche zu entfernen, „aus dem Korpus ausschließen“
`manually uploaded drawings cannot be excluded — delete the drawing or re-index it instead (platform-ledger drawings can be excluded)` (`409`)	Direkt über die Konsole hochgeladene Zeichnungen können nicht „von der Suche ausgeschlossen“ werden. Löschen oder neu indexieren. Zeichnungen aus dem Platform-Hauptregister können ausgeschlossen werden
`extension not allowed` (`400`)	Es handelt sich um DWG. Als DXF oder PDF exportieren und hochladen

In den Chat eingefügte Dateien werden nicht gelesen

Über Datei einfügen im Eingabefeld von Fragen eingefügte Dateien nimmt der Copilot entgegen, legt sie im Objektspeicher ab und lässt sie vom Dokumentenverständnis-Dienst (plantpulse-document-understanding-api) lesen — Dokumente mit docling, Zeichnungen mit der Zeichnungsauswertung, Video · Audio mit der Transkription (/api/v1/transcribe → plantpulse-asr). Die Bedienung steht unter KI-Chat — Dateien einfügen.

docker logs --tail=200 plantpulse-copilot-web 2>&1 | grep -E '\[CHAT_ATTACH|\[attach\]|\[CHAT_MEDIA'   # Hochladen · Lesen · Transkription · Fehlergründe
docker compose logs --tail=100 plantpulse-document-understanding-api
docker compose logs --tail=100 plantpulse-docling-serve
docker compose logs --tail=100 plantpulse-asr                       # Video · Audio — läuft nur bei PI_MEDIA_ENABLED=true

Beim Hochladen abgewiesen — der Chip zeigt den folgenden Satz unverändert an, und die Datei wird nicht gesendet.

Text im Chip	Ursache · Vorgehen
„Dieser Dateityp kann nicht hochgeladen werden. Laden Sie Office- (xlsx·xls·csv·docx·pptx), PDF-, Zeichnungs- (DXF·PDF), Video- (mp4·mov·mkv·webm) oder Audiodateien (m4a·mp3·wav) hoch“	Kein angenommenes Format. Das Format wird anhand des Inhalts bestimmt; nur die Endung zu ändern, genügt nicht
„Name und Inhalt der Video-·Audiodatei passen nicht zusammen …“	Die Endung ist die eines Videos · einer Audiodatei, der Dateikopf aber nicht dieses Format. Wurde in einem Konverter nur die Endung geändert, im ursprünglichen Format neu exportieren
„Die Video-·Audiodatei ist zu groß (maximal 1 GB)“	Video · Audio darf bis 1 GB groß sein. Aufteilen oder die Auflösung senken und einfügen
„Video·Audio ist zu lang (maximal 60 Minuten). Bitte schneiden und in Teilen hochladen“	Länger als 60 Minuten. Auch nur der Anfang wird nicht angenommen — schneiden und in Teilen einfügen
„Derzeit warten viele Dateien auf die Transkription. Bitte laden Sie sie später erneut hoch“	In der gesamten Installation warten 4 Video- · Audiodateien auf die Transkription oder werden hochgeladen. Erneut einfügen, sobald die vorherigen verarbeitet sind
„DWG kann nicht gelesen werden. Exportieren Sie als DXF oder PDF und laden Sie diese hoch“	Im CAD als DXF oder PDF exportieren und einfügen
„Fügen Sie Fotos als Bild an (im Eingabefeld abgelegt, werden sie als Bild angefügt)“	Eine Fotodatei kam über den Anhangsweg. Erneut ins Eingabefeld einfügen, dann wird sie als Foto angefügt
„Die Datei ist zu groß (maximal 50 MB)“	Eine Datei darf bis 50 MB groß sein. Aufteilen und einzeln einfügen
„In einen Dialog können bis zu 20 Dateien hochgeladen werden“	In diesem Dialog sind bereits 20. In einem neuen Dialog einfügen
„Die Datei ist leer“	Datei mit 0 Byte
„Diese Datei konnte nicht gelesen werden: beschädigt oder nicht vollständig empfangen“	Die Datei ist defekt oder das Hochladen wurde unterbrochen. Original öffnen und prüfen, dann erneut einfügen
„Die Dateistruktur ist zu groß und wurde nicht angenommen (Obergrenze für entpackte Größe·Anzahl der Einträge)“	Die Office-Datei enthält mehr als 20.000 Einträge oder ist entpackt größer als 500 MB
„Die Datei konnte nicht gespeichert werden. Bitte laden Sie sie später erneut hoch“	Schreiben in den Objektspeicher fehlgeschlagen. Copilot-Logs und Zustand des Objektspeichers prüfen

Lesen nach dem Hochladen fehlgeschlagen — der Chip zeigt „Diese Datei konnte nicht gelesen werden: Grund“. Der Grund ist ein englischer Satz des Servers. Die Datei kann trotzdem gesendet werden; die KI kennt sie als »nicht gelesene Datei«.

Grund	Ursache · Vorgehen
`document reader unreachable` · `drawing reader unreachable`	Der Dokumentenverständnis-Dienst ist nicht erreichbar. Prüfen, ob `plantpulse-document-understanding-api` läuft
`document reader is not configured`	Im Copilot fehlt die Adresse des Dokumentenverständnis-Dienstes. Mit dem Standard-compose tritt das nicht auf — prüfen, ob die Einstellungen von Hand geändert wurden
`reading took longer than 10 min`	Das Lesen dauerte länger als 10 Minuten. Ein großes PDF oder Überschneidung mit Indexierungsarbeiten. Datei entfernen und zu ruhigerer Zeit erneut einfügen oder nur die benötigten Seiten ausschneiden
`too many files are being read — remove it and add it again`	Zu viele Dateien werden gleichzeitig gelesen. Chip entfernen und kurz darauf erneut einfügen
`reading was interrupted — remove the file and add it again`	Der Copilot wurde während des Lesens neu gestartet (ohne Fortschritt über 15 Minuten wird so abgebrochen). Entfernen und erneut einfügen
`document reader answered 503` u. a. Zahlen	Der Dokumentenverständnis-Dienst ist ausgelastet oder der Schlüssel passt nicht. Logs des Dokumentenverständnis-Dienstes prüfen
Andere Sätze	Der Grund des Dokumentenverständnis-Dienstes im Wortlaut (z. B. eine alte Office-Datei, die sich nicht öffnen lässt). Original als PDF oder in neuem Format (xlsx · docx · pptx) speichern und einfügen

Transkription von Video · Audio fehlgeschlagen — der Chip zeigt „Konnte nicht transkribiert werden: Grund“ oder „Nicht angenommen: Grund“. Der Grund ist der englische Satz des Dokumentenverständnis-Dienstes im Wortlaut. Vorübergehende Fehler wie Verbindung · Überlastung werden nach 1 · 5 · 30 Sekunden dreimal wiederholt, bevor sie als Fehlschlag gelten; Konfigurations- · Eingabeprobleme gelten sofort als Fehlschlag. Auch eine fehlgeschlagene Datei kann gesendet werden, und das Original lässt sich abspielen; die KI kennt sie aber als »nicht transkribierte Datei«.

Grund	Ursache · Vorgehen
`media transcription is disabled: ASR_URL is not set`	In dieser Installation ist Video · Audio deaktiviert. Der Administrator setzt `PI_MEDIA_ENABLED=true` in der Host-env, lädt das Transkriptionsmodell und startet neu → Video- und Audio-Erfassung
`media transcription is misconfigured: …`	Die Transkriptionseinstellungen passen nicht (Serving-Name u. a.). `/health` und Logs des Dokumentenverständnis-Dienstes prüfen
`transcription service unreachable` · `transcription service answered 503` u. a.	Der Dokumentenverständnis-Dienst oder das Transkriptions-Serving (`plantpulse-asr`) war nicht erreichbar oder ausgelastet. Prüfen, ob beide laufen, dann entfernen und erneut einfügen
`transcription service is not configured`	Im Copilot fehlt die Adresse des Dokumentenverständnis-Dienstes. Mit dem Standard-compose tritt das nicht auf
„Nicht angenommen: …“ (Länge überschritten)	Die Länge ließ sich nicht aus dem Dateikopf lesen, und die angenommene Datei überschritt beim Transkribieren 60 Minuten. Schneiden und in Teilen einfügen

Weiteres Symptom	Ursache
Senden lässt sich nicht drücken, und „Dateien werden gelesen — senden Sie, sobald sie gelesen sind“ bleibt stehen	Das Lesen ist nicht abgeschlossen. Nach Abschluss oder Fehlschlag wird es freigegeben, ebenso beim Entfernen der Datei, die gerade gelesen wird
„Der Anhang wird noch gelesen. Senden Sie, sobald er gelesen ist“	Im Moment des Sendens wurde auf dem Server noch eine Datei gelesen. Erneut senden, wenn der Chip »Gelesen« zeigt
Beim Klick auf den Chip „Diese Datei wurde nicht gefunden. Sie wurde gelöscht, oder Sie können sie nicht ansehen“	Die Datei wurde gelöscht oder gehört zum Dialog einer anderen Person. Anhänge öffnet nur der Eigentümer des Dialogs (auch für Administratoren)
Beim Klick auf den Chip „Die Datei konnte nicht geladen werden. Bitte öffnen Sie sie später erneut“	Original oder gelesener Text konnten nicht aus dem Objektspeicher geholt werden
Die Datei ist »Gelesen«, aber die KI sagt, sie kenne den Inhalt nicht	Ohne das Chat-Werkzeugrecht `tool:builtin` erhält die KI das Werkzeug zum Lesen von Anhängen nicht → Berechtigungen
Die KI kennt den hinteren Teil eines langen Dokuments nicht	Gelesen werden nur die ersten 100 Seiten (jedes Blatt · jede Folie zählt als eine Seite). Den benötigten Teil ausschneiden und einfügen
Maße · Stückliste einer PDF-Zeichnung werden falsch gelesen	Sie wurde als Dokument gelesen. Über die Schaltfläche Zeichnung im Chip als Zeichnung neu lesen lassen, dann senden
Nach dem Einfügen eines Videos sagt die KI, es werde „noch transkribiert“	Die Transkription ist nicht abgeschlossen. Bei bis 5 Minuten · 200 MB wartet die Frage bis zu 20 Sekunden, längere Dateien werden im Hintergrund transkribiert. Erneut fragen, sobald „Transkript bereit“ erscheint
Der Chip bleibt lange bei „Wartet auf Transkription“	Transkribiert wird in der gesamten Installation jeweils eine Datei, in der Reihenfolge des Einfügens (kurze Dateien zuerst). Es wird auf die vorherigen Dateien gewartet. Bleibt es so, die Logs mit `[CHAT_MEDIA` prüfen
„Keine Sprache und keine Untertitel gefunden“	Weder Sprache noch eingebettete Untertitel vorhanden. Bildschirmtext · eingebrannte Untertitel werden nicht gelesen
Das Video wird nicht abgespielt	Ein Codec, den der Browser nicht öffnen kann (z. B. H.265). Transkription und Antworten funktionieren trotzdem
Beim Hochladen eines großen Videos erscheint HTML 413	Der Chat-Anhangspfad des Proxys ist bis 1040 MB offen (er folgt nicht `MEDIA_MAX_FILE_MB` des Hosts). Prüfen, ob das Proxy-Image von Hand geändert wurde oder ein weiterer Proxy davor steht

Fragen per Sprache endet mit „Spracheingabe derzeit nicht verfügbar“

Die Funktion Fragen per Sprache im Chat sendet die Aufnahme an den Transkriptions-Eingang des Dokumentenverständnis-Dienstes, und dieser ruft das Transkriptions-Serving (plantpulse-asr) auf. Diese Meldung („…der Transkriptionsdienst ist deaktiviert oder ausgelastet“) bedeutet, dass irgendwo auf diesem Pfad eine Blockade besteht. Im Copilot-Log bleibt der vom Dokumentenverständnis gelieferte Statuscode erhalten.

docker logs --tail=100 plantpulse-copilot-web 2>&1 | grep '\[voice\]'      # 예: [voice] doc-und answered 503: …
docker exec plantpulse-document-understanding-api printenv ASR_URL          # 비었으면 영상 · 음성이 꺼진 설치
cd /opt/kopens/plantpulse-ai-docker && bin/status.sh                        # plantpulse-asr · plantpulse-asr-audio

Ursache	Erscheinungsbild	Maßnahme
Bild/Ton ist deaktiviert (Standard)	`ASR_URL` des Dokumentenverständnisses ist leer, Transkriptions-Eingang gibt `503` (`media transcription is disabled: ASR_URL is not set`)	`PI_MEDIA_ENABLED=true` in die Host-env eintragen, Transkriptionsmodell beziehen und `bin/restart.sh` → Bild-/Tonerfassung
Aktiviert, aber Dokumentenverständnis läuft noch mit altem Wert	`ASR_URL` ist weiterhin leer	Nach Ändern des Schalters nicht `docker restart`, sondern mit `bin/restart.sh` neu erstellen
`plantpulse-asr` ist `unhealthy` · wiederholte Neustarts	`components.asr.status` von `/health` im Dokumentenverständnis ist `down`, gesamt `status` ist `degraded`	`docker logs plantpulse-asr` — fehlt das Modell (`/opt/kopens/models/Aura-ASR-Turbo`), mit `bin/fetch-models.sh` beziehen. Der erste Start kann wegen Kompilierung lange dauern
`plantpulse-asr-audio` endete mit einem Code ungleich null	`bin/status.sh` zeigt nicht „Exited (0)“. Auch `plantpulse-asr`, das darauf wartet, startet dann nicht	`docker logs plantpulse-asr-audio` prüfen, ob das Image bezogen wurde, dann `bin/restart.sh`
Transkriptions-Serving ist ausgelastet	Überschneidung mit Bildverarbeitung	Nach kurzer Zeit erneut versuchen

Dass plantpulse-asr-audio als „Exited (0)“ verbleibt, ist normal — es handelt sich um einen einmaligen Dienst, der Audio-Bibliotheken in ein Volume kopiert und dann endet; auch bin/status.sh zählt dies als normal.

Andere Meldung	Ursache
„Spracheingabe funktioniert nur über HTTPS-Adressen“	Der Browser gibt über eine unverschlüsselte Adresse kein Mikrofon frei. Über `https://` zugreifen
„Mikrofonberechtigung verweigert“	Schloss-Symbol in der Adressleiste → Mikrofon „erlauben“
„Aufnahme zu lang (max. 60 Sekunden)“ · „Aufnahme zu groß (max. 4 MB)“	Eine Frage darf bis zu 60 Sekunden bzw. 4 MB umfassen
„Sprache konnte nicht erkannt werden“	Die Transkription lieferte ein leeres Ergebnis. Näher ans Mikrofon gehen und erneut sprechen

MCP-Werkzeuge werden nicht angezeigt

PP_API_URL · PP_API_TOKEN verhindern den Start, wenn sie leer sind — ist der Token jedoch falsch, startet der Stack normal, und im Chat erscheinen 0 Platform-MCP-Werkzeuge. Dadurch sieht es nicht nach einem „Fehler“ aus.

sudo grep -E '^PP_API_(URL|TOKEN)' /etc/kopens/plantpulse-ai.env

Nach dem Eintragen der Werte ist nicht ein Neustart, sondern eine Neuerstellung erforderlich — docker restart liest die env nicht erneut ein.

cd /opt/kopens/plantpulse-ai-docker && bin/restart.sh

Zeitreihenanalyse funktioniert nicht

docker compose logs --tail=100 plantpulse-timeseries-insight-api    # :8970
docker compose logs --tail=100 plantpulse-timeseries-insight-server # :8980 (호스트에는 안 열립니다)

Diese beiden lesen Werte aus der Platform-Aster-TSDB. Prüfen Sie zuerst oben „Platform-DB“.

Vorhersage liefert 500 oder immer nur NAIVE

Ein Konfigurationsfehler lässt den Server nicht abstürzen — derselbe Prozess bedient auch die Anomalieerkennung, sodass unabhängige Funktionen nicht mit ausfallen. Prüfen Sie zuerst /health des Inferenzservers.

# 이 이미지에는 curl 이 없습니다 — python 으로 찌릅니다
docker compose exec plantpulse-timeseries-insight-server \
  python -c "import urllib.request; print(urllib.request.urlopen('http://localhost:8980/health').read().decode())"

Steht in models.ttm.loaded: false status: "degraded", konnte das Vorhersagemodell nicht geladen werden, und der Grund steht in error. Fehlt der Eintrag models vollständig, handelt es sich um eine ältere Version, bei der dies über den Health-Check nicht sichtbar ist — prüfen Sie dann anhand der folgenden Logs.

docker compose logs plantpulse-timeseries-insight-server | grep -E 'MODEL_LOAD|WARMUP|INFER_FORECAST|fallback naive'

Log	Bedeutung	Maßnahme
`[MODEL_WARMUP_FAIL] TTM ch=… 설정이 체크포인트와 맞지 않는다`	Checkpoint-Generation und Loader-Klasse stimmen nicht überein. Vorhersage liefert 500	`TS_TTM_MODEL_CLASS` leer lassen (Checkpoint wählt selbst) oder an die Generation anpassen → Erläuterung
`[MODEL_LOAD_FAIL] … 무작위 초기화 모델로 대체하지 «않는다»`	Gleiche Ursache. Das Laden wurde an dieser Stelle verweigert	Wie oben
`[MODEL_WARMUP_SKIP] TTM ch=…`	Gleiche Ursache bei Versionen vor dem 2026-09-21. Dort liefert die Vorhersage 200 mit `model_used="NAIVE"`	Wie oben
`TTM 을 돌릴 데이터가 모자라다 -> fallback naive. reason=…`	Unzureichende Daten. 200 mit `NAIVE` — die aktuelle Version fängt nur diesen Fall mit einfacher Extrapolation auf	`reason` lesen
`TTM failed -> fallback naive. reason='<태그>_prediction_q0.1'`	Alle Vorhersagen liefern `NAIVE`. Die R3-Gewichte wurden geladen, aber im Image fehlt die Korrektur der Quantil-Spaltennamen (z. B. `2026.09-20260924-1004`)	Mit einem Image mit dieser Korrektur neu beziehen (`./update.sh`)
`TTM failed -> fallback naive. reason=…` (sonstige)	Fallback einer früheren Version — dort wurden auch andere Fehler als Datenmangel als 200 `NAIVE` verschluckt	`reason` lesen

Bei einer Antwort mit NAIVE steht derselbe Grund auch im fallback_reason der Antwort — prüfen Sie das dort, wo kein Zugriff auf Logs besteht.

„Immer nur NAIVE“ und „500“ sind zwei Versionen desselben Problems

Dass ein Konfigurationsfehler zu stiller Extrapolation wurde, wurde am 2026-09-21 behoben. Ältere Versionen konnten mit /health normal, Vorhersage 200 und allen Antworten still als einfache Extrapolation weiterlaufen. Unabhängig von der Version ist dieselbe Stelle zu prüfen — die obigen Logs und TS_TTM_MODEL_CLASS.

Unterscheiden Sie nicht anhand der Versionsnummer — das Image dieses Monats wird mehrfach mit 2026.09-<date>-<시각> neu gebaut. Die obigen Logzeilen sind das zuverlässigste Unterscheidungsmerkmal.

Nach einer Konfigurationsänderung hat sich kein einziger Wert geändert

Dann wurde die Einstellung nicht übernommen. Parameter der Modellbibliothek können unbekannte Namen stillschweigend verschlucken, sodass ein falsch gesetzter Wert ohne Fehler ignoriert wird. Tatsächlich liefen die Aggregations-/Glättungsparameter der Anomalieerkennung (aggr_win_size · smoothing_window_size) nach einer Umbenennung der Bibliotheksargumente vollständig ignoriert weiter (Audit vom 2026-07-24), ohne dass dabei je ein Fehler oder eine Warnung ausgegeben wurde.

Nach einer Konfigurationsänderung prüfen, „ob sich der Wert geändert hat“

„Kein Fehler aufgetreten“ ist keine Bestätigung. Vergleichen Sie die Verteilung der Scores bzw. die Anzahl der Erkennungen vor und nach der Änderung — hat sich kein einziger Wert geändert, ist die Einstellung nicht angekommen.

Am schnellsten lässt sich dies mit einem Extremwert testen — bleibt das Ergebnis bei einer stark geänderten Einstellung unverändert, wird diese Einstellung nicht wirksam.

Die Festplatte läuft voll

docker system df
df -h /data1

Container-Logs werden von Docker rotiert, es gibt dort nichts manuell zu löschen. Meist sind es Images und Volumes.

docker image prune -f      # 태그 없는 옛 이미지

docker volume prune nicht leichtfertig ausführen

Die Speicher von Neo4j · Qdrant · LightRAG liegen in Volumes. Wird der Befehl ausgeführt, während die Container gestoppt sind, gehen Wissensgraph und Vektorindex verloren.

Notfall-Wiederherstellung

cd /opt/kopens/plantpulse-ai-docker/bin
./restart.sh                       # 스택 전체. 0 이면 «쓸 수 있다» 는 뜻입니다
docker compose restart plantpulse-lightrag   # 하나만

Um Images neu zu beziehen und hochzufahren:

./update.sh

Wo die Daten liegen

Die Originaldokumente, der Index und der Wissensgraph von LightRAG liegen in benannten Docker-Volumes (pi-lightrag-inputs · pi-lightrag-storage · pi-qdrant-data · pi-neo4j-data, ab 2026.10 zusätzlich pi-digital-thread-neo4j-data des Werkgraph-Spiegels und pi-ttm-tuned-models der Zeitreihen-Finetuning-Gewichte). Da es sich nicht um Host-Verzeichnisse handelt, werden sie durch rm -rf nicht gelöscht, gehen aber umgekehrt bei einem einzigen docker volume prune gemeinsam verloren. Sichern Sie unbedingt vorher ein Backup — bin/backup.sh sichert die compose-Volumes (ohne Logs und Cache).

Siehe auch

Dienstbetrieb — häufig verwendete Befehle
Logs und Monitoring — welche Container zu prüfen sind
Installationsübersicht — Rolle der fünfundzwanzig Container

Der Stack startet nicht​

Zuerst prüfen: sind beide Schwester-Repositories vorhanden?​

Ist die Konfigurationsdatei vorhanden?​

Hat die Vorab-Prüfung vor dem Start stattgefunden?​

Ein Container startet ständig neu​

Ein Container bleibt mit FATAL stehen — Platform-Zugangsdaten​

Backend-Dienst verweigert den Start — Inbound-Schlüssel​

Nur der Copilot startet nicht — Verschlüsselungsschlüssel für gespeicherte Zugangsdaten​

Nach einer Konfigurationsänderung ignoriert der Copilot diese — CH_-Präfix​

Nach dem Hochfahren fehlen Logs oder Schreibvorgänge schlagen fehl — Volume-Besitzrechte​

Verbindung zur Platform-DB schlägt fehl​

Admin-Konsole zeigt 502 · upstream_auth​

LLM-Bildschirm zeigt 502 · llm_upstream​

Es kommt keine Antwort​

„Verbindung unterbrochen. Der Server erstellt die Antwort weiterhin…“​

Dokumente werden nicht gefunden (RAG)​

Große PDFs schlagen während der Indexierung fehl​

Dokument-/Bildwerkzeuge schlagen mit „refused to fetch“ fehl​

Zeichnungen werden als normale Dokumente indexiert oder der Zeichnungsbildschirm erscheint nicht​

In den Chat eingefügte Dateien werden nicht gelesen​

Fragen per Sprache endet mit „Spracheingabe derzeit nicht verfügbar“​

MCP-Werkzeuge werden nicht angezeigt​

Zeitreihenanalyse funktioniert nicht​

Vorhersage liefert 500 oder immer nur NAIVE​

Nach einer Konfigurationsänderung hat sich kein einziger Wert geändert​

Die Festplatte läuft voll​

Notfall-Wiederherstellung​

Siehe auch​