Lässt sich "setuuid" deaktivieren oder ignorieren

[DeeSPe]

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

[marvin78]

Ich bin der Meinung, dieser Thread sollte geschlossen werden. Mindestens.

[frank]

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.

genau: zur zeit (noch) nicht.

[marvin78]

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.

[Benni]

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!

ich bin dafür die fhem.cfg zu "obfuskieren"

Oder gleich auf configDB wechseln

*duckundweg*

[nils_]

Oder gleich auf configDB wechseln

*duckundweg*

das eine schließt ja das andere nicht aus

[frank]

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.

[Benni]

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!

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.

[frank]

Wie 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.

[Wernieman]

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 ...

[Beta-User]

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 . 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...

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...

[Benni]

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.

Finde auch, dass es wichtigeres gäbe, als eine "Spezialistenfunktion" zu verbessern.

Den Satz verstehe ich irgenwie nicht.

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 

[the ratman]

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*

[Beta-User]

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...

[frank]

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".

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.

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.