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

Begonnen von Loredo, 13 August 2015, 19:31:07

Vorheriges Thema - Nächstes Thema

Loredo

Hallo zusammen,


ich habe ein neues FHEM Kommando implementiert, welches FHEM mit einem Routing Mechanismus für Benachrichtigungen ausstattet.
Es unterstützt folgende Typen:



FHEM Messaging Tree


COMMAND         ROUTING ESCALATION
-------------------------------------------------------------------
>>+ msg
  |--+ screen  [ light(d=N | p>=?,rA=?,rG=?), text(p>=?,rA=?,rG=?) ]
  |--+ light   [ audio(d=N | p>=?,rA=?,rG=?), text(p>=?,rA=?,rG=?) ]
  |--+ audio   [ text (d=N | p>=?,rA=?,rG=?) ]
  |--+ text    [ push (d=N | p>=?,rA=?,rG=?), mail(p>=?,rA=?,rG=?) ]
     |--+ push [ mail (d=N | p>=?,rA=?,rG=?) ]
     |--+ mail




text
Sendet eine Textnachricht per Push oder E-Mail. Je nach Priorität wird gepusht, gemailt oder beides. E-Mails werden mit der entsprechenden Priorität im Header markiert (dafür sind bei High und Low Prio HTML Mails zwingend erforderlich. Normale Mails werden als Nur-Text gesendet).

Die Befehle, wie gepusht oder gemailt werden soll, können über Attribute am Device "globalMsg" für die Prioritäts-Kategorien "High", "Normal" und "Low" angepasst werden. Standardmäßig wird für Push das Pushover Modul sowie für E-Mail system() per /usr/bin/mail verwendet.

Die Sub-Typen "mail" und "push" können auch explizit für sich aufgerufen werden.


audio
Gibt die Nachricht zunächst als Sprachnachricht weiter. Je nach Priorität wird die Nachricht auch per Text weitergeleitet. Auch kann optional die Anwesenheit des Bewohners berücksichtigt werden (follow me) und die Nachricht wird dann auch als Text weitergeleitet.
Außerdem kann über einen Dummy-Switcher gesteuert werden, ob Audio Nachrichten komplett wiedergegeben werden sollen, nur in einer gekürzten Fassung oder gerade überhaupt nicht (Emergency-Prio Nachrichten werden trotzdem immer wiedergegeben). Ich nutze das beispielsweise dafür, dass ich den Switcher auf "short" setze, wenn meine Wohnungstür offen steht, damit meine Nachbarn nicht meine gesamten Audio Benachrichtigungen zu hören kriegen  ;)

Die Befehle zur Audio Wiedergabe können über Attribute am Device "globalMsg" für die Kategorien "Long", "Short with Priority" und "Short" angepasst werden. Der Nachrichtentitel wird hier als |Titel| mit übergeben.


Bei Verwendung von SONOSPLAYER gilt: Ist eine entsprechende Audio-Datei hinterlegt, wird diese dann vor der Nachricht mit eingebunden (Details siehe SONOS Doku). Ich nutze das, um meinen Audio-Nachrichten verschiedene Varianten von einem Gong voran zu stellen (z.B. wie im Flugzeug), damit sich die Bewohner bei einer plötzlichen Ansage nicht so erschrecken  8)  Definiert man den Audio-Titel zentral über das Attribut msgTitleAudio, statt ihn in jedem msg-Kommando explizit anzugeben, kann man später auch zentral ändern, welche Sounddatei den Nachrichten vorangestellt werden soll und muss dann nicht überall Anpassungen vornehmen.
Weitere Audio-Dateien können natürlich wie in der SONOS Doku beschrieben in den Text über |Dateiname| aufgenommen werden.


light
Verwendet die Nachricht zunächst nur, um eine Leuchte anzusteuern (z.B. HUE). Je nach Priorität (hoch oder normal) kann die Leuchte anders geschaltet werden. Ist die Priorität hoch genug, wird die Nachricht zusätzlich auch per Audio wiedergegeben (dort greifen dann die Routing-Methoden für Audio). Auch hier kann optional die Anwesenheit des Bewohners berücksichtigt werden und die Nachricht alternativ als Text zugestellt werden, sofern die Priorität hoch genug ist.

Die Befehle zur visuellen Wiedergabe können über Attribute am Device "globaMsgl" für die Kategorien "High" und "Normal" angepasst werden. Standardmäßig wird ein einfaches Kommando für HUE Geräte verwendet (select und lselect zum kurzen bzw. längeren blinken).


screen
Ähnlich wie der Typ "light". Standardmäßig wird ein Text an eine ENIGMA2 Box geschickt.




Eine Liste der direkt unterstützten Module, ohne dass man diese händisch einbinden muss, kann man über den get-Befehl "routeCmd" beim Helfer-Device "globalMsg" (sofern es nicht umbenannt wurde) erhalten.
Dort kann man auch sehen, mit welcher Syntax ein bestimmtes Modul angesprochen wird und das ggf. als Vorlage für eine eigene Definition per msgCmd-Attribut nehmen.




Der Hauptvorteil ist, dass man hier an zentraler Stelle definiert, wie Nachrichten verteilt und zugestellt werden sollen und sich später auch jederzeit zentral anpassen lasst.
Dazu muss man dann nicht mehr jedes einzelne Notify, DOIF oder was auch immer anpassen (beispielsweise weil sich der Empfänger geändert hat oder man nun statt dem einen FHEM Modul ein anderes Modul für die Zustellung der Nachricht verwenden möchte).

Gesteuert wird das ganze über das setzen von Attributen. Zum einen am Device "globalMsg" für die Anpassung des Routing Verhaltens sowie einiger Attribute an einem beliebigen FHEM Device, welches die Adressierung des Bewohners oder der Bewohnergruppe ermöglicht. (Für die Profis: Alle globalen Attribute kann man auch per userattr an jedes beliebige Device hinzufügen; es erhält dort dann Vorrang).

Es können auch globale Empfänger konfiguriert werden, dann wird die Angabe eines Empfängers bei den neuen Kommandos optional und sollte einmal ein Empfänger angegeben werden, der keine Kontaktmöglichkeit für Text, Audio oder Visual hinterlegt hat, gibt es einen Fallback auf die globalen Einstellungen (also quasi eine Art Catch-All). Im Falle eines Fallbacks gibt es einen entsprechenden Logeintrag und eine Textnachricht wird entsprechend mit einem Hinweis ergänzt.


Ausblick

Module könnten auf das Vorhandensein der Recipient oder Contact Attribute in einem Device (oder gar in der globalMsg Definition) prüfen und dann bei Problemen selbstständig eine Systembenachrichtigung versenden (zusätzlich zu einem Logeintrag). Ein Modulautor wäre somit in der Lage aktiver bei Problemen den Systembetreuer zu informieren und könnte den Benutzern somit direkt ein paar Standards mit an die Hand geben, ohne dass dies jeder Nutzer sich selbst überlegen müsste (Beispiel: "Batterie leer" macht gerade jeder irgendwie anders...). Gleichzeitig behält der Benutzer trotzdem die Kontrolle wie er Nachrichten erhalten möchte und wo sie hingehen sollen.


Installation

Die Dateien werden ab dem 04.11.2015 per Update ausgeliefert.
Bitte die Hinweise für Benutzer des als deprecated geführten FHEM-Moduls 75_MSG.pm beachten.


Verwendung


Die Syntax ist sehr einfach gehalten:


Usage: msg [<type>] [<@device|e-mail address>] [<priority>] [|<title>|] <message>


Type kann auch weggelassen werden und ist dann automatisch auf "text" gesetzt.
Wenn kein Device und keine E-Mail Adresse angegeben wurden, dann wird automatisch an das globale msgConfig Device (globalMsg) verschickt (ansonsten gibt es eine Fehlermeldung, wenn dort kein passendes msgContact-Attribut gefunden wurde).
Auch können mehrere Typen oder Empfänger durch Komma getrennt angegeben werden (Und-Verknüpfung).
Eine Oder-Verknüpfung ist ebenso möglich und wird mit einer Pipe (|) zwischen Type und/oder Empfänger gemacht (Oder-Verknüpfung lässt sich auch mit Und-Verknüpfung kombinieren). Bei einer Oder-Verknüpfung wird nur zum nächsten Adressaten gesprungen, sofern für den vorigen keine der angegebenen Nachrichtentypen zugestellt werden konnte. Damit wird auch die automatische Eskalation zu einem anderen Nachrichten-Typ beeinflusst. Diese wird immer nur für den jeweils letzten Eintrag angewendet.

Grundsätzlich sind alle Syntax-Angaben, die oben in eckigen Klammern (also []) stehen, optional. Es wird dann auf entsprechende Standardwerte zurückgegriffen, die entweder über Attribute am Device oder global gesetzt wurden. Ist auch global nichts vorhanden, wird auf interne Standardwerte zurückgegriffen (gilt natürlich nicht für ein Device, denn irgendwo muss man ja immer einen Empfänger angeben  ;) ).

Der Wertebereich für Priorität orientiert sich dabei an der Pushover API mit -2 bis 2. Es kann jedoch grundsätzlich jeder beliebige Wert verwendet werden. Es ist dann Sache des FHEM Moduls, ob der Wertebereich richtig ist oder ob er dort automatisch begrenzt wird (sofern ein FHEM Modul von der Priorität Gebrauch macht, ansonsten wird sie in erster Linie für das Routing innnerhalb des msg-Befehls benutzt).

Sowohl Und-Verknüpfung als auch Oder-Verknüpfung lassen sich ebenfalls in den Contact- und Recipient-Attributen anwenden. Somit bestehen eine Vielzahl von Möglichkeiten für die Adressierung von Empfängern und das Routing über bestimmte Nachrichtentypen.


Konfiguration

Hier eine Auflistung der Attribute und ihrer Funktionsbestimmung.


Attribute für das Device "msgConfig"

msgCmdAudio (Standard ohne Verwendung Attribut msgSwitcherDev)
Kommando für das "verschicken" von (langen) Audio Mitteilungen.
Entweder FHEM-Befehl oder in {} eingeschlossener Perl Befehl.

Verfügbare Variablen:
%DEVICE%
%RECIPIENT% (abhängig davon, ob das Modul optional oder verpflichtend eine gesonderte Adressierung des Empfängers vorsieht)
%TITLE%
%MSG%
%PRIORITY%

msgCmdAudioShortPrio (nur in Verbindung mit msgSwitcherDev)
Kommando für das "verschicken" von Audio Mitteilungen mit Switcher Einstellung "short" und einer Prio höher/gleich msgFwPrioEmergencyAudio.
Entweder FHEM-Befehl oder in {} eingeschlossener Perl Befehl.

Verfügbare Variablen:
%DEVICE%
%RECIPIENT% (abhängig davon, ob das Modul optional oder verpflichtend eine gesonderte Adressierung des Empfängers vorsieht)
%TITLE%
%MSG%
%PRIORITY%

msgCmdAudioShort (nur in Verbindung mit msgSwitcherDev)
Kommando für das "verschicken" von (gekürzten) Audio Mitteilungen mit Switcher Einstellung "short" unabhängig von der Priorität.
Entweder FHEM-Befehl oder in {} eingeschlossener Perl Befehl.

Verfügbare Variablen:
%DEVICE%
%RECIPIENT% (abhängig davon, ob das Modul optional oder verpflichtend eine gesonderte Adressierung des Empfängers vorsieht)
%TITLE%
%MSG%
%PRIORITY%

msgCmd<TYPE><PrioCat>
Kommando für den jeweilige Nachrichten-Typen und der entsprechenden Nachrichten-Prioritätskategorie

msgFwPrioAbsent<TYPE>
Schwellenwert, ab dem Nachrichten diesen Typs bei kurzer Abwesenheit aller Bewohner per Text weitergeleitet werden sollen.
Voreinstellung: 0

msgFwPrioEmergency<TYPE>
Schwellenwert, ab dem Nachrichten diesen Typs als Emergency Prio behandelt werden.
Diese Nachrichten werden immer wiedergegeben, unabhängig der Abwesenheit oder der Einstellung long/short am aSwitcherDev Dummy.
Voreinstellung: 2

msgFwPrioGone<TYPE>
Schwellenwert, ab dem Nachrichten diesen Typs bei längerer Abwesenheit aller Bewohner per Text weitergeleitet werden sollen.
Voreinstellung: 1

msgPriority<TYPE>
Standard Priorität für Nachrichten diesen Typs, sofern nicht in der Nachricht angegeben.
Voreinstellung: 0

msgTitle<TYPE><PrioCat>
Standard Betreff für Nachrichten diesen Typs, sofern in der Nachricht keiner angegeben wurde.

msgResidentsDev
FHEM Gerätename, welcher für die Anwesenheit aller Bewohner verwendet wird. Auf dieses Device wird zurückgegriffen, sofern für das Empfänger-Device die entsprechenden Readings nicht vorhanden sind.
Bei Verwendung von ROOMMATE, GUEST oder RESIDENTS Devices als Empfänger wird dieses Attribut ignoriert.
Das in diesem Attribut angegebene Device muss die Readings "presence" und "state" haben. Es wird die Verwendung eines Devices vom FHEM Typ RESIDENTS empfohlen.
Über "presence" wird generell An/Abwesenheit bewertet. Hat "state" den Wert "gone", wird eine längere Abwesenheit angenommen.
Für das Weiterleiten von Nachrichten bei längerer Abwesenheit muss die Nachrichten Priorität höher sein, als wenn die Bewohner nur übergangsweise abwesend sind.
Siehe auch entsprechende Readings msgFwPrioGone<TYPE> msgFwPrioAbsent<TYPE>.

Readings Wertebereich:
presence: present|absent
state: gone|*

msgSwitcherDev
FHEM Gerätename, welcher für die Beeinflussung der Länge von Audio Nachrichten verwendet werden soll.
Bei "off" findet auch keine visuelle Benachrichtigung mehr statt. Screen Nachrichten sind nicht betroffen.
Hier bietet sich ein Dummy Device wie dieses hier an:

define HouseAnn dummy
attr HouseAnn alias Announcements
attr HouseAnn devStateIcon aktiv:general_an@90EE90 active:general_an@90EE90 lang:general_an@green:off aus:general_aus@red:long kurz:general_an@orange:long visuell:general_an@orange:long
attr HouseAnn event-on-change-reading state
attr HouseAnn eventMap active:aktiv long:lang short:kurz visual:visuell off:aus
attr HouseAnn group Automation
attr HouseAnn icon audio_volume_mid
attr HouseAnn room Apartment
attr HouseAnn setList state:lang,kurz,visuell,aus
attr HouseAnn webCmd state



Attribute für alle FHEM Devices

msgContact<TYPE> (zwingend für Nachrichten diesen Typs)
FHEM Gerätename, welcher zur Übermittlung von Nachrichten diesen Typs angesprochen werden soll.
Muss bei Audio Nachrichten ohne eigene Definition von msgCmdAudio* ein Gerät vom Typ SONOSPLAYER sein.Muss bei Screen Nachrichten ohne eigene Definition von msgCmdScreen* ein Gerät vom Typ ENIGMA2 sein.Muss bei Light Nachrichten ohne eigene Definition von msgCmdLight* ein Gerät vom Typ HUEDevice sein.
Muss bei Push Nachrichten ohne eigene Definition von msgCmdPush* ein Gerät vom Typ Pushover sein.
Muss bei Mail Nachrichten eine oder mehrere gültige E-Mail Adressen enthalten.
Bei FHEM Gerätenamen, über die mehrere Empfänger adressiert werden können, kann der Empfänger mittels Doppelpunkt getrennt vom FHEM Gerätenamen angegeben werden. Je nach Modul ist das optional oder verbindlich.


msgRecipient<TYPE>
Leitet Nachrichten, die an dieses Gerät adressiert werden, auf ein anderes FHEM Device um.
Es wird dann der Wert von msgContact<TYPE> des anderen Gerätes für die Übermittlung der Nachricht verwendet.
Bei Nutzung des Attributs mit Typangabe werden nur Nachrichten des entsprechenden Typs umgeleitet.
Kombination von msgRecipient mit msgRecipient<TYPE> führt dazu, dass msgRecipient<TYPE> bevorzugt wird.


---> Für die Verwendung der Fallback und Catchall-Zustellung von Nachrichten können diese Attribute im Device "globalMsg" gesetzt werden.
---> Nahezu alle globalen Attribute können auch auf ein Device angewendet werden (Ausnahme: msgResidentsDev). Sie tauchen allerdings dort aus Gründen der Übersicht nicht standardmäßig auf. Man muss sie deshalb zuvor als userattr (entweder beim Device oder eben global) hinzufügen, damit man sie setzen kann.


Follow-Me Funktion

Sobald ein Device, an welches man eine Nachricht schickt, ein Reading "location" beinhaltet, wird geprüft, ob es für diese Lokation eine speziell hinterlegte Kontaktmöglichkeit gibt (z.B. also eine genaue SONOS Soundbox in dem Raum, wo der Bewohner sich gerade befindet).

Gebraucht wird hierfür ein iBeacon zusammen mit dem GEOFANCY Modul. ich empfehle außerdem den Einsatz des ROOMMATE Moduls dazu, weil es die Handhabung der Location gleich mitbringt (Einrichtung siehe Wiki). Man kann aber auch jede andere Möglichkeit der Raumortung nutzen, es muss nur in einem Reading namens "location" enden.

Über das Attribut "msgLocationDevs" können Devices mit Komma getrennt angegeben werden, welche dann für je einen Raum stehen und welche dann dort die msgContact* Attribute hinterlegt haben (Delegationen mittels msgRecipient* funktionieren dort auch).
Am einfachsten ist es also pro Raum ein Dummy-Device anzulegen und dieses dann unter dem globalen Attribut "msgLocationDevs" mit aufzuführen.

Wichtig ist, dass dieses Dummy ein Attribut "msgLocationName" enthält, welches dann den exakt gleichen Wortlaut enthalten muss, wie auch im Reading "location" bei dem ROOMMATE Device (also genau der Lokationsname, den ihr z.B. in eurer Geofency.app angegeben habt). Zusätzlich dann eben noch die Type-Contacts. Hier ein Beispiel für Wohnzimmer und Schlafzimmer:


define msgRoom_Living dummy
attr msgRoom_Living msgContactAudio Sonos_Living_Room
attr msgRoom_Living msgContactLight LR_Ceilling,LR_FloorLamp,LR_SofaCorner,LR_DinnerCorner
attr msgRoom_Living msgLocationName Living
attr msgRoom_Living userattr msgLocationName

define msgRoom_Bedroom dummy
attr msgRoom_Bedroom msgContactAudio Sonos_Bedroom
attr msgRoom_Bedroom msgContactLight BR_FloorLamp
attr msgRoom_Bedroom msgLocationName Bedroom
attr msgRoom_Bedroom userattr msgLocationName


Beide Devices sind als globales Attribut verlinkt:


attr globalMsg msgLocationDevs msgRoom_Living,msgRoom_Bedroom


Wenn ich nun einen msg-Audio Befehl absetze während ich im Schlafzimmer oder Wohnzimmer bin (Reading ist gleich "Living" oder "Bedroom"), wird die Nachricht auf demjenigen Gerät abgespielt, welches ich für den Raum hinterlegt habe (gleiches gilt für Light-Nachrichten). Wechsle ich den Raum und führe den Befehl nochmal aus, folgt mir auch die Wiedergabe der Nachricht  :)
Hat meine Arbeit dir geholfen? ⟹ https://paypal.me/pools/c/8gDLrIWrG9

Maintainer:
FHEM-Docker Image, https://github.com/fhem, Astro(Co-Maintainer), ENIGMA2, GEOFANCY, GUEST, HP1000, Installer, LaMetric2, MSG, msgConfig, npmjs, PET, PHTV, Pushover, RESIDENTS, ROOMMATE, search, THINKINGCLEANER

rudolfkoenig

Bitte sowas als Funktion in 99_myUtils.pm realisieren, und in cmdAlias diese Funktion aufrufen.

Noch besser: 3 Module bauen (98_text.pm, 98_audio.pm, 98_visual.pm), und die Befehle registrieren (siehe auch 98_update.pm oder 98_restore.pm)

Loredo

Danke Rudi, werde ich mir ansehen.  :)


Bisher war es für die Entwicklung so am bequemsten, weil auch alles so schön in der fhem.cfg mit gebackupt wird bei jedem speichern der Config  8) 
Der Vorteil ist dabei auch, dass man für die cmdalias Devices das verbose Attribut getrennt vom globalen verbose setzen kann und so nur die Debug Meldungen bekommt, die man hier wirklich haben möchte (was natürlich bei der myUtils Variante auch ginge, nur müsste man dort je nach Arbeitsweise jedes mal ein reload der Datei machen, was bei cmdalias mit dem speichern im Editor einfach direkt erledigt ist).


Die Entwicklung ist ja noch nicht am Ende. Ich schaue mal das als 3 98_-er Module zu integrieren.









EDIT:
Die Befehle stehen jetzt als 99-er Module bereit.





Hat meine Arbeit dir geholfen? ⟹ https://paypal.me/pools/c/8gDLrIWrG9

Maintainer:
FHEM-Docker Image, https://github.com/fhem, Astro(Co-Maintainer), ENIGMA2, GEOFANCY, GUEST, HP1000, Installer, LaMetric2, MSG, msgConfig, npmjs, PET, PHTV, Pushover, RESIDENTS, ROOMMATE, search, THINKINGCLEANER

Brockmann

Ich habe in den letzten Tagen über genau eine solche Lösung nachgedacht und war deshalb sehr positiv überrascht, das hier zu finden.

Was ich mir noch wünschen würde (nur als Idee/Anregung gedacht): Einen Rückmeldungs- und Eskalationsmechanismus.
Beispiel: Eine Warnung wird erstmal nur visuell als Meldung auf einem Tablet ausgegeben. Wird die Meldung dort nicht innerhalb von x Minuten bestätigt bzw. gelöscht wird sie zusätzlich per Sprache ausgegeben oder per Push oder E-Mail verschickt. Ist in der Praxis komplexer, als es sich so anhört. Deshalb war ich ja noch in der Nachdenkphase.  ;)

Und eine Frage: Warum verwendest Du drei verschiedene Befehle/Module anstatt einen Befehl mit dem Parameter text,audio oder visual?

Loredo

#4
Zitat von: Brockmann am 14 August 2015, 08:41:09
Was ich mir noch wünschen würde (nur als Idee/Anregung gedacht): Einen Rückmeldungs- und Eskalationsmechanismus.


Die Grundlage damit habe ich gerade mit dem Umbau des Pushover Moduls bereits geschaffen (die Befehle text/audio/visual) hier waren meine Motivation dafür).
Mal sehen, wie man eine stufenweise Eskalation hinbekommen könnte. Derzeit kann man halt ein "visual 2 |Gefahr| Höchste Dringlichkeit! Bitte sofort reagieren!" absetzen und dann wird gleichzeitig visuell, per audio, push und auch E-Mail gewarnt. Im Pushover Modul muss man dann den Emergency Fall bestätigen, sonst wird man mehrfach daran erinnert. Bei entsprechender Callback-Konfiguration kommt die Bestätigung auch direkt wieder in FHEM in den Readings des Pushover Moduls an.


Was die 3 Befehle angeht: Ich wollte eine klare Trennung haben, das war bei der Entwicklung als cmdalias einfach viel übersichtlicher und flexibler. Mir fiel kein Grund ein das bei der Überführung in die Module nicht beizubehalten, also blieb es so. Ergibt schön kurze Befehle :-)
Hat meine Arbeit dir geholfen? ⟹ https://paypal.me/pools/c/8gDLrIWrG9

Maintainer:
FHEM-Docker Image, https://github.com/fhem, Astro(Co-Maintainer), ENIGMA2, GEOFANCY, GUEST, HP1000, Installer, LaMetric2, MSG, msgConfig, npmjs, PET, PHTV, Pushover, RESIDENTS, ROOMMATE, search, THINKINGCLEANER

Loredo

#5
Momentan sieht die Eskalation ja eher Top -> Down vor, also das hier:


visual -> audio -> push -> email


Je nachdem welchen Befehl man zum absetzen der Nachricht nimmt wird dort in den Eskalationsweg eingestiegen und eben nur weiter nach "unten/hinten" weitergereicht, wenn die Priorität der Nachricht das erfordert oder die Anwesenheit der Bewohner nicht gegeben ist.


Was du beschrieben hast ist ja quasi der umgekehrte weg:


email -> push -> audio -> visual


Mein Ansatz bei sowas währe eher ein entsprechendes DOIF zu nehmen, welches bei der Wiederholung dann eben seinen eigenen state entsprechend verändert und dann statt dem vorherigen "text" ein "audio" absetzt.
Da sowieso immer über die Text Möglichkeit bestätigt werden muss, wäre diese Möglichkeit mit den gerade erwähnten Pushover Modulerweiterungen bereits grundsätzlich möglich.
Für die Auswertung des korrekten Readings im Pushover Modul braucht man allerdings vermutlich die dort erzeugte FhemCallbackId (ist einfach der Unix-Timestring, wann die Emergency Meldung ihren Timeout hat und die Erinnerung in Pushover aufhören soll). Diese ID wollte ich eigentlich als Rückgabewert auf einen "set pushover msg ..." Befehl geben, dieser würde bei Verwendung des neuen FHEM Befehls "text" dann ebenfalls zurückgegeben. Der Rückgabewert müsste im DOIF dann irgendwie gespeichert bleiben, damit er bei der Auswertung/Überwachung der Readings des Pushover Moduls dann verwendet werden kann. Dafür habe ich aber gerade noch keine direkte Idee im Kopf wie das in DOIF einfach zu lösen wäre. Das müsste man vielleicht mal Damian zum grübeln geben, evtl. geht es ja sogar schon irgendwie.
Hat meine Arbeit dir geholfen? ⟹ https://paypal.me/pools/c/8gDLrIWrG9

Maintainer:
FHEM-Docker Image, https://github.com/fhem, Astro(Co-Maintainer), ENIGMA2, GEOFANCY, GUEST, HP1000, Installer, LaMetric2, MSG, msgConfig, npmjs, PET, PHTV, Pushover, RESIDENTS, ROOMMATE, search, THINKINGCLEANER

Loredo

So langsam wird ein Schuh draus  ;D


Ich habe jetzt alles in einen einzelnen Befehl "msg" gegossen, welcher entsprechende Typen unterstützt.
Der erste Post ist was die Funktionalität angeht aktualisiert (und hoffentlich soweit verständlich und komplett).


Ein paar Dinge fehlen noch, die ich auf der Todo Liste habe.
Hat meine Arbeit dir geholfen? ⟹ https://paypal.me/pools/c/8gDLrIWrG9

Maintainer:
FHEM-Docker Image, https://github.com/fhem, Astro(Co-Maintainer), ENIGMA2, GEOFANCY, GUEST, HP1000, Installer, LaMetric2, MSG, msgConfig, npmjs, PET, PHTV, Pushover, RESIDENTS, ROOMMATE, search, THINKINGCLEANER

Schlimbo

Hi Loredo,

erst mal danke für das Modul, finde die Idee,  die ganze Benachrichtigungs Geschichte Global zu machen,  echt klasse.
Bin gerade ein wenig am testen und mir ist aufgefallen, wenn im Titel einer Benachrichtigung ein Umlaut vorkommt wird der Titel nicht als Titel erkannt, sondern erscheint im Nachricht Text.
z.b.
msg push 0 |FHEM Müllabfuhr| Morgen wird Biomüll abgeholt!
schriebe ich stattdessen:
msg push 0 |FHEM Muellabfuhr| Morgen wird Biomüll abgeholt!
Wird der Titel korrekt dargestellt.

Gruß Schlimbo

Loredo

#8
Danke für den Hinweis!  Kommt auf die Todo Liste ☺️


Edit: Ist gefixt.
Hat meine Arbeit dir geholfen? ⟹ https://paypal.me/pools/c/8gDLrIWrG9

Maintainer:
FHEM-Docker Image, https://github.com/fhem, Astro(Co-Maintainer), ENIGMA2, GEOFANCY, GUEST, HP1000, Installer, LaMetric2, MSG, msgConfig, npmjs, PET, PHTV, Pushover, RESIDENTS, ROOMMATE, search, THINKINGCLEANER

Loredo

Ich habe jetzt gerade nochmals eine aktualisierte Version hochgeladen, die sich anfänglich dem Thema Readings widmet.
Hat meine Arbeit dir geholfen? ⟹ https://paypal.me/pools/c/8gDLrIWrG9

Maintainer:
FHEM-Docker Image, https://github.com/fhem, Astro(Co-Maintainer), ENIGMA2, GEOFANCY, GUEST, HP1000, Installer, LaMetric2, MSG, msgConfig, npmjs, PET, PHTV, Pushover, RESIDENTS, ROOMMATE, search, THINKINGCLEANER

Jojo11

Hallo, 

etwas ähnliches schwebt mir auch schon seit geraumer Zeit vor. Bin allerdings noch nicht viel weiter gekommen ::)
Da ich so gut wie alle verfügbaren Töne von pushover nutze, müssten die ebenfalls angegeben werden können. Auch die high priority pushs, die man bestätigen muss, halte ich für wichtig.

schöne Grüße
Jo


Loredo

#11
Du kannst den zu sendenden Befehl an Pushover mittels Attribut msgCmdPush* entsprechend anpassen, um vom Default abzuweichen. Dabei kannst du z.B. auch andere Töne angeben. Ob ich die speziellen Möglichkeiten, die Pushover so bietet, sinnvoll direkt im Nachrichtentext einbauen kann, überlege ich noch. Der Punkt ist auch, dass jedes Modul da ggf. andere kleine Anforderungen hat und ich dabei nicht für jedes Modul spezielle Anpassungen programmieren möchte. Daher gibt es die universelle Möglichkeit, den FHEM Befehl über das msgCmd-Attribut selbst festzulegen. Wer mehr möchte, kann dort auch ein Perl Kommandos in {} angeben. Damit gibt es bereits eine Menge Flexibilität, die denke ich für sehr viele Fälle ausreicht (z.B. wenn man eben statt Pushover Whatsapp nutzen möchte o.ä.).


Dies sind die aktuellen Standard-Befehle:






$defaults{audio}{Normal}    = "set \$DEVICE Speak 40 de |\$TITLE| \$MSG";
$defaults{audio}{ShortPrio} = "set \$DEVICE Speak 30 de |\$TITLE| Achtung!";
$defaults{audio}{Short}     = "set \$DEVICE Speak 30 de |\$TITLE|";


$defaults{light}{Normal} =
"{my \$state=ReadingsVal(\"\$DEVICE\",\"state\",\"off\"); fhem \"set \$DEVICE blink 2 1\"; fhem \"sleep 4;set \$DEVICE:FILTER=state!=\$state \$state\"}";
$defaults{light}{High} =
"{my \$state=ReadingsVal(\"\$DEVICE\",\"state\",\"off\"); fhem \"set \$DEVICE blink 10 1\"; fhem \"sleep 20;set \$DEVICE:FILTER=state!=\$state \$state\"}";
$defaults{light}{Low} = "set \$DEVICE alert select";


$defaults{mail}{Normal} =
"{system(\"echo '\$MSG' | /usr/bin/mail -s '\$TITLE' -t '\$RECIPIENT'\")}";
$defaults{mail}{High} =
"{system(\"/bin/echo '\$MSG' | /usr/bin/mail -s '\$TITLE' -t '\$RECIPIENT' -a 'MIME-Version: 1.0' -a 'Content-Type: text/html; charset=UTF-8' -a 'X-Priority: 1 (Highest)' -a 'X-MSMail-Priority: High' -a 'Importance: high'\")}";
$defaults{mail}{Low} =
"{system(\"/bin/echo '\$MSG' | /usr/bin/mail -s '\$TITLE' -t '\$RECIPIENT' -a 'MIME-Version: 1.0' -a 'Content-Type: text/html; charset=UTF-8' -a 'X-Priority: 5 (Lowest)' -a 'X-MSMail-Priority: Low' -a 'Importance: low'\")}";


$defaults{push}{Normal} =
"set \$DEVICE msg '\$TITLE' '\$MSG' '' \$PRIORITY ''";
$defaults{push}{High} =
"set \$DEVICE msg '\$TITLE' '\$MSG' '' \$PRIORITY '' 120 600";
$defaults{push}{Low} =
"set \$DEVICE msg '\$TITLE' '\$MSG' '' \$PRIORITY ''";


$defaults{screen}{Normal} = "set \$DEVICE msg info 8 \$MSG";
$defaults{screen}{High}   = "set \$DEVICE msg attention 12 \$MSG";
$defaults{screen}{Low}    = "set \$DEVICE msg message 8 \$MSG";



Bitte beachten, dass diese aufgrund der Perl-Definition an einigen Stellen gequotet sind. Man kann sie also nicht 1zu1 in das Attributfeld kopieren und dort abändern, sondern muss die Quotes auch entfernen.
Hat meine Arbeit dir geholfen? ⟹ https://paypal.me/pools/c/8gDLrIWrG9

Maintainer:
FHEM-Docker Image, https://github.com/fhem, Astro(Co-Maintainer), ENIGMA2, GEOFANCY, GUEST, HP1000, Installer, LaMetric2, MSG, msgConfig, npmjs, PET, PHTV, Pushover, RESIDENTS, ROOMMATE, search, THINKINGCLEANER

Jojo11

Ok, danke. Ich schaue mir das mal an.

schöne Grüße
Jo


l2r

hi,

interessantes Modul! Ich bin ebenfalls fleißig am testen. Läuft soweit auch echt super.
Ich hab nur ein Problem, wie kann ich den Inhalt einer Variablen mit in den Text bei einem Pushover einfügen. Zeilenumbrüche wären auch super!

Gruß Michael
Wissen ist Macht.
Ich weiß nix.
Macht nix.

Loredo

Das geht ähnlich wie bei DOIF:



msg audio @rgr_Residents -1 Hallo Juljan, willkommen zuhause. ({jpWelcomeHome()})
Hat meine Arbeit dir geholfen? ⟹ https://paypal.me/pools/c/8gDLrIWrG9

Maintainer:
FHEM-Docker Image, https://github.com/fhem, Astro(Co-Maintainer), ENIGMA2, GEOFANCY, GUEST, HP1000, Installer, LaMetric2, MSG, msgConfig, npmjs, PET, PHTV, Pushover, RESIDENTS, ROOMMATE, search, THINKINGCLEANER