Logeinträge vom WeekdayTimer

Begonnen von juemuc, 10 Juni 2020, 21:47:31

Vorheriges Thema - Nächstes Thema

juemuc

Hallo zusammen,

ich habe immer wieder diese Einträge im Logfile:

2020.06.10 21:06:17 1: PERL WARNING: Use of uninitialized value in regexp compilation at ./FHEM/98_WeekdayTimer.pm line 427.
2020.06.10 21:06:17 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at ./FHEM/98_WeekdayTimer.pm line 1229.
2020.06.10 21:06:17 1: PERL WARNING: Use of uninitialized value in string gt at ./FHEM/98_WeekdayTimer.pm line 1232.
2020.06.10 21:06:17 1: PERL WARNING: Use of uninitialized value in string gt at ./FHEM/98_WeekdayTimer.pm line 1183.

Was ist hier falsch ?

Viele Grüße
Jürgen
3x Sonos Play 1, 1x Sonos Arc + Sub, 1 Sonos-One, 1x Sonos Playbar
FB6690 + FB7490 mit 4x Dect 200 und 3 Dect-ULE-Thermostate,  raspberry3B+, HM Funkmodul HM-MOD-RPI-PCB, HM Klingelsensor HM-Sen-DB-PCB, HM (IP) Fensterkontakte und  Amazon Echo Dot,  piVCCU, pi OS (bookworm).

Beta-User

Hmmm....

Um das näher analysieren zu können, bräuchte ich den zugehörigen WDT bzw. ein list davon - ich habe diesen Monat (@verbose 3) noch keine einzige Meldung im log.

Die erste deutet auf einen wdt hin, der keine nummerische Tagesangabe hat, also mit $we oder Mo... arbeitet.
Anzeige z.B. über "list TYPE=WeekdayTimer DEF"

Bitte auch mal checken, ob die Spracheinstellungen bei allen passen (ggf. über global umstellen), nicht dass die regex auf englisch sucht und du deutsche Wochentage verwendest (kann sein, dass ich da noch nacharbeiten muss, um entsprechende Warnmeldungen auszugeben).

Falls das zu kryptisch ist bitte melden.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

juemuc

Hallo Beta-User,

hier mein list:

Internals:
   COMMAND   
   CONDITION 
   DEF        Esszimmerlampe_WT_dummy de 1234560|{sunset_abs("REAL",0,"00:00","23:59")}|on
   DEVICE     Esszimmerlampe_WT_dummy
   FUUID      5dc821e5-f33f-ca7c-4ab8-69ed7f10bba15d01
   GlobalDaylistSpec
   LANGUAGE   de
   NAME       Esszimmerlampe_WT
   NR         266
   Profil 0: Sonntag 21:06:51 on,
   Profil 1: Montag 21:06:51 on,
   Profil 2: Dienstag 21:06:51 on,
   Profil 3: Mittwoch 21:06:51 on,
   Profil 4: Donnerstag 21:06:51 on,
   Profil 5: Freitag 21:06:51 on,
   Profil 6: Samstag 21:06:51 on,
   STATE      AUS
   STILLDONETIME 0
   TYPE       WeekdayTimer
   READINGS:
     2020-06-10 21:06:19   currValue       on
     2020-04-05 19:28:52   disabled        1
     2020-06-10 21:06:19   nextUpdate      2020-06-11 21:06:16
     2020-06-10 21:06:19   nextValue       on
     2020-06-10 21:06:19   state           on
   SWITCHINGTIMES:
     0123456|{sunset_abs("REAL",0,"00:00","23:59")}|on
   TIMER:
     Esszimmerlampe_WT_1:
       HASH       Esszimmerlampe_WT
       MODIFIER   1
       NAME       Esszimmerlampe_WT_1
     Esszimmerlampe_WT_SetTimerOfDay:
       HASH       Esszimmerlampe_WT
       MODIFIER   SetTimerOfDay
       NAME       Esszimmerlampe_WT_SetTimerOfDay
       SETTIMERATMIDNIGHT 1
   helper:
     daysRegExp (so|mo|di|mi|do|fr|sa|\$we|\!\$we)
     daysRegExpMessage (so|mo|di|mi|do|fr|sa|$we|!$we)
     SWITCHINGTIME:
       0:
         21:06:51   on
       1:
         21:06:51   on
       2:
         21:06:51   on
       3:
         21:06:51   on
       4:
         21:06:51   on
       5:
         21:06:51   on
       6:
         21:06:51   on
     WEDAYS:
       0          1
       2          1
       3          1
   profil:
     1:
       EPOCH      1591902411
       PARA       on
       TIME       {sunset_abs("REAL",0,"00:00","23:59")}
       WE_Override 0
       TAGE:
         0
         1
         2
         3
         4
         5
         6
   profile_IDX:
     0:
       21:06:16   1
       21:06:51   1
     1:
       21:06:16   1
       21:06:51   1
     2:
       21:06:16   1
       21:06:51   1
     3:
       21:06:16   1
       21:06:51   1
     4:
       21:06:16   1
       21:06:51   1
     5:
       21:06:16   1
       21:06:51   1
     6:
       21:06:16   1
       21:06:51   1
Attributes:
   commandTemplate set $NAME  $EVENT
   devStateStyle style="text-align:right"
   disable    1
   group      Schaltzeitpunkte
   room       Schaltzentrale,Wohnzimmer
   stateFormat {my $val;
if (ReadingsVal($name, "disabled","") eq "1") {$val = "AUS"}
else {$val = ReadingsVal($name, "currValue","")};
$val}


Ich steuere hier in Abhängigkeit vom Sonnenuntergang  ;D

Viele Grüße
Jürgen
3x Sonos Play 1, 1x Sonos Arc + Sub, 1 Sonos-One, 1x Sonos Playbar
FB6690 + FB7490 mit 4x Dect 200 und 3 Dect-ULE-Thermostate,  raspberry3B+, HM Funkmodul HM-MOD-RPI-PCB, HM Klingelsensor HM-Sen-DB-PCB, HM (IP) Fensterkontakte und  Amazon Echo Dot,  piVCCU, pi OS (bookworm).

RichardCZ


Bin mir nicht sicher, wie treffgenau die aktuellen Sourcen in meinem Repo sind, aber:

Zitat2020.06.10 21:06:17 1: PERL WARNING: Use of uninitialized value in regexp compilation at ./FHEM/98_WeekdayTimer.pm line 427.

if ($daylist =~  m/^($hash->{helper}{daysRegExp}(,|-|$)){0,7}$/gx   ) {

Guggst Du https://perldoc.perl.org/perlvar.html
insbes.

$EFFECTIVE_GROUP_ID
$EGID
$)


Jahaaa. $) ist eine Variable.

könnte natürlich auch sein, dass $hash->{helper}{daysRegExp} undef ist.

Zitat2020.06.10 21:06:17 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at ./FHEM/98_WeekdayTimer.pm line 1229.

$hash->{CONDITION} ist undef (s.u.)


Zitat
2020.06.10 21:06:17 1: PERL WARNING: Use of uninitialized value in string gt at ./FHEM/98_WeekdayTimer.pm line 1232.
2020.06.10 21:06:17 1: PERL WARNING: Use of uninitialized value in string gt at ./FHEM/98_WeekdayTimer.pm line 1183.

Wie ich an anderer Stelle (Perl Ecke) ausgeführt habe, ist der Vergleich auf leeren String mittels gt eine schlechte Idee.
$hash->{CONDITION} / $hash->{COMMAND} ist vermutlich undef.

würde ich entweder mit

my $condition = $hash->{CONDITION} // 'default';
oder eben
$hash->{CONDITION} //= 'default';
lösen - je nachdem ob man gleich die Ursprungsdaten reparieren will oder nicht.
Witty House Infrastructure Processor (WHIP) is a modern and
comprehensive full-stack smart home framework for the 21st century.

Beta-User

Die Zeilennummern sollten halbwegs passen.

Wenn das mit "$)" als Variable passen würde, müßte die Fehlermeldung aber immer kommen, oder? Macht sie aber nicht, zumindest nicht bei meinen WDT's. Die sind btw. auch alle nummerisch notiert, wie der des TE. Was bei mir anders ist: In der Regel habe ich einen Command notiert bzw. führe Perl-Code aus, und languange kommt bei mir aus global. Das könnte einen Unterschied machen, aber so recht will ich daran noch nicht glauben; ausschließen würde ich es allerdings nicht, denn es finden sich in dem Code auch unshifts nach @$a (https://svn.fhem.de/trac/browser/trunk/fhem/FHEM/98_WeekdayTimer.pm#L627, L646, L665). Das könnte sich mit der Änderung zu @arr in WeekdayTimer_Start (und ggf. anderswo) beißen...?

Also käme man auf undef.

Aktuell wird aber WeekdayTimer_Start() "ziemlich schnell" nach dem define aufgerufen, und danach sollten beide ($hash->{COMMAND} und $hash->{CONDITION} eigentlich so oder so nicht mehr undef sein: https://svn.fhem.de/trac/browser/trunk/fhem/FHEM/98_WeekdayTimer.pm#L132. Eine andere Stelle, die das Löschen bzw. auf undef setzen würde, habe ich auf die Schnelle auch nicht gefunden. (Wenn gelöscht, wären die nicht mehr als Internals gelistet).

Von daher ist es wahrscheinlicher, dass das mit der "a"-Thematik zu tun hat. Was mich dann allerdings wundert: das list an sich sieht auch sonst ok aus. Hätte erwartet, dass das irgendwie "kaputt" ist, also irgendwas sinnfreies für diese Internals angezeigt wird oä..

Das mit den komischen Vergleichen ist in der in der Perl-Ecke angehängten Version beseitigt (ich fand das auch schon immer etwas seltsam, aber funktionierende Dinge zu ändern, hatte ich in der Vergangenheit tendenziell lieber vermieden, selbst wenn es (scheinbar...) trivial war...).
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Beta-User

@juemuc: Habe die geänderte .pm gestern eingecheckt, nachdem bei mir auch mit einem WDT nach deinem Muster einige Tage keine Fehler aufgetreten waren.

Wäre nett, wenn du bitte mal bei Gelegenheit checken könntest, ob das jetzt auch bei dir weg ist. Sonst muß ich wohl nochmal richtig unter dieses Auto liegen...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

juemuc

@Beta-User: Update wurde durchgeführt. Ich beobachte  :D

Viele Grüße
Jürgen
3x Sonos Play 1, 1x Sonos Arc + Sub, 1 Sonos-One, 1x Sonos Playbar
FB6690 + FB7490 mit 4x Dect 200 und 3 Dect-ULE-Thermostate,  raspberry3B+, HM Funkmodul HM-MOD-RPI-PCB, HM Klingelsensor HM-Sen-DB-PCB, HM (IP) Fensterkontakte und  Amazon Echo Dot,  piVCCU, pi OS (bookworm).

juemuc

Hallo Beta-User,

pünktlich zum Schaltzeitpunkt  :(

2020.06.22 21:10:41 1: PERL WARNING: Use of uninitialized value in regexp compilation at ./FHEM/98_WeekdayTimer.pm line 422.
2020.06.22 21:10:41 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at ./FHEM/98_WeekdayTimer.pm line 1212.
2020.06.22 21:10:41 1: PERL WARNING: Use of uninitialized value in string ne at ./FHEM/98_WeekdayTimer.pm line 1215.
2020.06.22 21:10:41 1: PERL WARNING: Use of uninitialized value in string ne at ./FHEM/98_WeekdayTimer.pm line 1166.


Ich glaube, dass diese Meldung nur einmal nach einem FHEM-Neustart kommt. Eventuell hilft dies bei der Fehlersuche.

Viele Grüße
Jürgen.
3x Sonos Play 1, 1x Sonos Arc + Sub, 1 Sonos-One, 1x Sonos Playbar
FB6690 + FB7490 mit 4x Dect 200 und 3 Dect-ULE-Thermostate,  raspberry3B+, HM Funkmodul HM-MOD-RPI-PCB, HM Klingelsensor HM-Sen-DB-PCB, HM (IP) Fensterkontakte und  Amazon Echo Dot,  piVCCU, pi OS (bookworm).

Beta-User

Hmm, irgendwie schräg...

Also:
-Ändere mal bitte Zeile 422 so ab:
  if ( $daylist =~ m{\A($hash->{helper}{daysRegExp}(,|$|-)){0,7}\z}xms ) {Damit sollte das von RichardCZ aufgezeigte potentielle Variablenproblem beseitigt sein, was aber mit einiger Sicherheit hier nicht durchschlägt.

Ansonsten habe ich mal zwei Test-WDT gebaut, die eigentlich genauso "ticken" wie der von deinem list (devStrich0 ist ein "Mülleimerdummy", den ich gerne zum Ausführen irgendwelcher eigentlich nicht irgendeinem anderen Device zuordenbarer Anweisungen nutze...):
defmod testWDT3 WeekdayTimer devStrich0 de Mo,Mi-Fr|{sunrise_abs("CIVIL",0,"00:00","23:59")}|on
attr testWDT3 switchInThePast 1

Sollte eigentlich nach einem Neustart denselben Eintrag provozieren wie bei dir (wg. switchInThePast).

Und
defmod testWDT2 WeekdayTimer devStrich0 de 1234560|{sunset_abs("REAL",0,"00:00","23:59")}|on

Das ist eigentlich nach meinem Verständnis (bis auf das Zieldevice) 1:1 das aus deinem list und lief seit längerem hier mit - ohne Fehlermeldung.
Mal schauen, ob der jetzt nach dem update bzw. der Änderung der obigen Zeile irgendwas ins log schreibt...

Da ich davon ausgehe, dass bei dir nicht noch irgendein WDT auf sunset_abs eingestellt ist und der Schaltzeitpunkt nur zu dem gezeigten WDT paßt: Hast du auch noch ein paar Infos zum Umfeld (Hardware, OS, Perl-Version => fheminfo sollte das liefern)?
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

juemuc

#9
Test läuft.

Hier die gewünschten Infos:

Pi 3 und PI3B Raspberry Pi OS (aktuell), Perl 5.28.1, FHEM aktuell,
Testsystem: PC Virtuelle Maschine mit Ubuntu 20.04, FHEM aktuell

Viele Grüße
Jürgen
3x Sonos Play 1, 1x Sonos Arc + Sub, 1 Sonos-One, 1x Sonos Playbar
FB6690 + FB7490 mit 4x Dect 200 und 3 Dect-ULE-Thermostate,  raspberry3B+, HM Funkmodul HM-MOD-RPI-PCB, HM Klingelsensor HM-Sen-DB-PCB, HM (IP) Fensterkontakte und  Amazon Echo Dot,  piVCCU, pi OS (bookworm).

Wzut

Ich hab jeden Morgen im Log (SVN 22373) :
2020.07.13 05:59:00 1: PERL WARNING: Use of uninitialized value $n in hash element at fhem.pl line 4493.
2020.07.13 05:59:00 1: stacktrace:
2020.07.13 05:59:00 1:     main::__ANON__                      called by fhem.pl (4493)
2020.07.13 05:59:00 1:     main::ReadingsVal                   called by ./FHEM/98_WeekdayTimer.pm (1174)
2020.07.13 05:59:00 1:     main::WeekdayTimer_Switch_Device    called by ./FHEM/98_WeekdayTimer.pm (965)
2020.07.13 05:59:00 1:     main::WeekdayTimer_Update           called by fhem.pl (3330)
2020.07.13 05:59:00 1:     main::HandleTimeout                 called by fhem.pl (684)

irgend ein Tipp wie ich es weiter eingrenzen könnte?
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

Beta-User

Hmm, kannst du mal Zeile 1019 auf
  return "";
ändern?

Meine Vermutung: Es wird da um 5:59 irgendwas geschaltet, das nicht dummy und auch nichts ist, was irgendwie eine Heizung sein könnte? (Falls du das eingrenzen kannst).

Vermutlich hat es auch mit dem Ausgangsthema nichts zu tun. (Das könnte (...) mit der 22373 erledigt sein; falls nicht, wären die neuen/noch verbliebenen Zeilennummern interessant).
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Wzut

Zitat von: Beta-User am 13 Juli 2020, 07:41:19
um 5:59 irgendwas geschaltet, das nicht dummy und auch nichts ist, was irgendwie eine Heizung sein könnte? (Falls du das eingrenzen kannst).
hey , hey natürlich hat mein BEOK etwas mit Heizung zu tun -> el. Fußbodenheizung :)
Kann ich im Modul selbst noch etwas tun um mehr nach Heizung auszusehen ?
Ich leg noch ein paar Schaltpunkte an sonst müsste ich bis Samstag warten (das Return baue ich vorher natürlich ein )
defmod beok_wdt WeekdayTimer beok sa|07:00|21.5 sa|13:00|20.5 mo|06:00|21.5 mo|15:00|20.5
attr beok_wdt DbLogExclude .*
attr beok_wdt commandTemplate set $NAME desired-temp $EVENT
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

Beta-User

Das mit dem return dürfte auf alle Fälle nicht schaden, auch wenn es "komisch" ist, falls es von diesem WDT kommt.

Evtl. ist auch der Aufruf schon shitty, und in die erste Zeile der Routine sollte sicherheitshalber noch das "Notaus" ergänzt werden: "// return "";"?

Kannst du mal nachsehen, ob du das korrekte Ergebnis bekommst bei
{WeekdayTimer_isHeizung($defs{"beok_wdt"})}
(Leider kann ich den Command auf die Schnelle nicht verifizieren, habe grade keine Heizung an einem WDT hängen und bei meinen kommt schlicht wieder meine Hauptseite...)
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Wzut

#14
{WeekdayTimer_isHeizung($defs{"beok_wdt"})}

=> desired-temp


Edit :  sorry , ich hab da noch einen gefunden , täglich um 5:59 für die KeyMatic ! Mal schauen ob er morgen früh still ist, THX
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher