Variablen (z.B. Passwort) in define

[wopl]

@marvin78:

Ein 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

[Wzut]

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.

[Damian]

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.

[MadMax-FHEM]

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

[marvin78]

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).

[wopl]

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:

Code Auswählen Erweitern


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

[Otto123]

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

[wopl]

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

[marvin78]

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.

[wopl]

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...

[marvin78]

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.