Hallo,
nachdem der erste motorisierte Rolladen mit icon, cmdIcon, "animiertem" devStateIcon und weiteren Verzierungen bedacht wurde, freute sich der Adressat der Hausautomation sehr und wollte nun gerne alle 10 Rolläden der Wohnung genauso haben.
Bevor nun eine Copypastenaktion fällig wäre, erstmal die Frage in die Runde:
Gibt es eine Methode, attr mehreren devices zuzuweisen, vielleicht mit RegEx oder dummy devices?
Falls dies in den 672 Seiten Anfängerfragen doch schon behandelt wurde, wären wir für einen Hinweis dankbar...
Wenn ich mich recht erinnere, gibt es ein Modul dafür. Es heißt archetype.
Und es gibt den copy Befehl.
Ja, das geht mit devspec. Alternativ kannst du aber auch mein noch in der Entwicklung befindliches Modul archetype (https://forum.fhem.de/index.php?topic=53402.0) verwenden.
Zu langsam :D
Zitat von: united-networking am 23 Januar 2017, 16:57:00
Gibt es eine Methode, attr mehreren devices zuzuweisen, vielleicht mit RegEx oder dummy devices?
Jepp, nennt sich devspec https://fhem.de/commandref_DE.html#devspec
Hi,
danke für die Tipps! Probieren gerade mit devspec rum...
@igami: was ist "zu langsam", devspec oder archetype?
Er
attr Devspec AttributName InhaltDesAtrributes
vorher sicherrn
anwenden
testen, testen, testen und erst danach wieder speichern :-)
Hi,
hmm, nach dem FHEM-Reference-Artikel http://www.fhem.de/commandref.html#devspec (http://www.fhem.de/commandref.html#devspec) und den Beispielen (freilich keins mit attr) hatten wir eigentlich gedacht:
attr Bewegung.* devStateIcon motion:people_sensor@red noMotion:people_sensor@black
oder
attr NAME=Bewegung.* devStateIcon motion:people_sensor@red noMotion:people_sensor@black
, was beides nix fruchtete.
Also demnach stattdessen:
attr DevSpec Bewegung.* devStateIcon motion:people_sensor@red noMotion:people_sensor@black?
Probieren wir...
Nein. DevSpec sollte in dem Beispiel für die devspec stehen. Devspec funktioniert genau so, wie in der commandref beschrieben.
Um zu testen, ob ein devspec auf alle Devices, dioe man erreichen möchte passt, kann man auch mal ein
list <devspec>
ausführen und schauen, ob alle gesuchten Devices aufgelistet werden.
Der Befehl zum Setzen des Attributs gehört übrigens in die Kommandozeile, nicht in die Config. Das macht dort überhaupt keinen Sinn.
Bitte beschäftigt euch doch einmal mit den Grundlagen von FHEM.
Hi,
mea culpa, mea maxima culpa...
Wer die fhem.cfg in mehrere aufteilt und eine zusätzliche solche in Umlauf bringt ohne sie zu include'n, wird mit Brett vorm Kopf nicht unter Daumesdicke bestraft.
Klappt nun schonmal mit beiden Formen die wir versucht hatten, mit oder ohne NAME=
Danke nochmal für die Tipps!
Hi,
@marvin78: ja da liegt das Problem bei der Zeit:
Im Prinzip lesen wir die Anfänger-PDF parallel mit dem Experimentieren und geben momentan der Suche in Referenz, Wiki und Forum eher Vorang vor dem PDF, da immer wieder Fragen auftauchen, die darin nicht behandelt werden.
Re Kommandozeile: aber es geht doch um die Vorkonfiguration von Devices, was, dachten wir, mit in die Konfigurationsdatei(en) gehört. Warum sollten wir das nach jedem FHEM-Neustart neu eingeben müssen?
Verstehen wir das falsch, und wenn ja, warum? Ein Hinweis auf bereits existierende Begründungen wäre natürlich willkommen.
Tut uns leid, wenn das sogar für dies Forum zu sehr NOOBmäßig erscheint.
Ich weiß nicht, was ihr da macht, aber wenn ihr das als Dienstleistung verkaufen möchtet, müsst ihr ganz sicher anders vorgehen.
Die Konfguration von Devices kann und sollte komplett im Frontend erfolgen. Die Config muss gar nicht angefasst werden (mache ich seit Jahren nicht. Darin sind 120000 Zeilen Kraut und Rüben, aber FHEM weiß wo alles steht und die Strukturierung macht das Frontend). Dann ist auch devspec sinvoll. Setzt man dann ein Attribut per devspec über die Kommandozeile, wird es bei JEDEM Device gesondert gesetzt. Eine Befehlsfolge mit devspec gehört aber, genau wie ein direktes set, nicht direkt in die Config. Dann wird man, mehr oder weniger, der Möglichkeit beraubt, die Attribute (oder andere Dinge) gesondert zu ändern. Das kann und soll nicht der Sinn der Sache sein.
Eine Bitte: Die Grundlagen lernen sollte der Anfang sein. Dann kommt das Testen. Lesen, lesen, lesen.. Die Fragen, die ihr hier stellt, sind auch nicht besonders neu oder gar originell. Im Gegenteil. Ich habe so ein wenig das Gefühl, dass ihr ein Gewerbe auf dem kostenlosen Support anderer aufbauen möchtet. Deshalb bin ich auch hier raus. Viel Erfolg, vermutlich wird das aber so nichts.
Zitat von: marvin78 am 24 Januar 2017, 13:26:55
Ich habe so ein wenig das Gefühl, dass ihr ein Gewerbe auf dem kostenlosen Support anderer aufbauen möchtet. Deshalb bin ich auch hier raus. Viel Erfolg, vermutlich wird das aber so nichts.
ich auch
Es steht selbsverständlich jedem frei, sich zu überlegen, ob man einem kommerziellen Forummitglied hier helfen möchte oder nicht.
ABER:
ein solches "Gefühl" in Form eines Verdachtes/Vorwurfs zu äußern
Zitat von: marvin78 am 24 Januar 2017, 13:26:55
Im Gegenteil. Ich habe so ein wenig das Gefühl, dass ihr ein Gewerbe auf dem kostenlosen Support anderer aufbauen möchtet.
halte ich hier für unangemessen, da der Benutzer "united-networking" eindeutig als kommerzieller Anbieter hier im Forum gekennzeichnet ist.
Ich habe nicht den Verdacht geäußert, dass man kommerzielle Absichten hat (ich kann lesen) sondern dass sie ihre Dienstleistung auf dem kostenlos vermittelten Wissen anderer aufbauen möchten. Das sind verschiedene Paar Schuhe. Als kommerzieller Anbieter "mal" eine Frage zu stellen, halte ich nicht für ganz verwerflich, das was hier versucht wird, jedoch schon. Es gibt mehr als nur schwarz und weiß.
Trotdzem habe ich vor meinem Beitrag vorhin für mich entschieden, kommerziellen Anbietern keinerlei weitere Hilfestellung zu geben.
Zitat von: united-networking am 24 Januar 2017, 13:18:52
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.
Zitat von: united-networking am 24 Januar 2017, 13:18:52
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.
ZitatDienstleistung 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.
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.
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.
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.
Zitat von: igami am 24 Januar 2017, 16:04:09
Hat sich schon mal einer von euch das archetype Modul angeschaut?
Ja habe ich. Bis jetzt erschließt sich mir der Sinn noch nicht.
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.
Hi,
@betateilchen: Ok, gefunden: Modul configdb. Danke für den Tipp.
Zitat von: united-networking am 24 Januar 2017, 16:22:46
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.
Zitatda 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.
Zitat von: rudolfkoenig am 24 Januar 2017, 17:02:19
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.
Zitat von: rudolfkoenig am 24 Januar 2017, 17:02:19
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.
- ...
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...
Zitat von: united-networking am 25 Januar 2017, 16:27:47
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.
Zitat von: betateilchen am 24 Januar 2017, 14:41:31
Ü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)....
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.
Zitat von: betateilchen am 25 Januar 2017, 18:39:30
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.
Eben weil ich keinen blassen Schimmer von Datenbanken habe benutze ich kein configDB ;)
Zitat von: betateilchen am 24 Januar 2017, 16:08:42
Ja habe ich. Bis jetzt erschließt sich mir der Sinn noch nicht.
Ist eben genau für Aufgaben wie diese hier. Vielen gleichen devices gleiche Attribute zuzuordnen und das auch bei einer Erweiterung der Installation zu wiederholen. Weiterhin können auch für viele gleiche devices gleiche andere devices angelegt werden (z.B. für jeden Thermo-Hygro-Sensor ein Plot).
Zitat von: betateilchen am 25 Januar 2017, 18:39:30
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?
der User hat nach etwas einfachem gefragt, und das ist configDB nunmal nicht!
Dass Du mich persönlich so anfährst, nur weil ich kein configDB-Fanboy bin ist schon bezeichnend... :D
Und jetzt beweise mal dass ich "
offensichtlich keinen blassen Schimmer" habe oder verbreite nicht solche Fake-News!
Natürlich kenne ich den Notstart-Modus, aber einfacher wie fhem.cfg ist er keineswegs => die User diesbezüglich zu befragen halte ich jedoch für unnötig?!
Zitat von: JoeALLb am 25 Januar 2017, 19:51:50
Und jetzt beweise mal dass ich "offensichtlich keinen blassen Schimmer" habe
Das beweist Du doch regelmäßig selbst.
Bitte solche Diskussionen per PM fuehren.
Zitat von: igami am 25 Januar 2017, 19:01:03
Eben weil ich keinen blassen Schimmer von Datenbanken habe benutze ich kein configDB
Die Nutzung von configDB setzt keinerlei Datenbankkenntnisse voraus.
Genausowenig wie man wissen muss, wie ein Texteditor "funktioniert", um ihn zu benutzen.