Ich habe seit letztem Update überall bei jedem Device oder auch Floorplan plötzlich in der FHEM.cfg ein setuuid mit einer endlos langen ID dahinter stehen.
Was soll ich damit? FHEM hat bisher auch ohne diese "Spielerei" einwandfrei funktioniert. Man kann auch alles immer komplizierter und unübersichtlicher machen.
Deshalb meine Frage: Wie kann man dieses "setuuid" deaktivieren bzw erst garnicht anlegen lassen, denn ich brauche es nicht und macht für mich das ganz nur unübersichtlicher.
Also, an die die sich dabei was gedacht haben könnten, nicht gleich an die Decke springen, wird wohl für einige nützlich sein, aber für mich erkenne ich da keine Verbesserung drin.
Deshalb würde ich es gerne wieder verschwinden lassen.
Geht das, und wie?
Gruß aus Köln
Norbert
Hallo Norbert,
FUUID kann man nicht abschalten denn sie wird von FHEM in Zukunft benötigt.
FHEM soll damit für zukünftige Funktionen gewappnet sein.
Grüße
Zitat von: cocojambo am 23 Januar 2019, 13:19:05
Ich habe seit letztem Update überall bei jedem Device oder auch Floorplan plötzlich in der FHEM.cfg ein setuuid mit einer endlos langen ID dahinter stehen.
Was soll ich damit? FHEM hat bisher auch ohne diese "Spielerei" einwandfrei funktioniert. Man kann auch alles immer komplizierter und unübersichtlicher machen.
Deshalb meine Frage: Wie kann man dieses "setuuid" deaktivieren bzw erst garnicht anlegen lassen, denn ich brauche es nicht und macht für mich das ganz nur unübersichtlicher.
Also, an die die sich dabei was gedacht haben könnten, nicht gleich an die Decke springen, wird wohl für einige nützlich sein, aber für mich erkenne ich da keine Verbesserung drin.
Deshalb würde ich es gerne wieder verschwinden lassen.
Geht das, und wie?
Gruß aus Köln
Norbert
Geht alles. Du gehst auf ein älteres Backup zurück und machst in Zukunft keine Updates mehr. ;)
Und wenn man nicht die config direkt editiert, fällt es gar nicht groß auf. Die, die das doch unbedingt tun müssen, müssen damit leben.
ich frage mich gerade wo das genau stört..... ::)
Es stört in der fhem.cfg also so verstehe ich das.
Jetzt muss er seine ganze Datei neu umordnen und alles nur weil ein paar Leute FHEM weiter entwickeln wollen. Furchtbar ::)
Zitat von: cocojambo am 23 Januar 2019, 13:19:05
Geht das, und wie?
Nein. Und das ist auch gut so.
So was habe ich mir schon gedacht, das man gleich aus allen Rohren schießt.
Mich erinnert das so ein bischen an die Einführung von "csrfToken". Da hieß es auch: braucht man unbedingt, wenn nicht jetzt, dann für zukünftige Anwendungen.
Bis heute zum Bespiel würde mein Badezimmer Fenstersensor, mein GartentempSensor und mein Garagentorschalter immer noch ohne dieses csrfToken funktionieren. Wird bei mir überhaupt nicht gebraucht, muß aber trotzdem überall miteingebaut werden. Zum Glück konnte man das aber mit einem Attribut "verunschlimmern".
So ist es wahrscheinlich auch bei diesem setuuid. Nur das man das nicht abstellen kann.
Was gibt es denn aktuell für einen Grund warum das benötigt wird? Meint Ihr mein Klo-Sensor, Garten Sensor oder meine Garage oder ein Floorplan brauchen unbedingt ein setuuid. Das glaube ich nicht. Ich bin auch davon überzeugt, das meine ganzen int. Abläufe hier im Hause ohne diese ID weiter funktionieren würden.
Also, warum muß man weil einige "schlaue EDV'ler sich das ausgedacht haben, das allen aufs Auge drücken. Ich bin davon überzeugt, das bei einem Großteil von Usern, FHEM nicht ausfällt, wenn diese IDs fehlen würden. Und warum ist es denn gut, wenn man es nicht braucht, man es nicht in Selbstbestimmung "abschalten" kann?
Wenn sich dann wirklich heraustellt, das man diese IDs tatsächlich für einige Funktionen braucht, könnte man diese doch dann manuell als Attribut für diese Funktion aktivieren.
Was ich hier geschrieben habe, hört sich vielleicht etwas zynich und provokativ an, aber mich stört es einfach, das man bei der Verwendung von FHEM in bestimmte Bahnen gezwungen wird, ohne selbst entscheiden zu können ob man das braucht oder überhaupt will oder ob das überhaupt für die persönliche Installation von FHEM notwendigt ist.
Gruß aus Köln
Norbert
Ich habe da eine gute Nachricht für Dich.
Deine ganzen Sensoren und Aktoren werden auch weiterhin ohne csrfToken funktionieren. Genau wie Dein Auto auch ohne Getränkehalter fahren kann. Der Getränkehalter ist nämlich für den Fahrer und nicht fürs Auto.
csrfToken ist für FHEMWEB und nicht für Deine Geräte.
Aber genau Deine blödsinnige fehlerbehaftete Aussage zeigt mir das wir alles richtig machen.
Danke Dir.
Zitat von: cocojambo am 25 Januar 2019, 11:52:18
So was habe ich mir schon gedacht, das man gleich aus allen Rohren schießt.
Mich erinnert das so ein bischen an die Einführung von "csrfToken". Da hieß es auch: braucht man unbedingt, wenn nicht jetzt, dann für zukünftige Anwendungen.
Bis heute zum Bespiel würde mein Badezimmer Fenstersensor, mein GartentempSensor und mein Garagentorschalter immer noch ohne dieses csrfToken funktionieren. Wird bei mir überhaupt nicht gebraucht, muß aber trotzdem überall miteingebaut werden. Zum Glück konnte man das aber mit einem Attribut "verunschlimmern".
So ist es wahrscheinlich auch bei diesem setuuid. Nur das man das nicht abstellen kann.
Was gibt es denn aktuell für einen Grund warum das benötigt wird? Meint Ihr mein Klo-Sensor, Garten Sensor oder meine Garage oder ein Floorplan brauchen unbedingt ein setuuid. Das glaube ich nicht. Ich bin auch davon überzeugt, das meine ganzen int. Abläufe hier im Hause ohne diese ID weiter funktionieren würden.
Also, warum muß man weil einige "schlaue EDV'ler sich das ausgedacht haben, das allen aufs Auge drücken. Ich bin davon überzeugt, das bei einem Großteil von Usern, FHEM nicht ausfällt, wenn diese IDs fehlen würden. Und warum ist es denn gut, wenn man es nicht braucht, man es nicht in Selbstbestimmung "abschalten" kann?
Wenn sich dann wirklich heraustellt, das man diese IDs tatsächlich für einige Funktionen braucht, könnte man diese doch dann manuell als Attribut für diese Funktion aktivieren.
Was ich hier geschrieben habe, hört sich vielleicht etwas zynich und provokativ an, aber mich stört es einfach, das man bei der Verwendung von FHEM in bestimmte Bahnen gezwungen wird, ohne selbst entscheiden zu können ob man das braucht oder überhaupt will oder ob das überhaupt für die persönliche Installation von FHEM notwendigt ist.
Gruß aus Köln
Norbert
Du kannst es problemlos selber entscheiden. Backup auf alter Version einspielen und dann keine Updates mehr durchführen. Die Entscheidung liegt ganz klar bei Dir.
Innovation wird nicht durch Stillstand gefördert
Zitat von: cocojambo am 25 Januar 2019, 11:52:18
Also, warum muß man weil einige "schlaue EDV'ler sich das ausgedacht haben,
Gut dass sich mal ein schlauer EDV'ler FHEM ausgedacht hat und ein paar andere schlaue EDV'ler (wenn überhaupt) viele gute Module. Alles, ohne jemanden zu fragen, nur weil sie es selbst für sich gebraucht haben (=Basisintention hinter fast allem hier) ::)
Nur weil du den Zweck von etwas nicht verstanden hast, heisst es nicht, dass man es nicht braucht oder es zukünftig für den Betrieb von FHEM essentiell sein kann.
Wenn außerdem einige Leute nur endlich mal ihre Finger (und Augen) von der Konfig lassen würden hätten sie selbst deutlich weniger Probleme!
Und wie schon geschrieben, wird hier keiner zu irgendwas gezwungen. Du kannst deine FHEM-Installation jederzeit von Neuerungen ausschließen. Das ist deine freie Entscheidung!
Mann, Mannn, Mann ::)
Jetzt brauche ich auch mal ne Tonne Popcorn....
Zitat von: cocojambo am 25 Januar 2019, 11:52:18
Was ich hier geschrieben habe, hört sich vielleicht etwas zynich und provokativ an, aber mich stört es einfach, das man bei der Verwendung von FHEM in bestimmte Bahnen gezwungen wird, ohne selbst entscheiden zu können ob man das braucht oder überhaupt will oder ob das überhaupt für die persönliche Installation von FHEM notwendigt ist.
Hallo Norbert,
komische Ansicht, aber:
einfach den gewünschten Stand nehmen, kein Update mehr machen und alle Weiterentwicklung selbst vornehmen. Ist doch alles im Quelltext verfügbar.
Gruß Otto
ich habe das problem von cocojambo noch nicht wirklich entdeckt.
geht es eventuell um das "aussehen" der cfg files?
Zitat von: frank am 25 Januar 2019, 12:43:15
ich habe das problem von cocojambo noch nicht wirklich entdeckt.
geht es eventuell um das "aussehen" der cfg files?
So habe ich es verstanden. Also ist das "Problem" tatsächlich vollständig zu vernachlässigen. Trotzdem könnte der Thread noch lustig werden.
Zitat von: frank am 25 Januar 2019, 12:43:15
geht es eventuell um das "aussehen" der cfg files?
also ich drucke mir die immer aus.... bisher hat alles auf 33 seiten gepasst. und zwar ziemlich genau. ich wollte das auch nie anders haben, und jetzt steht da nunmal eine zeile mehr pro device, d.h. es werden nun um die 35 seiten gedruckt. und das geht ja mal gar nicht, weil dafür bäume gefällt werden müssen. unnötigigerweise!!!!1111einseinself
dieser post kann spuren von ironie enthalten.
Unsere Katze meint zu diesem Thema:
Vielleicht mal ganz kurz (und möglicherweise vereinfacht) für den TE: Die FUUID ist ein INTERNAL, also etwas, was FHEM intern (bzw. einige Module) benötigen um dem User bessere Funktionalität zur Verfügung zu stellen. Der User soll damit nichts zu tun haben (müssen)
Ich habe mir kürzlich einen zusätzlichen Temperatursensor organisiert und händisch in der fhem.cfg eingefügt.
Die Filelog und SVG Daten habe ich von den Temperatursensoren übernommen die bereits vorhanden sind.
Die Namen und die GPLOT-Datei wurden natürlich angepasst.
Alles funktioniert super und ohne jegliche Probleme.
Jetzt ist es aber so, dass die ganzen define´s (SVG / FileLog / und der Sensor selber) keine FUUID in der fhem.cfg bekommen haben,
obwohl diese aber in den Internals der Devices steht.
Kann ich nun hingehen und diese FUUID in der fhem.cfg auch händisch nachtragen also in etwa so:
setuuid HMS100TF_Bad 5c4b3430-f33f-7267-6796-b168b8c24f255bf2
oder andere Frage, kann ich dieses "setuuid" einfach weglassen (anscheinend wird die ja nicht benötigt)?
Und bevor wieder mal irgendwelche Bemerkungen kommen....
Ja, ich bearbeite die fhem.cfg händisch, weil ich dadurch bestimmt mehrere Stunden Zeit einspare und das Ergebnis genau das gleiche ist als wenn
ich über die FHEM-Oberfläche die Devices bearbeite.
Außerdem, wenn setuuid so wichtig wäre, wieso bekomme ich dann keinen Hinweis über "Save Config"???
ZitatKann ich nun hingehen und diese FUUID in der fhem.cfg auch händisch nachtragen also in etwa so:[...]
Ja.
Zitat von: Tom111 am 27 Januar 2019, 17:41:29
Ja, ich bearbeite die fhem.cfg händisch, weil ich dadurch bestimmt mehrere Stunden Zeit einspare und das Ergebnis genau das gleiche ist als wenn ich über die FHEM-Oberfläche die Devices bearbeite
RAW Config kennst du?
Ich hab anfangs auch viel in der cfg gepinselt als ich es nicht besser wusste.
Seit ich dann auf RAW config gestoßen wurde haich nichts mehr in der cfg gemacht.
Gesendet von meinem Doogee S60 mit Tapatalk
Zitat von: Frank_Huber am 27 Januar 2019, 20:00:25
RAW Config kennst du?
öhm... NEIN, noch nie davon gehört, steht auch nichts davon in der commandref.
*** POPCORN ***
Da mein Popcorn inzwischen alle ist, werfe ich mich mal in die Runde mit der Frage:
wofür genau ist setuuid denn künftig gut? Wer das nämlich mal nachschlagen will, findet - im Gegensatz zu csrfToken - erschreckend wenig Informatives. OK, es haben sich ein paar schlaue Köpfe ausgedacht, und es wird schon seine Richtigkeit zu haben. Aber warum macht man so ein schreckliches Geheimnis daraus?
Wiki: Fehlanzeige
FHEM-Suche:
1: FHEM Code changes / Revision 18342: fhem.pl: fix rereadcfg for setuuid (Forum #96172)
2: FHEM Code changes / Revision 18310: fhem.pl: add setuuid (Forum #95902)
3: FHEM Code changes / Revision 18311: fhem.pl: ignore duplicate uuids in setuuid (Forum #95902)
4: Fehlerberichte / Antw:Fehlermeldungen "setuuid autocreate: duplicate value, ignoring it..."
5: Anfängerfragen / (Gelöst) Vorgehensweise: Handling von setuuid bei Geräte-Austausch
6: dieser Thread hier.
Wenn man dann etwas intern einliest, findet man endlich https://forum.fhem.de/index.php/topic,95902.0/all.html (https://forum.fhem.de/index.php/topic,95902.0/all.html) und versteht dann auch wozu das Ganze gut ist.
Ähnliches gilt auch für "RAW definition". Kein Wiki-Artikel und allenfalls Querverweise in der commandref. Und nicht einmal regelmäßige Hinweise der "tue-nicht-die-fhem.cfg-editieren"-Mahner. Dabei bietet genau RAW definition best of both worlds, FHEM und Direktedit.
Es gibt noch mehr Dinge in FHEM, die für den regelmäßigen User und Forumleser so selbstverständlich sind, dass man sich zu Dokus dazu den Wolf sucht. Ich beschwere mich nicht darüber - ich kenne es ja ... ;D
Zitat von: Tom111 am 27 Januar 2019, 22:57:26
öhm... NEIN, noch nie davon gehört, steht auch nichts davon in der commandref.
Bei jedem device ist unten ein link dazu.
Schau es dir mal an.
Gesendet von meinem Doogee S60 mit Tapatalk
Zitat von: Pfriemler am 27 Januar 2019, 23:30:19
Ähnliches gilt auch für "RAW definition". Kein Wiki-Artikel und allenfalls Querverweise in der commandref. Und nicht einmal regelmäßige Hinweise der "tue-nicht-die-fhem.cfg-editieren"-Mahner. Dabei bietet genau RAW definition best of both worlds, FHEM und Direktedit.
Stimmt nicht ganz:
https://wiki.fhem.de/wiki/Import_von_Code_Snippets
https://wiki.fhem.de/wiki/Konfiguration
Aber wie so immer: gib den Suchbegriff in der Suche im Wiki ein - und die Trefferquote ist "EIGENARTIG" um es mal zu umschreiben.
https://wiki.fhem.de/w/index.php?search=Raw+definition&title=Spezial%3ASuche&go=Seite
Gruß Otto
So ist die Suche besser:
https://wiki.fhem.de/w/index.php?search="Raw+definition"&title=Spezial%3ASuche&profile=default&fulltext=1
Aber auch hier ist das Ergebnis nicht zielführend.
Und wenn man es nicht kennt kann man auch nicht dannach suchen...
Gesendet von meinem Doogee S60 mit Tapatalk
Ach und ich Dödel hatte versehentlich nach "RAW definition" gesucht. Copy&Paste-Fehler im Kopf. GROSS/klein ist für jeden WinDOS-Nutzer schwer :-)
via Tapatalk
Zu dem Thread fallen mir spontan zwei Sachen ein:
1) Vielen Dank an Pfriemler für das aufzeigen bzw. recherchieren, wozu das Ganze gut sein wird...hätte man auch gleich in der ersten Antwort schreiben können und nicht erst anderthalb Threadseiten auf den TE einschlagen müssen. Er fragt wozu das Ganze gut ist und wird nur als Innovattionsfeindlich abgekanzelt. Auf seine Fragen wird nicht eingegangen. Das wäre jetzt nicht meine Idealvorstellung einer Community.
2) FHEM wird öfter als das "Linux der Hausautomatisierung" bezeichnet und ist genau deshalb beliebt, weil es einen zu nichts zwingt. Für jedes Vorhaben oder Problem gibt es mindestens 3, manchmal mehr mögliche Wege etwas umzusetzen oder zu verwenden. Deshalb finde ich es immer schade, wenn man Dinge nicht konfigurierbar, bzw. abschaltbar gestaltet. Wenn ich etwas nichtt zwingend benötige, kann ich so Komplexität herausnehmen und bleibe zudem abwärts und aufwärtskompatibel.
3) Wenn etwas eingeführt wird, sollte einfach auffindbare Dokumentation vorhanden sein und darin erklärt werden, wie man das Ganze handhabt und nachrüstet bzw. welche Auswirkungen es auf die laufende Installation haben kann, wenn etwas schiefgeht. Ansonsten gibts fröhliches Rätselraten und Backup hin- und herschieben.
Und wieder ein Grund mehr configDB als Standard ein zu führen!!!
3) Genau das ist das Grundproblem von OpenSource. Niemand wird für Doku bezahlt und deshalb "fällt sie unten durch" ... *)
Habe noch kein Projekt kennengelernt (nicht nur FHEM), wo es ein Problem ist. Weiß auch keine praktikable und funktionierende Lösung ...
Außer:
Wenn es einem als User auffällt, anstatt meckern einfach Dokumentieren!
*) Bei vielen ClosedSource-Projekten auch ein Problem, obwohl dort Leute dafür bezahlt werden)
Zitat von: CoolTux am 28 Januar 2019, 06:50:50
Und wieder ein Grund mehr configDB als Standard ein zu führen!!!
An Einführungen als Standard wäre nichts auszusetzen, denn ein Standard impliziert, dass es daneben die Möglichkeit gibt, ein non-Standardverfahren aufsetzen und benutzen zu können... damit wäre die Entscheidungsfreiheit gewahrt.
Das ist aber ein ganz anderes Thema.
Zitat von: cocojambo am 25 Januar 2019, 11:52:18
Mich erinnert das so ein bischen an die Einführung von "csrfToken". Da hieß es auch: braucht man unbedingt, wenn nicht jetzt, dann für zukünftige Anwendungen.
I beg to differ.
csrfToken schützt
dich davor, dass dir jemand anderes einen FHEM-Befehl unterjubelt, der das nicht können dürfen soll. Du hast es aber vermutlich nicht so verstanden, aber
csrfToken hat eine große Sicherheitsschwachstelle (jemand könnte z.B. hier ein "Bild" einfügen, dessen automatischer Aufruf durch den Browser bei dir zu Hause irgendeine Aktion auslöst) in FHEMWEB behoben und wenn du diese mit
none aushebelst, stellst du diesen unsicheren Zustand wieder her. (Informations-)Sicherheit ist meistens nicht so komfortabel wie Unsicherheit, aber - in Anlehnung an einen bedeutenden Denker (https://en.wikipedia.org/wiki/Fart_Proudly) des 18. Jahrhunderts: Wer Sicherheit für Komfort aufgibt, hat bald weder noch.
Das ist explizit keine Aussage über die UUID, nur über csrfToken.
Es erstaunt mich nicht wirklich, das ich mit so einer einfachen Bemerkung und Fragestellung diese Diskusion losgetreten habe. Damit hatte ich im Stillen gerechnet, weil sich die "Schlauen FHEMler" schon leicht auf die Füsse getreten fühlen, weil sie sich Mühe mit der Erfindung gemacht haben und sich auch irgendwas dabei gedacht haben, was z.B. ich nicht verstehe und hier auch keiner deutlich machen kann.
Aber es zeigt sich ja auch, das nicht alle der Meinung sind das diese ID im Moment gebraucht und wichtig ist. Bis jetzt konnte ich diesem Thema nicht entlocken, wofür denn diese ID wirklich im Moment wichtig ist und was aktuell nicht mehr funktioniert, wenn man sie nicht hat.
Mal sehen ob doch was informatives hier herauskommt.
Gruß aus Kölle
Norbert
Interessant ist doch, dass die Frage falsch herum gestellt wird.
Was stört dich an einem Thema, dass dich im Grunde nicht beeinflusst? Du musst keinerlei Maßnahmen ergreifen. Das Thema setuuid funktioniert komplett ohne dein Zutun, es schränkt die Funktionalität von FHEM in keiner Weise ein. Alle empfohlen Wege, FHEM zu konfigurieren werden durch die Maßnahme in keiner Weise beeinflusst. Die Frage muss also lauten: Warum ist das Thema hier so ein großes Problem?
Die Antwort auf deine Frage ist: Es kann in Zukunft an vielen Stellen wichtig werden, wenn einige Modulentwickler den Vorteil der Maßnahme erkennen und begreifen. Es ist eine Innovation, eine Neuerung, die einige Dinge vereinfachen kann, da eine eindeutig ID sehr hilfreich sein kann, wenn man bspw. konkrete Instanzen erkennen und/oder referenzieren möchte. Allerdings ist es nicht so, als wäre die Frage in diesem Thread nicht schon beantwortet worden.
Ich glaube im Übrigen nicht, dass sich auch nur einer der Entwickler, die sich über diese Maßnahme Gedanken gemacht haben, "auf die Füße getreten fühlt". Ich frage mich wirklich wo man das hier in diesem Thread erkennen könnte.
Zitat von: cocojambo am 28 Januar 2019, 11:18:46
Es erstaunt mich nicht wirklich, das ich mit so einer einfachen Bemerkung und Fragestellung diese Diskusion losgetreten habe. Damit hatte ich im Stillen gerechnet, weil sich die "Schlauen FHEMler" schon leicht auf die Füsse getreten fühlen, weil sie sich Mühe mit der Erfindung gemacht haben und sich auch irgendwas dabei gedacht haben, was z.B. ich nicht verstehe und hier auch keiner deutlich machen kann.
Aber es zeigt sich ja auch, das nicht alle der Meinung sind das diese ID im Moment gebraucht und wichtig ist. Bis jetzt konnte ich diesem Thema nicht entlocken, wofür denn diese ID wirklich im Moment wichtig ist und was aktuell nicht mehr funktioniert, wenn man sie nicht hat.
Mal sehen ob doch was informatives hier herauskommt.
Gruß aus Kölle
Norbert
Dann hast Du nicht richtig gelesen
https://forum.fhem.de/index.php/topic,95902.0/all.html
Davon mal ab. Meine persönliche Meinung.
Dich als User hat die setuuid überhaupt nicht zu interessieren. Lass es einfach und gut ist. Wenn Du der Meinung bist das Du irgendwas löschen musst dann bitte, tue Dir keinen Zwang an. Wunder Dich halt nicht wenn es Fehlermeldungen gibt und Probleme solltest Du mal Alexa oder GHome integrieren. Ich jedenfalls weiß jetzt schon wen ich dann nicht helfen werde.
Zitatdamit wäre die Entscheidungsfreiheit gewahrt.
Die Entscheidungsfreiheit wurde dir doch schon mehrmals angeboten:
Rollback und kein Update mehr, dann hast du Ruhe.
Gottseidank gibt es in FHEM vieles, was mich nicht zu interessieren braucht. Besondes wenn es störungsfrei funktioniert. Wie es aussieht wenn es nicht funktioniert, hatten wir unlängst in Homematic. Nebst den Diskussionen ob und wie man den Normal-User bei Neuerungen mitnimmt.
Wenn es etwas gibt in FHEM was mich nicht zu interessieren hat, sollte ich mich nach Ersatz umsehen ... :D
Zitat von: Pfriemler am 28 Januar 2019, 12:31:13
Wenn es etwas gibt in FHEM was mich nicht zu interessieren hat, sollte ich mich nach Ersatz umsehen ... :D
Da gebe ich dir vollkommen Recht. Das ist unglücklich formuliert, ich schätze aber, es war nicht so drastisch gemeint.
Leider habe ich unter diesem Link nichts gefunden, wo steht wofür man diese Änderung aktuell braucht.
Dann hast Du nicht richtig gelesen
https://forum.fhem.de/index.php/topic,95902.0/all.html
Und das mit dem "dann machst du eben kein Update mehr" ist ja sicherlich keine Lösung.
Ich warte mal ab, ob sich in Zukunft mit dieser Änderung wirklich was wichtiges mit dieser ID für mich geändert hat.
Vielleicht tut sich ja wirklich was und diese Neuerung wird unbedingt nötig und ansonsten, wie hier schon erwähnt, einfach nicht dran stören.
Gruß
Norbert
Die ersten drei Absätze. Da steht alles Haar klein.
Kleiner Tip, nur weil es für Dich nicht von Interesse ist heißt es noch lange nicht das andere es nicht brauchen.
Zitat von: cocojambo am 28 Januar 2019, 12:41:43
Vielleicht tut sich ja wirklich was und diese Neuerung wird unbedingt nötig und ansonsten, wie hier schon erwähnt, einfach nicht dran stören.
Jetzt hast du mich verloren. Wo lag der Sinn des Threads nochmal?
Zitat von: marvin78 am 28 Januar 2019, 13:36:57
Jetzt hast du mich verloren. Wo lag der Sinn des Threads nochmal?
"...nötig..." -> nötig wozu
...er will wissen, wozu das Ganze dient und ob es abschaltbar ist... seit dem ersten Post...
Ich sollte Sarkasmus wirklich besser kennzeichnen.
Und das, was er wissen möchte, ist beantwortet. Wenn er nun schreibt: "wie hier schon erwähnt, einfach nicht dran stören", ist seine Aufregung jedenfalls...naja..
Gut. Es soll mich nicht weiter interessieren. Ich schaue mir das hier weiter aus der Ferne an. Gesagt ist ja alles.
Ich habe das gefühlt, das einige als User denken und vergessen, das FHEM in der Freizeit als Hobby entwickelt wird. Schon die Unterscheidung "Entwickler" und "User" ist nicht nett (vor allem wenn dann Wörter wie "hohe" inkludiere werden.
Wenn man es besser machen will: Entweder auf altem Stand bleiben oder selber entwickeln. Nicht ohne Grund meckern.
Punk
Warum diskutiert ihr eigentlich immer noch? Den Zeitaufwand ist doch der Krampf hier überhaupt nicht wert.
Zitat von: Wernieman am 28 Januar 2019, 14:13:33
Ich habe das gefühlt, das einige als User denken und vergessen, das FHEM in der Freizeit als Hobby entwickelt wird. Schon die Unterscheidung "Entwickler" und "User" ist nicht nett (vor allem wenn dann Wörter wie "hohe" inkludiere werden.)
"hohe" habe ich hier nicht oder gekonnt über-lesen. Und es gibt schon eine Hierarchie in FHEM, aber die Wertung wird unterschiedlich interpretiert. Über den blutigen Anfängern, denen man schon den einen oder anderen Anfängerfehler verzeihen sollte, kommt eine dicke Schicht "Normal-User" wie ich sie nennen würde, die sich an den Vorzügen des freien Systems dankbar (doch wohl in der überwiegenden Mehrheit!) "bedienen", sich aber zunehmend (nach meinem Gefühl) davor ängstigen, in einer freien Minute mal ein Update zu machen, weil sie sich damit ganz schnell mal den Status quo zerschießen können - reell kein Problem dank der Backups, an denen man mittlerweile ja nur noch mit Vorsatz vorbei kommt, aber zusätzliche Arbeit dennoch. Und dann kommt die Schar der Leute, die sich hier fleißig quer durch alle Entwicklungen lesen und ihr FHEM schon dreimal aufgesetzt oder auf 4 oder sechs Geräte im Haus verteilt haben.
Und dann kommen die Entwickler, ohne die der ganze Laden hier nicht vom Fleck kommen oder oder überhaupt laufen würde. Die diskutieren unter sich und hüten den Unterbau von FHEM vor übereiligen Pfriemeleien.
Und beides völlig zu recht. Nur habe ich bei manchen den Eindruck, dass sie ihr Wissen und den Durchblick stillschweigend bei der breiten Masse voraussetzen und mehr oder weniger schnell genervt klingen, wenn sich ein paar "Minderbemittelte" zu Wort melden. Und das führt dann manchmal zu so komischen Situationen wie hier, wo man sich quasi untereinander über ein seltsames Ansinnen des Themenerstellers (und sorry, ich finde es auch seltsam) lustig macht. Das war außerordentlich amüsant zu lesen, kann aber auch sehr demotivierend wirken. Nichtsdestotrotz sind alle Fragen aus meiner Sicht reichlich (von Entwicklern!) beantwortet und dazugelernt habe ich auch wieder.
Und ja: Wenn FHEM schlecht "dokumentiert" ist, sollte man das nie den Entwicklern anlasten. Was heißt "dokumentiert" ... an der commandref hatte ich bislang nur seltenst etwas auszusetzen und weiß damit umzugehen. An einen Wiki-Artikel stelle ich persönlich ganz andere Anforderungen.
Jedem "Meckerer" die Erstellung eines erläuternden Wiki-Artikel ins Pflichtenheft zu schreiben verbessert die Qualität des Wiki auch nicht gerade - gerade die derer "vom Fach" sind dann doch durchweg die hilfreicheren. Nur wenn es die einen nicht können, die anderen sich nicht trauen und die welches es schon verstanden haben keine Zeit oder Lust mehr dafür haben, wird's nix. Ups, ich fühle mich angesprochen.
Aber das ist auch nicht das wirkliche Thema für mich. Hier ging es meines Erachtens von Anfang an nur um eine Neuerung weit hinter den Kulissen, die sicher >95% aller User unangekündigt "überrollt" hat - ein Aufreger nur weil etwas augenfällig (für den der mal in seine fhem.cfg schaut), von den vielen kleinen gestellten Schräubchen kriegen wir mitlaufendes Fußvolk sonst doch gar nichts mit. Und das ist auch gut so, sagte ich bereits. Und wenn man das verstanden hat, dann hütet man sich auch besser den Sinn der einen oder anderen Änderung voreilig in Frage zu stellen.
Sorry, wenn ich jetzt wem schon wieder Lebenszeit geklaut habe ... ich bin jetzt auch raus.
Zu den Stichworten Update und Dokumentation:
Es hat sich halt schon mehrfach gezeigt, dass nach einem Update irgendeine Komponente nicht mehr lief. Dementsprechend vorsichtig ist man inzwischen mit Updates.
Um das handzuhaben gibt es drei Szenarien:
- kompletter Rollback auf den alten FHEM Stand
- geupdateten FHEM Stand belassen und - sofern kompatibel - Problembehaftete Subkomponenten auf Rollback
- alten FHEM Stand belassen bzw. kein Update machen und nur - sofern kompatibel - benötigte oder aktualisierte Komponenten updaten
Wenn ich jetzt aber garnicht weiss, wie die ganzen Abhängigkeiten sich gestalten, dann habe ich ein Problem und kann tagelang herumtüfteln.
Und genau dieses klang hier ja schon an: "Ohne die setuuids kannst du zukünftig kein Alexa oder GHome verwenden"... aber nur sehr spät und es klang etwas widerwillig, das preiszugeben.
Dementsprechend wäre es gut zu wissen:
- was macht eine neue Funktion
- wie schalte ich sie ab, wenn sie Probleme macht (sofern möglich)
- welche anderen Funktionen bauen auf sie auf oder werden zukünftig auf sie aufbauen
Stattdessen hört man:
- wir brauchen das unbedingt
- wo stört es dich denn; es stört doch nirgendwo
- wir sagen nicht wozu, sondern wir wissen, wir brauchen das und du verstehst es eh nicht
Und anstatt das einfach kurz und sachlich zu klären haben wir diesen Thread hier...
Zitat- was macht eine neue Funktion
Jedes device hat eine eindeutige Kennung die auch nach einem rename erhalten bleibt.
Zitat- wie schalte ich sie ab, wenn sie Probleme macht (sofern möglich)
falsche Frage. Falls(!) die Kennung Probleme verursacht bitte einen qualifizierten Bug report mit allen relevanten Informationen damit die Probleme beseitigt werden können.
Zitat- welche anderen Funktionen bauen auf sie auf oder werden zukünftig auf sie aufbauen
Jetzt: die Kennung wurde für Sprachassistenten eingebaut die intern davon Gebrauch machen
Zukünftig: werden weitere module diese Kennung intern benutzen um device unabhängig vom Namen identifizieren zu können
nur mal so als hinweis:
der thread hat NICHT damit angefangen das jemand etwas neues gesehen hat, nicht wusste wozu es ist und dann gefragt hat wofür es gut ist.
sondern mit einem was soll der mist. ich will es nicht sehen. wie werde ich es wieder los. und das mehr als ein mal.
auf ersteres hätte es ganz sicher eine andere reaktion gegeben wie auf arrogantes unqualifiziertes gemeckere.
und um gleich vorzubeugen: mit unqualifiziert meine ich nicht etwas nicht wissen und nachfragen. ganz im gegenteil.
och menno,
jetzt hat die ganze Diskussion mich so buschig gemacht, dass ich schon der Suche nach Windows Light bin - die ganzen Treiber und Funktionen will ich nicht mehr haben und brauchen werde ich die niemals
Zitat von: Wuppi68 am 28 Januar 2019, 22:46:00
och menno,
jetzt hat die ganze Diskussion mich so buschig gemacht, dass ich schon der Suche nach Windows Light bin - die ganzen Treiber und Funktionen will ich nicht mehr haben und brauchen werde ich die niemals
Es gibt Seiten und Foren, die sich mit einem Windows Light beschäftigen, wie du es haben möchtest...
Wenn aber hier schon UUIDs diskutiert werden, dann könnte man Linux UUIDs anführen....und die wurden parallel zum bestehenden System eingeführt und man hat freie Wahl, was man benutzt... by-path, by-device, by-uuid...
Der Fortschritt hat damit das bestehende ergänzt und muss aber nicht gezwungenermassen verwendet werden.
Zitat von: connormcl am 28 Januar 2019, 23:01:34
Es gibt Seiten und Foren, die sich mit einem Windows Light beschäftigen, wie du es haben möchtest...
Wenn aber hier schon UUIDs diskutiert werden, dann könnte man Linux UUIDs anführen....und die wurden parallel zum bestehenden System eingeführt und man hat freie Wahl, was man benutzt... by-path, by-device, by-uuid...
Der Fortschritt hat damit das bestehende ergänzt und muss aber nicht gezwungenermassen verwendet werden.
Und Du merkst nicht mal wie Du Dich da wiedersprichst.
Denn by-uuid ist immer da. Du kannst es nicht deaktivieren, du kannst es nur nicht benutzen.
Zitat von: CoolTux am 28 Januar 2019, 23:05:07
Und Du merkst nicht mal wie Du Dich da wiedersprichst.
Denn by-uuid ist immer da. Du kannst es nicht deaktivieren, du kannst es nur nicht benutzen.
Im Falle Linux kann man sowohl die UUID beim Erzeugen eines Filesystems nicht vergeben, als auch sie nachträglich löschen oder ändern.
Sie haben natürlich ihre Vorteile, machen aber auch konkret Probleme beim Festplatten-Klonen.
Zitat von: connormcl am 28 Januar 2019, 23:25:20
Im Falle Linux kann man sowohl die UUID beim Erzeugen eines Filesystems nicht vergeben, als auch sie nachträglich löschen oder ändern.
Sie haben natürlich ihre Vorteile, machen aber auch konkret Probleme beim Festplatten-Klonen.
Da reicht es btw wenn man beim raspbian eigenen "sd card copier" vergisst ne neue uuid vergeben zu lassen.
Schon sucht man tagelang nen Fehler wo keiner ist......
Gesendet von meinem Doogee S60 mit Tapatalk
Zitat von: connormcl am 28 Januar 2019, 23:25:20
Im Falle Linux kann man sowohl die UUID beim Erzeugen eines Filesystems nicht vergeben, als auch sie nachträglich löschen oder ändern.
Sie haben natürlich ihre Vorteile, machen aber auch konkret Probleme beim Festplatten-Klonen.
OK hast Recht. Man kann unter Linux (nicht als default) die uuid manipulieren.
Ich verstehe aber immer noch nicht, und das würde ja nun schon oft genug hinterfragt, was genau stört Dich an der uuid in FHEM?
Funktioniert etwas nicht auf Grund dieser id? Kannst Du in FHEMWEB etwas nicht lesen weil die ID die Ansicht kaputt macht? Fühlst Du Deine Privatsphäre bedroht wegen dieser ID?
Bitte sage mir/uns was genau Dein Problem ist. Ansonsten wird das hier wieder so ein endlos länger Thread ohne das Die geholfen wird Dein Problem zu lösen. Du hast doch ein FHEM spezifisches Problem wegen der uuid oder?
Die Festplatten UUID ist übrigens ein guter Vergelich.
Jede Linux-Frestplatte hat eine, mann kann sie manipulieren (in FHEM doch auch?) aber nicht löschen. Eine gelöscht UUID ist eine "genullte UUID", also immer noch da.
Also genau das gleich, man kann es nutzen, aber nicht lösche ..... wenn man es löscht, wird es neu angelegt ....
Es geht hier doch längst nicht mehr um die UUID. Mein Tipp: Lasst es einfach gut sein.
Meine Idee hierzu wäre (und das würde es um einiges übersichtlicher machen):
Die setuuid nicht unter jedes Device schmieren, sondern in eine eigene Config.
So wie ich (und wahrscheinlich ein paar andere) fhem.cfg aufgeteilt haben in mehrere Configs.
Frage: kann ich mit Fhem Bordmitteln die uuids irgendwie exportieren? Sonst muss ichs via Texteditor erledigen...
tu dir und allen anderen einen gefallen und lass solchen blödsinn.
und wenn du es auf biegen und brechen nicht lassen kannst: renn selber in dein unglück und lass alle anderen unbehelligt.
ZitatFrage: kann ich mit Fhem Bordmitteln die uuids irgendwie exportieren?
Ich sehe das genau wie mein Vorredner - aber wer nicht mal den list (https://commandref.fhem.de/#list)Befehl kennt ... :o
list .* FUUID - ach ja klar: der editiert die fhem.cfg ;D
Wasn hier für ne aggressive Stimmung? :o
Zitat von: Otto123 am 26 Februar 2019, 15:43:36
Ich sehe das genau wie mein Vorredner - aber wer nicht mal den list (https://commandref.fhem.de/#list)Befehl kennt ... :olist .* FUUID - ach ja klar: der editiert die fhem.cfg ;D
Na na na, wir haben uns ja vorgenommen lieb zu sein. Also, nicht gleich drauf hauen bitte.
Wir merken uns die Kandidaten (meine Liste und schon ziemlich lang) und dann passt das schon.
;)
Grüße
Zitat von: retikulum am 26 Februar 2019, 15:45:36
Wasn hier für ne aggressive Stimmung? :o
ZitatDie setuuid nicht unter jedes Device schmieren,
Ich wollte nur die Frage beantworten - aggressiv bin ich anders :)
Zitat von: Otto123 am 26 Februar 2019, 15:47:15
Genau. Hier schmiert niemand, sondern entwickelt zu meist sinnvolles in stundenlanger Freizeit.
Zitat von: CoolTux am 26 Februar 2019, 15:46:31
Wir merken uns die Kandidaten (meine Liste und schon ziemlich lang) und dann passt das schon.
bitte schick mir mal die Liste 8) 8) 8)
vielleicht sollten wir die Liste zu einem offiziellen AdBlock Filter ausbauen 8)
Zitat von: betateilchen am 26 Februar 2019, 16:32:19
vielleicht sollten wir die Liste zu einem offiziellen AdBlock Filter ausbauen 8)
und wer verbraucht dann das ganze Popcorn?!?
Wäre doch schade, wenn es gar keine Anlässe mehr gäbe :P
Zitat von: retikulum am 26 Februar 2019, 15:33:37
Frage: kann ich mit Fhem Bordmitteln die uuids irgendwie exportieren? Sonst muss ichs via Texteditor erledigen...
... nein, oder?
Exportieren, in eine eigene .cfg packen und die dann per Import einbinden?
Viel Erfolg weiterhin!
gb#
ich bin dafür die fhem.cfg zu "obfuskieren"
https://de.wikipedia.org/wiki/Obfuskation_(Software)
https://de.wikipedia.org/wiki/Obfuscated_Perl_Contest
wer dann noch editiert ist noch mehr selber schuld als jetzt schon.... 8) 8) 8)
Zitat von: nils_ am 26 Februar 2019, 16:03:52
bitte schick mir mal die Liste 8) 8) 8)
Wer der Meinung ist er steht da zu Unrecht drauf kann gerne nett seine Entfernung beantragen.
Ich kann so eine List einerseits verstehen, würde aber eine öffentliche Präsentation in dieser Form nicht verwenden. Kann leicht "als Pranger" verstehen werden ... und hat eigentlich mit diesem Thread nichts zu tun ..
das ist jedenfalls meine Meinung ...
Zitat von: Wernieman am 27 Februar 2019, 11:19:35
Ich kann so eine List einerseits verstehen, würde aber eine öffentliche Präsentation in dieser Form nicht verwenden. Kann leicht "als Pranger" verstehen werden ... und hat eigentlich mit diesem Thread nichts zu tun ..
das ist jedenfalls meine Meinung ...
Du bist mit einer der wenigen auf dessen Meinung ich Wert lege.
Danke
Zitat von: nils_ am 27 Februar 2019, 10:52:25
ich bin dafür die fhem.cfg zu "obfuskieren"
https://de.wikipedia.org/wiki/Obfuskation_(Software)
https://de.wikipedia.org/wiki/Obfuscated_Perl_Contest
wer dann noch editiert ist noch mehr selber schuld als jetzt schon.... 8) 8) 8)
wäre es nicht effektiver den entgegengesetzten weg zu gehen?
da es nun mal den weg des manuellen editierens gibt, sollte dieser weg eventuell auch offensiv und anfängergerecht beschrieben sein. je einfacher und besser dokumentiert, desto weniger fehleranfällig.
da es hier genügend schlaue leute gibt, wird es auch immer eine anleitung zum manuellen editieren geben. wer es will, wird es dann auch machen. warum dann nicht den aufwand einer obfuskation in eine "automatische" fehlerminimierung stecken?
Zitat von: frank am 27 Februar 2019, 11:24:51
warum dann nicht den aufwand einer obfuskation in eine "automatische" fehlerminimierung stecken?
Weil in die automatische Fehlerminimierung schon jede Menge Aufwand der Entwickler geflossen ist!
Man muss nur die von FHEM(WEB) gebotenen Funktionen nutzen, dann werden auch fehlerhafte Eingaben abgefangen, das geht aber beim manuellen Editieren der fhem.cfg nicht.
Gruß
Dan
Ich bin der Meinung, dieser Thread sollte geschlossen werden. Mindestens.
ZitatMan muss nur die von FHEM(WEB) gebotenen Funktionen nutzen, dann werden auch fehlerhafte Eingaben abgefangen, das geht aber beim manuellen Editieren der fhem.cfg nicht.
genau: zur zeit (noch) nicht.
Zitat von: frank am 27 Februar 2019, 11:46:14
genau: zur zeit (noch) nicht.
Dann sag doch bitte mal, warum jemand an der Stelle Arbeit investieren sollte, obwohl dieser Weg nicht der empfohlene Weg ist, FHEM zu konfigurieren!? Ich empfinde das als verschwendete Zeit und das wird vermutlich jedem Entwickler so gehen.
Das soll es aber auch von mir zum Thema gewesen sein. Es hängt mir zum Hals raus.
Zitat von: frank am 27 Februar 2019, 11:24:51
wäre es nicht effektiver den entgegengesetzten weg zu gehen?
da es nun mal den weg des manuellen editierens gibt, sollte dieser weg eventuell auch offensiv und anfängergerecht beschrieben sein. je einfacher und besser dokumentiert, desto weniger fehleranfällig.
Damit die Direkt-Editierer (auf Anfänger-Level) wieder mehr werden? Keine gute Idee!
Zitat von: nils_ am 27 Februar 2019, 10:52:25
ich bin dafür die fhem.cfg zu "obfuskieren"
Oder gleich auf configDB wechseln ;)
*duckundweg*
Zitat von: Benni am 27 Februar 2019, 12:09:26
Oder gleich auf configDB wechseln ;)
*duckundweg*
das eine schließt ja das andere nicht aus :)
Zitat von: marvin78 am 27 Februar 2019, 11:50:44
Dann sag doch bitte mal, warum jemand an der Stelle Arbeit investieren sollte, obwohl dieser Weg nicht der empfohlene Weg ist, FHEM zu konfigurieren!? Ich empfinde das als verschwendete Zeit und das wird vermutlich jedem Entwickler so gehen.
Das soll es aber auch von mir zum Thema gewesen sein. Es hängt mir zum Hals raus.
der weg ist zwar nicht empfohlen, aber etabliert und nicht verboten.
daher wird er auch genutzt, was nicht zu verhindern ist.
grundsätzlich hängt mir dieses thema ebenfalls zum hals raus. allerdings empfinde ich manche äusserungen gegenüber usern, die diesen erlaubten weg dennoch gehen, "überflüssig".
nach meinem verständnis sollte es doch möglich sein, dass die vorhandenen funktionen zur fehlerminimierung bei der eingabe über FHEMWEB, auch bei einer "eingabe" über fhem.cfg eingebunden werden könnten.
es muss auch nicht immer eine "falsch editierte" fhem.cfg sein. defekte dateien könnten zb ähnliche effekte bewirken.
ich möchte diesen weg nicht bewerben.
trotzdem glaube ich, dass eine fehlerminimierung dieses weges für alle seiten vorteile hätte.
Zitat von: frank am 27 Februar 2019, 13:14:40
der weg ist zwar nicht empfohlen, aber etabliert und nicht verboten.
daher wird er auch genutzt, was nicht zu verhindern ist.
Nichts desto trotz ist er fehleranfällig und sollte, nach Möglichkeit, deswegen aktiv vermieden werden, gerade für Anfänger!
Zitat von: frank am 27 Februar 2019, 13:14:40
nach meinem verständnis sollte es doch möglich sein, dass die vorhandenen funktionen zur fehlerminimierung bei der eingabe über FHEMWEB, auch bei einer "eingabe" über fhem.cfg eingebunden werden könnten.
Wie soll denn das funktionieren? Man kann ja prinzipiell jeden Texteditor dafür hernehmen.
Und dann?
Warum dann nicht gleich FHEMWEB nutzen? Da funktioniert das!
Genau dass sollte man den Usern näher bringen und nicht fehleranfälliges Arbeiten.
Und schon gar nicht sollte man an der Stelle Ressourcen verbraten, in Form von Fehleranfälligkeit minimieren.
Gruß Benni.
ZitatWie soll denn das funktionieren? Man kann ja prinzipiell jeden Texteditor dafür hernehmen.
Und dann?
natürlich nicht bei der eingabe in die fhem.cfg. ;)
sondern beim einlesen der fhem.cfg in fhem.
Schon ein simples Nachdenken bring einen darauf, warum ein Test der Config-Edit nicht funktionieren KANN:
Beim edit innerhalb von Fhem wird eine "Falscheingabe" sofort mit einem Fehler gemeldet und nicht "live" genommen, Bei der config-Datei wird beim starten eingelesen .. wie soll jetzt ein Fehler gemeldet werden? Auch wird es gleich "live" genommen .. wie soll es abgewiesen werden??
Kurzgefasst:
Schon aus Systemgründen KANN ein solcher Test nicht funktionieren und ist deshalb aus Systemgründen grundsätzlich abzulehnen.
In der Vergangenheit war es der normale weg, aber altes ist eben nicht immer gut, nur weil " etabliert" ist.
Aber dieses sind nur meine Gedanken ... allerdings (wie ich glaube) werden viele "Entwickler" auch so denken.
Btw:
Finde es Lustig, das eine (aktuell) praktisch nicht verwendete Funktionalität (ein Feld wird dazugenommen), so eine Diskussionsauswirkung haben kann ...
Gibt's beim Einlesen der cfg Fehler, gibt es doch eine Rückmeldung via log, oder bin ich da falsch gewickelt?
Anmerkung: kann nicht mehr wirklich mitreden, mein Hauptsystem läuft seit "Ewigkeiten" stressfrei mit configDB, und seitdem kenne ich die Stellschrauben in FHEMWEB, wie man auch längeres Zeug in die cfg bekommt. Auch ich kann den "Bedarf" für includes oder sonstige manuelle Aktionen einfach nicht mehr erkennen ;D . Und soweit ich das bisher von einzelnen "Neuusern" als Rückmeldung wahrgenommen habe, sehen die oft auch schnell ein, dass es "schnellere" und v.a. im Endergebnis "stressfreiere" Lösungen gibt, als die cfg direkt per Texteditor anzufassen. Es ist nur allzu oft nicht bekannt => DAS sollte man m.E. irgendwie (auch) anpacken...
Zitat von: Wernieman am 27 Februar 2019, 13:48:50
Btw:
Finde es Lustig, das eine (aktuell) praktisch nicht verwendete Funktionalität (ein Feld wird dazugenommen), so eine Diskussionsauswirkung haben kann ...
Finde auch, dass es wichtigeres gäbe, als eine "Spezialistenfunktion" zu verbessern. Aber wer das wichtig findet, darf ja patches liefern, es ist open-source...
Zitat von: frank am 27 Februar 2019, 13:46:34
sondern beim einlesen der fhem.cfg in fhem.
Aber genau dann haben wir doch shon den Salat: cfg verbastelt, FHEM startet nicht mehr, oder nicht richtig. Fehlermeldungen gibt es (im Log) und nun steht der Anfänger genau vor dem Problem, was sich durch eine "saubere" Arbeit innerhalb von FHEMWEB schon von vornherein vermeiden oder minimieren ließe.
Zitat von: Beta-User am 27 Februar 2019, 13:58:57
Finde auch, dass es wichtigeres gäbe, als eine "Spezialistenfunktion" zu verbessern.
:-\ Den Satz verstehe ich irgenwie nicht.
Zitat von: Wernieman am 27 Februar 2019, 13:48:50
Finde es Lustig, das eine (aktuell) praktisch nicht verwendete Funktionalität (ein Feld wird dazugenommen), so eine Diskussionsauswirkung haben kann ...
Nun ja, die Diskussion wurde ja von einem cfg-Editierer ausgelöst, weil er nicht verstanden hat, dass er sich mit Datenstrukturen befasst, die er nicht versteht und auch gar nicht verstehen muss/soll.
Der Rest ist Geschichte....
Lustig? Nur mit Popcorn und Bier ;D
naja, ich verstehs schon ein bissi.
und NEIN! ich bin kein cfg-editierer, noch würd ich das je irgend nem neuen user empfehlen.
aber manchesmal muß es halt sein und dann stehst mitunter ein bissi blöd in der gegend rum.
bspl.:
vor ein paar wochen wollte mir fhem nicht anstarten - guter tipp aus dem forum: nimm mal die devices aus der cfg und setz sie der reihe nach wieder ein.
was natürlich keiner dazu sagt: mit der einfachen kopie ists nicht mehr getan. man muß die uuid entfernen, sonst kannst lange warten, bis fhem wieder mit dir will ...
mit einem laufenden fhem über rawdef kein problem. da steht ein großer hinweist am himmel.
wenn mans weiß, kein problem. als kleine nulpe kostet dir das wieder stunden, bis dus kapiert hast.
ansonsten versteh ich langsam, warum die deutsche regierung den popcorn-notstand ausgerufen hat *lach*
Zitat von: Benni am 27 Februar 2019, 14:18:18
:-\ Den Satz verstehe ich irgenwie nicht.
Sorry, wenn der Zusammenhang mit dem Wunsch von frank nicht mehr klar war, man möge doch auch die Prüfung der cfg beim Start verbessern (so hatte ich die beiden Beiträge interpretiert).
Es gibt - abgesehen von eventuellen Notfällen, die bei mir schon lange nicht mehr vorgekommen sind - vermutlich nur zwei große Gruppen von "Editieren": Die Anfänger, die nicht wissen, dass es (für sie) bessere Optionen gibt und die IT-Spezialisten (wie z.B. frank), die genau wissen, was sie mit welchem Werkzeug tun und daher auch keinen Stress damit haben.
Auch die ersteren sind auf ihre Art häufig "speziell", daher die Anführungszeichen ;) .
@frank: Auch wenn es nicht verboten ist (es ist open source...), gibt es m.E. eine ganz große Helfergruppe im Forum, die das direkte Editieren als mindestens "not recommended" betrachtet. Das (noch) fehlende "Verbot" zum Argument zu machen, Aufwand in irgendeine Art der Verbesserung dieses nicht verbotenen Wegs zu machen, ist ein "netter Versuch", aber ernsthaft:
Noch klarer machen, welche anderen, empfolenen Wege es gibt und gut ist...
Zitat von: Beta-User am 27 Februar 2019, 14:47:02
Sorry, wenn der Zusammenhang mit dem Wunsch von frank nicht mehr klar war, man möge doch auch die Prüfung der cfg beim Start verbessern (so hatte ich die beiden Beiträge interpretiert).
Es gibt - abgesehen von eventuellen Notfällen, die bei mir schon lange nicht mehr vorgekommen sind - vermutlich nur zwei große Gruppen von "Editieren": Die Anfänger, die nicht wissen, dass es (für sie) bessere Optionen gibt und die IT-Spezialisten (wie z.B. frank), die genau wissen, was sie mit welchem Werkzeug tun und daher auch keinen Stress damit haben.
@frank: Auch wenn es nicht verboten ist (es ist open source...), gibt es m.E. eine ganz große Helfergruppe im Forum, die das direkte Editieren als mindestens "not recommended" betrachtet. Das (noch) fehlende "Verbot" zum Argument zu machen, Aufwand in irgendeine Art der Verbesserung dieses nicht verbotenen Wegs zu machen, ist ein "netter Versuch",
1. nein, ich habe und hatte keinen wunsch.
2. nein, ich editiere keine fhem.cfg.
3. und nein, der hinweis auf eine legale vorgehensweise beim editieren der fhem.cfg war kein "netter versuch".
Zitat von: frank am 27 Februar 2019, 11:24:51
wäre es nicht effektiver den entgegengesetzten weg zu gehen?
da es nun mal den weg des manuellen editierens gibt, sollte dieser weg eventuell auch offensiv und anfängergerecht beschrieben sein. je einfacher und besser dokumentiert, desto weniger fehleranfällig.
da es hier genügend schlaue leute gibt, wird es auch immer eine anleitung zum manuellen editieren geben. wer es will, wird es dann auch machen. warum dann nicht den aufwand einer obfuskation in eine "automatische" fehlerminimierung stecken?
meine anregung war eigentlich zur minimierung des aufwandes aller helfenden gedacht.
unglaublich. scheinbar reicht schon der verdacht ein fhem.cfg-editierer zu sein, um unverzüglich auf dem scheiterhaufen zu landen. genau diese art "hexenjagd" missfällt mir bei diesem thema.
Zitat von: Benni am 27 Februar 2019, 14:18:18
Aber genau dann haben wir doch shon den Salat: cfg verbastelt, FHEM startet nicht mehr, oder nicht richtig. Fehlermeldungen gibt es (im Log) und nun steht der Anfänger genau vor dem Problem, was sich durch eine "saubere" Arbeit innerhalb von FHEMWEB schon von vornherein vermeiden oder minimieren ließe.
wenn beim einlesen der fhem.cfg, genau so wie über FHEMWEB, fehlerhafte anweisungen (define, attr) nicht zur ausführung kommen und identische fehlermeldungen im log erscheinen, verstehe ich die ganze aufregung um das editieren schon gar nicht mehr. dann sollte fhem doch weiterhin funktionieren, allerdings ohne die fehlerhaften anweisungen.
Vorab: sorry, wenn ich das mißverstanden hatte.
Schade, wenn meine Anmerkungen als negative Stimmungsmache ankamen, das war nicht beabsichtigt, und das hast du auch nicht verdient!
(Ich verstehe allerdings nach wie vor nicht so ganz, wieso du dann den "legalen Weg" besser beschrieben haben willst, das leuchtet mir einfach nicht ein).
Zitat von: frank am 27 Februar 2019, 16:57:39
wenn beim einlesen der fhem.cfg, genau so wie über FHEMWEB, fehlerhafte anweisungen (define, attr) nicht zur ausführung kommen und identische fehlermeldungen im log erscheinen, verstehe ich die ganze aufregung um das editieren schon gar nicht mehr. dann sollte fhem doch weiterhin funktionieren, allerdings ohne die fehlerhaften anweisungen.
Das ist nach meinem Kenntnisstand in der Regel auch so, dass FHEM - dann halt ggf. ohne die "kaputten Defines" startet und ins log schreibt, was übergangen wurde.
Warum also die "Aufregung" und die nachdrückliche Empfehlung, die editierer-Variante nicht zu propagieren:
Beim direkten Editieren kann man - aufgrund welcher Ursachen auch immer - allerdings mehr durcheinanderbringen als von FHEMWEB aus, beispielsweise die nachfolgende Zeile versehentlich maskieren, oder ein Hochkomma alleine stellen....
Als "Soweiso-Linuxer" habe ich da keine Erfahrung, aber "falsche" Zeilenumbrüche aus Redmond sind wohl auch was, auf das man aufpassen muß.
Aber im Ernst: Ich würde mir nicht zutrauen, eine "Wie editiert man fhem.cfg unfallfrei"-Anleitung zu schreiben. Die Erfahrung lehrt: irgendwas anderes, als das, was man geschrieben hat, geht dann doch schief, und hinterher beschwert sich der Betroffene, warum man das vergessen hat, wäre doch wichtig gewesen...
Wie dem auch sei, ich helfe auch weiterhin auch cfg-Editierern ;) . Anfänger bekommen halt den Schubser Richtung "stressfreier" Variante, und wer dann nicht ins log sieht, bekommt schließlich keinen support mehr. Die Erfahreneren haben sowieso entweder keine einfach zu beantwortenden Fragen und genug Erfahrung. Die Freiheit gönne ich ihnen, Verbote müssen nicht sein.
Und wieder dreht es sich im Kreis. Es gibt weder eine Hexenjagd noch negative Stimmungsmache. Es gibt lediglich Leute, die besseres zu tun haben, als Leuten zu helfen, die Beratungsresistent sind. Und das ist fair und gut. Wer es anders will, kann Pech haben. Auch gut.
Tut euch allen doch bitte einen gefallen und schließt den Thread hier, dass führt doch zu nichts sinnvollem.
Ok, gerade über die Suche gefunden. Sie setuuids sind für die Weiterentwicklung da und müssen mich nicht weiter stören. Alles andere - naja - da mische ich mich lieber nicht ein. Und: wofür die Dinger da sind, wurde nicht wirklich gesagt ...
Gruß Peter
wegen der suche:
Zitat von: PeMue am 03 September 2019, 20:17:18Und: wofür die Dinger da sind, wurde nicht wirklich gesagt ...
doch. wurde es. mehrfach. unter anderem im ursprungs thread hier: https://forum.fhem.de/index.php/topic,95902.msg888387.html#msg888387 und im weigern verlauf des threads gibt es noch mehr beispiele.
Zitat von: justme1968 am 03 September 2019, 20:33:40
wegen der suche:
unter anderem im ursprungs thread hier: https://forum.fhem.de/index.php/topic,95902.msg888387.html#msg888387 und im weiteren verlauf des threads gibt es noch mehr beispiele.
Ok, danke. Dann habe ich diesen nicht gefunden. Vermutlich weil ich die Suche nach dem ersten (vermeintlich besten) Treffer abgebrochen habe. Danke.
Gruß Peter
Ich kann nachvollziehen, dass es eine eindeutige ID braucht.
Aber wie genau gebt ihr Ausschnitte aus der Config an andere weiter?
Macht ihr einen Screenshot oder nehmt ihr nicht doch eher ein Copy/Paste aus der fhem.cfg?
Kopiert ihr dabei die ID mit?
Oder löscht ihr sie raus?
Bezüglich Config bearbeiten:
Ist eh nett gemeint, dass fhem.cfg bearbeiten "verboten" sein soll. Aber es gibt halt nix anderes, was irgendwie übersichtlich ist. Oder wie wäre der Weg, größere Teile einer Config von einem System zum anderen zu transportieren?
Oben in der Commandline definiere ich sicher keine MQTT Topic Attribute für eine Menge Devices, und dieses RAW Fenster, was genau soll das gut sein? Da seh ich auch nichts von der bestehenden Config, oder kann nichts Bestehendes bearbeiten.
Und dass man die fhem.cfg nicht bearbeiten dürfen soll, es aber gar keine andere, gleichwertige Alternative gibt, finde ich dann doch sehr strange.
Jedenfalls ist es nervig, wenn man z.B. Samples aus dem Web zum Testen in die fhem.cfg übernimmt und dann nichts funktioniert. Weil die uuid fehlt. Wenn diese schon übers WebUI automatisch angelegt wird, dann könnte sie genauso gut beim Speichern der fhem.cfg im WebUI automatisch angelegt werden.
Die Syntax von FHEM ist nunmal nicht für Herumgeklickse ausgelegt, sondern für einen Editor.
Zitat von: christiantf am 27 November 2019, 23:52:32
Aber wie genau gebt ihr Ausschnitte aus der Config an andere weiter?
Ich klicke auf "Raw definition" des gewünschten Device, und mache ein Copy/Paste. Die UUID ist da nicht sichtbar
ZitatDa seh ich auch nichts von der bestehenden Config, oder kann nichts Bestehendes bearbeiten.
Doch sieht man die vollstäntige Definition eines Devices. Man kann auch alles ändern, und man kann auch alles löschen, und ein Code Snipet einfügen (und die UUID wird automatisch kreiert). Sogar mit Syntax Highlighting (codemirror) und Syntax-Kontrolle
Seit 1,5 Jahre habe ich meine fhem.cfg nie editiert, weder auf dem produktiven System (ist sowieso auf ConfigDB) noch auf meinen beiden Testsystemen (noch mit fhem.cfg Dateien). Und ich bin fast sicher, dass ich viel mehr rumspiele als Du.
Du hast absolut Recht ::) Ich dachte irgendwie, das "Plus" links neben der Commandline wäre die "Raw definition". Und das kommt auch nur, wenn ein Device schon existiert.
In FHEM bzw. der FHEM-Config bin nur ab und zu, praktisch nie, und in der Regel nur dann, wenn etwas nicht mehr funktioniert oder ich was für jemanden ausprobieren.
Ich komme aus einer anderen Smarthome-Welt - KNX, Home Assistant, Loxone.
Auf die Gefahr hin, dass ich "der unwissende DAU" bin, möchte ich trotzdem hier meinen Blickwinkel zur ganzen Editor-Geschichte darlegen:
- "Raw definition", also ein Pseudo-Editor, warum wird das nur bei bestehenden Devices angezeigt, aber nicht immer? Das Konzept ohne fhem.cfg Editor, aber mit einem Pseudo-Texteditor, ist überhaupt nicht durchgängig. Da ist oben eine Command line, daneben ein Plus, dann mal ein "Raw definiton" klein irgendwo unten in der Fusszeile.
- Der eigentliche Attribut-Editor im WebIf, um Einstellungen festzulegen und zu ändern, ist viel zu viel Herumgeklickse um etwas einzustellen: Ein Dropdown öffnen, in der Attributliste herumsuchen, einen Eintrag auswählen, rechts einen Wert hinschreiben und dann links(!?) klicken, um den Wert zu setzen. Danach habe ich EIN Attribut gesetzt...!
- Warum werden bei einem Device nicht einfach alle Attribute als Liste hingeschrieben, rechts jeweils ein Eingabefeld und rechts daneben ein "Speichern-Symbol". Mit Tab von Feld zu Feld springen, und unten zusätzlich ein "Alles speichern". SO gibt man schnell Werte ein, und behält die Übersicht, was man gerade konfiguriert.
- So Dinge wie room oder group gehören immer oben hin, das sind für ein Smart Home doch die wichtigsten Eigenschaften...!
- Wie legt man ein neues Device über den Attribut Editor an? Alle Typen sind bekannt, es wäre doch sinnvoll, das ich ein Gerät mit einer Typ-Auswahl anlegen kann, statt einen String aus der Command Reference in die Eingabezeile zu kopieren.
- Das Datenmodell der configDB hab ich mir im Sourcecode angesehen, und das ist ja einfach eine 1:1 Kopie der fhem.cfg. Das Datenmodell gibt nichts her, außer dann man jetzt eine Volltextsuche machen kann. Da sehe ich für die Software jetzt noch gar keinen Vorteil, wenn die Datenbank noch nicht mal nach Type eines Devices unterscheiden kann.
Ich weiß, "das war immer so", "das gehört so", "du kennst dich nicht aus" usw. Stimmt alles. Das macht das Feedback vielleicht gerade erst interessant ;-)
lg, Christian
PS: Bitte schimpft nicht über Leute, die nicht jede Änderung am Sourcecode mitverfolgen, sondern die Software einfach benutzen, und dann mal eine Frage stellen. Das mit dem "Nicht die fhem.cfg bearbeiten" habe ich beispielsweise noch nie irgendwo gelesen.
ZitatUnd das kommt auch nur, wenn ein Device schon existiert.
Ich kenne kein Fhem, der kein Device hat... Schon um eine Weboberfläsche zu haben, gibt es ein Device des Typs FHEMWEB und ein Device global
Zitat- Der eigentliche Attribut-Editor im WebIf, um Einstellungen festzulegen und zu ändern, ist viel zu viel Herumgeklickse um etwas einzustellen: Ein Dropdown öffnen, in der Attributliste herumsuchen, einen Eintrag auswählen, rechts einen Wert hinschreiben und dann links(!?) klicken, um den Wert zu setzen. Danach habe ich EIN Attribut gesetzt...!
- Warum werden bei einem Device nicht einfach alle Attribute als Liste hingeschrieben, rechts jeweils ein Eingabefeld und rechts daneben ein "Speichern-Symbol". Mit Tab von Feld zu Feld springen, und unten zusätzlich ein "Alles speichern". SO gibt man schnell Werte ein, und behält die Übersicht, was man gerade konfiguriert.
Es gibt auch Devices, die über 100 mögliche Attribute haben (für HTTPMOD sogar unendlich - hab eins mit 300 Attribute). Schon ein HM Rollo mit ASC hat um die 100 Attribute. Wäre sehr unübersichlich, alle immer am Bildschirm zu haben, wenn nur eine 10 davon benutzt sind.
Zitat- So Dinge wie room oder group gehören immer oben hin, das sind für ein Smart Home doch die wichtigsten Eigenschaften...!
- Wie legt man ein neues Device über den Attribut Editor an? Alle Typen sind bekannt, es wäre doch sinnvoll, das ich ein Gerät mit einer Typ-Auswahl anlegen kann, statt einen String aus der Command Reference in die Eingabezeile zu kopieren.
Interessant
Zitat- Das Datenmodell der configDB hab ich mir im Sourcecode angesehen, und das ist ja einfach eine 1:1 Kopie der fhem.cfg. Das Datenmodell gibt nichts her, außer dann man jetzt eine Volltextsuche machen kann. Da sehe ich für die Software jetzt noch gar keinen Vorteil, wenn die Datenbank noch nicht mal nach Type eines Devices unterscheiden kann.
Nicht 1:1. ConfigDB hat Versioning dazu
Zitat von: christiantf am 28 November 2019, 01:29:39
- "Raw definition", also ein Pseudo-Editor, warum wird das nur bei bestehenden Devices angezeigt, aber nicht immer? Das Konzept ohne fhem.cfg Editor, aber mit einem Pseudo-Texteditor, ist überhaupt nicht durchgängig. Da ist oben eine Command line, daneben ein Plus, dann mal ein "Raw definiton" klein irgendwo unten in der Fusszeile.
- Der eigentliche Attribut-Editor im WebIf, um Einstellungen festzulegen und zu ändern, ist viel zu viel Herumgeklickse um etwas einzustellen: Ein Dropdown öffnen, in der Attributliste herumsuchen, einen Eintrag auswählen, rechts einen Wert hinschreiben und dann links(!?) klicken, um den Wert zu setzen. Danach habe ich EIN Attribut gesetzt...!
- Warum werden bei einem Device nicht einfach alle Attribute als Liste hingeschrieben, rechts jeweils ein Eingabefeld und rechts daneben ein "Speichern-Symbol". Mit Tab von Feld zu Feld springen, und unten zusätzlich ein "Alles speichern". SO gibt man schnell Werte ein, und behält die Übersicht, was man gerade konfiguriert.
Gueten Morgen,
Weil jemand sich hingesetzt hat und in seiner Freizeit es so programmiert hat. Man kann es auch anders machen wenn es einem nicht zu sagt. Hier ist nichts in Stein gemeißelt. Du kannst DEIN Frontend so machen wie Du es für Gut und Richtig erachtest.
Zitat von: christiantf am 28 November 2019, 01:29:39
- So Dinge wie room oder group gehören immer oben hin, das sind für ein Smart Home doch die wichtigsten Eigenschaften...!
Wer sagt sowas! Steht das irgendwo in einer Guidline oder so?
6 User die ich kenne und ich interessiert es zum Beispiel gar nicht wo was im FHEMWEB steht, wir benutzen es nicht. Du siehst, Deine Aussagen mögen für Dich zutreffend sein. Für andere sicherlich nicht. Wenn Du ein Frontend für FHEM Entwickeln möchtest dann findest Du aber auch sicherlich 1000 Leute die, sofern Du es nach deren Geschmack machst, Dir Zustimmung geben und sagen ja so sollte es aussehen das finde ich toll. Bis dahin kann man zwar sagen das man es selbst ungünstig im Aufbau findet aber mehr bitte auch nicht.
Zitat von: christiantf am 28 November 2019, 01:29:39
- Das Datenmodell der configDB hab ich mir im Sourcecode angesehen, und das ist ja einfach eine 1:1 Kopie der fhem.cfg. Das Datenmodell gibt nichts her, außer dann man jetzt eine Volltextsuche machen kann. Da sehe ich für die Software jetzt noch gar keinen Vorteil, wenn die Datenbank noch nicht mal nach Type eines Devices unterscheiden kann.
Wozu soll die Datenbank nach Device Typen unterscheiden können. Sowas ist nicht Teil einer Datenbank. Eine Datenbank hat Daten vor zu halten und gut ist. Derjenige der den Aufbau der Datenbank plant kann entscheiden was wie benötigt wird. Wenn derjenige sagt es ist nicht wichtig weil man es ja über FHEM macht dann ist es eben so.
Ich kenne persönlich Deine FHEM Erfahrung nicht, aber ich würde mal sagen versuche doch erstmal FHEM kennen zu lernen, schaue wie Du was an Logik und Geräten unterbringst und schaue Dich um ob Du nicht noch ein anderes für Dich besser passendes Frontend findest. FHEMWEB ist nicht das einzige.
Grüße
Leon
Trotzdem finde ich folgendes interessant:
ZitatAlle Typen sind bekannt, es wäre doch sinnvoll, das ich ein Gerät mit einer Typ-Auswahl anlegen kann, statt einen String aus der Command Reference in die Eingabezeile zu kopieren.
im Sinn von "Unterstützte Erstellung eines Devices"
Mir fehlen die Programmierungkenntnisse (Hmmm... stimmt nicht ganz... eigentlich fehlt mir eher die Zeit...), um sowas zu programmieren, aber ich sehe das als Verbessrungsvorschlag...
Und... algemeines Kommentar: man muss nicht unbedingt jeden Kommentar interpretieren, als ob etwas "falsch" entwickelt gewesen wäre. Natürlich kann jeder sein Frontend entwickeln. Das heisst nicht, dass das Hauptfrontend nicht verbessert werden kann. ;)
und warum ist es einfacher aus einer liste von 500+ typen auszuwählen statt eine hand voll buchstaben zu tippen?
eine scheinbar endlose liste ist keine lösung.
devices automatisch suchen und anlegen ist ein teil der lösung. leider komme ich nicht dazu damit eiter zu machen. wie so etwas aussehen könnte ist hier: https://forum.fhem.de/index.php/topic,67368.msg880001.html#msg880001 zu sehen.
Zitat von: justme1968 am 28 November 2019, 12:02:24
und warum ist es einfacher aus einer liste von 500+ typen auszuwählen statt eine hand voll buchstaben zu tippen?
eine scheinbar endlose liste ist keine lösung.
Da hast Du natürlich recht.
Zitat von: justme1968 am 28 November 2019, 12:02:24
devices automatisch suchen und anlegen ist ein teil der lösung. leider komme ich nicht dazu damit eiter zu machen. wie so etwas aussehen könnte ist hier: https://forum.fhem.de/index.php/topic,67368.msg880001.html#msg880001 zu sehen.
Ich fand das sehr verspreschend, als ich es gelesen habe. Warum schaffst Du es nicht weiter zu machen? Zeit (kann ich verstehen)?
Klingt für mich auch ein wenig nach attrTemplate!?
Da wählt man doch bei einem "pseudo angelegten" Device dann den richtigen (hoffentlich ;) ) Typ aus bzw. macht eine "Feinspezifizierung"!?
Gruß, Joachim
Na ja, attrTemplate ist imo was anderes; das setzt erst mal ein vorhandenes Device voraus, und teilweise erfordert die korrekte weitere automatische Konfiguration, dass das Device "etwas weiß", also z.B. bei den MQTT2_DEVICEs schon mal eine passende readingList da ist, die man auswerten kann...
Man _könnte_ das vielleicht kombinieren (und es ginge wohl auch, Devices automatisiert zu erstellen), aber insgesamt glaube ich nicht so recht an eine massive Erleichterung durch dieses tool, die wesentlich über das rausgeht, was jetzt schon geht.
(Das schließt "Kleinigkeiten" nicht aus, wie z.B. in der "?"-Übersicht z.B. gleich den FHEM-Command zu verlinken, um einen bestimmten HTTPMOD direkt zu erstellen. Bisher mußte man das eben kopieren und in eine Kommandozeile einfügen... Aber wem das zu viel ist, sollte evtl. dann eine andere HA-Lösung wählen :P ).
Zu den Feststellungen von christiantf noch:
Vielleicht könnte man am UI manches noch optimieren, aber meistens ist es doch so, dass man Attribute einmal vergibt, und das war's. Wenn man mal den Weg über RAW (Input oder Edit) gefunden hat (und dann ggf. noch was vorhandenes einfach als Ausgangsbasis für den "Klon" hat), ist es m.E. kaum mehr wert, darüber zu diskutieren, dass es noch einfacher ginge.
Unschön ist, dass das mit "cfg-editieren sein lassen, stattdessen 'plus' und RAW verwenden" in der Doku ggf. nicht so präsentiert wird, dass es Einsteiger gleich finden.
Was configDB angeht: Man mag lange darüber streiten, welches Datenmodell denn sinnvoll ist. Mir ging es ein paarmal so, dass Devices durch "unbedachtes" speichern verloren gegangen waren (weil die betreffenden Devices aus irgendeinem Grund grad nicht verfügbar waren, später aber wohl) und ich es leid war, immer wieder dieselben backups rauszukramen.
Da habe ich einfach ein besseres Gefühl, wenn ich bei Bedarf mal die DB befragen kann, ob die noch was weiß. (Ist aber aus anderen Gründen dann praktisch nie mehr erforderlich gewesen...)
ZitatDas mit dem "Nicht die fhem.cfg bearbeiten" habe ich beispielsweise noch nie irgendwo gelesen.
Das geht wirklich nur, wenn man sehr wenig liest...
Zitatund warum ist es einfacher aus einer liste von 500+ typen auszuwählen statt eine hand voll buchstaben zu tippen?
Ein Szenario wäre: Maus vorhanden, aber keine Tastatur...
Oder: Kann lesen, aber nicht schreiben...
LG
pah
Edit: Habe den Spruch gerade erst gelesen und mich scheckig gelacht...
ZitatDie Syntax von FHEM ist nunmal nicht für Herumgeklickse ausgelegt, sondern für einen Editor.
Ich freue mich immer wie ein Waschbär, wenn FHEM-Neulinge uns die Welt erklären wollen.
ZitatEin Szenario wäre: Maus vorhanden, aber keine Tastatur...
Oder: Kann lesen, aber nicht schreiben...
Das erfordert dann noch das Generieren von Geraete-, Raum-, und Gruppennamen.
Z.Bsp. man nimmt jeweils eine Menge von seltsamen Attributen und Hauptwoertern, und man wuerfelt die Zusammenstellung aus, wie bei Ubuntu oder bei Docker-Container.
Die Herausforderung ist zu wissen, was wofuer steht :)
Zitat von: rudolfkoenig am 28 November 2019, 20:37:09
Das erfordert dann noch das Generieren von Geraete-, Raum-, und Gruppennamen.
Z.Bsp. man nimmt jeweils eine Menge von seltsamen Attributen und Hauptwoertern, und man wuerfelt die Zusammenstellung aus, wie bei Ubuntu oder bei Docker-Container.
Die Herausforderung ist zu wissen, was wofuer steht :)
nix da, die Räume und Gruppen werden per cut & Paste "eingetragen"
Zitat von: Prof. Dr. Peter Henning am 28 November 2019, 20:17:58
Edit: Habe den Spruch gerade erst gelesen und mich scheckig gelacht...Ich freue mich immer wie ein Waschbär, wenn FHEM-Neulinge uns die Welt erklären wollen.
Ich erkläre euch nicht die Welt, sondern die Welt, die ich sehe :-) (deswegen hab ich doch geschrieben, dass ich "aus einer anderen Welt" komme)
Ich hab das wirklich ganz wertfrei gemeint, wo ich eben als Neueinsteiger meine Probleme damit habe. Es war als Feedback von Entwickler zu Entwickler gemeint. Ich bin selbst im Core-Entwicklerteam von LoxBerry (https://github.com/mschlenstedt/Loxberry) (https://github.com/mschlenstedt/Loxberry), ich muss mir "blöde" Kommentare von "Unwissenden" auch anhören, aber dann stellt sich heraus, dass die gar nicht so unwissend sind, und oft steckt dann doch was drin, was man in die Software mitnehmen kann.
Das mit dem Datenmodell der configdb hab ich aber (als "Unbeteiligter" bei FHEM, aber mit doch ein bisschen Erfahrung mit Datenbanken) ernst gemeint, dass das doch ein grober Einschnitt/Änderung für alle Benutzer von FHEM ist, deren Nutzen im Verhältnis zum Umstellungsaufwand der User sehr gering ist. Ich glaube, in einer Datenbank würde für FHEM viel mehr Potenzial stecken, wenn die Daten strukturiert abgelegt wären.
lg, Christian
Zitat von: christiantf am 02 Dezember 2019, 20:30:13
Ich erkläre euch nicht die Welt, sondern die Welt, die ich sehe :-) (deswegen hab ich doch geschrieben, dass ich "aus einer anderen Welt" komme)
Ich hab das wirklich ganz wertfrei gemeint, wo ich eben als Neueinsteiger meine Probleme damit habe. Es war als Feedback von Entwickler zu Entwickler gemeint. Ich bin selbst im Core-Entwicklerteam von LoxBerry (https://github.com/mschlenstedt/Loxberry) (https://github.com/mschlenstedt/Loxberry), ich muss mir "blöde" Kommentare von "Unwissenden" auch anhören, aber dann stellt sich heraus, dass die gar nicht so unwissend sind, und oft steckt dann doch was drin, was man in die Software mitnehmen kann.
Das mit dem Datenmodell der configdb hab ich aber (als "Unbeteiligter" bei FHEM, aber mit doch ein bisschen Erfahrung mit Datenbanken) ernst gemeint, dass das doch ein grober Einschnitt/Änderung für alle Benutzer von FHEM ist, deren Nutzen im Verhältnis zum Umstellungsaufwand der User sehr gering ist. Ich glaube, in einer Datenbank würde für FHEM viel mehr Potenzial stecken, wenn die Daten strukturiert abgelegt wären.
lg, Christian
Dann sage ich einfach mal Danke für Deine Ansicht.
Der configdb Entwickler liest es hier sicherlich und vielleicht fällt ihm ja was zum Thema ein.
Grüße
Bin gerade über dieses Thema gestoßen, ich bin gerade dabei mit 7896 Zeilen in der fhem.cfg auf einen anderen Server umzuziehen, da der Stand auf dem alten Server von 2018 ist, also vor FUUID Einführung (update kann ich auf dem System nicht machen, würde zuviel Fehler generieren), ist es iMo sehr zeitaufwändig jedes device auf dem neuen Server über WEbif neu anzulegen, damit die FUUID angelegt wird. Anderseits sieht man alte "FHEM-Leichen" und Sachen die nicht mehr funktionieren und angepasst werden müssen. Also tippe ich bestimmt noch bis zum WE :-)
(Server neu mit Debian 11 bullseye und FHEM nightly)
Wo ist der Unterschied bzw. ob du nun auf dem alten Server oder dem neuen ein Problem mit fhem update bekommst ;)
Und wo ist der Unterschied zu Probleme Stück für Stück oder Rutsch auf einmal: backup fhem aktueller Server, fhem auf neuem installieren, backup einspielen und dann fhem update (evtl. vorher kontrollieren, ob was vom OS fehlt)...
So ziehe ich seit Wheezy um... :)
Außer dass Stück für Stück (hoffentlich per RawDef) länger dauert... 8)
Die uuid kannst du ignorieren, die kommt dann schon... ;)
EDIT: Leichen vorher löschen oder gleich nach dem Umzug... Und wenn was nicht mehr tut merkst du das auch schnell nach dem "Komplett-in-einem-Rutsch-Umzug"...
Gruß, Joachim
yep, sehe ich auch so. Die Neuinstallation schafft ja nur das Grundgerüst auch für das OS (Autostart etc), das Backup bombt das System ja dann inklusive aller Module auf den Stand von 2018 zurück, der nächste Neustart sollte demnach keine fehlenden uuid bemeckern können. Und die Updates sind ja darauf ausgelegt, die uuid automatisch nachzulegen. Oder habe ich das jetzt falsch verstanden?
Zitat von: Pfriemler am 25 Oktober 2021, 22:47:59
yep, sehe ich auch so. Die Neuinstallation schafft ja nur das Grundgerüst auch für das OS (Autostart etc), das Backup bombt das System ja dann inklusive aller Module auf den Stand von 2018 zurück, der nächste Neustart sollte demnach keine fehlenden uuid bemeckern können. Und die Updates sind ja darauf ausgelegt, die uuid automatisch nachzulegen. Oder habe ich das jetzt falsch verstanden?
Nope, also jep ;)
Sehe ich genauso...
EDIT: wobei ich trotzdem vor dem Umzug ein fhem update fahre (man kann ja mal vorher ein Image ziehen oder einen Komplett-tar-Abzug ["sparsamer"])...
EDIT: kleine "Korrektur" Dinge die OS-seitig fehlen (z.B. Perl-libs etc.) fallen nat. schon sofort auf, also nach dem Einspielen des backup... Aber dann kann man sich da schon mal drum kümmern bevor der nächste Schtitt kommt: fhem update ;)
EDIT: Umzug von "CUL_HM-Devices" per RawDef ist auch nicht ohne...
Gruß, Joachim