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

[l2r]

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

[hartenthaler]

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.

[Loredo]

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.

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

[l2r]

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

[Loredo]

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.

[l2r]

aktuell nicht, aber du hast mich da grade auf ne idee gebracht.

Danke!

[DeeSPe]

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:

FATAL 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

[DeeSPe]

Hab den Fehler jetzt doch wieder und habe keine Ahnung wo er her kommt.

msg audio test

FATAL ERROR: Message NOT sent. No gateway device was available.

Hmmmm....

Gruß
Dan

[Loredo]

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

[Loredo]

Ü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

[DeeSPe]

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:

Code Auswählen Erweitern

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

[DeeSPe]

Hab's jetzt gefunden, dank verbose.

2016.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!

[DeeSPe]

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.

[Loredo]

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.

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

Code Auswählen Erweitern


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.

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.

P.S. Die Erklärung der ganzen Attribute hat mich dann übrigens 12 Seiten lesen dieses Beitrag gekostet!

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:

Code Auswählen Erweitern

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.

[DeeSPe]

Für Audio habe ich das Schema nun so definiert:

Code Auswählen Erweitern

{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?

Code Auswählen Erweitern

msg audio! Gute Nacht!

Danke.

Gruß
Dan