99 myUtils anlegen

Begonnen von Beta-User, 14 Mai 2019, 10:58:05

Vorheriges Thema - Nächstes Thema

nils_

Zitat von: Beta-User am 16 Mai 2019, 14:10:07
leider meckert schon die Linux-Konsole rum, dass ich 'ne geblacklistete IP zum Senden nutzen würde, daher kann ich nicht vollst. testen, aber das hier könnte funktionieren:
evtl. weil das getKeyValue fehlt?
my $provider = "myEmailServer"; # like before: {setKeyValue("myEmailServer",'smtp.provider.de:587')}
ändern zu
my $provider = getKeyValue("myEmailServer"); # like before: {setKeyValue("myEmailServer",'smtp.provider.de:587')}


kann man bei getKeyValue() abfragen ob ein Wert überhaupt existiert? undef??
dann kannste noch nen schönen Text ins log packen :)
viele Wege in FHEM es gibt!

Beta-User

#16
Thx.

Magst du den Code dann nach abschließendem Testen bei "Email senden" in's Wiki verfrachten? (Ich nutze wie gesagt sowieso Telegram, mir ging's nur um diese Art, credentials auszulagern, das ist m.E. (bisher) weniger beispielhaft). Dann war mir noch unklar, wieso da einfache Anführungszeichen innerhalb des qx() stehen. Muß das so sein bzw. mir kommt das hinderlich vor....? (bin aber mit den Optionen, Systembefehle aufzurufen auch nicht besonders vertraut).

Der um blocking-Call erweiterten Aufruf an der anderen Stelle finde ich eigentlich auch ganz chick, aber das ist eine "extended version", die m.E. erst dann Sinn macht, wenn man wirklich nicht nur "ein bißchen Text" versenden will. Wäre evtl. sinnvoll, dahin aus dem allg. Email-Versand-Artikel zu verlinken, das dann aber auch dort noch auf den aktuellen Stand zu bringen (sendEmail, credentials ...).

@nils_: Danke für den Hinweis. Das war auf Linux-Konsolenebene (ohne Perl) nicht das Problem...

Man kann den Rückgabewert übrigens prüfen, kein Thema (ist undef, wenn nichts hinterlegt ist). Und das dann z.B. nutzen, ein Dialogfeld anzuzeigen, das den Wert abholt....
So hatte ich einmal die {setKeyValue(...)}-Anweisungen in ein RAW-Feld gepackt, war auch kein Problem.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

betateilchen

Zitat von: Beta-User am 16 Mai 2019, 11:24:14
Was bei configDB empfohlene Vorgehensweisen für diverse Standardfälle sind, ist nach meinem persönlichen Eindruck nicht besonders weit gestreutes Wissen

Es gibt keine "empfohlenen Vorgehensweisem für Standardfälle" und das ist auch gut so. Das Konzept der configDB war und ist, für den Anwender völlig transparent zu funktionieren, ohne dass er sich Gedanken darüber machen muss, was er jetzt anders tun müsste als vorher. Und das ist der Standardfall. Vorausgesetzt, er hält sich an die in der commandref beschriebenen Vorgehensweisen, z.B. die automatische Migration.

Die 99_myUtils.pm Dateien in die Datenbank importieren zu können, wenn man das möchte, ist eines der ganz wenigen Features, die davon eine Ausnahme bilden. Und selbst wenn man das nicht weiß und nicht nutzt, wirkt sich das überhaupt nicht auf die Funktionsfähigkeit von FHEM aus.

Grundsätzlich lehne ich sämtliche Wiki Artikel zur configDB ab, da wird einfach zuviel gefährliches Halbwissen und Vermutungen verbreitet. Beides ist aus den Köpfen der Anwender nicht mehr rauszukriegen, wenn sie es einmal gelesen haben. Deshalb pflege ich als Modulverantwortlicher die commandref. Das ist aus meiner Sicht die einzige verbindliche und wirklich aktuelle Dokumentation zur configDB.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

Otto123

Das mit dem Wiki kann ich machen, aber das wird jetzt sicher nur quick und dirty. Ich bin am packen und dann ein paar Tage weg.
Ob man die ' ' Anführungszeichen braucht, weiß ich nicht. Das stammt nicht von mir :)
Bei sender und rcpt sowie Provider denke ich eigentlich nicht. Wahrscheinlich stammen die einfach aus der normalen Kommandozeile. Ansonsten nimmt man die ' ' an der Stelle typischerweise um splitting und globbing zu verhindern. Also bei subject und text braucht man die höchstwahrscheinlich!? Sonst ist die Kommandozeile gehäckselt.  ;)
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

Otto123

zu den Anführungszeichen um die Variablen:
tatsächlich ist die Kommandozeile von sendEmail sehr tolerant, auch die Strings von Subject und Text müssen nicht "geschlossen" sein. In dem Moment wo aber ein Parameter mit eingestreut wird knallt es.
$text = "Beispieltext aus ein paar Worten" -> funktioniert ohne Fehler
$text = "Enthält der Text aber -a knallt es" -> -a wird erkannt und führt zum Fehler (kein attachment)
Verwendet man statt $text diese Form '$text' funktionieren beide Strings ohne Probleme.
Ich würde jetzt einfach aus Gründen der Einheitlichkeit generell diese Form verwenden -> '$variable'

Andere Meinung?
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

Otto123

Wiki ist geändert https://wiki.fhem.de/wiki/E-Mail_senden#Raspberry_Pi
Ich weiß, das ist jetzt noch nicht schön und denglisch - aber mehr Zeit war jetzt nicht.  ;)
Die Routine ist so kurz und minimalistisch, getestet und funktioniert!
Man kann da noch Fehler behandeln und und und :)

Gute Nacht
Otto
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

DasQ

So, den Thread hab ich jetzt zweimal gelesen.

Sorry wenn ich des jetzt so rotzig sagen muss, aber spätestens nach dem 3. posting steigt der Laie nicht mehr durch, weils so derart pingpong artig wird.

Ich find die Idee hinter dem Thread mal grundsätzlich genial. Und es machen ja auch alle postings in dem Thread super Sinn. Aber in mein augen geht's von 0 auf 100 in drei postings. Also ruhig brauner, kommt alles noch, aber macht's nicht gleich so kompliziert.

Zähl mich selbst noch zu den Ursuppe User. Und wenn meine Hilfe im Augenblick nur sehr marginal ist. Hier könnt ich euch helfen etwas verständlicher und im Zusammenhang, mit Fokus auf Anfänger zu Schreiben.
So als TestDau

... sorry für den OT Text
Fhem on MacMini/Ubuntu.
Absoluter Befürworter der Konsequenten-Kleinschreibung https://de.wikipedia.org/wiki/Kleinschreibung
Infos zu Klimawandel http://www.globalcarbonatlas.org

nils_

meinst du den thread oder den wiki-artikel??

weil hier - im thread -  kann es schonmal etwas durcheinander gehen, dient ja nur als "vorlage" / ideensammlung / brainstorming für den atrikel im wiki.
(jedenfalls ist das meine meinung dazu, und die muss nicht stimmen!)
viele Wege in FHEM es gibt!

DasQ

naja mit "thread" und "postings" mein ich natürlich den thread hier.

bei dem topic bekommt man eben den eindruck, es kommt ne "anleitung"  ;)
ggf is ja schon alles im reinen, wenn man den vermerk [Diskussion]zum topic hinzueditiert
Fhem on MacMini/Ubuntu.
Absoluter Befürworter der Konsequenten-Kleinschreibung https://de.wikipedia.org/wiki/Kleinschreibung
Infos zu Klimawandel http://www.globalcarbonatlas.org

Beta-User

@Otto:
Danke!

Habe das noch von den historischen OS-Versionen gesäubert, und der Aufruf auf OS-Ebene funktioniert nach meinem (aus anderen Gründen erfolglosen) Konsolen Test auch "e"-mäßig in Kleinschreibung, das habe ich in beiden Artikeln dann noch geändert (vermutlich ist das mit dem "E" nur ein Kompabilitätsmodus, der irgendwann wegfällt) und hin- und herverweisende Hinweisboxen reingebastelt.



Zitat von: betateilchen am 16 Mai 2019, 19:21:29
Grundsätzlich [...] Wiki Artikel zur configDB [...].
Das ist ok, der Vorschlag, in _dem_ Artikel was zu configDB zu schreiben kam vom Entwickler ;) . Wenn irgendwas im Artikel "Halbwahrheit sein sollte, bitte melden (am besten mit konkretem Verbesserungsvorschlag).



@DasQ
M.E. darf das Niveau in diesem Thread ruhig zwischen (fast) 0 und 100 (oder mehr) pendeln; am Ende sollte "das Wiki" (oder sagen wir: wenigstens der im Titel genannte Artikel) auf einem Niveau sein, das
- sachlich korrekt und
- schwerpunktmäßig für ambitionierte Perl-Laien (und die, die eine Kurzreferenz brauchen, damit der eigene Code sauber in FHEM integriert wird (=>Header))
die erforderlichen Infos so aufbereitet (oder verlinkt) sind, dass "man" was damit anfangen kann...

Wenn du also konkrete Fragen zum Artikel hast oder Verbesserungsvorschläge: Einfach hier melden ;)

Ansonsten ist es - wie nils_ zutreffend angemerkt hat - eine offene Diskussion über "den richtigen Weg". Das darf gerne später derjenige lesen, der wissen will, "warum" denn bestimmte Dinge "so sind, wie sie (im Artikel im Ergebnis) sind", für alle anderen ist es völlig bedeutungslos.
Zum Verständnis von Artikeln in diesem Board ist evtl. das hier hilfreich: https://forum.fhem.de/index.php/topic,49630.msg413351.html#msg413351
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Otto123

Zitat von: DasQ am 17 Mai 2019, 09:31:52
naja mit "thread" und "postings" mein ich natürlich den thread hier.

bei dem topic bekommt man eben den eindruck, es kommt ne "anleitung"  ;)
ggf is ja schon alles im reinen, wenn man den vermerk [Diskussion]zum topic hinzueditiert
Naja nach meinem Verständnis geht es in diesem Board
FHEM Forum » Allgemeine Informationen » Wiki
immer irgendwie um Themen im Wiki - Wiki Artikel - Gestaltung des Wiki - Inhalte usw.
Im Wiki selbst kann man theoretisch auch über die Wiki Artikel diskutieren, aber das ist sagen wir mal - naja.
Ich bin froh wenn ich das Schreiben der Texte halbwegs verstanden und von einem zum nächsten Mal noch behalten habe.  ;)
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

Otto123

Moin Beta-User,
ZitatDie Zugangsdaten für den Email-Account müssen dabei FHEM-intern gespeichert werden. Geben Sie hierzu einmalig über die Kommandozeile folgendes ein (user@domain und password müssen auf Ihren Account geändert werden):
Wollen wir das förmliche Sie noch "verallgemeinern"?  :D
Vorschlag:
Die Zugangsdaten für den Email-Account müssen dabei FHEM-intern gespeichert werden. Dazu gibt man einmalig über die Kommandozeile folgendes ein (user@domain und password müssen auf den Email Account geändert werden):
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

betateilchen

Zitat von: Beta-User am 17 Mai 2019, 09:37:45
Das ist ok, der Vorschlag, in _dem_ Artikel was zu configDB zu schreiben kam vom Entwickler ;) . Wenn irgendwas im Artikel "Halbwahrheit sein sollte, bitte melden (am besten mit konkretem Verbesserungsvorschlag).

Richtig, der Vorschlag, im Zusammenhang mit der 99_myUtils.pm einen Hinweis bezüglich configDB aufzunehmen, kam von mir.

Aber von holiday- oder gplot-Dateien war von meiner Seite nie die Rede, in diesen Punkten enthält der grüne Kasten falsche Informationen. Diese Dateitypen haben aber auch nichts mit der 99_myUtils.pm zu tun, um die es ja eigentlich geht, insofern sollte man sich in dem grünen Kasten auch bitte auf die 99_myUtils.pm beschränken.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

Beta-User

Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Beta-User

Zitat von: Beta-User am 15 Mai 2019, 13:01:34
Generell noch: Tendenziell würde sich ein Link (mit ein paar erklärenden Worten) aus dem QuickStart gut machen, oder? Wäre dann bei "Komplexe Strukturen" gut unterzubringen. Würde da zwei Unterabschnitte vorschlagen, mit "Mehrere Geräte auf einmal schalten" (heutiger Inhalt) und "Eigene Perl-Routinen zentral zur Verfügung stellen"
Gibt's dazu eine Meinung?

Würde dafür jetzt doch eher einen eigenen Abschnitt (neu 10) vorschlagen, z.B. wie folgt:
Zitat
== Eigene Programme und Module ==
Die Möglichkeiten von FHEM können mit Hilfe eigener Programme (fast) beliebig erweitert werden. Beispielsweise lassen sich wiederkehrende Logiken oder Teilfunktionen mit Hilfe sogenannter [[99 myUtils anlegen‎|myUtils]] aus der Konfiguration auslagern und dann zeit- oder ereignisgesteuert aufrufen. Eine Einführung in die Erstellung ganz eigener Module finden Sie in der [[DevelopmentModuleIntro]].
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files