RaspberryMatic 3.75.7.20240420 – Neue Version

[JBecker32]

RaspberryMatic-3.75.7.20240420-tinkerboard (mittlerweile von Jens zurückgezogen)

Da war nur für die HomeAssistant Addon Version von RaspberryMatic der Fall und nicht für die anderen Platformen. Ich musste heute Nacht nur kurz für das erstellen einer neuen HA Addon Version alle Images kurzzeitig offline setzen. Sollte aber nun wieder alles online sein inkl. des tinkerboard images.

Gerade getestet und nun läuft es auch auf HA wieder!
Vielen Dank, Jens!

[NilsG]

Ich habe das Update auf 0420 nun auch mal gemacht (auf Original-CCU3).
Werde beobachten/berichten.

[0csic]

Danke für die schnelle Antwort! Hatte heute Morgen versucht aus dem Backup die vorherige Version des Addons wieder herzustellen, leider - oder zum Glück? - schlug das fehl, danach konnte ich aber wieder auf die aktuelle Version aktualisieren und da war der fix dann offenbar schon drin

Geiler Support, vielen Dank! Auch für dieses grandiose Addon

ich habe letzte Nacht diese Version installiert und es sah auch soweit alles gut aus im Setup, allerdings komme ich nicht mehr auf die Benutzeroberfläche. Die Meldung lautet „502: Bad Gateway“. Hatte einen Neustart der CCU und auch des kompletten HA versucht, leider ohne Erfolg.

Es hatte sich da leider ein Problem in das offizielle Release Image gestern eingeschlichen das nur bei den HA addon Nutzern dazu führte, das die WebUI innerhalb von HA nicht mehr zugreifbar war.

Das Problem ist aber inzwischen behoben und ein frisches 3.75.7.20240420 image nun online. Also bitte einfach mal ein altes Backup (vor 3.75.7.20240420) via der HA eigenen Backup Funktion des Addons einspielen Sofas temporär eine alter Version des Addon VOR der 3.75.7.20240420 installiert ist. Danach dann einfach wieder das Update frisch machen und dann sollte die WebUI wieder erreichbar sein.

[Bernd-Joras]

Wie (fast) immer ... Nach bisher 2h noch immer alles gut bei mir => DANKE

Code: Alles auswählen

Displaying running firmware update output:
==========================================
Preparing firmware update:
[1/7] Checking uploaded data... 322800135 bytes received, OK
[2/7] Calculating SHA256 checksum........d8b6ce28f28f645a755cde387bbdf8b4c53d03f854018801dccceecb9d731c6e
[3/7] Checking free disk space... 13102460928 bytes, OK
[4/7] Checking storage performance..............sequential write: 11.91 MB/s (OK: > 10.0 MB/s), random write: 398 IOPS (WARN! < 500 IOPS), random read: 1887 IOPS (OK: > 1500 IOPS), WARNING: Update process will take considerable time!
[5/7] Preparing uploaded data... zip identified, unarchiving........................................................OK
[6/7] Verifying uploaded data........................OK (sha256sum), DONE
[7/7] Preparing firmware update... OK, DONE
Finished preparation successfully.

Starting firmware update (DO NOT INTERRUPT!!!):
[1/5] Validate update directory... OK
[2/5] Checking update_script... no 'update_script', OK
[3/5] Checking for rootfs filesystem images... none found, OK
[4/5] Checking for bootfs filesystem images... none found, OK
[5/5] Checking for image file... found, flashing bootfs...............OK, flashing rootfs....................................................OK, DONE
Finished firmware update successfully.

==========================================
Browser closed connection.

NACHTRAG
Ich hatte nun innerhalb von ca. 3h Laufzeit 2 mal => WatchDog: regahss-restart
Ich beobachte weiter ... BGB

Nachtrag2: Keine weiteren WatchDog: regahss-restart´s .... was und warum auch immer ....

[fire0112]

Hallo,
Update heute über die Automatik Funktion durchgeführt.
Problemlose Installation , bisher keine Fehlermeldungen und normales Duty Cycle Verhalten.

Danke an alle die das System immer Besser machen.

Gruß Rainer

[Matthias K.]

Meine Erfahrungen mit den letzen RM Versionen und sehr langen Fehlersuchen ohne Ergebnis (nochmals Danke an alle die mir geholfen haben!),
bin jetzt wieder auf die Version vom 30.11.2023 zurück gegangen, die läuft sehr gut und hat mir keine Probleme gemacht.

Es kann ja bei der Menge an RM-Installationen die inzwischen im Umlauf sind, keine gerelles Problem sein, sonst wäre hier der Aufschrei riesig.
Daher würde ich dir empfehlen, das Thema in einen eigenen Thread zu packen um das da geordnet zu diskutieren.
Hier im Thread geht das doch nur unter und führt zu nix (außer Frust auf allen Seiten).

[zautrix]

RaspberryMatic-3.75.7.20240420-tinkerboard
...
- CarrierSense immer wieder über 20%, sobald irgend ein HmIP Gerät/Aktor angesprochen wurde.

Gut beobachtet! Und wie sind deine Schlussfolgerungen?

Verwendete Abkürzungen:
DutyCycle: DC.
CarrierSense: CS.
Mein System: Eine Zentrale mit einem HAP als "Router".



Ich kann bestätigen, dass der DC ab 3.75.6. eventuell deutlich höher werden kann.
Dieser höhere DC geht gerne einher mit erhöhtem CS.

Erstmal habe ich natürlich geschaut, wer da den hohen DC verursacht. Das geht ja ohne Probleme mit Bordmitteln, auch ohne irgendwelche externen Analyser.
Es war ein FSM16 (mit Routig aktiv) , der seine Leistungsdaten überträgt/übertragen möchte.
Ich konnte sehen, dass der auf Kanal 0 und 5 "wie blöd" sendet. Und dabei auch der CS der Zentrale auf 10% springt.

Dieser FSM16 ist von der Zentrale ziemlich abgeschirmt. Der muss also über einen Router gehen.
Dann habe ich mal meine möglichen Router ( also die PSM und PCBS ) auf die Einstellungen
"Routing aktiv" und "Gerät dient als Router" gecheckt.
Da hatte ich meiner Meinung nach gegebenenfalls etwas unsinnige Einstellungen drin.

Meine Schlussfolgerung: Da "wabern" gerne irgendwelche HMIP Signale durch das "Netz" aus den Geräten mit "Routing aktiv" und "Gerät dient als Router" und der Zentrale umher und die Zentrale interpretiert diese Signale als CS ( also Störsender ). Deswegen der höhere CS und auch der höhere DC.

Was habe ich also gemacht?

Erst einmal bei allen Geräten, die die Zentrale direkt erreichen können/müssen/sollten das "Routing aktiv" ausgeschaltet.
Bei dem HAP selbst auch das "Routing aktiv" ausgeschaltet ( was soll das da überhaupt? ).
Und "viel hilf nicht viel": Nur noch zwei PSM auf "Gerät dient als Router" gestellt und bei diesen das "Routing aktiv" ausgeschaltet.
Und seitdem ist der DC und der CS bei mir deutlich niedriger.

Da ich bei meinen ganzen "Experimenten" auf zwei Fehler in der Firmware vom FSM16 und vom SAM ( die neueste Firmware ist SCHROTT ) gestoßen bin, muss ich erst einmal um diese Fehler herum neue Programme und Systemvariablen anlegen um diese Fehler auszugleichen.
Wenn ich also damit fertig bin würde ich mich weiter der Erforschung des DC+CS Themas widmen.

Wenn ich neue Erkenntnisse habe melde ich mich wieder.

Zusammenfassung:
Der hohe DC/CS ab Version 3.75.6. wird meiner Ansicht nach verursacht durch Veränderungen in den von eq3 gelieferten Komponenten zusammen mit den im System von uns vergenommenen Konfigurationen der Einstellungen "Routing aktiv" und "Gerät dient als Router".

[Gerti]

Hi,

dann dürfte es vermutlich an unnötig aktiviertem Multicastrouting liegen. Es hieß schon immer, so viel wie nötig, aber so wenig wie möglich an Routern.
Gerade Multicastrouting (was nur selten benötigt wird) treibt den DC in die Höhe und wenn gefunkt wird, geht natürlich auch der CS hoch. Der zeigt ja keine Funktstörer an, sondern die prozentuale Auslastung des Frequenzbandes.

Gruß
Gerti

[MichaelN]

Multicastrouting (was nur selten benötigt wird)

Warum wird es denn benötigt?

[Gerti]

Hi,

das brauchst du zum Beispiel, wenn ein Wandthermostat mehrere Heizkörperthermostate in einem Raum steuern soll und nicht alle direkt erreichen kann.

Gruß
Gerti