Hallo,
ich habe mir zum Versand von Push-Nachrichten eine Funktion in der 99_myutils gebaut, um die Nachrichten über meine Nextcloud an die Endgeräte zu schicken.
Rufe ich die Funktion direkt auf, funktioniert es bisher tadellos.
Ich habe dann auf das msg-Modul umgestellt, da ich das Jo Zelt toll finde. Leider kommt es damit 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
Moin,
Ich erneuere mei e Anfrage nochmal.
Gibt es niemanden, der mir einen Tip geben könnte?
VG, Stephan
PSUH
Show us....
Zitat von: Beta-User am 02 Februar 2022, 18:47:29
Show us....
Don't know what....
Also nochmal im Ernst: hilft ein List vom msg Modul oder dergleichen hier?
Ich kann/konnte mir nicht vorstellen, wie es hilft und finde es nicht gut einfach alles möglich, so nach dem Motto "hier-such-dir-selbst-was-wichtig-ist", zu posten....
Wie rufst du die Funktion auf?!?
Klingt nach einem Klammer-Problem bei "set magic"?
ich habe im msg-Modul das entsprechende Attribut gesetzt
attr globalMsg msgCmdPush {ncMsg('%DEVICE%','%MSG%')}}
damit wird die die Funktion ncMsg in meiner 99_myUtils aufgerufen und der entsprechenden curl-Befehl ausgeführt.
Das funktioniert auch in 9 von 10 Fällen aber hin und wieder halt nicht und ich bekomme stattdessen eine Mail als Fallback. Ich habe das Gefühl, dass es dem MSG-Modul hin und wieder nicht schnell genug geht und es daher abbricht. Bevor ich das msg-Modul für mich entdeckt habe, habe ich die Funktion immer manuell aufgerufen und hatte das Problem nicht.
Hmm, scheint so zu sein, dass der msg command immer erst checkt, ob die "route" grade "available" ist. Wenn da irgendwas klemmt, könnte es schon sein, dass eben die Ersatzroute genommen wird. Das scheint dann aber kein Timing-Problem zu sein, zumindest war in 75_MSG.pm auf die Schnelle kein InternalTimer zu verorten.
Vielleicht kannst du in deine Routine mal ein paar Log-Einträge reinbasteln damit du siehst, wie lange es ggf. zwischen Aufruf und Ende dauert? Und/oder ggf. den Aufruf an das OS auf nicht blockierend umstellen?
EDIT: Da stimmt auch was mit den Klammern nicht, die letzte "Geschweifte" ist too much, oder?
hm... strange. Die Nextcloud und FHEM laufen auf dem selben Host und ich konnte auch keine Ausfälle in der Nextcloud registrieren, wenn das Phänomen auftrat.
Ich kann den Code leider nicht lesen - dafür reicht mein Perl einfach nicht - aber wie "tief" schaut denn das Modul in die Route? ich habe gerade ein bisschen Problem zu verstehen, wie diese Prüfung abläuft.
Woran macht das Modul fest, dass die Route nicht verfügbar ist? Vielleicht fehlt einfach eine entsprechende Rückmeldung in meiner Perl-Funktion.
Log-Einträge werd ich mal einbauen, vielleicht bringt das neue Erkenntnisse.
Wie stelle ich auf non-blocking um? in meinem Code ist es ein einziger curl-Befehl....
qx(curl -H "OCS-APIREQUEST: true" -u $admin:$pw -X POST https://$url/ocs/v2.php/apps/notifications/api/v2/admin_notifications/$_ -d "shortMessage=$msg");
Der Befehl kommt aus dem Nextcloud-Handbuch.
...habe da auch meine Schwierigkeiten, aber überschlägig betrachtet scheint es eher so zu sein, dass geschaut wird, ob denn die betreffende Definition in FHEM überhaupt vorhanden ist (also z.B. ein TelegramBot-Device existiert oder der Adressat/Resident) und (vielleicht?) ob der Befehl "gültig" ist. Da du direkt nach Perl gehst, dürfte das nicht das Problem sein.
"qx" liefert was zurück (https://perldoc.perl.org/perlop#qx/STRING/), und so wie du es aufrufst, wird es eben erst auf der OS-Ebene komplett abgearbeitet. Kann man unterdrücken, wenn man den Befehl auf der OS-Ebene in den Hintergrund schickt ("&" hinten dran (?)).
Oder eben (so mein Verständnis der Doku hier: https://perldoc.perl.org/functions/exec) "exec" verwendet als alternativen Aufruf eines Systembefehls.