Merkwürdiges Problem mit notify und HM-LC-SW1-BA-PCB

[ambiman]

Hallo zusammen,

ich habe ein seltsames Phänomen mit einem Notify und dem Funk-Batterieaktor zur Ansteuerung einer Piezosirene:

Folgendes Notify wurde definiert:

Code Auswählen Erweitern



Internals:
   DEF        TuerEG:open { if (Value('HomeStatus') eq '1') { fhem("set Alarmgeber_Piezo_Flur on-for-timer 2"); fhem("set pushmsg msg 'ALARM' '$NAME wurde in Abwesenheit geöffnet!' '' 1 ''"); DebianMail('mail@domain.com','ALARM: TuerEG','ALARM: '.$NAME.' wurde in Abwesenheit geöffnet!'); } }                   
   NAME       AlarmGruppe_TuerEGgeoeffnet
   NOTIFYDEV  TuerEG
   NR         91
   NTFY_ORDER 50-AlarmGruppe_TuerEGgeoeffnet
   REGEXP     TuerEG:open
   STATE      2016-01-01 14:57:15
   TYPE       notify
   Readings:
     2016-01-01 14:56:58   state           active
Attributes:



Lasse ich die E-Mailfunktion in der IF-Clause weg funktioniert alles wie gewünscht, die Sirene löst über einen Timer für 2 sek aus und ich bekomme eine Push-Msg aufs Smartphone.

Sobald ich die E-Mailfunktion jedoch mit rein nehme (Definition dieser siehe unten - quasi die FHEM Standardversion), funktioniert die Sirene nicht mehr: Ich erhalte noch die Pushmsg und eine E-Mail, der Status des Batterieaktors bleibt jedoch dauerhaft auf 'set_on-for-timer 2' stehen!?

Hat jemand eine Idee ?

Anbei die E-Mailfunktion in meiner myUtils.pm:

Code Auswählen Erweitern


DebianMail
{
my $rcpt = shift;
my $subject = shift;
my $text = shift;
my $ret = "";
my $sender = "sender\@domain.de";           
my $konto = "walle";
my $passwrd = "geheim";
my $provider = "mailserver:25";
Log 1, "sendEmail RCP: $rcpt";
Log 1, "sendEmail Subject: $subject";
Log 1, "sendEmail Text: $text";

$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
Log 1, "sendEmail returned: $ret";
}


[stromer-12]

Kann es sein, das deine Mailzustellung FHEM länger als 2 Sekunden blockiert?

[ambiman]

Da SMTPS im Spiel ist kann ich das nicht ausschließen, gibt es hier ein Limit von 2 sek?

[ambiman]

Ich verstehe deinen Gedankengang, ich habe nun den Timer mal auf 10sek erhöht - leider auch ohne wirklichen Erfolg.
Ich verstehe nicht, weshalb der Status des Geräts bei STATE set_on-for-timer 10 hängen bleibt - anschließend kann ich keine Befehle (bspw. getConfig o.ä.) mehr absetzen und muss den Aktor kurz vom Strom trennen.

Anbei noch einige Debug-Logs zum RAW-Datentransfer:

Manuelles set on-for-timer 2:

Code Auswählen Erweitern


2016.01.01 19:05:36 3: CUL_HM set Alarmgeber_Piezo_Flur on-for-timer 2
2016.01.01 19:05:36 4: CUL_send:  CUL_0As 10 07 B011 27D0E2 3C9821 0201C800000280
2016.01.01 19:05:37 4: CUL_Parse: CUL_0 A 11 07 A002 3C9821 27D0E2 04C3F0557E1224043F -42.5
2016.01.01 19:05:37 4: CUL_send:  CUL_0As 19 07 A003 27D0E2 3C9821 92a8a7e492c0da1b76ef7494c209bcc1
2016.01.01 19:05:37 4: CUL_Parse: CUL_0 A 12 07 8002 3C9821 27D0E2 0101C8402871BBCFDC41 -41.5


Aktivitäten des notify:

Code Auswählen Erweitern


2016.01.01 19:07:25 3: CUL_HM set Alarmgeber_Piezo_Flur on-for-timer 2
2016.01.01 19:07:25 4: CUL_send:  CUL_0As 10 09 B011 27D0E2 3C9821 0201C800000280
2016.01.01 19:07:25 1: sendEmail RCP: mail@domain.com
2016.01.01 19:07:25 1: sendEmail Subject: ALARM: TuerEG
2016.01.01 19:07:25 1: sendEmail Text: ALARM: TuerEG wurde in Abwesenheit geöffnet!
2016.01.01 19:07:28 1: sendEmail returned: Jan 01 19:07:28 walle sendEmail[21377]: Email was sent successfully!
2016.01.01 19:07:28 4: CUL_send:  CUL_0As 10 09 B011 27D0E2 3C9821 0201C800000280
2016.01.01 19:07:28 4: CUL_Parse: CUL_0 A 11 09 A002 3C9821 27D0E2 047DF258811689043F -42.5
2016.01.01 19:07:28 4: CUL_send:  CUL_0As 19 09 A003 27D0E2 3C9821 069a07b6c3fdb142754c3cc9d5c5a94e


[ambiman]

Hier noch ein paar weitere Logs, er scheint zu versuchen, etwas erneut zu senden (CUL_HM_Resend).

Code Auswählen Erweitern


2016.01.01 19:19:38 5: Notify loop for TuerEG open
2016.01.01 19:19:38 5: Triggering AlarmGruppe_TuerEGgeoeffnet
2016.01.01 19:19:38 4: AlarmGruppe_TuerEGgeoeffnet exec { if (Value('HomeStatus') eq '1') { fhem("set Alarmgeber_Piezo_Flur on-for-timer 2");; DebianMail('mail@domain.com','ALARM: TuerEG','ALARM: '.$NAME.' wurde in Abwesenheit geöffnet!');; } }2016.01.01 19:19:38 5: Cmd: >{ if (Value('HomeStatus') eq '1') { fhem("set Alarmgeber_Piezo_Flur on-for-timer 2"); DebianMail('mail@domain.com','ALARM: TuerEG','ALARM: '.$NAME.' wurde in Abwesenheit geöffnet!'); } }<
2016.01.01 19:19:38 5: Cmd: >set Alarmgeber_Piezo_Flur on-for-timer 2<
2016.01.01 19:19:38 5: CUL_HM Alarmgeber_Piezo_Flur protEvent:CMDs_pending pending:1
2016.01.01 19:19:38 5: Triggering Alarmgeber_Piezo_Flur (1 changes)
2016.01.01 19:19:38 5: Notify loop for Alarmgeber_Piezo_Flur set_on-for-timer 2
2016.01.01 19:19:38 3: CUL_HM set Alarmgeber_Piezo_Flur on-for-timer 2
2016.01.01 19:19:38 5: CUL_0 sending As1007B01127D0E23C98210201C800000280
2016.01.01 19:19:38 4: CUL_send:  CUL_0As 10 07 B011 27D0E2 3C9821 0201C800000280
2016.01.01 19:19:38 5: CUL_HM Alarmgeber_Piezo_Flur protEvent:CMDs_processing... pending:0
2016.01.01 19:19:38 1: sendEmail RCP: mail@domain.com
2016.01.01 19:19:38 1: sendEmail Subject: ALARM: TuerEG
2016.01.01 19:19:38 1: sendEmail Text: ALARM: TuerEG wurde in Abwesenheit geöffnet!
2016.01.01 19:19:42 1: sendEmail returned: Jan 01 19:19:42 walle sendEmail[21401]: Email was sent successfully!
2016.01.01 19:19:42 4: CUL_HM_Resend: Alarmgeber_Piezo_Flur nr 2
2016.01.01 19:19:42 5: CUL_0 sending As1007B01127D0E23C98210201C800000280
2016.01.01 19:19:42 4: CUL_send:  CUL_0As 10 07 B011 27D0E2 3C9821 0201C800000280
2016.01.01 19:19:42 5: CUL/RAW: /A1107A0023C982127D0E204C3DC8B7E12240440
2016.01.01 19:19:42 4: CUL_Parse: CUL_0 A 11 07 A002 3C9821 27D0E2 04C3DC8B7E12240440 -42
2016.01.01 19:19:42 5: CUL_0 dispatch A1107A0023C982127D0E204C3DC8B7E122404::-42:CUL_0
2016.01.01 19:19:42 5: CUL_HM Alarmgeber_Piezo_Flur signing request for As1007B01127D0E23C98210201C800000280 challenge: C3DC8B7E1224 kNo: 2
2016.01.01 19:19:42 5: CUL_HM Alarmgeber_Piezo_Flur signing response: 5686c33e939c07b01127d0e23c982102 should send DB132762 to authenticate
2016.01.01 19:19:42 5: CUL_0 sending As1907A00327D0E23C98210894bb1d7db345f55266dab67b640a19
2016.01.01 19:19:42 5: CUL 3C9821 dly:77ms
2016.01.01 19:19:42 4: CUL_send:  CUL_0As 19 07 A003 27D0E2 3C9821 0894bb1d7db345f55266dab67b640a19
2016.01.01 19:19:42 5: CUL_HM Alarmgeber_Piezo_Flur protEvent:CMDs_processing... pending:0
2016.01.01 19:19:42 5: Triggering Alarmgeber_Piezo_Flur (1 changes)
2016.01.01 19:19:42 5: Notify loop for Alarmgeber_Piezo_Flur aesKeyNbr: 04


[frank]

als workaround würde ich mal ein nicht blockierendes fhem sleep einbauen, oder eine andere verzögerung, so dass die mail später kommt.