FHEM Tablet UI – Testumgebung als Schutz vor umfangreichen Updates

Aktuell bin ich dabei, meine Tablet UI Umgebung zu optimieren und die Dateien für eine aktualisierte Veröffentlichung auf meinem Google Drive zur Verfügung zu stellen. Ich war schon fast mit allen Dateien durch, als ich im Forum gesehen habe, dass es wieder eine neue Version der FHEM Tablet Oberfläche gibt. Mittlerweile sind wir bei Version 2.5 angekommen. Glücklicherweise hatte ich in letzter Zeit noch kein Update gemacht und so konnte ich mir erst einmal Gedanken machen, wie ich mit so umfangreichen Änderungen, wie sie aktuell in der 2.5er Version zu finden sind, am besten umgehe.

Die neueste Version wurde auch in einigen Layoutfunktionen angepasst, so dass wieder einmal einige Nachbesserungen in der eigenen Umgebung notwendig werden. Je nach Umfang der eigenen Dateien kann das schon mal einiges an Zeit in Anspruch nehmen. Also wäre es eigentlich schön, wenn auch nach einem Update zunächst die bisherige Version bestehen bleibt und wie gewohnt funktioniert.

Aktuelle Startseite meiner FTUI Oberfläche in FHEM

Zusätzliche Produktionsumgebung anlegen

Da ich FTUI in die Update Funktion von FHEM integriert habe, bekomme ich mit jedem Aufruf von „update“ in der FHEM Befehlszeile auch das Update von FTUI. Damit mir zukünftige größere Änderungen nicht mein ganzes Layout zerschiessen, habe ich mich daher entschlossen, zusätzlich mit einer Testumgebung für das FTUI zu arbeiten. Hierzu habe ich einfach eine zweite Version innerhalb FHEM angelegt und diese neue Version als Produktionsumgebung genutzt.

Das Update von FTUI kann übrigens mit folgendem Befehl in die Update-Funktion von FHEM eingebunden werden:

update add https://raw.githubusercontent.com/knowthelist/fhem-tablet-ui/master/controls_fhemtabletui.txt

Für die Nutzung einer Testumgebung sollte man wissen, dass die Updates immer im Pfad „/<fhem-Pfad>/www/tablet/“ abgelegt werden. Für diesen Pfad wird auch überall erläutert, wie man den Aufruf der Tablet Oberfläche in FHEM einrichtet.

Also machen wir nun diese Umgebung zur Testumgebung. Bei jedem zukünftigen Update wird diese Testumgebung dann aktualisiert. Für die neue Produktionsumgebung habe ich mir den kompletten Pfad „tablet/*“ in das neue Verzeichnis „tablet_prod“ kopiert. Da ich hierbei wieder mal Probleme mit den Rechten hattee, habe ich das Verzeichnis wie folgt angelegt (während ich im Verzeichnis „www“ stehe“:

sudo mkdir tablet_prod
sudo chmod 777 tablet_prod
sudo chown -R fhem:dialout /opt/fhem

Zusätzlich muss dann nur noch der Aufruf in FHEM angelegt werden:

define ftui_prod httpsrv tablet_prod/ ./www/tablet_prod FTUI_Prod

Das war es im Prinzip auch schon. Ab sofort haben wir eine FTUI-Umgebung, die durch ein Update nicht sofort geändert wird.

Arbeiten mit den beiden Umgebungen

Wir haben also jetzt zwei Umgebungen. Die Testumgebung, die bei jedem Update geändert wird und unsere Produktionsumgebung, die nur noch mit einem manuellen Eingriff aktualisiert werden kann.

Nach jedem Update kann man nun die Testumgebung aufrufen und prüfen, ob noch alles wie gewohnt läuft. Falls das Update evtl. das bestehende Layout verändert, kann man nun zunächst die eigenen Dateien in der Testumgebung (<fhem-Pfad>/www/tablet/) anpassen und testen. Hat man alle notwendigen Anpassungen vorgenommen, muß man eigentlich nur noch die Dateien aus dem Testverzeichnis ins Produktionsverzeichnis kopieren.

Steht man im Vereichnis „www“ dann sieht der Aufruf auf dem Raspi wie folgt aus:

cp -r -p test/* test_prod

Da ich mir mittels Samba die Verzeichnisse des Raspi auch unter Windows verfügbar gemacht habe, kann ich das Kopieren natürlich auch direkt mit Windows durchführen. Noch schöner wäre es wohl aber auch, wenn man das Kopieren von FHEM direkt aufrufen könnte. Hierzu nutzen wir wieder einmal ein DOIF:

define di_FTUI_Copy ("$SELF:W_Copy: on")({system ('sudo cp -r -p /opt/fhem/www/tablet/* /opt/fhem/www/tablet_neu > /dev/null 2>&1 &')})

Dann müssen noch ein paar Attribute für das DOIF definiert werden:

attr di_FTUI_Copy setlist W_Copy:on
attr di_FTUI_Copy readingslist W_Copy
attr di_FTUI_Copy do always

DOIF für das Ausführen des Copy Befehls auf Betriebssystemebene

Bei dem „system“ Befehl könnte ich übrigens mal die Hilfe von einem Profi gebrauchen. Es wird immer „-1“ zurück gegeben und damit ein Fehler erzeugt. Der Befehl ist aber richtig und funktioniert auch. Ist nur etwas unschön, dass im DOIF immer ein Fehler ausgewiesen wird.

Nun kann mit dem Befehl „set di_FTUI_Copy W_Copy on“ der Kopiervorgang gestartet werden. Im FTUI könnte man sich z.B. einen Button dafür anlegen.

12 comments

  1. Hallo.
    der „return code -1“ könnte daher rühren, dass der Befehl mit „&“ im Hintergrund ausgeführt wird und somit die Verbindung zum rufenden Prozess nicht mehr besteht. Der „System“ Aufruf bekommt die Rückmeldung des Unix Kommandos nicht mehr mit.
    Gruß
    Christian

  2. Hallo nochmal 🙂
    Deine Testumgebung beinhaltet in dieser Variante leider nur das FTUI, was ja schon mal ein Anfang ist. Zum testen habe ich mir eine zweite FHEM Umgebung (nur die Software) aufgebaut, was durch die Implementierung in Perl recht einfach ist. Hardware abhängige Module müssen dann natürlich im Nachgang getestet werden, jedoch habe ich so mehr Rechnerpower zur Verfügung, was ja auch nicht so schlecht ist.
    Gruß
    Christian

  3. Danke für de Hinweis. Das macht Sinn.

  4. Ja, daran habe ich auch schon mal gedacht. Ich habe noch einen unbenutzten Raspi 3 auf den ich die FHEM Umgebung umziehen wollte. Dann würde ich meinen alten Raspi evtl. auch als Testsystem nutzen.

  5. Für das Entwickeln und Testen von Änderungen im FHEM verwende ich eine Oracle Solaris Zone (okay, dass ist etwas abgefahren, aber Virtualisierung interessiert mich halt auch ).
    Solange man nur Perl und das Internet nutzt läuft das echt gut. Für die Anbindung von EnOcean habe ich mir einen CunX mit LAN Anschluss zugelegt, über den ich meine Eltako-Rollosteuerung erreichen möchte. Das ist jedoch alles noch in der Umsetzung 😉
    Ein Apache Web Server für die Darstellung mit smatvisu und ein mySQL Server läuft auch performanter.
    Gruß
    Christian

  6. Der Befehl wird bei mir aus FHEM heraus nicht ausgeführt. Vielleicht weil der Benutzer nicht die richtigen Berechtigung hat?

    define di_FTUI_Copy („$SELF:W_Copy: on“)({system (’sudo cp -r -p /opt/fhem/www/tablet/* /opt/fhem/www/tablet_neu > /dev/null 2>&1 &‘)})

  7. Das ist seltsam. Mit „sudo“ sollte es eigentlich keine Rechteprobleme geben. Hast du mal versucht auf dem Raspberry direkt den Befehl „sudo cp -r…“ auszuführen? Hast du auch das Verzeichnis „tablet_neu“ zunächst von Hand angelegt?

  8. N’Abend Jürgen,

    Als Anregugng:
    Für das Kopieren auf ‚Prod‘ ist rsync meiner Meinung nach sinniger, da es mit –delete auch die nach einem Update ggf. gelöschten Dateien in ‚Prod‘ ebenfalls löscht und die beiden Verzeichnisse so defititiv identisch bleiben.

    Gruss
    Holger

    P.S.: Tolles Blog! Hast einen neuen Stammgast. 😉

  9. Herzlichen Dank für den guten Hinweis. Ich schau mir den Befehl mal genauer und und werde ihn dann im Blog anpassen. In der Tat wäre eine echte Synchronisation noch vorteilhafter.

  10. Hallo zusammen.
    Es kommt darauf an, ob der Benutzer eine Berechtigung für sudo hat. Sollte also fhem unter einem eigens eingerichtetem Benutzer laufen, so muss dieser Benutzer in /etc/sudoers
    eingetragen werden siehe hierzu https://www.raspberrypi.org/forums/viewtopic.php?f=63&t=7774
    Ich habe leider gerade keinen rp zur Nachprüfung…sorry.

    Gruß
    Christian

  11. Hi Jürgen,

    super Blog-Eintrag. Stellst du auch deine HTML-Datei zur Verfügung? Mich würde die eine oder andere Umsetzung brennend interessieren. 🙂

    VG
    Christoph

  12. Das kann ich gerne nochmal machen. Hatte vor einiger Zeit meine Oberfläche nochmal komplett umgestellt und kann diese gerne demnächst nochmal zur Verfügung stellen.

Leave a Reply

Your email address will not be published. Required fields are marked *

*

Why ask?

x

Check Also

Tibber Erfahrungen nach drei Monaten

Seit Mitte April nutzen wir die dynamischen Strompreise von Tibber*. Nach dem ersten vollen Monat ...