GCM und andFhem - Nachrichtenverlust

[siggi85]

Hallo,

ich lass mir den Status einiger Geräte als Widget auf meinem Android Handy anzeigen. Das passiert anhand folgender Abhängigkeit:
FHEM --> GCM Server --> Android Handy ( andFhem --> Tasker --> Zooper).
Ich lasse also Statusänderungen über die GCM Server and die andFhem Applikation auf meinem Handy senden. Ich fange diese Intents mit Tasker ab und importiere diese als Variablen in die Zooper App um diese Werte in selbst erstellten Widgets darzustellen. Das funktioniert soweit auch ganz gut.

Allerdings kommt ca jede 20. bis 30. Message nicht an. Das Resultat ist, dass bestimmte Werte dann nicht aktualisiert werden. Beispiel: Meine Freundin verlässt das Haus, das Presence Modul geht auf "absent" aber diese Statusänderung kommt nicht auf meinem Telefon an, wodurch sie auf dem Handy weiterhin als "present" angezeigt wird. Wenn man sich nicht 100% auf solche Werte verlassen kann, schmälert das leider deren Nutzen erheblich!

1. Frage: Habt ihr auch ähnliche Erfahrungen? Laut kurzen Recherchen liegt das anscheinend an GCM. Anscheinend existiert kein Puffer für Nachrichten, falls das Android Handy gerade GCM-technisch als "offline" geführt wird. Kann man was dagegen tun? Ggf. eine Art Attribut einfügen ins FHEM GCM Modul über das man steuern kann, dass Zustandsänderungen immer X Mal mit Y Sekunden Abstand gesendet werden?!
Da das Ausbleiben von nachrichten nicht häufig auftritt, sollte man vielleicht schon viele Fehlwerte verhindern können, indem man eine Zustandsänderung innerhalb von 4 Sekunden 2 Mal absendet...

2. Frage: Ist es möglich über das GCM Modul ein erneutes Senden aller Statuswerte zu übermitteln? Ich arbeite mit den Attributen "deviceFilter" und "stateFilter", und wenn ich FHEM neustarte, dann sendet er alle in Frage kommenden States der besagten Devices neu. Allerdings wäre ein "set" Befehl hierfür praktischer. Dann könnnte man diesen alle 30min ausführen und ein mal alle wichtigen States Richtung Handy schicken. Dies wäre zumindest erst mal ein Workaround, da ein fehlerhafter Wert so nicht mehr über mehrere Stunden im Handy angezeigt wird.

[siggi85]

Kann dieses Verhalten jemand bestätigen? Da der amdFhem Entwickler das GCM Modul gebaut hat, vielleicht kann er sich zu diesem Thema mal melden?! 

[siggi85]

Für alle stillen Mitleser: nutze diese Methode nicht mehr. Ich nutze nun "AutoRemote" um Daten von FHEM an meine Android Devices zu senden. Habe aber die Weiterleitungen für die Device States noch nichts umgesetzt, wird noch kommen. Die bisherigen umgesetzten Funktionen scheinen aber hier zuverlässiger zu funktionieren. Zusätzlich kann man hier noch eine TTL mitgeben. Sollte ich aufgrund von kurzzeitiger Nichterreichbarkeit der Devices also die gleichen Probleme bekommen, kann man hier anscheinend nachjustieren.
Da ich hierbei aber paar mehr Dinge per Hand konfigurieren muss, als übers AndFHEM GCM Modul, kann das noch bisschen dauern. Bisschen wenig Zeit momentan.

[hillbicks]

Nur mal kurz als Rueckmeldung fuer Dich, ich hab das Problem auch hin und wieder, kann aber auch nicht sagen unter welchen Bedingungen es dazu kommt. Guter Hinweis mit AutoRemote, hatte ich noch nicht dran gedacht es darueber zu loesen

[siggi85]

Nur mal kurz als Rueckmeldung fuer Dich, ich hab das Problem auch hin und wieder, kann aber auch nicht sagen unter welchen Bedingungen es dazu kommt. Guter Hinweis mit AutoRemote, hatte ich noch nicht dran gedacht es darueber zu loesen

Danke für deine Meldung! Dachte schon ich stand alleine mit dem Problem dar.

[hillbicks]

Hier der Vollstaendigkeit halber noch die Syntax fuer autoremote in fhem

Code Auswählen Erweitern

{system ("curl 'https://autoremotejoaomgcd.appspot.com/sendmessage?key=..................................................................'")}

[hillbicks]

Das ist so aber auch nicht ideal wie ich grade festgestellt habe. Hatte den Aufruf in einem notify drin und grade einen kurzen Internet Ausfall der dann dafuer gesorgt hat das fhem ueberhaupt gar nicht mehr reagiert hat da er offensichtlich ewig und 3 Tage auf einen Timeout wartet. Das war wenigstens dafuer gut das ich jetzt weiss warum meine Wifi Lampen teilweise 10 Sekunden gebraucht haben bis sie an oder aus gingen, der notify an gcmsend war offensichtlich schuld.

@siggi85: Wie hast Du den Aufruf von autoremote in fhem denn geloest?

[siggi85]

@siggi85: Wie hast Du den Aufruf von autoremote in fhem denn geloest?

Ich habe das auch nur über einen curl Aufruf wie du definiert.
Habe eben mal in die Manpage geschaut, am besten man benutzt im Curl Aufruf die option

Code Auswählen Erweitern

--connect-timeout <seconds>. Dann kann man den Timeout ferstlegen, falls Internet gerade streikt. Hatte ich bisher noch nicht, daher bin ich noch nicht auf diese Idee gekommen.
Wenn du in dem Notify erst die Lampen schaltest und dann per curl die Information an ein AutoRemote Device sendest, sollte der curl Aufruf am besten am Schluß stehen.
Hast du die Logmeldungen von Curl bereits abgestellt? Ich habe nur gesehen, dass Curl mir jedes Mal mehrere Zeilen output ins Log schreibt. Habe bisher aber kaum was an FHEM gemacht, kam also noch nicht dazu.  Nur für den Fall, falls du dich erst wie ich wunderst, was dir diese komischen Zeilen ins Log schreibt.

[hillbicks]

Du meinst das mit dem return value -1?

Ja, da habe ich mich schon gewundert und es bisher aber nicht wegbekommen, nicht einmal mit --fail --silent > /dev/null.

Ich werde auch nochmal damit experimentieren den notify nochmal auszulagern und einen seperaten dafuer zu bauen um den Verzug beim schalten von mehreren Geraeten weiter zu verringern.

In jedem Fall bin ich schonmal heilfroh nicht mehr 10 Sekunden warten zu muessen bis das Licht angeht, das war schon sehr nervig

[siggi85]

Du meinst das mit dem return value -1?

Ja, da habe ich mich schon gewundert und es bisher aber nicht wegbekommen, nicht einmal mit --fail --silent > /dev/null.

Ich werde auch nochmal damit experimentieren den notify nochmal auszulagern und einen seperaten dafuer zu bauen um den Verzug beim schalten von mehreren Geraeten weiter zu verringern.

In jedem Fall bin ich schonmal heilfroh nicht mehr 10 Sekunden warten zu muessen bis das Licht angeht, das war schon sehr nervig

Ich weiß nicht mehr genau welche Zeile/n das bei mir sind/waren, aber ich habe kurzfristig die Ausgabeumleitung

Code Auswählen Erweitern

> /dev/null 2>&1 hinter dem curl eingebaut. Keine Ahnung ob es das Problem gelöst hat, hatte keine Zeit mehr das zu verifizieren als ich es konfiguriert habe. 
Hierbei wird der STDOUT und der STDERR nach /dev/null umgeleitet.

[hillbicks]

Die Zeile taucht immer noch auf, ist mir jetzt aber auch egal. Die eine mehr oder weniger macht den Braten auch nicht fett.