Umstieg von Wheezy zu Buster erfolgreich durchgeführt

[UweUwe]

Hallo,
das mit der Datenbank auf der SD-Karte auf der Flask-Karte ist mir bewusst.
Ich habe nicht häufig Flash-Ausflälle, dies ist der erste Ausfall seit ca. 3 Jahren auf 3 laufenden FHEM-Systemen.

Sehr gestört hat mich, dass ich keinen Anpack hatte, ob die Karte wirklich defekt ist, oder ob ich einen anderen Fehler gemacht habe.

Win32Diskmanager hat fleissig auf die Karte Image geschrieben, und alles als ok gemeldet. Beim Test musste ich dann aber regelmässig feststellen, dass immer noch das "alte" FHEM-System auf der Karte war. Auch löschen , Neuformatierung mit SDFormatter zeigte ebenfalls keinen Fehler.

Die Lösung war :

Code Auswählen Erweitern

etcherhttps://www.balena.io/etcher/.
Eine "teilweise" Alternative zu Win32Diskmanager. Etcher sagte definitiv: Karte kann nicht beschrieben werden. Ich bin damit beruhigt.

[khk123]

Passt zwar nicht ganz zu dem Thema, aber...

Bitte mit Etcher oder W32Diskimager aufpassen. Nicht immer weist eine Fehlermeldung nach dem Schreiben eines Images auf eine defekt SD-Karte hin. Ich habe mit beiden Programmen eine Fehlermeldung erhalten: Sektor 8192 stimmt nicht überein. Die SD-Karte ist neu und nicht defekt. Das Problem lag darin, das Win10 nach dem Schreiben des Images die erste Partition "boot" als Laufwerk mounted und dieses Laufwerk bei der Windoiws-Suche einbindet. Win10 legt dann den Ordner "System Volume Information" an. Etcher und auch W32DiskImager vergleichen nun die Image-Datei mit der SD-Karte und finden natürlich Abweichungen und melden daher einen Fehler. Man kann verhindern, dass Win10 diesen Ordner auf USB-Devices anlegt. Mit gpedit.msc unter "Computerkonfiguration / Administrative Vorlagen / Windows-Komponenten / Suche" den Eintrag "Hinzufügen von Speicherorten auf Wechseldatenträgern zu Bibliotheken nicht zulassen" aktivieren. Dann klappt der Verify nach dem Schreiben wieder.
S.a.: https://www.windows-faq.de/2019/12/22/automatische-erstellung-des-ordners-system-volume-information-auf-usb-sticks-deaktivieren/

Vielleicht hilft der Tip ja dem ein oder anderen.

[Wernieman]

Ich m,uß gestehen, das ich für die Fehlersuche auf ein Linux-System und nicht Windows vertrauen würde. Dateisystemcheck sollte bekannt sein ...

[ITmeyer]

Ich habe einen Pi 1 mit COC 1.1 Steckbrücke, läuft mit Wheezy und FHEM mit update ohne Probleme.
Jetzt wollte ich auf Buster mit FHEM 6 das Sysrem mit einer neuen SD Karte neu aufspielen. Klappt alles soweit ok, nur COC meldet sich nicht.
In der veralteten Wiki howto steht noch ein Eintrag für COC:

Damit der COC beim Start vom FHEM initialisiert wird, muss die /etc/init.d/fhem editiert werden. Dies machen wir mittels sudo nano /etc/init.d/fhem
und fügen unterhalb von "Start)" folgendes in die Datei ein
echo "resetting 868MHz extension..."
if test ! -d /sys/class/gpio/gpio17; then echo 17 > /sys/class/gpio/export; fi
if test ! -d /sys/class/gpio/gpio18; then echo 18 > /sys/class/gpio/export; fi
echo out > /sys/class/gpio/gpio17/direction
echo out > /sys/class/gpio/gpio18/direction
echo 1 > /sys/class/gpio/gpio18/value
echo 0 > /sys/class/gpio/gpio17/value
sleep 1
echo 1 > /sys/class/gpio/gpio17/value
sleep 1

Wo muss ich jetzt mit FHEM 6 und Buster den Eintrag für einen (alten) COC 1.1 einstellen?
Hat da jemand eine Idee?

[MadMax-FHEM]

Du wirst wohl eine eigene systemd-Startdatei dafür brauchen...

Du kannst dich ja evtl. hier orientieren: https://wiki.fhem.de/wiki/HM-CFG-USB_USB_Konfigurations-Adapter

Der wurde früher bzw. bei initd auch mittels Eintrag in fhem.sh gestartet...

Oder auch hier: https://forum.fhem.de/index.php?topic=54271.0

Ich weiß aber nicht wie es mit "Abhängigkeiten" ist...
...dann musst du das halt entsprechend konfigurieren...

Gruß, Joachim

[ITmeyer]

Vielen Dank, werde mich mal einlesen und dann probieren.
Gruß Ingo

[Wernieman]

Würde Dir erstmal empfehlen:
Mache mal als root die genannten Einträge und starte dann FHEM (restart). Schaue mal, ob dann Dein COC in FHEM benutzbar ist.
Ja (Funzt): Systemd erweitern. Bei Problemen bitte melden
Nein (Funzt NICHT): Es ist noch mehr zu machen .... Fehlermeldung in FHEM?

[MadMax-FHEM]

Die genannten Einträge beziehen sich aber auf initd!

Vermutlich kommt die Frage, weil es eben diese Datei in initd nicht mehr gibt auf Buster...

Ein Start nach "alter" Methode funktioniert zwar auf Buster auch (noch)...

Aber da jetzt "zurückrüsten" würde ich nicht...

Und genau diese Einträge (glaube ich) gehen in einem systemd "Startscript" so nicht!?

Nur meine Meinung dazu...

Gruß, Joachim

[Otto123]

Ich hätte dazu noch diese Lösungsbeiträge:
https://forum.fhem.de/index.php?topic=103588.0
https://forum.fhem.de/index.php/topic,106060.msg1003767.html#msg1003767

Das Problem ist ja wie immer vielschichtig: UART vorbereiten, GPIO einschalten.

Das Wiki  sollte dann mal einer der Besitzer von COC SCC usw. aktualisieren.

Gruß Otto

[Wernieman]

Systemd kennt im Startbereich "pre-Scripte". Aber bevor wir in diese Richtung Diskutieren, sollten wir prüfen "was" FHEM unter buster so braucht, damit dder COC gefunden wird und funktioniert ....

Deshalb mein Vorschlag, es erstmal manuell zu probieren.

Da ich kein COC (o.Ä.) habe, kann ich es nicht probieren ...

[ITmeyer]

Danke für eure Antworten, ich habe jetztmal, wie Wernieman empfohlen, die Befehle unter Putty eingegeben und siehe da meine altte Fhem.cfg funktioniert wieder, also COC geht dann auch mit Buster.
So--, was muss ich jetzt machen, damit die Befehle automatisch beim Raspi Start geladen werden??

[MadMax-FHEM]

Ah, manuell eingeben...
Ja klar, da stand ich wohl auf dem Schlauch...

Leider daddel ich grad nur mobil, daher ist "weitere Anweisungen" geben grad nicht einfach...

Aber entweder mit so einem "pre-Script", das muss aber dann Wernieman machen...

Oder die Befehle in ein Script und das dann wie fhem auch aufrufen...

Also quasi Kopie von /etc/systemd/system/fhem und darin dann das Script mit den Befehlen aufrufen...

Evtl. noch Abhängigkeiten wegen Startreihen folge...

Gruß, Joachim

[Otto123]

Danke für eure Antworten, ich habe jetztmal, wie Wernieman empfohlen, die Befehle unter Putty eingegeben und siehe da meine altte Fhem.cfg funktioniert wieder, also COC geht dann auch mit Buster.
So--, was muss ich jetzt machen, damit die Befehle automatisch beim Raspi Start geladen werden??

Hast Du meine Links nicht beachtet? Da steht doch genau wie?! auch wenn es dort ein SCC ist, es ist doch der gleiche Weg

Code Auswählen Erweitern

#Alles als root machen
sudo su

#user fhem muss Mitglied in gpio sein!
usermod -aG gpio fhem

#Script erzeugen
cat <<EOF > /opt/fhem/EnableCOC.sh
echo "resetting 868MHz extension..."
if test ! -d /sys/class/gpio/gpio17; then echo 17 > /sys/class/gpio/export; fi
if test ! -d /sys/class/gpio/gpio18; then echo 18 > /sys/class/gpio/export; fi
echo out > /sys/class/gpio/gpio17/direction
echo out > /sys/class/gpio/gpio18/direction
echo 1 > /sys/class/gpio/gpio18/value
echo 0 > /sys/class/gpio/gpio17/value
sleep 1
echo 1 > /sys/class/gpio/gpio17/value
sleep 1
EOF

#/etc/systemd/system/fhem.service Datei ergänzen (muss schon existieren)
#sed fügt vor der Zeile ExecStart= eine Zeile ein.
#Mann kann es auch per Hand (nano) machen: ExecStartPre=/bin/bash /opt/fhem/EnableCOC.sh
sed -i '/^ExecStart=/ i \ExecStartPre=\/bin\/bash \/opt\/fhem\/EnableCOC.sh' /etc/systemd/system/fhem.service

#Test ob sed alles richtig gemacht hat
cat /etc/systemd/system/fhem.service

# Neustart um die neue Gruppe von user fhem wirksam zu machen
reboot

[ITmeyer]

Vielen Dank für deine Geduld, eine Anleitung für absolute Laien, super!!
Es hat alles soweit geklappt, nur der automatische Start von FHEM hat nicht geklappt, also nach dem Einschalten läuft der COC nicht an, aber wenn ich auf der Webseite für FHEM shutdown(+reboot) eingebe, läuft der COC mit. Habe ich da noch was übersehen?

[Otto123]

Den Part hast Du beachtet ? https://wiki.fhem.de/wiki/Raspberry_Pi#Verwendung_UART_f.C3.BCr_Zusatzmodule
Was sagt:

Code Auswählen Erweitern

systemctl status serial-getty@ttyAMA0.service
Zeig mal den Inhalt der fhem.service:

Code Auswählen Erweitern

/etc/systemd/system/fhem.service
Ansonsten kann es ein Zeitproblem sein: die fhem.service wird vielleicht zu früh ausgeführt und der COC lässt sich in dem Stadium noch nicht aktivieren?

Eventuell kann man mal schauen was beim start von fhem geloggt wird? @Werner hilf bitte

Gruß Otto