Modul für Pushover

[Garbsen]

Das ist schon klar, meine konkrete(re)n Fragen:
Kennt jemand dieses Verhalten?
Funktioniert bei anderen glance ohne dieses Verhalten?
Kann es an der Syntax der Meldung liegen oder müssen noch Attribute gesetzt werden?

Hier noch ein List

Code Auswählen Erweitern

Internals:
   APP_TOKEN  .....
   DEF        ......  .....
   NAME       pushmsg
   NR         687
   STATE      connected
   TYPE       Pushover
   USER_KEY   ......
   VALIDATION_TIMER 1486405047.414
   Readings:
     2017-02-06 11:35:44   apiLimit        7500

     2017-02-06 13:17:27   apiRemaining    7456

     2017-02-06 11:35:44   apiReset        1488348000

     2017-02-06 10:29:21   available       1
     2017-01-12 20:47:50   devices         ipad,iphone-K-H
     2017-01-07 20:47:50   group           0
     2017-02-06 12:14:14   lastAction      -
     2017-02-06 13:17:27   lastDevice      ipad,iphone-K-H
     2017-02-06 12:14:14   lastMessage     1
     2017-02-06 12:14:14   lastPriority    0
     2017-02-06 13:17:27   lastRequest     aa4c7304a2473182fd33ef8ddcd891d4
     2017-02-06 13:17:27   lastResult      ok
     2017-02-06 11:43:42   lastSubtext     Some more info
     2017-02-06 13:17:27   lastText        2
     2017-02-06 13:17:27   lastTitle
     2017-02-06 10:29:21   state           connected
     2017-01-07 20:47:50   tokenState      valid
     2017-01-07 20:47:50   userState       valid
Attributes:
   room       Allgemein,Pushover

[Klaus.A]

Das Problem mit der Apple Watch habe ich auch: Die Pushover Messages aus FHEM kommen alle (!) auf dem iPhone zuverlässig an, aber auf der Watch nur zufallsbedingt bzw. mit erheblicher Verzögerung. Das sieht aber nicht nach FHEM aus, sondern wie ein Apple-Watch OS Problem (seit Watch OS 3.1.3 oder dem neuesten iOS Update).

Sonderbar ist nur das ich mit der alten Syntax bei Aufruf aus einem Notify (set FHEM ...) korrekte Ergebnisse habe, bei Aufruf aus einem DOIF aber plötzlich die Probleme aufgetreten sind.
Da aber auf dem iPhone alles zuverlässig ankommt, kann die Ursache nicht in FHEM bzw. dem Pushover Modul liegen.

Gruß, Klaus

[Thyraz]

Bei mir werden die Pushnachrichten auch nicht an die Watch weitergeleitet.
Verstehe aber nicht warum, normal spiegelt die Watch doch einfach die Notifications vom iPhone.

Man merkt auch den Unterschied:
Wenn normal (z.B. bei anderen Apps) bei entsperrter Watch eine Nachricht reinkommt, bleibt das iPhone stumm und vibriert nicht.
Dafür "tippt" einen die Watch  an.

Bekomme ich jetzt aber PushNotifications von PushOver, vibriert direkt das Handy und nicht die Watch.
Wusste gar nicht, dass das technisch überhaupt so möglich ist, solang an in der Watch App für die jeweilige Anwendung "iPhone Benachrichtigungen spiegeln" aktiv hat. :-/

Bei allen anderen Apps klappts...

[peterk_de]

Das Problem mit der Apple Watch habe ich auch: Die Pushover Messages aus FHEM kommen alle (!) auf dem iPhone zuverlässig an, aber auf der Watch nur zufallsbedingt bzw. mit erheblicher Verzögerung. Das sieht aber nicht nach FHEM aus, sondern wie ein Apple-Watch OS Problem (seit Watch OS 3.1.3 oder dem neuesten iOS Update).

Sonderbar ist nur das ich mit der alten Syntax bei Aufruf aus einem Notify (set FHEM ...) korrekte Ergebnisse habe, bei Aufruf aus einem DOIF aber plötzlich die Probleme aufgetreten sind.
Da aber auf dem iPhone alles zuverlässig ankommt, kann die Ursache nicht in FHEM bzw. dem Pushover Modul liegen.

Gruß, Klaus

Ich reihe mich hier einmal ein, genau das gleiche Problem. Manche Benachrichtigungen kommen bis zur Watch durch, manche nicht, auf dem iPhone klappt es währenddessen super. WatchOS/ IOS sind aktuell.

Was ich bez. FHEM herausgefunden habe: Alte vs. neue Modul-Syntax kann ich definitiv ausschließen, es klappt bei beiden mal ja und mal nicht. Ich hab jetzt schon viel probiert und es scheint wirklich rein zufällig zu sein. Selbst die identische Nachricht (selber Titel, selber text) klappt manchmal, manchmal aber nicht. Und interessant ist auch, dass es bei anderen Apps (z.B. Telegram, Threema etc.) sehr zuverlässig funktioniert.

[farin1337]

Moin,

erst einmal vielen Dank für das tolle Modul es funktioniert fast alles wie gewünscht. Ich habe nur ein Problem mit der Callback-Funktion. Das Reading "cbAck_*" bleibt bei mir dauerhaft auf "0", obwohl ich das Atrribut "callbackUrl" gesetzt habe. Habe "verbose" auf 5 gesetzt und bekomme auch eine Bestätigung im Logfile, dass der entsprechende User die Pushover-Meldung acknowledged hat:

2017.03.17 12:24:37 4: Pushover pushmsg callback: link='/pushCallback1' URI='receipt=******&acknowledged=1&acknowledged_at=1489749876&acknowledged_by=******&acknowledged_by_device=farin'

Dennoch bleibt das Reading cbAck_* auf 0. Meine Callbackurl sieht folgendermaßen aus:
   
https://api:passwort@webhook.meinedomain.de/webhook/pushCallback1

Ich arbeite hier mit einem Apache reverseproxy und kann z.B. auch erfolgreich per HTTP readings setzen. Ich bin unter anderem nach folgender Anleitung gegangen: https://wiki.fhem.de/wiki/Anwesenheitserkennung#Webhook_weiter_absichern
Ich habe auch schon probiert das ganze ohne Authentifizierung zu machen, jedoch hat auch dies nicht den gewünschten Erfolg gebracht. Hat jemand vllt. noch eine Idee dazu?

Gruß
Farin1337

[Loredo]

An alle Apple Watch Glance Ausprobierer:
Ich muss euch nochmals mit der Nase auf ein Zitat in der API Dokumentation stoßen (was ich hier schon öfters getan habe):

Please note that our Glances API is currently in beta and may be subject to change.

und

These pieces of data should be low-priority since they often cannot get updated in real-time or very frequently, and they must be concise because they are often viewed on small screens such as a watch face.

und

Pushing data to the Apple Watch must be done infrequently, or WatchOS will stop processing updates due to battery concerns. Please note that Pushover does not do any throttling of your data updates, so it is up to you to throttle your Glances API calls. When sending data to the Apple Watch, we recommend at least 20 minutes between each call. If you have pushed too much data and WatchOS stops processing updates, this resets overnight.

Remember, the data presented through our Glances API should be low-priority (something to be occasionally glanced at). If you need to send data that is delivered right away and presented to the user, use our Messages API.

Die korrekte Schlussfolgerung ist also, dass ihr beim testen einfach zu viel und oft updated und die Verzögerungen in erster Linie dadurch entstehen, weil die Apple Watch API nicht für dauerhaftes Echtzeitupdate ausgelegt ist, um Strom zu sparen. Das ist nichts, was die Pushover App ändern könnte (oder gar das FHEM Modul, wie peterk_de richtig analysiert).

[Loredo]

Ich habe nur ein Problem mit der Callback-Funktion. Das Reading "cbAck_*" bleibt bei mir dauerhaft auf "0", obwohl ich das Atrribut "callbackUrl" gesetzt habe. Habe "verbose" auf 5 gesetzt und bekomme auch eine Bestätigung im Logfile, dass der entsprechende User die Pushover-Meldung acknowledged hat:

2017.03.17 12:24:37 4: Pushover pushmsg callback: link='/pushCallback1' URI='receipt=******&acknowledged=1&acknowledged_at=1489749876&acknowledged_by=******&acknowledged_by_device=farin'

Gibt es denn Readings, die im Namen den Wert von "receipt" beinhalten? Da wäre ein "list" und ein nicht geschwärztes Log interessant.

[choenig]

Hi,

ich gehöre auch zu den "Apple Watch Glance Ausprobierern" .

Es ist zur Zeit nicht nur umständlich möglich, "count" und "percent" wieder auf '0' zu setzen.

Folgendes setzt zwar "percent" auf '25', aber "count" bleibt unverändert:

Code Auswählen Erweitern

set Pushover glance count=0 percent=25

Folgendes ist der Workaround, mit dem ich es doch schaffe, "count" auf 0 zu setzen:

Code Auswählen Erweitern

set Pushover glance count="-0" percent=50

Durch kontinuierliches ändern des Percent-Wertes kann ich sicherstellen, dass die Änderungen auf der Applewatch ankommen und nicht durch das WatchOS blockiert werden.

Nach einem kurzen Blick in den Pushover-Code würde ich davon ausgehen, dass folgendes bei '0' nicht funktioniert:

Code Auswählen Erweitern


    $values{count}   = $h->{count}   ? $h->{count}   : undef;
    $values{percent} = $h->{percent} ? $h->{percent} : undef;


Meine Perl-Fähigkeiten sind aber nicht gut genug, um hier sicher zu sein und einen Fix vorzuschlagen.

Vielen Dank im Voraus
LG
Christian

[Loredo]

Es ist zur Zeit nicht nur umständlich möglich, "count" und "percent" wieder auf '0' zu setzen.

Fair enough. Habe einen Patch dazu eingecheckt.

[farin1337]

Gibt es denn Readings, die im Namen den Wert von "receipt" beinhalten? Da wäre ein "list" und ein nicht geschwärztes Log interessant.

Danke für deine Antwort und sorry, dass ich mich erst jetzt melde. Das Reading "cb_*" hat nur den Wert von receipt. Unter "list" finde ich keine Reading, die im Namen den Wert von "receipt" beinhalten. Ich habe das ganze bis jetzt nur mit einem Android Client probiert, werde es heute Abend einmal mit einem Apple Gerät ausprobieren. Anbei das entsprechende Logfile:

Code Auswählen Erweitern


2017.03.20 12:46:55 4: Pushover pushmsg: RCV messages.json/title=Notfall&message=Sicherheits-Alarm im Wohnzimmer.&device=farin&priority=2&sound=siren&retry=30&expire=120&callback=https://user:passwort@domain.de/webhook/pushCallback1&token=<MEINTOKEN>&user=<MEINUSER>
2017.03.20 12:46:55 5: Pushover pushmsg: RES messages.json/title=Notfall&message=Sicherheits-Alarm im Wohnzimmer.&device=farin&priority=2&sound=siren&retry=30&expire=120&callback=https://user:passwort@domain.de/webhook/pushCallback1&token=<MEINTOKEN>&user=<MEINUSER>
{"receipt":"rtj7cf11ufzgb7bogypv8h7q3j7vxg","status":1,"request":"304ccd84-3620-4145-8c18-779f2859eb21"}

2017.03.20 12:48:19 4: Pushover pushmsg callback: link='/pushCallback1' URI='receipt=rtj7cf11ufzgb7bogypv8h7q3j7vxg&acknowledged=1&acknowledged_at=1490010496&acknowledged_by=uirpG2u*******&acknowledged_by_device=farin'


Hier die entsprechenden Readings:
cbAck_1490010534  0                                                     2017-03-20 12:46:55
cbDev_1490010534 farin                                                 2017-03-20 12:46:55
cbMsg_1490010534 Sicherheits-Alarm im Wohnzimmer. 2017-03-20 12:46:55
cbPrio_1490010534 2                                                      2017-03-20 12:46:55
cbTitle_1490010534 Notfall                                              2017-03-20 12:46:55
cb_1490010534   rtj7cf11ufzgb7bogypv8h7q3j7vxg       2017-03-20 12:46:55
lastRequest 304ccd84-3620-4145-8c18-779f2859eb21  2017-03-20 12:46:55

Gruß
Farin

[Loredo]

Danke für deine Antwort und sorry, dass ich mich erst jetzt melde. Das Reading "cb_*" hat nur den Wert von receipt. Unter "list" finde ich keine Reading, die im Namen den Wert von "receipt" beinhalten.

Ok, ich denke ich konnte da was finden und habe einen Patch eingecheckt.

[Loredo]

Ab morgen ist es außerdem möglich, dass man die Aufforderung zur Bestätigung bei Priorität 2 Nachrichten vorzeitig beenden kann.
Siehe auch https://forum.fhem.de/index.php/topic,69281.0.html

[l2r]

ist das dann auch über den msg-Befehl bedienbar oder muss es über Optionen gelöst werden?

gruß Michael

[Loredo]

Ja wird über die Advanced Options unterstützt.

[l2r]

Ok, danke schau ich mir dann morgen mal an.

Gruß Michael


Gesendet von iPhone mit Tapatalk Pro