Hallo zusammen,
ich bin von Wheezy zu dem brandaktuellen Buster migriert.
Ergebis: alles läuft wie vorher.
Vorgehensweise: Backup von Fhem mit dem Backup Befehl erstellt und die Datei rauskopiert. Habe mir eine 2. SD Karte besorgt und Buster darauf geimaged.
Die Config.txt angepasst und die SD Karte in meinen Raspi2 gesteckt.
Filesystem über raspi-config expandiert.
Buster erst mal upgedated und Einstellungen in raspi-config durchgeführt.
WiringPi installiert
fhem installiert, dabei kamen gleich Meldungen über fehlende Libraries. Diese dann alle nachinstalliert
Fhem nochmals installiert
Backup restored.
Nochmals einige Libraries nachinstallieren müssen. Diese werden alle in der Log Datei angezeigt, die fehlen.
Immer die log beobachten nach Meldungen. Habe diese dann gegoogelt und fand sofort die notwendigen Lösungen.
Seitdem funktioniert alles.
Hoffe dies hilft jemand, der gerade vor der gleichen Frage steht.
Andy
Hallo Andy,
ZitatFilesystem über raspi-config expandiert.
das passiert seit der Version Raspbian Jessie vom 27.5.2016 automatisch beim ersten Start. Braucht man also nicht mehr machen.
Sieht man übrigens, wenn man beim ersten Start einen Monitor dran hat und genau hinschaut.
Gruß Otto
Zitat von: Otto123 am 27 Juni 2019, 11:38:48
Sieht man übrigens, wenn man beim ersten Start einen Monitor dran hat und genau hinschaut.
oder wenn man einfach mit "df -h" nachschaut, wie groß die eingebundene Partition ist :)
Zitat von: betateilchen am 27 Juni 2019, 13:37:46
oder wenn man einfach mit "df -h" nachschaut, wie groß die eingebundene Partition ist :)
Ja klar da auch. :D
Ich meinte, ich war letztens kurz irritiert, dass er kurz zweimal startet. Aber klar er führt das Script
/usr/lib/raspi-config/init_resize.sh
in der cmdline.txt aus und startet dort am Ende neu.
btw, WiringPI ist in Version 2.50 auf Buster vorinstalliert.
DAnke für die Hinweise
Das mit WiringPi war mir neu.
Nur zur Info: Ich habe keinen Monitor angeschlossen, um die Aktivitäten zu sehen.
Aber egal: wollte damit anderen Mut machen, die das OS-Upgrade wie ich lange vor sich herschieben.
Gruss Andy
Zitat von: Decki am 27 Juni 2019, 10:21:52
...
fhem installiert, dabei kamen gleich Meldungen über fehlende Libraries. Diese dann alle nachinstalliert
Fhem nochmals installiert
Backup restored.
Nochmals einige Libraries nachinstallieren müssen. Diese werden alle in der Log Datei angezeigt, die fehlen.
Immer die log beobachten nach Meldungen. Habe diese dann gegoogelt und fand sofort die notwendigen Lösungen.
Hallo Andy,
"... Diese dann alle nachinstalliert ..."
Kannst du bitte dies etwas erläutern, als Anfänger gebe ich die Zeilen ein welche man in allen howtos oder Wikis liest , wenn dann Fehlermeldungen kommen bin ich aufgeschmissen.
Danke
EDIT:
Ich habe nun nach der "The easy Way" Methode installiert ( https://debian.fhem.de/ )
Mit dem nano Befehl habe ich die sources.list editiert und die deb Zeile eingefügt. Danach update und install von Fhem.
Es kamen , glaube ich , keine Fehler Meldungen.
Fhem lässt sich im Browser aufrufen.
Kann ich davon ausgehen dass es nun richtig unter Raspbian Buster installiert ist?
Oder müssen noch weitere Sachen manuel hinzugefügt werden?
Zitat von: jumperger am 10 August 2019, 23:07:45
Ich habe nun nach der "The easy Way" Methode installiert ( https://debian.fhem.de/ )
Mit dem nano Befehl habe ich die sources.list editiert und die deb Zeile eingefügt. Danach update und install von Fhem.
Es kamen , glaube ich , keine Fehler Meldungen.
Fhem lässt sich im Browser aufrufen.
Kann ich davon ausgehen dass es nun richtig unter Raspbian Buster installiert ist?
Oder müssen noch weitere Sachen manuel hinzugefügt werden?
Moin,
Ja so ist fhem erstmal fertig installiert.
Weitere Pakete hängen von deinen FHEM Modulen ab.
Steht dann in der Regel als Voraussetzung in der Commandref.
Gesendet von meinem S60 mit Tapatalk
Zitat von: jumperger am 10 August 2019, 23:07:45
Kann ich davon ausgehen dass es nun richtig unter Raspbian Buster installiert ist?
Oder müssen noch weitere Sachen manuel hinzugefügt werden?
Hi,
Du grätschst hier komisch in diesen Thread rein :)
Also wenn Du einfach Buster hattest und so wie beschrieben FHEM neu installiert hast ist sicher alles schick.
Warum sollte es nicht so sein?
Gruß Otto
Ich wollte hier wirklich nicht rein grätschen, bitte dies zu entschuldigen.
Ich war ganz einfach froh ein Thema zur Installation von Fhem unter Buster gefunden zu haben.
Mein Problem ist dass ich derart Anfänger bin, dass in den Erklärungen welche ich finde immer derart viele neue Sachen stehen welche ich nachsuchen muss, dass ich manchmal nicht mehr weiss von wo ich ausgegangen bin. Für mich steht da manchmal Cinesisch, für euch ist es Umgangssprache.
ZitatWarum sollte das nicht so sein
Ja weil Andy schreibt dass er viel nachinstallieren musste.
Ich weiss jetzt zumindest dass ich zur nächsten Etappe schreiten kann und versuchen werde den I2C-Bus anzusteuern.
Ich hänge mich hier mal an:
Mein jetziger Pi2 b rev 1.1 mit Stretch hat OW Server für die 1wire Sensoren und einen HM USB Cfg Stick mit VCCU
Muss ich hier vor allem bei 1 wire OW Server etwas umstellen wenn ich diese Woche auf den neuen 4er umziehe?
Danke für eure Tipps
LG
Helmut
Hallo zusammen,
habe eben in einer virtuellen Maschine FHEM auf Buster migriert. Läuft ja soweit ganz gut.
Mir ist aufgefallen, dass man den FHEM Neustart durch "systemctl start fhem.service" machen muss und nicht mehr durch "/etc/init.d/fhem start".
Ok, kann man machen.
Aber bei mir repoduzirbar ist, dass, wenn der FHEM Perl Prozess abschmiert oder mit kill getötet wird, ein neuer FHEM Prozess nicht mehr durch "systemctl start fhem.service" gestartet werden kann. Ich muss erst "systemctl stop fhem.service" absetzten, bevor "systemctl start fhem.service"wieder funktioniert, so als ob der systemctl Prozess nicht mitbekommt, wenn untendrunter FHEM verschwindet.
Konntet ihr das bei euch auch beobachten oder läuft da bei meinem System etwas schief ?
Gruß
Isno
Hi Isno,
eigentlich ist fhem.service jetzt so gestrickt, dass systemctl fhem sofort selbst neu startet. Eventuell beobachtest Du das nicht?
Gerade probiert funktioniert bei mir einwandfrei.
root@raspib3plus:/home/pi# ps -aux |grep fhem
fhem 15963 0.0 2.8 35324 27420 ? S Sep09 2:45 /usr/bin/perl fhem.pl fhem.cfg
root 29770 0.0 0.0 7692 472 pts/0 S+ 10:34 0:00 grep fhem
root@raspib3plus:/home/pi# kill 15963
root@raspib3plus:/home/pi# ps -aux |grep fhem
fhem 29773 121 2.7 34124 26148 ? S 10:34 0:01 /usr/bin/perl fhem.pl fhem.cfg
root 29776 0.0 0.0 7692 516 pts/0 S+ 10:34 0:00 grep fhem
root@raspib3plus:/home/pi# kill 29773
root@raspib3plus:/home/pi# ps -aux |grep fhem
fhem 29780 57.0 2.7 34124 26100 ? S 10:35 0:01 /usr/bin/perl fhem.pl fhem.cfg
root 29782 0.0 0.0 7692 516 pts/0 S+ 10:35 0:00 grep fhem
root@raspib3plus:/home/pi#
Gruß Otto
Hallo Otto,
bei mir sieht die fhem.service so aus:
root@DEKHER2LDS02:/run/systemd/generator.late# more fhem.service
# Automatically generated by systemd-sysv-generator
[Unit]
Documentation=man:systemd-sysv-generator(8)
SourcePath=/etc/init.d/fhem
Description=LSB: FHEM server
Before=multi-user.target
Before=multi-user.target
Before=multi-user.target
Before=graphical.target
After=remote-fs.target
[Service]
Type=forking
Restart=no
TimeoutSec=5min
IgnoreSIGPIPE=no
KillMode=process
GuessMainPID=no
RemainAfterExit=yes
SuccessExitStatus=5 6
ExecStart=/etc/init.d/fhem start
ExecStop=/etc/init.d/fhem stop
root@DEKHER2LDS02:/run/systemd/generator.late#
Passt das so (ist auch der Pfad korrekt, den hat das Linux sich selbst so ausgedacht)?
Gruß
Isno
Hallo nochmal Otto,
nachdem du mich in die richtige Richtung geschubst hast, habe ich mich dort mal ein bisschen eingelesen.
Habe nun meine fhem.service neu nach Anleitung generiert.
Jetzt startet fhem auch wieder, so wie du es bei dir beschrieben hast.
Danke für den Schubser 8)
root@DEKHER2LDS02:/etc/systemd/system# more fhem.service
[Unit]
Description=FHEM Home Automation
Wants=knxd.service
[Service]
Type=forking
ExecStart=/etc/init.d/fhem start
ExecStop=/etc/init.d/fhem stop
#Restart=always
Restart=on-failure
RestartSec=5
[Install]
WantedBy=multi-user.target
root@DEKHER2LDS02:/etc/systemd/system#
Hi,
eigentlich ist aktuell (wenn man neu installiert) der Inhalt von/etc/systemd/system/fhem.service ein ganz anderer:
# $Id: fhem.service 19235 2019-04-21 13:26:17Z betateilchen $
[Unit]
Description=FHEM Home Automation
Wants=network.target
After=network.target
#Requires=postgresql.service
#After=postgresql.service
#Requires=mysql.service
#After=mysql.service
[Service]
Type=forking
User=fhem
Group=dialout
WorkingDirectory=/opt/fhem
ExecStart=/usr/bin/perl fhem.pl fhem.cfg
#ExecStart=/usr/bin/perl fhem.pl configDB
Restart=always
[Install]
WantedBy=multi-user.target
Gruß Otto
Hallo,
ich klinke mich hier mal ein. Aufgrund dieses Posts (https://forum.fhem.de/index.php/topic,105944.msg1003056.html#msg1003056) habe ich mal geschaut, wie alt meine Betriebssysteme (2x Raspberry Pi) sind. Auf einem ist immer noch Wheezy installiert, aber das sollte ich wohl ziemlich schnell ändern.
Ich denke, ein Upgrade der bestehenden SD Karte ist nicht empfehlenswert, korrekt?
Dann wäre die Alternative eine Neuinstallation, Ablauf in etwa so:
- Update von FHEM und Backup von FHEM
- Backup der SD Karte (komplett, falls was schief geht) (im laufenden Betrieb oder offline)
- neue SD Karte und Raspbian neu installieren
- FHEM neu installieren (inkl. Aufruf mit systemd), Bibliotheken nachinstallieren
- altes FHEM (inkl. logs und den anderen Daten) drüberkopieren, dann sollte nichts Neues überschrieben werden
Habe ich noch was vergessen, oder passt das in etwa so?
Danke + Gruß
Peter
Hallo Peter,
im Prinzip ja - ich mache zwischen dem vorletzen und dem letzen Schritt immer noch: stop fhem :)
Ich überschreibe auch immer alles, dann hast Du sicher den Stand vom Backup, dass was es noch nicht gab (contrib Inhalt) bleibt auf alle Fälle.
Und bei mir ist es doch noch etwas mehr :)
- ssh Umgebung
- Dateiserver (z.B. Sonos Sprachausgabe)
- Laufwerksverbindung (Backup Server)
- nodejs
- python pakete
Ich habe mir relativ viel Mühe gegeben um das alles aufzuschreiben (https://heinz-otto.blogspot.com/2019/07/neues-linux-system-nacharbeit.html), vielleicht hilft es Dir :)
Ist sicher nicht perfekt, aber ich verifiziere das gerade anhand von mindestens zwei Umzügen. ;)
Gruß Otto
Hi
Muss man unbedingt den Weg mit der neuen SD Karte machen? oder kann man die source.list auch so umschreiben dass raspbian automatisch die neuen Buster Pakete holt und installiert?
Hab das zwar Versucht, er bringt aber immer wieder Fehlermeldungen mit Paket-Zertifikat und Mosquitto.list source ....
Im Internet hab ich diverse Anleitungen gefunden, funktionieren aber irgendwie nicht.
Meine Antwort lautet: ja | ::)
Frage andersherum gestellt: Warum sollte man es Deiner Meinung nach nicht mit "neuer Karte" machen?
Für Anfänger empfehle ich eine Neuinstallation.
An sonsten kann man auch die source.list entsprechend anpassen. Vorher würde ich aber alle third part Quellen auskommentieren.
SD Karten haben eine begrenzte Lebensdauer.
Eine neue Karte zu verwenden ist daher eine gute Idee.
Produktivsysteme bekommen mit jeder neuen OS Version ne neue Karte.
Die "alten" Karten gehen dann in MediaPlayer oder Testsysteme. Eben dahin wo ein Ausfall unkritisch ist.
Gesendet von meinem Doogee S60 mit Tapatalk
Ich tausche jedes Jahr die SD Karten komplett aus. Mittlerweile läuft zwar kein FHEM mehr auf meinem Pi sondern Aufsteckmodule pur, aber dennoch werden die Pis benötigt.
Ein Distri-Update mache ich dennoch in-place.
Bei mir laufen die RasPis über SSD. Die SD-Karte ist im Pi4 nur noch zum booten drin.
Gesendet von iPhone mit Tapatalk
Ok schöne Diskussion 🎅 - wobei es hier um etwas ganz anderes ging.
Und fabse seine Frage habe ich eher - nicht nach der SD Karte an sich - sondern die scheinbar "faule Weiber" Variante: einfach nur update machen - verstanden.
Es gab hier im Forum den Hinweis: Es ist von wheezy schon etwas anderes und spezieller als von stretch oder jessie
Hallo Zusammen,
habe viel gelesen in den letzten Tagen. Man(n) hat Zeit, Frau denkt was ganz anderes....
Fing harmlos an. Sonos Move mit Alexa unterm Weihnachtsbaum. Aber Node.js wollte sich auf Jessie nicht mehr updaten lassen.
Also neue SD Karte mit Buster aufgesetzt.
Vorgehensweise von ALT JESSIE auf Neu BUSTER so:
- Update von FHEM und Backup von FHEM (über WinSCP auf dem Rechner gesichert)
- Alte SD- Karte als Back-up gesichert.
- neue SD Karte und Raspbian neu installiert
- FHEM neu installieren (the easy way)
- altes FHEM Backup von OTTO123 Webseite (inkl. logs und den anderen Daten) vom PC auf den Pi mittels WinSCP geschoben. Fhem über die Konsole sicher beendet und mittels
sudo tar -xvzf /home/pi/FHEM-20191229_151348.tar.gz -C /opt/fhem/
kopiert.
Fhem gestartet! Die Webseite aber nicht erreichbar. Status geprüft, läuft, scheint aber überlastet.
Ich habe geglaubt, dass ich in den LOGs sehen kann, welche Bibliotheken ggf. fehlen und installiere in Ruhe nach.
Da ich die Webseite http://192.168.178.21:8083/fhem? aber nicht erreichbar ist, komme ich gar nicht soweit....
Hat jemand von Euch eine Idee? Und bitte, habt Nachsicht, ich gehöre auch zu denen, die Linux für Chinesisch halten und hangele mich bisher stets erfolgreich, auch dank der Hilfe hier durch diverse Herausforderungen.
Lieben Dank
Gruß
Bibo
Du kannst Dich mittels ssh (putty) mit den Pi verbinden und findest unter /opt/fhem/log/fhem-xxx.log das Logfile
tail /opt/fhem/log/fhem-2019-12.log
BTW: Man kann sich unter Windows 10 auch einfach so mit ssh mit dem Linux verbinden.
Ich verwende schon lange kein putty und co mehr :)
danke für die schnellen Antworten...
System läuft in seinen Grundzügen wieder! Puuuuuuuhhh! ::) ;D
Ich habe einfach alles an Bibliotheken aus der Bash History aus 2016 und 2017 gnadenlos drübergebügelt und für Homekit und Sonos noch die Dateien erstellt.
Danach reboot und fhem lief. Homematic und FS20 sind schon mal da.....
bin ich erleichtert!
bash Historie - auch ne Variante :)
Es steht auch im apt Log https://heinz-otto.blogspot.com/2019/07/infos-zur-installation-von-modulen-und.html
Guten Morgen,
ich häng mich hier mal mit ran, wenn es in Ordnung ist. Ich bin gerade beim Installieren vom Buster und will im Anschluss umziehen mit meinem alten FHEM. Leider bin ich in Sachen Linux recht grün hinter den Ohren. Buster soll mit neustem Image auf einem PI 3 installiert werden.
Beim ersten update und upgrade erhalten ich diese Ausgabe:
pi@FHEM:~ $ sudo apt-get update && sudo apt-get upgrade
Holen:1 http://raspbian.raspberrypi.org/raspbian buster InRelease [15,0 kB]
OK:2 http://archive.raspberrypi.org/debian buster InRelease
Es wurden 15,0 kB in 1 s geholt (14,6 kB/s).
Paketlisten werden gelesen... Fertig
E: Der dpkg-Prozess wurde unterbrochen; Sie müssen manuell »sudo dpkg --configur e -a« ausführen, um das Problem zu beheben.
Bei der manuellen Ausführung erhalte ich dann die vielversprechende Meldung unten.
pi@FHEM:~ $ sudo dpkg --configure -a
systemd (241-7~deb10u2+rpi1) wird eingerichtet ...
Leider scheint sich das System dabei zu verschlucken und es geht nicht weiter. Daher bin ich leider etwas ratlos.
Ich habe schon mit Tante gegoogle versucht dem Problem auf den Grund zu gehen, dabei habe ich leider nichts passendes gefunden oder entsprechend nicht korrekt gesucht. Daher wäre ich über einen Hinweis was zu tun ist sehr dankbar.
Ich würde raspbian-lite nehmen, kein noobs, eine neue SD Karte und darauf achten das die rote LED NICHT blinkert.
Dein Fehler klingt nach: es ist irgendwas kaputt!
Gruß Otto
Danke für die Flotte Antwort. Lite habe ich schon gemäß deinem Blog genommen.
Dann werd ich mal die SD Karte als Problem ausschließen und ne neue nehmen. Wäre ja zu einfach :o
hab es jetzt mit 2 SD karten probiert 128GB Samsung EVO und ne alte Adata 16GB beide frisch formatiert. Bei beiden das gleiche Systemverhalten nach update und upgrade hängt sich das System an folgender Stelle auf:
Unpacking cron (3.0pl1-134+deb10u1) over (3.0pl1-134) ...
Netzwerkverbindung nach eniger Zeit weg. Beim nächsten update und upgrade kommt dann die bekannte Fehlermeldung.
Ich such noch mal ne dritte Karte und nehm das Gehäuse vom PI runter ein wenig warm ist er schon. Aber glaube nicht, dass das Problem daran liegt.
Stromversorgung! Anderes Netzteil nehmen. Hast Du einen Bildschirm dran? zeigt er beim starten da gelbe Dreieck?
Frisch formatiert ist unnütz, das passiert beim aufspielen des img ganz automatisch. ;)
Hallo,
Ich habe meinen Server (Kein RasPi) von Jessie --> Stretch --> Buster mit upgrade installiert und das hat auch funktioniert.
Da der X-server mit meiner alten Hardware nicht richtig funktioniert hat habe ich über Weihnachten eine neue Buster installation aufgespielt und bin dann in ein Problem mit dem SB_Server Modul gelaufen. Fhem war in einem restart loop solange der Squeezebox Server an war. Ursache ist eine Datei aus dem Paket libc6, libc-2.28.so. Die Datei war auf der alten Installation nicht drauf und hat zu viele Abhängigkeiten so das deinstallieren bei mir nicht geht.
Zur Info falls jemand das SB_Server Modul auch nutzt.
Ich ziehe jetzt in einen Docker um :)
Gruß
Eisix
Zitat von: Otto123 am 31 Dezember 2019, 13:37:40
Stromversorgung! Anderes Netzteil nehmen. Hast Du einen Bildschirm dran? zeigt er beim starten da gelbe Dreieck?
Frisch formatiert ist unnütz, das passiert beim aufspielen des img ganz automatisch. ;)
Das mit dem Formatieren, zeigt denke ich meine Verzweiflung ;D Wollte das Thema ausschließen. Netzteil ist ein guter Tip. Häng den PI mal ein anderes Netzteil und pack ihn auch mal an einen Monitor.
EDIT: Ja der Strom scheint der Übeltäter gewesen zu sein. Der PI ist gerade umgezogen und bezieht seinen Strom jetzt von einem anderen Netzteil. Die Installation lief sauber druch und ein
frisches FHEM ist auf im drauf. Dann werde ich mich morgen mal ans umziehen machen. Vielen Dank für die Lösung dieses, rückblickend betrachtet, doch sehr einfach zu lösneden Problems ::)
Hallo,
die Alexa-FHEM Gemeinde gibt den nachhaltigen Rat, jetzt auf Buster umzusteigen. Die neueren Alexa Versionen laufen nicht mehr, da von NPM nicht die aktuelle Version verwendet werden kann: https://forum.fhem.de/index.php/topic,60452.2745.html
Als Hardware habe ich
cat /sys/firmware/devicetree/base/model
Raspberry Pi 3 Model B Plus Rev 1.3 als Betriebssystem hab ich installiert:
pi@mymachine:~ $ cat /etc/os-release
PRETTY_NAME="Raspbian GNU/Linux 9 (stretch)"
NAME="Raspbian GNU/Linux"
VERSION_ID="9"
VERSION="9 (stretch)"
VERSION_CODENAME=stretch
ID=raspbian
ID_LIKE=debian
HOME_URL="http://www.raspbian.org/"
SUPPORT_URL="http://www.raspbian.org/RaspbianForums"
BUG_REPORT_URL="http://www.raspbian.org/RaspbianBugs"Wenn man sich im Forum zu diesem Thema Busterumstieg um"liest", so tendiert man zu einer Neuinstallation, nicht über update/upgrade. Korrekt?
In der Vergangenheit habe ich dazu immer die Anleitung von Otto verwendet:
http://heinz-otto.blogspot.com/2018/01/installation-raspberry-pi.html
Der download-link zeigt ja auf die Raspbian-Buster Variante:
ZitatRaspbian Buster Lite
Minimal image based on Debian Buster
Version: February 2020
Release date: 2020-02-13
Kernel version: 4.19
Size: 434 MB
Ist dies der richtige Weg oder muss ich noch was beachten?
Eine Detailfrage noch zur Formatierung der Flashkarte:
Ich habe den Eindruck, dass meine Zielkarte , eine 32 Gbyte Sandisk Ultra , nicht mehr ok ist.
Muss ich die Karte vor der Installation von Raspbian Buster Lite formatieren?
Welches Formatierungsprogramm schlagt ist vor, welche Optionen (Ich bevorzuge WIN10 Programme).
ZitatIch habe den Eindruck, dass meine Zielkarte , eine 32 Gbyte Sandisk Ultra , nicht mehr ok ist.
Wenn das so ist, kauf Dir besser ne Neue.
Ich mach es immer neu, aber es gibt Einige die sagen, das Problem ist systemd. Also von einem systemd System zu einem neuen systemd ist ev. kein Problem.
Hallo Otto123,
danke für deine Nachrichten. Wenn das so ist, kauf Dir besser ne Neue.
. Hab ich schon gemacht. Ich bin aber immer daran interessiert zu verstehen, ob ich es "kaputtformatiert" habe oder ob es ein physikalischer Effekt ist. Deshalb die Frage.
Ich mach es immer neu, aber es gibt Einige die sagen, das Problem ist systemd.
Damit hab ich keine Erfahrung. Ich weiss nicht mal, wie ich festellen kann, ob ich ein systemcd System habe.
Ich bin eigentlich auf dem Trip eines Neusystemes, hab aber zwischenzeitlich so viele Sonderlocken (Nachinstallationen) auf Betriebssystem Ebene und befürchte, dass ich dies nur schwer wieder hinbekomme:
Alexa, DBLogging, DbRep, FUIP, Geofancy, Pushover,TelegramBot, SIP, Text2Speech, Weather, Proplanta, etc..
Gibt es da ein bessere Möglichkeit, als alles einzeln zu übertragen und möglicherweise Dinge falsch zu machen bzw. zu vergessen.
Merci
Naja Du hast stretch, das ist ein systemd System :)
Hier im Thread ging es ja um Wheezy nach Buster, wheezy war noch init.d ;)
Du kannst doch ein Image der SD Card machen, dann ein inplace upgrade von stretch nach buster versuchen. Wenn es Fehlerfrei läuft ist es gut. Ich kann Dir dabei nicht helfen, ich habe es noch nicht gemacht. Es gab aber mehrere Anleitungen dazu.
Wenn es nicht lief hast Du das Image und gehst erstmal zurück.
Das Du die Karte kaputtformatiert hast glaub ich nicht.
Läuft die Datenbank auf der SD Card?
Hallo Otto,
danke für deine Antworten, die helfen mir weiter.
Ich habe bereits ein lauffähige Kopie meines Produktionssystemes in der Schublade. Vorsichtshalber.
Das mit inplace upgrade werde ich mir anschauen, danke für den Tip.
Ja, ich habe eine Datenbank auf der SD-Karte: DbLog DBLogging
Merci..
Die Datenbank auf der SD Card finde ich kritisch. Ich befürchte, das tötet systematisch die SD Card. Die Schreibzugriffe auf die gleiche Stelle passieren dabei eventuell sehr häufig. Alle, die ich gefragt habe, die häufig defekte SD Cards hatten, hatten Datenbanken darauf. Ich selbst hatte noch nie einen Defekt und habe keine Datenbanken aktiv. Das ist keine repräsentative Studie, das ist nur meine Vermutung! ;)
Die allerdings sehr fundiert ist. SDCards sind flashzellen und diese sind nicht für fiele Schreibvorgänge spezifiziert. Bei einer SSD ist deshalb ein Controller drauf, der durch verschieben der Zellen es versucht zu umgehen. Dafür ist aber eine SDCard "zu blöde" ...
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 :etcherhttps://www.balena.io/etcher/.
Eine "teilweise" Alternative zu Win32Diskmanager. Etcher sagte definitiv: Karte kann nicht beschrieben werden. Ich bin damit beruhigt.
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.
Ich m,uß gestehen, das ich für die Fehlersuche auf ein Linux-System und nicht Windows vertrauen würde. Dateisystemcheck sollte bekannt sein ...
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?
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
Vielen Dank, werde mich mal einlesen und dann probieren.
Gruß Ingo
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?
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
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
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 ...
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??
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
Zitat von: ITmeyer am 10 Mai 2020, 14:54:32
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 ::)
#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
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?
Den Part hast Du beachtet ? https://wiki.fhem.de/wiki/Raspberry_Pi#Verwendung_UART_f.C3.BCr_Zusatzmodule
Was sagt:
systemctl status serial-getty@ttyAMA0.service
Zeig mal den Inhalt der fhem.service:
/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
Ich schau mal wie das Login aussieht.
Hier schon mal das fhem.service:
[Unit]
Description=FHEM Home Automation
Wants=network.target
After=network.target
#Requires=postgresql.service
#After=postgresql.service
#Requires=mysql.service
#After=mysql.service
[Service]
Type=forking
User=fhem
Group=dialout
WorkingDirectory=/opt/fhem
ExecStartPre=/bin/bash /opt/fhem/EnableCOC.sh
ExecStart=/usr/bin/perl fhem.pl fhem.cfg
#ExecStart=/usr/bin/perl fhem.pl configDB
Restart=always
[Install]
WantedBy=multi-user.target
Im Script /opt/fhem/EnableCOC.sh (von Otto)
das letzte "sleep 1" mal durch ein "sleep 10" tauschen ...
Und danke für das systemd-config File. Beim nächsten mal aber bitte in "code" Tags, das ist hinter den "#" im Forumseditor zu finden, setzen.
Was zum durchlesen: https://www.freedesktop.org/software/systemd/man/systemd.service.html (https://www.freedesktop.org/software/systemd/man/systemd.service.html)
Danke, man lernt nie dazu, hoffentlich vergesse ich es nicht wieder :)
Sleep 10 hat leider auch nichts verändert,
was war mit dem Ergebnis:?
systemctl status serial-getty@ttyAMA0.service
Und was gibt? groups fhem
Otto, gibt es bei Dir in Systemd einen ttyAMA0.service??
Auf den Systemen wo UART verwendet wird, sprich ttyAMA0 existiert - ja klar. Er ist deaktiviert:
systemctl status serial-getty@ttyAMA0.service
● serial-getty@ttyAMA0.service - Serial Getty on ttyAMA0
Loaded: loaded (/lib/systemd/system/serial-getty@.service; disabled)
Active: inactive (dead)
Docs: man:agetty(8)
man:systemd-getty-generator(8)
http://0pointer.de/blog/projects/serial-console.html
Meine Vermutung wäre, das Beide um die ttyAMA0 kämpfen und beim zweiten Start gewinnt FHEM. Aber das ist nur ein Strohhalm.
Stimmt ... ich hatte eher die Vermutung, das FHEM immer noch zu schnell "kommt" .. Deine ist aber besser ;o)
Hier das Egebnis:
root@Fhemnew:~# systemctl status serial-getty@ttyAMA0.service
● serial-getty@ttyAMA0.service
Loaded: masked (Reason: Unit serial-getty@ttyAMA0.service is masked.)
Active: inactive (dead)
und
root@Fhemnew:~# groups fhem
fhem : dialout gpio
Hilft das?
Ja das sieht richtig aus :)
Damit ist mein Strohhalm abgeknickt :-[
Was steht denn im FHEM Log um so nach/während der ersten und zweiten Startphase?
Steht was im syslog?
sudo cat /var/log/syslog
Nach einem Neustart:
May 10 19:31:39 Fhemnew systemd-timesyncd[198]: Synchronized to time server for the first time [2001:638:502:137:21b:78ff:fe77:c6ec]:123 (2.debian.pool.ntp.org).
May 10 19:31:43 Fhemnew systemd[1]: Started FHEM Home Automation.
May 10 19:31:44 Fhemnew dhcpcd[438]: wlan0: fe80::464e:6dff:fe78:7224 is reachable again
May 10 19:31:44 Fhemnew dhcpcd[438]: wlan0: fe80::464e:6dff:fe78:7224 is reachable again
May 10 19:32:22 Fhemnew systemd[1]: dev-serial1.device: Job dev-serial1.device/start timed out.
May 10 19:32:22 Fhemnew systemd[1]: Timed out waiting for device /dev/serial1.
May 10 19:32:22 Fhemnew systemd[1]: Dependency failed for Configure Bluetooth Modems connected by UART.
May 10 19:32:22 Fhemnew systemd[1]: hciuart.service: Job hciuart.service/start failed with result 'dependency'.
May 10 19:32:22 Fhemnew systemd[1]: dev-serial1.device: Job dev-serial1.device/start failed with result 'timeout'.
May 10 19:32:22 Fhemnew systemd[1]: Reached target Multi-User System.
May 10 19:32:22 Fhemnew systemd[1]: Reached target Graphical Interface.
May 10 19:32:22 Fhemnew systemd[1]: Starting Update UTMP about System Runlevel Changes...
May 10 19:32:22 Fhemnew systemd[1]: systemd-update-utmp-runlevel.service: Succeeded.
May 10 19:32:22 Fhemnew systemd[1]: Started Update UTMP about System Runlevel Changes.
May 10 19:32:22 Fhemnew systemd[1]: StartMay 10 19:35:57 Fhemnew systemd[1]: Started Session c3 of user root.
Dazu nach shutdown mit FHEM
May 10 19:35:57 Fhemnew systemd[1]: Started Session c3 of user root.
May 10 19:36:42 Fhemnew systemd[1]: fhem.service: Succeeded.
May 10 19:36:43 Fhemnew systemd[1]: fhem.service: Service RestartSec=100ms expired, scheduling restart.
May 10 19:36:43 Fhemnew systemd[1]: fhem.service: Scheduled restart job, restart counter is at 1.
May 10 19:36:43 Fhemnew systemd[1]: Stopped FHEM Home Automation.
May 10 19:36:43 Fhemnew systemd[1]: Starting FHEM Home Automation...
May 10 19:36:43 Fhemnew bash[576]: resetting 868MHz extension...
May 10 19:36:49 Fhemnew dhcpcd[438]: wlan0: Router Advertisement from fe80::464e:6dff:fe78:7224
Aha - da knuspert einer an der UART rum:
ZitatMay 10 19:32:22 Fhemnew systemd[1]: dev-serial1.device: Job dev-serial1.device/start timed out.
May 10 19:32:22 Fhemnew systemd[1]: Timed out waiting for device /dev/serial1.
May 10 19:32:22 Fhemnew systemd[1]: Dependency failed for Configure Bluetooth Modems connected by UART.
May 10 19:32:22 Fhemnew systemd[1]: hciuart.service: Job hciuart.service/start failed with result 'dependency'.
May 10 19:32:22 Fhemnew systemd[1]: dev-serial1.device: Job dev-serial1.device/start failed with result 'timeout'.
Wieso eigentlich serial1 ? Du hast doch einen Pi1 - hast Du gesagt? Oder hast Du ein Bluetooth Modul dran?
Was sagt:
ls -lha /dev/serial*Da sollten wir versuchen den hciuart.service lahm zu legen. Solltest Du mal versuchen:
sudo systemctl stop hciuart.service
sudo systemctl disable hciuart.service
sudo systemctl mask hciuart.service
Bringt aber auch nichts!
root@Fhemnew:~# ls -lha /dev/serial*
lrwxrwxrwx 1 root root 7 Mai 10 19:17 /dev/serial0 -> ttyAMA0
root@Fhemnew:~# systemctl stop hciuart.service
root@Fhemnew:~# systemctl disable hciuart.service
Removed /etc/systemd/system/multi-user.target.wants/hciuart.service.
root@Fhemnew:~# systemctl mask hciuart.service
Created symlink /etc/systemd/system/hciuart.service → /dev/null.
Mir gehen die Ideen aus.
In deinem syslog oben fehlt mir beim Neustart die Zeile
Starting FHEM Home Automation...
Beim restart ist sie dann da.
Kannst Du mal bis zu der zurück gehen?
Starting FHEM Home Automation...
Die Zeile ist gleich an zweiter Stelle da.
Aber erstmal herzlichen Dank für deine Mühen, ich werde gleich mal Pause machen und mir morgen alles nochmal in Ruhe anschauen.
Und danach? kommt danach die Zeile resetting 868MHz extension... und / oder irgendwelche Fehler?
Es ist das Listing in von vorher, beginnt nach Power on, da steht ja leider nichts von resetting 868MHZ...
erst beim reboot??
Es steht auch Started FHEM automation und beim reboot steht Starting
ich behaupte Dein Ausschnitt aus dem Log ist unvollständig. Auch beim Neustart muss eine Zeile
starting ...
und dann irgendwann die Zeile
started ...
kommen
Du kannst so etwas filtern:
cat /var/log/syslog| grep -A 15 "FHEM Home"
Mich stöhrt aber immer noch das
May 10 19:32:22 Fhemnew systemd[1]: dev-serial1.device: Job dev-serial1.device/start timed out.
May 10 19:32:22 Fhemnew systemd[1]: Timed out waiting for device /dev/serial1.
Kannst Du uns mal die Liste der enabled Systemd Module geben?
systemctl list-unit-files | grep enabled
Bei soviel Knowhow will ich auch nicht aufgeben. Ich habe jetzt mal alles neu aufgesetzt, das Scricpt von Otto eingefügt und neu gestartet. Leider immer noch das gleiche Ergebnis, aber jetzt, warum auch immer, ein größeres Syslog. Hier fehlen beim ersten Start Berchtigungen?? Bei Reset geht es aber.
May 11 10:31:58 Fhemnew systemd[1]: Started dhcpcd on all interfaces.
May 11 10:31:59 Fhemnew systemd[1]: Reached target Network.
May 11 10:31:59 Fhemnew systemd[1]: Starting OpenBSD Secure Shell server...
May 11 10:31:59 Fhemnew systemd[1]: Condition check resulted in fast remote file copy program daemon being skipped.
May 11 10:31:59 Fhemnew systemd[1]: Starting Permit User Sessions...
May 11 10:31:59 Fhemnew systemd[1]: Starting FHEM Home Automation...
May 11 10:31:59 Fhemnew systemd[1]: Starting /etc/rc.local Compatibility...
May 11 10:31:59 Fhemnew systemd[1]: Started /etc/rc.local Compatibility.
May 11 10:31:59 Fhemnew bash[441]: resetting 868MHz extension...
May 11 10:31:59 Fhemnew bash[441]: /opt/fhem/EnableCOC.sh: Zeile 4: /sys/class/gpio/gpio17/direction: Keine Berechtigung
May 11 10:31:59 Fhemnew bash[441]: /opt/fhem/EnableCOC.sh: Zeile 5: /sys/class/gpio/gpio18/direction: Keine Berechtigung
May 11 10:31:59 Fhemnew bash[441]: /opt/fhem/EnableCOC.sh: Zeile 6: /sys/class/gpio/gpio18/value: Keine Berechtigung
May 11 10:31:59 Fhemnew bash[441]: /opt/fhem/EnableCOC.sh: Zeile 7: /sys/class/gpio/gpio17/value: Keine Berechtigung
May 11 10:31:59 Fhemnew systemd[1]: Started Permit User Sessions.
May 11 10:31:59 Fhemnew systemd[1]: Started Getty on tty1.
May 11 10:31:59 Fhemnew systemd[1]: Reached target Login Prompts.
May 11 10:32:00 Fhemnew systemd[1]: Started OpenBSD Secure Shell server.
May 11 10:32:00 Fhemnew bash[441]: /opt/fhem/EnableCOC.sh: Zeile 9: echo: Schreibfehler: Die Operation ist nicht erlaubt.
May 11 10:32:06 Fhemnew systemd[1]: Started FHEM Home Automation.
May 11 10:32:08 Fhemnew systemd[1]: systemd-fsckd.service: Succeeded.
May 11 10:32:30 Fhemnew systemd-timesyncd[196]: Synchronized to time server for the first time [2a02:8106:19::4]:123 (2.debian.pool.ntp.org).
May 11 10:32:31 Fhemnew systemd[1]: Created slice User Slice of UID 0.
May 11 10:32:31 Fhemnew systemd[1]: Starting User Runtime Directory /run/user/0...
May 11 10:32:31 Fhemnew systemd[1]: Started User Runtime Directory /run/user/0.
May 11 10:32:31 Fhemnew systemd[1]: Starting User Manager for UID 0...
May 11 10:32:33 Fhemnew systemd[517]: Listening on GnuPG network certificate management daemon.
May 11 10:32:34 Fhemnew systemd[517]: Listening on GnuPG cryptographic agent (ssh-agent emulation).
May 11 10:32:34 Fhemnew systemd[517]: Listening on GnuPG cryptographic agent and passphrase cache (access for web browsers).
May 11 10:32:34 Fhemnew systemd[517]: Reached target Paths.
May 11 10:32:34 Fhemnew systemd[517]: Reached target Timers.
May 11 10:32:34 Fhemnew systemd[517]: Listening on GnuPG cryptographic agent and passphrase cache.
May 11 10:32:34 Fhemnew systemd[517]: Listening on GnuPG cryptographic agent and passphrase cache (restricted).
May 11 10:32:34 Fhemnew systemd[517]: Reached target Sockets.
May 11 10:32:34 Fhemnew systemd[517]: Reached target Basic System.
May 11 10:32:34 Fhemnew systemd[1]: Started User Manager for UID 0.
May 11 10:32:34 Fhemnew systemd[517]: Reached target Default.
May 11 10:32:34 Fhemnew systemd[517]: Startup finished in 1.920s.
May 11 10:32:34 Fhemnew systemd[1]: Started Session c1 of user root.
May 11 10:32:35 Fhemnew dhcpcd[438]: wlan0: fe80::464e:6dff:fe78:7224 is reachable again
May 11 10:32:35 Fhemnew dhcpcd[438]: wlan0: fe80::464e:6dff:fe78:7224 is reachable again
May 11 10:33:12 Fhemnew systemd[1]: dev-serial1.device: Job dev-serial1.device/start timed out.
May 11 10:33:12 Fhemnew systemd[1]: Timed out waiting for device /dev/serial1.
May 11 10:33:12 Fhemnew systemd[1]: Dependency failed for Configure Bluetooth Modems connected by UART.
May 11 10:33:12 Fhemnew systemd[1]: hciuart.service: Job hciuart.service/start failed with result 'dependency'.
May 11 10:33:12 Fhemnew systemd[1]: dev-serial1.device: Job dev-serial1.device/start failed with result 'timeout'.
May 11 10:33:12 Fhemnew systemd[1]: Reached target Multi-User System.
May 11 10:33:12 Fhemnew systemd[1]: Reached target Graphical Interface.
May 11 10:33:12 Fhemnew systemd[1]: Starting Update UTMP about System Runlevel Changes...
May 11 10:33:13 Fhemnew systemd[1]: systemd-update-utmp-runlevel.service: Succeeded.
May 11 10:33:13 Fhemnew systemd[1]: Started Update UTMP about System Runlevel Changes.
May 11 10:33:13 Fhemnew systemd[1]: Startup finished in 3.726s (kernel) + 1min 33.837s (userspace) = 1min 37.563s.[/code]
Nach Reset kommt dazu:
May 11 10:41:16 Fhemnew dhcpcd[438]: wlan0: Router Advertisement from fe80::464e:6dff:fe78:7224
May 11 10:43:39 Fhemnew dhcpcd[438]: wlan0: Router Advertisement from fe80::464e:6dff:fe78:7224
May 11 10:43:53 Fhemnew systemd[1]: fhem.service: Succeeded.
May 11 10:43:53 Fhemnew systemd[1]: fhem.service: Service RestartSec=100ms expired, scheduling restart.
May 11 10:43:53 Fhemnew systemd[1]: fhem.service: Scheduled restart job, restart counter is at 1.
May 11 10:43:53 Fhemnew systemd[1]: Stopped FHEM Home Automation.
May 11 10:43:53 Fhemnew systemd[1]: Starting FHEM Home Automation...
May 11 10:43:53 Fhemnew bash[589]: resetting 868MHz extension...
May 11 10:43:58 Fhemnew systemd[1]: Started FHEM Home Automation.
Hier die Service List:
root@Fhemnew:~# systemctl list-unit-files | grep enabled
autovt@.service enabled
avahi-daemon.service enabled
bluetooth.service enabled
console-setup.service enabled
cron.service enabled
dbus-fi.w1.wpa_supplicant1.service enabled
dbus-org.bluez.service enabled
dbus-org.freedesktop.Avahi.service enabled
dbus-org.freedesktop.timesync1.service enabled
dhcpcd.service enabled
dhcpcd5.service enabled
dphys-swapfile.service enabled
fake-hwclock.service enabled
fhem.service enabled
getty@.service enabled
hciuart.service enabled
keyboard-setup.service enabled
networking.service enabled
raspberrypi-net-mods.service enabled
rc-local.service enabled-runtime
rc.local.service enabled-runtime
rpi-display-backlight.service enabled
rpi-eeprom-update.service enabled
rsync.service enabled
rsyslog.service enabled
ssh.service enabled
sshd.service enabled
sshswitch.service enabled
syslog.service enabled
systemd-fsck-root.service enabled-runtime
systemd-timesyncd.service enabled
triggerhappy.service enabled
wpa_supplicant.service enabled
avahi-daemon.socket enabled
triggerhappy.socket enabled
nfs-client.target enabled
remote-fs.target enabled
apt-daily-upgrade.timer enabled
apt-daily.timer enabled
logrotate.timer enabled
man-db.timer enabled
root@Fhemnew:~#
Dann füge doch mal bitte als erste Zeile in dem Script EnableCOC.sh ein sleep 10 ein. Offenbar ist da die Umgebung noch nicht so weit. Wenn das geht, können wir vielleicht ein besseres Kriterium finden.
Leider auch dann keine Berechtigungen:
May 11 11:26:30 Fhemnew systemd[1]: Reached target Network.
May 11 11:26:30 Fhemnew systemd[1]: Starting /etc/rc.local Compatibility...
May 11 11:26:30 Fhemnew systemd[1]: Starting FHEM Home Automation...
May 11 11:26:30 Fhemnew systemd[1]: Condition check resulted in fast remote file copy program daemon being skipped.
May 11 11:26:30 Fhemnew systemd[1]: Starting OpenBSD Secure Shell server...
May 11 11:26:30 Fhemnew systemd[1]: Starting Permit User Sessions...
May 11 11:26:30 Fhemnew systemd[1]: Started /etc/rc.local Compatibility.
May 11 11:26:30 Fhemnew systemd[1]: Started Permit User Sessions.
May 11 11:26:31 Fhemnew systemd[1]: Started Getty on tty1.
May 11 11:26:31 Fhemnew systemd[1]: Reached target Login Prompts.
May 11 11:26:31 Fhemnew systemd[1]: Started OpenBSD Secure Shell server.
May 11 11:26:40 Fhemnew systemd[1]: systemd-fsckd.service: Succeeded.
May 11 11:26:40 Fhemnew bash[440]: resetting 868MHz extension...
May 11 11:26:40 Fhemnew bash[440]: /opt/fhem/EnableCOC.sh: Zeile 5: /sys/class/gpio/gpio17/direction: Keine Berechtigung
May 11 11:26:40 Fhemnew bash[440]: /opt/fhem/EnableCOC.sh: Zeile 6: /sys/class/gpio/gpio18/direction: Keine Berechtigung
May 11 11:26:40 Fhemnew bash[440]: /opt/fhem/EnableCOC.sh: Zeile 7: /sys/class/gpio/gpio18/value: Keine Berechtigung
May 11 11:26:40 Fhemnew bash[440]: /opt/fhem/EnableCOC.sh: Zeile 8: /sys/class/gpio/gpio17/value: Keine Berechtigung
May 11 11:26:41 Fhemnew bash[440]: /opt/fhem/EnableCOC.sh: Zeile 10: echo: Schreibfehler: Die Operation ist nicht erlaubt.
May 11 11:27:01 Fhemnew systemd-timesyncd[188]: Synchronized to time server for the first time [2001:8d8:1801:2e::2]:123 (2.debian.pool.ntp.org).
May 11 11:27:02 Fhemnew systemd[1]: Started FHEM Home Automation.
May 11 11:27:06 Fhemnew dhcpcd[438]: wlan0: fe80::464e:6dff:fe78:7224 is reachable again
May 11 11:27:06 Fhemnew dhcpcd[438]: wlan0: fe80::464e:6dff:fe78:7224 is reachable again
May 11 11:27:23 Fhemnew systemd[1]: Created slice User Slice of UID 0.
May 11 11:27:23 Fhemnew systemd[1]: Starting User Runtime Directory /run/user/0...
May 11 11:27:24 Fhemnew systemd[1]: Started User Runtime Directory /run/user/0.
May 11 11:27:24 Fhemnew systemd[1]: Starting User Manager for UID 0...
May 11 11:27:25 Fhemnew systemd[518]: Listening on GnuPG cryptographic agent (ssh-agent emulation).
May 11 11:27:25 Fhemnew systemd[518]: Listening on GnuPG cryptographic agent and passphrase cache.
May 11 11:27:25 Fhemnew systemd[518]: Listening on GnuPG network certificate management daemon.
May 11 11:27:25 Fhemnew systemd[518]: Reached target Paths.
May 11 11:27:25 Fhemnew systemd[518]: Listening on GnuPG cryptographic agent and passphrase cache (restricted).
May 11 11:27:25 Fhemnew systemd[518]: Listening on GnuPG cryptographic agent and passphrase cache (access for web browsers).
May 11 11:27:25 Fhemnew systemd[518]: Reached target Sockets.
May 11 11:27:25 Fhemnew systemd[518]: Reached target Timers.
May 11 11:27:25 Fhemnew systemd[518]: Reached target Basic System.
May 11 11:27:25 Fhemnew systemd[1]: Started User Manager for UID 0.
May 11 11:27:25 Fhemnew systemd[518]: Reached target Default.
May 11 11:27:25 Fhemnew systemd[518]: Startup finished in 773ms.
May 11 11:27:25 Fhemnew systemd[1]: Started Session c1 of user root.
May 11 11:27:44 Fhemnew systemd[1]: dev-serial1.device: Job dev-serial1.device/start timed out.
May 11 11:27:44 Fhemnew systemd[1]: Timed out waiting for device /dev/serial1.
May 11 11:27:44 Fhemnew systemd[1]: Dependency failed for Configure Bluetooth Modems connected by UART.
May 11 11:27:44 Fhemnew systemd[1]: hciuart.service: Job hciuart.service/start failed with result 'dependency'.
May 11 11:27:44 Fhemnew systemd[1]: dev-serial1.device: Job dev-serial1.device/start failed with result 'timeout'.
May 11 11:27:44 Fhemnew systemd[1]: Reached target Multi-User System.
May 11 11:27:44 Fhemnew systemd[1]: Reached target Graphical Interface.
May 11 11:27:44 Fhemnew systemd[1]: Starting Update UTMP about System Runlevel Changes...
May 11 11:27:44 Fhemnew systemd[1]: systemd-update-utmp-runlevel.service: Succeeded.
May 11 11:27:44 Fhemnew systemd[1]: Started Update UTMP about System Runlevel Changes.
May 11 11:27:44 Fhemnew systemd[1]: Startup finished in 3.714s (kernel) + 1min 34.005s (userspace) = 1min 37.720s.
May 11 11:28:39 Fhemnew dhcpcd[438]: wlan0: Router Advertisement from fe80::464e:6dff:fe78:7224
Kannst Du bitte "step by step" folgendes deaktiviweren und testen?
bluetooth.service enabled
getty@.service enabled
hciuart.service enabled
Was mich bei der Liste wundert (ahci und dbus), was für ein Installationsmedium nimmst Du? Server (light) oder Desktop??
Dauert etwas, ich habe mit Buster Lite und Fhem nach der Anleitung im FHEM WIKI geladen.
Also erstmal hciuart dann bluetooth, keine Veränderung und danach getty versucht, da hiest not loaded??
Übrigens wenn ich das System ohne korrekte fhem.cfg starte, geht es ja automatisch in reset und der COC läuft, aber ohne fhem.cfg
Sorry bei getty hatte ich das @ vergessen, aber da will er auch nicht richtig und sagt missing the instance name.
ich habe etwas rum probiert. Irgendwie schaffe ich es nicht EnableCOC innerhalb der fhem.service unit zu starten (liegt es am user?).
Edit: Es liegt am user.
Extra starten dagegen geht sofort.
Also relativer Schnellschuss (getestet)
sudo su
nano /etc/systemd/system/fhem.service
Zeile ExecStartPre in der fhem.service auskommentieren.
Edit: Zur Sicherheit könnte man noch diese Zeile einfügen
After=EnableCOC.service
Die Datei /etc/systemd/system/EnableCOC.service mit nano und diesem Inhalt erzeugen
[Unit]
Description=EnableCOC
#After=network.target
[Service]
Type=oneshot
ExecStart=bash /opt/fhem/EnableCOC.sh
StandardOutput=journal
[Install]
WantedBy=multi-user.target
dann Dienst aktivieren
systemctl daemon-reload
systemctl enable EnableCOC
System neu starten
reboot
Ich werde es später ausprobieren, jetzt läuft FHEM überhaupt nicht mehr, ich melde mich dann wieder.
Super, Otto gibt nie auf!!! Es läuft!!!
Den Zusatz "After=EnableCOC.service" habe ich nicht gebraucht.
Für dich noch mal das Syslog, der Service EnableCOC startet jetzt ziemlich für und es läuft.
Vielen Dank nochmal für deine Geduld und ich werde berichten ob das System sonst stabil läuft.
May 11 13:00:06 Fhemnew systemd[1]: Started triggerhappy global hotkey daemon.
May 11 13:00:06 Fhemnew systemd[1]: Started System Logging Service.
May 11 13:00:06 Fhemnew systemd[1]: Started rng-tools.service.
May 11 13:00:07 Fhemnew systemd[1]: Started Save/Restore Sound Card State.
May 11 13:00:07 Fhemnew dphys-swapfile[253]: want /var/swap=100MByte, checking existing: keeping it
May 11 13:00:07 Fhemnew systemd[1]: Started Check for Raspberry Pi EEPROM updates.
May 11 13:00:07 Fhemnew wpa_supplicant[291]: Successfully initialized wpa_supplicant
May 11 13:00:07 Fhemnew systemd[1]: EnableCOC.service: Succeeded.
May 11 13:00:07 Fhemnew systemd[1]: Started EnableCOC.
May 11 13:00:07 Fhemnew systemd[1]: systemd-rfkill.service: Succeeded.
May 11 13:00:07 Fhemnew dhcpcd[261]: wlan0: starting wpa_supplicant
May 11 13:00:07 Fhemnew dhcpcd-run-hooks[322]: wlan0: starting wpa_supplicant
May 11 13:00:07 Fhemnew systemd[1]: Started Login Service.
May 11 13:00:07 Fhemnew raspi-config[244]: Checking if shift key is held down:Error opening '/dev/input/event*': No such file or directory
May 11 13:00:07 Fhemnew systemd[1]: Reached target Sound Card.
May 11 13:00:07 Fhemnew systemd[1]: Started WPA supplicant.
May 11 13:00:07 Fhemnew raspi-config[244]: No. Switching to ondemand scaling governor.
May 11 13:00:07 Fhemnew systemd[1]: Started Avahi mDNS/DNS-SD Stack.
May 11 13:00:07 Fhemnew kernel: [ 28.136468] Adding 102396k swap on /var/swap. Priority:-2 extents:1 across:102396k SSFS
May 11 13:00:08 Fhemnew systemd[1]: Started LSB: Switch to ondemand cpu governor (unless shift key is pressed).
May 11 13:00:08 Fhemnew systemd[1]: Started dphys-swapfile - set up, mount/unmount, and delete a swap file.
May 11 13:00:08 Fhemnew kernel: [ 28.377945] rtl8192cu: MAC auto ON okay!
May 11 13:00:08 Fhemnew kernel: [ 28.441294] rtl8192cu: Tx queue select: 0x05
May 11 13:00:10 Fhemnew kernel: [ 30.450758] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
May 11 13:00:10 Fhemnew dhcpcd[261]: wlan0: connected to Access Point `'
May 11 13:00:10 Fhemnew dhcpcd[261]: eth0: waiting for carrier
May 11 13:00:10 Fhemnew kernel: [ 30.866708] smsc95xx 1-1.1:1.0 eth0: hardware isn't capable of remote wakeup
May 11 13:00:10 Fhemnew kernel: [ 30.868378] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
May 11 13:00:10 Fhemnew dhcpcd[261]: wlan0: waiting for carrier
May 11 13:00:10 Fhemnew dhcpcd[261]: wlan0: carrier acquired
May 11 13:00:10 Fhemnew dhcpcd[261]: DUID 00:01:00:01:25:d8:31:77:4c:60:de:5c:21:42
May 11 13:00:10 Fhemnew dhcpcd[261]: wlan0: IAID de:5c:21:42
May 11 13:00:10 Fhemnew dhcpcd[261]: wlan0: adding address fe80::20c5:8888:b295:bfa
May 11 13:00:10 Fhemnew avahi-daemon[276]: Joining mDNS multicast group on interface wlan0.IPv6 with address fe80::20c5:8888:b295:bfa.
May 11 13:00:10 Fhemnew avahi-daemon[276]: New relevant interface wlan0.IPv6 for mDNS.
May 11 13:00:10 Fhemnew avahi-daemon[276]: Registering new address record for fe80::20c5:8888:b295:bfa on wlan0.*.
May 11 13:00:10 Fhemnew dhcpcd[261]: wlan0: carrier lost
May 11 13:00:10 Fhemnew dhcpcd[261]: wlan0: deleting address fe80::20c5:8888:b295:bfa
May 11 13:00:10 Fhemnew avahi-daemon[276]: Withdrawing address record for fe80::20c5:8888:b295:bfa on wlan0.
May 11 13:00:10 Fhemnew avahi-daemon[276]: Leaving mDNS multicast group on interface wlan0.IPv6 with address fe80::20c5:8888:b295:bfa.
May 11 13:00:10 Fhemnew avahi-daemon[276]: Interface wlan0.IPv6 no longer relevant for mDNS.
May 11 13:00:11 Fhemnew kernel: [ 31.834745] wlan0: authenticate with 44:4e:6d:78:72:27
May 11 13:00:11 Fhemnew kernel: [ 31.879188] wlan0: send auth to 44:4e:6d:78:72:27 (try 1/3)
May 11 13:00:11 Fhemnew kernel: [ 31.883812] wlan0: authenticated
May 11 13:00:11 Fhemnew kernel: [ 31.892446] wlan0: associate with 44:4e:6d:78:72:27 (try 1/3)
May 11 13:00:11 Fhemnew kernel: [ 31.925644] wlan0: RX AssocResp from 44:4e:6d:78:72:27 (capab=0x1031 status=0 aid=3)
May 11 13:00:11 Fhemnew kernel: [ 32.039971] wlan0: associated
May 11 13:00:11 Fhemnew kernel: [ 32.044780] wlan0: Limiting TX power to 20 (20 - 0) dBm as advertised by 44:4e:6d:78:72:27
May 11 13:00:13 Fhemnew kernel: [ 33.247943] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
May 11 13:00:13 Fhemnew dhcpcd[261]: wlan0: carrier acquired
May 11 13:00:13 Fhemnew dhcpcd[261]: wlan0: connected to Access Point `IT2'
May 11 13:00:13 Fhemnew dhcpcd[261]: wlan0: IAID de:5c:21:42
May 11 13:00:13 Fhemnew dhcpcd[261]: wlan0: adding address fe80::6d30:8d4a:8abb:3b49
May 11 13:00:13 Fhemnew avahi-daemon[276]: Joining mDNS multicast group on interface wlan0.IPv6 with address fe80::6d30:8d4a:8abb:3b49.
May 11 13:00:13 Fhemnew avahi-daemon[276]: New relevant interface wlan0.IPv6 for mDNS.
May 11 13:00:13 Fhemnew avahi-daemon[276]: Registering new address record for fe80::6d30:8d4a:8abb:3b49 on wlan0.*.
May 11 13:00:13 Fhemnew dhcpcd[261]: wlan0: soliciting an IPv6 router
May 11 13:00:14 Fhemnew dhcpcd[261]: wlan0: rebinding lease of 192.168.178.40
May 11 13:00:14 Fhemnew dhcpcd[261]: wlan0: probing address 192.168.178.40/24
May 11 13:00:14 Fhemnew kernel: [ 34.497881] ICMPv6: process `dhcpcd' is using deprecated sysctl (syscall) net.ipv6.neigh.wlan0.retrans_time - use net.ipv6.neigh.wlan0.retrans_time_ms instead
May 11 13:00:14 Fhemnew dhcpcd[261]: wlan0: Router Advertisement from fe80::464e:6dff:fe78:7224
May 11 13:00:14 Fhemnew dhcpcd[261]: wlan0: adding address 2003:c0:a719:2000:14d3:755b:87f3:dbec/64
May 11 13:00:14 Fhemnew avahi-daemon[276]: Leaving mDNS multicast group on interface wlan0.IPv6 with address fe80::6d30:8d4a:8abb:3b49.
May 11 13:00:14 Fhemnew avahi-daemon[276]: Joining mDNS multicast group on interface wlan0.IPv6 with address 2003:c0:a719:2000:14d3:755b:87f3:dbec.
May 11 13:00:14 Fhemnew avahi-daemon[276]: Registering new address record for 2003:c0:a719:2000:14d3:755b:87f3:dbec on wlan0.*.
May 11 13:00:14 Fhemnew avahi-daemon[276]: Withdrawing address record for fe80::6d30:8d4a:8abb:3b49 on wlan0.
May 11 13:00:14 Fhemnew dhcpcd[261]: wlan0: adding route to 2003:c0:a719:2000::/64
May 11 13:00:14 Fhemnew dhcpcd[261]: wlan0: requesting DHCPv6 information
May 11 13:00:14 Fhemnew dhcpcd[261]: wlan0: fe80::464e:6dff:fe78:7224 is reachable again
May 11 13:00:14 Fhemnew dhcpcd[261]: wlan0: adding default route via fe80::464e:6dff:fe78:7224
May 11 13:00:15 Fhemnew dhcpcd[261]: Too few arguments.
May 11 13:00:15 Fhemnew dhcpcd[261]: Too few arguments.
May 11 13:00:19 Fhemnew dhcpcd[261]: wlan0: leased 192.168.178.40 for 864000 seconds
May 11 13:00:19 Fhemnew avahi-daemon[276]: Joining mDNS multicast group on interface wlan0.IPv4 with address 192.168.178.40.
May 11 13:00:19 Fhemnew avahi-daemon[276]: New relevant interface wlan0.IPv4 for mDNS.
May 11 13:00:19 Fhemnew avahi-daemon[276]: Registering new address record for 192.168.178.40 on wlan0.IPv4.
May 11 13:00:19 Fhemnew dhcpcd[261]: wlan0: adding route to 192.168.178.0/24
May 11 13:00:19 Fhemnew dhcpcd[261]: wlan0: adding default route via 192.168.178.1
May 11 13:00:20 Fhemnew dhcpcd[261]: Too few arguments.
May 11 13:00:20 Fhemnew dhcpcd[261]: Too few arguments.
May 11 13:00:20 Fhemnew dhcpcd[261]: forked to background, child pid 453
May 11 13:00:20 Fhemnew systemd[1]: Started dhcpcd on all interfaces.
May 11 13:00:20 Fhemnew systemd[1]: Reached target Network.
May 11 13:00:20 Fhemnew systemd[1]: Starting /etc/rc.local Compatibility...
May 11 13:00:20 Fhemnew systemd[1]: Starting Permit User Sessions...
May 11 13:00:20 Fhemnew systemd[1]: Condition check resulted in fast remote file copy program daemon being skipped.
May 11 13:00:20 Fhemnew systemd[1]: Starting OpenBSD Secure Shell server...
May 11 13:00:20 Fhemnew systemd[1]: Starting FHEM Home Automation...
May 11 13:00:20 Fhemnew systemd[1]: Started /etc/rc.local Compatibility.
May 11 13:00:21 Fhemnew systemd[1]: Started Permit User Sessions.
May 11 13:00:21 Fhemnew systemd[1]: Started Getty on tty1.
May 11 13:00:21 Fhemnew systemd[1]: Reached target Login Prompts.
May 11 13:00:21 Fhemnew systemd[1]: Started OpenBSD Secure Shell server.
May 11 13:00:24 Fhemnew systemd[1]: Created slice User Slice of UID 0.
May 11 13:00:24 Fhemnew systemd[1]: Starting User Runtime Directory /run/user/0...
May 11 13:00:25 Fhemnew systemd[1]: Started User Runtime Directory /run/user/0.
May 11 13:00:25 Fhemnew systemd[1]: Starting User Manager for UID 0...
May 11 13:00:27 Fhemnew systemd[1]: Started FHEM Home Automation.
May 11 13:00:27 Fhemnew systemd[1]: Reached target Multi-User System.
May 11 13:00:27 Fhemnew systemd[1]: Reached target Graphical Interface.
May 11 13:00:27 Fhemnew systemd[1]: Starting Update UTMP about System Runlevel Changes...
May 11 13:00:27 Fhemnew systemd[1]: systemd-update-utmp-runlevel.service: Succeeded.
May 11 13:00:27 Fhemnew systemd[1]: Started Update UTMP about System Runlevel Changes.
May 11 13:00:28 Fhemnew systemd[467]: Listening on GnuPG cryptographic agent and passphrase cache (restricted).
May 11 13:00:28 Fhemnew systemd[467]: Listening on GnuPG cryptographic agent and passphrase cache (access for web browsers).
May 11 13:00:28 Fhemnew systemd[467]: Reached target Timers.
May 11 13:00:28 Fhemnew systemd[467]: Listening on GnuPG network certificate management daemon.
May 11 13:00:28 Fhemnew systemd[467]: Listening on GnuPG cryptographic agent and passphrase cache.
May 11 13:00:28 Fhemnew systemd[467]: Reached target Paths.
May 11 13:00:28 Fhemnew systemd[467]: Listening on GnuPG cryptographic agent (ssh-agent emulation).
May 11 13:00:28 Fhemnew systemd[467]: Reached target Sockets.
May 11 13:00:28 Fhemnew systemd[467]: Reached target Basic System.
May 11 13:00:28 Fhemnew systemd[1]: Started User Manager for UID 0.
May 11 13:00:28 Fhemnew systemd[467]: Reached target Default.
May 11 13:00:28 Fhemnew systemd[467]: Startup finished in 2.689s.
May 11 13:00:28 Fhemnew systemd[1]: Started Session c1 of user root.
May 11 13:00:28 Fhemnew systemd[1]: Startup finished in 3.714s (kernel) + 44.872s (userspace) = 48.587s.
May 11 13:00:29 Fhemnew systemd[1]: systemd-fsckd.service: Succeeded.
May 11 13:00:51 Fhemnew systemd-timesyncd[195]: Synchronized to time server for the first time [2001:a60::123:2]:123 (2.debian.pool.ntp.org).
May 11 13:00:56 Fhemnew dhcpcd[453]: wlan0: fe80::464e:6dff:fe78:7224 is reachable again
May 11 13:00:56 Fhemnew dhcpcd[453]: wlan0: fe80::464e:6dff:fe78:7224 is reachable again
Prima! Das freut mich. Die Idee kam mir, weil ich aus dem von mir verlinktem Thread mit dem SCC noch im Hinterkopf hatte: ... hab es dann mit rc.local gelöst...
Da gab es wohl auch Berechtigungsmeldungen. Aber so klar wie hier wurde das nicht aufgearbeitet.
Ich sehe schon, die Aufgabe für den fhem Start in speziellen Fällen wird immer umfangreicher: ::)
...
ich stelle eine dumme Anfängerfrage:
was ist denn der Vorteil von Buster bzgl. FHEM ?
Zitat von: thburkhart am 11 Mai 2020, 13:40:16
was ist denn der Vorteil von Buster bzgl. FHEM ?
Es ist einfach das aktuelle Linux System ...
Die alten Systeme könnten Nachteile haben...
wenn ich also unter https://www.raspberrypi.org/downloads/
mit Hilfe des Raspberry Pi Imager for Windows als OS Raspberry auswähle, dann ist das "Buster"?
Ja, die aktuellen Raspbian-Versionen basieren auf Buster.
Zitat von: thburkhart am 11 Mai 2020, 13:40:16
ich stelle eine dumme Anfängerfrage:
was ist denn der Vorteil von Buster bzgl. FHEM ?
Wheezy (https://www.debian.org/releases/wheezy/) stammt aus 2013, der LTS-Support ist Ende Mai 2018 ausgelaufen. D.h., das System hat seit 2 Jahren keinen Support mehr.
Für Jessie (https://www.debian.org/releases/jessie/) läuft der LTS-Support Ende Juni aus. Ab dann gibt es auch dafür keine Sicherheits-Updates mehr.
Stretch (https://www.debian.org/releases/stretch/) wird noch bis Juni 2022 supported.
Wenn man aber jetzt gerade ein Update oder eine Neuinstallation machen will, dann sollte man auch direkt auf Buster umsteigen.
Und bitte gleich ein LITE also OHNE Desktop...
Gruß, Joachim
P.S.: egal welche Version ;)
danke sehr
kommt man in der Lite dann auch direkt per putty SSH drauf?
oder anders wie mache ich die Desktopversion putty-fähig?
Gesendet von meinem SM-G950F mit Tapatalk
Selbstverständlich kann jede Version ssh. Empfehlung: lite nehmen.
Muß man nicht bei Raspian etwas "mit einer Datei" machen, weil sonst ssh erstmal deaktiv ist?
Debian geht jedenfalls sofort
Zitat von: Wernieman am 11 Mai 2020, 16:11:09
Muß man nicht bei Raspian etwas "mit einer Datei" machen, weil sonst ssh erstmal deaktiv ist?
Debian geht jedenfalls sofort
wenn man headless installieren will - ja. Wenn man mit Monitor und Tastatur installiert muss man es über raspi-config aktivieren.
Zitat von: Otto123 am 11 Mai 2020, 16:23:48
Wenn man mit Monitor und Tastatur installiert muss man es über raspi-config aktivieren.
wo finde ich dieses raspi-config in der Desktop oberfäche?
Zitatraspi-config in der Desktop oberfäche?
1. Bitte LIGHT nehmen, ohne Desktop!
2. raspi-config einfach in der shell eingeben ....
Ich vermute Du meinst, wie mache ich ein lite-image vor dem ersten Start putty-fähig?
Dazu musst die eine Datei "ssh" anlegen wie z, B, dort beschrieben
http://raspberry.tips/raspberrypi-tutorials/ssh-am-raspberry-pi-aktivieren-neue-methode-mit-raspbian-25-11-2016 (http://raspberry.tips/raspberrypi-tutorials/ssh-am-raspberry-pi-aktivieren-neue-methode-mit-raspbian-25-11-2016)
Hallo zusammen,
ich setze gerade eine neue SD Karte für mein FHEM auf. FHEM ist installiert, aber der Service kann nicht gestartet werden. Fehlermeldungen anbei:
● fhem.service - FHEM Home Automation
Loaded: loaded (/etc/systemd/system/fhem.service; enabled; vendor preset: enabled)
Active: inactive (dead) since Mon 2020-12-28 18:25:34 CET; 2h 4min ago
Dez 28 18:25:34 PMRPI04 systemd[1]: fhem.service: Service RestartSec=100ms expired, scheduling restart.
Dez 28 18:25:34 PMRPI04 systemd[1]: fhem.service: Scheduled restart job, restart counter is at 5.
Dez 28 18:25:34 PMRPI04 systemd[1]: Stopped FHEM Home Automation.
Dez 28 18:25:34 PMRPI04 systemd[1]: fhem.service: Start request repeated too quickly.
Dez 28 18:25:34 PMRPI04 systemd[1]: fhem.service: Failed with result 'exit-code'.
Dez 28 18:25:34 PMRPI04 systemd[1]: Failed to start FHEM Home Automation.
Mein fhem.service sieht so aus:
# $Id: fhem.service 19235 2019-04-21 13:26:17Z betateilchen $
[Unit]
Description=FHEM Home Automation
Wants=network.target
After=network.target
#Requires=postgresql.service
#After=postgresql.service
#Requires=mysql.service
#After=mysql.service
[Service]
Type=forking
User=fhem
Group=dialout
WorkingDirectory=/opt/fhem
ExecStart=/usr/bin/perl fhem.pl fhem.cfg
#ExecStart=/usr/bin/perl fhem.pl configDB
Restart=always
RestartSec=30
[Install]
WantedBy=multi-user.target
Ich habe schon in das Skript RestartSec=30 eingefügt, geht aber auch nicht.
Hat jemand eine Idee? Das Dumme ist, mein solarview Skript funktioniert :o.
Danke + Gruß
Peter
Hallo Peter,
aber die Fehlermeldung passt jetzt so gar nicht zu deinem Script.
Zitatfhem.service: Service RestartSec=100ms expired
redest Du jetzt von einem neu installiertem FHEM oder nach der Wiederherstellung Deines Backups?
Gruß Otto
Hallo Otto,
ich rede von einer Neuinstallation, danach kopiere ich die FHEM Dateien von der alten Installation zurück. Ich habe (aus anderen Gründen) den Raspberry Pi neu gestartet und - siehe da - es funktioniert (warum auch immer) :o :o :o
Gruß Peter
Du hast den systemd-Deamon nach Config Änderung nicht "reloaded".
Zitat von: Wernieman am 29 Dezember 2020, 13:46:59
Du hast den systemd-Deamon nach Config Änderung nicht "reloaded".
doch, ich meine schon ???
Zumindest steht in meinem Mitschrieb
sudo systemctl daemon-reloadGruß Peter
PS: Ich habe nach langem Irren und Wirren sogar locutus' LCD Board (https://forum.fhem.de/index.php/topic,14156.msg1115299.html#msg1115299) wieder angesteuert bekommen.
Ich habe jetzt klug reden - ich bin auch nur zufällig drauf gestoßen - aber wenn man es "richtig" macht, ist der daemon-reload inklusive :)
sudo systemctl edit --full fhem
Hallo zusammen,
es ist zum Verzweifeln. Ich hatte mal den CSM von Damian's Display laufen, vermutlich hat aber raspi.config wieder irgendwo etwas reingeschrieben. Folgender Status:
- ich kann die Firmware flashen (mit Hilfe seines Skriptes (https://forum.fhem.de/index.php?action=dlattach;topic=14156.0;attach=16973))
- dev/ttyAMA0 ist sichtbar
- der CUL in FHEM ist aber nur opened
sprich: ich schließe Hardwarefehler aus (weil ich den CSM flashen kann).
Irgendwie passt die Umsortierung Bluetooth/seriell nicht. Ich habe bei Otto (https://heinz-otto.blogspot.com/2019/05/setup-raspberry-pi-2019.html) noch mal nachgeschaut,
aber es scheint alles so weit ok zu sein. Habt ihr noch einen Tipp für mich?
Mein Model: Raspberry Pi 3 Model B Rev 1.2.
Habt ihr noch einen Tipp für mich?
Danke + Gruß
Peter
Hallo Peter,
es gab da in letzter Zeit verschiedene "Störer", ich zähle einfach mal auf:
FHEM klappert beim Start alle Schnittstellen ab und stört -> initialUsbCheck disable 1
Bluetooth geht nach FHEM Start nicht, FHEM Start verzögern (steht im fhem.service Artikel im Wiki)
deconz / conbee klappert beim Start alle seriellen Schnittstellen ab und nimmt sie sogar in Beschlag.
Also potentiell ist jede Software die irgendwas mit Schnittstellen macht in der Lage den Adapter zu stören.
Guten Rutsch
Otto
Zitat von: Otto123 am 31 Dezember 2020, 16:05:38
es gab da in letzter Zeit verschiedene "Störer", ich zähle einfach mal auf:
FHEM klappert beim Start alle Schnittstellen ab und stört -> initialUsbCheck disable 1
Bluetooth geht nach FHEM Start nicht, FHEM Start verzögern (steht im fhem.service Artikel im Wiki)
deconz / conbee klappert beim Start alle seriellen Schnittstellen ab und nimmt sie sogar in Beschlag.
Also potentiell ist jede Software die irgendwas mit Schnittstellen macht in der Lage den Adapter zu stören.
Danke, aber leider war es das nicht. Ich habe auf dem Display I2C auf den Raspberry Pi umgelegt (damit ich die 1-wire Sensoren der USV auslesen kann), und da braucht es leider eine spezielle Firmware, siehe https://forum.fhem.de/index.php?action=dlattach;topic=14156.0;attach=125681
Wünsche Dir bzw. auch allen Forumskollegen ein gutes neues Jahr.
Gruß Peter
Hallo Zusammen,
auch ich habe mich nun dazu entschieden von Wheezy auf Buster zu migrieren.
Ich denke die Vorgehensweise ist soweit klar, allerdings frage ich mich warum ich die Lite anstelle der Desktop Version nehmen soll.
Bisher habe ich immer bei Bedarf mit VNC angemeldet und konnte dann "meine Sachen" einfach so mit dem Desktop erledigen.
Zur Not könnte ja auch der Autostart deaktiert werden wenn es doch Probleme gibt ?
Vielen Dank, Michael
Auch wenn Du den Desktop "deaktivierst", sind die Dateien drauf. Besser ist es deshalb, per ssh, also Konsole, den Server zu bearbeiten.
Die Schwierigkeiten: Update, Sicherheit, ......
Deshalb IMMER die Empfehlung: Light!
Hallo,
OK Danke für die Info.
Dann werde ich wohl mal loslegen... :)
Hallo zusammen,
seit 2 Wochen läuft nun mein FHEM auf Buster einwandfrei.
D.h. der Umzug selber war kein Problem, ich hatte nur 2 "Fehler".
Zuerst konnten keine GPIO Ports geschaltet werden, da hatte ich vergessen den FHEM user der Gruppe GPIO hinzufügen.
Danach liessen sich Pin 24/26 nicht richtig schalten, was aber daran lag das ich in der Raspi-Config SPI aktiviert hatte welches eben diese Pins (bzw. GPIO 7/8) auch verwendet.
Ich habe daher nun meine Doku entsprechend angepasst :-)
VG, Michael