Modul für Pushover

[Loredo]

das ist korrekt


Sent from my iPhone using Tapatalk

[steffisb]

kann mir da mal jemand helfen? http://forum.fhem.de/index.php/topic,42030.msg343624.html#msg343624

[steffisb]

Der Test hat funktioniert:

Code Auswählen Erweitern

define pushovertest at +*00:01:00 {\
  my $temp=ReadingsVal("tempinnen", "temperature", "0");;\
  fhem("set Pushover msg 'Temperatur' 'Außentemperatur betraegt $temp Grad' '' 0 '' ");;\
}

Jetzt möchte ich gerne eine Push für die Türklingel erhalten:

Code Auswählen Erweitern

define FS20_19e600 FS20 0000 00
attr FS20_19e600 IODev CUL1
attr FS20_19e600 room Flur
define FileLog_FS20_19e600 FileLog ./log/FS20_19e600-%Y.log FS20_19e600
attr FileLog_FS20_19e600 logtype text
attr FileLog_FS20_19e600 room FS20
define FS20_19e601 FS20 0000 01
attr FS20_19e601 IODev CUL1
attr FS20_19e601 room Flur
define FileLog_FS20_19e601 FileLog ./log/FS20_19e601-%Y.log FS20_19e601
attr FileLog_FS20_19e601 logtype text
attr FileLog_FS20_19e601 room FS20


[Benni]

Hallo Loredo,

ich habe seit längerem mal wieder ein Update durchgeführt.
Jetzt habe ich leider ein kleines Problem mit dem Pushover-Modul.

Normalerweise schicke ich direkt beim Start von FHEM eine Pushover-Message auf mein Handy, um mir genau diesen Sachverhalt mitzuteilen. Allerdings steht bei mir nach einem FHEM-Neustart das Pushover-Device erst mal auf disconnected und geht erst nach den ca. 10 Minuten Wartezeit auf connected, oder wenn ich die DEF "modifiziere"

Dann allerdings funktioniert alles so, wie es soll.

Eine Idee, wo hier das Problem liegt?

Danke und Gruß
Benni.

[Loredo]

Nach einem Neustart wartet das Modul ein paar Sekunden, bis es die Pushover Verbindung prüft und der Status dann auf connected wechselt. Danach wird zyklisch geschaut, ob die Zugangsdaten noch stimmen.
Nachrichten können allerdings auch im Status disconnected verschickt werden. Es ist dann aber lediglich ein Versuch, der eben bei zB abgelaufenen Zugangsdaten oder einer fehlerhaften Netzwerkverbindung nicht ausgeführt werden kann.

Ich selbst schicke auch eine Pushover Nachricht nach einem Neustart über ein Doif, das funktioniert hier problemlos. Allerdings macht es Sinn, den Versand auch hier etwas zu verzögern, weil während des Starts doch erhebliche Vorgänge laufen können und man die Last so besser verteilt. Die Verzögerung ist ja bei Doif ganz einfach, aber auch ein Watchdog sollte gehen.


Gruß
Julian

[Benni]

Ich hab jetzt auch mal noch eine Verzögerung von 15 Sekunden eingebaut, allerdings mit einem simplen AT.
Jetzt klappt dann das Versenden beim FHEM-Startup auch bei mir wieder

Danke dir für den Hinweis!

Gruß Benni.

PS: Irgendwann muss ich mich auch mal noch mit DOIF beschäftigen

[Loredo]

Ich habe in einer erweiterten Version die API Nutzung optimiert. Dies wurde notwendig, da die Pushover Betreiber mich diesbezüglich angeschrieben haben (u.a. weil die Zugangsdaten zu häufig validiert würden).


Beiliegende Version sollte bitte getestet werden, bevor ich sie ins SVN einchecke. Feedback dazu dann gerne hier.


Was hat sich geändert:

   
• User key und App token werden nach (re)define reprüft, nicht jedoch nach einem Neustart, solange diese zuvor bereits erfolgreich geprüft wurden
• Bei falschen Userdaten weden diese nicht mehr automatisch/zyklisch erneut geprüft. Erst nach einem Modify werden die Daten erneut geprüft, da angenommen wird, dass diese dann korrigiert wurden
• Die Rückmeldung bei Senden einer Nachricht, ob ein Token oder Key nicht mehr gültig ist, wird ausgewertet
• Es lassen sich keine Nachrichten verschicken, wenn Token oder Key nicht erfolgreich geprüft wurden
• die API Limits werden ausgelesen und beachtet; der Status kann dazu auf "limited" wechseln
• Nachrichten lassen sich trotz Status "disconnected" oder "limited" senden (das Reading "available" ist dann auf 0). Es ist zwar anzunehmen, dass die Nachricht nicht erfolgreich verschickt werden kann, es bleibt aber Sache des Users das Reading "available" vor einem Versand entsprechend zu beachten oder nicht (--> hier ließen sich noch mehr API Calls einsparen, ich habe jedoch erstmal zu Gunsten der FHEM Community darauf verzichtet)
• Wenn innerhalb von 6h keinerlei Nachricht verschickt wurde, wird einmalig geprüft, ob die Zugangsdaten noch gültig sind. Ansonsten reicht das erfolgreiche versenden einer Nachricht aus.

[P.A.Trick]

Code Auswählen Erweitern

2015.11.01 10:59:19.114 3: set pushmsg msg 'fhem' '10:59:19: [info] NAS Platten aktiv!' '' 0 '' : Unable to send message: User key is invalid
2015.11.01 10:59:19.284 3: [sendmsg] - [MSG] 10:59:19: [info] NAS Platten aktiv!


Klappt bei mir nicht!

[Loredo]

Das spricht zunächst einmal dafür, dass der User Key von der Pushover-API als nicht korrekt zurückgemeldet wurde (siehe auch Reading "lastResult").
Es scheint als wenn ältere User Keys durch die API nicht immer validiert werden können. In diesen Fällen hat es Leuten hier schon geholfen einen neuen User Key zu generieren.


Du kannst auch mal mit verbose=5 mitloggen was passiert.

[Loredo]

@P.A.Trick:Ich vermute der Fehler kommt bei dir daher, dass du FHEM nicht neu gestartet hast, nachdem du das Modul eingespielt hast. Dadurch gibt es die neuen Readings noch nicht und der Default ist, dass dann angenommen wird, dass der User key noch nicht geprüft wurde bzw. somit nicht korrekt ist.


Da ich sonst keine Beschwerden hier höre, checke ich das Modul nun ein.

[Loredo]

An alle Nutzer:


Das Update sollte ab morgen möglichst von jedem zeitnah eingespielt werden, um den Pushover Betreibern entgegen zu kommen und weniger Last auf deren Servern zu erzeugen.

[Motivierte linke Hände]

Ist die Community der Nutzer hier so groß, dass das tatsächlich einen merkbaren Unterschied auf deren Servern macht?

Beeindruckt, Christian

[Loredo]

Ist die Community der Nutzer hier so groß, dass das tatsächlich einen merkbaren Unterschied auf deren Servern macht?

Offenbar ist dem so.

[P.A.Trick]

@P.A.Trick:Ich vermute der Fehler kommt bei dir daher, dass du FHEM nicht neu gestartet hast, nachdem du das Modul eingespielt hast. Dadurch gibt es die neuen Readings noch nicht und der Default ist, dass dann angenommen wird, dass der User key noch nicht geprüft wurde bzw. somit nicht korrekt ist.


Da ich sonst keine Beschwerden hier höre, checke ich das Modul nun ein.

Hm das kann sein! Ich hatte nur ein reload gemacht ;-/ Ok das wird dann morgen sicher funktionieren!

[Loredo]

Ich habe gerade ein Update eingecheckt, welches es ermöglicht, dass man als Device auch einen User oder Group Key angeben kann. Dieser wird dann statt dem Key aus dem define verwendet.
Somit muss man nicht zwangsläufig für jeden einzelnen Empfänger ein eigenes Pushover Device anlegen, sondern kann ein Device anlegen und alle damit adressieren. Wer dann trotzdem noch ein tatsächliches Device angeben will, kann es mit Doppelpunkt abgetrennt an den User Key anhängen.

Beispiele:

Code Auswählen Erweitern


# senden an einen anderen User/Group Key als im Define vom Gerät "Pushover"
set Pushover msg 'System Message' 'Testnachricht' 'uAJYUbbFqwsm8xhZgvktKkh9YgwTRJ' 0 ''

# senden an ein spezielles Gerät des Nutzers
set Pushover msg 'System Message' 'Testnachricht' 'uAJYUbbFqwsm8xhZgvktKkh9YgwTRJ:Geraetename' 0 ''


Um trotzdem nicht überall in seinen Automationen den User Key mehrfach zu hinterlegen (und dort ggf. pflegen zu müssen), empfiehlt es sich einmal einen Blick auf das msg-Kommando zu werfen und den Userkey dort in einem msgContactPush Attribut in der Form "Pushover:uAJYUbbFqwsm8xhZgvktKkh9YgwTRJ" zentral zu hinterlegen.