Autor Thema: Warum beendet sich FHEM immer mal wieder ? - Jemand anders auch betroffen ?  (Gelesen 1181 mal)

Offline Stargazer

  • Full Member
  • ***
  • Beiträge: 284
Derzeit ist es auffällig, dass die Energieinstanz von FHEM häufiger ausfällt, als der Wohnungsserver... .
Die Wetterstation wurde heute Morgen um 6 Uhr zuletzt vom Wohnungsserver und dessen Davis Vantage Pro Modul abgerufen.

Jetzt ist die Frage, ob sich da doch irgendwas überschneidet.. ?

« Letzte Änderung: 23 Mai 2017, 11:22:30 von Stargazer »

Offline Markus M.

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1795
Stacktrace aktivieren!
FHEM dev + HomeBridge + Lenovo Flex15 + HM-CFG-USB + RFXtrx433 + Fritz!Box 7490 + FRITZ!Powerline 546E

HM Aktoren/Sensoren/Winmatic/Keymatic/Thermostate, HUE, Netatmo Weather/Security/Heating, Xiaomi AirPurifier/Vacuum, Withings Aura/BPM/Cardio/Go/Pulse/Thermo, VSX828, Harmony
https://paypal.me/mm0

Offline Stargazer

  • Full Member
  • ***
  • Beiträge: 284
Hallo zusammen,

das mit der Wetterstation scheint sich irgendwie zu erhärten. Es scheint ein Hardwarefehler zu sein.
Denn wenn ich sie, wie sonst nach so einem Defekt, einfach kurz Stromlos schalte, damit sich die Station
neu einbuchen kann, kommt sie nicht mehr ins Netz zurück. Die IP wird unter dem Router als "Ungenutzte
Verbindung" deklariert. Ich hatte auf dem Wohnungsserver die Station nochmal gelöscht und neu angelegt.
Auch hier kommen keine Daten an. Auf der App ebenfalls. Hoffentlich war's das und es lag trotzdem an
diesem "Wackelkandidaten". Ich werde das im Auge behalten und berichten.

Ich habe das bereits dem Service gemeldet. Wird wohl auf einen Tausch herauslaufen.

VG

André

PS.: Wie aktiviere ich das Stacktrace und was macht das ?
« Letzte Änderung: 23 Mai 2017, 20:00:58 von Stargazer »

Offline Markus M.

  • Developer
  • Hero Member
  • ****
  • Beiträge: 1795
Such mal in der commandref und im Forum, bin gerade unterwegs.
Das sagt dir warum FHEM abstürzt.
FHEM dev + HomeBridge + Lenovo Flex15 + HM-CFG-USB + RFXtrx433 + Fritz!Box 7490 + FRITZ!Powerline 546E

HM Aktoren/Sensoren/Winmatic/Keymatic/Thermostate, HUE, Netatmo Weather/Security/Heating, Xiaomi AirPurifier/Vacuum, Withings Aura/BPM/Cardio/Go/Pulse/Thermo, VSX828, Harmony
https://paypal.me/mm0

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 16929
@Markus M: stacktrace zeigt nach einer "PERL WARNING" Meldung von FHEM, welches Modul diese Meldung ausgeloest hat. Aktivieren kann man es mit "attr global stacktrace". Wenn man keine Meldungen im FHEM-Log findet, dann hilft stacktrace auch nicht.

@Stargazer: ich empfehle immer noch
Zitat
FHEM in screen mit  "attr global logfile -" zu starten.

@schka17: Ein Speicherloch in einem Perl Programm habe ich bisher nur bei Verwendung von XML-DOM Bibliotheken gesehen (da aber oefters), wenn der Autor die (in perl unuebliche) explizite Freigabe des Speichers vergessen hat.

Offline herrmannj

  • Global Moderator
  • Hero Member
  • ****
  • Beiträge: 4114
ich erlaube mir hier eine persönliche Erfahrung einzustreuen die ich vor einigen Wochen gemacht habe.

Dazu hatte ich mir eine eigene (fhem) lib vorgenommen und habe mir gedacht, hey, schau mal so im Zuge der Qualitätssicherungen, ob da auch wirklich aller Speicher wieder freigegeben wird. War eher so pro-forma, macht perl ja selber. Etwa eine Stunde später war mir klar das *meine* lib dutzende von Speicherlöchern hatte. Das hätte ich auch nie gemerkt hätte ich nicht aktiv danach gesucht.

vg
joerg

 
smartVisu mit fronthem, einiges an HM, RFXTRX, Oregon, CUL, Homeeasy, ganz viele LED + Diverse

Offline schka17

  • Sr. Member
  • ****
  • Beiträge: 808
@schka17: Ein Speicherloch in einem Perl Programm habe ich bisher nur bei Verwendung von XML-DOM Bibliotheken gesehen (da aber oefters), wenn der Autor die (in perl unuebliche) explizite Freigabe des Speichers vergessen hat.

XML-DOM Bibliotheken, sorry da verstehe ich nur Bahnhof, wüsste auch nicht wie feststellen kann welches Modul der Verursacher ist. Hab den damaligen Thread grad nochmal rausgesucht
https://forum.fhem.de/index.php/topic,27223.0.html

Wahnsinn, ist bald 3 Jahre her, unzählige updates und Änderungen seither, aber das Problem sowie der workaround immer noch da.



Sent from my iPad using Tapatalk
M: Thinclient x64 Debian | CUL FS20, HMS100WD, HMS100TF, HMS100T, HMS100CO, S300, S555TH | OWServer DS1420, DS18B20, DS2408 | RFXCOM UVN128, THWR800, THGR228N,RTGR328, PCR800 |Jeelink PCA301 EC3000|CUNO+IR|HMLAN|HMUSB|CUL433 Somfy|mySensors|espEasy
S1:Raspberry mit BPM810, Jeelink EC3000

Offline Stargazer

  • Full Member
  • ***
  • Beiträge: 284
Hallo zusammen,

es scheint derweil wirklich so zu sein, dass es an der Davis Station liegt.
Ich hatte das ganze jetzt mal einen Tag komplett vom Netz genommen und nun wieder aktiviert.
Nun meldete sie sich wieder unter der IP an und ich hatte kurz nochmal das Modul gestartet um zu sehen, ob alles läuft.
Und soweit läuft sie gut. Doch man merkt im Netzwerk, dass, wenn das VantagePro - Modul am laufen ist, die Perfomance etwas einknickt. Also speziell was FHEM angeht. Da braucht es doch länger, eh sich die Browserseite mit FHEM aufbaut.
Das ist schonmal auffällig. Also ist erstmal auf jeder FHEM-Instanz das Modul deaktiviert.

Derweil habe ich eine andere Lösung um an die Daten zu gelangen. Ist zwar etwas am Leben vorbei, aber was will man machen ?

Ich rufe jetzt die WeatherLink Seite im Internet via HTTPMOD-Modul ab und werte diese aus. Wie gesagt...etwas Plem-Plem, aber wenn es nicht anders geht. Ich werde die Station trotzdem weiter im Auge behalten.

Ich habe jedoch noch das Problem, dass er mir in dem HTTPMOD-Modul noch keine Readings erzeugt.
Folgende Auswertung wurde via regex101.com gegengerechnet:

Hier die Attribute:

attr WeatherLink readingsName_Barometer Barometer
attr WeatherLink readingsRegex_Barometer (?s)Barometer.{43}([\d\.]+)


Dazu der Buffer des Moduls im Ausschnitt:
</tr> <tr> <td width="190" class="summary_data">Barometer</td> <td width="170" class="summary_data">1022.2hPa</td> <td width="100" class="summary_data">1024.1hPa</td> <td width="100" class="summary_data">11:02 AM</td> <td width="100" class="summary_data">1022.2hPa</td> <td width="100" class="summary_data">8:12 PM</td> </tr>

Kann da eventuell noch jemand drüber gucken ?
Ich kann keinen Fehler finden. Mit regex101 funktioniert es.


Viele Grüße und besten Dank

André

PS.: Könnte es sein, dass diese Probleme von einer "Inkompatibilität" des VantagePro - Moduls mit einer höheren FHEM Version herührt ?



Online Wernieman

  • Hero Member
  • *****
  • Beiträge: 3209
Zitat
Doch man merkt im Netzwerk
Mit Beaduern muß ich immer wieder feststellen, das die Leute "netzwerk" sagen, wenn sie allgemeine Probleme meinen. Netzwerk ist seeeehr vielschichtig. Meinst Du jetzt netzwerkgeschwidigkeit, wie z.B. zum surfen im netz, oder der Zugriff zu Deiner FHEM-Instanz. Ist es der Pi, oder .....
- Bitte um Input für Output
- When there is a Shell, there is a Way

Wie man Fragen stellt: https://tty1.net/smart-questions_de.html

Offline Stargazer

  • Full Member
  • ***
  • Beiträge: 284

Zitat
z.B. zum surfen im netz, oder der Zugriff zu Deiner FHEM-Instanz. Ist es der Pi, oder .....

Derzeit spürt man es in erster Linie auf den beiden FHEM - Instanzen.
Wir haben bei meinen Eltern eine Art "Infoschirm" mit dem originalen 7" Raspi - Touchdisplay installiert.
Läuft dort seit über einem Jahr sehr gut. Dort wird die Dashboard - Seite des Energieservers dargestellt.
Also die FHEM Instanz für die Energie. Diese lädt wesentlich schneller und läuft insgesamt perfomanter.

Ich habe jetzt, seit dem ich das Modul nicht mehr aktiv habe, auch keine weiteren Ausfälle der FHEM - Server
gehabt. Mal sehen ob das so bleibt, wenn die Station weiterhin aktiv im Netzwerk bleibt.
Darum liegt derzeit meine Vermutung einfach an einem Problem mit dem VantagePro - Modul.

VG

André