nach dem das gröbste mit dem forum nun abgeschlossen ist, wollte ich mich mal wieder um die fhem entwicklung kümmern. scheinbar sind da aber ein paar sachen an mir vorbeigegangen...
1. fhem wird nach /opt installiert
kann man machen, muss man aber nicht ;-) eigentlich geht der trend inzwischen wieder weg von opt. anyway..
fhem installiert und gestartet:
sudo make install
sudo perl /opt/fhem/fhem.pl /opt/fhem/fhem.cfg
2. FHEMWEB
ich wollte mir boris' neue 1-wire module ansehen. also mal ein blick in die commandref. diese liefert:
./docs/commandref.html: No such file or directory
ok, also mal ein update ausführen, welches durchlief und mit "shutdown restart" abgeschlossen wurde.
3. OWServer
nachdem nun commandref wieder funktionierte, wollte ich ein OWServer device anlegen, welches mit
Cannot load module OWServer
quitiert wurde. ok.. neben einem "vertipper" zu OWServer wo es in der commandref unter
Define
define <name> OWDevice <protocol>
OWDevice heisst (hier müsste eigentlich OWServer stehen), wollte ich mal ins logfile schauen..
4. Logfile
also in der bash mal eben ein tail -f /opt/fhem/log/
mittels autocompletion ausführen wollen aber /opt/fhem/log/ ist leer?? in FHEMWEB wird aber fleissig das logfile angezeigt.
5. FHEM und die pfade
das machte mich nun stutzig.. letztlich fand ich folgendes heraus:
obwohl fhem in /opt/fhem installiert wurde, führt ein sudo perl /opt/fhem/fhem.pl /opt/fhem/fhem.cfg
dazu, das alles (das update, das log, etc.(//images/smiley_icons/icon_wink.gif) in dem verzeichnis landet, in dem ich mich befand: ~/fhem/fhem-svn-5.3
das liegt wiederum daran, das in fhem.cfg attr global logfile ./log/fhem-%Y-%m.log
attr global modpath . # where our FHEM directory is
attr global statefile ./log/fhem.save
attr autocreate filelog ./log/%NAME-%Y.log
definiert ist aber das "BINDIR" aus dem Makefile nicht greift, da dort per default "RELATIVE_PATH=YES" gesetzt ist.
dies mag zwar für ggf. eine FRITZBox installtion oder w.a.i. von vorteil sein, ist aber aus meiner sicht etwas zu sehr optimiert. hier sollte per default auch der pfad in der config gesetzt sein, der im Makefile angegeben ist. ggf. sollte das "RELATIVE_PATH" als flag übergeben werden können.
nu werde ich mal wieder alles aufräumen und neu aufsetzen, nach "oldschool" art und ohne relative pfade..
gruss
Zitat von: Martin Fischer schrieb am Fr, 28 Dezember 2012 22:18ok.. neben einem "vertipper" zu OWServer wo es in der commandref unter
Define
define <name> OWDevice <protocol>
OWDevice heisst (hier müsste eigentlich OWServer stehen)
Ups, fixe ich morgen.
Viele Grüße
Boris
> ./docs/commandref.html: No such file or directory
Commandref.html wird neuerdings mit contrib/commandref_join.pl aus docs/commandref_frame.html und den =html Eintraegen aus FHEM/*.pm zusammengebaut. Habs im Makefile nachgezogen.
> dies mag zwar für ggf. eine FRITZBox installtion oder w.a.i. von vorteil sein, ist aber aus meiner sicht etwas zu sehr optimiert.
Vorteile der aktuellen Loesung mit relativen Pfaden bzw. "alles was zu fhem gehoert ist in einem Verzeichnis" sind:
- Eine Installation ist nicht notwendig: .tar.gz auspacken / SVN auschecken reicht, um fhem starten zu koennen. Funktioniert sogar unter Windows.
- man kann die fhem.cfg mit marginalen Aenderungen zw. unterschiedlichen Geraeten austauschen (Laptop vs. Fritzbox vs. RPi)
- Doku ist einheitlich
- Backup/restore ist einfacher
- Rechtevergabe ist einfacher
Nachteil:
- vor dem Start von fhem muss ein cd erfolgen.
Zitat von: rudolfkoenig schrieb am Sa, 29 Dezember 2012 08:59- Eine Installation ist nicht notwendig: .tar.gz auspacken / SVN auschecken reicht, um fhem starten zu koennen. Funktioniert sogar unter Windows.
das ist ja auch ok so. wenn man es so macht. in dem von dir geschilderten beispiel benötigt man dann ja auch kein Makefile. wenn ich aber über dieses gehe, dann erwarte ich, das es sich danach richtig verhält.
gruss martin