RaspberryMatic 3.75.7.20240420 – Neue Version

[Baxxy]

Es muss definitiv mal jemand analysieren welcher Prozess den CPU-Load so massiv in die Höhe treibt.
Und ja, das heißt ein Konsolenfenster mit top parallel zum Browser offen zu haben und die Sache ggf. auch längerfristig zu beobachten. Achja, ein Finger auf der "Drucken" Taste für den Screenshot im richtigen Moment kann nicht schaden.

[jmaus]

Hallo, habe mein tinkerboard vor 3 Tagen von 3.73.9.20240130 auf 3.75.7.20240420 updated .
[...]
Einen Tag nach dem Update geht über WebUI kaum noch was, Ladezeiten von ca. 30 Sek. CPU-Auslastung lag zwischen 150 und 900% . Nach Neustart ging der Zugriff wieder schneller ist jedoch immer noch sehr träge . Laut meiner Diagrammaufzeichnung steigt die CCU-Auslastung beim Zugriff über WebUI von 40 - 80 % auf 120 -180 % an. Mit der Version 3.73.9.20240130 läuft wieder alles normal .

Danke für die Rückmeldung. Also noch jemand bei dem offensichtlich ein TinkerboardS seit Versionen > 3.73.9.20240130 sich Performancetechnisch etwas komisch/anders verhält. Um jedoch Anhaltspunkte zu haben wäre es natürlich hilfreich wenn du (kenntnisse natürlich vorrausgesetzt) mal schauen könntest welcher Prozess in dem momentan denn die hohe auslastung verursacht wenn die Auslastung zu hoch geht?!? Hier scheint ja irgendwas zu "hängen" bzw. das ganze System in mitleidenschaft zu bringen. Ich kann ja mal parallel dazu schauen was sich seit der 3.73.9.20240130 im Bereich Linux kernel / OS so geändert hat was diese Effekte erklären könnte. Und vielleicht könntest du nochmal die 3.75.6.20240316 als zwischenversion testen um vielleicht zu sehen ob die bei dir geht und nur die 3.75.7.20240420 betroffen ist.

BTW: Ich sehe du hast auch einen Proxmox-Server wohl in Betrieb. Irgendeinen Grund wieso du nicht darauf setzt RaspberryMatic als VM darunter laufen zu lassen und stattdessen weiter auf ein TinkerboardS zu setzen?

[onkeltommy]

Hi
auch zu Monte, weil er es erwähnt hat, ja stimme da zu; ist mir auch aufgefallen, nach dem Neustart stupse ich immer ein paar Aktoren an, da der Status nicht stimmt, aber benötigt wird. (also einer der Channels zB PSM und so (auch DRS) wird richtig auf on angezeigt, aber Relaisstatus ist auf off) .. sind immer nur ein paar und das mache ich schon immer so. (Zu faul für ein Proggy ) ...Jedenfalls, es stimmt, zu Beginn konnte ich Bedienung Geräte ohne "Bremse" durchklickern, gefühlt 1-2h später wars eben wegen CPU Last vorbei damit. Und dass die CPU hochgeht spiegelt sich auch in deren Temperatur wider. Tinker hat bei mir eh nen Lüfter, aber, sie kommt ins Schwitzen.

Die 3.75.6.20240316 konnte ich gar nicht verwenden, nur Rega Fehler, IP Server kam erst nach 2tem oder 3ten Boot hoch und die Rega ist immer wieder zwischendurch abgesemmelt plus der hohen CPU Last. Die aktuelle Version war in der Richtung "besser", die lief wenigstens schon mal

Danke für Eure Mühen !

[EnricoL]

Hallo,

habe heute auch die neue Version eingespielt!
SD Karte genommen, Version 3.75.7.20240420 neu auf Karte aufgespielt, Karte getauscht, Hochgefahren und Backup wieder drauf gemacht
Läuft seid 15 min mit DC 16% und CS 1%
Pi 3B: CPU 0.00 0.15 0.19, RAM 43,30%, Temp 44,55 Grad

Mal laufen lassen und morgen schauen!

Update!
Nach 3 Stunden DC 32% und CS 0%
CPU 0.11 0.09 0.04, RAM 46.5% Temp 46.16 Grad

Gruß Enrico

[klana]

Hi,

Kann die normale CCU3 leider nicht testen.
Habe jetzt 2 SD Cards (1x neu, 1x gebraucht) versucht (aktuelle RM Release Version) ein System aufzuspielen
(Mit Balena Etcher und auch per Recovery). Beides mal Aufspielen ohne Fehler…durchgegangen.

Zugriff nur auf den Bildschirm „WebUI wird gestartet bitte warten..:“
Zugriff nur auf das Recevery System möglich.
CCU3 blink langsam blau.
Internet ist aber da und die CCU3 wird auch in der FRITZ!Box angezeigt.

Vorletzte Version auch probiert…gleiches Ergebnis.
Anscheinend ist die CCU3 hin


PS: mit dem NighlyBuild hatte ich zumindest kein CPU > 95%

[klana]

Hallo,

Hier ein Update…

Nachdem die Original CCU3 nicht mehr wollte habe ich dem Tinkerboard nochmal die Version: 3.73.9.20240130 (tinkerboard) verpasst.
Nach einer ersten Kontrolle (1 Sdt. Nach Boot)):

- DC = 38%, CS = 10%
- Zugriff auf WebUI mit Safari und Chrome = etwas zäh und nach einigen Klicks nur noch Wartekringel mit anschließendem Abbruch ohne Anzeige des gewählten Menüs.


Dann 3 Stunden auf die Couch gelegt und dabei eingeschlafen (also keine Aktorauslösung für 3 Std./ Programme laufen in der Zeit auch nicht):

- DC = 15%, CS=1-10% (meist zwischen 5-10%, lt. eigenem Log)
- Load Average: 0.44 0.33 0.27
- Zugriff auf WebUI mit Safari = immer noch zäh und nach einigen Klicks nur noch Wartekringel mit anschließendem Abbruch ohne Anzeige des gewählten Menüs, bzw. Systemprotokoll wurde nur zur Hälfte angezeigt und dann nach kurzer Zeit nach Beenden des Wartekringels auch nichts weiter angezeigt.

- Fenster der WebUI werden alle mittig und korrekt angezeigt und lassen sich auch bedienen.


Fazit:
Irgend etwas kam mit dieser Version 3.73.9.20240130 (tinkerboard) dazu, welche diese WebUI Probleme macht und
ich könnte mir auch gut vorstellen, dass dies auch den höheren DC verursacht und in den folgenden 2 Versionen
dieser Effekt durch etwas verstärkt wird.

[onkeltommy]

Verrückt....die rennt bei mir ohne meckern (wenn man davon absieht, dass Gewerke-Änderungen die Rega werfen)

Code: Alles auswählen

CCU Hardware Info
Hardware Model:	Rockchip RK3288 Asus Tinker Board S (tinkerboard)
CPU (Cores), Memory:	Cortex-A17 (4), 2.0G
Storage:	14.7G /dev/mmcblk2
Real-Time-Clock:	rx8130
Serial Number:	98********

CCU Software Info
Product:	raspmatic_tinkerboard (3.73.9.20240130)
ReGaHss:	R1.00.0388.0236
Engines:	Tcl (8.6.13), Java (11.0.21), NodeJS (v20.9.0)
Status:	SD(1) NTP(1) Link(1) Internet(1) IP(1)

homematicIP-RF (HmIP) Info
RF-Module (Firmware):	RPI-RF-MOD (4.4.22)
Device-Node:	/dev/raw-uart (GPIO@ff190000.serial)
Address:	0xB92226 (0xB92226)
SGTIN:	30*************************
Serial:	98********
DutyCycle, CarrierSense:	15 %, 1 %

HomeMatic-RF (HmRF) Info
RF-Module (Firmware):	RPI-RF-MOD (4.4.22)
Device-Node:	/dev/raw-uart (GPIO@ff190000.serial)
Address:	0xFF2B1A (4026133)
Serial:	98**********

[klana]

Morgen Zusammen,

So, nach einer Nacht mit der Version: 3.73.9.20240130 (tinkerboard) folgendes Ergebnis:

- DC geht in der Nacht bis auf 15% runter, aber sobald ein Fenster geöffnet wird oder die Rollladen fahren ist er sofort auf 35-39%
- CS schwankt die ganze Nacht zwischen 4 und 10%, nicht einmal auf 0% runter und zwar in 5 Minutentakt.
- WebUI keine Änderung: Sehr zäh bei der Bedienung und immer wieder Ladepausen von 10-30 Sekunden

All diese Probleme treten mit der Version 3.73.9.20231130 (tinkerboard) nicht auf.

Wie gesagt ich habe hier noch die Logs der Version 3.75.7.2024042 (tinkerboard) von meinen Tests hier liegen.
Es scheint aber kein Interesse daran zu geben??4


PS: Gerade mehrfach getestet...ein Neustart im Recoverymodus unter Einstellungen/ Zentralenwartung wird nicht ausgeführt (Wartezeit jeweils 5 Minuten - insgesamt 3 mal versucht.)
Runterfahren im gleichen Menü funktioniert dagegen schon

[Xel66]

- DC geht in der Nacht bis auf 15% runter, aber sobald ein Fenster geöffnet wird oder die Rollladen fahren ist er sofort auf 35-39%

Das ist leider ein untrügliches Zeichen, dass irgendwas mit Deiner Programmierung nicht passt, denn es werden durch das Öffnen des Fensters oder Fahren des Rollladens Programme getriggert, die ihrerseits das Aussenden von Befehlen veranlassen. Auch wenn Du nichts davon siehst (weil z.B. ein Aktor schon in dem Status ist, in den Du ihn noch mal befehligst) wird trotzdem gesendet. Beispiel: beim Öffnen des Fensters soll der Rollladen hochfahren, aber er ist schon oben. Mit vielen solcher Programmierungen kann man seinen DC ohne jeglichen Nutzwert vorzüglich hochtreiben. Dagegen hilft, in solchen Programmen schon den Sollstatus als Bedingung (nur prüfen) mit aufzunehmen.

- CS schwankt die ganze Nacht zwischen 4 und 10%, nicht einmal auf 0% runter und zwar in 5 Minutentakt.

Heißt, Du hast einen latenten schwachen externen Störer. Auch hierfür ist die Firmware nicht verantwortlich. Eine Möglichkeit wäre, dass Dein Prozessor selbst duch seine hohe Auslastung auf das Funkmodule einstreut.

- WebUI keine Änderung: Sehr zäh bei der Bedienung und immer wieder Ladepausen von 10-30 Sekunden

Solange Du die eigentliche Ursache nicht angehst, wird sich diesbezüglich nichts ändern. Dein System ist mit sich selbst beschäftigt. Auf der Konsole könntest Du mit top den auslastenden Prozess ermitteln. Ist Deine Programmierung Schuld, findest Du das in den Logs. Und Logs kann man selbst lesen. Mit dem folgenden kleinen Scriptchen kannst Du die Programmläufe aus dem Systemlog (messages und messages.0) Deiner laufenden auslesen und in eine Systemvariable (bei mir "Protokollanzeige" - vorher anlege und Namen ggf. auf die eigene ändern) schreiben. Ob diese Einträge grundsätzlich bei Deinem Loglevel vorhanden sind, kannst Du ja selbst prüfen. Das Script ist nicht schön, erfüllte aber seinen gelegentlichen Zweck.

Code: Alles auswählen

! Auflistung aller Programmläufe in den beiden letzten Logdateien per Systemvariable
string stdout;
string stderr;
string ausgabe;
string cmd = "cat /var/log/messages | grep 'ReGaHss: Info: Program'";
system.Exec (cmd, &stdout, &stderr);
ausgabe = stdout;
string cmd = "cat /var/log/messages.0 | grep 'ReGaHss: Info: Program'";
system.Exec (cmd, &stdout, &stderr);
ausgabe = stdout # ausgabe;
if(!stdout == ""){dom.GetObject(ID_SYSTEM_VARIABLES).Get("Protokollanzeige").State(ausgabe)};

Ich nutze es jetzt aber nicht mehr, weil ich inzwischen genau diese Programmläufe in einem Log hinterlege und so auch Zugriff auf weiter zurückliegende Ereignisse habe. Mit der Erkenntnis der häufig getriggerten (und ausgeführten) Programme (rule's trigger flags = 6) kannst Du dann Deine Programmierung durchforsten.

Da das hier aber ziemlich OT sollte vielleicht ein Admin diese individuelle Fehlerbehandlung mal in einen eigenen Thread auslagern.

Gruß Xel66

[klana]

Hallo Xel66,

Das was du hier aufführst ist ja alles richtig, aber das habe ich alles schon durch (hatte ich schon mal geschrieben…siehe auch im Thread der vorletzten Version) und auch die Programme sind ausgetestet und prüfen auch vor Ausführung, ob der Zielzustand schon erreicht ist und benutzen auch .Value() statt .State() wenns gebraucht wird und..und. Und..

Ein kleines Script welches mit die letzte Triggerung der Programme ausgibt, TOP, alles was ich zur Fehlersuche finden konnte habe ich ebenfalls schon durch.
Ich kann ja auch nicht jedesmal wieder neu schreiben was ich in den letzten 3-4 Wochen schon alles probiert habe.
Das habe ich am Anfang der Fehlersuche gemacht und es hat mir auch nicht weitergeholfen.

Wie schon öfters gesagt ist das erst seit der Version 3.73.9.20240130 (tinkerboard) so, mit vorherigen Versionen passiert das alles nicht.
Da ich eine individuelle Fehlerbehandlung falsch finde und alles was mit den Systemversionen anscheinend nicht schuld sein kann.
Betrachte ich mein Problem als erledigt und gehe wieder auf die Version vom 30.11.2023 zurück.
Danke an alle die versucht haben mir zu helfen.