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.