Raspberry Pi um Echtzeituhr (RTC) erweitern – HW-111

Diese Seite beschreibt die Nachrüstung einer batteriegepufferten Echtzeituhr (RTC) am Raspberry Pi mit dem verbreiteten HW-111-Modul, siehe auch Hauptanleitung, Teil 2.

Warum das nötig ist: Der Raspberry Pi hat werksseitig keine batteriegepufferte Uhr. Im isolierten Messnetz ohne Internetzugang kann er sich zudem nicht per NTP die korrekte Uhrzeit holen. Nach jedem Neustart oder Stromausfall fällt die Systemzeit daher auf einen falschen Wert zurück – neue EmonCMS-Feed-Daten bekommen dann falsche Zeitstempel und erscheinen in Diagrammen/CSV-Exports als fehlend, obwohl sie eigentlich geschrieben wurden.

Das HW-111 ist eine verbreitete, günstige RTC-Platine mit zwei separaten I²C-Bausteinen:

• DS1307 – der eigentliche Echtzeituhr-Chip, I²C-Adresse 0x68
• AT24C32 – ein zusätzlicher EEPROM-Speicherbaustein auf derselben Platine, I²C-Adresse 0x50 (wird für die RTC-Funktion selbst nicht gebraucht, stört aber auch nicht)
• Batteriehalter für eine CR2032-Knopfzelle

Sicherheitshinweis zu HW-111-Modulen: Manche Platinenversionen
besitzen einen (unbestückten oder bestückten) Ladewiderstand für
wiederaufladbare Akkus. Eine normale CR2032-Knopfzelle ist NICHT
wiederaufladbar - wird sie dauerhaft "geladen", besteht Überhitzungs-
und Explosionsgefahr! Vor Erstinbetriebnahme das Modul auf einen
Ladewiderstand (meist mit "R" beschriftet, in der Nähe der Batterie)
prüfen. Falls vorhanden und eine normale CR2032 verwendet wird,
diesen Widerstand auslöten oder ein Modul ohne Ladeschaltung nutzen.
Im Zweifel beim Platinenhersteller/Datenblatt nachsehen.

Falls am Pi noch nicht geschehen, zuerst per SSH mit dem Pi verbinden.

Der Pi hängt im isolierten Arduino-Messnetz der FRITZ!Box (siehe Hauptanleitung, Teil 1 & 2). Der eigene Rechner muss dafür nicht im selben WLAN wie der Pi sein – ein per LAN-Kabel an dieselbe FRITZ!Box angeschlossener Rechner reicht, da LAN und WLAN der FRITZ!Box intern ein gemeinsames Netz bilden.

1. LAN-Kabel vom eigenen Rechner zur FRITZ!Box stecken
2. In der FRITZ!Box-Oberfläche (z. B. http://192.168.1.1) unter Heimnetz → Netzwerk → Netzwerkverbindungen die IP-Adresse des Pi ablesen (Eintrag „emonpi„, z. B. 192.168.1.2 – bei fester IP-Vergabe immer dieselbe Adresse)
3. Terminal öffnen und per SSH verbinden:

ssh pi@192.168.1.2

  (Adresse ggf. anpassen; Passwort wie in der Hauptanleitung/Zugänge-Checkliste hinterlegt)

Häufiger Stolperstein: "ssh: connect to host ... port 22:
No route to host" bzw. die Verbindung kommt gar nicht erst zustande,
obwohl das LAN-Kabel korrekt steckt. Ursache ist fast immer, dass
der eigene Laptop keine automatische DHCP-Adresse von der FRITZ!Box
bekommen hat und stattdessen bei einer Ersatzadresse im Bereich
169.254.x.x hängengeblieben ist (Linux vergibt diese automatisch,
wenn kein DHCP-Server antwortet). Prüfen mit:

ip addr show eth0

Steht dort "inet 169.254.x.x" statt einer 192.168.1.x-Adresse, hilft
eine manuell gesetzte Adresse im richtigen Bereich:

sudo ip addr add 192.168.1.21/24 dev eth0
ping -c 3 192.168.1.1

(Adresse ggf. anpassen, falls 192.168.1.21 schon von einem anderen
Gerät belegt ist. Danach das FRITZ!Box-Webinterface bzw. die
SSH-Verbindung erneut versuchen.)

Sobald die SSH-Sitzung steht, die folgenden Befehle direkt darin ausführen:

sudo raspi-config

→ „Interface Options“ → „I2C„ → aktivieren, dann das Menü verlassen und neu starten:

sudo reboot

sudo nano /boot/firmware/config.txt

Am Ende folgende Zeilen ergänzen:

# 5. Zeitmodule
dtoverlay=i2c-rtc,ds1307

Tipp zum Einfügen: In vielen Linux-Terminals lässt sich Text aus der
Zwischenablage mit Umschalt+Strg+V direkt in nano einfügen (statt der
sonst in grafischen Anwendungen üblichen Strg+V-Kombination, die in
Terminals oft anders belegt ist). Das funktioniert auch für mehrzeilige
Blöcke wie den obigen in einem Rutsch.

Speichern (Strg+O, Enter) und Editor verlassen (Strg+X), dann neu starten:

sudo reboot

Nach dem Neustart:

sudo i2cdetect -y 1

Es sollten zwei Einträge erscheinen:

• 50 → AT24C32 (EEPROM, kann ignoriert werden)
• An Adresse 68 steht „UU“ statt einer Zahl – das ist der korrekte Erfolgsfall, kein Fehler! „UU“ bedeutet, dass der DS1307-Kernel-Treiber die Adresse bereits „belegt“ hat (durch den in Schritt 3 eingetragenen Overlay), weshalb i2cdetect sie nicht mehr direkt abfragen kann

Zusätzlicher Bestätigungstest:

ls -la /dev/rtc*
sudo hwclock -r

Der erste Befehl sollte /dev/rtc0 anzeigen, der zweite die aktuell auf der RTC gespeicherte Zeit ausgeben (an dieser Stelle, vor Schritt 6, ist ein noch falsches/altes Datum normal).

Taucht weder 50 noch UU/68 auf, siehe Stolpersteine unten.

Die vorinstallierte Software-Ersatzuhr würde sonst mit der echten RTC kollidieren:

sudo apt-get -y remove fake-hwclock
sudo systemctl disable fake-hwclock

Hinweis: Bei neueren, Debian-"trixie"-basierten emonSD-Images ist
"fake-hwclock" teils gar nicht erst installiert - dann meldet der
Befehl "Package 'fake-hwclock' is not installed, so not removed"
und "Failed to disable unit: ... does not exist". Das ist unkritisch
und kein Fehler: Ohne fake-hwclock gibt es schlicht nichts, was mit
der echten RTC kollidieren könnte - dieser Schritt kann dann einfach
übersprungen werden.

Voraussetzung: Das Kommando "hwclock" wird ab hier gebraucht. Bei
aktuellen emonSD-Images (Debian "trixie") fehlt es oft standardmäßig
- siehe Stolperstein "sudo: hwclock: command not found" weiter unten,
falls "sudo hwclock -r" mit einer Fehlermeldung statt einer Zeitangabe
antwortet.

Aktuelle, korrekte Uhrzeit manuell setzen (Datum/Uhrzeit anpassen):

sudo date -s "JJJJ-MM-TT HH:MM:SS"

Auf die RTC schreiben, damit sie dauerhaft erhalten bleibt:

sudo hwclock -w

Pi neu starten:

sudo reboot

Direkt danach (vor einer eventuellen manuellen Korrektur) prüfen:

date

Zeigt das Datum jetzt korrekt an, funktioniert die RTC – der Pi behält die Uhrzeit ab sofort auch über Neustarts und Stromausfälle hinweg, ganz ohne Internet.

Genauigkeit: Ein DS1307 geht über Monate hinweg um einige Sekunden
bis wenige Minuten nach/vor - für Klimadaten mit 20-300 Sekunden
Auflösung ist das unproblematisch. Bei Bedarf die Zeit gelegentlich
(z. B. einmal im Schulhalbjahr) manuell nachstellen (Schritt 6
wiederholen).

Für den Kofferbetrieb praktisch: ein einfacher Taster, mit dem sich der Pi sauber herunterfahren lässt, ohne Laptop/SSH mitbringen zu müssen. Raspberry Pi OS bringt dafür einen fertigen Mechanismus mit.

Wichtiger Pin-Hinweis: Der Standard-Pin für diese Funktion ist
eigentlich GPIO3 (Pin 5) - genau der wird hier aber bereits für die
I²C-Verbindung zur RTC verwendet! Deshalb einen anderen, freien Pin
nehmen, z. B. GPIO17 (Pin 11).

Einschränkung dabei: Nur GPIO3 kann den Pi aus dem vollständig
heruntergefahrenen Zustand per Tastendruck auch wieder EINSCHALTEN
(feste Hardware-Eigenschaft des SoC, kein Software-Feature). Mit
GPIO17 funktioniert nur das saubere HERUNTERFAHREN per Knopfdruck -
zum Wiedereinschalten bleibt es beim Ein-/Ausschalten über die
Steckdosenleiste. Für den Koffer-Einsatz reicht das aber völlig.

1. Per SSH verbinden, Konfigurationsdatei öffnen:

sudo nano /boot/firmware/config.txt

1. Am Ende ergänzen:

# 6. Shutdown-Taster
dtoverlay=gpio-shutdown,gpio_pin=17,active_low=1,gpio_pull=up

  Speichern (Strg+O, Enter) und Editor verlassen (Strg+X)
- **Sauber herunterfahren** (NICHT ''reboot'' – der Pi muss für die Verkabelung stromlos sein):

sudo shutdown -h now

1. Warten, bis die grüne Aktivitäts-LED dauerhaft aus ist, dann Steckdosenleiste ausschalten bzw. Stromkabel ziehen
2. Taster zwischen Pin 11 (GPIO17) und einem beliebigen GND-Pin (z. B. Pin 9) anschließen – kein zusätzlicher Widerstand nötig, der interne Pull-up wird durch gpio_pull=up aktiviert
3. Steckdosenleiste wieder einschalten – der Pi bootet neu, die config.txt-Änderung wird dabei automatisch aktiv

Verhalten: Ein kurzer Tastendruck löst einen sauberen Shutdown aus (wie sudo shutdown -h now). Die grüne Aktivitäts-LED erlischt, sobald es sicher ist, den Strom zu trennen.

• i2cdetect zeigt gar nichts (weder 50 noch UU/68): I²C wahrscheinlich nicht aktiviert (Schritt 2 wiederholen) oder Verkabelung vertauscht (SDA/SCL prüfen)
• Adresse 68 zeigt eine normale Zahl statt „UU“: Das würde bedeuten, dass sich (noch) kein Treiber an die RTC gebunden hat – Overlay-Eintrag in config.txt auf Tippfehler prüfen (cat /boot/firmware/config.txt) und sicherstellen, dass nach dem Speichern wirklich neu gestartet wurde
• Nach hwclock -w und Neustart trotzdem falsches Datum: Prüfen, ob fake-hwclock wirklich vollständig entfernt/deaktiviert ist (Schritt 5) – ein noch aktiver fake-hwclock-Dienst kann die RTC-Zeit beim Boot überschreiben
• Reihenfolge vertauscht (Zeit gesetzt, aber reboot vor hwclock -w): Die mit date -s gesetzte Zeit gilt nur im Arbeitsspeicher und geht bei einem Neustart verloren, wenn sie nicht vorher per hwclock -w auf die RTC geschrieben wurde – dann Schritt 6 wiederholen
• sudo: hwclock: command not found: Bei aktuellen, Debian-„trixie“-basierten emonSD-Images (Stand 2026) ist hwclock nicht mehr automatisch installiert – das Kommando wurde in ein separates Paket util-linux-extra ausgelagert. Da das isolierte Messnetz bewusst kein Internet hat, braucht es dafür kurzzeitig eine zusätzliche Verbindung mit Internetzugang:
  1. Ein LAN-Kabel vom Pi zu einem Router mit Internetzugang stecken – das bestehende WLAN „SAS-ARDUINO(-mobil)“ bleibt dabei unverändert aktiv, beide Verbindungen laufen parallel, die SSH-Sitzung über das isolierte Netz wird nicht unterbrochen
  2. Kurz testen: ping -c 3 8.8.8.8
  3. Dann installieren: sudo apt update && sudo apt install -y util-linux-extra
  4. LAN-Kabel danach wieder abziehen – das isolierte Konzept bleibt für den Dauerbetrieb bestehen, das Kabel war nur für diesen einmaligen Installationsschritt nötig
• Batterie nach einigen Jahren leer: CR2032 ist eine Standard-Knopfzelle, im Handel überall erhältlich – einfacher Tausch, danach Schritt 6 (Zeit setzen) einmalig wiederholen