shutdown restart startet FHEM nicht neu

[Sammy51]

Da fällt mir unterwegs noch ein - eigentlich wäre es am effizientesten FHEM auf dem qnap zu installieren. Das unerstützt VMs und qnap liefert sogar ein Ubuntu Server als mehr oder weniger fertige VM.

Macht das Sinn
a) QNAP + VM
b) oder doch besser NUC evtl. mit neuer SSD Neuaufsetzen
c)  oder den besagten Raspi 3

Backup Files wurden offenbar abgelegt:

Code Auswählen Erweitern

FHEM-20201027_195045.tar.gz
FHEM-20201030_113836.tar.gz
FHEM-20201030_114800.tar.gz

Bzgl. rote Led beim HMLAN .. die leuchtete mal dauerhaft und das ding war nicht mehr verfügbar. Stromlos und wieder an half seitdem gings erstmal wieder.

[MadMax-FHEM]

Also die Entscheidung musst du (leider) selber treffen...

Es gibt (gefühlt) 1000+ Threads zu dem Thema: welche Plattform am besten für fhem u.ä.

Meine persönliche Meinung:

Bei VMs (ich mache viel damit):

wenn du dich da auskennst auch bzgl. einbinden von Laufwerken, Netzwerkeinstellungen etc. und das Ding eh dauernd läuft -> warum nicht.
wenn du eher Anfänger bzgl. VMs etc. bist würde ich erst mal "üben" und das auf später "vertagen". Weil sonst kommen zu den "üblichen" fhem-Problemen/-Fragen auch noch "Probleme" bzgl. VM-Plattform. Bzw. musst du ja erst mal sehen, ob das Problem an der Plattform oder an fhem liegt
(siehe: wenn du Ahnung hast   )

EDIT: eine ähnliche Meinung habe ich zu Docker. Ja es gibt Anwendungsfälle wo das sehr gut geeignet ist... Aber wenn ich dann immer hier höre: ich bin von fhem@PI auf Docker umgestiegen und nun geht das nicht mehr oder das ist schwierig und wie kriege ich den USB-Stick rein usw. Da frage ich mich: war denn nicht die Absicht, dass es danach leichter, einfacher, etc. geht. Naja bzgl. fhem und ähnlicher "Server-Anwendungen" bin ich (gut mag "altmodisch" sein   ) eher noch für "bare metal"


Bzgl. NUC:

naja so lange Linux drauf läuft ist es ja (sehr) ähnlich der PI Plattform
(@andere: jaja nicht hauen!   ich meine nur im Vergleich zu beispielsweise Windows   )


Raspberry PI:

naja die meisten Anleitungen sind halt für die Plattform PI zu finden/gemacht...
Du hast GPIO (auch wenn die zu nutzen nicht unbedingt immer sinnvoll ist   )...
...außer eben besagtes Funkmodul (und andere Funkmodule), wobei das ja auch per USB an einen NUC (und eine VM -> Ahnung haben   ) geht...

EDIT: gut und dann eben die üblichen Dinge USB, SD, ... die eben nicht so toll sind...

Viel Erfolg, Joachim

P.S.: ich habe 4 fhem auf PI laufen. 2 "produktiv" (1x mit SSD / 1x [noch] mit SD) und 2 Testsysteme...

[Wernieman]

Zu Glück  ist bei FHEM selber die Plattform ziemlich egal, solange Du die Hardware nicht direkt ansprichst (und es unter Linux läuft).

1.
Wenn Du dagegen direkt anzusprechende Hardware hast (GPIO (nicht empfehlenswert), USB-Sticks (Funkmodule) ....) ist VM und/oder Docker erstmal eine zusätzliche Hürde (Wie oben angesprochen). Wenn es dagegen reine Netzwerkmodule sind (CCUx, esp8266, diverse NetzGateways (z.B. ser2net....) dagegen macht es eine "Virtuallisierung (VM/Docker) eventuell sogar einfacher ....

Aber das ist nur meine Meinung

2.
Bezüglich VM auf NAS:
Habe mich hier dagegen entschieden. Abgesehen davon, das ich die Hardware habe, die NAS kann sich automatisch updaten und rebooten und es interessiert mich nicht. Zusätzlich können sich die Platten "schlafenlegen" und damit Stromsparender arbeiten, was bei VMs nicht mehr geht (laut I-Net-Berichten).

Aber das ist nur meine Meinung

3. Bezüglich Docker:
bei jeder Technik muß man sich erst einarbeiten. habe jetzt beruflich viel mit Docker zu tuen, aber sogar bei uns sind die Entwickler, welche eigentlich Beare-Metal "Freunde" sind, mittlerweile auf Produktiven Systemen auf Docker umgestiegen (oder wollen). Liegt aber mehr auch daran, das dann Entwicklersysteme=Produktivsystemen, was bei Beare-Matel meistens nicht zu gewährleisten ist. Auch ist es umkomplizierter (Wenn man es kann), dann mehrere Dienste Parallel zu fahren.

Hintergrund:
Dienst X will library LX nur in Version LZ1
Dienst Y will library LX nur in Version LZ2
Löse mal das Problem auf Beare-Metal. Lösbar aber bei jedem Update ein Logistisches Problem. Genau das eben bei Docker (und aufwendiger VM) eben nicht ...

Das der Micro-Service Gedanke noch andere Vorzüge hat (der FHEM-Docker-Container ist kein Micro-Service), ist hier nicht betrachtet.

Aber auch das ist nur meine Meinung

[Sammy51]

Hallo nochmal,

Vielen Dank für Eure Ausführungen, Hinweise und Tipps!!

Bin nicht sicher ob ich richtig schlussfolgere würde erstmal nochmal auf PI zurückgehen und mal getestete VM vom Qnpa schmeißen - HA-Bridge z.B. hab ich da vor Jahren nicht so recht hinbekommmen. Diesmal dann aber PI 3 statt PI1 - den ich vor längerm mal für das Homematic GPIO Modul besorgt hatte.

* Für Homematice hätte ich das GPIO Modul noch rumliegen - was spricht dagegen?
* Die erstmalige vorbereitung und Einrichtung mit USB Adapter daran scheint etwas aufwändiger - dafür ließe sich das natürlich besser positionieren. 
* Die sonstige Hardware ist nämlich in einem 19" Blechschrank  (obschon der Raspi theoretisch auch außen fixiert werden könnte).

Sehe ich das richtig das ich vom prinzip FHEM neu aufsetze nach einer Anleitung (z.B. eben auf dem raspi); dann das backup rücksichere (auch dafür habt ihr schon freundlich eine Anleitung genannt) - und dann (oder vorher) die USB Adaptter Enocean, Zwave anstecke (HMLAN ist ja eh im Lan und behält IP) und dann sollte es gehen wenn ich den Nuc abschalte und den Pi an?

Beste Grüße
Sammy

PS: Mit dem Fachmann sein ist so ein Problem ... war vor Jahren mal halbwegs fit mit dem Zeug dann konnte und musste ich Jahre nichts machen damit (Job, Familie, Haus ...) und ich bin fast wieder bei Null. Inzwischen gäbe es auch andere Systeme (Openhab z.B.) aber ob das besser ist ist unklar und manche Komponenten sind nicht mal eben neu anlernbar weil "tief verbaut". Außerdem wäre das noch deutlich mehr Aufwand. Also bleib ich wohl "hier" und bei FHEM (obwohl deutschsprachig kein Argument ist - aber wer weiß ob die Spezialisten anderswo genauso nett sind . Tuts ja auch in der Regel wenn Routinen usw. erstmal eingerichtet sind

[Sammy51]

shutdown restart  - klappt jetzt übrigens wieder (weiß leider nicht weshalb).

Erhalte beim Neustart aber u.a. folgende Fehlermeldungen (im logfile). Habt ihr eine Idee woran das liegen kann?
Wüßte nicht welche CUL das sein sollte. Gibt zwei per IP angebundene (HMLAN und HUE) und zwei USB via ID angebundene (enocean und zwave)

Im Voraus vielen Dank!
Beste Grüße
Sammy

Code Auswählen Erweitern

2020.11.02 21:07:47 3: Probing CUL device /dev/ttyS0
2020.11.02 21:07:47 1: PERL WARNING: can't getattr: Input/output error at ./FHEM/DevIo.pm line 586.
2020.11.02 21:07:47 1: CUL: Can't open /dev/ttyS0: Input/output error
2020.11.02 21:07:47 3: Probing CUL device /dev/ttyS1
2020.11.02 21:07:47 1: CUL: Can't open /dev/ttyS1: Input/output error
2020.11.02 21:07:47 3: Probing CUL device /dev/ttyS10
2020.11.02 21:07:47 1: CUL: Can't open /dev/ttyS10: Input/output error
2020.11.02 21:07:47 3: Probing CUL device /dev/ttyS11
2020.11.02 21:07:47 1: CUL: Can't open /dev/ttyS11: Input/output error
2020.11.02 21:07:47 3: Probing CUL device /dev/ttyS12
2020.11.02 21:07:47 1: CUL: Can't open /dev/ttyS12: Input/output error
2020.11.02 21:07:47 3: Probing CUL device /dev/ttyS13
2020.11.02 21:07:47 1: CUL: Can't open /dev/ttyS13: Input/output error
2020.11.02 21:07:47 3: Probing CUL device /dev/ttyS14
2020.11.02 21:07:47 1: CUL: Can't open /dev/ttyS14: Input/output error
2020.11.02 21:07:47 3: Probing CUL device /dev/ttyS15
2020.11.02 21:07:47 1: CUL: Can't open /dev/ttyS15: Input/output error
2020.11.02 21:07:47 3: Probing CUL device /dev/ttyS16
2020.11.02 21:07:47 1: CUL: Can't open /dev/ttyS16: Input/output error
2020.11.02 21:07:47 3: Probing CUL device /dev/ttyS17
2020.11.02 21:07:47 1: CUL: Can't open /dev/ttyS17: Input/output error
2020.11.02 21:07:47 3: Probing CUL device /dev/ttyS18
2020.11.02 21:07:47 1: CUL: Can't open /dev/ttyS18: Input/output error
2020.11.02 21:07:47 3: Probing CUL device /dev/ttyS19
2020.11.02 21:07:47 1: CUL: Can't open /dev/ttyS19: Input/output error
2020.11.02 21:07:47 3: Probing CUL device /dev/ttyS2
2020.11.02 21:07:47 1: CUL: Can't open /dev/ttyS2: Input/output error
2020.11.02 21:07:47 3: Probing CUL device /dev/ttyS20
2020.11.02 21:07:47 1: CUL: Can't open /dev/ttyS20: Input/output error
2020.11.02 21:07:47 3: Probing CUL device /dev/ttyS21
2020.11.02 21:07:47 1: CUL: Can't open /dev/ttyS21: Input/output error
2020.11.02 21:07:47 3: Probing CUL device /dev/ttyS22
2020.11.02 21:07:47 1: CUL: Can't open /dev/ttyS22: Input/output error
2020.11.02 21:07:47 3: Probing CUL device /dev/ttyS23
2020.11.02 21:07:47 1: CUL: Can't open /dev/ttyS23: Input/output error
2020.11.02 21:07:47 3: Probing CUL device /dev/ttyS24
2020.11.02 21:07:47 1: CUL: Can't open /dev/ttyS24: Input/output error
2020.11.02 21:07:47 3: Probing CUL device /dev/ttyS25
2020.11.02 21:07:47 1: CUL: Can't open /dev/ttyS25: Input/output error
2020.11.02 21:07:47 3: Probing CUL device /dev/ttyS26
2020.11.02 21:07:47 1: CUL: Can't open /dev/ttyS26: Input/output error
2020.11.02 21:07:47 3: Probing CUL device /dev/ttyS27
2020.11.02 21:07:47 1: CUL: Can't open /dev/ttyS27: Input/output error
2020.11.02 21:07:47 3: Probing CUL device /dev/ttyS28
2020.11.02 21:07:47 1: CUL: Can't open /dev/ttyS28: Input/output error
2020.11.02 21:07:47 3: Probing CUL device /dev/ttyS29
2020.11.02 21:07:47 1: CUL: Can't open /dev/ttyS29: Input/output error
2020.11.02 21:07:47 3: Probing CUL device /dev/ttyS3
2020.11.02 21:07:47 1: CUL: Can't open /dev/ttyS3: Input/output error
2020.11.02 21:07:47 3: Probing CUL device /dev/ttyS30
2020.11.02 21:07:47 1: CUL: Can't open /dev/ttyS30: Input/output error
2020.11.02 21:07:47 3: Probing CUL device /dev/ttyS31
2020.11.02 21:07:47 1: CUL: Can't open /dev/ttyS31: Input/output error
2020.11.02 21:07:47 3: Probing CUL device /dev/ttyS4
2020.11.02 21:07:47 1: CUL: Can't open /dev/ttyS4: Input/output error
2020.11.02 21:07:47 3: Probing CUL device /dev/ttyS5
2020.11.02 21:07:47 1: CUL: Can't open /dev/ttyS5: Input/output error
2020.11.02 21:07:47 3: Probing CUL device /dev/ttyS6
2020.11.02 21:07:47 1: CUL: Can't open /dev/ttyS6: Input/output error
2020.11.02 21:07:47 3: Probing CUL device /dev/ttyS7
2020.11.02 21:07:47 1: CUL: Can't open /dev/ttyS7: Input/output error
2020.11.02 21:07:47 3: Probing CUL device /dev/ttyS8
2020.11.02 21:07:47 1: CUL: Can't open /dev/ttyS8: Input/output error
2020.11.02 21:07:47 3: Probing CUL device /dev/ttyS9
2020.11.02 21:07:47 1: CUL: Can't open /dev/ttyS9: Input/output error

[MadMax-FHEM]

Das ist (vermutlich) der initialUsbCheck, der prüft alles mögliche durch.

Wenn du keine CUL hast bzw. die die du evtl. hast "fix definiert" sind, dann kannst du das auch deaktivieren:

Code Auswählen Erweitern


attr initialUsbCheck disable 1


Gruß, Joachim

[Sammy51]

Stimmt - das hat geholfen.
Darf ich andere Fehlermeldungen die Tage auch hier aufführen oder mach ich da besser mal ein neues Topic auf?

Beste Grüße
Sammy

[MadMax-FHEM]

Es ist dein Thread...

Aber wenn Wernieman oder ich da dann nicht helfen können, wird sich verm. kein anderer Helfer hierher verirren...

D.h. spät. dann wird es Zeit für einen neuen Thread...

Und andere mit einem Problem wie es jetzt kommt, werden dann halt verm. die Lösung nicht finden, da der Betreff ja nicht (mehr) passt...

Aber wenn das hier jetzt gelöst ist, trotzdem bitte ein [gelöst] vorne dran pappen...

Gruß, Joachim

[Sammy51]

EDIT: die Schlüssel unter /opt/fhem/.ssh nicht vergessen... Oder Skill in der Alexa-App "deaktivieren" und neu (mit den neu generierten) Schlüsseln verknüpfen (also nat. nur, wenn du das System wechselst/neu machst /  Aber ansinsten brauchst du ja auch kein Backup   )

Nutze noch historisch sftp zum Zugriff auf den Server mit FHEM. Die Backups kann ich so auch problemlos herunterholen.
Aber auf .ssh will filezilla / der Server mich nicht zugreifen lassen?!

Fehler:         Directory /opt/fhem/.ssh: permission denied


EDIT: Bezüglich des Homematic-Adapters "auf USB  CP2102 Adapter" - empfiehlt sich da ein kleines Gehäuse? Was z.B. ?

[amenomade]

Das ist normal. Nur der Besitzer kann auf seinem .ssh Verzeichnis zugreifen: dort liegen ggf die private Schlüssel, die niemand sonst sehen sollte. Das ist Sicherheit.

Du kannst nur mit "sudo" oder als root drauf, oder eh mit dem User fhem.

[MadMax-FHEM]

EDIT: Bezüglich des Homematic-Adapters "auf USB  CP2102 Adapter" - empfiehlt sich da ein kleines Gehäuse? Was z.B. ?

Also ich habe das hier: https://de.elv.com/strapubox-kunststoff-gehaeuse-usb-1-abs-56-x-20-x-12-mm-schwarz-101670

Geht aber ziemlich eng zu...

Und mal nachmessen, ob der Adapter wirklich auf 3,3V arbeitet.
Einer meiner (gut "Billig-China" ) war zwar auf 3,3V "eingestellt" hat aber trotzdem 5V geliefert.
Fand der HM-Funk-Chip nicht so lustig...

Beim nächsten dann nachgemessen, seitdem alles gut. Ca. 2 Jahre jetzt im "Testbetrieb"...

Gruß, Joachim

[Sammy51]

Danke für den Tipp und die Fotos - das Gehäuse schau ich mir an. Hab auch schon überlegt nach etwas größerem zu schauen und das USB Verlängerungskabel mit dessen Buchse direkt mit "einzubauen".

Bzgl. root Zugriff für die SSH Files .. per SFTP klappt das testweise nicht mit admin/root entweder gibts die Kennung nicht oder ich weiß das PW nicht mehr.

Beste Grüße
Sammy

[MadMax-FHEM]

Vermutlich ist auch bei dir ein root-Login nicht möglich/gesperrt...

Ist auf vielen Linux-Sytemen so.

Drum gibt es sudo...

Auch ein Sicherheits-Feature...

Besser für die lange Zukunft ist daher wohl sich auf der Console "zurechtzufinden"...
Dateien eben dort hin zu transferieren (dann wenn es sein muss   auch mittels "Klicki-Programm") wo eben ein normaler User des Systens "darf" und dann lokal mittels sudo in Bereiche wo eben ein norm. User nicht darf und dann Besitzverhältnisse wieder "gerade rücken"...

EDIT: statt lokal Console gibt es wohl auch "Klicki-Programme" z.B. MidnightCommander? Also "mc". Den kann man dann wohl auch mittels sudo starten (also sudo mc) und dann Dateien "rumschubbsen"... Kenne ich aber nur vom "Hörensagen"

Bei einer Standard-fhem-Installation:

Code Auswählen Erweitern


sudo chown fhem: Pfad/Datei


Gruß, Joachim

[Sammy51]

Bei meinem 2017er Modul sind die Pin nicht beschriftet. Passt das so zur Skizze?

Davon verbinde ich dann nur ub+, gnd und über Kreuz rx und tx mit dem usb Adapter?
Ferrit Ding an raspi Power Kabel und fertig?

[MadMax-FHEM]

Im Prinzip ja und so läuft das bei mir auch.

Für die "Zwischenplatine" mit den Kondensatoren und Widerständen war bei mir bzw. bei meiner Gehäusewahl kein Platz, daher hab ich das weggelassen.

Läuft.
Habe aber auch schon gelesen, dass das dann irgendwann nicht mehr tun kann/soll...

Daher "rate" ich an der Stelle mal nicht dazu

Wenn du Platz hast, dann ist es (verm.) besser die Zwischenplatine zu nutzen...

Wichtig: echt messen, dass der USB-Adapter wirklich mit 3,3V arbeitet!
(wie geschrieben, ich hab so schon ein Funkmodul "gegrillt"   )

Alles weitere sollte doch hier stehen: https://wiki.fhem.de/wiki/HM-MOD-RPI-PCB_HomeMatic_Funkmodul_f%C3%BCr_Raspberry_Pi

Und auch prüfen, welche FW drauf ist!
Ich habe auch schon gelesen, dass die Funkmodule die jetzt neu geliefert werden schon die neuesete FW drauf haben sollen (obwohl eq3 da eher immer "langsam" war   ).
Die geht nicht mit CUL_HM/fhem!
Also "downgraden" (oder falls doch noch die "ganz alte" FW drauf ist: upgraden). Welche FW usw. steht (sollte) in dem Wiki...

Gruß, Joachim