Hallo,
wenn es zu schön ist, dann macht man sich Probleme. Habe hier einen wunderbaren RasPi, der hat etwas Performanceprobleme. Also nichts einfacher als das, ein Umzug ist geplant. Wenn man das so liest sollte das kein Problem sein.
Stepp A
1. Ubuntu 16.06 in eine VM
2. FHEM in der VM installiert >> Oberfläche ist erreichbar im Browser
peter@fhemnew:~$ ps aux | grep [f]hem
peter@fhemnew:~$ telnet localhost 7072
Trying ::1...
Trying 127.0.0.1...
telnet: Unable to connect to remote host: Connection refused
peter@fhemnew:~$ sudo systemctl status fhem
● fhem.service - LSB: FHEM server
Loaded: loaded (/etc/init.d/fhem; bad; vendor preset: enabled)
Active: active (exited) since Sa 2018-04-07 09:56:45 CEST; 6s ago
Docs: man:systemd-sysv-generator(8)
Process: 1435 ExecStart=/etc/init.d/fhem start (code=exited, status=0/SUCCESS)
Apr 07 09:56:44 fhemnew systemd[1]: Starting LSB: FHEM server...
Apr 07 09:56:44 fhemnew fhem[1435]: Starting fhem...
Apr 07 09:56:45 fhemnew systemd[1]: Started LSB: FHEM server.
peter@fhemnew:~$ sudo journalctl -u fhem.service
-- Logs begin at Sa 2018-04-07 09:37:07 CEST, end at Sa 2018-04-07 09:57:15 CEST. --
Apr 07 09:37:12 fhemnew systemd[1]: Starting LSB: FHEM server...
Apr 07 09:37:13 fhemnew fhem[1206]: Starting fhem...
Apr 07 09:37:13 fhemnew systemd[1]: Started LSB: FHEM server.
Apr 07 09:56:37 fhemnew systemd[1]: Stopping LSB: FHEM server...
Apr 07 09:56:37 fhemnew fhem[1407]: Stopping fhem...
Apr 07 09:56:37 fhemnew systemd[1]: fhem.service: Control process exited, code=exited status=1
Apr 07 09:56:37 fhemnew systemd[1]: Stopped LSB: FHEM server.
Apr 07 09:56:37 fhemnew systemd[1]: fhem.service: Unit entered failed state.
Apr 07 09:56:37 fhemnew systemd[1]: fhem.service: Failed with result 'exit-code'.
Apr 07 09:56:44 fhemnew systemd[1]: Starting LSB: FHEM server...
Apr 07 09:56:44 fhemnew fhem[1435]: Starting fhem...
Apr 07 09:56:45 fhemnew systemd[1]: Started LSB: FHEM server.
FHEM ist nicht mehr im Browser erreichbar und ich habe keine Ideen
Was könnte ich vergessen haben?
Danke schonmal vorab für das Mitgrübeln
Peter
Stepp B
1. Backup erstellen
2. Rüberkopieren und entpacken
Verzweiflung macht sich breit
Hallo Peter,
die Ursache dafuer findest Du im Log von fhem.
Gruss Helmut
Sorry,
hätte ich was gefunden, dann hätte ich mich für die Frage nicht angemeldet.
Irgendeinen wirklichen Hinweis nach was man suchen sollte?
Dass es Logs gibt weis ich.
Peter
Hallo Peter,
da wird schon noch etwas fehlen. Stell doch bitte die fhem-Logdatei hier 'rein (/opt/fhem/log/fhem-2014-08.log),
vorzugsweise als Dateianhang, sonst bitte in code-Tags.
Gruss Helmut
Zitat von: Peteruser am 07 April 2018, 12:18:39
Sorry,
hätte ich was gefunden, dann hätte ich mich für die Frage nicht angemeldet.
Irgendeinen wirklichen Hinweis nach was man suchen sollte?
Dass es Logs gibt weis ich.
Peter
Nur weil Du nichts siehst/erkennst, heißt es ja noch lange nicht das andere nicht doch was sehen.
Hallo,
erstmal danke an euch beiden!
Ich sehe das erstmal so, dass FHEM zickig ist was die Schnittstellen angeht. Werde jetzt erstmal die MQTT und Homematic Fehlermeldungen (versuchen) geradezuziehen. Wenn dann noch Probleme vorhanden sind, dann gibt es das Log.
Hatte bis jetzt noch nichts in dieser Richtung gelesen, ist aber nun mein Weg.
Grüße Peter
Hallo,
der Ansatz scheint schonmal richtig zu sein. Alles was man vorher auf der anderen Maschine an Tools aktiv hatte, muss auch auf der neuen installiert werden. Wenn das nicht so ist, dann kann evtl. FHEM als WebFrontend (oder überhaupt) nicht starten.
Bis zur Verwendbarkeit der neuen Maschine scheint es aber trotzdem noch ein weiter Weg.
Würde mich über Abkürzungen freuen.
Peter
Hallo Peter,
so richtige Abkuerzungen kann ich Dir nicht anbieten.
Wenn Du MQTT in Ordnung bringst, bist Du schon den groessten Teil Deiner Fehlermeldungen los.
https://wiki.fhem.de/wiki/MQTT_Einf%C3%BChrung#Installation_in_FHEM
Was mir weiter auffaellt, ist die vermutlich geaenderte ID des nanoCUL1. Gehe hier nach der Anleitung im Wiki vor.
https://wiki.fhem.de/wiki/Selbstbau_CUL#Hinweise_zum_Betrieb_mit_FHEM
Ob die Probleme mit dem HMCCU, beziehungsweise dem CCURPC aus der fehlenden Funktionalitaet des nanoCUL1
herruehren, kann ich mangels Masse nicht beurteilen. Moeglich, dass Du hier noch perl-Module nachinstallieren musst
oder die Ursache doch eine ganz andere ist.
Zur Vereinfachung der Installation des Debian-Systems sieh Dir diesen Forum-Artikel an --> dpkg --{g|s}et-selections
https://forum.fhem.de/index.php/topic,85011.msg773288.html#msg773288
Aber insgesamt sieht die Situation doch gar nicht so schlecht aus. Also viel Erfolg.
Gruss Helmut
Hallo,
das mit der MQTT Geschichte hatte ich schon losgesetzt, leider ohne Erfolg.
Der nanoCUL1 ist eh nur Geschichte, Homematic ist mit CCU2 und Max! mit dem Cube angeschlossen. Werde da noch aus zum Üben noch etwas Buxfixen, für die Zukunft sehe ich aber einen Neuanfang als die effektivere Variante. Den "Alten" noch parallel laufen lassen und eine neue saubere Instanz dann für das weitere. Möchte hier aber noch warten bis 18.04 da ist, dann habe ich den Schritt auch gleich mit abgedeckt.
Erstmal DANKE an alle die sich Gedanken gemacht haben, ganz besonders dir helmut! Immerhin hast du mich durch die Abfrage bezüglich Log öffenlich stellen motiviert selber erstmal so viel wie möglich selber wegzuräumen und das war dann ein grösserer Sprung als gedacht in Richtung Lösung.
Umschön ist aus meiner Sicht, dass bei einem Backup auf einen anderen Rechner so viele Stolpersteine vorhanden sind.
Grüße Peter
Zitat von: Peteruser am 08 April 2018, 14:16:54
das mit der MQTT Geschichte hatte ich schon losgesetzt, leider ohne Erfolg.
Hallo Peter,
dann pruefe doch mal, ob das geklappt hat. Ein "cpan -l|grep -i mqtt" als root liefert mir
Net::MQTT::Message 1.163170
Net::MQTT::TopicStore 1.163170
Net::MQTT::Constants 1.163170
Net::MQTT::Simple 1.21
Net::MQTT::Simple::SSL undef
Net::MQTT::Message::PubRec 1.163170
Net::MQTT::Message::Disconnect 1.163170
Net::MQTT::Message::UnsubAck 1.163170
Net::MQTT::Message::Connect 1.163170
Net::MQTT::Message::Subscribe 1.163170
Net::MQTT::Message::ConnAck 1.163170
Net::MQTT::Message::PubAck 1.163170
Net::MQTT::Message::PubComp 1.163170
Net::MQTT::Message::PingResp 1.163170
Net::MQTT::Message::PubRel 1.163170
Net::MQTT::Message::PingReq 1.163170
Net::MQTT::Message::Publish 1.163170
Net::MQTT::Message::JustMessageId 1.163170
Net::MQTT::Message::SubAck 1.163170
Net::MQTT::Message::Unsubscribe 1.163170Zitat von: Peteruser am 08 April 2018, 14:16:54
Den "Alten" noch parallel laufen lassen und eine neue saubere Instanz dann für das weitere.
Eine gute Idee.
Zitat von: Peteruser am 08 April 2018, 14:16:54
Immerhin hast du mich durch die Abfrage bezüglich Log öffenlich stellen motiviert selber erstmal so viel wie möglich selber wegzuräumen.
Klassenziel erreicht ;)
Zitat von: Peteruser am 08 April 2018, 14:16:54
Umschön ist aus meiner Sicht, dass bei einem Backup auf einen anderen Rechner so viele Stolpersteine vorhanden sind.
... die Du alle schon einmal aus dem Weg geraeumt hast. Und das ist das Gute daran: Du lernst mit jedem Mal dazu
und hast im Ergebnis keine Blackbox sondern etwas, dessen Ergebnis Du Dir erarbeitet hast. Besonderheiten
schreibe ich mir fuer das naechste Mal auf.
Gruss Helmut