RaspberryMatic 3.75.7.20240420 – Neue Version

[jmaus]

Hallo Zusammen,

nach einem Monat konstanter Entwicklungsarbeit habe ich soeben eine die neue stabile Version (3.75.7.20240420) für die Allgemeinheit freigegeben. Bei dieser Version handelt es sich um einen vorderrangig um einen Maintenance Release der einige Dinge aus den vorherigen Versionen verbessert, aber auch die eine oder andere Verbesserung und Updates mit sich bringt. Allen voran ist hier das Update auf OCCU 3.75.7 zu nennen welche eine kompatibilität zur offiziellen CCU3 3.75.7 mit sich bringt und darüberhinaus noch weitere Verbesserungen und Bugfixes mit sich bringt.

Die komplette Änderungshistorie – welche noch andere sicherlich interessante Veränderungen mit sich bringt – kann wie immer hier eingesehen werden (wurde mit DeepL automatisiert übersetzt):

Änderungen:

CCU/HomeMatic-System Änderungen:

• Aktualisierung der OCCU-Version auf 3.75.7-1 mit voller Kompatibilität zur CCU3-Firmware 3.75.7, die folgende Änderungen mit sich bringt:
  • Fehler bei der Ermittlung des kleinsten/maximal zulässigen Wertes bei der Eingabe von Dezimalzahlen mit Nachkommastellen behoben.
• das Init-Skript S47InitRFHardware so geändert, dass es eine HMRF_ADDRESS von 0x000000 akzeptiert und dann eine zufällige RF-Adresse in diesen Fällen generiert wird, da detect_radio_module 0x000000 zurückgeben kann, selbst wenn ein RF-Modul BidCos/HmRF-fähig ist. (vgl. viewtopic.php?f=65&t=82127).
• Aktualisierung des integrierten Mediola NEOserver auf 2.15.0.

WebUI Änderungen:

• 0119-WebUI-Fix-ProofAndSetValue WebUI-Patch geändert, um den Änderungen von OCCU 3.75.7 zu entsprechen.

Betriebsystem Änderungen:

• STOPSIGNAL SIGTERM zum Standard-Dockerfile hinzufügen, um explizit sicherzustellen, dass SIGTERM als Standard-Stoppsignal verwendet wird, wenn es in einer OCI-Umgebung entweder unter Docker oder Podman läuft (#2717).
• Änderung des S00watchdog-Init-Skripts, so dass der Watchdog-Daemon nicht in virtuellen OCI/LXC-Umgebungen gestartet wird, die andernfalls die Watchdog-Umgebung des entsprechenden Host-Systems beeinflussen könnten (#2717).
• Kernel-Upstream-Patch hinzugefügt, um das Zeichenlimit für USB-Storage-Quirks auf 256 Zeichen zu erhöhen, so dass die aktuell angegebene USB-Quirks-Zeichenkette nicht zu einem Kernel-Bootup-Fehler führt (vgl. home-assistant/operating-system#3308).
• Aktualisierung von buildroot auf 2024.02.1
• rpi-eeprom für rpi4 auf die neueste pieeprom-2024-04-15.bin aktualisiert.
• rpi-eeprom auf die neueste pieeprom-2024-04-05.bin für rpi5 aktualisiert.
• Java Azul auf die neueste Version 11.72.19-ca-jre11.0.23 aktualisiert.
• Aktualisierung von Tailscale auf 1.64.0
• Aktualisierung des Upstream-Kernels auf 6.6.28
• Aktualisierung der rpi-firmware auf die neueste Version.
• u-boot patch für ODROID-N2 sd card maximale Frequenzgrenze auf 40MHz hinzugefügt.
• rpi-Kernel auf 6.6.x-Kernel umgestellt und auf die neueste Version (6.6.26) aktualisiert.
• Änderung des macvlan HA Addon Patch-Skripts, um den gleichen cidr2network-Mechanismus zur Identifizierung der korrekten Subnetzzeichenkette zu verwenden wie das install-docker.sh-Skript, was die Verwendung dieses Skripts etwas bequemer machen sollte.
• Aktualisierung der Gerätebaumliste der rpi3-Plattform, um sicherzustellen, dass alle rpi3-bezogenen Gerätebäume korrekt eingesetzt werden. (vgl. home-assistant/operating-system#3301).
• Buildroot-Upstream-Patch hinzugefügt, um BR2_LINUX_KERNEL_INSTALL_INTREE_OVERLAYS einzuführen, um die Installation von mit dem Kernel erstellten Gerätebaum-Overlays zu ermöglichen. Daher wurden die rpi-Builds angepasst, um diese neue Option zu verwenden und das RPI_FIRMWARE-Paket für die Bereitstellung der Gerätebaum-Overlay-Dateien nicht mehr zu verwenden.
• Entfernen unnötiger fixup.dat/start.elf Verweise in der config.txt der rpi5 Plattform.
• Unterstützung für Multipath TCP (MPTCP) aktiviert (vgl. home-assistant/operating-system#3248).
• UAS über usb-storage.quirks auf dem RPi für ADATA SD600Q deaktiviert (vgl. home-assistant/operating-system#3281).
• Ignoriere Warnung bei nicht vorhandener Emulation von CP15-Barriereanweisungen (vgl. home-assistant/operating-system#3285).
• CONFIG_WERROR deaktiviert, da buildroot es ohnehin deaktiviert.
• Sichergestellt, dass BR2_CCACHE_DIR bei der erneuten Ausführung vorhanden ist.
• Neues rpi-eeprom-info Tool hinzugefügt, um die aktuelle RaspberryPi5 EEPROM/Bootloader Version auszugeben und um zu sehen, ob ein Update verfügbar ist oder nicht, basierend auf der pieeprom.upd Datei in /boot.
• Überarbeitung des install-lxc.sh Skripts, um eine etwas andere Überprüfung der Standard-Netzwerkbrücken durchzuführen, als nur die Überprüfung der ersten Zeile in brctl. (#2683).

Mitwirkende (diese Version, alphabetisch):

• @jens-maus

Support:
Hier sei auch noch einmal auf die umfangreiche Dokumentation von RaspberryMatic hingewiesen an der bereits seit einiger Zeit gearbeitet wird und die auch sukzessive mit jeder Version verbessert wird. Zu erreichen ist die Dokumentation unter folgender Stelle:

• RaspberryMatic - Dokumentation
• RaspberryMatic - Forum
• RaspberryMatic - Documentation
• RaspberryMatic - Discussions

Wie die URLs schon vermuten lassen, handelt es sich hierbei teils um einen öffentlichen Wiki an dem sich wirklich jeder gerne (nach entsprechender technischer Selbst-Einarbeitung) beteiligen kann um Anderen vor allem den Einstieg rund um das Thema "RaspberryMatic" zu erleichtern.

Download/Installation:

Die neue Version kann wie gehabt von folgender URL für die verschiedenen Installationsplatformen von RaspberryPi über Tinkerboard bis hin zu allen virtuellen Platformen heruntergeladen und entsprechend installiert werden:

https://github.com/jens-maus/RaspberryM ... ses/latest

Zu beachten gilt, das auf Grund der Unterstützung unterschiedlicher Geräte/Platformen es getrennte Installationsarchive und Installationsweisen gibt die für die folgende Hardware jeweils einheitlich ist. Hier bitte entsprechend die Dokumentation konsultieren.

Update/Upgrade:
Das Update auf diese Version kann bei Einsatz einer Vorversion unter "Einstellungen->Systemsteuerung->Zentralen-Wartung" durch Upload der jeweiligen *.zip oder *.tgz Datei (Nicht ausgepackt!) erfolgen. Alternativ kann natürlich weiterhin auch einfach eine neue SD-Karte verwendet werden und das im Archiv befindliche *.img auf die neue SD Karte kopiert werden um dann von dort aus neu zu booten und via Backup-Restore das jeweils aktuelle Backup wiederherstellen zu lassen. Bei den virtuellen Platformen (ova bzw. oci) passiert das jeweilige Update/Upgrade ggf. via der eingesetzten Virtualisierungsumgebung.

Hinweis:
Bitte beachten, dass natürlich vor jedem Update erst einmal ein manuelles Backup erfolgen sollte damit bei eventl. Fehlschlagen des WebUI-basierten Updates man mittels einer neuen SD-Karte dann sein aktuellstes Backup einfach wieder einspielen kann.

Für Bugreports und Featurerequests bitte den GitHub Issue-Tracker nutzen damit ich die Anfragen geordnet abarbeiten kann. Support- und Hilfeanfragen bei vermeintlichen Nutzungsproblemen bitte weiterhin hier als erstes im Forum platzieren und erst daraus ein Bugreport im GitHub machen wenn das Problem von anderen Nutzern bestätigt werden konnte.

Viel Spass mit der neuen RaspberryMatic Version!

[Monarch]

Update lief problemlos durch und scheint danach auch normal zu laufen. (OVA - Proxmox)

[alange6635@aol.com]

Update lief problemlos durch und läuft normal.Danke Jens Maus für diese Updates. Tolle Arbeit!

[schlichi]

Hallo Zusammen,

ja, update lief problemlos. Vielen Dank für die Arbeit.

... allerdings, die Favoriten werden nach wie vor 4x angezeigt.
... auch ich habe, " Den Browser Cache habe ich gelöscht und mehrere Browser getestet. Die Anzeige bleibt so." ... auch Safari auf iOS.
... und ich habe nur 2 zugeordnete User von insgesamt 3.

... und die Diagramme werden beim 1. Aufruf auch immer noch doppelt überlagert.

Gruß schlichi

[jmaus]

... allerdings, die Favoriten werden nach wie vor 4x angezeigt.
... auch ich habe, " Den Browser Cache habe ich gelöscht und mehrere Browser getestet. Die Anzeige bleibt so." ... auch Safari auf iOS.
... und ich habe nur 2 zugeordnete User von insgesamt 3.

Ich hatte doch bereits geschrieben/erklärt das das vollkommen normal ist und auch ein Feature und kein Bug. Wenn du da nochmal drüber nachdenkst wirst du verstehen warum die Favoriten dort mehrmals aufgelistet werden wenn man mehrere User hat denen man diese zuordnet. Also: It's a feature, not a bug.

... und die Diagramme werden beim 1. Aufruf auch immer noch doppelt überlagert.

Dann wend dich an den Hersteller. Die Diagrammfunktionen sind komplett teil des ClosedSource Teiles der CCU Firmware die RaspberryMatic nur unangefasst nutzt. Ergo: An eQ3 melden. Aber die Diagrammfunktionen braucht eh keiner, die sind so limitiert das man da besser auf andere Dinge (ioBroker, CCU-Historian, etc.) setzen sollte. Selbst wenn das OpenSource wäre würde das nicht den Aufwand lohnen da noch was dran zu arbeiten...

[schlichi]

Hallo Jens,

... tut mir leid, aber die "Favoriten" sind nicht plausibel, bzw. ich steige nicht durch. Bei 2 zugeordneten Usern 4x komplett anzeigen???
Ich bin deshalb nicht Deiner Meinung, ....

EQ3 sollen Ihre Hausaufgaben machen, ansonsten reagiert die Kundschaft

Gruß
schlichi

[jp112sdl]

EQ3 sollen Ihre Hausaufgaben machen, ansonsten reagiert die Kundschaft

Was sollen sie denn da noch machen?
Wenn eQ-3 die CCU(-Firmware) weiter verrotten lässt, bekehrt das vielleicht noch die restlichen 10%
Denn...

über 90% der Installationen laufen auf dem Accesspoint

[jmaus]

... tut mir leid, aber die "Favoriten" sind nicht plausibel, bzw. ich steige nicht durch. Bei 2 zugeordneten Usern 4x komplett anzeigen???
Ich bin deshalb nicht Deiner Meinung, ....

Musst nicht meiner Meinung sein, du hast hier aber definitiv einen Denkfehler bzw. eine falsche Erwartungshaltung. Um diesen Knoten im Kopf zu lösen am besten einfach mal hier alle Beiträge diesbzgl. durchlesen:

https://github.com/jens-maus/RaspberryM ... sions/2685

Dann wirst du am Ende hoffentlich verstehen wie genau diese Konfigurationsliste der Favoriten zu verstehen ist.

[Xel66]

Wenn eQ-3 die CCU(-Firmware) weiter verrotten lässt, bekehrt das vielleicht noch die restlichen 10%

Diese Rechnung halte ich für eine Milchmädchenrechnung. Und wenn nicht unbekannte Trackingmechanismen seitens der Originalfirmware laufen (außer Abfragen nach Gerätefirmwareupdates) dürfte dem Herteller eine wirklich verlässliche Statistik eher schwerfallen.

Die Anzahl der verkauften HAPs sind genauso wenig aussagekräftig (werden auch zur Reichweitenverlängerung eingesetzt), wie die Anzahl der verkauften CCUs/Funkmodule.

Dass sie laufende Cloud-Installationen auf dem HAP gut zählen können, ist klar. Aber bei allen alternativen Installationen (physische und virtualisierte CCU, RM, FEHM, sonstige Gateways anderer Hersteller, an denen sich Devices anlernen lassen) können sie nicht ermitteln. Insofern hielte ich eine solche Aussage für reines Marketinggeschwätz irgendwelcher Vertiebler.

Gruß Xel66

[jmaus]

Wenn eQ-3 die CCU(-Firmware) weiter verrotten lässt, bekehrt das vielleicht noch die restlichen 10%
Denn...

über 90% der Installationen laufen auf dem Accesspoint

Nun, wie immer ist es auch hier so bei diesen Statistiken: Kommt immer drauf an mit welcher Motivation man diese erstellt hat. Es mögen ja vielleicht absolut mehr (und vielleicht sogar nur 10%) sein, aber ich würde mal sagen das die CCU Nutzer weitaus mehr Geräte pro Installation betreiben und daher markttechnisch nicht zu unterschätzen sind. Und wenn man diese "verprellt" dann steigen die sicher nicht auf Cloud/Accesspoint oder eingeschränktem HCI um, sondern wenden sich von HomeMatic gänzlich ab, denn alternativen gibt es inzwischen wie Sand am mehr und durch solch Middlewares wie ioBroker und HomeAssistant sind diese auch inzwischen sehr gut in den Griff zu bekommen und zu vereinen... Zumindest wäre das mein Weg dann falls HomeMatic sich wirklich zu einer solchen Sackgasse entwickelt wie ich das gerade selbst auch befürchte. Aber das nur so ganz nebenbei als OT