99 myUtils anlegen

[Beta-User]

Hallo zusammen,

neulich hatten wir einen Thread "Perl für Anfänger". In den Zusammenhang greife ich mal das hier auf:

Die Schnittstelle zwischen FHEM und "normalem Perl" bzw. die Doku dazu sollte man sich ggf. mal ansehen. Soweit ich das im Kopf habe, firmiert das unter den Stichworten "myUtils anlegen" im Wiki und den Perl specials der commandref.

Den Artikel https://wiki.fhem.de/wiki/99_myUtils_anlegen habe ich mal durchgesehen, und wollte mal folgende Dinge zur Diskussion stellen, bevor ich ggf. an diesen doch zentralen Artikel "Hand anlege"...

- Einleitung: "eine eigene Programmdatei zu erzeugen"
Finde ich etwas unglücklich formuliert; ich nutze effektiv mehrere. Die sind jeweils thematisch gruppiert, z.B. gibt es was, was HomeMatic-spezifischen Code beinhaltet (z.B. devStateIcon-Code für CUL_HM-Thermostat-Geräte usw.). Splittet man das so auf, kann man leichter kompletten Code austauschen, ich finde es auch übersichtlicher und einfacher zum Testen, wenn man mind. eine zweite für "Experimente" hernimmt.
Vorschlag:

Die Speicherung von Perl-Code unmittelbar in Eventhandlern, Timehandlern oder anderen Geräten in der [[Konfiguration]], in denen Perl-Ausdrücke angegeben werden können, wird mit wachsender Zahl von Geräten und Logiken schnell unübersichtlich. Eine Möglichkeit, dies übersichtlicher zu gestalten und z.B. Doppelungen zu vermeiden, besteht darin, eine oder mehrere eigene Programmdateien zu erzeugen, in der mehrere kleine Programme gesammelt und dann aus entsprechenden Geräten aufgerufen werden können.

- "Eigene Routinen anlegen"
Das gewählte Beispiel ist m.E. aus mehreren Gründen nicht mehr optimal: FS20 ist outdated, Einsteiger werden sich also kaum mehr dafür interessieren, und der code ist zudem ausweislich der verlinkten Wikiseite seit Jahren in 99_Utils enthalten
Vorschlag wäre hier eine andere (allgemeinere) Funktion, konkret: ein Gerät nach einer bestimmten Zeit wieder auszuschalten - dort wo es mit on-for-timer nicht gelöst werden kann, nämlich beim Einschalten durch einen Schalter direkt am Gerät. Dazu werde ich aber in dem Perl-Lernen-Thread mal einen Test machen, inwieweit das ankommt.

- Generell: sollten da nicht ein paar Fußnoten aufgenommen werden, um weiterführende Hinweise und links unterzubringen?
Beispiele:
-- Prototypes: Zum einen auf die entsprechenden Seiten bei Perldoc, zum anderen auf die Prototype-Liste in fhem.pl (samt link zu diesem Artikel); da bekommt der geneigte Leser auch gleich präsentiert, was er ggf. verwenden kann .
-- Perl-Specials der cref verlinken?
-- wie/warum ggf. auf mehrer Dateien aufteilen

- Links:
Ein paar mehr Beispiele wären doch nett, z.B. von Benni: "globale Fenster-offen..."; aus diesem Beispiel habe ich persönlich einiges an "aha's" gezogen, gibt sicher noch mehrere.

Wäre nett, wenn hierzu etwas feedback käme, für mich alleine finde ich das schwer einzuschätzen.

Gruß, Beta-User

[ph1959de]

- Einleitung: "eine eigene Programmdatei zu erzeugen"
Finde ich etwas unglücklich formuliert; ich nutze effektiv mehrere.

Zustimmung; dabei bitte dann auch gleich das generelle an 99_myXXX darstellen

- "Eigene Routinen anlegen"
...Vorschlag wäre hier eine andere (allgemeinere) Funktion, konkret: ein Gerät nach einer bestimmten Zeit wieder auszuschalten - dort wo es mit on-for-timer nicht gelöst werden kann, nämlich beim Einschalten durch einen Schalter direkt am Gerät. Dazu werde ich aber in dem Perl-Lernen-Thread mal einen Test machen, inwieweit das ankommt.

Zustimmung.

- Generell: sollten da nicht ein paar Fußnoten aufgenommen werden, um weiterführende Hinweise und links unterzubringen?

Ich bin nicht so der Fan von Fußnoten in Wiki-Seiten; lieber Intra-Wiki Links sinnvoll in den Fließtext einarbeiten. Das signalisiert in meinen Augen recht deutlich: "Hier gibt es zusätzliche Infos zu einem Thema / Begriff ... und wer das schon kennt, liest einfach drüber weg"

Ein paar mehr Beispiele wären doch nett

Ich denke, vollständige, korrekte Beispiele mit einer Erläuterung, was sie machen, sind immer (auch ohne großen "Genehmigungsprozess") möglich. Es sollte aber auch nicht x-mal der gleiche Themenbereich damit durchgekaut werden.

Peter

[krikan]

Mach ruhig.

Die Seite ist -wie einige Seiten im Wiki- nie "generalüberholt", sondern immer wieder knapp an aktuelle Neuerungen angepasst worden. Das liest sich irgendwann nicht mehr flüssig/vernünftig.

Zu Fußnoten teile ich Peters Meinung.

Nebenbei zu Verlinkungen/Wiederholungen:
Mir ist das Thema commandref-Ergänzung in https://wiki.fhem.de/wiki/99_myUtils_anlegen#Eigene_Programmdatei_dokumentieren schon viel zu ausführlich und wiederholend. Im Wiki ist das an anderer Stelle (ja, im Developer-Bereich) bereits erklärt und das Verteilen an x Stellen macht die Wiki-Pflege nicht einfacher und das Wiki nicht besser. Darum ist mir eine Verlinkung oftmals lieber als die xte Erklärung bzw. Erklärungsversuch.

Gruß, Christian

[Beta-User]

Danke für die schnelle und positive Rückmeldung...

Einen ersten Wurf gibt's schon mal (auch mit codemirror-Link und was mir sonst noch so nebenbei aufgefallen war).

Fußnoten: Wer eine bessere Idee hat, darf die eine gerne "irgendwie anders" vertexten, an sich finde ich passende Links im Fließtext auch besser/angenehmer, aber wenn es erklärungsbedürftig ist wie hier, führt es häufig zu weit bzw. wird dann unübersichtlich. Eventuell wäre eine seitliche Infobox die bessere Lösung?

Verlinkung/Wiederholung:
Wegen der weiterführenden Hinweise ist sowieso ein Link in die DevModule-Ecke drin. Meine Befürchtung ist allerdings, dass das bei "massiverem " Einsatz der Methode ggf. abschreckend wirkt.
Grade habe ich noch einen Blick in https://wiki.fhem.de/wiki/Guidelines_zur_Dokumentation geworfen. An sich wäre der vorhandene Text dort ganz gut aufgehoben, man müßte/könnte ggf. dann nur zwischen "allg." und "Modul" unterscheiden; dann könnte man recht "unverfänglich" dahin verlinken?

Das mit den Beispielen war nicht unbedingt nur als Genehmigungsfrage gemeint, wer weitere gute Beispiele hat, darf die gerne hier reinwerfen .

Den eventuellen Ersatz für FS20 habe ich hier mal zur Diskussion gestellt: https://forum.fhem.de/index.php/topic,100206.msg939873.html#msg939873.

[betateilchen]

Vielleicht sollte man auch darauf hinweisen, dass bei Verwendung von configDB die 99_...Utils.pm in die Datenbank importiert werden können und dann automatisch von dort geladen werden. Das hat den Vorteil, dass beim Umzug / Neuaufsetzen von FHEM diese Dateien automatisch wieder verfügbar sind.

Über "Edit files" werden die Dateien ebenfalls wieder aus der Datenbank gelesen und nach der Bearbeitung auch automatisch wieder dorthin geschrieben.

[Beta-User]

configDB wird jetzt in einer Hinweisbox behandelt; hoffe, das faßt das Thema in diesem Punkt einigermaßen verständlich zusammen?

Ansonsten gibt's jetzt eine ganze Anzahl von Links, vorrangig ins Wiki.
(Ich fand das übrigens auch beim Zusammensuchen recht interessant, was es alles so gibt ). Wer was passendes hat: bitte ggf. direkt ergänzen oder Meldung hier.

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"

(Und ja, vermutlich würde es Sinn machen, das dann auch in einer englischen Fassung bereitzustellen; mach ich ggf., wenn das Beispiel überarbeitet ist, wenn nicht jemand sich vorher der Sache annimmt .)

[ph1959de]

configDB wird jetzt in einer Hinweisbox behandelt; hoffe, das faßt das Thema in diesem Punkt einigermaßen verständlich zusammen?

Bin mir nicht ganz sicher ob das

Nutzt man configDB, können die eigenen Programmdateien - ...

oder

Nutzt man configDB, müssen die eigenen Programmdateien - ...

oder auch "dringend empfohlen" ist.

[Beta-User]

Ich bin auf meinem Hauptsystem configDB-Nutzer . Da liegen die diversen myUtils (derzeit noch) im Filesystem, nicht aber z.B. die von einem at erstellten holiday-Dateien (siehe hier: https://forum.fhem.de/index.php/topic,85759.msg885883.html#msg885883).

Ergo ist es ein "können".

Was "empfohlen" angeht: da sind wir im Wiki ja allg. etwas zurückhaltend, aber ich werde das wohl demnächst umstellen. Edits laufen bei mir eh' über codemirror (das geht einfach am unkompliziertesten, selbst wenn ich das von "irgendwo" (notepad++=>github oder kate) dann einfach nur in codemirror hole); von daher ist es vom handling her egal. Nach meinen bisherigen Erfahrungen ist es so, dass configDB alles erst mal innerhalb der db sucht, und erst dann im filesystem (sofern man nicht ausdrücklich was anderes bei fileread anweist). Zurückgeschrieben werden editierte Dateien dabei immer dahin, wo sie herkamen.
M.E. bringt das Verwalten dieser Dateien innerhalb der db am meisten, wenn man keine lokale db-file nutzt, sondern einen zentralen Server; da würde ich es vermutlich dann auch empfehlen.

(OT @betateilchen: Es gibt ja Leute, die einen Pi im Einsatz haben, iVm. zentralen DB-Servern. Macht es für die eigentlich Sinn, auch die Moduldateien in die db zu importieren? Müßte doch updatefähig sein, oder...)

[betateilchen]

(OT @betateilchen: Es gibt ja Leute, die einen Pi im Einsatz haben, iVm. zentralen DB-Servern. Macht es für die eigentlich Sinn, auch die Moduldateien in die db zu importieren? Müßte doch updatefähig sein, oder...)

Wir sollten jetzt bitte die Anwender nicht durcheinander bringen.

Für die 99_..Utils.pm Dateien ist die Ablage in der Datenbank eine Empfehlung, kein Zwang.

Nach meinen bisherigen Erfahrungen ist es so, dass configDB alles erst mal innerhalb der db sucht, und erst dann im filesystem

Das ist so pauschal gesagt nicht richtig (das Verhalten ist abhängig von der Implementierung des jeweils "suchenden" Moduls), gehört aber auch nicht in diesen Thread.

[Beta-User]

Für die 99_..Utils.pm Dateien ist die Ablage in der Datenbank eine Empfehlung, kein Zwang.

Die Infobox ist nochmal etwas in diese Richtung angepaßt, Danke für die Klarstellung.

Das ist so pauschal gesagt nicht richtig (das Verhalten ist abhängig von der Implementierung des jeweils "suchenden" Moduls), gehört aber auch nicht in diesen Thread.

(auch OT, aber ich bin der TE und darf das...)
Fehlt in der list der supportenden Module nicht HMInfo (ich meine mich an eine Diskussion zwischen dir und Martin zu den Temperaturlisten erinnern zu können)?

Generelle Anmerkung: Was bei configDB empfohlene Vorgehensweisen für diverse Standardfälle sind, ist nach meinem persönlichen Eindruck nicht besonders weit gestreutes Wissen, ist mehr nach dem Motto: da gibt es eine Option, nutze sie oder lass' es. Ohne Erklärung, was wann ggf. für welche Variante spricht. Und wenn die Empfehlung heißt: in der Regel sollte man alles importieren, was supported wird, ist das auch eine Aussage. Die findet sich aber nicht so richtig in der cref, oder lese ich das einfach nicht richtig?


Auch in Teilen OT:

Es sind ja jetzt diverse Beispiele verlinkt. Da wollte ich mir den sendemail-Code mal "antun" (nutze normalerweise Telegram, und habe daher eigentlich nicht den Bedarf). Dazu finden sich im Wiki zwei Anleitungen: https://wiki.fhem.de/wiki/E-Mail_senden#Raspberry_Piund eine etwas erweiterte hier: https://wiki.fhem.de/wiki/SSCAM_-_Steuerung_von_Kameras_in_Synology_Surveillance_Station#Mail_mit_Snapshot_im_Anhang_und_Aufnahmelink_versenden_.28sendEmail.29

Beide haben aber den Nachteil, dass man die credentials hart vercoden muß. Gibt es da was besseres, als ggf. eine separate Textfile dafür zu nutzen? Dachte an einen Dummy, der die Daten dann in (teilweise) verschlüsselter Form bereitstellt...

[Otto123]

Beide haben aber den Nachteil, dass man die credentials hart vercoden muß. Gibt es da was besseres, als ggf. eine separate Textfile dafür zu nutzen? Dachte an einen Dummy, der die Daten dann in (teilweise) verschlüsselter Form bereitstellt...

Wollte ich auch schon immer mal angehen. Es gibt doch eine Funktion in FHEM die Account Infos in einem "verschlüsselten Speicher" ablegt? Kann man den nicht nutzen? Ich dachte Du als Entwickler kannst das
Oder kann man allowed dazu missbrauchen? - Haut mich nicht! 

Gruß Otto

[Beta-User]

Wollte ich auch schon immer mal angehen. Es gibt doch eine Funktion in FHEM die Account Infos in einem "verschlüsselten Speicher" ablegt? Kann man den nicht nutzen? Ich dachte Du als Entwickler kannst das
Oder kann man allowed dazu missbrauchen? - Haut mich nicht! 

Gruß Otto

Hmmm, wolltest du mit dem "Entwickler" meinen Ehrgeiz wecken?!? Du weißt doch genau, auf welchem Niveau sich meine Ratespielchen bewegen ...
Aber zumindest die Richtung, setKeyValue und getKeyValue zu nutzen, dürfte erst mal eine Verbesserung sein, wenn das auch nicht heißt, dass die Daten gleich verschlüsselt sind, sondern nur "zentral und woanders" gespeichert. Wer's fancy haben will und nicht per setKeyValue, sondern via Dialogfeld die (fehlenden) Daten da reinschubsen kann/will: evtl. Anleihe bei AttrTemplate nehmen (dort v.a. Zeilen 171ff)?

Zu allowed habe ich im Moment keine Idee. Aber das verlangt doch eigentlich immer Nutzereingaben (user/passwort) beim Aktivieren/Freischalten? Dürfte uns daher hier nicht weiterhelfen, es sei denn, wir nutzen einen starren "Verschlüsselungsmechanismus" wie in TelegramBot. Aber dann können wir (fast) auch Klartext verwenden.

Da es ja zunächst mal darum geht zu verhindern, dass versehentlich irgendwas veröffentlicht wird, was geheim bleiben soll, müßte set/getKeyValue eigentlich ein guter Weg sein, da bereits vorhanden . Und die zusätzlichen Schritte sind einfach zu erklären .

[Otto123]

Das mit allowed war eher so eine "indirekte" Idee, quasi nur als Datenspeicher. mit set schreib ich ja dort ein sha256 Attribute, kann man das nicht einfach wieder auslesen?
Ja habe mittlerweile nachgelesen: Nein kann man nicht, ist je "nur" ein Hash. Vergiss meine blöde Idee

[Beta-User]

Hmm,

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:

Code Auswählen Erweitern


######## sendEmail für den Emailversand verwenden ############
#adopted version from https://wiki.fhem.de/wiki/E-Mail_senden#Raspberry_Pi
sub
mySendEmail ($$$;$) {
my ($rcpt, $subject, $text, $attach) = @_;
my $sender = getKeyValue("myEmailAddress"); # use {setKeyValue("myEmailAddress",'absender@account.de')} once in commandline to store the parameter
my $konto = getKeyValue("myEmailAccount"); # like before: {setKeyValue("myEmailAccount",'absender@account.de')}
my $passwrd = getKeyValue("myEmailPasswrd"); # like before: {setKeyValue("myEmailPasswrd","passwrd")}
my $provider = getKeyValue("myEmailServer"); # like before: {setKeyValue("myEmailServer",'smtp.provider.de:587')}
Log3 1, "mySendEmail RCP: $rcpt, Subject: $subject, Text: $text";
Log3 1, "mySendEmail Anhang: $attach" if defined $attach;
my $ret ="";
if ($attach) {
   $ret .= qx(sendemail -f $sender -t $rcpt -u $subject -m $text -a $attach -s $provider -xu $konto -xp $passwrd -o tls=auto -o message-charset=utf-8);
} else {
   $ret .= qx(sendemail -f $sender -t $rcpt -u $subject -m $text -s $provider -xu $konto -xp $passwrd -o tls=auto -o message-charset=utf-8);
}
$ret =~ s,[\r\n]*,,g;    # remove CR from return-string
Log3 1, "mySendEmail returned: $ret";
}


Edit: Code verbessert, Danke an nils_!

[Otto123]

Das sieht gut aus. Ich habe jetzt bloß exemplarisch diese eine Zeile getestet, in meiner Sub ausgetauscht:

Code Auswählen Erweitern

my $passwrd = getKeyValue("myEmailPasswrd"); # like before: {setKeyValue("myEmailPasswrd","passwrd")}
Die Mail wurde erfolgreich versendet

[nils_]

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?

Code Auswählen Erweitern

my $provider = "myEmailServer"; # like before: {setKeyValue("myEmailServer",'smtp.provider.de:587')}
ändern zu

Code Auswählen Erweitern

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

[Beta-User]

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.

[betateilchen]

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.

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

[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?

[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

[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

[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!)

[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

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

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

[Otto123]

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. 

[Otto123]

Moin Beta-User,

Die 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"? 
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):

[betateilchen]

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.

[Beta-User]

@betateilchen:
done

[Beta-User]

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:

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

[Beta-User]

Im Nachgang zu dem hier hätte ich jetzt folgenden Vorschlag für einen Abschnitt im QuickStart (dort nach den "Modulen für die erste Zeit"):

FHEM ist ein Perl Server...

Die meisten FHEM-Nutzer werden früher oder später daran erinnert, dass FHEM in Perl programmiert ist. Auch wenn es in vielen Fällen nicht zwingend erforderlich ist, diese Programmiersprache zu erlernen, ist es für ein vertieftes Verständnis der Funktionsweise Ihrer Hausautomatisierung hilfreich, wenn Sie sich auch mit den Grundlagen zu Perl sowie der häufig vorkommenden [[Regulärer Ausdruck|regex-Ausdrücken]] vertraut machen. Manche Problemstellungen lassen sich nach wie vor am effektivsten unmittelbar mit diesen Werkzeugen lösen.
Einen ersten Einblick in diese Themen finden Sie in den (cref-link=>) FHEM Befehls-Typen, (cref-link=>) PERL Besonderheiten und dem Artikel zu [[99 myUtils anlegen]]. [[Kategorie:Development|In diesen Artikeln]] sind weitere Informationen für  Fortgeschrittene und Experten zu finden.

Damit soll es dann von meiner Seite her erst mal sein Bewenden haben, wenn es genügend positive Rückmeldung dazu gibt. bau ich es ein, ansonsten eben nicht . (Entsprechendes gilt für Verbesserungsvorschläge)

[Beta-User]

Grade habe ich noch einen Blick in https://wiki.fhem.de/wiki/Guidelines_zur_Dokumentation geworfen. An sich wäre der vorhandene Text dort ganz gut aufgehoben, man müßte/könnte ggf. dann nur zwischen "allg." und "Modul" unterscheiden; dann könnte man recht "unverfänglich" dahin verlinken?

Hab' mir jetzt mal das Doku-Thema nochmal angesehen. Soweit erkennbar haben wir:
- den Abschnitt in 99 myUtils anlegen
- das Hello-Beispiel in https://wiki.fhem.de/wiki/DevelopmentModuleIntro#.22Hello_World.22_Beispiel, das aber dann keine weiteren Erläuterungen enthält und die bereits oben genannten
- https://wiki.fhem.de/wiki/Guidelines_zur_Dokumentation.
Bei näherer Betrachtung kann ich keine wirkliche Doppelung erkennen, das einzige Manko ist das, dass es etwas verteilt ist.

An den "Guidelines" würde ich nichts ändern, Adressat sind klar Developer, und auch die dortige Botschaft sollte man nicht durch Ergänzung mit eher technischen Hinweisen verwässern.

Ergo würde ich es im wesentlichen lassen, wie es ist, der Doku-Abschnitt ist in "99" auch nicht so ausgeprägt lang.

Bleibt m.E. zur Überarbeitung das Beispiel.

Andere Ideen zu dem Punkt?

[krikan]

Im Nachgang zu dem hier hätte ich jetzt folgenden Vorschlag für einen Abschnitt im QuickStart (dort nach den "Modulen für die erste Zeit"):

Damit soll es dann von meiner Seite her erst mal sein Bewenden haben, wenn es genügend positive Rückmeldung dazu gibt.

positive Rückmeldung. 
Mir ist der Hinweis auf Perl-Grundkenntnisse sehr wichtig.

Letztlich laufen wir aber "Gefahr" Quick-Start irgendwann zu verlassen und in Einsteigerdoku überzugehen. Das finde ich aber nicht tragisch.

Positive Rückmeldung gilt auch für myUtils.

An den "Guidelines" würde ich nichts ändern, Adressat sind klar Developer, und auch die dortige Botschaft sollte man nicht durch Ergänzung mit eher technischen Hinweisen verwässern.

Ergo würde ich es im wesentlichen lassen, wie es ist, der Doku-Abschnitt ist in "99" auch nicht so ausgeprägt lang.

Bleibt m.E. zur Überarbeitung das Beispiel.

Andere Ideen zu dem Punkt?

Keine Ideen. Mach ruhig.

Gruß, Christian

[Beta-User]

positive Rückmeldung. 

Thx, das reicht mir schon . Ist drin, und auch eine vorläufige englische Fassung gibt's seit eben; die hat nur leider noch eine ganze Anzahl von deutschsprachigen Links, das überarbeite ich dann ggf. noch.

Mir ist der Hinweis auf Perl-Grundkenntnisse sehr wichtig.

Letztlich laufen wir aber "Gefahr" Quick-Start irgendwann zu verlassen und in Einsteigerdoku überzugehen. Das finde ich aber nicht tragisch.

Positive Rückmeldung gilt auch für myUtils.
Keine Ideen. Mach ruhig.

Gruß, Christian

Das mit den Perl-Grundkenntnissen geht (mMn.) nicht nur mir auch so.

Die "Gefahr" mag da sein, aber als "Einsteigerdoku" kann es allenfalls für User angesehen werden, die mit dem (mAn) gehobenen Niveau klarkommen . Aber es kann und soll ruhig eine solide Startbasis sein, wenn man auch als erfahrener Nutzer "mal eben was sucht"; daher finde ich die vielen Fußnoten da auch völlig ok .

An dem 99-er Artikel mache ich bei Gelegenheit weiter, im Moment fehlt noch Rückmeldung von meinen "Testusern" für das Beispielchen . Insbesondere der TE wollte mehr Zeit als ein WE haben.