Variablen (z.B. Passwort) in define

[wopl]

Hallo allerseits,
obwohl schon seit vielen Jahren dabei und einer Installation mit über 300 items, muß ich jetzt noch mal in die Anfängergruppe:

In einem define (konkret das Modul InfluxDBLog) muß ich UserID und Passwort übergeben. Ich habe "viele" dieser Aufrufe.

- natürlich möchte ich die Werte nur einmal definieren und dann als Variablen verwenden
- weiterhin dürfen diese Werte natürlich nicht im GIT (ja, ich verwalte meine FHEM Definitionen im privaten GIT) sichtbar sein... also möglichst aus einer conf o.ä. Datei ausgelesen werden.

Konkrete Fragen also: Wie sieht die Verwendung von Variablen in einem define aus? Also so in etwa:

Code Auswählen Erweitern

define mydb InfluxDBLog $database $user $password ...

Und wie kann ich diese Variablen (in einer conf-datei oder sonstwo "sicher") definieren?

Dank Euch,
Wolfram

[Wzut]

direkt beim define wird es nicht gehen, aber intern aus einer Datei lesen :
a. Modul selbst umschreiben
b. den Autor des Moduls anschreiben und ihn um so eine Erweiterung bitten.

[wopl]

Hmmm, so ganz will ich mich mit der Antwort nicht zufrieden geben...

Da gibts doch die Möglichkeit zwischen Perl und FHEM Syntax zu wechseln...
Irgendwie mit geschweiften Klammern...

Code Auswählen Erweitern

define mydb InfluxDBLog {$database $user $password} ...

Ich bin fast sicher, dass das irgendwie realisierbar ist...

[Wzut]

Ich kenne das Modul direkt nicht , aber im Normalfall klappt das so bei einem Modul nicht.
Der Autor hat sich wohl dünn gemacht aber schreib doch mal Peter (plin) oder Heiko (DS_Starter) an, die haben doch beide schon an dem Ding geschraubt und vllt klebt einer der beiden dem kranken Ochsen ein Pflaster auf, Fragen kostet i.d.R. nichts

[wopl]

Nein, mir geht es nicht um das Modul... es geht um die Einbindung von Variablen in ein DEFINE statement... eine ähnliche Fragestellung taucht bei mir in vielen Modulen auf.

[marvin78]

Also geht es doch um das Modul. Die Umsetzung erfolgt im Modul

[wopl]

Nein, es geht definitiv NICHT um das Modul...

DEFINE myname modul $VARIABLE1 $VARIABLE2

ist meine Fragestellung...

[marvin78]

Wo ist die Frage?

Es geht jeweils um das spezielle Modul, da diese Funktionalität im Modul umgesetzt werden muss. Ich sehe den Punkt, an dem das so schwer zu verstehen ist, nicht.

Zudem: Wie willst du, bei diesem Define, die Variablen denn bekannt machen und ihren Inhalt setzen?

[Damian]

Nein, es geht definitiv NICHT um das Modul...

DEFINE myname modul $VARIABLE1 $VARIABLE2

ist meine Fragestellung...

{fhem("DEFINE myname modul $VARIABLE1 $VARIABLE2")}

[wopl]

Puh, das scheint schwierig...

Also ich befinde mich in der FHEM cfg, in der sich viele DEFINEs befinden:

Code Auswählen Erweitern


DEFINE ...
DEFINE myname modul abc def xxx
DEFINE myname2 modul abc def yyy
DEFINE ...


das tut's natürlich.

Jetzt möchte ich aber:

Code Auswählen Erweitern


DEFINE ...
DEFINE myname modul $VAR1 $VAR2 xxx
DEFINE myname2 modul $VAR1 $VAR2 yyy
DEFINE ...


@Damian: warum muß ich hierfür {fhem("...")} drumrumbauen? Ich befinde mich ja bereits im FHEM und nicht in Perl ... Und 2te Frage: Wie kann ich $VAR definieren in meiner cfg Datei?

Würde eigentlich

Code Auswählen Erweitern


DEFINE myname modul {$ENV{'VAR1'}} {$ENV{'VAR2'}}

in ähnlicher Weise funktionieren? Die verschachtelten Klammern müssten sicher noch escaped werden, wenn's überhaupüt geht

Dank und Gruß,
Wolfram
Hoffe, wir schaffen das noch...

[carlos]

Dise Frage habe ich mir auch schon gestellt.
Warum gibt es da eigentlich keinen generellen Ansatz von FHEM. So muss das immer von jedem modul Entwickler selbst gelöst weden.
Das wäre doch direkt in FHEM besser gelöst.

Oder gibt es da sogar schon was?

Gruß

Carlos

[marvin78]

$VAR kann nur in Perl definiert werden (oder im Modul - dann natürlich auch Perl). Deshalb erschließt sich mir der Sinn nicht.

Es ist nicht zu vergleichen mit einem bspw. notify, in dem bspw. $NAME, $EVTPART ... fest vordefiniert sind (auch im Modul).


Ggf. fehlt hier noch das Verständnis über die Grundlegende Struktur von fhem und das Define.

[wopl]

Naja, ggf. fehlt hier noch das Verständnis für meine Fragestellung... (ich habs jetzt drei mal versucht zu beschreiben).
Liegt wohl an mir... Trotzdem ist die Frage noch offen.

Nunja, auch mag mir ein grundlegendes Verständnis von FHEM fehlen... Aber ich betreibe seit Jahren eine recht große Installation... inkl. eigener geschriebener Module... so schlecht kann mein Verständnis dann auch nicht sein.

2020.07.12 16:10:32 0: Server started with 333 defined entities (fhem.pl:22342/2020-07-04 perl:5.020002 os:linux user:root pid:8051)

Und bitte: Der Thread artet gerade in eine Diskussion aus, die nicht notwendig ist. Wäre schön, wenn sich die beteiligen, die eine Idee haben und nicht alle, die keine Idee haben. Das macht den Thread dann auch übersichtlicher.

Dank und Gruß,
Wolfram

[marvin78]

Es liegt ggf. auch daran, dass du keine konkrete Frage gestellt hast. Ein paar Variablen in ein define zu werfen, ist keine Frage.

Zu User-ID und Passwort im Allgemeinen: Diese Daten (insbesondere das Passwort) gehören nicht in ein Define. Für das Speichern dieser Daten stellt die FHEM-API dem Modulautor gewisse Funktionen zur Verfügung (siehe Wiki für Developer). Also sind wir wieder beim Modul. Dort muss einiges geändert werden, um die Lösung gut zu machen.

Das Problem, dass diese Daten nicht sichtbar sein sollen, bekommst du nicht durch bloße Verwendung von Variablen gelöst).

[Damian]

Es ist ganz einfach: FHEM-Ebene ist eine selbst programmierte Umgebung, die nicht den Anspruch einer höheren Programmiersprache haben kann. Das gilt insb. für Variablen, Schleifen etc.

Da FHEM aber mit {...} eine Schnittstelle zu Perl bietet, kannst du dort Elemente von Perl anwenden. Zu bedenken ist natürlich, dass man nicht überall auf alle Variablen zugreifen kann (lokale Variablen, globale Variablen, Instanz-Variablen, packageabhängige Variablen etc.)

Elemente wie $NAME, $EVTPART etc. sind keine echten Variablen, sondern vielmehr Platzhalter innerhalb eines bestimmten Moduls namens notify.

Auf der FHEM-Ebene kann man Readings eines Moduls (z. B. eines Dummys) als Variablen ansehen. Die kann man mit Werten füllen und auch wieder auslesen und sie überleben, im Gegensatz zu Variablen, in der Regel den System-Neustart.