FHEM von Debian lite Jessie auf DietPi Stretch umziehen (problemlos) möglich?

Begonnen von r00t2, 11 Januar 2019, 14:52:18

Vorheriges Thema - Nächstes Thema

r00t2

Ja, normalerweise kenne ich es auch so, dass die Imports ganz am Anfang stehen.
Wie gesagt: Ich hatte mir damals im Tagebuch nicht notiert, warum ich es so gelöst hatte (und warum es auch so funktioniert hat). Hauptsache es funktioniert jetzt wieder  :D

Mittlerweile läuft alles recht stabil. Auch externe Funktionen (wie z. B. Mails versenden) funktionieren. Und so wie es aussieht ist die CPU Last des Systems um einiges geringer geworden (obwohl ja zusätzlich noch Node-RED lokal läuft). Zumindest bleibt die CPU viel öfter bei 600MHz und geht nur selten auf 900MHz hoch bzw. der 15min Load Avg steht fast durchgängig unter 0.2.

Mal sehen, wie es mit der Speichernutzung aussieht. Ich hatte beim alten System wohl ein Leck, was dazu geführt hat, dass die RAM Nutzung innerhalb von 90 Tagen um ca. 20% gestiegen ist. Ein "shutdown restart" hat das zwar immer wieder normalisiert aber ganz sauber war das auch nicht.

Danke nochmal an alle (vor allem Otto) für die "Umzugshilfe" :)
FHEM 6.0 (Raspberry Pi 2 B | Raspberry Pi OS Lite | Perl 5.28.1 | UZB Z-WAVE.Me | Hue Bridge V1 | SIGNALDuino 433 MHz | FritzBox | Kodi | Pioneer AVR | MQTT | Node-RED | Diverse Google Dienste)

UweUwe

Hallo Otto,
Ich habe von Joachim (FHEM-Alexa) erfahren,  , dass du ein Unterstützungs-Skript hast, um von einem älteren Linux auf das aktuelle Debian die für  FHEM notwendigen Pakete zu ermitteln und auch umzuziehen.
Alexa-FHEM ist auch dabei.
Ich habe erfolglos gesucht. Neu installiert habe ich Raspbian GNU/Linux 11 (bullseye)

MadMax-FHEM

Hi,

bin zwar nicht Otto aber ich probiere mal:

https://heinz-otto.blogspot.com/2021/12/fhem-auf-neues-system-umziehen.html

EDIT: hier "FHEM entsprechend https://debian.fhem.de/ installieren" würde ich anmerken -> the easy way...

Und FHEM-Alexa -> MadMax-FHEM ;)

Evtl. hat Otto auch noch weitere Hinweise...
...obwohl der Thread ja schon ein paar (mehr) Tage alt ist.

Gruß, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

Otto123

Hi,

gibt noch etwas neueres
https://heinz-otto.blogspot.com/2022/08/howto-fhem-umzug-von-system-nach-system.html

Wobei ich von Alexa wenig Ahnung habe, der Artikel berücksichtigt FHEM und keine anderen System Dienste. :)

Gruß Otto
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

MadMax-FHEM

Zitat von: Otto123 am 02 November 2022, 22:13:31
Wobei ich von Alexa wenig Ahnung habe, der Artikel berücksichtigt FHEM und keine anderen System Dienste. :)

Das reicht... ;)
...alexa-fhem ist ganz einfach... 8)

Die Geräte-Konfiguration, also welches Device generell und als was/wie ist in fhem (fhem.cfg) verankert...
...alexa-fhem ist ein Befehl auf der Linux-Shell...
(wenn nodejs bereits vorhanden)
...die Verbindung zum Vereinsserver bzw. der Link zwischen fhem - Vereinsserver - Skill steckt in den Schlüsseln /opt/fhem/.ssh
Diese mit umziehen oder eben Skill neu verbinden...

EDIT: Zugriff von alexa-fhem auf fhem, wenn abgesichert ist entweder in der alexa-cfg hinterlegt oder/und (somit) im fhem Backup enthalten...

Also alles ganz harmlos...
Ich bin mit alexa-fhem schon einige Male umgezogen... :)

Gruß, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

UweUwe

Hier Kommentare aus dem Script von Otto:


Zitat
Zitat#!/bin/bash
# Dieses Script installiert FHEM falls es noch nicht vorhanden ist!
# Im FHEM wird ein Installer Device im Developer Modus definiert
# mit Hilfe meines bash FHEM Client wird eine Abfrage der "alten" fhem.cfg durchgeführt und alle benötigten Module ausgegeben
# ein copy & paste für dann zur Installation der fehlenden Perl Module
# am Einfachsten liegt die alte fhem.cfg vor Start des Script im aktuellen Verzeichnis

# run this Script as root https://www.linuxjournal.com/content/automatically-re-start-script-root-0

Ich möchte versuchen die auf Ottos Seite 
https://heinz-otto.blogspot.com/2021/12/fhem-auf-neues-system-umziehen.html vorgeschlagenen Skript zu verwenden.
Sowohl der Produktions RPI, als auch der für den Update vorbereitete RPI befinden sich bei mir im gleichen Netzwerk.
Der neue RPI hat bereits die aktuelle  Debian Installation.
PRETTY_NAME="Raspbian GNU/Linux 11 (bullseye)"
NAME="Raspbian GNU/Linux"
VERSION_ID="11"
VERSION="11 (bullseye)"
VERSION_CODENAME=bullseye
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"



Jetzt wollte ich verstehen, wie ich das Skript vorbereiten  / organisieren muss
Dieses Script installiert FHEM falls es noch nicht vorhanden ist!  ==> Bei  mir heisst das, FHEM wird installiert.
Im FHEM wird ein Installer Device im Developer Modus definiert  ==> verstehe ich nicht, muss ich aber wohl auch nicht verstehen
mit Hilfe meines bash FHEM Client wird eine Abfrage der "alten" fhem.cfg durchgeführt und alle benötigten Module ausgegeben  ==> reicht es, wenn sich das Produktions-FHEM im selben Netzwerk befindet wie das neue FHEM, wohl aber auf einer anderen RPI Hardware (beides mal RPI3)?

ein copy & paste für dann zur Installation der fehlenden Perl Module==> wohin die liste der zu installierenden Systeme kommt, werde ich noch lernen.

# am Einfachsten liegt die alte fhem.cfg vor Start des Script im aktuellen Verzeichnis ==> bedeutet dies, dass ich die fhem.cfg von der alten Hardware auf die neue Hardware vor Ausführung des Scipts kopieren muss. Die entsprechende Directory gibt es ja noch nicht.

# run this Script as root https://www.linuxjournal.com/content/automatically-re-start-script-root-0  ==> bedeutet: auf der neuen Hardware in der root directory wird mit dem Befehl sudo " https://www.linuxjournal.com/content/automatically-re-start-script-root-0[/quote][/quote]" das Script gestartet und macht dann hoffentlich seine Dienste.

Sorry für die vielen Fragen.



Otto123

Nimm bitte den Artikel https://heinz-otto.blogspot.com/2022/08/howto-fhem-umzug-von-system-nach-system.html
Dort wird eigentlich alles Schritt für Schritt erklärt.
Das Installer Modul ist ein FHEM define ...
Die zu prüfende fhem.cfg liegt einfach im Arbeitspfad auf der "neuen" Maschine. Es erfolgt keine Abfrage auf der "alten" Maschine. Es braucht also keine Netzwerkverbindung.

Am Ende des Script wird die Liste der zu installierenden Module ausgegeben.

Der letzte Kommentar ist nur ein Hinweis auf die Quelle, es muss beim Aufruf nichts beachtet werden. Wie gesagt, im hier verlinktem HowTo steht alles Schritt für Schritt.

Viel Erfolg
Otto
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

UweUwe


UweUwe

Hallo Otto,
ich habe heute begonnen, deine Seite abzuarbeiten.
Ich finde es ebenfalls sehr spannend, dass man jetzt Putty nicht nachinstallieren muss.
Zumindest den ersten Teil der Seite

https://heinz-otto.blogspot.com/2018/06/windows-hat-jetzt-ssh.html?sc=1667504782614#c6704896280525911792

konnte ich gut lesen und verstehen und hilft auch, für die weitere Bearbeitung des

https://heinz-otto.blogspot.com/2022/08/howto-fhem-umzug-von-system-nach-system.html.

Hier ergeben sich für mich noch Fragen.  Die von dir mühevoll vorbereiteten Befehle muss man bei offenen SSH dem "alten" System (hardware mit ProduktionsFHEM) mitteilen. Korrekt?

ZitatREM ein paar Variablen setzen
set "alt=pi@raspib3"        # username und host vom alten System
set "neu=otto@vmdebianfhem" # username und host vom neuen System
set "pfad=/opt/fhem"        # der Pfad in dem FHEM installiert ist
REM aktuellstes Backup ermitteln
for /f %i in ('ssh %alt% -t "ls -rt1 %pfad%/backup | tail -1"') do set datei=%i
REM alternativ eine Variante mit Umweg über eine Datei
REM ssh %alt% -t "ls -rt1 %pfad%/backup | tail -1" > datei.txt
REM set /p datei= < datei.txt
REM die Dateien vom alten System holen
scp %alt%:%pfad%/\{backup/%datei%,fhem.cfg\} .
REM eventuell die Hardware umbauen
REM die Dateien aufs neue System schaffen
scp %datei% fhem.cfg %neu%:
REM Ab jetzt interaktiv auf dem neuen System - anmelden
ssh %neu%

Das war auch meine Vorgehensweise .  bis zu dem Befehl:

ZitatREM aktuellstes Backup ermitteln
for /f %i in ('ssh %alt% -t "ls -rt1 %pfad%/backup | tail -1"') do set datei=%i

Hier bekomme ich die Fehlermeldung:

-bash: Syntaxfehler beim unerwarteten Wort `%i'


Leider funktioniert auch die Alternative nicht .

ssh %alt% -t "ls -rt1 %pfad%/backup | tail -1" > datei.txt
ssh %alt% -t "ls -rt1 %pfad%/backup | tail -1" > datei.txt
ssh: Could not resolve hostname %alt%: Name or service not known


Was mache ich falsch?








Otto123

Zitat von: UweUwe am 03 November 2022, 21:56:53
Hier ergeben sich für mich noch Fragen.  Die von dir mühevoll vorbereiteten Befehle muss man bei offenen SSH dem "alten" System (hardware mit ProduktionsFHEM) mitteilen. Korrekt?
Leider völlig falsch!
Über dem von Dir zitierten Befehlsblock steht doch
ZitatArbeiten unter Windows in der CMD Shell - Windows Taste + cmd + enter
sämtliche Befehle sind Windows CMD Befehle, keine bash Befehle!
Aber Du darfst es nicht einfach nur kopieren! Die ersten Zeilen musst Du an Deine Umgebung anpassen!
Du kannst diese Anpassung direkt in meinen Codeboxen machen und dann kopieren. Du brauchst keinen extra Editor.

Gruß Otto
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

UweUwe

Hallo Otto123,
Danke für deine Antwort. Ich verstehe es noch nicht.
Die Anpassung an meine Umgebung für die ersten Befehle hab ich schon gemacht.
Ich vermute mal, richtig.
Jetzt habe ich in dem Netzwerk den ,,ProduktionsRPI" , das neue System und meinen Windows-Rechner.

Mit deinem Script  holst du dir Daten und Informationen von dem ProduktionsRPI und kopierst diese auf das zukünftige System. Der Windows-PC dient als Terminal. Das Prinzip ist doch so korrekt. ?

Dazu braucht der Windows PC aber Zugang zu den beiden RPIs und dazu zum Beispiel auch die Passwörter.
Die vermisse ich Wie kommt der Windows PC auf die RPIs ohne die Passwörter und kann sich die Daten holen?

Vorgehensweise teste ich heute Abend aus:
CMD Shell öffnen mit Windows Taste + cmd + enter
Dann jeden der von dir beschriebenen Befehle ( zum Teil angepasst) eingeben.
Dazu ist keine Anmeldung an einem RPI notwendig.








Otto123

Moin,

ZitatMit deinem Script  holst du dir Daten und Informationen von dem ProduktionsRPI und kopierst diese auf das zukünftige System. Der Windows-PC dient als Terminal. Das Prinzip ist doch so korrekt. ?

Dazu braucht der Windows PC aber Zugang zu den beiden RPIs und dazu zum Beispiel auch die Passwörter.
Die vermisse ich Wie kommt der Windows PC auf die RPIs ohne die Passwörter und kann sich die Daten holen?
Ja das Prinzip ist so korrekt. Aber es sind einzelne Befehlszeilen! Kein Script im Block!

Die Befehlszeilen oben beinhalten 2 x ssh und 2 x scp Befehle - diese machen die Anmeldung am pi, die Passwörter werden abgefragt Probiere es doch einfach interaktiv aus:
ssh user@host
Da bekommst Du, je nach dem wie dein System eingerichtet / bisher verwendet wurde / eine oder mehrere Fragen:
Vertraust Du diesem PC, host key in der know_host Datei ablegen?
passwort?
Dann bist Du in der shell auf dem Remote PC
mit exit bist Du zurück im Windows Fenster.

Die Befehlszeilen oben verwenden diese Befehle im "Scriptmodus", d.h. sie führen etwas aus und kehren zur Windows Shell zurück. Bei der letzten Zeile wird die interaktive Shell zum neuen System geöffnet.

Verwendet man das ganze öfters und sitzt man an seinem privatem Rechner, kann man sich diese Abfragen sparen in dem man alles mit public key Anmeldung einrichtet. Darüber wie man dies in welcher Situation exakt macht habe ich auch schon öfters was geschrieben.

Gruß Otto
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

UweUwe

Hallo Otto,
ich hänge noch an grundlegenden Dingen, leider.

Die von dir häufig angegebene Tastenkombination:
ZitatArbeiten unter Windows in der CMD Shell - Windows Taste + cmd + enter

öffnet bei mir die Sprachausgabe von Windows und nicht die CMD Shell.
Ich habe Windows 10 Pro installiert.

Die CMD Shell öffnet sich bei mir mit Windows Taste + r .

In dieser CMD shell (geöffnet mit Windows + r Taste) habe ich jetzt den ersten Befehl eingegeben:

ssh set "alt=pi@vagabundi"

==> es öffnet sich ein weiteres Fenster,  ../ssh.exe, das aber schwarz bleibt und sich nach wenigen Sekunden automatisch ohne Meldung schliesst.

Desselbe mache ich mit dem nächsten Befehl:
ssh set "neu=pi@vagabundi02"

und weiter mit dem nächsten Befehl:
scp set"pfad=/opt/fhem"# der Pfad in dem FHEM installiert ist

und weiter mit dem nächsten Befehl:

scp for/f %i in('ssh %alt% -t "ls -rt1 %pfad%/backup | tail -1"')dosetdatei=%i


Von dir hab ich jetzt vernommen , dass es es sich um 2 SSH und 2 SCP Befehle handelt und ich habe deshalb vor die Befehle geraten und ssh und scp ergänzt. Woher muss ich das wissen oder kann ich das wissen oder ist dies ein Trugschluss von mir?

Bei den restlichen Befehlen ist ja bereits ssh bzw. scp von dir ergänzt. Diese weiteren Befehle  übernehme ich direkt und setzt jeweils einzeln in der mit Windows + r geöffneten CMD shell ab.
Es öffnet sich jeweils nur ganz kurz >> 1 sec ein weiteres Fenster.  Das Fenster bleibt auch beim letzten Befehl:

ssh %neu%

nicht geöffnet, so wie ich es erwartet hätte. Ich glaube , dass ich da irgendwo auf dem Irrweg bin. Korrekt?
Aber wo?









MadMax-FHEM

Zitat
Woher muss ich das wissen oder kann ich das wissen oder ist dies ein Trugschluss von mir?

Trugschluss!

Warum gibst du nicht einfach ein was da steht?
Nat. angepasst (Name, Rechner, Passwort, ...) an deine Umgebung.

Die genannten Befehle setzen (System) Variablen, damit du das nicht immer wieder eingeben musst...

EDIT: das sind dann eben %neu% %alt% %pfad% usw. du kannst das stattdessen auch direkt eingeben statt vorher per set vorzubelegen... ( set "Variablenname=Wert" )

Gruß, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

UweUwe

Hallo MadMax,

ZitatWarum gibst du nicht einfach ein was da steht?

weil es da einen Fehlermeldung gibt.
set "alt=pi@vagabundi"

"set" konnte nicht gefunden werden. Stellen Sie sicher, dass Sie den Namen richtig eingegeben haben und wiederholen den Vorgang.

wie von Otto123 g´hab ich die Prüfung gemacht und
ssh user@host in meinem Falle

ssh pi@vagabundi eingegeben und dann werde ich nach dem Passwort gefragt und ich kann mich anmelden.
An inkorrekten user/host Namen kann es damit nicht liegen...