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

Zitat von: l2r am 05 Dezember 2015, 01:22:08
@Loredo: Falls ich hier Bullshit erzähle, dann korrigiere mich bitte ;-)


Das ist soweit alles richtig  :)


Zitat von: Buwe am 04 Dezember 2015, 20:40:06
Vorab, ein:
msg push @mein_bot:@12345678 Titel: Test
sendet erfolgreich eine Nachricht über den TelegramBot und hat beim ersten Mal auch das Device globalMsg erstellt.


Ggf. möchtest du den Titel hier nicht als "Titel:" eintragen, sondern als "|Titel|", damit er innerhalb des msg-Kommandos richtig gehandhabt wird, falls mal eine Typ-Eskalation etc gemacht werden soll. Ansonsten wird "Titel:" als Teil des Body-Textes angesehen und der Standardtitel (bzw. jener aus einem gefundenen msgTitle Attribut) wird noch davor gesetzt.


Zitat von: Buwe am 04 Dezember 2015, 20:40:06
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.


Das stimmt, damit definiert man global ein Push-Ziel. Ansonsten eben bei jedem beliebigen FHEM-Device, welches man dann mit @Devicename adressieren möchte.


Zitat von: Buwe am 04 Dezember 2015, 20:40:06
Nur was trägt man da ein?
...
Kommt alles ab "set..." in das Attribut? Ersetzt man %DEVICE% durch @mein_bot ?


der Befehl "get globalMsg routeCmd" ist vornehmlich für erfahrene Nutzer gedacht, damit man in die interne Struktur hinein schauen kann. Man kann darüber herausfinden, wie ein msg-Befehl in den tatsächlichen Befehl für ein jeweiliges FHEM Modul umgeschrieben wird. Die Infos darin haben also nichts mit den msgContact Attributen zu tun. Sie hängen ausschließlich mit den msgCmd Attributen zusammen. Die braucht man aber für den Anfang nicht (oder im Optimalfall niemals), sie sind nur für erfahrene Nutzer und gehobene Ansprüche da, falls man ein Modul anders ansprechen möchte, als es in der Schema-Datenbank vom msg-Kommando vermerkt ist.


Zitat von: Buwe am 04 Dezember 2015, 20:40:06
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?


Fast. Du musst dort alles angeben, was du auch bei deinem manuellen, direkten Ansprechen des Telegram-Devices mit angegeben hast. Einzige Ausnahme ist, dass du das @ ganz am Anfang auch weglassen kannst, denn es dient dem msg-Befehl nur zum erkennen, dass ein Empfänger angegeben wurde. Das ist im msgContact Attribut nicht notwendig, da der Sinn des Attributs ja bekannt ist.


Aus deinem Beispiel oben würdest du also bei dem ROOMMATE-Device das Attribut msgContactPush auf "mein_bot:@12345678" setzen, um Pushnachrichten über Telegram zuzusenden.
Anschließend kannst du Push-Nachrichten an das ROOMMATE Device per "msg Devicename Text" senden. (die Angabe "push" nach msg kann hier auch entfallen, weil der Default der Typ "text" ist und dieser wiederum automatisch auf den Typ "push" routet, wenn das msgContactPush Attribut vorhanden ist).


Zitat von: Buwe am 04 Dezember 2015, 20:40:06
Ich habe auch einige Posts für Telegram/msg gefunden. Um Telegram explizit anzusprechen, heisst es jetzt Telegram: oder TelegramBot:?


Im Zusammenhang mit dem msg-Befehl gehst du immer über den Device-Namen, welchen du ja im Define-Befehl selbst vergeben hast. Der msg-Befehl erkennt anhand des Device-Type-Internals dann, wie er das Device ansprechen muss (oder nutzt eben direkt das Schema aus einem msgCmd-Attribut, falls vorhanden).
Ich habe bei mir tatsächlich mein einziges Telegram-Device auch einfach "Telegram" genannt.


Ansonsten spezielle Antwort bezogen auf die Telegram-Implementierung in Fhem: Das offizielle Modul heißt "TelegramBot". Es gibt noch ein anderes Vorgänger-Modul des selben Autors, welches aber nicht direkt in Fhem enthalten ist und auch anders arbeitet. Das hieß glaube ich nur "Telegram" ohne das Bot am Ende.
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

Übrigens noch ein Tipp für die Pushover User:

Bei mehreren Pushover Empfängern muss man nicht mehr für jeden Empfänger ein einzelnes Pushover-Device anlegen. Es genügt auch ein Gerät, man kann die Empfänger dann einfach als Sub-Empfänger ansprechen:


msg push @PushoverDevice:uQiRzpo4DXghDmr9QzzfQu27cmVRsG Dies ist eine Nachricht


Wie man sieht kann man einfach den User-Identifier (oder natürlich Group-Identifier) anhängen und adressiert somit einen alternativen Empfänger. Der im define des Device "PushoverDevice" angegebene User ist dann nur noch der Default-Empfänger.

Man kann auch an ein spezielles Endgerät adressieren:


msg push @PushoverDevice:uQiRzpo4DXghDmr9QzzfQu27cmVRsG:iPhone Dies ist eine Nachricht, die nur an das iPhone geschickt wird.


Natürlich kann man das auch in ein msgContactPush Attribut schreiben...


attr myDevice msgContactPush PushoverDevice:uQiRzpo4DXghDmr9QzzfQu27cmVRsG


...und anschließend so wie gewohnt über die Device-Adressierung verschicken:


msg push @myDevice Nachrichtentext
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

SirUli

Hi,

erstmal ein herzlichen Dank für diese Abstraktionsschicht (auch wenn man da erstmal den Kopf dazu bringen muss das alles zu verstehen, muss ich zugeben). Meine Frage an dich: Gibt es eine Möglichkeit, das routeCmd auf der basis einen "TYPE" zurück zu bekommen?

Anwendungsfall: Ich bin derzeit am schreiben eines Moduls was auf einen notify eines Eingabegerätes (ausserhalb meines Moduls) reagiert, eine Verarbeitung macht und das Ergebnis wieder an das Ursprüngsgerät zurückliefert. Zunächst hatte ich deine msgSchema Datenbank dazu mit verwendet, aber möchte eigentlich lieber nicht von der Datenbank sondern lieber von einer Schnittstelle abhängig sein. Das Modul kommt in Kürze - möchte da nur noch ein paar Feinheiten schleifen ;)

Wunsch wäre also ein Kommando wie:
get globalMsg routeCmd type yowsup high

Was dann einen Einzeiler wie:
set %DEVICE% send %RECIPIENT% %TITLE%: %MSG%
zurückgibt.

Derzeit ist das Problem, dass ich nicht weiss, von welcher Kategorie das Device ist - ob es push, audio oder ähnliches ist - insofern kann ich es auch nicht mitgeben. Und ich bräuchte nur einen Wichtigkeitslevel, den ich parametrisiert mitgeben würde (sofern low oder high). Aktuell habe ich es so gelöst, dass der Nutzer eben die userattr "msgCmdPush" definiert haben muss, was ich aber gerne noch eleganter machen wollte ;)

Sollte das nicht möglich sein, dann wäre mein Wunsch ein Kommando, was mir zurückgeben kann, welche types für einen Gerätetyp möglich sind. Also sowas wie:
get globalMsg showType yowsup
Mit Ergebnis
push

Dann kann ich in meinem Code einen weiteren Request aufbauend auf dem vorherigen durchführen.

Meinst du da ist was möglich? Vielen Dank im Voraus!

Loredo

Zitat von: SirUli am 12 Dezember 2015, 11:01:47
Gibt es eine Möglichkeit, das routeCmd auf der basis einen "TYPE" zurück zu bekommen?

Anwendungsfall: Ich bin derzeit am schreiben eines Moduls was auf einen notify eines Eingabegerätes (ausserhalb meines Moduls) reagiert, eine Verarbeitung macht und das Ergebnis wieder an das Ursprüngsgerät zurückliefert. Zunächst hatte ich deine msgSchema Datenbank dazu mit verwendet, aber möchte eigentlich lieber nicht von der Datenbank sondern lieber von einer Schnittstelle abhängig sein.


Richtiger Gedanke!  ;)


Zitat von: SirUli am 12 Dezember 2015, 11:01:47
Wunsch wäre also ein Kommando wie:
get globalMsg routeCmd type yowsup high

Was dann einen Einzeiler wie:
set %DEVICE% send %RECIPIENT% %TITLE%: %MSG%
zurückgibt.


Aber leider falsche Schlussfolgerung.
Der Sinn der Abstraktion ist nicht, dass du hinterher das Schema selbst weiter verwendest. Das erschwert spätere Änderungen und Erweiterungen maßgeblich. Richtig wäre, dass du das msg-Kommando verwendest und es seine Arbeit für dich machen lässt, nämlich den richtigen Befehl dahinter für dich zu suchen.


Das get-Kommando routeCmd ist für Analysezwecke bzw. leichte Einsicht was der Befehl im Hintergrund so tut gedacht.


Zitat von: SirUli am 12 Dezember 2015, 11:01:47
Derzeit ist das Problem, dass ich nicht weiss, von welcher Kategorie das Device ist - ob es push, audio oder ähnliches ist - insofern kann ich es auch nicht mitgeben.


Es gilt auch zu bedenken, dass ein DEVICE u.U. auch mehreren msg-Types unterstützt. Das AMAD Modul ist ein Beispiel dafür, welches wir schon in der Schema Datenbank haben.


Ich habe leider nicht verstanden, was genau dein Modul tun soll und kann daher nicht bewerten, ob du gerade den richtigen Weg einschlägst. Erstmal klingt es so, als würdest du einen sehr speziellen Anwendungsfall bei dir abdecken wollen und nichts, was der (größeren) Allgemeinheit nützlich wäre. Du müsstest dein Vorhaben besser beschreiben (optimalerweise ein einem eigenen, neuen Thread).


Ich habe erwartet, dass ich einzelne Perl-Funktionen bereitstelle, wenn sich die ersten Anwendungsfälle zeigen. Ich möchte aber nicht jeden Sonderfall als Schnittstelle einbauen (und pflegen), sondern möglichst universelle Funktionen bereitstellen. Dafür muss ich verstehen welche Anwendungsfälle es gibt und dann überlegen, ob und wie man das universell abbilden kann.


Zitat von: SirUli am 12 Dezember 2015, 11:01:47
Sollte das nicht möglich sein, dann wäre mein Wunsch ein Kommando, was mir zurückgeben kann, welche types für einen Gerätetyp möglich sind. Also sowas wie:
get globalMsg showType yowsup
Mit Ergebnis
push


Eine ähnliche Funktion hatte ich schon im Sinn, aber bisher noch nicht umgesetzt:


Man übergibt einen FHEM Devicenamen und erhält einen HASH zurück, in welchem für die möglichen Zustellmethoden eine 1 gesetzt ist, für die anderen eine 0. Das msg-Kommando berücksichtigt bei der tatsächlichen Routing-Ausführung allerdings zusätzliche Parameter wie den DEVICE-Status (also z.B. ob das Device eines Moduls gerade "absent" ist und dann die Nachricht gar nicht verarbeitet werden könnte). Außerdem je nach Konfiguration auch die Anwesenheit der Bewohner oder den Status eines ggf. vorhandenen msgSwitcherDev Devices und dessen Status.
Daher ist so eine Funktion nicht ganz trivial bereitzustellen. Diese Logik würde ich in dem Atemzug direkt so kapseln wollen, dass sie auch vom msg-Kommando intern verwendet werden kann. Derzeit läuft das intern über einen reversen Aufruf der eigenen Funktion. Es macht den Code allerdings zunehmend unübersichtlich, daher hatte ich vor das bei Gelegenheit umzuschreiben. Dabei fällt dann auch eine entsprechende Funktion für die Drittanwendung heraus, die dann tatsächlich "voraussagen" kann, welche Zustellmethoden zum aktuellen Zeitpunkt für ein bestimmtes FHEM-Device zur Verfügung stehen. Dieses kann man dann wirklich universell einsetzen und als Modulautor erkennen, ob und wenn ja wie man mit einem Nutzer interagieren kann/soll.
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

SirUli

Zitat von: Loredo am 14 Dezember 2015, 15:07:30Der Sinn der Abstraktion ist nicht, dass du hinterher das Schema selbst weiter verwendest. Das erschwert spätere Änderungen und Erweiterungen maßgeblich. Richtig wäre, dass du das msg-Kommando verwendest und es seine Arbeit für dich machen lässt, nämlich den richtigen Befehl dahinter für dich zu suchen.
Sehe ich genauso, nur hat es sozusagen zuviel Intelligenz. Wenn ich eine Nachricht von einem Modul bekomme (in meinem Fall yowsup), dann muss die Antwort meines Moduls genau an das Ursprungsmodul zurück (und nicht irgendeines, was sich msg gerade "denkt". Wenn msg das kann, bin ich sofort dabei :)

Momentan habe ich das so gelöst, dass ich msgCmdPush im Quelldevice gesetzt habe, was von meinem Modul ausgelesen wird. Das muss ich bei meinem device sowieso machen, da yowsup "unterdevices" leider so nicht von msg verarbeitet werden (wie vorher in diesem Thread schon mal bearbeitet). Insofern erstmal halb so wild.

Zitat von: Loredo am 14 Dezember 2015, 15:07:30Es gilt auch zu bedenken, dass ein DEVICE u.U. auch mehreren msg-Types unterstützt. Das AMAD Modul ist ein Beispiel dafür, welches wir schon in der Schema Datenbank haben.
Korrekt, daher mein Gedanke mit den Typen (ganz am Ende).

Zitat von: Loredo am 14 Dezember 2015, 15:07:30Du müsstest dein Vorhaben besser beschreiben (optimalerweise ein einem eigenen, neuen Thread).
Kommt die Tage - wäre aber vorsichtig mit dem "was einer größeren Allgemeinheit nützlich wäre" ;) Glaube eher dass es ganz sinnvoll ist. aber ich melde mich, wenn der Thread offen ist, vielleicht ergibt sich dann der Sinn.

hilde

Klasse Modul!

Ich war mir erst nicht so ganz sicher ob und wofür ich es brauche, aber nachdem ich es jetzt etwas ausprobiert habe, finde ich es richtig Klasse.
So habe ich eine schöne zentrale Konfiguration der verschiedenen Nachrichtenkanäle (bei mir Dreambox, Kodi, Squeezebox, Pushnotifier und ich probiere gerade yowsup). Und in Kombination mit Residents könnte ich jetzt einige Notifies deutlich schlanker halten.

Das einzige was mir noch fehlt ist ein optionaler TITLE. In meinen bestehenden Notifies hab ich den Title bisher nicht verwendet oder gebraucht. Mit dem msg Befehl steht aber immer mindestens "System Message: " vor der Nachricht, auch wenn z.B. "msgTitlePush" nicht gesetzt ist.

Hat jemand eine Idee, wie ich den Title abschalten kann?

SirUli

Zitat von: hilde am 19 Dezember 2015, 21:21:18
Hat jemand eine Idee, wie ich den Title abschalten kann?
Ich unterdrücke ihn derzeit teilweise dann mit:
msg @Device 0 | | Meine Nachricht
Somit hat der Titel nur ein Leerzeichen und mein Client (Yowsup in diesem Falle) lässt es einfach weg. Aber das geht sicherlich noch besser...vielleicht hat das Loredo schon eine Idee.

Zitat von: SirUli am 14 Dezember 2015, 21:15:41
Wenn ich eine Nachricht von einem Modul bekomme (in meinem Fall yowsup), dann muss die Antwort meines Moduls genau an das Ursprungsmodul zurück (und nicht irgendeines, was sich msg gerade "denkt". Wenn msg das kann, bin ich sofort dabei :)
Wie ich bemerkt habe: Geht... für die Mitleser:
msg @DEVICE Meine Nachricht
geht natürlich - ich war zu sehr fixiert auf den Nachrichtentyp. Verwende nun msg in meinem Modul, würde aber ebenso wie hilde gerne auf den TITLE verzichten können.

Loredo

Habe gerade ein Update eingecheckt.


Die Geschichte ist so einfach nicht, denn wenn man mehrere Kommunikationsarten mixt (parallel oder durch Eskalation), dann unterstützt das eine Medium/Modul einen Titel (oder verlangt ihn gar) und ein anderes nicht.



Für die Module, die keinen expliziten Title-Support haben, wird der Default-Title jetzt nicht mehr übermittelt. Das heißt aktuell auch, dass selbst bei expliziter Angabe eines Titles dieser nicht übermittelt wird. Bei Gelegenheit baue ich da etwas mehr Logik ein, damit ein Titel wie bisher als "Titel: " vorangestellt wird, sollte explizit einer angegeben werden.




Gruß
Julian
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

Zitat von: SirUli am 04 Januar 2016, 16:05:56
Wie ich bemerkt habe: Geht... für die Mitleser:


Das ist ja auch zentraler Kern des msg-Konzepts ;)
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

hilde

Klasse, Danke!

Die Frage ist sicher nicht so ganz simpel, für Mail ist ein Title/Subject ja z.B. unvermeidlich. (Obwohl es mir persönlich bei Mails genügen würde, dann die Nachricht im Subject zu haben. So lange Meldungen versende ich nicht.)

Ich finde Deinen jetzigen Ansatz aber sehr gut: Wenn man einen Title haben möchte, kann man ihn setzen. Hat man keinen gesetzt und der einzelne Nachrichtenkanal erfordert einen, wird ein Default gesetzt. Wirklich gut, Danke nochmal!


inesa394

Hallo
Ich lasse mir mit hilfe deines Modules Sprachansagen auf meine Sonos ansagen
nun möchte ich gern die Lautstärke etwas reduzieren (Abends) finde aber keine
möglichkeit wie das zu bewerkstelligen ist egal welche Lautstärke ich vorher
einstelle er nimmt wohl immer eine im Modul eingestellte feste Größe

Loredo

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:



msg audio @Sonos_Bedroom |Hint| Gute Nacht! O[{"VOLUME":"8"}]
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

gandy

Hallo Julian,

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:

MSGMail_send("fhemgmail","Nachrichtentext",{"subject"=>"Thema", "cc"=>"sonstnochwer\@irgendwo.de"})

Dazu wird pro Serveraccount eine Instanz von MSGMail benötigt (hier fhemgmail), die im wesentlichen die Anmeldedaten verwaltet und Defaults für subject, to, from, cc aufnimmt (letztere lassen sich über den optionalen Hash überschreiben).

Die neue Funktion habe ich versucht, so auszulegen, dass sie auch in Verbindung mit dem neuen Msg Mechanismus einfach einzusetzen ist. Ich denke, das Modul kann eine einfache Alternative dazu sein, Mailversendung über System-Aufruf umzusetzen. Feedback hierzu ist natürlich sehr willkommen.

Beste Grüße,
Andy.
fhem (svn) auf i5-4210U NUC
2x HMLAN, 19x HM-SEC-RHS, 15x HM-LC-Bl1PBU-FM, etc.
ODYS Neron Tablet / Android 4.2
Samsung Galaxy Tab 2 10.1N / Android 4.1.2
Samsung Galaxy Note / Android 6.0.1

Jamo

Hallo Loredo,
ich finde deinen msg Befehl ja super klasse, funktioniert bei mir auch weitgehend für einfache Pushmessages, habs mit dem Residents Modul verknüpft, und mit pushmsg und whatsapp/yowsup am laufen (also NUR text).
Aber ich bekomms echt nicht hin für meine e-mail und für die pushmessages mit Prio, Alarmton und den retry/expire Perioden.
Deswegen habe ich versucht, das ganze mit msgCmdMail und msgCmdPush anzupassen:

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);

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?
Muss ja nicht meins sein, aber damit man mal was hat, wo man sich entlang-hangeln kann.

Das gleiche für den Aufruf der Pushmessages: 
Ich habe da noch die retry/expire Perioden drin, für die Alarmanlage. Das sieht dann so aus: "set pushmsg msg 'Emergency ALARM ' 'ALARM: Wohnungstuer ist offen' '' 2 'siren' 30 3600"

Wenn Du mich in die richtige Richtung schubst?

Gruss, Ingolf


Bullseye auf iNUC, Homematic + HMIP(UART/HMUSB), Debmatic, HUEBridge, Zigbee/Conbee III, FB7690, Alexa (fhem-lazy), Livetracking, LaCrosse JeeLink, LoRaWan / TTN / Chirpstack, Sonos, ESPresence

Schlimbo

Hallo Loredo,
mir ist gerade aufgefallen, dass bei dem "screen" hinterlegten "XBMC" Befehlen etwas nicht stimmt:
XBMC
    Priority Normal:
      { my $dev='%DEVICE%'; my $msg='%MSG%'; $timeout=%TIMEOUT%*1000; fhem "set $dev msg $msg $timeout %XBMC_ICON%"; }
      Default Values:
        TIMEOUT = 8
        XBMC_ICON = info
    Priority High:
      { my $dev='%DEVICE%'; my $msg='%MSG%'; $timeout=%TIMEOUT%*1000; fhem "set $dev msg $msg $timeout %XBMC_ICON%"; }
      Default Values:
        TIMEOUT = 12
        XBMC_ICON = warning
    Priority Low:
      { my $dev='%DEVICE%'; my $msg='%MSG%'; $timeout=%TIMEOUT%*1000; fhem "set $dev msg $msg $timeout %XBMC_ICON%"; }
      Default Values:
        TIMEOUT = 8
        XBMC_ICON = [EMPTY]


Vor $timeout fehlt das "my".
dadurch bekomme ich die Fehlermeldung:
Global symbol "$timeout" requires explicit package name at (eval 589) line 1, <GEN38> line 3.

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

Gruß
Schlimbo