RaspberryMatic 3.55.10.20210213 – Neue Version

[erik]

vesuche gerade die aktuelle Version von RaspberryMatic als OVA File über ESX zu installieren. Ich erhalte einen Fehler das das Manifest nicht stimmt.

Welche Version von ESXi ist das?

Hi,

Esx Version 6.7 -aktuellster Patch.
VMware Workstation aktuellste Version.

Geüsse

Erik

[virgin]

Schaffen der Möglichkeit über das Anlegen einer "/etc/config/CustomStoragePath" Datei den Pfad für das Speichern der Diagramme und nächtlichen Backups selbst zu definieren. Damit können Nutzer, die keinen USB Stick zur Speicherung der Diagramme/Backups nutzen wollen/können, z.B. einen Netzwerkpfad zu einem netzwerkinternen NAS System spezifizieren und dann werden die angelegten Diagramme/Backups automatisch in diesem Pfad abgelegt (#914).

Könnte jemand mal ein Bespiel posten, wie eine solche Datei aussehen müsste? Danke

[virgin]

@jmaus,

auch ich mußte nun leider zurück auf die 3.55.5.20201226.

Warum auch immer, die neue Version 3.55.10.20210213:

- reagiert extrem sensibel auf Verbindungsprobleme mit den FLGW. Ich habe unglaublich viele und vor allem wiederkehrende Alarmmeldungen mit der neuen Version. Sind alle weg mit der alten Version
. zu allem Überfluß kamen dann auch noch Verbindungsprobleme mit dem Internet lt. Watchdog hinzu, die ich definitiv mit der gerade zurückgespielten Dezemberversion NICHT habe.
- die Internetverbindungsfehler traten immer nach einem WEBUI basierten Neustart der RM auf. Gefühlt startet irgendein Dienst nicht. Ich bin aber nicht tief genug im Thema, um das prüfen zu können
- sogar der Zeitserver (?) konnte lt. Watchdog nicht erreicht werden

Wenn ich irgendetwas testen soll um zur Verbesserung der neuen Version beizutragen, dann lasst es mich wissen. Ich helfe gerne, soweit ich das kann.

[Peter Sawatzki]

Na dein NAS Laufwerk musst du schon selbst via geeigneter Mittel (z.b. CUxD) anbinden - dazu gibt es hier zich Beiträge im Forum. Und wenn du dann das entsprechende laufwerk z.b. nach /mnt mounten lassen hast, dann kannst du diesen Pfad in die /etc/config/CustomStoragePath Datei reinschreiben. So ist das gedacht.

Gibt es hier eine Empfehlung zum Mounten von CIFS Shares zu diesem Zweck? Ich mache dies derzeit in /usr/local/etc/rc.local, damit hänge ich ein Share von meinem Windows Server in /mnt ein und habe /mnt auch in CustomStoragePath eingetragen. Ich musste dann noch manuell ein subdir "measurement" anlegen, da das automatische Anlegen beim Booten logischerweise scheitern, weil das Share ja erst zu einem späteren Zeitpunkt durch den Aufruf in rc.local eingehängt wird.

[jmaus]

Gibt es hier eine Empfehlung zum Mounten von CIFS Shares zu diesem Zweck? Ich mache dies derzeit in /usr/local/etc/rc.local, damit hänge ich ein Share von meinem Windows Server in /mnt ein und habe /mnt auch in CustomStoragePath eingetragen. Ich musste dann noch manuell ein subdir "measurement" anlegen, da das automatische Anlegen beim Booten logischerweise scheitern, weil das Share ja erst zu einem späteren Zeitpunkt durch den Aufruf in rc.local eingehängt wird.

Das du "/usr/local/etc/rc.local" nutzt um mittels eines shell-skriptes dein Netzwerklaufwerk zu "mounten" ist doch genau der richtige Weg und funktioniert ja auch anscheinend. Passt also meines Erachtens wie du das machst.

[Dragonfly]

@jmaus
@virgin

Auch bei mir treten probleme mit dem Funk-Lan-GW auf - das habe ich aber kurzerhand mal rausgeworfen.

Schlimmer ist noch, daß irgendwas mein gesamtes Netzwerk lahm legt.
Dies passiert aber nicht direkt nach einem Neustart der RM, sondern eher willkürlich - mindestens 1x am Tag über ca. 15-20 Minuten.
In dem Zeitraum geht dann wirklich fast nichts - von der Syno bis zu den IP-Kameras und PC´s.
Kurzfristig sind in dem Zeitraum wieder Geräte verfügbar - und dann wieder weg.

Da das FW-Update die letzte Änderung im Netzwerk war, werde ich auch auf die Version die 3.55.5.20201226 downgraden - mal sehen, ob das Besserung bringt.

LG

[Knoddel]

Ich habe das Update auch gewagt, bei mir funktioniert alles bestens.
Die Prozessorlast ist mit dem Update bei mir um 6% gesunken.
Das Update habe ich über die Webui eingespielt.


Danke für die tolle Arbeit

[SabineT]

Ich hab mich heute auch endlich aufgerafft und das Update gemacht. Um aber notfalls schnell zurücksteigen zu können, hab ich die neue Version auf eine neue SD-Karte installiert, von der CCU (RPI4) ein Backup gezogen und die dann runtergefahren.
SD-Karten getauscht und CCU neu hochgefahren.
Irgendwie war die Reaktionszeit des GUI dann erst mal extrem langsam, entsprechend lange hat es auch gedauert, das Backup auf die neue Version zu restoren. Was mir dabei auch aufgefallen ist, dass zwar dann CUX-Daemon, HM-Tools und Script-Parser wieder vorhanden waren, RedMatic aber nicht, was dann zu entsprechenden Meldungen von monit geführt hat. Die Flows selber wurde aber über das Backup mit restored.
Inzwischen lauft die CCU aber wieder normal, DutyCycle werden von der CCU (RPI-RF-MOD), HmIP-HAP und LanGW korrekt angezeigt.
SV für die CarrierSense Werte hab ich auch angelegt und mittels Script befüllt:

RPI-RF-MOD - CarrierSense: 0.50 %
HmIP-HAP - CarrierSense: 0.00 %
DutyCycle LGW (LGW1): 0 %
DutyCycle CCU: 7 %
DutyCycle HAP (HmIP-HAP_VorzVorne): 1 %

[Peter Sawatzki]

Gibt es hier eine Empfehlung zum Mounten von CIFS Shares zu diesem Zweck? Ich mache dies derzeit in /usr/local/etc/rc.local, damit hänge ich ein Share von meinem Windows Server in /mnt ein und habe /mnt auch in CustomStoragePath eingetragen. Ich musste dann noch manuell ein subdir "measurement" anlegen, da das automatische Anlegen beim Booten logischerweise scheitern, weil das Share ja erst zu einem späteren Zeitpunkt durch den Aufruf in rc.local eingehängt wird.

Das du "/usr/local/etc/rc.local" nutzt um mittels eines shell-skriptes dein Netzwerklaufwerk zu "mounten" ist doch genau der richtige Weg und funktioniert ja auch anscheinend. Passt also meines Erachtens wie du das machst.

Danke für die Bestätigung, ich dachte, es ginge noch besser, da mir die Lösung ein wenig wackelig erschien. Ich hatte die Freigabe nämlich zunächst nicht in /mnt eingehängt sondern in einem von mir angelegten leeren Verzeichnis /usr/local/myshare. Da dieses beschreibbar war trat der Effekt auf, dass beim Booten die Raspmatic dort lokal das measurement Verzeichnis angelegt hat und dort die Diagrammdaten anlegte und schrieb. Das Shell Skript in rc.local hat danach das Share eingehängt und es trat dann der Effekt auf, dass die Daten weiterhin auf dem lokalen Filesystem abgelegt wurden und an der shell das leere Share im/usr/local/myshare zu sehen war. Sobald ich aber das /mnt directory, das ja read-only ist, benutzt habe, um die Share einzuhängen, hat das ganze funktioniert.

[virgin]

@jmaus
@virgin

Auch bei mir treten probleme mit dem Funk-Lan-GW auf - das habe ich aber kurzerhand mal rausgeworfen.

Schlimmer ist noch, daß irgendwas mein gesamtes Netzwerk lahm legt.
Dies passiert aber nicht direkt nach einem Neustart der RM, sondern eher willkürlich - mindestens 1x am Tag über ca. 15-20 Minuten.
In dem Zeitraum geht dann wirklich fast nichts - von der Syno bis zu den IP-Kameras und PC´s.
Kurzfristig sind in dem Zeitraum wieder Geräte verfügbar - und dann wieder weg.

Da das FW-Update die letzte Änderung im Netzwerk war, werde ich auch auf die Version die 3.55.5.20201226 downgraden - mal sehen, ob das Besserung bringt.

LG

Bitte berichte mal, ob die Netwerkprobleme nach dem Downgrade weg sind.

Bei mir läuft jetzt nach dem Downgrade seit 6 Stunden alles wieder problemlos. Ich werde weiter berichten.