at-Device: Perl Warnung nach Update 10.02.2016

[alpha1974]

Sehr merkwürdig, nach dem heutigen Update läuft ein at-Device nicht mehr richtig rund, sondern produziert nachstehende Warnung. Vielleicht habe ich irgendeine Ankündigung verpasst, wonach ein Codechange Anpassungen erforderlich gemacht hat?

Hier die Fehlermeldung

Code Auswählen Erweitern

2016.02.10 18:32:24 1: PERL WARNING: Use of uninitialized value in string ne at (eval 1810) line 1, <FILE> line 7441.
2016.02.10 18:32:24 3: eval: {if (fhem("get ZWave_wassersensor_kueche sbStatus",1) ne "state:closed") {send_mail('mail@xxxxx.xxx','FHEM Wassersensor Kueche','Wassersensor Küche: keine Antwort seit 70 Minuten')}}


Das at-Device, um das es geht:

Code Auswählen Erweitern

Internals:
   COMMAND    {if (fhem("get ZWave_wassersensor_kueche sbStatus",1) ne "state:closed") {send_mail('mail@xxxxx.xxx','FHEM Wassersensor Kueche','Wassersensor Küche: keine Antwort seit 70 Minuten')}}

   DEF        +*01:10:00 {if (fhem("get ZWave_wassersensor_kueche sbStatus",1) ne "state:closed") {send_mail('mail@xxxxx.xxx','FHEM Wassersensor Kueche','Wassersensor Küche: keine Antwort seit 70 Minuten')}}

   NAME       Ping_ZWave_wassersensor_kueche
   NR         70
   NTM        20:52:24
   PERIODIC   yes
   RELATIVE   yes
   REP        -1
   STATE      Next: 20:52:24
   TIMESPEC   01:10:00
   TRIGGERTIME 1455133944.79647
   TRIGGERTIME_FMT 2016-02-10 20:52:24
   TYPE       at
   Helper:
     Dblog:
       Next:
         Logdb:
           TIME       1455131907.17744
           VALUE      20:52:24
       State:
         Logdb:
           TIME       1455130823.83695
           VALUE      disabled
   Readings:
     2016-02-10 20:18:27   state           Next: 20:52:24
Attributes:
   room       Monitoring
   verbose    2

Das Device soll regelmäßig prüfen, ob ein netzbetriebener Wassersensor noch erreichbar ist. Ein manuelles "get ZWave_wassersensor_kueche sbStatus" liefert "state:closed".

Gruß
alpha1974

[alpha1974]

Update: Ein weiteres at-Device, das ähnlich aufgebaut ist, liefert ebenfalls eine Fehlermeldung (beide Devices schicken via send_mail aus 99_myutils.pm zur richtigen Zeit eine Mail, obwohl die Geräte jeweils erreichbar sind):

Code Auswählen Erweitern

2016.02.11 01:02:00 1: PERL WARNING: Use of uninitialized value in index at (eval 42795) line 1.
2016.02.11 01:02:00 3: eval: {if (index(fhem ("get ZWave_Rauchmelder_Wohnzimmer battery",1),"battery:") eq "-1") {send_mail('xxx@xxxxx.xxx','FHEM Rauchmelder Wohnzimmer','Rauchmelder Wohnzimmer: keine Antwort auf get battery')}}
2016.02.11 01:02:00 3: Ping_Rauchmelder_Wohnzimmer: -1

Code Auswählen Erweitern


Internals:
   COMMAND    {if (index(fhem ("get ZWave_Rauchmelder_Wohnzimmer battery",1),"battery:") eq "-1") {send_mail('mail@xxxxx.xxx','FHEM Rauchmelder Wohnzimmer','Rauchmelder Wohnzimmer: keine Antwort auf get battery')}}
   DEF        *01:02:00 {if (index(fhem ("get ZWave_Rauchmelder_Wohnzimmer battery",1),"battery:") eq "-1") {send_mail('mail@xxxxx.xxx','FHEM Rauchmelder Wohnzimmer','Rauchmelder Wohnzimmer: keine Antwort auf get battery')}}
   NAME       Ping_Rauchmelder_Wohnzimmer
   NR         130
   PERIODIC   yes
   RELATIVE   no
   REP        -1
   STATE      Next: 01:02:00
   TIMESPEC   01:02:00
   TRIGGERTIME 1455235320
   TRIGGERTIME_FMT 2016-02-12 01:02:00
   TYPE       at
   Readings:
     2016-02-11 01:02:00   state           Next: 01:02:00
Attributes:
   room       Monitoring

[alpha1974]

Hallo,

leider treibt mich das oben beschriebene Phänomen immer noch um.

Des Pudels Kern dürfte darin liegen, dass

Code Auswählen Erweitern

{fhem ("get ZWave_Rauchmelder_Wohnzimmer battery")}
keinen Wert zurückgibt, wenn "get battery" ausgeführt werden konnte. Allerdings wird das passende Reading für das Device aktualisiert. "Früher" war das wohl mal anders und {fhem ("get ZWave_Rauchmelder_Wohnzimmer battery")} lieferte den Batteriestand.
Analog bei einem Wassersensor mit

Code Auswählen Erweitern

{fhem("get ZWave_wassersensor_kueche sbStatus")} = kein Wert wird zurückgegeben, aber das state-Reading auf "closed" aktualisiert.

Ist das ein Bug oder ein Feature?

Gruß,
alpha1974

[krikan]

Des Pudels Kern dürfte darin liegen, dass
Code: [Auswählen]

{fhem ("get ZWave_Rauchmelder_Wohnzimmer battery")}

keinen Wert zurückgibt, wenn "get battery" ausgeführt werden konnte. Allerdings wird das passende Reading für das Device aktualisiert. "Früher" war das wohl mal anders und {fhem ("get ZWave_Rauchmelder_Wohnzimmer battery")} lieferte den Batteriestand.
Analog bei einem Wassersensor mit
Code: [Auswählen]

{fhem("get ZWave_wassersensor_kueche sbStatus")}

= kein Wert wird zurückgegeben, aber das state-Reading auf "closed" aktualisiert.

Ist das ein Bug oder ein Feature?

Das ist ein Feature. An der Feature-Enststehung warst Du nicht unbeteiligt bzw. Auslöser.  : https://forum.fhem.de/index.php/topic,53315.0.html

FHEM wartet jetzt bei allen Zwave-get nicht (mehr) blockierend auf die Antwort der ZWave-Abfrage, sondern arbeitet weiter. Also bspw. ein FHEM-sleep nach get in die Abfrage einbauen und dann mit ReadingsVal/-Num auf den Readingwert zugreifen oder auf das Antwort-Event mit notify/DOIF reagieren.

Warum machst Du die Abfragen aktiv mit get und konfigurierst den/die Sensoren nicht so, dass sie in bestimmten Abständen automatisch die Info liefern und reagierst darauf mit notify/DOIF?

Gruß, Christian

[alpha1974]

Das ist ein Feature. An der Feature-Enststehung warst Du nicht unbeteiligt bzw. Auslöser.  :
https://forum.fhem.de/index.php/topic,53315.0.html

Oha, da fehlte mir wohl die Fähigkeit zur notwendigen Transferleistung zwischen beiden Themen.

Warum machst Du die Abfragen aktiv mit get und konfigurierst den/die Sensoren nicht so, dass sie in bestimmten Abständen automatisch die Info liefern und reagierst darauf mit notify/DOIF?

Bei dem Fibaro-Wassersensor habe ich das nicht hinbekommen: Seitdem ich ihn vom battery-Device zum netzteil-betriebenen Device umgebaut habe, schickt er keine Wakeups mehr, weil er ständig wach ist. Also muss ich ihm aktiv irgendeine Reaktion entlocken, z.B. durch ein get sbStatus. Kommt keine Rückmeldung, besteht Kontrollbedarf und ich erhalte eine entsprechende Nachricht.

Und beim Popp-Rauchmelder hatte ich das Thema hier schon einmal angesprochen (Batteriestatus regelmäßig abfragen, um die Batterie austauschen zu können, bevor der Rauchmelder ein akustisches Signal wegen schwacher Bat. von sich gibt). Wenn {fhem ("get...")} nichts zurückliefert, realisiere ich das wohl am besten - wie von dir vorgeschlagen - mit einem "at" (get battery) und einem notify/DOIF auf das per at ausgelöste Event.

Besten Dank für die Erleuchtung und viele Grüße
alpha1974