Parameter für ein Modul setzen

Begonnen von Sidey, 02 September 2016, 00:32:58

Vorheriges Thema - Nächstes Thema

betateilchen

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)
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

Sidey

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?

Signalduino, Homematic, Raspberry Pi, Mysensors, MQTT, Alexa, Docker, AlexaFhem

Maintainer von: SIGNALduino, fhem-docker, alexa-fhem-docker, fhempy-docker

Sidey

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
Signalduino, Homematic, Raspberry Pi, Mysensors, MQTT, Alexa, Docker, AlexaFhem

Maintainer von: SIGNALduino, fhem-docker, alexa-fhem-docker, fhempy-docker

betateilchen

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.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

Sidey

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.
Signalduino, Homematic, Raspberry Pi, Mysensors, MQTT, Alexa, Docker, AlexaFhem

Maintainer von: SIGNALduino, fhem-docker, alexa-fhem-docker, fhempy-docker

Sidey

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?
Signalduino, Homematic, Raspberry Pi, Mysensors, MQTT, Alexa, Docker, AlexaFhem

Maintainer von: SIGNALduino, fhem-docker, alexa-fhem-docker, fhempy-docker

rudolfkoenig

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.

Sidey

Ja, das macht es mal wieder kompliziert, das sehe ich auch so, ich probiere das mal aus.
Signalduino, Homematic, Raspberry Pi, Mysensors, MQTT, Alexa, Docker, AlexaFhem

Maintainer von: SIGNALduino, fhem-docker, alexa-fhem-docker, fhempy-docker