Seit ich eine Erweiterung nutze, die Fühlerausfälle per Telegram meldet, ist mir aufgefallen: Meine DS18B20-Fühler am VanPi zeigen nachts über mehrere Stunden „N/A“. Den Ausfall gab es vermutlich schon länger, sichtbar wurde er erst durch die Meldungen.
Ursache bei mir: Auf dem VanPi läuft ein Plex Media Server. Dessen nächtliche Wartung (Lautstärke-Analyse der Filme) legt den 1-Wire-Bus lahm. Verlege ich das Wartungsfenster, wandern die Ausfälle mit. Beende ich die Analyse, sind die Werte sofort wieder da.
Hintergrund: Die DS18B20 hängen per dtoverlay=w1-gpio am Pi. Der Pi erzeugt das 1-Wire-Timing dabei selbst per Software. Beim Raspberry Pi 5 sitzen die GPIO-Pins nicht direkt am Prozessor, sondern am Zusatzchip RP1. Unter bestimmter Last kommen die Pulse offenbar nicht mehr pünktlich: Die Fühler bleiben angemeldet, liefern aber keine Messung. Reine Rechenlast störte in meinen Tests nicht, starker Arbeitsspeicherverkehr teilweise, die Plex-Analyse fast vollständig. Der genaue Mechanismus ist eine Vermutung, nicht gemessen. Passend dazu der Forumsfaden „RPi 5 1-Wire / DS18B20 is unstable [SOLVED]“ (forums.raspberrypi.com, t=362339). Dort schreibt ein Raspberry-Pi-Entwickler zu Fehlern unter Last: „This is expected … Linux is not a realtime operating system.“
Messung: Die Fühler habe ich direkt aus /sys/bus/w1/devices/28-*/w1_slave gelesen. „gut“ heißt: Messwert mit gültiger Prüfsumme.
| Last während der Messung | gut | fehler |
|---|---|---|
| ohne Zusatzlast | 600 | 0 |
| 2 CPU-Kerne voll + Film von USB-Platte lesen, 15 min | 600 | 0 |
| Film von USB-Platte auf NVMe kopieren | 179 | 1 |
| Plex Transcoder, Lautstärke-Analyse einer Kopie auf NVMe (ohne USB) | 1 | 381 |
reiner Speicherverkehr (2× dd if=/dev/zero bs=64M), 5 min |
265 | 35 |
Abhilfe bei mir: Plex-Analysen abgeschaltet. Ob das reicht, beobachte ich noch. Unabhängig von der Last wäre wohl nur ein eigener 1-Wire-Baustein mit eigenem Timing, zum Beispiel ein DS2482 am I²C. Das habe ich nicht getestet.