neue Features: ereignisgesteuertes Perl - DOIF-Perl

[Damian]

so wird der Aufruf funktionieren:

Code: [Auswählen]

set_Exec("worktimer",1,"SatDown($delta)")

[obi]

Hallo,

ich habe das gleiche Problem, dass seit der Änderung der Parameterübergabe der rekursive Aufruf nicht funktioniert.
Habe alle erdenklichen variationen mal durchprobiert.

Code: [Auswählen]

set_Exec("worktimer",1,"volume($type)"); -> Bareword "Down" not allowed while "strict subs" in use
set_Exec("worktimer",1,'volume("$type")'); -> Global symbol "$type" requires explicit package name (did you forget to declare "my $type"?)
set_Exec("worktimer",1,'volume($type)'); -> Global symbol "$type" requires explicit package name (did you forget to declare "my $type"?)

Wie bekomme ich das Problem gelöst?

VG Sebastian

[Damian]

Hallo,

ich habe das gleiche Problem, dass seit der Änderung der Parameterübergabe der rekursive Aufruf nicht funktioniert.
Habe alle erdenklichen variationen mal durchprobiert.

Code: [Auswählen]

set_Exec("worktimer",1,"volume($type)"); -> Bareword "Down" not allowed while "strict subs" in use
set_Exec("worktimer",1,'volume("$type")'); -> Global symbol "$type" requires explicit package name (did you forget to declare "my $type"?)
set_Exec("worktimer",1,'volume($type)'); -> Global symbol "$type" requires explicit package name (did you forget to declare "my $type"?)

Wie bekomme ich das Problem gelöst?

VG Sebastian

Es kommt darauf auf, wie der Aufruf vorher aussah. Wo wird $type definiert?

[obi]

Hi Damian,

danke für die schnelle Antwort.

$type wird innerhalb der Sub als Übergabaparameter definiert, eventuell mache ich ja hier schon einen Fehler.

Hier mal mein kompletten Code der Sub:

Code: [Auswählen]

sub $SELF_volume
{
my ($type)=@_;
...
set_Exec('$SELF_volume', 1, '$SELF_volume($type)');
  }
Der 1. Aufruf sieht so aus in einem anderen teil des DOIF (Über einen externen Trigger mit IF)

Code: [Auswählen]

set_Exec('$SELF_volume', 0, '$SELF_volume("Up")');

[Damian]

Dann frage ich mich, wie du es vor der Umstellung aufgerufen hast.

[obi]

So hatte es vor der Umstellung fehlerfrei funktioniert:

Code: [Auswählen]

sub $SELF_volume
{
my ($type)=@_;
...
set_Exec('$SELF_volume', 1, '$SELF_volume', $type);
  }

Code: [Auswählen]

set_Exec('$SELF_volume', 0, '$SELF_volume', 'Up');

[Damian]

So hatte es vor der Umstellung fehlerfrei funktioniert:

Code: [Auswählen]

sub $SELF_volume
{
my ($type)=@_;
...
set_Exec('$SELF_volume', 1, '$SELF_volume', $type);
  }

Code: [Auswählen]

set_Exec('$SELF_volume', 0, '$SELF_volume', 'Up');

dann:

Code: [Auswählen]

sub $SELF_volume
{
my ($type)=@_;
...
set_Exec('$SELF_volume', 1, "$SELF_volume('$type')");
  }

Code: [Auswählen]

set_Exec('$SELF_volume', 0, "$SELF_volume('Up')";

[Per]

Um Lang- und Doppelclick bei meinen EnOcean-Tastern abzufragen, nutzte ich wegen der Timer jeweils ein klassisches DOIF. Ich wollte auf Templates umstellen, hat aber nicht funktioniert. Es gab keine Fehlermeldung, aber auch keine Aktion. Aber egal.
Dann habe ich mal bei Null angefangen und herausgekommen ist ein kleiner Mehrzeiler in Perl-DOIF (mein erster eigener), wahrscheinlich sogar, inkl. Attr., mit weniger Code pro DOIF als vorher. Und natürlich nur eine DOIF statt dutzender.

Code: [Auswählen]

define EnO_T_DOIF DOIF {\
if (["EnO_T_.*:buttons: released"]) {del_Exec('$DEVICE');;fhem('setreading $DEVICE pressed off');;} ##off\
if (["EnO_T_.*:buttons: pressed"]){\
if ([?$DEVICE:pressed:sec] < 2) {fhem('setreading $DEVICE pressed double');;} ## Double\
else {fhem('setreading $DEVICE pressed on');;set_Exec('$DEVICE',1,'fhem("setreading $DEVICE pressed long")')} ## short,long\
}\
}
Das einzige verbleibende Attribut bei mir ist der Raum.
Timer werden automatisch gesetzt/gelöscht, Events werden nicht erstellt (außer bei dem jeweiligen Tastern. Das benötigte Reading wird automatisch erzeugt. Neue Taster müssen nicht eingepflegt werden, was bei Templates notwendig wäre.

Einzige Voraussetzung ist der passende Namensraum (EnOcean-Taster -> EnO_T_xxx). Könnte man über eine Typ-Anfrage noch absichern, ist bei mir aber nicht notwendig.

PS: trotzdem werde ich nicht pauschal auf Perl-DOIF umsteigen
PPS: wäre es sinnvoll, neben fhem_set auch ein fhem_setreading bereitzustellen?

[hackepeter]

Hallo Damin

kurze Frage: ich habe ein Doif im PerlModus, welches auf viele Devices reagiert...
Gibt es eine elegante Möglichkeit, mehrfachtriggern zu verhindern, wenn die entsprechenden devices das reading neu setzen, sich dieses aber nicht verändert?

Code: [Auswählen]


{if (["Event:on"]){
  my $TriggerdeviceNr = substr($device, -4);;
  my $AckType;;
  my $ReceiverNr;;
........

[Damian]

Hallo Damin

kurze Frage: ich habe ein Doif im PerlModus, welches auf viele Devices reagiert...
Gibt es eine elegante Möglichkeit, mehrfachtriggern zu verhindern, wenn die entsprechenden devices das reading neu setzen, sich dieses aber nicht verändert?

Code: [Auswählen]

    U     "DB_Supplement_SEQ001".SupDB.Message[3]
      U     "DB_Meldungen".HM_FP[3]."1"
      =     "DB_Meldungen".Speicher_Meldungen_SEQ[1]."3"
........

Was ist das für eine Syntax? Das sagt mir nichts.

[hackepeter]

Moin Moin,

sorry, da hatte ich das falsche im Clipboard. Habe es geändert.

[Damian]

Also, Events eines Devices, die innerhalb eines EventBlocks kommen, triggern ohnehin nur einmal.

Man kann in DOIF-Perl mit Instanzvariablen arbeiten, man kann dort Sachen ablegen, die man beim nächsten Mal abfragen kann, z. B.

if ($_device ne $device) {
  $_device=$device;
  mein Code ...
}


Beim sendenden Device kann man event_on_change_reading-Attribut setzen, damit bleiben Events mit gleichem Inhalt schon mal aus.

[PSI69]

Mahlzeit!

Ich bin mir bewußt - das folgende ist kein DOIF Problem, sondern Perl generell und meinem Unverständnis geschuldet...

Ich habe in einem DOIF im Perl Mode folgende Funktion:

Code: [Auswählen]

  sub $SELF_KalenderEvents {
    my $iCalEvents = "";

    ## Events für Heute besorgen
    $iCalEvents = fhem("get Kalender.iCloud events limit:when=today");

    if(length($iCalEvents) != 0){
      ## Auf *ferien oder Feiertag prüfen
      if(($iCalEvents =~ ".*ferien.*") || ($iCalEvents =~ ".*Feiertag.*") || ($iCalEvents =~ ".*Urlaub.*")){
        $SELF_DebugMessage("setze Dummy 'Jalousien.Ferien' auf 'on'");
        fhem_set"Jalousien.Ferien on";
      }
      else{
        $SELF_DebugMessage("Termine '$iCalEvents' enthalten kein Schlüsselwort");
      }
    }
  }

So lange der 'fhem("get...' - Aufruf Daten zurück liefert, klappt alles super. Werden allerdings keine Kalendereinträge gefunden, erfolgt folgende Fehlermeldung (Warnung):

Code: [Auswählen]

2021.04.27 09:28:24 1: PERL WARNING: Use of uninitialized value $iCalEvents in numeric ne (!=) at (eval 2599711) line 18.
2021.04.27 09:28:24 3: eval: di_p_Jalousien_Ferien: warning in condition c03

Also, die Prüfung der Variable auf Inhalt mittels 'if(length($iCalEvents) != 0)' bringt mir die Warnung; hm.

Kommentiere ich '$iCalEvents = fhem("get Kalender.iCloud events limit:when=today");' komplett aus, entfällt die Warnung, denn die Variable ist ja mit 'my $iCalEvents = "";' initialisiert. Irgend etwas 'macht' also der 'fhem("get...' - Aufruf bei leeren Daten damit.

Nun zur Frage des Tages: Wie fange ich das 'nicht Zurückgeben' von Kalenderdaten sauber (ohne Warnung im Logfile) ab?
Bin dankbar für jeden Hinweis...

Peter

[Damian]

ganz einfach:

if (defined $iCalEvents and length($iCalEvents) != 0){

[PSI69]

ganz einfach:

... wenn man es weiß - ich ja jetzt auch .
Danke Peter