Fhem startet nicht mehr in Web-UI nach update

Begonnen von justcallmeal, 02 Juli 2019, 16:37:10

Vorheriges Thema - Nächstes Thema

Otto123

Du kannst es auch auf "High Level" mit meiner Rettungsweste machen. Einfach das ausführen was ich geschrieben habe und dort dann im Webinterface update force machen. Das wirkt auf den normalen FHEM Pfad.
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

CoolTux

Subversion auf dem Pi installieren und
svn co https://svn.fhem.de/fhem/trunk/fhem <directory>

Alternativ FHEM Packet deinstallieren und neu installieren, danach nur die Konfigdatei zurück sichern.

Für Linux unerfahrene aber am besten auf Otto hören.
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

Beta-User

Hmm,

vielleicht solltest du aber erst mal diesem Hinweis nachgehen:
Zitat von: Otto123 am 02 Juli 2019, 17:54:27
undefined subroutine? Da scheint doch eher die Datei Schrott zu sein?
Könnte es sein, dass die SD-Karte einen Hau hat?
Dann solltest du die Zeit eher in einen Neuaufsatz investieren als auf das Kopieren aktueller Module auf eine defekte Karte...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

justcallmeal

...ich habe noch ein Komplett-Image-File vom 11.6.2019 gefunden, welches ich gerade auf eine SD-Card kopiere.
Dann würde ich die aktuelle fhem.cfg und die aktuellen Log-Dateien auch noch auf die SD-Card ins entsprechende Verzeichnis kopieren und mit etwas Glück habe ich dann wieder ein aktuelles und hoffendlich auch funktionierendes System.

Gibt's hierzu noch Tips oder Hinweise?

Vielen Dank für Eure Hilfe!

LG,
al
HM-Sen-DB-PCB, HM-Sec-SCo, HM-MOD-Re-8, HM-SEC-SC-2, HM-Sen-MDIR-O, HM-LC-Sw1PBU-FM, HM-LC-RGBW-WM, HM-ES-PMSw1-SM, HM-LC-Sw1-DR, div. Shellies u.v.m.

justcallmeal

Zitat von: Otto123 am 02 Juli 2019, 18:47:55
Du kannst es auch auf "High Level" mit meiner Rettungsweste machen. Einfach das ausführen was ich geschrieben habe und dort dann im Webinterface update force machen. Das wirkt auf den normalen FHEM Pfad.

also, ich bin noch immer nicht erfolgreich gewesen. Mein vermeintliches Fullbackup war doch nicht vom 11.6.2019 (das war nur eines von FHEM), sondern vom 15.12.2018 - Also ein gutes halbes Jahr alt. Dieses habe ich auf eine neue/andere SD-Card kopiert und die Kiste lief wieder. Dann Update gemacht, lief immernoch. Dann aktuelle fhem.cfg  eingefügt (als Text aus Zwischenablage). Lief immer noch. Heute mal wieder ein Update mit einem erwartungsgemäß mickrigem Delta gemacht und nun geht das ganze von vorne los: Fhem via WEB-Frontend nicht erreichbar.

Schließlich habe ich Ottos Rettungsweste angewandt: ja, das ging, aber ich hatte danach ein jungfräuliches FHEM und irgendwie mochte ich das auch nicht wieder auf aktuellen STand bringen, also nochmal das ganze von vorne: Image auf SD-Card kopiert, und danach die fhem.cfg, sowie alle aktuellen logs an die entsprechende Stelle kopiert. Ergebnis: in den Raspi gesteckt und....   lief nicht. Bin jetzt langsam am Verzweifeln. Gerade kopiere ich zum x-ten Mal mein Image auf die SD-Card; diesmal werde ich updaten, dann restarten und dann die fhem.cfg editieren. Mal sehn wie's wird, ich halte Euch auf dem Laufenden, allerdings schwindet meine Hoffnung langsam....

VG,
al
HM-Sen-DB-PCB, HM-Sec-SCo, HM-MOD-Re-8, HM-SEC-SC-2, HM-Sen-MDIR-O, HM-LC-Sw1PBU-FM, HM-LC-RGBW-WM, HM-ES-PMSw1-SM, HM-LC-Sw1-DR, div. Shellies u.v.m.

Otto123

Hi al,

naja dann  ist irgendwas in Deiner cfg was einen neustart nicht übersteht. Ich denke nicht, das es an dem mickrigen Delta Update liegt.

Die Frage ist ja nach wie vor: Beendet sich FHEM oder geht das Webinterface wegen hoher Last nicht?

BTW: Klar meine "Rettungsweste" liefert temporär ein leeres FHEM, das ist zum probieren, testen und gucken! Das bringt kein altes laufendes FHEM zurück! Wesentlich: Man kann update fahren und man kann ins aktuelle Log schauen ohne Umstände zu machen. Zu viel mehr ist es nicht gedacht.

Gruß Otto
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

justcallmeal

Zitat von: Otto123 am 03 Juli 2019, 21:41:23
naja dann  ist irgendwas in Deiner cfg was einen neustart nicht übersteht. Ich denke nicht, das es an dem mickrigen Delta Update liegt.

...so kann man es treffend beschreiben. Habe das System jetzt wieder am Laufen. Nach einem Neustart ist's wohl dann wieder hinüber. Vielleicht sollte ich stretch mal updaten?

Das ist echt Mist!

Danke Otto für die Erläuterungen zu Deiner Rettungsweste, werde mal schauen, wie ich jetzt weiter verfahre...

VG,
al

HM-Sen-DB-PCB, HM-Sec-SCo, HM-MOD-Re-8, HM-SEC-SC-2, HM-Sen-MDIR-O, HM-LC-Sw1PBU-FM, HM-LC-RGBW-WM, HM-ES-PMSw1-SM, HM-LC-Sw1-DR, div. Shellies u.v.m.

Otto123

hast Du initialUsbCheck disabled? Obwohl es das nicht sein wird. Dein FHEM lief ja nicht, initialUsbCheck bringt im Fehlerfall 100 % CPU Last.
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

justcallmeal

Zitat von: Otto123 am 03 Juli 2019, 21:54:55
hast Du initialUsbCheck disabled? Obwohl es das nicht sein wird. Dein FHEM lief ja nicht, initialUsbCheck bringt im Fehlerfall 100 % CPU Last.

Ja, aber das war schon immer in meiner cfg:

define initialUsbCheck notify global:INITIALIZED usb create

ich habe aber jetzt auch noch so einen Fehler im Log:

2019.07.03 21:41:33 1: PERL WARNING: Use of uninitialized value $ret in numeric le (<=) at FHEM/HttpUtils.pm line 621.


die Zeile mit initialUSBCheck habe ich nun mal auskommentiert; könnte es daran liegen?


VG,
al
HM-Sen-DB-PCB, HM-Sec-SCo, HM-MOD-Re-8, HM-SEC-SC-2, HM-Sen-MDIR-O, HM-LC-Sw1PBU-FM, HM-LC-RGBW-WM, HM-ES-PMSw1-SM, HM-LC-Sw1-DR, div. Shellies u.v.m.

Otto123

ich hätte attr initialUsbCheck disable 1in der Weboberfläche und dann save gemacht.  ;)
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

justcallmeal

Zitat von: Otto123 am 03 Juli 2019, 22:06:52
ich hätte attr initialUsbCheck disable 1in der Weboberfläche und dann save gemacht.  ;)

Ja, das wäre die elegantere Methode gewesen, aber ehrlich gesagt habe ich noch nicht herausgefunden, wo ich dieses Attribut im Frontend finde. Bei Devices ist das kein Problem, aber wo ist das hier zugeordnet? Bei "global" habe ich es vergeblich gesucht....

BTW, mittlerweile denke ich, dass es an dem HttpUtils.pm - Modul in Verbindung mit dem Shelly liegt. Einerseits ist das das letzte, was ich an Veränderungen eingebracht hatte, andererseits hatte dieses Modul ein Update Ende Juni erfahren, welches ich mitunter kurz vor meiner Havarie aktualisiert hatte.

Wäre es sinnvoll die Vorversion von HttpUtils.pm einzuspielen, - Wenn ja, wie macht man das? 
Einfacher wäre vielleicht auch den Shelly-Kram zu deaktivieren....

VG,
al

HM-Sen-DB-PCB, HM-Sec-SCo, HM-MOD-Re-8, HM-SEC-SC-2, HM-Sen-MDIR-O, HM-LC-Sw1PBU-FM, HM-LC-RGBW-WM, HM-ES-PMSw1-SM, HM-LC-Sw1-DR, div. Shellies u.v.m.

Otto123

So findest Du jedes Device, egal in welchem Raum es sich versteckt. Notfalls nur list und dann mit ctrl+f im Browser suchen.
list initialUsbCheck Du kannst den Befehl attr initialUsbCheck disable 1aber an jeder Stelle in die Kommandozeile werfen. Gut man muss dann genau wissen wie es heisst. :D

Zum Restore der alten Version:
restore list updategibt Dir die Ordner mit Datum zurück- Mein Beispiel! 30.06.2019
restore list update/2019-06-30/FHEMgibt Dir den Inhalt des gesicherten Ordner zurück. Wenn Die Datei vor diesem Update funktionierte, ist es genau die die Du wiederherstellen musst ->
restore list update/2019-06-30/FHEM/HttpUtils.pmdanach machst Du ein reload HttpUtils.pm
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

justcallmeal

Hi Otto,

super, vielen Dank für die wertvollen Tips!

Mein Problem beim Wiederherstellen der letzten HttpUtils.pm -Datei ist, dass ich meine 2 verfügbaren SD-Cards nun mittlerweile mehrfach wechselnd mit Images beschrieben habe, so dass ich die Vorversion von HttpUtils.pm in keinem Restore-Ordner habe :-(

Was ich benötigen würde wäre die Vorversion von:

File         Rev   Last Change

HttpUtils.pm 19689 2019-06-23 07:28:05Z rudolfkoenig


und eine kurze Anweisung wie ich diese einspielen kann.

VG,
al
HM-Sen-DB-PCB, HM-Sec-SCo, HM-MOD-Re-8, HM-SEC-SC-2, HM-Sen-MDIR-O, HM-LC-Sw1PBU-FM, HM-LC-RGBW-WM, HM-ES-PMSw1-SM, HM-LC-Sw1-DR, div. Shellies u.v.m.

Beta-User

Im Svn runterladen, z.B. über https://svn.fhem.de/trac/browser/trunk/fhem/FHEM/HttpUtils.pm den "richtigen" Versionsstand wählen und dann unten auf "reiner Text".

Direkter Link:
https://svn.fhem.de/trac/browser/trunk/fhem/FHEM/HttpUtils.pm?rev=19493&format=txt

Das dann mit den richtigen Rechten an die originale Stelle.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

justcallmeal

Zitat von: Beta-User am 04 Juli 2019, 10:52:24
Im Svn runterladen.....schnipp......
Direkter Link:
https://svn.fhem.de/trac/browser/trunk/fhem/FHEM/HttpUtils.pm?rev=19493&format=txt
Das dann mit den richtigen Rechten an die originale Stelle.

Das hat prima geklappt, vielen Dank für die Hilfe bei der ich mal wieder etwas lernen konnte!

...geholfen hatte es aber hierfür leider nicht  :(

Mein letzter Versuch das Desaster zu beenden bestand darin, das Shelly-Geraffel aus der fhem.cfg herauszunehmen. Und siehe da, es läuft wieder und bootet und und und.  Meine ursprünglichen logs habe ich auch wieder reingefahren, so dass nur zwei Tage fehlen, was zu verschmerzen ist.

Keine Ahnung, warum die Shelly-Schnittstelle solche Probleme gemacht hat, wo sie doch immerhin ein paar Wochen anstandslos lief....

Für jene, die sich gerne mal meine wieder entfernte Shelly-Definition ansehen wollen:

############################___SHELLY1___FHEM Anbindung per HTTP___##########################
#
define shelly1_Kaercher Shelly 192.yyy.yyy.yy
setuuid shelly1_Kaercher 5d0168a4-f33f-53a6-3d9b-a0dd01d0163c040d
attr shelly1_Kaercher event-on-change-reading .*
attr shelly1_Kaercher model shelly1
attr shelly1_Kaercher room CUL_HM,SHELLY
attr shelly1_Kaercher webCmd on-for-timer 7200:on:off
###___logs___SHELLY___###
define FileLog_shelly1_Kaercher FileLog ./log/shelly1_Kaercher-%Y.log shelly1_Kaercher
setuuid FileLog_shelly1_Kaercher 5d05dc41-f33f-53a6-beca-424086567ca6a1e8
attr FileLog_shelly1_Kaercher logtype text
attr FileLog_shelly1_Kaercher room Logs
###
###
define shelly1_78 Shelly 192.xxx.xxx.xx
setuuid shelly1_78 5d08c56c-f33f-53a6-4bab-27913e6d542b11e5
attr shelly1_78 event-on-change-reading .*
attr shelly1_78 model shelly1
attr shelly1_78 room CUL_HM,SHELLY
attr shelly1_78 webCmd on-for-timer 7200:on:off
define FileLog_shelly1_78 FileLog ./log/shelly1_78-%Y.log shelly1_78
setuuid FileLog_shelly1_78 5d08c56c-f33f-53a6-02a4-5417ba1860bb5eb0
attr FileLog_shelly1_78 logtype text
attr FileLog_shelly1_78 room Logs
###
###
####___shelly1_Kaercher schalten via Dummy (so funzt Anzeige in der fhem-App __13.06.2019___####
define Kaercher_dummy dummy
setuuid Kaercher_dummy 5d02085e-f33f-53a6-5213-2089af5cbc560d09
attr Kaercher_dummy room 1_Ruth,Dummy,SHELLY
attr Kaercher_dummy webCmd on-for-timer 7200:on:off
define Kaercher_an notify Kaercher_dummy:on set shelly1_Kaercher on
setuuid Kaercher_an 5d03085e-f33f-53a6-3b45-49ad22cf9439c07b
define Kaercher_aus notify Kaercher_dummy:off set shelly1_Kaercher off
setuuid Kaercher_aus 5d02085e-f33f353a6-1c8f-c1eb9d9f730c6c1a
define Kaercher_7200 notify Kaercher_dummy:on-for-timer 7200 set shelly1_Kaercher on-for-timer 7200
setuuid Kaercher_7200 5d02ba51-f33f-53a6-cfca-07a9c6788d738f44
#


Vielleicht gitbt es ja noch Tips und Hinweise, was da verkehrt lief.

Bis dahin erst einmal vielen Dank für Eure Unterstützung, die mich wieder ein Stück "wissender" gemacht haben  ;)

VG,al
HM-Sen-DB-PCB, HM-Sec-SCo, HM-MOD-Re-8, HM-SEC-SC-2, HM-Sen-MDIR-O, HM-LC-Sw1PBU-FM, HM-LC-RGBW-WM, HM-ES-PMSw1-SM, HM-LC-Sw1-DR, div. Shellies u.v.m.