E-Mail SSMTP Raspberry Batterieüberwachung

[stephanr]

Steht denn in den Logs etwas? var/log/syslog, var/log/messages oder /var/log/mail.*?

Gesendet von meinem E5823 mit Tapatalk

[tantor]

Hallo,
ihr der Auszug aus den entsprechenden Log-Dateien. Kann leider mit den Meldungen nichts anfangen. Habe vorher den "echo-Befehl" abgesetzt.

sys.log:     Nov 25 17:52:34 raspberrypi sSMTP[4484]: Creating SSL connection to host
                 Nov 25 17:52:34 raspberrypi sSMTP[4484]: SSL connection using RSA_AES_128_CBC_SHA1
                 Nov 25 17:52:34 raspberrypi sSMTP[4484]: Authorization failed (535 Authentication credentials invalid)

mail.log:   Nov 25 17:52:34 raspberrypi sSMTP[4484]: Creating SSL connection to host
                 Nov 25 17:52:34 raspberrypi sSMTP[4484]: SSL connection using RSA_AES_128_CBC_SHA1
                 Nov 25 17:52:34 raspberrypi sSMTP[4484]: Authorization failed (535 Authentication credentials invalid)

mail.err:    Nov 25 17:52:34 raspberrypi sSMTP[4484]: Authorization failed (535 Authentication credentials invalid)

mail.info:  Nov 25 17:52:34 raspberrypi sSMTP[4484]: Creating SSL connection to host
                 Nov 25 17:52:34 raspberrypi sSMTP[4484]: SSL connection using RSA_AES_128_CBC_SHA1
                 Nov 25 17:52:34 raspberrypi sSMTP[4484]: Authorization failed (535 Authentication credentials invalid)

[stephanr]

Irgendwie klappt die Authentifizierung nicht. Username und Passwort hast Du bestimmt schon überprüft, oder? Gegenprüfung wäre z. B. ein Login in das Webinterface.
SSMTP hat wohl auch einen Bug, wenn im Passwort das # Zeichen vorkommt.

If the '#' character appear anywhere in your password, and that you
put it in the /etc/ssmtp/ssmtp.conf file using the AuthPass option,
an empty password will be sent instead and the authentication will
fails with a message such as:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=544018

Vielleicht bist Du von dem Bug betroffen? Mit = und : gabs wohl auch mal Probleme. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=463196

[Gernott]

Hallo

Das ist mal eine nette Idee, danke. Es läuft auf Anhieb.
Nur mit dem notify habe ich meine Bedenken. Das sendet meines Erachtens bei jeder Battery:low Meldung eine E-Mail, unter Umständen alle paar Minuten. Eigentlich müßte man das auf eine einmalige Mail begrenzen, aber das würde dann wohl deutlich aufwendiger zu programmieren.

So wie hier erläutert: http://www.fhemwiki.de/wiki/E-Mail_per_notify_nach_Zeitablauf_erneut_senden
Oder mit DOIF, das erst nach einem Statuswechsel wieder eine Mail gesendet wird?

Gruß
G.

[stephanr]

Moin,

vielleicht kann man ein erneutes Senden folgendermaßen verhindern.

99_myUtils.pm erweitern um folgende Subroutinen.

Code Auswählen Erweitern


# Für jedes Device wird ein Wert im Hash hinterlegt. Im Notify kann die Ausfuehrung dann abhaengig vom Wert erfolgen. So ist es z. B. moeglich
# die mehrfache Notifikation per E-Mail zu verhindern.
sub batterynotifycontrol
{
my %batterynotify = ();


sub setbatterymailonce
{
my $name = shift;
my $value = shift;
$batterynotify{ $name } = $value;
}

sub getbatterymailonce
{
my $name = shift;
if (exists $batterynotify{$name}) {
  return $batterynotify{$name};
}
else {
return 0;
}
}

}


Die Ausführung des Notify abhängig vom Hash-Wert machen, der über die Subroutinen gesetzt/verändert wird. Bsp:

DEF

Code Auswählen Erweitern


.*:[Bb]attery:.* { if(($EVENT !~ m/ok/) && (getbatterymailonce("$NAME") == 0)) { ssmtpMail('vorname.nachname@gmail.com', 'FHEM Batteriewarnung', $NAME.': '.$EVENT);
    Log 3, "$NAME : Batteriewarnung $EVENT"; setbatterymailonce("$NAME",'1');
  }
}


Wenn der Zustand wieder "normal" wird muss natürlich der Hash-Wert wieder auf einen Wert geändert werden, der eine erneute Benachrichtigung erlaubt. Dazu könnte man ein zweites Notify bauen.

DEF

Code Auswählen Erweitern


.*:[Bb]attery:.* { if(($EVENT =~ m/ok/) && (getbatterymailonce("$NAME") != 0)) {setbatterymailonce("$NAME",'0') }}


Ich hoffe der Ansatz ist kein großer Quatsch. Ein Test mit "trigger wz_wandthermostat :battery: low" hat jedenfalls funktioniert und den gewünschten Erfolg von nur einer Mail erbracht.
Für eine wiederkehrende Benachrichtigung könnte ich mir auch vorstellen, dass man sich ein at definiert, dass den Hash-Wert in bestimmten Zeitintervallen zurücksetzt und so eine erneute Benachrichtigung erfolgen kann.

Gruß
Stephan

[Gernott]

Die Lösung ist elegant, finde ich. Nur eine Frage: Bleibt der hash nach einen fhem-Restart erhalten? Obwohl, wenn nicht ist es auch nicht weiter schlimm, da nur dann nochmal eine einmalige, neue Benachrichtigung verschickt würde. Damit kann man leben, denke ich.

Viele Grüße
G.

[stephanr]

Nach einem Neustart ist der Hash leer und es würde wieder einmalig zu einer Benachrichtigung kommen. Wenn man das verhindern will wird es für mich zu kompliziert 

Gruß
Stephan

[Gernott]

Nee, lass mal. Die eine Benachrichtigung kann man tolerieren. Danke für die Lösung. Werde es mal scharf schalten.

Gruß
G.

[Gernott]

Hallo

Habe vorhin zufällig gelesen, daß ssmtp die Mail verliert, wenn die Internetverbindung oder der externe Mailprovider down ist (http://www.tuksub.de/2015/03/homeserver-27-mailversand-ueber-postfix-einrichten/).
Deswegen habe ich gerade mal ssmtp durch postfix ersetzt. Wenn man der verlinkten Anweisung folgt, sind keine Änderungen in fhem erforderlich.

Gruß
G.