Lässt sich "setuuid" deaktivieren oder ignorieren

Beta-User · 28 November 2019, 13:07:38

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

).

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

Prof. Dr. Peter Henning · 28 November 2019, 20:17:58

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.

rudolfkoenig · 28 November 2019, 20:37:09

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

Wuppi68 · 29 November 2019, 15:04:03

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"

christiantf · 02 Dezember 2019, 20:30:13

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), 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

CoolTux · 02 Dezember 2019, 20:56:57

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), 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

franky08 · 25 Oktober 2021, 22:29:39

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)

MadMax-FHEM · 25 Oktober 2021, 22:43:23

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

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

Pfriemler · 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?

MadMax-FHEM · 25 Oktober 2021, 22:49:17

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