[GELÖST]: FHEM startet nach Stromausfall nicht mehr

Begonnen von FHEM_newbie, 05 Januar 2021, 00:25:10

Vorheriges Thema - Nächstes Thema

FHEM_newbie

Nach einem Stromausfall startet mein FHEM nicht mehr. Mit der Minimalkonfiguration starten funktioniert perfekt. Ich habe jetzt mit "attr global logfile -" gestartet und dann kommt folgendes:


sudo /usr/bin/perl /opt/fhem/fhem.pl /opt/fhem/fhem.cfg
2021.01.05 00:18:14 1: Including /opt/fhem/fhem.cfg
2021.01.05 00:18:14 3: telnetPort: port 7072 opened
2021.01.05 00:18:14 3: WEB: port 8083 opened
2021.01.05 00:18:14 3: WEBphone: port 8084 opened
2021.01.05 00:18:14 3: WEBtablet: port 8085 opened
2021.01.05 00:18:14 2: eventTypes: loaded 3458 events from ./log/eventTypes.txt
2021.01.05 00:18:14 3: Opening TCM_ESP3_0 device /dev/ttyAMA0
2021.01.05 00:18:14 3: Setting TCM_ESP3_0 serial parameters to 57600,8,N,1
2021.01.05 00:18:14 3: TCM_ESP3_0 device opened
2021.01.05 00:18:14 3: Opening FritzBox device 192.168.178.1:1012
2021.01.05 00:18:15 3: modbus_rtu_network: defined as /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AC01QB2V-if00-port0@19200,8,E,1
2021.01.05 00:18:15 3: Proxon: defined with id 41, interval 60, protocol RTU, mode master
2021.01.05 00:18:15 3: Proxon: RegisterAtIODev called from SetIODev registers Proxon at modbus_rtu_network with id 41, MODE master, PROTOCOL RTU
2021.01.05 00:18:17 2: EnOcean Cryptographic functions are not available.
2021.01.05 00:18:17 2: EnOcean XML functions available.
2021.01.05 00:18:17 3: Opening TCM_ESP2_0 device /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_AH05TOC7-if00-port0
2021.01.05 00:18:17 3: Setting TCM_ESP2_0 serial parameters to 57600,8,N,1
2021.01.05 00:18:17 3: TCM_ESP2_0 device opened
2021.01.05 00:18:18 3: Wechselrichter: Defined with URL http://192.168.178.35/api/dxs.json?dxsEntries=16780032&dxsEntries=33556736&dxsEntries=33555201&dxsEntries=33555202&dxsEntries=33555203&dxsEntries=33555457&dxsEntries=33555458&dxsEntries=33555459&dxsEntries=33555713&dxsEntries=33555714&dxsEntries=33555715&dxsEntries=67109120&dxsEntries=251658754&dxsEntries=251658753&dxsEntries=251658496&dxsEntries=251658496&dxsEntries=83887872&dxsEntries=33556736&dxsEntries=83888128&dxsEntries=33556226&dxsEntries=33556229&dxsEntries=33556238&dxsEntries=33556228&dxsEntries=33556227&dxsEntries=83886336&dxsEntries=83886592&dxsEntries=83886848 and interval 60 featurelevel 6
2021.01.05 00:18:19 3: TABLETUI: new ext defined infix:ftui/: dir:./www/tablet/:
2021.01.05 00:18:19 3: Registering HTTPSRV TABLETUI for URL /ftui   and assigned link ftui/ ...
2021.01.05 00:18:20 3: DLNARenderer: DLNA Renderer v2.0.7
2021.01.05 00:18:21 1: PERL WARNING: Subroutine import redefined at FHEM/Meta.pm line 654, <$fh> line 2023.
2021.01.05 00:18:21 1: PERL WARNING: Subroutine InitMod redefined at FHEM/Meta.pm line 670, <$fh> line 2023.
2021.01.05 00:18:21 1: PERL WARNING: Subroutine Load redefined at FHEM/Meta.pm line 706, <$fh> line 2023.
2021.01.05 00:18:21 1: PERL WARNING: Subroutine SetInternals redefined at FHEM/Meta.pm line 878, <$fh> line 2023.
2021.01.05 00:18:21 1: PERL WARNING: Subroutine Get redefined at FHEM/Meta.pm line 901, <$fh> line 2023.
2021.01.05 00:18:21 1: PERL WARNING: Subroutine GetModuleSourceOrigin redefined at FHEM/Meta.pm line 919, <$fh> line 2023.
2021.01.05 00:18:21 1: PERL WARNING: Subroutine GetKeywordDesc redefined at FHEM/Meta.pm line 940, <$fh> line 2023.
2021.01.05 00:18:21 1: PERL WARNING: Subroutine ModuleIsCore redefined at FHEM/Meta.pm line 956, <$fh> line 2023.
2021.01.05 00:18:21 1: PERL WARNING: Subroutine ModuleIsInternal redefined at FHEM/Meta.pm line 961, <$fh> line 2023.
2021.01.05 00:18:21 1: PERL WARNING: Subroutine GetModuleFilepath redefined at FHEM/Meta.pm line 993, <$fh> line 2023.
2021.01.05 00:18:21 1: PERL WARNING: Subroutine ModuleIsPerlCore redefined at FHEM/Meta.pm line 1049, <$fh> line 2023.
2021.01.05 00:18:21 1: PERL WARNING: Subroutine __CopyMetaToInternals redefined at FHEM/Meta.pm line 1085, <$fh> line 2023.
2021.01.05 00:18:21 1: PERL WARNING: Subroutine __PutMetadata redefined at FHEM/Meta.pm line 1096, <$fh> line 2023.
2021.01.05 00:18:21 1: PERL WARNING: Subroutine __GetMetadata redefined at FHEM/Meta.pm line 1121, <$fh> line 2023.
2021.01.05 00:18:21 1: PERL WARNING: Subroutine __GenerateKeywordsFromSupportCommunity redefined at FHEM/Meta.pm line 2426, <$fh> line 2023.
2021.01.05 00:18:21 1: PERL WARNING: Subroutine __GetPackages redefined at FHEM/Meta.pm line 2521, <$fh> line 2023.
2021.01.05 00:18:21 1: PERL WARNING: Subroutine __GetMaintainerdata redefined at FHEM/Meta.pm line 2556, <$fh> line 2023.
2021.01.05 00:18:21 1: PERL WARNING: Subroutine __GetSupportForum redefined at FHEM/Meta.pm line 2770, <$fh> line 2023.
2021.01.05 00:18:21 1: PERL WARNING: Subroutine __GetUpdatedata redefined at FHEM/Meta.pm line 2956, <$fh> line 2023.
2021.01.05 00:18:21 1: PERL WARNING: Subroutine __SetXVersion redefined at FHEM/Meta.pm line 3206, <$fh> line 2023.
2021.01.05 00:18:22 3: AutoShuttersControl (myASControl) - defined
2021.01.05 00:18:22 3: Zisterne: Defined with URL http://192.168.178.52/ and interval 60 featurelevel 6
2021.01.05 00:18:22 1: mqtt2: Can't open server port at 1883: Address already in use. Exiting.



Jemand einen guten Tipp? Ich bin mit meinem Linux Latein am Ende...  Liegt es nur am mqtt2 (hier hatte FHEM immer für jedes MQTT2 device nochmals einen Server angelegt, hat aber alles problemlos funktioniert)? Oder machen die PERL Warnings auch schon was aus?

Ich wäre sehr dankbar wenn das Ding irgendwie wieder laufen würde. Oder am besten neu aufsetzen und die fhem.cfg vorher sichern und wieder wieder einspielen?

LuckyDay

mqtt2: Can't open server port at 1883: Address already in use. Exiting.

läuft bei dir auch noch ein mosquitto früher ???

fakt ist wenn der mqtt2 server in Fhem konfiguriert ist und der port nicht frei, beendet sich Fhem!

FHEM_newbie

Ich wüsste nicht dass ich jemals was mit mosquitto gemachr hätte. Habe erst letztens ein paar Tasmota Stekdosen neu reingenommen aber gleich mit MQTT2. Wie kann ich den mosquitto oder was auch immer auf 1883 läuft stoppen?

FHEM_newbie

So jetzt habe ich es geschafft den moquitto Prozess (warum auch immer der lief?) zu killen und FHEM zu starten. Soweit alles gut aber wenn ich den Raspberry neu starte ist das Problem (mosquitto wieder da). Wie kann man den aus dem Autostart (sorry, bin Windows geschädigt) bekommen?

herrmannj

Bei der Fülle der von Dir gelieferten Informationen weiß ich gar nicht wo ich da anfangen soll ...

Eventuell hier https://lmgtfy.app/?q=mosquitto+stoppen


FHEM_newbie

Das war jetzt wohl ironisch zu verstehen...
Wie gesagt der " mqtt2: Can't open server port at 1883: Address already in use. Exiting." verursacht das Problem. Wenn ich den laufenden mosquitto Prozess mittels kill stoppe und FHEM dann manuell starte funktioniert alles. Starte ich den Raspberry dann neu, habe ich wieder dasselbe Problem. Keine Ahnung ob das Problem schon länger bestand und jetzt nur durch den Stromausfall aufgedeckt wurde.
Welche Infos würden denn noch weiterhelfen? Wie gesagt MQTT2 legt für jedes Device einen extra Server an, der nicht gelöscht werden kann. Ist das normal?
Sollte ich evtl. mal die ganzen MQTT2 devices einschliesslich Server löschen?

KölnSolar

ZitatWenn ich den laufenden mosquitto Prozess mittels kill stoppe und FHEM dann manuell starte funktioniert alles.
ZitatIch wüsste nicht dass ich jemals was mit mosquitto gemachr hätte.
Wir auch nicht, aber offensichtlich hast Du etwas gemacht. Das musst Du nun wieder ändern. Sonst
Zitat
fakt ist wenn der mqtt2 server in Fhem konfiguriert ist und der port nicht frei, beendet sich Fhem!
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

FHEM_newbie

Schon klar, aber wenn ich nun mal nicht weiß warum oder was den mosqquitto Prozeß startet, kann ich es halt auch nicht ändern.
Wie gesagt ich habe die MQTT2 devices erst vor ein paar Wochen hinzugefügt und das direkt über MQTT2 und niemals über mosquitto.

Den MQTT2 Server neu zu definieren hat auch nichts gebracht...

viegener

Zitat von: FHEM_newbie am 05 Januar 2021, 12:01:25
Schon klar, aber wenn ich nun mal nicht weiß warum oder was den mosqquitto Prozeß startet, kann ich es halt auch nicht ändern.
Wie gesagt ich habe die MQTT2 devices erst vor ein paar Wochen hinzugefügt und das direkt über MQTT2 und niemals über mosquitto.

Den MQTT2 Server neu zu definieren hat auch nichts gebracht...

Ich vermute die Information die hier hilfreich für Dich wäre ist, wie hast Du mosquitto aufs system gebracht. Denn wenn Du einen mosquitto-Prozess killen kannst, ist mosquitto installiert und wird vermutlich automatisch vom System gestartet.

Hintergrund: der FHEM-MQTT server ist nicht der mosquitto prozess - also läsuft noch ein anderer MQTT-Broker

MQTT läuft standardmässig mit port 1883 und der kann eben nur einmal vergeben werden

Also am besten klören wir mosquitto aufs System gekommen ist und ob es da noch benötigt wird.
Wenn nicht benötigt mosquitto wieder entfernen (oder zumindest nicht mehr starten oder zur Not den Port ändern)

Kein Support über PM - Anfragen gerne im Forum - Damit auch andere profitieren und helfen können

Otto123

#9
Zitat von: FHEM_newbie am 05 Januar 2021, 12:01:25
Wie gesagt ich habe die MQTT2 devices erst vor ein paar Wochen hinzugefügt und das direkt über MQTT2 und niemals über mosquitto.
Nur so als Idee: Die Neuen mit tuya Convert umgeflashed und diesen Server dafür genommen? Dann war Weihnachten :)

Da Du ja mosquitto nicht brauchst - einfach entfernen?
sudo apt purge mosquitto
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

FHEM_newbie

Danke Otto! Das war die exakt die richtige Idee! Hatte sogar deine Anleitung dazu benutzt. Vielen Dank!
Wenn ich mit systemctl list-units schaue, habe ich einen Eintrag:   mosquitto.service            loaded active exited    LSB: mosquitto MQTT v3.1 message broker

Jetzt ist nur noch die Frage wie ich den mosqquitto oder das ganze Tuya-Convert wieder runterbekomme...
Und ja, ich weiß man hätte das nicht über den aktiven FHEM Raspberry machen sollen, jetzt weiß ich auch wieso.

FHEM_newbie

Super auch dafür nochmals besten Dank!

ZitatDa Du ja mosquitto nicht brauchst - einfach entfernen?
Code: [Auswählen]

sudo apt purge mosquitto

Danke auch an die anderen, die mit Tipps gegeben haben.

Beta-User

Wenn Tuya-Convert die "Ursache" war: Bitte eine neue SD-Karte für FHEM aufsetzen. mosquitto ist mAn. noch der geringste Teil dessen, was da installiert wird...

(Und bei diesem Linux-"Kenntnisstand" würde ich sowieso davon ausgehen, dass üben eine gute Idee ist und bei der Gelegenheit evtl. noch eine GUI entsorgt werden kann... Oder ist es falsch, wenn ich unterstelle, dass du kein Raspian-lite (oder wie das aktuell eben heißt) gewählt hast, sondern die "Luxusvariante" mit GUI und eventuell sogar noch samba...?)
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

Otto123

Zitat von: FHEM_newbie am 05 Januar 2021, 12:22:19
Jetzt ist nur noch die Frage wie ich den mosqquitto oder das ganze Tuya-Convert wieder runterbekomme...
Und ja, ich weiß man hätte das nicht über den aktiven FHEM Raspberry machen sollen, jetzt weiß ich auch wieso.
Ich habe es in meinem Artikel nochmal rot hingeschrieben :)

Ich würde es wie Beta-User sagt machen. Backup von FHEM, nochmal schauen welche System Module / Pakete man installiert hat. Dann neues System (neue SD Card) und restore üben :)  Es geht niemals so entspannt wie jetzt :)
Notizen machen!
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

Beta-User

Falls das nicht angekommen sein sollte: Es mag pointiert formuliert sein, aber falls du dich entscheidest, das bei dem einen purge zu belassen, ist das nur die halbe Miete.

Schau einfach mal in das script https://github.com/ct-Open-Source/tuya-convert/blob/master/install_prereq.sh rein, was da alles installiert wird, und v.a., was die Packete im einzelnen tun _können_. Da die Empfehlung auch von seiten der Macher die ist, das auf einer separaten Karte zu veranstalten, glaube ich z.B. nicht unbedingt daran, dass z.B. dnsmasq nach Gebrauch auch wieder ausgeschaltet wird...
(Wobei es uU. schon eine gute Idee sein könnte, den Pi zum AP für das ganze Heimautomatisierungs-WLAN-Geraffel zu machen, aber das hattest du vermutlich bisher nicht vor...).

Übrigens @Otto: Super Glaskugel, die du da vor dir liegen hast ;D .
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors