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

rudolfkoenig · 19 Oktober 2015, 18:04:53

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.

Loredo · 19 Oktober 2015, 18:35:43

Ok, danke. Ich nahm an Module und Befehle seien besser voneinander getrennt.

Gruß
Julian

Loredo · 19 Oktober 2015, 18:48:02

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.

rapster · 19 Oktober 2015, 18:50:51

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

rudolfkoenig · 19 Oktober 2015, 19:39:59

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.

Loredo · 22 Oktober 2015, 11:10:42

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?

rudolfkoenig · 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

vbs · 25 Oktober 2015, 12:09:53

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

Loredo · 25 Oktober 2015, 12:13:31

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

vbs · 25 Oktober 2015, 12:50:29

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.

gandy · 28 Oktober 2015, 10:43:19

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.

rudolfkoenig · 28 Oktober 2015, 10:57:44

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?

vbs · 28 Oktober 2015, 12:37:40

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

gandy · 28 Oktober 2015, 12:59:10

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

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.

Loredo · 28 Oktober 2015, 13:43:49

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.