EE stürzt kontinuierlich ab

[Daimler]

Hi,


Und darum hatte ich ja 'Spieltrieb' geschrieben.

Nein - bei mir läuft das System ohne Probleme nach einem Absturz - liegt vielleicht auch am besagten Haken, der bei mir gesetzt ist?
Wie im anderen (Kampf-) Fred geschrieben, hatten bei mir 2 oder 3 HPCL-Neustarts für eine Stunde Pause gesorgt.

Kannst du eigentlich noch nachvollziehen, ab welcher Version das mit den EE-Abstürzen begann?
Ich habe das zum. aus den CCU-Anfangszeiten nicht in Erinnerung und es fiel mir irgendwann in 2015 auf, das ich ein Startdatum / - Uhrzeit in meiner Visu stehen hatte, zu dem ich 1000 %ig nichts gemacht hatte.

Und nochmal nein - ich habe die hier liegende CCU noch niemals produktiv eingesetzt.
Nur zu Zeiten von LXCCU ab und an mal angeschmissen, um neue XML-Files und Updates kopieren zu können.
Setze seit dem Umstieg vom PC LXCCU und seit Erscheinen Yahm ein.

Und glaube mir, wenn du die (Yahm-) Grundinstallation - mit funktionierenden Funkmodul am Laufen hast.
Spiel dein Produktiv-Backup drauf, installiere das Funkmodul noch einmal neu und du wirst / willst nicht mehr zurück!
Vor allem bei deinem ja auch nicht gerade kleinen Fuhrpark.

OCCU - du meinst RasperryMatic? - kann ich nichts zu sagen, da mir seinerzeit die zusätzlichen Abhängigkeiten (Zusatzsoftware muss angepasst werden) zu unsicher waren.

[Familienvater]

Hi,

meine EE hat schon immer spontane Neustarts hingelegt, egal ob CCU1 oder CCU2, manchmal erst nach 3-6 Wochen, manchmal schon nach 24h, teilweise habe ich mein Projekt ja 3 Monate nicht geändert, und mal lief es lange, dann ein Absturz, kurz danach noch einer, und dann wieder Wochen ohne Probleme, ohne irgendwelche Änderungen.

Teilweise ist es wohl tagesform-abhängig, vor kurzem hatte ich eine Projektversion, die ist alle 24-36h abgeschmiert, da habe ich dann das automatische Nachtreten eingebaut, und die Version läuft jetzt seit fast 2 Wochen ohne Probleme.

"Traurigerweise" reicht eine "Division by zero" um die EE zu killen, was aber in keinem Log auftaucht, dann wüsste man ggf. wonach man mal schauen muss, von daher bin ich einigen Problemchen mit dem Untersuchen der History zum Absturzzeitpunkt auf die schliche gekommen, das was als letztes Empfangen wurde, könnte das Problem verursacht haben, und ist der Start der Suche.

OCCU (die aktuelle Raspberrymatic beta4) ist wirklich kinderleicht zu installieren, aber mich stört da theoretisch auch, das ich angepasste Addons dafür brauche, und ein Backup der CCU nicht einfach eingespielt werden kann, weil vorher die Addons raus (auf der CCU deinstalliert werden) müssen. Das YAHM-Konzept finde ich schon interessanter, weil es eben 1:1 mit dem Backup funktioniert. Aber die Installation ist "schwieriger", man muss eher schon Linux-Kenntnisse haben, um z.B. im darunterliegenden jessie erstmal den SSH Port zu öffnen. YAHM lief dann auch schnell, aber das Funkmodul muss ich jetzt irgendwie noch nach Tutorial einbinden.

Der Familienvater

[Daimler]

Hi,

ja, die Abstände sind bei mir auch variabel und haben mich - außer halt vorgestern - noch nicht weiter gestört, so dass ich auch noch keine Ursachenforschung betrieben habe.
Ich war ja nicht der einzige und da gibt es jemanden, der das mit seinen Log-Tools 100* schneller als ich finden würde.

"Traurigerweise" reicht eine "Division by zero" um die EE zu killen

Das kann ich eigentlich ausschliessen, da neben Feier-, Urlaubstagen und Wochenenden eigentlich täglich alles immer gleich abläuft und das Ding schmiert willkürlich (Tageszeit, Wochentag) ab.

YAHM lief dann auch schnell, aber das Funkmodul muss ich jetzt irgendwie noch nach Tutorial einbinden.

Wenn du per ssh auf den Raspi (nicht auf die CCU!) kommst und das Funkmodul (vor dem Restore) funktionierte:
den Container per 'yahm-ctl stop' beenden --> per Yahm-Ui das Menü aufrufen --> 4 (Module) --> hm-mod-rpi-pcb deinstallieren --> PI Neustart -->
same Procedere --> hm-mod-rpi-pcb installieren --> PI Neustart
Und alles sollte funktionieren.

Und dann noch eine externe HD / SSD dran - feddich.
- Quatsch - da hast du ja andere Lösungen.

[Familienvater]

Hi,

danke für die YAHM-Schulung, es war die Funk-Modul-Firmware, die durch die raspimatic-Beta4 upgedated wurde, und die ich mit der beta3 wieder runterbringen musste, dann hat es auch in YAHM mit dem Funkmodul funktioniert.
Ich bin jetzt erstmal dabei, mich in dem YAHM-Container häuslich einzurichten, und z.B. mein health-Monitoring von der CCU2 zu adaptieren (wobei es da eigentlich nicht so viel zu adaptieren gibt), der DC vom YAHM wird ab sofort geloggt

Der Familienvater

[Daimler]

Hi,

gerne

und die ich mit der beta3 wieder runterbringen musste,

So macht man es ohne Umwege direkt unter Yahm:
Container stoppen
cd /opt/YAHM/share/tools/hmgw
sudo ./hmlangw -f
Gruß Thomas


Viel Erfolg und nicht verzagen.......

[Familienvater]

Hi,

da kann ich Dir keinen Vorwurf machen, das ist nach meiner kurzen Erfahrung so ein bisschen das Problem von YAHM:
Es wird jedemenge Wissen vorrausgesetzt, ich weiß grundsätzlich wie linux funktioniert, allerdings komme ich aus dem SuSe-Universum, das Debian-Universum ist für mich gänzlich neu, dank google kein großes Problem, aber man muss wissen, was man sucht, damit man es findet. Da ist Raspberrymatic um Potenzen einfacher bei der Installation, später im Betrieb dreht sich das dann ggf. um.
Zum YAHM zurück, auf den YAHM-Seiten bei Github wird in keinster Weise eine Start-From-Scratch Anleitung angeboten, für Leute, die das erste mal einen Pi, eine leere SD-Karte und das Funkmodul in der Hand halten. Welches "einfache" von den zig Images für den Raspi nehme ich, wie kann ich mich das erste mal auf der Console lokal anmelden, um die SSH-Anmeldung freizuschalten, und wer sich die Töchter von anderen OCCU-Müttern schonmal angeschaut hat, das wird auch mit keiner Silbe erwähnt, das da vielleicht bei der Firmware vom Funkmodul was nicht stimmen könnte.
Und dann kommt die Sucherei, im Beitrag mit 138 Seiten lese selbst ich dann nicht wirklich alles, und beim selektiven Überfliegen der Beiträge war auch nicht auf Anhieb die logische Lösung dabei.
Ich will ja kein HM-Gateway updaten, ich will ein hm-mod-rpi wie auch immer Funkmodul downgraden, die Gateways hängen ja noch am Livesystem mit der CCU2...
Von daher bleibe ich bei meiner grundsätzlich Aussage:
Anfänger auf eine CCU2 zu heben, da haben die definitiv ein Problem weniger, die Schwuppdizität fehlt vielleicht.
Apropos Schwuppdizität:
Da habe ich doch eine! Abfrage auf meinem SQL-Server optimiert (die für die Cacti-grapherei ziemlich oft alle 5 min ausgeführt wurde), die mir gefühlt zu lange gedauert hat, selbst mit dem Ausführungsplan-Optimierer hat man zwar gesehen, wo es krankt, aber der hat auch keine Vorschläge mehr gehabt, von wegen Index auf die 2 Felder legen. Die durchschnittliche CPU-Last des virtualisierten SQL-Servers mit 4 zugeteilten CPUs und 10 GB Ram hat sich von durchschnittlich 40% auf 5% verringert, das spart 10-15 Watt pro Stunde, bei 24/7 springt übers Jahr gesehen auf jeden Fall der Strom für den Pi mehr als wieder bei raus. Man muss nicht immer in neuere, schnellere Hardware investieren, es lohnt sich evtl. auch mal, über die bestehende Nutzung und deren Engpässe intensiv nachzudenken.

Der Familienvater

[Daimler]

Hi,

stimme dir teilweise zu - manchmal muss man den Jungs die Angaben aus den Rippen saugen.
Aber ich bin froh, dass es sie gibt und sie sich der Sache annehmen.

Ich will ja kein HM-Gateway updaten, ich will ein hm-mod-rpi wie auch immer Funkmodul downgraden..

Du kannst es jetzt nicht Yahm in die Schuhe schieben, dass bei deiner RasperyMatic-Spielerei das Modul mit einer zu Yahm nicht kompatiblen FW versehen wurde.

Habe zwar schon längere Zeit keinen Yahm mehr aufgesetzt - aber eigentlich war das kein wesentlich höherer Aufwand als bei der Alternative.
Jessie Lite Image auf die SD --> Root User und SSH konfigurieren --> wget -nv -O- https://raw.githubusercontent.com/leons ... /yahm-init | sudo -E bash -s quickinstall -
Feddich.

Und ich kann nachdenken so lange ich will - ob sich z. B. meine Geräteliste bei der originalen CCU2 nach (gefühlten) 10 Minuten oder unter Yahm nach 15 Sekunden öffnet - es wird sich nichts daran ändern.

[Daimler]

Hi Vadder,

da wir beide in dem Fred ja sowieso mittlerweile Alleinunterhalter waren und das ursprüngliche Thema eigentlich gelöst ist, können wir den Fred ja auch als 'Chat' für alle missbrauchen.

Konntest du bei deinen Beobachtungen einen Zusammenhang zwischen Abschmieren der EE und der Anzahl der Projektübertragungen feststellen?

Nachdem mir die EE vorhin nach 41 (gewollten oder durch EE-Absturz verursachten) Programmstarts wieder abgeschmiert ist, habe ich den PI (der war fast 5 Monate online) neu gestartet.

Schau'n mer mal.

[Familienvater]

Hi,

ich kann da keinerlei Regelmäßigkeiten erkennen. Es ist wirklich tagesformabhängig. Ein kompiliertes Projekt läuft fast 20 Tage am Stück, dann Crash, dann das gleiche Projekt wieder fast 20 Tage am Stück, dann knallt es nach 11 Tagen, dann läuft es wieder 14 Tage, da wurde es dann aber gezielt und sauber beendet und durch eine neue Version des Projekts und auch der EE (von 3.03 auf 3.04) ersetztm noch eine kleine Änderung am Projekt, läuft 7 Tage bis zum sauberen Beenden, dann wieder neue Projektversion, crash nach weniger als 2 Tagen, crash nach weniger als 2 Tagen, dann läuft das Projekt 3 Tage bis zum sauberen Beenden. Dann wieder neue Projektversion, nach 14 Tagen habe ich den kontrollierten Neustart der EE ausgelöst, weil das Projekt teilweise nicht mehr funktioniert hat, ich weiß nicht, ob es nicht auf Änderungen angesprungen ist, oder ob Bedingungen nicht mehr richtig ausgwertet wurden, es hat auf jeden Fall nicht mehr so funktioniert, wie es sollte. Seit dem Neustart der EE vor 2 Tagen läuft es wieder. Die CCU habe ich während all dem nicht neu gestartet, Uptime der CCU2 aktuell 194 Tage.

Was ich halt sehe, ist das die EE im Hauptspeicherverbrauch wächst, von ca. 6,3 MB beim Projektstart bis auf ca 20 MB nach 14-20 Tagen, in der Spitze waren es auch schon einmal 28 MB, dann knallt die normalerweise irgendwann weg. Als das Projekt plötzlich nicht mehr richtig funktionierte war aber der Speicherzuwachs in den letzten 24h deutlich weniger geworden.

Zur Zeit läuft auf dem YAHM ein mini-HPCL Projekt mit aktuell 3 Objekten, eines davon traktiert im Sekundentakt ein Zeichenobjekt und läßt es wachsen und schrumpfen, aber das macht aktuell der EE keine Probleme, die Größe der EE ist da seit 48h stabil, da muss ich mal schauen, wie ich da Stückweise die "intelligenz" aus der Echtanlage reinbekomme und Last drauf geben kann, um das Speicherleck aus der Live-Anlage evtl. einzugrenzen, damit die EE insgesamt wieder zuverlässiger wird, und vielleicht 4-6 Wochen am Stück ohne Probleme durchläuft.

Woran es aber im konkreten Fall immer liegt, kann ich definitiv nicht sagen, ich habe so ein bisschen das FHZ2000-Handling im Verdacht, aber aktuell hängen da über die FHZ2000 noch ein paar wenige alte Energiemonitore dran, die ich noch nicht durch was von HM ersetzt habe. Aber vielleicht ist das mal eine Aktion fürs Wochenende, die soweit aus dem Live-Projekt rauszuziehen, und ins Testprojekt zu hängen, und das auf dem YAHM laufen zu lassen, um im Idealfall die EE auf dem YAHM wachsen zu lassen, und vielleicht auch das Gegenteil beim Live-Projekt zu erreichen.

Der Familienvater

[ubecker]

Hallo,
melde mich auch mal kurz dazu.
Meine CCU2 hat zur Zeit 64Tage uptime somit für mich auch die EE. Habe schon lange nichts mehr an meinem Projekt geändert. Der Neustart war wenn ich mich richtig erinnere durch ein update gewesen.
ich habe mal eine Zeitlang die Größe der EE und FHZ geloggt, mach ich aber nicht mehr seit ich die FHZ2000 ins Altenteil geschickt habe. Der Wert ist fast konstant.

Mem: 113552K used, 141840K free, 0K shrd, 120K buff, 12584K cached
CPU: 15% usr 23% sys 0% nic 61% idle 0% io 0% irq 0% sirq
Load average: 0.12 0.08 0.09 2/140 20132
PID PPID USER STAT VSZ %VSZ %CPU COMMAND
20132 20121 root R 2380 1% 38% top -n 2
393 1 root S 200m 80% 0% java -Xmx64m -Dlog4j.configuration=fil
20025 517 root S 32796 13% 0% {ExecEngine}
344 1 root S 32004 13% 0% /bin/rfd -f /etc/config/rfd.conf -l 5
480 1 root S 20756 8% 0% /bin/ReGaHss -f /etc/rega.conf -l 2
517 514 root S 11936 5% 0% /usr/local/homeputer/ctlexen

Meine jetzt ca. 80 Module laufen ohne Beanstandung. Servicemeldungen bekomme ich so alle 2Wochen mal eine. (Wobei das meist Batteriewarnung sind)

Bitte berichte mal weiter was deinen Speicher frisst.
gruß Udo