Bericht: FHEM auf Stretch (Debian 9) RPI

curt · 30 Oktober 2017, 07:11:59

Zu meiner Einordnung: FHEM-Anfänger, Linux eher Profi.

Da der für FHEM genutzte RPI B+ bei SVG-Grafiken (mehrere, Monatsansicht) deutlich schwächelt, kam ein neuer RPI 3b. Und ich dachte: Das ist doch die beste Gelegenheit, das seit wenigen Monaten freigegebene Stretch in Verbindung mit FHEM zu testen. Reales Zielsystem war: Raspian Stretch (Clone von Debian 9), die Lite-Version.

Vorab: Es gibt keine Probleme zwischen Stretch und FHEM. Alles gut.

Allerdings gibt es kleinere Stolperfallen, bei mir waren das die folgenden:

Ich hatte Raspian Stretch auf dem neuen RPI3 aufgesetzt, dort auch ein nacktes FHEM eingespielt. Immer wieder update, ist doch klar. Auf dem alten RPI-B+ unter FHEM ein backup, dann shutdown. Das komplette Verzeichnis via scp rüber auf den neuen RPI3b. Und einspielen und erstmal ohne die ganze Peripherie starten.

Hier knallt es das erste Mal: /opt/fhem/certs wird beim Backup nicht mitgesichert. Wer ausschließlich HTTPS 1 nutzt, fällt zügig auf die Nase, keinerlei Zugriff über Browser oder andere Geräte. Da ist es zwingend, sich ein neues Zertifikat zu bauen. Wenn man das nicht täglich macht und zudem nicht so genau weiß, wo die beiden Dateien abzulegen sind, sucht erstmal in den verschiedenen Dokus.

Bei genauerem Hinsehen scheint es mir aber richtig, das man mit sanftem Druck gezwungen wird, auf einer neuen Maschine auch ein neues Zertifikat anzulegen. Es könnte netter gesagt und fachlich begündet werden, klar.

So, FHEM funktioniert also nun, der Zugriff funktioniert auch. FHEM jammert ... die physikalischen Geräte sind noch gar nicht angeschlossen. Dann mal los ... ganz langsam.

Die (bei mir!) via USB angeschlossenen Dingser machten so gar keine Probleme - bei mir waren sie im alten System via "by-device" konfiguriert. (Hier wird das erklärt -> https://steigerbalett.wordpress.com/2015/05/24/mehrere-usb-devices-am-raspberrypi-richtig-in-fhem-zuordnen/ )

Dann mal "Busware-CC1101" auf den GPIO-Port stecken. Ich habe dieses: https://www.amazon.de/dp/B00MW4CAZU/

Das machte dann schon mehr Ärger, da ist der gut dran, der alles genau dokumentierte.
Da sind Config-Dateien des Betriebssystems unter /boot anzufassen, das erinnert teilweise an magisches Zaubersalz: Es gibt einen Forenthread, der half mir - aber da wurden sich die Teilnehmer nicht wirklich einig, was denn nun die richtige Einstellungen seien. (Bei Bedarf suche ich den nochmal raus.)

Ach - und bei ZWave muss man alle Sensoren neu bekannt machen. Nicht der ganz große Zirkus mit abmelden/anmelden. Nur "set <SCC> hmPairForSec 600" und dann jeden Sensor dreimal Taste drücken ...

So nach und nach fällt auf, dass für verschiedene Funktionen (UWD als Beispiel) noch Perl-Bibliotheken fehlen. In den jeweiligen FHEM-Dokus wird dann der Weg der Installation über das CPAN-Archiv empfohlen. Ich persönlich halte das für langfristig falsch. Ich habe das jeweilige Perl-Modul (da heißt es anders, man muss da die zutreffende Perl-Lib finden) über "aptitude search" gesucht und danach via apt-get install <Modul> eingespielt.

Summa:
Es gibt keine Probleme zwischen Stretch und FHEM. Alles gut.

JuergenR · 28 Januar 2018, 23:03:01

ZitatEs gibt keine Probleme zwischen Stretch und FHEM. Alles gut.

Ich habe mein FHEM auf Stretch (Armbian cubietruck 4.13.16-sunxi) für meinen Cubietruck neu aufgesetzt und die bisherige FHEM Konfiguration übernommen.
Alles funktioniert wieder, aber
seitdem "verschluckt" der mplayer oder auch play oder auch mpv im Text2Speech immer die erste Sekunde bei jeder Ansage.
Beispiel: Text: "Hallo Otto" Ausgabe: knack "tto" knack.
Die Ausgabe erfolgt über den Analogausgang.
Das hört sich so an, als würde der Audioausgang erst mal eingeschaltet werden und in dieser Zeit läuft die Wiedergabe schon.
Bei zwei kurzen Texten hintereinander ist der zweite Text vollständig zu hören.

Ich bin ratlos.

Wernieman · 29 Januar 2018, 08:21:54

Das hört sich an, als ob Deine Soundhardware sich "schlafenlegt". Versuche dieses mal zu unterbieten ... kann Dir jetzt nur nicht sagen wo, weil ich keinen Cubi (keine Cubihardware) habe.

Thyraz · 29 Januar 2018, 10:08:19

Zitat von: curt am 30 Oktober 2017, 07:11:59
Ach - und bei ZWave muss man alle Sensoren neu bekannt machen. Nicht der ganz große Zirkus mit abmelden/anmelden. Nur "set <SCC> hmPairForSec 600" und dann jeden Sensor dreimal Taste drücken ...

hmPairForSec bei Zwave?

JuergenR · 29 Januar 2018, 13:49:34

ZitatDas hört sich an, als ob Deine Soundhardware sich "schlafenlegt".

So wird es sein.
Mit Jessie war das nicht so.

JuergenR · 31 Januar 2018, 15:07:46

Bernie_O aus dem armbian Forum wusste es von Fex:

https://forum.armbian.com/topic/4230-power-line-hum-on-lime2-with-mainline-kernel/?do=findComment&comment=31494

echo -1 > /sys/devices/platform/soc@01c00000/1c22c00.codec/cdc/pmdown_time

elbombo · 03 Februar 2018, 16:36:05

Bei mir läuft FHEM nicht unter Debian 9 und auch nicht auf dem Raspberry3 unter Raspian Stretch.
Folgende Geschichte:
1. Debian 9 in einer VM installiert
alle abhängigen Pakete nachinstalliert
FHEM installiert
-> MQTT läuft nicht

2. Debian Jessie installiert..
-> alles gut

Raspberry 3
1. Debian Strecht mit allen abhängigen Paketen installiert
-> MQTT läuft nicht

2. besorge mir gerade nen altes Rasbian und versuche mein Glück

elbombo · 03 Februar 2018, 17:23:38

Nachtrag:
Mit Raspian Jessie funzt FHEM auf Anhieb.
alte Config eingespielt.... alle MQTT Devices wieder da.

Also irgend etwas stimmt da nicht mit FHEM<->Debian 9
oder ich stelle mich zu doof an

schwatter · 03 Februar 2018, 17:46:36

Ich hatte auch das Problem. Geholfen hat

Code Auswählen

cpan -i Net::MQTT::Message

Wobei curt es oben im ersten Text langfristig für falsch hält. Vielleicht kann er dir mit den richtigen Paketen helfen.

pink99panther · 03 Februar 2018, 18:16:52

Ich Stufe mich bei Linux und FHEM ehr als noob ein, aber
bei mir läuft das auf einer VM mit Stretch und Mosquitto

The-Holgi · 05 Februar 2018, 17:31:09

Hallo,
bei mir hat der Umzug von Jessie auf Stretch problemlos geklappt.
Hatte unter Jessie ein backup erstellt und nach installation von Stretch und fhem wieder hergestellt.
Nur sendEmail funktionierte nicht mehr, unter Stretch ist es jetzt sendemail.

Gruss Holgi

maci · 06 Februar 2018, 15:45:57

Zitat von: curt am 30 Oktober 2017, 07:11:59
Zu meiner Einordnung: FHEM-Anfänger, Linux eher Profi.

...

So nach und nach fällt auf, dass für verschiedene Funktionen (UWD als Beispiel) noch Perl-Bibliotheken fehlen. In den jeweiligen FHEM-Dokus wird dann der Weg der Installation über das CPAN-Archiv empfohlen. Ich persönlich halte das für langfristig falsch. Ich habe das jeweilige Perl-Modul (da heißt es anders, man muss da die zutreffende Perl-Lib finden) über "aptitude search" gesucht und danach via apt-get install <Modul> eingespielt.

Ich denke das bedarf einer genaueren Erklärung. Mir wäre diese Methode sehr neu. Außerdem sind viele hier, keine Linux Profis.

Ich finde den Artikel in Summer sehr wichtig, denn es wird wahrscheinlich viele so gehen, dass beim Übernehmen der fhem.cfg viele Fehler auftauchen werden.
Bei vielen wird die Fhem Installation ein gewachsenes System sein. Immer wieder kommt etwas dazu.

Otto123 · 06 Februar 2018, 15:59:27

Zitat von: The-Holgi am 05 Februar 2018, 17:31:09
Nur sendEmail funktionierte nicht mehr, unter Stretch ist es jetzt sendemail.

Diesen genialen Streich gab es schon unter Jessie. Ist wohl auch etwas älter, es gab immer einen link von sendemail nach sendEmail. Das ist jetzt offenbar mal "bereinigt".

Ich habe mir aus der Doku (commandref) und meiner Installationshistorie eine Tabelle gemacht in der die debian Pakete (bevorzugt) oder die Per Module drin stehen. Ich installiere dann immer erstmal sorgsam nach dieser Liste.

Mit diesem Script kann man die Liste abfragen, ob installiert oder nicht.

Code Auswählen

bash scriptname.sh Paktename1 Paketname2 usw

Code Auswählen

# Eine von beiden Zeilen auskommentieren
#echo -n "cpan install " >notinstalled.sh
echo -n "apt-get install " >notinstalled.sh
while [ $# -gt 0 ]
do
# eine von beiden Zeilen auskommentieren
#perl -M$1 -e '' 2>/dev/null
dpkg -s $1 &> /dev/null

if [ $? -eq 0 ]; then
    echo $1" is installed!"
else
    echo $1" is not installed!"
    echo -n $1" " >>notinstalled.sh
fi
shift
done

Man kann ein frisches neues System hernehmen und seine Liste einfach installieren. Wenn dann was fehlt muss man suchen, ob das Paket umbenannt oder in andere integriert wurde. Manches wird auch nicht weiterentwickelt oder entwickelt sich dann irgendwie seitwärts.

Nur auf Fehlermeldungen von FHEM würde ich nicht vertrauen, im Zweifelsfall gibt es die nicht und es funktioniert einfach nicht.
Bis jetzt funktioniert bei mir alles unter Stretch.

Gruß Otto

Beta-User · 06 Februar 2018, 16:22:16

Zitat von: maci am 06 Februar 2018, 15:45:57
Ich denke das bedarf einer genaueren Erklärung. Mir wäre diese Methode sehr neu. Außerdem sind viele hier, keine Linux Profis.

Mal abgesehen von FHEM ist es in der Regel ratsam, möglichst alle Software-Pakete über die mitgelieferte Paketverwaltung zu installieren. Das war - soweit ich mich erinnern kann - gerade _der_ Große Vorzug, den Debian vor vielen anderen Linux-Distris hat.
Wer nicht eine Suchmaschine bemühen möchte, um das "richtige" .deb zu finden: https://forum.fhem.de/index.php/topic,61370.msg527931.html#msg527931, da gab es indirekt auch schon die Empfehlung, apt-get statt cpan zu nutzen...

Ansonsten: Warum sollte denn Stretch irgendwelchen Stress verursachen?
Jedenfalls hatte ich auf meinem hp ThinClient seit der Installation von Stretch (10/2017) auch keine Probleme, die im OS begründet gewesen wären.

Das einzige, was wirklich neu ist, ist der Umstand, dass systemd jetzt "schärfer" geschalten ist - die sich daraus ergebenden Herausforderungen sind aber schon an anderer Stelle beschrieben.

SCMP77 · 06 Februar 2018, 16:45:13

Zitat von: Beta-User am 06 Februar 2018, 16:22:16
Mal abgesehen von FHEM ist es in der Regel ratsam, möglichst alle Software-Pakete über die mitgelieferte Paketverwaltung zu installieren. Das war - soweit ich mich erinnern kann - gerade _der_ Große Vorzug, den Debian vor vielen anderen Linux-Distris hat.

Genauso ist es. In der Paketverwaltung sind Abhängigkeiten auch definiert.

Hat man ein Modul mittels CPAN eingebunden, fehlen diese Abhängigkeiten. Die Folge kann sein, dass dem so eingebundenen CPAN-Modul quasi durch ein Update der Boden unter den Füßen weggerissen wird. Die Folge davon ist, das es nach einem Update irgend etwas nicht mehr geht, die Suche nach dem Warum ist dann manchmal recht aufwendig, besonders dann, wenn man es erst nicht merkt. Ich hatte das auch schon mal, seitdem suche ich mir immer die entsprechenden Module aus der Debian-Paketverwaltung.