(gelöst) notify kann plötzlich scheinbar Trigger nicht mehr verarbeiten

[r00t2]

Hallo,

ich habe gerade ein (für mich) seltsames Verhalten meiner FHEM Installation beobachtet.

Setting: Ich habe eine notify für eine Lampe, die ich per Weather Twilight je nach Wochentag eine Zeit lang laufen lasse und welches bisher super und sehr zuverlässig funktioniert hat.

RAW Define vom notify:

Code Auswählen Erweitern

defmod notify_SchlaLa_an_by_Twilight notify wtr_Twilight:twilight_weather:.* {\
\
  my $state = ReadingsVal("wtr_Twilight","state","0");;;;\
#  Log 1, "notify_SchlaLa_an_by_Twilight EVTPART1 [" . $EVTPART1 . "] - state [" . $state . "]";;;; \
\
  # Pruefen, ob es schon dunkel genug ist\
  if (($EVTPART1 < 55) && ($state >= 7)) {\
    # Pruefen, ob SchlaLa bereits an ist\
    if(Value("sw_Stehlampe_till")) {\
#      Log 1, "SchlaLa bereits an - nichts zu tun";;;; \
    }\
    else {\
      if (($wday == 5) || ($wday == 6)) {\
        Log 1, "Freitag oder Samstag ($wday): SchlaLa bis 0200h an";;;;\
        fhem ("set sw_Stehlampe on-till-overnight 02:00");;;;\
#        fhem ("set sw_Schalter03 on-till-overnight 02:00");;;;\
      }\
      else {\
        Log 1, "Wochentag oder Sonntag ($wday): SchlaLa bis 2358h an";;;;\
        fhem ("set sw_Stehlampe on-till 23:58");;;;\
#        fhem ("set sw_Schalter03 on-till 23:58");;;;\
      }\
    }\
  }\
  else {\
#    Log 1, "Twilight_Weather > 55 bzw state < 7 - nichts zu tun";;;;\
  }\
}
attr notify_SchlaLa_an_by_Twilight disabledForIntervals 23:00-24:00 00:00-15:00
attr notify_SchlaLa_an_by_Twilight room Zustandssteuerung

setstate notify_SchlaLa_an_by_Twilight 2019-07-28 21:15:08
setstate notify_SchlaLa_an_by_Twilight 2019-03-16 14:55:45 state active



Das hat bis gestern gut funktioniert. Heute (nach einer FHEM Uptime von 134 days, 05 hours, 32 minutes) hat es nicht mehr getriggert, obwohl die Weather Werte scheinbar passend waren. Im FHEM Logfile erscheint kein Eintrag, als ob das notify einfach nicht zu den entsprechenden Codezeilen gekommen ist, die Logging beinhalten.

Ein manuelles Triggern per:

Code Auswählen Erweitern

trigger wtr_Twilight twilight_weather:0

ergab folgenden Fehler:

Code Auswählen Erweitern

2019.07.28 21:25:37 1: ERROR evaluating my $EVTPART0='twilight_weather:0';my $TYPE='Twilight';my $EVENT='twilight_weather:0';my $SELF='notify_SchlaLa_an_by_Twilight';my $NAME='wtr_Twilight';{

  my $state = ReadingsVal("wtr_Twilight","state","0");;
  Log 1, "notify_SchlaLa_an_by_Twilight EVTPART1 [" . $EVTPART1 . "] - state [" . $state . "]";;

  # Pruefen, ob es schon dunkel genug ist
  if (($EVTPART1 < 55) && ($state >= 7)) {
    # Pruefen, ob SchlaLa bereits an ist
    if(Value("sw_Stehlampe_till")) {
#      Log 1, "SchlaLa bereits an - nichts zu tun";;
    }
    else {
      if (($wday == 5) || ($wday == 6)) {
        Log 1, "Freitag oder Samstag ($wday): SchlaLa bis 0200h an";;
        fhem ("set sw_Stehlampe on-till-overnight 02:00");;
#        fhem ("set sw_Schalter03 on-till-overnight 02:00");;
      }
      else {
        Log 1, "Wochentag oder Sonntag ($wday): SchlaLa bis 2358h an";;
        fhem ("set sw_Stehlampe on-till 23:58");;
#        fhem ("set sw_Schalter03 on-till 23:58");;
      }
    }
  }
  else {
#    Log 1, "Twilight_Weather > 55 bzw state < 7 - nichts zu tun";;
  }
}: Global symbol "$EVTPART1" requires explicit package name (did you forget to declare "my $EVTPART1"?) at (eval 6254955) line 4.
Global symbol "$EVTPART1" requires explicit package name (did you forget to declare "my $EVTPART1"?) at (eval 6254955) line 7.

2019.07.28 21:25:37 3: notify_SchlaLa_an_by_Twilight return value: Global symbol "$EVTPART1" requires explicit package name (did you forget to declare "my $EVTPART1"?) at (eval 6254955) line 4.
Global symbol "$EVTPART1" requires explicit package name (did you forget to declare "my $EVTPART1"?) at (eval 6254955) line 7.


Woran kann das liegen? Ich stehe gerade tatsächlich vor einem Rätsel, da das System wirklich stabil lief bisher.

Vielleicht an einer "ungünstigen" Konstellation von weather_twilight und state? Sollte ich state bzw jede Änderung des Weather Devices als Trigger für das notify setzen?

Ich sehe gerade nur ein paar Fragezeichen

[Otto123]

Hi,

ich verstehe die Fehlermeldung so: Du verarbeitest $EVTPART1, den gibt es aber bei deinem Trigger nicht. Es gibt nur $EVTPART0.

Global symbol "$EVTPART1" requires explicit package name (did you forget to declare "my $EVTPART1"?) at (eval 6254955) line 7.

$EVTPART0='twilight_weather:0'

Gruß Otto

[r00t2]

Danke für Deine Antwort!

Ich habe jetzt mal den ersten Logging Eintrag wieder einkommentiert:

Code Auswählen Erweitern

Log 1, "notify_SchlaLa_an_by_Twilight EVTPART1 [" . $EVTPART1 . "] - state [" . $state . "]";;;; \

Mal sehen, was sich da tut. Eventuell gibt es Unterschiede zwischen dem manuellen Trigger und dem vom Device selbst generierten.

Wie gesagt: Das notify wurde nicht von mir verändert und lief bisher fehlerfrei. Habe gerade nochmal ein Backup von vor ein paar Tagen angeschaut und auch da ist es EVTPART1.

[Otto123]

Naja die Frage ist ja: Was geht nicht? Also wird es nicht getriggert oder wird der Ausführungsteil nicht abgearbeitet?
Deswegen konnte ich  mich nur auf deinen manuellen Test beziehen, denn nur zu dem hast Du was geschrieben. Ich gehe auch erstmal davon aus: dein manueller Trigger stimmt eventuell nicht mit der Realität überein. 

Es wäre übrigens für solche Test Logeinträge besser den $EVENT zu loggen, da siehst Du was drin steht. Wenn er Dir mit $EVTPART1 einen Fehler wirft hast Du nicht viel davon.

BTW: die ;;;; kannst Du in ;; umwandeln/kürzen. Man muss im define das eine Semikolon im Perl Ausführungsteil verdoppeln - aber nicht vervierfachen

Gruß Otto

[r00t2]

Soweit ich gesehen habe wird das notify schon noch getriggert - allerdings bricht der Ausführungsteil mit der geschriebenen Meldung ab, wenn ich es manuell triggere.

Beim gestrigen Fall durch das Weather Device selbst kann ich es leider nicht mehr nachvollziehen. Aber da sollte das Log bzw. die Readings des notify heute Abend Auskunft geben können, denn es sollte definitiv den Tag über ein paar Mal durch das Weather Device getriggert worden sein.

Ja, das mit dem Verwenden von $EVENT habe ich mir gestern Abend auch noch überlegt - aber da war der PC schon aus und ich zu faul, um ihn nochmal hoch zu fahren

Stimmt, da hast Du absolut Recht mit den Semikolons - ich prüfe das heute Abend gleich mal, ob ich das tatsächlich 4x im Code des Ausführungsteils stehen habe. Ich glaube nämlich, dass es nur 2x drin steht und das RAW Device Listing es verdoppelt, wenn man es sich so anzeigen lässt.

[Otto123]

Stimmt, da hast Du absolut Recht mit den Semikolons - ich prüfe das heute Abend gleich mal, ob ich das tatsächlich 4x im Code des Ausführungsteils stehen habe. Ich glaube nämlich, dass es nur 2x drin steht und das RAW Device Listing es verdoppelt, wenn man es sich so anzeigen lässt.

Sie stehen sicher in der DEF 2 mal drin. In der DEF (auch im DEF Editor)  brauchst Du aber wie normal im Perl nur eines. Die RAW Definition zeigt was in der Config steht und beim define oder in der FHEM Kommandozeile im Perl Teil, also zwischen {} muss man verdoppeln.

Du hast es manuell getriggert, also wird es prinzipiell getriggert. An dem Trigger Aufbau im notify ist sicher nichts falsch. Aber geht denn das Device noch richtig was den Trigger erzeugt? Erzeugt es den gleichen Fehler wie dein manueller Trigger?
Oder endet dein Ausführungsteil einfach im "tu nichts" (dem letzten else)

Gruß Otto

[r00t2]

Danke Dir.

Das kann gut sein, ja. Die DEF werde ich entsprechend ändern.

Ob die Trigger vom Weather Device richtig kommen (und welche Trigger das sind) werde ich ab heute Abend (wenn ich das Logging entsprechend überall aktiviere) sehen.

Gestern gab es keinen Fehler im Log (außer die, die ich durch manuelles Triggern verursacht habe). Von daher gehe ich momentan davon aus, dass das notify schon triggert, wie es soll - es vermutlich aber aufgrund einer ungünstigen Konstellation von twilight_weather und state im "Tu nichts" Fall gelandet ist. Aber auch das sollte sich durch mehr (aussagekräftige) Logging-Stellen entsprechend prüfen lassen.

Ich könnte mir z. B. vorstellen, dass aufgrund der starken Bewölkung und weil Darksky ziemlich ungenau bei sowas ist, der twilight_weather Wert bereits auf "0" stand und sich einfach nicht mehr geändert hat den Abend über.

Daher habe ich mir auch gedacht, dass ich zusätzlich zu twilight_weather ja auch state mit als Trigger aufnehmen könnte.
Also so etwas in der Art:

Code Auswählen Erweitern

defmod notify_SchlaLa_an_by_Twilight notify wtr_Twilight:twilight_weather:.* | wtr_Twilight:state:.* {...}

So würde - auch wenn sich twilight_weather nicht mehr ändert - zumindest zur nächsten state Änderung das notify nochmal getriggert werden.

[Otto123]

Dann schau aber bitte noch hier nach:
http://fhem.de/commandref_DE.html#notify

addStateEvent
Das mit dem state Reading verknüpfte Event ist speziell, da das dazugehörige Prefix "state: " entfernt wird, d.h. $EVENT ist nicht "state: on", sondern nur "on". In manchen Fällen ist es aber erwünscht das unmodifizierte Event zu bekommen, d.h. wo "state: " nicht entfernt ist. Für diese Fälle sollte addStateEvent auf 1 gesetzt werden, die Voreinstellung ist 0 (deaktiviert).
Achtung:
dieses Attribut muss beim Empfänger (notify, FileLog, etc) gesetzt werden.
dieses Attribut zeigt nur für solche Geräte-Events eine Wirkung, die readingFnAttributes unterstützen.

Ich habe leider keine konkreten Tipps zu twilight_weather da ich es nicht verwende.

[r00t2]

So, gestern noch etwas am Logging gefeilt und den Abend über mal beobachtet, was passiert.

Tatsächlich triggert das notify wie es soll und auch die Werte werden richtig erfasst und verarbeitet. Ich glaube noch immer, dass es eine ungünstige Konstellation der beiden Werte war, die zum "nicht-Ausführen" des "Mach das Licht an" Teils geführt hat.

Ich habe jetzt (danke nochmal an die Unterstützung, Otto) den Trigger um state erweitert und somit sollte es zumindest immer mal wieder getriggert werden, auch wenn twilight_weather sich nicht ändert.

Ich setze das Thema dann erstmal auf "erledigt".