RaspberryMatic 3.55.10.20210213 – Neue Version

[jp112sdl]

Das liegt wohl daran, dass "Computer-mathematisch" in einem String die ".5" größer ist als die ".10"

Nein.Es findet kein numerischer Versionsvergleich statt. Liegt am Github-Cache.

[jmaus]

Das liegt wohl daran, dass "Computer-mathematisch" in einem String die ".5" größer ist als die ".10"

Nein.Es findet kein numerischer Versionsvergleich statt. Liegt am Github-Cache.

Es wird für die Versionsprüfung schon länger nicht mehr GitHub verwendet, sondern eine URL unter "raspberrymatic.de". Lag gestern zumindest noch daran, dass ich vergessen hatte in der .js datei die version zu erhöhen. Sollte aber seid gestern abend nun gehen bzw die aktuelle als die aktuellste version ausgeliefert wird. Wenn fas bei dem Einen oder Anderen nicht der Fall ist liegt das sicherlich am browser bzw an dessen cache.

[Ukle]

Ich habe heute morgen sowohl mein rudimentäres, VM-(noch)Testsystem als auch meine aktuelle Produktionsversion problemlos auf die 3.55.10.20210213 per Web-Upgrade gebracht.
Bis jetzt habe ich noch keine Auffälligkeiten festgestellt bis auf temporär sehr hohen DC, den ich aber schon die letzten Tage unter der Testversion hatte und die wohl eher auf den Firmware-Update der zwei HmIP-FSM und einem HmIP-FSM16 auf die 1.18.20 , die das System seit Tagen quält ...
Ich werde wohl mal die HmIP-HAPs ausschalten und schauen, ob das den Prozess beschleunigt.

Großartige Leistung und vielen Dank an das Entwicklerteam!

P.S. Jetzt warte ich nur noch auf die Lieferung der bestellten LAN-Extender-Platine HB-RF-ETH von @alexreinert um die nächsten Schritte vom Rasppi4 auf die Virtuelle Maschine (meine aktuelle Testverison) vorzubereiten.

[jmaus]

• Hinzufügen eines neuen Monit-WatchDog Checks der bei Nutzung einer eMMC (z.B. bei Einsatz eines Tinkerboard S) in regelmäßigen Abständen Lebenszyklus Einträge der eMMC überwacht und eine WebUI Alarmierung auslöst wenn die Lebenzeit der eMMC über 90% ausgeschöpft ist.

Der checkEMMCLifeTime.sh läuft auf meinen beiden Pi 3b+ (garantiert ohne eMMC ^^) endlos.
Alle 15...20 Sekunden bekommt er eine neue Prozess-ID.
Ich werde den auch mit kill nicht los.

Ist das das Verhalten welches du meinst?

https://bitbucket.org/tildeslash/monit/ ... ck-program

Das scheint eine Limitationen von Monit zu sein (siehe https://mmonit.com/monit/documentation/ ... TATUS-TEST).
Die Frage wäre nur ob das ein Problem darstellt? Denn die defunct/zombies sollten bon Monit ab und an ja aufgeräumt werden und Ressourcen sollten diese nicht verbrauchen. Laut doku scheint dies nicht wirklich ein Problem darstellen.

[jp112sdl]

Ist das das Verhalten welches du meinst?

Mit <defunct> steht dort nix.

Der Prozess (3. von unten) steht da nur dauerhaft mit sich alle paar Sekunden ändernder PID.

Mich verwirrte es nur, dass da jetzt ein checkEMMC... dauerhaft läuft, auch auf einem nicht-eMMC System.

Negatives habe ich erstmal nicht feststellen können. Habe den Check aber auf meinem Produktivsystem erstmal aus der monitrc rauskommentiert.

[jmaus]

Ist das das Verhalten welches du meinst?

Mit <defunct> steht dort nix.

Der Prozess (3. von unten) steht da nur dauerhaft mit sich alle paar Sekunden ändernder PID.

Das mit dem fehlenden <defunct> liegt sicher an dem busybox 'ps' das zeigt es nicht an und nach zombie prozessen muss man da anders suchen.

Das verhalten von dem emmc skript ist sicher nicht anders als die zich [test] die du da in deiner prozessliste siehst. Die kommen auch von Monit. Und auch wenn die jetzige Umsetzung vollkommen unproblematisch sein sollte, kann ich gerne das für die nächste noch so optimieren, das ich einen zusätzlichen eintrag in die monitrc aufnehme der dann prüft ob es eine emmc gibt und wenn nicht den emmc Check entsprechend abschaltet.

[jp112sdl]

Das mit dem fehlenden <defunct> liegt sicher an dem busybox 'ps' das zeigt es nicht an und nach zombie prozessen muss man da anders suchen.

Ah okay, das kann sein. Da kenne ich mich nicht aus.

Optisch sah es für mich aus, als wenn das Skript gestartet, nach ein paar Sekunden abgebrochen und wieder neu instanziiert wird. Und das in ununterbrochener Endlosschleife.

An sich passiert ja auch nix Schlimmes auf dem Pi3, da .../life_time nicht existiert

[NFTE]

Hallo

nach dem Zurückspielen meines Backups (RP B3+, neues Funkmodul auf Header) auf ein neu aufgesetztes Qnap OVA (HB-RF-ETH 1.2.9 + anderes neues Funkmodul) sind alle meine Homematic IP-Geräte komplett verschwunden.
Bidcos-RF Geräte sind OK und funktionieren.

Habe folgende Backups erstellt (alle vom Dezember RPM Release):
Backup ohne und mit Plugins (Historian, Cuxd, xml-api)
Auch versucht: hp-rf-eth (config) bereits in den RPI kopiert und dann ein Backup erstellt, damit beim ersten Start das eth Modul erkannt wird - auch keine IP-Geräte.
Dabei ist es egal, ob ein RF Modul erkannt wird oder nicht. Bidcos da, IP nicht.

@Jens bin gerne bereit Dir mein Backup/Startup per pm zu senden.

Danke
Hans

[jmaus]

nach dem Zurückspielen meines Backups (RP B3+, neues Funkmodul auf Header) auf ein neu aufgesetztes Qnap OVA (HB-RF-ETH 1.2.9 + anderes neues Funkmodul)

Muss das neue Funkmodul denn sein? Dir ist hoffentlich bewusst das dadurch ein rekeying alles homematicIP geräte passiert und das mehrere minuten bis stunden dauern kann und das das System währendessen vollen interntzugriff zu eQ3 server braucht.

... sind alle meine Homematic IP-Geräte komplett verschwunden.
Bidcos-RF Geräte sind OK und funktionieren.

Ich würde vorschlagen du schaust mal während des ersten starts nach einspielen des backups was auf der Konsole der RaspberryMatic VM beim Start (ALT+F2) so ausgegeben wird und ob da was verdächtiges zu sehen/erkennen ist.

[heavykid]

Hallo,

ich kann die Problematik mit dem Backup ebenfalls bestätigen. Habe ein Backup der Version 3.55.5 auf die neue Version 3.55.10 aufgespielt. Sämtliche Homematic IP Geräte sind danach weg, nur BidCos-RF sind noch da. Downgrade auf die Version 3.55.5 mit anschließendem Einspielen des Backups funktioniert dagegen problemlos.

Ich verwende einen RPi3 mit dem ELV Charly Modul.

Gruß