Neuer FHEM Befehl "msg" für Benachrichtigungen (Push,Mail,Audio,Light,Screen)

[r_knipp]

Hi,

ich habe mich mal mit dem neuen Befehl auseinandergesetzt.
Habe doch ne ganze Zeit gebraucht bis ich alles verstanden habe.
Habe jetzt noch ein paar Fragen dazu.

Wofür sind die Attribute msgTh... im Device globalMSG?

Wie kann ich das Timeout einer Nachricht auf meine VUUno ändern und ist es richtig, dass ENIGMA2 kein Title unterstützt?

Wie kann ich das retry Intervall einer Pushover Nachricht mit Prio 2 ändern?

Gruß
Robert

[kjmEjfu]

Dabei sei nochmals erwähnt, dass man das msgCmd Attribut nicht nur global setzen kann, sondern es auch per userattr direkt einem Gateway Device zuweisen kann. Jeden FHEM Device kann man somit dann individuell ein Benachrichtigungs-Schema zuweisen. Ist das Schema einmal definiert, kann man den msg-Befehl überall in gleicher Art und Weise verwenden (eben mit Ausnahme der Optionen, die dann eben nur bei den Modulen berücksichtigt werden können, welche diese Option auch unterstützen bzw. in deren Schema-Definition diese auch verwendet werden).

Wie funktioniert das denn mit dem msgCmd im userattr eines Devices?

Also in der globalMsg habe ich definiert

Code Auswählen Erweitern

msgContactPush
pushmsg

nun möchte ich in einem Device aber yowsup nutzen. Von daher müsste ich das msgCmdPush im userattr dieses Devices anpassen. Aber was trage ich dort exakt ein bzw. wie nutze ich jetzt die Schema-Definition dafür?

Danke schon mal,
Ejfu

[Schlimbo]

Hallo Loredo,
ich bin jetzt mal dazu gekommen, mein Konfiguration von der "99_msg" Version auf die aktuelle umzustellen.
Das hat soweit auch auf Anhieb geklappt, beim Absetzen des erstem msg Befehls wurde das Device "globalMSG" automatisch angelegt, dann müsste ich nur die früheren "global msg.."  Attribute in "globalMSG msg.." umbenennen.

Habe aber auch einige "msgCMD" Kommandos in meiner Konfiguration:

Code Auswählen Erweitern

attr globalMsg msgCmdScreen set SATReceiver msg info 5 $MSG;;set raspbmc msg "$TITLE" "$MSG" 5000 info
attr globalMsg msgCmdScreenHigh set SATReceiver msg attention 5 $MSG;;set raspbmc msg "$TITLE" "$MSG" 5000 info
attr globalMsg msgCmdScreenLow set SATReceiver msg message 5 $MSG;;set raspbmc msg "$TITLE" "$MSG" 5000 info

Bei diesen werden seit der Umstellung die Variablen $MSG und $TITLE nicht mehr aufgelöst. Ändere ich diese in %MSG% und %TITLE% funktioniert es wieder. Ist das so gewollt?

[Loredo]

Wofür sind die Attribute msgTh... im Device globalMSG?

Es wird kompliziert, daher ist das auch noch nicht beschrieben 
Ich würde nur empfehlen diese Einstellungen zu ändern, wenn man wirklich genau verstanden hat, welche Auswirkung das hat. Damit niemand sagen kann er würde bei irgendetwas "bevormundet" werden, gibt es diese Einstellungen für die ganz Harten:


Darüber lässt sich eine Menge des Routing Verhaltens beeinflussen (wenn man das möchte). Die Routing Berechnung besteht nicht nur daraus, welche Routen für die Zustellung der Nachricht zur Verfügung stehen, sondern auch mit welcher Priorität die Nachricht verschickt wird. Deshalb gibt es bestimmte Schwellenwerte für die Priorität, ab der ein anderes Verhalten greift. Diese Schwellenwerte kann man hier anpassen.


Über msgThPrioText* lässt sich das Routing Verhalten für Nachrichten mit dem Typ "text" beeinflussen:

   
• msgThPrioTextEmergency sagt, ab wann eine Nachricht vom Typ "text" in die Prioritäts-Kategorie "emergency" eingeordnet wird. Ist das der Fall, werden Nachrichten sowohl als Push als auch als Mail zugestellt (natürlich nur, wenn für Push und/oder Mail ein entsprechender Kontakt ermittelt werden konnte). Es wird das Kommando-Schema aus msgCmd[Push|Mail]High für die Zustellung der Nachricht verwendet verwendet (bzw. das entsprechende Äquivalent aus der Schema-Datenbank). Standard ist ab Prio 2.
• msgThPrioTextNormal sagt, ab wann eine Nachricht vom Typ "text" bevorzugt per Push statt E-Mail zugestellt werden soll. Es wird das Kommando-Schema aus msgCmd[Push|Mail] für die Zustellung der Nachricht verwendet verwendet (bzw. das entsprechende Äquivalent aus der Schema-Datenbank). Standard ist ab Prio -2.
• Ist die Nachrichten Priorität niedriger als in msgThPrioTextNormal, wird das Kommando-Schema aus msgCmd[Push|Mail]Low für die Zustellung der Nachricht verwendet.

Über msgThPrioAudio* lässt sich das Verhalten für das Routing von Audio Nachrichten beeinflussen:

   
• msgThPrioAudioEmergency sagt, ab wann eine Audio Nachricht in die Prioritäts-Kategorie "emergency" eingeordnet wird. Ist das der Fall, werden Nachrichten auf jeden Fall in ganzer Länge abgespielt, egal ob über msgSwitcherDev ein Switcher-Device definiert wurde und dies auf off oder short steht. Es wird das Kommando-Schema aus msgCmdAudio für die Zustellung der Nachricht verwendet verwendet (bzw. die entsprechende Äquivalenz aus der Schema-Datenbank). Standard ist ab Prio 2.
• msgThPrioAudioHigh sagt, ab wann eine Audio Nachricht in die Prioritäts-Kategorie "high" eingeordnet wird. Ist das der Fall, wird das Kommando-Schema aus msgCmdAudioShortPrio für die Zustellung der Nachricht verwendet verwendet (bzw. die entsprechende Äquivalenz aus der Schema-Datenbank), sofern es ein msgSwitcherDev gibt und es auf "short" steht. Standard ist ab Prio 1.
• Ist die Nachrichten Priorität niedriger als in msgThPrioAudioHigh, wird das Kommando-Schema aus msgCmdAudioShort für die Zustellung der Nachricht verwendet (bzw. die entsprechende Äquivalenz aus der Schema-Datenbank), sofern es ein msgSwitcherDev gibt und es auf "short" steht.

Über msgThPrio* lässt sich beeinflussen, wie eine Nachricht in die Prioritäts-Kategorien High, Normal und Low eingeordnet wird (ausgenommen Nachrichten vom Typ Audio und Text, deren Handhabung besonders ist und oben bereits beschrieben wurde). Darüber wird dann entscheiden, welches Kommando-Schema greift und woher z.B. Standard Betrefftexte kommen:

   
• msgThPrioHigh sagt, ab wann eine Nachricht der Prioritäts-Kategorie "high" zugeordnet wird. Ist das der Fall, greifen msgCmd[Light|Mail|Push|Screen]High und msgTitle[Light|Mail|Push|Screen]High (bzw. die entsprechenden Äquivalenzen aus der Schema-Datenbank). Standard ist ab Prio 2.
• msgThPrioNormal sagt, ab wann eine Nachricht der Prioritäts-Kategorie "normal" zugeordnet wird. Ist das der Fall, greifen msgCmd[Light|Mail|Push|Screen] und msgTitle[Light|Mail|Push|Screen] (bzw. die entsprechenden Äquivalenzen aus der Schema-Datenbank). Standard ist ab Prio 0.
• Ist die Nachrichten Priorität niedriger als in msgThPrioNormal, greifen msgCmd[Light|Mail|Push|Screen]Low und msgTitle[Light|Mail|Push|Screen]Low (bzw. die entsprechenden Äquivalenzen aus der Schema-Datenbank).

Über msgThPrioGwEmergency lässt sich beeinflussen, ab wann eine Nachricht an ein Device mit erkanntem Anwesenheitsstatus in jedem Fall zugestellt werden soll (also Devices mit Readings wie presence oder einem Status "absent", "gone"). Das kann sein: Device/Bewohner ist DISABLED oder ABWESEND oder SCHLÄFT. Standard Prio ist hier 2. Normalerweise würde die Nachricht nicht zugestellt, wenn der Bewohner abwesend ist oder schläft. Mit einer Nachrichten Priorität ab <msgThPrioGwEmergency> wird der Status aber ignoriert. Das ganze greift allerdings nicht bei den Nachrichten Typen Push oder Mail (und somit auch Text), denn es wird angenommen, dass Textnachrichten eben "geduldig" sind und nicht stören (bei Push gibts an den Endgeräten ja entsprechende Silence/DND-Einstellungen).

[Loredo]

Wie kann ich das Timeout einer Nachricht auf meine VUUno ändern und ist es richtig, dass ENIGMA2 kein Title unterstützt?

Wie kann ich das retry Intervall einer Pushover Nachricht mit Prio 2 ändern?

Das geht beides über Advanced Options. Diese lassen sich derzeit nur pro jeweiliger Nachricht mit angeben und (noch) nicht zentral über ein Attribut hinterlegen.
Die Advanced Options unterscheiden sich je nach Modul, über das die Nachricht zugestellt wird. Daher ist das Namensschema hier noch nicht 100% klar, da einige Optionen modulübergreifend funktionieren und andere aber je nach Modul ganz speziell sind. Ich erhoffe mir ja hier nun entsprechend erweitertes Feedback, damit sich hier eine gute Vorgehensweise herauskristalisiert und man festlegen kann, welche Optionen nach dem Schema <MODULNAME>_<OPTION> benannt werden müssen und welche universell als <OPTION> für mehrere Module ohne Probleme verwendet werden können. Dabei spielen Gedanken wie z.B. der Zahlenraum eine Rolle (-> ist eine Angabe in Sekunden, oder Minuten etc.). Einige Werte kann man sicherlich auch pro Modul umrechnen (zB Zeiten immer in Sekunden angeben und wenn ein Modul es als Minuten braucht entsprechend in Minuten umrechnen). Das kann man derzeit in msgCmd* über {...} selbst machen, ich bin aber für die Schema Datenbank noch nicht sicher, ob ich das nicht noch etwas anders umsetzen wollen würde. Hängt aber wie gesagt davon ab, wie sich das hier mit der Nutzung der Advanced Options entwickelt. Ziel wäre es über den msg-Befehl möglichst alle Module über eine möglichst einheitliche Syntax ansprechen zu können und alle Module miteinander in einem einzigen Befehl vermischen zu können. (Übrigens kann man den msg-Befehl somit auch ganz einfach direkt ohne setzen von Attributen einfach nur als Alias-Befehl zu den anderen Modulen benutzen, einfach damit man eine gemeinsame Syntax hat und sie nicht bei jedem Modul wieder anders ist).


Welche Advanced Options ein Modul unterstützt, kann man derzeit in der Schema Datenbank einsehen (geht über das globalMsg Device per get Befehl).


Um Advanced Options bei einer Nachricht mit anzugeben, wird an das Ende der Nachricht ein JSON Container mit den Variablen und deren Werten angegeben. Damit der Container richtig erkannt wird, muss der Buchstable O für "Option" noch davor. Hier Beispiele bezogen auf deine Fragen:

Code Auswählen Erweitern


# setzt das Timeout auf 20 Sekunden statt der
# prioritätsabhängigen Definition aus der Schema-Datenbank
msg screen @ENIGMA2Device |Betreff| Nachrichtentext O[{"TIMEOUT":20}]


# setzt RETRY auf 60 Sekunden und EXPIRE auf 1800 Sekunden
msg push @PushoverDevice 2 |Warnung| Nachrichtentext O[{"RETRY":"60","EXPIRE":"1800"}]



Was passiert da: Im Grunde werden alle KEY/VALUE Paare aus dem JSON in den Kommando-Schemata (also entweder aus msgCmd* oder der Schema-Datenbank) in der Form %NAME% gesucht und durch den Wert aus den Advanced Options ersetzt. Man kann also damit auch sein eigenes msgCmd-Kommando mit beliebigen Platzhaltern erweitern. Die Standardwerte aus der Schema-Datenbank stehen immer dann zur Verfügung, wenn das FHEM Modul dort unterstützt wird und über die Advanced Options keine anderen Angaben gemacht worden sind. Für einige Module ist die Angabe von Advanced Options teilweise notwendig, wenn es eine sehr spezielle Syntax hat. Auch muss man Teilweise die Werte als "KEY":"'VALUE'" (man beachte die zusätzlich ' innerhalb der ") angeben, weil es das jeweilige Modul in seiner Syntax vielleicht so braucht. Es wird hier wie gesagt einfach nur gesucht und ersetzt, man muss eben das jeweilige Modul genau genug dafür kennen. Bei Pushover trifft das z.B. auf die optionalen Parameter URLTITLE und ACTION zu.

[Loredo]

Wie funktioniert das denn mit dem msgCmd im userattr eines Devices?

Also in der globalMsg habe ich definiert

Code Auswählen Erweitern

msgContactPush pushmsg

nun möchte ich in einem Device aber yowsup nutzen. Von daher müsste ich das msgCmdPush im userattr dieses Devices anpassen. Aber was trage ich dort exakt ein bzw. wie nutze ich jetzt die Schema-Definition dafür?

Dann gibst du einfach bei dem Device im msgContactPush Attribut eben "yowsup:EMPFAENGER" ein.
Du hast bisher vermutlich Nachrichten ohne Empfänger angegeben, sprich also "global" über den Fallback auf globalMsg. Das sollte aber eher die Ausnahme sein. Die Regel ist, dass du beim msg-Befehl einen Empfänger mittels @device angibst und dort bei dem Device dann ein msgContact Attribut hinterlegt ist. nur Wenn dort keins gefunden wird und du trotzdem bei globalMsg ein msgContact Attribut hinterlegt hast, wird die Nachricht stattdessen dort mit dem Vermerk "catchall" zugestellt (der Vermerk entfällt, wenn man direkt an @globalMsg schickt oder gar keinen Empfänger beim msg-Kommando angegeben hatte).

Generell für yowsup gibt es bereits ein hinterlegtes Schema in der Datenbank, welches du nicht zwangsweise anpassen musst:

Code Auswählen Erweitern


get globalMsg routeCmd push yowsup


PUSH: DEFAULT COMMANDS
-------------------------------------------------------------------------------
yowsup
  Priority Normal:
  set %DEVICE% send %RECIPIENT% %TITLE%: %MSG%
  Priority High:
  set %DEVICE% send %RECIPIENT% %TITLE%: %MSG%
  Priority Low:
  set %DEVICE% send %RECIPIENT% %TITLE%: %MSG%


Man kann also in dieser Form bereits fix und fertig eine Nachricht per WhatApp verschicken:

Code Auswählen Erweitern


msg push @yowsupDevice:EMPFAENGER |Betreff| Nachrichtentext


Das mit der msgCmd Anpassung funktioniert so:

Wenn etwas an ein FHEM-Device per msg-Kommando geschickt wird, dann wird dort zunächst nach den Attributen msgContact* gesucht. Ist das passende Attribut vorhanden, werden die Angaben darin als die Ziel-Gateways, über die die Nachricht verschickt werden soll, verwendet. Gibt es diese Attribute nicht, wird nach msgRecipient* gesucht und wenn vorhanden, bei den dort hinterlegten Devices nach msgContact* gesucht. Wird auch hier nichts gefunden, dann wird noch geschaut, ob das FHEM Empfänger Gerät, welches beim msg-Befehl als Empfänger angegeben wurde, ein in der Schema Datenbank bekanntes Device ist und es diesen Nachrichtentyp auch direkt verarbeiten könnte. Ist das der Fall, wird dieses Gerät selbst als Ziel-Gateway für die Nachrichtenübermittlung hergenommen.

So, nun haben wir also das Ziel-Gateway. Aber in welchem Format das Gateway jetzt angesprochen werden soll, hängt davon ab was für ein TYPE es ist, sprich also was für ein Modul-Typ dieses Device verwendet. Um jetzt das richtige Kommando-Schema zu finden wird zunächst beim Ziel-Gateway direkt nach einem msgCmd* Attribut geschaut. Ist es vorhanden, wird es für die Zustellung der Nachricht verwendet. Ist es nicht vorhanden, wird beim globalen Device (meist heißt es "globalMsg", wenn es nicht umbenannt wurde) nach einem msgCmd* Attribut geschaut. Wird es gefunden, wird es verwendet. Wird auch hier nichts gefunden, dann wird auf die Schema-Datenbank zurückgegriffen. Erst wenn hier nichts hinterlegt ist, gibt es den Fehler, dass das Modul vom msg-Befehl nicht unterstützt wird. Dann kann man mir entweder eine allgemein gültige Definition schicken, die ich dann in die Schema-Datenbank aufnehmen kann, oder man definiert eben ein entsprechendes msgCmd-Attribut.

Ein msgCmd-Attribut selbst zu definieren kann man wie oben gerade beschrieben eben an zwei Stellen tun:

   
• global am Device globalMsg. Dort sind die Attribute auch schon sichtbar.
• Manchmal möchte man aber für den selben Nachrichten-Typ unterschiedliche Module gleichzeitig verwenden. Dann passt eine globale Definition aber nicht mehr, denn sie passt dann ja nur für eine der zu verwendenden Module. Also muss das msgCmd Attribut am jeweiligen Gateway Device selbst gesetzt werden, damit es sozusagen sein eigenes Schema dem msg-Kommando bekannt machen kann. Das Attribut ist dort aber nicht eingeblendet, weil es sonst bei sämtlichen FHEM Devices auftauchen würde, obwohl man es dort zu 99% gar nicht braucht. Deshalb legt man bei dem jeweiligen Gateway Device zunächst ein userattr-Attribut an, in dem dann das entsprechende msgCmd* Attribut aufgeführt wird, an. Anschließend kann man dann das msgCmd Attribut direkt am Gateway Device konfigurieren. Das ist eigentlich FHEM-Standardwissen (bzw. sollte es sein  )

[Loredo]

ich bin jetzt mal dazu gekommen, mein Konfiguration von der "99_msg" Version auf die aktuelle umzustellen.
Das hat soweit auch auf Anhieb geklappt, beim Absetzen des erstem msg Befehls wurde das Device "globalMSG" automatisch angelegt, dann müsste ich nur die früheren "global msg.."  Attribute in "globalMSG msg.." umbenennen.

Genau.

Habe aber auch einige "msgCMD" Kommandos in meiner Konfiguration:

Code Auswählen Erweitern

attr globalMsg msgCmdScreen set SATReceiver msg info 5 $MSG;;set raspbmc msg "$TITLE" "$MSG" 5000 infoattr globalMsg msgCmdScreenHigh set SATReceiver msg attention 5 $MSG;;set raspbmc msg "$TITLE" "$MSG" 5000 infoattr globalMsg msgCmdScreenLow set SATReceiver msg message 5 $MSG;;set raspbmc msg "$TITLE" "$MSG" 5000 info Bei diesen werden seit der Umstellung die Variablen $MSG und $TITLE nicht mehr aufgelöst. Ändere ich diese in %MSG% und %TITLE% funktioniert es wieder. Ist das so gewollt?

Ja. Die Notation hat sich geändert. War ja alles vorher noch im Entstehen 

Übrigens kann man das so machen, wie du das machst. Gedacht ist es allerdings eher so, dass man beim Adressieren mehrerer Geräte diese entsprechend im msgContactScreen (in deinem Fall) mit Komma getrennt angibt (also z.B. eben "SATReceiver,raspbmc"). Da sowohl ENIGMA2 als auch XBMC inzwischen in der Schema Datenbank drin sind, könntest du auf die msgCmdScreen Angaben sogar gänzlich verzichten. Für das Anpassen der Timeout-Werte könntest du die weiter oben gerade beschriebenen Advanced Options verwenden. Ein msgCmdScreen Attribut ist für dich eigentlich nur noch notwendig, wenn du die Timeouts nicht in der Nachricht mit angeben, sondern zentral hinterlegen möchtest. Aber auch nur solange, bis ich die Advanced-Options als zentrales Attribut eingebaut habe (steht noch auf meiner Todo-Liste). 

[Loredo]

ist es richtig, dass ENIGMA2 kein Title unterstützt?

Ja, das ist von der ENIGMA2 API nicht vorgesehen.

[Schlimbo]

Danke für deine Antwort.
Ja, meine msgCmd stammen noch aus der Anfangszeit des Moduls, muss ich mal umstellen.

Ja. Die Notation hat sich geändert. War ja alles vorher noch im Entstehen 

Gibt es die Variante $DEVICE, $TITLE, $MSG, $PRIORITY jetzt nur noch bei msgCmdAudio? oder hast du deinen ersten Post nur noch nicht angepasst?

[Loredo]

Der Post ist da wohl noch nicht angepasst. Es ist überall %KEY%



Edit: Post angepasst.

[kjmEjfu]

Dann gibst du einfach bei dem Device im msgContactPush Attribut eben "yowsup:EMPFAENGER" ein.
Du hast bisher vermutlich Nachrichten ohne Empfänger angegeben, sprich also "global" über den Fallback auf globalMsg. Das sollte aber eher die Ausnahme sein. Die Regel ist, dass du beim msg-Befehl einen Empfänger mittels @device angibst und dort bei dem Device dann ein msgContact Attribut hinterlegt ist. nur Wenn dort keins gefunden wird und du trotzdem bei globalMsg ein msgContact Attribut hinterlegt hast, wird die Nachricht stattdessen dort mit dem Vermerk "catchall" zugestellt (der Vermerk entfällt, wenn man direkt an @globalMsg schickt oder gar keinen Empfänger beim msg-Kommando angegeben hatte).

Aaaah, so einfach ist das 
Mir war nur nicht klar, dass man so einfach im msgContactPush umswitchen kann. Aber so ist es ja genial!
Dann kann der Spaß nun los gehen 

Danke auch für die restliche Erklärung, sehr hilfreich fürs gesamte Verständnis.

Übrigens: vielleicht würde es vielen helfen, wenn man deine langen Erklärungstexte zu msg einfach auf eine Wiki-Seite kopiert. Dann findet man sie schneller als über die vielen Seiten dieses Threads verteilt (und die Anwendungsbeispiele im residents-Threads). Um sie "vergammeln" zu lassen, sind die Erklärung zu lang und detailiert.

Viele Grüße,
Ejfu

[Loredo]

Übrigens: vielleicht würde es vielen helfen, wenn man deine langen Erklärungstexte zu msg einfach auf eine Wiki-Seite kopiert. Dann findet man sie schneller als über die vielen Seiten dieses Threads verteilt (und die Anwendungsbeispiele im residents-Threads). Um sie "vergammeln" zu lassen, sind die Erklärung zu lang und detailiert.

Das wandert in erster Linie in die Commandref, die es noch zu schreiben gilt.


Es geht auch darum, dass ich vielleicht je nach Nutzerrückmeldung hier und dort noch Anpassungen vornehmen möchte oder muss. Daher möchte ich erst nach und nach alles fest zementieren, weil ggf. einige Änderungen später nur mit Schmerzen für Nutzer durchzuführen sind, die dann ihre Definitionen abändern müssen.

[kjmEjfu]

Das wandert in erster Linie in die Commandref, die es noch zu schreiben gilt.

Ich dachte auch eher an übergangsweise 

Btw: ich stolpere da gerade über ein unerwartetes Verhalten, bin mir aber nicht sicher, ob das an der msg-Syntax oder an fehlendem FHEM-Knowhow auf meiner Seite liegt.


Ich habe ein DOIF mit der Definition

Code Auswählen Erweitern

my_callmonitor:event:.connect
{
if(ReadingsVal("my_callmonitor","internal_connection","") eq "Answering_Machine_1")
{
fhem "msg push @Eltern |Telefon| Verpasster Anruf von  ".ReadingsVal("my_callmonitor","external_number","")." (".ReadingsVal("my_callmonitor","external_name","").")"
}
}

und im Logfile steht dann

Code Auswählen Erweitern

2015.11.15 15:05:01 1: PERL WARNING: Possible unintended interpolation of @Eltern in string at (eval 521) line 1.
2015.11.15 15:05:01 3: eval: {if(ReadingsVal("my_callmonitor","internal_connection","") eq "Answering_Machine_1") { fhem "msg push @Eltern |Telefon| Verpasster Anruf von  ".ReadingsVal("my_callmonitor","external_number","")." (".ReadingsVal("my_callmonitor","external_name","").")"}}
2015.11.15 15:05:01 3: FB_Anruf_verpasst_AB return value: Global symbol "@Eltern" requires explicit package name at (eval 521) line 1.

muss ich das @ irgendwie escapen?

[Spook112]

Hi,
ich habe versucht mittels des msg Befehls eine Mail aus FHEM zu verschicken - scheitere aber an einer Mailadresse, die das System aus welchem Grunde auch immer selbst vergibt:

Die Eingabe die ich im GUI gemacht habe ist die folgende:

msg mail webmaster@meine.domain Test Dies ist eine Testmail aus FHEM

Leider sendet mir exim4 daraufhin die Email an die Mailadresse fhem@servername zurück - mit dem Hinweis, dass die Adresse globalMsg@servername  nicht zustellbar ist.

Scheinbar wird die in der Kommandozeile eingegebene Mailadresse webmaster@meine.domain nicht an exim4 übergeben.

Hier die Mail die ich von exim4 zurück bekomme:

Code Auswählen Erweitern

root@servername:/opt/fhem/Maildir/new# more 1447599938.H373276P31097.servername
Return-path: <>
Envelope-to: fhem@servername
Delivery-date: Sun, 15 Nov 2015 16:05:38 +0100
Received: from Debian-exim by servername with local (Exim 4.80)
        id 1Zxys5-00085V-GI
        for fhem@servername; Sun, 15 Nov 2015 16:05:38 +0100
X-Failed-Recipients: globalMsg@servername
Auto-Submitted: auto-replied
From: Mail Delivery System <Mailer-Daemon@servername>
To: fhem@servername
Subject: Mail delivery failed: returning message to sender
Message-Id: <E1Zxys5-00085V-GI@servername>
Date: Sun, 15 Nov 2015 16:05:37 +0100

This message was created automatically by mail delivery software.

A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:

  globalMsg@servername
    Unrouteable address

------ This is a copy of the message, including all the headers. ------

Return-path: <fhem@servername>
Received: from fhem by servername with local (Exim 4.80)
        (envelope-from <fhem@servername>)
        id 1Zxys4-00085R-W0
        for globalMsg@servername; Sun, 15 Nov 2015 16:05:37 +0100
Date: Sun, 15 Nov 2015 16:05:36 +0100
To: globalMsg@servername
Subject: System Message
User-Agent: Heirloom mailx 12.5 6/20/10
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <E1Zxys4-00085R-W0@servername>
From: fhem@servername

Testemail Test Email aus FHEM

Auch das Logfile von exim4 zeigt nicht mehr als das an:

Code Auswählen Erweitern

2015-11-15 16:05:37 1Zxys4-00085R-W0 <= fhem@servername U=fhem P=local S=494
2015-11-15 16:05:37 1Zxys4-00085R-W0 ** globalmsg@servername <globalMsg@servername>: Unrouteable address
2015-11-15 16:05:38 1Zxys5-00085V-GI <= <> R=1Zxys4-00085R-W0 U=Debian-exim P=local S=1289
2015-11-15 16:05:38 1Zxys4-00085R-W0 Completed
2015-11-15 16:05:38 1Zxys5-00085V-GI => fhem <fhem@servername> R=local_user T=maildir_home
2015-11-15 16:05:38 1Zxys5-00085V-GI Completed

Noch ein Hinweis:
Im globalMsg Device habe ich die folgenden Attribute definiert (in der Annahme, dass das die defaultadresse sein könnte):
Attributes
comment   FHEM Global Configuration for command 'msg'
group        Global
msgRecipient   webmaster@meine.domain
msgRecipientMail    webmaster@meine.domain
msgRecipientText   webmaster@meine.domain
stateFormat     fhemMsgState
verbose     4

Hat jemand eine Idee woran es liegen könnte, dass FHEM diese falsche Mailadresse verwendet?
(Direkter Versand von Emails per comand line auf OS Ebene geht.)

[Loredo]

Ich habe ein DOIF mit der Definition...und im Logfile steht dann...muss ich das @ irgendwie escapen?

Das sieht mir eher nach einem Notify aus, keinem DOIF.
Dort könntest du dir den ganzen Perl-Kram nämlich sparen und bräuchtest das @ nicht escapen.
In Perl code möchte das @ als \@ geschrieben werden.

ich habe versucht mittels des msg Befehls eine Mail aus FHEM zu verschicken - scheitere aber an einer Mailadresse, die das System aus welchem Grunde auch immer selbst vergibt:

Du meinst den E-Mail Absender? Der resultiert daraus unter welchem Benutzer dein FHEM läuft und wie dein lokaler Mailserver konfiguriert ist. FHEM hat damit nichts zu tun.

msg mail webmaster@meine.domain Test Dies ist eine Testmail aus FHEM

Leider sendet mir exim4 daraufhin die Email an die Mailadresse fhem@servername zurück - mit dem Hinweis, dass die Adresse globalMsg@servername  nicht zustellbar ist.

Scheinbar wird die in der Kommandozeile eingegebene Mailadresse webmaster@meine.domain nicht an exim4 übergeben.

Du musst in deiner lokalen Mailserver Konfiguration dafür sorgen, dass eine FQDN (=voll qualifizierte Domain) als Absender-Adresse verwendet wird, statt nur fhem@servername. Laut Mail Statuten sollte das auch eine echte Domain sein, die entweder einen MX Record oder zumindest einen A/AAAA Record hat. Je nach Mailempfänger ist es auch notwendig, dass die resultierende IP-Adresse auch wieder einen damit übereinstimmenden PTR-Reverseintrag im DNS hat.


Woher bei dir der Empfänger globalMsg@servername als Bounce Empfänger kommt kann ich allerdings auch nicht sagen.
Wenn du beim globalMsg Device verbose=5 setzt kannst du beim erneuten ausführen deines Kommandos im Logfile sehen, welcher Befehl daraus generiert wird.

Im globalMsg Device habe ich die folgenden Attribute definiert (in der Annahme, dass das die defaultadresse sein könnte):
Attributes
comment   FHEM Global Configuration for command 'msg'
group        Global
msgRecipient   webmaster@meine.domain
msgRecipientMail    webmaster@meine.domain
msgRecipientText   webmaster@meine.domain
stateFormat     fhemMsgState
verbose     4

Das ist verkehrt. Finale Empfänger gibst du über die msgContact* Attribute an. E-Mail Adressen gehören in ein msgContactMail Attribut. In anderen msgContact* Attributen gehören nur FHEM Devicenamen.
Es hilft auch nichts einfach wild in allen möglichen Attributen eine Mailadresse einzutragen.


msgRecipient* ist dafür da, wenn man auf ein anderes FHEM Device verweisen möchte, welches den eigentlichen msgContact* Eintrag hat.

(Direkter Versand von Emails per comand line auf OS Ebene geht.)

Das kann ich mir jetzt nur schwer vorstellen, zumindest wenn du dort mails unter dem User "fhem" auch mit "echo text | mail webmaster@deinedomain.tld" verschickst.