MartinP sagte: Ein neues Kernel ist ja nicht der einzige "Geist", den man sich ins System holen kann. Auch bei Bibliotheken ist es so, dass beim upgrade eine Bibliothek die Prozesse, die diese Bibliothek nutzen nicht automatisch "abgeschossen" werden, sondern erstmal mit der alten Version der Bibliothek weiterlaufen. Für das Finden solcher Abhängigkeiten ist "needrestart" ein hilfreiches Tool. needrestart findet ein noch laufendes veraltetes Kernel ... und Prozesse, die noch alte Bibliotheksversionen nutzen... https://dev.to/lyraalishaikh/stop-rebooting-linux-just-in-case-practical-needrestart-after-apt-upgrades-58j6 [image: image.jpeg]

Das Paket wurde von @bluefox in einem Adapter umgesetzt und dadurch besser getestet und eingesetzt werden https://forum.iobroker.net/topic/85797/test-adapter-ai-parakeet-v0.1.x-lokale-spracherkennung

Neue Version 1.10.0 für geblockte IPs kann man nun ein paar Informationen über die IP abrufen dem Dialog zur Ansicht der log files wurden such und filterfunktionen hinzugefügt [image: image.jpeg] [image: image.jpeg]

Mal eine Frage zum Betriebsmodus "heat" über die interne Regelung. Gibt es außer dem Datenpunkt "heat_percentage_hour" und die lokale Temperatur einen Indikator oder sogar wirklichen Verlauf um die Regelung nachzuvollziehen? heat pecentage hour sagt für mich aktuell nur aus wieviel in der letzten Stunde geheizt wurde (binär). Es sagt nichts darüber aus wie weit das Ventil geöffnet wurde. Bei niedrigem Sollwert und passendem Istwert, kann ich höchstens drauf schließen das es passt aber nicht wie gut das erzielt wurde, oder?

@Bluefox Das wars, ich war zu ungeduldig. Nachdem das Auto angesteckt war und ich mal das Laden gestartet habe kommt auch der SoC Wert dahin wo ich ihn erwartet habe, also auch in openWB. Danke...

Hallo Bluefox Ich habe soeben meine Skripte im Iob angepasst und das zusammenspiel evcc<-> iob klappt auf diese weise absolut genial. Ich habe gerade gefragt: wäre es nicht schlau man würde dem evcc oder den einzelnen "Geräten" noch irgendwie ein Datenpunkt aus dem iob zurückgeben ob Energie gebraucht wird oder nicht? Bei dieser konfiguration schreibt das evcc zwar den "true" in den iob-Datenpunkt, wenn aber die Heizung gar nicht an geht, weil die Temperatur schon erreicht ist, zählt evcc trotzdem Energie die dort angeblich verwendet wird. Ich bin mir sehr sicher, das geht, aber den Lösungsansatz ist mal wieder hinter sehr vielen Dingen verborgen. Nachtrag: Ich habe gefunden type: switchsocket features: - integrateddevice - heating enabled: source: http uri: http://192.168.130.10:8087/getPlainValue/alias.0.Heizung.Hz_Speicher_L1 temp: source: http uri: http://192.168.130.10:8087/getPlainValue/alias.0.Heizung.Speicher_oben enable: source: http uri: "http://192.168.130.10:8087/set/0_userdata.0.Daten.evcc.Pufferspeicher_1?value={{.enable}}" standbypower: -1600 icon: waterheater # icon for UI purpose only So zeigt er mir als Information sogar die Temperatur des Heizungsspeichers in evcc an, und beim "enabled" steht jetzt der Status, des Shelly Switch drin.

@peterfido sagte: durch Korrekturfaktoren versucht, evtl. Spannungsfälle / -hübe zu korrigieren Oh, dann ist der Tod im Topf. Dann kann man mit den Ergebnissen nichts mehr erreichen. Wem will man das noch zeigen? Bei solchen Themen geht Qualität vor Quantität.

@bluefox erledigt. VG Duffy

Ist Dein Provider zu Hause zufällig Vodafone?

Der Fix ist mittlerweile draussen. Betroffen sind ALLE PHP-Versionen seit v5 (aktuell ist 8) Den Fix gibt es allerdings nur für die folgenden Versionen (8.2,8.3,8.4,8.5) In den folgenden Versionen ist der Fix dann enthalten. PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 Mehr Details hier https://www.php.net/archive/2026.php Man geht auch davon aus, das entsprechende exploits relativ schnell im Netz umhergehen werden um das auszunutzen. Gegenstand der Lücke ist eine sogenannte remote code execution. Das bedeutet, das jemand ohne Authorisierung auf dem Server code ausführen lassen kann und dann im Rahmen der Nutzerberechtigung alles machen kann. uU auch Dinge, die ihr als Kunde nicht mal selbst machen könnt. Die wirklichen Auswirkungen wird man in den nächsten Tagen dann sicherlich der Presse entnehmen können. Aufgrund der hohen Einstufung (9.2 von 10) werden diese Auswirkungen meiner Meinung nach gewaltig sein. v8.1 und früher wird nicht behoben. PHP kann von https://www.php.net geladen werden. Auch in den offiziellen docker images gab es die Aktualisierung bereits https://hub.docker.com/_/php Wer darauf aufbauende images verwendet (und die Software öffentlich im Internet steht, sollte dringend seine Container aktualisieren. Bitte prüft, ob die aktualisierten Images eurer Software dieses Basis-Images bereits berücksichtigen oder PHP die richtigen Versionen direkt beim image build herunterladen. Bei Nextcloud ist is im Imagetag 33 bereits so. https://hub.docker.com/_/nextcloud Bei wordpress in den heute (21.10.25) aktualisierten images ebenfalls https://hub.docker.com/_/wordpress Beides sind official Images auf dockerhub, denkt dran es gibt ggfs auch gleich- oder ähnlich namige images, bei denen es nicht so ist. Nachtrag: Davon sind auch eure Provider betroffen bei denen Ihr evtl Dienste (Webserver, oben genannte Software und mehr) gehostet habt. Da im Web-Bereich PHP mehr oder weniger Standard ist, wollt ihr nicht, das die Instanz übernommen oder Daten kopiert werden. Hier der aktuelle Artikel auf heise https://www.heise.de/news/php2shell-Kritische-Sicherheitsluecken-erlauben-Codeeinschleusung-in-PHP-11492938.html

karl-heinz@meinbroker:~ $ ls -la /etc/.evcc* ps aux | grep nano -rw-r--r-- 1 root root 1024 Oct 18 12:31 /etc/.evcc.yaml.swp karl-he+ 2644 0.0 0.0 6260 2020 pts/1 S+ 18:44 0:00 grep --color=auto nano karl-heinz@meinbroker:~ $

Update [image: Screenshot 2026-10-17 081701.png]

Ich würde im Unifi einfach die nötigen Ports für ntp nach extern freigeben.

@Samson71 sagte: Reißt Funk ab, dann müsste der WR seinen Dienst einstellen. Bin ich ganz bei dir, auch da liegen meine Bedenken.

Ich habe mal ein wenig in der Wayback-Machine die Dokumentation gewälzt. 2023 gab es 1280x720 noch gar nicht.. https://web.archive.org/web/20230101141538/https://tasmota.github.io/docs/Commands/#camera#camera Es scheint also schon ein paar mal vorgekommen sein, dass bei Tasmota dieser Parameter verändert worden ist...

Für dich noch als Anmerkung, was das Tool kann ist zu prüfen ob der Pfad in der History gesetzt ist. Bei deinem Fehler wird es schwierig zur Laufzeit zu analysieren.

Ich habe alle meine Queries in Flux geschrieben bzw schreiben lassen (influxdb-Data Explorer - Script Editor). Es wäre eine Katastrophe, wenn irgendwann doch ein Schwenk auf 3.x nicht mehr zu vermeiden ist (keine Patches mehr für 2.x)

ist es möglich das die Meldung nicht von Iobroker kommt ? Ki sagt: Spoiler Dass die Nachricht punkt 02:00 Uhr parallel zum Proxmox-Backup kommt und kein Eintrag im ioBroker-Log auftaucht, ist der entscheidende Durchbruch! Das bedeutet: Die Nachricht wird mit sehr hoher Wahrscheinlichkeit überhaupt nicht von ioBroker gesendet, sondern direkt von einem Skript/Dienst auf dem Proxmox-Host oder aus der OpenCCU-VM heraus. Der Text "ioBroker..." im Betreff wurde damals beim Erstellen der Nachricht vermutlich nur manuell als Absender-Name im Skript eingetragen. Da das Proxmox-Backup um 02:00 Uhr die OpenCCU-VM ganz kurz einfriert (Snapshot/Freeze) oder die Netzwerkkarte kurz blockiert, schlägt in genau dieser Sekunde ein externer Ping/Check fehl. Hier sind die 4 Verdächtigen außerhalb von ioBroker, die du prüfen musst: Das Proxmox Backup-Skript (Hookscript / Mail / Pushover) Nutzt du in Proxmox ein benutzerdefiniertes Hook-Script für VZDump (Backups) oder einen Proxmox-Benachrichtigungsdienst? Prüfe auf dem Proxmox-Host unter /etc/pve/vzdump.conf oder in den VM-Einstellungen unter Backup -> Advanced -> Hookscript. Wenn ein Backup fehlschlägt oder die VM während des Snapshots kurz nicht antwortet, feuert ein solches Skript eine Pushover-Nachricht ab. Ein Cronjob / Skript direkt auf dem Proxmox-Host (Node/Shell/Python) Möglicherweise hast du früher auf Proxmox-Ebene (per SSH) ein kleines Shell-Skript oder einen Cronjob angelegt, der die Erreichbarkeit der CCU prüft und bei Timeout via curl an Pushover sendet. Verbinde dich per SSH auf deinen Proxmox-Host und prüfe die Cronjobs: Bash crontab -l cat /etc/crontab ls -la /etc/cron.* Suche auf dem Proxmox-Host nach dem Text der Nachricht: Bash grep -rnw '/etc/' -e 'Emerhency' 2>/dev/null grep -rnw '/var/' -e 'Emerhency' 2>/dev/null grep -rnw '/root/' -e 'Emerhency' 2>/dev/null (Der Rechtschreibfehler Emerhency ist hier dein größter Vorteil beim Suchen!) Ein Watchdog-Skript AUF der OpenCCU selbst Einige RaspberryMatic/CCU-Zusatzsoftware (z.B. CCU-Historian, CUxD oder eigene Servicemeldungs-Skripte) führt beim Sichern/Backup interne Neustarts von Diensten durch. Wenn ein CCU-internes Skript merkt, dass der Reinhard/ReGaHSS-Prozess stoppt, schickt es eine Nachricht. Prüfe in der OpenCCU unter Einstellungen -> Systemsteuerung -> Zusatzsoftware oder in den CCU-Programmen, ob dort ein Pushover-Skript aktiv ist. Verbinde dich per SSH auf die OpenCCU und suche auch dort nach dem Schreibfehler: Bash grep -rnw '/usr/local/' -e 'Emerhency' 2>/dev/null Ein zweiter ioBroker-Container / Test-Instanz Hast du auf Proxmox eventuell irgendwann mal ein Template, ein Backup oder einen zweiten ioBroker-CT (z. B. eine Test-Instanz) geklont, der im Hintergrund noch läuft oder per Cron gestartet wird? Schau in Proxmox in die Liste aller CTs und VMs. Läuft dort noch ein anderer Container, den du vielleicht vergessen hast? Warum bricht die CCU beim Backup ein? Wenn Proxmox ein Backup einer VM macht (Modus Snapshot oder Stop): Modus Snapshot (QEMU Guest Agent): Der Speicher/die Disk wird kurz eingefroren (Gefrier-Zustand). Die VM antwortet für 2–10 Sekunden nicht auf Netzwerk-Pings. Lösung für die Warnung: Wenn du die Quelle der Nachricht gefunden hast, passe dort das Timeout an (z. B. erst nach 3 gescheiterten Versuchen im Abstand von 30 Sekunden benachrichtigen) oder schließe das Backup-Zeitfenster (02:00 bis 02:05 Uhr) von der Überwachung aus.

@Homoran ja besser, hat nur indirekt was mit iobroker zu tun