FHEM stürzt immer um 20 Uhr ab .....

Begonnen von Edi77, 05 April 2016, 07:46:18

Vorheriges Thema - Nächstes Thema

Edi77

Ich komme einfach nicht drauf.


2016.04.04 19:59:54 3: SMAspot called
2016.04.04 20:00:08 3: SMAspot called
2016.04.04 20:00:24 3: SMAspot called
2016.04.04 20:00:39 3: SMAspot called
2016.04.04 20:00:54 3: SMAspot called
recv() returned an error: 104
send() returned an error: 107


Danach tut sich nichts mehr

Hat vielleicht jemand eine Idee?
Master FHEM 6 als VM auf ESX Ubuntu 20.04 LTS mit MAXCube/MAX!/FS20|TabletUI|Flightradar|Tasmota|TTN Lora|CCU3 HomematicIP|RPi mit GammaScout|MQTT EasyESP 8266|LuftdatenInfo|deCONZ HUEDev|probemon|Siemens Logo|P4D|3D PRINTER RAISE3D

KölnSolar

smaspot kenn ich nicht, aber sehr speziell und Deine Frage vermutlich besser unter Solaranlagen aufgehoben. Scheint mir nicht an fhem zu liegen, aber

Wie ist smaspot(Bluetooth) in fhem eingebunden ?

Was passiert ohne smaspot ?

Kannst Du verbose 5 einstellen ?

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

Edi77

Hallo,

Habe leider nicht wirklich was rausfinden können


2016.04.11 19:56:35 5: Triggering powerzaehler (0 changes)
2016.04.11 19:56:35 5: SMLUSB: Partial beginning of SML File found. Repaired and  start parsing
2016.04.11 19:56:36 5: SMLUSB: End of SML found. Looking for a beginning.
2016.04.11 19:56:36 5: SMLUSB: Started parsing
2016.04.11 19:56:36 5: SMLUSB: SML Telegram found: 77070100010801FF
2016.04.11 19:56:36 5: SMLUSB: Reading BulkUpdate. Value > 0
2016.04.11 19:56:36 5: SMLUSB: SML Telegram found: 77070100020801FF
2016.04.11 19:56:36 5: SMLUSB: Reading BulkUpdate. Value > 0
2016.04.11 19:56:36 5: SMLUSB: Parsing ended
2016.04.11 19:56:36 5: Triggering powerzaehler (0 changes)
2016.04.11 19:56:36 5: SMLUSB: Partial beginning of SML File found. Repaired and  start parsing
recv() returned an error: 104
send() returned an error: 107
2016.04.12 13:36:53 3: SMAspot called
2016.04.12 13:36:53 5: Triggering Solar2 (8 changes)
2016.04.12 13:36:53 5: Notify loop for Solar2 datetimeformat=%d/%m/%y_%h: %M:%S
2016.04.12 13:36:53 5: Triggering global (1 changes)
2016.04.12 13:36:53 5: Notify loop for global SHUTDOWN
2016.04.12 13:36:53 0: Server shutdown
Master FHEM 6 als VM auf ESX Ubuntu 20.04 LTS mit MAXCube/MAX!/FS20|TabletUI|Flightradar|Tasmota|TTN Lora|CCU3 HomematicIP|RPi mit GammaScout|MQTT EasyESP 8266|LuftdatenInfo|deCONZ HUEDev|probemon|Siemens Logo|P4D|3D PRINTER RAISE3D

KölnSolar

So ganz versteh ich Dein Logfile nicht. Ist das ungeschnitten ? Wo kommt denn der shutdown her ? Hast Du den absetzen können ?

Ich spekuliere daher mal auf einen Loop und nicht Absturz. Das kannst Du ja mit
sudo /etc/init.d/fhem status
über die Konsole prüfen.

Hast Du mal ohne SMAspot durchlaufen lassen? Kein Absturz/Loop ?

Man kann ja auch nicht erkennen aus welchem Modul die Fehler ans Log gemeldet werden, nach denen dann nichts mehr geht. Wenn die auch aus SMLUSB kommen könnten, könntest Du vielleicht alternativ mal OBIS 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

franky08

Du könntest stacktrace mal aktivieren, um zu sehen welches Modul verantwortlich ist.

VG
Frank
Debian Bookworm auf HUNSN / Debian Bullseye auf 2.ter HUNSN F2F an 2x RaspiB
mit FHEM aktuell
22Zoll ViewSonic als Infodislay (WVC)
3xHMLAN mit vccu, raspmatic_rpi3, HMIP-HCU1

KölnSolar

Uih, was es alles so gibt. Damit andere nicht suchen müssen wie ich: stacktrace ist ein Attribut des global device.
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

dieoma

laut deiner Signatur hast du FHEM ja in vSphere als VM und auch nochmal auf echter Hardware - welcher schmiert denn da ab? Hast du andere Mintlinux als VM?
FHEM5.8 auf Raspi 2, HomeMatic über HMLan mit einigen Aktoren, IT433 Steckosen über CUL, Squeezebox und Tablet-UI

Edi77

#7
So, bin mal wieder ein Stück weiter.
Es ist der FHEM der nur SMAUtil und SMLUSB also den Stromzähler macht, sonst nichts, und läuft auf einem RPi2 jetzt mit jessie, hatte es auch mal neu installiert, Problem ist geblieben.
Ein mal letzte Woche ist er abends nicht abgeschmiert.
Es ist ja auch über Monate alles gelaufen, ich habe vermutet das es daran liegt das ich statt 300 Sek. jetzt alle 30 Sek. abfrage, weil die Werte zur Verbrauchsberechnung noch in eine Formel fließen sollen, das wars auch nicht.

Installiert habe ich nach http://www.fhemwiki.de/wiki/SMAWechselrichter

Den shutdown konnte ich machen, es läuft immer nur der fhem nicht.

Dann dachte ich wenn die Wechselrichter offline gehen das dann SMAUtils verrückt spielt.
Das scheint noch zu passen. Gestern lief FHEM zuletzt um 19:56. Die Wechselrichter gingen ab 20:01 offline. Alle 300 Sek. fragt SMAUtil die Wechselrichter ab, könnte also passen.
Master FHEM 6 als VM auf ESX Ubuntu 20.04 LTS mit MAXCube/MAX!/FS20|TabletUI|Flightradar|Tasmota|TTN Lora|CCU3 HomematicIP|RPi mit GammaScout|MQTT EasyESP 8266|LuftdatenInfo|deCONZ HUEDev|probemon|Siemens Logo|P4D|3D PRINTER RAISE3D

KölnSolar

Letzteres glaube ich auch. Wenn Du den shutdown über die Konsole ausgelöst hast, dann lief aber fhem doch noch laut Deinem Log ? Also Loop oder wait/sleep in SMAspot, weil die Bluetooth Kommunikation beendet ist ?

Bist Du dem Vorschlag von Frank mal gefolgt ?

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

Edi77

Hallo,

Ich habe stacktrace=1 eingestellt ( was macht das überhaupt genau ?)

Dann habe ich mal das hier noch probiert https://forum.fhem.de/index.php/topic,14624.msg412206.html#msg412206
Da blieb aber mein logfile leer :(

Master FHEM 6 als VM auf ESX Ubuntu 20.04 LTS mit MAXCube/MAX!/FS20|TabletUI|Flightradar|Tasmota|TTN Lora|CCU3 HomematicIP|RPi mit GammaScout|MQTT EasyESP 8266|LuftdatenInfo|deCONZ HUEDev|probemon|Siemens Logo|P4D|3D PRINTER RAISE3D

franky08

ZitatIch habe stacktrace=1 eingestellt ( was macht das überhaupt genau ?)

macht, was der Name schon sagt Stapel(speicher)zurückverfolgung. Warte bis heute 20:00 Uhr fhem wieder abstürzt und dann solltest du im Log was finden.
Debian Bookworm auf HUNSN / Debian Bullseye auf 2.ter HUNSN F2F an 2x RaspiB
mit FHEM aktuell
22Zoll ViewSonic als Infodislay (WVC)
3xHMLAN mit vccu, raspmatic_rpi3, HMIP-HCU1

Edi77

#11
DANKE ........... ;D

Heute mal nicht abgestürzt
Master FHEM 6 als VM auf ESX Ubuntu 20.04 LTS mit MAXCube/MAX!/FS20|TabletUI|Flightradar|Tasmota|TTN Lora|CCU3 HomematicIP|RPi mit GammaScout|MQTT EasyESP 8266|LuftdatenInfo|deCONZ HUEDev|probemon|Siemens Logo|P4D|3D PRINTER RAISE3D

micomat

geht dein wechselrichter evtl um 20uhr "schlafen"?
Synology DS218+ with fhem+iobroker in docker, 2x RasPi w. ser2net, CUL433+868, IT, EGPM2LAN, THZ/LWZ, FB_Callmonitor, HMS100TF, Homematic, 2x TX3-TH, Pushover, USB-IR-SML-Head, SONOS, GHoma, MBus, KLF200

Edi77

Wenn es kein Licht mehr gibt, gehen die offline also ca. 20 Uhr
Master FHEM 6 als VM auf ESX Ubuntu 20.04 LTS mit MAXCube/MAX!/FS20|TabletUI|Flightradar|Tasmota|TTN Lora|CCU3 HomematicIP|RPi mit GammaScout|MQTT EasyESP 8266|LuftdatenInfo|deCONZ HUEDev|probemon|Siemens Logo|P4D|3D PRINTER RAISE3D

micomat

Ich nutze das gleiche Modul mit dem SBFspot...
Sowas hab ich allerdings noch nie gehabt...
Ergab denn der StackTrace irgendwas?
Synology DS218+ with fhem+iobroker in docker, 2x RasPi w. ser2net, CUL433+868, IT, EGPM2LAN, THZ/LWZ, FB_Callmonitor, HMS100TF, Homematic, 2x TX3-TH, Pushover, USB-IR-SML-Head, SONOS, GHoma, MBus, KLF200