Updates

[jemu75]

Danke erstmal, dass ihr hier so aktiv dran seid. Ich bin auf dem Gebiet (FHEM update und svn) nicht wirklich fit. Deshalb liefere ich mal noch ein paar Infos zu dem Thema.
Das github-Repository von FHEMApp beinhaltet neben der eigentlichen App auch die komplette Entwicklungsumgebung. Diese ist für den Betrieb von FHEMApp also faktisch nicht von Relevanz.

Anbei mal die Struktur von dem Git-Repository:
+ docs/media
+ public
+ src
+ www/fhemapp
    + cfg
    + css
    + fonts
    + img
    + js
    apple-touch-icon.png
    favicon.png
    index.html
.browserslistrc
.env
.eslintrc.js
.gitignore
LICENSE
README.md
babel.config.js
package-lock.json
package.json
vue.config.js

Relevant ist nur das Verzeichnis www/fhemapp inkl. aller Unterverzeichnisse und Dateien mit Ausnahme des Unterverzeichnis ../cfg/
Zusätzlich werden die Dateien (insb. in den Verzeichnissen ../css/ und ../js/ beim "kompilieren" (Minimizen mit webpack) mit hashes versehen werden.
D.h. bei jedem Release bekommen die css-Dateien und js-Dateien andere Namen!
Damit müsste man ohnehin immer alle Dateien/Verzeichnisse "komplett" austauschen - also zuerst in FHEM löschen und dann neu rüber kopieren.
Da FHEMApp mit ca. 5MB recht klein ist, sollte das aber nicht all zu lange dauern.

Wenn ich das richtig verstanden habe, wird für den  Updateprozess mit FHEM eine "contrib-Datei" benötigt, in der alle relevanten Dateien aufgeführt sind.
Könnte man in dieser contrib-Datei auch Pfade und Ausschluß-Pfade angeben?
Also sowas wie:  Nimm alle Dateien und Unterverzeichnisse aus dem Repository-Pfad "/www/fhemapp/" mit Ausnahme von "/www/fhemapp/cfg"

Ich würde mich freuen, wenn wir zeitnah eine gute Lösung finden.  Bi  also auf eure Hinweise und Anregungen gespannt

[Benni]

Hallo Jens,

im Wiki ist der Update-Prozess von FHEM ganz gut beschrieben:

https://wiki.fhem.de/wiki/Update

Unter anderem auch die Repository-Verwaltung mittels controlfile:

https://wiki.fhem.de/wiki/Update#Syntax_controlfile

Wenn ich das richtig verstehe, ist allerdings ein Löschen von Dateien nicht vorgesehen, sondern lediglich ein Verschieben. Das würde bedeuten, dass durch die Neubenennung der Files mit der Zeit eine ganze Menge Datenmüll erzeugt würde.

Alternative wäre, ein fhemapp-Release zu erzeugen (keine Ahnung, in wie weit das dein Build-Prozess hergibt), das eindeutige, immer gleiche Namen für (funktional) gleiche Dateien hat.

gb#

[Beta-User]

Wenn ich das richtig verstehe, ist allerdings ein Löschen von Dateien nicht vorgesehen, sondern lediglich ein Verschieben. Das würde bedeuten, dass durch die Neubenennung der Files mit der Zeit eine ganze Menge Datenmüll erzeugt würde.

Löschen ist ein Problem, ja, siehe z.B. aktuell https://forum.fhem.de/index.php/topic,120939.0.html (1. Antwort von Rudi) wegen diverser Icons.

Alternative wäre, ein fhemapp-Release zu erzeugen (keine Ahnung, in wie weit das dein Build-Prozess hergibt), das eindeutige, immer gleiche Namen für (funktional) gleiche Dateien hat.

Das fände ich auch gut. Ansonsten würde man irgendeine Art Routine benötigen (FHEM-Modul?), die die Verzeichnisse bzw. bestimmte Inhalte löscht (was dort genau...?) und dann die aktuelle Fassung nachlädt. (Unter Linuxen wäre das bestimmt auch kein großes Ding, weil wget und unzip vermutlich auch den meisten Systemen vorhanden sind; unter Win geht aber z.B. Svn_GetFile() auch nicht, was die Basis sein könnte, um aktuelle Fassungen aus dem svn (contib) zu holen - was dort liegt, wird nämlich beim normalen "update" auch nicht mit aktualisiert.)
Das mit dem Modul wäre ggf. sowieso eine gute Idee, weil man dann FHEMApp nicht immer aktiv hätte und z.B. auch für verschiedene Nutzer verschiedene fhemapp-Verzeichnisse anlegen könnte und gleich den "Basis-JSON" (Pfad und Port etc.) generieren. (Ist aber ziemlich sicher noch nicht zuende gedacht!).

[yersinia]

@jemu75: warum nicht von ftui3 abschauen? Da wird das Update auch direkt aus dem git gezogen.

Code Auswählen Erweitern

update all https://raw.githubusercontent.com/knowthelist/ftui/master/controls_ftui.txt
https://github.com/knowthelist/ftui

[Beta-User]

...egal, ob die control-file nun auf den FHEM-eigenen Server zeigt oder nach irgendwo anders hin, das Problem mit den gehashten Dateinamen und der fehlenden "Löschwilligkeit" von update bleibt bestehen, ebenso das Thema, dass nicht das ganze repo einbezogen sein sollte, sondern nur ein Teil davon...

Auf die Schnelle habe ich das hier gefunden: https://cli.vuejs.org/config/#filenamehashing
Wenn das aktuell sein sollte, kann man das mit dem Hashing wohl abstellen.

[Benni]

Das mit dem Modul wäre ggf. sowieso eine gute Idee, weil man dann FHEMApp nicht immer aktiv hätte und z.B. auch für verschiedene Nutzer verschiedene fhemapp-Verzeichnisse anlegen könnte und gleich den "Basis-JSON" (Pfad und Port etc.) generieren. (Ist aber ziemlich sicher noch nicht zuende gedacht!).

Daran habe ich auch schon ein paar mal rum-gedacht, dass es eventuell praktisch wäre, wenn fhemapp direkt ein dediziertes Gegenstück auf FHEM-Seite hätte.
Ich bin da auch schon eine ganze Weile am hin und her überlegen ob es dafür wirklich ein eigenes Modul braucht, oder ob dafür ggf. auch ein einfaches Dummy-Device reichen würde, das wie von FHEMAPP gewohnt ein entsprechendes JSON in appOptions oder appConfig oder wie auch immer liefert.

Andererseits könnte man ein eigenes Modul mit entsprechenden Attributen für die Config ausstatten und den json dann erzeugen lassen. Eventuell könnte ein eigenes Modul auch nützlich sein, wenn es um die Anwendung von allowed o.ä. geht.

"(Ist aber ziemlich sicher noch nicht zu Ende gedacht!)"

gb#

[jemu75]

Kann man eigentlich aus der FHEM Kommandozeile ein lokales Script aufrufen?

Wenn ja, könnte man doch ein Script bauen, welches folgendes macht.
1) alle lokalen Verzeichnisse und Dateien aus opt/fhem/www/fhemapp/... löschen. (mit Ausnahme des Verzeichnisses cfg)
2) alle Verzeichnisse und Dateien von github "holen" und nach opt/fhem/www/fhemapp/... entpacken/kopieren (mit Ausnahme des Verzeichnisses cfg wenn dieses lokal noch nicht existiert)

Da die App sehr überschaubar ist und auch bleiben soll, geht das entpacken/kopieren aller Dateien sicher recht zügig.
Und das Problem mit den hashes in den Dateinamen wäre auch vom Tisch.

[binford6000]

Kann man eigentlich aus der FHEM Kommandozeile ein lokales Script aufrufen?

Ja kann man. Einfach in der Kommandozeile eingeben:

Code Auswählen Erweitern

"/opt/fhem/test.sh"

Zwar nicht mit einem Skript, aber über Systembefehle steuere ich zB. meinen fhemApp dummy per notify:

Code Auswählen Erweitern

fhemapp.d:.* {
if ($EVENT =~ /light/) {
fhem("\"sed -i 's/\"dark\": true,/\"dark\": false,/g' ./www/fhemapp/cfg/config.json\"")
}
elsif ($EVENT =~ /dark/) {
fhem("\"sed -i 's/\"dark\": false,/\"dark\": true,/g' ./www/fhemapp/cfg/config.json\"")
}
elsif ($EVENT =~ /on/) {
fhem("\"sed -i 's/\"debugMode\": false,/\"debugMode\": true,/g' ./www/fhemapp/cfg/config.json\"")
}
elsif ($EVENT =~ /off/) {
fhem("\"sed -i 's/\"debugMode\": true,/\"debugMode\": false,/g' ./www/fhemapp/cfg/config.json\"")
}
elsif ($EVENT =~ /debug_level/) {
my $level = (split ' ', $EVENT)[-1];
fhem("\"sed -i 's/\"debugLevel\": .*/\"debugLevel\": $level/g' ./www/fhemapp/cfg/config.json\"")
}
}

VG Sebastian

[jemu75]

Ja kann man. Einfach in der Kommandozeile eingeben:

Code Auswählen Erweitern

"/opt/fhem/test.sh"

Zwar nicht mit einem Skript, aber über Systembefehle steuere ich zB. meinen fhemApp dummy per notify:

Code Auswählen Erweitern

fhemapp.d:.* {
if ($EVENT =~ /light/) {
fhem("\"sed -i 's/\"dark\": true,/\"dark\": false,/g' ./www/fhemapp/cfg/config.json\"")
}
elsif ($EVENT =~ /dark/) {
fhem("\"sed -i 's/\"dark\": false,/\"dark\": true,/g' ./www/fhemapp/cfg/config.json\"")
}
elsif ($EVENT =~ /on/) {
fhem("\"sed -i 's/\"debugMode\": false,/\"debugMode\": true,/g' ./www/fhemapp/cfg/config.json\"")
}
elsif ($EVENT =~ /off/) {
fhem("\"sed -i 's/\"debugMode\": true,/\"debugMode\": false,/g' ./www/fhemapp/cfg/config.json\"")
}
elsif ($EVENT =~ /debug_level/) {
my $level = (split ' ', $EVENT)[-1];
fhem("\"sed -i 's/\"debugLevel\": .*/\"debugLevel\": $level/g' ./www/fhemapp/cfg/config.json\"")
}
}

VG Sebastian

Na dann ist das Thema doch schon so gut wie gelöst. Ich erstelle ein Script, welches ich in opt/fhem/www/fhemapp ablege. Diese kann man dann von fhem (respektive FHEMApp) aus aufrufen. Denke ich zu einfach oder gibt's noch irgendwelche Stolpersteine bei dieser Lösung?

[Jamo]

Ja kann man. Einfach in der Kommandozeile eingeben:

Code Auswählen Erweitern

"/opt/fhem/test.sh"

Zwar nicht mit einem Skript, aber über Systembefehle steuere ich zB. meinen fhemApp dummy per notify:

Code Auswählen Erweitern

fhemapp.d:.* {
if ($EVENT =~ /light/) {
fhem("\"sed -i 's/\"dark\": true,/\"dark\": false,/g' ./www/fhemapp/cfg/config.json\"")
}
elsif ($EVENT =~ /dark/) {
fhem("\"sed -i 's/\"dark\": false,/\"dark\": true,/g' ./www/fhemapp/cfg/config.json\"")
}
elsif ($EVENT =~ /on/) {
fhem("\"sed -i 's/\"debugMode\": false,/\"debugMode\": true,/g' ./www/fhemapp/cfg/config.json\"")
}
elsif ($EVENT =~ /off/) {
fhem("\"sed -i 's/\"debugMode\": true,/\"debugMode\": false,/g' ./www/fhemapp/cfg/config.json\"")
}
elsif ($EVENT =~ /debug_level/) {
my $level = (split ' ', $EVENT)[-1];
fhem("\"sed -i 's/\"debugLevel\": .*/\"debugLevel\": $level/g' ./www/fhemapp/cfg/config.json\"")
}
}

VG Sebastian

Hallo Sebastian,
könntest Du mir das template.json für dein fhemApp Steuerung schicken? Und auch den dummy? Das finde ich prima wie Du das umgesetzt hast!
Danke!

[binford6000]

Hallo Sebastian,
könntest Du mir das template.json für dein fhemApp Steuerung schicken? Und auch den dummy? Das finde ich prima wie Du das umgesetzt hast!
Danke!

Klaro 
Template :

Code Auswählen Erweitern

{
  "name": "fhemapp",
  "author": "binford6000",
  "date": "2021-05-08",
  "status": {
    "bar": ["state:on:100:success","state:off:100:error"],
    "error": [""]
  },
  "main": [
    {
      "leftBtn": ["state:off:mdi-debug-step-into","state:on:mdi-debug-step-out"],
      "leftClick": ["state:off:on","state:on:off"],
      "midBtn": ["theme:light:mdi-weather-sunny","theme:dark:mdi-weather-night"],
      "midClick": ["theme:dark:theme light","theme:light:theme dark"],
      "rightBtn": "mdi-menu",
      "rightMenu": ["1:debug_level 1", "2:debug_level 2", "3:debug_level 3", "4:debug_level 4", "5:debug_level 5"]
    }
  ],
  "info": {
    "left1": ["state:::mdi-android-debug-bridge"],
    "left2": ["state:on:ein","state:off:aus"],
  "mid1": ["theme::Theme:"],
  "mid2": ["theme:dark::mdi-weather-night","theme:light::mdi-weather-sunny"],
    "right1": ["debug_level::DebugLevel:"],
    "right2": ["debug_level::%n"]
  }
}


Dummy:

Code Auswählen Erweitern

defmod fhemapp.d dummy
attr fhemapp.d appOptions { \
  "template": "fhemapp",\
  "name": "fhemApp Steuerung",\
  "sortby": 2,\
  "home": false,\
  "dashboard": false,\
  "system": true\
}
attr fhemapp.d event-on-change-reading .*
attr fhemapp.d readingList debug_level theme
attr fhemapp.d setList on off debug_level:1,2,3,4,5 theme:light,dark
attr fhemapp.d stateFormat state level
attr fhemapp.d webCmd on:off:theme:debug_level

Notify:

Code Auswählen Erweitern

defmod fhemapp.n notify fhemapp.d:.* {\
if ($EVENT =~ /light/) {\
fhem("\"sed -i 's/\"dark\": true,/\"dark\": false,/g' ./www/fhemapp/cfg/config.json\"")\
}\
elsif ($EVENT =~ /dark/) {\
fhem("\"sed -i 's/\"dark\": false,/\"dark\": true,/g' ./www/fhemapp/cfg/config.json\"")\
}\
elsif ($EVENT =~ /on/) {\
fhem("\"sed -i 's/\"debugMode\": false,/\"debugMode\": true,/g' ./www/fhemapp/cfg/config.json\"")\
}\
elsif ($EVENT =~ /off/) {\
fhem("\"sed -i 's/\"debugMode\": true,/\"debugMode\": false,/g' ./www/fhemapp/cfg/config.json\"")\
}\
elsif ($EVENT =~ /debug_level/) {\
my $level = (split ' ', $EVENT)[-1];;\
fhem("\"sed -i 's/\"debugLevel\": .*/\"debugLevel\": $level/g' ./www/fhemapp/cfg/config.json\"")\
}\
}\

attr fhemapp.n devStateIcon {ReadingsVal($name,"state","inactive") eq "active" ? ".*:ios-on-blue:inactive" : ".*:ios-off:active"}


Theme und Debugmodus erfordern jeweils ein Reload rechts oben. DebugLevel greift sofort.

VG Sebastian

[Jamo]

Klaro 
Template :

Danke - super. Viel Tipperei erspart, und funktioniert out-of-the-box!

Beste Grüsse!

[jemu75]

Hallo,

ich habe mal ein bash-script erstellt, welches das Update von FEMApp automatisieren könnte.
Das kann künftig mit im Verzeichnis der app liegen und mit folgendem Befehl in der FHEM-Kommadozeile aufgerufen werden.

Code Auswählen Erweitern


"/opt/fhem/www/fhemapp/update.sh"


Im log von FHEM wird folgender Eintrag generiert:

Code Auswählen Erweitern


---------------------------------------------------------------
Fr 14. Mai 13:50:16 CEST 2021  Starting Update from FHEMApp...
---------------------------------------------------------------
Klone nach 'update' ...
sent 5,449,030 bytes  received 1,310 bytes  10,900,680.00 bytes/sec
total size is 5,442,680  speedup is 1.00
---------------------------------------------------------------
Fr 14. Mai 13:50:19 CEST 2021  Updating FHEMApp is finished.
---------------------------------------------------------------


Das Script sieht im Moment wie folgt aus siehe hier

Gern mal eure "Manöverkritik" zu dem Ansatz. 

[binford6000]

Hallo,

ich habe mal ein bash-script erstellt, welches das Update von FEMApp automatisieren könnte.
Das kann künftig mit im Verzeichnis der app liegen und mit folgendem Befehl in der FHEM-Kommadozeile aufgerufen werden.

Code Auswählen Erweitern


"/opt/fhem/www/fhemapp/update.sh"


Im log von FHEM wird folgender Eintrag generiert:

Code Auswählen Erweitern


---------------------------------------------------------------
Fr 14. Mai 13:50:16 CEST 2021  Starting Update from FHEMApp...
---------------------------------------------------------------
Klone nach 'update' ...
sent 5,449,030 bytes  received 1,310 bytes  10,900,680.00 bytes/sec
total size is 5,442,680  speedup is 1.00
---------------------------------------------------------------
Fr 14. Mai 13:50:19 CEST 2021  Updating FHEMApp is finished.
---------------------------------------------------------------


Das Script sieht im Moment wie folgt aus siehe hier

Gern mal eure "Manöverkritik" zu dem Ansatz. 

Hallo Jens,
hat fast auf Anhieb geklappt - musste nur git nachinstallieren.

Für alle FHEM Installationen welche auf Linux basieren funktioniert das denke ich ganz gut.
Aber es soll ja auch ein paar User geben die auf Windows setzen.

Mir persönlich würde ja auch ein Update Button innerhalb von fhemApp genügen.

VG Sebastian

[Benni]

hat fast auf Anhieb geklappt - musste nur git nachinstallieren.

Für alle FHEM Installationen welche auf Linux basieren funktioniert das denke ich ganz gut.
Aber es soll ja auch ein paar User geben die auf Windows setzen.

Hallo Jens,

genau da sehe ich halt auch das Problem! Das ganze funktioniert erst mal nur auf Linux und ob git und rsync überall auf Anhieb vorhanden sind? Das wäre auf jeden Fall eine zusätzliche Hürde.

Außerdem schaffst du damit quasi eine 3. Update-Variante, abseits von FHEM-update vom Standard SVN (1.) oder durch Einbindung von git repositories in den normalen Update-Prozess (2.)

Weitere Probleme sind damit auch nur bedingt gelöst. Durch das Ausschließen des cfg Verzeichnisses kannst du im Update-Prozess keine neuen Templates in diesem Folder ausliefern. So gesehen ist auch nur der Update-Prozess abgedeckt. Die Erstinstallation muss immer noch von Hand durchgeführt werden. Dies könnte bei der Verwendung von FHEM-Update mit git-Repository (o.g. Methode 2), soweit ich das sehe, mit abgedeckt werden.

Auch sind die Template-Files im cfg-Folder nach wie vor nicht ohne weiteres in FHEM editierbar, auch hier muss weiter manuell Hand angelegt werden.

Was allerdings auch immer in betracht gezogen werden muss, ist der ursprüngliche Ansatz, mit dem fhemapp kam, nämlich der, mit einem beliebigen http-Service unabhängig von FHEM eingesetzt werden zu können. Das ist immer noch eine legitime Anforderung!

Ich denke, mit so einem einfachen (bash-)Skript lässt sich wohl erst mal eine schnelle Interimslösung schaffen, die 80% (+) der Fälle abdeckt. Für's Erste besser als nix und besser, als wenn sich jeder eine eigene Lösung strickt.

Nichts desto trotz glaube ich, dass eine Integration in den FHEM-Update-Prozess langfristig die bessere Lösung ist.

Ich hoffe, es hat sich jetzt nicht zu sehr nach Kritik angehört, in allererster Linie waren das nur mal die Gedanken, die ich so spontan dazu hatte. 

gb#