Community Forum

Bluefox

@fastfoot Danke für den Vorschlag, ist umgesetzt! 👍

Es gibt jetzt eine eigene Kategorie Künstliche Intelligenz. Dieses Thema ist schon dorthin umgezogen.

Ab sofort gilt: Für jede eigene Frage, jedes Projekt oder jede Anleitung bitte ein neues Thema in der Kategorie aufmachen. So bleibt alles übersichtlich und lässt sich später auch wiederfinden. Zum Beispiel:

Fragen zur Einrichtung (API-Schlüssel, Modelle, MCP-Server)
eigene Projekte, gern mit Beschreibung, wie ihr es gemacht habt
Erfahrungen mit bestimmten Modellen, auch lokal mit Ollama oder LM Studio
Sprachsteuerung und der neue assistant-Adapter

Dieses Thema hier bleibt für den allgemeinen Austausch und Meinungen rund um KI in ioBroker.

@stenmic @docsnyder7 Euer Wunsch nach einem Leitfaden „welche KI für was" wäre ein gutes erstes Thema für die neue Kategorie. Einen Einstieg mit Übersicht über Modelle und Hardware gibt es auch im Blog: KI in ioBroker

Bluefox

@infinity Laut den Grafiken läuft bis ca. 19:20 alles normal mit etwa 2,6 GB. Dann geht der RAM innerhalb kurzer Zeit auf 4 GB, der Swap ist voll und Disk-Read bleibt dauerhaft hoch. Dann lagert der Container nur noch aus, deshalb die hohe CPU und deshalb geht nichts mehr. Irgendein Prozess (meist eine Adapter-Instanz oder ein Skript) frisst also plötzlich Speicher. Den müssen wir finden.

Bitte schick zuerst den Teil vom ioBroker-Log um diese Zeit:

grep -E "2026-10-29 19:(0|1|2)" /opt/iobroker/log/iobroker.2026-10-29.log | grep -iE "error|warn|memory|heap|terminated|restart" | tail -n 100

Auf dem Proxmox-Host (nicht im Container), ob der OOM-Killer zugeschlagen hat:

dmesg -T | grep -iE "oom|killed process"

Und beim nächsten Hänger, falls du noch auf die Konsole kommst (Proxmox > Console), vor dem Neustart:

free -m
ps aux --sort=-rss | head -n 15

Dann sehen wir direkt, welcher Prozess so viel Speicher braucht. Wenn es wieder läuft, poste bitte auch noch die Ausgabe von iob diag.

Eine bekannte Ursache für solche Sprünge ist das Update der Repositories. Das braucht unter Node 24 kurzzeitig mehrere hundert MB. Schau mit iob repo, ob außer dem aktiven Repo noch andere eingetragen sind (z. B. beta). Was du nicht brauchst, kannst du mit iob repo del beta löschen.

Unabhängig davon sind 512 MB Swap bei 4 GB RAM knapp. Wenn der Host genug Speicher hat, gib dem Container mehr RAM, z. B. 6 GB. Damit ist die Ursache aber nicht weg.

Bluefox

@andibr Du denkst nicht zu sehr um die Ecke, das sind wirklich nur vier Schaltbefehle. Der Knackpunkt ist die Richtung: Der evcc-Adapter legt kein Gerät in evcc an. Er holt nur das, was es in evcc schon gibt, als Datenpunkte nach ioBroker. Das „virtuelle Gerät“ legst du in evcc selbst an, und die Datenpunkte erstellst du selbst im ioBroker.

So würde ich es machen:

Im ioBroker unter Objekte in 0_userdata.0 vier boolesche Datenpunkte anlegen, z. B. evcc.Heizstab1, evcc.Heizstab2, evcc.Heizstab3 und evcc.Whirlpool.
Den simple-api-Adapter installieren, falls noch nicht vorhanden (Port 8087).
In evcc für jeden Datenpunkt „Ladepunkt oder Heizung hinzufügen“ > „Benutzerdefiniertes Gerät“ wählen und Folgendes eintragen, hier für Stufe 1:

type: switchsocket
features:
  - integrateddevice
  - heating
enabled:
  source: http
  uri: http://192.168.x.x:8087/getPlainValue/0_userdata.0.evcc.Heizstab1
enable:
  source: http
  uri: "http://192.168.x.x:8087/set/0_userdata.0.evcc.Heizstab1?value={{.enable}}"
standbypower: -1500

Für Stufe 2 und 3 genauso, nur mit der anderen ID. Beim Whirlpool standbypower: -1800. Da du keine Leistungsmessung hast, nimmt evcc mit dem negativen Wert einfach eine feste Leistung an.

Jedes Gerät bekommt einen Ladepunkt. Dort stellst du den Modus auf PV und legst über die Priorität fest, was zuerst Überschuss bekommt, z. B. Whirlpool vor den Heizstäben und die Stufen 1, 2, 3 nacheinander.

Dann setzt evcc die Datenpunkte auf true oder false, und dein Blockly macht nur noch Folgendes:

Heizstab: Shelly-Kanal = Datenpunkt von evcc UND Temperatur unter Sollwert. Das Thermostat bleibt als Hardware-Sicherung, wie es ist.
Whirlpool: auf 0_userdata.0.evcc.Whirlpool reagieren und den Heizungs-Datenpunkt im Bestway-Adapter setzen, bei Bedarf auch die Filterpumpe.

Für den Whirlpool brauchst du also keinen Shelly. Den evcc-Adapter brauchst du dafür gar nicht, den kannst du für Anzeigen weiter nutzen.

Wenn evcc das Gerät nach dem Speichern als Fehler anzeigt, schick bitte einen Screenshot und rufe die getPlainValue-URL einmal im Browser auf. Dann sieht man gleich, ob es an simple-api oder an der evcc-Konfiguration liegt.

apollon77

@David-G. sagte:

Hey,

ich hab nun auch ein Echo bei mir stehen und wirde den Adapter gerne in Betrieb nehmen.

Leider scheitert es, finde hier im Thread nichts zu.

Wenn ich mich im Adapter über den link anmelden möchte, komme ich zur Seite um meine Mail einzugeben, wenn ich dort dann weiter gehe kommt sofort
Diese Website kann keine sichere Verbindung bereitstellen
192.168.99.33 hat eine ungültige Antwort gesendet.
ERR_SSL_PROTOCOL_ERROR

Die Frage ist doch erstmal wann und wo genau diese Meldung kommt. Kommt die direkt als antwort wenn du den link aufrufen willst? hast du http genutzt anstelle https im Link? ODer machen vllt neue Browser jetzt da blödsinn - weil dieser lokale link ist http und nicht https ... wenn man den versuch mit https aufzurufen gibts so einen fehler ggf.

Bitte mehr details dazu.

Und @samson71 @homoran Könntet Ihr bitte die obige unrelated diskussion zur "Art und Weise von Foren betrogen " irgendwo anders hin packen? Danke

Bluefox

@franzda Im Adapter gibt es keinen Timer, der nach etwa 1000 s etwas macht. Der Client übergibt an MQTT.js nur keepalive (Standard 10 s), reconnectPeriod (Standard 10 s), connectTimeout (Standard 30 s), clean und rejectUnauthorized. Ein ECONNRESET heißt, dass von außen ein TCP-RST gekommen ist. MQTT.js oder der Adapter beenden die Verbindung in so einem Fall sauber und erzeugen kein RST. Der Reset kommt also vom Broker oder von etwas auf dem Weg dorthin.

Fragen bzw. Ansätze:

Welcher Wert steht bei dir in den Instanzeinstellungen bei Keep-Alive? Wenn er deutlich höher als 60 ist und nur alle 10 Minuten etwas gesendet wird, passt das gut zu deiner Beobachtung (1 Minute stabil, 10 Minuten nicht). Ein NAT oder Mobilfunk-Gateway (der Name "womoraspi" klingt nach Wohnmobil und LTE) wirft untätige Verbindungen gern nach einer festen Zeit raus. Stell testweise 30 oder 60 ein, so wie bei deinem Paho-Test.
Hat der Paho-Test eine andere Client-ID benutzt? Wenn irgendwo ein zweiter Client mit womoraspi verbindet, wirft EMQX die alte Session raus (Takeover).
Am zuverlässigsten siehst du es in der EMQX-Cloud-Konsole: Dort steht beim Client das Ereignis zum Disconnect mit Grund (z. B. keepalive_timeout, takenover, kicked). Steht da nichts oder nur ein unspezifischer Socket-Fehler, liegt es eher am Netzwerk.
Auf dem Pi selbst mitschneiden, dann siehst du, wer das RST schickt und ob vorher PINGREQ/PINGRESP laufen:

sudo tcpdump -i any -nn port 8883 -w mqtt.pcap

Dazu die Instanz auf Loglevel debug stellen und die Zeilen rund um den nächsten Abbruch als Text posten.

Bluefox

Danke für den Log, damit war die Ursache schnell klar.

Bei InfluxDB 2.x gibt es kein „DROP MEASUREMENT“. Der Adapter löscht deshalb alle Werte des Datenpunkts über die Delete-API. Dabei geht InfluxDB jeden Shard des Buckets durch, und bei einem Bucket mit Daten aus mehreren Jahren dauert das schnell mehrere Minuten. Der Adapter hat aber nur so lange gewartet, wie das normale „Request timeout“ erlaubt (Standard 30 Sekunden), und dann mit RequestTimedOutError abgebrochen.

Ab Version 5.2.3 bekommen Löschvorgänge eine eigene Verbindung und dürfen bis zu 10 Minuten dauern. Das gilt für das Aufräumen in der Statistik und auch für delete, deleteRange und deleteAll. Schreiben und Abfragen behalten das eingestellte Timeout. Die Version ist veröffentlicht und sollte in Kürze im Latest-Repository auftauchen.

Wer nicht warten möchte: In den Instanzeinstellungen das „Request timeout“ vorübergehend auf z. B. 600000 (10 Minuten) setzen, aufräumen, danach wieder zurückstellen.

Das Löschen kann je nach Größe des Buckets trotzdem einige Minuten dauern. Bitte den Dialog so lange offen lassen.

Kannst du mit 5.2.3 noch einmal aufräumen und kurz Bescheid geben, ob es jetzt durchläuft? Falls einzelne Datenpunkte weiter fehlschlagen, bitte den Log-Ausschnitt dazu posten.

Bluefox

@Schimi Danke, der Request #539 ist ja schon lange offen. Schön, dass sich jemand drangesetzt hat, noch dazu mit eigener Umsetzung von Remote-Protokoll v2 und ADB ohne zusätzliche Abhängigkeiten.

Ein paar Punkte vom kurzen Blick ins Repo:

Bevor du den Antrag fürs Latest stellst, lass am besten den Adapter-Check laufen: https://adapter-check.iobroker.in/
Wenn er im Repo ist, verlinke bitte den Adapter-Request #539 und schließ ihn.
Zum Fire TV im tiefen Standby: Hast du Wake-on-LAN schon probiert? Manche Fire-TV-Fernseher reagieren darauf. Wenn ja, wäre eine optionale MAC-Adresse für WoL beim Einschalten über power praktisch.
Bei den Rollen hast du schon gut aufgepasst (switch.power, media.elapsed, button.play usw.), das hilft später bei type-detector, iot und Matter.

Testberichte mit anderen Geräten kommen hoffentlich jetzt von den Usern.

Bluefox

Danke für das Feedback, vor allem an @mcm1957 für den Vorschlag.

Ist umgesetzt, seit heute ist der Fixer 2026-10-29 online (der Installer ebenfalls):

"Hardened" ist nicht mehr auf dem Startbildschirm. Für normale Installationen braucht man den Modus nicht, und als Haken lädt er nur zum Ausprobieren ein. Wer ihn wirklich will, startet iob fix --hardened bzw. den Installer mit --hardened. Dann zeigt der Startbildschirm auch an, was das bedeutet: Der iobroker-User verliert seine sudo-Rechte und die docker-Gruppe, und Adapter, die Root-Rechte brauchen, funktionieren dann nicht mehr.
Neuer Hinweis auf dem Startbildschirm: "Standard users should not change the defaults, just press Enter." Also: nichts umstellen, Enter drücken, fertig.

Wer schon gehärtet hat, muss nichts tun. Eine gehärtete Installation bleibt auch bei späteren iob fix-Läufen gehärtet.

Die alte Ausgabe Zeile für Zeile gibt es weiterhin mit iob fix --classic.

Bluefox

@TimoWald Die Meldungen DISCONNECTED/CONNECTED erzeugt nicht der Adapter selbst. Er gibt nur die Events aus der Home-Connect-Cloud weiter. Heißt: Die Kaffeemaschine verliert kurz die Verbindung zur Home-Connect-Cloud und meldet sich gleich wieder an. Meist liegt das am WLAN der Maschine und nicht an ioBroker.

Schau bitte:

Zeigt die Home Connect App die Maschine in diesen Momenten auch als offline?
Hat sich vor 3 Tagen am Router oder WLAN etwas geändert (Firmware-Update, Kanal, Mesh, Repeater, Band Steering)?
Wie gut ist der WLAN-Empfang an der Maschine? Hilft es, sie einmal kurz vom Strom zu nehmen?

Wenn die App keine Aussetzer zeigt, stell die Instanz bitte auf Loglevel debug und poste ein paar Minuten Log rund um ein DISCONNECTED. Schreib dazu, welche Version vom homeconnect-Adapter du hast.

Bluefox

@moridin Danke, das hilft schon weiter. Die Warnungen zu den Roboto-Fonts kannst du ignorieren. Wichtig ist diese Zeile:

WebSocket connection to 'wss://iobroker.pro:4443/api/websocket' failed: The network connection was lost.

Die Seite selbst wird also geladen, aber die Websocket-Verbindung von Lovelace über die Cloud bricht ab. Deshalb bleibt das Ladezeichen stehen. Das muss ich mir auf der Cloud-Seite ansehen.

Welche Lovelace-Version hast du jetzt installiert? Am Anfang hast du 7.1.0 geschrieben. Schau bitte im Admin unter Instanzen bei lovelace.0 nach, ob das nach deinen Updates noch stimmt.

Außerdem brauche ich das cloud.0 Log von genau diesem Zeitpunkt. So kommst du daran:

Im Admin links auf Log klicken.
Oben im Filter cloud.0 auswählen.
Lovelace über iobroker.pro öffnen und warten, bis es beim Ladezeichen hängt.
Die Zeilen ab diesem Zeitpunkt als Text hier posten (bitte in einen Codeblock). Oder du lädst das Log dort über den Download-Button herunter und hängst es als Datei an.

Alternativ liegt das Log auch auf dem Server unter /opt/iobroker/log/. Die aktuelle Datei heißt iobroker.current.log.

Schau bitte zusätzlich im Safari unter Netzwerk nach, welcher Status bei api/websocket steht, und mach davon einen Screenshot.

Zu deiner Zusatzfrage: Die Cloud leitet nur Admin, Web (vis) und Lovelace weiter. Jarvis läuft mit einem eigenen Webserver und ist deshalb über ioBroker.pro nicht erreichbar.

Community Forum

administrators

Beiträge

Mitgliederliste