99 myUtils anlegen

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

Vorheriges Thema - Nächstes Thema

Beta-User

Hallo zusammen,

neulich hatten wir einen Thread "Perl für Anfänger". In den Zusammenhang greife ich mal das hier auf:
Zitat von: Beta-User am 04 Mai 2019, 14:20:00
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:
ZitatDie 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
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

ph1959de

Zitat von: Beta-User am 14 Mai 2019, 10:58:05
- 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

Zitat von: Beta-User am 14 Mai 2019, 10:58:05
- "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.

Zitat von: Beta-User am 14 Mai 2019, 10:58:05
- 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"

Zitat von: Beta-User am 14 Mai 2019, 10:58:05
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
Aktives Mitglied des FHEM e.V. | Moderator im Forenbereich "Wiki"

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

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

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

ph1959de

Zitat von: Beta-User am 15 Mai 2019, 13:01:34
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
ZitatNutzt man configDB, können die eigenen Programmdateien - ...
oder
ZitatNutzt man configDB, müssen die eigenen Programmdateien - ...
oder auch "dringend empfohlen" ist.
Aktives Mitglied des FHEM e.V. | Moderator im Forenbereich "Wiki"

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...)
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 15 Mai 2019, 14:11:13
(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.

Zitat von: Beta-User am 15 Mai 2019, 14:11:13
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.
-----------------------
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

Zitat von: betateilchen am 15 Mai 2019, 18:34:52
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.

ZitatDas 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...
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: Beta-User am 16 Mai 2019, 11:24:14
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!  :D

Gruß 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

Beta-User

Zitat von: Otto123 am 16 Mai 2019, 12:02:31
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!  :D

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

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

Beta-User

#13
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:

######## 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_!
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

#14
Das sieht gut aus. Ich habe jetzt bloß exemplarisch diese eine Zeile getestet, in meiner Sub ausgetauscht:
my $passwrd = getKeyValue("myEmailPasswrd"); # like before: {setKeyValue("myEmailPasswrd","passwrd")}
Die Mail wurde erfolgreich versendet :)
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