Okay, jetzt habe ich es verstanden und brauche mir (theoretisch) keine Sorgen machen.
Das stimmt leider.
Seit letzter Nacht. Keine Probleme, außer der erheblich erhöhten Speichernutzung von Homey selbst:
- v7.4.0: ~50 MB höher als v7.3.0
- v7.4.1: ~100 MB höher als v7.3.0
Jetzt kann ich viel weniger Apps ausführen.
Mit v7.3.0 Homey verbrauchte etwa 120 - 150 MB!
Edit:
Ein Ticket bei Athom erstellt. Hoffentlich können sie im Diagnosebericht etwas entdecken.
Kann ich bestätigen. Hab es heute auf meinen Pflegehomey installiert. Im Moment 225,5 MB. Mein eigener Homey mit der 7.3 ist brav bei 124 MB.
Kann ich nicht bestätigen. Bei mir ist die Speichernutzung nach Installation der v7.4.0-rc.22 am 25.04. um ca. 50 MB gesunken:
EDIT Ein vollständiger factory reset und eine Backup zurücksetzen, haben das Problem gelöst. Die RAM-Auslastung ist wieder normal
@DirkG Hat Ihr Homey 512 MB oder 1 GB Speicher?
@Undertaker Sehen Sie auch einen solchen Unterschied zwischen diesen beiden?
.
Homey Pro (Early 2019, 1 GB)
Ich wollte den Nicht-Entwicklern (speziell @DirkG) unter uns mal einen kurzen Einblick in die “Crash-Log” Problematik geben. Das wird ja überall mit 7.4.x thematisiert.
Hintergrund:
In der App werden oft Funktionen asynchron aufgerufen/verarbeitet. Das trifft z.B: auf periodische Aktivitäten zu, wie DatenBrufe alle x Minuten. Ein interner Timer (Intervall) startet dann die asynchrone Aufführung der als Eventhandler registrierten Methoden.
Tritt in do einer Method ein Fehler auf (ausgelöst in einer aufgerufenen Methode oder durch fehlerrhafte Konveriterungen oder Daten-Inkompatibilitäten wie Verwenden eines Textes als Zahl), so bricht die Verarbetung dieser Methode mit einer Ausnahme ab. Das ist erstmal unproblematisch, beim nächsten Intervall wird das erneut ausgeführt. Daher merkt man erst einmal nichts von dem Fehler.
Bisher wurde diese Fehler von NodeJS ignoriert. Sie tauchten nur im Konsolen-Log auf, falls man als Entwickler beim Test über die Kondole zufällig diese Situation hat.
Mit NodeJS 16 (also mti 7.4) führen solche Exceptions aber zum Abbruch der kompletten App.
Athom hat zumindest das verhindert und stellt die Exceptions-log den Entwicklern in der App-Verwaltung zur Verfügung. Damit kann man die Programmstelle prüfen und hoffentlich eine Fehlerbehandlung ergänzen - oder wenn das nicht möglich ist den Fehler komplett ignorieren (z.B. wenn es durch fehlerhafte Daten verursacht wird und man diese Situation nicht nachstellen kann).
Ich mermute, das wird ermöglicht. weil die Apps mit NodeJS 16 laufen, HomeyCore aber noch nmit NodeJS 13. Soweit zumindest die spärlichen Infos in Slack.
Die Korrektur dieser Stellen wird angeraten, weil später (vermutlich mit Umstellung von HomeyCore auf NodeJS16) die Apps bei solchen Fehler komplett abbrechen werden.
EIn Beispiel:
In der App-Versionsliste wird ein Crash-Log angezeigt:
Man sieht hier auch die Homey-Version, mit der der Abbruch erfolgte:
Der StackTrace sieht dann so aus:
Man sieht die Ursache (Excaption-Text) und die Abbruchstelle.
Die Exception wird durch die Methode JSON.parse( ) ausgelöst. Ursache ist wohl ein fehlerhafter JSON-String (den man leider im Log niccht sieht)
Da man hier die genaue Ursache nicht kennt (vermutlich ein Verbindungsabbruch beim Lesen der DWD-API-Daten), kann man nur den Fehler mit einem Try-Catch-Block abfangen. Das Schreiben des Logs führt zu einem Logeintrag. Die so geschrieben Logeinträge stehen dann im Diagnosereport, den man ünber die App senden kann. Das setzt aber voraus, dass der User den Fehler überhaupt bemerkt (würde aber nur beim App-Crash passieren). So hat man als Entwickler leider keine Chance, diesen Fehler genauer auf den Grund zu gehen.
Mit 7.4.x tauchen nun vermehrt solche Fehler auf, die durch Konstellationen verursacht werden, die oft sporadisch und unvorhergesehen auftreten und die man nicht testen kann.
Ich sehe das mal positiv als Möglichkeit, die Apps mit den zusätzlichen Fehlerbehandlungen etwas fehlerresistenter zu machen 
3 Likes
Vielen Dank für die ausführliche Erklärung, auch wenn es für mich weiterhin trotzdem schwierig ist, das ganze zu verstehen.
Aber wo wir bei dem Thema schon mal sind. Ich habe eben die FW v7.4.1-rc.2 aufgespielt. Im Anschluss daran hat die FlowChecker App mehrere “Broken Flows” ausgespuckt, die unter v7.4.0-rc.22 noch nicht als “Broken Flows” erkannt wurden. U.A. auch ein rel. simpler Flow, in dem Deine DWD Wetterwarnungen App genutzt wird.
Einen “Broken Flow” kann ich jetzt nicht wirklich erkennen. Auch die anderen Flows sind auf dem ersten Blick nicht fehlerhaft und zeigen kein Ausrufezeichen. Aber ich stelle mir jetzt die Frage, ob durch die FlowChecker App ein Fehler in der DWD App (Version v1.0.17 habe ich installiert) angezeigt wird, oder wurden die ganzen “Broken Flows” ausgespuckt weil die FlowChecker App fehlerhaft ist. 
Soll ich Dir mal einen Diagnosebericht schicken?
Das ist eine Sache der FlowChecker App, denke ich. Wenn der Flow ok ist und keine fehlenden Geräte/Flows anzeigt, dann passt das schon.
Da wird in der FlowChecker-App vermutlich ein Fehler auftreten, der zu einen (ggf. falsch) erkannten Flow-Fehler führt.
1 Like
Habe Martijn schon kontaktiert…
1 Like
Einfach gesagt:
Die Fehler sind bisher auch aufgetreten nur umbemerkt.
Jetzt führen diese Fehler zu einem CrashLog in der App-Verwaltung.
Werden die Fehlerursachen in der App nicht korrigiert, wird das in Zukunft zu App-Abstürzen führen.
1 Like
DAS hatte ich schon verstanden und finde es auch gut, dass dadurch die Apps optimiert werden können… 
1 Like
Ich wollte mal zeigen, was sich “hinter den Kulissen” so abspielt. Und das es manchmal eindeutige Stellen gibt, die man direkt korrigieren kann, und oft aber auch Stellen, wo man die Situation und die gerade verarbeiteten Daten nicht kennt. Da hilt auch nur Try&Error => Neue App-Version und schauen, ob der Fehler wieder auftritt 
2 Likes
Interessant, bei meinem Homey hat die Speichernutzung nach dem Update auf v7.4.1-rc.2 (bis jetzt) weiterhin abgenommen.
v7.3.0: ca. 280 MB im Schnitt
v7.4.0-rc.22: ca. 240 MB im Schnitt
v7.4.1-rc.2: ca. 180 MB im Schnitt
Ich sag ja, Homey ist immer für eine Überraschung gut. Vielleicht gibt es doch verschiedene Revisionen, die auch verschieden reagieren.
Der von mit getestete, mit hohem Speicherverbrauch war brandneu. Mein eigener Pro, war einer der Ersten, kurz nach der Markteinführung.
Ich verstehe es nicht ganz. Nach anderen FW Updates hatte ich Probleme mit dem Speicher, während alle Anderen keine Probleme hatten… 
Weiß jemand was
- [Apps] Improve stack traces
bedeutet?
Drüber gebügelt und es läuft. Keine Auffälligkeiten.
„Problem-Apps“ wie Deconz und Homematic laufen beide und per Stichprobe habe ich einige Geräte geprüft. Alles wie es soll.
