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

Spook112 · 15 November 2015, 23:56:51

Hi Loredo,
danke erst mal für die Antworten.
Das der Mailversand von der OS Konsole geklappt hat kannst Du mir schon glauben

Ich habe aber Deinen Hinweis mit der FQDN im Mail-Absendernamen aufgegriffen und angepasst.

Inzwischen habe ich auch einen Weg gefunden, dass der Mailversand aus FHEM klappt.
Es lag an dem nicht definierten Mail Contact
Nachdem ich
msgContactMail webmaster@meine.domain
in globalMsg definiert hatte konnte ich auch aus der FHEM Comandline
msg mail Test
erfolgreich verschicken.

Mittels eines notify ging es dann beim Statuswechsel eines Fensterkontaktes so:
AZ_Fenster:basicSet:.* "echo "Fenster im Arbeitszimmer wurde geöffnet" | mail -s "FHEM Warnmeldung" -r "FHEM@@meine.domain" webmaster@@meine.domain"
Wichtig dabei waren die Anführungszeichen nach den Parametern -s und -r und die dopelten @-Zeichen in den Domain-Namen.

Vielleicht helfen die Infos ja jemandem

Nochmals danke und Gruß
Spook

Loredo · 15 November 2015, 23:59:27

Zitat von: Spook112 am 15 November 2015, 23:56:51
Mittels eines notify ging es dann beim Statuswechsel eines Fensterkontaktes so:
AZ_Fenster:basicSet:.* "echo "Fenster im Arbeitszimmer wurde geöffnet" | mail -s "FHEM Warnmeldung" -r "FHEM@@meine.domain" webmaster@@meine.domain"
Wichtig dabei waren die Anführungszeichen nach den Parametern -s und -r und die dopelten @-Zeichen in den Domain-Namen.

Das macht jetzt allerdings nicht viel Sinn, wenn du den msg Befehl benutzen willst.
Da lautet es, nachdem du ja das globale msgContactMail Attribut gesetzt hast, einfach nur

Code Auswählen


msg |FHEM Warnmeldung| Fenster im Arbeitszimmer wurde geöffnet

Loredo · 16 November 2015, 11:48:38

Im msgConfig Helper Modul gibt es inzwischen neben dem informativen Get-Befehl für die Einsicht in die Schema Datenbank noch einige Set-Befehle, die die Konfiguration vereinfachen sollen:

addLocation <Name der Lokation>
Damit wird ein Dummy-Device basierend auf dem Namen der Lokation angelegt und für die Nutzung mit dem msg-Befehl vorkonfiguriert und auch im globalen Attribut msgLocationDevs des globalMsg Devices registriert. Man muss dort dann nur noch die msgContact* Attribute entsprechend so setzen, wie man es für den jeweiligen Raum haben möchte (also zB welche Sonos Lautsprecher sich dort befinden -> msgContactAudio. Dreambox -> msgContactScreen. HUE Lampen -> msgContactLight).

Wenn man jetzt z.B. ein ROOMMATE Device hat (sprich einen Bewohner), dessen location-Reading über GEOFANCY und einem iBeacon ständig aktualisiert wird, wenn er/sie (bzw. das iPhone) sich in der Wohnung bewegt, und man dieser Person eine Audio Nachricht auf dem Lautsprecher ausgeben möchte, der in diesem Raum steht, dann kann man das in seiner Automations-Logik entweder immer mit vielen IF/ELSE Anweisungen lösen. Oder aber man nimmt den msg-Befehl und schickt einfach nur eine Nachricht an das ROOMMATE Device. Stimmt dort das Reading "location" mit dem Attribut "msgLocationName" aus einem der in msgLocationDevs angegebenen Dummy-Devices überein, so wird das msgContactAudio-Attribut aus dem Dummy-Device eben für diese Lokation genommen, um den richtigen Lautsprecher zu finden. Für die Automation ist das dann transparent, man schickt einfach nur seine Audio-Nachricht an das ROOMMATE Device ab und das wars.

Siehe auch "Follow-Me Funktion" im allerersten Post dieses Threads.

cleanReadings [<Devicename ggf mit Regex>]
Eine einfache Möglichkeit die fhemMsg* Readings innerhalb von FHEM aufzuräumen. Ohne Parameter werden alle Readings in allen Devices gelöscht, die mit fhemMsg anfangen.
Ist im Prinzip ein etwas flexiblerer Alias für "deletereading .* fhemMsg.*" und soll es einfach nur ermöglichen die Readings per Klick aufzuräumen, wenn man das nach viel probieren mal möchte.

createResidentsDev <language>
Erstellt ein RESIDENTS Device mit dem Namen rgr_Residents oder aktualisiert ein unter diesem Namen bereits vorhandenes Device und konfiguriert es in der angegebenen Sprache vor. Anschließend gibt es Hinweise was man als nächstes tun muss, um die automatische, Anwesenheits-basierte Steuerung des msg-Kommandos nutzen zu können.
Der nächste Schritt ist dabei dann das msgResidentsDev Attribut so zu setzen, dass es auf rgr_Residents zeigt. Das macht createResidentsDev hier nicht automatisch, weil es selten wirklich Klug ist das Attribut global im Device globalMsg zu setzen. Stattdessen sollte es bei einem dedizierten FHEM Device gesetzt werden, an welches man später auch Nachrichten adressieren möchte, welches jedoch selbst keine Anwesenheits-Readings/Stati bietet und man möchte, dass trotzdem die allgemeine Anwesenheit aller Bewohner berücksichtigt wird. Natürlich kann man in msgResidentsDev auch ein ROOMMATE Device angeben, wenn man nur die Anwesenheit einer speziellen Person berücksichtigen möchte. Dafür ist aber der set-Hilfsbefehl "createResidentsDev" nicht gedacht. Er soll auch nur einen rudimentären Einstieg bieten und einen auf den "richtigen" Pfad bringen.
Das anschließende anlegen von ROOMMATE Devices über den Set-Befehl im RESIDENTS Device ist nicht Teil des Hinweises.

createSwitcherDev <language>
Legt ein vorkonfiguriertes Dummy Device mit dem Namen HouseAnn an und verlinkt es im globalen Attribut msgSwitcherDev von globalMsg. Dieser Dummy ermöglicht es den Nutzern manuell darauf Einfluss zu nehmen, ob Audio-visuelle Nachrichten gerade in vollem Umfang "zugestellt" werden sollen oder nicht. Audio-Nachrichten beispielsweise werden dann zB nur mit den Short-Befehlen wiedergegeben statt mit dem Long-Befehl. Oder sie werden komplett unterdrückt und es wird versucht die Nachricht visuell (=per Typ 'light') zuzustellen. Bei "off" werden sämtliche audio-visuelle Nachrichten einfach unterdrückt. Es werden dann nur entsprechende Readings erzeugt, in deren Status man auch sieht, dass die Nachricht unterdrückt wurde.

Spook112 · 16 November 2015, 18:14:33

Hallo Loredo,
danke für die Antwort ...

Zitat von: Loredo am 15 November 2015, 23:59:27

Das macht jetzt allerdings nicht viel Sinn, wenn du den msg Befehl benutzen willst.
Da lautet es, nachdem du ja das globale msgContactMail Attribut gesetzt hast, einfach nur

Code Auswählen Erweitern
msg |FHEM Warnmeldung| Fenster im Arbeitszimmer wurde geöffnet

... ich verstehe das als Verbesserungsvorschlag oder anderen Weg zum Ergebnis zu kommen, eben mttels des msg Befehls statt über den "Umweg" Echo und mail.
Also statt:

Code Auswählen

AZ_Fenster:basicSet:.* "echo "Fenster im Arbeitszimmer wurde geöffnet" | mail -s "FHEM Warnmeldung" -r "FHEM@@meine.domain" webmaster@@meine.domain"

eben so:

Code Auswählen

AZ_Fenster:basicSet:.* msg |FHEM Warnmeldung| Fenster im Arbeitszimmer wurde geöffnet
Funktioniert (beides) prima.

Was für mich der entscheidende Vorteil war, dass ich es damit endlich geschafft habe die Variablen $NAME und $EVENT beim Auslesen der Batterie in einem zweiten Anwendungsfall zu verwenden und damit dann auch gleich eine Angabe über die verblieben Leistng der Baterie in % erhalte.

Code Auswählen

SZE_Fenster:battery:.* msg |FHEM Warnmeldung| Der Wert für die Batterie des Fensterkontaktes $NAME liegt bei: $EVENT

Auch das funktioniert so weit prima.
Was ich aber nicht hin kriege ist der Anwendungsfall, dass ich nicht bei jedem Auslesen (einmal pro Tag) eine Email bekomme, sondern nur dann, wenn der Batteriestand beispielsweise 40% oder weniger anzeigt.

Versuchsweise habe ich es mal mit:

Code Auswählen

SZE_Fenster:battery:100% msg |FHEM Warnmeldung| Der Wert für die Batterie des Fensterkontaktes $NAME liegt bei: $EVENT
versucht, aber da schickt FHEM keine Mail.

Hat jemand eine Idee was daran falsch ist und wie man es hinkriegen würde?
Als Test für 100% und als realen Anwendungsfall für kleiner/gleich 40%

Danke im Voraus für jegliche Tips.

Loredo · 16 November 2015, 23:10:29

Zitat von: Spook112 am 16 November 2015, 18:14:33
... ich verstehe das als Verbesserungsvorschlag oder anderen Weg zum Ergebnis zu kommen, eben mttels des msg Befehls statt über den "Umweg" Echo und mail.

Naja, der Punkt ist ja: Möchtest du dich in deiner Automation mit immer wiederholenden Kontaktangaben herumschlagen oder diese einmal zentral hinterlegen und auch nur dort ändern müssen? Der Code wird wesentlich übersichtlicher und besser wartbar.
Auch wenn du die anderen Features von msg nicht benutzt, zumindest diesen Vorteil hat man immer

Das war die Hauptintention dahinter.

Zitat von: Spook112 am 16 November 2015, 18:14:33
Was ich aber nicht hin kriege ist der Anwendungsfall, dass ich nicht bei jedem Auslesen (einmal pro Tag) eine Email bekomme, sondern nur dann, wenn der Batteriestand beispielsweise 40% oder weniger anzeigt.

Da fehlen dir jetzt wohl ein paar FHEM Grundlagen und ein paar Kenntnisse zu notify.
event-on-change-reading könnte dir hier weiterhelfen, ein DOIF kann das ggf. auch eleganter lösen (aber wohl aktuell noch nicht für mehrere Geräte über ein Regex, man muss alle als Oder-Verknüpfung angeben). Dort ließe sich auch das <40 mit einbauen.
Im Notify musst du das mit Perlcode in {} lösen und dabei den aktuellen Wert erst mit [AZ_Fenster:basicSet] (diese Schreibweise funktioniert nur in einem IF() oder DOIF()) auslesen und dann mit einem IF() vergleichen.

Hat jetzt aber weniger mit dem msg Kommando zu tun

RoBra81 · 20 November 2015, 14:41:49

Hallo,

da ich gerade etwas Zeit habe, dachte ich mir, ich probiere mal den neuen msg-Befehl aus. Leider komme ich gerade nicht weiter. Ich habe ein Device namens globalMsg vom Typ msgConfig angelegt. Dann habe ich als erstes versucht, eine WhatsApp-Nachricht mit einem yowsup-Device zu versenden. Im ersten Versuch habe ich dem ROOMMATE rr_Ronny das Attribute msgContactPush mit dem Inhalt WhatsApp.Ronny (ein yowsup-Device) gegeben und habe folgenden Befehl ausgeführt:

Code Auswählen

msg push @rr_Ronny 0 |Test| Nachricht

Ergebnis im Log:

Code Auswählen

2015.11.20 14:38:57.849 3: set WhatsApp.Ronny msg 'Test' 'Nachricht' '' 0 '' : Unknown argument msg, choose one of image send
2015.11.20 14:38:57.847 3: msg push: RECIPIENT=rr_Ronny ROUTE=WhatsApp.Ronny(0) STATUS=OK PRIORITY=0 TITLE='Test' MSG='Nachricht'

Hier wird scheinbar nicht der richtige Befehl für yowsup verwendet...

Also habe ich die Nachricht mal direkt über das yowsup-Device schicken wollen:

Code Auswählen

msg push @WhatsApp.Ronny 0 |Test| Nachricht

Gleiches Ergebnis im Log:

Code Auswählen

2015.11.20 14:40:38.227 3: set WhatsApp.Ronny msg 'Test' 'Nachricht' '' 0 '' : Unknown argument msg, choose one of image send
2015.11.20 14:40:38.226 3: msg push: RECIPIENT=WhatsApp.Ronny ROUTE=WhatsApp.Ronny(0) STATUS=OK PRIORITY=0 TITLE='Test' MSG='Nachricht'

Wo liegt hier mein Denkfehler?

Vielen Dank

Ronny

Loredo · 20 November 2015, 14:55:57

Zitat von: RoBra81 am 20 November 2015, 14:41:49
Wo liegt hier mein Denkfehler?

Nirgends, du hast alles richtig gemacht aus Sicht des msg-Kommandos

Ich benutze nur einige der Module, welche ich in der Schema Datenbank führe und habe für die anderen streng nach deren Commandref rudimentäre Schemata eingefügt in der Hoffnung, dass sie funktionieren. Der Plan war zu warten, bis das jemand getestet hat und es dann ggf. anzupassen oder zu erweitern.

Wie verschickst du denn, wenn du über "set WhatsApp.Ronny" verschickst? Die Schema Datenbank hat dies hier für Yowsup hinterlegt:

Code Auswählen


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%

Du kannst nun beim Device WhatsApp.Ronny hergehen und per userattr ein eigenes Schema definieren.
Hiermit kopierst du erstmal das Schema, was auch schon in der Datenbank ist und kannst es dann abändern:

Code Auswählen


attr WhatsApp.Ronny userattr msgCmdPush,msgCmdPushHigh,msgCmdPushLow
attr WhatsApp.Ronny msgCmdPush set %DEVICE% send %RECIPIENT% %TITLE%: %MSG%
attr WhatsApp.Ronny msgCmdPushHigh set %DEVICE% send %RECIPIENT% %TITLE%: %MSG%
attr WhatsApp.Ronny msgCmdPushLow set %DEVICE% send %RECIPIENT% %TITLE%: %MSG%

Wenn du mir dann sagst, was du geändert hast, damit es funktioniert, übernehme ich das gerne in die Schema Datenbank. Dann kann man sich das userattr sparen (es sei denn man will was ausgefallenes tun

)

Du kannst dann auch überprüfen, welches Schema für WhatsApp.Ronny verwendet wird, wenn darüber verschickt wird:

Code Auswählen


get globalMsg routeCmd push WhatApp.Ronny


PUSH: USER DEFINED COMMANDS WITH PRECEDENCE
-------------------------------------------------------------------------------

  WhatsApp.Ronny (DEVICE TYPE: 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%


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%

@all:
Das selbe Vorgehen gilt übrigens für alle bereits bekannten oder noch unbekannten FHEM Module

Jetzt sehe ich gerade, dass bei dir im Log ein "set WhatsApp.Ronny msg..." geschickt wird und nicht "set WhatsApp.Ronny send..." wie es im Schema definiert ist. Kannst du mal ein "list WhatsApp.Ronny" machen und das Ergebnis schicken? Steht bei TYPE da wirklich yowsup?

Außerdem sieht die Logausgabe leicht so aus, als wenn du eine veraltete Version des msg-Kommandos verwendest. Hast du vorher schon manuell was installiert und nicht aufgeräumt? Siehe http://forum.fhem.de/index.php/topic,39983.msg354034.html#msg354034

RoBra81 · 20 November 2015, 15:09:08

Zitat von: Loredo am 20 November 2015, 14:55:57
Außerdem sieht die Logausgabe leicht so aus, als wenn du eine veraltete Version des msg-Kommandos verwendest. Hast du vorher schon manuell was installiert und nicht aufgeräumt? Siehe http://forum.fhem.de/index.php/topic,39983.msg354034.html#msg354034

Vielen Dank, das war's. Der yowsup-Befehl funktioniert, allerdings wird %RECIPIENT% nicht ersetzt so dass es vermutlich entfallen kann...

Ronny

Loredo · 20 November 2015, 15:13:51

Zitat von: RoBra81 am 20 November 2015, 15:09:08
Vielen Dank, das war's. Der yowsup-Befehl funktioniert, allerdings wird %RECIPIENT% nicht ersetzt so dass es vermutlich entfallen kann...

Soweit ich es verstehe braucht man für Yowsup immer einen Empfänger und den kann der msg-Befehl so nicht einfach erraten. Deshalb musst du im Attribut msgContactPush nicht nur "WhatsApp.Ronny" angeben, sondern "WhatApp.Ronny:MEINWHATSAPPNAME". Oder kann man bei yowsup auch direkt einen Default Kontakt hinterlegen? Hab ich so in der Commandref nicht gefunden, daher ist RECIPIENT im Schema nicht als optional hinterlegt.

RoBra81 · 20 November 2015, 15:19:29

Bei yowsup ist es so, dass es ein "zentrales" yowsup-Device gibt, welches (glaube ich) die Verbindung mit yowsup aufbaut und dann gibt es pro Kontakt/Gruppe ein eigenes Device. Man kann die Nachrichten entweder über das Zentrale Device senden und muss da den Empfänger angeben (dann passt deine Konfiguration) oder aber (wie ich es gemacht habe) an den konkreten Kontakt - ein Empfänger ist dann nicht erforderlich. Der TYPE bei beiden ist yowsup...

Ronny

Loredo · 20 November 2015, 15:23:31

Zitat von: RoBra81 am 20 November 2015, 15:19:29
Bei yowsup ist es so, dass es ein "zentrales" yowsup-Device gibt, welches (glaube ich) die Verbindung mit yowsup aufbaut und dann gibt es pro Kontakt/Gruppe ein eigenes Device. Man kann die Nachrichten entweder über das Zentrale Device senden und muss da den Empfänger angeben (dann passt deine Konfiguration) oder aber (wie ich es gemacht habe) an den konkreten Kontakt - ein Empfänger ist dann nicht erforderlich. Der TYPE bei beiden ist yowsup...

Ok, dann tendiere ich dazu, das so zu belassen. Der Sinn des msg-Befehls ist es möglichst nichts doppelt zu pflegen und ein "yowsup Sub-Device" ist genau das. Ich empfehle dann bei msgContactPush das zentrale yowsup-Device gefolgt von der Rufnummer zu verwenden und sich das Sub-Device (WhatsApp.Ronny) zu sparen.
Ich denke André hatte bei der Gestaltung von yowsup auch eine Vereinfachung beim Versand im Kopf, in diesem Fall vereinfacht aber der msg-Befehl das ganze bereits und man braucht kein Sub-Device mehr.

RoBra81 · 20 November 2015, 15:28:03

Okay, das passt. Da kann ich jetzt mit meinen WIFILights und dem SB_PLAYER spielen...

Ronny

Loredo · 20 November 2015, 15:29:30

Wenn da allgemeine Befehls-Schemata bei herausfallen, gerne hier posten, ich nehme die dann mit in die Datenbank auf

Buwe · 04 Dezember 2015, 20:40:06

Trotz mehrfachen durcharbeitens dieses Threads (oder gerade deswegen) habe ich ein Verständnis Problem.

Vorab, ein:

Code Auswählen

msg push @mein_bot:@12345678 Titel: Test
sendet erfolgreich eine Nachricht über den TelegramBot und hat beim ersten Mal auch das Device globalMsg erstellt.

Wenn ich den ersten Post verstanden habe, würde man nun über das Attribut msgCmdPush in globalMsg nun ein Mal definieren das Pushnachrichten über den TelegramBot versendet werden. Nur was trägt man da ein?

Code Auswählen

get globalMsg route cmd

TelegramBot 
    Priority Normal: 
      set %DEVICE% message %RECIPIENT% %TITLE%: %MSG% 
      Default Values: 
        RECIPIENT = [EMPTY]

Kommt alles ab "set..." in das Attribut? Ersetzt man %DEVICE% durch @mein_bot ?

Dann müsste ich unter jedem Roommate nur noch das Attribut msgContactPush = @meineTelegramID setzen?

Letztendlich reicht dann nur noch ein:

msg push mein_roommate Titel Text

zum Senden?

Ist vermutlich zu einfach gedacht?

Ich habe auch einige Posts für Telegram/msg gefunden. Um Telegram explizit anzusprechen, heisst es jetzt Telegram: oder TelegramBot:?

l2r · 05 Dezember 2015, 01:22:08

hi,

so wie ich das verstanden habe dient das Attribut msgCmdPush dazu, die Befehlsfolge, die für die einzelnen Möglichkeiten Pushnachrichten definiert ist, umzukonfogurieren bzw. anzupassen, falls die Befehlsfolge nicht passt.

Ich nutze Pushover für Pushnachrichten.

deshalb habe ich bei msgContactPush mein Device vom Typ Pushover (also den Empfänger der Pushnachrichten) eingetragen. Anhand des Typs erkennt der msg-Befehl welche Syntax zu nutzen ist.

@Loredo: Falls ich hier Bullshit erzähle, dann korrigiere mich bitte