Probleme nach Restart von FHEM (verursacht vom USB)

Begonnen von uxtuner, 12 Dezember 2017, 17:09:14

Vorheriges Thema - Nächstes Thema

uxtuner

Hallo,

war gestern am verzweifeln, da ich nach einem "shutdown restart" nicht mehr auf die FHEM Oberfläche zugreifen konnte.
Auch "service fhem stop" auf der Kommandozeile hat nicht mehr funktioniert, den Prozess mußte ich hart mit "kill -9" beenden.

Nach mehrmaligen deinstallieren/installieren mit blanker Konfig von FHEM (ohne das sich irgendwas geändert hätte) bin ich dann auf die Lösung gekommen:
Vor 2 Tagen hatte ich den EBUS über USB an den PC angebunden. Dass der EBus viele Daten liefert war mir schon aufgefallen aber in meinem Fall hat er FHEM komplett lahmgelegt. Erst nachdem ich den USB Stecker abgezogen hatte lief alles wieder ganz normal.

Vielleicht hilft die Info jemanden in der gleichen Situation.

Schön wäre, wenn man FHEM bei Gelegenheit überarbeiten bzw. auf diesen Punkt prüfen könnte ...
Viele Grüße
  Uwe

Intel NUC (VDR & FHEM), QNAP TS-453, OneWire (Temp. Sensor, 8-fach Schalter, Hub, Controller), Ebus (Wolf CGW-2, ISM7i), Fibaro (Flood Sensor, Wall Plug, 4 in 1 Sensor), Qubino (Flush 1D), Shelly (Plug S, H&T, 2.5, 1 PM), Tado (Thermostat V3+)

nias

klingt eher nach Problemen mit dem "usb" Befehl wenn create/scan automatisch beim Start ausgeführt wird.
Steht denn in deiner fhem.cfg etwas in der Art:

define initialUsbCheck notify global:INITIALIZED usb create

wenn ja, dann nimm's raus...

Otto123

Hi,

attr initialUsbCheck disable 1über die FHEM Oberfläche wäre die supportete Variante  :D

Gruß Otto
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

MadMax-FHEM

Zitat von: Otto123 am 20 Dezember 2017, 21:41:24
Hi,

attr initialUsbCheck disable 1über die FHEM Oberfläche wäre die supportete Variante  :D

Gruß Otto

Geht aber nur, wenn Zugriff über die Weboberfläche gegeben ist/wäre ;)

Und nachdem sich der Service auch nicht mehr beenden ließ, ist auch evtl. kein "Durchkommen" per Telnet... ;)

Gruß, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

Otto123

Hallo Joachim,

klar, ich wollte das nur für allgemeine Leser ergänzen.
Löschen wie von nias empfohlen finde ich eben doof. Aber bei einer vollen fhem.cfg bleibt fast nichts anderes übrig.
Ich mache immer
echo 'attr initialUsbCheck disable 1' >> /opt/fhem/fhem.cfgunmittelbar nach der Installation. Ich habe auch schon immer mal empfohlen, dies quasi als Standard in der Quelle zu setzen.
Denn meiner Meinung nach, bringt es bei mehr Benutzern Probleme als bei Einigen Nutzen.

Gruß Otto
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

MadMax-FHEM

Zitat von: Otto123 am 21 Dezember 2017, 11:27:04
Hallo Joachim,

klar, ich wollte das nur für allgemeine Leser ergänzen.
Löschen wie von nias empfohlen finde ich eben doof. Aber bei einer vollen fhem.cfg bleibt fast nichts anderes übrig.
Ich mache immer
echo 'attr initialUsbCheck disable 1' >> /opt/fhem/fhem.cfgunmittelbar nach der Installation. Ich habe auch schon immer mal empfohlen, dies quasi als Standard in der Quelle zu setzen.
Denn meiner Meinung nach, bringt es bei mehr Benutzern Probleme als bei Einigen Nutzen.

Gruß Otto

War mir schon klar! ;)

Hat das eigentlich überhaupt jemand in benutzung? ;)

Frosch Fescht!

Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)