RaspberryMatic 3.75.6.20240316 – Neue Version

[Zodiac]

Bis gestern Abend hat ja noch alles funktioniert.

Dann habe ich die FW aktualisiert und alle HomematicIP Geräte verloren,
heute morgen habe ich wieder die 08.2023 software installiert, die ja bis gestern noch funktioniert hatte.
Aber CS ist weg und ich habe keine Idee was ich machen kann...
oder ist das gar nicht das Problem?

Auszug aus der Log-Datei:
2024-04-14 12:40:36: (../src/gw_backend.c.274) establishing connection failed: socket: tcp:127.0.0.1:8183: Connection refused
2024-04-14 12:40:36: (../src/gw_backend.c.960) all handlers for /esp/system.htm?sid=@ML2ffN70pM@&action=UpdateUI on are down.
2024-04-14 12:40:39: (../src/gw_backend.c.351) gw-server re-enabled: tcp:127.0.0.1:8183 127.0.0.1 8183
2024-04-14 12:40:39: (../src/gw_backend.c.274) establishing connection failed: socket: tcp:127.0.0.1:8183: Connection refused
2024-04-14 12:40:39: (../src/gw_backend.c.960) all handlers for /esp/system.htm?sid=@ML2ffN70pM@&action=UpdateUI on are down.
2024-04-14 12:40:41: (../src/gw_backend.c.351) gw-server re-enabled: tcp:127.0.0.1:8183 127.0.0.1 8183
2024-04-14 12:40:42: (../src/gw_backend.c.274) establishing connection failed: socket: tcp:127.0.0.1:8183: Connection refused
2024-04-14 12:40:42: (../src/gw_backend.c.960) all handlers for /esp/system.htm?sid=@ML2ffN70pM@&action=UpdateUI on are down.
2024-04-14 12:40:45: (../src/gw_backend.c.351) gw-server re-enabled: tcp:127.0.0.1:8183 127.0.0.1 8183
2024-04-14 12:40:46: (../src/gw_backend.c.274) establishing connection failed: socket: tcp:127.0.0.1:8183: Connection refused
2024-04-14 12:40:46: (../src/gw_backend.c.960) all handlers for /esp/system.htm?sid=@ML2ffN70pM@&action=UpdateUI on are down.
2024-04-14 12:40:48: (../src/gw_backend.c.351) gw-server re-enabled: tcp:127.0.0.1:8183 127.0.0.1 8183
2024-04-14 12:40:50: (../src/gw_backend.c.274) establishing connection failed: socket: tcp:127.0.0.1:8183: Connection refused
2024-04-14 12:40:50: (../src/gw_backend.c.960) all handlers for /tclrega.exe? on are down.
2024-04-14 12:40:52: (../src/gw_backend.c.274) establishing connection failed: socket: tcp:127.0.0.1:8183: Connection refused
2024-04-14 12:40:52: (../src/gw_backend.c.960) all handlers for /esp/system.htm?sid=@ML2ffN70pM@&action=UpdateUI on are down.
2024-04-14 12:40:52: (../src/gw_backend.c.351) gw-server re-enabled: tcp:127.0.0.1:8183 127.0.0.1 8183
2024-04-14 12:40:54: (../src/gw_backend.c.351) gw-server re-enabled: tcp:127.0.0.1:8183 127.0.0.1 8183
2024-04-14 12:40:58: (../src/gw_backend.c.274) establishing connection failed: socket: tcp:127.0.0.1:8183: Connection refused
2024-04-14 12:40:58: (../src/gw_backend.c.960) all handlers for /esp/system.htm?sid=@VHMv1kta6s@&action=UpdateUI on are down.
2024-04-14 12:40:59: (../src/gw_backend.c.274) establishing connection failed: socket: tcp:127.0.0.1:8183: Connection refused
2024-04-14 12:40:59: (../src/gw_backend.c.960) all handlers for /tclrega.exe? on are down.
2024-04-14 12:41:01: (../src/gw_backend.c.351) gw-server re-enabled: tcp:127.0.0.1:8183 127.0.0.1 8183
2024-04-14 12:41:02: (../src/gw_backend.c.351) gw-server re-enabled: tcp:127.0.0.1:8183 127.0.0.1 8183

[MichaelN]

Aber CS ist weg und ich habe keine Idee was ich machen kann...

Willst du damit andeuten du hattest bis zum Update eine CS Anzeige? Wie hoch im Durchschnitt?

Vielleicht listet du doch mal deine konkrete Hardware auf

[Zodiac]

Hm, kann ich ehrlich gesagt gar nicht sagen, vielleicht stand da auch schon immer n/a.
allerdings haben ja alle HomematicIP Geräte funktioniert und jetzt sind sie nicht mehr erreichbar.
Anlernen funktioniert auch nicht.

Konfiguration:
Raspberry Pi3 3.71.12.20230826
BidCos-RF Geräte (die funktionieren auch noch)
HmIP-RF Geräte (die sind alle weg)
Ein LAN-Gateway habe ich auch noch.

[NilsG]

Hm, kann ich ehrlich gesagt gar nicht sagen, vielleicht stand da auch schon immer n/a.
allerdings haben ja alle HomematicIP Geräte funktioniert und jetzt sind sie nicht mehr erreichbar.
Anlernen funktioniert auch nicht.

Konfiguration:
Raspberry Pi3 3.71.12.20230826
BidCos-RF Geräte (die funktionieren auch noch)
HmIP-RF Geräte (die sind alle weg)
Ein LAN-Gateway habe ich auch noch.

An dieser Stelle muss ich mich auch mal einklinken!
Meine IP Geräte sind seitdem auch alle ohne Funktion :/ Sind zwar noch sichtbar in der CCU3, aber reagieren nicht mehr.
Dacht erst an leere Batterien, bin dem dann aber Stück für Stück nachgegangen.

Ist leider bei allen IP Geräte bei mir der Fall - ein Downgrade hat die Erreichbarkeit sofort wieder hergestellt.

[Zodiac]

Auf welche Version hast du gedowngraded?

Hier nochmal die Konfig:

CCU Hardware Info

Serial Number:
Hardware Model: Raspberry Pi 3 Model B Rev 1.2 (rpi3)
CPU / Memory: Cortex-A53 (4), 955.4M
Storage: 29.8G /dev/mmcblk0
Real-Time-Clock: n/a
CCU Software Info

Product: raspmatic_rpi3 (3.71.12.20230826)
ReGaHss: R1.00.0388.0235
Engines: Tcl (8.6.12), Java (1.8.0_382), NodeJS (v16.20.0)
Status: SD(1) NTP(1) Link(1) Internet(1) IP(1)
Operating System Info

OS Type/Kernel: Buildroot 2023.05.1 (Linux 6.1.21 aarch64)
Uptime: 0 d, 0 h 31 min
Load Average: 0.05 0.19 0.26
System Temperature: 49.4 °C
Memory / Swap Utilization: 58.1 % / 0.0 %
NTP Offset (Server): -0.034 ms (2a01:4f8:201:4101::40)
rootfs / userfs Free Space: 228.9 MB [23.5%] / 26.0 GB [92.8%]
IP address: 192.168.0.71 (eth0, MANUAL)
Gateway / Netmask: 192.168.0.1 / 255.255.255.0
Nameservers: 192.168.0.1, 0.0.0.0
Hostname: Raspberrymatic
homematicIP-RF (HmIP) Info

RF-Module/Firmware: HM-MOD-RPI-PCB (2.8.6)
Device-Node: /dev/raw-uart (GPIO@3f201000.serial)
Address: 0xB7035A (0xB7035A)
SGTIN: 3014F711A061A7D7098E1729
Serial: OEQ0306985
DC / CS: 32 % / -1 %
HomeMatic-RF (HmRF) Info

RF-Module/Firmware: HM-MOD-RPI-PCB (2.8.6)
Device-Node: /dev/raw-uart (GPIO@3f201000.serial)
Address: 0x5841D0 (0x40291b)
Serial: OEQ0306985
DC / CS: 32 % / -1 %

[Baxxy]

Das ist wohl wieder dieses ominöse "IP-Geräte gehen nach Update nicht mehr" - Problem wenn ein HM-MOD-RPI-PCB involviert ist.
Ursache bisher ungeklärt.

Was meist hilft:
A: Gerät kurz entstromen, danach verbinden die sich normalerweise wieder.
B: Gerät lokal werksresetten, danach wird es reincludiert. Wichtig hierbei, der eQ-3 Keyserver muss erreichbar sein.

[NilsG]

Auf welche Version hast du gedowngraded?

Auf die vorletzte RM, die auf GitHub liegt.
Und nein, dieses HM-MOD-RPI-PCB ist nicht involviert.
Die bekannte Vorgehensweise, wie beschrieben, kenne ich, habe ich probiert - ohne Erfolg!
Daher dachte ich ja: „Batterie leer“ und habe mir alle Geräte mal angesehen usw

[klana]

Morgen Zusammen,

wollte hier mal den aktuellen Stand meiner Fehlersuche bekannt geben.
Danke nochmal an MichaelN für den Link...habe ich ausführlichst ausprobiert.

Nachdem ich mit der aktuellen RM-Version (RaspberryMatic-3.75.6.20240316-tinkerboard) massive Probleme mit CPU Auslastung (>95%) und CarrierSense hatte und auch die ausgiebige Fehlersuche nicht wirklich etwas gebracht hat, bin ich auf die vorherige Version (RaspberryMatic-3.73.9.20240130-tinkerboard) zurück gegangen.
Hier hatte ich dann keinerlei Probleme mehr mit der CPU Auslastung, allerdings blieben die Probleme mit dem CarrierSense, der sich so alle paar mal pro Stunde über 10% teilweise 20% bewegte.
Also wieder Fehlersuche über mehrere Tage (das übliche: Batterien raus, Programme deaktiviert, ausgiebiges Logging usw....).
Sogar den USB Stick an der RM und das Netzteil habe ich getauscht, aber die CS Spitzen blieben.

Dann habe ich die RM Version(RaspberryMatic-3.73.9.20231130-tinkerboard) aufgespielt.
Hier halten sich die CarrierSense Werte zwischen 0% und 4% und nur in einigen wenigen Fällen geht es mal bis 10% hoch.
Also deutlich besser als mit den beiden letzen Versionen.

Ich möchte natürlich auf einem aktuellen Stand kommen, aber wie kann ich das Problem noch suchen bzw. finden?
Oder ist evtl. das Tinkerboard defekt?

Hier noch die aktuellen Daten aus dem Hilfe-Screen (DutyCycle ist wegen Update so hoch, normal ist er zwischen 19 und 23%):

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:	58A992F644
CCU Software Info

Product:	raspmatic_tinkerboard (3.73.9.20231130)
ReGaHss:	R1.00.0388.0235
Engines:	Tcl (8.6.12), Java (11.0.21), NodeJS (v18.18.2)
Status:	SD(1) NTP(1) Link(1) Internet(1) IP(1)
Operating System Info

OS Type (Kernel):	Buildroot 2023.08.3 (Linux 6.1.63 armv7l)
Uptime:	2 d, 18 h 44 min
Load Average:	0.15 0.16 0.18
System Temperature:	51.7 °C
Memory, Swap Utilization:	18.9 %, 0.0 %
NTP Offset (Server):	-0.062 ms (217.91.44.17)
rootfs Free Space:	224.7 MB [23.1%] / 973.4 MB
userfs Free Space:	12.4 GB [94.3%] / 13.1 GB
USB Free Space:	7.2 GB [99.8%] / 7.2 GB
IP address:	192.168.178.42 (eth0, DHCP)
Gateway (Netmask):	192.168.178.1 (255.255.255.0)
Nameservers:	192.168.178.1, 0.0.0.0
Hostname:	hm-raspi-03
homematicIP-RF (HmIP) Info

RF-Module (Firmware):	RPI-RF-MOD (4.4.22)
Device-Node:	/dev/raw-uart (GPIO@ff190000.serial)
Address:	0xBC56C4 (0xBC56C4)
SGTIN:	3014F711A0001F58A992F644
Serial:	58A992F644
DutyCycle, CarrierSense:	48 %, 2 %
HomeMatic-RF (HmRF) Info

RF-Module (Firmware):	RPI-RF-MOD (4.4.22)
Device-Node:	/dev/raw-uart (GPIO@ff190000.serial)
Address:	0xFFF644 (0xFFF644)
Serial:	58A992F644
DutyCycle, CarrierSense:	48 %, 2 %

[MichaelN]

Dir ist schon klar, das der CS von draußen kommt und daher kaum von der FW der CCU beeinflusst werden kann?

[jmaus]

Dir ist schon klar, das der CS von draußen kommt und daher kaum von der FW der CCU beeinflusst werden kann?

So sehe ich das selbst auch. Immer dieser Firmware Downgrade als erstes Mittel der Wahl bzw. Mittel der Wahl um seinen DutyCycle oder CarrierSense irgendwie zu optimieren ist IMHO die falsche Herangehensweise. Vor allem wenn das eigentliche Problem ja war das das Tinkerboard zeitweise eine hohe CPU Auslastung hatte. Dann muss man eben dem auf den Grund gehen und dann nicht von einem Problem zum anderen kommen bzw. Probleme suchen. Ich würde vorschlagen auf die aktuellste RM wieder hochzurüsten und dann systematisch zu schauen warum genau die CPU Auslastung phasenweise hoch geht.

Das einzige was ich mir vorstellen kann was dazu geführt hat das der CarrierSense hoch geht kann eben in der hohen CPU Auslastung auch begründet sein. Denn wenn die CPU Auslastung hoch geht kann natürlich parallel dazu auch der CarrierSense vielleicht hoch gehen, weil dann das Tinkerboard quasi die Taktfrequenz auf maximum schraubt und dann ggf. irgendwelche Funkstörungen erzeugt und das dann wiederum dazu führt das der CarrierSense hochschnellt. Ergo: Grund für hohe CPU Auslastung finden und eliminieren.