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 :)
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)
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.
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?
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 (http://forum.fhem.de/index.php/topic,16215.msg321251.html#msg321251) 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 :-)
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.
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.
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
Danke für den Hinweis! Kommt auf die Todo Liste ☺️
Edit: Ist gefixt.
Ich habe jetzt gerade nochmals eine aktualisierte Version hochgeladen, die sich anfänglich dem Thema Readings widmet.
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
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.
Ok, danke. Ich schaue mir das mal an.
schöne Grüße
Jo
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
Das geht ähnlich wie bei DOIF:
msg audio @rgr_Residents -1 Hallo Juljan, willkommen zuhause. ({jpWelcomeHome()})
Zeilenumbrüche hatte ich aus irgend einem Grund bei Nachrichten!=Mail rausgefiltert, weiß aber grad selbst nicht mehr warum...
Ich nehms mal wieder mit rein.
hi,
bei mir läuft das irgendwie noch nicht.
Person_Anwesend:present.* {
my $AnwesendePersonen = "";
if(Value("iPhone6") eq "present") {$AnwesendePersonen = "-Michael-"};
if if(Value("iPhone6") eq "present") {
fhem("msg push -1 |ANWESENHEIT|Personen Anwesend!({$AnwesendePersonen})");}
}
sprich ich möchte gerne den Wert von $AnwesendePersonen auf in der Push-Meldung haben... klappt aber nicht.
sry... tut doch:
Person_Anwesend:present.* {
my $AnwesendePersonen = "";
if(Value("iPhone6") eq "present") {$AnwesendePersonen = "-Michael-"};
if(Value("iPhone6") eq "present") {
fhem("msg push -1 |ANWESENHEIT| Personen Anwesend!$AnwesendePersonen");}
}
Ich habe gerade eine neue Version hochgeladen, welche die Follow-Me Funktion enthält.
Sie wird im ersten Post erklärt.
Damit ist eine dynamische Adressierung der Wiedergabe von Audio, Light und Screen Nachrichten abhängig vom Aufenthaltsort möglich (die anderen Typen werden auch dynamisch adressiert, wenn ein Contact-Attribut hinterlegt ist; aber es macht bei Textnachrichten wohl weniger Sinn ;) ).
Also z.B. kann die Sprachnachricht immer in dem Raum abgespielt werden, in dem ich mich gerade befinde.
hi,
nach dem Update bekommen ich folgende Fehlermeldung:
Scalar found where operator expected at ./FHEM/99_msg.pm line 388, near "$useLocation"
(Missing semicolon on previous line?)
nach setzen des Semikolons scheint es zu laufen
danke, kommt vor ;)
Verbesserte Version hochgeladen:
- verbessertes Routing
- verbessertes Logging
- verbesserte Readings
Aktualisierte Version im 1. Post:
- verbessertes Logging
- verbesserte Readings
- Anwesenheitsstatus wird besser berücksichtigt
- forciertes verschicken mit "!" vor Empfänger oder Typ (ignoriert Abwesenheit oder SwitcherDev Status)
Aktualisierte Version:
Support für Or-Definition bei Typen
Mehrere Typen, die gleichzeitig angesprochen werden sollen, werden bisher mit einem Komma getrennt.
Zusätzlich kann man nun weitere Typen mit einer Pipe (|) trennen, um einen alternativen Typ anzugeben, sofern über den ersten Typ die Nachricht nicht erfolgreich verschickt werden konnte. z.B.
msg audio|text @Device Wenn diese Nachricht nicht vorgelesen werden kann, dann wird sie eben per Text zugestellt.
Das lässt sich natürlich auch wieder mit der Und-Definition kombinieren:
msg audio,screen|text @Device Wenn diese Nachricht weder vorgelesen noch auf dem Bildschirm gezeigt werden kann, dann wird sie eben per Text zugestellt.
Support für Or-Definition bei Empfängern
Mehrere Empfänger, die gleichzeitig angesprochen werden sollen, werden bisher mit einem Komma getrennt.
Zusätzlich kann man nun weitere Empfänger mit einer Pipe (|) trennen, um alternative Empfänger anzugeben, sofern die Nachricht an den/die ersten Empfänger nicht zugestellt werden konnte:
msg audio @Device1|@Device2 Wenn Device1 diese Nachricht nicht abspielen kann, dann wird sie eben auf Device2 abgespielt.
Das lässt sich natürlich auch wieder mit der Und-Definition kombinieren:
msg audio @Device1,@Device2|@Device3 Wenn Device1 und Device2 diese Nachricht nicht abspielen kann, dann wird sie eben auf Device3 abgespielt.
Sofern bei der ersten Gruppe niemand erreicht wurde, wird dort auch nicht zu anderen Typen eskaliert. Dies passiert nur, wenn die Nachricht über den definierten Haupttyp erfolgreich zugestellt werden konnte oder es sich aber um den allerletzten Empfänger in der Gesamtliste handelt. Letzteres stellt sicher, dass alles unternommen wurde, um die Nachricht irgendwie zuzustellen.
Ich denke wir nähern uns einer Version 1.0, die Liste der Todos wird kürzer ;)
Aktualisierte Version ab sofort im Contrib-Ordner per SVN:
- diverse Bugfixes
- or-Unterstützung für msgContact* Attribute
Aktualisierte Version ins SVN eingecheckt:
- Steuerung diverser Thresholds über Attribute
Aktualisierte Version ins SVN eingecheckt:
1. Erweiterte Parameter Kontrolle: es können jetzt an alle Module auch individuelle Parameter übergeben werden. Dazu am Ende der Nachricht ein JSON der folgenden Form anhängen:
O[{"VARNAME":"value"}]
Der Variablenname unterscheidet sich dabei von Modul zu Modul. In userattr msgCmd* können auch eigene Variablen genutzt werden, also z.B. %VARNAME% um bei dem Beispiel gerade zu bleiben.
In der Schema Datenbank bereits bekannte FHEM Module haben für die Steuerung ihrer Parameter bereits Variablen hinterlegt (siehe nächster Punkt).
Für die Nutzung erweiterter Parameter muss zwingend Perl::JSON installiert sein, ansonsten werden die Parameter ignoriert.
2. Vorbereitung für FHEM Schema Datenbank:
Für jedes FHEM Modul kann über ein Schema die genaue Syntax hinterlegt werden.
Für die bisherigen Module SONOS, HUE, ENIGMA2 und Pushover sind wie gehabt die Definitionen vorhanden. Aktuell ist die Datenbank noch Teil der Datei 99_msg.pm ($cmdSchema), sie wird jedoch zukünftig in eine eigene Datei ausgelagert, um dort besser gepflegt werden zu können und gleichzeitig von anderen FHEM Modulautoren erweitert zu werden und so eine direkte Zusammenarbeit mit dem msg-Befehl zu ermöglichen.
Für die Push-Nachrichten ist ja derzeit anscheinend 'Pushover' aufgenommen worden.
Ist geplant, dein Modul um andere/weitere Push-Dienste zu erweitern?
Ich selbst nutze 'Fhemapppush' in FHEM, welches durch die 'FHEM App' angeboten wird.
Es ist vorgesehen, dass jeder Modulautor die Schema-Datenbank für sein Modul erweitern kann (vorzugsweise nach kurzer Rücksprache, damit es auch richtig eingebunden ist). Ich werde noch einige Module selbst hinzufügen, möchte aber nicht alle verfügbaren Module daraufhin durchgehen, ob sie irgendwelche Benachrichtigungsmöglichkeiten haben.
Endnutzer können auch jetzt schon jedes Modul verwenden. Dafür sind die Attribute msgCmd* gedacht. Dort kann man das zu nutzende Befehls-Schema genauso hinterlegen. Auch ist es dafür gedacht, falls man aus irgend einem Grund mit dem Standardschema nicht weiterkommt oder man sich die Angabe von Optionen über O[{"VAR":"VAL"}] sparen möchte.
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).
Die Möglichkeiten sind inzwischen so vielseitig und komplex, dass es mir schon davor graut das alles einmal zu dokumentieren.
Glücklicherweise ist alles eher nach dem Motto "alles kann, nichts muss" definiert. Wer also nichts einstellen möchte, kann auch bereits ganz zu Anfang eine sehr große Bandbreite an Funktionen nutzen. Erst wer dann spezielle Anforderungen hat muss sich genauer mit der Materie befassen.
Wow. Klingt gut. Kling vielversprechend.
Ich habe mal einfache Schemata für die Module AMAD, Fhemapppush und TelegramBot hinzugefügt.
Ab sofort im SVN.
Hallo
Wie setzt man z.b mit deinen Modul audio global
msgContact ist bei mir bei global attribut
nicht vorhanden, am Device selber gibt es auch nicht so ein Attribut
Andre
hast du 99_msg.pm nach /opt/fhem/FHEM kopiert und FHEM neu gestartet?
Gruß
Julian
ja hatte ich habe sie hier aus dem Thread nach opt/fhem/FHEM kopiert und rechte angepaßt anschließend über ssh
neu gestartet
Hilft ein "reload 99_msg"?
Gruß
Julian
Hallo Loredo
Danke hat geklappt das reload hats gebracht
An meiner zweiten fhem installtion hatte ich das auch
das dieses Attribut nicht vorhanden war erst nach
einen reload kam es zum Vorschein
Andre
da muss ich Rudi wohl nochmal fragen. Lt. seiner Aussage müsste es genügen die Datei 99_* zu nennen, damit sie immer automatisch geladen wird. Bei mir tut sie das auch, uU aber auch nur weil ich msg bei mir im Code auch verwende (u.a. auch gleich direkt nach dem Start, um mich per Push+Light über den Neustart von FHEM informieren zu lassen).
Gruß
Julian
Hab jetzt nochmal Schemata für Pushbullet und yowsup hinzugefügt. Pushalot macht grad als allgemeine Defintion noch nicht so viel Sinn, da dort die Optionen als Default nicht so ohne weiteres Sinn machen. Ich muss mir da wohl nochmal eine Art Konvertierung überlegen...
Wg. der load-Problematik:
- 99_ er Module werden immer als erstes geladen.
- Wenn das Laden zunaechst schiefgeht, aber danach klappt, dann tippe ich auf die Verwendung von irgendwelchen Funktionen im 99-er Modul, die erst in einem anderen Modul via "use" geladen werden.
- Uebrigens sind 99-er Module unerwenscht. 99_Utils.pm und 99_myUtils.pm sind Ausnahmen von diesem Regel. 99_SUNRISE_EL.pm ist keine Ausnahme, und wird bei passender Gelegenheit umbenannt. Missachtung dieser Regel wird geahndet :)
Hallo Rudi,
es ist eigentlich nur so, dass ich dem global-Device zusätzliche Attribute für die Konfiguration mitgeben möchte (siehe msg_Initialize()). Dies ist über 98_* nicht möglich gewesen. Diese Attribute sollen aber per Default nicht bei allen anderen Devices zu sehen sein, weshalb userattr dafür nicht in Frage kommt.
Trotzdem nutze ich auch userattr, um die für alle Devices gedachten Standard Attribute anzeigen zu lassen. Da msg jedoch kein Modul ist, sondern ein Command, gibt es hier das Henne-Ei-Problem: Man müsste "msg" einmal aufrufen, damit das userattr erweitert wird. Ansonsten kann man den msg-Befehl nicht an den Devices konfigurieren und ihn somit nicht benutzen.
Die Datei kann auch 98_msg.pm genannt werden. Nur müssten dann wohl die global-Attribute und die default-Vorgabe für userattr an zentraler Stelle erweitert werden, statt über die 98_msg.pm Datei selbst. Oder gibt es da eine Möglichkeit von der ich nichts weiß?
Gruß
Julian
Ich will eigentlich weniger Attribute fuer global und nicht mehr.
Insb. will ich keine globale Attribute fuer etwas, was nicht alle verwenden.
Wie waere es mit einem msgConfig device?
Man koennte mehrere Konfigurations-Sets anlegen, und die Befehle koennen sich optional auf einem beziehen. Ohne Angabe wird nach dem ersten device mit diesen Typ gesucht, und wenn keins gefunden, dann default verwendet.
Ich glaube ich habe gerade ein TODO fuer mich erfunden: etliche bisherige global Attribute sollten so umgebaut werden: update*, backup*, longitude/etc.
Zitat von: rudolfkoenig am 15 Oktober 2015, 20:07:58
- Uebrigens sind 99-er Module unerwenscht.
*unterschreib*
Hallo Rudi,
Zitat von: rudolfkoenig am 16 Oktober 2015, 14:01:33Wie waere es mit einem msgConfig device?Man koennte mehrere Konfigurations-Sets anlegen, und die Befehle koennen sich optional auf einem beziehen. Ohne Angabe wird nach dem ersten device mit diesen Typ gesucht, und wenn keins gefunden, dann default verwendet.
Habe gerade ein kleines 97_msgConfig.pm Device eingecheckt (derzeit noch in ./contrib/97_msgConfig.pm).
Mehrere Konfigurations-Sets anlegen ist eines der Kernfunktionen des msg-Kommandos, nämlich für jedes existierende FHEM Device.
Die Kernphilosophie ist, dass ich jedem FHEM Device eine "Nachricht" schicken kann. Auf welche Art die Nachricht dann zugestellt wird (Mail-Text, Push-Text, Screen-Text, Licht, Audio), an welchen Empfänger(kreis) und mit welcher Priorität, genau darum kümmert sich der msg-Befehl dann anhand der hinterlegten Konfigurations-Attribute. Hauptziel ist es die Nachricht auf jeden Fall "zuzustellen" und dabei die vorgegebenen Möglichkeiten nacheinander abzuwägen.
Ich kann dabei auch Weiterleitungen definieren, sprich von einem Device auf ein anderes verweisen, damit dort die Konfiguration gelesen wird. Auf das globale msgConfig Device wird erst zuletzt zurückgegriffen.
Wenn an einem Device nichts konfiguriert wurde, wird auf das globale Device zurückgegriffen (eben eine Art Fallback/Catchall, was dann sowohl für den Versand von Nachrichten als auch für die Konfiguration ansich funktioniert). Das globale Device muss dafür eindeutig sein, sprich es kann dann in FHEM nur ein msgConfig Device geben, auf welches zurückgegriffen wird (analog dazu, dass es ja auch nur ein global-Device geben kann). Sofern keine Instanz von msgConfig gefunden wurde, wird automatisch eine angelegt und heftet sich sinnvollerweise an die aktuell definierten Attribute von "global" (group, room, verbose).
Derzeit muss der Name noch "msgConfig" heißen, da ich noch keine elegante Möglichkeit gefunden habe zu schauen, ob es bereits ein Device mit dem TYPE gibt und dann eben dieses verwenden kann. Alle definierten Devices in $defs{} dafür in einem Loop durchzugehen widerstrebt mir da irgendwie.
Gibt es da eine einfache Möglichkeit?
Zitat von: rudolfkoenig am 13 August 2015, 20:42:05
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)
Ich habe 98_msg.pm exakt nacht dem selben Schema wie 98_[update|restore].pm nachgebaut.
Trotzdem erhalte ich beim Aufruf des Kommandos "msg" dann die Meldung "Unknown command msg, try help.".
Ein "reload 98_msg" wirft dabei keinen Fehler, trotzdem kann ich den Befehl hinterher nicht aufrufen. Seltsamerweise kann ich ein "define test msg" machen und erhalte dann natürlich ein total unsinniges Device. Das gleiche kann ich mit update oder restore nicht machen, erkenne aber keinen Unterschied zu meiner 98_msg.pm Datei. Muss ich den Befehl noch in einer externen Datei registrieren?
Die Datei als 99_msg.pm benannt funktioniert wie erwartet.
Gruß
Julian
dafür kannst du den $modules{<device>}{defptr} verwenden. wenn es nur ein einziges msgConfig device geben soll weisst du den device hash im der DefFn so zu: $modules{msgConfig}{defptr} = $hashin der Undeffn machst du ein delete $modules{msgConfig}{defptr}.
über $modules{msgConfig}{defptr} bekommst du den device hash und kannst drauf zugreifen und auch verhindern das ein zweites definiert wird.
wenn es mehrere msgConfig devices geben darf brauchst du eine hash ebene mehr und verwendest z.b. $modules{msgConfig}{defptr}{<id>}.
den mechanismus verwenden fast alle zweistufigen module um beim parsen schnell an das client modul zu kommen das für eine nachricht zuständig ist ohne alle $defs durchzugehen.
gruss
andre
Danke, André! Ich muss mir das mal genauer ansehen, Ad-Hoc verstehe ich es nicht.
-----
Derweil habe ich nochmals ein Update hochgeladen.
Bis das Problem gelöst wurde, dass bei Benennung 98_msg.pm der Befehl nicht erkannt wird, muss man die Datei selbst in 99_msg.pm umbenennen.
Folgende Änderungen:
1. Schema Datenbank jetzt als eigene Datei msgSchema.pm zwecks besserer Wartbarkeit
2. Für Gateway-Module, die mehrere Empfänger adressieren und somit oft explizit einen zusätzlichen Empfänger verlangen, kann man in den msgContact* Attributen den Empfänger jetzt mit einem Doppelpunkt getrennt vom Device-Namen angeben (in der Form, wie es das jeweilige Modul dann erfordert). Das sind dann z.B. Module wie yowsup oder TelegramBot, aber auch Pushover, wenn man dort nur an ein spezifisches Gerät benachrichtigen möchte.
Beispiel:
attr rr_Julian msgContactPush Telegram:@@USERNAME,PushoverJulian:iPhone|Pushalot:Julian
Wie man sieht bleibt die Möglichkeit der und/oder Verknüpfungen trotzdem erhalten.
ZitatTrotzdem erhalte ich beim Aufruf des Kommandos "msg" dann die Meldung "Unknown command msg, try help.".
Dein Problem ist, dass in FHEM bereits ein MSG Modul gibt: 75_MSG.pm.
Ok, danke. Ich nahm an Module und Befehle seien besser voneinander getrennt.
Gruß
Julian
Ich nehme an es ist zu viel verlangt das Modul rauszunehmen, da es ja in der Commandref längere Zeit deprecated gelistet wird?
Dann hilft es wohl nichts und ich muss den Befehl länger benennen. Schade.
Zitat von: Loredo am 19 Oktober 2015, 18:48:02
Ich nehme an es ist zu viel verlangt das Modul rauszunehmen, da es ja längere Zeit deprecated gelistet wird?
Es gibt laut statistic zumindest noch 93 definitions von MSG
ZitatIch nehme an es ist zu viel verlangt das Modul rauszunehmen, da es ja in der Commandref längere Zeit deprecated gelistet wird?
Das musst du mit dem MAINTAINER (gandy) klaeren.
Hatte gandy direkt angeschrieben, leider gibt es bisher keine Rückmeldung zu meiner Frage.
Er war dieses Jahr im Forum auch nicht sonderlich aktiv, die letzte Nachricht stammt vom 30.8. und es gab ansonsten nur zwei weitere Nachrichten in diesem Jahr. Mal sehen, ob er bis Montag Abend noch antwortet. Was passiert danach?
Ich meine, jeder sollte die Moeglichkeit haben, 2-3 Wochen ungestoerten Urlaub zu haben.
Wenn er antwortet, dann bitten wir ihn eindringlich, das Modul nach contrib zu schieben, insb. da er das ja selbst als deprecated markeiert hat. Wenn er nicht antwortet, dann schieben wir 75_MSG.pm selbst ins contrib, und dein Modul darf nach FHEM :)
Ich finde die Idee des Moduls super und denke sowas fehlt wirklich noch sehr in FHEM!
Ich hab hier jetzt ein bisschen mitgelesen, aber eine Sache ist mir nicht ganz klar:
Werden die messages in irgendeiner Form geloggt bzw. konserviert und gibt es dann eine Möglichkeit, diese Nachrichten als eine Art "User-Log" in FHEMWEB anzuzeigen? Das normale Log ist ja eigentlich mehr ein Log für den Admin. Was ich im Moment Suche, wäre ein Log für den Endbenutzer, wo dann nur Sachen drin stehen in der Art "20.10.2015 - 22:23 - Fenster offen Bad" oder "20.10.2015 - 00:00 - Gestern höchster Stromverbrauch des Jahres".
du kannst dafür einfach ein Logfile anlegen, was nur auf msg Nachrichten reagiert und wo nur diese drin stehen. Als Reading wird nur immer die letzte Nachricht gespeichert.
Gruß
Julian
Ahh, danke, gute Idee! Ich hab jetzt im ersten Schritt (noch ohne dein Modul) ein FileLog angelegt, welches nach "./fhem/user-%%%.txt" schreibt. Scheinbar kann man da aber auch aus Perl-Code nicht direkt reinschreiben (hab zumindest nix gefunden). Daher hab ich mir ein dummy ("userLogDummy") angelegt und alle Events dieses dummies werden in das FileLog geschrieben. Nun kann ich mit "trigger userLogDummy Es ist was dolles passiert" da reinschreiben.
Gibt es jetzt evtl. eine Möglichkeit, dieses Logfile einigermaßen schick in FHEMWEB anzuzeigen? Das FileLog hat zwar in FHEMWEB einen Link "text", der dann das File "raw" anzeigt, aber das ist mMn nicht sonderlich sexy.
Hi,
Zitat von: rudolfkoenig am 22 Oktober 2015, 12:23:03
Ich meine, jeder sollte die Moeglichkeit haben, 2-3 Wochen ungestoerten Urlaub zu haben.
Wenn er antwortet, dann bitten wir ihn eindringlich, das Modul nach contrib zu schieben, insb. da er das ja selbst als deprecated markeiert hat. Wenn er nicht antwortet, dann schieben wir 75_MSG.pm selbst ins contrib, und dein Modul darf nach FHEM :)
er war nicht in Urlaub sondern hat schlicht die PN nicht gesehen ;) (Edit: habs gefunden...
gibt es im Forum irgendeine Möglichkeit PNs an die Mailadresse weiterleiten zu lassen?)
Das MSG Modul kann gern Platz machen, wie ist das Vorgehen um die Schmerzen für die Anwender der 95 Instanzen möglichst gering zu halten?
Grüße,
Andy.
Fuer sowas gibt es kein etabliertes Vorgehen.
Ich kann zwei Mehtoden vorstellen:
Methode 1: Datei identisch benennen, damit wird es ueberschrieben.
Methode 2: in control_fhem.txt ein "MOV FHEM/75_MSG.pm www/contrib" einbauen.
Fuer beide Verfahren gilt: die, die MSG noch verwenden (bzw. verwenden wollen), haben ein Problem.
Weitere Ideen?
Zitat von: vbs am 25 Oktober 2015, 12:50:29
Gibt es jetzt evtl. eine Möglichkeit, dieses Logfile einigermaßen schick in FHEMWEB anzuzeigen? Das FileLog hat zwar in FHEMWEB einen Link "text", der dann das File "raw" anzeigt, aber das ist mMn nicht sonderlich sexy.
Mit readingsHistory bekommt man es super hin, die alten Nachrichten in FHEMWEB anzuzeigen. Keine Ahnung, warum ich das Modul erst jetzt für mich entdeckt habe...
Zitat von: rudolfkoenig am 28 Oktober 2015, 10:57:44
Fuer beide Verfahren gilt: die, die MSG noch verwenden (bzw. verwenden wollen), haben ein Problem.
Im Grunde enthält MSG aktuell keinen Code mehr, der nicht in MSGMail oder MSGFile enthalten ist.
Wenn ein Device vom Typ MSG nach einem Update wegfällt, wird zunächst das define fehlschlagen. Wenn jemand noch die Delegate Funktionen in MSG verwendet, um die in MSGFile oder MSGMail implementierte Funktionalität zu nutzen, bekommt er an diesen Stellen ein Problem und muss seinen Code leicht umstellen; die dafür notwendigen Devices vom Typ MSGMail oder MSGFile sind dann ohnehin schon definiert. Im Schlimmsten Fall triggert die Umstellung potentiell ein paar Support-Anfragen, aber das gehört wohl zum Geschäft 8) Einen automatischen Mechanismus zur Umstellung kann ich mir nicht vorstellen, da MSG überwiegend aus Perl-Code heraus verwendet werden dürfte.
Bleibt zu überlegen, was passiert, wenn MSG durch ein gleichnamiges Modul ersetzt wird. Nach einem Update kommt es sicherlich auch zu Problemen, weil das neue Modul nicht mehr die API des Alten bietet. Hier könnte ein Hinweis in der Doku des neuen Moduls helfen, dass die alte Funktionalität jetzt in MSGFile bzw MSGMail zu finden ist.
So oder so bin ich damit einverstanden, dass 75_MSG ersetzt, verschoben, oder gern auch entfernt wird.
Grüße,
Andy.
Hier muss man nochmals herausstellen, dass der msg-Befehl kein Modul ist und somit auch nicht mittels "define" definiert wird.
Lediglich zur Steuerung gibt es (wie jüngst beschrieben) ein msgConfig Device, welches dann aber eben auch so heißt und nicht "msg". Die Überlappung entsteht hier nur, weil aufgrund der FHEM Internen Struktur die Funktionen gleich heißen (msg_Initialize()) und dabei nicht unterschieden werden kann, ob dies nun ein Modul oder nur ein FHEM-Befehl ist.
Eine (unsaubere) Variante fällt mir noch ein: Man könnte versuchen die Wrapper-Funktion aus 75_MSG in 98_msg.pm zu integrieren und quasi den neuen Befehl mit dem ursprünglichen Device mischen. Keine Ahnung, ob das tatsächlich ginge, wäre aber in jedem Fall verwirrend 2 Funktionen, die nichts wirklich gemein haben, in einer Datei wiederzufinden (auch was Maintenance angeht eher schwierig).
Weil 75_MSG ja nur Wrapper Funktionen enthält, braucht man die Datei auch nicht in contrib aufbewahren denke ich. Ich tendiere daher sie zu ersetzen. Man kann sie ohnehin nicht sinnvoll manuell zurückspielen, ohne dann wieder Überlappungen zu erzeugen.
Zitat von: Loredo am 28 Oktober 2015, 13:43:49
Weil 75_MSG ja nur Wrapper Funktionen enthält, braucht man die Datei auch nicht in contrib aufbewahren denke ich. Ich tendiere daher sie zu ersetzen. Man kann sie ohnehin nicht sinnvoll manuell zurückspielen, ohne dann wieder Überlappungen zu erzeugen.
Seh ich genauso. Du gibst dann 75_MSG den Rest? Meinen Segen hast Du :)
Nach so einer einfachen Möglichkeit hatte ich schon gesucht... super!
Hatte gerade leichte Probleme bei der Installation, da sich wohl inzwischen die Namen der Dateien geändert haben; die Links im ersten Post laufen daher ins Leere.
Bitte für weitere Neu-Nutzer anpassen und möglichst die Namen nicht mehr ändern ;)
Ich kapier irgendwie nicht, wie man diesen neuen Befehl benutzen kann... gibt es denn evtl. irgendwo eine Anleitung für Dummys? ;)
Mehr als in diesem Thread gibt es derzeit noch nicht.
Hast du das Grundkonzept verstanden und dir die sehr einfache Syntax angesehen? Hast du dir die notwendigen und optionalen Attribute durchgelesen? Der erste Post sollte ausreichend sein für Leute, die mit FHEM bereits arbeiten. Neulinge erlernen besser zunächst FHEM ansich ;-)
Zitat von: AndyMu am 01 November 2015, 11:57:36
Hatte gerade leichte Probleme bei der Installation, da sich wohl inzwischen die Namen der Dateien geändert haben; die Links im ersten Post laufen daher ins Leere.
Bitte für weitere Neu-Nutzer anpassen und möglichst die Namen nicht mehr ändern ;)
Der Befehl wird ja wieder in "msg" umbenannt und ich bin gerade dabei vorzubereiten die Dateien nach ./FHEM zu verschieben (siehe Diskussion in den vorigen Beiträgen).
Hallo Loredo,
mit dem Attribut "msgFwPrioGone<TYPE>" kann ich ja einstellen, dass bei länger Abwesenheit mir Meldungen des angegeben TYPES über Push weiter gegeben werden.
Gibt es auch eine Möglichkeit das Gegenteil einzustellen, dass bei längerer Abwesenheit Nachrichten nicht gepusht werden?
Ich lasse mich über einige Sachen über Push informieren z.B. "Morgen wird Restmüll abgeholt!".
Wenn ich aber länger unterwegs bin (Urlaub, Geschäftsreise) will ich diese Meldungen nicht bekommen.
Gruß Schlimbo
Zitat von: Loredo am 01 November 2015, 14:15:12
Neulinge erlernen besser zunächst FHEM ansich ;-)
Da ist es wieder, mein kleines Problem ;D
Vielleicht sollte ich mich tatsächlich erstmal weiter mit den Basics befassen und dann nochmal zurückkommen, wenn ich kein Rookie mehr bin.
Zitat von: Schlimbo am 01 November 2015, 16:03:48
mit dem Attribut "msgFwPrioGone<TYPE>" kann ich ja einstellen, dass bei länger Abwesenheit mir Meldungen des angegeben TYPES über Push weiter gegeben werden.
Das ist so nicht ganz richtig formuliert. Damit kann man die Priorität, ab der trotz längerer Abwesenheit (=Status "gone") eine Weiterleitung/Eskalation per Text erfolgt, einstellen (sofern also ein Push- oder Mail-Contact hinterlegt wurde natürlich). Standard ist bei msgFwPrioGone<TYPE> 1, also jede Nachricht mit mindestens Priorität 1.
Das wirkt, wenn der Ursprungstyp Audio, Light oder Screen war. Eine Eskalation einer Push Nachricht als Text macht ja wenig Sinn, da drehte man sich ja im Kreis :-)
Zitat von: Schlimbo am 01 November 2015, 16:03:48
Gibt es auch eine Möglichkeit das Gegenteil einzustellen, dass bei längerer Abwesenheit Nachrichten nicht gepusht werden?
Ich lasse mich über einige Sachen über Push informieren z.B. "Morgen wird Restmüll abgeholt!".
Wenn ich aber länger unterwegs bin (Urlaub, Geschäftsreise) will ich diese Meldungen nicht bekommen.
Ich habe hier das gleiche Setup, z.B. für co2 Warnung per Audio. Das ganze wird ausschließlich über die gewählte Priorität der Nachricht gesteuert. Man stellt also nicht "das Gegenteil" ein, sondern man wählt in seinem Automatisierungscode die Priorität der Nachricht entsprechend. In deinem Fall sollte die Nachrichten Priorität also nicht höher als 0 liegen. Dann werden Nachrichten bei vorübergehender Abwesenheit hinterhergeschickt (msgFwPrioAbsent<TYPE> hat 0 als Standard) und bei längerer Abwesenheit reicht die Priorität nicht aus, um hinterhergeschickt zu werden und die Nachricht bleibt aus.
Bei Push und E-Mail Nachrichten, die auch als eine solche abgesetzt werden, wird generell davon ausgegangen, dass diese immer zugestellt werden sollen (nach dem Motto "Text ist geduldig" und die Automation wird sich hier schon sicher sein, dass sie wirklich etwas mitzuteilen hat). Das würde ich an dieser Stelle auch beim msg-Kommando nicht aufweichen wollen, sonst würde es unlogisch. Du müsstest also, wenn du als Ursprung keine Audio-Nachricht hast, sondern direkt eine Push-Nachricht verschickst, das in deinem eigenen Code abfangen. Ist in DOIF aber ja ganz einfach.
Ich denke aber nochmal drüber nach, ob man das irgendwie doch auch für Text-Nachrichten sinnvoll mit einbauen kann.
Gruß
Julian
Ich habe nun gerade die besprochene Änderung an 75_MSG.pm durchgeführt und alle Dateien, die zum msg-Kommando dazugehören nach ./FHEM/ verschoben.
Entsprechende Hinweise sind in CHANGES und HISTORY ebenfalls aufgenommen, zusätzlich habe ich hier (http://forum.fhem.de/index.php/topic,43447.0.html) eine Ankündigung an die noch verbliebenen Nutzer der bisherigen 75_MSG.pm als Modul platziert.
Damit beginnt ab morgen aus meiner Sicht eine erweiterte Test- und Weiterentwicklungsphase für das Kommando "msg". Die bisherige Nutzerschaft war vermutlich noch nicht so groß; ich erhoffe mir also nun mehr Feedback um zu wissen, an welchen Ecken noch gefeilt werden muss, um das ganze nutzbar zu haben. Und ja: Die Dokumentation in der Commandref steht für mich jetzt auch sehr weit oben auf meiner Todo Liste ;) Wahrscheinlich werde ich mich dort aber auch mehr auf die generelle Anwendung und Syntax beschränken und Beispiele eher in einem Wiki Artikel ergänzen.
Gruß
Julian
PS: Nutzer, die bisher die Dateien manuell aus ./contrib/ runter geladen und in ./FHEM eingespielt haben, sollten diese Dateien unbedingt löschen, um Dopplungen und somit Überschneidungen zu vermeiden. Diese Dateien gilt es zu prüfen und ggf. zu löschen:
./FHEM/99_msg.pm
./FHEM/98_msg.pm
./FHEM/98_message.pm
./FHEM/99_message.pm
./FHEM/97_msgConfig.pm
./FHEM/97_messageConfig.pm
./FHEM/messageSchema.pm
Die neuen Dateien kommen ab morgen per Update und heißen nun final:
./FHEM/75_MSG.pm
./FHEM/75_msgConfig.pm
./FHEM/msgSchema.pm
Gruß
Julian
Läuft
Hallo,
kleines Problem.
Mailversand von der Konsole geht und landet auch im externen Mailkonto:
fhem@fhem:~$ which mail
/usr/bin/mail
fhem@fhem:~$ mail ralf -s "test" <./tempList.cfg
Versand über FHEM-Konsole:
fhem> msg text ralf@fhem test2 test2
ergibt:
2015.11.04 09:25:23 5: msg: typeOr total is 1
2015.11.04 09:25:23 5: msg: start typeOr loop for type(s) text
2015.11.04 09:25:23 5: msg: running loop for type text
2015.11.04 09:25:23 5: msg: recipientOr total is 1
2015.11.04 09:25:23 5: msg: start recipientsOr loop for recipient(s) ralf@fhem
2015.11.04 09:25:23 5: msg: running loop for device ralf@fhem
2015.11.04 09:25:23 5: msg ralf@fhem: Skipping loop for device type 'email' with unmatched message type 'text'
Kann mir da mal jemand auf die Sprünge helfen?
MfG
Da fehlte noch etwas, um auch per "text" direkte E-Mails zu verschicken. Der Fix ist morgen im Update.
Derweil funktioniert natürlich der Typ "mail" statt "text" ;-)
Danke für die Info, aber Mmmmhhhh ...
fhem> msg mail ralf@fhem test2 test2
ergibt:
2015.11.04 13:06:55 5: msg: typeOr total is 1
2015.11.04 13:06:55 5: msg: start typeOr loop for type(s) mail
2015.11.04 13:06:55 5: msg: running loop for type mail
2015.11.04 13:06:55 5: msg: recipientOr total is 1
2015.11.04 13:06:55 5: msg: start recipientsOr loop for recipient(s) ralf@fhem
2015.11.04 13:06:55 5: msg: running loop for device ralf@fhem
2015.11.04 13:06:55 5: msg ralf@fhem: Checking for available routes (triggered by type mail)
2015.11.04 13:06:55 4: msg ralf@fhem: Available routes: screen=0 light=0 audio=0 text=0 push=0 mail=1
2015.11.04 13:06:55 5: msg ralf@fhem: Trying to send message via gateway globalMsg to recipient
2015.11.04 13:06:55 5: msg ralf@fhem: mail route command (Perl): system("echo 'test2 test2' | /usr/bin/mail -s 'System Message' -t 'globalMsg' -a 'MIME-Version: 1.0' -a 'Content-Type: text/html; ch
arset=UTF-8'")
/usr/bin/mail: invalid option -- 't'
usage: mail [-dEIinv] [-a header] [-b bcc-addr] [-c cc-addr] [-s subject] to-addr ...
mail [-dEIiNnv] -f [name]
mail [-dEIiNnv] [-u user]
2015.11.04 13:06:55 3: msg ralf@fhem: ID=1446638815.31576.1 TYPE=mail ROUTE=globalMsg STATUS=OK PRIORITY=0 TITLE='System Message' MSG='test2 test2'
MfG
Es gibt unterschiedliche Versionen von Mail. Habe es mit einem anderen System verglichen.
sudo apt-get install heirloom-mailx
und er kennt -t.
Dafür zickt er jetzt an anderer Stelle:
2015.11.04 13:22:06 4: msg ralf@fhem: Available routes: screen=0 light=0 audio=0 text=0 push=0 mail=1
2015.11.04 13:22:06 5: msg ralf@fhem: Trying to send message via gateway globalMsg to recipient
2015.11.04 13:22:06 5: msg ralf@fhem: mail route command (Perl): system("echo 'test2 test2' | /usr/bin/mail -s 'System Message' -t 'globalMsg' -a 'MIME-Version: 1.0' -a 'Content-Type: text/html; ch
arset=UTF-8'")
MIME-Version: contains invalid character ':'
Content-Type: contains invalid character ':'
No recipients specified
"./dead.letter" 8/208
2015.11.04 13:22:06 3: msg ralf@fhem: ID=1446639726.66057.1 TYPE=mail ROUTE=globalMsg STATUS=OK PRIORITY=0 TITLE='System Message' MSG='test2 test2'
MfG
Das Mail-Kommando ist so systemspezifisch, dass der Default-Wert nicht zwingend funktionieren muss.
Bei wem es nicht funktioniert, der muss auf seine Systemumgebung passend über die Attribute msgCmdMail* entsprechend funktionierende Kommandos hinterlegen.
Für das direkte Senden von Mails ist aber auch noch ein Fehler im Code.
Indirekt über die Adressierung an ein Device (also "msg @devicename Nachricht") und einem msgContactMail Attribut dort für die Mailadresse funktioniert es.
Adressierung an Device klappt leider auch nicht:
attr TX25 msgContactMail ralf@fhem
fhem> msg @TX25 Test3
Ergibt:
2015.11.04 13:57:07 5: msg: typeOr total is 1
2015.11.04 13:57:07 5: msg: start typeOr loop for type(s) text
2015.11.04 13:57:07 5: msg: running loop for type text
2015.11.04 13:57:07 5: msg: recipientOr total is 1
2015.11.04 13:57:07 5: msg: start recipientsOr loop for recipient(s) @TX25
2015.11.04 13:57:07 5: msg: running loop for device @TX25
2015.11.04 13:57:07 5: msg: running loop for type mail
2015.11.04 13:57:07 5: msg: recipientOr total is 1
2015.11.04 13:57:07 5: msg: start recipientsOr loop for recipient(s) @TX25
2015.11.04 13:57:07 5: msg: running loop for device @TX25
MIME-Version: contains invalid character ':'
Content-Type: contains invalid character ':'
No recipients specified
"./dead.letter" 8/202
2015.11.04 13:57:08 1: PERL WARNING: Use of uninitialized value $d in hash element at fhem.pl line 3654.
2015.11.04 13:57:08 1: PERL WARNING: Use of uninitialized value $cmd in hash element at FHEM/SetExtensions.pm line 49.
2015.11.04 13:57:08 1: PERL WARNING: Use of uninitialized value $cmd in concatenation (.) or string at FHEM/SetExtensions.pm line 52.
Liegt das jetzt an der "mail"-Version?
MfG
Ja. Oder am nicht (richtig) definierten msgCmdMail* Attribut, je nachdem wie man es sehen will.
Ich habe für E-Mail jetzt einen weniger komplexen Befehl in die Schema-Datenbank aufgenommen, der dann möglicherweise kompatibler ist.
Dafür fällt die Prioritätsangabe im E-Mail Header weg. Wer so etwas haben möchte, muss sich dann derzeit mit einem manuellen Kommando helfen und dort den Header mit aufnehmen.
Ich überlege mal, ob man unterschiedliche Arten der E-Mail Verarbeitung vordefinieren kann.
Hallo Loredo,
Dein Modul finde ich sehr interessant.
Da ich mit zum Mailversand DebianMail eingerichtet habe, versuche ich das gerade zu integrieren. Aber irgendwie krieg ich die Variablen in DebianMail nicht richtig ausgewertet.
msgCmdMail {DebianMail('\$RECIPIENT','\$TITLE','\$MSG')}
Im Log erhalte ich dann:
2015.11.04 18:00:08 1: sendEmail RCP: \$RECIPIENT
2015.11.04 18:00:08 1: sendEmail Subject: \$TITLE
2015.11.04 18:00:08 1: sendEmail Text: \$MSG
2015.11.04 18:00:08 1: sendEmail Anhang:
2015.11.04 18:00:09 1: sendEmail returned: Nov 04 18:00:09 raspberrypi sendEmail[25794]: ERROR => Can't use improperly formatted email address: \$RECIPIENT
2015.11.04 18:00:09 3: msg xxxx@gmx.de: ID=1446656408.2204.1 TYPE=mail ROUTE=globalMsg STATUS=OK PRIORITY=0 TITLE='System Message' MSG='test'
Er ruft also DebianMail richtig auf, kriegt aber scheinbar die Variablen nicht richtig umgesetzt. Habs auch schon ohne \, mit Verdoppelung von $, mit "" probiert, leider alles ohne Erfolg.
Vielleicht fällt Dir ja auf, wo wohl mein Fehler liegt.
Vielen Dank
Reinhard
Zitat von: Laffer72 am 04 November 2015, 18:04:04
msgCmdMail {DebianMail('\$RECIPIENT','\$TITLE','\$MSG')}
Das entspricht nicht dem korrekten Schema. Die Dinge, die ersetzt werden sollen, werden hier nicht wie normale Variablen angegeben. Richtig muss es also heißen:
attr globalMsg msgCmdMail {DebianMail('%DEVICE%','%TITLE%','%MSG%')}Außerdem ist die richtige Variable hier %DEVICE% und nicht %RECIPIENT%.
Mails werden etwas speziell behandelt, daher ist das da nicht so passend (Mail ist eben ein Legacy Medium ;) ).
Ab morgen hat das msgConfig Modul einen neu hinzugefügten Getter, um sich die Standard Routing Commandos aus der Schema Datenbank anzeigen zu lassen:
get globalMsg routeCmd
AUDIO: DEFAULT COMMANDS
-------------------------------------------------------------------------------
Text2Speech
Priority Normal:
set %DEVICE% tts %MSG%
Priority ShortPrio:
set %DEVICE% tts %MSGSH%
Default Values:
MSGSH = Achtung!
Priority Short:
set %DEVICE% tts %MSGSH%
Default Values:
MSGSH = Hinweis!
SONOSPLAYER
Priority Normal:
set %DEVICE% Speak %VOLUME% %LANG% |%TITLE%| %MSG%
Default Values:
VOLUME = 38
LANG = de
Priority ShortPrio:
set %DEVICE% Speak %VOLUME% %LANG% |%TITLE%| %MSGSH%
Default Values:
VOLUME = 33
MSGSH = Achtung!
LANG = de
Priority Short:
set %DEVICE% Speak %VOLUME% %LANG% |%TITLE%| %MSGSH%
Default Values:
VOLUME = 28
MSGSH = [EMPTY]
LANG = de
AMAD
Priority Normal:
set %DEVICE% ttsMsg %MSG%
Priority ShortPrio:
set %DEVICE% ttsMsg %MSGSH%
Default Values:
MSGSH = Achtung!
Priority Short:
set %DEVICE% ttsMsg %MSGSH%
Default Values:
MSGSH = Hinweis!
LIGHT: DEFAULT COMMANDS
-------------------------------------------------------------------------------
HUEDevice
Priority Normal:
{my $state=ReadingsVal("%DEVICE%","state","off"); fhem "set %DEVICE% blink 2 1"; fhem "sleep 4.25;set %DEVICE%:FILTER=state!=$state $state"}
Priority High:
{my $state=ReadingsVal("%DEVICE%","state","off"); fhem "set %DEVICE% blink 10 1"; fhem "sleep 20.25;set %DEVICE%:FILTER=state!=$state $state"}
Priority Low:
set %DEVICE% alert select
MAIL: USER DEFINED COMMANDS WITH PRECEDENCE
-------------------------------------------------------------------------------
globalMsg (DEVICE TYPE: msgConfig)
Priority Normal:
{system("echo '%MSG%' | /usr/bin/mail -s '%TITLE%' -a 'MIME-Version: 1.0' -a 'Content-Type: text/html; charset=UTF-8' '%DEVICE%'")}
Priority High:
{system("echo '%MSG%' | /usr/bin/mail -s '%TITLE%' -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' '%DEVICE%'")}
Priority Low:
{system("echo '%MSG%' | /usr/bin/mail -s '%TITLE%' -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' '%DEVICE%'")}
MAIL: DEFAULT COMMANDS
-------------------------------------------------------------------------------
fhemMsgMail
Priority Normal:
{system("echo '%MSG%' | /usr/bin/mail -s '%TITLE%' '%DEVICE%'")}
Priority High:
{system("echo '%MSG%' | /usr/bin/mail -s '[High] %TITLE%' '%DEVICE%'")}
Priority Low:
{system("echo '%MSG%' | /usr/bin/mail -s '[Low] %TITLE%' '%DEVICE%'")}
PUSH: DEFAULT COMMANDS
-------------------------------------------------------------------------------
Pushbullet
Priority Normal:
set %DEVICE% message %MSG% | %TITLE% %RECIPIENT%
Priority High:
set %DEVICE% message %MSG% | %TITLE% %RECIPIENT%
Priority Low:
set %DEVICE% message %MSG% | %TITLE% %RECIPIENT%
TelegramBot
Priority Normal:
set %DEVICE% message %RECIPIENT% %TITLE%: %MSG%
Default Values:
RECIPIENT = [EMPTY]
Priority High:
set %DEVICE% message %RECIPIENT% %TITLE%: %MSG%
Default Values:
RECIPIENT = [EMPTY]
Priority Low:
set %DEVICE% message %RECIPIENT% %TITLE%: %MSG%
Default Values:
RECIPIENT = [EMPTY]
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%
Pushover
Priority Normal:
set %DEVICE% msg '%TITLE%' '%MSG%' '%RECIPIENT%' %PRIORITY% '' %RETRY% %EXPIRE% %URLTITLE% %ACTION%
Default Values:
URLTITLE = [EMPTY]
ACTION = [EMPTY]
RETRY = [EMPTY]
RECIPIENT = [EMPTY]
EXPIRE = [EMPTY]
Priority High:
set %DEVICE% msg '%TITLE%' '%MSG%' '%RECIPIENT%' %PRIORITY% '' %RETRY% %EXPIRE% %URLTITLE% %ACTION%
Default Values:
URLTITLE = [EMPTY]
ACTION = [EMPTY]
RETRY = 120
RECIPIENT = [EMPTY]
EXPIRE = 600
Priority Low:
set %DEVICE% msg '%TITLE%' '%MSG%' '%RECIPIENT%' %PRIORITY% '' %RETRY% %EXPIRE% %URLTITLE% %ACTION%
Default Values:
URLTITLE = [EMPTY]
ACTION = [EMPTY]
RETRY = [EMPTY]
RECIPIENT = [EMPTY]
EXPIRE = [EMPTY]
Fhemapppush
Priority Normal:
set %DEVICE% message '%TITLE%: %MSG%' %ACTION%
Default Values:
ACTION = [EMPTY]
Priority High:
set %DEVICE% message '%TITLE%: %MSG%' %ACTION%
Default Values:
ACTION = [EMPTY]
Priority Low:
set %DEVICE% message '%TITLE%: %MSG%' %ACTION%
Default Values:
ACTION = [EMPTY]
PushNotifier
Priority Normal:
set %DEVICE% message %TITLE%: %MSG%
Priority High:
set %DEVICE% message %TITLE%: %MSG%
Priority Low:
set %DEVICE% message %TITLE%: %MSG%
SCREEN: DEFAULT COMMANDS
-------------------------------------------------------------------------------
ENIGMA2
Priority Normal:
set %DEVICE% msg %ENIGMA2_TYPE% %TIMEOUT% %MSG%
Default Values:
ENIGMA2_TYPE = info
TIMEOUT = 8
Priority High:
set %DEVICE% msg %ENIGMA2_TYPE% %TIMEOUT% %MSG%
Default Values:
ENIGMA2_TYPE = attention
TIMEOUT = 12
Priority Low:
set %DEVICE% msg %ENIGMA2_TYPE% %TIMEOUT% %MSG%
Default Values:
ENIGMA2_TYPE = message
TIMEOUT = 8
AMAD
Priority Normal:
set %DEVICE% screenMsg %TITLE%: %MSG%
Priority High:
set %DEVICE% screenMsg %TITLE%: %MSG%
Priority Low: set %DEVICE% screenMsg %TITLE%: %MSG%
Außerdem kann man damit auch prüfen, welcher Befehl für ein bestimmtes Device hergenommen wird. Wenn es irgendwo ein msgCmd* Attribut gibt und es hier zum tragen kommt, dann wird das entsprechend angezeigt:
get globalMsg routeCmd mail rr_Julian
MAIL: USER DEFINED COMMANDS WITH PRECEDENCE
-------------------------------------------------------------------------------
rr_Julian (DEVICE TYPE: ROOMMATE)
Priority Normal:
{system("echo '%MSG%' | /usr/bin/mail -s '%TITLE%' -a 'MIME-Version: 1.0' -a 'Content-Type: text/html; charset=UTF-8' '%DEVICE%'")}
Priority High:
{system("echo '%MSG%' | /usr/bin/mail -s '%TITLE%' -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' '%DEVICE%'")}
Priority Low:
{system("echo '%MSG%' | /usr/bin/mail -s '%TITLE%' -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' '%DEVICE%'")}
MAIL: DEFAULT COMMANDS
-------------------------------------------------------------------------------
fhemMsgMail
Priority Normal:
{system("echo '%MSG%' | /usr/bin/mail -s '%TITLE%' '%DEVICE%'")}
Priority High:
{system("echo '%MSG%' | /usr/bin/mail -s '[High] %TITLE%' '%DEVICE%'")}
Priority Low:
{system("echo '%MSG%' | /usr/bin/mail -s '[Low] %TITLE%' '%DEVICE%'")} In diesem Beispiel wird dann angezeigt, ob für rr_Julian ein msgCmdMail* Attribute gefunden werden konnten und wenn ja, wie das Messaging Schema dazu aussieht. Zusätzlich wird darunter der Standardbefehl aus der Schema Datenbank zum Vergleich angezeigt (sofern dort vorhanden).
Statt einen Devicenamen kann man auch einen Modulnamen angeben, um speziell eine Info für ein bestimmtes Modul zu erhalten. Außerdem können mehrere Typen oder Devices mit Komma getrennt angegeben werden, also z.B.:
# zeigt an, welche Default Kommandos für das FHEM Modul SONOSPLAYER hinterlegt sind
get globalMsg routeCmd audio SONOSPLAYER
# Listet alle Default Kommandos für Module auf, die light oder screen verarbeiten können
get globalMsg routeCmd light,screen
# Zeigt an, ob die Geräte device1 und device2 light eigene Kommandos für light und screen definiert haben oder die Standard
get globalMsg routeCmd light,screen device1,device2
Danke für die schnelle Reaktion.
Deine Lösung führt mich nur teilweise zum Erfolg.
2015.11.04 18:19:06 1: sendEmail RCP: %RECIPIENT%
2015.11.04 18:19:06 1: sendEmail Subject: System Message
2015.11.04 18:19:06 1: sendEmail Text: test
2015.11.04 18:19:06 1: sendEmail Anhang:
2015.11.04 18:19:07 1: sendEmail returned: Nov 04 18:19:07 raspberrypi sendEmail[26601]: ERROR => Can't use improperly formatted email address: %RECIPIENT%
2015.11.04 18:19:07 3: msg xxx@gmx.de: ID=1446657546.87072.1 TYPE=mail ROUTE=globalMsg STATUS=OK PRIORITY=0 TITLE='System Message' MSG='test'
TITLE und MSG übernimmt er jetzt. Aber bei der Mail-Adresse hat er immer noch die Variable.
Da warst du zu schnell. Hatte ich oben bereits ergänzt. Pls read again ;)
Jetzt bin ichs nochmal... ;D
Nachdem ich in globalMsg
attr globalMsg msgContactMail xxx@gmx.de
gesetz habe und den Befehl
msg @globalMsg test test
abgesetzt habe steht im Log folgendes:
2015.11.04 23:23:29 1: sendEmail RCP: xxx\@gmx.de
2015.11.04 23:23:29 1: sendEmail Subject: System Message
2015.11.04 23:23:29 1: sendEmail Text: test test
2015.11.04 23:23:29 1: sendEmail Anhang:
2015.11.04 23:23:31 1: sendEmail returned: Nov 04 23:23:30 raspberrypi sendEmail[10349]: WARNING => The address [xxx\@gmx.de] seems to contain invalid characters: continuing anywayNov 04 23:23:31 raspberrypi sendEmail[10349]: WARNING => The address [xxx\@gmx.de] seems to contain invalid characters: continuing anywayNov 04 23:23:31 raspberrypi sendEmail[10349]: WARNING => The recipient <xxx\@gmx.de> was rejected by the mail server, error follows:Nov 04 23:23:31 raspberrypi sendEmail[10349]: WARNING => Received: 501 Syntax error in parameters or argumentsNov 04 23:23:31 raspberrypi sendEmail[10349]: ERROR => Exiting. No recipients were accepted for delivery by the mail server.
2015.11.04 23:23:31 3: msg globalMsg: ID=1446675809.29994.1 TYPE=mail ROUTE=xxx@gmx.de STATUS=OK PRIORITY=0 TITLE='System Message' MSG='test test'
Also es wird scheinbar durch msg versucht das @ zu maskieren. Wie kann ich das unterbinden?
Danke schonmal
Reinhard
Zitat von: Laffer72 am 04 November 2015, 23:37:33
Also es wird scheinbar durch msg versucht das @ zu maskieren. Wie kann ich das unterbinden?
Ich denke eigentlich die Maskierung muss sein, denn ich bekomme ohne sie bei mir einen Fehler:
Global symbol "@gmx.de" requires explicit package name at (eval 3832) line 1.
Du kannst in 75_MSG.pm die Zeile 1815 löschen, damit das @ nicht mehr maskiert wird.
Derweil habe ich ein Update eingecheckt, was eine Maskierung nun hoffentlich auch für system() überflüssig macht.
Zitat von: Laffer72 am 04 November 2015, 23:37:33
... und den Befehl
msg @globalMsg test test
abgesetzt ...
@globalMsg ist hier übrigens überflüssig, da ohne Angabe eines Empfängers automatisch auf globalMsg zurückgegriffen wird.
Den Nachrichtentitel musst du als |test| angeben, damit er als Titel erkannt wird. Richtig ist also:
msg |Test Titel| Nachrichtentext
Danke für die Hilfe.
Nachdem ich die Zeile 1815 gelöscht habe, klappt es jetzt und die Mail geht raus.
Ich weiß ja, dass ich die Doku noch liefern muss ::)
Ein sehr einfaches Beispiel für die Nutzung des neuen msg-Kommandos habe ich gerade im Zusammenhang mit einer Anwesenheitssteuerung hier (http://forum.fhem.de/index.php/topic,19040.msg356330.html#msg356330) erklärt. Ich denke das ist ein durchaus recht häufiger Anwendungsfall, denn ich las schon öfter, dass einige hier ihren Bewohnern beim Verlassen der Wohnung Nachrichten per Push "hinterher" schicken.
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
Zitat von: Loredo am 13 Oktober 2015, 12:58:01
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
msgContactPush
pushmsgnun 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
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:
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?
Zitat von: r_knipp am 11 November 2015, 21:15:16
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).
Zitat von: r_knipp am 11 November 2015, 21:15:16
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:
# 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.
Zitat von: kjmEjfu am 13 November 2015, 17:24:08
Wie funktioniert das denn mit dem msgCmd im userattr eines Devices?
Also in der globalMsg habe ich definiert
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:
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:
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 ;) )
Zitat von: Schlimbo am 13 November 2015, 23:00:57
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.
Zitat von: Schlimbo am 13 November 2015, 23:00:57Habe aber auch einige "msgCMD" Kommandos in meiner Konfiguration: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). ;)
Zitat von: r_knipp am 11 November 2015, 21:15:16
ist es richtig, dass ENIGMA2 kein Title unterstützt?
Ja, das ist von der ENIGMA2 API nicht vorgesehen.
Danke für deine Antwort.
Ja, meine msgCmd stammen noch aus der Anfangszeit des Moduls, muss ich mal umstellen.
Zitat von: Loredo am 14 November 2015, 15:52:34
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?
Der Post ist da wohl noch nicht angepasst. Es ist überall %KEY%
Edit: Post angepasst.
Zitat von: Loredo am 14 November 2015, 15:25:42
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 8)
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
Zitat von: kjmEjfu am 15 November 2015, 15:22:14
Ü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.
Zitat von: Loredo am 15 November 2015, 15:28:38
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
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
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?
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:
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:
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.)
Zitat von: kjmEjfu am 15 November 2015, 16:29:26Ich 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.
Zitat von: Spook112 am 15 November 2015, 16:33:13
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.
Zitat von: Spook112 am 15 November 2015, 16:33:13
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.
Zitat von: Spook112 am 15 November 2015, 16:33:13
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.
Zitat von: Spook112 am 15 November 2015, 16:33:13
(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.
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
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
msg |FHEM Warnmeldung| Fenster im Arbeitszimmer wurde geöffnet
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.
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
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:
AZ_Fenster:basicSet:.* "echo "Fenster im Arbeitszimmer wurde geöffnet" | mail -s "FHEM Warnmeldung" -r "FHEM@@meine.domain" webmaster@@meine.domain"eben so:
AZ_Fenster:basicSet:.* msg |FHEM Warnmeldung| Fenster im Arbeitszimmer wurde geöffnetFunktioniert (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.
SZE_Fenster:battery:.* msg |FHEM Warnmeldung| Der Wert für die Batterie des Fensterkontaktes $NAME liegt bei: $EVENTAuch 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:
SZE_Fenster:battery:100% msg |FHEM Warnmeldung| Der Wert für die Batterie des Fensterkontaktes $NAME liegt bei: $EVENTversucht, 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.
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 ;)
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:
msg push @rr_Ronny 0 |Test| Nachricht
Ergebnis im Log:
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:
msg push @WhatsApp.Ronny 0 |Test| Nachricht
Gleiches Ergebnis im Log:
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
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 8)
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:
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:
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 8) )
Du kannst dann auch überprüfen, welches Schema für WhatsApp.Ronny verwendet wird, wenn darüber verschickt wird:
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%
Das selbe Vorgehen gilt übrigens für alle bereits bekannten oder noch unbekannten FHEM Module :D
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 (http://forum.fhem.de/index.php/topic,39983.msg354034.html#msg354034)
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 (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
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.
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
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.
Okay, das passt. Da kann ich jetzt mit meinen WIFILights und dem SB_PLAYER spielen...
Ronny
Wenn da allgemeine Befehls-Schemata bei herausfallen, gerne hier posten, ich nehme die dann mit in die Datenbank auf ;)
Trotz mehrfachen durcharbeitens dieses Threads (oder gerade deswegen) habe ich ein Verständnis Problem.
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.
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?
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:?
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 ;-)
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.
Ü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
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!
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.
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.
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?
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 NachrichtSomit 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 Nachrichtgeht 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.
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
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 ;)
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!
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
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"}]
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.
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
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
Zitat von: gandy am 28 Januar 2016, 18:15:00
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.
Zitat von: inoma am 02 Februar 2016, 00:24:23
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.
Zitat von: inoma am 02 Februar 2016, 00:24:23
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:
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.
Zitat von: Schlimbo am 07 Februar 2016, 01:18:05
mir ist gerade aufgefallen, dass bei dem "screen" hinterlegten "XBMC" Befehlen etwas nicht stimmt:
...
Vor $timeout fehlt das "my".
Danke, habe ich korrigiert.
Zitat von: Schlimbo am 07 Februar 2016, 01:18:05
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%"
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 (http://forum.fhem.de/index.php/topic,39983.msg376876.html#msg376876), hier (http://forum.fhem.de/index.php/topic,39983.msg384612.html#msg384612) und hier (http://forum.fhem.de/index.php/topic,39983.msg386429.html#msg386429) 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.
Zitat von: Loredo am 07 Februar 2016, 14:45:10
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:
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:
attr globalMsg msgCmdScreen set raspbmc msg "%TITLE%" "%MSG%" 5000 infoGruß Schlimbo
Zitat von: Schlimbo am 08 Februar 2016, 18:40:34
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.
Zitat von: Schlimbo am 08 Februar 2016, 18:40:34
Um momentan Nachrichte an XBMC anzeigen zu können nutze ich das msgCmd Attribut:
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:
attr globalMsg msgCmdScreen set %DEVICE% msg "%TITLE%" "%MSG%" 5000 info
Ü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:
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:
attr globalMsg msgContactScreen raspbmc
Gruß
Julian
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
Zitat von: Loredo am 17 Januar 2016, 02:04:15
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"}]
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:
msg audio @Sonos_Wohnzimmer Hallo Welt O[{"VOLUME":"8"}]
spiele den Text in der Lautstärker ,, 8" ab.
Ein
msg audio @Sonos_Wohnzimmer Hallo Welt O[{"VOLUME":"9"}]
jedoch erhöht die Lautstärke nicht um eins sonder auf ,,38". Und
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
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:
msg audio @Sonos_Bedroom |Hint| Gute Nacht! O[{"VOLUME":"8"}]
msg audio @Sonos_Bedroom |Hint| Gute Nacht! O[{'VOLUME':'8'}]
geht auch:
msg audio @Sonos_Bedroom |Hint| Gute Nacht! O[{"VOLUME":8}]
msg audio @Sonos_Bedroom |Hint| Gute Nacht! O[{'VOLUME':8}]
geht nicht:
msg audio @Sonos_Bedroom |Hint| Gute Nacht! O[{"VOLUME":"8"}]
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
Zitat von: raimundl am 15 Februar 2016, 21:54:58
Hallo Danke!!!
Hallo Bitte :-)))
Zitat von: raimundl am 15 Februar 2016, 21:54:58
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.
Zitat von: raimundl am 15 Februar 2016, 21:54:58
(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.
Zitat von: raimundl am 15 Februar 2016, 21:54:58
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).
Zitat von: raimundl am 15 Februar 2016, 21:54:58
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.ä.).
Danke für die ausführliche Antwort!
Ich werde nun tiefer eintauchen.
LG
Was ist zu tun, wenn beim Versuchen den msg zu Befehl zu verwenden, folgende Meldung kommt?
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)?
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
Hallo,
Diesem Wunsch möchte ich mich sehr gerne anschließen.
Danke
Ist bisschen frech, aber darf ich kurz herauf aufmerksam machen?
https://forum.fhem.de/index.php/topic,19040.msg447277.html#msg447277
Grüße
Leon
Zitat von: justme1968 am 25 April 2016, 19:00:45
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 ;-)
für die queue gibt es denke ich zwei möglichkeiten:
wenn es für den anwender direkt sichtbar sein soll: in readings die bei save automatisch gespeichert werden
wenn intern reicht: in irgendeiner datenstriuktur die dir passt. du kannst dich dann an global:SAVE hängen und selber speichern. serialisieren kannst du mit Data::Dumper, der Rückweg geht mit eval. beispiele gibt es in LightScene, readingsHistory und FB_CALLLIST.
oder du speicherst intern und baust noch etwas zum anzeigen so wie ebenfalls in LightScene, readingsHistory und FB_CALLLIST.
gruss
andre
ps: du bist genau so entwickler
gruss
andre
@Loredo: es ist mir gerade aufgefallen, dass 75_MSG.pm ohne commandref Doku kommt, "No documentation here yet, sorry." zaehlt nicht als Doku :) Koenntest du das bitte in der naechsten Zeit nachschieben? Es waere auch Anderen gegenueber fair, denen ich das Verteilen eines Moduls wg. fehlender Doku verweigere.
Zitat von: rudolfkoenig am 04 Juni 2016, 15:10:59zaehlt nicht als Doku :) Koenntest du das bitte in der naechsten Zeit nachschieben?
Ja, ich bin dran.
Ich habe einen recht hohen Anspruch an die Doku und wollte sie daher nicht so hinro**** :)
Leider kommt in letzter Zeit immer was dazwischen und ganz Feature-complete ist der aktuelle Stand auch noch nicht. Es lohnt sich aber wohl inzwischen den Ist-Stand zu dokumentieren, da die bisherigen Rückmeldungen darauf schließen lassen, dass sich viel grundlegendes nicht mehr ändern und es eher Erweiterungen und Ergänzungen geben wird.
Zitat von: karl0123 am 25 April 2016, 08:33:41
Was ist zu tun, wenn beim Versuchen den msg zu Befehl zu verwenden, folgende Meldung kommt?
Unknown command msgconfig, try help.
Bekomme auch diese Meldung. :(
nach einem reload 75_MSG gings wieder
Zitat von: kumue am 08 Juni 2016, 02:24:20
Bekomme auch diese Meldung. :(
Der Befehl lautet auch "msg", nicht "msgconfig" ;-)
Es hat auch niemand geschrieben, dass er den Befehl "msgconfig" verwendet. Die Fehlermeldung wurde gepostet und die lautet tatsächlich (erstmal) unsinnigerweise auf msconfig. Das gleiche Phänomen habe ich übrigens auch in meiner Installation gehabt. Da mich das Modul aber nur am Rande interessierte, habe ich es nicht weiter verfolgt. Und ja, der Befehl msg wurde verwendet.
P.S.: ich hatte damals schon heraus gefunden, dass der Fehler mir einer eignen Perl-Funktion für z.B. TTS zusammen hing (die standalone wunderbar funktioniert) und da habe ich das Interesse verloren.
Zitat von: Loredo am 08 Juni 2016, 10:24:32
Der Befehl lautet auch "msg", nicht "msgconfig" ;-)
Schon klar, ich hatte auch msg eingegeben und nicht msgconfig... ;)
Zitat von: SirUli am 14 Dezember 2015, 21:15:41
Kommt die Tage
Die Tage sind rum ;) https://forum.fhem.de/index.php/topic,54863.0.html
Hoffe das ist in deinem Sinne verwendet
Viele Grüße,
Uli
Meine lieben Freunde. Habe jetzt nen Abend lang versucht (als nicht-entwickler) die Verwendung der schönen neuen msg-Welt zu erschliessen und habe jetzt nach stunden trial and error keinen bock mehr. Folgendes treibt mich um:
1. Finde ich die Idee zu "msg" und das was ich bisher an Anwendung (speziell mit "Residents") gesehen habe sehr cool.Danke Loredo!
2. Kann mir jemand eine kurze Einweisung geben, wie ich "msg" mit Residents, Rommate und Pushbullet verwenden kann
(quasi einen aktuellen Stand mit nem generischen sample)
3. Glaube ich, ich bin damit nicht allein und eine Doku (wenn auch hinge**tzt :-)) hilft einigen Usern
THX,
Jakob
Ich muss leider auch mal kurz den Zeigefinger heben. Es wäre echt super, wenn du (Loredo) langsam mal eine Doku einstellen würdest :) Der Thread hilft viel, aber auch der wird länger und ne gute Doku ist einfach immer schöner zu lesen. Auch, wenn sie dem Entwickler am wenigsten Spaß macht.
Das hat nichts mit "wenig Spaß" zu tun, sondern vielmehr mit der dafür notwendigen Zeit für Ruhe und Sorgfalt.
Den "Zeigefinger zu heben" hilft dabei keinen Deut weiter und führt nur dazu, dass ich tatsächlich keine Lust dazu verspüre die Infos, die ja im allerersten Beitrag dieses Threads zu ~90% bereits eine prima Einführung geben, für die CommandRef besser aufzubereiten ::) .
Natürlich muss man es auch wollen sich damit zu beschäftigen; daran änderte eine CommandRef allerdings auch wenig - das lesen, verstehen und herumprobieren kann man niemandem abnehmen (besonders letzteres finde ich unheimlich wichtig!). Der msg-Befehl ist sehr redefreudig (sowohl direkt als auch im Logfile bei entsprechendem Loglevel), wenn man ihn interaktiv verwendet. Das soll explizit dazu einladen auch die Arbeitsweise nachzuvollziehen. Das ist aber für die normale Verwendung gar nicht notwendig.
Die Entscheidung den msg-Befehl zunächst mit Hinweis auf diesen Thread zu veröffentlichen habe ich auch getroffen, weil ich vorher so gut wie kein Feedback erhalten habe um herauszufinden, ob einige der Konzepte so auch in der Praxis brauchbar sind. Die Veröffentlichung sollte mehr Aufmerksamkeit schaffen, was auch teilweise geklappt hat (der Featurewunsch von Leon und Andre hat mich da sehr gefreut, auch wenn ich dafür noch keine Zeit hatte und die Doku sicherlich auch vorher erledigt gehört).
Trotzdem ist noch einiges offen, z.B. habe ich für die msg-Datenbank und deren Standard-Befehle für alle Fhem Module, die etwas mit Benachrichtigung zu tun haben, bekommen. Meine Sorge ist bei vielen Funktionen auch, dass ich sie bei der Dokumentation in gewisser Weise fest zementiere und dann nach ewigen Zeiten eine valide Rückmeldung kommt wie "das ist ja totaler Murks", andere sich aber damit dann schon arrangiert haben und es dann schwierig wird ohne einen Bruch diese Dinge dann im Sinne aller gerade zu rücken.
Vielleicht ist es aber auch mein eigener Anspruch direkt alle enthaltenen Funktionen penibel dokumentiert zu wissen. Bleibe ich dabei allerdings oberflächlich ist die Gefahr groß, dass ich nicht das allumfängliche Feedback bekomme und auch nicht erkennbar ist, welches Potential ich mit dem msg-Befehl verbinde.
Ich hoffe ich konnte neben meinem zeitlichen Problem noch etwas die Umstände drum herum erläutern.
Nimm den Zeigefinger nicht zu ernst ;) Und das es an der Zeit liegt ist mir klar.
Ich bin gerade dabei mich mit msg anzufreunden und es zu testen. Aber zum Beispiel schaffe ich es aktuell noch nicht, wie ich mittels Msg ein Pushover Nachricht an ein bestimmtes Device senden kann und nicht immer an alle. Und da muss man hier halt viel mehr im Thread suchen und blättern, als es nötig wäre, wenn es eine richtige Doku geben würde. Natürlich Suche ich dann auch etc. und finde es sicher auch irgendwann noch. Aber du musst auch verstehen, dass es halt eigentlich nicht den Regeln von FHEM entspricht einfach auf den Thread zu verweisen und es auch die User vermutlich ein Wenig abschreckt, wenn es noch keine wirkliche Doku gibt oder einen Wiki Eintrag und man schon vorher erkennt, dass es sich hierbei um ein relativ mächtiges Tool handelt ;) Ich zB wollte schon lange Msg umsetzten und habe immer auf eine Doku gehofft. Da diese wohl nicht kommt, habe ich mich heute trotzdem dran gesetzt.
Und besonders, da der erste Thread das letzte Mal im Nov. 2015 geändert wurde und sich seit dem sicher noch etwas getan hat. Daher wäre es top, wenn zumindest der erste Post aktuell gehalten werden würde. Sollte es dieser sein und sich seit Nov. 2015 nichts geändert haben, dann nehme ich alles zurück und behaupte das Gegenteil :D
Zitat von: Amenophis86 am 31 Juli 2016, 15:31:55
Und besonders, da der erste Thread das letzte Mal im Nov. 2015 geändert wurde und sich seit dem sicher noch etwas getan hat. Daher wäre es top, wenn zumindest der erste Post aktuell gehalten werden würde. Sollte es dieser sein und sich seit Nov. 2015 nichts geändert haben, dann nehme ich alles zurück und behaupte das Gegenteil :D
In der Tat hat sich seit dem nichts verändert.
Die ganze manuelle Formatierung für die CommandRef und die verständliche/präzise Neuformulierung in Englisch braucht eben viel Zeit. Du kannst aber davon ausgehen, dass die CommandRef inhaltlich nichts weiter enthalten würde, als der erste Post und sich im wesentlichen nur in Darstellung und Sprache unterscheiden wird.
Zitat von: Amenophis86 am 31 Juli 2016, 15:31:55
Aber zum Beispiel schaffe ich es aktuell noch nicht, wie ich mittels Msg ein Pushover Nachricht an ein bestimmtes Device senden kann und nicht immer an alle
Ein solches Detail wird es auch niemals in der CommandRef geben können, denn das Format dazu hängt ganz entscheidend vom Ziel-Modul selbst ab, da es hier halt leider keinen allgemeinen Standard gibt (das versucht ja msg zumindest unter anderem ganz allgemein herzustellen; auch wenns für die Adressierung eines speziellen Sub-Devices eben sehr schwierig ist). Man kann sich dem nähern, indem man in der msg-Schemadatenbank nachschaut, wie Pushover vom msg-Befehl angesprochen wird:
get globalMsg routeCmd push Pushover
PUSH: USER DEFINED COMMANDS WITH PRECEDENCE
-------------------------------------------------------------------------------
Pushover (DEVICE TYPE: Pushover)
Priority Normal:
[DEFAULT COMMAND]
Priority High:
[DEFAULT COMMAND]
Priority Low:
[DEFAULT COMMAND]
PUSH: DEFAULT COMMANDS
-------------------------------------------------------------------------------
Pushover
Priority Normal:
set %DEVICE% msg '%TITLE%' '%MSG%' '%RECIPIENT%' %PRIORITY% '%Pushover_SOUND%' %RETRY% %EXPIRE% %URLTITLE% %ACTION%
Default Values:
EXPIRE = [EMPTY]
RECIPIENT = [EMPTY]
RETRY = [EMPTY]
Pushover_SOUND = [EMPTY]
URLTITLE = [EMPTY]
ACTION = [EMPTY]
Priority High:
set %DEVICE% msg '%TITLE%' '%MSG%' '%RECIPIENT%' %PRIORITY% '%Pushover_SOUND%' %RETRY% %EXPIRE% %URLTITLE% %ACTION%
Default Values:
RETRY = 120
Pushover_SOUND = [EMPTY]
RECIPIENT = [EMPTY]
EXPIRE = 600
ACTION = [EMPTY]
URLTITLE = [EMPTY]
Priority Low:
set %DEVICE% msg '%TITLE%' '%MSG%' '%RECIPIENT%' %PRIORITY% '%Pushover_SOUND%' %RETRY% %EXPIRE% %URLTITLE% %ACTION%
Default Values:
ACTION = [EMPTY]
URLTITLE = [EMPTY]
RETRY = [EMPTY]
Pushover_SOUND = [EMPTY]
RECIPIENT = [EMPTY]
EXPIRE = [EMPTY]
Daran sieht man, dass es eine Variable %RECIPIENT% gibt, für die es keinen vorbelegten Wert gibt. Wenn man nun weiß, dass in der Pushover CommandRef steht, dass an dieser Stelle der Devicename stehen muss, um nur dieses Device anzusprechen, muss man nur noch wissen wie man die die optionale Variable RECIPIENT füllen muss. Das passiert mit einem JSON Addon am Ende der Nachricht:
msg @PushoverDevice |Betreffzeile1| Diese Nachricht soll nur an das iPhone des Standard-Users geschickt werden O[{"RECIPIENT":"iPhone"}]
msg @PushoverDevice |Betreffzeile2| Diese Nachricht soll nur an das iPhone eines speziellen Users ungleich des Standard-Users geschickt werden O[{"RECIPIENT":"u2asdfghjklqwertzuiopyxcvbnmac:iPhone"}]
Hierfür fehlt bisher noch die gleiche Funktion auch als Attribut per Default zu hinterlegen (weshalb diese Funktion auch noch nicht im ersten Post dokumentiert ist). Ob diese Lösung gangbar ist oder ob jemand eine bessere Idee hat das für alle Module flexibel und generisch zu implementieren, dafür fehlt ebenfalls ein Feedback.
Und das führt mich wieder zu meinem vorigen Beitrag weshalb die CommandRef Doku so schwer zu erstellen ist... Insofern kann man sagen: Alles was im ersten Post dokumentiert ist, kann man als gegeben ansehen. Der Rest, der sich erst beim lesen dieses Threads erklärt, ist zum testen gedacht und dafür wünsche ich mir Feedback.
Ich danke dir für die ausführliche Erklärung.
Dachte, dass so etwas dann in der CommandRef stehen würde. Aber man könnte es zumindest im Wiki Artikel unterbringen. Natürlich muss man dafür auch die Zeit haben. Das wiederum könnte ich übernehmen, aber dafür fehlt mir aktuell noch zu viel das Verständnis für msg.
Dann drücke ich dir die Daumen, dass du die Zeit findest für die Doku. Und bezüglich der Test werde ich mich melden, wenn mir etwas auffällt. Auf jeden Fall kann ich schon mal sagen, dass ich die Funktion nur an einen bestimmten zu senden brauche. Daher danke für die Info :)
hi,
nachdem ich das msg-Modul jetzt schon etwas länger im Einsatz habe, bin ich jetzt dabei die audio,light und follow-me funktionen zu testen. Dazu habe ich einei Fragen:
Ich habe für ein Roommate für alle 3 Kontaktmöglichkeiten Devices hinterlegt. Zusätzlich habe ich msg_Rooms erstellt und dort auch die Devices der jeweiligen Location eingetragen.
Wenn ich nun eine audio-Nachricht an ein Roommate schicke, dann werden die bei dem Roommate eingetragenen Devices ignoriert und die von der Location genommen, und die Ausgabe erfolgt auch auf Devices die nicht beim Roommate, wohl aber bei dem msg_Room der location des Roommates eingetragen sind, oder?
Der Hintergrund ist folgender:
Ich mache die Location-Bestimmung eher ungenau über 2 Access-Points (EG und 1.OG). Für die beiden Etage habe ich die msg_Rooms angelegt. Jetzt kann es aber sein, dass Roommate 1 in Schlafzimmer 1 ein Tablet mit Sprachausgabe hat und Roommate 2 in Schlafzimmer 2 ein weiteres. Die Schlafzimmer befinden sich aber in der selben Etage.
Also wäre doch eine Kombination aus msg_Room und den msgContact*-Devices der Roommates sinnvoll.
Ich weiß nicht, wie viel Aufwand das ist, diese logik noch mit einzubauen, oder ob es außer für mich noch andere Anwender gibt für die das interessant wäre... Das macht das ganze von der Config her natürlich noch ein bisschen komplizierter ;-)
Gruß Michael
Ich bin gerade erst dabei mich dem msg-Modul zu nähern. Mächtig, mächtig. Und wichtig.
Ich hatte vor über 10 Jahren mal so etwas ähnliches versucht. Person A möchte Person B erreichen. Dazu gibt es verschieden gut geeignete Kanäle (E-Mail, Telefonanruf, SMS, ...). Person A und B haben diverse Endgeräte, die manche dieser Kanäle unterstützen. Und sowohl der Sender als auch der Empfänger haben Präferenzen für diese Kanäle in Abhängigkeit von ihrem Ort und ihrer Situation (im Auto eher das Telefon, im Büro vielleicht die E-Mail, in einer Besprechung eventuell die SMS). Das ganze konnte jeder Nutzer in Regeln festhalten, etwa "Wenn ich in einem Besprechungsraum bin und in meinem Kalender ein Termin steht (= Situation Besprechung), dann bin ich nur per SMS erreichbar, es sei denn meine Frau oder mein Chef wollen mich dringend (Priorität!) telefonisch erreichen.". Nach ein paar Monaten Probelauf haben wir das wieder eingestampft, weil es zu komplex war. Die Leute wussten nicht mehr warum was wann wie passierte oder eben nicht passierte, d.h. welche ihrer Regeln triggerte oder eben nicht. Und wenn man nicht mehr weiß warum etwas geschieht, dann ist besonders der WAF gleich null und die Frustration unendlich.
Was ich daraus gelernt habe: normale Nutzer dürfen nicht durch Komplexität und Variabilität erschlagen werden. Ein Feueralarm lässt immer die Brandmelder tröten, eine fertige Waschmaschine meldet sich immer per Pushover beim Hausmann, die offen stehende Garage lässt immer die Lampe im Flur rot leuchten. Klare Konzepte wie "dieses iPad gehört Roommate 1" oder "dies ist das Schlafzimmer von Roommate 2" sind einfach zu verstehen und deshalb finde ich die Idee von @I2r ganz gut. Vermeiden würde ich so Dinge, die zu granular den aktuellen Aufenthaltsort oder die Stimmung oder die Situation berücksichtigen.
So genug theoretisiert. Morgen mache ich mich daran zu überlegen wie ich msg in meinem System systematisch einsetzen kann. Also erst einmal alles lesen, was hier schon alles steht.
Zitat von: l2r am 25 August 2016, 11:50:58
Wenn ich nun eine audio-Nachricht an ein Roommate schicke, dann werden die bei dem Roommate eingetragenen Devices ignoriert und die von der Location genommen, und die Ausgabe erfolgt auch auf Devices die nicht beim Roommate, wohl aber bei dem msg_Room der location des Roommates eingetragen sind, oder?
Genau so funktioniert's.
Zitat von: l2r am 25 August 2016, 11:50:58
Ich mache die Location-Bestimmung eher ungenau über 2 Access-Points (EG und 1.OG). Für die beiden Etage habe ich die msg_Rooms angelegt. Jetzt kann es aber sein, dass Roommate 1 in Schlafzimmer 1 ein Tablet mit Sprachausgabe hat und Roommate 2 in Schlafzimmer 2 ein weiteres. Die Schlafzimmer befinden sich aber in der selben Etage.
Also wäre doch eine Kombination aus msg_Room und den msgContact*-Devices der Roommates sinnvoll.
Ich weiß nicht, wie viel Aufwand das ist, diese logik noch mit einzubauen, oder ob es außer für mich noch andere Anwender gibt für die das interessant wäre... Das macht das ganze von der Config her natürlich noch ein bisschen komplizierter ;-)
Das ist wohl in erster Linie ein Ortungs-Problem bzw. ein Problem mit dessen Genauigkeit.
Ich habe aber nicht verstanden, in welchen anderen Zusammenhang msg_Room mit dem msgContact Attribut gebracht werden soll. Das müsstest du mal genauer erklären, denn wie du ja richtig geschrieben hast wird bei einer übereinstimmenden Location und wenn für diese ein gesondertes Gerät für die Audioausgabe hinterlegt wurde eben dieses Gerät genommen. Ich sehe jetzt nicht, wie die msgContact Information eines Roommate Devices hier wieder mit eingespielt werden soll, dann diese Informationen sind alle ortsunabhängig.
Wenn die beiden Räume so nah beieinander liegen, brauchst du wohl eher eine bessere Auflösung für die Ortung, die mehr als nur das Stockwerk umfasst. Dafür eignen sich momentan in erster Linie einzelne iBeacons. Die Ortung darüber, in welchem WLAN AccessPoint ich eingebucht bin, macht schon aus technologischer Sicht keinen Sinn. Denn in welchen AP sich ein Gerät einloggt wählt es selbst aus, nicht der AP (selbst wenn man welche mit intelligentem WLAN-Controller wie z.B. von Unifi hat). Und da man für die korrekte Abdeckung eine gewisse Überlappung braucht gibt es immer Punkte, wo es quasi dem Zufall überlassen ist wo sich das Gerät einbucht.
Theoretisch kann man mit einigen iBeacons pro Raum sogar eine Ortung innerhalb desselben machen (und dann auch besser von den Beacons unterscheiden, die aus dem Nachbarraum noch rüber strahlen). Die Triangulation aus mehreren Punkten muss jedoch die App auf dem Gerät vornehmen und hier habe ich bisher noch keine App gesehen, die das machen würde und dann noch in der Lage wäre so wie z.B. Geofency.app einen entsprechenden Webhook an FHEM abzusetzen. Momentan kann man daher nur empfehlen die Beacons alle möglichst an den äußersten Rändern der Wohnung oder des Hauses zu platzieren und zusätzlich mit der Sendeleistung herumzuexperimentieren. Ein Patentrezept kann es hier nicht geben, weil es eben jedes Haus und jede Wohnung nur einmal gibt ;-)
Zitat von: Loredo am 28 August 2016, 08:25:30
Das ist wohl in erster Linie ein Ortungs-Problem bzw. ein Problem mit dessen Genauigkeit.
Ich habe aber nicht verstanden, in welchen anderen Zusammenhang msg_Room mit dem msgContact Attribut gebracht werden soll. Das müsstest du mal genauer erklären, denn wie du ja richtig geschrieben hast wird bei einer übereinstimmenden Location und wenn für diese ein gesondertes Gerät für die Audioausgabe hinterlegt wurde eben dieses Gerät genommen. Ich sehe jetzt nicht, wie die msgContact Information eines Roommate Devices hier wieder mit eingespielt werden soll, dann diese Informationen sind alle ortsunabhängig.
Ja mit dem Ortungs-Problem hast du recht. Meine Überlegungen waren darauf abgezielt, die ungenaue Ortung über die Kombination aus Person und Location etwas genauer zu machen.
Angenommen ich habe in einer Etage 3 Sonos Boxen Definiert. Jede Box in einem Raum der Etage. Die Räume kann ich aber aufgrund der ungenauen Ortung nicht auflösen. Die Räume Wären Schlafzimmer1, Schlafzimmer2, Wohnzimmer.
Es gibt 2 Personen. Jede Person hat sein eigenes Schlafzimmer und das Wohnzimmer, in dem sich beide Personen aufhalten können.
Also definiere ich pro Person die Sonos-Box aus dem eigenen Schlafzimmer und die aus dem Wohnzimmer.
Schicke ich nun eine Nachricht, wird zuerst geguckt, welche Boxen auf der Etage zur Verfügung stehen; das ist dann die Grundmenge. Diese Grundmenge wird dann mit den Boxen der Personen verglichen und auf der Schnittmenge erfolgt dann die Ausgabe (also quasi ein Art Filter).
Wie gesagt ist im Moment nur son bisschen Brainstorming von mir und die Frage, ob das nachher außer mir dann tatsächlich jemand benutzt steht auch noch im Raum, ganz abgesehen von dem Aufwand der Implementierung.
Im Moment komme ich so auch ganz gut klar ;-)
Wenn ich dich richtig verstehe, dann schaltest du die Sonos Boxen stromlos, wenn derjenige nicht im Raum ist?
Dann ist das eine klare Oder-Verknüpfung, die bereits jetzt schon funktioniert. Einfach die angegebenen Geräte mit einer Pipe ("|") voneinander trennen. Die Presence-Readings werden ohnehin bereits bei jedem Gateway-Device ausgewertet und wenn es auf absent steht kann dort ja kein Audio abgespielt werden. Wenn dann in der Liste ein weiteres Device steht, wird versucht dies für eine Audio-Ausgabe zu verwenden. Da es sich um eine Oder-Verknüpfung handelt wird auch nur solange versucht das nächste Device anzusprechen, bis eines in der Reihenfolge verfügbar ist und das Audio-Kommando ausführen kann.
aktuell nicht, aber du hast mich da grade auf ne idee gebracht.
Danke!
Ich habe mich gestern mal hier durchgehangelt.
Erst einmal Danke für das Modul.
Leider ist es sehr müssig sich hier durch 12 Seiten zu wühlen um entsprechende Antworten auf seine Fragen zu erhalten! Das hat mich gestern den ganzen Abend und die halbe Nacht gekostet. Eine vollständige Doku oder entsprechender Wiki Eintrag wären wirklich nach über einem Jahr mal fällig!!!
Bis eben zum FHEM Update lief auch noch alles einwandfrei, nun kommt bei einem einfachen "msg audio blablabla" nur noch:ZitatFATAL ERROR: Message NOT sent. No gateway device was available.
Was ist hier kaputt gegangen?
Das audio Device (Sonos) ist aber da und lässt sich auch steuern.EDIT: Habe es gerade noch einmal getestet und nun geht es wieder! Dauert es eine Weile nach dem FHEM Neustart bis msg das audio Device wieder erkennt?
Gruß
Dan
Hab den Fehler jetzt doch wieder und habe keine Ahnung wo er her kommt.
Zitatmsg audio test
ZitatFATAL ERROR: Message NOT sent. No gateway device was available.
Hmmmm....
Gruß
Dan
Welche Fragen ergeben sich denn über den erste Post und der Online Hilfe (zB "msg help") hinaus noch?
Devices werden auf ihre Verfügbarkeit geprüft. Sonos Devices, die nicht im Status available sind, könnten nichts abspielen und werden im Routing daher dann natürlich nicht berücksichtigt, weil sie zu dem Zeitpunkt ohnehin nichts abspielen könnten. Die Meldung besagt, dass auch nachgelagert keine alternativen Routen für eine Zustellung per Text ermittelt werden konnten, weil wahrscheinlich keine im globalMsg Device hinterlegt sind
Sent from my iPad using Tapatalk
Übrigens gibt es im Logfile sehr ausführliche Routing Infos, wenn man das angesprochene Device im Verhose Level höher setzt (in diesem Fall globalMsg, weil du kein anderes Device per @ angeben hast)
Sent from my iPad using Tapatalk
Was mich am meisten Zeit gekostet hat, war herauszufinden wie/wo und in welcher Form ich meinen ROOMMATE/GUEST den Push Kontakt für TelegramBot beibringen musste. Das war nur mit viel lesen und "trial and error" möglich herauszufinden.
Nun aber zum Fehler:
Das Sonos Device ist definitiv verfügbar und ich kann darauf auch mit dem integrierten Speak Befehl Sprache ausgeben, währen msg weiter diesen Fehler wirft.
Hab leider noch nicht herausgefunden in welchem Zusammenhang das steht.
Was ich noch angepasst habe am audio Befehl ist die einzustellende Lautstärke:
attr globalMsg msgCmdAudio {my $vol=%PRIORITY%>0?80:AutoVolume; fhem "set %DEVICE% Speak $vol de |%TITLE%| %MSG%"}
Alles mit Priorität größer 0 wird mit 80% Lautstärke abgespielt und alles darunter mit AutoVolume.
Das kann doch aber nichts mit dem Fehler zu tun haben oder?
Gruß
Dan
Hab's jetzt gefunden, dank verbose.
Zitat2016.10.30 14:47:22 5 : msg globalMsg: Trying to send message via gateway Sonos_Flur
2016.10.30 14:47:22 5 : msg globalMsg: Determined default title: Announcement
2016.10.30 14:47:22 3 : msg globalMsg: ID=1477835242.45912.1 TYPE=audio ROUTE=Sonos_Flur STATUS=USER_ASLEEP PRIORITY=0 TITLE='Bell-sound-magical' 'Die Wohnung befindet sich nun im Nachtmodus! Gute Nacht!'
2016.10.30 14:47:22 5 : msg globalMsg: Implicit forwards: recipient presence=present state=asleep
Ich möchte aber gerne die audio Ausgaben auch haben wenn RESIDENTS auf asleep ist!
Wenn ich die nun mit Priorität 2 ausgebe, dann wird es auch angesagt, allerdings dann auf Volume 80 (durch meine Funktion) und auch als push und mail zugestellt. Wie kann ich das ändern? Es soll auch mit Priorität 0 bei asleep ausgegeben werden.
Gruß
Dan
P.S. Die Erklärung der ganzen Attribute hat mich dann übrigens 12 Seiten lesen dieses Beitrag gekostet! :o
Ich würde auch gerne als "msg light" mein dafür vorbereitetes Hue structure nehmen, welches auch "alert select" und "alert lselect" unterstützt!
structures werden aber leider von msg nicht unterstützt...
Geht da noch was?
Gruß
Dan
EDIT: Hab jetzt die cmds für light angepasst und nun klappt es auch mit dem structure.
Zitat von: DeeSPe am 30 Oktober 2016, 14:54:37
Hab's jetzt gefunden, dank verbose.
Das sieht man aber auch schon ab Verbose Level 3 sehr gut: STATUS=USER_ASLEEP
Genau deshalb gibt es diese kompakte Logging Anzeige bereits bei Verbose 3.
Zitat von: DeeSPe am 30 Oktober 2016, 14:54:37
Ich möchte aber gerne die audio Ausgaben auch haben wenn RESIDENTS auf asleep ist!
Du kannst bei einer Nachricht ein Device-Enforce mitschicken, indem du am Ende des Devicenamen ein Ausrufezeichen anfügst (klappt auch beim Nachrichtentyp, wenn man da keinen impliziten Wechsel haben möchte):
msg audio @rgr_Residents! |Bell-sound-magical| Die Wohnung befindet sich nun im Nachtmodus! Gute Nacht!
Der Status der ROOMMATE/GUEST/RESIDENTS Devices bleibt dann komplett unberücksichtigt.
Zitat von: DeeSPe am 30 Oktober 2016, 15:07:30
Ich würde auch gerne als "msg light" mein dafür vorbereitetes Hue structure nehmen, welches auch "alert select" und "alert lselect" unterstützt!
structures werden aber leider von msg nicht unterstützt...
Geht da noch was?
EDIT: Hab jetzt die cmds für light angepasst und nun klappt es auch mit dem structure.
Genau so ist es auch gedacht. Das mitgelieferte Schema kann nicht immer für alle Fälle komplett brauchbar sein und für Structure müsste man mal überlegen, wie man für die verschiedenen Nachrichtentypen sinnvolle Schemata hinterlegen könnte. Aber da man in der Regel nicht erahnen kann, welche ja teils auch unterschiedlichen Geräte hier zusammengefasst wurden (welche dann alle eine unterschiedliche set-Befehlssyntax haben), wird das eher schwer zu generalisieren und es bleibt nur per msgCmd* Attribut ein für den genauen Anwendungsfall passendes Schema selbst zu definieren. Das kann man ja auf unterschiedlichen Ebenen machen, eben entweder auf Device-Ebene (sehr speziell also), Gateway-Ebene (etwas allgemeiner) oder globalMsg Ebene (eben global allgemein).
Ganz generell: Wer sinnvolle Ergänzungen für die Schemata hat möge sie gerne hier vorstellen und wir nehmen das in msgSchema.pm auf.
Zitat von: DeeSPe am 30 Oktober 2016, 14:54:37
P.S. Die Erklärung der ganzen Attribute hat mich dann übrigens 12 Seiten lesen dieses Beitrag gekostet! :o
Das wird sich auch nicht vermeiden lassen, dass man sich damit etwas mehr beschäftigen muss, wenn man es verstehen und sinnvoll einsetzen möchte. Der erste Post entspricht wie gesagt in etwa das, was in die commandRef auch kommen wird. Ich hätte es für einen ersten Wurf auch wohl schon längst 1-zu-1 übernommen, wenn die HTML Formatierung dabei nicht irgendwie so umständlich zu übernehmen wäre.
Den Einsatz vom msg-Befehl und den Umgang damit erlernt man eben eher durch Anwendung und das kann einem keine Doku der Welt abnehmen. Wer sich berufen fühlt darüber eine Abhandlung zu verfassen ist mehr als Willkommen das im Wiki für alle zu tun ;)
Achso: Du musst bei dir für die Anpassung der Lautstärke nicht zwangsweise das Schema komplett selbst definieren.
Du kannst auch einfach am Ende der Message mit Advanced Options arbeiten:
msg audio @rgr_Residents! |Bell-sound-magical| Die Wohnung befindet sich nun im Nachtmodus! Gute Nacht! O[{"VOLUME":15}]Ich muss nochmal einbauen, dass man die Advanced Options auch als Attribut z.B. am Gateway Device oder wo auch immer hinterlegen kann, um sie zentral als Quasi Konfigurationsoption des vorhandenen msgSchema benutzen zu können.
Dein Schema hast du wie genau definiert? Die Verwendung des TITLE scheint mit etwas verkehrt (nicht so wie vorgesehen) zu sein.
"get globalMsg audio SONOSPLAYER" sollte dir mehr sagen, wie das Schema normal ist.
Für Audio habe ich das Schema nun so definiert:
{my $vol=%PRIORITY%>0?80:%PRIORITY%>2?90:AutoVolume; fhem "set %DEVICE% Speak $vol de |%TITLE%| %MSG%"}
Das ist mir angenehmer wenn die Lautstärke anhand der Priorität verändert werden kann, anstatt die Lautstärke bei jedem Befehl mitzuschicken. AutoVolume liefert mir eine Lautstärke anhand der Uhrzeit zurück.
Alles unter Prio 1 bekommt also AutoVolume, Prio 1 bekommt Volume 80 und Prio höher 2 bekommt Volume 90.
Ich denke der TITLE ist auch richtig definiert! Funktioniert so wie es soll. Habe auch msgTitleAudio gesetzt. Für manche Ansagen möchte ich aber dennoch einen anderen TITLE, den setze ich dann manuell.
Bei asleep möchte ich auch nicht an ein bestimmtes Device senden, sondern an das globale audio Device!
Das mache ich dann so?
msg audio! Gute Nacht!
Danke.
Gruß
Dan
Hallo,
wie gestalte ich es denn, um einen msg-push mittels pushover an ein bestimmtes Pushover-Device zu senden? Melodieart auch?
gesendet:
msg text 0 |Meldung| Das ist ein Test von M S G ! 'htconex' 0 'mechanical'
Logfile:
msg globalMsg: ID=000000000000 TYPE=push ROUTE=MyPushover STATUS=OK PRIORITY=0 TITLE='Meldung' MSG='Das ist ein Test von M S G ! 'htconex' 0 'mechanical''
Hi,
das ist ein tolles Modul - tatsächlich aber ist der Thread hier echt unübersichtlich, und daher möchte ich das Thema "fehlende Doku" nochmal ansprechen. In der Commandref finde ich nichts, und "msg help" ist auch nicht wirklich ergiebig.
Gerade für Leute, die das Modul zügig zum Laufen bringen und die nicht stundenlang irgendwelche Threads lesen oder selbst basteln wollen, wäre eine Einsteiger-Doku sinnvoll. Hierbei sollten die Attribute von globalMsg beschrieben werden, die für eine funktionierende Basis eingerichtet werden sollten.
Und dann wäre es schön, wenn die Doku mit ein paar Beispielen abschließt, die mit der Basiseinrichtung machbar sind.
VG Yil
was fehlt dir denn im ersten Post um das Modul zum laufen zu bringen? Ich kam damit bisher immer sehr gut klar
Also, grundsätzlich kann ich über den msg-Befehl email, Push (Pushover sowie Telegram) und Audio zum Laufen bringen. Das Roommate-Modul nutze ich allerdings nicht und brauche es auch nicht.
Das ist meine Einrichtung bisher:
Internals:
CFGFN
NAME globalMsg
NR 2775
STATE 1
TYPE msgConfig
Readings:
2016-11-16 16:05:20 fhemMsgAudio Testnachricht!
2016-11-16 16:05:20 fhemMsgAudioGw Sonos_Esszimmer:OK
2016-11-16 16:05:20 fhemMsgAudioPrio 0
2016-11-16 16:05:20 fhemMsgAudioState 1
2016-11-16 16:05:20 fhemMsgAudioTitle Bell-sound-magical
2016-11-16 15:54:27 fhemMsgMail Nachrichtentext
2016-11-16 15:54:27 fhemMsgMailGw xxx@gmx.de:OK
2016-11-16 15:54:27 fhemMsgMailPrio 0
2016-11-16 15:54:27 fhemMsgMailState 1
2016-11-16 15:54:27 fhemMsgMailTitle Test Titel
2016-11-16 16:02:52 fhemMsgPush Nachrichtentext
2016-11-16 16:02:52 fhemMsgPushGw Telegram-Device:@xxx:OK
2016-11-16 16:02:52 fhemMsgPushPrio 0
2016-11-16 16:02:52 fhemMsgPushState 1
2016-11-16 16:02:52 fhemMsgPushTitle Test Titel
2016-11-16 16:05:20 fhemMsgState 1
2016-11-16 16:05:20 fhemMsgStateTypes audio:1
Attributes:
alias Global Messaging
comment FHEM Global Configuration for command 'msg'
devStateIcon 1:it_network@green
devStateStyle style="text-align:right;"
group Kommunikation
msgCmdMail {DebianMail('%DEVICE%','%TITLE%','%MSG%')}
msgContactAudio Sonos_Esszimmer
msgContactLight Osram09
msgContactMail xxx@gmx.de
msgContactPush Telegram-Device:@xxx
room Zentral
stateFormat fhemMsgState
verbose 3
Dabei funktionieren folgende Befehle bei mir:
msg |Test Titel| Nachrichtentext -> sendet eine eMail sowie ein Telegram
Allerdings erzeugt es zahlreiche Fehlerwiederholungen von:
PERL WARNING: Use of uninitialized value in string eq at fhem.pl line 4636.
Außerdem funktioniert die Audio-Ausgabe:
msg audio |Bell-sound-magical| Testnachricht! O[{"VOLUME":15}] -> lässt den Nachrichtentext an einer vorgewählten Sonos-Bos erklingen
Was mir fehlt, ist eine Prioritätensteuerung - wie stelle ich ein, wann welcher Befehl wo ausgegeben wird? In meiner "Welt" ist die Eskalation Audio-Push-eMail. Licht-Signale brauche ich eigentlich nicht, ebenbso den Pushover-Dienst auch niucht - den habe ich zugunsten des telegram-Dienbstes abgeschaltet. Lieber wäre mir WhatsApp, aber die mögen es nicht, wenn der device automatisch beschickt wird und haben mich abgeschaltet ::). Melodien gehen nicht - wie würde ich die aktivieren?
Auch bin ich nicht sicher, ob die gewählte Einstellung der Attribute richtig ist - sie ist eher das Ergebnis von Trial & Error ...
Kannst Du bei den Fragen helfen?
Hallo,
ich muss mich bezüglich fehlender Beschreibung mal anschließen.
Irgendwie kann ich es ja verstehen, daß erst mal eine neue Funktion kreiert wird und
erfahrenen Testern vorgestellt wird, um Verbesserungen daran zu erarbeiten.
Momentan sehe ich es aber grundsätzlich als abgeschlossen, daß der msg Befehl
nützlich ist und nun auch etliche Anwendungen abdeckt.
Warum fehlt dann trotzdem noch eine Beschreibung (80%-Erfüllungsstatus wäre schon prima)?
Mir würden auch sortierte hilfreich Beispiele genügen, an denen man sich orientieren kann - DOIF macht es vor!
Es ist sehr mühsam, aus den 13 Seiten funktionierende, nicht bestätigte Beispiele herauszufiltern ...
Ich finde es sehr widersprüchlich, einen Funktion zu erstellen, die Erleichterungen schaffen soll - aber bitte nur für Leute
die verstehen, was der Ersteller zu übermitteln versucht.
Dann bleibe ich als mäßig Fortgeschrittener doch lieber bei den "komplizierten" Anweisungen, welche abgelöst werden sollten,
die ich aber verstehe.
PS.: Vielleicht findet sich doch noch jemand, der mir mal die oben stehende Frage beantworten kann ...)
Danke!
https://forum.fhem.de/index.php/topic,39983.msg477357/topicseen.html#msg477357
Auch wenn ich wegen der fehlende Doku zu Stimme. Das hier hat mich 3 Sekunden gekostet um es über die Suche zu finden.
Hallo CoolTux
Danke für die Rückmeldung, aber 3 Sek - das ist geflunkert ;)
An der Stelle bin ich auch schon hängen geblieben, konnte es aber nicht recht glauben.
Was ist an
msg @PushoverDevice |Betreffzeile2| Diese Nachricht soll nur an das iPhone eines speziellen Users ungleich des Standard-Users geschickt werden O[{"RECIPIENT":"u2asdfghjklqwertzuiopyxcvbnmac:iPhone"}]
so viel einfacher, als es gleich selber kürzer und vollumfänglich an Pushover zu senden?
Da ich ja noch den AppToken mitsenden muss habe ich ja gerade die erworbene Nützlichkeit des msg-Kommandos wieder verloren!
Und die Mitgabe der Soundart ist immer noch nicht gegeben
Ich fände es es daher gescheiter, in dem @PushoverDevice weitere Push-Unterdevices anlegen zu können (iPhone,Samsung_Karl, htconex, usw) , wobei das erste zum Default wird und dann so sende:
msg @PushoverDevice |Betreffzeile2| Diese Nachricht soll definierte User/Endgeräte mit bestimmten Alarmton geschickt werden O[{"RECIPIENT":"msgPushSubDev1|msgPushSubDev2":"SOUND":"mechanical"}]
Mal noch kurze Fragen: Warum steht die Prioritäten-Null so am Ende der Nachricht.
Warum wird sie nicht als Teil der Nachricht erkannt.
Was, wenn ich tatsächlich mal eine "0" im Text habe. Wird diese dann fälschlich als Priorität definiert/erkannt?
Ich denke es ginge dem Modulauthor nicht darum die Befehlsketten der einzelnen Modulbefehle zu vereinfachen, sondern um das Zusammenspiel dieser. Darum nach Prioritäten entsprechende Dienste/Benachrichtigungen zu versenden und Automatisiert zu erkennen. Da kann es auch mal komplexer werden.
Es ist ja schlau, nicht das ganze Haus zusammen zu schreien über das Sounsystem, sondern eine Nachricht zu senden.
@Yil
Da hilft auch keine Negativ Bewertung. Meine Meinung steht!
@All
Jeder hat die Möglichkeit selbst zu entscheiden ob er den Befehl wählt oder nicht.
Ich finde einen Modulauthor welcher freiwillig in seiner freien Zeit etwas für uns macht zu kritisieren, und einige Texte hier sind nah an der Kritik, ist gelinde gesagt nicht Hilfreich. Ideen, Verbesserungsvorschläge oder sogar Code ist da schon hilfreicher.
Warum hat noch keiner von Euch einen Wikieintrag gemacht um alle Informationen zusammen zu tragen? Ein Wikieintrag kann jeder machen. Statt dessen wird nur genörgelt.
LG
Leon
@panik: ich nutze unter anderem RESIDENTS und ROOMMATES und hab auch die ein oder anderen Attribute gesetzt.
somit kann ich einfach sagen:
msg push @rr_Michael |Titel| Text
somit bekomme ich eine Nachricht über mein Zentral defniniertes Pushover device. Ob das jetzt Pushover oder Telegram oder weiß der Geier was ist, ist ja erstmal egal. Es kommt an. und wenn ich die Übertragungsmethode ändern möchte, dann mach ich das an einer Stelle und nicht an jeder Stelle im Code an der eine Push-Nachricht gesendet wird.
Das ist in erster Linie der Hauptvorteil von dem msg-Modul.
Dann kommen die bequemen Sachen wie follow me usw.
@Yil: mit Priorisierung habe ich mich noch nicht intensiv beschäftigt, ich werde mir das heute abend mal ansehen und mich dann nochmal melden.
Ansonsten simmte ich @CoolTux voll und ganz zu
Gruß Michael
Die Advanced Options sind dem Namen nach optional, mit den Attributen geht eigentlich auch alles. Das hinten bei den Optionen ist demnach auch keine Null/0, sondern ein O wie Option.
RECIPIENT in den Advanced Options anzugeben ist allerdings Sinn befreit.
Vielleicht ist das nicht allen Nutzern hier bewusst, aber es gibt Regeln für die Entwicklung neuer Module. Rudi König weist immer mal wieder darauf hin, dass er z.B. eher weniger als mehr globale Variablen wünscht, dass Module so und so aufgebaut werden sollen und entsprechende Benennungen haben sollten. Viele wissen, wovon ich spreche. In diesem Thread wird der Autor von Rudi vor einem halben Jahr (!) explizit aufgefordert, endlich eine Doku zur Verfügung zu stellen. Er weist darauf hin, dass eine Doku ein
wesentlicher Bestandteil eines Moduls ist und er in der Vergangenheit die Aufnahme neuer Module in die Updates verwehrt hat, wenn es an der Doku fehlte.
Zitat von: rudolfkoenig am 04 Juni 2016, 15:10:59
@Loredo: es ist mir gerade aufgefallen, dass 75_MSG.pm ohne commandref Doku kommt, "No documentation here yet, sorry." zaehlt nicht als Doku :) Koenntest du das bitte in der naechsten Zeit nachschieben? Es waere auch Anderen gegenueber fair, denen ich das Verteilen eines Moduls wg. fehlender Doku verweigere.
Die Nutzbarkeit von FHEM insgesamt orientiert sich nicht nur an den Möglichkeiten, sondern auch an der guten und schlüssigen Kommunikation dazu. Dieses Forum ist dafür eine Goldgrube, ersetzt aber nicht eine Basis-Doku, auf die von erfahrenen Nutzern immer wieder so eloquent hingewiesen wird. Und so, wie es Bastler und Entwickler und Experten gibt, so gibt es auch zahlreiche Anwender mit geringem oder erst langsam ansteigenden Wissen zu fhem, zu Perl und deren Synatax. Und gerade für die letztere Gruppe, über die man sich als Experte immer so schön erheben kann (wofür ich gerne Negativbewertungen verteile), ist eine gute Doku. wesentlich und kann den Einstieg und die Anwendung deutlich erleichtern.
Eigentlich sind das Selbstverständlichkeiten, von dene ich hier rede.
Ich verweise aus meine vorigen Posts, es ist alles gesagt.
Gruß
Julian
Vielleicht ist das nicht allen Nutzern hier bewusst, aber es ist Unsinn das es Regeln für die Entwicklung neuer Module gibt.
Es ist aber korrekt das es Regeln für den Aufbau von Modulen gibt welche ins offizielle Repo von FHEM eingecheckt werden.
Ansonsten darf jeder User oder auch Entwickler seine Module gestalten wie es ihm beliebt. Es gibt einige auf GitHub, einige User haben privat für sich was entwickelt.
Ansonsten gibt es gewünschte Richtlinien, so z.b. Readingsnamen Klein anfangen und Media Readings sollten bitte in allen Modulen gleich lauten, volume z.B.
Daher gebe ich denjenigen Recht was dieses Modul an geht, denn es ist ja offiziell über das Update erhältlich. :D
Zitat von: Yil am 16 November 2016, 16:16:12
Was mir fehlt, ist eine Prioritätensteuerung - wie stelle ich ein, wann welcher Befehl wo ausgegeben wird? In meiner "Welt" ist die Eskalation Audio-Push-eMail. Licht-Signale brauche ich eigentlich nicht, ebenbso den Pushover-Dienst auch niucht - den habe ich zugunsten des telegram-Dienbstes abgeschaltet. Lieber wäre mir WhatsApp, aber die mögen es nicht, wenn der device automatisch beschickt wird und haben mich abgeschaltet ::). Melodien gehen nicht - wie würde ich die aktivieren?
was möchtest du jetzt genau erreichen?
Du schickst eine Nachricht mit einer Bestimmten Priorität und die soll dann als Lichtsignal ausgegeben werden bzw. anhand welcher Kriterien als Push bzw Mail? woran machst du die Kriterien fest? Hast du vllt. ein Beispiel?
Gruß Michael
Hallo,
zur Bemerkung von CoolTux:
Zitat
Jeder hat die Möglichkeit selbst zu entscheiden ob er den Befehl wählt oder nicht.
Ich finde einen Modulauthor welcher freiwillig in seiner freien Zeit etwas für uns macht zu kritisieren, und einige Texte hier sind nah an der Kritik, ist gelinde gesagt nicht Hilfreich. Ideen, Verbesserungsvorschläge oder sogar Code ist da schon hilfreicher.
Warum hat noch keiner von Euch einen Wikieintrag gemacht um alle Informationen zusammen zu tragen? Ein Wikieintrag kann jeder machen. Statt dessen wird nur genörgelt.
Das ist ja gerade der springende Punkt:
Ob ich einen Befehl möchte oder nicht, kann ich ja erst entscheiden, wenn ich ihn einbinde, teste und seine Möglichkeiten begreife.
Doch momentan ist bei mir der Groschen - gerade bei diesem Befehl - nicht zur Gänze bis auf den Boden gefallen.
Manchmal brauchts eben doch so einen Einstieg ala Feuerzangenbowle:
"Wat is´ne Dampfmaschin´? Da stelle ma uns mal janz dumm, ..."
Ich finde es ja Klasse, dass es so Autoren wie Euch gibt, die so tolle Module erstellen,
aber mir fehlt es manchmal daran, auch Leute abzuholen, die nicht auf demselben Denk-Level sind.
Die können dann natürlich auch nicht kreativ mitwirken, was dann wiederum auch nicht gut ankommt
Beruflich geht es mir ja auch manchmal so, dass ich z.B. im Bereich Klein-SPS mit HMI etwas gestalte, von dem ich der Meinung bin:
"Das ist so einfach, das müssen die Leute doch auch ohne Erklärung und Anleitung begreifen".
Aber ich muss mich dann oft eines Besseren belehren lassen, dass ich schon viel höher ansetze als ich glaubte...
Bitte fühlt Euch aber von meinen Äußerungen nicht auf den Schlips getreten und genörgelt.
Ich hatte neulich nur echt Frust, dass ich's nicht raffe.
Panik
deine Argumentation kann ich gut verstehen und ich muss gestehen mir ist es mit msg am Anfang auch so ähnlich gegangen.
Mir ging es so, dass ich die volle Mächtigkeit dieses Befehls erst erkannt habe, als ich auch das RESIDENTS- bzw. ROOMMATE-Modul integriert haben und auch die locations-Readings der ROOMMATES nutze. Und auch dann hat es ein bisschen gedauert, bis ich mich dort reingefuchst und ich hab den ersten Post bestimmt schon 15 mal gelesen...
Trotzdem kann ich Loredo auch verstehen und wenn man sich den ersten Post mal durchliest und damit meine ich durchlesen und jeden einzelnen Schritt versucht nachzuvollziehen und nicht überfliegt, so wie man das heute sehr oft macht, dann macht es auch klick. Es ist alles gesagt, was man zur erfolgreichen Einbindung benötigt.
Ist halt ein Modul wo man n bisschen nachdenken muss und was man mal nicht so eben "nebenbei" einbinden kann.
Gruß Michael
Ich gebe zu dass wirklich eigentlich alles im ersten Beitrag gesagt ist. Wenn man sich erst einmal komplett durch das Modul und alle Seiten hier durchgekämpft hat, macht auch alles Sinn!!!!
Leider fehlen für einen halbwegs schnellen Einstieg die entsprechenden Beispiele die man sich dann über alle Seiten dieses Beitrags mühsam erarbeiten muss. Ich habe z.B. mind. eine Stunde gebraucht um überhaupt die erste Push Nachricht verschicken zu können. Erst nach viel Lesen und "Trial & Error" habe ich begriffen dass man TelegramBot mit "<NameTelegramBot>:@<TelegramId>" adressieren muss.
Dann wollte ich natürlich auch noch den Sinn aller übrigen Attribute begreifen und das hat mich dann bis zum Ende dieses Beitrag gebracht.
Wir sollten wirklich zusammen einen Wiki Eintrag mit entsprechenden Beispielen dafür anlegen!!!
Gruß
Dan
so ich hab mich dann mal ran gesetzt und den Ersten Post ins Wiki übertragen und am Ende ein einfaches Beispiel hinzugefügt. Weiter folgen in den nächsten Tagen.
http://www.fhemwiki.de/wiki/Msg (http://www.fhemwiki.de/wiki/Msg)
Diskussion zum WIKI-Eintrag hier:
https://forum.fhem.de/index.php/topic,61033.0.html (https://forum.fhem.de/index.php/topic,61033.0.html)
Gruß Michael
Vielen Dank Michael. So stellt man es sich vor. Klotzen statt Kleckern. Da vergibt man gerne einen Daumen Hoch.
Ich sehe in dem Wiki Eintrag jetzt keinen Vorteil (derzeit Copy&Paste meiner Beschreibung). Aber okay, wem es hilft und solange ihn jemand anderes pflegt. Ich bin da kein Fan von Dopplungen.
Der Roommate Hinweis ist nur halb richtig, denn die Attribute kann man _jedem_ FHEM Device zuweisen.
Gruß
Julian
Da hast du schon Recht. ich bin auch kein Fan von Dopplungen. Ich habe diesen Wiki-Eintrag in erster Linie angelegt um eine Zentrale Anlaufstelle für Beispiele zu schaffen und diese stetig auszubauen. Wurde hier im Thread ja auch schon mehrfach angesprochen.
Hätte ich deine Ausführungen aus dem ersten Post weggelassen, wäre es für mich nicht richtig Vollständig gewesen und hätte bei unerfahrenen User vllt. nur noch mehr Fragen aufgeworfen.
Gruß Michael
Hallo Julian,
ich glaube es hat sich ein kleiner Fehler in der Schema DB für Pushover eingeschlichen, der es verhindert die Nachricht an ein bestimmtes Gerät zu schicken.
Derzeit steht im Schema das:
set %DEVICE% msg '%TITLE%' '%MSG%' '%RECIPIENT%:%TERMINAL%' %PRIORITY% '%Pushover_SOUND%' %RETRY% %EXPIRE% %URLTITLE% %ACTION%
Das ":%TERMINAL%" hinter Recipient ist wohl zu viel (vorher war es ja nicht drin)?! Dadurch wird hinter dem Gerätenamen immer noch ein ":" angehängt, da es so eins nicht gibt geht die Nachricht einfach an alle :)
Das Log sagt dazu:
msg Handy: push route command (fhem): set PO msg 'Test' 'Test Nachricht' 'Galaxy-S6:' 0
Da ich heute mal ausprobieren wollte wie man eine Nachricht gezielt an ein Gerät schickt und es aber das nie gemacht hat, hat mich das den ganzen Nachmittag gekostet ::)
PS: Danke für das tolle Modul/Befehl! So was in der Art wollte ich mir auch schon selbst schreiben (natürlich nicht so umfangreich ;D ), wird definitiv gebraucht. Aber ich muss den anderen Recht geben, ich hätte auch ein paar Beispiele gebraucht um den Einstig besser hinzubekommen. Ich hab den Thread 30 mal rauf und runtergelesen und mir waren die zusammenhänge wohl nicht so klar wie dir (als Entwickler) ;D
Zitat von: Viktor am 20 November 2016, 19:40:06
ich glaube es hat sich ein kleiner Fehler in der Schema DB für Pushover eingeschlichen
Das ist schon richtig so, das Pushover Modul habe ich entsprechend erweitert gehabt. Es ist seit jeher Standard beim Pushover Modul, dass Nachrichten an alle Devices gehen, wenn man kein spezifisches Device angibt. Das macht die API schon von ganz alleine. Der Doppelpunkt kann stehen bleiben, denn das Pushover Modul berücksichtigt das entsprechend.
Wer über den msg-Befehl an ein bestimmtes Pushover-Gerät schicken möchte, der muss sich dabei (wie überall) an die richtige Notation des Pushover Moduls halten, wenn er das im msgContactPush Attribut hinterlegen möchte. Konkret kann man nicht einfach den Pushover FHEM-Gerätenamen gefolgt vom Endgerät (iPhone o.ä.) angeben; es fehlt die Angabe des Pushover Users selbst. Richtig lauten muss es also:
MeinZentralesFHEMPushoverDevice:u2USERTOKEN:MeinPushoverGeraeteName
%RECIPIENT% wird dabei dann durch u2USERTOKEN ersetzt und %TERMINAL% durch MeinPushoverGeraeteName. Das entspricht der erwarteten Pushover Notation und hat mit dem msg-Befehl wenig zu tun. Es ist die Pushover Funktion nicht für jeden Adressaten ein separates Device in FHEM anlegen zu müssen und den Usertoken stattdessen in den msgContactPush Attributen zu pflegen.
Edit:Ich habe im Pushover Device auch noch einen Fix vorgenommen, damit es dort mit dem Doppelpunkt klarkommt. Man kann dann auch ohne die Angabe eines User-Token ein Device adressieren, wenn man den Usertoken aus dem Pushover-Device verwenden möchte.
Alles klar, dann wollte ich mir das zu einfach machen ;D
Danke für den Fix, so wollte ich das gleich verwenden, da ich nur einen Account habe. (dafür hatte ich mir die cmd auf das alte Format, also ohne TERMINAL, umgeschrieben und es hat auch funktioniert)
hi,
bei Pushover scheint der jetzt die Priorität nicht mehr richtig zu verwenden:
bei Verwendung von:
msg @rr_Michael -1 |WASCHRAUM| Trockner fertig.
steht das im Log:
2016.11.22 10:11:32 3: msg rr_Michael: ID=XXXX.XXX TYPE=push ROUTE=PushMichael STATUS=OK PRIORITY=-1(Low) TITLE='WASCHRAUM' MSG='Trockner fertig.'
es kommt aber folgende Nachricht mit Priorität 0 an:
Trockner fertig. : -1
Gruß Michael
Zitat von: l2r am 22 November 2016, 11:19:13
hi,
bei Pushover scheint der jetzt die Priorität nicht mehr richtig zu verwenden:
Kann ich bestätigen seit dem gestrigen Update des Moduls.
läuft wieder. Danke
Gruß Michael
Zitat von: Loredo am 13 August 2015, 19:31:07
Follow-Me Funktion
...
Ü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.
...
Beide Devices sind als globales Attribut verlinkt:
attr global msgLocationDevs msgRoom_Living,msgRoom_Bedroom
Was ich nicht verstehe: warum ist msgLocationDevs ein Attribut von global und nicht von globalMsg? Das wäre für mich naheliegender. Um es als Attribut von global anzulegen, muss ich zuvor auch noch das global userattr msgLocationDevs anlegen. Absicht oder Fehler in der Dokumentation?
Fehler in der Doku. Ist ein Attribut von globalMsg.
Gesendet von iPhone mit Tapatalk
Zitat von: hartenthaler am 23 November 2016, 18:24:30
Was ich nicht verstehe: warum ist msgLocationDevs ein Attribut von global und nicht von globalMsg? Das wäre für mich naheliegender. Um es als Attribut von global anzulegen, muss ich zuvor auch noch das global userattr msgLocationDevs anlegen. Absicht oder Fehler in der Dokumentation?
Das liegt daran, dass Rudi eine klare Trennung des normalen global Devices haben wollte und dort keine Attribute von Modulen zulassen möchte.
Deshalb gibt es das Hilfsmodul msgConfig, dessen automatisch angelegtes Device per Default "globalMsg" heißt, jedoch auch komplett anders benannt werden kann, da es pro FHEM Installation immer nur ein Device vom TYPE msgConfig geben kann.
Hi,
ist durch den Umbau zum Doppelpunkt bei Pushover eventuell etwas kaputt gegangen?
Meine Message:
msg rr_xyz: ID=xxxxx TYPE=push ROUTE=pushmsg RECIPIENT=iPhone STATUS=OK PRIORITY=0 TITLE='Parkplatz für abc' MSG='Das Auto wurde hier geparkt [{"URLTITLE":"'In Google Maps öffnen'","ACTION":"'comgooglemapsurl://maps.google.com/?q=[rr_xyz:locationLat],[rr_xyz:locationLong]'","RETRY":0,"EXPIRE":0}]'
funktioniert seit ein paar Tagen (quasi nach dem letzten Update von msg) nicht mehr richtig.
a) wird die Nachricht nicht nur auf dem Gerät iPhone angezeigt, sondern auf allen für diesen Pushover-Account registrierten
b) wird die eigentliche Nachricht nicht mehr richtig umgewandelt. so steht jetzt im Title:
Parkplatz für abc' 'Das Auto wurde hier geparkt [{"URLTITLE":"'In Google Maps öffnen
und im Body ,"ACTION":
muss ich mir ansehen, geht aktuell leider nicht. Habe es auf die Todo Liste gepackt.
Zitat von: l2r am 26 August 2015, 17:35:36
sry... tut doch:
Person_Anwesend:present.* {
my $AnwesendePersonen = "";
if(Value("iPhone6") eq "present") {$AnwesendePersonen = "-Michael-"};
if(Value("iPhone6") eq "present") {
fhem("msg push -1 |ANWESENHEIT| Personen Anwesend!$AnwesendePersonen");}
}
Hi. Funktioniert bei mir leider nicht.
(
my $devType=InternalVal([rgr_Residents:lastActivityByDev],"TYPE","NONE");
my $lastState=ReadingsVal([rgr_Residents:lastActivityByDev],"lastState","none");
my $fensterOffen=statusFensterOffen();
[rgr_Residents:?lastActivity] and
[?rgr_Residents:lastActivity] eq "absent" and
$devType eq "ROOMMATE" and
$lastState eq "home" and
[?rgr_Residents:state] eq "absent" and
$fensterOffen ne ""
)
(
(msg push @[rgr_Residents:lastActivityByDev] 2|Türen und Fenster|Die $fensterOffen sind nicht geschlossen O[{"RETRY":60,"EXPIRE":300,"Pushover_SOUND":"siren"}])
)Statt, anstelle der offenen Fenster, wird der Text wie angegeben per Push übertrage.
Gruss
Chris
Ich fange gerade an, mich in deine Lösung einzuarbeiten und stolpere über eine Kleinigkeit:
Ich habe u.a. folgende Titel über die Attribute konfiguriert:
msgCmdMail {DebianMail('%DEVICE%','%TITLE%','%MSG%')}
msgCmdMailHigh {DebianMail('%DEVICE%','%TITLE%','%MSG%')}
msgCmdMailLow {DebianMail('%DEVICE%','%TITLE%','%MSG%')}
msgTitleMail Hausautomation - Info
msgTitleMailHigh Hausautomation - Warnung
msgTitleMailLow Hausautomation - Hinweis
Wenn ich nun
msg mail 0 HalloWeltPrio0
oder
msg mail 1 HalloWeltPrio1
ausführe, so wird in beiden Fällen der Titel aus dem Attribut "msgTitleMail" genommen.
Habe ich da einen Denkfehler oder ist im Code irgendwo ein Dreher? :-)
Danke.
Ich bräuchte mal einen "Stupser":
Ich nutze das Squeezebox Modul, dass soweit tadellos funktioniert.
set sb_kueche talk |fahrradklingel.mp3| Fenster noch offen
funktioniert unabhäng davon ob der Player im Status on oder off ist.
msg audio @res.home_XXX |fahrradklingel.mp3| Fenster noch offen
Funktioniert nur bei eingeschaltetem Player.
Log bei Erfolg/eingeschaltetem Player:
2017.01.16 20:40:04 3: msg res.home_XXX: ID=1484595604.62001.1 TYPE=audio ROUTE=sb_kueche STATUS=OK PRIORITY=0 TITLE='fahrradklingel.mp3' MSG='Fenster noch offen'
Bei ausgeschaltetem Player:
2017.01.16 20:41:47 3: msg res.home_XXX: ID=1484595707.24917.1 TYPE=audio ROUTE=sb_kueche STATUS=UNAVAILABLE PRIORITY=0 TITLE='fahrradklingel.mp3' 'Fenster noch offen'
Wenn ich unter routecmd schaue, wird doch genau der Befehl verwendet, den ich auch direkt oben eingebe?
Habs auch schon mit/ohne Title versucht, etc.
Was erwartest du, wie ein ausgeschaltetes Gerät etwas abspielen soll? :)
Gruß
Julian
Gegenfrage: Warum soll msg bei ausgeschalteten Player die Sprache nicht ausgeben?
get globalmsg routeCmd audio
sagt mir:
SB_PLAYER
Priority Normal:
set %DEVICE% talk |%TITLE%| %MSG%
...
Der Syntax ist m.E. identisch zu:
set sb_kueche talk |fahrradklingel.mp3| Fenster noch offen
Dieser Befehl, direkt in fhem eingegeben, bringt die gewünschte Sprachausgabe. Unabhängig davon ob der Player ein- oder aus-geschaltet ist!
Entschuldige, jetzt habe ich glaube ich verstanden was du meinst. Ich habe zunächst gedacht mit ausgeschaltet sei gemeint das Gerät sei auch tatsächlich nicht erreichbar.
Ich habe gerade einen Patch eingecheckt, der das Verhalten an dieser Stelle korrigiert.
Zitat von: outhouse am 17 Dezember 2016, 13:12:37
Statt, anstelle der offenen Fenster, wird der Text wie angegeben per Push übertrage.
konntest du das Problem zwischenzeitlich lösen?
Hallo zusammen,
irgendwie stehe ich mit dem msg zuweilen auf Kriegsfuß .. oder eher auf dem Schlauch ...
Mein Problem ist das ich bei dem Befehl
msg push @[MBW_HS:lastActivityByDev] |Anwesenheit| [MBW_HS:lastActivityBy] abgemeldet.
gerne hätte das die Meldung via Telegram an den zuletzt aktiven Benutzer geht.
Dazu habe ich bei jedem Benutzer das Attribut
msgContactPush Telegram
msgRecipientPush @SeinTelegramName
gesetzt.
Irgendwie geht das nicht - die Meldungen gehen an den "defaultPeer" und werden dort toll zugestellt ... aber gerade wenn die anderen gehen sollen sie ja die Nachrichten bekommen um dann zurückzugehen und die Fenster zu schliessen ..
Danke schon mal Vorweg.
Andreas
@ -> \@
LG
pah
@Loredo:
Ich habe heute Abend das Update gemacht.
Der Squeezeplayer gibt jetzt bei ausgeschalteten Player den Text aus.
Aber nicht mehr bei eingeschalteten Player.
Schlimmer noch, ein mal versucht den Text bei eingeschalteten Player Sprache auszugeben, geht erst mal gar keine Sprachausgabe mehr.
Selbst über den set talk Befehl des Squeezeplayer nicht mehr.
Ich habe noch kein Muster gefunden wann oder wie der Player sich wieder berappelt.
Der Player stürzt auch nicht ab, Musik (Radio) starten/stoppen geht trotzdem.
Laut logs behauptet msg der Befehl war erfolgreich. Auch laut den logs des Squeezeplayers wird Google angeblich erfolgreich für TTS aufgerufen.
Ich komme aber frühestens am Wochenende dazu weiter zu suchen :(
Muss ja auch nicht unbedingt an msg liegen.
Zitat von: Prof. Dr. Peter Henning am 18 Januar 2017, 20:39:46
@ -> \@
Hallo,
war das die Lösung für mein Problem?
Habe es bei den Attributen \@TelegramBenutzerName versucht sowie im DoIf code msg push \@[MBW_HS:lastActivityByDev] .. leider in beiden Fällen erfolglos ..
Ist es denke nicht ..
im Logfile sieht es ohne den Backslash so aus:
2017.01.18 20:59:11 2: ROOMMATE set rr_Andreas absent
2017.01.18 20:59:12 3: msg rr_Andreas: ID=123456789.98765.1 TYPE=push ROUTE=Telegram STATUS=OK PRIORITY=0 TITLE='Anwesenheit' MSG='Andreas abgemeldet. 1 Bewohner verblieben: Paul'
Gruß Andreas
EDIT: Fehler korrigiert.
Ich stehe gerade irgendwie auf dem Schlauch oder sehe den Wald vor läuter Bäumen nicht.
Ich habe sowohl ein Residents wie auch diverse Roommates-Geräte.
Wie kann ich aber eine Push-Nachricht nur an die Personen senden, die gerade daheim sind?
Oder muss ich das selber abfragen? Das wäre kein Problem. So ist das auch bisher. Aber ich dachte, dass könnte ich mir sparen.
msg push,screen @rr_Person1,@rr_Person2 Anruf von [FbCallMonitor:external_name] [FbCallMonitor:external_number] O[{"Pushover_SOUND":"bike"}]
Hallo
die anwesenden Roommates stehen in residentsHomeDevs
in https://forum.fhem.de/index.php/topic,19040.msg359145.html#msg359145 (https://forum.fhem.de/index.php/topic,19040.msg359145.html#msg359145) ist ein DoIf das mir beim aufknoten diverser Fragen in diesem Zusammenhang geholfen hat;
Gruß
Andreas
Zitat von: AndreasR am 19 Januar 2017, 16:59:21
Hallo
die anwesenden Roommates stehen in residentsHomeDevs
in https://forum.fhem.de/index.php/topic,19040.msg359145.html#msg359145 (https://forum.fhem.de/index.php/topic,19040.msg359145.html#msg359145) ist ein DoIf das mir beim aufknoten diverser Fragen in diesem Zusammenhang geholfen hat;
Gruß
Andreas
Okay, danke. Das kann ich bei mir jedoch viel einfacher machen, da ich nur zwei Standard-Bewohner abfragen muss.
Innerhalb eines DOIF-Ausführungsteils hatte ich folgende Abfrage. Dies wollte ich mir nur ersparen.
([FbCallMonitor:event] eq "ring")
(
IF ([rr_Bewohner1] eq "home")
(set push_Bewohner1 msg '' 'Anruf von [FbCallMonitor:external_name] [FbCallMonitor:external_number]' '' 0 'bike'),
IF ([rr_Bewohner2] eq "home")
(set push_Bewohner2 msg '' 'Anruf von [FbCallMonitor:external_name] [FbCallMonitor:external_number]' '' 0 'bike'),
)Ich nahm an, dass das irgendetwas mit dem Attribut "msgResidentsDev" zu tun hätte. Nunja. Dann halt weiter manuell. :-)
So sieht das nun mit der neuen Syntax aus. Leider musste ich "msg screen" nun getrennt einbauen, da die Nachricht sonst doppelt erscheinen:
([FbCallMonitor:event] eq "ring")
(
IF ([Dreambox:state] eq "on")
msg screen Anruf von [FbCallMonitor:external_name] [FbCallMonitor:external_number],
IF ([rr_Bewohner1] eq "home")
msg push @rr_Bewohner1 Anruf von [FbCallMonitor:external_name] [FbCallMonitor:external_number] O[{"Pushover_SOUND":"bike"}],
IF ([rr_Bewohner2] eq "home")
msg push @rr_Bewohner2 Anruf von [FbCallMonitor:external_name] [FbCallMonitor:external_number]
)
Ich habe noch einmal eine andere Frage.
Irgendwo habe ich einen Fehler. Ich erhalte nur eine Push-Nachricht mit dem Inhalt "audio". Titel, richtiger Inhalte, Audio-Ausgabe haben nicht funktioniert:
Code
## CMD4: Ausführungsteil
(
set irgendetwas on,
msg audio,push @rr_Bewohner1 |Alarmsystem| bla bla bla.
)
Log
2017.01.19 17:05:58 3: msg globalMsg: ID=1484841958.08763.1 TYPE=push ROUTE=pushBewohner1 STATUS=OK PRIORITY=0 TITLE='Hausautomation - Info' MSG='push'
2017.01.19 17:05:58 2: di_alarm: audio @rr_Bewohner1 |Alarmsystem| bla bla bla. : Unknown command audio, try help.
Zitat von: kjmEjfu am 04 Dezember 2016, 20:31:43
ist durch den Umbau zum Doppelpunkt bei Pushover eventuell etwas kaputt gegangen?
Mir ist aufgefallen, dass du den Buchstaben O nicht vor den Advanced Options gesetzt hast, weshalb sie nicht als solche erkannt werden können.
Zitat von: outhouse am 17 Dezember 2016, 13:12:37
Statt, anstelle der offenen Fenster, wird der Text wie angegeben per Push übertrage.
Das ist eine Frage zur Nutzung von DOIF, da sich DOIF in diesem Fall um die Ersetzung der Variable kümmern muss.
Zitat von: FunkOdyssey am 09 Januar 2017, 15:50:40
Ich fange gerade an, mich in deine Lösung einzuarbeiten und stolpere über eine Kleinigkeit:
Ich habe u.a. folgende Titel über die Attribute konfiguriert:
msgCmdMail {DebianMail('%DEVICE%','%TITLE%','%MSG%')}
msgCmdMailHigh {DebianMail('%DEVICE%','%TITLE%','%MSG%')}
msgCmdMailLow {DebianMail('%DEVICE%','%TITLE%','%MSG%')}
msgTitleMail Hausautomation - Info
msgTitleMailHigh Hausautomation - Warnung
msgTitleMailLow Hausautomation - Hinweis
Wenn ich nun
msg mail 0 HalloWeltPrio0
oder
msg mail 1 HalloWeltPrio1
ausführe, so wird in beiden Fällen der Titel aus dem Attribut "msgTitleMail" genommen.
Habe ich da einen Denkfehler oder ist im Code irgendwo ein Dreher? :-)
Muss ich mir genauer ansehen.
Zitat von: AndreasR am 18 Januar 2017, 20:26:40
Mein Problem ist das ich bei dem Befehl
msg push @[MBW_HS:lastActivityByDev] |Anwesenheit| [MBW_HS:lastActivityBy] abgemeldet.
gerne hätte das die Meldung via Telegram an den zuletzt aktiven Benutzer geht.
Dazu habe ich bei jedem Benutzer das Attribut
msgContactPush Telegram
msgRecipientPush @SeinTelegramName
gesetzt.
Beide Attribute gleichzeitig zu verwenden macht keinen Sinn.
msgRecipientPush ist ein Alias, der auf ein anderes FHEM Device zeigen muss, bei dem nach einem msContactPush Attribut gesucht werden soll.
Du willst wahrscheinlich nur msgContactPush setzen. Dort hast du aber nur dein Telegram Device angegeben ohne einen zusätzlichen Empfänger, der an Telegram mit übergeben werden kann. Also greift der Default Empfänger von Telegram.
Richtig muss es lauten:
msgContactPush Telegram:@@SeinTelegramName
Hier sind zwei aufeinanderfolgende @ notwendig, um das @ zu quoten und von einem Perl Array zu unterscheiden.
Zitat von: Buwe am 18 Januar 2017, 21:00:47
@Loredo:
Ich habe heute Abend das Update gemacht.
Der Squeezeplayer gibt jetzt bei ausgeschalteten Player den Text aus.
Aber nicht mehr bei eingeschalteten Player.
Schlimmer noch, ein mal versucht den Text bei eingeschalteten Player Sprache auszugeben, geht erst mal gar keine Sprachausgabe mehr.
Selbst über den set talk Befehl des Squeezeplayer nicht mehr.
Ich habe noch kein Muster gefunden wann oder wie der Player sich wieder berappelt.
Der Player stürzt auch nicht ab, Musik (Radio) starten/stoppen geht trotzdem.
Laut logs behauptet msg der Befehl war erfolgreich. Auch laut den logs des Squeezeplayers wird Google angeblich erfolgreich für TTS aufgerufen.
Ich komme aber frühestens am Wochenende dazu weiter zu suchen :(
Muss ja auch nicht unbedingt an msg liegen.
Das denke ich auch. Der msg-Befehl setzt nur den set-Befehl an das Gateway Device ab, hat aber keine Möglichkeit einer Rückmeldung um zu erfahren, ob er erfolgreich war oder nicht. Wenn der Befehl abgesetzt werden konnte, gibt msg den Status OK zurück.
Zitat von: AndreasR am 18 Januar 2017, 21:08:36
[...] sowie im DoIf code msg push \@[MBW_HS:lastActivityByDev] .. leider in beiden Fällen erfolglos ..
Hier muss wiederum kein Backslash angegeben werden, da es sich um normale msg-Notation handelt.
Siehe mein Beispiel, was Andreas verlinkt hat.
Zitat von: AndreasR am 19 Januar 2017, 16:59:21
die anwesenden Roommates stehen in residentsHomeDevs
Das stimmt nicht ganz: Die anwesenden Roommate stehen in residentsTotalPresentDevs. residentsHomeDevs beinhaltet alle Roommates, die gerade den Aktivitätsstatus "home" haben. Wenn also jemand schlafen ginge und damit einen anderen Aktivitätsstatus bekäme, dann würde diese Person nicht mehr in residentsHomeDevs aufgelistet werden, sondern stattdessen in residentsAsleepDevs. residentsHomeDevs ist aber vermutlich für den Fall, dass ein Anruf signalisiert werden soll, u.U. trotzdem richtig, wenn man die schlafenden Personen außen vor lassen möchte ;-)
In einem DOIF lässt sich das entsprechende Reading am einfachsten verwenden, um z.B. auf einen Anruf zu reagieren:
DOIF (...)
(msg push,screen @[rgr_Residents:residentsHomeDevs] Anruf von [FbCallMonitor:external_name] [FbCallMonitor:external_number] O[{"Pushover_SOUND":"bike"}])
Zitat von: FunkOdyssey am 19 Januar 2017, 17:47:51
Ich habe noch einmal eine andere Frage.
Irgendwo habe ich einen Fehler. Ich erhalte nur eine Push-Nachricht mit dem Inhalt "audio". Titel, richtiger Inhalte, Audio-Ausgabe haben nicht funktioniert:
DOIF verlangt an dieser Stelle, dass du die Befehlszeile nochmals in Klammern einschließt:
## CMD4: Ausführungsteil
(
set irgendetwas on,
(msg audio,push @rr_Bewohner1 |Alarmsystem| bla bla bla.)
)
Zitat von: Loredo am 19 Januar 2017, 18:14:08
DOIF verlangt an dieser Stelle, dass du die Befehlszeile nochmals in Klammern einschließt:
Ach, stimmt. Über ähnliches Problem (Kommatrennung) bin ich früher schon einmal gestolpert. Macht Sinn. Danke.
Zitat von: Loredo am 19 Januar 2017, 18:14:08
Richtig muss es lauten:
msgContactPush Telegram:@@SeinTelegramName
Hier sind zwei aufeinanderfolgende @ notwendig, um das @ zu quoten und von einem Perl Array zu unterscheiden.
Das kann ich so nicht bestätigen.
Habe es von Anfang an nur mit einem @ und es funktioniert bei allen ROOMMATE/GUEST Devices.
attr rr_Dan msgContactPush TB:@XXXXXXXXXGruß
Dan
Nope, ansonsten gibt's diese Meldung in TelegramBot:
sentMsgResult NonBlockingGet: returned FAILED peer not found :Loredo:
Wie man sieht fehlt dort das @, denn es wird von TelegramBot erwartet, um den Shortname aus dem Reading "Contacts" zu finden.
Zitat von: Loredo am 19 Januar 2017, 19:32:47
Nope, ansonsten gibt's diese Meldung in TelegramBot:
sentMsgResult NonBlockingGet: returned FAILED peer not found :Loredo:
Wie man sieht fehlt dort das @, denn es wird von TelegramBot erwartet, um den Shortname aus dem Reading "Contacts" zu finden.
Ich gehe über die ID-NR mit TelegramBot, nicht über den Benutzernamen.
Vielleicht ist das der Unterschied?
Denn die ID-NR wird im Contacts Reading nicht mit einem @ davor angezeigt, der Benutzername schon. ;)
Gruß
Dan
Zitat von: FunkOdyssey am 19 Januar 2017, 17:16:00
([FbCallMonitor:event] eq "ring")
(
IF ([Dreambox:state] eq "on")
msg screen Anruf von [FbCallMonitor:external_name] [FbCallMonitor:external_number],
IF ([rr_Bewohner1] eq "home")
msg push @rr_Bewohner1 Anruf von [FbCallMonitor:external_name] [FbCallMonitor:external_number] O[{"Pushover_SOUND":"bike"}],
IF ([rr_Bewohner2] eq "home")
msg push @rr_Bewohner2 Anruf von [FbCallMonitor:external_name] [FbCallMonitor:external_number]
)
Hmm. Es hört nicht auf bei mir. Nun habe ich folgenden Fehler.
IF ([rr_Bewohner1] eq "home") ((msg push @rr_Bewohner1 Es klingelt an der Haustür. O[{"Pushover_SOUND":"bike"}])): IF: unknown Device: {"Pushover_SOUND"
(Bitte nicht am leicht anderen Text stören)
Deine Fragen sind glaube ich alle DOIF bezogen und hier eher falsch.
Gruß
Julian
Es liegt wohl an der Kombination mit dem IF.
Eine Umgehungslösung habe ich hier (https://forum.fhem.de/index.php/topic,65238.msg565356.html#msg565356) beschrieben.
Ich muss leider noch einmal mit einer Frage stören. ::)
Wen ich folgenden Befehl ausführe, so liest mir mein Sonos-Lautsprecher den Text "rr_Bewohner1" vor.
(msg audio,push @rr_Bewohner1|Titel| Nachricht.)
Ich hatte in "rr_Bewohner1" das Attribut "msgContactAudio" auch nicht gesetzt und bin davon ausgegangen, dass auf die Einstellungen des globalMsg-Device zurückgegriffen wird. Erst nach der Pflege des Attributs in allen ROOMMATEs funktioniert die Sprachwiedergabe mit dem richtigen Text.
Is it a bug or a feature? ;)
Es fehlt vermutlich die Leertaste nach dem Titel:
msg audio,push @rr_Bewohner1 |Titel| Nachricht.
Danke, aber leider nein. Vielleicht oben in der Codezeile, aber ich habe alle Varianten ausprobiert.
Es änderte sich erst, als ich die Sonosgeräte bei den Bewohnern ergänzt hatte.
Eigentlich zweckentfremdest du die Catchall Fallback Funktion hier. Wenn man etwas zentral pflegen will ist eigentlich vorgesehen msgRecipient* zu verwenden, um auf das andere Device zu verlinken, in dem dann msgContact* zu suchen ist.
Da die Catchall-Funktion wie gesagt eigentlich ein Fallback ist, wird die Nachricht immer entsprechend mit einer zusätzlichen Nachricht erweitert, damit man sich dessen bewusst ist und ggf. eine Routing Korrektur programmieren kann. Mit dieser Texterweiterung kommt SONOS dann nicht klar und liefert beim Versuch die Nachricht umzuwandeln und abzuspielen dann einen entsprechenden Fehler (sieht man auch im Sonos Controller).
Ich habe den Textzusatz nun für Audio und Screen Nachrichten deaktiviert, da ich davon ausgehe, dass die Weiterleitungshinweise dort auch nicht wirklich hilfreich sind.
Zitat von: kjmEjfu am 17 Januar 2017, 14:23:31
konntest du das Problem zwischenzeitlich lösen?
Leider nein. Such noch immer nach einer Lösung.
Zitat von: Loredo am 21 Januar 2017, 11:16:25
Ich habe den Textzusatz nun für Audio und Screen Nachrichten deaktiviert, da ich davon ausgehe, dass die Weiterleitungshinweise dort auch nicht wirklich hilfreich sind.
Hallo Loredo,
Was bedeutet Textzusatz in diesem Zusammenhang?
Gruß
Andreas
Alle guten Dinge sind bekanntlich drei...
Das Problem von mehrfach Posts tritt in Verbindung mit dem Posten über Tapatalk in letzter Zeit häufiger auf. ^^
Zitat von: Spezialtrick am 22 Januar 2017, 13:06:47
Das Problem von mehrfach Posts tritt in Verbindung mit dem Posten über Tapatalk in letzter Zeit häufiger auf. ^^
JA - so wars - habe die 2 anderen gelöscht.
Andreas
Ich lasse mir über folgende Funktion (Quelle: Forum) die Unwetterwarnungen per E-Mail zusenden.
sub getUWZDetails($) {
my ($device) = @_;
my $warnCount = ReadingsVal($device,"WarnCount", undef);
my $retVal = "";
return undef if(!$device or !defined($warnCount));
for(my $i = 0; $i < $warnCount; $i++) {
my $warnStart = strftime("%d.%m.%Y %H:%M", localtime(ReadingsVal($device,"Warn_".$i."_Start", undef)));
my $warnEnd = strftime("%d.%m.%Y %H:%M", localtime(ReadingsVal($device,"Warn_".$i."_End", undef)));
my $warnShortText = ReadingsVal($device,"Warn_".$i."_ShortText", undef);
my $warnLongText = ReadingsVal($device,"Warn_".$i."_LongText", undef);
$retVal .= "Beginn: $warnStart Ende: $warnEnd\n";
$retVal .= "$warnShortText\n";
$retVal .= "$warnLongText\n\n";
}
return $retVal;
}
Ich nutze folgenden CMD-Aufruf in msg:
{DebianMail('%DEVICE%','%TITLE%','%MSG%')}
Vor dem Einsatz des msg-Aufrufs wurden mir die E-Mails mit Zeilenumbrüchen im Mailer angezeigt. Nun werden die HTML-Tags "scheinbar" in HTML Entitäten umgewandelt.
Früher:
------MIME delimiter for sendEmail-585471.55124052
Content-Type: text/plain;
charset="utf-8"
Content-Transfer-Encoding: 7bit
Beginn: 18.01.2017 14:10 Ende: 19.01.2017 12:00
Bis Do.-vormittag / -mittag örtlich Glatteisregen möglich
Bis Donnerstagvormittag und -mittag ist örtlich Glatteisregen möglich.
------MIME delimiter for sendEmail-585471.55124052--
Aktuell:
------MIME delimiter for sendEmail-839039.157218398
Content-Type: text/plain;
charset="utf-8"
Content-Transfer-Encoding: 7bit
Beginn: 21.01.2017 16:00 Ende: 22.01.2017 10:00<br />Streckenweise bei läng. Aufklaren gefährliche Fahrbahnverhältnisse durch Reifglätte<br />Streckenweise muss nachts bei längerem Aufklaren mit gefährlichen Fahrbahnverhältnissen durch Reifglätte gerechnet werden.<br /><br />
------MIME delimiter for sendEmail-839039.157218398--
Hat jemand eine Idee wieso das nun anders ist?
Oder besser: Hat jemand eine Quelle, wie man einen Raspberry beibringt über /usr/bin/mail zu versenden? Dann hätte ich auch die Priorität klarer bei den E-Mails.
Zitat von: FunkOdyssey am 23 Januar 2017, 09:46:33
Vor dem Einsatz des msg-Aufrufs wurden mir die E-Mails mit Zeilenumbrüchen im Mailer angezeigt. Nun werden die HTML-Tags "scheinbar" in HTML Entitäten umgewandelt.
[...]
Hat jemand eine Idee wieso das nun anders ist?
Bei höher oder niedriger priorisierten Mails muss diese als HTML Mail verschickt werden, damit Mailclients das Prioritäten-Feld im E-Mail Header korrekt auswerten.
Bei reinen Textmails ignorieren die meisten Clients das Attribut.
Nachrichten mit der Priorität 0 bleiben Plaintext.
Zitat von: FunkOdyssey am 23 Januar 2017, 09:46:33
Oder besser: Hat jemand eine Quelle, wie man einen Raspberry beibringt über /usr/bin/mail zu versenden? Dann hätte ich auch die Priorität klarer bei den E-Mails.
Nach Postfix googeln und lokalen Mailserver korrekt mit Smarthost einrichten.
Zitat von: Loredo am 23 Januar 2017, 14:19:19
Bei höher oder niedriger priorisierten Mails muss diese als HTML Mail verschickt werden, damit Mailclients das Prioritäten-Feld im E-Mail Header korrekt auswerten.
Bei reinen Textmails ignorieren die meisten Clients das Attribut.
Nachrichten mit der Priorität 0 bleiben Plaintext.
Das ist mir bekannt. Aber unabhängig von der Priorität werden die Zeilenumbrüche \n durch "msg" entfernt.
Zitat von: Loredo am 23 Januar 2017, 14:19:19
Nach Postfix googeln und lokalen Mailserver korrekt mit Smarthost einrichten.
Danke für den Tipp.
Zitat von: AndreasR am 22 Januar 2017, 12:23:49
Was bedeutet Textzusatz in diesem Zusammenhang?
Wenn eine Nachricht an ein FHEM Device geschickt wird, welches keine msgRecipient* oder msgContact* Attribute gesetzt hat, dann findet ein Fallback auf globalMsg statt. Dies wird im ersten Beitrag (https://forum.fhem.de/index.php/topic,39983.msg322257.html#msg322257) als "Catchall" beschrieben. Das bedeutet, dass Nachrichten im Titel ein "Fw: " vorangestellt wird und dem Nachrichtentext hinten ein Zusatz angefügt wird der erklärt, an welches FHEM Gerät die Nachricht ursprünglich geschickt wurde. Diese Funktion ist dafür gedacht, dass keine Nachrichten verloren gehen können und man weiß welches FHEM Device man vergessen hat mit einem msgContact* oder msgRecipient* Attribut zu versehen. Es ist nicht dafür gedacht, dass man es als Standard so verwendet. Wenn man so etwas möchte, dann gibt man einfach gar kein Empfänger-Device an. Das impliziert ebenfalls einen Fallback auf "globalMsg", löst aber die Catchall-Funktion nicht aus, weil gar kein Empfänger automatisch bedeutet, dass man etwas an globalMsg verschicken möchte.
Zitat von: FunkOdyssey am 23 Januar 2017, 14:24:59
Das ist mir bekannt. Aber unabhängig von der Priorität werden die Zeilenumbrüche \n durch "msg" entfernt.
Nein, sie werden durch ein in HTML sichtbares <br /> ersetzt, da ansonsten die Zeilenumbrüche unsichtbar werden.
Ah, alles klar. Das erklärt es. Danke.
@Loredo
Danke für Die Antwort - hat gleich einige andere Fragen geklärt.
Gruß
Andreas
Zitat von: Loredo am 23 Januar 2017, 14:28:01
Nein, sie werden durch ein in HTML sichtbares <br /> ersetzt, da ansonsten die Zeilenumbrüche unsichtbar werden.
So, ich lass nicht locker. :-) Ich habe Postfix nun am Laufen und nun sehen meine E-Mail wie folgt aus:
Zeilenumbrüche wurden erstellt. Aber zusätzlich werden noch die br-Tags angezeigt.
Beginn: 23.01.2017 09:39 Ende: 27.01.2017 10:00<br />
In den nächsten Nächten mäßiger b. strenger Frost, -5 bis -10 Grad, stellw. darunter<br />
Bei zeitweiligem Aufklaren ist in windschwacher Situation in den nächsten Nächten mit mäßigem bis strengem Frost bei Tiefstwerten von -5 bis -10 Grad, stellenweise darunter, zu rechnen.<br />
<br />
Beginn: 23.01.2017 10:37 Ende: 27.01.2017 10:00<br />
In den nächsten Nächten strenger Frost, -10 bis -15 Grad, örtlich daruner<br />
In den nächsten Nächten ist besonders bei längerem Aufklaren sowie in windschwacher Situation mit strengem Frost bei Tiefstwerten zwischen -10 und -15 Grad, örtlich darunter, zu rechnen.<br />
<br />
Beginn: 25.01.2017 03:00 Ende: 25.01.2017 15:00<br />
Ab 1200 Meter: Einzelne Sturmböen bis etwa 80 km/h sind möglich<br />
Für Lagen oberhalb von 1200 Metern: Im Hochschwarzwald sind ab der Nacht um Mittwoch einzelne Sturmböen aus östlichen Richtungen bis etwa 80 km/h möglich. Am Mittwoch nachmittag lässt der auf Südost bis Süd drehende Wind rasch nach.<br />
<br />Ich kann aber nirgends erkennen, ob die Mails nun als HTML-Mails verschickt werden.
Ich kann auch keinen Unterschied zwischen den verschiedenen Prioritäten feststellen.
Sorry Leute, ich vermute ich stehe voll auf dem Schlauch!
versuche das Modul zu verstehen, aber irgendwo hackt es ordentlich!
Zu meinem System: Ich benutze ausschließlich Telegramm.
set telegramm msg test
set telegramm msg @xxxxx test
funktioniert bei mir! Beides
msg push TestNachricht
jedoch nicht. Natürlich habe ich auch viele alternative Schreibweisen versucht.
globalMsg sieht so aus, und natürlich bin ich unsicher, was genau bei msgContactPush und msgCmdPush
eingetragen gehört. Habe auch hier einiges versucht und im Forum 2 Beispiele gefunden, aber beide senden bei mir keinen Text.
defmod globalMsg msgConfig
attr globalMsg comment FHEM Global Configuration for command 'msg'
attr globalMsg group Global
attr globalMsg msgCmdPush telegramm
attr globalMsg msgContactPush telegramm
attr globalMsg room System
attr globalMsg stateFormat fhemMsgState
attr globalMsg verbose 2
setstate globalMsg 1
setstate globalMsg 2017-01-25 18:02:42 fhemMsgPush TestNachricht
setstate globalMsg 2017-01-25 18:02:42 fhemMsgPushGw telegramm:OK
setstate globalMsg 2017-01-25 18:02:42 fhemMsgPushPrio 0
setstate globalMsg 2017-01-25 18:02:42 fhemMsgPushState 1
setstate globalMsg 2017-01-25 18:02:42 fhemMsgPushTitle -
setstate globalMsg 2017-01-25 18:02:42 fhemMsgState 1
setstate globalMsg 2017-01-25 18:02:42 fhemMsgStateTypes push:1
Ich benötige aktuell nur ein funktionierendes Telegram. Muss ich also nur den korrekten Eintrag für msgContactPush finden?
Zitat von: JoeALLb am 25 Januar 2017, 18:08:16
Sorry Leute, ich vermute ich stehe voll auf dem Schlauch!
versuche das Modul zu verstehen, aber irgendwo hackt es ordentlich!
Zu meinem System: Ich benutze ausschließlich Telegramm.
set telegramm msg test
set telegramm msg @xxxxx test
funktioniert bei mir! Beides
msg push TestNachricht
jedoch nicht. Natürlich habe ich auch viele alternative Schreibweisen versucht.
globalMsg sieht so aus, und natürlich bin ich unsicher, was genau bei msgContactPush und msgCmdPush
eingetragen gehört. Habe auch hier einiges versucht und im Forum 2 Beispiele gefunden, aber beide senden bei mir keinen Text.
defmod globalMsg msgConfig
attr globalMsg comment FHEM Global Configuration for command 'msg'
attr globalMsg group Global
attr globalMsg msgCmdPush telegramm
attr globalMsg msgContactPush telegramm
attr globalMsg room System
attr globalMsg stateFormat fhemMsgState
attr globalMsg verbose 2
setstate globalMsg 1
setstate globalMsg 2017-01-25 18:02:42 fhemMsgPush TestNachricht
setstate globalMsg 2017-01-25 18:02:42 fhemMsgPushGw telegramm:OK
setstate globalMsg 2017-01-25 18:02:42 fhemMsgPushPrio 0
setstate globalMsg 2017-01-25 18:02:42 fhemMsgPushState 1
setstate globalMsg 2017-01-25 18:02:42 fhemMsgPushTitle -
setstate globalMsg 2017-01-25 18:02:42 fhemMsgState 1
setstate globalMsg 2017-01-25 18:02:42 fhemMsgStateTypes push:1
Ich benötige aktuell nur ein funktionierendes Telegram. Muss ich also nur den korrekten Eintrag für msgContactPush finden?
Der Kontakt ist falsch hinterlegt!
Ich hinterlege die so:
<NAME-TELEGRAMBOT>:@<ID-NR-DES-KONTAKT>Gruß
Dan
Zitat von: FunkOdyssey am 24 Januar 2017, 16:07:37
Ich kann aber nirgends erkennen, ob die Mails nun als HTML-Mails verschickt werden.
Ich kann auch keinen Unterschied zwischen den verschiedenen Prioritäten feststellen.
msg übergibt dir nur den Body Text im HTML-Format. Damit das vom Mailclient richtig interpretiert wird, muss das Script zum verschicken der Mails die Header richtig setzen.
Das kann dann z.B. so aussehen:
attr globalMsg msgCmdMail { my $dev='%DEVICE%';; system("echo '%MSG%' | /usr/bin/mail -s '%TITLE%' -a 'MIME-Version: 1.0' -a 'Content-Type: text/html;; charset=UTF-8' '$dev'");; }
attr globalMsg msgCmdMailHigh { my $dev='%DEVICE%';; system("echo '%MSG%' | /usr/bin/mail -s '%TITLE%' -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' '$dev'");; }
attr globalMsg msgCmdMailLow { my $dev='%DEVICE%';; system("echo '%MSG%' | /usr/bin/mail -s '%TITLE%' -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' '$dev'");; }
Ich glaube ich habe das noch nicht als Standard im Schema hinterlegt, weil ich auch warten wollte, ob sich hier aus Diskussionen ein geeigneter Default herauskristallisieren würde.
Wenn man die E-Mails mit Prioritäten möchte, dann macht es auch keinen wirklichen Sinn für Prio=0 ne Extrawurst zu braten. Daher wird für alle Prioritäten aktuell ein Leerzeichen umgewandelt.
Zitat von: JoeALLb am 25 Januar 2017, 18:08:16
attr globalMsg msgCmdPush telegramm
Das hier solltest du auch löschen, wenn du kein eigenes Schema hinterlegen möchtest. In dieser Form ist es hier verkehrt.
Zitat von: DeeSPe am 25 Januar 2017, 19:13:51
Der Kontakt ist falsch hinterlegt!
Dan
Hallo Dan,
danke für die Antwort.
Das hatte ich auch versucht, ohne Erfolg.
Anbei das attr, wie ich versuche deinen Ratschlag zu befolgen.
attr globalMsg msgContactPush telegram:@1234565432Wenn ich
set relegramm msg @1234565432 Testnachrichtnutze, geht es.
Das bedeutet vermutlich hier nicht viel, oder?
reading fhemMsgPushGw telegram:@1234565432 :OK
Das war es!
Sorry, hab diese Nachricht war erst da, während ich meine Nachricht geschrieben habe!!
Vielen Dank, jetzt funktioniert es!
Zitat von: Loredo am 25 Januar 2017, 19:27:17
Das hier solltest du auch löschen, wenn du kein eigenes Schema hinterlegen möchtest. In dieser Form ist es hier verkehrt.
Zitat von: Loredo am 25 Januar 2017, 19:24:27
msg übergibt dir nur den Body Text im HTML-Format. Damit das vom Mailclient richtig interpretiert wird, muss das Script zum verschicken der Mails die Header richtig setzen.
Das kann dann z.B. so aussehen:
attr globalMsg msgCmdMail { my $dev='%DEVICE%';; system("echo '%MSG%' | /usr/bin/mail -s '%TITLE%' -a 'MIME-Version: 1.0' -a 'Content-Type: text/html;; charset=UTF-8' '$dev'");; }
attr globalMsg msgCmdMailHigh { my $dev='%DEVICE%';; system("echo '%MSG%' | /usr/bin/mail -s '%TITLE%' -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' '$dev'");; }
attr globalMsg msgCmdMailLow { my $dev='%DEVICE%';; system("echo '%MSG%' | /usr/bin/mail -s '%TITLE%' -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' '$dev'");; }
Ich glaube ich habe das noch nicht als Standard im Schema hinterlegt, weil ich auch warten wollte, ob sich hier aus Diskussionen ein geeigneter Default herauskristallisieren würde.
Wenn man die E-Mails mit Prioritäten möchte, dann macht es auch keinen wirklichen Sinn für Prio=0 ne Extrawurst zu braten. Daher wird für alle Prioritäten aktuell ein Leerzeichen umgewandelt.
Und ich suche mich dumm und dusselig. Ich habe alle Dateien nach Content-Type abgesucht und mich auch gewundert, warum in der msgSchema.pm (https://svn.fhem.de/trac/browser/trunk/fhem/FHEM/msgSchema.pm) nichts dergleichen gefunden habe. :-)
Die Zeilenumbrüche der Unwetterwarnungen funktionieren nun auch. Das Thema "Priorität" hatte ich ein wenig überschätze. Meine Mailer (GMail, iPhone, etc.) zeigen keine Unterschiede an.
Vielleicht könntest du die CMDs in das Schema aufnehmen.
Und viele Dank für deine Hilfe.
Zitat von: FunkOdyssey am 26 Januar 2017, 11:56:47
Das Thema "Priorität" hatte ich ein wenig überschätze. Meine Mailer (GMail, iPhone, etc.) zeigen keine Unterschiede an.
Vielleicht könntest du die CMDs in das Schema aufnehmen.
Das ist einer der Gründe, weshalb das noch nicht im Schema so drin ist, denn ich hatte noch keine Zeit zu recherchieren welche Clients mit welchen Headern arbeiten. Lt Standard sollten es die beiden hier enthaltenen sein, was aber wie du feststellst eben nicht ganz funktioniert.
Ich habe gerade eine aktualisierte Version eingecheckt, die ReplaceSetMagic unterstützt.
Was das bedeutet, steht hier: https://fhem.de/commandref_DE.html#set (https://fhem.de/commandref_DE.html#set)
ZitatAb featurelevel 5.7 ersetzt das set und setreading Befehl
- [device:reading] mit dem Wert des Readings für device, falls sowohl device, als auch Reading existiert, und nicht leer ist.
- [device:reading:d] wie ohne :d, aber alles nicht-numerische wird entfernt, siehe ReadingsNum
- {(perlExpression)} mit dem Ergebnis der perlExpression. $DEV wird dabei mit dem Namen des vom set betroffenen Gerätes ersetzt.
hi,
ich hab nochmal eine Frage. Kann sein, dass die schon mal gestellt wurde, ich hab aber so auf Anhieb nichts gefunden:
verwende ich die Sprachausgabe der Sonos über den Befehl:
set Sonos_Michael Speak 2 de test
ist alles gut und die Ansage kommt.
nutze ich
msg audio @Sonos_Michael test
kommt auch die Ansage, allerdings erhalte ich im Log folgende Fehlermeldung:
msg Sonos_Michael: ID=1485864054.9446.1 TYPE=audio ROUTE=Sonos_Michael STATUS=OK PRIORITY=0 TITLE='Announcement' MSG='test'
Use of uninitialized value in concatenation (.) or string at ./FHEM/00_SONOS.pm line 4241.
mache ich da noch etwas falsch?
Am Schema habe ich nicht rumgefuscht
Gruß Michael
Nein. Das ist ein Fehler in Sonos Modul, was Reinerlein beheben müsste.
Gruß
Julian
Vielen Dank für dieses tolle Modul. Nach einem Hinweis von @MadMax-FHEM habe ich nun msg im Einsatz und möchte gerne eine Push Nachricht per Telegram an Residents mit dem Status home senden.
Ich habe ein device Residents mit dem Namen Bewohner.
Ich habe ein device Roommate mit dem Namen Michael.
Der Status von Michael ist home.
Michael hat ein Attribut msgContactPush mit dem Inhalt TB:@Michael_XXXX.
Das ist der Name des Kontakts im Telegram Bot.
Im Device des Telegram Bot ist das Attribut defaultPeer mit dem Inhalt #FHEM belegt.
Das ist eine Gruppe, in der alle Kontakte sind.
Was funktioniert, sind
msg Test -> Test geht an alle in der Gruppe #FHEM unabhängig vom Status.
msg @FHEM Test -> Test geht an alle in der Gruppe #FHEM unabhängig vom Status, nur nicht über den defaultPeer.
msg @Michael Test -> Test geht an den Telegram Kontakt Michael_XXXX
Ich habe das Attribut msgContactPush von Michael auch mit dem Inhalt TB:@@Michael_XXXX probiert, wie es Loredo im Thread vorschreibt.
Dann bekomme ich aber im Telegram Bot die Meldung:
NonBlockingGet: returned FAILED peer not found :@Michael_XXX:
Mit einem einzelnen @ im Attribut klappt es.
Was nun aber nicht funktioniert ist:
msg @[Bewohner:residentsHomeDevs] Test
Im Telegram Bot bekomme ich die Meldung:
NonBlockingGet: returned FAILED peer not found :Michael:
Was mache ich falsch?
Wenn du das Verbose-Level von Markus auf 5 setzt, dann steht im Logfile welcher Befehl an TelegramBot übergeben wird und du kannst herauslesen, was dort anders ankommt.
Grundsätzlich sollte im Reading Bewohner:residentsHomeDevs der FHEM Gerätename stehen (leider hast du es genauso genannt wie den Vornamen, was es schwierig macht den geschriebenen Vornamen vom Gerätenamen zu unterscheiden). [Bewohner:residentsHomeDevs] wird automatisch durch Michael ersetzt, weshalb das Ergebnis dann genau der Befehl ist, den du oben händisch ausgeführt hast.
Hi Loredo,
das XBMC Modul wurde abgekündigt, das nachfolge Modul heißt jetzt KODI.
https://forum.fhem.de/index.php/topic,66299.0.html (https://forum.fhem.de/index.php/topic,66299.0.html)
Könntest du dies bitte in das msgSchema mit aufnehmen ?
Gruß Schlimbo
kurzes Update zu meinem Problem von oben:
die Announcement.mp3 war in meinem SonosSpeak-Ordner nicht vorhanden. Die hab ich eingefügt, dann war ruhe!
Gruß Michael
@Loredo:
Sorry, dass ich nochmal nerve. Ich habe jetzt nochmal meine residents und roommates angepasst, damit sie Deinen Beispielen ähnlicher sind.
Jetzt sieht das so aus:
Ich habe ein device Residents mit dem Namen rgr_bewohner.
Ich habe ein device Roommate mit dem Namen rr_michael.
Der Status von rr_michael ist home.
rr_michael hat ein Attribut msgContactPush mit dem Inhalt TB:@Michael_XXXX.
Das ist der Name des Kontakts im Telegram Bot.
Im Device des Telegram Bot ist das Attribut defaultPeer mit dem Inhalt #FHEM belegt.
Das ist eine Gruppe, in der alle Kontakte sind.
Was funktioniert, sind
msg Test -> Test geht an alle in der Gruppe #FHEM unabhängig vom Status.
msg @FHEM Test -> Test geht an alle in der Gruppe #FHEM unabhängig vom Status, nur nicht über den defaultPeer.
msg @rr_michael Test -> Test geht an den Telegram Kontakt Michael_XXXX
Ich habe das Attribut msgContactPush von Michael auch mit dem Inhalt TB:@@Michael_XXXX probiert, wie Du es im Thread vorschreibst.
Dann bekomme ich aber im Telegram Bot die Meldung:
NonBlockingGet: returned FAILED peer not found :@Michael_XXX:
Mit einem einzelnen @ im Attribut klappt es. Das hat sich also trotz der besseren Device Benennung nicht geändert!
Was weiterhin nicht funktioniert ist:
msg @[rgr_bewohner:residentsHomeDevs] Test
Im Telegram Bot bekomme ich die Meldung:
NonBlockingGet: returned FAILED peer not found :rr_michael:
Jetzt steht in residentsHomeDevs also der FHEM device Name. Aber der wird 1:1 an Telegram durchgereicht und das kann damit natürlich nichts anfangen. Es fehlt die Umsetzung des device Namen in den Telegram Kontaktnamen. :(
Jetzt bin ich wieder ratlos, was ich falsch mache.
Was meinst Du mit "Verbose-Level von Markus auf 5"?
Zitat von: SlrG am 03 Februar 2017, 20:47:24
Was meinst Du mit "Verbose-Level von Markus auf 5"?
Da du es jetzt wohl umbenannt hast, geht es jetzt um das FHEM Device rr_Michael. Dort das Attribut verbose=5 setzen und mal im Logfile beobachten, was dort steht. Dabei steht auch der Befehl, der dann über Telegramm abgesetzt wird. Darüber lassen sich Rückschlüsse ziehen, was du falsch gesetzt hast.
Bei mir steht da dann sowas hier:
2017.02.05 14:46:37.906 5: msg rr_Julian: push route command (fhem): set TB message @XYZ Test
Wenn ich diesen Befehl "set TB message @XYZ Test" manuell absetzte, bekomme ich auch die Meldung wie du. Daraus lässt sich folgern: Ich habe nicht den richtigen Adressaten für TelegramBot angegeben.
Der Fehler ist also beim TelegramBot Modul zu suchen. Was bei mir funktioniert:
set TB message @@XYZ Test
Wenn ich also dann als Attribut msgContactPush entsprechend "TB:@@XYZ" schreibe, funktioniert es wie es soll.
Im TelegramBot Device steht dabei im Reading "Contact": 123456789:Julian_Musterman:@XYZ.
Wie das genau zusammenhängt und warum man da mal 2 @-Zeichen braucht und mal nur einen oder wann man die Nummer nimmt und wann den Vor/Nachnamen - keine Ahnung... ist für mich genauso verwirrend.
TelegramBot bietet leider sehr viele und unübersichtliche Möglichkeiten den Adressaten anzugeben. Wie man das am klügsten macht fragst du besser in einem separaten Thread zu TelegramBot.
Ansonsten hat DeeSPe vorher ja schon geschrieben, dass er es bei sich so hinterlegt:
Zitat von: DeeSPe am 25 Januar 2017, 19:13:51Ich hinterlege die so:
<NAME-TELEGRAMBOT>:@<ID-NR-DES-KONTAKT>
Es gibt also nicht DIE eine richtige Antwort. Man muss wohl verstehen, wie das TelegramBot Modul arbeitet.
Zitat von: Schlimbo am 03 Februar 2017, 17:08:28
das XBMC Modul wurde abgekündigt, das nachfolge Modul heißt jetzt KODI.
https://forum.fhem.de/index.php/topic,66299.0.html (https://forum.fhem.de/index.php/topic,66299.0.html)
Könntest du dies bitte in das msgSchema mit aufnehmen ?
Habe ich hinzugefügt.
@Loredo:
Danke für Deine Erklärungen. Verbose 5 für rr_Michael und für den TelegramBot TB sind gesetzt.
msg Test
Geht an die in globalMsg definierte Gruppe und ergibt:
2017.02.05 15:32:28 4: TelegramBot_Set TB: called
2017.02.05 15:32:28 4: TelegramBot_Set TB: Processing TelegramBot_Set( message )
2017.02.05 15:32:28 5: TelegramBot_Set TB: start send for cmd :message: and sendType :0:
2017.02.05 15:32:28 5: TelegramBot_SendIt TB: called
2017.02.05 15:32:28 5: TelegramBot_SendIt TB: try to send message to :#FHEM: -:test: - :<undef>:
2017.02.05 15:32:28 4: TelegramBot_GetFullnameForContact # Contacts is -XXXXXXXX::#FHEM:
2017.02.05 15:32:28 4: TelegramBot_GetFullnameForContact # name is #FHEM
2017.02.05 15:32:28 4: TelegramBot_SendIt parseMode 0
2017.02.05 15:32:28 4: TelegramBot_SendIt TB: timeout for sent :30:
2017.02.05 15:32:28 5: TelegramBot_Set TB: message done succesful:
2017.02.05 15:32:28 3: msg globalMsg: ID=1486305148.41049.1 TYPE=push ROUTE=TB STATUS=OK PRIORITY=0 TITLE='' MSG='test'
2017.02.05 15:32:28 4: TelegramBot_Set TB: called
2017.02.05 15:32:28 4: TelegramBot_Set TB: Processing TelegramBot_Set( ? )
2017.02.05 15:32:28 5: TelegramBot_Callback TB: called from SendIt
2017.02.05 15:32:28 5: TelegramBot_Callback TB: data returned :{"ok":true,...
...
2017.02.05 15:32:28 5: TelegramBot_Callback TB: resulted in :SUCCESS: from SendIt
Funktioniert also, wie schon gesagt.
msg @rr_michael test
Schaut im device rr_michael nach dem in msgContactPush hinterlegten Kontakt und ergibt:
2017.02.05 15:40:17 5: msg rr_michael: (No Text contact defined, trying global instead)
2017.02.05 15:40:17 5: msg rr_michael: Checking for available routes (triggered by type text)
2017.02.05 15:40:17 5: msg rr_michael: (No Screen contact defined, trying global instead)
2017.02.05 15:40:17 5: msg rr_michael: screen route check result: ROUTE_UNAVAILABLE
2017.02.05 15:40:17 5: msg rr_michael: (No Light contact defined, trying global instead)
2017.02.05 15:40:17 5: msg rr_michael: light route check result: ROUTE_UNAVAILABLE
2017.02.05 15:40:17 5: msg rr_michael: (No Audio contact defined, trying global instead)
2017.02.05 15:40:17 5: msg rr_michael: audio route check result: ROUTE_UNAVAILABLE
2017.02.05 15:40:17 5: msg rr_michael: push route check result: ROUTE_AVAILABLE
2017.02.05 15:40:17 5: msg rr_michael: (No Mail contact defined, trying global instead)
2017.02.05 15:40:17 5: msg rr_michael: mail route check result: ROUTE_UNAVAILABLE
2017.02.05 15:40:17 4: msg rr_michael: Available routes: screen=0 light=0 audio=0 text=1 push=1 mail=0
2017.02.05 15:40:17 4: msg rr_michael: Text routing decision: push(4)
2017.02.05 15:40:17 5: msg rr_michael: Checking for available routes (triggered by type push)
2017.02.05 15:40:17 5: msg rr_michael: (No Screen contact defined, trying global instead)
2017.02.05 15:40:17 5: msg rr_michael: screen route check result: ROUTE_UNAVAILABLE
2017.02.05 15:40:17 5: msg rr_michael: (No Light contact defined, trying global instead)
2017.02.05 15:40:17 5: msg rr_michael: light route check result: ROUTE_UNAVAILABLE
2017.02.05 15:40:17 5: msg rr_michael: (No Audio contact defined, trying global instead)
2017.02.05 15:40:17 5: msg rr_michael: audio route check result: ROUTE_UNAVAILABLE
2017.02.05 15:40:17 5: msg rr_michael: push route check result: ROUTE_AVAILABLE
2017.02.05 15:40:17 5: msg rr_michael: (No Mail contact defined, trying global instead)
2017.02.05 15:40:17 5: msg rr_michael: mail route check result: ROUTE_UNAVAILABLE
2017.02.05 15:40:17 4: msg rr_michael: Available routes: screen=0 light=0 audio=0 text=1 push=1 mail=0
2017.02.05 15:40:17 5: msg rr_michael: Trying to send message via gateway TB to recipient @Michael_XXX
2017.02.05 15:40:17 5: msg rr_michael: Determined default title:
2017.02.05 15:40:17 5: msg rr_michael: push route command (fhem): set TB message @Michael_XXX Test
2017.02.05 15:40:17 4: TelegramBot_Set TB: called
2017.02.05 15:40:17 4: TelegramBot_Set TB: Processing TelegramBot_Set( message )
2017.02.05 15:40:17 5: TelegramBot_Set TB: start send for cmd :message: and sendType :0:
2017.02.05 15:40:17 5: TelegramBot_SendIt TB: called
2017.02.05 15:40:17 5: TelegramBot_SendIt TB: try to send message to :Michael_XXX: -:Test: - :<undef>:
2017.02.05 15:40:17 4: TelegramBot_GetFullnameForContact # Contacts is 123456789:Michael_XXX:@XXX:
2017.02.05 15:40:17 4: TelegramBot_GetFullnameForContact # name is Michael_XXX
2017.02.05 15:40:17 4: TelegramBot_SendIt parseMode 0
2017.02.05 15:40:17 4: TelegramBot_SendIt TB: timeout for sent :30:
2017.02.05 15:40:17 5: TelegramBot_Set TB: message done succesful:
2017.02.05 15:40:17 4: TelegramBot_Set TB: called
2017.02.05 15:40:17 4: TelegramBot_Set TB: Processing TelegramBot_Set( ? )
2017.02.05 15:40:17 3: msg rr_michael: ID=1486305617.37319.1 TYPE=push ROUTE=TB RECIPIENT=@Michael_XXX STATUS=OK PRIORITY=0 TITLE='' MSG='Test'
2017.02.05 15:40:17 5: msg rr_michael: Implicit forwards: recipient presence=present state=home
2017.02.05 15:40:17 5: ROOMMATE rr_michael: called function ROOMMATE_Set()
2017.02.05 15:40:17 5: ROOMMATE rr_michael: called function ROOMMATE_Set()
2017.02.05 15:40:17 4: TelegramBot_Set TB: called
2017.02.05 15:40:17 4: TelegramBot_Set TB: Processing TelegramBot_Set( ? )
2017.02.05 15:40:17 5: TelegramBot_Callback TB: called from SendIt
2017.02.05 15:40:17 5: TelegramBot_Callback TB: data returned :{"ok":true,...
...
2017.02.05 15:40:17 5: TelegramBot_Callback TB: resulted in :SUCCESS: from SendIt
Auch das funktioniert also.
Genauso, wenn ich die von DeeSPe verwendete Benennungsmethode verwende. Auch hier wird im Device rr_michael nachgeschaut und der Kontakt bestimmt.
Das sieht dann so aus:
2017.02.05 15:48:45 5: msg rr_michael: (No Text contact defined, trying global instead)
2017.02.05 15:48:45 5: msg rr_michael: Checking for available routes (triggered by type text)
2017.02.05 15:48:45 5: msg rr_michael: (No Screen contact defined, trying global instead)
2017.02.05 15:48:45 5: msg rr_michael: screen route check result: ROUTE_UNAVAILABLE
2017.02.05 15:48:45 5: msg rr_michael: (No Light contact defined, trying global instead)
2017.02.05 15:48:45 5: msg rr_michael: light route check result: ROUTE_UNAVAILABLE
2017.02.05 15:48:45 5: msg rr_michael: (No Audio contact defined, trying global instead)
2017.02.05 15:48:45 5: msg rr_michael: audio route check result: ROUTE_UNAVAILABLE
2017.02.05 15:48:45 5: msg rr_michael: push route check result: ROUTE_AVAILABLE
2017.02.05 15:48:45 5: msg rr_michael: (No Mail contact defined, trying global instead)
2017.02.05 15:48:45 5: msg rr_michael: mail route check result: ROUTE_UNAVAILABLE
2017.02.05 15:48:45 4: msg rr_michael: Available routes: screen=0 light=0 audio=0 text=1 push=1 mail=0
2017.02.05 15:48:45 4: msg rr_michael: Text routing decision: push(4)
2017.02.05 15:48:45 5: msg rr_michael: Checking for available routes (triggered by type push)
2017.02.05 15:48:45 5: msg rr_michael: (No Screen contact defined, trying global instead)
2017.02.05 15:48:45 5: msg rr_michael: screen route check result: ROUTE_UNAVAILABLE
2017.02.05 15:48:45 5: msg rr_michael: (No Light contact defined, trying global instead)
2017.02.05 15:48:45 5: msg rr_michael: light route check result: ROUTE_UNAVAILABLE
2017.02.05 15:48:45 5: msg rr_michael: (No Audio contact defined, trying global instead)
2017.02.05 15:48:45 5: msg rr_michael: audio route check result: ROUTE_UNAVAILABLE
2017.02.05 15:48:45 5: msg rr_michael: push route check result: ROUTE_AVAILABLE
2017.02.05 15:48:45 5: msg rr_michael: (No Mail contact defined, trying global instead)
2017.02.05 15:48:45 5: msg rr_michael: mail route check result: ROUTE_UNAVAILABLE
2017.02.05 15:48:45 4: msg rr_michael: Available routes: screen=0 light=0 audio=0 text=1 push=1 mail=0
2017.02.05 15:48:45 5: msg rr_michael: Trying to send message via gateway TB to recipient @123456789
2017.02.05 15:48:45 5: msg rr_michael: Determined default title:
2017.02.05 15:48:45 5: msg rr_michael: push route command (fhem): set TB message @123456789 Test
2017.02.05 15:48:45 4: TelegramBot_Set TB: called
2017.02.05 15:48:45 4: TelegramBot_Set TB: Processing TelegramBot_Set( message )
2017.02.05 15:48:45 5: TelegramBot_Set TB: start send for cmd :message: and sendType :0:
2017.02.05 15:48:45 5: TelegramBot_SendIt TB: called
2017.02.05 15:48:45 5: TelegramBot_SendIt TB: try to send message to :123456789: -:Test: - :<undef>:
2017.02.05 15:48:45 4: TelegramBot_GetFullnameForContact # Contacts is 123456789:Michael_XXX:@XXX:
2017.02.05 15:48:45 4: TelegramBot_GetFullnameForContact # name is Michael_XXX
2017.02.05 15:48:45 4: TelegramBot_SendIt parseMode 0
2017.02.05 15:48:45 4: TelegramBot_SendIt TB: timeout for sent :30:
2017.02.05 15:48:45 5: TelegramBot_Set TB: message done succesful:
2017.02.05 15:48:45 4: TelegramBot_Set TB: called
2017.02.05 15:48:45 4: TelegramBot_Set TB: Processing TelegramBot_Set( ? )
2017.02.05 15:48:45 4: TelegramBot_Set TB: called
2017.02.05 15:48:45 4: TelegramBot_Set TB: Processing TelegramBot_Set( ? )
2017.02.05 15:48:45 3: msg rr_michael: ID=1486306125.07257.1 TYPE=push ROUTE=TB RECIPIENT=@123456789 STATUS=OK PRIORITY=0 TITLE='' MSG='Test'
2017.02.05 15:48:45 5: msg rr_michael: Implicit forwards: recipient presence=present state=home
2017.02.05 15:48:45 5: ROOMMATE rr_michael: called function ROOMMATE_Set()
2017.02.05 15:48:45 5: ROOMMATE rr_michael: called function ROOMMATE_Set()
2017.02.05 15:48:45 5: TelegramBot_Callback TB: called from SendIt
2017.02.05 15:48:45 5: TelegramBot_Callback TB: data returned :{"ok":true, ...
...
2017.02.05 15:48:45 5: TelegramBot_Callback TB: resulted in :SUCCESS: from SendIt
Was bei mir nicht funktioniert ist, wenn im device rr_michael der msgContactPush Kontakt, wie von Dir empfohlen, mit @@ hinterlegt ist.
Das ergibt dann:
2017.02.05 15:54:37 5: msg rr_michael: (No Text contact defined, trying global instead)
2017.02.05 15:54:37 5: msg rr_michael: Checking for available routes (triggered by type text)
2017.02.05 15:54:37 5: msg rr_michael: (No Screen contact defined, trying global instead)
2017.02.05 15:54:37 5: msg rr_michael: screen route check result: ROUTE_UNAVAILABLE
2017.02.05 15:54:37 5: msg rr_michael: (No Light contact defined, trying global instead)
2017.02.05 15:54:37 5: msg rr_michael: light route check result: ROUTE_UNAVAILABLE
2017.02.05 15:54:37 5: msg rr_michael: (No Audio contact defined, trying global instead)
2017.02.05 15:54:37 5: msg rr_michael: audio route check result: ROUTE_UNAVAILABLE
2017.02.05 15:54:37 5: msg rr_michael: push route check result: ROUTE_AVAILABLE
2017.02.05 15:54:37 5: msg rr_michael: (No Mail contact defined, trying global instead)
2017.02.05 15:54:37 5: msg rr_michael: mail route check result: ROUTE_UNAVAILABLE
2017.02.05 15:54:37 4: msg rr_michael: Available routes: screen=0 light=0 audio=0 text=1 push=1 mail=0
2017.02.05 15:54:37 4: msg rr_michael: Text routing decision: push(4)
2017.02.05 15:54:37 5: msg rr_michael: Checking for available routes (triggered by type push)
2017.02.05 15:54:37 5: msg rr_michael: (No Screen contact defined, trying global instead)
2017.02.05 15:54:37 5: msg rr_michael: screen route check result: ROUTE_UNAVAILABLE
2017.02.05 15:54:37 5: msg rr_michael: (No Light contact defined, trying global instead)
2017.02.05 15:54:37 5: msg rr_michael: light route check result: ROUTE_UNAVAILABLE
2017.02.05 15:54:37 5: msg rr_michael: (No Audio contact defined, trying global instead)
2017.02.05 15:54:37 5: msg rr_michael: audio route check result: ROUTE_UNAVAILABLE
2017.02.05 15:54:37 5: msg rr_michael: push route check result: ROUTE_AVAILABLE
2017.02.05 15:54:37 5: msg rr_michael: (No Mail contact defined, trying global instead)
2017.02.05 15:54:37 5: msg rr_michael: mail route check result: ROUTE_UNAVAILABLE
2017.02.05 15:54:37 4: msg rr_michael: Available routes: screen=0 light=0 audio=0 text=1 push=1 mail=0
2017.02.05 15:54:37 5: msg rr_michael: Trying to send message via gateway TB to recipient @@Michael_XXX
2017.02.05 15:54:37 5: msg rr_michael: Determined default title:
2017.02.05 15:54:37 5: msg rr_michael: push route command (fhem): set TB message @@Michael_XXX Test
2017.02.05 15:54:37 4: TelegramBot_Set TB: called
2017.02.05 15:54:37 4: TelegramBot_Set TB: Processing TelegramBot_Set( message )
2017.02.05 15:54:37 5: TelegramBot_Set TB: start send for cmd :message: and sendType :0:
2017.02.05 15:54:37 5: TelegramBot_SendIt TB: called
2017.02.05 15:54:37 5: TelegramBot_SendIt TB: try to send message to :@Michael_XXX: -:Test: - :<undef>:
2017.02.05 15:54:37 4: TelegramBot_GetFullnameForContact # Contacts is <undef>
2017.02.05 15:54:37 3: TelegramBot_SendIt TB: Failed with :FAILED peer not found :@Michael_XXX::
2017.02.05 15:54:37 5: TelegramBot_Callback TB: called from SendIt
2017.02.05 15:54:37 3: TelegramBot_Callback TB: resulted in :NonBlockingGet: returned FAILED peer not found :@Michael_XXX:: from SendIt
2017.02.05 15:54:37 4: TelegramBot_Set TB: called
2017.02.05 15:54:37 4: TelegramBot_Set TB: Processing TelegramBot_Set( ? )
2017.02.05 15:54:37 4: TelegramBot_Set TB: called
2017.02.05 15:54:37 4: TelegramBot_Set TB: Processing TelegramBot_Set( ? )
2017.02.05 15:54:37 5: TelegramBot_Set TB: message failed with :FAILED peer not found :@Michael_XXX::
2017.02.05 15:54:37 3: msg rr_michael: ID=1486306477.28527.1 TYPE=push ROUTE=TB RECIPIENT=@@Michael_XXX STATUS=OK PRIORITY=0 TITLE='' MSG='Test'
2017.02.05 15:54:37 5: msg rr_michael: Implicit forwards: recipient presence=present state=home
Die Frage ist, warum funktioniert das bei Dir anders wie bei mir? Das sollte doch eigentlich nicht sein?!
Und dann nochmal das eigentliche Problem. Was passiert bei Dir, wenn Du an die zu Hause anwesenden eine Nachricht schicken willst?
Also bei mir:
msg @[rgr_bewohner:residentsHomeDevs] Test
und bei Dir:
msg @[rgr_residents:residentsHomeDevs] Test
Kommt die Nachricht dann bei Deinen Kontakten an?
Bei mir sieht das mit verbose=5 so aus:
2017.02.05 16:03:43 4: TelegramBot_Set TB: Processing TelegramBot_Set( message )
2017.02.05 16:03:43 5: TelegramBot_Set TB: start send for cmd :message: and sendType :0:
2017.02.05 16:03:43 5: TelegramBot_SendIt TB: called
2017.02.05 16:03:43 5: TelegramBot_SendIt TB: try to send message to :rr_michael: -:Test: - :<undef>:
2017.02.05 16:03:43 4: TelegramBot_GetFullnameForContact # Contacts is <undef>
2017.02.05 16:03:43 3: TelegramBot_SendIt TB: Failed with :FAILED peer not found :rr_michael::
2017.02.05 16:03:43 5: TelegramBot_Callback TB: called from SendIt
2017.02.05 16:03:43 3: TelegramBot_Callback TB: resulted in :NonBlockingGet: returned FAILED peer not found :rr_michael:: from SendIt
2017.02.05 16:03:43 4: TelegramBot_Set TB: called
2017.02.05 16:03:43 4: TelegramBot_Set TB: Processing TelegramBot_Set( ? )
2017.02.05 16:03:43 4: TelegramBot_Set TB: called
2017.02.05 16:03:43 4: TelegramBot_Set TB: Processing TelegramBot_Set( ? )
2017.02.05 16:03:43 5: TelegramBot_Set TB: message failed with :FAILED peer not found :rr_michael::
2017.02.05 16:03:43 3: msg globalMsg: ID=1486307023.25168.1 TYPE=push ROUTE=TB STATUS=OK PRIORITY=0 TITLE='' MSG='@[rgr_bewohner:residentsHomeDevs] Test'
2017.02.05 16:03:43 5: ROOMMATE rr_michael: called function ROOMMATE_Set()
In dem Array rgr_bewohner:residentsHomeDevs, stehen also die device Namen der Bewohner mit dem Status home. Dieser device Name wird direkt an den Telegram Bot durchgereicht, der damit aber nichts anfangen kann. Was IMHO fehlt, ist die Umsetzung des device Namen in den in msgContactPush hinterlegten Kontakt. Erst dieser dürfte dann an den Telegram Bot durchgereicht werden.
Meiner Meinung nach, müsste diese Umsetzung von msg übernommen werden.
Das scheint bei mir aber nicht zu passieren? Funktioniert das bei Dir?
Zitat von: SlrG am 05 Februar 2017, 16:21:41
Kommt die Nachricht dann bei Deinen Kontakten an?
Ja.
Zitat von: SlrG am 05 Februar 2017, 16:21:41
Meiner Meinung nach, müsste diese Umsetzung von msg übernommen werden.
Das scheint bei mir aber nicht zu passieren? Funktioniert das bei Dir?
Ja.
In deinem Logfile steht ja auch eindeutig, dass der Befehl richtig umgesetzt wird:
2017.02.05 15:54:37 5: msg rr_michael: push route command (fhem): set TB message @@Michael_XXX Test
Der Fehler ist bei TelegramBot zu suchen.
@Loredo:
Irgendwie mischt Du meiner Meinung nach die zwei Sachen.
Das @@Michael_XXX passiert ja nur, wenn msg das @@ aus dem msgContactPush 1:1 an den Bot durchreicht. Im Bot bleibt dann ein @ übrig, weil er eins entfernt. Liegt der Fehler dann trotzdem beim Telegram Bot oder bei msg, was zwei @ schickt? Und wieso funktioniert es bei Dir und bei mir nicht? Wieso funktioniert es bei mir mit einem @ in msgContactPush?
Und dann die Sache mit den residents bzw. roommates, die Home sind. Wenn msg an den Bot den Device Namen schickt, ist das dann die Schuld des Bots, wenn er damit nichts anfangen kann? Von den msgContactPush Attributen weiß er ja nichts. Die kennt doch nur msg selbst und kann die Umsetzung durchführen? msg müsste die Kontaktinfos aus msgContactPush an den Telegram Bot schicken, statt die device Namen.
Also ich zumindest kann die Schuld hier nicht beim Telegram Bot sehen. Ich werde den Entwickler aber auch nochmal anschreiben und fragen.
Zitat von: SlrG am 05 Februar 2017, 17:56:39
Das @@Michael_XXX passiert ja nur, wenn msg das @@ aus dem msgContactPush 1:1 an den Bot durchreicht. Im Bot bleibt dann ein @ übrig, weil er eins entfernt.
Der set-Befehl wird mit 2 @-Zeichen abgesetzt (siehe dein Logfileauszug), da der set-Befehl von FHEM eines davon verschluckt. Bei der internen set-Funktion von TelegramBot kommt dann 1 @-Zeichen an, was im Text geparst werden kann.
Zitat von: SlrG am 05 Februar 2017, 17:56:39
Liegt der Fehler dann trotzdem beim Telegram Bot oder bei msg, was zwei @ schickt?
Es liegt daran, dass bei TelegramBot die Adressierung so seltsam und in verschiedener Art und Weise vornehmen kann.
Zitat von: SlrG am 05 Februar 2017, 17:56:39
Und wieso funktioniert es bei Dir und bei mir nicht? Wieso funktioniert es bei mir mit einem @ in msgContactPush?
Weil ich meinen Aliasnamen verwende und du bei dir irgendwie noch die ID mit drin hast (vergleiche Reading "Contact" in TelegramBot; siehe oben wie es bei mir lautet). Das ist ein Unterschied, genau erklären kann dir das aber nur der Autor vom TelegramBot Modul.
Zitat von: SlrG am 05 Februar 2017, 17:56:39
Die kennt doch nur msg selbst und kann die Umsetzung durchführen? msg müsste die Kontaktinfos aus msgContactPush an den Telegram Bot schicken, statt die device Namen.
Tut er bei mir auch einwandfrei und meiner Meinung nach auch bei dir.
Ich kann es nicht nachvollziehen und deine Beschreibungen sind extrem kompliziert nachzuvollziehen. Es ist mein Sonntag und ich habe keine weitere Lust mich da noch tiefer reinzudenken, denn IMHO liegt hier kein Fehler im msg Befehl vor, sondern ein Verständnisfehler.
Hier mal zum Vergleich mein Session Log:
XXXstr 1> list rgr_Residents
Internals:
CHANGED
NAME rgr_Residents
NR 27
NTFY_ORDER 50-rgr_Residents
ROOMMATES rr_Julian
STATE home
TYPE RESIDENTS
Readings:
2017-02-05 14:38:36 residentsHome 1
2017-02-05 14:38:36 residentsHomeDevs rr_Julian
2017-02-05 14:38:36 residentsHomeNames Julian
XXXstr 1> list rr_Julian
Internals:
DEF rgr_Residents
NAME rr_Julian
NR 28
NTFY_ORDER 50-rr_Julian
RESIDENTGROUPS rgr_Residents,
STATE home
TYPE ROOMMATE
Readings:
2017-02-05 18:23:25 fhemMsgPush Test
2017-02-05 18:23:25 fhemMsgPushGw Telegram:@@XXX:OK
2017-02-05 18:23:25 fhemMsgPushPrio 0
2017-02-05 18:23:25 fhemMsgPushState 1
2017-02-05 18:23:25 fhemMsgPushTitle -
2017-02-05 18:23:25 fhemMsgState 1
2017-02-05 18:23:25 fhemMsgStateTypes push:1 forwards:text>push
2017-02-03 21:51:01 presence present
2017-02-05 14:38:36 state home
Attributes:
msgContactPush Telegram:@@XXX
rr_realname group
XXXstr 1> list Telegram
Internals:
CHANGED
DEF 123456789:ABCDEFGHIJKLMNOPQRSTUVWXYZ-ABC80
FAILS 0
NAME Telegram
NR 47
OLD_POLLING 95
POLLING 95
SNAME Telegram
STATE Polling
TYPE TelegramBot
Token 123456789:ABCDEFGHIJKLMNOPQRSTUVWXYZ-ABC80
UPDATER 0
URL https://api.telegram.org/bot123456789:ABCDEFGHIJKLMNOPQRSTUVWXYZ-ABC80/
WAIT 0
me 123456789:XXXstr_1,_M?nchen:@XXX_bot
sentLastResult SUCCESS
sentMsgId 1406
sentMsgPeer Julian_Pawlowski
sentMsgPeerId 123456789
sentMsgResult SUCCESS
sentMsgText Test
Contacts:
123456789 223456789:Julian_Pawlowski:@XXX
Readings:
2016-11-22 09:54:49 Contacts 223456789:Julian_Pawlowski:@XXX
2017-02-05 18:23:25 sentMsgId 1406
2017-02-05 18:23:25 sentMsgPeerId 223456789
2017-02-05 18:23:25 sentMsgResult SUCCESS
sentQueue:
XXXstr 1> msg @[rgr_Residents:residentsHomeDevs] Test
XXXstr 1>
Okay. :) Kann ich verstehen. Trotzdem vielen herzlichen Dank für Deine Hilfe bisher. Ich schaue es mir selbst nochmal in Ruhe alles an. Einen Schönen Rest vom Sonntag noch. :)
Ich habe mir das jetzt nochmal ganz in Ruhe und eine lange Zeit angesehen. Für mich steht immer noch fest, dass msg das Array mit den Device Namen aus residentsHomeDevs 1:1 an den TelegramBot weiterreicht. Der rechnet nicht mit einer per Komma getrennten Liste von Device Namen als Empfänger und kann keine Nachricht schicken.
Meine Idee war deshalb meine Roommate Devices so zu nennen, wie die Kontakte im TelegramBot. rr_michael wird bei mir Michael_XXX. Wenn dann nur Michael_XXX den Status Home hat, funktioniert auch der Befehl:
msg @[rgr_bewohner:residentsHomeDevs] test
Leider geht es nicht mehr, wenn mehrere Bewohner zu Hause sind. Dann bekommt der Telegram Bot wieder eine per Komma getrennte Liste von Empfängern und kann damit nicht umgehen.
msg globalMsg: ID=1486385291.56288.1 TYPE=push ROUTE=TB STATUS=OK PRIORITY=0 TITLE='' MSG='@[rgr_bewohner:residentsHomeDevs] Test'
2017.02.06 13:49:39 3: TelegramBot_SendIt TB: Failed with :FAILED peer not found :Michael_XXX,Kristin_XXX,Renate_XXX,Johannes_XXX::
Da frage ich jetzt nochmal im TelegramBot Thread.
@Loredo:
TelegramBot erwartet eine durch Leerzeichen getrennte Liste von Kontakten (@Kontakt1 @Kontakt2 ...). , ist für Telegram ein zulässiger Bestandteil von Kontaktnamen, so dass es deshalb nicht als Trennzeichen geeignet ist.
Wie im Thread zum TelegramBot nachzulesen ist, konnte ich das Ganze jetzt provisorisch lösen, indem ich meine Roommate Devices wie die TelegramBot Kontakte genannt habe und im Roommate Device ein userReading (residentsHomeContacts) erzeuge, dass die residentsHomeDevs in eine TelegramBot kompatible Liste umwandle und diese dann für den msg Befehl verwende.
msg @[rgr_bewohner:residentsHomeContacts] Test
Funktioniert dann und sendet den Text "Test" an alle Residents mit Status home.
Aus meiner Sicht ist das aber eine umständliche Lösung für etwas, was msg eigentlich tun sollte.
Hättest Du Interesse an einer Teamviewer Sitzung, wo ich Dich auf meinen Rechner lasse, damit Du Dir meine FHEM Installation ansehen kannst? Ich kann mir einfach nicht vorstellen, dass es bei Dir funktioniert und bei mir nur mit solchen Klimmzügen.
Hast Du mit mehreren Roommate Devices getestet? Weil in Deinem Listing hast Du nur rr_Julian in residentsHomeDevs.
Ich habe es gerade nochmals mit einer FHEM Testinstallation ausprobiert. Auch mit mehreren Devices funktioniert es so, wie es soll; meine Nachricht wird dupliziert und kommt bei jedem Empfänger an.
⋊> ~ telnet localhost 7072 12:40:46
Trying ::1...
telnet: connect to address ::1: Connection refused
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
fhem> list rgr_Parents
Internals:
CHANGED
NAME rgr_Parents
NR 54
NTFY_ORDER 50-rgr_Parents
ROOMMATES rr_Father,rr_Mother
STATE home
TYPE RESIDENTS
Readings:
2017-02-11 12:36:35 lastActivity home
2017-02-11 12:36:35 lastActivityBy Father
2017-02-11 12:36:35 lastActivityByDev rr_Father
2014-02-16 14:16:17 lastArrival 2014-02-16 14:16:17
2014-02-15 16:39:35 lastAwake 2014-02-15 16:39:35
2014-02-16 14:16:16 lastDeparture 2014-02-16 14:16:16
2014-02-16 14:16:17 lastDurAbsence 00:00:01
2014-02-16 14:16:16 lastDurPresence 00:00:03
2014-02-15 16:39:35 lastDurSleep 00:02:44
2014-02-15 16:36:51 lastSleep 2014-02-15 16:36:51
2014-02-16 14:16:17 lastState absent
2014-02-16 14:16:17 presence present
2015-01-04 16:19:19 residentsAbsent 0
2017-02-11 12:36:35 residentsAbsentDevs -
2017-02-11 12:36:35 residentsAbsentNames -
2014-02-16 13:31:53 residentsAsleep 0
2017-02-11 12:36:35 residentsAsleepDevs -
2017-02-11 12:36:35 residentsAsleepNames -
2014-02-16 13:31:53 residentsAwoken 0
2017-02-11 12:36:35 residentsAwokenDevs -
2017-02-11 12:36:35 residentsAwokenNames -
2017-02-11 12:36:35 residentsGone 0
2017-02-11 12:36:35 residentsGoneDevs -
2017-02-11 12:36:35 residentsGoneNames -
2014-02-15 16:36:51 residentsGotosleep 0
2017-02-11 12:36:35 residentsGotosleepDevs -
2017-02-11 12:36:35 residentsGotosleepNames -
2014-02-15 16:13:39 residentsGuests 0
2017-02-11 12:36:35 residentsHome 2
2017-02-11 12:36:35 residentsHomeDevs rr_Father,rr_Mother
2017-02-11 12:36:35 residentsHomeNames Status, Status
2014-02-16 13:48:12 residentsTotal 2
2017-02-11 12:36:35 residentsTotalAbsent 0
2017-02-11 12:36:35 residentsTotalAbsentDevs -
2017-02-11 12:36:35 residentsTotalAbsentNames -
2017-02-11 12:36:35 residentsTotalGuests 0
2017-02-11 12:36:35 residentsTotalGuestsAbsent 0
2017-02-11 12:36:35 residentsTotalGuestsAbsentDevs -
2017-02-11 12:36:35 residentsTotalGuestsAbsentNames -
2017-02-11 12:36:35 residentsTotalGuestsPresent 0
2017-02-11 12:36:35 residentsTotalGuestsPresentDevs -
2017-02-11 12:36:35 residentsTotalGuestsPresentNames -
2017-02-11 12:36:35 residentsTotalPresent 2
2017-02-11 12:36:35 residentsTotalPresentDevs rr_Father,rr_Mother
2017-02-11 12:36:35 residentsTotalPresentNames Status, Status
2017-02-11 12:36:35 residentsTotalRoommates 2
2017-02-11 12:36:35 residentsTotalRoommatesAbsent 0
2017-02-11 12:36:35 residentsTotalRoommatesAbsentDevs -
2017-02-11 12:36:35 residentsTotalRoommatesAbsentNames -
2017-02-11 12:36:35 residentsTotalRoommatesPresent 2
2017-02-11 12:36:35 residentsTotalRoommatesPresentDevs rr_Father,rr_Mother
2017-02-11 12:36:35 residentsTotalRoommatesPresentNames Status, Status
2017-02-11 12:36:35 residentsTotalWakeup 0
2017-02-11 12:36:35 residentsTotalWakeupDevs -
2017-02-11 12:36:35 residentsTotalWakeupNames -
2014-02-15 16:13:39 residentsTotalWayhome 0
2017-02-11 12:36:35 residentsTotalWayhomeDelayed 0
2017-02-11 12:36:35 residentsTotalWayhomeDelayedDevs -
2017-02-11 12:36:35 residentsTotalWayhomeDelayedNames -
2017-02-11 12:36:35 residentsTotalWayhomeDevs -
2017-02-11 12:36:35 residentsTotalWayhomeNames -
2014-02-16 14:16:17 state home
Attributes:
alias Parents
devStateIcon .*home:status_available:absent .*absent:status_away_1:home .*gone:status_standby:home .*none:control_building_empty .*gotosleep:status_night:asleep .*asleep:status_night:awoken .*awoken:status_available:home
group Home State
icon control_building_filled
room Residents
sortby 2
webCmd state
fhem> list rr_Father
Internals:
DEF rgr_Residents,rgr_Parents
NAME rr_Father
NR 59
NTFY_ORDER 50-rr_Father
RESIDENTGROUPS rgr_Residents,rgr_Parents,
STATE home
TYPE ROOMMATE
Readings:
2017-02-11 12:36:35 durTimerAbsence 00:00:00
2017-02-11 12:36:35 durTimerAbsence_cr 0
2017-02-11 12:40:35 durTimerPresence 00:04:00
2017-02-11 12:40:35 durTimerPresence_cr 4
2015-01-04 16:19:19 durTimerSleep 00:00:00
2015-01-04 16:19:19 durTimerSleep_cr 0
2017-02-11 12:39:32 fhemMsgPush test2
2017-02-11 12:39:32 fhemMsgPushGw TG:@223456789:OK
2017-02-11 12:39:32 fhemMsgPushPrio 0
2017-02-11 12:39:32 fhemMsgPushState 1
2017-02-11 12:39:32 fhemMsgPushTitle -
2017-02-11 12:39:32 fhemMsgState 1
2017-02-11 12:39:32 fhemMsgStateTypes push:1 forwards:text>push,text>push
2017-02-11 12:36:35 lastArrival 2017-02-11 12:36:35
2014-02-16 14:26:52 lastDeparture 2014-02-16 14:26:52
2017-02-11 12:36:35 lastDurAbsence 26182:09:43
2017-02-11 12:36:35 lastDurAbsence_cr 1570930
2014-02-16 14:26:52 lastDurPresence 00:10:35
2014-02-16 14:26:52 lastLocation home
2014-02-16 14:26:52 lastMood calm
2017-02-11 12:36:35 lastState gone
2017-02-11 12:36:35 location home
2017-02-11 12:36:35 mood calm
2017-02-11 12:36:35 presence present
2017-02-11 12:36:35 state home
2014-02-16 13:46:02 wayhome 0
Timer:
Rr_father_durationtimer:
HASH rr_Father
MODIFIER DurationTimer
NAME rr_Father_DurationTimer
Attributes:
alias Status
devStateIcon .*home:user_available:absent .*absent:user_away:home .*gone:user_ext_away:home .*gotosleep:scene_toilet:asleep .*asleep:scene_sleeping:awoken .*awoken:scene_sleeping_alternat:home .*:user_unknown
group Father
icon status_available
msgContactPush TG:@223456789
room Residents
rr_autoGoneAfter 0.1
sortby 0
webCmd state
fhem> list rr_Mother
Internals:
DEF rgr_Residents,rgr_Parents
NAME rr_Mother
NR 60
NTFY_ORDER 50-rr_Mother
RESIDENTGROUPS rgr_Residents,rgr_Parents,
STATE home
TYPE ROOMMATE
Readings:
2015-01-04 16:19:19 durTimerAbsence 00:00:00
2015-01-04 16:19:19 durTimerAbsence_cr 0
2017-02-11 12:40:31 durTimerPresence 26182:24:14
2017-02-11 12:40:31 durTimerPresence_cr 1570944
2015-01-04 16:19:19 durTimerSleep 00:00:00
2015-01-04 16:19:19 durTimerSleep_cr 0
2017-02-11 12:39:32 fhemMsgPush test2
2017-02-11 12:39:32 fhemMsgPushGw TG:@223456789:OK
2017-02-11 12:39:32 fhemMsgPushPrio 0
2017-02-11 12:39:32 fhemMsgPushState 1
2017-02-11 12:39:32 fhemMsgPushTitle -
2017-02-11 12:39:32 fhemMsgState 1
2017-02-11 12:39:32 fhemMsgStateTypes push:1 forwards:text>push,text>push
2014-02-16 14:16:17 lastArrival 2014-02-16 14:16:17
2014-02-16 14:16:16 lastDeparture 2014-02-16 14:16:16
2014-02-16 14:16:17 lastDurAbsence 00:00:01
2014-02-16 14:16:16 lastDurPresence 00:00:02
2014-02-16 14:16:16 lastLocation home
2014-02-16 14:16:16 lastMood calm
2014-02-16 14:16:17 lastState absent
2014-02-16 14:16:17 location home
2014-02-16 14:16:17 mood calm
2014-02-16 14:16:17 presence present
2014-02-16 14:16:17 state home
2014-02-16 13:46:09 wayhome 0
Timer:
Rr_mother_durationtimer:
HASH rr_Mother
MODIFIER DurationTimer
NAME rr_Mother_DurationTimer
Attributes:
alias Status
devStateIcon .*home:user_available:absent .*absent:user_away:home .*gone:user_ext_away:home .*gotosleep:scene_toilet:asleep .*asleep:scene_sleeping:awoken .*awoken:scene_sleeping_alternat:home .*:user_unknown
group Mother
icon status_available
msgContactPush TG:@223456789
room Residents
rr_autoGoneAfter 0.1
rr_passPresenceTo rr_Baby
sortby 0
webCmd state
fhem> list TG
Internals:
DEF 123456789:ABCDEFGHIJKLMNOPQRSTUVWXYZAAAAA
FAILS 0
NAME TG
NR 74
OLD_POLLING 2
POLLING 0
SNAME TG
STATE Static
TYPE TelegramBot
Token 123456789:ABCDEFGHIJKLMNOPQRSTUVWXYZAAAAA
UPDATER 0
URL https://api.telegram.org/bot123456789:ABCDEFGHIJKLMNOPQRSTUVWXYZAAAAA/
WAIT 0
me 123456789:XXX_Admin_Bot:@XXX_AdminBot
offset_id 812345677
sentLastResult SUCCESS
sentMsgId 31
sentMsgPeer Julian_Pawlowski
sentMsgPeerId 223456789
sentMsgResult SUCCESS
sentMsgText test2
Contacts:
223456789 223456789:Julian_Pawlowski:@Loredo
Hu_do_params:
NAME
addr https://api.telegram.org:443
boundary TelegramBot_boundary-x0123
buf
code 200
conn
data
displayurl <hidden>
header agent: TelegramBot/1.0
User-Agent: TelegramBot/1.0
Accept: application/json
Accept-Charset: utf-8
Content-Type: multipart/form-data; boundary=TelegramBot_boundary-x0123
hideurl 1
host api.telegram.org
httpheader HTTP/1.1 200 OK
Server: nginx/1.10.0
Date: Sat, 11 Feb 2017 11:39:32 GMT
Content-Type: application/json
Content-Length: 257
Connection: close
Access-Control-Allow-Origin: *
Access-Control-Allow-Methods: GET, POST, OPTIONS
Access-Control-Expose-Headers: Content-Length,Content-Type,Date,Server,Connection
Strict-Transport-Security: max-age=31536000; includeSubdomains
hu_blocking 0
hu_filecount 12
hu_portSfx
loglevel 4
method POST
path /bot123456789:ABCDEFGHIJKLMNOPQRSTUVWXYZAAAAA/sendMessage
protocol https
redirects 0
timeout 30
url https://api.telegram.org/bot123456789:ABCDEFGHIJKLMNOPQRSTUVWXYZAAAAA/sendMessage
args:
223456789
test2
undef
0
undef
2
Hash:
Sslargs:
Hu_upd_params:
NAME
addr https://api.telegram.org:443
buf
code 200
conn
displayurl <hidden>
header agent: TelegramBot/1.0
User-Agent: TelegramBot/1.0
Accept: application/json
Accept-Charset: utf-8
hideurl 1
host api.telegram.org
httpheader HTTP/1.1 200 OK
Server: nginx/1.10.0
Date: Sat, 11 Feb 2017 11:34:35 GMT
Content-Type: application/json
Content-Length: 304
Connection: close
Access-Control-Allow-Origin: *
Access-Control-Allow-Methods: GET, POST, OPTIONS
Access-Control-Expose-Headers: Content-Length,Content-Type,Date,Server,Connection
Strict-Transport-Security: max-age=31536000; includeSubdomains
hu_blocking 0
hu_filecount 1
hu_portSfx
isPolling update
loglevel 4
method GET
offset 0
path /bot123456789:ABCDEFGHIJKLMNOPQRSTUVWXYZAAAAA/getUpdates?offset=0
protocol https
redirects 0
timeout 5
url https://api.telegram.org/bot123456789:ABCDEFGHIJKLMNOPQRSTUVWXYZAAAAA/getUpdates?offset=0
Hash:
Sslargs:
Readings:
2017-02-11 12:34:35 Contacts 223456789:Julian_Pawlowski:@Loredo
2017-02-11 12:31:41 PollingErrCount 0
2017-02-11 12:35:15 fhemMsgPush test
2017-02-11 12:35:15 fhemMsgPushGw TG:OK
2017-02-11 12:35:15 fhemMsgPushPrio 0
2017-02-11 12:35:15 fhemMsgPushState 1
2017-02-11 12:35:15 fhemMsgPushTitle -
2017-02-11 12:35:15 fhemMsgState 1
2017-02-11 12:35:15 fhemMsgStateTypes push:1 forwards:text>push
2017-02-11 12:34:35 msgChat
2017-02-11 12:34:35 msgFileId
2017-02-11 12:34:35 msgId 19
2017-02-11 12:34:35 msgPeer Julian_Pawlowski
2017-02-11 12:34:35 msgPeerId 223456789
2017-02-11 12:35:20 msgReplyMsgId 0
2017-02-11 12:34:35 msgText test
2017-02-11 12:39:32 sentMsgId 31
2017-02-11 12:39:32 sentMsgPeerId 223456789
2017-02-11 12:39:32 sentMsgResult SUCCESS
sentQueue:
Attributes:
defaultPeer 223456789
fhem> msg @[rgr_Parents:residentsHomeDevs] test2
fhem>
In diesem Beispiel kommt halt die selbe Nachricht 2x an, weil beide ROOMMATE Devices den gleichen Empfänger angegeben haben.
Logfile:
2017.02.11 12:41:46.887 3: msg rr_Father: ID=1486813306.88261.1 TYPE=push ROUTE=TG RECIPIENT=@223456789 STATUS=OK PRIORITY=0 TITLE='' MSG='test2'
2017.02.11 12:41:46.889 3: msg rr_Mother: ID=1486813306.88261.2 TYPE=push ROUTE=TG RECIPIENT=@223456789 STATUS=OK PRIORITY=0 TITLE='' MSG='test2'
Für jeden Empfänger wird ein einzelnes Set-Kommando erzeugt; die Liste wird also gar nicht an TelegramBot übergeben, sondern wie erwartet vorher vom msg-Befehl aufgelöst.
Achso: ich gehe selbstverständlich davon aus, dass du ALLE Fhem Module auf dem aktuellsten Entwicklungsstand hast (kein Cherry-Picking, keine Fhem Version 5.7 ohne nachfolgendes Update).
@Loredo:
Vielen Dank für Deine Mühe das so zu dokumentieren. Nun sieht es auch für mich so aus, als ob der Fehler bei mir liegt. Wieso weiß ich nicht, weil eigentlich sollte FHEM inklusive aller Module auf dem aktuellsten Stand sein. Ich werde nochmal alles entfernen und neu beginnen. Vielleicht hilft das ja.
@all:
Nachdem ich alles zu residents, roommates und msg komplett gelöscht und neu angefangen habe, funktioniert es nun tatsächlich! Ich habe zwar leider keine Ahnung, was ich diesmal anders gemacht habe, aber da es jetzt geht, muss beim ersten Versuch irgend etwas falsch gewesen sein.
Vielen vielen Dank an Loredo, der mir immer geantwortet hat, obwohl ich sicher etwas anstrengend war. :)
Ist geplant Pushbullet zu unterstützen?
Ist bereits im Standard-Schema hinterlegt (ungetestet):
fhem> get globalMsg routeCmd push Pushbullet
PUSH: DEFAULT COMMANDS
-------------------------------------------------------------------------------
Pushbullet
Priority Normal:
set %DEVICE% message %MSG% | %TITLE% %RECIPIENT%
Default Values:
RECIPIENT = [EMPTY]
Priority High:
set %DEVICE% message %MSG% | %TITLE% %RECIPIENT%
Default Values:
RECIPIENT = [EMPTY]
Priority Low:
set %DEVICE% message %MSG% | %TITLE% %RECIPIENT%
Default Values:
RECIPIENT = [EMPTY]
Alternativ kannst du über msgCmd* ein eigenes Schema definieren, welches zu Pushbullet passt.
Oh cool super danke. Hatte dazu keine Angaben gefunden, werde mich dann aber mal intensiver mit der Materie beschäftigen...
Hi,
ich verstehe irgendwie die konfiguration nicht bzw. wie ich das modul benutze. Ich würde gerne via jabber eine nachricht verschicken. Ein device mit dem Name jabber habe ich und auch via einer myUtils methode funktioniert alles (sendMejabberMessage(text)) und auch mit dem Device. würde gerne das msg modul / command nutzen. was muss ich jetzt genau tun?
danke + gruß
Zitat von: rageltus am 14 März 2017, 20:43:45
ich verstehe irgendwie die konfiguration nicht bzw. wie ich das modul benutze. Ich würde gerne via jabber eine nachricht verschicken. Ein device mit dem Name jabber habe ich und auch via einer myUtils methode funktioniert alles (sendMejabberMessage(text)) und auch mit dem Device. würde gerne das msg modul / command nutzen. was muss ich jetzt genau tun?
Du musst den Jabber Empfängernamen in einem Attribut msgContactPush bei einem beliebigen FHEM Device hinterlegen und kannst dann so eine Nachricht schicken:
msg @FHEMDeviceName Dies ist die Nachricht
Ich habe gerade ein Update für den msg-Befehl eingecheckt.
Damit hält Support für parseParams() Einzug. Das hat verschiedene Auswirkungen:
1. Die vormals als "Advanced Options" betitelten Optionen nennen sich ab sofort "User Parameters".
2. Die umständliche Notation der User Parameter über O[{}] am Ende der Nachricht kann entfallen und stattdessen kann direkt mit key=value Angaben im Nachrichtentext gearbeitet werden. Die alte Notation bleibt vorerst aus Kompatibilitätsgründen erhalten.
3. Alle Parameter des msg-Befehls können jetzt auch alternativ als key=value Paare angegeben werden, eine Mischung beider Notationen ist möglich. Gültige Keys sind: msgType, msgRcpt, msgPrio, msgTitle
4. Wenn man in seinem Nachrichtentext key=value Angaben verschicken will und das nicht als User Parameter erkannt werden soll, muss der Nachrichtentext selbst ebenfalls als User Parameter übergeben werden:
msg msgText='Dies ist mein Text mit key=value darin'5. Wenn ein Gateway Modul parseParams unterstützt, dann werden alle User Parameter, die dem msg-Befehl übergeben worden sind, an das Modul durchgereicht (ist bei Pushover z.B. der Fall). Um bei gleichzeitiger Verwendung verschiedener Nachrichtenmodule eine Überlappung zu vermeiden, können Keys mit dem Namen des Moduls gefolgt von einem Unterstrich als Präfix übergeben werden. Dieses Präfix wird dann abgeschnitten, so dass das richtige Zielmodul dann seinen Parameter so erhalten kann, wie es das braucht.
6. Mit Punkt 5 werden die im Schema bisher vorhandenen modulspezifischen Platzhalter obsolete (zumindest für Module mit parseParams Support). Sie bleiben aber vorerst noch darin enthalten, um Abwärtskompatibilität zu bewahren.
Hier ein Vergleich:
Vorher:
msg push @Pushover1 1 |Titel| Dies ist eine wichtige Nachricht. O[{"Pushover_SOUND":"siren"}]
Nachher:
# msg-Befehl kümmert sich um den Parameter; Funktioniert mit jedem Modul, hängt vom definierten msg-Schema ab (entweder aus der Default Vorlage oder aus den msgCmd* Attributen)
msg push @Pushover1 1 |Bitte beachten| Dies ist eine wichtige Nachricht. Pushover_SOUND=siren
Weitere Beispiele:
# User Parameter 'sound' wird direkt ans Pushover Modul durchgereicht
msg push @Pushover1 1 |Bitte beachten| Dies ist eine wichtige Nachricht. Pushover_sound=siren
# Das hier geht auch, aber "sound" könnte mit anderen Modulen überlappen, die "siren" dann nicht verstehen
msg push @Pushover1 1 |Bitte beachten| Dies ist eine wichtige Nachricht. sound=siren
# Priorität als User Parameter
msg push @Pushover1 |Bitte beachten| Dies ist eine wichtige Nachricht. msgPrio=1
# der Titel wird als User Parameter übergeben
msg push @Pushover1 1 Dies ist eine wichtige Nachricht msgTitle='Bitte beachten'
# Type als User Parameter
msg @Pushover1 1 Dies ist eine wichtige Nachricht. msgType=push
# Empfänger als User Parameter
msg push 1 Dies ist eine wichtige Nachricht. msgRcpt=@Pushover1
# Text als User Parameter
msg push @Pushover1 1 msgText='Dies ist eine wichtige Nachricht.'
# Alles über User Parameter
msg msgType=push msgRcpt=@Pushover1 msgPrio=1 msgText='Dies ist eine wichtige Nachricht.'
Für msg relevante Module
mit parseParams Support:
Für msg relevante Module
ohne parseParams Support:
- AMAD
- SB_PLAYER
- SONOSPLAYER
- Text2Speech
- HUEDevice
- Fhemapppush
- Jabber
- Pushbullet
- PushNotifier
- TelegramBot
- yowsup
- KODI
- XBMC
- PostMe
Ich habe gerade Support für das PostMe (https://fhem.de/commandref.html#PostMe) Modul eingebaut.
Siehe auch hier:
https://forum.fhem.de/index.php/topic,69683.msg612220.html#msg612220
hi,
seit dem letzten Update bekomme ich bei Priorität 2
msg push 2 test
folgende Fehlermeldung:
ERROR: Could not find any general Mail contact. Please specify a destination device or set attributes in general msg configuration device globalMsg : msgContactMail | msgRecipientMail | msgRecipient
liegt daran dass ich Mail nicht konfiguriert hatte. Bis zum letzten Update hatte er hingenommen dass mail nicht konfiguriert war und keinen Fehler ausgespuckt.
Grundsätzlich aber richtiges Verhalten, wenn ich das richtig verstanden habe, da Prio 2 ja auf allen Kanälen rausgehauen wird, oder?
Also habe ich sendmail nach der Anleitung aus dem WIKI installiert https://wiki.fhem.de/wiki/E-Mail_senden (https://wiki.fhem.de/wiki/E-Mail_senden) inkl 99_MyUtils-Funktion.
Diese funktion habe ich dann im globalMsg-Device bekannt gemacht:
attr globalMsg msgCmdMail {DebianMail('%DEVICE%','%TITLE%','%MSG%')}
Wenn ich nun eine mail über den direkten Funktionsaufruf schicke, ist alles gut. Auch über den msg-Befehl kommt die Mail an (habe unter msgContactMail eine Mailadresse eingetragen). Allerdings habe ich im Log noch eine Fehlermeldung:
2017.03.29 11:13:19 1: sendEmail RCP: test@test.de
2017.03.29 11:13:19 1: sendEmail Subject: L2R-FHEM Hinweis
2017.03.29 11:13:19 1: sendEmail Text: test
2017.03.29 11:13:19 1: sendEmail Anhang:
2017.03.29 11:13:21 1: sendEmail returned: Mar 29 11:13:21 pi-fhem sendEmail[4322]: Email was sent successfully!
2017.03.29 11:13:21 3: msg globalMsg: ID=1490778799.68928.1 TYPE=mail ROUTE=test@test.de STATUS=OK PRIORITY=0 TITLE='L2R-FHEM Hinweis' MSG='test'
2017.03.29 11:13:25 1: Error: >test@test.de< has no TYPE, but following keys: ><
die ersten 5 Zeilen sind Logausgaben von der MailFunktion, die letzten beiden stammen von msg.
darf ich bei msgContactMail keine Mailadresse eintragen? Falls nicht, wie muss ich das dann konfigurieren?
Gruß Michael
Zitat von: l2r am 29 März 2017, 11:16:35
seit dem letzten Update bekomme ich bei Priorität 2
msg push 2 test
folgende Fehlermeldung:
ERROR: Could not find any general Mail contact. Please specify a destination device or set attributes in general msg configuration device globalMsg : msgContactMail | msgRecipientMail | msgRecipient
Das sollte mit dem heutigen Update behoben sein.
Zitat von: l2r am 29 März 2017, 11:16:35
Auch über den msg-Befehl kommt die Mail an (habe unter msgContactMail eine Mailadresse eingetragen). Allerdings habe ich im Log noch eine Fehlermeldung:
2017.03.29 11:13:19 1: sendEmail RCP: test@test.de
2017.03.29 11:13:19 1: sendEmail Subject: L2R-FHEM Hinweis
2017.03.29 11:13:19 1: sendEmail Text: test
2017.03.29 11:13:19 1: sendEmail Anhang:
2017.03.29 11:13:21 1: sendEmail returned: Mar 29 11:13:21 pi-fhem sendEmail[4322]: Email was sent successfully!
2017.03.29 11:13:21 3: msg globalMsg: ID=1490778799.68928.1 TYPE=mail ROUTE=test@test.de STATUS=OK PRIORITY=0 TITLE='L2R-FHEM Hinweis' MSG='test'
2017.03.29 11:13:25 1: Error: >test@test.de< has no TYPE, but following keys: ><
die ersten 5 Zeilen sind Logausgaben von der MailFunktion, die letzten beiden stammen von msg.
darf ich bei msgContactMail keine Mailadresse eintragen?
Du sollst sogar ;)
Irgendwie scheint Perl beim reinen überprüfen, ob ein Hash mit dem Namen der E-Mail Adresse vorhanden ist automatisch dort einen leeren Hash anzulegen, was FHEM seit einiger Zeit dann auch entsprechend meldet, da somit quasi ein komplett leeres FHEM Device angelegt wird. Ich muss mal genauer schauen, wie man das verhindern kann.
Zitat von: l2r am 29 März 2017, 11:16:35
Allerdings habe ich im Log noch eine Fehlermeldung:
2017.03.29 11:13:25 1: Error: >test@test.de< has no TYPE, but following keys: ><
Ich konnte den Fehler finden (https://forum.fhem.de/index.php/topic,63709.msg614704.html#msg614704) und habe ihn entsprechend korrigiert.
Ok, ich verzweifle absolut und muss jetzt doch fragen.
- Ich habe Pushover als Device in FHEM angelegt, das heißt auch Pushover.
- Mein Handy heißt bei Pushover HA_Ede
- ich habe einen Roommate rr_Etienne
- ich habe msg angelegt
wie muss ich es nun machen, dass ich eine Nachricht mittels msg über Pushover nur an mein Handy schicke?
- bei globalMsg habe ich bereits msgcmdPush mit "Pushover" belegt (hatte auch mal mit :USERKey noch gearbeitet, hat auch nix gebracht)
- bei rr_Etienne habe ich bei msgContactPush folgende Dinge versucht: "HA_Ede" / "Pushover:HA_Ede" / "Pushover:@HA_Ede" / "Pushover:@@HA_Ede"
die Nachricht habe ich wie folgt versucht zu senden:
msg rr_Etienne Test
msg @rr_Etienne Test
und nie kam sie nur bei mir, oder generell nicht an. Im Log steht immer bei Status ok:
2017.04.02 13:21:59 3: msg rr_Etienne: ID=1491132119.6691.1 TYPE=push ROUTE=Pushover RECIPIENT=@@HA_Ede STATUS=OK PRIORITY=0 TITLE='' MSG='Test3'
2017.04.02 13:22:47 3: msg rr_Etienne: ID=1491132167.89592.1 TYPE=push ROUTE=Pushover RECIPIENT=@HA_Ede STATUS=OK PRIORITY=0 TITLE='' MSG='Test4'
2017.04.02 13:24:15 3: msg rr_Etienne: ID=1491132255.23546.1 TYPE=push ROUTE=Pushover RECIPIENT=@HA_Ede STATUS=OK PRIORITY=0 TITLE='' MSG='Test5'
2017.04.02 13:24:47 3: msg rr_Etienne: ID=1491132287.72375.1 TYPE=push ROUTE=Pushover RECIPIENT=HA_Ede STATUS=OK PRIORITY=0 TITLE='' MSG='Test6'
2017.04.02 13:37:55 3: msg rr_Etienne: ID=1491133075.59593.1 TYPE=push ROUTE=Pushover RECIPIENT=HA_Ede STATUS=OK PRIORITY=0 TITLE='' MSG='Test8'
Was mache ich falsch?
attr rr_Etienne msgContactPush Pushover:HA_Ede
msg @rr_Etienne Test
oder
attr rr_Etienne msgContactPush Pushover:USERKEY:HA_Ede
msg @rr_Etienne Test
Wenn du beim Pushover das Attribut verbose=4 setzt, dann siehst du die Zeile, die an Pushover geschickt wird. Dort ist dann &device=HA_Ede enthalten.
2017.04.02 18:17:13.991 4: Pushover Pushover: REQ messages.json/&message=test&device=HA_Ede&token=aABCDEF&user=uGHIJKLMN
Sofern dann trotzdem die Nachricht an alle Geräte geschickt wird, liegt ein Fehler beim Pushover Dienst vor oder dein Gerät heißt bei Pushover unter der User-ID nicht HA_Ede.
genau so hatte ich es gemacht. Und scheinbar kommt beim Pushover nix an, weil auch mit verbose 5 sehe ich keine Reaktion vom Pushovermodul. Es scheint, dass msg die Daten nicht an Pushover über gibt. Wobei das Modul "Pushover" heißt, habe es extra nochmal gecheckt eben.
Edit:
Direkt aus dem Pushover lässt sich auch alles versenden, nur die Verbindung von Resident zu Pushover scheint nicht zu klappen. Beides nochmal getestet und das Pushover Device nochmal umbenannt zum Test. Bleibt dabei, bei Pushover kommt nix an.
Über
attr globalmsg msgcontactPush Pushover
kommt bei allen die Nachricht an, die ich mit
msg Test
versende. Ich sehe einfach den Fehler nicht.
Edit:
Ich fresse einen Besen. Ich habe kein Plan warum es jetzt geht. Ich habe einfach nochmal im rr_Etienne ein anderes Handy genommen und getestet, da kam es an. Dann habe ich es wieder auf
Pushover:HA_Ede
umgestellt und es geht auf einmal. Ich habe NULL Plan warum. Hauptsache es geht. Danke für die "Hilfe" :D
Du scheinst das Konzept noch nicht ganz verstanden zu haben.Wenn du explizit an ein Device etwas senden willst, musst du es mit einem @ vorne dran übergeben. Sonst kann es nicht erkannt werden.
Sucht nach msgContactPush oder msgContactMail am Device vom Typ msgConfig (heißt standardmäßig globalMsg, wenn man es nicht umbenannt hat):
msg Test
Sucht nach msgContactPush oder msgContactMail unter rr_Etienne. Wenn dort nichts gefunden wird fällt es auf globalMsg zurück und sucht dort:
msg @rr_Etienne Test
msgContact* hat generell das Format:
DEVICE:SubDevice:TerminalDevice
DEVICE ist der FHEM Gerätename für das Gateway.
SubDevice und TerminalDevice sind optional oder je nach Ziel-Gateway auch notwendig. Deren Format hängt entscheidend davon ab, wie es das Ziel-Gateway erwartet.
Konzept habe ich verstanden, deswegen hatte der Fehler keinen Sinn gemacht. Es war defakto so, dass msg nichts ans Pushover Modul gegeben hat, wenn es direkt an den Roommate gehen sollte. Erst nachdem ist testweise im gleichen Resident mal ein anderes Handy als Ziel angegeben hatte. Danach habe ich es wieder auf HA_Ede geändert und dann kamen auch die Nachrichten an. Keine Ahnung wieso dann erst. Die Nachrichten an alle mittels
msg Test kamen die ganze Zeit schon an.
Zitat von: Amenophis86 am 02 April 2017, 19:05:41
Es war defakto so, dass msg nichts ans Pushover Modul gegeben hat, wenn es direkt an den Roommate gehen sollte. Erst nachdem ist testweise im gleichen Resident mal ein anderes Handy als Ziel angegeben hatte. Danach habe ich es wieder auf HA_Ede geändert und dann kamen auch die Nachrichten an. Keine Ahnung wieso dann erst. Die Nachrichten an alle mittels
Das klingt schon irgendwie nach Voodoo, kann es aber bekanntermaßen nicht sein. ;)
Wenn du verbose=5 beim ROOMMATE Device setzt, dann kriegst du auch genau erklärt, was der msg-Befehl tut und wie der generierte Befehl aussieht.
Zitat von: Loredo am 02 April 2017, 22:27:06
Das klingt schon irgendwie nach Voodoo, kann es aber bekanntermaßen nicht sein. ;)
gebe ich dir zu 100% recht und bin auch vom Glauben abgefallen, als es plötzlich funktionierte :D Habe allerdings immer noch nicht herausfinden können was genau der Fehler war. Solange er nicht wieder auftritt soll es mir recht sein. Und reproduzieren zum prüfen schaffe ich es nicht. Vermutlich habe ich irgendwo was falsch gemacht und kann es nicht mehr sagen. Aber wie gesagt, Hauptsache es klappt jetzt und vielen Dank für die Hilfe hier und in den ganzen anderen Themen bezüglich meiner Fragen. Bin jetzt schon begeistert von msg und Resident :)
hi,
hab heute morgen ein update gemacht und erhalte folgende Meldung im Log:
Undefined subroutine &main::msgConfig_IsDevice called at ./FHEM/75_MSG.pm line 464.
FhemWeb ist anschließend nicht mehr aufrufbar.
Nachdem ich die 75_msgConfig.pm restored habe ist alles wieder gut
Gruß Michael
Auch ich musste einen Restore wg. benanntem Problem machen.
Hatte mich schon gewundert warum keine msg kam nach restart und dann war FHEM tot.
Gruß
Dan
Ich hatte die zweite Datei gestern nicht mit eingecheckt, da dort eigentlich bereits (unvollständige) Änderungen für das Queuing drin sind.
Dabei ist mir missfallen, dass die Funktionsnamen auch hätten angepasst werden sollen. Ich habe die zweite Datei gerade eingecheckt und hoffentlich die Queue Funktionen gut genug deaktiviert. Download für Quickfix hier (https://svn.fhem.de/trac/export/HEAD/trunk/fhem/FHEM/75_MSG.pm).
In solchen Momenten fehlt mir mal wieder ein vernünftiges VCS wie Git, wo man gescheit branchen und Cherry Picking machen kann... #hateSVN
Quickfix läuft. Danke.
hi,
mir ist heute im Log noch etwas aufgefallen:
\1 better written as $1 at ./FHEM/75_MSG.pm line 1920.
\2 better written as $2 at ./FHEM/75_MSG.pm line 1920.
2017.04.10 10:17:28 3: msg rr_Michael: ID=1491812248.72979.1 TYPE=push ROUTE=PushMichael STATUS=OK PRIORITY=0 TITLE='' MSG='FHEM reboot'
der msg-Befehl wird durch folgendes Notify ausgelöst:
defmod Reboot_Notify notify global:INITIALIZED msg push @rr_Michael FHEM reboot
was mache ich falsch?
Das verhalten tritt aber nur nach einem shutdown restart auf. Wenn ich danach nochmal den msg-Befehl absetzte, dann ist alles sauber.
Gruß Michael
Ich habe dafür gestern noch einen kleinen Patch eingecheckt, der heute bereitsteht.
jo,
hab ich heute morgen beim Update schon mitbekommen. Sieht alles gut aus.
Besten Dank!
Gruß Michael
Irgendwie scheint mein msg dazu zuführen, dass Pushover sich disconnected. Ich habe jetzt zweimal mit folgender Nachricht geschafft, dass Pushover keine Verbindung mehr hat:
msg @rr_Etienne title="Bewegung Erkannt" msgPrio=2 retry=100 expire=3600 Pushover_sound=siren Eine Bewegung wurde erkannt!
Ne Ahnung woran das liegen könnte?
EDIT:
Ich würde ja gerne ein Log beilegen mit verbose 5, aber jetzt lässt es sich nicht mehr reproduzieren.
Hallo,
seit dem letztem fhem update (13.4.17) verhält sich pushover anders:
2017-04-14 19:34:38 Pushover pushmsg msg 'Garage Tor rechts geöffnet' "0"
2017-04-14 19:34:39 Pushover pushmsg lastTitle: Garage Tor rechts geöffnet
2017-04-14 19:34:39 Pushover pushmsg lastMessage: 0
2017-04-14 19:34:39 Pushover pushmsg lastAction: -
2017-04-14 19:34:39 Pushover pushmsg lastDevice: fp2,htconex
2017-04-14 19:34:39 Pushover pushmsg lastRequest:xxxxxxxxxxxxxxxxxxxx
2017-04-14 19:34:39 Pushover pushmsg lastResult: Error 400: message cannot be blank
2017-04-14 19:34:39 Pushover pushmsg error
Mit ein wenig testen habe herausgefunden, dass es am Parameter "0" liegt.
Hat sich da in der Syntax etwas geändert, denn es hat jahrelang funktioniert.
Frohe Ostern!
Zitat von: uprinz am 14 April 2017, 20:06:16
2017-04-14 19:34:39 Pushover pushmsg lastResult: Error 400: message cannot be blank
2017-04-14 19:34:39 Pushover pushmsg error
Mit ein wenig testen habe herausgefunden, dass es am Parameter "0" liegt.
Hat sich da in der Syntax etwas geändert, denn es hat jahrelang funktioniert.
Das hier ist nicht ganz der richtige Thread. Hier geht es um den msg-Befehl, nicht das Pushover Modul.
Dennoch: Die Fehlermeldung kommt vom Pushover Dienst selbst. Der Nachrichten Text "0" wird zwar richtig übertragen, aber von Pushover (wohl dann offenbar neuerdings) als leere Zeichenkette interpretiert. Da eine Nachricht zwingend einen Nachrichtentext haben muss, wird die Nachricht nicht verarbeitet.
hi,
ich finde msg klasse und es geht auch soweit,
nur möchte ich gerne eine Mail formatieren:
doif zur Statusabfrage der Fenster (9x und geht auch)
Ausgabe:
<TAB> Fenster sind noch geöffnet:<BR>
<TAB> <TAB>Links<TAB>Rechts
<TAB> Wohnzimmer<TAB>geschlossen<TAB>offen<BR>
<TAB> Arbeitszimmer<TAB>geschlossen<TAB>offen<BR>
usw.
alles funktioniert auser <TAB> <BR>
msg |Fenster| "Guten Tag /n Aktuell sind noch folgende Fenster offen: /n /n hallo"
msg |Fenster| Guten Tag /n Aktuell sind noch folgende Fenster offen: /n /n hallo
war jetzt mal ein versuch von mir, geht aber auch nicht,
kann mir da vielleicht jemand weiterhelfen,danke
gruss
ps:
(soweit bin ich gekommen::nur noch nich glücklich)
Guten Tag
Es sind noch folgende Fenster offen
closed closed Wohnzimmer
closed closed Arbeitszimmer
closed closed Schlafzimmer
closed closed Küche
closed Bad
mit freudlichen grüßen
ihr FHEM-Server
Hi Loredo,
ich bin mit dem msg-Befehl für mich nicht warm geworden und haben meinen Kommunikation anders gelöst.
Frage: wie werde ich die Einstellungen nun wieder los? (insbesondere die Attribute bei Global). Wenn ich sie manuell lösche, sind sind kurze Zeit später wieder da.
VG Yil
Bin mir nicht sicher, ob es an DOIF, oder msg liegt, aber fange mal hier an mit der Fehlersuche. Ich habe folgendes DOIF definiert:
([?Abfall:KLAbfallkalender_EFBAltpapier_tage] eq 1 and [19:00])
(msg @rr_Etienne,@rr_Anja title="Abfallerinnerung" Morgen wird die PAPIERtonne abgeholt)
DOELSEIF ([?Abfall:KLAbfallkalender_EFBBioabfall_tage] eq 1 and [19:00])
(msg @rr_Etienne,@rr_Anja title="Abfallerinnerung" Morgen wird die BIOtonne abgeholt)
DOELSEIF ([?Abfall:KLAbfallkalender_EFBGelberSack_tage] eq 1 and [19:00])
(msg @rr_Etienne,@rr_Anja title="Abfallerinnerung" Morgen wird der GELBESACK abgeholt)
DOELSEIF ([?Abfall:KLAbfallkalender_EFBRestabfall_tage] eq 1 and [19:00])
(msg @rr_Etienne,@rr_Anja title="Abfallerinnerung" Morgen wird die RESTMÜLLtonne abgeholt)
DOELSEIF ([?Abfall:KLAbfallkalender_EFBSchadstoffmobilimAbfuhrbezirk_tage] eq 1 and [19:00])
(msg @rr_Etienne,@rr_Anja title="Abfallerinnerung" Morgen ist das Schadstoffmobil in der Nähe)
Allerdings scheint es ein Problem mit der Nachricht zu geben. Es kommt bei allen Geräten @rr_Etienne als Nachricht an und folgender Fehler:
rr_Anja title="Abfallerinnerung" Morgen wird die PAPIERtonne abgeholt: Unknown command rr_Anja, try help.
Im Log steht:
2017.04.19 21:31:54 3: msg globalMsg: ID=1492630314.55022.1 TYPE=push ROUTE=Pushover STATUS=OK PRIORITY=0 TITLE='' MSG='@rr_Etienne'
2017.04.19 21:31:54 2: KL.Abfall.Erinnerung: rr_Anja title="Abfallerinnerung" Morgen wird die PAPIERtonne abgeholt: Unknown command rr_Anja, try help.
Ich dachte eigentlich, dass mittels Komma mehrer Empfänger erreicht werden können. Gebe ich den gleichen Befehl in die Befehlszeile ein, dann funktioniert er auch richtig. Sollte ich mich an Damian wenden, weil das Problem DOIF ist, dann sry fürs falsche posten.
(msg @rr_Etienne,@rr_Anja title="Abfallerinnerung" Morgen wird die PAPIERtonne abgeholt)
Kann so mit DOIF nicht funktioniert haben.
Komma ist bei DOIF ein Trennzeichen, daher doppelt klammern, um den Ausdruck zusammenzulassen.
((msg @rr_Etienne,@rr_Anja title="Abfallerinnerung" Morgen wird die PAPIERtonne abgeholt))
macht Sinn. Da hab ich einfach nicht dran gedacht, oh man. Danke für den Hinweis. Also doch ein DOIF Problem gewesen.
Zitat von: Yil am 19 April 2017, 09:38:05
Frage: wie werde ich die Einstellungen nun wieder los? (insbesondere die Attribute bei Global). Wenn ich sie manuell lösche, sind sind kurze Zeit später wieder da.
Du hast übersehen das msgConfig Device aufzuräumen (Standardname: globalMsg, wenn du es nicht umbenannt hast). Ansonsten werden die User Readings bei jedem Neustart natürlich wieder hinzugefügt.
Mit diesem Device lassen sich auch die Readings aufräumen. Alternativ:
deletereading .* fhemMsg.*
Zitat von: eisman am 18 April 2017, 12:31:20
nur möchte ich gerne eine Mail formatieren:
doif zur Statusabfrage der Fenster (9x und geht auch)
Geht die Formatierung denn überhaupt ohne den msg-Befehl, wenn du den Sendebefehl für die Email direkt ausführst? Das wäre zunächst zu klären.
Ich möchte gerne die Benachrichtigung auf meinem FHEM Server standardisierten. Dabei bin ich auf den msg Befehl gestoßen. Dazu habe ich folgende frage: Ist es möglich einen anderen Push Dienst außer Pushover einzubinden? Aus dem Wiki wurde ich nicht ganz schlau [emoji846]
Das ist ja das schöne: Du kannst jedes FHEM Modul benutzen, was du möchtest. Für alle von FHEM unterstützen Pushdienste sind Standard Befehle hinterlegt, welche man aber mit den msgCmd* Attributen übersteuern kann. Wie die Standardbefehle aussehen, kann einem das msgConfig Modul sagen. Davon wird eine Instanz automatisch angelegt, wenn man den msg-Befehl das erste Mal anlegt. Das Device heißt dann "globalMsg", man kann es aber umbenennen wir man mag.
Der Befehl "get globalMsg routeCmd push" zeigt die Standard Schemata für alle Push Module an. Normalerweise muss man da nichts ändern, die Platzhalter werden vom msg-Befehl automatisch entsprechend befüllt.
Danke für die Rückmeldung. :)
Mein verwendeter Push Dienst ist leider nicht als FHEM Modul vorhanden. Ich teste mal Pushover aus.
Habe im Augenblick Probleme Spezielle Endgeräte zu Adressieren. Diese Hilfe habe ich gefunden:
Zitat von: Loredo am 05 Dezember 2015, 15:05:16
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
Der obere Teil funktioniert. Allerdings in dieser Form:
msg push @PushoverDevice:iPhone Dies ist eine Nachricht, die nur an das iPhone geschickt wird.Ich würde es gerne aber wie unten beschrieben umsetzten. Leider kommt folgende Meldung:
Device myDevice does not existHat jemand eine Idee?
du musst das Device an das du schicken möchtest ja auch anlegen.
myDevice gibt es nicht und ist wie der Name schon sagt als Platzhalter im Beispiel zu verstehen.
Dein Pushoverdevice definierst du im Fhem. Bei mir heißt es PushMichael
Jetzt kann ich mit
msg push @PushMichael Testnachricht
an dieses Device eine Nachricht schicken.
Der Vorteil von Msg ist, dass ich für jedes beliebige in FHEM angelegte Device definieren kann wie ich eine Nachricht an dieses Device schicke.
Als Beispiel:
Ich habe einen Dummy der heißt Test.
dem Dummy kann ich mit dem Attribut msgContactPush ein Pushover Device, über dass die Nachricht verschickt werden soll, hinzufügen.
konkret:
attr msgContactPush PushMichael
somit kann ich jetzt sagen:
msg @Test Nachricht
jetzt wird an Test eine Nachricht geschickt, die an das Pushoverdevice PushMichael weitergegeben wird und dann schließlich auf dem Handy landet.
Ich hoffe ich habe ein bisschen Licht ins Dunkel gebracht
Gruß Michael
EDIT: und das charmante ist, wenn du dein Pushoverdevice im Device globalMsg im Attribut msgContactPush angelegt hast, dann wird dieses immer genommen wenn im Angesprochenen Device das Attribut nicht gesetzt ist.
Somit ist dann auch :
msg push Nachricht
oder noch kürzer
msg Nachricht
möglich.
Danke 8)
Der Hinweis mit dem Dummy hat mir gefehlt ;)
Zitat von: Loredo am 20 April 2017, 08:54:21
Du hast übersehen das msgConfig Device aufzuräumen (Standardname: globalMsg, wenn du es nicht umbenannt hast). Ansonsten werden die User Readings bei jedem Neustart natürlich wieder hinzugefügt.
Mit diesem Device lassen sich auch die Readings aufräumen. Alternativ:
deletereading .* fhemMsg.*
Natürlich - vielen Dank!
Nächste Frage von mir, wenn ich in der action folgende zwei Befehle einbauen will, wie wäre die richtige Syntax?
Erst soll Anja.Kaffe auf off gesetzt werden und dann soll noch das at definiert werden. Aber natürlich soll das ganze erst passieren, wenn die url_title gedrückt wurde und nicht gleich.
msg @rr_Etienne title="Kaffe morgen AUSschalten?" Pushover_action="set Anja.Kaffe off; define Anja.Kaffe.An at +12:00 set Anja.Kaffe on" url_title="Morgen Kaffe AUSschalten?" expire=3600 Kaffe wird morgen um [KU.Kaffe.Anja:timer_01_c01] eingeschaltet. Soll er für morgen ausgeschaltet werden?
Leider bekomme ich die Meldung, dass die url_titel fehlt und direkt das define ausgeführt wird. Auch mit ;; funktioniert es nicht. Auch mit \; habe ich es nicht hinbekommen.
DU hast richtig erkannt, dass das Semikolon von dem FHEM Befehlszeileninterpreter besonders behandelt wird.
Damit es dort nicht abgeschnitten wird und richtig beim msg-Befehl und dem Pushover Modul ankommt, musst du aus jedem Semikolon zwei machen. Allerdings darf danach kein Leerzeichen sein.
Richtig ist also:
set Pushover msg title="Kaffe morgen AUSschalten?" action="set Anja.Kaffe off;;define Anja.Kaffe.An at +12:00 set Anja.Kaffe on" url_title="Morgen Kaffe AUSschalten?" expire=3600 Kaffe wird morgen um [KU.Kaffe.Anja:timer_01_c01] eingeschaltet. Soll er für morgen ausgeschaltet werden?
Das mit zwei ; hatte ich versucht, wusste jedoch nicht, dass der Übeltäter das Leerzeichen ist. Ich danke für die Information :)
ZitatIch habe einen recht hohen Anspruch an die Doku und wollte sie daher nicht so hinro**** (https://forum.fhem.de/Smileys/default/smiley.gif)
@Loredo: gerne, aber diese Aussage (https://forum.fhem.de/index.php/topic,39983.msg458699.html#msg458699) inzwischen 11 Monate alt: kannst du bitte diesen Punkt hoeher priorisieren?
Hi,
ich versuche gerade mein Pushover auf meine Frau auszudehnen um es dann mittels msg zu verwenden. Dabei bin ich auf ein Problem gestoßen:
In Pushover habe ich für mich zwei Geräte definiert (iPhone + iPad) und für meine Frau eines (iPhone). Jetzt möchte ich in meinem RESIDENT (rr_Christian) gerne den msgContactPush für meine beiden Geräte setzen
attr rr_Christian msgContactPush Pushover:iPhone_c,Pushover:iPad_c
(Das Format habe ich mir so durch testen zusammengesucht, ob es richtig ist, weiss ich leider nicht genau.)
Das Problem ist jetzt, dass folgendes passiert:
msg push @rr_Christian Test
ergibt folgendes im Log:
...
2017.05.27 10:07:05 5: msg rr_Christian: Trying to send message via gateway Pushover to recipient iPhone_c
...
2017.05.27 10:09:53 5: msg rr_Christian: Trying to send message via gateway Pushover to recipient iPhone_c
...
Das bedeutet, er sendet zwei mal an das selbe Gerät. Hintergrund ist vermutlich folgender Code aus 75_MSG.pm (ca. Zeile 1272ff)
$gatewayDev = $1;
$subRecipient = $2 if ( $subRecipient eq "" );
$termRecipient = $3 if ( $termRecipient eq "" );
Mir ist nicht klar, warum der Code ist, wie er ist, allerdings sieht es für mich so aus, als würde er das $gatewayDev in jeder Schleife korrekt verwenden, aber $subRecipient (und auch $termRecipient) wird im zweiten Durchlauf der Schleife nicht mehr überschrieben.
Ist das Absicht? Oder ein Bug? Oder mache ich es ganz falsch? ;)
Über Feedback freue ich mich :)
LG
Christian
Zitat von: choenig am 27 Mai 2017, 11:47:41
Ist das Absicht? Oder ein Bug? Oder mache ich es ganz falsch? ;)
Das klingt eher nach einem Bug, muss ich mir bei Gelegenheit genauer ansehen. Die Details des msg-Befehls sind ja nach wie vor "Work in progress". Ich bin froh, wenn ich einmal Feedback zu Funktionen bekomme, die ich hier auch bekannt gemacht habe, um eben genau von dir dann aus der Praxis heraus das ganze rundzuschleifen :-)
Ich weiß allerdings nicht, wann ich dazu komme, mir das anzusehen.
Hallo zusammen,
mit
msg push @[rgr_Residents:residentsHomeDevs] ...ist es ja möglich an alle ROOMMATES, die zu Hause sind, eine Meldung zu senden.
Bräuchte aber auch einen einfache Möglichkeit an alle ROOMMATES, unabhängig von der Anwesenheit zu senden.
Im Internal "ROOMMATES" vom Residents Device sind alle Roommates hinterlegt, gibt es eine Möglichkeit auf dieses zuzugreifen?
So wie bei DOIF z.B.
Aus Commandref DOIF:
Zitatstatus is specified with [<devicename>], readings with [<devicename>:<readingname>] or internals with [<devicename>:&<internal>]
Habe
msg push @[rgr_Residents:&ROOMMATES] ... probiert, das funktionierte aber nicht.
Zitat von: Schlimbo am 03 Juni 2017, 09:28:17
Hallo zusammen,
mit
msg push @[rgr_Residents:residentsHomeDevs] ...
ist es ja möglich an alle ROOMMATES, die zu Hause sind, eine Meldung zu senden.
Bräuchte aber auch einen einfache Möglichkeit an alle ROOMMATES, unabhängig von der Anwesenheit zu senden.
Im Internal "ROOMMATES" vom Residents Device sind alle Roommates hinterlegt, gibt es eine Möglichkeit auf dieses zuzugreifen?
So wie bei DOIF z.B.
Aus Commandref DOIF:Habe
msg push @[rgr_Residents:&ROOMMATES] ...
probiert, das funktionierte aber nicht.
Alle Roommates kommasepariert:
my $roommates = InternalVal("rgr_Residents","ROOMMATES","");Alle Roommates im Array:
my @roommates = split ",",InternalVal("rgr_Residents","ROOMMATES","");Gruß
Dan
Hallo Dan,
danke für deine Antwort, ja über eine Variable funktioniert das natürlich, fände es aber etwas eleganter wenn das auch, wie mit den Readings, direkt im msg Aufruf funktionieren würde (ohne Perl Umweg).
Moin,
ich hab' da mal ein Verständnisproblem hinsichtlich push mit Jabber, vielleicht kann mir jemand auf die Sprünge helfen?
Leider war/bin ich wohl zu doof für den ersten Beitrag - ich musste mich trotzdem durch die 23 Seiten wühlen und 2 Tage experimentieren, bevor ich endlich die erste Message bekam. :(
In meiner bisherigen Installation habe ich das Jabber-Device "IM" (heißt hier auch so), nur dass ich dort direkt mit "set IM msg..." arbeite; nun wollte ich das mit dem MSG-Modul lösen.
Für meine An- und Abwesenheits-Meldung gibt es je ein Notify.
Notify-DEF:
rgr_wir:abwesend {
fhem('msg push @rgr_wir Bis bald!')
}in rgr_wir habe ich nur msgContactMail als Attribut (denn das ist eine vom globalen Wert abweichende Mail-Adresse). Aber es gibt nur den einen Jabber-Account.
In globalMSG sind die allgemeine msgContactMail sowie der Messenger definiert (msgContactPush IM:meinacc@meinjabber.de).
Wenn obiger Notify nun ausgelöst wird, würde ich erwarten, dass eine Jabber-Message an den Standardaccount rausgeht, und NUR wenn das fehlschlägt (da Prio 0), eine Mail an die Kontaktadresse.
Tatsächlich kriege ich zwar keine Mail (=ok), aber Messages in diesem Format:
ZitatForwarded Message: Bis bald! ### (Catched from device rgr_wir)
Warum dieses? Wo liegt mein Fehler?
hallo Loredo,
möchtest du den DeviceTyp AMADDevice auch noch in das msgSchema aufnehmen? Ist analog zu AMAD. Oder willst du damit warten, bis AMADDevice offiziell eingecheckt ist?
Gruß Michael
Hallo!
Ich verwende den nachfolgenden Befehl, um eine Nachricht per Pushover an alle Zuhause anwesenden Personen zu senden:
msg push @[Anwesenheit:residentsHomeDevs] NACHRICHT!
Insgesamt sind es aktuell zwei Empfänger. Leider erhalten beide Empfänger jede Nachricht doppelt. Kann sich jemand das Verhalten erklären?
Muss man irgendwo die unterschiedlichen Empfänger angeben?
Außerdem werden alle Nachrichten immer auf beiden Geräten zugestellt und zwar auch dann, wenn eines der Geräte unterwegs ist.
welche msg-Attribute hast du bei den Residents gesetzt?
Gruß Michael
Lediglich den nachfolgenden:
msgContactPush Pushover
Jeweils bei beiden Residents.
da liegt dann wahrscheinlich der Hund begraben.
Pushover ist dein Pushoverdevice. Wenn du das gleiche bei beiden Residents eingetragen hast, dann schickt der pro Resident eine Nachricht an das Device Pushover.
ich hab bei mir pro Resident ein Pusoverdevice angelegt, mit einem API-Key usw... also zb. PushoverMichael
Gruß Michael
Zitat von: l2r am 19 Juni 2017, 16:17:56
Pushover ist dein Pushoverdevice. Wenn du das gleiche bei beiden Residents eingetragen hast, dann schickt der pro Resident eine Nachricht an das Device Pushover.
Das klingt logisch und nachvollziehbar. Aber es muss doch irgendwie möglich sein, die einzelnen Empfängergeräte, die ja in Pushover angelegt werden, anzusprechen, ohne für jedes Geräte eine neue Pushover Instanz anzulegen. ???
schau dir mal den Pushover-Commandref-Beitrag an. Das geht glaub ich mit nem :
und im msg-Schema von globalMsg ist steht auch was zu device.
Müsste man dann ggf für die Residents überschreiben.
Gruß Michael
Beim Resident
attr Resident msgContactPush <Pushoverdevice>:PushoverGerät
Also zb
attr rr_max msgContactPush Pushover1:HandyMax
Beim globalmsg
attr globalMsg msgContactPush <Pushoverdevice>
Zitat von: Amenophis86 am 19 Juni 2017, 18:01:41
Beim Resident
attr Resident msgContactPush <Pushoverdevice>:PushoverGerät
Also zb
attr rr_max msgContactPush Pushover1:HandyMax
Beim globalmsg
attr globalMsg msgContactPush <Pushoverdevice>
Vielen Dank so funktioniert es perfekt! :)
Zitat von: Amenophis86 am 19 Juni 2017, 18:01:41
Beim Resident
attr Resident msgContactPush <Pushoverdevice>:PushoverGerät
Also zb
attr rr_max msgContactPush Pushover1:HandyMax
Beim globalmsg
attr globalMsg msgContactPush <Pushoverdevice>
Hallo!
Wie würde das oben zitierte für Telegram funktionieren? Also eine Nachricht über ein definiertes Telegram-Device an einen bestimmten Kontakt senden?
Vielen Dank im Voraus!
Gruß
Andreas
gleiches Prinzip nur, dass du halt die Telegramdaten einsetzen muss. Wie heißt den Telegram Nutzer und wie dein Device? Einfach bisschen try and error begehen ;)
Hab ich schon probiert.
Device heißt telegramBot, Nutzer heißt Andreas. Hab es aber auch mit der telegram-Id versucht, also nicht über den Nutzer-Namen, sondern über die 7? stellige Nummer:
msg @telegramBot:1234567 test
msg @telegramBot:Andreas test
msg @telegramBot:@Andreas test
msg @telegramBot:@1234567 test
hat jeweils nicht funktioniert bzw. wird jeweils einfach an den telegram defaultPeer gesendet anstatt an den im Message Befehl ausgewählten.
msgContactPush ist telegramBot im globalMsg
Als ich msgContactPush im roommate rr_Andreas als telegramBot:1234567 bzw. telegramBot:Andreas angelegt hab, ging es auch nicht. msgRecipientPush Andreas bzw. 1234567 im roommate hat auch nicht geholfen.
Landet alles immer beim defaultPeer.
Hab mal im Thread hier gesucht. Versuch mal beim rr_xx das attr so zu setzen telegramBot:@@Andreas und dann eine Nachricht mittels msg rr_xx test zu verschicken.
Zitat von: Amenophis86 am 22 Juni 2017, 06:20:42
Hab mal im Thread hier gesucht. Versuch mal beim rr_xx das attr so zu setzen telegramBot:@@Andreas und dann eine Nachricht mittels msg rr_xx test zu verschicken.
Vielen Dank für den Hinweis!
Mit msgContactPush -> telegramBot:@Andreas im Roomate-device rr_Andreas hat es dann geklappt.
Wenn es über das Attribut des Roommates funktioniert, wieso funktioniert dann "msg @telegramBot:@Andreas test" nicht über die Kommandozeile?
Offtopic: Wie hast du denn konkret diesen Thread durchsucht, ich habe nämlich fieberhaft nach der Funktion gesucht, bevor ich hier meine Frage gepostet habe.
Die Suche oben rechts, also das Input Fenster, sucht nur deine aktuelle Ebene im Forum und unterhalb dieser.
Die Suche über den Link Suche durchsucht das komplette Forum.
Warum der Befehl nicht geht kann ich auswendig nicht sagen, müsste ich jetzt auch nachlesen und die Frage ist, wie deine Einstellungen zum Zeitpunkt des Befehls waren.
Zitat von: duke am 22 Juni 2017, 23:24:26
Vielen Dank für den Hinweis!
Mit msgContactPush -> telegramBot:@Andreas im Roomate-device rr_Andreas hat es dann geklappt.
Wenn es über das Attribut des Roommates funktioniert, wieso funktioniert dann "msg @telegramBot:@Andreas test" nicht über die Kommandozeile?
Offtopic: Wie hast du denn konkret diesen Thread durchsucht, ich habe nämlich fieberhaft nach der Funktion gesucht, bevor ich hier meine Frage gepostet habe.
Wenn bei rr_Andreas das Attribut msgContactPush gesetzt ist, schickst Du ihm Nachrichten mit "msg @rr_Andreas Das ist ein Test".
Gruß
Dan
Moin
auch ich probiere mich in das msg. Habe allerdings Probleme mit Mail. Konfiguriert ist DebianMail wie Inder WiKi.
Zusätzlich habe ich:
attr globalMsg msgCmdMail {DebianMail('%DEVICE%','%TITLE%','%MSG%')}
Grundsätzlich funktioniert das auch, doch es gibt eine Fehlermeldung im Log.
Beim Aufruf mit:
msg mail @rr_Tom |test Titel| Nachricht
2017.07.10 12:35:25 1: sendEmail RCP: mail@empfänger.domain
2017.07.10 12:35:25 1: sendEmail Subject: test Titel
2017.07.10 12:35:25 1: sendEmail Text: Nachricht
2017.07.10 12:35:25 1: PERL WARNING: Use of uninitialized value $attach in concatenation (.) or string at ./FHEM/99_myUtils.pm line 101.
2017.07.10 12:35:25 1: stacktrace:
2017.07.10 12:35:25 1: main::__ANON__ called by ./FHEM/99_myUtils.pm (101)
2017.07.10 12:35:25 1: main::DebianMail called by (eval 787325) (1)
2017.07.10 12:35:25 1: (eval) called by ./FHEM/75_MSG.pm (1979)
2017.07.10 12:35:25 1: main::CommandMsg called by fhem.pl (1157)
2017.07.10 12:35:25 1: main::AnalyzeCommand called by fhem.pl (1021)
2017.07.10 12:35:25 1: main::AnalyzeCommandChain called by ./FHEM/01_FHEMWEB.pm (2468)
2017.07.10 12:35:25 1: main::FW_fC called by ./FHEM/01_FHEMWEB.pm (904)
2017.07.10 12:35:25 1: main::FW_answerCall called by ./FHEM/01_FHEMWEB.pm (547)
2017.07.10 12:35:25 1: main::FW_Read called by fhem.pl (3412)
2017.07.10 12:35:25 1: main::CallFn called by fhem.pl (686)
2017.07.10 12:35:25 1: sendEmail Anhang:
2017.07.10 12:35:25 1: PERL WARNING: Use of uninitialized value $attach in concatenation (.) or string at ./FHEM/99_myUtils.pm line 103.
2017.07.10 12:35:25 1: stacktrace:
2017.07.10 12:35:25 1: main::__ANON__ called by ./FHEM/99_myUtils.pm (103)
2017.07.10 12:35:25 1: main::DebianMail called by (eval 787325) (1)
2017.07.10 12:35:25 1: (eval) called by ./FHEM/75_MSG.pm (1979)
2017.07.10 12:35:25 1: main::CommandMsg called by fhem.pl (1157)
2017.07.10 12:35:25 1: main::AnalyzeCommand called by fhem.pl (1021)
2017.07.10 12:35:25 1: main::AnalyzeCommandChain called by ./FHEM/01_FHEMWEB.pm (2468)
2017.07.10 12:35:25 1: main::FW_fC called by ./FHEM/01_FHEMWEB.pm (904)
2017.07.10 12:35:25 1: main::FW_answerCall called by ./FHEM/01_FHEMWEB.pm (547)
2017.07.10 12:35:25 1: main::FW_Read called by fhem.pl (3412)
2017.07.10 12:35:25 1: main::CallFn called by fhem.pl (686)
2017.07.10 12:35:26 1: sendEmail returned: Jul 10 12:35:26 spooky-srv02 sendEmail[20869]: Email was sent successfully!
Ich verstehe das es an dem NICHT vorhandenen Anhang liegt, denn wenn ich es so aufrufe:
{ DebianMail('mail@empfänger.domain,'Test','Test-Text','');; }
Gibt es die Fehlermeldung nicht.
Kann mir da jemand auf die Sprünge helfen.
LG
Tom
In dem ersten Fall ist der Parameter undef und im zweiten setzt du den zu '', was nicht undef ist, sondern ein leerer String. Das könntest du vielleicht in deiner DebianMail Funktion einfach abfangen und dann aus undef ein '' machen?!?
Steinigt mich nicht aber:
ZitatStandardmäßig wird für Push das Pushover Modul sowie für E-Mail system() per /usr/bin/mail verwendet.
Bedeutet das "mein" DebianMail gar nicht dafür gedacht ist?
Habe soeben noch probiert aber das will leider auch nicht:
attr globalMsg msgCmdMail { my $dev='%DEVICE%';; system("echo '%MSG%' | /usr/bin/sendEmail -s '%TITLE%' -a 'MIME-Version: 1.0' -a 'Content-Type: text/html;; charset=UTF-8' '$dev'");; }LG
Tom
Ich hatte jetzt eher die Vermutung, dass die Funktion DebianMail in deiner 99_myUtils.pm definiert ist. Und dort solltest du einfach abfangen wenn der Parameter 4 undef ist und dann parameter 4 zu einem '' machen. Aber das ist nur eine Vermutung, keine Ahnung ob ich da richtig liege.
Ich hätte einen Verbesserungsvorschlag zur Benachrichtigung mehrerer anwesender Bewohner (via RESIDENTS "residentsHomeDevs") über Audio.
An einigen Stellen verwende ich aktuell Konstrukte wie
msg audio @[rgr_Bewohner:residentsHomeDevs] ....
um alle anwesenden Bewohner per Audio (via SONOS) über Dinge zu benachrichtigen.
Halten sich nun zufällig 2 Bewohner im gleichen Raum auf (location Reading identisch), wird auf dem dazugehörigen SONOS Device die Meldung immer doppelt abgespielt - halt für jeden Bewohner im Raum 1 mal.
Könnte man hier eine Prüfung einbauen, um bei mehreren Bewohnern an der gleichen location (Raum) die Ausgabe dann nur einmalig an das Wiedergabegerät zu schicken? Könnte ja per Attribut an/abschaltbar sein, für Fälle wo das vielleicht doch in dieser Form gewünscht ist.
hi Julian,
falls du das einbauen solltest, dann wäre es super wenn du auch eben die msgSchema anpassen würdest:
Zitat von: l2r am 13 Juni 2017, 08:33:23
möchtest du den DeviceTyp AMADDevice auch noch in das msgSchema aufnehmen? Ist analog zu AMAD. Oder willst du damit warten, bis AMADDevice offiziell eingecheckt ist?
Gruß Michael
@Phiolin:
Ich weiß ja nicht, wie du den Befehl aufrufst, aber bau doch einfach selbst vorher ein IF Prüfung ein, dass es nur einmal gesendet wird, wenn die Räume gleich sind.
Wo muss ich denn verbose auf 2 stellen, dass ich im Log nicht immer die Meldung über eine gesendet Nachricht erhalte? Gerade bei UWZ Meldungen mit langem Text ist das Log soweit nach rechts ausgedehnt, dass es mich total nervt. Beim Device "global msg" habe ich das schon gemacht, aber das scheint nicht zu klappen.
Übrigens gibt es immer noch keinen Eintrag in der CommandRef ;)
also bei mir funktioniert
attr globalMsg verbose 2
Gruß Michael
bei mir steht globalmsg auch auf verbose 2, aber im Log kommen trotzdem die Meldungen:
017.08.25 09:59:46 3: msg rr_Etienne: ID=xxx TYPE=push ROUTE=Pushover RECIPIENT=HA_Etienne STATUS=OK PRIORITY=0 TITLE='' MSG='Die Waschmaschine ist fertig.'
verstanden,
dann musst du das Device an das gesendet wird auf Verbose 2 stellen, in deinem Fall rr_Etienne
Gruß Michael
P.S.: ich hatte es nur mit msg test also ohne angegebenen Empfänger probiert und dann wird globasMsg adressiert.
Gruß Michael
Der Roomemate soll dafür verantwortlich sein? Auf die Idee bin ich noch gar nicht gekommen dann muss ich das mal versuchen. Danke
das log ist ja in der Regel so aufgebaut, dass erst DatumZeit kommt, dann loglevel , dann das Modul, dann das Deivice und dann der Logeintrag
Gruß Michael
Das ist korrekt, mich hat nur das msg vor rr_Etienne abgelenkt, dass ich quasi nach diesem "Device" gesucht habe wohl wissend, dass es sich dabei um einen Befehl handelt.
Hallo,
ich versuche gerade per MSG eine Nachricht über AMAD2 zu senden.
Befehl:
msg audio @rr_ICH Test
Beim Absenden erhalte ich folgenden Fehler:
MeinHandy: Unknown command schema for gateway device type AMADDevice. Use manual definition by userattr msgCmd*
Wenn ich mir die Routen im msgConfig anschaue, steht dort folgendes:
AMAD
Priority Normal:
set %DEVICE% ttsMsg %MSG%
Priority ShortPrio:
set %DEVICE% ttsMsg %MSGSHRT%
Default Values:
MSGSH = Achtung!
Priority Short:
set %DEVICE% ttsMsg %MSGSHRT%
Default Values:
MSGSH = Hinweis!
AMADDevice
Priority Normal:
Default Values:
Priority ShortPrio:
Priority Short:
Beim Resident rr_ICH habe ich folgendes Attribut
msgContactAudio MeinHandy
Müssten die Einträge vom AMAD nicht beim AMADDevice stehen? Natürlich kann ich userattr msgCmd* noch setzten. Aber ich dachte die FHEM-Module sollte "Out of the Box" unterstützt werden?
Oder liegt der Fehler bei mir?
du hast Recht.
Die msgSchema ist noch auf das alte AMAD-Modul gemappt. Entweder du passt die msgSchema an und schließt die dann vom Update aus (So mache ich das) oder Loredo müsste diese aktualisieren. Da Loredo im Moment aber nicht aktiv ist, würde ich dir zu ersterem Raten.
Eine Beispielconfig hab ich weiter oben mal gepostet.
Gruß Michael
Hallo,
danke für die Antwort.
Die entsprechenden Teile über AMAD hatte ich übersehen ???
Ich habe noch ein kleines Problem damit, wie der Titel von einer Nachricht gefunden wird.
Bei Telegram würde ich mir gerne ein mehrspaltigey Keyboard senden. Der Aufruf dafür lautet:
msg push @MichaelP (5|10|15|20|25) Welche Wert soll ich einstellen?
Empfangen tue ich aber
5\n\n15\n\n25
Ich vermute, dass es was damit zu tun hat, dass der Titel normalerweise zwischen zwei pipe Zeichen angegeben wird.
Mein Vorschlag: Den Titel nur suchen, wenn sich vor, bzw. hinter, dem pipe Zeichen ein Leerzeichen befindet.
Zitat von: l2r am 25 September 2017, 10:20:53
Eine Beispielconfig hab ich weiter oben mal gepostet.
Habe gerade ein Update des Schemas eingecheckt. Allerdings habe ich kein Beispiel von dir dafür gefunden und habe es daher so eingecheckt, wie es sich für mich aus der CommandRef ergab :-)
Zitat von: igami am 28 September 2017, 19:36:05
Ich habe noch ein kleines Problem damit, wie der Titel von einer Nachricht gefunden wird.
Bei Telegram würde ich mir gerne ein mehrspaltigey Keyboard senden. Der Aufruf dafür lautet:
msg push @MichaelP (5|10|15|20|25) Welche Wert soll ich einstellen?
Empfangen tue ich aber
5\n\n15\n\n25
Ich vermute, dass es was damit zu tun hat, dass der Titel normalerweise zwischen zwei pipe Zeichen angegeben wird.
Mein Vorschlag: Den Titel nur suchen, wenn sich vor, bzw. hinter, dem pipe Zeichen ein Leerzeichen befindet.
Daran liegt es nicht, denn das ist schon der Fall. Es wird dieser Regex verwendet:
elsif ( $msg =~ s/^[\s\t ]*\|(.*?)\|[\s\t ]*// ) {
Log3 $globalDevName, 5, "msg: found title=$1"
unless ( defined($testMode) && $testMode eq "1" );
$title = $1;
}
Es liegt vielmehr an der speziellen Unterstützung für das SONOSPLAYER Modul aus dem Text alle Sound Files ( |filename| ) herauszufiltern in der Annahme, dass andere Module damit nichts anfangen können und es z.B. bei Sprachausgaben dann zu unerwünschten Texten kommt. Dies dient dazu, dass man SONOS und Nicht-SONOS Geräte bei der Sprachausgabe theoretisch mischen kann. Wenn die anderen Module diesen Filter direkt selbst hätten, bräuchte es den Hack hier nicht dafür. Um das zu lösen bedarf es also einer Vereinheitlichung in der Syntax der Module, die mit Sprachausgabe umgehen.
Zitat von: Loredo am 01 Oktober 2017, 13:49:24
Habe gerade ein Update des Schemas eingecheckt. Allerdings habe ich kein Beispiel von dir dafür gefunden und habe es daher so eingecheckt, wie es sich für mich aus der CommandRef ergab :-)
Besten Dank!! ja das mit dem Beispiel war vllt. ein bisschen weit ausgelegt;-)
Aber so wie du es umgesetzt hattest, hatte ich das bei mir auch editiert;-)
Gruß Michael
Zitat von: Loredo am 01 Oktober 2017, 13:49:24
Habe gerade ein Update des Schemas eingecheckt.
Danke
Ich habe noch eine kleine Frage zum Verständnis.
Du hast für AMAD jetzt folgenden Befehl
set %DEVICE% ttsMsg &%LANG%; %MSGSHRT%
Woher kommt denn das &%LANG%?
Der eigentliche Befehl ist doch: set %DEVICE% ttsMsg %MSGSHRT%
Bin etwas verwirrt...
Auszug aus der Commandref für AmadDevice:
ttsMsg - versendet eine Nachricht welche als Sprachnachricht ausgegeben wird (um die Sprache für diese eine Durchsage zu ändern setze vor Deinem eigentlichen Text &en; oder &de;)
Gruß Michael
Kann ich mittels msg auch MUC-Nachrichten an Jabber versenden (set msgmuc)? Also Nachrichten an einen Raum?
Danke!
Stefan
Zitat von: darkness am 02 Oktober 2017, 09:57:04
Ich habe noch eine kleine Frage zum Verständnis.
Du hast für AMAD jetzt folgenden Befehl
set %DEVICE% ttsMsg &%LANG%; %MSGSHRT%
Woher kommt denn das &%LANG%?
Der eigentliche Befehl ist doch: set %DEVICE% ttsMsg %MSGSHRT%
Da hast du dir deine Frage eigentlich schon selbst beantwortet :-)
Da hat l2r deine Frage eigentlich schon beantwortet :-)Über den msg-Befehl wird die Sprache ja außerhalb des Nutztextes angegeben und muss dann bei der Übersetzung in die jeweilige Notation eines jeden Moduls entsprechend umgesetzt werden, sofern das Modul dies beherrscht. In der CommandRef steht, dass AMAD das über &en; bzw. &de; macht. Nachdem man in &%LANG%; also das %LANG% ausgetauscht hat, steht genau das dann auch dort im Set Befehl.
Zitat von: drhirn am 02 Oktober 2017, 11:53:32
Kann ich mittels msg auch MUC-Nachrichten an Jabber versenden (set msgmuc)? Also Nachrichten an einen Raum?
Ja, indem du als Parameter Jabber_MTYPE=muc mit angibst.
Ja, danke. Habe ich bisher nicht gesehen :o
Bekomme bei der Spracheausgabe nur immer "und de" angesagt. Muss nachher noch mal gucken.
Zitat von: darkness am 02 Oktober 2017, 12:31:15
Ja, danke. Habe ich bisher nicht gesehen :o
Bekomme bei der Spracheausgabe nur immer "und de" angesagt. Muss nachher noch mal gucken.
Hm, möglicherweise muss das Semikolon maskiert werden, probier mal das Attribut msgCmdAudio beim AMADDevice so zu setzen (muss man als userattr hinzufügen bzw. "einblenden", ansonsten kann man es auch global beim Device globalMsg ändern, dann ist das aber das Kommando für alle Audio Devices, nicht nur für AMADDevice) und schau, ob es dann geht:
set %DEVICE% ttsMsg &%LANG%;; %MSGSHRT%
@l2r: Ggf. war es auch keine gute Idee die Notation so zu wählen, weil ein ; beim Set Kommando evtl als neues Set Kommando interpretiert wird. Somit wäre auch klar, weshalb darkness nur diesen Textteil angesagt bekommt. Bestimmt gibt es im Log da dann eine Fehlermeldung wie "unknown command <der eigentliche text>". Am flexibelsten wärst auch du, wenn du parseParams nach dem Beispiel wie beim msg-Befehl implementiertest.
Zitat von: Loredo am 02 Oktober 2017, 12:23:33
Ja, indem du als Parameter Jabber_MTYPE=muc mit angibst.[/font]
Könntest du das auch noch für TelegramBot einbauen, dass man dann queryInline Nachrichten senden kann.
Müsste dann, wenn ich das richtig verstanden haben, so aussehen:
'TelegramBot' => {
'Normal' => 'set %DEVICE% %TelegramBot_MTYPE% %RECIPIENT% %MSG%',
'High' => 'set %DEVICE% %TelegramBot_MTYPE% %RECIPIENT% %MSG%',
'Low' => 'set %DEVICE% %TelegramBot_MTYPE% %RECIPIENT% %MSG%',
'defaultValues' => {
'Normal' => {
'RECIPIENT' => '',
'TelegramBot_MTYPE' => 'message',
},
'High' => {
'RECIPIENT' => '',
'TelegramBot_MTYPE' => 'message',
},
'Low' => {
'RECIPIENT' => '',
'TelegramBot_MTYPE' => 'message',
},
},
},
Dann könnte man sich auch noch einen cmdalias sparen :)
Zitat von: Loredo am 02 Oktober 2017, 12:41:42
set %DEVICE% ttsMsg &%LANG%;; %MSGSHRT%
Mit den doppelten Semikolon funktioniert es.
Und so ein Eintrag in der CommandRef mit den ganzen Sachen wäre echt schön :)
Zitat von: Loredo am 02 Oktober 2017, 12:23:33Ja, indem du als Parameter Jabber_MTYPE=muc mit angibst.
Ich danke!
msg push Jabber_MTYPE=muc @JabberClient:raum@conference.jabber.xy Hier die Nachricht
Hier noch ein kleiner Patch, damit auch Zeilenumbrüche funktionieren, wenn man einen MTYPE angibt :)
Index: FHEM/75_MSG.pm
===================================================================
--- FHEM/75_MSG.pm (Revision 15200)
+++ FHEM/75_MSG.pm (Arbeitskopie)
@@ -133,7 +133,7 @@
### extract message details
###
- my ( $msgA, $params ) = parseParams($msg);
+ my ( $msgA, $params ) = parseParams($msg, "[^\\S\\n]", " ");
# only use output from parseParams when
# parameters where found
Ansonsten funktioniert das mit dem TelegramBot nun auch wunderbar.
Ich habe seit kurzem das Problem dass bei "msg audio/screen" offenbar kein UTF8 mehr verwendet wird.
"msg audio" sind bei mir Sonos Devices und "msg screen" ein LG-WebOS-TV.
Benutze ich die nativen Setter der Devices funktioniert es wie gewünscht.
Sobald ich msg verwende wird teilweise Kauderwelsch angesagt/-gezeigt.
Meine Attribute für globalMsg sehen so aus:
msgCmdAudio {my $vol=%PRIORITY%>2?90:%PRIORITY%>0?80:SpeakVolume("%DEVICE%");fhem "set %DEVICE% Speak $vol de |%TITLE%| %MSG%"}
msgCmdScreen {fhem "set %DEVICE% screenMsg %MSG%"}
msgContactAudio wz_Sonos
msgContactScreen wz_LGTV
was steht denn im Log?
Ich habe derzeit Postfix auf dem RasPi installiert, auf dem auf FHEM läuft.
Nun will ich aber auf Docker wechseln und würde einen eigenen MailRelay-Container bevorzugen.
Hat jemand eine Idee, wie bzw. wo ich das umkonfigurieren muss.
Aktuelle routeCmd:
attr globalMsg msgCmdMail { my $dev='%DEVICE%';; system("echo '%MSG%' | /usr/bin/mail -s '%TITLE%' -a 'MIME-Version: 1.0' -a 'Content-Type: text/html;; charset=UTF-8' '$dev'");; }
attr globalMsg msgCmdMailHigh { my $dev='%DEVICE%';; system("echo '%MSG%' | /usr/bin/mail -s '%TITLE%' -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' '$dev'");; }
attr globalMsg msgCmdMailLow { my $dev='%DEVICE%';; system("echo '%MSG%' | /usr/bin/mail -s '%TITLE%' -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' '$dev'");; }
Wie weise ich dem Modul an, einen anderen Server zu nutzen?
Danke
alles was du in der Klammer nach system( hast ist ja die Syntax von Postfix.
Sprich wenn du das auf der Linuzx-Konsole so eingibst, dann schickst du auch eine Mail weg. Musst natürlich die Platzhalter ersetzen.
Das ganze würde ich jetzt auf der Linux-Konsole so anpassen, bis das der Syntax von Docker(kenne ich persönlich nicht) entspricht und die Mail rausgeht. Anschließend die neue Syntax in den Attributen einfügen und mit den Platzhaltern von msg versehen.
Gruß Michael
Wenn ich bei manchen Nachrichten Pushover und bei anderen Telegram nutzen möchte für den msg Befehl für den gleichen Roommate, wie kann ich dann unterscheiden mit was die Nachricht gesendet werden soll. Type kann ja nur Push und da kommt es darauf an, was beim Roommate hinterlegt wurde als Standard. Also gibt es etwas in Form von xy=Pushover xy=TelegramBot was ich der Nachricht mitgebe?
Hat mal jemand ein Beispiel durch das sich msgCmdAudioShort und msgCmdAudioShortPrio besser verstehen lässt?
Irgendwie werde ich da weder aus commandref noch Wiki schlau zu.
Was wird da unterschiedlich ausgeführt?
Und, zusätzliche Frage, wenn ich auf Audio (in dem Fall Sonos) etwas mit Emergency-Prio (also Prio > 1) ausgeben lasse, dann werden die Einstellungen von "normal" genutzt (also u.a. 'VOLUME' => 38), oder? Wenn ich aber Emergency-Audiomeldungen gerne sehr laut haben möchte, dann müsste ich was tun?
Danke schon mal :-)
hi,
die Lautstärke kannst du als Option mitgeben:
msg audio @Sonos_Bedroom |Hint| Gute Nacht! O[{"VOLUME":"8"}]
Gruß Michael
Zitat von: l2r am 15 Januar 2018, 15:17:07
die Lautstärke kannst du als Option mitgeben:
msg audio @Sonos_Bedroom |Hint| Gute Nacht! O[{"VOLUME":"8"}]
ja, die Option kenne ich.
Praktischer fände ich es aber trotzdem, wenn die sich automatisch aus der Prio ergibt. Ist ja bei den Push-Nachrichten i.d.R. auch hinterlegt, dass die automatisch "nerviger" auf dem Device ankommen. Würde dann einfach nur helfen eine mögliche Fehlerquelle zu eliminieren.
Hallo,
ich versuche gerade folgendes zu realisieren:
Alle messages in meiner config sollen normalerweise an einen Empfänger gesendet werden.
So wie ich es verstanden habe, ist dann das Attribut mit dem entsprechenden Empfänger zu setzen.
attr globalMsg msgContactPush TelegramBot@@DefaultTelegramName
Ohne die Angabe eines Empfängers (attr globalMsg msgContactPush TelegramBot) wird der am TelegramBot-Device angegebene defaultPeer angesprochen.
attr TelegramBot defaultPeer DefaultTelegramName
Es wäre anstatt des DefaultTelegramName auch möglich hier die MsgPeerId zu setzen.
Das klappt soweit auch alles. Jetzt zu meinem Ziel:
An einem anderen device (zweitesdevice) möchte ich diesen Empfänger durch einen anderen Wert überschreiben.
Dazu habe dann folgendes Attribut gesetzt:
attr zweitesdevice msgContactPush TelegramBot@@ZweiterTelegramName
Im zweiten Schritt soll sogar eine Telegramm-Gruppe angesprochen werden. Dazu habe ich das Attribut wie folgt gesetzt:
attr zweitesdevice msgContactPush TelegramBot@@#TelegramGruppe
Beides habe ich ausprobiert und musste leider feststellen, dass weiterhin an den global gesetzten Empfänger gesendet wird.
Was mache ich falsch? Ist das anders gedacht?
Würde mich über eine genauere Beschreibung von Redefinitionen des Empfängers an bestimmten devices sehr freuen.
Danke
msg <zweitdevice> push <nachricht>
sollte funktionieren. Du schickst quasi eine Nachricht an ein Device und dann wird geschaut, welcher Empfänger über die Attribute definiert ist.
Gruß Michael
Also wenn dann müsste es glaube ich so heißen:
msg push <zweitdevice> <nachricht>
Aber alle Versuche damit haben nicht funktioniert.
Ich habe wirklich alles mögliche probiert.
@Loredo: Was sagt der Entwickler dazu? :-)
hi,
sry hast recht. Allerdings hast du das @ vergessen:
msg push @<zweitdevice> <nachricht>
gruß Micahel
Hallo,
das ist korrekt und hat mir über eine kleine gedankliche Klippe geholfen.
Jetzt kann ich auch an Empfänger senden, die im Attribut "msgContactPush" definiert sind.
Was allerdings nicht geht, ist das Senden an eine Telegramm-Gruppe, die nicht per ID, sondern per Name angesprochen werden soll.
Also folgendes funktioniert
attr <zweitesdevice> msgContactPush TelegramBot:@@#-123456789
-123456789 = TelegramGruppenID
Folgendes aber leider nicht
attr <zweitesdevice> msgContactPush TelegramBot:@#TelegramGruppenName
attr <zweitesdevice> msgContactPush TelegramBot:@@#TelegramGruppenName
attr <zweitesdevice> msgContactPush TelegramBot:@@@#TelegramGruppenName
attr <zweitesdevice> msgContactPush TelegramBot:@\#TelegramGruppenName
Probiert habe ich alle verschiedenen Werte
Gibt es dazu evtl. noch nicht das richtige schema?
Gruß
THEM
das wird es wohl sein.
Gruß Michael
Hallo,
habe ein seltsames verhalten festgestellt.
Am msgConfig Device ist als msgContactAudio das Device "MyTTS" hinterlegt:
attr globalMsg msgContactAudio MyTTS
An MyTTS ist das msgCmd Attribut gesetzt:
attr MyTTS msgCmdAudio {fhem "set %DEVICE% tts :%TITLE%: %MSG%"}
Verwende ich bei "msgCmdAudio" Perl code werden die Umlaute nicht korrekt ausgesprochen.
ü wird zu �
Befehl:
msg audio tür
Zugehöriger Log:
018.02.11 17:04:46.288 5: msg: found types=audio
2018.02.11 17:04:46.294 5: msg globalMsg: Checking for available routes (triggered by type audio)
2018.02.11 17:04:46.312 5: msg globalMsg: screen route check result: ROUTE_AVAILABLE
2018.02.11 17:04:46.326 5: msg globalMsg: light route check result: ROUTE_AVAILABLE
2018.02.11 17:04:46.338 5: msg globalMsg: audio route check result: ROUTE_AVAILABLE
2018.02.11 17:04:46.351 5: msg globalMsg: push route check result: ROUTE_AVAILABLE
2018.02.11 17:04:46.359 5: msg globalMsg: mail route check result: ROUTE_UNAVAILABLE
2018.02.11 17:04:46.359 4: msg globalMsg: Available routes: screen=1 light=1 audio=1 text=1 push=1 mail=0
2018.02.11 17:04:46.363 5: msg globalMsg: Trying to send message via gateway MyTTS
2018.02.11 17:04:46.364 5: msg globalMsg: Determined default title:
2018.02.11 17:04:46.370 5: msg globalMsg: audio route command (Perl): {fhem "set MyTTS tts :Doorbell: tür"}
2018.02.11 17:04:46.421 4: MyTTS: Auflistung der Textbausteine nach Aufbereitung:
2018.02.11 17:04:46.421 4: MyTTS: 0 => audio/Doorbell.mp3
2018.02.11 17:04:46.422 4: MyTTS: 1 => t�r
Verwende ich keinen perl code werden Umlaute korrekt ausgesprochen:
attr MyTTS msgCmdAudio set %DEVICE% tts :%TITLE%: %MSG%
018.02.11 17:06:40.529 5: msg: found types=audio
2018.02.11 17:06:40.536 5: msg globalMsg: Checking for available routes (triggered by type audio)
2018.02.11 17:06:40.557 5: msg globalMsg: screen route check result: ROUTE_AVAILABLE
2018.02.11 17:06:40.571 5: msg globalMsg: light route check result: ROUTE_AVAILABLE
2018.02.11 17:06:40.583 5: msg globalMsg: audio route check result: ROUTE_AVAILABLE
2018.02.11 17:06:40.596 5: msg globalMsg: push route check result: ROUTE_AVAILABLE
2018.02.11 17:06:40.604 5: msg globalMsg: mail route check result: ROUTE_UNAVAILABLE
2018.02.11 17:06:40.605 4: msg globalMsg: Available routes: screen=1 light=1 audio=1 text=1 push=1 mail=0
2018.02.11 17:06:40.608 5: msg globalMsg: Trying to send message via gateway MyTTS
2018.02.11 17:06:40.609 5: msg globalMsg: Determined default title:
2018.02.11 17:06:40.615 5: msg globalMsg: audio route command (fhem): set MyTTS tts :Doorbell: tür
2018.02.11 17:06:40.924 4: MyTTS: Auflistung der Textbausteine nach Aufbereitung:
2018.02.11 17:06:40.925 4: MyTTS: 0 => audio/Doorbell.mp3
2018.02.11 17:06:40.925 4: MyTTS: 1 => tuer
Mit dem Device "MyTTS" hat das nichts zu tun, denn auch wenn ich nur ins Log schreiben lasse, ist der Fehler zu erkennen:
attr MyTTS msgCmdAudio {Log 3, "set %DEVICE% tts :%TITLE%: %MSG%"}
018.02.11 17:24:46.099 5: msg: found types=audio
2018.02.11 17:24:46.104 5: msg globalMsg: Checking for available routes (triggered by type audio)
2018.02.11 17:24:46.122 5: msg globalMsg: screen route check result: ROUTE_AVAILABLE
2018.02.11 17:24:46.134 5: msg globalMsg: light route check result: ROUTE_AVAILABLE
2018.02.11 17:24:46.146 5: msg globalMsg: audio route check result: ROUTE_AVAILABLE
2018.02.11 17:24:46.158 5: msg globalMsg: push route check result: ROUTE_AVAILABLE
2018.02.11 17:24:46.166 5: msg globalMsg: mail route check result: ROUTE_UNAVAILABLE
2018.02.11 17:24:46.167 4: msg globalMsg: Available routes: screen=1 light=1 audio=1 text=1 push=1 mail=0
2018.02.11 17:24:46.171 5: msg globalMsg: Trying to send message via gateway MyTTS
2018.02.11 17:24:46.172 5: msg globalMsg: Determined default title:
2018.02.11 17:24:46.177 5: msg globalMsg: audio route command (Perl): {Log 3, "set MyTTS tts :Doorbell: tür"}
2018.02.11 17:24:46.179 3: set MyTTS tts :Doorbell: t�r
2018.02.11 17:24:46.179 3: msg globalMsg: ID=1518366286.10046.1 TYPE=audio ROUTE=MyTTS STATUS=OK PRIORITY=0 TITLE='Doorbell' MSG='tür'
2018.02.11 17:24:46.677 5: msgConfig globalMsg: called function msgConfig_Set()
Hat hier jemand eine Idee an was das liegen könnte? Und wie ich das beheben kann?
Habe hier noch mal etwas weiter geforscht.
aus 75_MSG.pm:
elsif ( $cmd =~ /^\s*\{.*\}\s*$/ ) {
Log3 $logDevice, 5,
"msg $device: "
. "$type[$i] route command (Perl): $cmd";
eval $cmd;
unless ( !$@ || $@ =~ m/^[\s\t\n ]*$/ )
{
Bei Zeile 1957 (eval $cmd) geht irgendetwas mit der utf8 Formatierung schief.
Laut Log Einträge passt die Formatierung in der vorherigen Zeile noch
2018.02.11 17:24:46.177 5: msg globalMsg: audio route command (Perl): {Log 3, "set MyTTS tts :Doorbell: tür"}
Bei der Ausführung des Befehls über "eval" wird dann aus ü ein �
2018.02.11 17:24:46.179 3: set MyTTS tts :Doorbell: t�r
Habe testweise die Zeile
eval $cmd;
mal mit
AnalyzeCommand(undef,$cmd);
ersetzt, damit funktioniert es auch mit Umlauten.
Hat das Problem sonst keiner?
@Loredo: könntest du dir das bitte mal ansehen?
Zitat von: Schlimbo am 13 Februar 2018, 21:35:00
Hat das Problem sonst keiner?
Siehe #381 (https://forum.fhem.de/index.php/topic,39983.msg704361.html#msg704361).
Gruß
Dan
Hallo,
ich hatte ein paar Problem mit msg und habe mich durch das Forum gewühlt. Dadurch konnte ich meine Probleme beheben. Ich habe für Pushover und Telegram entsprechende Ergänzungen, die ich hier im Forum gefunden habe, in das Wiki eingetragen, vielleicht sind sie ja hilfreich.
Eine wirklich tolle Arbeit! Großen Dank an Loredo! Und natürlich auch an die anderen Mitglieder in diesem Forum. Das hat mir sehr geholfen...
Gruß
Stephan
Zitat von: tomspatz am 10 Juli 2017, 14:07:36
Moin
auch ich probiere mich in das msg. Habe allerdings Probleme mit Mail. Konfiguriert ist DebianMail wie Inder WiKi.
Zusätzlich habe ich:
attr globalMsg msgCmdMail {DebianMail('%DEVICE%','%TITLE%','%MSG%')}
Grundsätzlich funktioniert das auch, doch es gibt eine Fehlermeldung im Log.
Beim Aufruf mit:
msg mail @rr_Tom |test Titel| Nachricht
Ich verstehe das es an dem NICHT vorhandenen Anhang liegt, denn wenn ich es so aufrufe:
{ DebianMail('mail@empfänger.domain,'Test','Test-Text','');; }
Gibt es die Fehlermeldung nicht.
Kann mir da jemand auf die Sprünge helfen.
LG
Tom
Ich weiß nicht ob es noch aktuell ist und Dir weiterhilft:
Aber weshalb packst Du nicht hier
attr globalMsg msgCmdMail {DebianMail('%DEVICE%','%TITLE%','%MSG%')}ebenfalls die Hochkommata hinter das "%MSG%? also so:
attr globalMsg msgCmdMail {DebianMail('%DEVICE%','%TITLE%','%MSG%','')}Dann hast Du keine Fehlermeldung im Log, weil im der Anhang eben leer ist.
Gruß
Jens
Ich habe nun den ganzen Thread von vorn bis hinten durchgelesen, komme aber nicht zu einer Lösung.
Mit
msg Das ist eine Nachricht
kann ich eine Nachricht per Jabber versenden.
Nun hätte ich gerne Zeilenumbrüche in der Nachricht. Intuitiv habe ich dann schon
msg Das ist die erste Zeile! \nDas ist die zweite Zeile
versucht. Aber es erfolgt kein Zeilenumbruch.
Wie muss ich das anstellen?
Hallo,
ich versuche den msg Befehl mit Pushsafer zu verwenden, stoße dabei aber auf folgende Probleme:
Ich habe ein MyPushsafer Device erstellt und dieses funktioniert auch problemlos, wenn ich die Pushnachricht darüber direkt versende.
Laut Doku rufe ich den msg Befehl folgendermaßen auf: msg push @MyPushsafer |Test| Das ist ein Test
Als direkte Rückmeldung bekomme folgendes angezeigt:
MyPushsafer: wrong syntax for option url:
wrong syntax for option ttl:
wrong syntax for option device:
wrong syntax for option key:
Mein msgConfig Device habe ich mal auf verbose 5 gestellt und den o.g. msg Befehl aufgerufen.
Im Logfile erhalte ich dann folgende Ausgabe:
2018.05.20 11:16:45 5: msg: found types=push
2018.05.20 11:16:45 5: msg: found recipient=@MyPushsafer
2018.05.20 11:16:45 5: msg: found title=Test
2018.05.20 11:16:45 4: msg MyPushsafer: Recipient type Pushsafer is a gateway device itself for message type push. Still checking for any delegates ...
2018.05.20 11:16:45 5: msg MyPushsafer: Checking for available routes (triggered by type push)
2018.05.20 11:16:45 5: msg MyPushsafer: screen route check result: ROUTE_UNAVAILABLE
2018.05.20 11:16:45 5: msg MyPushsafer: light route check result: ROUTE_UNAVAILABLE
2018.05.20 11:16:45 5: msg MyPushsafer: audio route check result: ROUTE_UNAVAILABLE
2018.05.20 11:16:46 5: msg MyPushsafer: push route check result: ROUTE_AVAILABLE
2018.05.20 11:16:46 5: msg MyPushsafer: mail route check result: ROUTE_UNAVAILABLE
2018.05.20 11:16:46 4: msg MyPushsafer: Available routes: screen=0 light=0 audio=0 text=1 push=1 mail=0
2018.05.20 11:16:46 5: msg MyPushsafer: Trying to send message via gateway MyPushsafer
2018.05.20 11:16:46 5: msg MyPushsafer: Determined default title:
2018.05.20 11:16:46 5: msg MyPushsafer: msgSchema: replacing %RECIPIENT% and $RECIPIENT by ''
2018.05.20 11:16:46 5: msg MyPushsafer: msgSchema: replacing %URLTITLE% and $URLTITLE by ''
2018.05.20 11:16:46 5: msg MyPushsafer: msgSchema: replacing %EXPIRE% and $EXPIRE by ''
2018.05.20 11:16:46 5: msg MyPushsafer: msgSchema: replacing %ACTION% and $ACTION by ''
2018.05.20 11:16:46 5: msg MyPushsafer: msgSchema: replacing %TERMINAL% and $TERMINAL by ''
2018.05.20 11:16:46 5: msg MyPushsafer: msgSchema: replacing %Pushsafer_VIBRATION% and $Pushsafer_VIBRATION by '1'
2018.05.20 11:16:46 5: msg MyPushsafer: push route command (fhem): set MyPushsafer message "Das ist ein Test" title="Test" key="" device="" vibration="1" url="" urlText="" ttl=""
2018.05.20 11:16:46 3: msg MyPushsafer: ID=1526807805.97424.1 TYPE=push ROUTE=MyPushsafer STATUS=ERROR PRIORITY=0 TITLE='Test' MSG='Das ist ein Test'
Für mich sieht es irgendwie so aus, als ob mit dem replacing der Variablen bei der Umsetzung des msg-Befehls in den MyPushsafer-Aufruf etwas nicht stimmt. Wenn key, device, url und ttl beim msg Befehl nicht mit angegeben werden und die Variablen demzufolge leer sind, dann dürfen diese bei der Umsetzung des msg-Befehls in den MyPushsafer-Aufruf nicht mit angegeben werden, da ansonsten ein Syntaxfehler angezeigt wird.
Stimmt das oder mache ich schlicht und ergreifend irgendwo einen Fehler?
Gruß
Wolle
Nur eine kleine Frage:
Threadbeginn:
ZitatEine 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.
Ist es richtig, dass
globalMSG (Beitrag #1) von
msgConfig abgelöst wurde?
Gruß Eberhard
ZitatIst es richtig, dass globalMSG (Beitrag #1) von msgConfig abgelöst wurde?
Gruß Eberhard
Hallo Eberhard,
nein, denn laut Commandref:
ZitatMSGCONFIG
Stellt globale Einstellungen und Tools für das FHEM Kommando msg bereit.
Ein Device mit dem Namen globalMsg wird automatisch bei der ersten Benutzung des msg Kommandos angelegt, sofern kein msgConfig Device gefunden wurde.
Der Device Name kann anschließend beliebig umbenannt und umkonfiguriert werden.
VG Sebastian
So, jetzt habe ich 27 Seiten in in zwei langen Tagen "durchgeackert" und hoffe, dass mich niemand ob meiner Fragen erschlägt.
Ich arbeite das Beispiel aus dem Wiki MsgDialog durch und versuche es möglichst nah das Beispiel meta_Dialog nachzuarbeiten. Mein Problem besteht darin, dass das notify auf des Schlüsselwort 'start' nur höchst mangelhaft bis gar nicht anspricht. Ich glaube, dass die Auflösung der Eingabe und die Umsetzung als Befehl irgendwie fehlerhaft ist. Deshalb habe ich mal im ersten Aufschlag die Meldungen im Eventmonitor mit verbose=5 für die beteiligten Module hier angehängt. Ich erkenne zwar die Warnung, kann sie aber wegen mangelhafter Perl-Kenntnisse nicht deuten.
2018.05.28 17:24:23 5 : msgConfig msgConfig: called function msgConfig_Notify()
2018.05.28 17:24:23 4 : msg Eberhard: Received push message from VillaLuehl: start
2018.05.28 17:24:23 5 : msgDialog (msg_Wz_Heizung) - entering msgDialog_Notify
2018.05.28 17:24:23 4 : msgDialog (msg_Wz_Heizung) triggered by "Eberhard fhemMsgRcvPush: start"
2018.05.28 17:24:23 5 : msgDialog (msg_Wz_Heizung) entering msgDialog_progress recipients: Eberhard message: start force: 0
2018.05.28 17:24:23 5 : msgDialog (msg_Wz_Heizung) - entering msgDialog_evalSpecials
2018-05-28 17:24:23 msgDialog msg_Wz_Heizung Eberhard_history:
2018-05-28 17:24:23 msgDialog msg_Wz_Heizung Eberhard: start
2018.05.28 17:24:23 4 : msgDialog (msg_Wz_Heizung) - return from command "deletereading TYPE=msgDialog Eberhard_history": Deleted reading Eberhard_history for device msg_Wz_Heizung
2018.05.28 17:24:23 1 : PERL WARNING: Use of uninitialized value in split at (eval 28421) line 1.
2018.05.28 17:24:23 3 : eval: {return('(' . join(') (', sort(split(' ', fhem('get TYPE=msgDialog:FILTER=NAME!=msg_Wz_Heizung:FILTER=allowed=.*(Eberhard|everyone).* trigger'))), 'abbrechen') . ') ')}
2018.05.28 17:24:23 5 : msg: found types=push
2018.05.28 17:24:23 5 : msg: found recipient=@Eberhard
2018.05.28 17:24:23 5 : msg: found title=FHEM
2018.05.28 17:24:23 5 : msg Eberhard: Checking for available routes (triggered by type push)
2018.05.28 17:24:23 5 : msg Eberhard: screen route check result: ROUTE_UNAVAILABLE
2018.05.28 17:24:23 5 : msg Eberhard: light route check result: ROUTE_UNAVAILABLE
2018.05.28 17:24:23 5 : msg Eberhard: audio route check result: ROUTE_UNAVAILABLE
2018.05.28 17:24:23 5 : msg Eberhard: push route check result: ROUTE_AVAILABLE
2018.05.28 17:24:23 5 : msg Eberhard: mail route check result: ROUTE_UNAVAILABLE
2018.05.28 17:24:23 4 : msg Eberhard: Available routes: screen=0 light=0 audio=0 text=1 push=1 mail=0
2018.05.28 17:24:23 5 : msg Eberhard: Trying to send message via gateway VillaLuehl to recipient @123456789
2018.05.28 17:24:23 5 : msg Eberhard: Determined default title:
2018.05.28 17:24:23 5 : msg Eberhard: msgSchema: replacing %RECIPIENT% and $RECIPIENT by ''
2018.05.28 17:24:23 5 : msg Eberhard: msgSchema: replacing %TelegramBot_MTYPE% and $TelegramBot_MTYPE by 'message'
2018.05.28 17:24:23 5 : msg Eberhard: push route command (fhem): set VillaLuehl message @123456789 : (abbrechen) Ich kann folgendes für dich tun:
2018.05.28 17:24:23 3 : msg Eberhard: ID=1527521063.1763.1 TYPE=push ROUTE=VillaLuehl RECIPIENT=@123456789 STATUS=OK PRIORITY=0 TITLE='FHEM' MSG=': (abbrechen) Ich kann folgendes für dich tun:'
2018-05-28 17:24:23 ROOMMATE Eberhard fhemMsgRcvPush: start
2018-05-28 17:24:23 ROOMMATE Eberhard fhemMsgRcvPushGw: VillaLuehl
2018-05-28 17:24:23 ROOMMATE Eberhard fhemMsgPush: : (abbrechen) Ich kann folgendes für dich tun:
2018-05-28 17:24:23 ROOMMATE Eberhard fhemMsgPushTitle: FHEM
2018-05-28 17:24:23 ROOMMATE Eberhard fhemMsgPushPrio: 0
2018-05-28 17:24:23 ROOMMATE Eberhard fhemMsgPushGw: VillaLuehl:@123456789:OK
2018-05-28 17:24:23 ROOMMATE Eberhard fhemMsgPushState: 1
2018-05-28 17:24:23 ROOMMATE Eberhard fhemMsgStateTypes: push:1
2018-05-28 17:24:23 ROOMMATE Eberhard fhemMsgState: 1
2018-05-28 17:24:23 TelegramBot VillaLuehl msgText: start
2018.05.28 17:24:59 5 : msgDialog (msg_Wz_Heizung) - entering msgDialog_Notify
Nach dem 'start' kommt die Meldung
: (abbrechen)
Ich kann folgendes für dich tun:
Das Modul ist fürwahr nichts für Normalos, da muss der Vorname schon Nerd lauten ;)
Gruß Eberhard
Ich korrigiere: nach 'start' kommt die meldung:
: Klammer auf ) (abbrechen)
Ich kann folgendes für dich tun:
Da kommt mir immer der Smilie dazwischen bei Doppelpunkt Klammer auf :(
Die Fehlersuche gestaltet sich schwierig.
Im Eventmonitor stehen die zwei Zeilen:
2018.05.30 08:21:16 1 : PERL WARNING: Use of uninitialized value in split at (eval 49794) line 1.
2018.05.30 08:21:16 3 : eval: {return('(' . join(') (', sort{lc($a) cmp lc($b)} (split(' ', fhem('get TYPE=msgDialog:FILTER=NAME!=msg_Wz_Heizung:FILTER=allowed=.*(Eberhard|everyone).* trigger', 1)))) . ') (abbrechen) ')}
Wenn ich den Teil TYPE=msgDialog:FILTER=NAME!=msg_Wz_Heizung:FILTER=allowed=.*(Eberhard|everyone).* durch msg_Wz_Heizung ersetze also nur get msg_WZ_Heizung trigger an fhem sende, funktioniert alles bestens. Das bedeutet der Fehler muss in diesem Teil liegen.
Der Teil TYPE=msgDialog:FILTER=NAME!= wird m.E. richtig aufgelöst und zwei Zeilen tiefer findet er den recipient:
2018.05.30 08:21:16 5 : msg: found types=push
2018.05.30 08:21:16 5 : msg: found recipient=@Eberhard
Eberhard ist der ROOMMATE bei mir. Dort steht im attr msgContactPush @VillaLuehl:123456789 . Ist hier etwas falsch geschrieben?
Die große Frage ist: Welcher Wert ist nicht initialisiert? Wer kann helfen?
Gruß Eberhard
Hallo Eberhard,
ZitatWenn ich den Teil TYPE=msgDialog:FILTER=NAME!=msg_Wz_Heizung:FILTER=allowed=.*(Eberhard|everyone).* durch msg_Wz_Heizung ersetze also nur get msg_WZ_Heizung trigger an fhem sende, funktioniert alles bestens. Das bedeutet der Fehler muss in diesem Teil liegen.
Lass doch mal das "!" bei NAME weg:
TYPE=msgDialog:FILTER=NAME=msg_Wz_Heizung:FILTER=allowed=.*(Eberhard|everyone).*VG Sebastian
PS: Auch auf die Gefahr hin dass ich mich wiederhole: Falscher Thread. Poste doch lieber im passenden:
https://forum.fhem.de/index.php/topic,77297 (https://forum.fhem.de/index.php/topic,77297)
Hallo Sebastian,
ersteinmal Danke! Hat geholfen. Das ist ein Fehler im Wiki!
Ich war wegen dem Thema "Sprachsteuerung " verunsichert. Ich habe immer noch ein kleines Problem, soll ich damit bereits umziehen?
Gruß Eberhard
Hallo,
mthilfe des msg Moduls versuche ich mit dem Befehl (enthalten im Attribut msgCmdMail):
Zitat
{ my $d='%DEVICE%'; my $title='%TITLE%'; my $msg='%MSG%'; system("echo '$msg' | /usr/bin/mailx -s '$title' -S ttycharset=UTF-8 -S sendcharsets=UTF-8 -S encoding=8bit '$d'"); }
Text EMails zu versenden. Dies funktioniert auch sehr gut, solange in der Nachricht keine Zeilenumbrüche vorhanden sind. Sind Zeilenumbrüche enthalten, ergibt sich folgendes im Log:
Zitat
2018.06.07 22:43:59 3: msg text @rr_XXXXX Hallo
duda : mail@XXXXXXXX.de: Unknown command {, try help.
Unknown command my, try help.
Unknown command my, try help.
Unknown command system("echo, try help.
Unknown command }, try help.
Ich denke, das hat etwas mit der Maskierung zu tun, sodass das Kommando falsch interpretiert wird. Hab auch schon verschiedenste Maskierungen ausprobiert, leider ohne Erfolg.
Würde mich über Unterstützung freuen.
Freundliche Grüße
Quantum
Erledigt. Bitte unten lesen.
Ich habe in Pushover ein zweites Device in Betrieb genommen.
Wenn ich folgenden Befehl ausführe, so habe ich bei Klaus den "gamelan"-Sound. Bei Maria aber den PushOver-Default-Ton.
(msg push @rr_Klaus,@rr_Maria |FHEM| Beschattung aktiv. Pushover_SOUND=gamelan)
Folgende Attribute habe ich in den Residents-Geräten angelegt.
rr_Klaus => msgContactPush => pushOver:KlausHandy
rr_Maria => msgContactPush => pushOver:MariaHandy
Kennt jemand dieses Problem und hat dafür ne Lösung?
Kommando zurück. Mein Fehler.
Ich habe zwar das neue Push-Device für rr_Maria geändert, aber gar nicht darüber nachgedacht, dass ich die Sounds auch noch bei den "msg push"-Befehlen zuordnen muss. Da es vorher zwei verschiedene Push-Apps waren, gab es für rr_Maria den Parameter noch nicht.
Hi, ich bin auch auf der Suche nach der Lösung für diese Problem - aber wurde hier nicht fündig. Kann jemand helfen?
Zitat von: der_da am 15 Mai 2018, 12:01:31
Ich habe nun den ganzen Thread von vorn bis hinten durchgelesen, komme aber nicht zu einer Lösung.
Mit
msg Das ist eine Nachricht
kann ich eine Nachricht per Jabber versenden.
Nun hätte ich gerne Zeilenumbrüche in der Nachricht. Intuitiv habe ich dann schon
msg Das ist die erste Zeile! \nDas ist die zweite Zeile
versucht. Aber es erfolgt kein Zeilenumbruch.
Wie muss ich das anstellen?
Viele Grüße
doc
wie muss denn der Befehl für Jabber aussehen wenn du ohne msg an Jabber senden möchtest?
Gruß Michael
Zitat von: Loredo am 27 März 2017, 00:28:12
Dafür gibt es bereits den msg-Befehl. Auf der ToDo steht die Erweiterung um eine Nachrichten Queue.
Hi Julian,
hast Du schon eine Idee wann das Queueing-Feature verfügbar sein wird? Ich hätte Bedarf.
Ciao,
Peter
Hi Julian,
ich baue auch aktuell alles um auf "msg" und muss sagen, anspruchsvolle Lernkurve aber feht gut ;)
Für screen habe ich eine Neutrino Box, die kann text folgendermaßen ansteuern (ich habs derzeit simpel gehalten,
msgCmdScreen set %DEVICE% showText %MSG%
msgCmdScreenHigh set %DEVICE% showtextwithbutton %MSG%
msgCmdScreenLow set %DEVICE% showText %MSG%
Das zeigt eine Nachricht auf dem TV an, bei High mit einem Bestätigen Button.
Vielleicht kannst du das ja ins Schema mit aufnehmen ?
Ronny
Hallo,
verstehe ich richtig: unter
attr globalmsg msgContactAudio
lässt sich jeweils nur ein Audio-Gerät definieren?
Habe das bisher mit Text2Speech am Laufen, feine Sache. Aber jetzt haben die Kinder ein Sonos bekommen. Und denen würden wir gerne zurufen lassen, wenn es Essen gibt ;-)
Alexander
hi,
wenn du das resident-Modul verwendest und für deine Kinder einen Roommate vergeben hast, kannst du die Audio-Device für jedes kind in den Attributen setzen. Oder du schickst die Audio-Nachricht direkt an die Sonos
msg audio @Sonos_Bedroom |Hint|Abendessen.
Gruß Michael
Danke, Michael.
Das klappt. Bedeutet aber, dass bei den universellen Durchsagen jetzt immer zwei Befehle fällig werden. Einmal für Analog-Out über das in globalMsg definierte TTS Device und einmal per separatem msg @Sonos_Player.
Das ist nicht wesentlich eleganter als mit einem separaten set Sonos_Player speak, ohne Umweg über msg.
Vielleicht ist das eine Anregung für Loredo:
Wäre toll, wenn msg, das für die zentrale Abwicklung von Benachrichtigungen über unterschiedlichste Devices und Ausgabewege so hervorragend funktioniert, mehrere Audiodevices parallel unterstützt und transparent nebeneinander verwaltet.
Grüße
Alexander
ähm die wiedergabe an mehrere Geräte ist jetzt schon integriert?!
es ist sogar so elegant gelöst, das man das abhängig vom Status bzw Aufenthaltsort des ROOMates machen kann...
Beispiel:
der Roommate rr_Michael hat folgendes gesetzt:
attr rr_Michael msgContactAudio Sonos_Bad,Sonos_Kueche
wenn ich jetzt
msg audio @rr_Michael Testdurchsage ausführe, dann wird das auf allen Sonos-Geräte wiedergegeben, aber nur wenn rr_Michael nicht abwesend oder gone ist..., wenn rr_Michael nicht zuhause ist, dann wird die audio-Nachricht auf push Weitergeleitet, sofern definiert.
das ganze kann man dann noch auf die Spitze treiben indem man msgRoom_<Raumname> definiert und da dann die passenden Audio-Devices hinterlegt. Dann wird die Audioausgabe nur auf den Geräten wiedergegeben, die in dem Raum stehen, wo sich rr_Michael befindet... (ich hoffe ich habe das jetzt richtig zusammengefasst. Das ist bei mir auch schon ein bisschen her, wo ich das alles eingerichtet habe... und ich habe da auch ein bisschen für gebraucht um alles zu schnallen)
Gruß Michael
Das habe ich schon verstanden. Und das funktioniert hier auch.
Um so logischer wäre es aus meiner Sicht aber auch, wenn man unter globalmsg zwei oder mehr msgContactAudio Geräte definieren könnte.
Die Durchsagen für Alle sollen ja gerade nicht an einen bestimmten Resident|ResidentGroup oder einen bestimmten Raum gehen. Da ist es von der Befehlsökonomie her einfach ungünstig, wenn man mehrere msg an unterschiedliche Adressaten schicken muss.
Vielleicht bin ich aber auch der einzige, der neben Sonos noch TTS (und im Schlafzimmer SB_Player) benutzt.
Grüße
Alexander
hi,
du kannst doch 2 Empfänger, durch Komma getrennt, angeben?!
attr globalMsg msgContactAudio Sonos_1,Sonos_2
und dann mit
msg audio <Audionachricht>
deine Ausgabe an die Devices schicken...
Gruß Michael
Ich glaube, das geht nur, wenn beide Empfänger vom selben Typ sind. In deinem Beispiel SONOSPLAYER.
Bei mir sind es aber zwei unterschiedliche Typen, SONOSPLAYER und Text2Speech. Ich kann die Devices mit Komma getrennt bei msgContactAudio eintragen.
Für das Attribut msgCmdAudio scheint aber nur jeweils ein Befehl akzeptiert zu werden.
Da stand für Text2Speech bisher
set raspiTTS tts %TITLE% %MSG%
Wenn ich jetzt für den neuen Sonos ergänze
set %DEVICE% Speak %VOLUME% %LANG% |%TITLE%| %MSGSHRT%,set raspiTTS tts %TITLE% %MSG%
wird eine Nachricht ,,msg audio..." nur auf dem Sonos abgespielt. Wenn ich die Reihenfolge der Befehle tausche, nur auf dem TTS-Device.
Das Problem ist also nicht, glaube ich, dass msg nicht mehrere Audio-Geräte adressieren kann, sondern dass es mehrere unterschiedliche Audio-Devices nicht transparent mit ihren jeweiligen Befehlen anspricht.
Grüße
Alexandrr
wo fummelst du rum?
sowohl für Sonos als auch für TTS gibts ja bereits ein schema.
Wenn du im globalMSG-Device
get globalMsg routeCmd audio
ausführst, dann siehst du die Befehle die ausgeführt werden...
und msg erkennt von welchem Typ deine Ausgabedevices sind und führt dann die passenden Befehle aus. Das ist ja gerade der Vorteil von msg, dass man sich keine Gedanken mehr um Syntax usw machen muss.
Ich habe zum Beispiel ein Device vom Typ FULLY und eins vom Typ SONOS.
Diese beiden trage ich beim Attribut msgContactAudio im globalMsg ein. Mehr nicht!!!
dann kann ich einfach sagen:
msg audio test
und schon wird die Audionachricht test auf meinen beiden Devices ausgegeben, da ich ja im MSG-Befehl kein spezifisches Device angegeben habe und er somit auf den default für Audio zurückgreift, welcher
ja vorher im globalMsg definiert wurde.
also bei dem Schemata brauchst du nix rumfummeln, das geht alles bereits per default.
das msgCmdAudio attribut kannst du wieder löschen. - da er so deinen gesetzten Befehl verwendet, ohne in die msgSchema zu schauen.
Poste bitte mal ein list von deinem globalMsg
Gruß Michael
Danke, das war der Fehler, Michael!
Hab das msgCmdAudio attribut gelöscht, jetzt läuft der Laden.
;D
Super
Benachrichtigung über Raumfeld Lautsprecher oder über Alexa?
Ich bin auf der Suche nach einer Audio-Ausgabemöglichkeit für mein FHEM System für 2 Anwendungsmöglichkeiten:
1. Abhängig von einem Event möchte ich eine Sprachnachricht ausgeben z.B. "Alarmanlage scharf geschalten".
2. Im Alarmfall möchte ich meine Raumfeld Lautsprecher aus dem Standby hochholen und "Heavy Metal Musil abspielen".
Mit Sonos sollte dies problemlos sein, leider Raumfeld(Teufel).
Die mp3 Dose von Homematic kenne ich.. És stehen ja überall Lautsprecher rum im Haus. Noch einen, als sperates System, mit Batterien?
Kann ich über euer Modul hier was machen?
wenn du deine Raumfeld über FHEM steuern kannst, dann könntest du für deine Raumfeld ein eingenes msg-Schema erstellen und dann über den msg-Befehl ansprechen.
Steuern würde ich das ganze mit nem DOIF. Für die Heavy-Metal Musik brauchst du nicht unbedingt den msg-Befehl.
Gruß Michael
Hallo,
ich tue mich sehr schwer mit der Verwendung vom msg / msgconfig. Ich habe die Wikis durchgearbeitet. Folgende "Text-Nachrichtensysteme" funktionieren bei mir als Standalonesysteme und verwende ich:
Debian, teleBot und Pushover. Als Audiosystem habe ich mySip bzw. t2Speech.
telebot habe ich als msgContactPush eingerichtet.
msg test schickt auch an meinen Telegramm Account eine Nachricht. Das funktioniert
msg @pushmsg test sendet eine Nachricht an meinen Pushover account . Das funktioniert.
Welche attr. muss ich jetzt setzen, um eine email (Debian) an eine emailadresse mit Namen Hans.Klaus@t-online.de zu schicken? msg @DEBIANMAIL |Hans.Klaus.t-online.de msg tuts leider nicht.
Noch eine Verständisfrage:
Es gibt eine globale Definition der Attribute für msg. Dies ist die globalMsg.
Dort definiere ich mit msgType ... welche MessageType ich verschicken möchte: text, audio, etc.
Dort definiere ich mit msgContactPush, welchen Push Dienst ich verwenden möchte teleBot, Pushover
Dort definiere ich mit msgCmdMail, welchen Email Dienst ich verwenden möchte: Debian ...
Diese attr zieht nur, wenn in dem sendenden device oder dem "Sendebefehl" selbst nicht anderes definiert ist.
Sendebefehl schlägt hier noch attr in der Devicespezifikation.
hier noch ein list des globalMsg
Internals:
FUUID 5c6d216d-f33f-64ff-88bb-a05d2d1ea0531502
NAME globalMsg
NOTIFYDEV TYPE=(Jabber|TelegramBot|yowsup)
NR 219
NTFY_ORDER 50-globalMsg
STATE 0
TYPE msgConfig
READINGS:
2019-03-07 18:32:31 fhemMsgPush @DebianMail|Klaus.Peter@t-online.de
2019-03-07 18:32:31 fhemMsgPushGw teleBot:ERROR
2019-03-07 18:32:31 fhemMsgPushPrio 0
2019-03-07 18:32:31 fhemMsgPushState 0
2019-03-07 18:32:31 fhemMsgPushTitle -
2019-03-07 18:32:31 fhemMsgState 0
2019-03-07 18:32:31 fhemMsgStateTypes push:0 forwards:text>push
Attributes:
DbLogExclude .*
alias Zentrales Device zum Verschicken von Nachrichten
comment FHEM Global Configuration for command 'msg'
group Global
icon message_mail_open
msgCmdMail {DebianMail('%DEVICE%','%TITLE%','%MSG%')}
msgContactPush teleBot
msgType text
room GERAETE
stateFormat fhemMsgState
verbose 3
Hallo Loredo,
spricht etwas dagegen die Zeile 1957 in "75_MSG.pm" wie in meinen Post beschrieben anzupassen?
Zitat von: Schlimbo am 13 Februar 2018, 21:35:00
Habe testweise die Zeile
eval $cmd;
mal mit
AnalyzeCommand(undef,$cmd);
ersetzt, damit funktioniert es auch mit Umlauten.
Ohne diese Änderung habe ich nach wie vor Probleme mit den Umlauten:
https://forum.fhem.de/index.php/topic,39983.msg764689.html#msg764689
zu AnalyzeCommand:
https://wiki.fhem.de/wiki/DevelopmentModuleAPI
Danke für die Erinnerung! Habe ich kurz getestet und in abgewandelter Form eingecheckt.
Außerdem wurde die Abhängigkeit von JSON zugunsten von JSON::PP geändert, welches seit Perl 5.14 direkt mitgeliefert wird.
Hallo Zusammen,
ich habe in Zusammenhang mit msg folgende Frage:
Kann ich mit dem
attr msgRecipientMail
was unter den jeweiligen Devices steht auch mehrere Devices eintragen?
also so:
attr msgRecipientMail Jens,Susi
Wobei die Devices "Jens" und "Susi" roommates device sind unter denen per "attr msgContactMail" jeweils die Mailadresse hinterlegt ist.
Ich würde gern aus dem Residents Device per
attr msgRecipientMail Jens,Susi
auf die beiden anderen Devices verweisen.
Das hätte den Vorteil, das man eben zentral unter den jeweiligen Roommates die Mailadresse pflegen kann.
Da mein Homemode Modul eine Alarmmeldung über mail verschickt per "@RESIDENTS" wäre das schön, die Mailadressen nur im jeweiligen ROOMMATE Device zu hinterlegen und nicht schon im RESIDENTS Modul.
Gruß
Jens
Hallo,
gibt es eine Möglichkeit, eine Nachricht an alle außer einen Resident zu adressieren?
fhem("msg push @rgr_Bewohner:FILTER=NAME!=rr_$alias |Departure| $alias hat die Wohnung verlassen!");
So in der art?
Nein aber du kannst das entsprechende Reading aus dem rgr_Bewohner Device dafür nehmen, dafür sind sie da.
Zitat von: Loredo am 01 August 2019, 15:15:36
Nein aber du kannst das entsprechende Reading aus dem rgr_Bewohner Device dafür nehmen, dafür sind sie da.
Welches Reading meinst du?
Ich möchte eine Nachricht an alle Residents außer einen adressieren.
Das war noch eine Idee:
msg push @i:NAME~rr_.*:FILTER=i:NAME!=rr_Sarah |Test| Nachrichtfunktioniert allerdings leider auch nicht. Vermutlich weil die Adressaten durch Pipes (|) voneinander getrennt übergeben werden müssen.
Hat jemand einen Tip für mich?
Wenn ich eine Pushnachricht mit Zeilenumbrüchen habe
msg push erste zeile <br> zwieite zeile
kann diese nicht als Audionachricht
msg audio erste zeile <br> zwieite zeile
ausgegeben werden.
Es wäre klasse, wenn ein Zeilenumbruch zum Beispiel als Redepause ähnlich wie 2-3 punke " . . . " interpretiert würde.
Escapete Zeilenumbrüche im code, wie sie in längeren skripten zur lesbarkeit hilfreich führen ebenfalls dazu das Audionachrichten nicht mehr funktiuonieren.
Funktioniert:
fhem("msg push \@rgr_Bewohner \
|Frau Schnitzler| \
Der Staubsauger wurde unterbrochen! <br>\
Er fährt in $abbruchverzoegerung min zur Basis zurück."\
);
Funktioniert nicht:
fhem("msg audio \
Der Staubsauger wurde unterbrochen! . . . \
Er fährt in $abbruchverzoegerung min zur Basis zurück.\
");
Funktioniert:
fhem("msg audio Der Staubsauger wurde unterbrochen! . . . Er fährt in $abbruchverzoegerung min zur Basis zurück.");
Bitte entschuldigt den Spam. Ich stoße grade auf die ein oder andere Schwierigkeit da ich versuche alle Nachrichten auf msg umzustellen.
Perl code wird innerhalb des msg Befehls nicht interpretiert. Mache ich da irgendwas falsch?
msg push @rr_Joscha 2 |Batterie Warnung| {fhem("get mon_Batterie default")}
Meine Empfehlung ist RTFM. Oder zu deutsch, lies die commandref. Da wirst Du als erstes feststellen, das das von Dir verwendete Format als Deprecated ausgezeichnet ist.
Ich stehe vor folgendem Problem, vielleicht hat jemand eine Lösung bzw. Denkanstoss für mich:
- Als Standardkanal für Push möchte ich gerne Pushover nutzen
- dementsprechend habe ich auch bei jedem Roommate das msgContactPush gesetzt
- wenn ich nun aber MsgDialog nutzen möchte, muss ich gemäß Anleitung (https://wiki.fhem.de/wiki/MsgDialog#ROOMMATE_.2F_GUEST) msgContactPush auf Telegram umstellen, damit auch fhemMsgRcvPush richtig befüllt wird
- anschließend kommen aber - natürlich - alle meine Push-Nachrichten auf Telegram raus
das möchte ich so aber nicht :-)
Natürlich kann ich jetzt alle push-Befehle von
msg push @rr_Michael |FHEM| Dies ist eine Testnachricht für Michael!
umstellen auf
msg push @<Pushoverdevice> 1 |FHEM| test
aber das möchte ich eigentlich nicht, weil ich dadurch einen Teil der Flexibilität von msg (Zentrale Stelle zum Definieren von push-Kanal pro Roommate) verliere.
Wie habt ihr sowas denn umgesetzt?
hi,
das gleiche Problem hatte ich auch. Ich habe es jetzt so gemacht, dass ich neben meinem Roommate rr_Michael ein Guest rg_Michael angelegt habe. bei dem Guest habe ich dann attr rg_presenceDevices rr_Michael gesetzt, damit der Status der beiden immer gleich ist.
bei rg_Michael habe ich dann als msgContactPush Telegram hinterlegt, rg_Michael habe ich dann in den room hidden gepackt.
Somit läuft meine normale Kommunikation über pushover, es sei denn ich nutze msgDialog, dann über Telegram.
Gruß Michael
Hallo zusammen
hat schon jemand YAMAHA_MC in Verbindung mit tts und msg ans laufen gebracht??
Mir raucht der Schädel und ich komme nicht weiter.
Gruß Helmuth
Zitat von: l2r am 14 Oktober 2019, 14:24:03
hi,
das gleiche Problem hatte ich auch. Ich habe es jetzt so gemacht, dass ich neben meinem Roommate rr_Michael ein Guest rg_Michael angelegt habe. bei dem Guest habe ich dann attr rg_presenceDevices rr_Michael gesetzt, damit der Status der beiden immer gleich ist.
bei rg_Michael habe ich dann als msgContactPush Telegram hinterlegt, rg_Michael habe ich dann in den room hidden gepackt.
Somit läuft meine normale Kommunikation über pushover, es sei denn ich nutze msgDialog, dann über Telegram.
Gruß Michael
Ich habe das jetzt auch eine Weile so laufen, ist als Notlösung auch ok. Aber grundsätzlich irgendwie doch schon arg von Hinten durch die Bruste ;-)
Wäre es nicht eventuell möglich msg so zu erweitern, dass ein msgDialog über ein eigenes Attribut eingetragen werden kann und das msgContactPush für die eigentlich vorgesehene Funktion (nämlich Push von Nachrichten) bleiben kann?
Hallo Allerseits,
ich hoffe ihr könnt mir helfen :)
ich nutze bisher SONOS um eine Sprachausgabe in 4 räumen zu Realisieren.
Mein Problem ist nun: läuft Musik in einem Raum, und ich nutzte die alte Variante mit "set Sonos_Wohnzimmer Speak 40 de Jemand ist an der Haustür" stoppt die Musik, die Ansage kommt und nach der ansage läuft die Musik weiter. Nutze ich nun das globalmsg Modul "msg audio Jemand ist an der Haustür", stoppt die Musik, die Ansage kommt aber die Wiedergabe wird nicht fortgesetzt.
kann das jemand bestätigen?
Grüße
GrayDeath
Guten Morgen,
ich habe einen LG Fernseher "TV" mit dem Modul LGTV_WebOS eingebunden und kann auch Nachrichten darauf senden.
Allerdings klappt das bei mir nicht mit msg. PushOVer und e-mail funktioniert einwandfrei.
ich habe als attr msgContactScreen TV eingebunden.
Das einzige was "anders" ist, war der Name des Schemas, das heisst "LGTV_WEBOS" und nicht wie das Modul "LGTV_WebOS"
Es kommt auch die Fehlermeldung:
Unknown command schema for gateway device type LGTV_WebOS.
Kann das damit zu tun haben?
Gruß
Carsten
Ich nutze bereits seit Jahren diese Variante. Ich störe mich jedoch auch immer wieder an der Anzahl der Attribute, die mir in jedem Device angeboten werden. In Global habe ich aktuell folgende zusätzliche userattr:
msgContactAudio msgContactLight msgContactMail msgContactPush msgContactScreen msgParams msgPriority msgRecipient msgRecipientAudio msgRecipientLight msgRecipientMail msgRecipientPush msgRecipientScreen msgRecipientText msgTitle msgTitleShrt msgType:text,push,mail,screen,light,audio,queue
An diesem Verfahren hat sich nichts geändert, oder?
Es gab damals verschiedene Überlegungen, aber die scheinen im Sande verlaufen zu sein.
Oder habe ich etwas übersehen? Danke.
Hi,
hätte eine kurze frage die ich nirgends beantwortet finde.
Wo ist der unterschied zwischen %MSGSHRT% und %MSG% und wie benutze ich die beiden?
In der Doku wird nur auf %MSG% eingegangen.
Danke und Gruß,
Stefan
Hallo,
ich bin erst vor Kurzem auf den Befehl msg gestossen und nutze ihn mittlerweile ausgiebig.
Allerdings möchte ich nun auf Amazon Polly zur Sprachsynthese umsteigen.
Prinzipiell funktioniert das auch schon, bei meinen Sonos-Playern habe ich dafür einen "Speak1"-Befehl.
Was nicht funktioniert ist die Einbindung in msg.
Eigentlich dachte ich, dass das relativ einfach sein sollte, da man ja das Attribut "msgCmdAudio" im Device msgConfig richtig setzen kann.
Also habe ich definiert:
attr myMsgConfig msgCmdAudio set $DEVICE Speak1 40 Hans <speak>$TITLE <break> $MSG</speak>
attr myMsgConfig msgContactAudio Sonos_Wohnzimmer
Wenn ich jetzt "msg Hallo" aufrufe, dann kommt folgende Meldung:
Sonos_Wohnzimmer: Please define $DEVICE first
However, message was still sent to some recipients!
Was mache ich falsch?
Kann mir da bitte jemand helfen?
Danke, lg, Gerhard
Zitatattr myMsgConfig msgCmdAudio set $DEVICE Speak1 40 Hans <speak>$TITLE <break> $MSG</speak>
Habs mit meinen Amazon Echos so am laufen:
set %DEVICE% speak %MSG%
Hallo Borkk,
Danke. Das war's.
Hab's dann auch erst im Wiki gefunden, obwohl ich hundertmal drübergelesen habe.
Mein msgCmdAudio sieht nun so aus:
msgCmdAudio set %DEVICE% Speak1 40 Hans <speak>%TITLE% %MSG%</speak>
lg, Gerhard
Hallo,
eine Frage dazu bitte noch:
Ich möchte die Stimme gerne auswählbar machen.
Dazu hätte ich mir ein Userattribut msgPollyStimme (mit den Werten Hans, Marlene etc.) angelegt.
Aber wie bringe ich das Attribut nun in das Attribut msgCmdAudio ?
Ein einfaches "set %DEVICE% Speak1 40 AttrVal("myMsgConfig","msgPollyStimme","Hans") <speak>%TITLE% %MSG%</speak>" funktioniert leider nicht.
Danke, lg, Gerhard
Bevor ich mich verrenne:
Ich habe an mehreren DOIFs ellenlange Einträge, um verschiedene Nachrichten zu verschicken. Diese haben jeweils einen eigenen Dummy-Schalter (an/aus), so dass ich im Nachgang ohne DOIF-Änderung Nachrichtenversand an- und ausschalten kann.
Hier ein Beispiel:
([kg_wr_hm_waschmaschine_Pwr:power:d] > 4 )
(set kg_wr_waschmaschine_Betrieb an)
(set Waschmaschine_Leerung nein)
DOELSEIF ([kg_wr_hm_waschmaschine_Pwr:power:d] < 4 )
(set kg_wr_waschmaschine_Betrieb fertig)
(set Waschmaschine_Leerung ja)
(set kg_wr_hm_waschmaschine_Sw off)
(IF (([haus_Status:state] eq 1) and [ttsMsg_waschmaschine_eg_fl_Tablet10Zoll] eq "an")(set eg_fl_Tablet10Zoll volume [ttsMsg_waschmaschine_lautstaerke]))
(IF (([haus_Status:state] eq 1) and [ttsMsg_waschmaschine_eg_fl_Tablet10Zoll] eq "an")(set eg_fl_Tablet10Zoll ttsMsg Die Waschmaschine ist fertig))
(IF (([haus_Status:state] eq 1) and [ttsMsg_waschmaschine_eg_wz_Tablet10Zoll] eq "an")(set eg_wz_Tablet10Zoll volume [ttsMsg_waschmaschine_lautstaerke]))
(IF (([haus_Status:state] eq 1) and [ttsMsg_waschmaschine_eg_wz_Tablet10Zoll] eq "an")(set eg_wz_Tablet10Zoll ttsMsg Die Waschmaschine ist fertig))
(IF (([haus_Status:state] eq 1) and [ttsMsg_waschmaschine_og_bz_Tablet10Zoll] eq "an")(set og_bz_Tablet10Zoll volume [ttsMsg_waschmaschine_lautstaerke]))
(IF (([haus_Status:state] eq 1) and [ttsMsg_waschmaschine_og_bz_Tablet10Zoll] eq "an")(set og_bz_Tablet10Zoll ttsMsg Die Waschmaschine ist fertig))
(IF (([haus_Status:state] eq 1) and [ttsMsg_waschmaschine_og_fl_Tablet10Zoll] eq "an")(set og_fl_Tablet10Zoll volume [ttsMsg_waschmaschine_lautstaerke]))
(IF (([haus_Status:state] eq 1) and [ttsMsg_waschmaschine_og_fl_Tablet10Zoll] eq "an")(set og_fl_Tablet10Zoll ttsMsg Die Waschmaschine ist fertig))
(IF (([pushover_waschmaschine_gunther:state] eq "an")) (set Pushover msg title="Waschmaschine" "Die Wäsche ist fertig" device='IPhone7GB'))
(IF (([pushover_waschmaschine_hilke:state] eq "an")) (set Pushover msg title="Waschmaschine" "Die Wäsche ist fertig" device='IPhone8Hilke'))
1. Frage:
Kann ich über den msg-Befehl das Gleiche hinbekommen (inkl. "Nachrichten-Schaltern" zum aktivieren/deaktivieren, die ich mir z. B. über Tablet UI einbauen kann)?
2. Frage:
Ich habe mir gerade das globalMsg Device angelegt und versucht per
msg push @IPhone7GB 1 |FHEM| test
eine Testnachricht auf mein sonst funktionierendes Pushdevice zu bringen. Leider bekomme ich folgende Meldung
Device IPhone7GB does not exist
Muss ich noch ein Extra-Device anlegen oder handelt es sich um das Device im Pushdienst?
ich pushe das nochmal nach oben. Vielleicht kann mir ja einer von Euch Tipps geben. ::)
Hallo Gunther, ganz kurz als Anstoss:
Zitat1. Frage:
Kann ich über den msg-Befehl das Gleiche hinbekommen (inkl. "Nachrichten-Schaltern" zum aktivieren/deaktivieren, die ich mir z. B. über Tablet UI einbauen kann)?
Ja, ich habe die gleiche Historie wie Du. Meldungen und Bedingungen zu deren Versand verteilt über unzählige DOIFs.
Das war ein riesiger Aufwand zur Pflege. Nachdem ich MSG fand habe ich die ganzen Bedingungen zentral und gebe
im jeweiligen DOIF nur noch den generellen Aufruf ab.
Das sieht dann z.B. so aus
([Waschmaschine.Status:"done"])
{
fhem("msg audio,screen 1 |Waschkeller| Waschmaschine ist fertig!");
}
DOELSEEine Beispielbedingung im zentralen MSG device (Attribut "msgCmdAudio") könnte dann so aussehen:
IF ([KNX.FIDS.Aktiv] eq "off" and [KNX.ZENTRAL.DoNotDisturb.SW] eq "off")(set %DEVICE% speak 'Achtung Achtung %MSG%')Zur Frage:
Zitateine Testnachricht auf mein sonst funktionierendes Pushdevice zu bringen. Leider bekomme ich folgende Meldung
Meine Definition im MSG device für Push (Attribut "msgCmdPush") sieht so aus
set %DEVICE% msg title='%TITLE%' device='%RECIPIENT%:%TERMINAL%' priority=%PRIORITY% url_title="%URLTITLE%" message='%MSG%'Gruß
Danke für Deine Unterstützung.
Was sind
KNX.FIDS.Aktiv und KNX.ZENTRAL.DoNotDisturb.SW bei Dir?
Dummy-Devices?
Moin Gunther,
Das sind devices (KNX) die den Zustand des Hauses abbilden und damit bestimmen ob z.B. Eine Audio Message gesendet werden soll oder nicht. So oder ähnlich könntest du die Zustände deiner Tablets abfragen.
Gruß
Gesendet von iPhone mit Tapatalk Pro
Auch eine Eule... :)
Damit könnte ich ja nur generell (in Deinem Fall) Audio an oder abschalten und nicht abhängig vom Vorgang (also je DOIF), richtig?
Sehe den Vorteil noch nicht so richtig... Sollte vielleicht mal ins Bett. ;-)
Moin Gunther,
Eule und Vogel ... :D
Ja und Nein. Prinzipiell trennt man mit MSG Ereignis und Benachrichtigungsvorgang (-Eskalation).
Ich erzeuge generell in der Ereignisbehandlung (Waschmaschine fertig, Fenster offen usw.) eine Nachricht (optional mit Prio und Empfängern).
Und im MSG wird dann zentral entschieden ob die Nachricht über ein Tablet ausgegeben wird (weil jemand anwesend ist), ob sie auf dem Bildschirm angezeigt werden soll (weil ein SAT Receiver an ist) oder ob die Nachricht doch noch auf ein Handy gepusht werden soll.
Man verliert etwas an Flexibilität (wenn die Nachrichtenweitergabe nur bei einem bestimmten Event genau auf eine Art erfolgen soll). Dafür spare ich mir in jedem Ereignis-DOIF den ganzen Rattenschwanz aus gib Audio aus, sende Text an Receiver und pushe Text an Handy (den Du auch hast). Denn die Waschmaschine war der Anfang und dann kam noch ein weiteres Wandtablet im Keller dazu und dann noch die Fenster-Offen-Erkennung usw. ...
So ganz steige ich durch Dein DOIF noch nicht durch ...
(IF (([haus_Status:state] eq 1) and [ttsMsg_waschmaschine_eg_fl_Tablet10Zoll] eq "an")(set eg_fl_Tablet10Zoll volume [ttsMsg_waschmaschine_lautstaerke]))
(IF (([haus_Status:state] eq 1) and [ttsMsg_waschmaschine_eg_fl_Tablet10Zoll] eq "an")(set eg_fl_Tablet10Zoll ttsMsg Die Waschmaschine ist fertig))
...
(IF (([pushover_waschmaschine_gunther:state] eq "an")) (set Pushover msg title="Waschmaschine" "Die Wäsche ist fertig" device='IPhone7GB'))
(IF (([pushover_waschmaschine_hilke:state] eq "an")) (set Pushover msg title="Waschmaschine" "Die Wäsche ist fertig" device='IPhone8Hilke'))
Die Abfragen ob Audiodevice an ist und Lautstärke setzen lässt sich ganz einfach zentral im MSG durchführen. Unabhängig vom Event und Ausgabedevice. Zusätzlich hast Du noch die Optionen dem Ereignis eine Priorität mitzugeben und die Ausgabe im MSG davon abhängig zu steuern. Und Du kannst das ganze noch mit Residents verknüpfen.
pushover_waschmaschine_gunther
pushover_waschmaschine_hilke
ttsMsg_waschmaschine_eg_fl_Tablet10Zoll
Ich vermute das sind Dummies und steuern welche Audioausgabe wo erfolgen soll?
Ich verstehe noch nicht ganz wie und wann die gesetzt werden? Nur wenn man diese vom eigentlichen Ereignis trennen kann und man mehrere Ereignisse und Benachrichtigungsdevices verwalten muss macht MSG aus meiner Sicht wirklich Sinn.
Gruß
Hallo zusammen,
ich habe vor ein paar Tagen angefangen mich mit dem msg Befehl auseinanderzusetzen, und bin eigentlich recht begeistert davon, leider ist das ganze etwas unübersichtlich, und die Dokumentation lässt noch etwas zu wünschen übrig. Daher frage ich einfach mal hier, vielleicht kann ja jemand Licht ins Dunkel bringen.
Ich habe hier sowohl Google Home Lautsprecher als auch Sonos Lautsprecher im Einsatz. Die Sonos Lautsprecher funktionieren ohne Probleme, die Google Home Lautsprecher bekomme ich momentan nicht zum Laufen, weis aber das ich sie schonmal erfolgreich zur Sprachausgabe eingesetzt habe, daher frage ich auch hier, anstatt es selbst einfach auszuprobieren. Ich möchte einfach vermeiden, Tage damit zu verbringen, das Googlecast Device ins Laufen zu bringen nur um dann festzustellen das ich mit msg nur entweder Sonos ODER Googlecast verwenden kann.
Soweit ich das verstanden habe, unterstützt msg von Haus aus einige "Dienste" wenn etwas nicht dabei ist, lässt sich das ganze über die msgCmd Attribute selbst einstellen.
So habe ich es auch für msg screen gemacht. Hier benutze ich NotifyAndroidTV, um Benachrichtigungen auf allen TVs anzuzeigen. Da ich hier auch keine anderen Screens habe, reicht mir das auch aus.
Wie sieht das jetzt aber bei Audio aus? Die Sonos Lautsprecher werden von hause aus unterstützt. Googlecast so wie ich das verstanden habe nicht, hier müsste ich mir dann über das entsprechende Attribut den Befehl selbst basteln. Soweit so gut, aber was passiert dann mit den Sonos Geräten? Wird der voreingestellte Befehl dann durch das Attribut überschrieben und msg versucht alle Audio Benachrichtigungen mit dem neuen Befehl zu versenden, oder erkennt das Modul, ob es sich um ein Sonos Gerät oder etwas anderes handelt?
Was passiert eigentlich, wenn ich in Zukunft noch einen dritten Audio-Weg benötige? Ich habe doch nur ein Attribut msgCmdAudio. Wie definiere ich hier jetzt mehrere verschiedene Wege, und woran erkennt fhem im Zweifelsfall welchen der selbst definierten Befehle verwendet wird?
@Loredo, ich habe seit einiger Zeit das Modul SSChatBot zur Integration des Synology Chat Servers im Angebot. Ein User fragte bereits ob du das Modul in deinem msg mit implementieren könntest.
Forum: https://forum.fhem.de/index.php/topic,105714.msg1062901.html#msg1062901
Wiki: https://wiki.fhem.de/wiki/SSChatBot_-_Integration_des_Synology_Chat_Servers
VG,
Heiko
Hallo,
ich nutze zum Versand von Push-Nachrichten eine Funktion in der 99_myutils, um die Nachrichten über meine Nextcloud an die Endgeräte zu schicken.
Rufe ich die Funktion direkt auf, funktioniert es bisher tadellos. über das msg-Modul kommt es regelmäßig vor, dass doch nicht gepusht wird und stattdessen eine Mail geschickt wird. Im globalMsg-Device findet sich jedoch kein Hinweis.
Wie kann ich das debuggen bzw. wie kann ich es der perl-Funktion heraus eine Rückmeldung an das Modul schicken?
VG, Stephan
Hallo,
leider verstehe ich das Modul noch nicht ganz. Ich habe msg grundlegend eingerichtet und versende per Telegram und Residents bereits Nachrichten:
Internals:
CFGFN
FUUID 5f8628aa-f33f-50ef-85d7-a4e61f51686ab251
FVERSION 75_msgConfig.pm:0.189950/2019-03-22
NAME globalMsg
NOTIFYDEV TYPE=(Jabber|TelegramBot|yowsup)
NR 352756
NTFY_ORDER 50-globalMsg
STATE 0
TYPE msgConfig
READINGS:
2020-10-16 01:07:57 fhemMsgMail Normal Titel message
2020-10-16 01:07:57 fhemMsgMailPrio 0
2020-10-16 01:07:57 fhemMsgMailState 0
2020-10-16 01:07:57 fhemMsgMailTitle -
2020-10-14 00:26:42 fhemMsgPush test
2020-10-14 00:26:42 fhemMsgPushGw Telegram:OK
2020-10-14 00:26:42 fhemMsgPushPrio 0
2020-10-14 00:26:42 fhemMsgPushState 1
2020-10-14 00:26:42 fhemMsgPushTitle -
2020-10-16 01:07:57 fhemMsgState 0
2020-10-16 01:07:57 fhemMsgStateTypes mail:0 forwards:text>mail
Attributes:
comment FHEM Global Configuration for command 'msg'
event-on-change-reading .*
group Global
msgContactPush Telegram
msgType text
room 91_WebDevices
stateFormat fhemMsgState
verbose 1
Mein Ziel ist es nun, für manche Events E-Mails zu versenden.
Bisher versende ich E-Mail über ssmtp:
sub SendMail($$$) {
my ($subject, $message, $recipient) = @_;
system("echo \"$message\" | mail -s \"$subject\" $recipient");
{SendMail('Betreff', 'Nachricht', 'Empfänger')}
}
Kann ich das dafür verwenden, oder gibt es besseres?
Hi zusammen,
wenn man Sonos auf MQTT umstellt (https://wiki.fhem.de/wiki/Sonos2mqtt), dann mag msg nicht mehr.
Sonos_Wohnzimmer: Unknown command schema for gateway device type MQTT2_DEVICE. Use manual definition by userattr msgCmd*
Kann mir jemand sagen (oder einen Link verraten), wie/wo ich so ein Schema anlegen kann und was dort rein muss?
Edit:
Wichtig wäre dabei, dass ich im Schema nach "model=sonos2mqtt_speaker" filtern kann. Der Device Type "MQTT2_DEVICE" alleine wäre unpassend.
Danke schon mal
Schön, dass du fragst. Vor diesem Problem stehe ich auch gerade und wollte mich in Kürze einarbeiten.
Irgendwie müsste man die Datei msgSchema.pm (https://svn.fhem.de/trac/browser/trunk/fhem/FHEM/msgSchema.pm) erweitern.
Zitat von: FunkOdyssey am 21 Oktober 2020, 14:15:47
Irgendwie müsste man die Datei msgSchema.pm (https://svn.fhem.de/trac/browser/trunk/fhem/FHEM/msgSchema.pm) erweitern.
die scheint aber nur auf den Type vom Device zu gehen.
Kann sein, dass wir (übergangsweise) das Attribut msgCmdAudio im msgConfig-Device nutzen müssen.
Die Audioausgabe auf ein FULLY Device funktioniert m. E. nicht korrekt. Es wird nur das erste Wort eines Satzes ausgegeben.
Das liegt daran, dass FULLY den auszugebenden String wohl mit Quotes erwartet.
Ich habe daher den entsprechenden Abschnitt in msgSchema wie folgt geändert:
'FULLY' => {
'Normal' => 'set %DEVICE% speak "%MSGSHRT%"',
'ShortPrio' => 'set %DEVICE% speak "%SHOUTOUT%"',
'Short' => 'set %DEVICE% speak "%SHOUTOUT%"',
'defaultValues' => {
'ShortPrio' => {
'SHOUTOUT' => 'Achtung!',
},
'Short' => {
'SHOUTOUT' => 'Hinweis!',
},
},
},
Damit funktioniert das wie erwartet.
Wäre schön wenn die Anpassung übernommen würde.
Hallo zusammen,
aktuell versende ich WebCam-Bilder an TelegramBot und wechsele gerade zu SiSi (Signal). Die einzelnen Module können das auch recht gut.
In diesem Thread konnte ich keine Details zum Versenden von Dateien finden.
Gibt es spezielle Parameter, die ich übersehen habe oder ist es evtl. gar nicht vorgesehen?
Grüße, Carsten
Hallo,
mit meinem Problem bei Push-Nachrichten bin ich leider bisher nicht weiter gekommen...
Hinzu kommt nun ein neues Problem:
Ich nutze das Echo-Device-Modul für Audio-Ausgaben über meine Alexa-Geräte.
zuletzt hat das Modul bei mir etwas gestreikt und ich habe es vorübergehend deaktiviert (disable 1).
Dies hat dazu geführt, dass Nachrichten per msg-Befehl zwar wie vorgesehen auf push/mail umgeleitet wurden aber FHEM in der Zwischenzeit scheinbar blockiert wurde. Ein notify, welches als erstes eine Nachricht abspielt und anschließend einige Geräte schaltet, wurde mit mehreren Sekunden Verzögerung abgearbeitete.
Lässt sich dies umgehen / abfangen?
Grüße, Stephan
Hallo Loredo,
Für mein Modul "Signalbot" (quasi der Nachfolger von SiSi, welches ja nicht mehr aktiv maintained wird) habe ich eine Anfrage dies mit deinem msg Modul zu verknüpfen:
https://forum.fhem.de/index.php/topic,118370.msg1136305.html#msg1136305
Wenn ich das richtig verstanden habe, brauche ich dafür in mein Modul eigentlich gar nichts zu integrieren, aber eine Default config wie sie für SiSi bereits existiert bei dir könnte Sinn machen.
Letztendlich ist meine Syntax kompatibel zu SiSi, ich biete aber vereinfacht nur die Methode "send" für alle Arten von Nachrichten an.
Lass mich wissen, wenn es sinnvoll wäre auch auf meiner Seite etwas anzupassen,
Gruß,
Jörg
Zitat von: Adimarantis am 01 März 2021, 08:46:49
Für mein Modul "Signalbot" (quasi der Nachfolger von SiSi, welches ja nicht mehr aktiv maintained wird) habe ich eine Anfrage dies mit deinem msg Modul zu verknüpfen:
https://forum.fhem.de/index.php/topic,118370.msg1136305.html#msg1136305
Ich schließe mich dem Wunsch an. Signal steigt ja gerade enorm in der Popularität!
Du kannst unter github.com/fhem ein PR für das msg Modul einreichen.
Zitat von: CoolTux am 02 Juni 2021, 19:39:00
Du kannst unter github.com/fhem ein PR für das msg Modul einreichen.
Ich habe leider nichts, was gepullt werden könnte. Ich hoffe im Moment noch darauf, dass Julian Signalbot integriert, bevor ich mich selbst in den Code einarbeite (mein Leidensdruck im Verhältnis zu meiner Freizeit ist noch nicht hoch genug).
Zitat von: Dr. Boris Neubert am 03 Juni 2021, 13:18:02
Ich habe leider nichts, was gepullt werden könnte. Ich hoffe im Moment noch darauf, dass Julian Signalbot integriert, bevor ich mich selbst in den Code einarbeite (mein Leidensdruck im Verhältnis zu meiner Freizeit ist noch nicht hoch genug).
Auch auf die Gefahr hin, dass ich hier etwas nicht richtig verstehe aber das msg-Midul bietet doch schon auf der Benutzer-Ebene die Möglichkeit es zu erweitern, wie man möchte.
Sprich, alles was in einem anderen Modul (hier "Signalbot") oder in einer 99_myUtils-Fubktion in FHEM ausgeführt werden kann, sollte auch im msg-Modul anleg bar sein, sodass der Entwickler nicht jedes Mal aktiv werden muss....
Zitat von: balli1187 am 03 Juni 2021, 15:41:34
Auch auf die Gefahr hin, dass ich hier etwas nicht richtig verstehe aber das msg-Midul bietet doch schon auf der Benutzer-Ebene die Möglichkeit es zu erweitern, wie man möchte.
Sprich, alles was in einem anderen Modul (hier "Signalbot") oder in einer 99_myUtils-Fubktion in FHEM ausgeführt werden kann, sollte auch im msg-Modul anleg bar sein, sodass der Entwickler nicht jedes Mal aktiv werden muss....
Das ist richtig. Jedoch ist die Doku für mich nicht ausreichend gewesen, das auch zu realisieren. Ein Anwender hat mich darauf hingewiesen, dass im Wiki zum veralteten SiSi ein Beispiel steht, mit dem ich dann wohl zurechtkomme.
Interessant bzgl. Doku wäre für mich (und andere Sonos2mqtt'ler) auch noch, wie man ein Schema anlegen kann, bei man mit Model (=sonos2mqtt_speaker) und nicht Device Type (MQTT2_DEVICE macht keinen Sinn) arbeitet.
Bitte steinigt mich nicht, aber ich benutze bisher pushnotifier um Nachrichten von FHEM auf verschiedene iPhones zu schicken. Jetzt möchte ich pushnotifier gerne in mit msg benutzen, finde aber leider keinerlei Dokumentation dazu. Im Wiki steht nichts von Pushnotifier und hier im Forum finde ich lediglich den Hinweis, dass Pushnotifier parseParams nicht ünterstützt.
Kann mir jemand von Euch auf die Sprünge helfen oder geht msg nicht mit Pushnotifier?
Zitat von: Uli am 30 Juni 2021, 16:46:04
Bitte steinigt mich nicht, aber ich benutze bisher pushnotifier um Nachrichten von FHEM auf verschiedene iPhones zu schicken. Jetzt möchte ich pushnotifier gerne in mit msg benutzen, finde aber leider keinerlei Dokumentation dazu. Im Wiki steht nichts von Pushnotifier und hier im Forum finde ich lediglich den Hinweis, dass Pushnotifier parseParams nicht ünterstützt.
Kann mir jemand von Euch auf die Sprünge helfen oder geht msg nicht mit Pushnotifier?
Ich nutze zwar kein pushnotifier aber das sollte eigentlich kein Problem sein:
Im msg-Modul kannst du beliebige Methoden zusätzlich zu den von Haus aus definierten erstellen.
Für pushnotifier wirst du ja ein FHEM-Modul haben und kannst dessen Set-Befehle als Template in das msg-Modul eintragen. Da musst du nur mal genau schauen welche Platzhalter du dabei brauchst. Das steht im Wiki-Artikel oder/und im ersten Post dieses Threads (weis ich nicht mehr genau).
Ich habe damit das echodevice eine zeitlang für push-Nachrichten missbraucht und aktuell nehme ich meine Nextcloud.
Zitat von: balli1187 am 30 Juni 2021, 17:21:26
Ich nutze zwar kein pushnotifier aber das sollte eigentlich kein Problem sein:
Im msg-Modul kannst du beliebige Methoden zusätzlich zu den von Haus aus definierten erstellen.
Für pushnotifier wirst du ja ein FHEM-Modul haben und kannst dessen Set-Befehle als Template in das msg-Modul eintragen. Da musst du nur mal genau schauen welche Platzhalter du dabei brauchst. Das steht im Wiki-Artikel oder/und im ersten Post dieses Threads (weis ich nicht mehr genau).
Ich habe damit das echodevice eine zeitlang für push-Nachrichten missbraucht und aktuell nehme ich meine Nextcloud.
Ich hatte gestern einen Knoten im Gehirn, sorry. Funktioniert genau so, wie es sollte. Danke für den Weckruf...
Hallo Julian,
ich nutze bei mir zu Hause nur Push für die Benachrichtigung und wollte mich erkundigen, ob es inzwischen auch eine zentral zu steuernde Lösung gibt, dass die Push-Nachrichten mit niedriger Priorität im Urlaub nicht nachgesendet werden. Ich hatte vermutet, dass es hierfür ein
msgFwPrioGonePush geben müsste, habe das aber nicht gefunden.
Zitat von: Loredo am 02 November 2015, 10:12:41
Bei Push und E-Mail Nachrichten, die auch als eine solche abgesetzt werden, wird generell davon ausgegangen, dass diese immer zugestellt werden sollen (nach dem Motto "Text ist geduldig" und die Automation wird sich hier schon sicher sein, dass sie wirklich etwas mitzuteilen hat). Das würde ich an dieser Stelle auch beim msg-Kommando nicht aufweichen wollen, sonst würde es unlogisch. Du müsstest also, wenn du als Ursprung keine Audio-Nachricht hast, sondern direkt eine Push-Nachricht verschickst, das in deinem eigenen Code abfangen. Ist in DOIF aber ja ganz einfach.
Ich denke aber nochmal drüber nach, ob man das irgendwie doch auch für Text-Nachrichten sinnvoll mit einbauen kann.
Danke für Tipps und Ideen!
Phillip
Zitat von: Adimarantis am 01 März 2021, 08:46:49
Hallo Loredo,
Für mein Modul "Signalbot" (quasi der Nachfolger von SiSi, welches ja nicht mehr aktiv maintained wird) habe ich eine Anfrage dies mit deinem msg Modul zu verknüpfen:
https://forum.fhem.de/index.php/topic,118370.msg1136305.html#msg1136305
Wenn ich das richtig verstanden habe, brauche ich dafür in mein Modul eigentlich gar nichts zu integrieren, aber eine Default config wie sie für SiSi bereits existiert bei dir könnte Sinn machen.
Letztendlich ist meine Syntax kompatibel zu SiSi, ich biete aber vereinfacht nur die Methode "send" für alle Arten von Nachrichten an.
Lass mich wissen, wenn es sinnvoll wäre auch auf meiner Seite etwas anzupassen,
Gruß,
Jörg
Der Impuls kam vermutlich von mir. Grundsätzlich funktioniert msg mit signalbot. Ich würde jedoch gerne msgContactPush sowohl für Einzelkontakte (bei signalbot mit @ adressiert) als auch für Gruppen nutzen (bei signalbot mit # adressiert). So kann ich zum Beispiel in Kombination mit RESIDENTS diese über eine Gruppe erreichen.
Damit das funktioniert fehlt gefühlt nur wenig.
globalMSG:
msgCmdPush set %DEVICE% send %RECIPIENT% %MSG%
msgContactPush Signalbot:@+49175XXXXXX
=> So erreiche ich den hinterlegten Einzelempfänger.
Naheliegend wäre jetzt ein
msgContactPush Signalbot:#Gruppe
Das wird aber nicht wie gewünscht richtig geparsed und dann auch nicht an Signalbot gegeben. Liegt es vielleicht an der Raute?
Das Log sieht dann wie folgt aus:
2021.09.19 11:56:48 3: msg globalMsg: ID=1632045408.28048.1 TYPE=push ROUTE=Signalbot:#Gruppe STATUS=UNDEFINED PRIORITY=0 TITLE='' 'Testnachricht'Gruß
Chris
Edit: Vielleicht wäre es auch ein Option Signalbot anzupassen, so dass auch Gruppen mit @angesprochen werden, d.h. set signalbot send @#Gruppe. Klingt auf den ersten Blick sogar sauberer
ZitatEdit: Vielleicht wäre es auch ein Option Signalbot anzupassen, so dass auch Gruppen mit @angesprochen werden, d.h. set signalbot send @#Gruppe. Klingt auf den ersten Blick sogar sauberer
Das geht schon (ist sogar dokumentiert):
For compatibility reasons @# can also be used to mark group namesGruß,
Jörg
Zitat von: Adimarantis am 19 September 2021, 13:01:16
Das geht schon (ist sogar dokumentiert):
For compatibility reasons @# can also be used to mark group names
Top, danke und verzeihe mir, dass ich es überlesen habe.
Ich habe mir gerade den Code von MSG angeschaut. Man muss nur in Zeile 1248 die Raute als valides Zeichen in der Regex ergänzen. Dann läuft es (ohne, dass ich Seiteneffekte beurteilen kann).
Hallo,
ich bekomme es irgendwie nicht mit dem Signalbot hin. Bei Email klappt es. Aber beim Singalbot kommt beim Aufruf:
msg push |FHEM| Test
immer die Meldung: STATUS=UNAVAILABLE im Log und ich habe das Gefühl, das der Aufruf Signalbot gar nicht erreicht.
2023.01.13 20:07:44 5: msg: found types=push
2023.01.13 20:07:44 5: msg: found title=FHEM
2023.01.13 20:07:44 5: msg globalMsg: Checking for available routes (triggered by type push)
2023.01.13 20:07:44 5: msg globalMsg: screen route check result: ROUTE_UNAVAILABLE
2023.01.13 20:07:44 5: msg globalMsg: light route check result: ROUTE_UNAVAILABLE
2023.01.13 20:07:44 5: msg globalMsg: audio route check result: ROUTE_UNAVAILABLE
2023.01.13 20:07:44 5: msg globalMsg: push route check result: ROUTE_AVAILABLE
2023.01.13 20:07:44 5: msg globalMsg: mail route check result: ROUTE_UNAVAILABLE
2023.01.13 20:07:44 4: msg globalMsg: Available routes: screen=0 light=0 audio=0 text=1 push=1 mail=0
2023.01.13 20:07:44 5: msg globalMsg: Trying to send message via gateway Signalbot to recipient @+49XXXXXXXX
2023.01.13 20:07:44 5: msg globalMsg: Determined default title:
2023.01.13 20:07:44 5: msg globalMsg: msgSchema: replacing %RECIPIENT% and $RECIPIENT by ''
2023.01.13 20:07:44 5: msg globalMsg: msgSchema: replacing %Signalbot_MTYPE% and $Signalbot_MTYPE by 'send'
2023.01.13 20:07:44 3: msg globalMsg: ID=1673636864.9654.1 TYPE=push ROUTE=Signalbot RECIPIENT=@+49XXXXXXXX STATUS=UNAVAILABLE PRIORITY=0 TITLE='FHEM' 'Test'
2023.01.13 20:07:44 5: msgConfig globalMsg: called function msgConfig_Set()
Der direkte Aufruf in Signalbot mit
set Signalbot send @+49XXXXXXXX Test
funktioniert.
Das MSG-Device sieht folgendermaßen aus:
define globalMsg msgConfig
attr globalMsg userattr msgDialog_evalSpecials:textField-long msgDialog_msgCommand:textField
attr globalMsg comment FHEM Global Configuration for command 'msg'
attr globalMsg group Global
attr globalMsg msgCmdMail { my $d='%DEVICE%';; my $title='%TITLE%';; my $msg='%MSG%';; DebianMail($d,$title,$msg)}
attr globalMsg msgCmdPush set %DEVICE% %Signalbot_MTYPE% %RECIPIENT% %MSG%
attr globalMsg msgContactPush Signalbot:@+49XXXXXXXX
attr globalMsg msgResidentsDev rgr_Bewohner
attr globalMsg msgType text
attr globalMsg room System
attr globalMsg stateFormat fhemMsgState
attr globalMsg verbose 5
# .FhemMetaInternals 1
# FUUID 63bab526-f33f-0756-6ccf-420731ddad0bbd4e
# FVERSION 75_msgConfig.pm:0.269650/2023-01-05
# NAME globalMsg
# NOTIFYDEV TYPE=(Jabber|TelegramBot|yowsup|Signalbot)
# NR 55
# NTFY_ORDER 50-globalMsg
# STATE 0
# TYPE msgConfig
# eventCount 4
# .attraggr:
# .attrminint:
# Helper:
# DBLOG:
# fhemMsgPush:
# myDbLog:
# TIME 1673636864.98384
# VALUE Test
# fhemMsgPushGw:
# myDbLog:
# TIME 1673636864.98384
# VALUE Signalbot:UNAVAILABLE
# fhemMsgPushPrio:
# myDbLog:
# TIME 1673636864.98384
# VALUE 0
# fhemMsgPushState:
# myDbLog:
# TIME 1673636864.98384
# VALUE 0
# fhemMsgPushTitle:
# myDbLog:
# TIME 1673636864.98384
# VALUE FHEM
# fhemMsgState:
# myDbLog:
# TIME 1673636864.98384
# VALUE 0
# fhemMsgStateTypes:
# myDbLog:
# TIME 1673636864.98384
# VALUE push:0
# READINGS:
# 2023-01-13 20:07:44 fhemMsgPush Test
# 2023-01-13 20:07:44 fhemMsgPushGw Signalbot:UNAVAILABLE
# 2023-01-13 20:07:44 fhemMsgPushPrio 0
# 2023-01-13 20:07:44 fhemMsgPushState 0
# 2023-01-13 20:07:44 fhemMsgPushTitle FHEM
# 2023-01-13 20:07:44 fhemMsgState 0
# 2023-01-13 20:07:44 fhemMsgStateTypes push:0
#
setstate globalMsg 0
setstate globalMsg 2023-01-13 20:07:44 fhemMsgPush Test
setstate globalMsg 2023-01-13 20:07:44 fhemMsgPushGw Signalbot:UNAVAILABLE
setstate globalMsg 2023-01-13 20:07:44 fhemMsgPushPrio 0
setstate globalMsg 2023-01-13 20:07:44 fhemMsgPushState 0
setstate globalMsg 2023-01-13 20:07:44 fhemMsgPushTitle FHEM
setstate globalMsg 2023-01-13 20:07:44 fhemMsgState 0
setstate globalMsg 2023-01-13 20:07:44 fhemMsgStateTypes push:0
Ich habe auch schon bei msgCmdPush das gleiche eingegeben, wie für die direkte Eingabe des Signalbots, aber auch hier kommt Status=Unavailable
Grüsse
Marcus
Wie schaut den Dein Signalbot Device aus?
Das sieht so aus:
[code]define Signalbot Signalbot
attr Signalbot DbLogExclude .*
attr Signalbot defaultPeer #Family
attr Signalbot event-on-change-reading .*
attr Signalbot group Netzwerk
attr Signalbot registerMethod Voice
attr Signalbot room Kommunikation
attr Signalbot showtime 1
# FD 19
# FUUID 63b03e41-f33f-0756-8160-385828ecc0605362
# NAME Signalbot
# NOTIFYDEV global
# NR 52
# NTFY_ORDER 50-Signalbot
# STATE 0
# TYPE Signalbot
# VERSION Signalbot:3.11 signal-cli:0.11.4 Protocol::DBus:0.22
# model Raspbian GNU/Linux 11 (bullseye)
# .attraggr:
# .attreocr:
# .*
# .attrminint:
# READINGS:
# 2023-01-12 21:07:51 account +49XXXXXXXX
# 2023-01-12 21:07:51 accountName
# 2023-01-10 20:47:17 fhemMsgPush test
# 2023-01-10 20:47:17 fhemMsgPushGw Signalbot:UNAVAILABLE
# 2023-01-10 20:47:17 fhemMsgPushPrio 0
# 2023-01-10 20:47:17 fhemMsgPushState 0
# 2023-01-10 20:47:17 fhemMsgPushTitle -
# 2023-01-10 20:47:17 fhemMsgState 0
# 2023-01-10 20:47:17 fhemMsgStateTypes push:0
# 2023-01-10 19:53:49 joinedGroups Family
# 2023-01-12 21:07:51 lastError ok
# 2023-01-08 18:31:11 msgAttachment
# 2023-01-08 18:31:11 msgAuth 0
# 2023-01-08 18:31:11 msgGroupName
# 2023-01-08 18:31:11 msgSender Marcus
# 2023-01-08 18:31:11 msgText Test zur�ck
# 2023-01-08 18:31:11 msgTimestamp 08-01-2023 18:31:10
# 2023-01-13 20:13:00 sentMsg Test
# 2023-01-13 20:13:04 sentMsgRecipient Marcus
# 2023-01-13 20:13:04 sentMsgTimestamp 13-01-2023 20:13:01
# 2023-01-08 13:50:48 state 0
# helper:
# accounts 1
# init 1
# multi 1
# signalpath /org/asamk/Signal/_49XXXXXXXX
# version 1104
# accountlist:
# +49XXXXXXXXX
# contacts:
# +49XXXXXXXX XXXXX
# +49XXXXXXXX XXXXX
# +49XXXXXXXX XXXXX
# +49XXXXXXXX
#
setstate Signalbot 0
setstate Signalbot 2023-01-12 21:07:51 account +49XXXXXXXX
setstate Signalbot 2023-01-12 21:07:51 accountName
setstate Signalbot 2023-01-10 20:47:17 fhemMsgPush test
setstate Signalbot 2023-01-10 20:47:17 fhemMsgPushGw Signalbot:UNAVAILABLE
setstate Signalbot 2023-01-10 20:47:17 fhemMsgPushPrio 0
setstate Signalbot 2023-01-10 20:47:17 fhemMsgPushState 0
setstate Signalbot 2023-01-10 20:47:17 fhemMsgPushTitle -
setstate Signalbot 2023-01-10 20:47:17 fhemMsgState 0
setstate Signalbot 2023-01-10 20:47:17 fhemMsgStateTypes push:0
setstate Signalbot 2023-01-10 19:53:49 joinedGroups Family
setstate Signalbot 2023-01-12 21:07:51 lastError ok
setstate Signalbot 2023-01-08 18:31:11 msgAttachment
setstate Signalbot 2023-01-08 18:31:11 msgAuth 0
setstate Signalbot 2023-01-08 18:31:11 msgGroupName
setstate Signalbot 2023-01-08 18:31:11 msgSender Marcus
setstate Signalbot 2023-01-08 18:31:11 msgText Test zur�ck
setstate Signalbot 2023-01-08 18:31:11 msgTimestamp 08-01-2023 18:31:10
setstate Signalbot 2023-01-13 20:13:00 sentMsg Test
setstate Signalbot 2023-01-13 20:13:04 sentMsgRecipient Marcus
setstate Signalbot 2023-01-13 20:13:04 sentMsgTimestamp 13-01-2023 20:13:01
setstate Signalbot 2023-01-08 13:50:48 state 0
Hast Du in den letzten Tagen ein Update von FHEM gemacht? Wenn nicht bitte machen und noch mal probieren.
Heute noch mal ein Update durchgeführt, macht aber leider keinen Unterschied.
msg push Test
2023.01.14 16:46:01 3: msg globalMsg: ID=1673711161.41052.1 TYPE=push ROUTE=Signalbot RECIPIENT=@+49XXXXXXXX STATUS=UNAVAILABLE PRIORITY=0 TITLE='' 'test'
Msg schickt die Nachricht dann an die hinterlegte Email Adresse
Der state Deines Signalbot Devices ist 0
2023-01-08 13:50:48 state 0
Da bedeutet für msg das es aktuell keine Nachrichten zustellen kann.
Das reading "state" wird von Signalbot nicht gesetzt - nur "STATE".
Das ist aber im dump auch "0", was es eigentlich gar nicht geben sollte.
Muss "state" zwingend gesetzt sein? Was erwartet "msg" hier?
Das müsste ich dann in Signalbot noch entsprechend setzen.
Zitat von: Adimarantis am 15 Januar 2023, 12:07:02
Das reading "state" wird von Signalbot nicht gesetzt - nur "STATE".
Das ist aber im dump auch "0", was es eigentlich gar nicht geben sollte.
Muss "state" zwingend gesetzt sein? Was erwartet "msg" hier?
Das müsste ich dann in Signalbot noch entsprechend setzen.
Ich schaue heute Abend einmal genauer, gibt da vieles zur Auswahl. Schreibe Dir dann
Zitat von: Adimarantis am 15 Januar 2023, 12:07:02
Das reading "state" wird von Signalbot nicht gesetzt - nur "STATE".
Das ist aber im dump auch "0", was es eigentlich gar nicht geben sollte.
Muss "state" zwingend gesetzt sein? Was erwartet "msg" hier?
Das müsste ich dann in Signalbot noch entsprechend setzen.
@unavailabilityIndicators = (
"0", "false",
"absent", "disappeared",
"unauthorized", "unavailable",
"unreachable", "disconnected")Das sind alles Werte für state welche als unavailability ausgewertet werden.
Danke. Hab nochmal tiefer gegraben und die unavailbilityIndicators werden mit
ReadingsVal($gatewayDev,"state","present")
abgefragt.
Wenn "state" also nicht existiert, was aktuell bei Signalbot der Fall ist, sollte also der default "present" genommen werden und alles funktionieren.
@aeroschmelz: Warum bei dir state=0 ist, weiss ich nicht. Du kannst aber mal versuchen es mit
deletereading Signalbot state
einfach zu entfernen.
Dann sollte "msg" eigentlich kein Problem mehr haben.
Ich werden trotzdem einbauen das Signalbot "state" in Zukunft entsprechend setzt, da es ja tatsächlich auch einen "disconnected" Status gibt.
Hi Adimarantis,
auf die gleiche Idee kam ich auch schon, leider ändert das aber nichts am Resultat Staus "Unvailable"
2023.01.16 20:33:11 3: msg globalMsg: ID=1673897591.86601.1 TYPE=push ROUTE=Signalbot RECIPIENT=@+49XXXXXXXX STATUS=UNAVAILABLE PRIORITY=0 TITLE='' 'test'
2023.01.16 20:33:12 1: sendemail returned: Jan 16 20:33:12 fhem sendemail[27898]: Email was sent successfully!
2023.01.16 20:33:12 3: msg globalMsg: ID=1673897591.86601.2 TYPE=mail ROUTE=XXXXX.XXXXXXXXX@XXXXXXXX.com STATUS=OK PRIORITY=0 TITLE='System Message' MSG='test'
Direkt nach dem Aufrufen von msg mit
msg push test
taucht "state" dann nach ca. 1 Minute wieder auf und steht auf "0". Ich würde mal davona usgehen, dass msg da irgendetwas macht.
Ich frag mich wer das setzt.
Das Update für Signalbot ist inzwischen online im SVN https://svn.fhem.de/fhem/trunk/fhem/FHEM/50_Signalbot.pm
Versuch doch gleich mal ob das was hilft.
Ich teste das gleich mal. Habe inzwischen mal alle Readings gelöscht und das Backup wieder eingespielt. Mal sehen, ob das noch etwas zusammen mit dem Update bringt ;-)
Aktuell sieht das Device ohne jeglichen Aufruf von msg so aus. State 0 taucht aber schon wieder auf :(
[code]define Signalbot Signalbot
attr Signalbot DbLogExclude .*
attr Signalbot defaultPeer #Family
attr Signalbot event-on-change-reading .*
attr Signalbot group Netzwerk
attr Signalbot registerMethod Voice
attr Signalbot room Kommunikation
attr Signalbot showtime 1
# FD 22
# FUUID 63b03e41-f33f-0756-8160-385828ecc0605362
# NAME Signalbot
# NOTIFYDEV global
# NR 52
# NTFY_ORDER 50-Signalbot
# STATE 0
# TYPE Signalbot
# VERSION Signalbot:3.11 signal-cli:0.11.4 Protocol::DBus:0.22
# eventCount 1
# model Raspbian GNU/Linux 11 (bullseye)
# .attraggr:
# .attreocr:
# .*
# .attrminint:
# READINGS:
# 2023-01-16 21:03:37 account +4961172389577
# 2023-01-16 21:03:37 accountName
# 2023-01-16 21:12:58 joinedGroups Family
# 2023-01-16 21:03:37 lastError ok
# 2023-01-16 21:12:58 sentMsg Hallo FHEM
# 2023-01-16 21:13:12 sentMsgRecipient Marcus
# 2023-01-16 21:13:12 sentMsgTimestamp 16-01-2023 21:12:58
# 2023-01-16 20:46:00 state 0
# helper:
# accounts 1
# init 1
# multi 1
# signalpath /org/asamk/Signal/_49XXXXXXXX
# version 1104
# accountlist:
# +49XXXXXXXX
# contacts:
# groups:
# 236 27 98 194 199 43 56 114 139 232 138 141 135 205 122 32 11 36 194 239 130 51 244 159 46 133 122 64 212 85 242 113:
# active 1
# blocked 0
# name Family
#
setstate Signalbot 0
setstate Signalbot 2023-01-16 21:03:37 account +49XXXXXXXX
setstate Signalbot 2023-01-16 21:03:37 accountName
setstate Signalbot 2023-01-16 21:12:58 joinedGroups Family
setstate Signalbot 2023-01-16 21:03:37 lastError ok
setstate Signalbot 2023-01-16 21:12:58 sentMsg Hallo FHEM
setstate Signalbot 2023-01-16 21:13:12 sentMsgRecipient Marcus
setstate Signalbot 2023-01-16 21:13:12 sentMsgTimestamp 16-01-2023 21:12:58
setstate Signalbot 2023-01-16 20:46:00 state 0
Im Log ist das direkt beim Server Shutdown für den Neustart....
2023.01.16 20:45:58 0: Server shutdown
2023.01.16 20:46:00 2: DbLog myDbLog - stopping SubProcess PID >649< ...
2023.01.16 20:46:00 2: DbLog myDbLog - SubProcess PID >649< stopped
2023.01.16 20:46:11 1: PERL WARNING: Useless use of a variable in void context at ./FHEM/99_myUtilsTelefon.pm line 174.
2023.01.16 20:46:11 1: Including fhem.cfg
2023.01.16 20:46:13 2: DbLog myDbLog - Subprocess >648< initialized ... ready for non-blocking operation
2023.01.16 20:46:14 2: eventTypes: loaded 8278 lines from ./log/eventTypes.txt
2023.01.16 20:46:14 2: Signalbot Define: Signalbot Signalbot
2023.01.16 20:46:15 1: mapleCUL1: Can't open /dev/ttyACM0: Device or resource busy
2023.01.16 20:46:15 2: Switched mapleCUL2 rfmode to HomeMatic
2023.01.16 20:46:18 1: Fritz_Box: Can't connect to 192.168.0.1:1012: Network is unreachable
2023.01.16 20:46:18 1: Fritz_Box: Can't connect to 192.168.0.1:1012: connect to http://192.168.0.1:1012: Network is unreachable
2023.01.16 20:46:18 2: FB_CALLMONITOR (Fritz_Box) - read 402 contacts from Cache
2023.01.16 20:46:22 1: Including ./log/fhem.save
2023.01.16 20:46:24 2: huebridge: autocreate: created 0/0/0 devices (ignored 0/0/18)
2023.01.16 20:46:25 1: usb create starting
2023.01.16 20:46:25 1: CUL: Can't open /dev/ttyACM1: Device or resource busy
2023.01.16 20:46:25 1: CUL: Can't open /dev/ttyACM2: Device or resource busy
2023.01.16 20:46:32 1: usb create end
2023.01.16 20:46:33 0: Featurelevel: 6.1
2023.01.16 20:46:33 0: Server started with 201 defined entities (fhem.pl:26868/2022-12-18 perl:5.032001 os:linux user:fhem pid:645)
2023.01.16 20:46:33 3: DbLog myDbLog - DB connection parameters are stored in SubProcess
Das ist scheinbar auch reproduzierbar bei einem Neustart.
Guten Abend,
mit dem Update funktioniert es. Ich kann jetzt zumindest direkt über das GlobalMsg Device über die dort hinterlegten Attribute eine Nachricht an Signal schicken. Herzlichen Dank für das Update und die Fehlersuche. Ich bekomme es lediglich noch nicht hin an eine Gruppe zu schreiben ;-) Muss man wohl noch mal den Tip von Flachzange ansehen und den Code ändern. @#Gruppe funktioniert standardmäßig nicht.
Danke noch einmal... ;-)
Viele Grüsse
Marcus
Ja, das wäre tatsächlich toll, wenn der Maintainer von msg die Regex um die Raute ergänzen könnte. :D
@Aeroschmelz: was war denn jetzt der Fehler bei Dir? Ich habe es ehrlich gesagt nicht verstanden. Ist das ein Einzelschicksal bei Dir? Bei mir läuft msg mit signalbot nämlich ohne Auffälligkeiten.
Der Status der Push Route bei msg hat immer auf STATUS=UNAVAILABLE gestanden, weil der state des Signalbot Devices auf 0 gesetzt wurde. Das ist bei mir mindestens beim Neustarten passiert. Kannst du mal deine Änderung in der Zeile 1247/1248 hier posten?
Danke.
m/^@?([A-Za-z0-9._]+):([A-Za-z0-9._\-\/@+\#]*):?([A-Za-z0-9._\-\/@+]*)$/
Unterstützung für Signalbot Gruppen kommt mit dem morgigen Update.
Hallo Zusammen
Eine Frage in die Runde zum Thema "msg text" bzw. exakt "msg push".
Ich habe für mich sowohl "msgCmdMail" als auch "msgCmdPush" (per TelegramBot) definiert - jeweils für alle drei Prioritätskategorien (High, Low und "normal").
Die Ansteuerung z.B. msg push [<priority>] funktioiert.
Für Priority=2 wird bei "msg push 2 Meldung" neben der Push Meldung auch eine Mail verschickt.
Das ist gemäß Wiki <
Sendet eine Textnachricht per Push oder E-Mail. Je nach Priorität wird gepusht, gemailt oder beides.> wohl auch korrekt.
Ich nutze in der Definition für "msgCmdPushHigh" und "msgCmdPushLow/msgCmdPush" zwei verschiedene Empfänger um die Prios zu unterscheiden.
Lässt sich "Beides (also Push & Mail gleichzeitig)" über Attribute steuern/unterbinden? Ich habe nichts gefunden und würde es gern auf Push-Only beschränken.
Gruß Ralf
Hallo zusammen,
ich beschäftige mich gerade damit den Messenger gotify selber zu hosten. Das klappt auch ganz gut. Ich würde damit gerne meine Telegrammbots ablösen. Leider gibt es aber für gotify kein FHEM Modul. Habe ich trotzdem eine Möglichkeit gotify über msg zu verwenden und wenn ja wie und welche Attributen müsste ich die konfigurieren damit das funktioniert? Oder kann msg "nur" mit vorhandenen FHEM Modulen kommunizieren?
Ohne Modul kein msg
Zitat von: CoolTux am 19 September 2023, 22:06:55Ohne Modul kein msg
Das stimmt so nicht.
Über Perl-Commandos lässt sich ja so ziemlich alles einbinden.
Ich lasse mich z.Bsp. über mein Nextcloud benachrichtigen und brauche dazu nur ein Curl in einer myUtils-Funktion.
Zitat von: balli1187 am 19 September 2023, 22:36:17Zitat von: CoolTux am 19 September 2023, 22:06:55Ohne Modul kein msg
Das stimmt so nicht.
Über Perl-Commandos lässt sich ja so ziemlich alles einbinden.
Ich lasse mich z.Bsp. über mein Nextcloud benachrichtigen und brauche dazu nur ein Curl in einer myUtils-Funktion.
Ja genau an sowas habe ich auch gedacht. Ich habe auch schon eine myUtils erstellt und das Senden zu einem Kanal funktioniert auch. Was ich aber nicht hinbekomme bzw. nicht in Erfahrung bringen konnte ist wie ich das für mehrere Kanäle also in meinen Fall mit unterschiedlichen Routinen steuern kann.
Aktuell habe das nur so hinbekommen wenn ich im Device globalMsg in der Attribute msgCmdPush die Routine aufrufe.
Wo kann ich es konfigurieren, das ich unterschiedliche Routine aufrufe. In dachte man kann es dann über die Roommates vielleicht lösen aber ich weis ehrlich gesagt nicht was ich wo eintragen muss. Hast du vielleicht einen Tipp für mich?
Danke.
Zitat von: balli1187 am 19 September 2023, 22:36:17Zitat von: CoolTux am 19 September 2023, 22:06:55Ohne Modul kein msg
Das stimmt so nicht.
Über Perl-Commandos lässt sich ja so ziemlich alles einbinden.
Ich lasse mich z.Bsp. über mein Nextcloud benachrichtigen und brauche dazu nur ein Curl in einer myUtils-Funktion.
Und hast Du den msg auch erfolgreich mit Deiner myUtils zum laufen gebracht?
Zitat von: CoolTux am 20 September 2023, 07:01:40Zitat von: balli1187 am 19 September 2023, 22:36:17Zitat von: CoolTux am 19 September 2023, 22:06:55Ohne Modul kein msg
Das stimmt so nicht.
Über Perl-Commandos lässt sich ja so ziemlich alles einbinden.
Ich lasse mich z.Bsp. über mein Nextcloud benachrichtigen und brauche dazu nur ein Curl in einer myUtils-Funktion.
Und hast Du den msg auch erfolgreich mit Deiner myUtils zum laufen gebracht?
Ja das läuft bei mir seit ca. 2 Jahren.
Einziger "Mangel" ist, dass der curl-Aufruf hin und wieder wohl zu lange braucht und msg, dann abbricht. In dem Fall bekomme ich eine Mail als Ersatz.
Hierzu hatte ich auch mal eine Frage in diesem Thread gestellt, die leider unbeantwortet blieb 😉
Hi,
ich habe ein Problem und verstehe entweder die Anleitung falsch oder etwas funktioniert nicht.
Ich lese heraus dass ich ein msgContact auch an einem Device setzen kann.
Ich dachte nun super dann kann ich bei bestimmten Devices einfach ein anderes msgContact setzen und die Meldungen in diesem Device landen dann bei dem dort angegebene Device anstatt im standard Device das in glabalmsg angegeben ist.
Leider zieht immer der default aus dem globalmsg Device aber nicht der im Device gesetzte.
Hier mein Beispiel:
Ich habe am globalMsg Device folgende Config um Ausgaben in einer readingsGroupHistory zu speichern und auf dem Tablet Ui anzuzeigen:
msgCmdScreen {fhem "set %DEVICE% %MSGSHRT%"}
msgContactScreen fhem_messages
Das funktioniert auch. Ich schreibe in einem DOIF folgendes:
msg screen Batterie Entladeleistung nicht mehr begrenzt
und die Message landet in dem fhem_messages Device und in der History.
Möchte ich nun für das DOIF die Meldungen in ein anderes Device schreiben, dachte ich, ich definiere am DOIF Device dann nur:
msgContactScreen fhem_pv_messages
Also hier möchte ich anstatt in fhem_messages in fhem_pv_messages schreiben.
Aber wenn ich msg aufrufe bleibt alles beim alten.
msg screen Batterie Entladeleistung nicht mehr begrenzt
landet es nach wie vor in fhem_messages.
Benutze ich statt dessen das Contact Device direkt im Aufruf also:
msg screen @fhem_pv_messages Batterie Entladeleistung nicht mehr begrenzt
klappt es und die Nachricht landet im fhem_pv_messages Device.
Mache ich etwas falsch? Verstehe ich die Anleitung falsch?
Danke und Gruß,
Stefan
Hallo euch allen,
stehe gerade etwas auf dem Schlauch und bräuchte einen Tipp von euch.
Ich habe das Modul soweit eingerichtet, die Audioausgabe auf meine Alexa und die Nachrichten über Pushover funktionieren auch.
Jetzt habe ich in Pushover mehrere Geräte drin und würde gerne die Nachrichten z.B. gerne nur an ein Gerät senden.
Hier ein list vom Pushover-Device (eingekürzt):
Internals:
FVERSION 70_Pushover.pm:v2.2.0-s27466/2023-04-20
NAME NN_xx_SW_Pushover
STATE connected
TYPE Pushover
READINGS:
2023-12-31 11:03:55 available 1
2023-02-02 03:31:50 devices Markus-Handy,Sabrina-Handy
2023-12-31 11:03:55 state connected
2021-10-22 12:20:35 tokenState valid
2021-10-22 12:20:35 userState valid
und hier ein list vom msgconfig-Device:
Internals:
FVERSION 75_msgConfig.pm:0.269650/2023-01-05
NAME NN_xx_SW_Benachrichtigung
NOTIFYDEV TYPE=(Jabber|TelegramBot|yowsup|Signalbot)
STATE 1
TYPE msgConfig
READINGS:
2023-12-31 12:03:01 fhemMsgAudio Hallo Markus
2023-12-31 12:03:01 fhemMsgAudioGw EG_wz_HW_Amazon_Echo_Dot:OK
2023-12-31 12:03:01 fhemMsgAudioPrio 0
2023-12-31 12:03:01 fhemMsgAudioState 1
2023-12-31 12:03:01 fhemMsgAudioTitle -
2023-12-31 12:16:59 fhemMsgPush @NN_xx_SW_Pushover:Markus-Handy 0 |FHEM| test
2023-12-31 12:16:59 fhemMsgPushGw NN_xx_SW_Pushover:OK
2023-12-31 12:16:59 fhemMsgPushPrio 0
2023-12-31 12:16:59 fhemMsgPushState 1
2023-12-31 12:16:59 fhemMsgPushTitle -
2023-12-31 12:16:59 fhemMsgState 1
2023-12-31 12:16:59 fhemMsgStateTypes push:1
Attributes:
msgCmdAudio set %DEVICE% speak %MSGSHRT%
msgCmdAudioShort set %DEVICE% speak %SHOUTOUT%
msgCmdAudioShortPrio set %DEVICE% speak %SHOUTOUT%
msgContactAudio EG_wz_HW_Amazon_Echo_Dot
msgContactPush NN_xx_SW_Pushover
msgType text
verbose 3
Ich dachte ich kann einzelne Geräte über @NN_xx_SW_Pushover:Markus-Handy 0 |FHEM| test ansprechen, das geht aber so nicht und er schickt es an alle Geräte.
Wie würde denn hier der richtige Befehl zum senden nur an das Gerät Markus-Handy aussehen?
Danke schonmal.
LG Markus