Files
ki 28124c5617 Initial commit: epaper-dashboard for 7.3" ACeP 7-Color display
- dashboard.py: plugin-based renderer with 4x4 grid layout
- admin.py: web UI with layout editor + plugin configs
- layout.py: pack algorithm, item placement, grid system
- plugins/: clock, weather, system, spotify, strava, gmail, minimax, hello
- network_watchdog.py: WiFi AP/client mode management
- waveshare_epd_init.py: vendor driver stub
2026-08-26 14:12:43 +04:00

1.9 KiB

Recovery wenn der Pi nicht mehr per SSH erreichbar ist

Was passiert ist

  • Auf dem Pi lief ein WLAN mit SSID IoT, Profil-Name netplan-wlan0-IoT
  • Recovery-AP-Test über nmcli device wifi hotspot hat einen WLAN-Hotspot epaper-test gestartet
  • Dies hat wahrscheinlich die WLAN-Verbindung zum Heimnetz unterbrochen
  • SSH-Connect zum Pi schlägt jetzt fehl (Timeout)

Sofortige Hilfe

Option A: Strom-Reset

  1. Pi vom Strom trennen
  2. 10 Sekunden warten
  3. Strom wieder rein
  4. Pi bootet → NetworkManager verbindet sich automatisch mit IoT (sofern in Reichweite)
  5. Nach ~60 Sekunden: ssh koptikp@10.11.3.144 sollte wieder gehen

Option B: Recovery-Hotspot

Falls Strom-Reset nicht hilft (z.B. weil Profil netplan-wlan0-IoT kaputt ist):

  1. Auf dem Laptop WLAN-Liste scannen
  2. epaper-recovery suchen (Passwort recovery1234) — falls der Pi im Recovery-Modus ist oder
  3. epaper-test suchen (Passwort test1234) — falls der Test-Hotspot noch läuft
  4. Verbinden, dann im Browser http://10.42.0.1:8080
  5. Bei Auth-Prompt: admin:changeme123 (oder admin:admin)
  6. Im Netzwerk-Panel: WLAN neu konfigurieren oder "Force AP Mode" / "Disconnect"

Option C: Tastatur + Monitor

  1. HDMI + USB-Tastatur an den Pi
  2. Anmelden als koptikp
  3. sudo nmcli connection show → sehen was aktiv ist
  4. sudo nmcli connection down epaper-test (oder welcher Müll-Profile da sind)
  5. sudo nmcli connection delete epaper-test
  6. sudo nmcli connection up netplan-wlan0-IoT
  7. sudo reboot

Was ich anders machen würde

  • Hotspot-Tests nie auf einem produktiven Pi laufen lassen, ohne physischen Zugang als Fallback zu haben
  • Watchdog-Code war korrekt; das Problem ist die PolicyKit-Konfiguration
  • Polkit-Restart nach Rule-Update: besser nur polkitd SIGHUP schicken, nicht systemctl restart (das hat in dieser Session offenbar den Polkit-Daemon in einem inkonsistenten Zustand hinterlassen)