Parameter für ein Modul setzen

[Sidey]

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

[DeeSPe]

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

[Sidey]

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

[rudolfkoenig]

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.

[Sidey]

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.

[rudolfkoenig]

In einem in fhem.pl neu anzulegende Datenstruktur.

[Sidey]

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?

[rudolfkoenig]

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.

[justme1968]

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.

[Sidey]

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?

[justme1968]

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?

[Dr. Boris Neubert]

Hallo,

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

[Sidey]

Beide Anwendungsfälle existieren.

[rudolfkoenig]

Andere Faelle:
- update, backup, sunrise
- Passwort/etc fuer alle Fhemweb Instanzen gleich setzen

[justme1968]

Code Auswählen Erweitern

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.

Code Auswählen Erweitern

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.

Code Auswählen Erweitern

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?