Never touch a running system!

[kud]

                                                 

Nach einem blauäugigen "fhemupdate houskeeping" geht nun nichts mehr.
Habe das FHEM-Verzeichnis aus dem Backup zurückgespielt sowie die fhem.pl
in /usr/bin wieder auf den alten Stand gebracht.
In der Logdatei steht

2012.09.02 06:10:54 2: Telnet port 7072 opened
2012.09.02 06:10:55 2: FHEMWEB port 8083 opened
2012.09.02 06:10:55 2: FHEMWEB port 8084 opened
2012.09.02 06:10:55 2: FHEMWEB port 8085 opened
2012.09.02 06:10:55 3: Opening CUL_0 device /dev/ttyACM0
2012.09.02 06:10:55 3: Setting CUL_0 baudrate to 9600
2012.09.02 06:10:55 3: CUL_0 device opened
2012.09.02 06:10:55 3: sub define2 with host: 192.168.1.212


mehr nicht.
Zugriff via Browser http://192.168.1.29:8083/fhem geht nicht mehr.

Wie bekommt man das Ganze wieder zum Laufen

Danke Ku

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[rudolfkoenig]

                                                   

> Wie bekommt man das Ganze wieder zum Laufen

Am besten startet man fhem direkt in einem telnet session, wahrscheinlich sieht
man dann noch weitere Fehlermeldungen. Die letzte Meldung kommt von 70_STV.pm,
d.h. die Fehlerursache muss im fhem.cfg ab diese Definition gesucht werden.

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[kud]

                                                 

Aber an der fhem.cfg habe ich nichts verändert.
Ändert das "updatefhem" irgendetwas an dieser Datei?
Wie gesagt, das ganze System lief bis zum update einwandfrei.

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[kud]

                                                 

Hier die Ausgabe am Terminal.

root@nonamefhem:~# fhem.pl /etc/fhem.cfg
root@nonamefhem:~# Subroutine sende_mail redefined at
/usr/share/fhem/FHEM/99_myUtils.pm line 15, <$fh> line 3.
Use of implicit split to @_ is deprecated at
/usr/share/fhem/FHEM/95_FLOORPLAN.pm line 410, <$fh> line 38.
Undefined subroutine &main::readingsBeginUpdate called at
/usr/share/fhem/FHEM/59_Weather.pm line 204, <$fh> line 141.

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[rudolfkoenig]

                                                   

> Undefined subroutine &main::readingsBeginUpdate called at
> /usr/share/fhem/FHEM/59_Weather.pm line 204, <$fh> line 141.

fhem.pl wurde durch das update nicht heruntergeladen.

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[kud]

                                                 

Und was heisst schlussendlich??
Neu aufsetzen und update noch einmal machen?

Am Sonntag, 2. September 2012 10:51:51 UTC+2 schrieb Rudolf Koenig:
>
> > Undefined subroutine &main::readingsBeginUpdate called at
> > /usr/share/fhem/FHEM/59_Weather.pm line 204, <$fh> line 141.
>
> fhem.pl wurde durch das update nicht heruntergeladen.
>

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[kud]

                                                 

Jetzt habe ich alles(?) wieder neu aufgespielt.
Nur warum startet FHEM nicht mehr automatisch (Debian)?
Per Hand in /etc/init.d/fhem start geht.....aber nur für ein paar Minute
danach wieder keinen Zugriff mehr.
Wie gesagt , habe an dieser Startdatei in /etc nicht geändert und das
System lief Monate ohne Probleme auch nach diversen Neustarts.
Ich denke diese Updategeschichte sollte etwas transparenter werden und evtl
eine Roolbackfunktion haben..

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Martin Fischer]

Am Sonntag, 2. September 2012, 06:53:05 schrieb KUD:
> [...]
> Ich denke diese Updategeschichte sollte etwas transparenter werden und evtl
> eine Roolbackfunktion haben..

die "updategeschichte" haben wir inzwischen so transparent wie möglich
gemacht. auch kann ich nicht nachvollziehen, warum es vereinzelt immer wieder
zu problemen kommt.

ein "update housekeeping clean yes" von einer stable 5.2 + den vergangenen
updates aus dem svn durchlief zahlreiche tests von verschiedenen personen und
auf verschiedenen systemen. scheinbar gibt es aber immer noch probleme mit
vereinzelten modulen. denn das sind die aus meiner sicht häufigsten
rückmeldungen in sachen probleme mit dem update und haben in erster linie
nichts mit dem "update"-befehl zu tun. hier müssen die entsprechenden module
geprüft werden; ggf. das script auf dem updateserver. da fhem so offen
entwickelt ist, das der anwender selber die unterschiedlichsten
installationsformen vornehmen sowie eigene perlfunktionen integrieren kann,
wird es zwangsläufig immer mal wieder zu dem einem oder anderem fehler kommen,
da es einfach schier unmöglich ist alle eventualitäten bei den vielen
"freiheiten" von fhem abzudecken.

am neuen update wird zur zeit noch gearbeitet und wird dann so weit möglich
ausführlich getestet. wobei auch hier wieder gilt: der update-befehl ist auch
nur die eine seite der medaillie. wichtig ist: auch die module müssen mit
evtl. strukturveränderungen harmonisieren.

die angesprochene "rollback"-funktion ist durch das backup ja vorhanden. ein
"(semi)-automatisches" rollback wird es aus meiner sicht nicht geben (können).
denn was hilft es, wenn fhem nicht startet.

das backup sollte alle dateien (exclusive logfiles) enthalten um daraus
relativ einfach ein restore vornehmen zu können.

gruss martin

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[kud]

                                                 

Danke für die schnelle und ausführliche Antwort.

Dieses Update-(Problem) sollte nicht so einfach abgehandelt werden!!
Die einzige Veränderung(Neuerstellung) war am Modul 99_my_Utils.pm und
zusätzlich am Samsung Modul(Ip-Adresse).
Egal. Es läuft ja wieder ansatzweise(nach manuellen Start).
Nur warum beendet FHEM das Ganze nach ein paar Minuten und startet nicht
mehr beim Neustart ??
Keine Änderung der Hardware! (Seit zig Reboots und ca. 2 Monaten) Kein
Steckerziehen! Kein Update...
Eigentlich wäre doch ein Rollback ganz einfach... Ich habe die
/etc/fhem.cfg und die backup/FHEM !
Warum eigentlich nicht den gesamten Backup-Pfad /usr/share/fhem....? Da
fehlt vielleicht bei Einigen Etwas!

Aber mein Problem ist das manuelle Starten und das nach ? Minuten abkack..
Kein Eintrag in der fehm...log oder dmesg ! Einfach nur aus.

Habe auch kein Problem mit "Einmal neu". Die fhem.cfg hab ich ja.

VG

Kai-Uwe

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Martin Fischer]

hallo kai-uwe,

Am Sonntag, 2. September 2012, 10:04:07 schrieb KUD:
> Danke für die schnelle und ausführliche Antwort.

büdde
 
> Dieses Update-(Problem) sollte nicht so einfach abgehandelt werden!!

ich habe das (update)-problem nicht "einfach so" angehandelt. ich spreche für
das modul updatefhem, das in der momentan verteilten version meine änderungen
enthält, die auch ausführlich getestet wurden. das hier immer wieder erwähnte
"update-problem" liegt aber nicht direkt an dem updatefhem-befehl, sondern das
es zeitgleich zu überschneidungen bei änderungen an FHEMWEB und der neuen
installationsstruktur kam, was zur folge hatte, das FHEMWEB und FLOORPLAN bei
einigen nicht mehr lief. alle beteiligten (boris, ulli, rudi & ich) haben in
dieser phase bei (meiner meinung nach) allen hier gemeldeten problemen sehr
zeitnah korrigiert.

in meiner antwort habe ich versucht deutlich zu machen, das _ich_ es mir nur
sehr schwer vorstellen kann, das es eben genau an dem _updatefhem_ modul
liegt. denn das updatefhem hat keinerlei funktionen die in frage kommt das
fhem erst [zitat on] "nach ? minuten abkack.." [zitat off].

das derzeit noch in den letzten entwicklungsänderungen befindliche modul
update.pm (das updatefhem komplett ablösen wird) ist ein kompletter rewrite
mit ganz anderen möglichkeiten. darauf habe ich hingewiesen, was wohl den
eindruck vermittelt hat "dein problem ist egal, es gibt bald eine neue update-
funktion". das war / ist nicht meine intention, sondern nur ein hinweis, dass
das eigentliche problem woanders zu suchen ist.

ich hatte in diesem zusammenhang darauf hingewiesen, das es aus meiner sicht
ggf. eher mit änderungen an bestimmten modulen zu tun hat. rudi gab den
hinweis, in der .cfg mal ab einer device-definition die mit 70_STV.pm gesetzt
ist zu suchen. das hat dann aber alles nichts mit dem eigentlichen updatefhem-
befehl zu tun. denn der verrichtet eigentlich seine arbeit (wenn zur zeit auch
noch etwas umständlich mit mehreren update-läufen) korrekt. aber auch hier
hatten wir in der vergangenheit mehrfach transparent hingewiesen: in der
derzeitigen "umbau-phase" _kann_ es durchaus mal zu einem fehler kommen. um
alle fehler einzufangen, sind die in der "freien wildbahn" befindlichen
installationsvarianten zu weitläufig.

gruss martin

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[tiptronic]

                                                 

Hi Martin,

fyi: ich habe gerade mal ein updatefhem auf meiner Synology (4.1) ausprobiert:

- Hat gleich nicht geklappt (war ja irgendwie klar). Ich hab' Dir mal den start.log angehängt, vielleicht hilft's Dir ja, das zu debuggen:


2012.09.03 16:10:50 3: Opening CUNO device 192.168.XX.120:2323
2012.09.03 16:10:50 3: CUNO device opened
2012.09.03 16:10:50 2: Setting CUL fhtid from A00871234 to 1234
2012.09.03 16:10:50 2: Switched CUNO rfmode to HomeMatic
2012.09.03 16:10:50 3: Opening CUNOv1 device 192.168.XX.121:2323
2012.09.03 16:10:50 3: CUNOv1 device opened
2012.09.03 16:10:50 2: FHEMWEB port 8083 opened
2012.09.03 16:10:50 2: FHEMWEB port 8084 opened
2012.09.03 16:10:50 2: FHEMWEB port 8085 opened
2012.09.03 16:10:51 3: Connecting to database SQLite:dbname=/volume1/web/fhem.db with user
2012.09.03 16:10:51 3: Connection to db SQLite:dbname=/volume1/web/fhem.db established
2012.09.03 16:10:51 3: NetIO230B: device opened at host: 192.168.XX.130 => NetIO1 NetIO230B 192.168.XX.130 1 admin admin
2012.09.03 16:41:03 1: updatefhem updated ./fhem.pl
2012.09.03 16:41:03 1: updatefhem updated FHEM/01_FHEMWEB.pm
2012.09.03 16:41:03 1: updatefhem updated FHEM/02_HTTPSRV.pm
2012.09.03 16:41:03 1: updatefhem updated FHEM/57_Calendar.pm
2012.09.03 16:41:03 1: updatefhem updated FHEM/70_SML.pm
2012.09.03 16:41:03 1: updatefhem updated FHEM/70_STV.pm
2012.09.03 16:41:03 1: updatefhem updated FHEM/98_SVG.pm
2012.09.03 16:41:03 1: updatefhem updated FHEM/HttpUtils.pm
2012.09.03 16:41:04 1: updatefhem updated www/pgm2/commandref.html
2012.09.03 16:41:04 1: updatefhem New version of fhem.pl, 'shutdown restart' is required!
2012.09.03 16:41:20 0: Server shutdown
2012.09.03 16:41:24 1: Including /var/log/fhem/fhem.cfg
2012.09.03 16:41:25 3: Opening CUNO device 192.168.XX.120:2323
2012.09.03 16:41:25 3: CUNO device opened
2012.09.03 16:41:25 2: Setting CUL fhtid from A00281234 to 1234
2012.09.03 16:41:25 2: Switched CUNO rfmode to HomeMatic
2012.09.03 16:41:25 3: Opening CUNOv1 device 192.168.XX.121:2323
2012.09.03 16:41:25 3: CUNOv1 device opened
2012.09.03 16:41:25 1: reload: Error:Modul 01_FHEMWEB deactivated:
 Can't locate TcpServerUtils.pm in @INC (@INC contains: /opt/lib/perl5/5.10.0/arm-linux /opt/lib/perl5/5.10.0 /opt/lib/perl5/site_perl/5.10.0/arm-linux /opt/lib/perl5/site_perl/5.10.0 . /usr/share/fhem/FHEM) at /usr/share/fhem/FHEM/01_FHEMWEB.pm line 7, <$fh> line 17.
BEGIN failed--compilation aborted at /usr/share/fhem/FHEM/01_FHEMWEB.pm line 7, <$fh> line 17.

2012.09.03 16:41:25 0: Can't locate TcpServerUtils.pm in @INC (@INC contains: /opt/lib/perl5/5.10.0/arm-linux /opt/lib/perl5/5.10.0 /opt/lib/perl5/site_perl/5.10.0/arm-linux /opt/lib/perl5/site_perl/5.10.0 . /usr/share/fhem/FHEM) at /usr/share/fhem/FHEM/01_FHEMWEB.pm line 7, <$fh> line 17.
BEGIN failed--compilation aborted at /usr/share/fhem/FHEM/01_FHEMWEB.pm line 7, <$fh> line 17.



Grüße

Andy
PS: Ach ja... fhem selbst läuft, nur die FHEMWEBs gehen nicht... Was wird denn von den TcpServerUtils.pm fürs Frontend benötigt?






On 02.09.2012, at 22:44, Martin Fischer wrote:

> hallo kai-uwe,
>
> Am Sonntag, 2. September 2012, 10:04:07 schrieb KUD:
>> Danke für die schnelle und ausführliche Antwort.
>
> büdde
>
>> Dieses Update-(Problem) sollte nicht so einfach abgehandelt werden!!
>
> ich habe das (update)-problem nicht "einfach so" angehandelt. ich spreche für
> das modul updatefhem, das in der momentan verteilten version meine änderungen
> enthält, die auch ausführlich getestet wurden. das hier immer wieder erwähnte
> "update-problem" liegt aber nicht direkt an dem updatefhem-befehl, sondern das
> es zeitgleich zu überschneidungen bei änderungen an FHEMWEB und der neuen
> installationsstruktur kam, was zur folge hatte, das FHEMWEB und FLOORPLAN bei
> einigen nicht mehr lief. alle beteiligten (boris, ulli, rudi & ich) haben in
> dieser phase bei (meiner meinung nach) allen hier gemeldeten problemen sehr
> zeitnah korrigiert.
>
> in meiner antwort habe ich versucht deutlich zu machen, das _ich_ es mir nur
> sehr schwer vorstellen kann, das es eben genau an dem _updatefhem_ modul
> liegt. denn das updatefhem hat keinerlei funktionen die in frage kommt das
> fhem erst [zitat on] "nach ? minuten abkack.." [zitat off].
>
> das derzeit noch in den letzten entwicklungsänderungen befindliche modul
> update.pm (das updatefhem komplett ablösen wird) ist ein kompletter rewrite
> mit ganz anderen möglichkeiten. darauf habe ich hingewiesen, was wohl den
> eindruck vermittelt hat "dein problem ist egal, es gibt bald eine neue update-
> funktion". das war / ist nicht meine intention, sondern nur ein hinweis, dass
> das eigentliche problem woanders zu suchen ist.
>
> ich hatte in diesem zusammenhang darauf hingewiesen, das es aus meiner sicht
> ggf. eher mit änderungen an bestimmten modulen zu tun hat. rudi gab den
> hinweis, in der .cfg mal ab einer device-definition die mit 70_STV.pm gesetzt
> ist zu suchen. das hat dann aber alles nichts mit dem eigentlichen updatefhem-
> befehl zu tun. denn der verrichtet eigentlich seine arbeit (wenn zur zeit auch
> noch etwas umständlich mit mehreren update-läufen) korrekt. aber auch hier
> hatten wir in der vergangenheit mehrfach transparent hingewiesen: in der
> derzeitigen "umbau-phase" _kann_ es durchaus mal zu einem fehler kommen. um
> alle fehler einzufangen, sind die in der "freien wildbahn" befindlichen
> installationsvarianten zu weitläufig.
>
> gruss martin
>
> --
> To unsubscribe from this group, send email to
> fhem-users+unsubscribe@googlegroups.com

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Martin Fischer]

hallo andy,

Am Montag, 3. September 2012, 18:25:19 schrieb Andy Fuchs:
> [...]
> fyi: ich habe gerade mal ein updatefhem auf meiner Synology (4.1)
> ausprobiert:

von welcher version? und wie oft hast du updatefhem durchgeführt?

> - Hat gleich nicht geklappt (war ja irgendwie klar). Ich hab' Dir mal den
> start.log angehängt, vielleicht hilft's Dir ja, das zu debuggen:

warum war das "ja irgendwie klar"? auf allen entwicklungssystemen (inkl.
synology mit 4.1) + produktivsystem konnte ich (und kann zum testen immer
noch) von einer frischen 5.2 bis zur aktuellen version update _ohne_ einen
fehler.

> [...]
> PS: Ach ja... fhem selbst läuft, nur die FHEMWEBs gehen nicht... Was wird
> denn von den TcpServerUtils.pm fürs Frontend benötigt?

rudi hat funktionen in die TcpServerUtils.pm ausgelagert. diese werden meines
wissens nach für die telnet sowie fhemweb sockets benötigt.

es scheint, das bei deinem update die TcpServerUtils.pm nicht übertragen
wurde.

steht die TcpServerUtils.pm in filetimes.txt? ggf. diese datei löschen und
updatefhem neu anstossen. kann sein, dass das noch ein "überbleibsel" aus den
überschneidungen der damaligen zeigleichen änderungen an updatefhem, fhemweb
und TcpServerUtils.pm

martin

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[tiptronic]

                                                 

Am 04.09.2012 um 21:48 schrieb Martin Fischer :

> hallo andy,
>
> Am Montag, 3. September 2012, 18:25:19 schrieb Andy Fuchs:
>> [...]
>> fyi: ich habe gerade mal ein updatefhem auf meiner Synology (4.1)
>> ausprobiert:
>
> von welcher version? und wie oft hast du updatefhem durchgeführt?

Hi Martin,

von der letzten Release-Version (ich glaube 05/2012).

>
>> - Hat gleich nicht geklappt (war ja irgendwie klar). Ich hab' Dir mal den
>> start.log angehängt, vielleicht hilft's Dir ja, das zu debuggen:
>
> warum war das "ja irgendwie klar"? auf allen entwicklungssystemen (inkl.
> synology mit 4.1) + produktivsystem konnte ich (und kann zum testen immer
> noch) von einer frischen 5.2 bis zur aktuellen version update _ohne_ einen
> fehler.

Tja

>> [...]
>> PS: Ach ja... fhem selbst läuft, nur die FHEMWEBs gehen nicht... Was wird
>> denn von den TcpServerUtils.pm fürs Frontend benötigt?
>
> rudi hat funktionen in die TcpServerUtils.pm ausgelagert. diese werden meines
> wissens nach für die telnet sowie fhemweb sockets benötigt.

> es scheint, das bei deinem update die TcpServerUtils.pm nicht übertragen
> wurde.

Ich hatte einen clean-Installation via fhem.tar so wie in der Commandref gemacht. Anschließend updatefhem aufgerufen und fhem neu gestartet.

Vielleicht hatte ich mich bei meinem Posting etwas zu knapp ausgedrückt:
Mir ging es mehr darum, darauf aufmerksam zu machen, dass offensichtlich das updatefhem einige Module nicht korrekt nachzieht.
Nachdem ich gesehen hatte, dass die Logs und dbLog, etc... laufen, ich aber kein WebUI hatte, hab ich das fehlende Modul (stand ja im Log) händisch nachinstalliert und dann ging's. Joe User dürfte damit aber ein Problem haben schätze ich.

> steht die TcpServerUtils.pm in filetimes.txt? ggf. diese datei löschen und
> updatefhem neu anstossen. kann sein, dass das noch ein "überbleibsel" aus den
> überschneidungen der damaligen zeigleichen änderungen an updatefhem, fhemweb
> und TcpServerUtils.pm

Kann ich jetzt natürlich nicht mehr sagen, ich werd's bei nächster Gelegenheit im Auge behalten.

Grüsse

Andy


> martin
>
> --
> To unsubscribe from this group, send email to
> fhem-users+unsubscribe@googlegroups.com

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Martin Fischer]

hiya nady,

Am Dienstag, 4. September 2012, 22:22:07 schrieb Andy Fuchs:
> [...].
> > steht die TcpServerUtils.pm in filetimes.txt? ggf. diese datei löschen und
> > updatefhem neu anstossen. kann sein, dass das noch ein "überbleibsel" aus
> > den überschneidungen der damaligen zeigleichen änderungen an updatefhem,
> > fhemweb und TcpServerUtils.pm
>
> Kann ich jetzt natürlich nicht mehr sagen, ich werd's bei nächster
> Gelegenheit im Auge behalten.

genau das wäre ein wichtiger hinweis. updatefhem, sowie das künftige update
arbeiten beide mit "steuerdateien", die jeweils auf fhem.de erzeugt und
bereitgestellt werden.

hier wäre es dann wichtig gewesen ob besagte datei in der "steuerdatei"
eingetrage war oder nicht. letzteres würde nämlich darauf schliessen, dass das
script auf fhem.de das nicht berücksichtigt hatte.

wir müssen das also weiter im auge behalten. ich kann den fehler auch nach
mehrfachem neuinstallieren von 5.2 auf verschiedenen systemen nicht
nachstellen.

gruss martin

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Martin Fischer]

Am Dienstag, 4. September 2012, 22:22:07 schrieb Andy Fuchs:
> Am 04.09.2012 um 21:48 schrieb Martin Fischer :
> > hallo andy,
> >
> > Am Montag, 3. September 2012, 18:25:19 schrieb Andy Fuchs:
> >> [...]
> >> fyi: ich habe gerade mal ein updatefhem auf meiner Synology (4.1)
> >
> >> ausprobiert:
> > von welcher version? und wie oft hast du updatefhem durchgeführt?
>
> Hi Martin,
>
> von der letzten Release-Version (ich glaube 05/2012).
>
> >> - Hat gleich nicht geklappt (war ja irgendwie klar). Ich hab' Dir mal den
> >
> >> start.log angehängt, vielleicht hilft's Dir ja, das zu debuggen:
> > warum war das "ja irgendwie klar"? auf allen entwicklungssystemen (inkl.
> > synology mit 4.1) + produktivsystem konnte ich (und kann zum testen immer
> > noch) von einer frischen 5.2 bis zur aktuellen version update _ohne_ einen
> > fehler.

ich habe das heute nochmal auf einem anderen Synology System nachgestellt.
Diesmal auf meiner Rackstation RS812:

Folgende Reihenfolge habe ich eingehalten:
1. usb-driver-kernel-2.6.32_mfr-1.0_syno-88f628x.spk
2. openssl-1.0.0j_mfr-1.0_syno-88f628x.spk
3. perl-5.16.0_mfr-1.0_syno-88f628x.spk
4. FHEM-5.2_mfr-1.0_syno-88f628x.spk

Die Pakete stammen von meiner Homepage http://www.fischer-net.de

Die Installation, sowie die darauf folgenden FHEM-Updates:
1. updatefhem, shutdown restart
2. updatefhem -> command changed, updatefhem housekeeping clean yes, shutdown
restart
3. updatefhem -> nothing to do
verliefen ohne Probleme. Auszug aus dem Logfile anbei.

Ich kann die gemeldeten Fehler nicht nachstellen!

2012.09.10 22:02:12 2: Telnet port 7072 opened
2012.09.10 22:02:12 2: FHEMWEB port 8083 opened
2012.09.10 22:02:12 2: FHEMWEB port 8084 opened
2012.09.10 22:02:12 2: FHEMWEB port 8085 opened
2012.09.10 22:02:12 0: Server started (version 5.2 from 2011-12-31 ($Id: fhem.pl 1159 2011-12-31 13:31:58Z rudolfkoenig $), pid 29411)
2012.09.10 22:02:35 1: Got http://fhem.de/fhemupdate/filetimes.txt, length: 9335
2012.09.10 22:02:35 1: Got http://fhem.de/fhemupdate/00_CM11.pm, length: 19833
[...]
2012.09.10 22:03:00 1: Got http://fhem.de/fhemupdate/wind4windDir4.gplot, length: 1086
2012.09.10 22:03:29 0: Server shutdown
2012.09.10 22:03:32 1: Including /usr/local/FHEM/etc/fhem.cfg
2012.09.10 22:03:33 3: WEB: port 8083 opened
2012.09.10 22:03:33 3: WEBphone: port 8084 opened
2012.09.10 22:03:33 3: WEBtablet: port 8085 opened
2012.09.10 22:03:33 1: Including /usr/local/FHEM/var/log/fhem.save
2012.09.10 22:03:33 3: Converting 'attr global port 7072 global' to 'define telnetPort telnet 7072 global'
2012.09.10 22:03:33 3: telnetPort: port 7072 opened
2012.09.10 22:03:33 2: SecurityCheck:  WEB,WEBphone,WEBtablet has no basicAuth attribute. telnetPort has no password/globalpassword attribute. Running with root privileges. Restart fhem for a new check if the problem is fixed, or set the global attribute motd to none to supress this message.
2012.09.10 22:03:33 0: Server started (version Fhem 5.2 (DEVELOPMENT), $Id: fhem.pl 1764 2012-07-28 06:27:09Z rudolfkoenig $, pid 2495)
2012.09.10 22:05:02 1: backup tar: removing leading '/' from member names
2012.09.10 22:05:02 1: backup done: FHEM-20120910_220457.tar.gz (1209356 Bytes)
2012.09.10 22:05:02 1: updatefhem updated ./CHANGED
2012.09.10 22:05:02 1: updatefhem updated ./fhem.pl
2012.09.10 22:05:02 1: updatefhem updated FHEM/00_CM11.pm
[...]
2012.09.10 22:05:18 1: updatefhem Housekeeping finished, 'shutdown restart' is recommended!
2012.09.10 22:05:18 1: updatefhem New version of fhem.pl, 'shutdown restart' is required!
2012.09.10 22:05:56 0: Server shutdown
2012.09.10 22:05:58 1: Including /usr/local/FHEM/etc/fhem.cfg
2012.09.10 22:05:59 3: WEB: port 8083 opened
2012.09.10 22:05:59 3: WEBphone: port 8084 opened
2012.09.10 22:05:59 3: WEBtablet: port 8085 opened
2012.09.10 22:06:00 1: Including /usr/local/FHEM/var/log/fhem.save
2012.09.10 22:06:00 3: Converting 'attr global port 7072 global' to 'define telnetPort telnet 7072 global'
2012.09.10 22:06:00 3: telnetPort: port 7072 opened
2012.09.10 22:06:00 2: SecurityCheck:  WEB,WEBphone,WEBtablet has no basicAuth attribute. telnetPort has no password/globalpassword attribute. Running with root privileges. Restart fhem for a new check if the problem is fixed, or set the global attribute motd to none to supress this message.
2012.09.10 22:06:00 0: Server started (version Fhem 5.2 (DEVELOPMENT), $Id: fhem.pl 1764 2012-07-28 06:27:09Z rudolfkoenig $, pid 12513)
2012.09.10 22:14:55 0: Server shutdown

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com