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

[justme1968]

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

[rudolfkoenig]

@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.

[Loredo]

zaehlt 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.

[kumue]

Was ist zu tun, wenn beim Versuchen den msg zu Befehl zu verwenden, folgende Meldung kommt?

Code Auswählen Erweitern

Unknown command msgconfig, try help.

Bekomme auch diese Meldung. 

[kumue]

nach einem

Code Auswählen Erweitern

reload 75_MSG gings wieder

[Loredo]

Bekomme auch diese Meldung. 

Der Befehl lautet auch "msg", nicht "msgconfig"

[marvin78]

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.

[kumue]

Der Befehl lautet auch "msg", nicht "msgconfig"

Schon klar, ich hatte auch msg eingegeben und nicht msgconfig...

[SirUli]

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

[JT089]

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

[Amenophis86]

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.

[Loredo]

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.

[Amenophis86]

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

[Loredo]

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

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.

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:

Code Auswählen Erweitern


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:

Code Auswählen Erweitern


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.

[Amenophis86]

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