Raspberry Pi Umstieg auf Raspberry Pi 3B+ und von Wheezy zu Buster

[mfeske]

Hallo zusammen,

mein Raspberry Pi ist in die Tage gekommen und ich denke ich sollte FHEM auch etwas mehr Performance können. Deshalb plane ich den Umstieg von einem Raspberry Pi auf Raspberry Pi 3B+ und damit einen Sprung von Wheezy zu Buster. Ein Upgrade von Wheezy zu Buster gibt es wohl nicht, so bleibt mir wohl nur auf dem Raspberry Pi 3B+ Buster komplett neu einzurichten, das sollte noch gehen.

Wie bekomme ich dann aber meine FHEM Installation mit allen Einstellungen etc. schadfrei rüber ? Ich glaube es gab auch Besonderheiten bei der festen Zuweisung der CUL zu USB und HMLan.

Hat das vielleicht schon jemand mal gemacht und evt. dokumentiert ?

Gruß
Micha

[MadMax-FHEM]

Nicht übel nehmen:

gefühlt ist das ganze Forum voll mit dieser oder ähnlicher Frage und auch entsprechenden Antworten.

Hier kurz (trotzdem):

backup jetziges System: siehe fhem backup

SD-Karte mit neuem System Buster (oder doch noch Stretch) ABER: lite!

OS etc. einrichten: Speicher, locale, andere besondere Einstellungen, ...

fhem installieren

Dann in der eigenen Doku schauen, ob weitere Perl-Pakete notwendig sind (oder andere Dinge: Startscripte, ...)

Dann Backup von altem/jetzigen fhem übertragen, auspacken: fertig (wenn nicht was vergessen wurde: z.B. Perl-Pakete etc.)

Das mit CUL: entweder exakt so stecken (wenn mit /by-path) oder wenn mit /by-id dann sollte es einfach klappen...
...ansonsten halt mal einen nach dem anderen stecken, schauen wo/wie sie "auftauchen" und dann entsprechendes "DEF" anpassen (falls nötig)...

Gruß, Joachim

[mfeske]

Hallo Joachim,

ich werde niemandem etwas Übel nehmen der mir hilft
Das mit der Neuinstallation und dem Backup hatte ich gefunden und auch schon verstanden.
Sorge machen mir die Perl-Pakete wo ich nicht weiss welche ich wann wie installiert habe fehlende Doku.
Das mit dem stecken der Cul´s habe ich nicht ganz verstanden. Wie soll ich Sie exakt gleich stecken ? Der neue hat ja dann ausreichend Ports so das ich eigentlich den Hub einsparen möchte. Ich weiss auch nicht mehr ob ich mit ids hantiert habe und wo ich das finde
Ist die hmlan Installation den auch im Backup ?
Gruß
Micha

[MadMax-FHEM]

Naja mit exakt stecken meinte ich eigentlich, selben Port wie zuvor...

Ah, ok, wenn du bislang einen USB-HUB hattest, dann musst du schauen wie du bisher eingebunden hast.
Wo/wie du das siehst!?

Einfach den DEF des entsprechenden Gerätes in fhem anschauen...
Wenn per /by-id sollte es keine Probleme geben...
...ansonsten wie geschrieben:

einen nach dem anderen stecken und auf OS-Ebene schauen wie der jeweilige "angelegt" wird/wurde und dann eben die entsprechende DEF anpassen...

Mit HMLAN meinst du HMLAN?
Das sollte im Backup drin sein...

Wenn du hmland (also HM-CFG-USB) meinst: NEIN!

Da ist es wohl besser neu mit den Sourcen zu beginnen und "nachbauen" auf dem neuen System.

Aber Achtung: seit Jessie bzw. auf jeden Fall Strech (und somit wohl auch Buster) ist nicht mehr initd (mit Startcripten unter /etc/init.d/) sondern systemd (mit Startscripten unter /etc/systemd/system/ ).
Auch fhem!

D.h. für hmland musst du ebenfalls ein Startscript erstellen (da gibt es aber ein Wiki zu)...

Perl Pakete: einfach mal Backup einspielen, dann ins Log schauen welche Module WARUM (meist: fehlendes Perl-Paket   ) nicht geladen werden konnten und dann eben nach und nach installieren...
...und diesmal: DOKUMENTIEREN!

Hilft auch bei einem System-Crash, weil man dann schnell wieder auf die Beine kommt.

Dauert bei mir (mit entspr. Doku) unter einer halben Stunde...
...dabei dauert das Schreiben von OS auf SD noch mit am längsten

Gruß, Joachim

[kroman]

so bleibt mir wohl nur auf dem Raspberry Pi 3B+ Buster komplett neu einzurichten

Welches Buster OS hast du geplant zu verwenden?
Raspbian Buster gibt es hier noch nicht...

https://www.raspberrypi.org/downloads/raspbian/

[mfeske]

@kroman Raspbian Buster Ich bin ja noch am planen und das kann dauern und nach den Hinweisen zu hmland von @MadMax-FHEM habe ich jetzt Angst  und ja ich werde das Neuaufsetzen *dokumentieren*

[MadMax-FHEM]

@kroman Raspbian Buster Ich bin ja noch am planen und das kann dauern und nach den Hinweisen zu hmland von @MadMax-FHEM habe ich jetzt Angst  und ja ich werde das Neuaufsetzen *dokumentieren*

So schlimm ist das nicht.
Theoretisch kannst du auch hmland einfach auf das neue System kopieren...

Allerdings würde ich ein neu compilieren auf dem neuen System vorziehen...
...ebenso wie eine Neuinstallation mit neuem OS (und neuer SD!) statt einem Upgrade...

Gruß, Joachim

[mfeske]

Hallo Joachim,

ich bin völlig durcheinander

Code Auswählen Erweitern

   IFmodel    LAN
   NAME       hmusb
   NR         217
   NTFY_ORDER 50-hmusb
   PARTIAL   
   RAWMSG     E308E84,0000,0E952506,FF,FFB3,028610308E840000000AA8E00B0F00
   RSSI       -77
   STATE      opened
   TYPE       HMLAN
ist doch hmland ?!

oder wo finde ich jetzt welches ?

ls -la opt/hmcfgusb/ zeiget aber auch hmland

[Beta-User]

Hmm, ohne jetzt hmland-Erfahrung zu haben, meine ich mich erinnern zu können, dass man das recht mit den alten USB-Dingern recht einfach auf HMUARTLGW umstellen kann, oder?

Und beim Rest: nur Mut! Irgendwann weiß man, an welchen Stellen es hakt, und du mußt den 1-er ja nicht gleich wegwerfen . Also vorbereiten ("by-id", IP-Adresse des FHEM-Servers möglichst beibehalten), ggf. Testen, was man vorher schon umstellen kann und dann los auf der neuen Mühle+ins log sehen => bis es klappt!

[MadMax-FHEM]

Hallo Joachim,

ich bin völlig durcheinander

Code Auswählen Erweitern

   IFmodel    LAN
   NAME       hmusb
   NR         217
   NTFY_ORDER 50-hmusb
   PARTIAL   
   RAWMSG     E308E84,0000,0E952506,FF,FFB3,028610308E840000000AA8E00B0F00
   RSSI       -77
   STATE      opened
   TYPE       HMLAN
ist doch hmland ?!

oder wo finde ich jetzt welches ?

ls -la opt/hmcfgusb/ zeiget aber auch hmland

Vermutlich ist es hmland also ein HM-CFG-USB...

Du musst doch wissen, was du gesteckt hast um mit HomeMatic Geräten zu funken!

Es ist wohl ein weißer USB-Stick...
...mit grüner LED die ab und an blinkt...

Hmm, ohne jetzt hmland-Erfahrung zu haben, meine ich mich erinnern zu können, dass man das recht mit den alten USB-Dingern recht einfach auf HMUARTLGW umstellen kann, oder?

Hmmm, das weiß ich jetzt nicht...
...aber wie geschrieben: ein Neuaufsetzen des hmland ist nicht wirklich schwer.
Wenn man nach dem Wiki vorgeht sind es ja nur wenige Schritte.

ABER (noch mal): dort wo es dann um Autostart geht, also /etc/init.d/ usw. STOP! Dann ein Wiki suchen wo beschrieben wird wie fhem (und hmland) NEU mittels systemd gestartet werden!

EDIT: fhem macht das automatisch schon so (wenn "the easy way" installiert wird bzw. mindestens per Debian-Paket)...

Und beim Rest: nur Mut! Irgendwann weiß man, an welchen Stellen es hakt, und du mußt den 1-er ja nicht gleich wegwerfen . Also vorbereiten ("by-id", IP-Adresse des FHEM-Servers möglichst beibehalten), ggf. Testen, was man vorher schon umstellen kann und dann los auf der neuen Mühle+ins log sehen => bis es klappt!

Da kann ich nur zustimmen!!
Wird wohl eh Zeit, dass du mal einen Restore "übst"!

Gruß, Joachim

[Beta-User]

...aber wie geschrieben: ein Neuaufsetzen des hmland ist nicht wirklich schwer.

Das mag sein, aber es ist ein weiterer Dienst, der aufgesetzt sein will. Wenn es also direkt im anderen IO-Modul ohne geht, wie würdest du das dann machen? (Ich würde es mir ansehen .)
Die "eigentlichen" Devices selbst sind ja weiter TYPE=CUL_HM (sonst macht das selbstredend wenig Sinn....).

[MadMax-FHEM]

Das muss der TE entscheiden wo er lieber "dreht"

An fhem indem er das neue Modul ausprobiert, ob es mit dem HM-CFG-USB "zurecht kommt"...
...oder nach Wiki den hmland "baut" und dann ein einfaches Startscript in /etc/systemd/system ablegt...
...was ebenfalls in einem Wiki beschrieben ist...

Aber egal wie, ich bin immer noch der Meinung: höchste Eisenbahn mal den "Ernstfall" (der bei einem PI mit SD schon mal kommen kann)  unter "entspannten Bedingungen" zu üben...
Und dabei gleich von vorne gut zu dokumentieren damit der echte Ernstfall dann tatsächlich "einfach" und schnell geht...

Gruß, Joachim

[mfeske]

Na ich bin jetzt weiter beim Ernstfall und dokumentieren
Also mal ein Backup der alten FHEM Installation und glücklicherweise auch in die Logs geschaut:
Auweia

Code Auswählen Erweitern

2019.02.27 19:24:22 2: Backup with command: tar -cf - "./certs" "./CHANGED" "./configDB.pm" "./contrib" "./demolog" "./docs" "./FHEM" "./fhem.cfg" "./fhem.cfg.demo" "./fhem.pl" "./log" "./MAINTAINER.txt" "./README_DEMO.txt" "./restoreDir" "./unused" "./www" |gzip > ./backup/FHEM-20190227_192422.tar.gz
tar: ./certs: Cannot open: Permission denied
tar: ./FHEM/99_perfmon.pm: Cannot open: Permission denied
tar: Exiting with failure status due to previous errors
Backup done
Da ist das Backup wohl nicht vollständig ?

Dann noch die Sache mit HM, ja

Es ist wohl ein weißer USB-Stick...
...mit grüner LED die ab und an blinkt...

Was würdet Ihr jetzt machen neu einrichten oder kopieren oder auf HMUARTLGW umstellen. Könntet Ihr mir die Vor- und Nachteile aus Eurer Sicht für mich als newbi schildern ?

Gruß
Micha

[Beta-User]

Du solltest dich mit der Rechteverwaltung unter Linux beschäftigen...

Und ja, mindestens bestimmte Dateien sind nicht im Backup gelandet (bzw. das exisitert evtl. gar nicht...). Die dann halt erst mal entweder vom backup ausnehmen oder "rechtemäßig" anpassen, allerdings dabei vorher prüfen, warum die andere Rechte haben (perfmon hast du vermutlich selbst verbogen, das ist auch nicht wichtig bzw. kommt sowieso mit einer Neuinstallation).

Was HMUARTLGW angeht: Wie geschrieben, habe ich keine Ahnung, _ob_ das überhaupt funktioniert. Wenn, halte ich das wie bereits geschrieben für die bessere Lösung (da ohne externen Dienst), allerdings taucht das in der commandref nirgends auf (woanders habe ich erst mal nicht gesucht)...
Evtl. wäre das eine Kleinigkeit, das zu integrieren (der Autor von hmland und HMUARTLGW ist derselbe...). Müßte man ggf. fragen (bitte aber erst testen!)

Zum testen (geht ja ohne weiteres mit einem Testsystem):
by-id-Adresse ermitteln (siehe Wiki: mehrere USB-Geräte), dann sollte das Teil z.B. so zu definieren sein (das ist mein Pi-PSB, angebunden an einen USB-Seriell-Wandler):

Code Auswählen Erweitern

defmod myHmUART HMUARTLGW /dev/serial/by-id/usb-Silicon_Labs_myHMUART_0001-if00-port0
Klappt das, müßten ein paar Internals zu sehen sein, und das Device auf "opened" gehen... That's all.

[Hollo]

...Deshalb plane ich den Umstieg von einem Raspberry Pi auf Raspberry Pi 3B+ und damit einen Sprung von Wheezy zu Buster. Ein Upgrade von Wheezy zu Buster gibt es wohl nicht...

Buster ist aktuell noch TESTING, daher gibt es auch kein direktes Upgrade.
Das werden die wenigsten hier einsetzen; und wenn dann eher die "Linux-Cracks", die sich selbst zu helfen wissen (Pakete selbst kompilileren, backports nutzen etc.).

An Deiner Stelle würde ich ein Upgrade NICHT in Erwägung ziehen und das System mit stretch (aktuelles stable release) und FHEM 5.9 neu aufsetzen.
Damit sparst Du Dir die Zwischenschritte wheezy -> jessie -> stretch -> buster und schleppst keine Altlasten mit.
Dann hast Du eine saubere Installation mit "bewährten" Versionen und kannst Fehler/Probleme in Deinem System suchen (und auch Hilfe dazu anfragen).
Wenn Buster im Laufe des Jahres stable wird, kannst Du im Normalfall recht unproblematisch von stretch aus ein dist-upgrade machen.

[mfeske]

Fortschritt:

Code Auswählen Erweitern

2019.02.28 09:16:21 2: Backup with command: tar -cf - "./certs" "./CHANGED" "./configDB.pm" "./contrib" "./demolog" "./docs" "./FHEM" "./fhem.cfg" "./fhem.cfg.demo" "./fhem.pl" "./log" "./MAINTAINER.txt" "./README_DEMO.txt" "./restoreDir" "./unused" "./www" |gzip > ./backup/FHEM-20190228_091621.tar.gz
Backup done

[mfeske]

An Deiner Stelle würde ich ein Upgrade NICHT in Erwägung ziehen und das System mit dem stretch (aktuelles stable release) und FHEM 5.9 neu aufsetzen.

Hallo Hollo,

ja bin jetzt auf Stretch gewechselt und werde mich an der Neuinstallation von FHEM versuchen.
Ein Backup konnte ich erfolgreich machen, jetzt muss ich halt die HMUARTLGW irgendwie angehen.

Gruß
Micha

[mfeske]

Alles auf Start und nun wollte ich loslegen. Die Anleitung https://wiki.fhem.de/wiki/Raspberry_Pi ist ja für Anfänger gedacht. Also los geht es:

Code Auswählen Erweitern


su - root
# serielle Schnittstelle aktivieren und mit BT Schnittstelle tauschen
echo "enable_uart=1" >> /boot/config.txt
echo "dtoverlay=pi3-miniuart-bt" >> /boot/config.txt
echo "core_freq=250" >> /boot/config.txt
sudo shutdown -r now
pi@raspberrypi:~ $ ls -l /dev/ttyAMA0
crw-rw---- 1 root dialout 204, 64 Feb 28 08:58 /dev/ttyAMA0
pi@raspberrypi:~ $ ls -l /dev/serial*
lrwxrwxrwx 1 root root 7 Feb 28 11:07 /dev/serial0 -> ttyAMA0
lrwxrwxrwx 1 root root 5 Feb 28 11:07 /dev/serial1 -> ttyS0
pi@raspberrypi:~ $ su - root
Passwort:
root@raspberrypi:~# wget -qO - http://debian.fhem.de/archive.key | apt-key add -
OK
root@raspberrypi:~# echo "deb http://debian.fhem.de/nightly/ /" >> /etc/apt/sources.list
root@raspberrypi:~# apt-get update
root@raspberrypi:~# apt-get install fhem
​

Meine Vermutung war jetzt, das nach einem Neustart mit FHEM unter http://192.168.115.75:8083 begrüsst. Da passiert aber leider nichts.

Code Auswählen Erweitern

pi@raspberrypi:/opt/fhem $  /etc/init.d/fhem start
-bash: /etc/init.d/fhem: Datei oder Verzeichnis nicht gefunden

deutet mir wohl auch an, das da noch was fehlt. In /etc/init.d/ gibt es auch kein fhem

[yersinia]

Meine Vermutung war jetzt, das nach einem Neustart mit FHEM unter http://192.168.115.75:8083 begrüsst. Da passiert aber leider nichts.

Code Auswählen Erweitern

pi@raspberrypi:/opt/fhem $  /etc/init.d/fhem start
-bash: /etc/init.d/fhem: Datei oder Verzeichnis nicht gefunden

deutet mir wohl auch an, das da noch was fehlt. In /etc/init.d/ gibt es auch kein fhem

Du bist auf Buster Stretch umgestiegen und damit auch auf systemd.

Versuche mal

Code Auswählen Erweitern

systemctl status fhem
und dann je nachdem

Code Auswählen Erweitern

systemctl restart fhem
systemctl stop fhem
systemctl start fhem

Manchmal kann der Start auch was dauern. Insbesondere am Anfang.

Was gibt denn

Code Auswählen Erweitern

dmesg
nach FHEM start (ggf via systemctl restart fhem) aus?

[mfeske]

Hallo yersinia,

vielen Dank. Ich werde das mal in meiner Doku ergänzen
offenbar läuft fhem

Code Auswählen Erweitern

root@raspberrypi:~# systemctl status fhem
● fhem.service - FHEM Home Automation
   Loaded: loaded (/etc/systemd/system/fhem.service; enabled; vendor preset: enabled)
   Active: active (running) since Thu 2019-02-28 11:18:14 CET; 27min ago
  Process: 384 ExecStart=/usr/bin/perl fhem.pl fhem.cfg (code=exited, status=0/SUCCESS)
Main PID: 489 (perl)
   CGroup: /system.slice/fhem.service
           └─489 /usr/bin/perl fhem.pl fhem.cfg

Feb 28 11:18:12 raspberrypi systemd[1]: Starting FHEM Home Automation...
Feb 28 11:18:14 raspberrypi systemd[1]: Started FHEM Home Automation.


aber über den Browser ist es nicht aufrufbar.

dmesg fast alles grün, bis auf

Code Auswählen Erweitern


[    4.361385] brcmfmac: brcmf_fw_map_chip_to_name: using brcm/brcmfmac43455-sdio.bin for chip 0x004345(17221) rev 0x000006
[    4.729254] brcmfmac: brcmf_c_preinit_dcmds: Firmware version = wl0: Feb 27 2018 03:15:32 version 7.45.154 (r684107 CY) FWID 01-4fbe0b04
[    4.729822] brcmfmac: brcmf_c_preinit_dcmds: CLM version = API: 12.2 Data: 9.10.105 Compiler: 1.29.4 ClmImport: 1.36.3 Creation: 2018-03-09 18:56:28


[yersinia]

Was sagt denn das Log von FHEM? Müsste irgendwo unter

Code Auswählen Erweitern

/opt/fhem/log
o.ä. liegen.
Kannst du mit cat, nano oder vi auslesen. Möglicherweise auch mit tail (gibt standardmässig letzten 10 Zeilen einer Datei aus).

[mfeske]

angeblich wäre 8083 open

Code Auswählen Erweitern


2019.02.28 11:48:57 1: Including fhem.cfg
2019.02.28 11:48:57 3: WEB: port 8083 opened
2019.02.28 11:48:57 2: eventTypes: loaded 0 events from ./log/eventTypes.txt
2019.02.28 11:48:57 1: Including ./log/fhem.save
2019.02.28 11:48:57 1: usb create starting
2019.02.28 11:48:58 3: Probing ZWDongle device /dev/serial0
2019.02.28 11:48:58 1: ZWDongle: Can't open /dev/serial0: Permission denied
2019.02.28 11:48:58 3: Probing ZWDongle device /dev/serial1
2019.02.28 11:48:58 3: Probing CUL device /dev/ttyAMA0
2019.02.28 11:48:58 1: CUL: Can't open /dev/ttyAMA0: Permission denied
2019.02.28 11:48:58 3: Probing CUL device /dev/ttyS0
2019.02.28 11:48:58 1: usb create end
2019.02.28 11:48:58 0: Featurelevel: 5.9
2019.02.28 11:48:58 0: Server started with 6 defined entities (fhem.pl:18623/2019-02-17 perl:5.024001 os:linux user:fhem pid:1528)



[Beta-User]

Bist du im selben Netzwerksegment?
(=> "allowed")

[mfeske]

Hallo @Beta-User,

ja ich sitze im gleichen Netzwerk und die IP unterscheidet sich nur in der letzten Stelle.
Ich habe die Installation einfach erneut durchgeführt (komplett) und jetzt geht es.

Aber was wäre so eine Neuinstallation ohne Probleme
Nach dem Neustart scheint FHEM jedoch auf dem Raspi BT zu killen Meine dort angeschlossene BT Maus und Tastatur funktionieren nicht mehr. Der Desktop behauptet "No Bluetooth adapter found.

Im Frontend habe ich dann noch:

Code Auswählen Erweitern


SecurityCheck:
  WEB is not password protected

Protect this FHEM installation by defining an allowed device with define allowed allowed
You can disable this message with attr global motd none


Wäre das jetzt das korrekte vorgehen:
in fhem Zeile define allowed WEB allowed
in fhem zeile define WEB FHEMWEB 8083 global
in fhem zeile attr WEB basicAuth { "$user:$password" eq "ich:geheim" }
​
Gruß
Micha

[willib]

Ich würde die lite version nehmen und per SSH arbeiten.

[mfeske]

Hallo @willib,

ich werde überwiegend per SSH zugreifen, benötige den pi aber noch zu anderen Zwecken.

Das sollte doch trotzdem gehen.

[willib]

Ja, das sollte schon gehen.
Ich nutze einen 3B und habe jetzt einen Einbruch in der Performance. Zum Beispiel wenn ich den Raum everything öffne dauert es mittlerweile doch recht lang. Ich weiß nicht woran das liegt. Ich habe aber viele Module, DOIFs und auch MQTT2 in Benutzung. Ich verfolge diesen Thread weil ich auch auf den 3B+ wechseln will und mein System dabei vollständig neu machen will. Bis auf die config natürlich.

Mit der Zeit werden die Aufgaben die FHEM übernimmt sicherlich immer mehr. Daher würde ich immer nur FHEM auf dem Pi laufen lassen und keine anderen Tasks.
Vieleicht is das auch Quatsch. Aber ein zweiter Pi kostet nicht viel. Ich bin mir auch nicht sicher ob das plus an Prozessorleistung beim 3B+ überhaubt relevant für die Nutzung von FHEM ist und nicht eher mehr RAM gebraucht wird. Da scheiden sich vermutlich die Geister.

[Beta-User]

Bitte nicht noch eine pro/contra Pi Diskussion... Und ich würde auch immer versuchen, die Zahl der zu pflegenden Geräte auf einem für mich überschaubaren Niveau zu halten, weniger ist also mehr.

Aber: der FHEM-Server sollte tatsächlich NIE einen Desktop haben, das ist sch.*e! Und wenn du noch 100 youtubes dazu siehst, die was anderes behaupten .

Dass BT bei den Dingern auch ein Problem darstellen kann, ist dem Wiki zu entnehmen. Die Konfiguration würde ich daher tatsächlich erst mal via ssh und ohne WLAN machen, dabei ist es vermutlich am einfachsten, die Schnittstellen passend zu konfigurieren.

Und das schient mir nicht ganz der korrekte code zu allowed zu sein (die Namenswahl ist aber auch irritierend), schau dazu in der commandref nach (oder im Wiki, da müßte vielleicht im QuickStart was zu finden sein).

[mfeske]

Um rauszubekommen ob meine Vermutung stimmt muss ich erstmal finden, wie ich den automatischen start von fhem verhindere. Ich vermute tatsächlich darin die Ursache. Vielleicht kann einer der Profis mir zur Seite springen. Es handelt sich um einen 3B+ mit integrierten BT. Keine weiteren USB Geräte angeschlossen, wie in der Anleitung beschrieben.

Gruß
Micha

[Beta-User]

Bitte nicht nur alles einfach fragen, sondern versuchen, das bisher gesagte auch zu verstehen.

Du hattest ein Problem, weil init.d nicht vorhanden war, oder? Es wurde ersetzt durch? OK, wenn du das gefunden hast: passenden Systembefehl finden und mit der Option disable aufrufen...

[mfeske]

Hallo Beta-User,
danke. Ja, ich hatte ein Problem weil init.d nicht vorhanden ist. Es wurde ersetzt durch systemctl. Damit FHEM nicht beim start ausgeführt wird habe ich

Code Auswählen Erweitern

systemctl disable fhem verwendet und den pi neu gestartet. Es funktioniert dann wieder alles was mit BT zu tun hat Tatstatur und Maus. Das (für mich) erstaunliche ist es funktioniert auch wenn ich FHEM manuell mit

Code Auswählen Erweitern

systemctl start fhem starte und mir den Status durch

Code Auswählen Erweitern

systemctl status fhem und Aufruf im Web bestätigen lasse.

Ist FHEM einfach zu schnell beim start und dadurch geht die BT Konfiguration kaputt ? Eine Möglichkeit wäre natürlich FHEM vom Autostart auszuschließen und immer nach einem pi Neustart manuell zu starten, schön ist das aber nicht.

Gruß
Micha

[Beta-User]

 
Schön, dass du den richtigen Ansatz gefunden hast.

systemd bietet auch Optionen an, die Reihenfolge zu bestimmen (praktische Erfahrung mußte ich damit bisher nicht sammeln, kann daher nur das Stichwort liefern).
ABER: Wenn es BT-spezifisch ist, wäre die erste Frage, ob du die Anleitung im Wiki zu BT-fähigen Pis beachtet hast?

[mfeske]

Ich wollte es ja "sicher" machen und dokumentieren für das nächste mal und bin von daher der Anleitung gefolgt https://wiki.fhem.de/wiki/Raspberry_Pi Aber der Hinweis "Anleitung im Wiki zu BT-fähigen Pis" hat mich nun auch hierher https://wiki.fhem.de/wiki/Raspberry_Pi_3:_GPIO-Port_Module_und_Bluetooth gebracht. Mein erster Treffer bei meiner Suche war aber der erste Link. Vielleicht könntet Ihr da noch einen Hinweis auf den zweiten bringen ?

Ich werde dann mal mit meiner Installation von vorne beginnen
Bisher bin ich davon ausgegangen, das

Code Auswählen Erweitern


# serielle Schnittstelle aktivieren und mit BT Schnittstelle tauschen
echo "enable_uart=1" >> /boot/config.txt
echo "dtoverlay=pi3-miniuart-bt" >> /boot/config.txt
echo "core_freq=250" >> /boot/config.txt

die Schlüsselstelle war.
Schritt 7 ist vermutlich der der mich retten könnte, obwohl er eigentlich nicht mehr notwendig sein soll. Allerdings init.d

Gruß
Micha

BTW Gibt es eine Möglichkeit am WIKI sinnvoll mitzuarbeiten, nein ich möchte da jetzt nichts direkt schreiben / löschen, aber vielleicht helfen ja die Versuche eine newbi die Anleitungen evt. anzupassen.

[Wernieman]

Dazu müsste man "nur" rausfinden, welche Kombi genau BT und FHEM durcheinanderbringen.

Btw: Hast Du in FHEM die USB-Überprüfung noch aktiviert? Das würde ich lieber rausnehmen ...

[Beta-User]

Das ist seltsam, und es würde mich insgesamt auch interessieren, ob das an der GUI-Geschichte liegt - die Anleitung im Wiki ist _ohne_ GUI...

Und eine veraltete Anleitung für init.d wird vermutlich keiner mehr gerne anfassen.

Kannst du bitte vor einer Neuinstallation den von Wernieman vorgeschlagenen Fix mal testweise durchführen?

(Anmerkung: Mein letzter Pi war ein Pi 2, und "sowas" kommt mir auch nur für Tests usw. ins Haus, und wenn, dann ohne GUI; ich werde mich definitiv nicht weiter mit der Materie beschäftigen, um Anleitungen zu aktualisieren . Geht ggf. nur darum, bei akuten Problemen einen Tip geben zu können).

[Wernieman]

Ich würde IMMER Gui und Server Trennen. Lieber nehme ich einen 2.Pi im Kios-Modus für einen Bildschirm, als das ich einen Server mit einer GUI ausstatte. Auch wenn es "mehr" Hardware und damit "mehr" Pflege bedeuten könnte, macht es die "Pflege" insgesamt einfacher und Fehlerfreier. Also in "Summe" spare ich  mir damit meine Freizeit ..... wenn ich privat eine Dauerausgabe für FHEM brauchen würde ...

Aber das ist nur meine persönliche (private und berufliche) Meinung ....

[mfeske]

Hallo @Beta-User und @Wernieman,

ich habe meine persönliche Doku ergänzt um:

Code Auswählen Erweitern


sudo apt-get install rpi-update
sudo rpi-update
sudo reboot


und fhem Befehlszeile

Code Auswählen Erweitern

attr initialUsbCheck disable 1

nach einem

Code Auswählen Erweitern

systemctl enable fhem und 20 Neustarts sind momentan keine Probleme erkennbar. Es kann also weitergehen  Danke Euch wie immer für die schnelle und erfolgreiche Hilfe.

@Wernieman wie läuft das mit dem Kiosk Modus ? Heisst ich könnte mir einen PI mit echtem Monitor hinlegen und auf alle anderen zugreifen als ob ich davor sitze ? Voraussetzung vermutlich das Netzwerk ist nicht defekt.
@Beta-User Ich würde ja auch gerne mal was von meinen Anfängererfahrungen zurückgeben und einen entsprechenden wiki Artikel verfassen, oder ist das nicht sinnvoll ? Reicht vermutlich als txt und Du könntest es einstellen ?

Gruß
Micha

[Wernieman]

KIOS-Modus ist eine Browsereinstellung. D.h. der PI bootet in den Browser, der gleich die FHEM-Webside darstellt.Mit passenden BrowserModul sogar mit autologin bei Passwortabfrage. Bekanntlich ist FHEM per Browser administrierbar .. also ja, es ist fast wie "davorsitzen".

Der Vorteil: Der PI im Kios-Modus kann irgendwo in der Wohnung/Haus stehen, der FHEM-Rechner dort wo es technisch sinnvoll ist.

(Wobei ich meinen Normalen Rechner zur Administration benutzen würde)

[Beta-User]

Erst mal Danke für's Testen.

Ich hatte mich schon immer gewundert, warum manche Pi-User mit dem initialUsbCheck Probleme haben und scheinbar viele andere nicht. Jetzt haben wir eine mögliche Ursache: Verwendung von USB-Eingabegeräten... (besonders gefährdet: GUI-Nutzer!)

@Beta-User Ich würde ja auch gerne mal was von meinen Anfängererfahrungen zurückgeben und einen entsprechenden wiki Artikel verfassen, oder ist das nicht sinnvoll ? Reicht vermutlich als txt und Du könntest es einstellen ?

"Meistens" schreibe ich nur ins Wiki, was ich glaube, selbst richtig und in der erforderlichen Tiefe verstanden zu haben. Daher werde ich fremde Texte nur dann einstellen, wenn ich sie nachvollziehen kann. Beim Pi ist das weitestgehend nicht (mehr) der Fall.

Hier ist es aber nochmal anders: Es steht bei dem "normalen" Pi-Artikel schon dabei, dass man ein update des Betriebssystems machen soll (was eigentlich an sich schon so eine Selbstverständlichkeit ist, aber was soll's). Detaillierter sollte man da nach meiner persönlichen Überzeugung gar nicht werden, da die Frage, wie das geht, zum einen keine FHEM-Frage ist und zum anderen immer mal wieder Änderungen unterliegen kann. Sowas ist dann an anderer Stelle besser aufgehoben.
(Auch deine persönliche Aufzeichnung sollte besser kein ausformuliertes "Script" sein, an das du dich sklavisch hältst, sondern eben "nur" eine Stichwort-Liste, damit du drandenkst, was da alles so war... Jeweils die aktuelle Fassung zu suchen, solltest du dringlich üben).

Nur meine 2ct .