Originally posted by: <email address deleted>
Hallo zusammen,
ich habe zwei Fragen zu myutils:
a) Was fasst man alles dort hnein? Ich habe mitlerweile enige notify`s in
der global configuration.
Sollte ich dies auslagern?
b) Wie genau klappt das? Ich habe die Beispiele in Wiki und in groups
gelesen, aber dort werden die "Unterprogramme" alle wiederum mit notify´s
in der cfg aufgerufen. Da "spart" man ja ncht wirklich was, oder?
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
ist ne Frage der Übersichtlichkeit. Ein 30-zeiliger code hinter einem notify ist unpraktisch.
Bei mehr als 3 bis 5 Anweisungen wandert's bei mir in myUtils.
Gruß Uli
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
> Ich habe mitlerweile enige notify`s in der
> global configuration. Sollte ich dies auslagern?
Ja, wenn diese jeweils deutlich laenger als eine "normale" Zeile sind, und
man Probleme beim editieren hat.
> b) Wie genau klappt das?
FHEMWEB:
Edit Files
99_Utils.pm
Alles nach der Funktion Utils_Initialize bis zum (exklusive) 1; entfernen
Utils_Initialize in MyUtils_Initialize umbenenne
Save as: 99_MyUtils.pm
99_MyUtils.pm
Funktion Anlegen:
sub
myNotifyFn1($$)
{
my ($dev, $event);
}
Save 99_MyUtils.pm
Notify definieren:
define myNotify1 notify regexp { myNotifyFn1("@", "%") }
Notify testen:
trigger myNotify device regexp
Alternative (am besten mit einem zweiten fhem)
- fhem.cfg mit "attr global logfile -":
das fhem-log landet im Start-Terminal und nicht in einer Datei, fhem bleibt
im Vordergrund
- Mit dem lieblings-Editor 99_MyUtils.pm bearbeiten
- Fhem in separaten Terminal starten, Fehlermeldungen beobachten, fhem mit ^C
abbrechen, und nach fixen der Fehler mit Pfeil nach oben, return neu starten.
- Debuggen kann man mit
Log 1, "debugzeile";
in der Funktion, das sieht man dann direkt im Start-Terminal
- Testen mit "trigger myNotify device regexp" aus einem zweiten Terminal mit
telnet oder aus FHEMWEB.
- die "echten" events sieht man in einem telnet zum "echten" fhem, indem man da
"inform timer" eingibt. Oder man verwendet den Event-Monitor von FHEMWEB.
Dieser braucht aber ein refresh nach dem fhem-neustart.
> Ich habe die Beispiele in Wiki und in groups gelesen, aber dort werden die
> "Unterprogramme" alle wiederum mit notify愀 in der cfg aufgerufen. Da "spart"
> man ja ncht wirklich was, oder?
Text sparen tut man nicht wirklich, aber:
- die Perl-Fehlermeldungen sind verstaendlicher, weil diese eine Zeilenangabe
enthalten
- man spart sich das dumme ;; bzw \,
- auch @ bzw. % muss nicht gedoppelt werden. Dafuer muss man @, % bzw.
%EVTPARTx als Parameter an die Funktion weiterreichen.
- Bei einem at - Einzeiler muss @ und % wiederum nicht geschuetzt werden, das
kann manchmal auch verwirren.
-> Man schreibt halt "normales" perl. Der Aufwand lohnt sich nur fuer laengere
Sachen bzw. wenn man unsicher ist. Geschwindigkeitsunterschiede sind nicht
relevant.
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Sorry, mein Fehler:
my ($dev, $event);
gehoert als
my ($dev, $event) = @_;
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Genial!
Ich finde so was gehört direkt is Wiki :-)
Am Samstag, 11. August 2012 08:26:54 UTC+2 schrieb Rudolf Koenig:
>
> Sorry, mein Fehler:
> my ($dev, $event);
> gehoert als
> my ($dev, $event) = @_;
>
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Dann hitte den bestehenden Einorarg erweitern:
http://fhemwiki.de/wiki/99_myUtils_anlegen
Gruß Uli
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
Vielen Dank für die ausführliche Antwort, ich werde das am WE ausprobieren.
Rein vom lesen her ist das dür einen Einsteiger ziemlich viel input.
Bisher habe ich mich immer mide codeschnipseln durchgeschlagen.
Am Samstag, 11. August 2012 08:23:42 UTC+2 schrieb Rudolf Koenig:
>
> > Ich habe mitlerweile enige notify`s in der
> > global configuration. Sollte ich dies auslagern?
>
> Ja, wenn diese jeweils deutlich laenger als eine "normale" Zeile sind, und
> man Probleme beim editieren hat.
>
> > b) Wie genau klappt das?
>
> FHEMWEB:
> Edit Files
> 99_Utils.pm
> Alles nach der Funktion Utils_Initialize bis zum (exklusive) 1;
> entfernen
> Utils_Initialize in MyUtils_Initialize umbenenne
> Save as: 99_MyUtils.pm
> 99_MyUtils.pm
> Funktion Anlegen:
> sub
> myNotifyFn1($$)
> {
> my ($dev, $event);
>
> }
> Save 99_MyUtils.pm
> Notify definieren:
> define myNotify1 notify regexp { myNotifyFn1("@", "%") }
> Notify testen:
> trigger myNotify device regexp
>
> Alternative (am besten mit einem zweiten fhem)
> - fhem.cfg mit "attr global logfile -":
> das fhem-log landet im Start-Terminal und nicht in einer Datei, fhem
> bleibt
> im Vordergrund
> - Mit dem lieblings-Editor 99_MyUtils.pm bearbeiten
> - Fhem in separaten Terminal starten, Fehlermeldungen beobachten, fhem mit
> ^C
> abbrechen, und nach fixen der Fehler mit Pfeil nach oben, return neu
> starten.
> - Debuggen kann man mit
> Log 1, "debugzeile";
> in der Funktion, das sieht man dann direkt im Start-Terminal
> - Testen mit "trigger myNotify device regexp" aus einem zweiten Terminal
> mit
> telnet oder aus FHEMWEB.
> - die "echten" events sieht man in einem telnet zum "echten" fhem, indem
> man da
> "inform timer" eingibt. Oder man verwendet den Event-Monitor von
> FHEMWEB.
> Dieser braucht aber ein refresh nach dem fhem-neustart.
>
>
>
> > Ich habe die Beispiele in Wiki und in groups gelesen, aber dort werden
> die
> > "Unterprogramme" alle wiederum mit notify�s in der cfg aufgerufen. Da
> "spart"
> > man ja ncht wirklich was, oder?
>
> Text sparen tut man nicht wirklich, aber:
> - die Perl-Fehlermeldungen sind verstaendlicher, weil diese eine
> Zeilenangabe
> enthalten
> - man spart sich das dumme ;; bzw \,
> - auch @ bzw. % muss nicht gedoppelt werden. Dafuer muss man @, % bzw.
> %EVTPARTx als Parameter an die Funktion weiterreichen.
> - Bei einem at - Einzeiler muss @ und % wiederum nicht geschuetzt werden,
> das
> kann manchmal auch verwirren.
>
> -> Man schreibt halt "normales" perl. Der Aufwand lohnt sich nur fuer
> laengere
> Sachen bzw. wenn man unsicher ist. Geschwindigkeitsunterschiede sind
> nicht
> relevant.
>
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
>
>
> Ist es sinnvoll/möglich den eigenen Code in mehrere Dateien aufzusplitten
wie:
99_my_fht_utils.pm, 99_my_wetter_utils.pm, 99_my_bild_generieren_utils.pm?
Gruß
Gerhard
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
möglich ja
sinnvoll hängt vom umfang ab
ich scrolle lieber etwas in derselben datei, statt zwischen files wechseln
zu müssen
ist geschmacksache denk ich. je größer die installation, desto sinnvoller
gruß, Uli
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com
Originally posted by: <email address deleted>
>
> ist geschmacksache denk ich. je größer die installation, desto sinnvoller
>
Hab gerade mal nachgezählt. Es sind bei mir mittlerweile über 3300 Zeilen.
19 at-Blöcke, 31 Notifys. Und da meine Notifys großenteils abgeschlossene
Funktionsblöcke darstellen (Heizungsregelung, Taktgeber, Bildgenerator,
Hinweisgenerator, Info-/Warnsystem mit Priorisierung, Fernbedienung etc.),
dürfte sich das aufsplitten in mehrere Dateien lohnen.
Muss ich mich demnächst mal daran versuchen. Vielen Dank für die Info!
Gruß
Gerhard
--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com