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

[Loredo]

Im morgigen Update ist eine neue Version des Moduls 76_MSGMail enthalten, die zum einen Blocking_Call verwendet, um Emails direkt aus fhem heraus zu versenden (optional per SSL), zum anderen aber auch eine Perl Funktion bietet, um dies zu tun:

Ich schau mal, wie ich das verwerten kann. Die Behandlung von E-Mail unterscheidet sich davon wie sonst Nachrichten zugestellt werden. Das anders zu generalisieren, so dass sowohl ohne ein FHEM Device als auch mit einem FHEM Device Mails verschickt werden können (und ohne explizites FHEM Device gar noch aus einer Zahl unterschiedlicher Befehlsvorlagen zu wählen, womöglich noch pro Empfänger-Device und nicht nur global), erfordert einiges an Änderungen. Das lässt sich nicht so eben machen, aktuell fehlen mir Ruhe und Zeit.

Für die e-mail benutze ich Debianmail, das ist eine sub in 99_MyUtils.pm mit folgendem Aufruf:
$ret .= qx(sendEmail -f '$sender' -t '$rcpt' -u '$subject' -m '$text' -s '$provider' -xu '$konto' -xp '$passwrd' -o tls=no -o message-charset=utf-8);

Für E-Mail ist es derzeit auch so gedacht, dass man msgCmdMail entsprechend seiner lokalen Gegebenheiten selbst setzt. Obgleich für viele auch der Versand über einen lokal laufenden Mailserver, dessen Spooler einfach mittels dem Shell-Kommando "mail" befüllt wird, sicherlich out-of-the-box funktioniert. Mail ist da sehr viel spezieller und daher auch individuell zu betrachten.

Aber ich habe echt keine Ahnung wie ich das mit msgCmdMail so hinbiege das es funktioniert. Aus dem Thread gehts nicht eindeutig hervor, könntest Du evtl mal ein Beispiel machen?

Man hat generell die Wahl, ob man in ein msgCmd* Attribut einen FHEM-Befehl einträgt (egal ob set, get, whatever) oder Perl-Code.
FHEM Befehle kann man einfach direkt eintragen. Perl Code muss in geschweiften Klammern eingeschlossen sein. Das ist ja auch an ganz vielen anderen Stellen in FHEM so gehandhabt. Der Code wird dann per eval() ausgeführt.


Um eine Pushover Nachricht mit Parametern zu versenden muss man wissen, dass diese Parameter Pushover speziell sind. Alle speziellen Parameter (egal bei welchem Modul) können über Advanced Options am Ende eines jeden Nachrichtentextes übergeben werden. Einige Optionen sind bereits im Schema hinterlegt, aber man kann zusammen mit msgCmd* jedwede Platzhalter selbst pflegen und verwenden.


Hier ein Beispiel für einen Pushover Prio2 Alarm:

Code Auswählen Erweitern


msg push @rr_Ingolf 2 |Emergency ALARM| ALARM: Wohnungstür ist offen O[{"RETRY":30,"EXPIRE":3600,"Pushover_SOUND":"siren"}]



Im Schema sind Default-Werte für RETRY (120) und EXPIRE (600) hinterlegt, weshalb man die auch weglassen kann, sofern diese Werte genügen. Pushover_SOUND ist ja ohnehin optional und somit käme man auch komplett ohne die Angabe der Advanced Options aus.
Der entscheidende Parameter hier ist die Angabe der Priorität "2" direkt hinter dem Empfänger-Device. Also ohnehin ganz so wie es bei Pushover sein muss für diese Art der Nachricht.

[Loredo]

mir ist gerade aufgefallen, dass bei dem "screen" hinterlegten "XBMC" Befehlen etwas nicht stimmt:
...
Vor $timeout fehlt das "my".

Danke, habe ich korrigiert.

und beim Befehl

Code Auswählen Erweitern

fhem "set $dev msg $msg $timeout %XBMC_ICON%"
fehlt die Variable %TITLE%,  der Befehl sollte so aussehen:

Code Auswählen Erweitern

fhem "set $dev msg %TITLE% $msg $timeout %XBMC_ICON%"

Das XBMC Modul und/oder die XBMC Software selbst unterstützen keine Anzeige eines Titels. Wenn das der Fall ist, pflege ich das gerne nach.
Ansonsten gab es hier, hier und hier Diskussion zum Thema "was mache ich wenn ein Modul oder ein Gerät keinen Titel unterstützt". Die Quintessenz daraus ist, dass der Titel nicht einfach so in den Nachrichtenteil hinein kopiert wird. Wer das möchte, kann sich mit dem Attribut msgCmd* das Schema ja entsprechend selbst umbauen.

[Schlimbo]

Das XBMC Modul und/oder die XBMC Software selbst unterstützen keine Anzeige eines Titels. Wenn das der Fall ist, pflege ich das gerne nach.

Hallo Loredo, da liegst du falsch, das XBMC Modul unterstützt einen Titel
siehe Commandref:

Code Auswählen Erweitern

Messaging

    To show messages on XBMC (little message PopUp at the bottom right egde of the screen) you can use the following commands:
    set <XBMC_device> msg <title> <msg> [<duration>] [<icon>]
    The default duration of a message is 5000 (5 seconds). The minimum duration is 1500 (1.5 seconds). By default no icon is shown. XBMC provides three different icon: error, info and warning. You can also use an uri to define an icon. Please enclose title and/or message into quotes (" or ') if it consists of multiple words.

Um momentan Nachrichte an XBMC anzeigen zu können nutze ich das msgCmd Attribut:

Code Auswählen Erweitern

attr globalMsg msgCmdScreen set raspbmc msg "%TITLE%" "%MSG%" 5000 info

Gruß Schlimbo

[Loredo]

das XBMC Modul unterstützt einen Titel

Ah, danke. Hatte die Commandref nur schnell überflogen und es springt nicht direkt ins Auge, wie man Text und Titel voneinander trennen soll.
Pflege ich nach. Edit: Ist ergänzt und ab morgen im Update.

Um momentan Nachrichte an XBMC anzeigen zu können nutze ich das msgCmd Attribut:

Code Auswählen Erweitern

attr globalMsg msgCmdScreen set raspbmc msg "%TITLE%" "%MSG%" 5000 info

Das ist insofern nicht ganz richtig, als dass du damit immer fix an raspbmc verschickst und somit eine Menge der Routing-Funktionen nicht funktionieren. Deshalb muss es richtig heißen:

Code Auswählen Erweitern


attr globalMsg msgCmdScreen set %DEVICE% msg "%TITLE%" "%MSG%" 5000 info



Edit:

Übrigens würde es noch mehr Sinn machen das Attribut einem Gateway-Device direkt zuzuweisen. Indem man global das msgCmdScreen Attribut setzt, kann man nämlich sonst keinerlei andere Geräte vom Typ "screen" mehr adressieren.

Clever wäre deshalb:

Code Auswählen Erweitern


attr raspbmc msgCmdScreen set %DEVICE% msg "%TITLE%" "%MSG%" 5000 info


Nachrichten werden dann mit "msg screen @raspbmc Text 123" verschickt. Oder eben an jedes andere Device, welches ein entsprechendes msgContactScreen Attribut hat, welches dann auf "raspbmc" verweist.
Wenn man auch einfach nur "msg screen Text 123" schreiben können will (also das Device weglassen), dann muss das msgContactScreen Attribut natürlich für globalMsg gesetzt sein. Um dein Szenario also vermutlich ganz richtig nachzustellen fehlt dann noch dies hier:

Code Auswählen Erweitern


attr globalMsg msgContactScreen raspbmc




Gruß
Julian

[Schlimbo]

Es funktioniert, jetzt kommen die Nachrichten auch ohne eine eigenes "msgCmdScreen" an XBMC an.
Danke für die Anpassung und die Ausführliche Erklärung, jetzt wird einiges klar.

Gruß
Schlimbo

[aherby]

So etwas ist sehr modulspezifisch und wird daher über die hier schon früher erwähnten Advanced Options gemacht.
Du kannst dafür am Ende deiner Nachricht ein JSON mit Variablen anhängen, welche vom Schema (siehe "get globalMsg routeCmd") unterstützt wird oder welche du selbst in einem msgCmd* Attribut verwendest. Für eine Sonos Nachricht sieht das dann zB so aus:

Code Auswählen Erweitern


msg audio @Sonos_Bedroom |Hint| Gute Nacht! O[{"VOLUME":"8"}]


Hallo Julian,

danke für den oben genannten Hinweis. Diese Lautstärkeänderung haben ich auch gerade probiert.
Wobei mir folgendes bei meiner Soundbar / Playbar aufgefallen ist:

Code Auswählen Erweitern


msg audio @Sonos_Wohnzimmer Hallo Welt O[{"VOLUME":"8"}]

spiele den Text in der Lautstärker ,, 8" ab.
Ein

Code Auswählen Erweitern


msg audio @Sonos_Wohnzimmer Hallo Welt O[{"VOLUME":"9"}]

jedoch erhöht die Lautstärke nicht um eins sonder auf ,,38". Und

Code Auswählen Erweitern


msg audio @Sonos_Wohnzimmer Hallo Welt O[{"VOLUME":"10"}]

scheinbar auch auf ,,38".

Habe ih hier wieder ein Schicht 8 -Fehler gemacht oder kannst du es mir erklären?

Danke

Gruß Alex

[Loredo]

Der Wert 38 ist der im msg-Schema hinterlegte Standard-Lautstärkewert. Der wird immer dann genommen, wenn keine Volume Angabe gemacht wurde oder diese nicht erkannt wurde. Letzteres ist in deinem Fall ziemlich sicher so. Ich kann in deinen Posts sehen, dass du die falschen Hochkomma nimmst und daher wird das JSON ungültig. Eine entsprechende Meldung darüber sollte im Logfile auftauchen, wenn du das verbose-Attribut hoch genug gesetzt hast.


Die richtigen Hochkomma sind " oder '. Bei Zahlen kann man die Hochkomma auch weglassen.


Hier zum Vergleich:


geht:

Code Auswählen Erweitern


msg audio @Sonos_Bedroom |Hint| Gute Nacht! O[{"VOLUME":"8"}]
msg audio @Sonos_Bedroom |Hint| Gute Nacht! O[{'VOLUME':'8'}]



geht auch:

Code Auswählen Erweitern


msg audio @Sonos_Bedroom |Hint| Gute Nacht! O[{"VOLUME":8}]
msg audio @Sonos_Bedroom |Hint| Gute Nacht! O[{'VOLUME':8}]


geht nicht:

Code Auswählen Erweitern


msg audio @Sonos_Bedroom |Hint| Gute Nacht! O[{"VOLUME":"8"}]


[raimundl]

Hallo Danke!!!

Bin noch ziemlich unerfahren, habe jedoch auf Anhieb nach Studium dieses Threads sowohl "DebianMail" als auch "WhatsApp" konfigurieren können - und es funktioniert auch.

Der Defaultwert ist "push" - ohne Angabe wird bei mir eine "WhatsApp" Nachricht versendet (Images kann man noch nicht versenden?). Bei Angabe von "mail" in der Befehlszeile eine Mail.

Kann man auch mehrere Pushdienste verwenden (WhatsApp, Pushover ...)?
Was ist die Funktion "msgType" bei den Attributen?

Nochmals Danke und LG

[Loredo]

Hallo Danke!!!

Hallo Bitte ))

Der Defaultwert ist "push" - ohne Angabe wird bei mir eine "WhatsApp" Nachricht versendet

Genauer gesagt wird eine Nachricht vom Typ "text" verschickt. "Text" entscheidet dann variabel zwischen Push und E-Mail, je nachdem was konfiguriert ist und wie die Priorität der Nachricht ist. Meist kommt aber "push" dabei heraus bzw. wenn man eh nur Push konfiguriert hat, dann natürlich ausschließlich push.
Push wird so gut wie immer bevorzugt. Nur bei niedrig priorisierten Nachrichten (also niedriger als im Attribut msgThPrioTextNormal angegeben, Default ist -2) wird per E-Mail verschickt. Gleichwohl werden hoch priorisierte Nachrichten (höher/gleich $prioThresTextEmergency, Default ist 2) sowohl per Push als auch zusätzlich per E-Mail verschickt. Dies greift wie gesagt aber nur, wenn man als Typ "text" angibt, nicht wenn man "push" oder "mail" direkt als Typ angibt.

(Images kann man noch nicht versenden?).

Wenn das WhatsUp Modul das kann, schon. Muss man sich dann ggf. selbst über die Anpassung des Schemas im msgCmdPush Attribut konfigurieren (ggf. in Kombination mit den Advanced Options O[{}] ); das Handwerkszeug dafür sollte da sein.
Der Hauptzweck für den msg-Befehl ist Text zu handhaben. Wenn aber ein allgemein gültiges Schema definierbar ist, bei dem Anhänge optional möglich sind, übernehme ich das gerne mit ins Standard-Schema.

Kann man auch mehrere Pushdienste verwenden (WhatsApp, Pushover ...)?

Ja, dafür ist der msg-Befehl gemacht. Man kann im Befehl selbst mehrere Empfänger getrennt durch Komma angeben oder natürlich in den msgContact* Attributen.
Bei der Angabe im msg-Befehl kann man auch unterschiedliche Typen mischen und mehrere Empfänger angeben (beides einfach mit Komma getrennt angeben).

Was ist die Funktion "msgType" bei den Attributen?

Mit dem Attribut msgType kann man den Standardwert festlegen, wenn über den msg-Befehl kein Typ angegeben wurde. Standardwert ist wie oben gerade beschrieben "text". Das kann man hier ändern und somit über Attribute die Zustellart beeinflussen statt diese in jedem msg-Kommando einzeln anzugeben. Je nach Umfang der Benachrichtigungen, die über ein FHEM Device abgewickelt werden, kann das sinnvoll sein, um es zentral ändern zu können (z.B. weil man anfänglich alles über mail machen möchte, später jedoch auf push umstellen will o.ä.).

[raimundl]

Danke für die ausführliche Antwort!

Ich werde nun tiefer eintauchen.

LG

[karl0123]

Was ist zu tun, wenn beim Versuchen den msg zu Befehl zu verwenden, folgende Meldung kommt?

Code Auswählen Erweitern

Unknown command msgconfig, try help.

Hängt es damit zusammen, dass es im FHEM die Funktion gibt, einen Befehl abgekürzt zu verwenden (z.B. u für update) und hier falsch statt auf msg, versucht wird, auf msgConfig zu routen? Was muss mindestens konfiguriert werden, um Text Nachrichten versenden zu können (TelegramBot)?

[justme1968]

hallo loredo,

ich hätte einen vorschlag für eine funktionalität

für manche nachrichten ist es nicht unbedingt sinnvoll sie anzuzeigen/abzuspielen wenn niemand im haus ist und es ist auch nicht hilfreich sie dann nach unterwegs weiter zuleiten.

hier wäre es praktisch die nachrichten so lange 'aufzuheben' bis der erste wieder zuhause ist und sie dann abzuspielen. vielleicht gibt es auch noch andere sinnvolle bedingungen.

ein beispiel wäre eine spülmaschine ist fertig meldung. wenn keiner da ist kann keiner die tür aufmachen, von unterwegs auch nicht und wenn man nach hause kommt hat man die meldung von unterwegs vermutlich schon vergessen. kurz nach dem haustür öffnen ist aber ein guter zeitpunkt.

für die spülmaschine habe ich das zur zeit von hand so gebaut. normaler geht die nachricht an die sonos player, wenn es in abwesenheit eine nachricht gibt wird sie erst beim öffnen der tür und nur direkt am tablet das dort montiert ist abgespielt.

wenn so etwas direkt zentral msg modul möglich wäre würde das das erweitern auf andere nachrichten sehr vereinfachen

gruss
  andre

[CoolTux]

Hallo,

Diesem Wunsch möchte ich mich sehr gerne anschließen.


Danke

[CoolTux]

Ist bisschen frech, aber darf ich kurz herauf aufmerksam machen?


https://forum.fhem.de/index.php/topic,19040.msg447277.html#msg447277



Grüße
Leon

[Loredo]

für manche nachrichten ist es nicht unbedingt sinnvoll sie anzuzeigen/abzuspielen wenn niemand im haus ist und es ist auch nicht hilfreich sie dann nach unterwegs weiter zuleiten.

hier wäre es praktisch die nachrichten so lange 'aufzuheben' bis der erste wieder zuhause ist und sie dann abzuspielen. vielleicht gibt es auch noch andere sinnvolle bedingungen.

Ja find ich gut, stand auch schon auf der Liste. Komm ich grad nur nicht zu das genauer auszukaspern. Wird also eine Weile dauern.
Aber vielleicht kannst du mir schonmal sagen, wie ich die Queue-Daten dann am klügsten FHEM-konform persistent abspeichere




PS: freue mich ja, wenns endlich mal jemand der Entwickler auch verwendet