Hallo Fhemler, >:( >:( >:( >:(
heute war es wieder einmal so weit.
Ein " klick auf Update" und der Tag ist im AR***
...wiedermal...
Nach einem Neustart von Fhem ist kein Starten mehr Möglich. Den Prozess Killen und Starten bringt nichts, ein Blick in TOP verrät das Fhem aller 10 sec. von vorn anfängt.
Das macht so keinen Spaß....
Ja ich habe ein Backup und es ist in 5 min alles wieder beim Alten, aber das kann so nicht der richtige weg sein....
Anbei die Updateliste von heute Morgen.
fhem
List of new / modified files since last update:
UPD ./CHANGED
UPD ./MAINTAINER.txt
UPD ./fhem.pl
UPD FHEM/10_MYSENSORS_DEVICE.pm
UPD FHEM/10_ZWave.pm
UPD FHEM/70_Pushover.pm
UPD FHEM/73_AMADCommBridge.pm
UPD FHEM/73_AutoShuttersControl.pm
UPD FHEM/73_DoorBird.pm
UPD FHEM/73_GardenaSmartBridge.pm
UPD FHEM/74_AMADDevice.pm
UPD FHEM/88_HMCCU.pm
UPD FHEM/88_HMCCURPCPROC.pm
UPD FHEM/91_notify.pm
UPD FHEM/95_YAAHM.pm
UPD FHEM/98_Heating_Control.pm
UPD FHEM/98_MediaList.pm
UPD FHEM/98_Text2Speech.pm
UPD FHEM/98_WeekdayTimer.pm
UPD FHEM/98_autocreate.pm
UPD FHEM/DevIo.pm
UPD FHEM/HttpUtils.pm
UPD FHEM/UConv.pm
UPD FHEM/lib/74_AMADautomagicFlowset_4.4.1.xml
UPD FHEM/lib/74_AMADtaskerset_4.4.1.prj.xml
UPD FHEM/lib/AttrTemplate/mqtt2.template
UPD docs/commandref_frame.html
UPD docs/commandref_frame_DE.html
New entries in the CHANGED file:
- bugfix: 88_HMCCU: Flag for disabling initial device update
- bugfix: 10_MYSENSORS_DEVICE: prevent fhem crashing by ack timeout
at higher verobse levels
- change: 98_Heating_Control.pm will be removed soon. Users will need to
change their device definitions to 98_WeekdayTimer; supporting
code is provided, but perl calls have to be changed manually.
- bugfix: 73_AutoShuttersControl: fix bug roommate and windwo comfort
- bugfix: 73_DoorBird: Error 404 handling for history images corrected
- bugfix: 73_AutoShuttersControl: fix sunset sunrise object values
- feature: 74_AMADtaskerset_4.4.0.prj: add nfc tag support in taskerset
74_AMADautomagicflowset: fix bug then use VLC player
- feature: 73_DoorBird: Images can be stored as JPGs
- feature: 73_DoorBird: Secure communication with https ans SessionID
- bugfix: 73_AutoShuttersControl: fix brightness detection for IsDay,
fix detection for manual driveing
- bugfix: 73_GardenaSmartBridge: fix the fix
- bugfix: 73_GardenaSmartBridge: check if defined $data
gcmsend
nothing to do...
dbplan
nothing to do...
fhemabfall
nothing to do...
Ich habe es 3 mal versucht mit dem Update und auf dem Testsystem lief es auch ohne Probleme...werde nun 3-4 Tage warten und es dann nochmal versuchen.
MFG Rico
PS:Es muss doch Möglich sein Fhem so zu Konstruieren, das es wenigstens Startet und einen Fehler ausgibt.
Vielen Dan das sie Ihren Frust abgelassen haben. Sie können nun weiter gehen.
Ansonsten hat der Post null Aussage in Richtung Fehlerfindung.
Ich gehe aber davon aus das Du ESPEasy in Betrieb hast.
Jupp hab ich.
Gut. Dann wissen wir ja Bescheid.
Hab noch einen entspannten Tag.
Warum sollte espeasy der Übeltäter sein?
Habe s auch bei mir definiert und am laufen?
Gruß Sascha
Gesendet von meinem E6653 mit Tapatalk
Wer sagt dass ESPEasy der Übeltäter ist?
Es ist der Auslöser, der Übeltäte rist noch unbekannt. aber vermutlich die fhem.pl.
lässt sich im Forum seit 2 oder 3 Tagen nachlesen.
btw:
Wer selten Updates macht wäre immer gut beraten VOR einem Update mal ins Forum zu schauen.
Rico z.B. hätte gelesen dass es Probleme nach dem Update gibt wenn man ESPEasy im Einsatz hat und hätte kein Update angestossen.
Zitat von: sash.sc am 13 Mai 2019, 09:31:02
Warum sollte espeasy der Übeltäter sein?
Habe s auch bei mir definiert und am laufen?
Gruß Sascha
Gesendet von meinem E6653 mit Tapatalk
So lange der Threadersteller nicht mit sinnvollen Aussagen (Logfile) rüber kommt nehme ich das was ich kenne. Und seit gestern gibt es Probleme mit dem ESPEasy Modul
https://forum.fhem.de/index.php/topic,100477.0.html
Wenn es bei Dir läuft wäre interessant welche Modulversionen Du ein setzt. Aber das dann bitte im verlinkten Thread posten. Du würdest uns damit sehr helfen.
Werde heute nachmittag mal schauen und mich melden.
Gruß Sascha
Gesendet von meinem E6653 mit Tapatalk
Habe mal meine Infos in den Thread geschrieben !
Vielen Dank
Hallo Zusammen,
mal etwas Kritik loswerden sollte keinem Schaden, nur so ändert sich (vielleicht) mal etwas.
Ich selbst kann nicht Programmieren und werde somit nichts brauchbares beitragen können.
Zum Fehler:
2019.05.13 09:34:14 1: ESPEasy espBridgeS0: Error: Can't open server port [TCP:IPV4:80**]
2019.05.13 09:34:14 1: ESPEasy espBridgeS0: Address already in use
Can't use an undefined value as a symbol reference at ./FHEM/34_ESPEasy.pm line 951.
Wenn der Fehler bei ESPEasy seit mehreren Tagen bekannt ist, hätte man ein Update Warnung ausgeben können.
Dieses hatte ich schon bei einem anderem Fehler angeregt. CUL-HM ...(https://forum.fhem.de/index.php/topic,95409.msg885996.html#msg885996)
Genug geschimpft... euch auch einen Sonnigen Tag :D
MFG Rico
Zitat von: rico5588 am 13 Mai 2019, 09:58:49
Hallo Zusammen,
mal etwas Kritik loswerden sollte keinem Schaden, nur so ändert sich (vielleicht) mal etwas.
Ich selbst kann nicht Programmieren und werde somit nichts brauchbares beitragen können.
Zum Fehler:
2019.05.13 09:34:14 1: ESPEasy espBridgeS0: Error: Can't open server port [TCP:IPV4:80**]
2019.05.13 09:34:14 1: ESPEasy espBridgeS0: Address already in use
Can't use an undefined value as a symbol reference at ./FHEM/34_ESPEasy.pm line 951.
Wenn der Fehler bei ESPEasy seit mehreren Tagen bekannt ist, hätte man ein Update Warnung ausgeben können.
Dieses hatte ich schon bei einem anderem Fehler angeregt. CUL-HM ...(https://forum.fhem.de/index.php/topic,95409.msg885996.html#msg885996)
Genug geschimpft... euch auch einen Sonnigen Tag :D
MFG Rico
Du kannst gerne aktiv an der Fehler suche mitwirken. FHEM ist keine Einbahnstraße.
Stelle Dein globales verbose bitte auf 5 und mache dann das Update samt neustart. Danach brauchen wir Logausgaben seit dem Neustart.
Das alles bitte in den anderen Thread abkippen und schon kann geholfen werden.
Zitatmal etwas Kritik loswerden sollte keinem Schaden, nur so ändert sich (vielleicht) mal etwas.
Die Aeusserungen habe ich nicht als Kritik sondern als Schimpftirade wahrgenommen, und motiviert mich zum Ignorieren des Beitrags und des Problems.
Wer update macht, der nimmt aktiv am Testen teil.
Wer das nicht wuenscht, sollte update lassen, und die Freuden der Neuerungen sich verkneifen.
FHEM hatt 500+ Module: keiner hat alles an Hardware, geschweige denn Zeit und Energie alle Kombinationen durchzutesten: Eine Hoffnung auf ein "garantiert stabil laufendes FHEM" nach einem update ist eine Illusion, was nirgendwo versprochen wurde.
Btw: dass ein Fehler mit ESPEasy geben soll, ist mir seit heute frueh bekannt, das Modul habe ich bisher nur aus Hoerensagen gekannt.
ZitatIch selbst kann nicht Programmieren und werde somit nichts brauchbares beitragen können.
Diese Folgerung ist falsch:
- man kann die von mir gewuenschten Logs und Configs (siehe verwandtes Thema (https://forum.fhem.de/index.php?topic=100477.new#new)) ohne Programmierkenntnisse liefern.
- die Aussage "ich kann nicht Programmieren" bedeutet nicht, dass man es nicht lernen kann, ich konnte es bei Geburt auch nicht.
Zitatmal etwas Kritik loswerden sollte keinem Schaden,
Das war nicht "etwas Kritik", sondern Gemecker. Und zwar über kostenlos erhaltene Leistungen.
Zitatnur so ändert sich (vielleicht) mal etwas.
Das ist schon eine Frechheit. Ich schlage vor, künftig kommerzielle Software einzusetzen und dort den Support zu nutzen - viel Vergnügen.
ZitatIch selbst kann nicht Programmieren und werde somit nichts brauchbares beitragen können.
Das erste spricht für mangelndes Engagement und das zweite ist offensichtlich...
LG
pah
dann mal was positives - auch von nem nicht-progger und 0-auskenner:
a) wir kriegen hier alles von leuten geschenkt, die ihre freizeit für uns verbraten ==> ewige dankbarkeit dafür!
b) hier gibts täglich updates. oft natürlich für module, die man selber nicht braucht. aber zeig mir bitte mal ne firma, die so ne updatepolitik hat ...
c) geht dann mal was schief, sitzt der - oben schon erwähnte - freiwillige meistens am selben tag (eher stunden später) noch am problem und in den meisten fällen is nach 24 h eitel-wonne-sonnenschein.
d) dank des vor dem update erledigten backups aller zu ändernden files, ist n lauffähiges system - wie eh schon erwähnt - nur n klick weit entfernt.
only my 2 cents + ein bissi bauchgepinsle für unsere programmierer ...
aber ne extrem dumme idee, damit auch der größte anfänger gleich wieder ein lauffähiges system hat:
(ich hätte mir sowas anfangs immer gewünscht, als ich noch nix von winscp usw. gewusst hab)
o) könnte man nicht ne kleine routine schreiben, die das "backup" wieder per knopfdruck zurück schreibt?
so nach dem motto: geht fhem nicht, kommt ne art "notfall-seite" auf der dann 3 knopferl für die jeweiligen files aus dem restore-dir zum zurückspielen klickbar sind.
o) fast wichtiger: davor eventuell mit weiteren knöpfchen zur fehlersuche. ein modul-los gestartetes fhem, dass gleich die wichtigsten infos zusammen fasst und dem geneigten 0-wisser die möglichkeit gibt, alles grundlegend wichtige per copy&past ins forum zu schieben. ganz lustig (z.b. jdownloader2 macht das so), die erhobenen daten gleich direkt ins forum/programmierer schieben, damit nicht mal bei c&p was schief gehen kann.
so wären alle glücklich ... der user, weil er per knopfdruck wieder sein fhem hat und der programmierer, weil er nicht erst alle grundlegenden infos aus dem user rausprügeln muß.
und nein, das muß nicht alle eventuellen probleme abdecken - aber grundlegende infos wären dann schon mal ohne den üblichen 5 fragen dort, wo sie sein sollten.
o) aja, und ich würd mir noch ein riesiges "dont't panic" als überschrift wünschen ...
Zitat von: rico5588 am 13 Mai 2019, 09:21:06
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
Zitato) könnte man nicht ne kleine routine schreiben, die das "backup" wieder per knopfdruck zurück schreibt?
Gibt es bereits!
Zitatkönnte man nicht ne kleine routine schreiben, die das "backup" wieder per knopfdruck zurück schreibt?
Zitatrestore update/2014-08-19
restore update/2014-08-19/fhem.pl
Und ja diese Version geht nur wenn FHEM läuft.
ZitatUnd 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.
Zitat von: the ratman am 13 Mai 2019, 11:38:30
so ein modul-loses notfall-fhem [...]
Nicht ganz modul-los: https://forum.fhem.de/index.php/topic,86225.0.html
"Leeres" Notfall FHEM:
Erstmal prüfen, ob FHEM wirklich nicht läuft.
ps -aux|grep fhem
Wenn kein FHEM läuft:
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
Zitatso 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.
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!
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
Zitat von: Beta-User am 13 Mai 2019, 11:51:09
Nicht ganz modul-los: https://forum.fhem.de/index.php/topic,86225.0.html (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 (https://forum.fhem.de/index.php/topic,99827.0.html) war sie dort abzulegen, wo sie auch über den Update Mechanismus verfügbar wäre.
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!
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.
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*.
Zitat von: Prof. Dr. Peter Henning am 13 Mai 2019, 12:25:44
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
Zitat- 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
Zitat von: Prof. Dr. Peter Henning am 13 Mai 2019, 15:00:07
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.
Zitat von: Prof. Dr. Peter Henning am 13 Mai 2019, 15:00:07
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.
Ich sag mal ganz lieb :-* Bravo :-*
ich kenne kein weiteres System, wo mit der Geschwindigkeit und Intensität Fehler behoben werden. :D
Zitat von: Loredo am 13 Mai 2019, 15:30:27
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. [...]
@Loredo:
(Vorneweg zum Hintergrund: Ich bin eher User als Modulautor und bestenfalls als "Modulbetreuer" von vorhandenem Zeug anzusehen mit eher saumäßigen Perlkenntnissen).
Ich finde es sehr klasse, dass du dich dieser Themen für uns alle annimmst, auch wenn ich effektiv allenfalls eine blasse Vorstellung davon habe, wie sowas umzusetzen ist, und daher auch keinen Plan habe, ob das, was du da entwickelst (z.B. mit Meta.pm und dem installer) überhaupt die richtige Richtung ist.
Vom "Gefühl her" entwickelt sich FHEM aus einem sehr harten SW-Kern heraus, der ursprünglich nicht für diese (UN-) Zahl von Modulen, Varianten und Entwicklervorstellungen gemacht war, zu einem universellen Schweizer Taschenmesser, das für "alles mögliche" eingesetzt wird. Für mich steht die hardwarenahme Automatisierung weiter sehr im Vordergrund, von daher bin ich auch Rudi und ein paar anderen sehr dankbar, die (wenn auch teilweise mit anderen Ansichten, Motivationen oder Lösungsstrategien) das Hauptziel, nämlich FHEM auf lange Sicht schlank und "hart" lauffähig zu halten sehr "hart" verteidigen.
Am Ende scheinen wir aber meistens einen Kompromiss gefunden zu haben, gute Vorschläge auch aufzugreifen und zu integrieren. Daher bitte nicht zu digital denken und vor der Zeit aufgeben ;) .
Zitat von: Loredo am 13 Mai 2019, 13:23:50
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).
Das mit der Nutzerfreundlichkeit mag ich nicht so im Raum stehen lassen. Beispiel initialUsbCheck: Das soll eindeutig den Einstieg für totale Neulinge erleichtern. Es ist (gefühlt) schon immer drin, und Rudi mag es trotz der bekannten Probleme, die es macht trotzdem nicht deaktivieren... (Verbessern aber sehr gerne!)
Was mich angeht, habe ich auch nicht den Eindruck, dass Noobs (zu denen btw. unser "ratman" nur noch der vorgeblichen eigenen Meinung nach gehört) das Problem sind, auch nicht viele Noobs. Problematisch sind nur die Noobs, die nicht mitdenken wollen oder mal in die Doku sehen. Wobei das Forum als Doku nur noch bedingt taugt, es ist einfach zu groß, und oft ist es schwierig, den richtigen Suchbegriff zu finden (aber nicht immer!). Und auch commandref und Wiki sind gelegentlich schlecht zu durchsuchen.
Ansonsten finde ich "nur" Noobs richtig schwierig, die sich an Zeug ranwagen, weit bevor sie das erforderliche Grundlagenwissen haben.
Nach meinem Eindruck stehe ich mit der Haltung zu Noobs nicht ganz alleine.
ich wollt ja eigentlich nix mehr schreiben hier, weil ich mich freu, dass leute miteinander reden und ich selbige dabei lieber nicht stören will, aber das kann ich nicht auf mir sitzen lassen:
Zitatzu denen btw. unser "ratman" nur noch der vorgeblichen eigenen Meinung nach gehört
nun denne, das aus grad deinem munde zu hören, leg ich mal unter ganz großes kompliment ab *verbeug* ... aaaaber
ich bin, wenn schon kein fhem-noob, max. user. und was ich sicher bin, ist ein perl-noob und ein linux-noob, was also 2/3 fehlende kenntnisse wären, um auch den letzten programmierer hier glücklich zu machen.
[mimimi]
was mich selber sehr unglücklich macht: mittlerweile weiß ich sehr genau, was ich nicht weiß. das is noch um ecken schlimmer als ich noch nicht wusste, was ich nicht weiß. da hat ich wenigstens noch leute, denen ich die schuld am versagen geben konnte *g*.
[/mimimi]
Ergänzung zu Noob:
Linux:
Die meisten Leute, die hier helfen (mich eingeschlossen) - haben m.E. kein Problem mit Linux-Noobs; "die" sollten halt akzeptieren, dass es einfacher ist, FHEM auf Linux zu betreiben (wie die meisten anderen HA-Lösungen auch, btw.), und sie daher gut daran tun, sich wenigstens ein paar Grundlagen dazu anzueignen. Sobald man User- und Gruppen-Rechte verstanden hat, weiß, was das sudo soll und eine manpage aufrufen kann, ist man auch da user, nicht mehr Noob :P
Perl:
Es gibt ja Leute, die behaupten, man könnte es vermeiden, das auch noch zu lernen (wollte ich btw. früher auch nicht unbedingt in der Tiefe...), wenn man bestimmte Module nutzt, die einem das abnehmen. Da diese Leute das besser wissen wie ich, braucht man das also gar nicht :P . (Für die anderen meine 2ct: Es ist kein Hexenwerk, Perl zu lernen, und den Aufwand, den man in das Erlernen der Syntax bestimmter Module steckt, könnte man auch für den direkten Weg nach Perl hernehmen. Dann hat man nicht schnelle Ergebnisse, aber langfristig "vollen Zugriff".)
@ratman - da wir hier sowieso off-topic sind - es dürfte Dich interessieren: ich habe heute meine Matrix Voice bekommen.
Betreffend das eigentliche Thema: Ich kann jedem nur den klassischen Artikel von Eric Raymond empfehlen.
https://de.wikipedia.org/wiki/Die_Kathedrale_und_der_Basar
LG
pah
@ratman
Möchte etwas zu Deinem (guten) Beitrag ergänzen:
Zitatmittlerweile weiß ich sehr genau, was ich nicht weiß.
Damit habe ich (persönlich) kein Problem. Finde es sogar positiv, wenn jemand seine Grenzen kennt, solange er bereit ist, etwas zu lernen.
Probleme habe ich mit Leuten, die eben Ihre Grenzen/Wissen nicht kennen, oder nicht bereit sind zu lernen. Denen kann man (meines Wissens) nicht helfen ...
na dann offtopic weiter *g*
@prof!
hast schon ne pn - hier nochmal: lass mich dein igor sein , so du was machst!
@wernieman
da ich scheints unfähig bin bessere programmiersprachen zu lernen als html (sofern man die als sprache sehen will), muß ich mit weiterbilden passen. zumindest in dem bereich. hat weniger was mit wollen als "falsch rum denken" und natürlich mit den nur 36 stunden pro tag zu tun.
empfind ich mittlerweile aber als nicht gar so schlimm. ich kann mir auch ohne perl in fhem alles machen, was ich brauch und zumindest den perl-programmierern input zurück geben, solangs mir sagen, was genau sie wissen wollen. hat für betatests den vorteil: wenn das ding bei mir 100% funzt, dann überall *g*.
und DAS kann echt jeder fhem-user zurück geben. das seh ich auch als vorteil hier! weil nicht nur wir user haben super programme kostenlos, auch die programmierer haben nen echt großen haufen betatester - man müßte nur mehr drüber reden und entsprechende übersetzer zwischen schalten, bevor wieder der eine den andern falsch versteht.