Hallo zusammen,
ich bin nun das erste Mal mit dem System längere Zeit im Urlaub.
Gestern stellte ich fest, das die Relais vom schwarzen Board nicht mehr reagierten.
Erst ein Neustart von NodeRed konnte das Problem lösen.
Ich verwende ausschließlich ein iPad über WLAN oder mein Handy zum anzeigen und steuern. Ich muss feststellen, das System bereits nach ein paar Tagen sehr sehr träge ist.
Der Kabelgebundenen Shunt zeigt starke Schwankungen bereits bei der Spannung. Also unzuverlässig.
Allgemein sind die analogen Messeungen sehr unzuverlässig.
Kann noch jemand das bestätigen?
Gruß Stefan
Karl
September 18, 2025, 12:12pm
2
Hallo Stefan,
man merkt an deinen Beiträgen, dass du dein System schon viel verändert und ausprobiert hast. Deshalb ist deine Einrichtung wahrscheinlich inzwischen ziemlich einzigartig.
Das macht es schwer, dass jemand anderes genau dieselben Probleme hat – viele nutzen eine einfachere „Standard“-Variante ohne so viele Anpassungen.
Bei Dingen wie den Relais, der Trägheit nach ein paar Tagen oder den ungenauen Messungen spielen deine Flows, die Hardware-Anschlüsse und deine Änderungen stark zusammen.
Das heißt aber nicht, dass deine Beobachtungen falsch sind – nur ist es eher unwahrscheinlich, dass jemand die gleichen Effekte genauso erlebt.
Schreib dir am besten auf, welche Änderungen du gemacht hast und wann die Probleme auftreten. So können andere besser einschätzen, ob es an einer speziellen Anpassung liegt oder ob es ein allgemeines Problem ist. Hilfreich ist auch ein Blick auf die installierten Paletten/Nodes in Node-RED, weil zusätzliche Erweiterungen oder Updates oft Einfluss auf die Stabilität und Geschwindigkeit haben.
@Karl Klar habe ich einiges geändert und individualisiert.
Ich habe einen Raspi 4 mit 4GB, wobei nur 1.1GB benutzt werden.
Auf der Fesplatte ist übersll genügend Platz, bis auf /var/log dieser bereich ist zu 100% voll!
Ist das ein Problem?
CPU Tem: 50.4 C
Die CPU Auslastung:
Architecture: aarch64
CPU op-mode(s): 32-bit, 64-bit
Byte Order: Little Endian
CPU(s): 4
On-line CPU(s) list: 0-3
Vendor ID: ARM
Model name: Cortex-A72
Model: 3
Thread(s) per core: 1
Core(s) per cluster: 4
Socket(s): -
Cluster(s): 1
Stepping: r0p3
CPU(s) scaling MHz: 100%
CPU max MHz: 1800.0000
CPU min MHz: 600.0000
BogoMIPS: 108.00
Flags: fp asimd evtstrm crc32 cpuid
L1d cache: 128 KiB (4 instances)
L1i cache: 192 KiB (4 instances)
L2 cache: 1 MiB (1 instance)
Vulnerability Gather data sampling: Not affected
Vulnerability Itlb multihit: Not affected
Vulnerability L1tf: Not affected
Vulnerability Mds: Not affected
Vulnerability Meltdown: Not affected
Vulnerability Mmio stale data: Not affected
Vulnerability Reg file data sampling: Not affected
Vulnerability Retbleed: Not affected
Vulnerability Spec rstack overflow: Not affected
Vulnerability Spec store bypass: Vulnerable
Vulnerability Spectre v1: Mitigation; __user pointer sanitization
Vulnerability Spectre v2: Vulnerable
Vulnerability Srbds: Not affected
Vulnerability Tsx async abort:
Also CPU last sehe ich da keine !?
Ich würde mal gucken was die Logs so zu knallt, 100mb logs ist viel, da muss was bei dir in den fehler laufen.
Als das System Träge war, was war die CPU last, Ram Verbrauche, was lief alles , welche plugins wurden hinzugefügt. was wurde verändert.
Ich hab an meine System schon viel verändert, aber performance probleme kenne ich nicht.
Gruß Wulle
1 Like
So sieht das /var/log Verzeichnis aus:
tail auf syslog: (sieht nach BT Problemen aus?)
tail auf syslog.1: (sieht nach BT Problemen aus?)
tail auf kern.log:
tail auf kern.log.1:
Also, ich habe festgestellt, das syslog voll läuf.
Häufigster Eintrag:
2025-09-23T14:07:05.077896+02:00 pekaway env[712]: 2025-09-23 14:07:05,077 inet.protocol INFO #011Received read by identifier request.#011Responding to 08 message (updates_to_send={})!#011Received read by identifier request.#011Responding to 08 message (updates_to_send={})!#011Received read by identifier request.#011Responding to 08 message (updates_to_send={})!#011Received read by identifier request.#011Responding to 08 message (updates_to_send={})!#011Received read by identifier request.#011Responding to 08 message (updates_to_send={})!#011Received read by identifier request.#011Responding to 08 message (updates_to_send={})!
Kann mir dazu jemand etwas sagen?
Ich vermute es liegt am BT Check von BLE Connections:
Debug:
Ich habe herausgefunden, dass die Logeinträge vom „truma_service“ Dienst kommen.
Auch wenn NodeRed aus ist.
Ich habe in der /etc/miqro.yml den Loglevel von Info auf Error gestellt, bringt aber nichts.
@Vincent fällt dir dazu noch etwas ein? Liegt das evtl. ander Installation:
pip3 install inetbox_py[truma_service] --break-system-packages
Gruss, Stefan
Ein Bekannter konnte mir helfen:
Die syslog Einträge kommen von dem Prozess truma_service.
Die Einstellung damit sie nicht jede Info in das syslog protokollieren werden hier geändert:
/usr/local/lib/python3.11/dist-packages/inetbox/inetbox.py
self.log.setLevel(logging.DEBUG if debug else logging.WARNING)
Log-Level von INFO auf WARNING umgestellt
Danach den Dienst neu starten:
sudo systemctl restart miqro_truma
1 Like
