Hauptmenü

Updates

Begonnen von P.A.Trick, 09 Mai 2021, 09:07:49

Vorheriges Thema - Nächstes Thema

P.A.Trick

Hallo Jens, erst einmal vielen Dank für das coole Frontend. Ich bin durch den Stammtisch darauf aufmerksam geworden und
bin fleißig am testen.
Eine Frage umwandert mich aber. Wie kann ich am geschicktesten die Version aktualisieren? Ist es geplant, den FHEM Update
Mechanismus dafür nutzen zu können?
Wenn nicht, wie kann ein einzelnes Verzeichnis via git clonen? Hast du da ein Beispiel?
Danke und Gruß
Patrick
Cubietruck,RPI,QNAP Ts-419p+, FS20, FRITZ!DECT200, 7 MAX! Thermostate, 3 MAX! Fensterkontakte, Kodi, CUL V3.3, EM1000S, LW12, LD382, HUE, HM-CFG-USB-2, 1x HM-LC-SW1-FM, 2x HM-LC-SW2-FM, 2x HM-LC-Sw1PBU-FM, 3xHM-LC-Bl1PBU-FM,HM-SEC-RHS, 2xHM-SEC-SD,HM-WDS30-T-O, 3x HM-LC-Dim1TPBU-FM, RPI+AddOn

CoolTux

Hallo Patrick,

Ich bin zwar nicht Jens kann Dir aber sagen das es geplant ist die FHEMapp mit in den FHEM Update Prozess ein zu beziehen. Wird aber noch etwas dauern.


Grüße
Marko
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

P.A.Trick

Zitat von: CoolTux am 09 Mai 2021, 09:19:24
Hallo Patrick,

Ich bin zwar nicht Jens kann Dir aber sagen das es geplant ist die FHEMapp mit in den FHEM Update Prozess ein zu beziehen. Wird aber noch etwas dauern.


Grüße
Marko

Sehr schön! Danke dir Marko.
Cubietruck,RPI,QNAP Ts-419p+, FS20, FRITZ!DECT200, 7 MAX! Thermostate, 3 MAX! Fensterkontakte, Kodi, CUL V3.3, EM1000S, LW12, LD382, HUE, HM-CFG-USB-2, 1x HM-LC-SW1-FM, 2x HM-LC-SW2-FM, 2x HM-LC-Sw1PBU-FM, 3xHM-LC-Bl1PBU-FM,HM-SEC-RHS, 2xHM-SEC-SD,HM-WDS30-T-O, 3x HM-LC-Dim1TPBU-FM, RPI+AddOn

Jamo

Hallo Patrick,
evtl. hilfts: Ich habe eine Samba freigabe eingerichtet. Lade mir dann von https://github.com/jemu75/fhemApp oben rechts mithilfe des gruenen Buttons den .zip file auf den PC runter. Den Zip entpacken, und dann nur das fhemapp Verzeichnis über das Samba Verzeichnis auf den Linux Rechner. Da habe ich dann ein Shell script, das alles andere (backup, hinkopieren der templates, rechteanpassung ) dann quasi auf Knopfdruck macht. Das dauert pro neuem release etwa 2 minuten.

Frohen Muttertag!
Bullseye auf iNUC, Homematic + HMIP(UART/HMUSB), Debmatic, HUEBridge, Zigbee/Conbee III, FB7690, Alexa (fhem-lazy), Livetracking, LaCrosse JeeLink, LoRaWan / TTN / Chirpstack, Sonos, ESPresence

jemu75

Zitat von: CoolTux am 09 Mai 2021, 09:19:24
Hallo Patrick,

Ich bin zwar nicht Jens kann Dir aber sagen das es geplant ist die FHEMapp mit in den FHEM Update Prozess ein zu beziehen. Wird aber noch etwas dauern.


Grüße
Marko

Die perfekte Antwort. Danke Dir Marko.  :)

P.A.Trick

Um einen Ordner aus dem Repo herauszuholen gibt es git archive.

git archive HEAD www -o fhemApp_latest.zip

Vielleicht kann es jemand gebrauchen.
Cubietruck,RPI,QNAP Ts-419p+, FS20, FRITZ!DECT200, 7 MAX! Thermostate, 3 MAX! Fensterkontakte, Kodi, CUL V3.3, EM1000S, LW12, LD382, HUE, HM-CFG-USB-2, 1x HM-LC-SW1-FM, 2x HM-LC-SW2-FM, 2x HM-LC-Sw1PBU-FM, 3xHM-LC-Bl1PBU-FM,HM-SEC-RHS, 2xHM-SEC-SD,HM-WDS30-T-O, 3x HM-LC-Dim1TPBU-FM, RPI+AddOn

Benni

#6
Ich habe mir auch mit git was eingerichtet:

Ich habe einen Clone des FHEMAPP github repository auf meinem FHEM-Server, den ich bei Bedarf einfach per git pull updaten kann.

Den Ordner fhemapp/www/fhemapp habe ich per ln in direkt in meine FHEM-Installation unter www verlinkt.
Meine eigenen Templates (heißen alle templ_my*.json) habe ich in der FHEM-Installation im Verzeichnis conf liegen (s.u.) und dann, ebenfalls per ln ins cfg-Verzeichnis der fhemapp installation rein-gelinkt.
Für meine Änderungen habe ich einen eigenen lokalen branch "my", in dem ich arbeite und der standardmäßig ausgecheckt ist.

Spätestens bei einem Update committe ich alles im Branch "my", checke den "master"-Branch aus, und hole den aktuellen Stand per git pull, danach checke ich wieder meinen branch aus und bringe den mit git rebase master auf den aktuellen Stand.

Eigentlich ziemlich Easy!

Die eigenen Templates liegen bei mir deshalb im conf-Ordner in der FHEM-Installation (normalerweise /opt/fhem/conf), weil ich die dann direkt im FHEMWEB editieren kann.
Damit das klappt, muss ich die nur noch in FHEM bekannt machen. Das habe ich bei mir mit einem einfachen notify geregelt, das genau das beim FHEM-Start für mich übernimmt:


defmod nyFhemAppEditFiles notify global:INITIALIZED {\
$data{confFiles}{'templ_my.*\.json'} = '0';;\
$data{confFiles}{'config.json'} = '0';;\
}


Wie ich gerade sehe, liegt dort aus dem selben Grund auch meine config.json :)

Weiterer Vorteil ist, das conf-Verzeichnis ist standardmäßig Teil des fhem-Backups und somit werden die Dateien bei mir täglich automatisch mit gesichert.

Klingt komplizierter, als es ist.
Wenn es einmal eingerichtet ist, dann ist das flott und einfach.

Ach ja, bei der Ersteinrichtung ggf. auf die Berechtigungen achten. FHEM braucht halt die nötigen Berechtigungen fürs Editieren (chown fhem:dialout ...)

gb#

Wolle02

Zitat von: Benni am 09 Mai 2021, 11:53:56
Ich habe mir auch mit git was eingerichtet:

Ich habe einen Clone des FHEMAPP github repository auf meinem FHEM-Server, den ich bei Bedarf einfach per git pull updaten kann.

Den Ordner fhemapp/www/fhemapp habe ich per ln in direkt in meine FHEM-Installation unter www verlinkt.
Meine eigenen Templates (heißen alle templ_my*.json) habe ich in der FHEM-Installation im Verzeichnis conf liegen (s.u.) und dann, ebenfalls per ln ins cfg-Verzeichnis der fhemapp installation rein-gelinkt.
Für meine Änderungen habe ich einen eigenen lokalen branch "my", in dem ich arbeite und der standardmäßig ausgecheckt ist.

Spätestens bei einem Update committe ich alles im Branch "my", checke den "master"-Branch aus, und hole den aktuellen Stand per git pull, danach checke ich wieder meinen branch aus und bringe den mit git rebase master auf den aktuellen Stand.

Eigentlich ziemlich Easy!


:o :o :o
Junge, Junge, da brauch ich erst mal nen Wörterbuch, damit ich das überhaupt verstehe. Und dann kommt er mit "Eigentlich ziemlich easy" um die Ecke.  ;D ;D

Ich mach das von Anfang an schon so wie Jamo; nur per NFS. Dann sitzen auch gleich die Rechte richtig.  8)

jemu75

Betrachtet die aktuellen Lösungen mal als Zwischenstand. Die sind sicher noch nicht perfekt, aber auf jeden Fall besser, als immer alles händisch zu kopieren - so, wie ich das aktuell  noch mache...  ;D

Wie schon geschrieben, strebe ich ein Update der App direkt in FHEM an, damit das Updaten einfacher wird. Weiterhin wird so auch das Risiko minimiert, dass man seine eigene Konfiguration oder eigene Template aus Versehen überschreibt. Aktuell gibt es noch ein paar andere Featurewünsche, die ich gern umsetzen möchte. Danach nehme ich mir das Thema Updates vor.  :)

Benni

Zitat von: jemu75 am 09 Mai 2021, 20:46:07
Wie schon geschrieben, strebe ich ein Update der App direkt in FHEM an, damit das Updaten einfacher wird. Weiterhin wird so auch das Risiko minimiert, dass man seine eigene Konfiguration oder eigene Template aus Versehen überschreibt.

Hallo Jens,

ich fände es prima, wenn dabei grundsätzlich die Möglichkeit erhalten bliebe, fhemapp unabhängig von der restlichen FHEM-Installation updaten zu können.

gb#

jemu75

Zitat von: Benni am 10 Mai 2021, 21:49:53
Hallo Jens,

ich fände es prima, wenn dabei grundsätzlich die Möglichkeit erhalten bliebe, fhemapp unabhängig von der restlichen FHEM-Installation updaten zu können.

gb#

Ja, so sehe ich das auch. Soweit ich das bisher verstehe, kann ich in FHEM über den Befehl update all die Updates für FHEMApp realisieren. Über update add kann man das Update der App in das normale Update integrieren. Es wären also beide Varianten möglich. Aber ich muss mich zu dem Thema noch etwas aufschlauen.  ;)

Beta-User

Das hängt im Detail  davon ab, wie updates angeboten werden. Via seperater control-file (update oder update all schlägt durch oder man kann isoliert updaten) oder als update  aus dem svn (dann ist es Teil von update; mir würde es sehr gefallen, wenn das via svn käme!).

Es sollte aber doch - so oder so - möglich sein, via "exclude" den fhemapp-Teil auszuschließen.

@benni: Was ist die Motivation dahinter?
Auch andere (js-) scripte, die von FHEMWEB genutzt werden, werden doch in der Regel über den normalen update-Weg aktualisiert? Und - wenn ich es richtig verstanden habe - eigene templates braucht man "nur" anders zu benennen, dann werden die beim Aktualisieren nicht überschrieben.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Benni

Zitat von: Beta-User am 11 Mai 2021, 08:09:07
Es sollte aber doch - so oder so - möglich sein, via "exclude" den fhemapp-Teil auszuschließen.

@benni: Was ist die Motivation dahinter?
Auch andere (js-) scripte, die von FHEMWEB genutzt werden, werden doch in der Regel über den normalen update-Weg aktualisiert? Und - wenn ich es richtig verstanden habe - eigene templates braucht man "nur" anders zu benennen, dann werden die beim Aktualisieren nicht überschrieben.

Nein! Ich möchte nicht den fhemapp-Teil ausschließen, sondern den ganzen Rest und NUR FHEMAPP updaten können.
Das lässt sich mit exclude nicht sinnvoll abbilden!

Die Motivation dahinter ist, dass ich meine FHEM-Produktivumgebung nur sehr selten update (2-4 mal im Jahr).
Fhemapp ist erst mal gar nicht von irgendwelchen Features in FHEM selbst abhängig, da es für mein Verständnis sehr Basisnahe Funktionalität (jsonlist2).
fhemapp selbst hat im Prinzip keinen Einfluss auf meine bestehende FHEM-Installation und kann somit einfach jederzeit unabhängig von FHEM upgedatet werden ohne dort etwas zu "zerstören".
Das würde ich gerne so nutzen, sowieso in der aktuell noch andauernden Hoch-Entwicklungs-Phase.

Für mich wäre es aber auch kein Problem, wenn ich mein bisheriges vorgehen beibehalten müsste, um das für mich zu realisieren.

gb#

Beta-User

Zitat von: Benni am 11 Mai 2021, 10:28:15
Das würde ich gerne so nutzen, sowieso in der aktuell noch andauernden Hoch-Entwicklungs-Phase.
Ah, ok, so herum ist es verständlich.

Für die Phase der schnellen Weiterentwicklung finde ich das auch passend, hatte aber verstanden, dass sich das langsam dem Ende nähert...

(Ich mache das mit den Updates übrigens via wget des zip und dann per ssh mit mc: Der kann nämlich das zip auch direkt öffnen und dann den fhemapp-Teil rauskopieren).
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

frank

man kann doch bei update auch explizit files angeben. sogar als regexp.


update [-noSSL] [<fileName>|all|check|checktime|force] [http://.../controlfile]
or
update [add source|delete source|list|reset]

Update the FHEM installation. Technically this means update will download the controlfile(s) first, compare it to the local version of the file in the moddir/FHEM directory, and download each file where the attributes (timestamp and filelength) are different. Upon completion it triggers the global:UPDATE event.
-noSSL will use the http protocol instead of https, which might be necessary for some older distributions with outdated ciphers.
With the commands add/delete/list/reset you can manage the list of controlfiles, e.g. for thirdparty packages. Notes:

    The contrib directory will not be updated.
    The files are automatically transferred from the source repository (SVN) to the web site once a day, at 7:45 CET / CEST.
    The all argument is default.
    The force argument will disregard the local file.
    The check argument will only display the files it would download, and the last section of the CHANGED file.
    checktime is like check, but additionally displays the update timestamp of the new file, which is usually the version date +1 day.
    Specifying a filename will only download matching files (regexp).

See also the restore command.
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

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

Zitat von: Benni am 12 Mai 2021, 06:53:21
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.

Zitat
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!).
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

yersinia

@jemu75: warum nicht von ftui3 abschauen? Da wird das Update auch direkt aus dem git gezogen.
update all https://raw.githubusercontent.com/knowthelist/ftui/master/controls_ftui.txt
https://github.com/knowthelist/ftui
viele Grüße, yersinia
----
FHEM 6.3 (SVN) on RPi 4B with RasPi OS Bullseye (perl 5.32.1) | FTUI
nanoCUL->2x868(1x ser2net)@tsculfw, 1x433@Sduino | MQTT2 | Tasmota | ESPEasy
VCCU->14xSEC-SCo, 7xCC-RT-DN, 5xLC-Bl1PBU-FM, 3xTC-IT-WM-W-EU, 1xPB-2-WM55, 1xLC-Sw1PBU-FM, 1xES-PMSw1-Pl

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.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Benni

#20
Zitat von: Beta-User am 12 Mai 2021, 08:36:41
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

Zitat von: jemu75 am 13 Mai 2021, 13:25:06
Kann man eigentlich aus der FHEM Kommandozeile ein lokales Script aufrufen?

Ja kann man. Einfach in der Kommandozeile eingeben:
"/opt/fhem/test.sh"

Zwar nicht mit einem Skript, aber über Systembefehle steuere ich zB. meinen fhemApp dummy per 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\"")
}
}


VG Sebastian

jemu75

Zitat von: binford6000 am 13 Mai 2021, 17:53:49
Ja kann man. Einfach in der Kommandozeile eingeben:
"/opt/fhem/test.sh"

Zwar nicht mit einem Skript, aber über Systembefehle steuere ich zB. meinen fhemApp dummy per 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\"")
}
}


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

Zitat von: binford6000 am 13 Mai 2021, 17:53:49
Ja kann man. Einfach in der Kommandozeile eingeben:
"/opt/fhem/test.sh"

Zwar nicht mit einem Skript, aber über Systembefehle steuere ich zB. meinen fhemApp dummy per 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\"")
}
}


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!
Bullseye auf iNUC, Homematic + HMIP(UART/HMUSB), Debmatic, HUEBridge, Zigbee/Conbee III, FB7690, Alexa (fhem-lazy), Livetracking, LaCrosse JeeLink, LoRaWan / TTN / Chirpstack, Sonos, ESPresence

binford6000

#25
Zitat von: Jamo am 13 Mai 2021, 20:26:44
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 :
{
  "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:
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:
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

#26
Zitat von: binford6000 am 13 Mai 2021, 20:31:08
Klaro  :)
Template :
Danke - super. Viel Tipperei erspart, und funktioniert out-of-the-box!

Beste Grüsse!
Bullseye auf iNUC, Homematic + HMIP(UART/HMUSB), Debmatic, HUEBridge, Zigbee/Conbee III, FB7690, Alexa (fhem-lazy), Livetracking, LaCrosse JeeLink, LoRaWan / TTN / Chirpstack, Sonos, ESPresence

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.

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


Im log von FHEM wird folgender Eintrag generiert:

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

Zitat von: jemu75 am 14 Mai 2021, 13:58:25
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.

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


Im log von FHEM wird folgender Eintrag generiert:

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

Zitat von: binford6000 am 14 Mai 2021, 17:05:30
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#



jemu75

Zitat von: Benni am 14 Mai 2021, 22:34:02
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#

Sehr gutes Feedback. Sowas bringt das Projekt doch letztlich voran! Also dann geht's zurück ans Reisbrett für die nächste (bessere) Lösung.  :)

P.A.Trick

Zitat von: Benni am 09 Mai 2021, 11:53:56
Ich habe mir auch mit git was eingerichtet:

Ich habe einen Clone des FHEMAPP github repository auf meinem FHEM-Server, den ich bei Bedarf einfach per git pull updaten kann.

Den Ordner fhemapp/www/fhemapp habe ich per ln in direkt in meine FHEM-Installation unter www verlinkt.
Meine eigenen Templates (heißen alle templ_my*.json) habe ich in der FHEM-Installation im Verzeichnis conf liegen (s.u.) und dann, ebenfalls per ln ins cfg-Verzeichnis der fhemapp installation rein-gelinkt.
Für meine Änderungen habe ich einen eigenen lokalen branch "my", in dem ich arbeite und der standardmäßig ausgecheckt ist.

Spätestens bei einem Update committe ich alles im Branch "my", checke den "master"-Branch aus, und hole den aktuellen Stand per git pull, danach checke ich wieder meinen branch aus und bringe den mit git rebase master auf den aktuellen Stand.

Eigentlich ziemlich Easy!

Die eigenen Templates liegen bei mir deshalb im conf-Ordner in der FHEM-Installation (normalerweise /opt/fhem/conf), weil ich die dann direkt im FHEMWEB editieren kann.
Damit das klappt, muss ich die nur noch in FHEM bekannt machen. Das habe ich bei mir mit einem einfachen notify geregelt, das genau das beim FHEM-Start für mich übernimmt:


defmod nyFhemAppEditFiles notify global:INITIALIZED {\
$data{confFiles}{'templ_my.*\.json'} = '0';;\
$data{confFiles}{'config.json'} = '0';;\
}


Wie ich gerade sehe, liegt dort aus dem selben Grund auch meine config.json :)

Weiterer Vorteil ist, das conf-Verzeichnis ist standardmäßig Teil des fhem-Backups und somit werden die Dateien bei mir täglich automatisch mit gesichert.

Klingt komplizierter, als es ist.
Wenn es einmal eingerichtet ist, dann ist das flott und einfach.

Ach ja, bei der Ersteinrichtung ggf. auf die Berechtigungen achten. FHEM braucht halt die nötigen Berechtigungen fürs Editieren (chown fhem:dialout ...)

gb#

Super Idee, bin ich gar nicht drauf gekommen. Ich habe das mal eingerichtet und es ist super. Vielen Dank für den Tipp.
PS: Läuft im fhemdocker super, da hat man dann auch keine Rechte Probleme.
Cubietruck,RPI,QNAP Ts-419p+, FS20, FRITZ!DECT200, 7 MAX! Thermostate, 3 MAX! Fensterkontakte, Kodi, CUL V3.3, EM1000S, LW12, LD382, HUE, HM-CFG-USB-2, 1x HM-LC-SW1-FM, 2x HM-LC-SW2-FM, 2x HM-LC-Sw1PBU-FM, 3xHM-LC-Bl1PBU-FM,HM-SEC-RHS, 2xHM-SEC-SD,HM-WDS30-T-O, 3x HM-LC-Dim1TPBU-FM, RPI+AddOn