NEWS
MQTT Adapter does not start any more after raspi-crash
-
- Adaptername: ...MQTT Broker/Client
- Link zu Adapterrepository: www.github.com...
- Adapterversion: 6.1.4
- js-controller Version: 7.07.
- Admin Version: 7.7.19
- Hardwaresystem: Pi5
- Arbeitsspeicher: 8GB
- Festplattenart: SSD
- Betriebssystem: Trixie
- Nodejs-Version: 22.21.0
- NPM-Version: 10.9.4
- Installationsart: Skript
- Image, Docker genutzt: Nein
- Ort, Name der Imagedatei: NA
Linux User bitte hier den Output von iob diag einfügen.
========== Start marking the full check here ===========Script v.2025-08-09 *** BASE SYSTEM *** Operating System: Debian GNU/Linux 13 (trixie) Static hostname: raspberrypi01 Icon name: computer Kernel: Linux 6.12.47+rpt-rpi-2712 Architecture: arm64 OS is similar to: Model : Raspberry Pi 5 Model B Rev 1.0 Docker : false Virtualization : none Kernel : aarch64 Userland : 64 bit Systemuptime and Load: 13:08:00 up 1:16, 4 users, load average: 0.12, 0.08, 0.09 CPU threads: 4 *** LIFE CYCLE STATUS *** Operating System is the current Debian stable version codenamed 'trixie'! *** RASPBERRY THROTTLING *** Current issues: No throttling issues detected. Previously detected issues: No throttling issues detected. *** TIME AND TIMEZONES *** Local time: Sat 2026-01-03 13:08:01 CET Universal time: Sat 2026-01-03 12:08:01 UTC RTC time: Sat 2026-01-03 12:08:01 Time zone: Europe/Berlin (CET, +0100) System clock synchronized: yes NTP service: active RTC in local TZ: no *** Users and Groups *** User that called 'iob diag': pi HOME=/home/pi GROUPS=pi adm dialout cdrom sudo audio video plugdev games users netdev lpadmin gpio i2c spi render input iobroker User that is running 'js-controller': iobroker HOME=/home/iobroker SUDO_HOME=/home/pi GROUPS=iobroker tty dialout audio video plugdev bluetooth gpio i2c *** DISPLAY-SERVER SETUP *** Display-Server: true Display-Manager: * lightdm.service - Light Display Manager Desktop: Session: tty System is booting into 'graphical.target'. Usually a server is running in 'multi-user.target'. Please set BootTarget to 'multi-user.target' or run 'iobroker fix' *** MEMORY *** total used free shared buff/cache available Mem: 8.5G 3.4G 3.4G 152M 1.9G 5.1G Swap: 2.1G 0B 2.1G Total: 10G 3.4G 5.6G Active iob-Instances: 18 8059 M total memory 3211 M used memory 3347 M active memory 933 M inactive memory 3251 M free memory 124 M buffer memory 1702 M swap cache 2047 M total swap 0 M used swap 2047 M free swap *** top - Table Of Processes *** top - 13:08:01 up 1:16, 4 users, load average: 0.12, 0.08, 0.09 Tasks: 301 total, 1 running, 300 sleeping, 0 stopped, 0 zombie %Cpu(s): 0.0 us, 0.0 sy, 0.0 ni, 97.7 id, 2.3 wa, 0.0 hi, 0.0 si, 0.0 st MiB Mem : 8059.0 total, 3248.2 free, 3213.8 used, 1828.7 buff/cache MiB Swap: 2048.0 total, 2048.0 free, 0.0 used. 4845.2 avail Mem *** FAILED SERVICES *** UNIT LOAD ACTIVE SUB DESCRIPTION 0 loaded units listed. *** DMESG CRITICAL ERRORS *** No critical errors detected *** FILESYSTEM *** Filesystem Type Size Used Avail Use% Mounted on udev devtmpfs 3.9G 0 3.9G 0% /dev tmpfs tmpfs 1.6G 20M 1.6G 2% /run /dev/nvme0n1p2 ext4 234G 78G 144G 36% / tmpfs tmpfs 4.0G 912K 4.0G 1% /dev/shm tmpfs tmpfs 5.0M 48K 5.0M 1% /run/lock tmpfs tmpfs 1.0M 0 1.0M 0% /run/credentials/systemd-journald.service tmpfs tmpfs 4.0G 9.7M 4.0G 1% /tmp /dev/nvme0n1p1 vfat 511M 79M 433M 16% /boot/firmware tmpfs tmpfs 806M 544K 806M 1% /run/user/1000 tmpfs tmpfs 1.0M 0 1.0M 0% /run/credentials/getty@tty1.service tmpfs tmpfs 1.0M 0 1.0M 0% /run/credentials/serial-getty@ttyAMA10.service Messages concerning ext4 filesystem in dmesg: [Sat Jan 3 11:51:27 2026] Kernel command line: reboot=w coherent_pool=1M 8250.nr_uarts=1 pci=pcie_bus_safe cgroup_disable=memory numa_policy=interleave nvme.max_host_mem_size_mb=0 numa=fake=8 system_heap.max_order=0 smsc95xx.macaddr=2C:CF:67:9E:6A:69 vc_mem.mem_base=0x3fc00000 vc_mem.mem_size=0x40000000 console=ttyAMA10,115200 console=tty1 root=PARTUUID=b035d9c0-02 rootfstype=ext4 fsck.repair=yes rootwait quiet splash plymouth.ignore-serial-consoles cfg80211.ieee80211_regdom=DE [Sat Jan 3 11:51:29 2026] EXT4-fs (nvme0n1p2): orphan cleanup on readonly fs [Sat Jan 3 11:51:29 2026] EXT4-fs (nvme0n1p2): mounted filesystem 37d2cb52-513e-40e1-b90f-213aa6096cba ro with ordered data mode. Quota mode: none. [Sat Jan 3 11:51:30 2026] EXT4-fs (nvme0n1p2): re-mounted 37d2cb52-513e-40e1-b90f-213aa6096cba r/w. Show mounted filesystems: TARGET SOURCE FSTYPE OPTIONS / /dev/nvme0n1p2 ext4 rw,noatime `-/boot/firmware /dev/nvme0n1p1 vfat rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,errors=remount-ro Files in neuralgic directories: /var: 33G /var/ 30G /var/lib 29G /var/lib/mysql 12G /var/lib/mysql/senec 10G /var/lib/mysql/climatecontrol Archived and active journals take up 8M in the file system. /opt/iobroker/backups: 23M /opt/iobroker/backups/ /opt/iobroker/iobroker-data: 219M /opt/iobroker/iobroker-data/ 153M /opt/iobroker/iobroker-data/files 52M /opt/iobroker/iobroker-data/backup-objects 47M /opt/iobroker/iobroker-data/files/admin.admin 46M /opt/iobroker/iobroker-data/files/admin.admin/custom/assets The five largest files in iobroker-data are: 9.8M /opt/iobroker/iobroker-data/files/vis-2/material-icons/knx-uf.json 8.8M /opt/iobroker/iobroker-data/objects.jsonl 8.1M /opt/iobroker/iobroker-data/files/backitup.admin/assets/index-C_W7K-9p.js 5.1M /opt/iobroker/iobroker-data/states.jsonl 4.6M /opt/iobroker/iobroker-data/files/javascript.admin/vs/language/typescript/tsWorker.js USB-Devices by-id: USB-Sticks - Avoid direct links to /dev/tty* in your adapter setups, please always prefer the links 'by-id': No Devices found 'by-id' Zigbee Network Settings on your coordinator/in nvbackup are: zigbee.X Extended Pan ID: *** MASKED *** Pan ID: *** MASKED *** Channel: *** MASKED *** Network Key: *** MASKED *** To unmask the settings run 'iob diag --unmask' *** NodeJS-Installation *** /usr/bin/nodejs v22.21.0 /usr/bin/node v22.21.0 /usr/bin/npm 10.9.4 /usr/bin/npx 10.9.4 /usr/bin/corepack 0.34.0 nodejs: Installed: 22.21.0-1nodesource1 Candidate: 22.21.0-1nodesource1 Version table: *** 22.21.0-1nodesource1 1001 500 https://deb.nodesource.com/node_22.x nodistro/main arm64 Packages 100 /var/lib/dpkg/status 22.20.0-1nodesource1 1001 500 https://deb.nodesource.com/node_22.x nodistro/main arm64 Packages 22.19.0-1nodesource1 1001 500 https://deb.nodesource.com/node_22.x nodistro/main arm64 Packages 22.18.0-1nodesource1 1001 500 https://deb.nodesource.com/node_22.x nodistro/main arm64 Packages 22.17.1-1nodesource1 1001 500 https://deb.nodesource.com/node_22.x nodistro/main arm64 Packages 22.17.0-1nodesource1 1001 500 https://deb.nodesource.com/node_22.x nodistro/main arm64 Packages 22.16.0-1nodesource1 1001 500 https://deb.nodesource.com/node_22.x nodistro/main arm64 Packages 22.15.1-1nodesource1 1001 500 https://deb.nodesource.com/node_22.x nodistro/main arm64 Packages 22.15.0-1nodesource1 1001 500 https://deb.nodesource.com/node_22.x nodistro/main arm64 Packages 22.14.0-1nodesource1 1001 500 https://deb.nodesource.com/node_22.x nodistro/main arm64 Packages 22.13.1-1nodesource1 1001 500 https://deb.nodesource.com/node_22.x nodistro/main arm64 Packages 22.13.0-1nodesource1 1001 500 https://deb.nodesource.com/node_22.x nodistro/main arm64 Packages 22.12.0-1nodesource1 1001 500 https://deb.nodesource.com/node_22.x nodistro/main arm64 Packages 22.11.0-1nodesource1 1001 500 https://deb.nodesource.com/node_22.x nodistro/main arm64 Packages 22.10.0-1nodesource1 1001 500 https://deb.nodesource.com/node_22.x nodistro/main arm64 Packages 22.9.0-1nodesource1 1001 500 https://deb.nodesource.com/node_22.x nodistro/main arm64 Packages 22.8.0-1nodesource1 1001 500 https://deb.nodesource.com/node_22.x nodistro/main arm64 Packages 22.7.0-1nodesource1 1001 500 https://deb.nodesource.com/node_22.x nodistro/main arm64 Packages 22.6.0-1nodesource1 1001 500 https://deb.nodesource.com/node_22.x nodistro/main arm64 Packages 22.5.1-1nodesource1 1001 500 https://deb.nodesource.com/node_22.x nodistro/main arm64 Packages 22.5.0-1nodesource1 1001 500 https://deb.nodesource.com/node_22.x nodistro/main arm64 Packages 22.4.1-1nodesource1 1001 500 https://deb.nodesource.com/node_22.x nodistro/main arm64 Packages 22.4.0-1nodesource1 1001 500 https://deb.nodesource.com/node_22.x nodistro/main arm64 Packages 22.3.0-1nodesource1 1001 500 https://deb.nodesource.com/node_22.x nodistro/main arm64 Packages 22.2.0-1nodesource1 1001 500 https://deb.nodesource.com/node_22.x nodistro/main arm64 Packages 22.1.0-1nodesource1 1001 500 https://deb.nodesource.com/node_22.x nodistro/main arm64 Packages 22.0.0-1nodesource1 1001 500 https://deb.nodesource.com/node_22.x nodistro/main arm64 Packages 20.19.2+dfsg-1 500 500 http://deb.debian.org/debian trixie/main arm64 Packages Temp directories causing deletion problem: 0 No problems detected Errors in npm tree: 0 No problems detected Checking for nodejs vulnerability: █████ ██ ██ ██████ ██████ ██████ ██████ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ███████ ██ ██ ██ ███ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ██ ███████ ███████ ██████ ██████ ██████ ██████ ██ *** ioBroker-Installation *** ioBroker Status iobroker is running on this host. Objects type: jsonl States type: jsonl Hosts: raspberrypi01 raspberrypi01 (version: 7.0.7, hostname: raspberrypi01 , alive, uptime: 3361) Core adapters versions js-controller: 7.0.7 admin: 7.7.19 javascript: 8.9.2 nodejs modules from github: 2 +-- iobroker.husqvarna-automower@0.6.0-beta.12 (git+ssh://git@github.com/ice987987/ioBroker.husqvarna-automower.git#d0df35eeb074d8ffb02a30ee0c27b72b03216108) +-- iobroker.rpi2@2.4.0 (git+ssh://git@github.com/Grothesk242/ioBroker.rpi2.git#4520729d0399a57717ea36573d39a726b120a048) Adapter State + system.adapter.admin.0 : admin : raspberrypi01 - enabled, port: 8081, bind: 0.0.0.0 (SSL), run as: admin + system.adapter.backitup.0 : backitup : raspberrypi01 - enabled + system.adapter.bshb.0 : bshb : raspberrypi01 - enabled + system.adapter.daikin-cloud.0 : daikin-cloud : raspberrypi01 - enabled + system.adapter.discovery.0 : discovery : raspberrypi01 - enabled + system.adapter.homeconnect.0 : homeconnect : raspberrypi01 - enabled + system.adapter.husqvarna-automower.0 : husqvarna-automower : raspberrypi01 - enabled + system.adapter.javascript.0 : javascript : raspberrypi01 - enabled + system.adapter.mqtt.0 : mqtt : raspberrypi01 - enabled, port: 1883, bind: 0.0.0.0 + system.adapter.nut.0 : nut : raspberrypi01 - enabled + system.adapter.rpi2.0 : rpi2 : raspberrypi01 - enabled + system.adapter.shelly.0 : shelly : raspberrypi01 - enabled, port: 1882, bind: 0.0.0.0 + system.adapter.simple-api.0 : simple-api : raspberrypi01 - enabled, port: 8087, bind: 0.0.0.0, run as: admin + system.adapter.sql.0 : sql : raspberrypi01 - enabled, port: 3306 + system.adapter.tibberlink.0 : tibberlink : raspberrypi01 - enabled + system.adapter.vis-2.0 : vis-2 : raspberrypi01 - enabled system.adapter.vis-hqwidgets.0 : vis-hqwidgets : raspberrypi01 - enabled + system.adapter.web.0 : web : raspberrypi01 - enabled, port: 8082, bind: 0.0.0.0, run as: admin + instance is alive Enabled adapters with bindings + system.adapter.admin.0 : admin : raspberrypi01 - enabled, port: 8081, bind: 0.0.0.0 (SSL), run as: admin + system.adapter.mqtt.0 : mqtt : raspberrypi01 - enabled, port: 1883, bind: 0.0.0.0 + system.adapter.shelly.0 : shelly : raspberrypi01 - enabled, port: 1882, bind: 0.0.0.0 + system.adapter.simple-api.0 : simple-api : raspberrypi01 - enabled, port: 8087, bind: 0.0.0.0, run as: admin + system.adapter.sql.0 : sql : raspberrypi01 - enabled, port: 3306 + system.adapter.web.0 : web : raspberrypi01 - enabled, port: 8082, bind: 0.0.0.0, run as: admin ioBroker-Repositories ┌─────────┬──────────┬─────────────────────────────────────────────────────────┬──────────────┐ │ (index) │ name │ url │ auto upgrade │ ├─────────┼──────────┼─────────────────────────────────────────────────────────┼──────────────┤ │ 0 │ 'stable' │ 'http://download.iobroker.net/sources-dist.json' │ false │ │ 1 │ 'beta' │ 'http://download.iobroker.net/sources-dist-latest.json' │ false │ └─────────┴──────────┴─────────────────────────────────────────────────────────┴──────────────┘ Active repo(s): stable Upgrade policy: none Installed ioBroker-Adapters Used repository: stable Adapter "admin" : 7.7.19 , installed 7.7.19 Adapter "backitup" : 3.3.10 , installed 3.3.10 Adapter "bshb" : 0.5.0 , installed 0.5.0 Adapter "daikin-cloud" : 0.4.12 , installed 0.4.12 Adapter "discovery" : 5.0.0 , installed 5.0.0 Adapter "homeconnect" : 1.4.3 , installed 1.4.3 Adapter "javascript" : 9.0.11 , installed 8.9.2 [Updatable] Controller "js-controller": 7.0.7 , installed 7.0.7 Adapter "mqtt" : 6.1.4 , installed 6.1.4 Adapter "nut" : 1.6.0 , installed 1.6.0 Adapter "rpi2" : 2.4.0 , installed 2.4.0 Adapter "shelly" : 10.4.1 , installed 10.4.1 Adapter "simple-api" : 2.8.0 , installed 2.8.0 Adapter "socketio" : 6.7.1 , installed 7.0.8 Adapter "sql" : 3.0.1 , installed 3.0.1 Adapter "tibberlink" : 6.0.3 , installed 6.0.3 Adapter "vis-2" : 2.13.4 , installed 2.13.4 Adapter "vis-hqwidgets": 1.5.1 , installed 1.5.1 Adapter "web" : 7.0.8 , installed 7.0.8 Adapter "ws" : 2.6.2 , installed 3.0.19 Objects and States Please stand by - This may take a while Objects: 3572 States: 2778 *** OS-Repositories and Updates *** W: https://deb.nodesource.com/node_22.x/dists/nodistro/InRelease: Policy will reject signature within a year, see --audit for details Hit:1 http://deb.debian.org/debian trixie InRelease Hit:2 http://deb.debian.org/debian trixie-updates InRelease Hit:3 http://deb.debian.org/debian-security trixie-security InRelease Hit:4 http://archive.raspberrypi.com/debian trixie InRelease Hit:5 https://apt.grafana.com stable InRelease Hit:6 https://deb.nodesource.com/node_22.x nodistro InRelease Reading package lists... W: https://deb.nodesource.com/node_22.x/dists/nodistro/InRelease: Policy will reject signature within a year, see --audit for details Pending Updates: 4 *** Listening Ports *** Active Internet connections (only servers) Proto Recv-Q Send-Q Local Address Foreign Address State User Inode PID/Program name tcp 0 0 0.0.0.0:139 0.0.0.0:* LISTEN 0 12404 1330/smbd tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 0 11348 1316/sshd: /usr/sbi tcp 0 0 0.0.0.0:111 0.0.0.0:* LISTEN 0 5263 1/init tcp 0 0 0.0.0.0:445 0.0.0.0:* LISTEN 0 12403 1330/smbd tcp 0 0 127.0.0.1:631 0.0.0.0:* LISTEN 0 9831 1296/cupsd tcp 0 0 0.0.0.0:1883 0.0.0.0:* LISTEN 1001 34357 4622/io.mqtt.0 tcp 0 0 127.0.0.1:9000 0.0.0.0:* LISTEN 1001 33041 4410/iobroker.js-co tcp 0 0 127.0.0.1:9001 0.0.0.0:* LISTEN 1001 33036 4410/iobroker.js-co tcp 0 0 0.0.0.0:3306 0.0.0.0:* LISTEN 111 9561 1146/mariadbd tcp 0 0 0.0.0.0:3493 0.0.0.0:* LISTEN 0 9496 1072/upsd tcp6 0 0 :::139 :::* LISTEN 0 12402 1330/smbd tcp6 0 0 :::22 :::* LISTEN 0 11351 1316/sshd: /usr/sbi tcp6 0 0 :::111 :::* LISTEN 0 263 1/init tcp6 0 0 :::445 :::* LISTEN 0 12401 1330/smbd tcp6 0 0 :::5900 :::* LISTEN 985 9551 1098/wayvnc tcp6 0 0 ::1:631 :::* LISTEN 0 9830 1296/cupsd tcp6 0 0 :::3000 :::* LISTEN 113 13620 1260/grafana tcp6 0 0 :::8087 :::* LISTEN 1001 34590 4789/io.simple-api. tcp6 0 0 :::8082 :::* LISTEN 1001 34537 4744/io.web.0 tcp6 0 0 :::8081 :::* LISTEN 1001 33086 4431/io.admin.0 tcp6 0 0 :::3306 :::* LISTEN 111 9562 1146/mariadbd udp 0 0 0.0.0.0:5353 0.0.0.0:* 101 6532 726/avahi-daemon: r udp 0 0 0.0.0.0:5683 0.0.0.0:* 1001 34441 4684/io.shelly.0 udp 0 0 0.0.0.0:39626 0.0.0.0:* 101 6534 726/avahi-daemon: r udp 0 0 0.0.0.0:111 0.0.0.0:* 0 4576 1/init udp 0 0 192.168.178.255:137 0.0.0.0:* 0 8120 1283/nmbd udp 0 0 192.168.178.101:137 0.0.0.0:* 0 8119 1283/nmbd udp 0 0 192.168.178.255:137 0.0.0.0:* 0 8116 1283/nmbd udp 0 0 192.168.178.124:137 0.0.0.0:* 0 8115 1283/nmbd udp 0 0 0.0.0.0:137 0.0.0.0:* 0 8100 1283/nmbd udp 0 0 192.168.178.255:138 0.0.0.0:* 0 8122 1283/nmbd udp 0 0 192.168.178.101:138 0.0.0.0:* 0 8121 1283/nmbd udp 0 0 192.168.178.255:138 0.0.0.0:* 0 8118 1283/nmbd udp 0 0 192.168.178.124:138 0.0.0.0:* 0 8117 1283/nmbd udp 0 0 0.0.0.0:138 0.0.0.0:* 0 8101 1283/nmbd udp6 0 0 fe80::3782:de7b:aa2:546 :::* 0 18298 779/NetworkManager udp6 0 0 fe80::e80d:455f:41e:546 :::* 0 11668 779/NetworkManager udp6 0 0 :::5353 :::* 101 6533 726/avahi-daemon: r udp6 0 0 :::52997 :::* 101 6535 726/avahi-daemon: r udp6 0 0 :::111 :::* 0 5264 1/init *** Log File - Last 25 Lines *** at StatesInMemoryServer.handleSubscribe (file:///opt/iobroker/node_modules/@iobroker/db-base/src/lib/inMemFileDB.ts:323:59) at StatesInMemoryServer._subscribeForClient (file:///opt/iobroker/node_modules/@iobroker/db-states-file/src/lib/states/statesInMemFileDB.js:240:14) at RedisHandler.<anonymous> (file:///opt/iobroker/node_modules/@iobroker/db-states-jsonl/src/lib/states/statesInMemServerRedis.js:380:26) at RedisHandler.emit (node:events:519:28) at RedisHandler.emit (node:domain:489:12) at Immediate._onImmediate (file:///opt/iobroker/node_modules/@iobroker/db-base/src/lib/redisHandler.ts:210:37) at processImmediate (node:internal/timers:485:21) 2026-01-03 12:13:12.361 - error: web.0 (4744) Cannot subscribe "http://raspberrypi01:3000/d/BlDiLtmgk/mobilealerts03?orgId=1&refresh=1m&kiosk": Error The pattern "http://raspberrypi01:3000/d/BlDiLtmgk/mobilealerts03?orgId=1&refresh=1m&kiosk" is not a valid ID pattern 2026-01-03 12:13:15.040 - info: host.raspberrypi01 instance system.adapter.husqvarna-automower.0 in version "0.6.0-beta.12" (non-npm: ice987987/ioBroker.husqvarna-automower#d0df35eeb074d8ffb02a30ee0c27b72b03216108) started with pid 4774 2026-01-03 12:13:15.775 - info: husqvarna-automower.0 (4774) starting. Version 0.6.0-beta.12 (non-npm: ice987987/ioBroker.husqvarna-automower#d0df35eeb074d8ffb02a30ee0c27b72b03216108) in /opt/iobroker/node_modules/iobroker.husqvarna-automower, node: v22.21.0, js-controller: 7.0.7 2026-01-03 12:13:15.784 - info: husqvarna-automower.0 (4774) starting adapter "husqvarna-automower"... 2026-01-03 12:13:15.944 - info: husqvarna-automower.0 (4774) "Husqvarna Authentication API Access token" received. 2026-01-03 12:13:16.221 - info: husqvarna-automower.0 (4774) Mowerdata initially saved. 2026-01-03 12:13:16.275 - info: husqvarna-automower.0 (4774) State value to set for "husqvarna-automower.0.65aee08a-aca4-4d4b-bef4-96ef3ebb40d6.stayOutZones.zones" has to be stringified but received type "object" 2026-01-03 12:13:16.431 - info: husqvarna-automower.0 (4774) Connection to "Husqvarna WebSocket" established. Ready to get data... 2026-01-03 12:13:19.038 - info: host.raspberrypi01 instance system.adapter.simple-api.0 in version "2.8.0" started with pid 4789 2026-01-03 12:13:19.952 - info: simple-api.0 (4789) starting. Version 2.8.0 in /opt/iobroker/node_modules/iobroker.simple-api, node: v22.21.0, js-controller: 7.0.7 2026-01-03 12:13:19.963 - info: simple-api.0 (4789) simpleAPI server listening on port 8087 2026-01-03 12:13:19.963 - info: simple-api.0 (4789) Allow states only when user is owner: false 2026-01-03 12:13:19.970 - info: simple-api.0 (4789) http server listening on port 8087 2026-01-03 12:44:04.927 - warn: tibberlink.0 (4699) Error (Unknown Status) occurred during: -pull of prices tomorrow- : Request timeout for https://api.tibber.com/v1-beta/gql 2026-01-03 12:56:09.790 - info: shelly.0 (4684) [CoAP] Device 192.168.178.6 (shellyflood / shellyflood-441793220A77 / SHWT-1#441793220A77#1) connected! Polltime set to 3600 sec. 2026-01-03 12:57:42.034 - info: daikin-cloud.0 (4607) Daikin-Cloud tokens updated ... 2026-01-03 12:57:42.035 - info: daikin-cloud.0 (4607) Daikin token updated in adapter configuration ... 2026-01-03 13:00:45.685 - info: shelly.0 (4684) [CoAP] Device 192.168.178.5 (shellyflood / shellyflood-4C7525062C2F / SHWT-1#4C7525062C2F#1) connected! Polltime set to 3600 sec.============ Mark until here for C&P =============
iob diag has finished.
Have set up a new raspi 5 with Trixie, with iobroker and MQTT.
Yesterday i did unplug an external SSD from my old raspi which is near by the new one... which ended up in both, the old and new raspi, to get stuck and they did not respond any more.
After reboot everything looks fine, except the MQTT Adapter.
When starting it gets stuck with a yellow warning sign in the list of instdances, with 2 greens and one red behind.
I cannot see any strange thing in the protocol.What i did so far:
iob fix setting log to debug and checking log when stopping and starting the adapter deinstall and reinstall the mqtt-adapterNo change in behaviour.... the adapter simply does not start.
debug-log attached.... the 5 mqtt clients which are listed at end of the start of the adapter are exactly the 5 which i want to track....Any help here ?
@NoPlayBack-0 sagte in MQTT Adapter does not start any more after raspi-crash:
orphan cleanup on readonly fs
das ist weder ein englischer, noch ein deutscher Bug von ioBroker!
-
Nein sie werden nicht ignoriert. Es hat sich überschlagen.
Mea culpa.Aber wieso steht oben auf der Seite bei mir
-
Nein sie werden nicht ignoriert. Es hat sich überschlagen.
Mea culpa.Aber wieso steht oben auf der Seite bei mir
@NoPlayBack-0
Weil es dorthin verschoben wurde. Englischer Post -> englische Sektion. Soll das wieder nach Deutsch? -
uiuiui, ja wenn möglich, ich gelobe Besserung und entschuldige mich.
Meine nächste oder letzte Frage hier wäre nämlich... lässt sich so ein Fehler beheben, kann man einfach die Platte reparieren, oder nehme ich lieber das Backup was ich kurz vorher gemacht habe (das war nämlich der Grund für die SSD am alten Raspi)...
-
S Samson71 verschob dieses Thema von ioBroker general am
-
uiuiui, ja wenn möglich, ich gelobe Besserung und entschuldige mich.
Meine nächste oder letzte Frage hier wäre nämlich... lässt sich so ein Fehler beheben, kann man einfach die Platte reparieren, oder nehme ich lieber das Backup was ich kurz vorher gemacht habe (das war nämlich der Grund für die SSD am alten Raspi)...
@NoPlayBack-0
Ist wieder im Deutschen Bereich, allerdings bei "Pflege des Betriebssystems". Du hast nen Schuss im Dateisystem. @homoran hat Dir das im Beitrag #4 aufgezeigt. Ich würde wohl zum Backup greifen denke ich, sofern das vor den Problemen entstanden ist. -
Sodelle.... raspiBackup zurückgespielt, Fehler immer noch da.
In iob diag ist immer noch die Zeile zu sehen:
[Sat Jan 3 16:46:16 2026] EXT4-fs (nvme0n1p2): orphan cleanup on readonly fsAlso war der Fehler wohl schon beim Backup vorhanden, muss aber sehr sehr kurz vorher entstanden sein weil der MQTT-Adapter bis wenige Minuten vorher noch Daten empfangen hat und die in der db gespeichert wurden.
Das einzige was ich vorher gemacht hatte in dem Zeitraum (wegen dem anderen Problem hier: https://forum.iobroker.net/topic/83446/meldung-auth-could-not-identify-password-for-iobroker) war der Versuch, iob diag laufen zu lassen was wegen Rechteprobleme nicht ging. Ich hatte versucht den User pi zur Gruppe iobroker hinzuzufügen mit "sudo usermod -a -G iobroker pi" was aber auch nicht geholfen hatte.
Dann hatte ich vorsichtshalber ein Backup gemacht und danach erst mit iob fix das Rechteproblem gelöst. Obwohl dort keine Abfrage nach einem User und Passwort kam konnte ich nacher als pi den Befehl iob diag laufen lassen.Wieso läuft alles, nur dieser MQTT bleibt auf gelb hängen ?????
-
Ich hätte hier noch ein Backup aus dem gleichen Moment... ich mache auch immer ein Image mit SDCard-Kopier.... aber das kann ja nichts anderes machen?
Oder wäre das ein Versuch wert ??? -
Sodelle.... raspiBackup zurückgespielt, Fehler immer noch da.
In iob diag ist immer noch die Zeile zu sehen:
[Sat Jan 3 16:46:16 2026] EXT4-fs (nvme0n1p2): orphan cleanup on readonly fsAlso war der Fehler wohl schon beim Backup vorhanden, muss aber sehr sehr kurz vorher entstanden sein weil der MQTT-Adapter bis wenige Minuten vorher noch Daten empfangen hat und die in der db gespeichert wurden.
Das einzige was ich vorher gemacht hatte in dem Zeitraum (wegen dem anderen Problem hier: https://forum.iobroker.net/topic/83446/meldung-auth-could-not-identify-password-for-iobroker) war der Versuch, iob diag laufen zu lassen was wegen Rechteprobleme nicht ging. Ich hatte versucht den User pi zur Gruppe iobroker hinzuzufügen mit "sudo usermod -a -G iobroker pi" was aber auch nicht geholfen hatte.
Dann hatte ich vorsichtshalber ein Backup gemacht und danach erst mit iob fix das Rechteproblem gelöst. Obwohl dort keine Abfrage nach einem User und Passwort kam konnte ich nacher als pi den Befehl iob diag laufen lassen.Wieso läuft alles, nur dieser MQTT bleibt auf gelb hängen ?????
@NoPlayBack-0 sagte in MQTT Adapter does not start any more after raspi-crash:
war der Versuch, iob diag laufen zu lassen was wegen Rechteprobleme nicht ging. Ich hatte versucht den User pi zur Gruppe iobroker hinzuzufügen mit "sudo usermod -a -G iobroker pi" was aber auch nicht geholfen hatte.
Bei einem 'ordentlichen Setup' (bei dem der user pi (bzw. ein anderer Standarduser) verwendet wird) ist der user immer auch in der Gruppe 'iobroker' enthalten.
danach erst mit iob fix das Rechteproblem gelöst. Obwohl dort keine Abfrage nach einem User und Passwort kam konnte ich nacher als pi den Befehl iob diag laufen lassen.
Der 'iob fix' löst kein Rechte-'Problem', weil es da nie 'Probleme' gibt, lediglich nicht korrekt gesetzte Rechte. Der Fixer greift dem Admin des Systems nur etwas unter die Arme und richtet die Rechte für ihn ein.
-
Sodelle.... raspiBackup zurückgespielt, Fehler immer noch da.
In iob diag ist immer noch die Zeile zu sehen:
[Sat Jan 3 16:46:16 2026] EXT4-fs (nvme0n1p2): orphan cleanup on readonly fsAlso war der Fehler wohl schon beim Backup vorhanden, muss aber sehr sehr kurz vorher entstanden sein weil der MQTT-Adapter bis wenige Minuten vorher noch Daten empfangen hat und die in der db gespeichert wurden.
Das einzige was ich vorher gemacht hatte in dem Zeitraum (wegen dem anderen Problem hier: https://forum.iobroker.net/topic/83446/meldung-auth-could-not-identify-password-for-iobroker) war der Versuch, iob diag laufen zu lassen was wegen Rechteprobleme nicht ging. Ich hatte versucht den User pi zur Gruppe iobroker hinzuzufügen mit "sudo usermod -a -G iobroker pi" was aber auch nicht geholfen hatte.
Dann hatte ich vorsichtshalber ein Backup gemacht und danach erst mit iob fix das Rechteproblem gelöst. Obwohl dort keine Abfrage nach einem User und Passwort kam konnte ich nacher als pi den Befehl iob diag laufen lassen.Wieso läuft alles, nur dieser MQTT bleibt auf gelb hängen ?????
@NoPlayBack-0 sagte in MQTT Adapter does not start any more after raspi-crash:
Also war der Fehler wohl schon beim Backup vorhanden
nöö, die Platte scheint massive Probleme zu haben, und/oder die Einschläge sind in Dateien vom OS, node.js...ä
-
so und jetzt wird es richtig komisch... habe gerade nachgeguckt, der MQTT-Adapter auf dem alten Raspi (den hatte ich deaktivert) zeigt jetzt das gleiche Verhalten, wird nicht grün.
Der MQTT-Adapter auf einem dritten Raspi ebenfalls, bleibt auf gelb.
Ich bin ratlos ... -
Sodelle.... raspiBackup zurückgespielt, Fehler immer noch da.
In iob diag ist immer noch die Zeile zu sehen:
[Sat Jan 3 16:46:16 2026] EXT4-fs (nvme0n1p2): orphan cleanup on readonly fsAlso war der Fehler wohl schon beim Backup vorhanden, muss aber sehr sehr kurz vorher entstanden sein weil der MQTT-Adapter bis wenige Minuten vorher noch Daten empfangen hat und die in der db gespeichert wurden.
Das einzige was ich vorher gemacht hatte in dem Zeitraum (wegen dem anderen Problem hier: https://forum.iobroker.net/topic/83446/meldung-auth-could-not-identify-password-for-iobroker) war der Versuch, iob diag laufen zu lassen was wegen Rechteprobleme nicht ging. Ich hatte versucht den User pi zur Gruppe iobroker hinzuzufügen mit "sudo usermod -a -G iobroker pi" was aber auch nicht geholfen hatte.
Dann hatte ich vorsichtshalber ein Backup gemacht und danach erst mit iob fix das Rechteproblem gelöst. Obwohl dort keine Abfrage nach einem User und Passwort kam konnte ich nacher als pi den Befehl iob diag laufen lassen.Wieso läuft alles, nur dieser MQTT bleibt auf gelb hängen ?????
@NoPlayBack-0 sagte in MQTT Adapter does not start any more after raspi-crash:
In iob diag ist immer noch die Zeile zu sehen:
[Sat Jan 3 16:46:16 2026] EXT4-fs (nvme0n1p2): orphan cleanup on readonly fsWas heißt immer noch? Das ist ein neuer Eintrag. Es wurden also bei diesem Boot weitere/neue verwaiste Einträge gelöscht.
Spricht für einen wurmstichigen Datenträger, wenn der Neustart ordentlich durchgeführt wurde jedenfalls. -
Link zum gleichlautenden Issue: https://github.com/ioBroker/ioBroker.mqtt/issues/582
-
so und jetzt wird es richtig komisch... habe gerade nachgeguckt, der MQTT-Adapter auf dem alten Raspi (den hatte ich deaktivert) zeigt jetzt das gleiche Verhalten, wird nicht grün.
Der MQTT-Adapter auf einem dritten Raspi ebenfalls, bleibt auf gelb.
Ich bin ratlos ...Betriebst du den mqtt Adapter als client oder als server?
Wenn der Adapter als Server / Broker läuft:
Hast du ggF die IP Addressen bei den clients angepasst? Ein neuer Rechner hat ja mit einer gewissen Wahrscheinlichkeit eine neue IP. Ohne Anpassen der clients werden die den nicht finden. -
Jupp... habe ich, bzw. die nutzen keine IP sondern DNS, aber ja, die IPs habe ich tatsächlich bei den Raspis manuell und fix vergeben. Der Adapter läuft als Server/Broker.
Und... die liefen nach der ganzen Umstellung ja auch bis gestern abend.... -
Neee nä ?
Meine Gedanken gingen in die gleiche Richtung daher war ich gerade dabei und habe einen Client umprogrammiert auf die fixe Adresse.... und zack, der Adapter wird grün.
In meiner FritzBox gibt es gerade im Netzwerk 2 Geräte mit unterschiedlichen IPs, aber sie haben den gleichen Netzwerknamen !?!?!?!?!?
Nachtrag: Eins ist das WLAN das andere kabelgebunden.....
Nachtrag2: .... und damit zu früh gefreut... WLAN abgeschaltet (wie ich es bei den anderen Raspis auch hatte), wieder versucht den Server/Broker mit Netzwerknamen anzusprechen, es kommt kein Connect, die Clients können sich nicht verbinden...
Morgen ist auch noch ein Tag. -
so, neuer Tag neues Glück:
Erst einmal vielen Dank an die super Unterstützung hier, ich weiß jetzt wo die Ursache ist, beheben konnte ich sie noch nicht.
Ich hatte beim Umbau von alt auf neu ein paar mal IPs und Namen der Netzwerkgeräte gewechselt, mit dem Ziel, dem Haupt-Raspi die gleiche IP und den gleichen Namen zu geben wie vorher.
In der Fritzbox ist nun bei den Geräteinformationen zwar der richtige Name eingetragen, aber es gibt dort auch einen Eintrag "Erstverbindung ins Heimnetz als:" und dort steht der Name-02 drinne... ich vermute das ist der Name den ich beim ersten Start von Trixie vergeben hatte.
Wenn ich heute mit tracert IP in einem Windows-Terminal nachschaue dann kommt dort die Rückmeldung, dass unter der IP das Gerät Name-02 ist.
Wenn ich tracert Name teste kommt das gleiche Ergebnis, mit tracert Name-02 gibt es "Name konnte nicht aufgelöst werden".
Ein ping klappt mit beiden Namen.
Wenn ich einen MQTT-Client programmiere mit dem Namen, kann keine Verbindung aufgebaut werden.
Wenn ich einen MQTT-Client programmiere mit dem Namen-02, dann wird eine Verbindung aufgebaut.
Mit IP natürlich auch.Ich vermute dass beim crash gar nix passiert ist... außer dass der neue raspi halt neu gestartet werden musste und er ab dem Zeitpunkt dann mit dieser Situation nicht mehr klarkommt... bzw. der Adapter.
Langer Rede kurzer Sinn: Ich würde mich freuen Hilfe zu bekommen die Ursache zu finden und auch zu beheben, aber das ist ja jetzt eigentlich ein anderes Thema. Ich möchte nicht einfach nur in den Clients jetzt die IPs eintragen, ich würde gerne beim Namen bleiben, daher muss ich mal herausfinden wie ich das löse.
Eine viel wichtigere Frage die hier vielleicht noch hinpasst:
Ihr habt mir ja jetzt gezeigt dass meine Platte offensichtlich Kummer hat. Wo kann ich da mehr lesen bzgl. SSD-Test, SSD-Health, Ursachen-Analyse?
An der Stelle noch ein kleiner Hinweis: Ich habe in der config.txt das pciex1_gen=3 gesetzt um die Geschwindigkeit höher zu zwingen... in einem anderen Forum wurde mir gesagt dass das alle machen und bis jetzt noch keine Schwierigkeiten bekannt sind...oder gibt es hier eine andere Meinung ? -
so, neuer Tag neues Glück:
Erst einmal vielen Dank an die super Unterstützung hier, ich weiß jetzt wo die Ursache ist, beheben konnte ich sie noch nicht.
Ich hatte beim Umbau von alt auf neu ein paar mal IPs und Namen der Netzwerkgeräte gewechselt, mit dem Ziel, dem Haupt-Raspi die gleiche IP und den gleichen Namen zu geben wie vorher.
In der Fritzbox ist nun bei den Geräteinformationen zwar der richtige Name eingetragen, aber es gibt dort auch einen Eintrag "Erstverbindung ins Heimnetz als:" und dort steht der Name-02 drinne... ich vermute das ist der Name den ich beim ersten Start von Trixie vergeben hatte.
Wenn ich heute mit tracert IP in einem Windows-Terminal nachschaue dann kommt dort die Rückmeldung, dass unter der IP das Gerät Name-02 ist.
Wenn ich tracert Name teste kommt das gleiche Ergebnis, mit tracert Name-02 gibt es "Name konnte nicht aufgelöst werden".
Ein ping klappt mit beiden Namen.
Wenn ich einen MQTT-Client programmiere mit dem Namen, kann keine Verbindung aufgebaut werden.
Wenn ich einen MQTT-Client programmiere mit dem Namen-02, dann wird eine Verbindung aufgebaut.
Mit IP natürlich auch.Ich vermute dass beim crash gar nix passiert ist... außer dass der neue raspi halt neu gestartet werden musste und er ab dem Zeitpunkt dann mit dieser Situation nicht mehr klarkommt... bzw. der Adapter.
Langer Rede kurzer Sinn: Ich würde mich freuen Hilfe zu bekommen die Ursache zu finden und auch zu beheben, aber das ist ja jetzt eigentlich ein anderes Thema. Ich möchte nicht einfach nur in den Clients jetzt die IPs eintragen, ich würde gerne beim Namen bleiben, daher muss ich mal herausfinden wie ich das löse.
Eine viel wichtigere Frage die hier vielleicht noch hinpasst:
Ihr habt mir ja jetzt gezeigt dass meine Platte offensichtlich Kummer hat. Wo kann ich da mehr lesen bzgl. SSD-Test, SSD-Health, Ursachen-Analyse?
An der Stelle noch ein kleiner Hinweis: Ich habe in der config.txt das pciex1_gen=3 gesetzt um die Geschwindigkeit höher zu zwingen... in einem anderen Forum wurde mir gesagt dass das alle machen und bis jetzt noch keine Schwierigkeiten bekannt sind...oder gibt es hier eine andere Meinung ?@NoPlayBack-0 sagte in MQTT Adapter does not start any more after raspi-crash:
In der Fritzbox ist nun bei den Geräteinformationen zwar der richtige Name eingetragen
Dann lösch die Doublette dort raus.
-
so, neuer Tag neues Glück:
Erst einmal vielen Dank an die super Unterstützung hier, ich weiß jetzt wo die Ursache ist, beheben konnte ich sie noch nicht.
Ich hatte beim Umbau von alt auf neu ein paar mal IPs und Namen der Netzwerkgeräte gewechselt, mit dem Ziel, dem Haupt-Raspi die gleiche IP und den gleichen Namen zu geben wie vorher.
In der Fritzbox ist nun bei den Geräteinformationen zwar der richtige Name eingetragen, aber es gibt dort auch einen Eintrag "Erstverbindung ins Heimnetz als:" und dort steht der Name-02 drinne... ich vermute das ist der Name den ich beim ersten Start von Trixie vergeben hatte.
Wenn ich heute mit tracert IP in einem Windows-Terminal nachschaue dann kommt dort die Rückmeldung, dass unter der IP das Gerät Name-02 ist.
Wenn ich tracert Name teste kommt das gleiche Ergebnis, mit tracert Name-02 gibt es "Name konnte nicht aufgelöst werden".
Ein ping klappt mit beiden Namen.
Wenn ich einen MQTT-Client programmiere mit dem Namen, kann keine Verbindung aufgebaut werden.
Wenn ich einen MQTT-Client programmiere mit dem Namen-02, dann wird eine Verbindung aufgebaut.
Mit IP natürlich auch.Ich vermute dass beim crash gar nix passiert ist... außer dass der neue raspi halt neu gestartet werden musste und er ab dem Zeitpunkt dann mit dieser Situation nicht mehr klarkommt... bzw. der Adapter.
Langer Rede kurzer Sinn: Ich würde mich freuen Hilfe zu bekommen die Ursache zu finden und auch zu beheben, aber das ist ja jetzt eigentlich ein anderes Thema. Ich möchte nicht einfach nur in den Clients jetzt die IPs eintragen, ich würde gerne beim Namen bleiben, daher muss ich mal herausfinden wie ich das löse.
Eine viel wichtigere Frage die hier vielleicht noch hinpasst:
Ihr habt mir ja jetzt gezeigt dass meine Platte offensichtlich Kummer hat. Wo kann ich da mehr lesen bzgl. SSD-Test, SSD-Health, Ursachen-Analyse?
An der Stelle noch ein kleiner Hinweis: Ich habe in der config.txt das pciex1_gen=3 gesetzt um die Geschwindigkeit höher zu zwingen... in einem anderen Forum wurde mir gesagt dass das alle machen und bis jetzt noch keine Schwierigkeiten bekannt sind...oder gibt es hier eine andere Meinung ?@NoPlayBack-0 sagte in MQTT Adapter does not start any more after raspi-crash:
pciex1_gen=3
Dazu nur:
- Gen3 is not officially supported. This is high frequency stuff, so running with Gen3 on a system laid out for Gen2 might or might not work and you are expected to get random errors.
- I am still waiting for a real-life usage-scenario that gives you an advantage with Gen3 over Gen2. And if you need this additional performance, than I question that the Pi5 is a good basis for your needs.
Würde ich also auf einem System, das stabil laufen soll und nicht als Experimentierfeld dient nicht setzen.
Ich sehe gerade, dass du dir da einen ganzen Blumenstrauß an wilden Einstellungen reingeklatscht hast. Kein Wunder, dass die Kiste seltsam läuft.
-
@NoPlayBack-0 sagte in MQTT Adapter does not start any more after raspi-crash:
pciex1_gen=3
Dazu nur:
- Gen3 is not officially supported. This is high frequency stuff, so running with Gen3 on a system laid out for Gen2 might or might not work and you are expected to get random errors.
- I am still waiting for a real-life usage-scenario that gives you an advantage with Gen3 over Gen2. And if you need this additional performance, than I question that the Pi5 is a good basis for your needs.
Würde ich also auf einem System, das stabil laufen soll und nicht als Experimentierfeld dient nicht setzen.
Ich sehe gerade, dass du dir da einen ganzen Blumenstrauß an wilden Einstellungen reingeklatscht hast. Kein Wunder, dass die Kiste seltsam läuft.
Das Feld lässt sich in der Fritzbox nicht editieren !
@Thomas-Braun sagte in MQTT Adapter does not start any more after raspi-crash:
Ich sehe gerade, dass du dir da einen ganzen Blumenstrauß an wilden Einstellungen reingeklatscht hast. Kein Wunder, dass die Kiste seltsam läuft.
What ? Wo ? Was ? Außer diesem einen Eintrag weiß ich von nix ?
-
Das Feld lässt sich in der Fritzbox nicht editieren !
@Thomas-Braun sagte in MQTT Adapter does not start any more after raspi-crash:
Ich sehe gerade, dass du dir da einen ganzen Blumenstrauß an wilden Einstellungen reingeklatscht hast. Kein Wunder, dass die Kiste seltsam läuft.
What ? Wo ? Was ? Außer diesem einen Eintrag weiß ich von nix ?
[Sat Jan 3 11:51:27 2026] Kernel command line: reboot=w coherent_pool=1M 8250.nr_uarts=1 pci=pcie_bus_safe cgroup_disable=memory numa_policy=interleave nvme.max_host_mem_size_mb=0 numa=fake=8 system_heap.max_order=0 smsc95xx.macaddr=2C:CF:67:9E:6A:69 vc_mem.mem_base=0x3fc00000 vc_mem.mem_size=0x40000000 console=ttyAMA10,115200 console=tty1 root=PARTUUID=b035d9c0-02 rootfstype=ext4 fsck.repair=yes rootwait quiet splash plymouth.ignore-serial-consoles cfg80211.ieee80211_regdom=DEBei mir (Allerdings ein RPI4)
[Fri Dec 26 23:39:09 2025] Kernel command line: coherent_pool=1M 8250.nr_uarts=1 snd_bcm2835.enable_headphones=0 cgroup_disable=memory numa_policy=interleave nvme.max_host_mem_size_mb=0 snd_bcm2835.enable_headphones=1 snd_bcm2835.enable_hdmi=1 snd_bcm2835.enable_hdmi=0 numa=fake=2 system_heap.max_order=0 smsc95xx.macaddr=E4:5F:01:0B:F7:93 vc_mem.mem_base=0x3eb00000 vc_mem.mem_size=0x3ff00000 console=tty1 root=PARTUUID=68a5cb8b-02 rootfstype=ext4 fsck.repair=yes rootwaitUnterschied: Mein System läuft stabil, deins verhält sich seltsam.
Support us
478
Online32.6k
Benutzer82.0k
Themen1.3m
Beiträge