Update Chaos

[enno]

heute war es wieder einmal so weit.

Ich würde sagen, falscher Ton und vermutlich falsches System - bei dem Anspruch.

Das man sich ärgert, kann ich verstehen, bei der Bundeswehr wurde für Beschwerden mal eingeführt, dass man eine Nacht drüber schlafen muss und sich dann beschwert. Ich würde sagen, dass hilft hier auch die Kritik sachlicher rüber zu bringen.

Ich denke Frust ist raus, jetzt die gewünschten Logs liefern... Auf gehts!

Gruss
  Enno

[CoolTux]

o) könnte man nicht ne kleine routine schreiben, die das "backup" wieder per knopfdruck zurück schreibt?

Gibt es bereits!

könnte man nicht ne kleine routine schreiben, die das "backup" wieder per knopfdruck zurück schreibt?

restore update/2014-08-19
restore update/2014-08-19/fhem.pl

Und ja diese Version geht nur wenn FHEM läuft.

[the ratman]

Und ja diese Version geht nur wenn FHEM läuft.

eben *g* ich mach das, wie erwähnt, sowieso "händisch" winscp an, und lustig einzelne files schieben. so kriegst auch schnell raus, was genau da nicht will.

so ein modul-loses notfall-fhem (windoof machts z.b. vor) wär da echt ne feine sache - dann müßte zwar immer noch der webserver und perl rennen, aber ich kann mich ned erinnern, dass dass zumindest bei mir nicht der fall war bei problemen.
bei dem, was ich bis jetzt an problemen hatte, wäre dann nur mehr das größte problem, wenn irgendwas blockiert. wie z.b. damals mein netzwerk nach dem update der win-treiber. aber man kann fhem ja nicht für alles verantwortlich machen ...

wichtig wäre halt nur, dass der programmierer seine infos und der user sein fhem haben. ab dann ist die welt ja wieder entspannt und man kann vernünftig weiterführende infos austauschen.

[Beta-User]

so ein modul-loses notfall-fhem [...]

Nicht ganz modul-los: https://forum.fhem.de/index.php/topic,86225.0.html

[Otto123]

"Leeres" Notfall FHEM:
Erstmal prüfen, ob FHEM wirklich nicht läuft.

Code Auswählen Erweitern

ps -aux|grep fhem
Wenn kein FHEM läuft:

Code Auswählen Erweitern

n=4
cd /opt/fhem
sudo wget -qO fhem$n.cfg https://svn.fhem.de/fhem/trunk/fhem/fhem.cfg
sudo sed -i "s/\/fhem.save/\/fhem$n.save/" fhem$n.cfg
# oder auch das Port ändern und UsbCheck disable
sudo sed -i -e "s/8083/8093/;;\$aattr initialUsbCheck disable 1" fhem$n.cfg
sudo chown fhem: fhem$n.cfg
sudo perl fhem.pl fhem$n.cfg
Der Name für den Statefile wird geändert, damit der Inhalt des originalen Statefile erhalten bleibt.
Der Logfilename bleibt erhalten, man startet zwar ein  FHEM mit leerer cfg, hat aber den originalen Logfile im Zugriff.
Man kann restore machen usw...

Oder man nimmt die fhem.cfg.demo - nicht leer

Gruß Otto

[rudolfkoenig]

so ein modul-loses notfall-fhem (windoof machts z.b. vor) wär da echt ne feine sache - dann müßte zwar immer noch der webserver und perl rennen, aber ich kann mich ned erinnern, dass dass zumindest bei mir nicht der fall war bei problemen.

Einen Absturz kann FHEM nur anhand eines nicht sauberen Herunterfahrens feststellen.
Und damit wuerde FHEM auch nach einem RPI-reset (ergo kein sauberes Herunterfahern) ins Notfall-Modus schalten.

[rico5588]

Hätte ich das gewusst...

Sorry an dieser Stelle an alle die sich angegriffen fühlen.
Meine Wortwahl war heute nicht sehr Zielführend.
Selbstverständlich bin auch ich Dankbar über die Entwickler die Ihre Freizeit dafür investieren das bei mir das Licht an und aus geht.
Und gerade weil Fhem das mächtigste Tool weit und breit ist und weil hier ein Riesen Haufen Spezialisten zusammen kommt, dachte ich mit einem Denkanstoß könnte man Fhem noch besser machen.

Sorry nochmal!

[Prof. Dr. Peter Henning]

Ich habe auf einem Testsystem auch schon Fehler ganz anderer Art produziert - Endlosschleifen. Die mich gezwungen haben, fhem brutal zu killen.

Vorschlag: Man könnte ja nach einem erfolgten Update den restart=always automatisch außer Kraft setzen, bis der Administrator des Systems dieses wieder manuell freigibt. Und natürlich einen Modus beim Start einfügen, der die alte Version vor Update zurückholt.

Use case also:
FHEM Update. Setzt bei Auslösung Autorestart auf disabled. FHEM stürzt beim Shutdown restart ab. Beim manuellen Neustart dann Abfrage, ob alte Version zurückgeholt werden soll, oder einfach ein Brute Force-Versuch unternommen werden soll.

LG

pah

[Loredo]

Nicht ganz modul-los: https://forum.fhem.de/index.php/topic,86225.0.html

Auch der FHEM Installer ist für einen solchen Betriebsmodus vorgesehen. Eine dafür vorkonfigurierte fhem.cfg.install gibt es aber leider bisher nicht im SVN, da bisher nicht gewünscht war sie dort abzulegen, wo sie auch über den Update Mechanismus verfügbar wäre.

[the ratman]

also wenn ich da so bei euch les, ärger ich mich grade, dass so viel brauchbares irgendwie untergeht. am anfang zu viel zu lernen und im notfall anderes im kopf.

ihr habts doch eh schon alles einbaut, um zumindest die "leichteren" notfälle automatisieren zu können. da fehlt ja einfach wieder nur die user-freundliche oberfläche, auch gern genannt klicki-bunti *lach*.
warum bastelt ihr da nicht wirklich ne art norfall-seite zusammen? darf auch durchaus ausserhalb eines notfalls erreichbar sein, einfach nur, um z.b. per knopfdruck alle relavanten infos für die anstehende frage im forum beisammen zu haben, wenns auch kein notfall is.
immer dran denken: es wäre ja nicht nur ne erleichterung für uns noobs, ihr modul-baumeister ersparts euch damit jede menge fragen, die meistens eh nicht zur 100%igen zufriedenheit beantwortet werden. n echtes win-win!

[Loredo]

Den Diskussionen aus der Vergangenheit habe ich als Essenz entnommen:


- Nutzerfreundlichkeit ist nur begrenzt gewünscht.
- Noops sind als Anwender nicht gern gesehen.
- Die Nutzung von FHEM soll nicht so stark attraktiv gemacht werden, um nicht noch mehr Noops anzulocken, die nicht bereit sind Doku zu lesen und selbst nachzudenken (wobei letzteres zumeist eher heißt sich im Forum durch duzende Threads zu wühlen).


Aus diesem Grund ist es sehr unwahrscheinlich, dass du da viel mehr, als heute da ist, erwarten kannst.

[the ratman]

erwarten tu ich mir nix - bin zwar weit weg von der gewünschten allwissenden müllhalde, aber ich kann mir bei vielen sache mittlerweile selber helfen und gelernt hab ich hier auch so einiges - auch über menschen.
aber bei zumindest manchen leuten hier vermute ich, dass deine aussagen zutreffen. is wohl angst vor neuem, andern oder sich selber (?) ... da müsste mal ein psycho-onkel ran *g*.

was ich aber tue und immer wieder tun werde: ich versuch immer nur die sicht der "andere seite" mit einzubringen. weil "betriebsblind" is ma schnell. vielleicht hilfts ja was ...
und so schlimm is es auch nicht mit der "elitären fhem-lobby". wärs das, würds so manches knopferl nicht geben und sicherlich auch keine tablet-ui, schon gar ned mit klicki-bunti-schieberei, warscheinlich auch kein doif. nur, um ein paar "kundenfreundliche" beispiele von vielen zu nennen.

was sich so manche "elitären" hinter die ohren schreiben könnten wäre: je mehr noobs eure module verwenden, je besser habt ihr sie programmiert. da wär ich dann wohl eher stolz drauf, als an der unwissenheit der leute zu verzweifeln.
und wer weiß - vielleicht gewinnt ja mal der programmierer und nicht immer das universum *lach*.

[rico5588]

Ich habe auf einem Testsystem auch schon Fehler ganz anderer Art produziert - Endlosschleifen. Die mich gezwungen haben, fhem brutal zu killen.

Vorschlag: Man könnte ja nach einem erfolgten Update den restart=always automatisch außer Kraft setzen, bis der Administrator des Systems dieses wieder manuell freigibt. Und natürlich einen Modus beim Start einfügen, der die alte Version vor Update zurückholt.

Use case also:
FHEM Update. Setzt bei Auslösung Autorestart auf disabled. FHEM stürzt beim Shutdown restart ab. Beim manuellen Neustart dann Abfrage, ob alte Version zurückgeholt werden soll, oder einfach ein Brute Force-Versuch unternommen werden soll.

LG

pah

Das Problem von heute scheint gelösst, hoffe dennoch das solch gute Ansätze s.o. weiter verfolgt werden.
Danke @all

[Prof. Dr. Peter Henning]

- Nutzerfreundlichkeit ist nur begrenzt gewünscht.
- Noops sind als Anwender nicht gern gesehen.
- Die Nutzung von FHEM soll nicht so stark attraktiv gemacht werden, um nicht noch mehr Noops anzulocken, die nicht bereit sind Doku zu lesen und selbst nachzudenken (wobei letzteres zumeist eher heißt sich im Forum durch duzende Threads zu wühlen).

Sehe ich ganz anders. Nutzerfreundlichkeit steht hoch im Kurs - allerdings haben die meisten ernsthaften Entwickler nicht die Zeit, gute Module zu schreiben UND Anfänger unter die Fittiche zu nehmen. Insofern müssen wir dankbar sein, dass es in der Community Leute gibt, die diesen Support leisten und damit als isolierende Schicht zwischen den beiden Extremen wirken.

Natürlich sind sich die meisten Entwickler im Klaren darüber, dass die Nutzung das Ziel ist, sie werden darum versuchen, die Zielerreichung zu maximieren. Umgekehrt vermisse ich aber bei vielen Nutzern irgendeine Art der Anerkennung dafür, dass sie hier extrem von der kostenfreien Arbeit hoch qualifizierter Personen profitieren, die sie anderswo teuer bezahlen müssten. Mit "Anerkennung" ist natürlich nicht "Lob und Dankbarkeit" gemeint, die sollte man nie einfordern. Aber Respekt vor dem erbrachten Zeitaufwand - an Stelle von Forderungen, es "müsse sich etwas ändern."

LG

pah

[Loredo]

Sehe ich ganz anders. Nutzerfreundlichkeit steht hoch im Kurs - allerdings haben die meisten ernsthaften Entwickler nicht die Zeit, gute Module zu schreiben UND Anfänger unter die Fittiche zu nehmen. Insofern müssen wir dankbar sein, dass es in der Community Leute gibt, die diesen Support leisten und damit als isolierende Schicht zwischen den beiden Extremen wirken.

Ich spreche davon, dass Nutzerfreundlichkeit nicht beim Modulautor anfängt, sondern an zentralen Positionen im Code und auch einer konkreten Strategie bedarf. Ob die dann immer vom Modulautor bis nach ganz unten beachtet wird oder auch kann, steht auf einem anderen Blatt. Mein Eindruck ist aber seit Jahren, dass Modulautoren sehr wohl extrem auf Nutzerfreundlichkeit eingestellt sind, es ihnen aber oft nicht leicht gemacht wird das auch ordentlich umzusetzen, so wie sie es möchten. Die richtigen Voraussetzungen dafür zu schaffen, dafür ist nicht der Modulautor verantwortlich, weil er das schlichtweg nicht kann.

Umgekehrt vermisse ich aber bei vielen Nutzern irgendeine Art der Anerkennung dafür, dass sie hier extrem von der kostenfreien Arbeit hoch qualifizierter Personen profitieren, die sie anderswo teuer bezahlen müssten. Mit "Anerkennung" ist natürlich nicht "Lob und Dankbarkeit" gemeint, die sollte man nie einfordern. Aber Respekt vor dem erbrachten Zeitaufwand - an Stelle von Forderungen, es "müsse sich etwas ändern."

Absolut richtig. Ergänzend dazu kann man noch sagen, dass so einleitende Sätze wie "erstmal Danke für die Mühe" oder ähnliches nicht zwangsläufig ernsthaftes Lob und Dankbarkeit ausdrücken. Mir fällt das oft als plumper Versuch einer Sandwich Methode auf. Anstatt das so explizit zu betonen ist es viel entscheidender, wie der restliche Inhalt formuliert ist. Indirektes Lob, Anerkennung und Dankbarkeit sind mir da die liebsten, denn sie sind die ehrlicheren Varianten.


Außerdem füge ich hinzu, dass es auch "Forderungen" aus Entwicklerkreisen gibt, die aber nicht selten genauso behandelt werden, als seien es Forderungen von Nutzern der Art "es müsse sich was ändern". Hier fehlt mir eben der Gemeinschaftssinn, stattdessen gibt es gerade beim Thema "ist das nun unbedingt nötig" regelmäßig Auseinandersetzungen, bei denen das Argument "Best User Experience" keinerlei Bedeutung hat.