Neues Linux System - Nacharbeit

Generell ist es relativ einfach eine bestehende FHEM Installation auf ein neues Betriebssystem/System zu setzen:

1. Backup FHEM
2. Kopie der aktuellen Backupdatei -> Server | USB Stick | per scp lokal
3. sudo halt
4. neue SD Card mit aktuellem Image (ich behalte immer die alte SD erstmal in Reserve)
5. setupBasic, setupFhem, testen
6. Backupdatei verfügbar machen -> Server | USB Stick mounten | per scp - lokal -> nach /home/pi
7. stop fhem
8. restore des Backups
9. start fhem

Sicherung / Backup

Bei mir ist beim obigen Plan mindestens die Anbindung an Dateiserver und die ssh Verbindung auf der Strecke geblieben. Schritt 1 und 8 muss man dafür noch etwas ausbauen.

Sicherung ssh Umgebung

Die notwendigen Dateien befinden sich in diesen Verzeichnissen:

• /etc/ssh für den ssh Host / Server
• /opt/fhem/.ssh für den User fhem
• /home/pi/.ssh für den User pi. 

Ich werde zwei zusätzliche Dateien in den Backup Ordner von FHEM erstellen. Dies könnte man auch von FHEM von Zeit zu Zeit machen lassen. Neben der Datei für eine Historie mit Zeitstempel erzeuge ich noch eine ohne Zeitstempel. Damit muss man bei der Wiederherstellung nicht lang suchen.
Man kann dieses als Script auch unter FHEM ausführen, da aber Systemdateien gesichert werden, muss tar als sudo ausgeführt werden. Damit das funktioniert, muss die zuständige Datei um /bin/tar ergänzt werden.

datei=/opt/fhem/backup/ssh$(date +%Y%m%d_%H%M%S).tar.gz
sudo tar -czf $datei /etc/ssh /opt/fhem/.ssh /home/pi/.ssh
sudo cp $datei /opt/fhem/backup/ssh.tar.gz

Falls der User fhem gar kein ssh verwendet kommt ein Fehler, dann muss man die Befehle abwandeln. Da die Dateien nicht voluminös sind, kann man auf zip verzichten. Damit kann das tar Archiv leichter mit der Option -rf ergänzt werden.

sudo tar -cf $datei /etc/ssh /home/pi/.ssh
cp $datei /opt/fhem/backup/ssh.tar

Der folgende Zweizeiler wirft zwar Fehler, sichert aber die ssh Dateien für alle existierenden User.

datei=ssh$(date +%Y%m%d_%H%M%S).tar
sudo tar rf $datei /etc/ssh $(awk -F: '$3>998{print $6"/.ssh"}' /etc/passwd)

Will man einfach in FHEM die ssh Key für user fhem sichern kann man das auch dort machen: 

"datei=./backup/sshFhem$(date +%Y%m%d_%H%M%S).tar;; tar -cf $datei ./.ssh"

Und auch später wiederherstellen:

"datei=./backup/sshFhem*.tar;; tar -xf $datei ./.ssh"

Sicherung Dateiserver Umgebung

datei=/opt/fhem/backup/fsconf$(date +%Y%m%d_%H%M%S).tar.gz
sudo tar -czf $datei /etc/fstab /usr/.*credentials /etc/davfs2/secrets
cp $datei /opt/fhem/backup/fsconf.tar.gz

Hat man Scripte o.ä. zusätzlich in anderen Pfaden, kann man die natürlich einfach in dem tar Befehl ergänzen und gleich mit sichern oder eine weitere Datei nach gleichem Schema erzeugen.

Finale Sicherung des alten Systems

Damit man den finalen Status im FHEM System behält, muss man FHEM beenden und dann ein backup durchführen!

systemctl stop fhem
datei=/opt/fhem/backup/FHEM-$(date +%Y%m%d_%H%M%S).tar.gz
tar -czf $datei -C /opt/fhem --exclude ./backup ./

Wenn das Backup zu Ende ist, startet man beispielsweise das Script /opt/fhem/backupFhem.sh und kopiert alle aktuellen Dateien damit auf den Sicherungsserver.
Am Ende des Artikels habe ich noch den Hinweis auf Alternativen zum Server.

Wiederherstellung

Nachdem das neue System grundlegend installiert und getestet ist (Ergänzung Schritt 5. optional: setupDavfs) wird die Sicherung zurückgespielt.
Die Verbindung zu meinem Windows Server geht relativ simpel. Ohne Angabe des Usernamens wird der momentane User (root) verwendet. Ohne Angabe des Passwortes wird es abgefragt:

sudo su
mount -t cifs //ServerName/Freigabe /mnt
mount -t cifs -o username=UserName //ServerName/Freigabe /mnt
mount -t cifs -o username=UserName,password=Passwort //ServerName/Freigabe /mnt

Ist das Laufwerk verbunden, kann auch ohne lokale Kopie sofort mit der Wiederherstellung begonnen werden.

datei=/mnt/fhem/$(hostname)/backup/FHEM-$(date +%Y%m%d_%H%M%S).tar.gz
tar -xzf $datei -C /opt/fhem

Querverweis: Falls die Module im alten System nicht gut dokumentiert waren, hilft eventuell dieser Beitrag.

Wiederherstellung ssh

Bei meinen Systemen wurde immer nur der ecsda Key verwendet. Ich möchte nicht die neue ssh Server Gesamtkonfiguration zerstören (da ändert sich immer mal was, ich habe nicht untersucht was genau) sondern nur das wiederherstellen was gebraucht wird. Unter der Annahme: es gibt nur eine aktuelle Datei im Verzeichnis, wird damit der ecdsa Key in /etc/ssh wieder hergestellt:

datei=/mnt/fhem/$(hostname)/backup/ssh.tar.gz
tar -xzf $datei -C / --wildcards etc/ssh/ssh_host_ecdsa_*

Um die User .ssh Verzeichnisse wieder herzustellen, sollte dieser Befehl gut sein

tar -xzf $datei -C / home/pi/.ssh/ opt/fhem/.ssh/

Damit steht die ssh Umgebung wieder.

Wiederherstellung Verbindungen zum Dateiserver

Die für die Verbindung verantwortlichen Scripte sollten im /opt/fhem Verzeichnis liegen und sind damit schon Teile der Wiederherstellung. Die Datei /etc/fstab und die jeweiligen Credential Dateien liegen aber unter Umständen "verstreut" im System und sind jetzt entweder nicht vorhanden oder neu gemacht.
Zunächst die credential Datei(en) in /usr/

datei=/mnt/fhem/$(hostname)/backup/fsconf.tar.gz
tar -xzf $datei -C / --wildcards usr/.*credentials

Die davfs2/secrets will ich nur ergänzen, davfs muss schon installiert sein!

tar -xzf $datei etc/davfs2/secrets -O|grep magentacloud >> /etc/davfs2/secrets

Ich möchte gern die fstab nicht überbügeln sondern die neue Datei einfach um meine Einträge ergänzen. Existieren z.B. mehrere Mountpoints in /media/ - kann das in einer Zeile erledigt werden:

tar -xzf $datei etc/fstab -O|grep /media/ >> /etc/fstab

Jetzt müssen noch die Mountpoint erzeugt werden:

mkdir $(tar -xzf $datei etc/fstab -O|grep -o '/media/[a-Z,0-9]*'|tr '\n' ' ')

Jetzt kann man das Sicherungslaufwerk wieder trennen.

umount /mnt

Die Verbindung zu davfs2 erfordert auch noch die Gruppenmitgliedschaft in der Gruppe davfs2

usermod -aG davfs2 fhem

Die Gruppenmitgliedschaft greift erst nach erneutem Login! Also mindestens FHEM neu starten!

Alternativen zum Sicherungsserver

USB Stick
Man könnte einen USB Stick verwenden, der Raspberry Pi 3 verkraftet das Stecken im laufenden Betrieb. Bei allen anderen Typen und "zur Vorsicht" ist aber vom Stecken eines USB Sticks im laufenden Betrieb abzuraten. Zuerst schauen welches Device der Stick geworden ist und dann einfach temporär mounten:

lsblk
mount /dev/sda1 /mnt

SCP - lokale Kopie
Mit scp ist es recht simpel sich eine Kopie der Dateien lokal zum holen und diese später zurück zu spielen. Geht auch unter Windows 10 ab 1809 einfach so!

scp pi@hostname:dateiname .
scp dateiname pi@hostname:

Die Restore Befehle muss man natürlich etwas abwandeln, entweder die Variable $datei wird einfach auf die lokale Datei Homedir von pi gesetzt, oder im tar Befehl die Datei direkt angeben.

Installation nodejs, pm2 und pip

Die Installation von nodejs hatte ich ja hier schon erläutert.
Zusätzlich brauche ich "global" noch den Nodejs Prozessmanager pm2.

sudo su
curl -sL https://deb.nodesource.com/setup_10.x | bash -
apt-get install nodejs
npm install pm2 -g

Trotz der Sicherung des gesamten Ordners installiere ich Landroid neu. Wie so oft gibt es mittlerweile neue Versionen.

Python Pakete werden mit Hilfe von pip installiert. Beispiel: die fhem API

apt-get install python-pip
pip install fhem

ToDo
Andere Applikationen unterhalb von /opt sichern

codebox

Backup und Restore von FHEM

Backup ist immer eine gute Idee und sollte regelmäßig erfolgen. Noch viel wichtiger ist, dass man das Backup auch durch einen Restore verifiziert hat!
Viele machen Backup - aber kontrollieren?
Oder wie geht Restore?
Nachtrag 2021: Der Artikel gilt für eine externes Backup/Restore nach wie vor. Auch wenn man mit Windows 10 kein WinScp mehr benötigt, da ssh/scp direkt im System verfügbar ist.

Hinweis auf den restore Befehl: Im Wiki gibt es Beiträge wie der FHEM eigene restore Befehl verwendet werden kann. Link1  Link2

HowTo - FHEM Umzug von System A nach System B

Scenario: Umzug auf neues System

• System Alt: altes Linux, alte Hardware ...
• System Neu: neues Linux, neue/andere Hardware Plattform ...

Zwei verschiedenen Hardware Systeme sind etwas einfacher zu handhaben, es geht aber auch auf der gleichen Hardware (z.B. Raspberry Pi mit SD Card Wechsel oder USB-Bootstick). Ich habe alle Schritte mit einem Raspberry Pi(Raspberry OS Lite) und einer Virtuellen Maschine(debian 11 netinst) getestet. Dieses HowTo ist auch eine Ergänzung zu meinem vorjährigen Artikel.

Mit dem Raspberry Pi Imager kann man eine neue SD Card effektiv vorbereiten und das System grundlegen konfigurieren (Zahnradsymbol am rechten unteren Rand nachdem man das OS ausgewählt hat) 

Es gab von mir schon ein paar ähnliche Artikel, dieser hier soll ganz gezielt Schritt für Schritt zeigen was zu tun ist. Windows 10 hat ssh und scp eingebaut, andere Tools braucht man nicht. Wer nicht mit Windows CMD arbeiten will findet die Codezeilen für Schritt 1 am Ende auch für Linux und Powershell.

Man kann alle Schritte beliebig oft wiederholen / durchspielen und dabei lernen.

Achtung (03.2024): Das FHEM Installermodul wird leider nicht mehr gepflegt, es häufen sich die Meldungen, das mein hier gezeigtes Verfahren der Ermittlung der fehlenden Debianpakete nicht mehr funktioniert. Ich habe derzeit keine Problem Behebung!

Backup wenn der Server kommt

FHEM sichert ziemlich viel selbstständig, allerdings lokal innerhalb der Ordnerstruktur von FHEM. Geht beim Raspberry mal die SD Card kaputt, sollte man das Backup auf einem anderen System gesichert haben. Da bietet sich die NAS, der Windows Server oder was auch immer im lokalen Netzwerk an. Die Anbindung eines Windows/Samba Shares an den Raspberry hatte ich hier schon mal im Detail beschrieben.
Ich möchte zeigen, wie man bestimmte Ordner von FHEM auf ein temporäres Netzlaufwerk sichert und wie man diese Sicherung triggern kann.

Umzug FHEM auf die Paparazzischeue Power Himbeere

Aktuelles 23.03.2017: Dieser Artikel ist mittlerweile zwei Jahre alt, ich empfehle meine aktuellen Anleitungen zur Installation und zum Umzug 

Vorbemerkung zur Überschrift 

Der neue Raspberry Pi 2 hat einen lichtempfindlichen Chip an Board, man tut also gut daran ein weitestgehend lichtdichtes Gehäuse zu verwenden, oder eben nicht zu blitzen.
Wer Himbeermarmelade mag weiß, die Himbeere an sich hat viele Kerne. Ob die im Kuchen nicht auffallen, ist mir jetzt nicht so bewusst aber der Raspberry Pi 2 hat 4 Kerne anstatt bisher nur einen. Mal sehen ob wir die auch wirklich nutzen können.

Installation

Ich schreibe hier einfach mal mit was ich alles tue, um die aktuelle FHEM Installation auf einen neuen Raspberry Pi umzuziehen. Die vielleicht einfachste Variante ist:
Altes System

sudo apt-get update
sudo apt-get upgrade
sudo apt-get autoremove
sudo rpi-update
sudo halt

Dann SD Karte ins neue System stecken, hochfahren und fertig. Das werde ich später auch noch probieren, aber: Wer will schon immer einfach? :-)

Kann ja sein man will/muss die SD Karte auch wechseln. Oder man will das Betriebssystem einfach mal von alten Lasten befreien. Oder wie auch immer ...

Also erstmal System einrichten, wie von mir beschrieben.

Kleine Feststellung am Rande:
Wenn man mehrere Kommando Zeilen aus diesem Text kopiert und mit einem Mal in das Terminalfenster einfügt wird die Verarbeitung abgebrochen wenn ein Zwischenfrage kommt und man J oder enter drückt. Deswegen schreibe ich mal auch die Einzeiler mit && zwischen den einzelnen Kommandos - liest sich nicht so schön funktioniert aber.

Hardwareunterstützung

Ein bisschen mein Standard ist eine Stop/Start Taste einrichten. Die Hardware ist ja vorbereitet, dann noch:

sudo apt-get install python-dev python-rpi.gpio

das schon existierende Script von dem alten Raspberry kopieren nach

/home/pi/shutdown.py

Rechte setzen

sudo chmod +x /home/pi/shutdown.py

und für den Systemstart aktivieren

sudo nano /etc/rc.local

und ganz zum Ende gehen und vor exit 0

sudo python /home/pi/shutdown.py &

eintragen.

FHEM installieren

Die notwendigen Module, dass -f install am Anfang überprüft nochmal die Paketabhängigkeiten. Ob das bei der sauberen Neuinstallation wirklich nötig ist weiß ich nicht.

sudo apt-get -f install
sudo apt-get install perl libdevice-serialport-perl
sudo apt-get install libio-socket-ssl-perl
sudo apt-get install libwww-perl
sudo apt-get install libxml-simple-perl

oder so

sudo apt-get -f install && sudo apt-get install perl libdevice-serialport-perl && sudo apt-get install libio-socket-ssl-perl && sudo apt-get install libwww-perl && sudo apt-get install libxml-simple-perl

oder so

sudo apt-get -f install && sudo apt-get install perl libdevice-serialport-perl libio-socket-ssl-perl libwww-perl libxml-simple-perl

RSS Unterstützung

Will man RSS verwenden braucht man folgende Module

sudo apt-get install msttcorefonts libgd-graph-perl libimage-librsvg-perl

sudo apt-get install libgd-text-perl (wird gebraucht ist schon installiert)

Sonos Unterstützung 

zusätzliche Perl Pakete

sudo apt-get install libsoap-lite-perl

Die Sprachausgabe benötigt eine Samba Freigabe die von Sonos erreichbar sein muss. Ich habe es noch so gemacht, dass jeder schreiben kann.

sudo apt-get install samba samba-common-bin
sudo mkdir /mnt/SonosSpeak
sudo chmod 777 /mnt/SonosSpeak/
sudo nano /etc/samba/smb.conf

Folgende Zeilen hinzufügen (Pfade müssen natürlich u.U. angepasst werden):

[SonosSpeak]

  comment = Audio-Files for SonosPlayer to Speak

  read only = false

  path = /mnt/SonosSpeak

  guest ok = yes

Hier muss normal nichts stehen, damit steht der Eintrag per default auf user:

[global]
  security = user

Samba-Server neustarten:

sudo /etc/init.d/samba restart
oder
sudo invoke-rc.d samba restart

Für das Caching der Sprachausgabe brauche ich noch ein Perl Modul, welches über cpan installiert werden muss.

sudo cpan install Digest::SHA1

netatmo Unterstützung

Netatmo braucht vor allem die Json Library

sudo apt-get install libjson-perl libdigest-md5-file-perl liblwp-protocol-https-perl liblwp-protocol-http-socketunix-perl

FHEM auf der Fritzbox Unterstützung

Um FHEM auf der Fritzbox Remote zu überwachen brauchen wir auch noch zwei Softwarepakete.

sudo apt-get install telnet expect

und das Script /home/pi/StartFhemOnFritz.sh muss von der alten Installation kopiert werden und mit Berechtigung zum ausführen versehen werden.

Email senden

Siehe hier

Das FHEM Paket selbst ist dann nur noch ein klacks, vorher kann man hier schauen ob es eine Neue Version gibt.
Man kann zwar im Zweifelsfall im sudo machen, aber bei wget braucht man es nicht.

wget http://fhem.de/fhem-5.6.deb
sudo dpkg -i fhem-5.6.deb

FHEM wird gestartet und wir sind erstmal fertig mit einem neuen System.

Wiederherstellung altes System

Jetzt noch FHEM auf den aktuellen Stand bringen, oder braucht man das nicht weil ich ja ein backup zurückspielen will? Man könnte jetzt einfach die fhem.cfg einspielen und neu starten, dazu wäre es clever das System zu aktualisieren. Das will  ich aber nicht, ich prüfe einfach mal ob das System läuft:
http://<hostname>:8083
Man kann an 3 Stellen nach einer Version schauen.

1. version in der Kommandozeile von FHEM - die Versionsnummern der geladenen Module
2. fheminfo in der Kommandozeile von FHEM - gibt einen Satz Infos aus, je nach dem was verwendet wird. Bereit um es an das Statistic Modul von Martin Fischer zu senden (fheminfo send)
3. list global in der Kommandozeile von FHEM - gibt uns die Version der fhem.pl

Da ich etwas testen will, mache ich von diesem System mal noch ein backup. Also einfach backup in der Kommandzeile von FHEM.

Achtung! beim enter drücken passiert erstmal gar nichts. Der Browser sendet nach 1 min den Befehl von sich aus neu, damit werden zwei Sicherungen erzeugt. Also besser nach dem Backup Befehl den Browser schließen und im Terminal weitermachen.

Im Terminalfenster eingeben:

sudo invoke-rc.d fhem stop

Jetzt mache ich am "Alten System" nochmal ein backup und dann ein shutdown in der Kommandozeile von FHEM.

Mit Winscp kopiere ich die aktuelle Backup Datei aus dem Verzeichnis 

/opt/fhem/backup auf meinen Windows PC

und dann auf das neue System nach /home/pi . Damit umgehe ich Schreibrechte, muss nichts verbiegen und es bleibt quasi eine temporäre Datei. Sie hat aus meiner Sicht nichts im Pfad /opt/fhem/backup zu suchen.
Jetzt die eigentliche Wiederherstellung des Programmpfades

sudo tar -xvzf /home/pi/FHEM-201xxxxx_xxxxxx.tar.gz -C /opt/fhem/

In meinem Fall brauche ich an Hardware nichts weiter umstecken, ich habe einen HMLAN. Ansonsten müsste man das hier an dieser Stelle tun. 

Und das System wieder starten

sudo invoke-rc.d fhem start

Das SONOS Modul schreibt bei mir ins aktuelle Terminalfenster, für weitere Arbeit öffnet man besser ein neues.

Für eine Test zwischendurch gebe ich dem HMLAN in der fhem.cfg einfach mal eine andere Adresse um es prinzipiell zu testen

sudo nano /opt/fhem/fhem.cfg

Wenn alles läuft kann man die Sache endgültig machen, wenn nicht folgt noch mal Analyse:
Auf dem alten System
Den automatischen Start von FHEM verhindern

sudo update-rc.d -f fhem remove

Auf dem neuen System
Den Start von FHEM wieder auf automatisch stellen

sudo update-rc.d -f fhem defaults

Restarbeiten

Sounddateien für Sonos

Die vorhandene Dateien kann man einfach von Freigabe zu Freigabe kopieren.

Die DEFs verweisen aber noch auf die alte Freigabe, die müsste man auch noch ändern. Solange der alte Raspberry am Netz ist funktioniert natürlich alles.

Tuning

Das sollte die Plots auf mehrere Prozesse auslagern.

attr WEB plotfork 1

Quellen

http://www.meintechblog.de/2014/05/intel-nuc-als-smart-home-server-fhem-on-steroids/
http://www.fhemwiki.de/wiki/Sonos_Anwendungsbeispiel
http://forum.fhem.de/index.php/topic,22520.0.html

Eine weitere FHEM Instanz auf gleicher Hardware

Ein kleines HowTo für eine zweite FHEM Instanz.

1. Variante: Codeshare

Es gibt bei dieser Variante keine separaten Pfade - alles läuft in einem Pfad!
Lediglich eine neue fhem.cfg wird verwendet. Ein Update wirkt sich auf alle Instanzen aus!
Nur 3 Zeilen für die FHEM Kommandozeile - Achtung! Einzeln ausführen! FHEM startet über die Raw Definition mehrere Prozesse, da wäre die neue cfg noch nicht da wenn der sed Befehl losläuft:

• Die erste Zeile holt eine Standard fhem.cfg vom SVN und speichert sie als fhem2.cfg. Die Original fhem.cfg wird nicht überschrieben!
• Die zweite Zeile modifiziert diese fhem2.cfg:
• Port 8093 statt 8083
• ändert Namen für Logfile und Statefile sowie eventTypes, damit läuft diese Instanz zunächst unabhängig.
• initialUsbCheck wird deaktiviert 
• Die dritte Zeile startet diese neue Instanz, sie ist unter http://<hostname>:8093 erreichbar.

"wget -qO fhem2.cfg https://svn.fhem.de/fhem/trunk/fhem/fhem.cfg"
"sed -i -e 's/\/fhem/\/fhem2/;;s/\/eventTypes/\/eventTypes2/;;s/8083/8093/;;$aattr initialUsbCheck disable 1' fhem2.cfg"
"perl /opt/fhem/fhem.pl /opt/fhem/fhem2.cfg"

Achtung: Obwohl die Konfiguration separat ist, verwendet sie den gleichen Pfad wie die erste Instanz. Update, gleiche Namen innerhalb von Definitionen (Logdateien usw.) wirken sich auf beide Instanzen aus!

Ein shutdown der zweiten Instanz beendet diese, ein shutdown der ersten Instanz beendet beide Instanzen!

Mit einem notify in der ersten Instanz, kann man die zweite Instanz automatisch nach dem Start der ersten Instanz starten:

define n_StartFhem2 notify global:INITIALIZED "perl /opt/fhem/fhem.pl /opt/fhem/fhem2.cfg"

Damit läuft auch ein restart ohne Probleme: beide Instanzen werden nacheinander neu gestartet.
Beide Instanzen verwenden unterschiedliche Prozessorthreads/CPUs.

2. Variante: Rettungsweste

Wenn FHEM nicht mehr startet muss man Fehler suchen. Dazu ist es eigentlich nicht schlecht, mal eben "schnell" zu prüfen: Läuft es generell "ohne alles", was sagt das Log?
Der Ausgangszustand ist hier: FHEM läuft nicht! Wir bewegen uns im Terminal!

Erstmal prüfen, ob FHEM wirklich nicht läuft.

ps -aux|grep fhem

Prinzipiell passiert mit diesen Zeilen, das Gleiche wie in Variante 1, außer:

• Nur der Name für den Statefile wird geändert, damit der Inhalt des originalen Statefile erhalten bleibt. 
• Der Logfilename bleibt erhalten, man startet zwar ein  FHEM mit leerer cfg, hat aber den originalen Logfile im Zugriff.

n=3
cd /opt/fhem
sudo wget -qO fhem$n.cfg https://svn.fhem.de/fhem/trunk/fhem/fhem.cfg
sudo sed -i "s/\/fhem.save/\/fhem$n.save/;\$aattr initialUsbCheck disable 1" fhem$n.cfg
# oder auch das Port ändern
# sudo sed -i -e "s/8083/8093/" fhem$n.cfg
sudo chown fhem: fhem$n.cfg 
sudo perl fhem.pl fhem$n.cfg

Damit sieht/kann man:

• ob FHEM startet (keine Problem mit dem Betriebssystem),
• wie gewohnt das Logfile lesen. 
• restore machen
• diese Instanz ganz normal mit shutdown beenden

3. Variante: Völlig separat

In dieser Variante wird folgendes eingerichtet:

• neues Port, 
• der existierende /opt/fhem Pfad wird ohne die aktuellen Daten in einen neuen Pfad /opt/fhemN kopiert, 
• neuer zweiter FHEM Service, 
• neue leere fhem.cfg wird verwendet.

Ein installiertes FHEM  mit Systemd ist Voraussetzung!

Das Script / die Befehle alle im sudo Kontext (sudo su) ausführen!

#!/bin/bash
# Nummer und Port vergeben
n=4
fPort=8103

# aktiven Pfad kopieren, aktuelle Daten ausschließen
rsync -av --exclude={'log/*','restoreDir/*','cache','backup'} /opt/fhem/ /opt/fhem$n/

# fhem Service kopieren, anpassen und anlegen
cp /etc/systemd/system/fhem.service /etc/systemd/system/fhem$n.service
sed -i -e "s/\/fhem/\/fhem$n/" /etc/systemd/system/fhem$n.service
systemctl daemon-reload
systemctl enable fhem$n

# Leere cfg holen und anpassen
wget -qO /opt/fhem$n/fhem.cfg https://svn.fhem.de/fhem/trunk/fhem/fhem.cfg
sed -i -e "s/8083/$fPort/;\$aattr initialUsbCheck disable 1" /opt/fhem$n/fhem.cfg

#Besitzer setzen
chown -R fhem: /opt/fhem$n/

# Service starten
systemctl start fhem$n

Achtung, das kopiert und modifiziert die Version von fhem.cfg und fhem.service vom Entwicklungsstand heute! Wenn sich in Zukunft etwas ändert, muss dieser Code angepasst werden!

Will man alles wieder entfernen:
Bitte Vorsicht!

# zur Sicherheit nochmal n setzen
n=4

# Entferne den Dienst
systemctl stop fhem$n
systemctl disable fhem$n
systemctl daemon-reload
systemctl reset-failed
echo 'Mit y oder Y bestätigen'
rm -i /etc/systemd/system/fhem$n.service

#Entferne den Pfad
echo 'Mit y oder Y bestätigen'
rm -I -R /opt/fhem$n

Dockerfile - Image für den Container selbst bauen

Das hier ist mehr ein persönliche Machbarkeitsstudie und soll kein Ansatz für ein dauerhaft gepflegtes Dockerimage werden. Ich wollte wissen wie es geht und den Vorgang verstehen. herausgekommen ist erstmal ein kurzes Beispiel und ein minimales FHEM Image.

Kurz vornweg: Hier ein Script welches die gesamte docker Umgebung und das FHEM Image baut. Damit hat man auf einem Intel PC in weniger als 2 min (Pi3 ca. 6 min) ein funktionierendes FHEM. 

Crash Recovery

Das System verhält sich komisch? Raspbian bleibt beim Start hängen?

Die SD Card als Datenträger beim Raspberry soll ja häufig den Geist aufgeben. Ich hatte das noch nie, ich behaupte immer das passiert bevorzugt wenn Datenbanken im Spiel sind - aber jetzt hatte es einen Kumpel aus heiterem Himmel getroffen. Ohne Datenbank, ohne aktuellem Backup. Ich konnte ihm helfen und daraus ist dieser Artikel geworden.

Was tun?

Zutaten

• Neue SD Card für das neue System, Größe "egal"
• USB Stick oder zweite SD Card + Reader mit dem Speicherplatz mindestens der alten SD Card.
• Image Tool  (win32diskimager, USB Image Tool, Etcher oder mit Linux Bordmitteln dd.)

In jedem Fall eine Kopie der SD Card anfertigen: Imagedatei ablegen.

Die Originalkarte sollte nicht weiter manipuliert werden und meist ist eine Reparatur der defekten Karte weder sinnvoll noch möglich!

Den Raspberry neu machen

• neue SD Card, 
• aktuelles Raspbian Image aufspielen, 
• starten, 
• System und FHEM Setup.

An der Stelle der Hinweis, auf diesen Artikel falls man nicht mehr weiß, welche Perl Module für die persönliche Installation nötig sind.

systemctl stop fhem

Dateisystem prüfen und Zugriff herstellen

Die 1:1 Kopie auf dem USB Stick (oder SD Card in SD Reader) in den Raspberry stecken. 

Achtung: Das geht bei einem Pi ab Version 2 nach meiner Erfahrung gut. Ein 1er Exemplar würde ich zum Stecken herunterfahren, er wird beim einstecken von selbst neu starten. 

Oder die Imagedatei direkt mounten, siehe weiter unten.

Danach sollte sich folgendes Bild ergeben:

pi@raspib31:~ $ lsblk
NAME        MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
sda           8:0    1 29,8G  0 disk
├─sda1        8:1    1 41,7M  0 part
└─sda2        8:2    1   15G  0 part
mmcblk0     179:0    0 14,9G  0 disk
├─mmcblk0p1 179:1    0  256M  0 part /boot
└─mmcblk0p2 179:2    0 14,7G  0 part /

Der USB "Stick" wird als sda erkannt, die interessante Partition ist sda2. Für die jetzt folgende Reparatur darf sda2 nicht gemountet sein/werden! 

Ein erster Check ohne Optionen erledigt offenbar schon mal alles, mir ist nicht klar in welchem Fall welche zusätzlichen Optionen (oft empfohlen -l, Hilfe mit -h) notwendig sind.

Alle weiteren Befehle erfordern erhöhte Rechte, deswegen erstmal sudo su. 

Die Ausgabe ist nur ein Beispiel und kann je nach Fehler völlig anders sein!

sudo su
fsck /dev/sda2
# fsck from util-linux 2.33.1
# e2fsck 1.44.5 (15-Dec-2018)
# /dev/sda2: recovering journal
# Setting free inodes count to 899857 (was 899863)
# Setting free blocks count to 3338902 (was 3339342)
# /dev/sda2: clean, 46703/946560 files, 577130/3916032 blocks

SD Card mounten 

Jetzt die interessante Partition mounten und hoffen dass etwas lesbar ist.

mkdir /mnt/sda2
mount /dev/sda2 /mnt/sda2

Alte Dateien kopieren

Alle Dateien von dem alten System werden kopiert und die Rechte entsprechend gesetzt, zuletzt wird das USB Gerät ausgeworfen. In der Hoffnung, dass nichts wichtiges kaputt ist! 

Idee: Man könnte die Backup Dateien ausschließen  oder rsync verwenden.

cp -R /mnt/sda2/opt/fhem/* /opt/fhem/
chown -R fhem: /opt/fhem/
umount /mnt/sda2

System prüfen

systemctl start fhem

Das kann eine Weile dauern, z.B. wenn Moduldateien fehlerhaft sind. Der Ungeduldige kann derweil ins Log schauen.

tail /opt/fhem/log/fhem-$(date +%Y)-$(date +%m).log

Wenn das System Fehler zu defekten Modulen liefert, nach dem Start in FHEM erstmal ein update versuchen.

update force

Neu starten und System wieder prüfen

systemctl restart fhem

Wenn es doch nicht läuft

• Es fehlen System Pakete? Da hatte ich hier schon mal was geschrieben.
• Wenigsten mit der fhem.cfg neu anfangen, notfalls eine Alte aus dem restoreDir pfad. Siehe Wikiartikel.
• Ist eine Backupdatei in /opt/fhem/backup vorhanden? Einfach das letzte Backup versuchen, siehe hier.

Alternative - Image Datei direkt mounten

Die kopierte Image Datei wird direkt als Block Laufwerk eingebunden. Ich habe dazu hier eine gute Erklärung gefunden. Das sieht alles etwas komplizierter aus, aber eigentlich spart man die Zeit für die Kopie auf den USB Stick und man muss nichts stecken.

Zunächst den Pfad zum Image z.B. über cifs (SMB) einbinden:

sudo su
# SMB Laufwerk mounten
mp="/mnt/daten"
mkdir $mp
mount -t cifs -o username=UserName,password=Passwort //server/sicherung $mp
# Loop Device erstellen
img="$mp/fhem/raspib3/kopieSdDefekt.img"
ldev=$(losetup --show -f -P "$img")

An der Stelle hat man quasi "den USB Stick gesteckt" d.h. man hat einen /dev/ Eintrag den man wie ein angeschlossenes Laufwerk behandeln kann. Dies(e) Gerät(e) anzeigen:

losetup -l

Jetzt kann man wie oben beschrieben fsck ausführen. dafür kann man einfach die Variable $ldev verwenden:

fsck ${ldev}p2

Ist der Vorgang erfolgreich kann man die Partitionen mounten:

Achtung: Diese Schleife mounted nicht, sie gibt nur die Befehle aus!

#Alle Partitionen mounten
for part in ${ldev}p*
do 
  dst=/mnt/$(basename $part)
  echo "mkdir $dst"
  echo "mount $part $dst"
done

Nachdem man analog zu oben die Dateien kopiert hat, kann man alles wieder aufräumen:

umount /mnt/loop0*
rm -R /mnt/loop0*
losetup -D
umount $mp

Backup einrichten!

Siehe dazu auch meinem Artikel zur externen Sicherung des FHEM backups.

FHEM - kann ich nicht einfach bei null beginnen?

Diese Frage wird immer mal gestellt - Aber: Was ist eigentlich null?

Warnung: Was ich jetzt beschreibe löscht wirklich alle eigenen Definitionen. Falls man etwas behalten will, sollte man den Pfad /opt/fhem vorher komplett sichern!!! Zumindest die Textdatei fhem.cfg sollte man aufheben, eventuell stehen dort nützliche Definitionen drin, die man wieder übernehmen kann.

Also dann - setzen wir FHEM zurück:
- erstmal shutdown in der Befehlszeile von FHEM und tschüss Browser

Alles weitere über Terminal oder WinSCP
- die leere fhem.cfg gibt es hier, die ersetzt die bisherige fhem.cfg
Jetzt müssen wir noch ein paar Dateien unterhalb von /opt/fhem löschen:
- Inhalt von ./log löschen.
- Inhalt von ./backup löschen
- Inhalt von ./restoreDir löschen
- ./FHEM/controls_fhem.txt löschen
- ./FHEM/99_myUtils.pm kann man löschen oder behalten.

Jetzt können wir FHEM wieder starten und anschließend im Browser neu beginnen.

Diese Script würde das erledigen. Vorsicht die bestehende FHEM Installation wird damit zurückgesetzt auf null!

wget https://svn.fhem.de/fhem/trunk/fhem/fhem.cfg
sudo systemctl stop fhem
# Kopie anlegen
sudo cp -R /opt/fhem/ ~/Sicherung/
# Ab hier wird zurück gesetzt
sudo cp fhem.cfg /opt/fhem/
sudo chown fhem:dialout /opt/fhem/fhem.cfg
sudo rm -R /opt/fhem/log/*
sudo rm -R /opt/fhem/backup/*
sudo rm -R /opt/fhem/restoreDir/*
sudo rm /opt/fhem/FHEM/controls_fhem.txt
sudo rm /opt/fhem/FHEM/99_myUtils.pm
# FHEM neu starten
sudo systemctl start fhem

Umzug von FHEM

Die alte Hardware ist zu schwach, defekt oder warum auch immer - das System soll neu gemacht werden!?
Ausgangszustand:

• Raspberry Pi2, 
• Raspbian Wheezy, 
• Probleme mit der SSL Lib beim https Zugriff (SSL Version SSLv2 not supported), ist mit jessie behoben.

Zielzustand:

• Raspberry Pi3
• Raspbian Jessie Lite

Geht relativ einfach, wenn man einige Vorbereitungen trifft. Der grobe Fahrplan sieht so aus:

1. Auf neuer Hardware ein neues System installieren.
2. Alle benötigten Tools und Module (debian Pakete) nachinstallieren.
3. FHEM als Grundlage installieren, eventuell Details testen (z.B. SSL).
4. Backup und shutdown aktuelles FHEM System auf Pi2
5. Transfer der Backupdatei auf Pi3
6. Restore und Start von FHEM auf dem Pi3
7. Test ob System einwandfrei läuft, wenn ja alles gut, wenn nein eventuell erstmal Restart FHEM auf Pi2 und in Ruhe untersuchen -> nochmal ab Schritt 4 bis alles läuft.

Schritt 1-3 

habe ich hier ausführlich beschrieben, das dauert je nach dem was man im Schritt 2 alles benötigt alles in allem keine 20 min. Dieser Artikel wird von mir laufend aktualisiert. Zu dem Wissen zu gelangen was man alles benötigt, kann allerdings wesentlich länger dauern, wenn man sich nichts aufgeschrieben hat. Im Zweifelsfall sollte man ein Paket/Tool mehr als eines zu wenig installieren. Die empfohlene Liste auf debian.fhem.de ist sicher ein guter Kompromiss.  Ich habe angefangen eine Liste zu erstellen, welches FHEM Modul welche cpan Module bzw. debian Pakete benötigt. Die werde ich noch veröffentlichen.

Schritt 4 und 6 

kann man nach seinen persönlichen Vorlieben gestalten. Normalerweise sollte das in wenigen Minuten abgeschlossen sein.
In der Regel sollte alles was FHEM betrifft in diesem Pfad liegen /opt/fhem/. Dieser Pfad muss auf das neue System und muss die richtigen Berechtigungen erhalten. Ich habe das hier schon mal im Detail beschrieben und es genauso gemacht:

Pi2 in der FHEM Oberfläche 

backup
warten bis backup fertig -> Log oder Eventmonitor
shutdown

• mit winscp die aktuelle Sicherung ins zentrale Sicherungs-Share auf den Server kopieren
• und in  einer zweiten Sitzung gleich wieder auf den Pi3 ins /home/pi/ Verzeichnis kopieren

Pi3 als User Pi im putty Terminal

sudo systemctl stop fhem
sudo tar -xvzf /home/pi/FHEM-201xxxxx_xxxxxx.tar.gz -C /opt/fhem/
sudo systemctl start fhem

Schritt 7

• FHEM Web erreichbar?
• Log File kontrollieren!!!

Wenn bis hier grobe Fehler vorhanden sind am Besten erstmal den Pi3 wieder beenden und alles auf dem Pi2 wieder starten. In Ruhe Fehler suchen.

• Schalter betätigen
• Sonderfunktionen kontrollieren (Sound und Sprachausgabe usw)

Nützliche Hinweise und Befehle

Umfangreiche Manipulation müssen nicht zeileweise mit sudo gemacht werden, sudo su schaltet den sudo Modus ein bis zum exit.

Es kann immer mal passieren, dass die Rechte im fhem Verzeichnis falsch sind. Dies kann man relativ einfach beheben in dem man den Eigentümer aller Dateien setzt:

sudo chown -R fhem:dialout /opt/fhem/

Manchmal muss die Rechte einzelner Dateien setzen, z.B. ausführbar machen:

sudo chmod +x /home/pi/shutdown.py

In besonderen Fällen muss das UID Bit gesetzt werden:

chmod u+s /usr/bin/dfu-programmer

Oder ganz brutal, einfach Rechte auf Alles:

sudo chmod 777 /etc/systemd/system/pishutdown.service

Ein paar Beispiele für User und Gruppen Mitgliedschaften:

useradd -m test
passwd test
gpasswd -a test users
gpasswd -a pi pulse-access
gpasswd -d pi audio
gpasswd -d test audio
groups test
getent group test
cat /etc/group

Samba Freigabe für Sonos einrichten:

sudo mkdir /mnt/SonosSpeak
sudo chmod 777 /mnt/SonosSpeak/
sudo nano /etc/samba/smb.conf

am Ende folgendes einfügen:

[SonosSpeak] comment = Audio-Files for SonosPlayer to Speak
read only = false
path = /mnt/SonosSpeak
guest ok = yes

anschließen den Service neu starten

sudo systemctl restart smbd.service

Zusatzinfo

Das Verhalten/der Syntax in der smb.conf hat sich offenbar bei Jessie etwas geändert! Nutzt man die Originale smb.conf von Raspbian muss man nur den Abschnitt des Shares (siehe oben) einfügen.
Die Anonyme Zugriff auf Shares wird durch die Standard Einstellung im Abschnitt
   [global]
   security = user
   map to guest = bad user
ermöglicht. Die erste Zeile ist die Standardeinstellung und ist in der smb.conf nicht extra gesetzt. Die zweite Zeile steht so in der Original smb.conf schon drin.

FHEM auf neues System umziehen

Eigentlich ist der Weg einfach:

1. Neues System installieren (Perl Module dokumentiert?)
2. Altes System beenden und sichern
3. Restore der Sicherung, Test und Start neues System

Die Downtime beim finalen Umzug soll möglichst gering sein. Punkt 3 kann, vor allem auch zur Übung, mehrfach durchlaufen werden. 

Hinweis: Es gibt zu diesem Thema auch eine aktualisierte Schritt für Schritt Anleitung.

Am Setup eines Raspberry hat sich seit 2019 bei mir nichts geändert. Aber ich habe ein paar neue Ideen getestet. Es ist gut wenn man ein Testsystem oder die neue Hardware bereits zur Vorbereitung hat! 

Will man es auf gleicher Hardware vorbereiten, sollte man sich meinen Artikel BootStick für den RaspberryPi anschauen. 

Browser Timeout und FHEM

Schon mal einen Befehl in FHEM ausgeführt und nach ca. zwei Minuten einen Time-out bekommen? Schon mal gewundert, dass ein Backup doppelt ausgeführt wurde?

Warum das so ist? Den Hinweis fand ich im Forum.
Mir sind zwei Situationen aufgefallen in denen der Browser beim Zugriff auf FHEM in einen Time-out gerät. Beim Backup und beim update force. In beiden Fällen bekommt der Browser keine Quittung für den Befehl und wartet eine Minute. Läuft der angeforderte Befehl länger als eine Minute sendet der Browser einmalig den Request neu. Damit erhält FHEM erneut den Request und führt ihn aus, der Browser zeigt nach der zweiten Minute einen Time-out.
Blöd ist: Man hat anschließend das Backup doppelt in kurzem Abstand. Das update force läuft unnötigerweise auch zweimal.
Nicht besonders schlimm, aber man kann das auch verhindern: Befehl ausführen und einfach Browser schließen.

Beim Backup gibt es noch die gute Idee es nicht manuell zu starten sondern automatisch auszuführen. z.B. vor dem Update:

attr global backup_before_update 1

Oder man richtet ein zyklisches Backup ein.

Containern - Praxis

Im ersten Teil habe ich die Installation einer LXD Umgebung beschrieben. Im zweiten Teil soll es um die weitere Konfiguration und den Umgang mit LXD Containern gehen: 

• Zugriff auf die Container mittels Port Mapping, 
• Hardware anbinden durch USB Port Mapping und Verwaltung, 
• Backup und Zugriff auf den Speicher.

Es gibt eine gute grundlegende Doku, ich will nur ein paar praktische Versuche dokumentieren.

Setup Raspberry Pi 2019

Mal wieder ist ein Jahr um und ich habe ein bisschen dazu gelernt. Ich stelle jetzt meine Setup Scripts über GitHub zur Verfügung, das macht es leicht sie einfach beim Setup zu laden.
Am grundlegenden Setup vom System und von FHEM hat sich nicht soviel geändert, deswegen verzichte ich hier auf Detailbeschreibungen, soweit die vom vorigen Jahr noch gelten.

Mein Setup basiert auf einem aktuellem raspbian Lite Image, welches von raspberrypi.org herunter geladen wird und mit einem Imagetool (Windows z.B. win32DiskImager) auf die SD Card geschrieben wird. Für die Headless-Installation braucht man den ssh Zugang und darf die Datei ssh im Bootlaufwerk nicht vergessen! Vor dem Kopieren den Laufwerksbuchstaben richtig setzen (meine Codeboxen sind editierbar) ctrl+a um alles zu kopieren, Windows+r um die Ausführen-Box zu erhalten und die Zeile dort "einwerfen".

cmd /c echo " " >e:\ssh

Beim Setup braucht man erweiterte Rechte, deshalb alles im Context "root" - sudo su ausführen! Man kann die Scripts entweder mit chmod +x ausführbar machen oder einfach mit bash Scriptname starten. Bitte beachten:
Alle meine Scripts sind für "einmaligen" Gebrauch bestimmt! Ich habe praktisch keine Fehlerbehandlung für wiederholte Ausführung und Bereinigung drin. Sollte also während der Installation etwas schief gehen, kann man völlig neu beginnen oder muss die Installation Schritt für Schritt manuell ausführen!

Die Basis

Die Grundeinstellung:

• Zeitzone Berlin, 
• alles auf "deutsch" :
• Land, 
• Locale, 
• Consolen Keyboard 
• und WiFi, 
• Hostname. 

Das müsste eigentlich noch um die Abfrage des Passwortes für Pi ergänzt werden.
Das Setup Script startet mit einem Upgrade des aktuellen Raspbian Standes, je nach nach aktuellen Zeitpunkt "zwischen den Images" kann das aktuelle Image schon ein paar Monate alt sein und könnte offene Lücken haben.
Wesentliche Schritte sind im Script kommentiert, das wird auch aktuell gehalten.

wget https://raw.githubusercontent.com/heinz-otto/raspberry/master/setupBasic.sh

Jetzt hat man ein aktuelles raspbian, das restliche Setup ist Anwendungsspezifisch.
Update Juni 2019: Mir ist erst jetzt aufgefallen, das hostnamectl den Namen in der /etc/hosts nicht anpasst. Das muss man also zusätzlich mit sed (Meine Version von September 2016) tun.

Für Pi mit Bluetooth Modul

Als nächstes kann man für Zusatzmodule auf der GPIO-UART Schnittstelle beim Pi3 und P3+ diese Schnittstelle aktivieren.
Bei den Modellen B, B+, B2 wird lediglich die uart aktiviert, da sie per default deaktiviert ist. Link
Nach diesem Script wäre ein Neustart fällig, aber nicht an dieser Stelle notwendig und deshalb nicht integriert. Den reboot kann man jederzeit später einbauen.

wget https://raw.githubusercontent.com/heinz-otto/raspberry/master/setupUart.sh

Samba Server

Für die Sprachausgabe brauche ich einen SMB Server. Das folgende Script installiert den Dienst und ein SMB Share, welches ohne Anmeldung frei beschreibbar ist!

wget https://raw.githubusercontent.com/heinz-otto/raspberry/master/setupSamba.sh

FHEM

Auch das Script für die grundlegende FHEM Installation habe ich angepasst. Ich verwende jetzt zwei Textdateien in denen meine aktuell zusätzlich verwendeten deb Pakete und Perl Module (cpan) enthalten sind. Wer das lokal anpassen möchte erstellt einfach im aktuellen Pfad (/home/pi) beide Dateien mit entsprechendem Inhalt (Vorlage auf GitHub). Die vorhanden Dateien werden vom Script genutzt und nicht überschrieben.
Das Script arbeitet folgende Schritt ab:

• Vorbereitung FHEM Setup gemäß https://debian.fhem.de/
• Hole Textdateien mit zusätzlichen deb Paketen und Perl Modulen
• und Installiere ...
• Installation FHEM
• Basiskonfiguration FHEM 

wget https://raw.githubusercontent.com/heinz-otto/raspberry/master/setupFhem.sh

Nach dem Download ist es sicher sinnvoll, gerade die Basiskonfiguration von FHEM noch anzupassen und zu erweitern. Z.B. die Ortsabhängigen Koordinaten attr global l...
Ein automatisches Save am Schluss der Konfiguration ist in meinem Script nicht drin!

Backup

Wer möchte kümmert sich auch jetzt sofort ums Backup. Ich hatte dazu schon etwas geschrieben. 

Das Script muss nach dem download mit den Informationen zum Server und Account angepasst werden.

wget https://raw.githubusercontent.com/heinz-otto/raspberry/master/setupBackupFhem2Cifs.sh

Nodejs

Einige Applikationen erfordern die Anbindung mit Node Server. Die Installation habe ich hier beschrieben und ein simples Script dazu gemacht.

wget https://raw.githubusercontent.com/heinz-otto/raspberry/master/setupNodejs.sh

Tipp

Will man alle hier erwähnten Scripts herunterladen, geht das mit "Brace Expansion" in diesem Einzeiler.

wget https://raw.githubusercontent.com/heinz-otto/raspberry/master/setup{Basic.sh,Uart.sh,Samba.sh,Fhem.sh,BackupFhem2Cifs.sh,Nodejs.sh}

Sound

Tobias hat irgendwann in seinem Text2Speech Modul den Aufruf MplayerCall so erweitert, dass man den Aufruf z.B. für play ohne mein früheres Wrapper Script verwenden kann. Der Volume Level wird bei mplayer quasi in Prozent, bei play eher als Faktor angegeben. Deshalb teile ich den vom Modul übergebenen Level einfach durch 100. Zusätzlich muss man den leicht anderen Syntax des Alsa Devices bei der Definition beachten! (Bei mplayer hw=0.0)

Mit aplay -l kann man sich die Geräte anzeigen lassen. Die Subgeräte kann man bei der Definition weglassen! Zeigt aplay -l die Soundkarte als Device 1 braucht in der Definition nur hw:1 stehen.
Leider kann die Shell nur ganze Zahlen rechnen. Man könnte Perl nehmen oder die Nachkommastellen mit Modulo rechnen. Ich habe mal beide Varianten aufgeschrieben. Funktionieren tun beide.

define MyTTS Text2Speech hw:0,0
attr MyTTS TTS_MplayerCall AUDIODEV={device} play -q -v $(perl -e 'print {volume}*{volumeadjust} / 10000;') {file}
attr MyTTS TTS_MplayerCall AUDIODEV={device} play -q -v $(({volume}*{volumeadjust}/10000)).$(({volume}*{volumeadjust}%10000)) {file}

Es gibt eventuell eine Fehlermeldung (WARN alsa: can't encode 0-bit Unknown or not applicable) und es wird trotzdem Sound wieder gegeben. Das ist offenbar ein Bug, diese Meldung kann man mit &>/dev/null am Ende des Befehls unterdrücken.

Update

Ein vorhandenes System aktuell halten, wie macht man es richtig? So einfach wie unter Windows ist es leider nicht.Bei Windows wird es uns mittlerweile zwangsweise ziemlich einfach gemacht, das System macht einfach ein Update. Bei Linux muss man irgendwie wissen was in welcher Reihenfolge man tun muss. Mal schauen was ich da noch so herausfinde.
Hier gibt es einen Ausgangspunkt für  mein ToDo
https://forum.fhem.de/index.php/topic,101232.0.html#lastPost

Infos zur Installation von Modulen und Paketen

• Was ist auf meinem System in der Vergangenheit installiert worden?
• Ist ein bestimmtes Modul oder Paket schon installiert?
• Welches Debian Paket brauch ich für ein bestimmtes Perl Modul?

Ich habe etwas herum experimentiert und dabei sind ein paar Einzeiler für die Beantwortung dieser Fragen entstanden.

Historie

Die erste Frage kann man relativ leicht beantworten, das apt System loggt nämlich alle apt-get Vorgänge sogar mit der eingegeben Kommandozeile mit.

cat /var/log/apt/history.log|grep Commandline

Besser zuordnen lässt sich das noch in der Art.

cat /var/log/apt/history.log|grep -A1 Start-Date

Beide Zeilen ergeben keine Ausgabe? Das gesuchte ist nicht dabei? Die Installation liegt schon zu lange zurück! Die Logs werden mit Log Rotate archiviert. Auch dieses Archive kann man komplett, zeitlich richtig sortiert, anzeigen/durchsuchen.

zcat $(ls -tr /var/log/apt/history.log.*.gz)|grep -A1 Start-Date

Man hat Perl Module per CPAN installiert?
Wenn man das debian Paket perl-doc installiert hat (oder noch installiert) kann man mit diesem Mammut-Einzeiler eine List der mit cpan installierten Module ausgeben (Quelle):

for M in `perldoc -t perllocal|grep Module |sed -e 's/^.*" //'`; do V=`perldoc -t perllocal|awk "/$M/{y=1;next}y" |grep VERSION |head -n 1`; printf "%30s %s\n" "$M" "$V"; done |sort

Installierte Modul und Pakete finden und listen

Wie man ermitteln kann ob ein bestimmtes Perl Modul oder debian Paket schon installiert ist habe ich hier schon mal gezeigt. Die beiden folgende Zeile liefern jeweils ein Liste aller installierter Pakete, entweder zeilenweise oder eine Zeile mit Leerzeichen getrennt. Der wichtige Schlüssel in dieser Zeile ist der String "^ii", mit diesem oder vielleicht einfacher einem weiteren grep 'suchstring' kann man die Rückgabe wesentlich beeinflussen. Beide Listentypen eignen sich für die weitere Verarbeitung.

dpkg -l |grep ^ii| awk '{ print $2 }'
dpkg -l |grep ^ii| awk '{ print $2 }'|tr -d "\r"|tr "\n" " "

Will man wissen ob ein bestimmtes Perl Modul installiert ist, kann man das einfach herausfinden. Man kann aber auch herausfinden ob und durch welches debian Paket es installiert wurde. Die zweite Version sucht nur in Paketen die -perl im Namen tragen und läuft damit wesentlich schneller.

s='Device::SerialPort'
perl -M$s -e '' 2>/dev/null &&echo "Modul $s ist vorhanden"
for i in $(dpkg -l |grep ^ii| awk '{ print $2 }'|tr -d "\r"|tr "\n" " ");do if dpkg -L $i|grep $s &> /dev/null;then echo $i enthält $s;fi;done
for i in $(dpkg -l |grep ^ii|grep '\-perl'| awk '{ print $2 }'|tr -d "\r"|tr "\n" " ");do if dpkg -L $i|grep $s &> /dev/null;then echo $i enthält $s;fi;done

Debian Pakete anhand von Perl Modulnamen finden

Es gibt gute Gründe die Installation von Perl Modulen über debian Pakete der Installation über cpan zu bevorzugen. Für mich zählt die Updatefähigkeit und die Geschwindigkeit. Man kann im Internet nach den Paketen suchen, man kann aber auch einfach die Verfügbarkeit für das lokale System testen. Dazu braucht man das Tool apt-file, welches man zuerst installieren muss. Der letzte Befehl lädt den Infocache lokal und dauert etwas.

sudo apt-get update
sudo apt-get install apt-file
sudo apt-file update

Für die folgende Suche, nutze ich den Umstand, dass in der im Paket enthaltenen Liste der Dateien auch die Doku in der Form "/usr/share/man/man3/IO::File.3perl.gz" enthalten ist. Ich ergänze also den Modulstring um "/" + "." und suche exakt danach. Da die Suche ziemlich zeitaufwendig ist, kann man auch nach mehreren Modulen in einem Vorgang suchen lassen. Der search Befehl akzeptiert mehrere Modulnamen durch Zeilenumbruch getrennt. In meinem Beispiel sind die Modulnamen in einem String durch Leerzeichen getrennt, die Trennung wird in Zeilenumbruch geändert, jede Zeile ergänzt und über stdin an den search Befehl von apt-file übergeben. Die Option -l bewirkt das nur die gefunden Pakete gelistet werden, werden mehrere der abgefragten Modulnamen in einem Paket gefunden, wird es nur einmal gelistet!

s="IO::File Digest::MD5"
echo $s|tr " " "\n"|sed 's/$/./;s/^/\//'|apt-file search -l -f -

Die Config analysieren

Mit Hilfe des Installermoduls, kann man auch eine bestehende Configdatei untersuchen und fehlende Pakete nachinstallieren. 

Voraussetzung: das neue FHEM System.

Mit einem Zusatzmodul, einer Definition sowi ein paar Zeilen Scriptcode kann man so testen ob alle Vorrausetzungen installiert sind bzw. die fehlenden Pakete installieren.

Danach backup zurückspielen und fertig. 

# System mit Suchmaschinen und Hilfsscript aufrüsten
sudo apt install apt-file libperl-prereqscanner-notquitelite-perl
sudo apt-file update
wget -O fhemcl.sh https://raw.githubusercontent.com/heinz-otto/fhemcl/master/fhemcl.sh
chmod +x fhemcl.sh

# Definition zum Testen erstellen
cat <<EOF | ./fhemcl.sh 8083
attr initialUsbCheck disable 1
define installer installer
attr installer installerMode developer
save
EOF

# Zu prüfende config Datei holen
scp pi@raspib3:/opt/fhem/fhem.cfg .
ref='/home/pi/fhem.cfg'

# Abfrage starten
s=$(./fhemcl.sh 8083 "get installer checkPrereqs $ref"|grep -oE 'installPerl.*&fwcsrf'|grep -oE '\s[a-z,A-Z,:]+\s')
packages=$(echo $s|tr " " "\n"|sed 's/$/./;s/^/\//'|apt-file search -l -f -)
echo 'debian Pakete fehlen:'
echo $packages
echo 'sudo apt install $packages' 

Gibt es noch mehr?
Oh ja, nodejs Pakete oder auch python.
Mit npm kann man so die "global" installierten Pakete listen lassen:

npm list -g --depth 0

Python ist ja Bestandteil des debian System, verwendet man zusätzliche Pakete hat man meist pip (python-pip) installiert. Python gibt es auch in der Version 3 (python3) dafür gibt es natürlich separat pip3 (python3-pip). Mit der Option -l verringert sich die Liste auf das, was man selbst installiert hat.

pip list -l

Und man kann auch schauen ob sich was neues findet.

pip list -l --outdated

File Log - und gut?

Ich suche schon lange einen Anfang um vom FileLog auf eine Datenbank umzusteigen. Es soll ja Vorteile bringen ...
Das sind einfach ein paar Notizen, eine Anleitung wird das so erstmal nicht werden.

Ein paar Gedankenstriche

• Ich hätte Bedenken eine SQL Datenbank auf einer SD Card zu betreiben.
• SQLite ist eine Datei basierte, lokale Datenbank, es ist kein Datenbankserver.
• MySql ist ein Datenbankserver, der Zugriff kann auch Remote erfolgen, man könnte die Server-Instanzen auf mehrere Maschinen aufteilen.
• Einzelne Textdateien können beim Stromausfall unbrauchbar werden, bei einem Datenbankserver kann die gesamte Datenbank unbrauchbar werden.
• Backup muss anders gemacht werden, einfach alle Dateien eines laufenden DB Servers sichern ist nicht sinnvoll.
• Die Erzeugung von SVG-Plots ist aus meiner Sicht derzeit schwieriger als aus FileLogs und hat Stolpersteine.

Um in das Thema einzusteigen, habe ich MariaDB installiert, ein DBLog und ein FileLogConvert Device in FHEM angelegt und erstmal geschaut wie es sich mit einem importierten Jahreslog von 2018 mit der Temperatur und Luftfeuchte meines Aussensensors so arbeiten lässt.
Ich konnte die Temperatur plotten, die Luftfeuchte funktionierte nicht. Obwohl ich dachte, ich hätte die Erklärungen im Wiki für den Umstieg verstanden. Hatte ich - aber meine Daten waren Murks.

Plot erzeugen

Was habe ich beim Erzeugen eines Plot bisher verstanden und für mich als Handlungsgrundlage festgelegt habe:
Das Anlegen eines Plots geht quasi los wie immer:
Am DbLog Device gibt es oben einen Link: Create SVG Plot from DbLog
Im Menüpunkt "Diagram label, Source" wählt man als Quelle sein DbLog Device.
Dahinter kommt die Wertzuweisung in der Form (für den Fall das man nicht nur ein Reading mit einem Wert pro Zeile geloggt hat).

<Device>:<Reading>:::$val=~s/<regex>/$1/eg

$val ist die interne Variable die letztendlich den Wert für diese Plotzeile enthält (z.B. die Temperatur)
Auf $val wird ein regex angewendet (=~) welches mit suchen (<regex>) und ersetzen ($1) den Inhalt von $val verändert. Trifft das regex nicht zu, bleibt $val unverändert!
$1 (oder auch $2 usw) enthält dabei den "Groupmatch", also normal einen Teilstring.

Match

Dezimalzahlen mit Punkt kann man so als Gruppe erkennen: ([-\d.]+) -> erkennt eine Zeichengruppe aus "- . und Ziffer" zwischen 1 und unendlich mal. (* erkennt zwischen 0 und unendlich mal, Punkt ist hier wirklich der Punkt und nicht ein beliebiges Zeichen)
Ein "T: " am Beginn eines Wertes kann man so erkennen: ^T:\s -> Anfang der Zeichenkette, ein T, ein : und ein Whitespace.
Einen Trenner zwischendrin kann man so erkennen: .H:\s -> Ein Zeichen, ein H ein : und ein Whitespace
Mein geloggtes state Reading sieht so aus: T: 20.7 H: 69 und mit dem regex   ^T:\s([-\d.]+).H:\s([-\d.]+) habe ich den Zahlenwert hinter T in $1 und den Zahlenwert für H in $2.
Nach diesem Schema ließen sich jetzt beliebige Kolonnen analysieren. Anstatt in jeder Zeile die Klammern zu versetzen und immer eine Ersetzung mit $1 zu machen, finde ich es übersichtlicher jede Zeile mit gleichen (allen) Klammern auszustatten und von Zeile zu Zeile $1 auf $n zu wechseln.

Resultat

Zeile in der Datenbank

select * from history where (TIMESTAMP like "2019-08-19 10:25:21");

+---------------------+--------------+-------+----------------------+---------+---------------+------+
| TIMESTAMP           | DEVICE       | TYPE  | EVENT                | READING | VALUE         | UNIT |
+---------------------+--------------+-------+----------------------+---------+---------------+------+
| 2019-08-19 10:25:21 | SensorAussen | DUMMY | state: T: 20.7 H: 69 | state   | T: 20.7 H: 69 |      |
| 2019-08-19 10:25:21 | SensorAussen | DUMMY | tempMax: 30.3        | tempMax | 30.3          |      |
| 2019-08-19 10:25:21 | SensorAussen | DUMMY | tempMin: 18.6        | tempMin | 18.6          |      |
+---------------------+--------------+-------+----------------------+---------+---------------+------+

Zeilen im SVG Plot

SensorAussen:state:::$val=~s/^T:\s([-\d.]+).*H:\s([-\d.]+)/$1/eg
SensorAussen:state:::$val=~s/^T:\s([-\d.]+).*H:\s([-\d.]+)/$2/eg

Für die Zeilen wo nur ein Wert in Value steht sieht die Sache viel einfacher aus:

SensorAussen:tempMax::

Fragen

Was der Wert an dritter Stelle (::0:) bewirkt den man laut Wiki hinschreiben kann? - ist mir nicht klar.
Auch ist nicht klar, warum bei der Angabe von $val= noch ein vierter Trenner ":" sein muss.
Device:Reading:?:?:$val= ...
Der Umgang mit Platzhalter <SPEC1> (attr plotfunction) oder mit attr plotReplace ist mir auch noch nicht klar. Es würde SVG gplot Dateien universell nutzbar machen.

Achtung

Wenn die current Tabelle gefüllt ist, steht der Fenster Device:Reading nicht zum Schreiben zur Verfügung. Man kann dann nur "Pärchen" aus der Klappliste auswählen. Wenn man dann speichert wird jede Zeile die man vorher mit :$val= eingetragen hat gelöscht!
Will man den Inhalt der current löschen geht das mit einem SQL Statement:
delete from current;

Fazit

Es ist aufwendig und der Nutzen scheint mir derzeit gering. Ich muss mich noch weiter damit beschäftigen