fix(station): SPI in setup_pi.sh automatisch einschalten
Auf frischem Raspberry Pi OS ist SPI aus, das E-Paper bleibt schwarz mit irrefuehrender "nicht verfuegbar"-Meldung. setup_pi.sh erkennt jetzt beide config.txt-Pfade, normalisiert dtparam=spi=on (fehlend/auskommentiert/off), sichert vorher nach config.txt.bak-ninlight und weist nur bei echter Aenderung auf den noetigen Neustart hin.
This commit is contained in:
+122
-2
@@ -210,6 +210,112 @@ else
|
||||
fi
|
||||
REMOTE
|
||||
|
||||
echo "== SPI aktivieren =="
|
||||
# Auf einem frischen Raspberry Pi OS ist SPI ausgeschaltet: dtparam=spi=on steht
|
||||
# auskommentiert in der Boot-Konfiguration, /dev/spidev0.0 fehlt, und der Anzeigedienst
|
||||
# meldet "E-Paper-Anzeige nicht verfuegbar" - das sieht nach fehlender Hardware aus,
|
||||
# ist aber nur ein abgeschalteter Bus. Ohne diesen Schritt haette jede frische Station
|
||||
# ein schwarzes Panel, bis jemand von Hand nachhilft (wie hier gestern geschehen).
|
||||
#
|
||||
# Die Aenderung wirkt erst nach einem Neustart der Boot-Konfiguration - das Skript
|
||||
# startet den Pi NICHT selbst neu (ein unerwarteter Reboot mitten in einer Fernsitzung
|
||||
# waere ueberraschender als ein Hinweis am Ende), meldet ueber den Exit-Code des
|
||||
# Remote-Blocks aber, ob einer noetig war (10 = geaendert, 0 = schon an, 20 = keine
|
||||
# Boot-Konfiguration gefunden). $SPI_REBOOT_NEEDED steuert unten, ob der Hinweis in den
|
||||
# naechsten Schritten erscheint - nur dann, wenn wirklich etwas geaendert wurde.
|
||||
SPI_REBOOT_NEEDED=0
|
||||
set +e
|
||||
"$SSH_BIN" "$HOST" bash -s <<'REMOTE'
|
||||
set -e
|
||||
# Ueberschreibbar wie die anderen NINLIGHT_*-Pfade oben: auf dem Pi bleibt es bei den
|
||||
# echten Pfaden, ein Test kann hier gegen Sandbox-Dateien statt gegen echte
|
||||
# Systempfade laufen.
|
||||
SPIDEV=${NINLIGHT_SPIDEV_PATH:-/dev/spidev0.0}
|
||||
CONFIG_NEW=${NINLIGHT_BOOT_CONFIG_NEW:-/boot/firmware/config.txt}
|
||||
CONFIG_OLD=${NINLIGHT_BOOT_CONFIG_OLD:-/boot/config.txt}
|
||||
|
||||
# Existiert das Geraeteknoten schon, ist SPI aktiv - unabhaengig davon, was in der
|
||||
# Boot-Konfiguration steht (es kann auch per Overlay oder einem anderen Mechanismus
|
||||
# kommen). Dann kein Eingriff und kein Neustart-Hinweis.
|
||||
if [ -e "$SPIDEV" ]; then
|
||||
echo " SPI ist bereits aktiv ($SPIDEV vorhanden)"
|
||||
exit 0
|
||||
fi
|
||||
|
||||
# Aktuelle Raspberry-Pi-OS-Images nutzen /boot/firmware/config.txt, aeltere
|
||||
# /boot/config.txt - beide werden geprueft, die neuere zuerst. Gibt es keinen von
|
||||
# beiden, ist das kein Grund abzubrechen: ein anderes Boot-Verfahren (oder gar kein
|
||||
# Raspberry Pi OS) ist moeglich, und die Anzeige ist nirgends Voraussetzung fuer eine
|
||||
# funktionierende Station (dasselbe Prinzip wie beim apt-Schritt und beim
|
||||
# Anzeigedienst oben).
|
||||
CONFIG=""
|
||||
if sudo test -f "$CONFIG_NEW"; then
|
||||
CONFIG="$CONFIG_NEW"
|
||||
elif sudo test -f "$CONFIG_OLD"; then
|
||||
CONFIG="$CONFIG_OLD"
|
||||
fi
|
||||
|
||||
if [ -z "$CONFIG" ]; then
|
||||
echo "Warnung: weder $CONFIG_NEW noch $CONFIG_OLD gefunden - vermutlich kein" >&2
|
||||
echo " Raspberry Pi OS oder ein anderes Boot-Verfahren. SPI konnte nicht" >&2
|
||||
echo " geprueft werden - bleibt das E-Paper schwarz, ist das der" >&2
|
||||
echo " wahrscheinlichste Grund." >&2
|
||||
exit 20
|
||||
fi
|
||||
|
||||
# Eine aktive (nicht auskommentierte) "dtparam=spi=on"-Zeile heisst: schon an - dann
|
||||
# nichts tun und keinen Neustart verlangen, den es nicht braucht.
|
||||
if sudo grep -Eq '^[[:space:]]*dtparam=spi=on[[:space:]]*$' "$CONFIG"; then
|
||||
echo " SPI ist in $CONFIG bereits eingeschaltet"
|
||||
exit 0
|
||||
fi
|
||||
|
||||
BACKUP="${CONFIG}.bak-ninlight"
|
||||
if sudo test -f "$BACKUP"; then
|
||||
# Nicht ueberschreiben: sonst waere beim zweiten Lauf (z.B. weil zwischendurch von
|
||||
# Hand wieder auf "off" gestellt wurde) der urspruengliche Originalzustand weg.
|
||||
echo " Sicherung $BACKUP existiert bereits - wird nicht ueberschrieben"
|
||||
else
|
||||
sudo cp -p "$CONFIG" "$BACKUP"
|
||||
echo " Sicherung angelegt: $BACKUP"
|
||||
fi
|
||||
|
||||
# Drei Faelle bleiben: die Zeile fehlt ganz, sie steht auskommentiert da, oder sie
|
||||
# steht aktiv auf "off" (z.B. von Hand deaktiviert). In allen dreien wird auf
|
||||
# "dtparam=spi=on" normalisiert - eine vorhandene Zeile wird ERSETZT statt eine
|
||||
# zweite anzuhaengen, sonst stuenden am Ende zwei widerspruechliche
|
||||
# dtparam=spi-Zeilen in der Datei und es waere Zufall, welche NetworkManager beim
|
||||
# naechsten Boot zuletzt liest.
|
||||
#
|
||||
# Kein "sed -i": dieser Block laeuft zwar auf dem Pi (GNU) unter "REMOTE", aber der
|
||||
# Stub-Test fuehrt ihn woertlich auf dem Entwicklungsrechner (macOS/BSD) aus - "sed
|
||||
# -i" braucht dort ein Suffix-Argument, GNU-sed keins, und die falsche Reihenfolge
|
||||
# war in diesem Projekt schon zweimal ein Fehler. Deshalb sed nur als Filter
|
||||
# (Eingabe->Ausgabe), das Ergebnis geht ueber eine Temp-Datei und "sudo install" an
|
||||
# den Zielpfad - das funktioniert auf beiden Plattformen identisch.
|
||||
if sudo grep -Eq '^[[:space:]]*#?[[:space:]]*dtparam=spi=(on|off)[[:space:]]*$' "$CONFIG"; then
|
||||
TMP_CONFIG=$(mktemp "${TMPDIR:-/tmp}/ninlight-spi-config.XXXXXX")
|
||||
sudo sed -E 's/^[[:space:]]*#?[[:space:]]*dtparam=spi=(on|off)[[:space:]]*$/dtparam=spi=on/' "$CONFIG" >"$TMP_CONFIG"
|
||||
sudo install -m 0644 -o root -g root "$TMP_CONFIG" "$CONFIG"
|
||||
rm -f "$TMP_CONFIG"
|
||||
echo " $CONFIG: dtparam=spi=on gesetzt (vorhandene Zeile aktiviert)"
|
||||
else
|
||||
printf '%s\n' 'dtparam=spi=on' | sudo tee -a "$CONFIG" >/dev/null
|
||||
echo " $CONFIG: dtparam=spi=on ergaenzt"
|
||||
fi
|
||||
|
||||
# Signalisiert dem Aufrufer, dass ein Neustart noetig ist (siehe oben).
|
||||
exit 10
|
||||
REMOTE
|
||||
SPI_RC=$?
|
||||
set -e
|
||||
case "$SPI_RC" in
|
||||
0) ;;
|
||||
10) SPI_REBOOT_NEEDED=1 ;;
|
||||
20) ;;
|
||||
*) echo "Warnung: SPI-Aktivierung ergab einen unerwarteten Fehler (rc=$SPI_RC) - /boot/firmware/config.txt bzw. /boot/config.txt von Hand pruefen." >&2 ;;
|
||||
esac
|
||||
|
||||
echo "== Anzeigedienst aktivieren =="
|
||||
# Die Anzeige wird aktiviert (startet also beim Booten mit) UND jetzt gestartet - anders
|
||||
# als die Station selbst, die absichtlich aus bleibt: die Anzeige sendet nichts, sie
|
||||
@@ -353,10 +459,24 @@ write_profile "$AP_CONNECTION" "$SSID" "$PSK" update
|
||||
write_profile "$MIGRATE_AP_CONNECTION" "$MIGRATE_SSID" "$MIGRATE_PSK" keep
|
||||
REMOTE
|
||||
|
||||
cat <<'EOF'
|
||||
# Der Neustart-Hinweis steht an eigener, auffaelliger Stelle VOR den "Naechsten
|
||||
# Schritten" - nicht dazwischengemischt - und nur, wenn oben wirklich etwas an der
|
||||
# Boot-Konfiguration geaendert wurde (SPI_REBOOT_NEEDED). Ein Hinweis bei jedem Lauf,
|
||||
# auch wenn SPI laengst an ist, wuerde nach ein paar Durchlaeufen ignoriert.
|
||||
SPI_NOTE=""
|
||||
if [ "$SPI_REBOOT_NEEDED" -eq 1 ]; then
|
||||
SPI_NOTE='
|
||||
WICHTIG: SPI wurde soeben erst eingeschaltet (Aenderung an der Boot-Konfiguration) -
|
||||
das wirkt erst nach einem Neustart. Bis dahin bleibt das E-Paper schwarz,
|
||||
auch wenn sonst alles richtig eingerichtet ist.
|
||||
ssh <pi-host> sudo reboot
|
||||
'
|
||||
fi
|
||||
|
||||
cat <<EOF
|
||||
|
||||
Fertig. Die Station ist absichtlich noch AUS.
|
||||
|
||||
$SPI_NOTE
|
||||
Naechste Schritte:
|
||||
ssh <pi-host> ninlight-station display test
|
||||
Testbild aufs E-Paper - bleibt es leer oder
|
||||
|
||||
Reference in New Issue
Block a user