[gelöst] Fhem crasht nach 30 Sekunden

Begonnen von oldscout, 05 Juli 2022, 06:47:30

Vorheriges Thema - Nächstes Thema

KölnSolar

Ich kann es zwar nicht wirklich glauben, dass freezemon der Verursacher sein soll, zumal Du "glaubst" freezemon deaktiviert zu haben.

ZitatDas Modul habe ich schon ewig deaktiviert in der Config drin stehen gelassen.
Wie hast Du es deaktiviert ? (Ich frage, um ggfs. freezemon zu korrigieren)


Zitat von: betateilchen am 15 Juli 2022, 09:23:41
Zumindest für Nutzer der configDB geht das ab heute:

https://forum.fhem.de/index.php/topic,128400.0.html
Versteh ich nicht. Ein delete devicename löscht doch ein device(dauerhaft nach save config). ???
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

betateilchen

Zitat von: KölnSolar am 15 Juli 2022, 10:59:50
Versteh ich nicht. Ein delete devicename löscht doch ein device(dauerhaft nach save config). ???

Du hast das eigentliche Problem nicht erkannt.

Das "delete devicename" funktioniert nur, wenn FHEM läuft.
Wenn irgendein device aber den FHEM Start verhindert, kommst Du nicht soweit, ein device löschen zu können.

-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

KölnSolar

Ah, jetzt.

Die fhem.cfg editiert man. 8) (duck und weg)
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

Beta-User

#33
Wenn man ein Problem mit einem bestimmten Modul hat, benennt man am einfachsten die Moduldatei um...

(Trotzdem ist das eine sinnvolle Ergänzung von configDB!).

Hier scheint (einmal mehr) PRESENCE in der ping-Variante das Problem gewesen zu sein. Vielleicht sollte man den betreffenden Maintainer mal anpingen, ob er sich nicht den Vorschlag mal näher ansehen will, den martinp876 zu diesem Thema vor längerem mal gemacht hatte?
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

oldscout

Hallo,
@KölnSolar: Das Deaktivieren wurde mit "set inactive.." gemacht.
Ja, möglicherweise war/ist es ein Zusammenspiel mit Ping-presence, habe davon einige in der Config.
@betateilchen: danke für die Info mit der Deaktivierungsmöglichkeit, schau ich mir an.

Gruß und schöne Woche.

FHEM 5.8 auf Intel Celeron CPU
HM-.*, 1-Wire DS18B20, FritzDect 200, HMLAN, HMUSB, Arduino Uno, ESP8266, Enigma2, FB7490, MySql-DB,TP-Link HS100, RaspiCCU

KölnSolar

ZitatDas Deaktivieren wurde mit "set inactive.." gemacht.
Ich habe es mir gedacht. Beim Boot ist das ja "nur" ein reading, das auf den Wert gesetzt wird. Ein aktives set findet nicht statt. Ich bin mir nicht sicher, ob das in anderen Modulen "besser" berücksichtigt wird.  :-[
Besser ist die Verwendung des Attributs disable. Das deaktiviert das device "dauerhaft".

Kannst Du das mal ausprobieren ?

Grüße Markus

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