Modul für Pushover

[FHEMAN]

Ich habe nach einigen probieren, meine ganzen \n durch ein <br> ersetzt. Damit funktioniert es bei mir problemlos.

Guten Rutsch
arokh12

Ah gut, vielen Dank. Das funktioniert bei den Description Texten (nicht im Titel, was aber ok ist).

[arokh12]

Ah gut, vielen Dank. Das funktioniert bei den Description Texten (nicht im Titel, was aber ok ist).

Ah, gut zu wissen. Das hab ich noch nicht ausprobiert, ob das im Titel anders ist.

arokh12


Gesendet von iPad mit Tapatalk

[Loredo]

Daran hänge ich auch gerade. Hast du eine Lösung für den Zeilenumbruch gefunden?

Funktioniert hier wie erwartet:

Code Auswählen Erweitern


set Pushover msg title=Test zeile1\nzeile2


So recht verstehe ich nicht, warum der Description Text nicht konsequenterweise auch einen Parameter bekommt.

Weil es einfacher ist und sich der Nachrichtentext bereits durch den Setter "msg" impliziert.

Denn sowie man im Titel ein Leerzeichen angibt - ohne diesen in einfache Anführungszeichen zu setzen (wie im Beispiel oben) - rennt man in den nächsten Fehler.

Works as designed/intended. Diese Form der Notation ist ja FHEM übergreifend bei mehreren Modulen im Einsatz (und teilt sich auch eine Code Basis dafür). Ohne Anführungszeichen kann natürlich nicht erraten werden, wo der Inhalt z.B. für den Titel aufhören soll und wo der Nachrichtentext beginnt. Den Nachrichtentext explizit mit z.B. text="Zeile1\nZeile2 mit noch mehr Text" anzugeben hilft da auch nicht zu verstehen, dass Anführungszeichen unerlässlich bleiben. Dennoch bleibt die neue Notation flexibler und einfacher als zuvor, beispielsweise weil die Reihenfolge egal ist.

Das funktioniert bei den Description Texten (nicht im Titel, was aber ok ist).

Die Pushover API selbst unterstützt auch keine mehrzeiligen Titel. Ist IMHO auch wenig sinnvoll; Romane gehören in den Beschreibungstext.

[FHEMAN]

Funktioniert hier wie erwartet:

Code Auswählen Erweitern


set Pushover msg title=Test zeile1\nzeile2


Funktioniert bei mir hier auch aktuell. Keine Ahnung, was wir da falsch gemacht haben. Dann kann ich meine Ersetzungsroutinen wieder ausbauen.

Weil es einfacher ist und sich der Nachrichtentext bereits durch den Setter "msg" impliziert.

Im ersten Moment erschien es mir auch so. Aber übersichtlich ist das mMn nicht. So gesehen könnte der Setter "msg" dann ebenfalls eingespart werden. (Oder als Default gesetzt werden, sofern es noch andere gibt/geben wird)

Works as designed/intended. Diese Form der Notation ist ja FHEM übergreifend bei mehreren Modulen im Einsatz (und teilt sich auch eine Code Basis dafür). Ohne Anführungszeichen kann natürlich nicht erraten werden, wo der Inhalt z.B. für den Titel aufhören soll und wo der Nachrichtentext beginnt. Den Nachrichtentext explizit mit z.B. text="Zeile1\nZeile2 mit noch mehr Text" anzugeben hilft da auch nicht zu verstehen, dass Anführungszeichen unerlässlich bleiben. Dennoch bleibt die neue Notation flexibler und einfacher als zuvor, beispielsweise weil die Reihenfolge egal ist.

Genau das meine ich ja: Um nicht raten zu müssen und um es übersichtlicher zu halten, wäre die konsequente Nutzung von Anführungszeichen aus meiner Sicht sinnvoll. Dass es an anderer FHEM Stelle ähnlich läuft, macht es ja nicht besser.

//edit: habe gerade gesehen, dass du die FHEM Referenz diesbezüglich angepasst hast. Ich denke, das hilft ungemein.

Die Pushover API selbst unterstützt auch keine mehrzeiligen Titel. Ist IMHO auch wenig sinnvoll; Romane gehören in den Beschreibungstext.

Vollkommen ok, wie gesagt.

Mit ging es mit meinen Hinweisen nur darum, den ein oder anderen Hilfepost hier zu vermeiden.

[Loredo]

Ich habe gerade eine neue Version eingecheckt und darin auch die CommandRef mit der neuen Syntax und dem Support für die Glances erweitert.
Man kann sich jetzt entscheiden auch den Nachrichtentext explizit als Option mit anzugeben, die Beispiele in der CommandRef machen das deutlich. Somit hat jeder die Wahl es sich einfach oder kompliziert zu gestalten.


Ab morgen per Update.

[nsu1200c]

Moin,

ich habe das Modul auch seit einiger Zeit ohne Probleme z.B. zur pushen der Wettervorhersage als 2maligen push pro Tag am laufen.

Allerdings habe ich seit 3. Jan. einen doppelten push, einmal mit korrekten Daten aus dem Wetter-Proplanta und einmal mit täglich denselben Daten.
Ich kann den Fehler leider nicht finden...vielleicht könnt Ihr das ja:

Einmal ein List aus dem Device

Code Auswählen Erweitern


Internals:
   DEF        31028 de
   INTERVAL   600
   NAME       Wetter_Pro
   NR         375
   STATE      Tmin: -1 Tmax: 1 T: 1.9 H: 80.3 W: 10.8 P: 1023.4
   TYPE       PROPLANTA
   URL        http://www.proplanta.de/Wetter/profi-wetter.php?SITEID=60&PLZ=31028&STADT=31028&WETTERaufrufen=stadt&Wtp=&SUCHE=Wetter&wT=
   Readings:
     2017-01-09 14:47:35   cloudBaseMax    1000
     2017-01-09 14:47:35   cloudBaseMin    600
     2017-01-09 14:47:35   dewPoint        -1.4
     2017-01-09 14:47:35   durationFetchReadings 10.00
     2017-01-09 14:47:35   fc0_chOfRain00  20
     2017-01-09 14:47:35   fc0_chOfRain03  20
     2017-01-09 14:47:35   fc0_chOfRain06  20
     2017-01-09 14:47:35   fc0_chOfRain09  15
     2017-01-09 14:47:35   fc0_chOfRain12  15
     2017-01-09 14:47:35   fc0_chOfRain15  15
     2017-01-09 14:47:35   fc0_chOfRain18  10
     2017-01-09 14:47:35   fc0_chOfRain21  10
     2017-01-09 14:47:35   fc0_chOfRainDay 15
     2017-01-09 14:47:35   fc0_chOfRainNight 15
     2017-01-09 14:47:35   fc0_cloud00     100
     2017-01-09 14:47:35   fc0_cloud03     100
     2017-01-09 14:47:35   fc0_cloud06     100
     2017-01-09 14:47:35   fc0_cloud09     87.5
     2017-01-09 14:47:35   fc0_cloud12     87.5
     2017-01-09 14:47:35   fc0_cloud15     87.5
     2017-01-09 14:47:35   fc0_cloud18     37.5
     2017-01-09 14:47:35   fc0_cloud21     62.5
     2017-01-09 14:47:35   fc0_date        09.01.2017
     2017-01-09 14:47:35   fc0_dew         0
     2017-01-09 14:47:35   fc0_evapor      1
     2017-01-09 14:47:35   fc0_frost       1
     2017-01-09 14:47:35   fc0_moonRise    14:07
     2017-01-09 14:47:35   fc0_moonSet     04:39
     2017-01-09 14:47:35   fc0_rad         1
     2017-01-09 14:47:35   fc0_rain        0
     2017-01-09 14:47:35   fc0_rain00      0
     2017-01-09 14:47:35   fc0_rain03      0
     2017-01-09 14:47:35   fc0_rain06      0
     2017-01-09 14:47:35   fc0_rain09      0
     2017-01-09 14:47:35   fc0_rain12      0
     2017-01-09 14:47:35   fc0_rain15      0
     2017-01-09 14:47:35   fc0_rain18      0
     2017-01-09 14:47:35   fc0_rain21      0
     2017-01-09 14:47:35   fc0_sun         25
     2017-01-09 14:47:35   fc0_temp00      0
     2017-01-09 14:47:35   fc0_temp03      0
     2017-01-09 14:47:35   fc0_temp06      0
     2017-01-09 14:47:35   fc0_temp09      -1
     2017-01-09 14:47:35   fc0_temp12      1
     2017-01-09 14:47:35   fc0_temp15      -1
     2017-01-09 14:47:35   fc0_temp18      -1
     2017-01-09 14:47:35   fc0_temp21      -1
     2017-01-09 14:47:35   fc0_tempMax     1
     2017-01-09 14:47:35   fc0_tempMin     -1
     2017-01-09 14:47:35   fc0_uv          2
     2017-01-09 14:47:35   fc0_weatherDay  stark bewoelkt
     2017-01-09 14:47:35   fc0_weatherDayIcon http://www.proplanta.de/wetterdaten/images/symbole/t4.gif
     2017-01-09 14:47:35   fc0_weatherEvening wolkig
     2017-01-09 14:47:35   fc0_weatherEveningIcon http://www.proplanta.de/wetterdaten/images/symbole/n3.gif
     2017-01-09 14:47:35   fc0_weatherMorning bedeckt
     2017-01-09 14:47:35   fc0_weatherMorningIcon http://www.proplanta.de/wetterdaten/images/symbole/t5.gif
     2017-01-09 14:47:35   fc0_weatherNight stark bewoelkt
     2017-01-09 14:47:35   fc0_weatherNightIcon http://www.proplanta.de/wetterdaten/images/symbole/n4.gif


Einmal der Push:

Code Auswählen Erweitern



define PushTempEarly at *06:30 {\
  my $temp=ReadingsVal("Wetter_Pro","fc0_tempMax","");;\
  my $morgens=ReadingsVal("Wetter_Pro","fc0_weatherMorning","");;\
  my $nachmittags=ReadingsVal("Wetter_Pro","fc0_weatherEvening","");;\
  my $regenday=ReadingsVal("Wetter_Pro","fc0_chOfRainDay","");;\
  fhem("set PushMessage msg 'Guten Morgen, Simon sagt: ' 'Das Wetter am Vormittag wird: $morgens und es wird max. $temp °C. Die Regenwahrscheinlichkeit liegt bei $regenday Prozent. Am Nachmittag wird es $nachmittags. Ich wünsche Dir einen schönen Tag' '' 0 '' ")}



Vielleicht hat jemand eine Idee

Gruss

Thomas

[automatisierer]

vielleicht mal auf die neue Syntax umstellen...

Code Auswählen Erweitern

msg title='Guten Morgen, Simon sagt: ' 'Das Wetter am Vormittag wird: $morgens und es wird max. $temp °C. Die Regenwahrscheinlichkeit liegt bei $regenday Prozent. Am Nachmittag wird es $nachmittags. Ich wünsche Dir einen schönen Tag' priority=0

[nsu1200c]

Moin,

danke für die Unterstützung, und Nein´, es war nicht die Syntax, -->allerdings eine 2te FHEM Instanz auf dem Testsystem die diesen Blödsinn gepusht hat.

[Thyraz]

Das Modul ist doch eigentlich schon länger Zeit auf Non-Blocking HttpUtils umgeschrieben worden oder?

Hatte neulich einen Internetausfall und Zuhause gab es wohl andauernd längere Lags bei den Reaktionen von FHEM während ich noch arbeiten war.
Der WAF war natürlich sofort im Keller.

Habe bei all den internetbasierenden Modulen in meinem FHEM schon gefürchtet, dass ich eine zweite lokale FHEM Installation mit FHEM2FHEM für all das Zeug auslagern muss.
Nach einigen Tests ist Pushover aber das einzige Modul, welches FHEM bei mir regelmäßig blockiert wenn keine Internetverbindung da ist.
Trenne ich die Verbindung habe ich alle paar Minuten ein c.a. 20 Sekunden-Lag.

Sobald ich Pushover auf disabled setze passiert das nicht mehr.

Kann das jemand anderes auch nachstellen und/oder hat eine Idee wo in dem Modul noch blockierender Code zu finden ist?

[marvin78]

Module, die auf das Internet zugreifen, schalte mein FHEM sofort auf disabled, wenn googles DNS Server per PRESENCE nicht erreichbar sind.

[Thyraz]

Ah, sehr gute Idee.

Danke

[Loredo]

Das Modul ist doch eigentlich schon länger Zeit auf Non-Blocking HttpUtils umgeschrieben worden oder?

Ist es.

Hatte neulich einen Internetausfall und Zuhause gab es wohl andauernd längere Lags bei den Reaktionen von FHEM während ich noch arbeiten war.

AFAIK ist Non-Blocking HttpUtils nicht 100% unblockierend. Die DNS Auflösung ist nach wie vor blockierend (lässt sich wohl nicht vermeiden) und wenn kein Internet vorhanden ist wird natürlich bis zu einem Timeout blockiert. Das Modul merkt allerdings, dass es den Request nicht erfolgreich absetzen konnte und deaktiviert sich dann.

Nach einigen Tests ist Pushover aber das einzige Modul, welches FHEM bei mir regelmäßig blockiert wenn keine Internetverbindung da ist.
Trenne ich die Verbindung habe ich alle paar Minuten ein c.a. 20 Sekunden-Lag.

Sobald ich Pushover auf disabled setze passiert das nicht mehr.

Kann das jemand anderes auch nachstellen und/oder hat eine Idee wo in dem Modul noch blockierender Code zu finden ist?

Das ist nicht nachzuvollziehen. Es gibt nichts, was das Modul alle 20sek tun würde, ohne dass Nachrichten darüber verschickt würden.

[marvin78]

@Loredo: Er hat auch nicht davon gesprochen, dass das Modul alle 20 Sekunden etwas macht.

[Thyraz]

Ja, passiert eher so alle 5-10 Minuten und ist dann für etwa 20 Sekunden blockiert.

[Loredo]

Für den Fall, dass während eines Internetausfalls eine Pushnachricht versucht wird zu verschicken, wird sich das Modul auf "disabled" setzen, damit bei Nutzung des msg-Befehls erkannt werden kann, dass ein alternatives Routing verwendet werden muss, um die Nachricht zuzustellen (beispielsweise Audio). Wenn das Modul sich selbst disabled hat (nicht zu verwechseln mit dem Attribut "disabled"), dann wird alle 5 Minuten geschaut, ob wieder eine Verbindung zu Pushover aufgebaut werden kann. Ist das der Fall, wechselt der Status wieder auf "connected".


Das Timeout für HttpUtils ist auf 3 Sekunden eingestellt und kann über das Attribut timeout geändert werden. Warum aber HttpUtils nicht spätestens zumindest nach diesen 3 Sekunden nicht mehr auf eine DNS Antwort wartet, bleibt vermutlich ein Geheimnis. Du kannst auch versuchen dein lokales DNS Setup zu optimieren und negative Responses zu cachen (z.B. unbound auf deinem FHEM Server mit installieren).


Evtl auch mal dem Blockieren mit apptime und ggf perfmon genauer auf die Spur gehen.