RaspberryMatic 3.59.6.20210703 – Neue Version

[TomMajor]

Das werde ich auch nicht tun (siehe oben), denn für die meisten Leute mit normalem WebUI Update taucht dieses Requester gar nicht auf.

Es lässt die User, die ihr System schnell wieder gangbar machen wollen, wenn sie ein Backup einspielen (z.B. nach defekter SD Karte), jedoch über eine blöde Falle stolpern

Dass der Bug unkritisch ist werden ja erst mal viele die ihn sehen nicht sofort mitbekommen.

Einen bekannten Bug, (und wenn der auch nur z.B. 5% der User betrifft, bei Tausenden Installationen kann das schnell eine beträchtliche Anzahl ergeben), für 4 Wochen mit Verweis auf Rapid-Release-Model auszusitzen ist IMHO kein besonders professioneller Stil und schmälert etwas die sonst von mir als sehr gut & professionell wahrgenommene Entwicklungs- und Release-Arbeit zu RaspberryMatic.
Professionell ist hier nicht im Sinne von kommerziell sondern von Profi, State of the Art etc. gemeint.

Das soll lediglich etwas konstruktive Kritik sein.
Tiefe Verneigung vor der Arbeit und dem Engagement an RaspberryMatic.

[Bernd-Joras]

Ohne Eintrag des Ports 8183 in der Firewall der CCU nimmt der CUXD keine Verbindung auf.
Ich betreibe Raspberrymatic auf einem Thinkerboard S.
Mit der neuen Version von Raspberrymatic nun nimmt CUXD erst dann Verbindung auf, wenn ich den Port 8183 explizit freigebe ...
schneider.obw

nur ergänzend …
OK, da Du Raspberrymatic auf einem Thinkerboard S betreibst kann es natürlich sein, dass es sich zu meinem Pi3 anders verhält …
Dann sollten sich jetzt hier bezüglich des Ports 8183 die wissendenden einmischen.
BG, Bernd

[Je.Vi]

Update lief problemlos. Seit 2 Tagen Stabil und ohne Probleme.
Danke für eure Arbeit...

[Raspihausfan_1]

Ich betreibe Raspberrymatic auf einem Thinkerboard S.
Mit der neuen Version von Raspberrymatic nun nimmt CUXD erst dann Verbindung auf, wenn ich den Port 8183 explizit freigebe ...

OK, da Du Raspberrymatic auf einem Thinkerboard S betreibst kann es natürlich sein, dass es sich zu meinem Pi3 anders verhält …
Dann sollten sich jetzt hier bezüglich des Ports 8183 die wissendenden einmischen.

Ich habe in RM keinen Port 8183 freigegeben, trotzdem läuft CUxD. Ich verwende Tinkerboard S!!!

2021-07-07_Ports RM.JPG (14.21 KiB) 793 mal betrachtet

2021-07-07_Port 8183 in CUxD.JPG (23.48 KiB) 793 mal betrachtet

[jmaus]

Ja. Nach mehrfacher Überprüfung und Kreuztest mit jeweiligem Reboot bin ich mir nun endgültig sicher:
Ohne Eintrag des Ports 8183 in der Firewall der CCU nimmt der CUXD keine Verbindung auf.
Die Fehlermeldung im Log des CUXD ist wie oben beschrieben:
"Nicht mit HomeMatic-CCU 127.0.0.1:8183 verbunden!"
Öffne ich Port 8183 ist alles ok.

Ehrlich gesagt ergibt das keinerlei Sinn, ausser du hast an der Firewall selbst rumgespielt oder nutzt irgendein zusätzliche CCU Firewall-Addon was an den Firewall-Einstellungen rumgedreht hat. Denn, eine Verbinung zu 127.0.0.1:8183 muss eigentlich IMMER funktionieren. die IP 127.0.0.1 verweisst ja auf localhost und localhost verbindugen sind generell von den Firewallregeln eigentlich ausgeschlossen. Wenn dies also reproduzierbar bei dir auftritt würde ich darum bitten die Ausgaben des Kommandos "iptables -L -n -v" hier mal abzuliefern, dann könnte man schauen was da ggf. komisch/ursächlich ist.

[E 175]

Hallo,

wo und wie spielt man den Patch ein?
Bei Script testen bekomme ich eine Fehlermeldung.

Code: Alles auswählen

Error 1 at row 1 col 5 near ^- /bin/checkUsrBackup.sh
+++ /bin/checkUsrBackup.sh
@@ -23,13 +23,6 @@ if [[ -n 
Parse following code failed:
--- /bin/checkUsrBackup.sh
+++ /bin/checkUsrBackup.sh
@@ -23,13 +23,6 @@ if [[ -n "${HM_HMIP_DEV}" ]]; then
   # get the architecture
   ARCH=$(uname -m)
 
-  # if we run on aarch64 we have to override the libNRJavaSerial definition
-  # so that the aarch64 (v8) version is used we supply our own
-  JAVAOPT=
-  if [[ "${ARCH}" == "aarch64" ]];then
-    JAVAOPT="-DlibNRJavaSerial.userlib=/opt/HMServer/libNRJavaSerialv8.so"
-  fi
-
   /opt/java/bin/java -Dos.arch="${ARCH}" ${JAVAOPT} -Dfile.encoding=ISO-8859-1 -Dvertx.cacheDirBase=/tmp/.vertx-backuprestore -Dgnu.io.rxtx.SerialPorts="${HM_SERVER_DEVNODE}" -cp "${HM_SERVER}" de.eq3.ccu.server.ip.validation.ValidateHmIPBackup ${HM_SERVER_ARGS} "${pathBackup}"
 
   case $? in

Ich habe einen RPi3B mit RPI-RF-MOD.

Paul

Kann mir bitte mal jemand über die Straße helfen?

Danke Paul

[jmaus]

wo und wie spielt man den Patch ein?
Bei Script testen bekomme ich eine Fehlermeldung.

Kann mir bitte mal jemand über die Straße helfen?

Wie gesagt, den Patch musst du nicht zwangsläufig einspielen. Einfach die Fehlermeldung ignorieren und dann danach einen Reboot via WebUI anstoßen, dann wird das Backup trotzdem angewendet und alles ist gut.

[Urs53]

Hallo zusammen
Die neuste Version 3.59.6.20210703 läuft auf meiner RPi4 perfekt.
Danke an Jens für seine perfekte Arbeit.
Ein Schönheitsfehler ist aufgetreten:
Die LAN-Gateway-Konfiguration kann ich einrichten und verändern (Wired RS485 LAN Gateway).
Auf der Weboberfläche kann ich das Gateway auch löschen (anschliessend Aenderungen speichern).
Nach einem Restart der RaspberryMatic ist jedoch die Gateway wieder vorhanden.
Regelmässig habe ich dann Fehlermeldungen "WatchDog-Alarm" bzw. "hs485d restarted".
Ich kann den ganzen Inhalt löschen (Adresse, Schlüssel, ...), aber die leere Gateway bleibt stehen.
(Da ich sehr wenig IT-Wissen habe, kann ich ohne Anweisung nicht weiter suchen.)

Ich habe realisiert, dass die Drahtgebundenen Komponenten besser auf der CCU2 weiter laufen.
Deshalb will ich die Gateway vom RPi4 löschen.

Hat jemand eine Idee, wie ich die (fast) leere Gateway abschiessen kann?

Danke für einen Tipp.

[Auweia]

Hi,
die Einschätzung, dass der Fehler unkritisch ist, kann ich nicht folgen:
Meine Umgebung: RPI4+, 8GB Mem, SSD (Sabrent), RPI-RF-MOD mit den addons: rmupdate, HPCL, CLWebserver, CuxD, RedMatic.
Ich habe per rmupdate den Update versucht: Das Update lief ohne Fehlermeldung durch bis zum Reboot, der wieder in den Recovery Mode bootete. Das wars gewesen: Aus dem Backup-Restore Mode komme ich nicht mehr raus. Ein Restore mit diversen Sicherungen schlägt fehl ohne Fehlermeldungen:

RecoveryMode.PNG

Der Restore dauert nur ein paar Minuten, dann wird immer in den Backup-Restore Mode gebootet.
Was nützen Sicherungen dann, wenn man sie nicht zurückspielen kann?

Gut , dass das 2. System (RPI4+, 4GB) noch gut und aktuell, aber mit der Version 3.55.10.20210213 ist.

[aiko]

@Urs53 Lösche den Gateway mal und gucke in der Shell mit „cat /etc/config/rfd.conf“ was da drin steht. Am besten hier mal posten. Falls ein Sicherheitsschlüssel dort steht kannst du ihn natürlich am besten zensieren