Hi,
ich habe mir gerade die Frage gestellt, wie man einem Modul Parameter setzen könnte.
Ich meine nicht einem Gerät, welches definiert ist, ich meine tatsächlich das Modul selbst.
Die einzige Idee, welche mir dazu gekommen ist bislang:
Anlegen eines Dummy: Der Name muss vom Modulentwickler fest vorgegeben werden. Der Anwender muss dieses Dummy dann selbst anlegen, wenn er Attribute für das Modul setzen möchte.
Einziges Problem. Ein Dummy kennt erst mal nur eine Vorgefertigte Liste von Attributen.
Alternativ, könnte man eine definitere Instanz des eigentlichen Modules dazu verwenden. Das verwirrt aber vermutlich noch mehr.
Hat da jemand eine Idee, wie so etwas geht? Sollte man dazu eventuell ein eigenes Modul entwickeln, was solche "Geräte" anlegen lässt?
Grüße Sidey
Habe Deinen Text jetzt 3-4 Mal gelesen, aber mir will sich einfach nicht erschließen was Du genau meinst, noch was Du eigentlich damit bezwecken möchtest.
Die Verbindung zwischen FHEM und dem Device macht doch eben ein Modul. Im angelegten Device macht man dann die vom Modulentwickler vorgegebenen Einstellungen für das Device.
Gruß
Dan
Ja, ich habe mich wohl ziemlich kompliziert ausgedrückt.
Es gibt Situationen und das öfters, dass Parameter in einem Modul benötigt werden, noch bevor klar ist, welches definierte Gerät verarbeitet wird.
Bei Logischen Modulen wird dann teilweise ein Parameter aus einem physichen Modul abgefragt. Das macht es aber schwierig, dass dieses Modul nicht mit mehreren unterschiedlichen Physichen Modulen funktioniert.
Es geht also darum, Parameter durch den Anwender definieren zu können, welche noch benötigt werden, bevor von einer Instanz Attribute abgefragt werden können.
Grüße Sidey
Das Problem ist mir bekannt, und es gibt dafuer bisher keine saubere Loesung.
Auf Kommandozeile was einzufuehren sollte einfach genug sein, im Frontend ist das noch eine ungeloeste Baustelle.
Hi Rudi,
Danke für die Antwort.
Hat das mit der Kommandozeile schon mal jemand gemacht?
Ich kann mir gerade nicht vorstellen, wo ein Wert gespeichert werden könnte.
In einem in fhem.pl neu anzulegende Datenstruktur.
Ah, das müsste also noch gemacht werden.
In etwa so:
$defaultParams{Modulname}{Attribut} = 'Wert';
Für das Abrufen und Setzen könnte man ja zwei Funktionen zur Verfügung stellen.
Soll ich da mal einen kleinen Patch erstellen?
Ich muss noch drueber nachdenken, und in den naechsten 2 Wochen habe ich dafuer keine Zeit.
Bitte um etwas Geduld. Ich haette auch gerne die Meinung von anderen noch dazu.
geht es wirklich darum parameter schon vor/im define zu setzen oder parameter für alle devices eines typs auf ein mal zu setzen?
ersteres geht in dem man die parameter im define mit gibt, letzteres in dem man devspec beim setzen verwendet.
die zweite frage wäre ob es primär für entwickler oder anwender sein soll.
gerade bei letzterem muss man zuerst das genaue verhalten klären. haben die globalen parameter/attribute vorrang vor den device spezifischen oder umgekehrt? immer? kann der anwender die priorität umdrehen? wie stellt man das im frontend dar? auch bei list über telnet.
was gewinnen wir gegenüber der beiden ganz oben beschrieben möglichkeiten?
je nach anwendung ist es vielleicht auch eine option das doch modulspezifisch mit einem extra parameter device zu lösen. das würde ohne weitere interne änderungen an fhem gehen.
vielleicht sollten wir zuerst die ganz konkreten anwendungsfällw sammeln bevor wir drüber nachdenken ob und wie man das zentral lösen kann. es gab ja schon mindestens zwei threads in dieser richtung.
falls sich etwas an den attributen tut wäre es zu überlegen ob man sie in fhemweb im drop down nicht auch sinnvoll
nach system weiten und modul spezifischen gruppiert.
Also Anwendungsfall 1:
In einem Logischen Modul werden zwei Wetterstationen unterstützt. Autocreate legt diese auch automatisch an.
Beide verwenden das identische Übertragungsverfahren und lassen sich nicht auseinander halten.
Es gibt allerdings einen Unterschied in der CRC Berechnung. Für eine der Stationen ist die Berechnung bekannt, für die andere nicht.
Wie übergibt man nun einen Schalter, ob CRC berücksichtigt werden soll, oder nicht?
Anwendungsfall 2:
In einem Logischen Modul soll man Wetter Sensoren entweder über die Zufalls ID + Kanal definieren oder nur über den Kanal.
Die Zufalls ID bekommt man nur per Autocreate. Wie kann man aber das Autocreate beeinflussen, dass der Anwender bestimmen kann, welche Variante er für das Define verwenden möchte?
ich glaube ich verstehe bei beiden fällen nicht warum es hilft irgendetwas vorher zu setzen.
entweder das physikalische modul kann den unterschied automatisch herausfinden, dann wird autocreate passend getriggert oder es lässt sich nicht automatisch herausfinden oder es geht nicht automatisch, dann muss der anwender eingreifen. wenn es global für seine komplette installation gilt würde er den parameter im physikalischen modul setzen, wenn es device spezifisch ist würde er es nach dem autocreate im device setzen.
oder vielleicht noch besser: das physikalische modul legt die devices bei denen es nicht sicher ist nicht automatisch per autocreate an sondern erzeugt nur eine liste der gefundenen devices die der anwender sich ansehen und dann per kommando das autocreate mir der passenden option anstossen kann.
was meinst du mit zufalls id? warum kommt die per autocreate?
Hallo,
Zitat von: Sidey am 02 September 2016, 22:00:20
Also Anwendungsfall 1:
Anwendungsfall 2:
sind das hypothetische Anwendungsfälle oder sind Dir Geräte bekannt, bei denen das relevant ist?
Viele Grüße
Boris
Beide Anwendungsfälle existieren.
Andere Faelle:
- update, backup, sunrise
- Passwort/etc fuer alle Fhemweb Instanzen gleich setzen
update, backup
die sind etwas anders gelagert da es sich nicht um devices handelt sondern um kommandos. hier gibt es tatsächlich aktuell keinen eleganten weg defaults zu setzen. wenn nicht alles nach global soll würde sich je ein device anbieten.
gerade bei backup könnte man so auch unterschiedliche backup konfigurationen/ziele haben und die events würden vom backup kommen statt von global.
sunrise
auch etwas anders gelagert da perl routinen.
aber das würde vermutlich auch mit einem/mehereren devices sehr gut gehen. man hätte unterschiedliche konfigurationen, könnte im device direkt die werte sehen (ohne sie per at in dummys zu kopieren) und hätte auch gleich events. statt at könnte man dann notify verwenden und hätte auch das auslösen der neuberechnung und das +24 stunden problem im at nicht mehr. die manchmal auftretenden sommer/winterzeit probleme sind event basiert vielleicht auch besser zu lösen.
Passwort/etc fuer alle Fhemweb Instanzen gleich setzen
genau das geht doch mit devspec und hat den vorteil das es keine vorrang probleme gibt und man sich jederzeit umentscheiden kann.
ein weiteres beispiel wäre auch das mit den allowed devices. das ist ja auch entstanden weil es keine bessere möglichkeit für n:m beziehungen gab.
aus den alten diskussionen fällt mir noch ein das es auch mal darum ging attribute für räume oder gruppen und ähnliches zu haben.
damit wären es drei unterschiedliche dinge
- modul typ spezifische parameter(, eventuell setzbar bevor es das erste device gibt?)
- n:m zuordnung von devices und konfigurationen
- attribute/parameter für 'virtuelle' dinge wie räume oder gruppen
ist es sinnvoll das alles unter einen hut zu bringen? mit dem normalen attribut mechanismus? einer erweiterten version? oder etwas ganz neuem?
Zitat von: Sidey am 02 September 2016, 09:05:38
Es geht also darum, Parameter durch den Anwender definieren zu können, welche noch benötigt werden, bevor von einer Instanz Attribute abgefragt werden können.
Das ist doch der Zeitpunkt, zu dem das DEFINE ausgeführt wird?
Darüberhinaus halte ich nach wie vor nichts von vordefinierten Attributen. Getreu dem Motto "Attribute gehören dem Benutzer, nicht dem Entwickler."
Zitat von: Sidey am 02 September 2016, 10:33:04
Hat das mit der Kommandozeile schon mal jemand gemacht?
Naja, sowas ähnliches. Wer mit configDB arbeitet, kann bestimmte Verhalten der Konfigurationsdatenbank beim fhem-Start beeinflussen. So kann man beispielsweise definieren, ob fhem in einem "rescue-Modus" gestartet wird, wenn man sich mal verbastelt hat oder beispielsweise auch, ob fhem zwar mit der gespeicherten Konfiguration, aber ohne Ausführung des statefile gestartet werden soll.
Zugegeben - das ist ein Spezialfall, da ja keine devices von dem Modul abgeleitet/erzeugt werden.
(Die configDB hat aber auch noch eigene Attribute, die der Anwender setzen kann. wenn er das möchte)
Zitat von: justme1968 am 02 September 2016, 23:03:59
entweder das physikalische modul kann den unterschied automatisch herausfinden, dann wird autocreate passend getriggert oder es lässt sich nicht automatisch herausfinden oder es geht nicht automatisch, dann muss der anwender eingreifen. wenn es global für seine komplette installation gilt würde er den parameter im physikalischen modul setzen, wenn es device spezifisch ist würde er es nach dem autocreate im device setzen.
Das physische Modul löst das autocreate nicht für das logische Modul auf. Das Physische Modul übergibt Daten via Dispatch. Diese werden an ein Logisches Modul in der parse Funktion übergeben. Solange das Gerät nicht angelegt und definiert ist, besteht derzeit keine Möglichkeit für den Anwender das Verhalten in der parse Funktion zu beeinflussen.
Zitat von: justme1968 am 02 September 2016, 23:03:59
oder vielleicht noch besser: das physikalische modul legt die devices bei denen es nicht sicher ist nicht automatisch per autocreate an sondern erzeugt nur eine liste der gefundenen devices die der anwender sich ansehen und dann per kommando das autocreate mir der passenden option anstossen kann.
Ja, so etwas klingt prinzipiell machbar. Nur dass auch hier eher das logische Gerät all das macht.
Der Anwender könnte die Daten also nur sehen, wenn sich das logische Gerät erst mal selbst ein Gerät anlegt in dem es dem Anwender ermöglicht etwas zu tun.
Das könnte prinzipiell funktionieren. Bedarf aber einiger grundlegender Anpassungen.
Zitat von: justme1968 am 02 September 2016, 23:03:59
was meinst du mit zufalls id? warum kommt die per autocreate?
Viele Funkgeräte erzeugen beim Batterie Einlegen eine Zufalls ID. Als Anwender kennst Du diese erst mal nicht.
Die Hersteller sehen hier entweder eine Pairing Funktion zwischen Sender um Empfänger vor (selten) oder bieten dem Anwender einen Kanal Schalter.
Folgenden Fall als Beispiel: Der Sensor erzeugt eine Zufalls ID und bietet dem Anwender drei Kanäle zur Auswahl. Der Anwender hat aber 5 Sensoren und möchte diese auch verwenden. Er kann seine Geräte also nur unter Zuhilfenahme der Zufalls ID auseinander halten (FHEM übrigens auch). Also muss er sich die Sensoren via autocreate mit der ZufallsID anlegen lassen. Die ändert sich leider bei jedem Batteriewechsel.
Folgenden 2. Fall als Beispiel: Der Sensor erzeugt eine Zufalls ID und bietet dem Anwender drei Kanäle zur Auswahl. Der Anwender hat 2 Sensoren und möchte diese auch verwenden. Er möchte nicht bei jedem Batteriewechsel seine Gerätedefinition anpassen, also sollen die Sensoren nur mit der Kanal Nummer angelegt werden. Er könnte sich die Sensoren in diesem Fall manuell anlegen, allerdings muss der Parse Funktion noch mitgeteilt werden, dass der Anwender nur mit der Kanalnummer arbeiten möchte. Wo kann der Anwender diese Information mitgeben?
Zitat von: betateilchen am 04 September 2016, 16:55:28
Das ist doch der Zeitpunkt, zu dem das DEFINE ausgeführt wird?
Nein, wenn ich die Verhaltensweise des Modules beeinflussen möchte, noch bevor ein Gerät definiert werden konnte oder noch bevor klar ist, um welche Device es konkret geht ist das nicht so.
Zitat von: betateilchen am 04 September 2016, 16:55:28
Darüberhinaus halte ich nach wie vor nichts von vordefinierten Attributen. Getreu dem Motto "Attribute gehören dem Benutzer, nicht dem Entwickler."
Sehe ich auch so, letztendlich sind alle Attribute aber mit einem Standardwert durch den Entwickler vorbelegt.
Der Anwender sollte aber die Freiheit haben, das Verhalten leicht zu verändern. Änderungen am Quellcode von Modulen scheidet also aus.
Zitat von: betateilchen am 04 September 2016, 16:55:28
(Die configDB hat aber auch noch eigene Attribute, die der Anwender setzen kann. wenn er das möchte)
Ich habe mich mit der ConfigDB noch nicht beschäftigt. Vielleicht sollte ich das mal machen. Wie kann der Anwender denn seine eigenen Attribute setzen und zu welchem Gerät gehören die dann?
Grüße Sidey
Zitat von: Sidey am 05 September 2016, 22:34:39
Nein, wenn ich die Verhaltensweise des Modules beeinflussen möchte, noch bevor ein Gerät definiert werden konnte oder noch bevor klar ist, um welche Device es konkret geht ist das nicht so.
Das xxx_initialize wird beim allerersten Define (genauer: beim Laden des Moduls im Rahmen des ersten Define) aufgerufen. Das xxx_define wird danach ausgeführt, auch zu diesem Zeitpunkt ist noch kein device festgelegt. Ich verstehe das Problem immer noch nicht.
Und Deine Aussage, jedes Attribut sei vom Entwickler mit einem Wert vorbelegt, stimmt definitiv nicht.
Zitat von: betateilchen am 05 September 2016, 22:59:40
Das xxx_initialize wird beim allerersten Define (genauer: beim Laden des Moduls im Rahmen des ersten Define) aufgerufen. Das xxx_define wird danach ausgeführt, auch zu diesem Zeitpunkt ist noch kein device festgelegt. Ich verstehe das Problem immer noch nicht.
Problem ist, dass der Anwender keine Parameter übergeben kann, welche das Verhalten vor dem Define eines Gerätes beeinflussen.
Zumindest habe ich noch keine Möglichkeit gefunden. Hätte man die Möglichkeit, könnte man die wohl in xxx_initialize auswerten.
Zitat von: betateilchen am 05 September 2016, 22:59:40
Und Deine Aussage, jedes Attribut sei vom Entwickler mit einem Wert vorbelegt, stimmt definitiv nicht.
Okay, ich stimme dir zu, nur jedes verwendete Attribut hat üblicherweise einen Standardwert, den der Entwickler bestimmt.
Ich habe die Diskussion noch mal sacken lassen.
Was wäre, wenn man ein Device vom entsprechenden Modul anlegt und es über das Define als "Konfigurations" Device markiert.
Grüße Sidey?
Das steht jedem Modulentwickler frei, und braucht keine Framework-Unterstuetzung.
Bin nicht sicher, wie gut das bei den Anwendern ankommt, vlt. sollte man das einfach ausprobieren.
Ja, das macht es mal wieder kompliziert, das sehe ich auch so, ich probiere das mal aus.