Ich oute mich hier mal als der ultimative nicht-update-Nerd, der immer noch mit
version $Id: fhem.pl 9118 2015-08-23 12:43:56Z rudolfkoenig $
unterwegs ist.
Man hat mir unmissverständlich klar gemacht, das es jetzt Zeit für ein update sei... also dann...
Mein größtes Problem ist meine organisch gewachsene 99_MyUtils
Die hat knapp 1600 Zeilen, die aber alles das was sie sollen, ganz gut tun.
Die gilt es jetzt auf den aktuellen Stand zu bringen.
Ich gehe davon aus, das mein "Problem" wohl in der neuen Form einiger globaler Variablen liegen wird, wo % und @ nicht mehr verwendet werden dürfen.
Das kam mit den Update des Feature-Level auf 5.7 wenn ich mich Recht erinnere.
3762 - IMPORTANT: featurelevel is now 5.7, rendering @ and % non-functional
Danach werden globale Variablen der Form %NAME zu $NAME und %DEVICE zu $DEVICE ... korrekt?
Was gäbe es sonst noch zu beachten?
VG
Ralf
PS: fhem läuft auf einem Laptop im Keller, das auch mein genereller Server ist.
System ist soweit aktuell.
PRETTY_NAME="Debian GNU/Linux 9 (stretch)"
Zu den Hürden bei FHEM Update kann ich DIr wenig sagen, aber Debian Stretch ist NICHT mehr UpToDate.
Da Du D eine fhem-Config migrieren must, würde ich auch ein Betriebsystemupdate empfehlen. Am besten erstmal über ein 2. System zum "Testen". Klassischer Upgrade eben.
Zitat von: dougie am 25 Oktober 2022, 13:12:27
Mein größtes Problem ist meine organisch gewachsene 99_MyUtils
Die hat knapp 1600 Zeilen, die aber alles das was sie sollen, ganz gut tun.
Das ist recht und schön, aber vieles, was man früher in die myUtils.pm packen "musste", ist inzwischen im Standard implementiert, als prominentes Beispiel sei hier addLog() genannt.
Insofern sollte man die Datei auf jeden Fall durchforsten und prüfen, ob das, was dort drinsteht, überhaupt noch benötigt wird.
Ansonsten würde ich ein aktuelles FHEM auf einem Testsystem aufsetzen, die 99_myUtils.pm dorthin kopieren und schauen, ob beim Speichern der Datei nach dem Editieren (in FHEM!) schon Fehler auftreten. Das wären die ersten Ansatzpunkte.
das mit der fhem Installation auf einem Ersatz-system ist gar nicht so einfach, da es da doch zig hard-gecodete adressen zu log files gibt.
Puh ... das wird etwas Arbeit.
An dem Debian Stretch werde ich nix ändern. Muss auch nicht. Ist ein Insel-System auf das man nur via Zertifikat kommt. Das reicht.
ZitatIst ein Insel-System
Es währe ein Insel System, wenn es sich in einem eigenen Netz ohne Außenverbindung befinden würde.
Will Dir in Deine Entscheidung nicht reinreden, nur ist in 99% der Fälle genau diese Aussage nur ein "Feigenblatt" und kein Argument.
z.B. wenn sich im gleichen Netz ein Rechner mit genutzter Internetverbindung befindet, ist ein Angriff "über Bande" möglich und wird auch aktiv gemacht.
Ein Argument währe, wenn Du sagen würdest, das Deine Migration FHEM schon so aufwändig ist, das Du nicht zusätzlich die Komplikation eines Betriebsystemupgrades haben möchtest, nur bei dem hier genannten Aufwand reden wir fast von einer Neuimplementierung, und da könnte man .....
Zitat von: dougie am 25 Oktober 2022, 20:55:18An dem Debian Stretch werde ich nix ändern. Muss auch nicht. Ist ein Insel-System auf das man nur via Zertifikat kommt. Das reicht.
Mit dieser Einstellung lässt Du am besten alles auf dem alten Stand.
Bei allem Respekt, aber ich gehöre nicht zu denjenigen, die 3x pro Woche ihren Rechner zum Spass neu aufsetzen.
Kommantare wie den letzten empfinde ich ohne Kenntnis der hiesigen Gegebenheiten als pauschal, unverschämt und wenig hilfreich.
Ich hab hier auch noch Rechner mit Windows 98, XP und Vista im Einsatz.... und das aus sehr guten Gründen.
Der Aufwand, das hiesige Linux-System upzugraden, steht in keinem sinnvollen Verhältnis, zum möglichen Nutzen. Und diese Beurteilung kann man gerne demjenigen überlassen, der es abschätzen kann und der bereit ist, die Risiken zu tragen.
Das es Individuen gibt, die sich daran gewöhnt haben, das ihr Windows System mindestens ein Update pro Tag braucht, um alte Fehler zu beheben, und neue einzuführen, mag sein - ich gehöre definitiv nicht dazu!
Zurück zum Thema: ich befürchte ich komme nicht drum herum erst ein vollständiges Backup zu machen und dann zu schauen, was nach dem Update alles hängt.
VG
Ralf
Und bei dem Aufwand de, würde ich Dir wirklich empfehlen, über ein Spiegelsystem nachzudenken. Du wirst es nicht in einem Tag schaffen und es entspannt wirklich, wenn man vorher einiges Ausprobieren konnte.
Und noch ein Hinweis: nach einer Migration ist immer vor der nächsten .... also gleich nachdenken, ob Hardcodiert" sinnvoll ist .....
...gibt es hier einen "seufz" Smiley?
Das Betateilchen hatte es oben ja schon gesagt und du ja auch: die Syntax Prüfung in nem neuen System werde ich sicher vorab mal laufen lassen.
Das System hat nur so verdammt viele Schnittstellen ... etliche oneWire Busse, etliche CUNOs, Hue Bridge, HM-LAN Adapter, Viessmann vcontrol, MQTT.... usw. .... dieses "Never touch a running System" hat auch manchmal seinen Charme... aber die Entscheidung ist gefallen: einen Versuch ist es wert!
Zitateinen Versuch ist es wert!
Und genau deshalb bitte nicht im Life-System ;o)
Und ja, ich kenne das Problem "Never touch a running System" auch, nur wird die "technische" Schuld mit jedem aufgeschobenem Update immer größer, bis es eben nicht mehr Handelbar ist, bzw. ein neuaufbau "einfacher" ....
Ich fühle mit dir. Ich hatte den ,,Vorteil", dass ich zu Beginn mein System im Halbjahres-Rythmus neu aufgesetzt hatte. Da war ich fit, das dauerte 10 Minuten. Seit es läuft, mache ich Updates nur, wenn zwingend nötig.
Einfach ständig hier fragen, das wird schon!
Und genau aus all den Pros und Cons bin ich dazu übergegangen, zu einem festen Termin pro Woche bzw. pro Monat meine Systeme komplett zu patchen - natürlich nach automatisiertem Backup. So bin ich immer auf aktuellem Stand und wenn dann mal was schief geht, kann ich relativ schnell und einfach auf eine nicht total veraltete Vorversion zurück.
Ich kann den Schmerz vom TE absolut nachvollziehen. Letztendlich ist dies aber tatsächlich einfach eine Folge davon, dass "der richtige Zeitpunkt" für ein kontrolliertes Update/Upgrade gewollt oder ungewollt verpasst wurde, und damit vergrößern sich die zu lösenden Themen mehr und mehr.
Zur Sache: ich würde hier in der Tat ein Parallelsystem (im Idealfall als VM oder Container) hochziehen und strukturiert die Probleme eingrenzen und ausmerzen. Ein "einfaches" Update wird hier nicht funktionieren.
du kannst auch ein aktuelles Fhem bezüglich Variablen die deprecated sind , wieder freischalten
probieren musst du selber.
siehe Bild der Fhemversionen
Allerherzlichen Dank für Anteilnahme und die tollen Ratschläge!! Vor allem das der Featurelevel inzwischen gesetzt werden kann, war mir total neu.
Ich fand fhem seinerzeit genial und so ist es heute auch noch, aber irgendwann reichen die 24h/Tag nicht mehr um bei allen Änderung die nötige Zeit bereit zu haben. Soll keine Entschuldigung sein - nur eine Erklärung.
Manchmal fühl ich mich wie Gates "640k should be enough for everybody" ... mir gehen hier zu Hause langsam die Class-C Adressen aus.... hätte ich auch nie für möglich gehalten.
Zum Thema: VM & Container wird wegen der Hardware-Schnittstellen (USB) nicht einfach.... Ich werde es mit nem RPI probieren. Das wird wahrscheinlich schon etliche Erkenntnisse liefern.
Mal sehen welche Module alle fehlen, die ich im Laufe der Jahre händisch eingepflegt hatte....
Wenn du die Möglichkeiten hast, einen Host aufzusetzen, möchte ich dich ermutigen, trotz USB-Themen tatsächlich einmal den Weg mit VM zu probieren. Dadurch ergeben sich vielfältige Möglichkeiten in Bezug auf Wartung, Backup, Verschieben usw.
Bei Containern ist USB teilweise recht tricky, bei VM ist das überhaupt kein Thema. Ich habe 5 Jahre ESXi eingesetzt und nun Proxmox, absolut keine Probleme mit USB-Durchreiche.
....versuch das mal mit Hyper-V ::)
Hyper-V wäre tatsächlich aus diesem Grund das falsche Produkt für diesen Anwendungsfall. Aber andere Mütter haben auch hübsche Töchter.
Und per se würde ich jetzt nicht sagen, das VM einfacher als Container beim USB durchreichen ist .. hat beide seine "tricky Stellen".
Bei einem Neuaufbau "meines" Systems würde ich deshalb heute darauf achten, das die Schnittstellen Netzwerkfähig sind, so das man Hausautomatisierung (FHEM) und Schnittstelle trennen kann.
Aber DAS führt zu einer anderen Diskussion ....
Wieso musst du eigentlich updaten? Was hindert dich daran, ein zweites FHEM aufzusetzen? Oder hast du einfach nur Langeweile? ;)
Ich habe 3 im Einsatz. So geht zB nicht ganz so viel schief, wenn mal was mit einem FHEM nicht stimmt. Und der Haupt-FHEM sichert die Config täglich, die SD-Karte wöchentlich auf ne NAS. Dazu immer ein Reserve-PI und Reserve-ZWAVE-Stick
....warum "muss".... nun, ab und zu kommt dann doch die ein oder andere Begehrlichkeit des Weges, wie aktuell die gewünschte Integration eines auvisio IR Tranceivers, oder vllt. eine Alexa integration... da kann ich mit meiner Konfig hier keinen mehr fragen...
Nur noch ein kleiner Hinweis - aus eigener Erfahrung - warum auch das Linux nicht zu alt werden sollte: Für z.B. TLS/SSL Verbindungen werden die Zertifikate irgenwann zu alt und es funktioniert "plötzlich" z.B. kein HTTPS mehr, weil die Gegenstelle dann nur noch sagt: Certificate expired...
Bei Geräten mit Netzwerkkontakt (Egal ob Intern/Extern, Senden/Empfangen) sollte man grundsätzlich auf eine Gewisse "Aktualität" achten. Dazu passiert mittlerweile im Netz einfach zu viel ... und wer ist schon gerne "Opfer" ...
Ich habe nun endlich mein leider viel zu altes FHEM auch aktualisiert.
Es war ca. 2,5 Jahre alt und was soll ich sagen: Alles problemlos!
Vielen Dank an alle Entwickler!
Übrigens: Schnell mal ein Testsystem als Kopie aufsetzen und darin das Update proben ist echt einfach.
Falls von Interesse in Kurzform:
su - fhem
# Daten vom produktiven FHEM kopieren:
rsync -av --delete fhem:/opt/fhem/* /opt/fhem/
rsync -av --delete fhem:/var/log/fhem/* /var/log/fhem/
# FHEM starten:
cd /opt/fhem/fhem && ./fhem.pl fhem.cfg >/tmp/fhem-start.log 2>&1 &
telnet localhost 7072
# Andere Farbe und Titel einstellen, um es besser vom produktiven FHEM unterscheiden zu können:
attr WEB styleData {\
"f18": {\
"Pinned.menu": "true",\
"hidePin": "true",\
"cols.bg": "ff825c",\
"cols.fg": "000000",\
"cols.link": "278727",\
"cols.evenrow": "F8F8E0",\
"cols.oddrow": "F0F0D8",\
"cols.header": "E0E0C8",\
"cols.menu": "D7FFFF",\
"cols.sel": "A0FFFF",\
"cols.inpBack": "FFFFFF",\
"savePinChanges": true\
}\
}
attr WEB title ***FHEM-TEST***
quit
LG,
Stephan.