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:
define mydb InfluxDBLog $database $user $password ...
Und wie kann ich diese Variablen (in einer conf-datei oder sonstwo "sicher") definieren?
Dank Euch,
Wolfram
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.
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...
define mydb InfluxDBLog {$database $user $password} ...
Ich bin fast sicher, dass das irgendwie realisierbar ist...
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 :)
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.
Also geht es doch um das Modul. Die Umsetzung erfolgt im Modul
Nein, es geht definitiv NICHT um das Modul...
DEFINE myname modul $VARIABLE1 $VARIABLE2
ist meine Fragestellung...
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?
Zitat von: wopl am 13 Juli 2020, 09:22:19
Nein, es geht definitiv NICHT um das Modul...
DEFINE myname modul $VARIABLE1 $VARIABLE2
ist meine Fragestellung...
{fhem("DEFINE myname modul $VARIABLE1 $VARIABLE2")}
Puh, das scheint schwierig...
Also ich befinde mich in der FHEM cfg, in der sich viele DEFINEs befinden:
DEFINE ...
DEFINE myname modul abc def xxx
DEFINE myname2 modul abc def yyy
DEFINE ...
das tut's natürlich.
Jetzt möchte ich aber:
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
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...
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
$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.
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.
Zitat2020.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
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).
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.
@marvin78:
ZitatEin paar Variablen in ein define zu werfen, ist keine Frage.
Dann helf mir doch mal bitte auf die Sprünge; ich weiß nämlich nicht, wie es geht.
@Damian:
An welcher Stelle kann ich denn (wie) die Variablen definieren?
schaust Du auch bitte mal auf mein $ENV Konstrukt? Kann das in ähnlicher Weise laufen?
Und das {fhem... } Konstrukt kann ich zwischen die anderen "defines" in meiner cfg setzen?
Dank Wolfram
wäre es mein Problem , würde ich ne neue sub in der 99_myUtils anlegen und dort via fhem("defmod alle in Frage kommenden Geräte glattziehen
Dann noch ein notify das auf global init done triggert und die neue Sub mit User,PW aufruft.
Bei User/PW Änderungen musst dann nur das notify anpassen.
Variable Definitionen in FHEM sind meines Wissens in FHEM direkt nicht vorgesehen. Da wirst du, wie Wzut schon vorgeschlagen hat, etwas selbst "programmieren" müssen.
Und dann kommt hinzu, dass wenige Module (zumindest der von mir verwendeten) User/PW im define haben (wo es [wurde ja schon angemerkt] eigentl. nicht hingehört)...
Davon "wandeln" einige Module um, entfernen es aus dem define und speichern es "irgendwo"...
Dann gibt es Module, da hast du ein Attribut für Username und einen set-Befehl für Passwort...
Und dann gibt es Module...
Ich will damit nur sagen: da müsstest du ja für jedes Modul extra was haben/schreiben...
Solange das jedes Modul macht wie es will, wird es schwer mit EINEM Ansatz...
Gruß, Joachim
Im Grunde gibt es diesen Ansatz für die Modulentwickler schon (siehe oben). Leider wird er (in der Regel von entweder hingeklöppelten oder auch älteren Modulen) nicht immer verwendet.
Aber das bestägigt meine Grundaussage: Das Problem liegt im jeweiligen Modul (was nicht heißen soll, dass man die zentrale API nicht verbessern könnte).
Hallo allerseits,
so ich hab meine initiale Frage komplett gelöst bekommen.
- Verwendung von Variablen in einem define
- Verwendung von Environment-Variablen zur Absicherung von Credentials
Meine Lösung sieht jetzt so aus:
DEFINE ...
{ \
my $var1 = "$ENV{'envvar1'}";; \
my $var2 = "$ENV{'envvar2'}";; \
fhem ("define myname modul $var1 $var2 xxx";; \
fhem ("define myname2 modul $var1 $var2 yyy";; \
}
DEFINE ...
Das war alles, was ich brauchte. Immer schwierig, wenn man nicht weiß, wie es geht. Nachher ist's ganz simpel. Dank Euch.
Gruß Wolfram
Hallo Wolfram,
was Du als Lösung ansiehst, sehen wahrscheinlich einige als Problem :)
Meine Meinung, drei Tipps und eine Anmerkung:
1. lass die Finger von der cfg.
2. lass die Finger von der cfg.
3. lass die Finger von der cfg.
Anmerkung
Dein Code, den Du so offenbar in die cfg gepackt hast, erzeugt beim Start "Geräte" in Deiner Konfig und damit eine (nicht gespeicherte) Konfigänderung.
In den Geräten steht im Klartext dein Credential drin, was daran abgesichert sein soll?
Da beim Neustart (nach Speichern) dein Code wieder ausgeführt wird, die Geräte aber schon da sind, läufst Du bei jedem Start in Fehler.
Dein Code würde sich (wie vorgeschlagen ) als Würgaround in 99_myUtils (mit defmod) zur Wartung von Definitionen eignen.
Ein Betrieb eines Systems in diesem Modus (wie er nicht angedacht ist) ist möglich, aber Du solltest bei jeder zukünftigen Frage diesen Thread verlinken ;)
Gruß Otto
Hallo Otto,
Dank für Deine Anmerkungen.
Bei mir gibt es nicht eine CFG sondern etwa 20 (mit includes miteinander verbunden). Die laufen seit 8 Jahren mit vielen Veränderungen sehr gut. Insbesondere kann ich alles scriptgesteuert laufen lassen. Die Diskussion kann ich bei meiner recht großen und sehr komplexen Installation gerne führen.
Die Credentials dürfen in den Geräten stehen, das ist kein Problem. Wichtig ist mir, dass die Credentials nicht in GitHub landen. Das ist mit der von mir geschriebenen Lösung so sichergestellt.
Defmod ist mir bekannt und wird verwendet.
Und warum ist eine Konfiguration der CFGs nun schlechter als eine nichtnachvollziehbare Klick-Orgie?
Ich hab die CFGs von Hand angelegt und noch nicht einmal zerschossen... auch wenn ich zwischenzeitlich hunderte Änderungen vorgenommen habe.
Das schöne ist ja, dass FHEM viele Möglichkeiten bietet. Jeder darf und kann so, wie er will :=)
Gruß Wolfram
Zitat von: wopl am 13 Juli 2020, 15:28:21
Das schöne ist ja, dass FHEM viele Möglichkeiten bietet. Jeder darf und kann so, wie er will :=)
Korrekt. Das ist super. ABER: Ob der, der es macht, wie nicht empfohlen, auch Support bekommt, steht dann auf einem anderen Blatt.
Na dann lass mich noch wissen, wo steht, dass ich es nicht so machen soll...Ich kann mich über meine Logfiles, Verhalten bei Änderungen, Ausfallsicherheit und anderen Kriterien nun wirklich nicht beschweren. Komische Diskussion hier...
Naja. Dann ist das gut für dich. Ich jedenfalls helfe nicht, wenn jemand Probleme mit meinem Modulen bekommt, wenn er die Config editiert. Das ist mir zu anstrengend, weil der Fehler dann nicht selten schwer zu finden ist (während es bei Bedienung über Frontend klare Meldungen gibt). Ähnlich halten es einige. Und Sinn ergibt es tatsächlich auch nicht. Und die Diskussion ist nicht komisch. Sie hilft ggf. dem ein oder anderen, sich zu orientieren.