IP-Symcon v4.3: Dienst beendet erratisch ohne Hinweis im Log

IP-Symcon
41

guten Abend zusammen,

also… gemaess meines letzten Updates bin ich immer noch bei 78% aktivierten Graphen.

Ich habe seit Anfang des Monats eine Chart instantiiert die das overlay von PV Momentanleistung und Hausverbrauch Momentanleistung zeigt. Heute Abend hat mich dann der Tagesverlauf von PV und Hausverbrauch interessiert… also einfach mal auf die Chart geklickt um die beiden Kurven im „overlay“ zu sehen…
…und siehe da IPS ist sofort abgeschmiert… mein Chronjob hat zugeschlagen und die Recovery nach 2 min eingeläutet.

Also, kanonisch geurteilt: beim Aufruf der Chart werden von IPS zur anstehenden Visualisierung der Chart einiges an Daten eingesammelt. Der PV Wechselrichter erzeugt alle 3s einen Wert, das SmartMeter so ca. alle 2s. Sprich ab „start einsammeln der Daten“ aus der (json?) datenbasis bis hin zur „Visualisierung“ scheint wohl irgend ein Teilnehmer des IPS Code Conglomerats entweder aus dem allokierten Buffer rauszulaufen oder irgendwo zuzugreifen wo es das Raspian gar nicht gut findet…

Viel Spass beim Knobeln… und ggf. beim Instrumentieren ? :slight_smile:

Grüsse, homa

Konfiguration der Chart:
IPS_Chart_Configuration_Energiebilanz_22-Okt-2017.PNG
Und so sieht das dann aus:

IPS_Chart_Energiebilanz_22-Okt-2017.PNG
IPS_Chart_Energiebilanz_22-Okt-2017.PNG770×901 101 KB

42

Kannst du mir die geloggten Daten von den beiden Variablen schicken, damit ich das besser reproduzieren kann? Gerne per E-Mail an nt@symcon.de oder PM im Forum.

43

@Dr. Niels

zu deinem Post

Dr. Niels

Ich habe die problematische Funktion ParseBuffer noch einmal überprüft und finde keine Stelle, an der dieser Fehler fliegen könnte. Ist dein System auf dem aktuellen Stand? Kannst du mir mal deine Kernel-Version schicken?

.
Ich habe nach den Problemen alle FS20 / FHZ - Koponenten rausgeschmissen und durch Homematic oder z-wave ersetzt. War eh nur eine alte Schaltsteckdose und 3 Heiz-/Wandthermostate. Ich hatte da einige eigene Scripte geschrieben / angepasst und einiges ausprobiert. Das hat damals Spaß gemacht und es war etwas zum Tüfteln. Leider habe ich zur Zeit nicht die Muße mich näher damit zu befassen. Es lief ja auch fast ein Jahr ganz gut.
Nun habe ich wieder ein stabiles System und das war es mir Wert.

Versionsabfrage:

uname -a
Linux raspberrypi 4.9.35-v7+ #1014 SMP Fri Jun 30 14:47:43 BST 2017 armv7l GNU/Linux

In /etc/os-release steht:

PRETTY_NAME="Raspbian GNU/Linux 8 (jessie)"
NAME="Raspbian GNU/Linux"
VERSION_ID="8"
VERSION="8 (jessie)"
ID=raspbian
ID_LIKE=debian

viele Grüße
cervicor

44

Ich meinte mit Kernel-Version die Version von IP-Symcon, die du beispielsweise auf der Wilkommensseite unter „Lizenz anzeigen“ herausfinden kannst. Da einfach das Ergebnis von „Kopieren“.

45

@homa

Ich habe probiert das Problem zu reproduzieren, es hat aber leider nicht geklappt. Ich kann den Chart mit den beiden Variablen problemlos auf einem Pi Symcon darstellen. Bleibt das Problem erhalten, wenn du dein Symcon bis auf den Chart und die beiden Variablen reduzierst? Wenn ja, dann müssten wir hier noch einmal genauer reinschauen. Ansonsten hängt der Crash mit irgendwelchen Wechselwirkungen zusammen.

46

@cervicor: Wir haben noch einen weiteren Fehler im FHZ parsing entdeckt, welcher zum nächsten Update gelöst sein wird.

paresy

47

Mit gdb gestartet lief es jetzt einige Zeit, gestern wars dann mal wieder soweit und IP-Symcon war wieder weg:

Thread 21 „symcon“ received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffb6ffd700 (LWP 20352)]
0x0000000000874fa1 in ELVFHZ::ParseBuffer(unsigned long) ()
(gdb) Quit
(gdb) bt
#0 0x0000000000874fa1 in ELVFHZ::ParseBuffer(unsigned long) ()
#1 0x0000000000878008 in ELVFHZ::ReceiveData(IPSData const&) ()
#2 0x0000000000ecea45 in IPSFlowHandler::SendDataToChildren(unsigned short, IPSData const&) ()
#3 0x0000000000b0dea1 in IOSerialPort::completedReading(std::shared_ptr<std::array<char, 4096ul> >, unsigned long, boost::system::error_code const&) ()
#4 0x0000000000b136ce in boost::asio::detail::descriptor_read_op<boost::asio::mutable_buffers_1, boost::_bi::bind_t<void, boost::_mfi::mf3<void, IOSerialPort, std::shared_ptr<std::array<char, 4096ul> >, unsigned long, boost::system::error_code const&>, boost::_bi::list4<boost::_bi::value<IOSerialPort*>, boost::_bi::value<std::shared_ptr<std::array<char, 4096ul> > >, boost::arg<2> ()(), boost::arg<1> ()()> > >::do_complete(boost::asio::detail::task_io_service*, boost::asio::detail::task_io_service_operation*, boost::system::error_code const&, unsigned long) ()
#5 0x00000000007d330d in boost::asio::detail::epoll_reactor::descriptor_state::do_complete(boost::asio::detail::task_io_service*, boost::asio::detail::task_io_service_operation*, boost::system::error_code const&, unsigned long) ()
#6 0x0000000000b0a6c0 in std::thread::_State_impl<std::_Bind_simple<IOSerialPort::Connect()::{lambda()#1} ()> >::_M_run() ()
#7 0x00000000015429af in execute_native_thread_routine ()
#8 0x00007ffff7bc16ba in start_thread (arg=0x7fffb6ffd700) at pthread_create.c:333
#9 0x00007ffff55533dd in clone () at …/sysdeps/unix/sysv/linux/x86_64/clone.S:109
(gdb)

48

Das Problem sollte in der aktuellen Beta-Version korrigiert sein - Hast du die installiert?

IP-Symcon 4.3.x (Beta)

paresy

49

@Dr. Nils

ich kann den Absturz mittlerweile triggern… mit dem oben genannten Graphen… zwar nicht prediktiv… aber statistisch schlägts immer wieder zu… was den Graphen anbetrifft… ist momentan der den ich mir am liebsten anschau :slight_smile:

Ich bin mit dir… es ist intermittierend und damit wohl ein eher komplexes Fehlerverhalten das mehrerer Ereignisse bedarf um den Fehler auszulösen.

Klar, könnte ich jetzt wieder alle Graphen bis auf den einen rauswerfen… aber ob ich dann die fehlerkonditionen noch habe… wer weiss.

Ich bin eher auf der Schiene, mal alle Konditionen zusammenzutragen die ein Raspian über die Wupper schicken… und dann ein Probability-Mapping zu den Funktionsblöcken im IPS zu machen… in anderen Worten „logisch einkreisen“.

Gruss, homa