[GELÖST] wie gleichartige Geräte mit gleichen Attributen versorgen?

[betateilchen]

Re Kommandozeile: aber es geht doch um die Vorkonfiguration von Devices, was,  dachten wir, mit in die Konfigurationsdatei(en) gehört.

komplett falsch gedacht. Rate mal, wozu der "Save config" Button in der Weboberfläche von fhem vorhanden ist.

Warum sollten wir das nach jedem FHEM-Neustart neu eingeben müssen?

Müsst ihr gar nicht. Die vorhandene Konfiguration wird beim fhem Neustart einfach wieder eingelesen und verwendet.

Übrigens: wer anstatt der antiquierten Konfigurationsdateien mit der ebenfalls möglichen Konfigurationsdatenbank arbeitet, macht sich das Leben, gerade beim Experimentieren, sehr viel einfacher.

[rudolfkoenig]

Dienstleistung auf dem kostenlos vermittelten Wissen anderer aufbauen möchten

Ich muss mich auch schuldig bekennen: ich habe weder fuers Lesen/Schreiben-Lernen, noch fuer Informatik-Studium was bezahlt, bin dankbar dafuer, und verdiene mein Geld damit. Auf der anderen Seite: keiner ist verpflichtet hier zu helfen. Aber wenn man nicht helfen will, dann lieber ohne Text.

[marvin78]

Ein Vergleich von Äpfeln mit Birnen könnte nicht schlechter ausfallen, ich nehme aber an, dass dir das bewusst ist. Deine Professoren und Lehrer haben sicher alle ehrenamtlich gearbeitet....

Damit bin ich aus der Diskussion raus. Das gehört hier nicht hin und könnte Seiten füllen.

[Mitch]

Mal wieder zurück zum Topic 

Warum so kompliziert?
Ich habe das mit meinen Rollos ganz einfach so gemacht: attr Rollo_.* devStateIcon Auf:fts_shutter_10 Zu:fts_shutter_100 20:fts_shutter_70
Und schon haben alle Rollo Devices dieses Attribut.

Setzt halt nur eine "vernünftige" Namensgeung voraus.

[igami]

Hat sich schon mal einer von euch das archetype Modul angeschaut? Das gleicht auch neue Devices immer wieder mit ab ohne dass ich händische eingreifen muss. Ist aber ein inofizielles Modul und noch in Entwicklung.

[betateilchen]

Hat sich schon mal einer von euch das archetype Modul angeschaut?

Ja habe ich. Bis jetzt erschließt sich mir der Sinn noch nicht.

[united-networking]

Hi,

@Mitch: und genauso funktionierts jetzt auch bei uns, wie am Anfang auch gedacht.
Anderswo hörten wir mal "Sobald man alles richtig macht, funktionierts plötzlich."

@betateilchen: Mit "Save config" landen die letzten Änderungen dann in der(den) Konfigurationsdatei(en), nicht?
Da wir uns aber eine Aufteilung der fhem.cfg angelegt haben, meist in der falschen. Aber gut, notfalls kopieren wir anschließend halt in die richtige Teildatei um.
Von der Konfigurationsdatenbank hatten wir noch nicht gehört und machen uns nun auf die Suche nach Dokumentation dazu.

Ja, wir sind eine Firma, und eingedenk der Forumsregeln machen wir keinen Hehl daraus.
Mit Hausautomation sind wir blutige Anfänger (daher in diesem Unterforum unterwegs) und machen Fehler. Einstweilen ist das für uns noch länger ein Experimentierfeld und bis wir daraus eventuell ein "Produkt" anbieten können (wenn überhaupt), vergeht mit Sicherheit noch reichlich Zeit.

Wenn "kommerzielle" Forumsteilnehmer keine Fragen stellen sollen, sollte das vielleicht mit in die Dokumentation für neue Teilnehmer rein, um Missverständnissen vorzubeugen.

Ansonsten sind wir dankbar für jeden Hinweis und werden, wo wir uns kompetent genug fühlen, auch selbst gerne weiterhelfen.

[united-networking]

Hi,

@betateilchen: Ok, gefunden: Modul configdb. Danke für den Tipp.

[betateilchen]

Mit "Save config" landen die letzten Änderungen dann in der(den) Konfigurationsdatei(en), nicht?
Da wir uns aber eine Aufteilung der fhem.cfg angelegt haben, meist in der falschen.

Eine Aufteilung der fhem.cfg macht wenig Sinn. Man sollte besser nicht darin herumpfuschen.

Mit "save config" landen die devices genau in den Konfigurationsdateien, aus denen sie gelesen wurden.
Neu angelegte devices landen in der fhem.cfg, da sie natürlich noch keinen Marker für die "eigene" Konfigurationsdatei haben.

Genau wegen all dieser Krämpfe habe ich vor einigen Jahren die Konfigurationsdatenbank gebaut, da muss man sich über solche Dinge keine Gedanken mehr machen. Und man kommt auch nicht in die Versuchung, irgendwas manuell "besser" machen zu wollen, als FHEM das automatisch (richtig) macht.

[rudolfkoenig]

da muss man sich über solche Dinge keine Gedanken mehr machen.

Muss man bei der Dateibasierten (fhem.cfg) eigentlich auch nicht. Und unfairerweise kommt bei configDB keiner auf die Idee, die Konfiguration in separate Tabellen ablegen zu wollen, damit es "ordentlich" ist.

[betateilchen]

Muss man bei der Dateibasierten (fhem.cfg) eigentlich auch nicht.

Hab ich ja geschrieben - aber Du weißt ja selbst, dass sich immer wieder viel zu viele Anfänger Anwender viel zu viele (meist falsche) Gedanken darüber machen.

Und unfairerweise kommt bei configDB keiner auf die Idee, die Konfiguration in separate Tabellen ablegen zu wollen, damit es "ordentlich" ist.

Was ist daran unfair? Das war ja einer der wichtigsten Hintergedanken bei der Entwicklung der Datenbank.

Darüber hinaus hat die Datenbank noch ganz andere Vorteile gegenüber der fhem.cfg:

• Man kann gplot holiday layout Dateien in der Datenbank ablegen, genau wie images, icons und andere Dateien. Das erleichtert Systemumzüge und Systemkopien erheblich.
• Man kann mehrere Konfigurationsversionen in der Datenbank verwalten.
• Man kann in einer einzigen zentralen Datenbank die Konfigurationen mehrerer einzelner FHEM Installationen ablegen.
• ...

[united-networking]

Hi,

zurück zum Thema; bei einem neuerlichen Hinsehen stellten wir eben fest, dass die attr-Regeln mit RegEx'es verschwunden sind und stattdessen mit einzeln aufgelösten Werten den jeweiligen Devices zugeordnet wurden, fast wie Resultate von copy.

Das finden wir überaschend, wenn auch nachvollziehbar. Leider fand sich in der Referenz unter #devspec nichts dazu.

Das konterkariert ausserdem unsere Absicht, sozusagen Device-Template-Regeln anzulegen, und neue Devices passender Namen werden somit nicht mehr automatisch mit komplexen Attributen versorgt.

Wir schauen dann nochmal das Modul archetype genauer an...

[betateilchen]

dass die attr-Regeln mit RegEx'es verschwunden sind und stattdessen mit einzeln aufgelösten Werten den jeweiligen Devices zugeordnet wurden,

• es gibt keine attr-"Regeln"
• das von Dir beschriebene Verhalten ist exakt das, wofür devspec gedacht ist. Was hattest Du anderes erwartet?

Du solltest Dich wirklich dringend mit den absoluten GRUNDLAGEN von fhem beschäftigen, bevor Du versuchst, irgendwas umzusetzen, von dem Du selbst überhaupt noch nicht verstanden hast, was Du da eigentlich tust.

[JoeALLb]

Übrigens: wer anstatt der antiquierten Konfigurationsdateien mit der ebenfalls möglichen Konfigurationsdatenbank arbeitet, macht sich das Leben, gerade beim Experimentieren, sehr viel einfacher.

einfacher, solange man für den Start von FHEM keine Zeile aus der Config wieder entfernen muss (die den Start von FHEM verhindert)....

[betateilchen]

Hast Du eigentlich jemals die Dokumentation zu configDB gelesen, oder geht es Dir tatsächlich nur um sinn- und inhaltsloses Bashing gegen Dinge, von denen Du offensichtlich keinen blassen Schimmer hast?

Die configDB bringt von Haus aus einen "Notstart-Modus" mit, wenn man sich tatsächlich einmal "kaputtkonfiguriert" haben sollte.