Upgrade uralt-fhem auf aktuell...

[dougie]

Ich oute mich hier mal als der ultimative nicht-update-Nerd, der immer noch mit

Code Auswählen Erweitern

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.

Code Auswählen Erweitern

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.

Code Auswählen Erweitern

PRETTY_NAME="Debian GNU/Linux 9 (stretch)"

[Wernieman]

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.

[betateilchen]

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.

[dougie]

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.

[Wernieman]

Ist 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 .....

[Frank_Huber]

An 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.

[dougie]

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

[Wernieman]

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 .....

[dougie]

...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!

[Wernieman]

einen 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" ....

[andies]

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!

[Ralli]

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.

[LuckyDay]

du kannst auch ein aktuelles Fhem bezüglich Variablen die deprecated sind , wieder freischalten
probieren musst du selber.
siehe Bild der Fhemversionen

[dougie]

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....

[Ralli]

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.