Server hängt beim Email senden

[Guest]

Originally posted by: <email address deleted>

Hi,

Ich nutze einen rPi mit COC und CUL. Zur Überwachung meiner Fenster nutze ich HM-SEC-SC Sensoren. Wenn ich via notify nun eine Email beim öffnen versende und der Kontakt dann relativ schnell (zwischen 2 und 5 Sekunden) wieder schließt, bekommt der Sensor die ACK Message nicht mit und gibt den Fehler über die rote LED aus. Scheinbar blockiert der mail Prozess für ein paar Sekunden die weitere Kommunikation. Selbst wenn ich Register 48 für die Sendeversuche auf den Maximalwert setze, bekommt er kein ACK mit.

Hatte jemand schon ein ähnliches Problem und kennt einen Lösungsansatz? Wie kann ich das nur für ein Device gut debuggen? Sendet fhem nur ein ACK und kein weiteres bei den erneuten Sendeversuchen des Sensors?

Gruß,
Andre

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

Wie versendest du denn die E-Mail im Notify?

Du könntest das auch in einen eigenen Thread oder einen Systemaufruf wegkapseln. Dann würde die Fhem Verarbeitung normal weiter gehen.

Am Mittwoch, 28. November 2012 19:55:59 UTC+1 schrieb Andre:
> Hi,
>
> Ich nutze einen rPi mit COC und CUL. Zur Überwachung meiner Fenster nutze ich HM-SEC-SC Sensoren. Wenn ich via notify nun eine Email beim öffnen versende und der Kontakt dann relativ schnell (zwischen 2 und 5 Sekunden) wieder schließt, bekommt der Sensor die ACK Message nicht mit und gibt den Fehler über die rote LED aus. Scheinbar blockiert der mail Prozess für ein paar Sekunden die weitere Kommunikation. Selbst wenn ich Register 48 für die Sendeversuche auf den Maximalwert setze, bekommt er kein ACK mit.

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

Ich nutze folgenden Call in 99_myUtils.pm

sub rpiMail {
...
qx(sendEmail -f '$from' -t '$rcpt' -u '$subject' -m '$text' -s '$provider'
-xu '$account' -xp '$pass' -o tls=yes);
}

Wird ein "system" Call direkt multithreaded ausgeführt? Sollte FHEM nicht
einen der folgenden Sendeversuche des Sensors beantworten oder hab ich da
etwas prinzipiell nicht verstanden?

Am Mittwoch, 28. November 2012 21:50:16 UTC+1 schrieb Reinerlein:
>
> Wie versendest du denn die E-Mail im Notify?
>
> Du könntest das auch in einen eigenen Thread oder einen Systemaufruf
> wegkapseln. Dann würde die Fhem Verarbeitung normal weiter gehen.
>
> Am Mittwoch, 28. November 2012 19:55:59 UTC+1 schrieb Andre:
> > Hi,
> >
> > Ich nutze einen rPi mit COC und CUL. Zur Überwachung meiner Fenster
> nutze ich HM-SEC-SC Sensoren. Wenn ich via notify nun eine Email beim
> öffnen versende und der Kontakt dann relativ schnell (zwischen 2 und 5
> Sekunden) wieder schließt, bekommt der Sensor die ACK Message nicht mit und
> gibt den Fehler über die rote LED aus. Scheinbar blockiert der mail Prozess
> für ein paar Sekunden die weitere Kommunikation. Selbst wenn ich Register
> 48 für die Sendeversuche auf den Maximalwert setze, bekommt er kein ACK
> mit.
>
>

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

Also zu den Aktorsachen kann ich wenig sagen, allerdings zu dem Mailversand.

Der ist so erstmal blockierend. Das bedeutet, wenn der SMTP-Server etwas langsamer ist (bzw. die Leitung dahin), dann dauert das etwas.

Ein Systemaufruf ist nicht per se in einem eigenen Thread. Du kannst aber ein &-Zeichen an die Befehlszeile anhängen, sodass das Betriebssystem den Job alleine erledigt (zumindest gilt das für Linux o.ä.). Dann erhältst du aber keine direkte Rückantwort (Ist dann ja asynchron), und müsstest dich um ein Logging kümmern, damit du das Ergebnis analysieren kannst.

Ob das mit dem &-Zeichen bei qx() direkt geht, weiss ich jetzt nicht auswendig. Das müsstest du mal probieren...
Ansonsten wäre die Alternative system().

Am Mittwoch, 28. November 2012 21:59:58 UTC+1 schrieb Andre:
> Ich nutze folgenden Call in 99_myUtils.pm
>
>
> sub rpiMail {
> ...
> qx(sendEmail -f '$from' -t '$rcpt' -u '$subject' -m '$text' -s '$provider' -xu '$account' -xp '$pass' -o tls=yes);
> }
>
>
> Wird ein "system" Call direkt multithreaded ausgeführt? Sollte FHEM nicht einen der folgenden Sendeversuche des Sensors beantworten oder hab ich da etwas prinzipiell nicht verstanden?
>
>
> Am Mittwoch, 28. November 2012 21:50:16 UTC+1 schrieb Reinerlein:Wie versendest du denn die E-Mail im Notify?
>
>
>
> Du könntest das auch in einen eigenen Thread oder einen Systemaufruf wegkapseln. Dann würde die Fhem Verarbeitung normal weiter gehen.
>
>
>
> Am Mittwoch, 28. November 2012 19:55:59 UTC+1 schrieb Andre:
>
> > Hi,
>
> >
>
> > Ich nutze einen rPi mit COC und CUL. Zur Überwachung meiner Fenster nutze ich HM-SEC-SC Sensoren. Wenn ich via notify nun eine Email beim öffnen versende und der Kontakt dann relativ schnell (zwischen 2 und 5 Sekunden) wieder schließt, bekommt der Sensor die ACK Message nicht mit und gibt den Fehler über die rote LED aus. Scheinbar blockiert der mail Prozess für ein paar Sekunden die weitere Kommunikation. Selbst wenn ich Register 48 für die Sendeversuche auf den Maximalwert setze, bekommt er kein ACK mit.

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

[Guest]

Originally posted by: <email address deleted>

Ok, wenn ich das umschreibe zu

 $ret = system("sendEmail -f '$sender' -t '$rcpt' -u '$subject' -m '$text'
-s '$provider' -xu '$konto' -xp '$passwrd' -o tls=yes &");

haut das hin. Da ich die Antwort des calls nicht benötige ist das für mich
auch ok, danke für den Hinweis.

Kann dennoch jemand etwas zu dem FHEM Mechanismus sagen?

Am Mittwoch, 28. November 2012 22:10:44 UTC+1 schrieb Reinerlein:
>
> Also zu den Aktorsachen kann ich wenig sagen, allerdings zu dem
> Mailversand.
>
> Der ist so erstmal blockierend. Das bedeutet, wenn der SMTP-Server etwas
> langsamer ist (bzw. die Leitung dahin), dann dauert das etwas.
>
> Ein Systemaufruf ist nicht per se in einem eigenen Thread. Du kannst aber
> ein &-Zeichen an die Befehlszeile anhängen, sodass das Betriebssystem den
> Job alleine erledigt (zumindest gilt das für Linux o.ä.). Dann erhältst du
> aber keine direkte Rückantwort (Ist dann ja asynchron), und müsstest dich
> um ein Logging kümmern, damit du das Ergebnis analysieren kannst.
>
> Ob das mit dem &-Zeichen bei qx() direkt geht, weiss ich jetzt nicht
> auswendig. Das müsstest du mal probieren...
> Ansonsten wäre die Alternative system().
>
> Am Mittwoch, 28. November 2012 21:59:58 UTC+1 schrieb Andre:
> > Ich nutze folgenden Call in 99_myUtils.pm
> >
> >
> > sub rpiMail {
> > ...
> > qx(sendEmail -f '$from' -t '$rcpt' -u '$subject' -m '$text' -s
> '$provider' -xu '$account' -xp '$pass' -o tls=yes);
> > }
> >
> >
> > Wird ein "system" Call direkt multithreaded ausgeführt? Sollte FHEM
> nicht einen der folgenden Sendeversuche des Sensors beantworten oder hab
> ich da etwas prinzipiell nicht verstanden?
> >
> >
> > Am Mittwoch, 28. November 2012 21:50:16 UTC+1 schrieb Reinerlein:Wie
> versendest du denn die E-Mail im Notify?
> >
> >
> >
> > Du könntest das auch in einen eigenen Thread oder einen Systemaufruf
> wegkapseln. Dann würde die Fhem Verarbeitung normal weiter gehen.
> >
> >
> >
> > Am Mittwoch, 28. November 2012 19:55:59 UTC+1 schrieb Andre:
> >
> > > Hi,
> >
> > >
> >
> > > Ich nutze einen rPi mit COC und CUL. Zur Überwachung meiner Fenster
> nutze ich HM-SEC-SC Sensoren. Wenn ich via notify nun eine Email beim
> öffnen versende und der Kontakt dann relativ schnell (zwischen 2 und 5
> Sekunden) wieder schließt, bekommt der Sensor die ACK Message nicht mit und
> gibt den Fehler über die rote LED aus. Scheinbar blockiert der mail Prozess
> für ein paar Sekunden die weitere Kommunikation. Selbst wenn ich Register
> 48 für die Sendeversuche auf den Maximalwert setze, bekommt er kein ACK
> mit.
>
>

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com