[gelöst] Nochmals HMW_LC_BL1_DR und UZSU Smartvisu

Begonnen von Funsailor, 25 April 2022, 15:49:42

Vorheriges Thema - Nächstes Thema

Funsailor

#30
Hallo zusammen,
ich setze mein Monolog fort und berichte ....
Ich habe jetzt auch meine Selbstbau - CUL wieder repariert und damit mein Testsystem um Homematic-Devices erweitert. Desweiteren habe ich ein HM-LC-SW1-BA-PCB - Device (mit Relais, dann höre ich wenigstens wenn das Teil schaltet  8))  als WohnZimmerTestschalter hinzugefügt.
Das Teil dann in SmartVISU eingebaut, UZSU hinzu und ...
Die UZSU geht im Develop-Branch überhaupt nicht, da werden auch für das HM Device keine Schaltzeiten angelegt.

Wieder auf den Master-Branch umgestellt... Alles prima, das Relais klappert in den festgelegten Zeiten.

Irgendwie läuft da beim mir etwas total schief...

Folgendes habe ich gemacht:
Update FHEM .....
Restart FHEM...
Nach der Installation von smartVISU 3.3.1 habe ich lediglich meine Abgespeckt "Wohnungs"-Page hinzugefügt und die Config.ini angepasst.

Zum testen habe ich einfach die beiden Verzeichnisse /opt/fhem/www/ und /opt/fhem/FHEM/ nach /www dev/ bzw. /FHEM dev/ kopiert.
In die kopierten Verzeichnisse habe ich dann die Dateien aus
https://github.com/wvhn/fronthem/tree/develop
hinkopiert.

Rechte gesetzt...
FHEM gestoppt...
Die Verzeichnisse umbenannt: 
                                            /www/ -> /www default/
                                            /www dev/ -> /www/
                                            /FHEM/ -> /FHEM default/
                                            /FHEM dev/ -> /FHEM/
FHEM gestartet...
smartVISU ctrl+F5 (Cache ist aus)


Habe ich irgendetwas vergessen?   :-[










- Asus PN 41- mapleCul V1.24.01 - FHEMDuino - FHEM 6.2 - HUE Bridge - ESPEasy Bridge -  Milight HUB - smartVISU 3.40 -

Funsailor

Ich berichte mal weiter...
Wenn ich hier von Master bzw. Develop Spreche, beziehe ich mich auf die entsprechenden Branches von Wolframs GitHub.

Beim Master werden die Zeiten für HM-Devices richtig angelegt:
2023-02-14 14:50:24.406 Global global DELETED wdt_uzsu_ActorWeihnachtsBeleuchtung_FlurOG_0
2023-02-14 14:50:24.443 Global global DELETED wdt_uzsu_ActorWeihnachtsBeleuchtung_FlurOG_1
2023-02-14 14:50:24.454 WeekdayTimer wdt_uzsu_ActorWeihnachtsBeleuchtung_FlurOG_0 inactive
2023-02-14 14:50:24.456 WeekdayTimer wdt_uzsu_ActorWeihnachtsBeleuchtung_FlurOG_0 active
2023-02-14 14:50:24.458 WeekdayTimer wdt_uzsu_ActorWeihnachtsBeleuchtung_FlurOG_0 nextUpdate: 2023-02-14 22:02:00
2023-02-14 14:50:24.458 WeekdayTimer wdt_uzsu_ActorWeihnachtsBeleuchtung_FlurOG_0 nextValue: on
2023-02-14 14:50:24.458 WeekdayTimer wdt_uzsu_ActorWeihnachtsBeleuchtung_FlurOG_0 currValue: on
2023-02-14 14:50:24.503 Global global DEFINED wdt_uzsu_ActorWeihnachtsBeleuchtung_FlurOG_0
2023-02-14 14:50:24.505 Global global ATTR wdt_uzsu_ActorWeihnachtsBeleuchtung_FlurOG_0 room UZSU
2023-02-14 14:50:24.508 Global global ATTR wdt_uzsu_ActorWeihnachtsBeleuchtung_FlurOG_0 group ActorWeihnachtsBeleuchtung_FlurOG
2023-02-14 14:50:24.510 WeekdayTimer wdt_uzsu_ActorWeihnachtsBeleuchtung_FlurOG_0 weekdays: MO,TU,WE,TH,FR,SA,SU|{sunset_abs("REAL",960,,"22:02")}|on
2023-02-14 14:50:24.521 Global global MODIFIED rg_uzsu_ActorWeihnachtsBeleuchtung_FlurOG
2023-02-14 14:50:24.524 Global global ATTR rg_uzsu_ActorWeihnachtsBeleuchtung_FlurOG room UZSU
2023-02-14 14:50:24.530 WeekdayTimer wdt_uzsu_ActorWeihnachtsBeleuchtung_FlurOG_1 inactive
2023-02-14 14:50:24.532 WeekdayTimer wdt_uzsu_ActorWeihnachtsBeleuchtung_FlurOG_1 active
2023-02-14 14:50:24.534 WeekdayTimer wdt_uzsu_ActorWeihnachtsBeleuchtung_FlurOG_1 nextUpdate: 2023-02-14 23:30:00
2023-02-14 14:50:24.534 WeekdayTimer wdt_uzsu_ActorWeihnachtsBeleuchtung_FlurOG_1 nextValue: off
2023-02-14 14:50:24.534 WeekdayTimer wdt_uzsu_ActorWeihnachtsBeleuchtung_FlurOG_1 currValue: off
2023-02-14 14:50:24.577 Global global DEFINED wdt_uzsu_ActorWeihnachtsBeleuchtung_FlurOG_1
2023-02-14 14:50:24.580 Global global ATTR wdt_uzsu_ActorWeihnachtsBeleuchtung_FlurOG_1 room UZSU
2023-02-14 14:50:24.582 Global global ATTR wdt_uzsu_ActorWeihnachtsBeleuchtung_FlurOG_1 group ActorWeihnachtsBeleuchtung_FlurOG
2023-02-14 14:50:24.584 WeekdayTimer wdt_uzsu_ActorWeihnachtsBeleuchtung_FlurOG_1 weekdays: MO,TU,WE,TH,FR,SA,SU|{sunset_abs("REAL",4500,,"23:30")}|off
2023-02-14 14:50:24.594 Global global MODIFIED rg_uzsu_ActorWeihnachtsBeleuchtung_FlurOG
2023-02-14 14:50:24.597 Global global ATTR rg_uzsu_ActorWeihnachtsBeleuchtung_FlurOG room UZSU
2023-02-14 14:50:24.601 WeekdayTimer wdt_uzsu_ActorWeihnachtsBeleuchtung_FlurOG_0 disabled: 0
2023-02-14 14:50:24.607 WeekdayTimer wdt_uzsu_ActorWeihnachtsBeleuchtung_FlurOG_0 inactive
2023-02-14 14:50:24.608 WeekdayTimer wdt_uzsu_ActorWeihnachtsBeleuchtung_FlurOG_0 active
2023-02-14 14:50:24.610 WeekdayTimer wdt_uzsu_ActorWeihnachtsBeleuchtung_FlurOG_0 nextUpdate: 2023-02-14 22:02:00
2023-02-14 14:50:24.610 WeekdayTimer wdt_uzsu_ActorWeihnachtsBeleuchtung_FlurOG_0 nextValue: on
2023-02-14 14:50:24.610 WeekdayTimer wdt_uzsu_ActorWeihnachtsBeleuchtung_FlurOG_0 currValue: on
2023-02-14 14:50:24.613 Global global ATTR wdt_uzsu_ActorWeihnachtsBeleuchtung_FlurOG_0 disable 0
2023-02-14 14:50:24.615 WeekdayTimer wdt_uzsu_ActorWeihnachtsBeleuchtung_FlurOG_1 disabled: 0
2023-02-14 14:50:24.620 WeekdayTimer wdt_uzsu_ActorWeihnachtsBeleuchtung_FlurOG_1 inactive
2023-02-14 14:50:24.622 WeekdayTimer wdt_uzsu_ActorWeihnachtsBeleuchtung_FlurOG_1 active
2023-02-14 14:50:24.624 WeekdayTimer wdt_uzsu_ActorWeihnachtsBeleuchtung_FlurOG_1 nextUpdate: 2023-02-14 23:30:00
2023-02-14 14:50:24.624 WeekdayTimer wdt_uzsu_ActorWeihnachtsBeleuchtung_FlurOG_1 nextValue: off
2023-02-14 14:50:24.624 WeekdayTimer wdt_uzsu_ActorWeihnachtsBeleuchtung_FlurOG_1 currValue: off
2023-02-14 14:50:24.627 Global global ATTR wdt_uzsu_ActorWeihnachtsBeleuchtung_FlurOG_1 disable 0
2023-02-14 14:50:24.627 CUL_HM ActorWeihnachtsBeleuchtung_FlurOG uzsu: {"active":true,"list":[{"timeMin":"","condition":{"value":"","type":"String","active":false,"deviceString":""},"rrule":"FREQ=WEEKLY;BYDAY=MO,TU,WE,TH,FR,SA,SU","time":"sunset+16m<22:02","timeCron":"sunset","value":"on","timeMax":"22:02","holiday":{"weekend":false,"workday":false},"active":true,"event":"sunset","delayedExec":{"type":"String","deviceString":"","active":false,"value":""},"timeOffset":"16","timeOffsetType":"m"},{"timeMin":"","condition":{"active":false,"deviceString":"","type":"String","value":""},"timeMax":"23:30","value":"off","holiday":{"workday":false,"weekend":false},"event":"sunset","timeOffset":"75","timeOffsetType":"m","rrule":"FREQ=WEEKLY;BYDAY=MO,TU,WE,TH,FR,SA,SU","time":"sunset+75m<23:30","timeCron":"sunset","active":true,"delayedExec":{"deviceString":"","active":false,"type":"String","value":""}}]}

Zuerst werden die alten Einträge gelöscht, dann die neuen angelgt.

Beim Develop sieht das so aus:
2023-02-14 14:47:24 WeekdayTimer wdt_uzsu_WohnZimmerTestSchalter_0 inactive
2023-02-14 14:47:24 WeekdayTimer wdt_uzsu_WohnZimmerTestSchalter_0 active
2023-02-14 14:47:24 WeekdayTimer wdt_uzsu_WohnZimmerTestSchalter_0 nextUpdate: 2023-02-14 19:50:00
2023-02-14 14:47:24 WeekdayTimer wdt_uzsu_WohnZimmerTestSchalter_0 nextValue: on
2023-02-14 14:47:24 WeekdayTimer wdt_uzsu_WohnZimmerTestSchalter_0 currValue: on
2023-02-14 14:47:24 Global global DEFINED wdt_uzsu_WohnZimmerTestSchalter_0
2023-02-14 14:47:24 Global global ATTR wdt_uzsu_WohnZimmerTestSchalter_0 room UZSU
2023-02-14 14:47:24 Global global ATTR wdt_uzsu_WohnZimmerTestSchalter_0 group WohnZimmerTestSchalter
2023-02-14 14:47:24 WeekdayTimer wdt_uzsu_WohnZimmerTestSchalter_0 weekdays: MO,TU,WE,TH,FR,SA,SU|19:50|on
2023-02-14 14:47:24 Global global DEFINED rg_uzsu_WohnZimmerTestSchalter
2023-02-14 14:47:24 Global global ATTR rg_uzsu_WohnZimmerTestSchalter room UZSU
2023-02-14 14:47:24 WeekdayTimer wdt_uzsu_WohnZimmerTestSchalter_1 inactive
2023-02-14 14:47:24 WeekdayTimer wdt_uzsu_WohnZimmerTestSchalter_1 active
2023-02-14 14:47:24 WeekdayTimer wdt_uzsu_WohnZimmerTestSchalter_1 nextUpdate: 2023-02-14 19:51:00
2023-02-14 14:47:24 WeekdayTimer wdt_uzsu_WohnZimmerTestSchalter_1 nextValue: off
2023-02-14 14:47:24 WeekdayTimer wdt_uzsu_WohnZimmerTestSchalter_1 currValue: off
2023-02-14 14:47:24 Global global DEFINED wdt_uzsu_WohnZimmerTestSchalter_1
2023-02-14 14:47:24 Global global ATTR wdt_uzsu_WohnZimmerTestSchalter_1 room UZSU
2023-02-14 14:47:24 Global global ATTR wdt_uzsu_WohnZimmerTestSchalter_1 group WohnZimmerTestSchalter
2023-02-14 14:47:24 WeekdayTimer wdt_uzsu_WohnZimmerTestSchalter_1 weekdays: MO,TU,WE,TH,FR,SA,SU|19:51|off
2023-02-14 14:47:24 Global global MODIFIED rg_uzsu_WohnZimmerTestSchalter
2023-02-14 14:47:24 Global global ATTR rg_uzsu_WohnZimmerTestSchalter room UZSU
2023-02-14 14:47:24 WeekdayTimer wdt_uzsu_WohnZimmerTestSchalter_0 disabled: 0
2023-02-14 14:47:24 WeekdayTimer wdt_uzsu_WohnZimmerTestSchalter_0 inactive
2023-02-14 14:47:24 WeekdayTimer wdt_uzsu_WohnZimmerTestSchalter_0 active
2023-02-14 14:47:24 WeekdayTimer wdt_uzsu_WohnZimmerTestSchalter_0 nextUpdate: 2023-02-14 19:50:00
2023-02-14 14:47:24 WeekdayTimer wdt_uzsu_WohnZimmerTestSchalter_0 nextValue: on
2023-02-14 14:47:24 WeekdayTimer wdt_uzsu_WohnZimmerTestSchalter_0 currValue: on
2023-02-14 14:47:24 Global global ATTR wdt_uzsu_WohnZimmerTestSchalter_0 disable 0
2023-02-14 14:47:24 WeekdayTimer wdt_uzsu_WohnZimmerTestSchalter_1 disabled: 0
2023-02-14 14:47:24 WeekdayTimer wdt_uzsu_WohnZimmerTestSchalter_1 inactive
2023-02-14 14:47:24 WeekdayTimer wdt_uzsu_WohnZimmerTestSchalter_1 active
2023-02-14 14:47:24 WeekdayTimer wdt_uzsu_WohnZimmerTestSchalter_1 nextUpdate: 2023-02-14 19:51:00
2023-02-14 14:47:24 WeekdayTimer wdt_uzsu_WohnZimmerTestSchalter_1 nextValue: off
2023-02-14 14:47:24 WeekdayTimer wdt_uzsu_WohnZimmerTestSchalter_1 currValue: off
2023-02-14 14:47:24 Global global ATTR wdt_uzsu_WohnZimmerTestSchalter_1 disable 0
2023-02-14 14:47:24 Global global DELETED wdt_uzsu_WohnZimmerTestSchalter_0
2023-02-14 14:47:24 Global global DELETED wdt_uzsu_WohnZimmerTestSchalter_1
2023-02-14 14:47:24 Global global DELETED rg_uzsu_WohnZimmerTestSchalter


Seltsamerweise wird hier am Ende alles wieder gelöscht....  :o
Wenn ich mir in der "99_fronthemUtils.pm" die Funktion "UZSU_execute" anschaue, bekomme ich so meine Zweifel was da abgeht.
Eigentlich wird hier zuerst "delete wdt_uzsu..." aufgerufen und danach die ganzen Einträge erzeugt.
Kann mir das jemand erklären?

So sieht das in der Develop Version aus:

sub UZSU_execute($$;$)
{
  my ($device, $uzsu, $save) = @_;
  $save = (defined($save) ? $save : "na");
  my $rg = AttrVal('rg_uzsu_'.$device, "room", "na");   
  fhem('delete wdt_uzsu_'.$device.'.*') if($rg ne "na");
  fhem('delete rg_uzsu_'.$device) if($rg ne "na");

  for (my $i = 0; $i < @{$uzsu->{list}}; $i++) {
    if ($uzsu->{list}[$i]->{active}) {
      my %rrule = UZSU_getRrules($uzsu->{list}[$i]{rrule});
      my $holiday = $uzsu->{list}[$i]{holiday}{weekend} && $uzsu->{list}[$i]{holiday}{workday} ? '' : $uzsu->{list}[$i]{holiday}{weekend} ? $rrule{'BYDAY'} ne '' ? ',$we' : '$we' : $uzsu->{list}[$i]{holiday}{workday} ? $rrule{'BYDAY'} ne '' ? ',!$we' : '!$we' : '';

      my $time = $uzsu->{list}[$i]{event} eq "time" ?  $uzsu->{list}[$i]{time} : '{'.$uzsu->{list}[$i]->{event} . '_abs("REAL"' . ($uzsu->{list}[$i]->{timeOffset} ne '' ? ',' . $uzsu->{list}[$i]->{timeOffset} * 60 : '') . ($uzsu->{list}[$i]->{timeMin} ne '' ? ', "' . $uzsu->{list}[$i]->{timeMin} . '"' : '') . ($uzsu->{list}[$i]->{timeMax} ne '' ? ', "' . $uzsu->{list}[$i]->{timeMax} . '"' : '') . ')}';
      my $condition = UZSU_getCommand($uzsu->{list}[$i]{condition});

      my $weekdayTimer = $rrule{'BYDAY'} . $holiday . ($rrule{'BYDAY'} ne '' || $holiday ne '' ? "|" : '') . $time . "|" . $uzsu->{list}[$i]{value};
      my $delayedExec = UZSU_getCommand($uzsu->{list}[$i]{delayedExec});

      fhem('defmod wdt_uzsu_' . $device . '_' . $i . ' WeekdayTimer ' . $device . ' en ' . $weekdayTimer . $condition);
      fhem('attr wdt_uzsu_' . $device . '_' . $i . ' room UZSU');
      fhem('attr wdt_uzsu_' . $device . '_' . $i . ' group ' . $device);
      fhem('setreading wdt_uzsu_' . $device . '_' . $i . ' weekdays ' . $weekdayTimer);
      fhem('defmod rg_uzsu_' . $device . ' readingsGroup wdt_uzsu_' . $device . '.*');
      fhem('attr rg_uzsu_' . $device . ' room UZSU');
  if ($delayedExec) {
        fhem('attr wdt_uzsu_' . $device . '_' . $i . ' delayedExecutionCond ' . $delayedExec);
      }
    }
  }
  if ($uzsu->{active}) {
    fhem('attr NAME=wdt_uzsu_' . $device . '_.*' . ' disable 0');
  }
  else {
    fhem('attr NAME=wdt_uzsu_' . $device . '_.*' . ' disable 1');
  }
  fhem('save', 1) if ($save eq 'save');
}


Hier noch die - UZSU_execute Funktion aus dem Master:
sub UZSU_execute($$;$)
{
my ($device, $uzsu, $save) = @_;
$uzsu = decode_json($uzsu);

fhem('delete wdt_uzsu_'.$device.'.*');

for (my $i = 0; $i < @{$uzsu->{list}}; $i++) {
if ($uzsu->{list}[$i]->{active}) {
my %rrule = UZSU_getRrules($uzsu->{list}[$i]{rrule});
my $holiday = $uzsu->{list}[$i]{holiday}{weekend} && $uzsu->{list}[$i]{holiday}{workday} ? '' : $uzsu->{list}[$i]{holiday}{weekend} ? $rrule{'BYDAY'} ne '' ? ',$we' : '$we' : $uzsu->{list}[$i]{holiday}{workday} ? $rrule{'BYDAY'} ne '' ? ',!$we' : '!$we' : '';
my $time = $uzsu->{list}[$i]{event} eq "time" ?  $uzsu->{list}[$i]{time} : '{'.$uzsu->{list}[$i]->{event} .'_abs("REAL",' . $uzsu->{list}[$i]->{timeOffset} * 60 . ',' . ($uzsu->{list}[$i]->{timeMin} ne '' ? '"' . $uzsu->{list}[$i]->{timeMin} . '"' : '') . ',' . ($uzsu->{list}[$i]->{timeMax} ne '' ? '"' . $uzsu->{list}[$i]->{timeMax} . '"' : '') . ')}';
my $condition = UZSU_getCommand($uzsu->{list}[$i]{condition});

my $weekdayTimer = $rrule{'BYDAY'} . $holiday . ($rrule{'BYDAY'} ne '' || $holiday ne '' ? "|" : '') . $time . "|" . $uzsu->{list}[$i]{value};
my $delayedExec = UZSU_getCommand($uzsu->{list}[$i]{delayedExec});

fhem('defmod wdt_uzsu_' . $device . '_' . $i . ' WeekdayTimer ' . $device . ' en ' . $weekdayTimer . $condition);
fhem('attr wdt_uzsu_' . $device . '_' . $i . ' room UZSU');
fhem('attr wdt_uzsu_' . $device . '_' . $i . ' group ' . $device);
fhem('setreading wdt_uzsu_' . $device . '_' . $i . ' weekdays ' . $weekdayTimer);
fhem('defmod rg_uzsu_' . $device . ' readingsgroup wdt_uzsu_' . $device . '.*');
fhem('attr rg_uzsu_' . $device . ' room UZSU');
if ($delayedExec) {
fhem('attr wdt_uzsu_' . $device . '_' . $i . ' delayedExecutionCond ' . $delayedExec);
}
}
}
if ($uzsu->{active}) {
fhem('attr NAME=wdt_uzsu_' . $device . '_.*' . ' disable 0');
}
else {
fhem('attr NAME=wdt_uzsu_' . $device . '_.*' . ' disable 1');
}
fhem('save', 1) if ($save eq 'save');
}


Die Ausgaben der Aktionen habe ich aus dem Event Monitor mit Verbose=5 im fronthem-Device herauskopiert...
- Asus PN 41- mapleCul V1.24.01 - FHEMDuino - FHEM 6.2 - HUE Bridge - ESPEasy Bridge -  Milight HUB - smartVISU 3.40 -

wvhn

Hallo MIchael,

raman hat ja geschrieben, dass die UZSU_Execute bei der Version im develop branch nicht mehr per notify aufgerufen wird, sondern direkt bei Änderung der UZSU-Werte.
Nach meinem laienhaften Verständnis müsste das notify dann gelöscht werden, oder?

Kann es sein, dass Du das notify für die UZSU noch aktiv hast und dies das Löschen der wdts nach dem korrekten Setzen verursacht?

Gruß
Wolfram

Funsailor

#33
Hallo Wolfram,
jeep... das war es. Vielen Dank für das öffnen meiner "Scheuklappen". ::)
Ich hatte den Satz:
"UZSU_execute" wird nicht mehr per Notify getriggert, sondern wird beim Anfordern der Daten von smartVisu ausgeführt.
Das Reading "uzsu" ..... "

Auf das
setreading <device> uzsu {}
bezogen.
Hab mich heute ein wenig mit perl auseinandergesetzt und mir den Ablauf der "UZSU_execute" in eine Datei reingeschrieben. Dabei hatte ich festgestellt, das "UZSU_Execute" 2 mal aufgerufen wird....
Das wäre dann geklärt!

Aber wie sind diese Zeile zu verstehen?

 
  fhem('delete wdt_uzsu_'.$device.'.*') if($rg ne "na");
  fhem('delete rg_uzsu_'.$device) if($rg ne "na");


Das "if" nach dem Funktionsaufruf scheint zu bewirken, das die fhem Anweisung nicht ausgeführt wird (In $rg steht "UZSU")

Ich war gerade dabei in der Perl Doku zu suchen was ein nachgestelltes if bewirkt, von C/C++ etc kenne ich das nicht!

Kann mir jemand diesen Konstrukt erklären?

Die Condition kommt jetzt an:

Internals:
   CFGFN     
   COMMAND   
   CONDITION  (set $NAME level $EVENT)
   DEF        WohnZimmerTestBlind en MO,TU,WE,TH,FR,SA,SU|17:33|89 (set $NAME level  $EVENT)
   DEVICE     WohnZimmerTestBlind
   FUUID      63ebbae4-f33f-8046-00d7-b47e618bdc63aa9c
   GlobalDaylistSpec
   LANGUAGE   en
   NAME       wdt_uzsu_WohnZimmerTestBlind_1
   NR         242
   Profil 0: Sunday 17:33:00 89,
   Profil 1: Monday 17:33:00 89,
   Profil 2: Tuesday 17:33:00 89,
   Profil 3: Wednesday 17:33:00 89,
   Profil 4: Thursday 17:33:00 89,
   Profil 5: Friday 17:33:00 89,
   Profil 6: Saturday 17:33:00 89,
   STATE      active
   STILLDONETIME 0
   TYPE       WeekdayTimer
   eventCount 8
   setModifier
   READINGS:
     2023-02-14 17:46:28   currValue       89


Diese wird im WeekdayTimer aber nicht verarbeitet... Wer ist da jetzt zuständig?

LG
Michael
- Asus PN 41- mapleCul V1.24.01 - FHEMDuino - FHEM 6.2 - HUE Bridge - ESPEasy Bridge -  Milight HUB - smartVISU 3.40 -

wvhn

Für die Condition und DelayedExec wird das Kommando von der Funktion UZSU_getCommand() geparst. Ist der eingestellte Typ "string", sind 3 Möglichkeiten vorgesehen:

  • ein Kommando, das mit "fhem" startet und ggfls. noch eine if-Bedingung enthält, wird in geschweifte Klammern gesetzt und zurück gegeben
  • Kommandos, die auf setstate, setreading oder set mit einem nachfolgenden string lauten, werden mit "$NAME" und "$EVENT" ergänzt. Also führt die EIngabe von "set level" im UZSU-Popup zu einer Rückgabe von " set $NAME level $EVENT"
  • jeder andere String wird in eine runde Klammer gepackt
Conditions werden in der genannten Form an den defmod-Befehl angehängt, delayedExec als Attribut "delayedExecutionCond" für das jeweilige Device definiert.

Gruß
Wolfram

Funsailor

Hallo Wolfram,
jeep, die Condition wird ja eingetragen.
Internals:
   CFGFN     
   COMMAND   
   CONDITION  (set $NAME level $EVENT)


Das Problem ist aber, das "set $NAME level $EVENT" in das attribut commandTemplate übertragen werden muss, daran hapert es
- Asus PN 41- mapleCul V1.24.01 - FHEMDuino - FHEM 6.2 - HUE Bridge - ESPEasy Bridge -  Milight HUB - smartVISU 3.40 -

wvhn

ich sehe da eine runde Klammer um die condition. Keine Ahnung, ob das etwas zu bedeuten hat, aber ich würde auf einen falschen String im UZSU-Popup tippen. Hast Du "set level" verwendet?

Funsailor

#37
in "Condition" der wdt_uzsu_.... wird genau das eingetragen was ich im Feld "Condition" in der UZSU eintrage. Die Klammer wird von FHEM erweitert...
Ich hatte im obigen Beispiel in der UZSU folgendes eingetragen:

set $NAME level $EVENT

Trage ich in der UZSU
set level
ein, wird in der wdt_uzsu_....

CONDITION (set level )

eingetragen.
Auf das Attribut commandTemplate hat das in keinem Fall eine Auswirkung.

Edit:
Aber Raman hat ja schon darauf hingewiesen:


@Funsailor:
.....
Zum anderen werden für "WeekdayTimer" in dieser Funktion nur "conditions" und keine "commands" generiert, die statt "commandTemplate" ausgeführt wird. Keine Ahnung, ob das jemals in der Kombination "WeekdayTimer" ging!?



Edit2:
Im 98_weekdayTimer wird in der Funktion WDT_Start folgende Abfrage gemacht:


$attr{$name}{commandTemplate} =
'set $NAME '. checkIfDeviceIsHeatingType($hash) .' $EVENT' if !defined attr{$name}{commandTemplate};


Und nur bei einem HeatingDevice wird die Condition auch eingetragen....  :-[

So kann das ja nicht funktionieren, oder?
Da müsste man wahrscheinlich auf ein HMW - Device (in meinem Fall auf ein Rolladendevice) abprüfen um dann die richtige Bedingung enpflegen.

Spaßhalber habe ich die Anweisung geändert:


  $attr{$name}{commandTemplate} =
     'set $NAME '. "level" .' $EVENT' if !defined $attr{$name}{commandTemplate}; 


Dann funktioniert das wie gewünscht. Aber das hat dann Auswirkung bei allen Devices, also nicht Zielführend  ;)

Ich habe mir mal die aktuellen Condition Ausdrucken lassen:

  _Profile ($hash);
  delete $hash->{DELAYED};
  delete $hash->{DELAYED_IDX};

  open(MYLOG1, ">>WeekdayTimer.txt");   
  print(MYLOG1 "WDT_Start\n");
  print(MYLOG1 "conditionOrCommand: $conditionOrCommand\n");
  close(MYLOG1);


  $attr{$name}{commandTemplate} =
     'set $NAME '. checkIfDeviceIsHeatingType($hash) .' $EVENT' if !defined $attr{$name}{commandTemplate};
     
     
##  $attr{$name}{commandTemplate} =
##     'set $NAME '. "level" .' $EVENT' if !defined $attr{$name}{commandTemplate};     

  WDT_SetTimerOfDay({ HASH => $hash});


Dann sehe ich folgende Ausgabe


WDT_Start
conditionOrCommand: set $NAME level $EVENT
WDT_Start
conditionOrCommand: set $NAME level $EVENT


Wenn ich in die im Bild zu sehende Einstellung vornehme:

- Asus PN 41- mapleCul V1.24.01 - FHEMDuino - FHEM 6.2 - HUE Bridge - ESPEasy Bridge -  Milight HUB - smartVISU 3.40 -

wvhn

#38
IMHO funktioniert das Regex in der UZSU_getCommand($) nicht. Kannst Du dem mal auf den Grund gehen?

Die betreffenden Zeilen sind:

elsif($command->{deviceString} =~ /(setstate|setreading|set).([a-zA-Z]+)$/)
    {
      return ' ' . $1 . ' $NAME ' . $2 . ' $EVENT';
    }

Probiere doch mal auf der Kommandozeile folgendes aus:
{"set level" ~= /(setstate|setreading|set).([a-zA-Z]+)$/}

Evtl. kommen in $command->{deviceString} aus UZSU noch Leerzeichen mit?

EDIT: ein oder mehrere Leerzeichen am Ende würden dazu führen, dass ein Befehl ,,set level " nicht erkannt wird. Das kann man ändern, indem man das $ Zeichen am Ende des Regex entfernt.

EDIT 2:
wir diskutieren jetzt gerade 2 Themen:
- kommen die Eingaben im UZSU-Widget via UZSU_Execute in korrekter Syntax bei fhem an?
- was macht fhem mit den Kommandos?

Für dieses Forum hier ist erstmal die erste Frage relevant. Die zweite kann wahrscheinlich besser an anderer Stelle im fhem-Forum geklärt werden.

Aus meiner Sicht widersprechen sich die Informationen in Deinen letzten Posts bzw. sind unter unterschiedlichen Bedingungen zustande gekommen. Oben hast Du geschrieben, dass immer exakt das in der Condition steht, was Du im Widget eingetragen hast.
CONDITION (set level ) Das ist meines Erachtens nach ein Fehler und man sieht auch das überschüssige Leerzeichen hinter "level".

In Deinem letzten Post stimmt die Condition hingegen bei gleicher (?) Eingabe:
conditionOrCommand: set $NAME level $EVENT

Wie passt das zusammen? Mir wäre Aufklärung an dieser Stelle sehr wichtig, um die zuverlässige Funktion des Codes im develop branch nachzuweisen oder durch Änderungen herzustellen. Dazu kann man sich auch die Syntax des fhem-Kommandos ansehen, das die UZSU_Execute zusammen baut und diese Zeile ggfls. durch manuelle Eingabe in die Kommandozeile testen:
bisher (siehe oben 2 Ergebnisse aus Deinen Posts):
fhem('defmod wdt_uzsu_WohnZimmerTestBlind_1 WeekdayTimer WohnZimmerTestBlind en MO,TU,WE,TH,FR,SA,SU|17:33|89 (set $NAME level  $EVENT))
oder
fhem('defmod wdt_uzsu_WohnZimmerTestBlind_1 WeekdayTimer WohnZimmerTestBlind en MO,TU,WE,TH,FR,SA,SU|17:33|89 (set level ))


IMHO wäre korrekt:
fhem('defmod wdt_uzsu_WohnZimmerTestBlind_1 WeekdayTimer WohnZimmerTestBlind en MO,TU,WE,TH,FR,SA,SU|17:33|89 set $NAME level  $EVENT)

Gruß
Wolfram

wvhn

Ich habe jetzt mal folgende Hinweise in die 99_fronthemUtils.pm im develop branch übernommen:

# ACHTUNG: falls von einer vorherigen fronthem-Version noch das notify definiert ist
# " define UZSU notify .*:uzsu:.* { UZSU_execute($NAME, $EVTPART1) } "
# dann muss dieses gelöscht werden, da UZSU_Execute sonst doppelt ausgeführt wird
# und die Einstellungen wieder löscht!!
#
# Bei den Angaben für Conditions und delayedExec muss darauf geachtet werden, dass
# am Ende der jeweiligen Strings keine überzähligen Leerzeichen vorkommen.


Für eine Rückmeldung / Bestätigung durch Tests zu meinen diversen letzten EDITs im letzen Post (sorry) wäre ich noch dankbar.

Gruß
Wolfram

Funsailor

#40
Zitat von: wvhn am 14 Februar 2023, 22:05:41
IMHO funktioniert das Regex in der UZSU_getCommand($) nicht. Kannst Du dem mal auf den Grund gehen?

Okay, habe den "Fehler" gefunden. Bin mal wieder über eine Flüchtigkeit gestolpert.
Ich hatte am Anfang immer 2 Zeiten eingetragen und beide wdt_uzsu_ in je einem TAB im Firefox offen. Nach einer Änderung im Widget habe ich dann immer nur in einem Tab CTRL+F5 gemacht... im andere TAB wurde dann das Cache nicht gelöscht :( .

Die Datenübertragung der UZSU zu FHEM funktioniert!

Sobald ein falsches Zeichen nach set kommt, wird die Condition in Klammer gesetzt.

  • Ein Blank vor dem set ist OK.
  • Ein Blank (oder anderes Zeichen) nach dem set erzeugt den Fehler
  • Ein Blank (oder anderes Zeichen) nach dem level erzeugt den Fehler

Sorry das ich gestern für Verwirrung gesorgt hatte :-[ ich hoffe ich habe das jetzt soweit klargestellt.  :)

Praktisch wäre es, wenn der String "set level" und die Aktivierung der Condition beim Neuanlegen einer weiteren Zeit automatisch eingefügt wird.  8)

Ich würde in deinem Hinweis erwähnen, das auch nach dem set nur ein Blank erlaubt ist!
Zitat# Bei den Angaben für Conditions und delayedExec muss darauf geachtet werden, dass
# am Ende der jeweiligen Strings keine überzähligen Leerzeichen vorkommen.

Wenn ich das richtig gesehen habe, kümmert sich Beta-User um die98_WeekdayTimer.pm... glaube aber nicht, das er hier noch mitliest.

Anpingen oder neues Thema?
- Asus PN 41- mapleCul V1.24.01 - FHEMDuino - FHEM 6.2 - HUE Bridge - ESPEasy Bridge -  Milight HUB - smartVISU 3.40 -

wvhn

Moin Michael,

ich hab einige Erfahrung mit Regex, wenn auch in anderen Programmiersprachen. Ich versuche mich mal schlau zu machen, was in Perl möglich ist, um dies etwas fehlertoleranter zu machen.
Ich melde mich nochmal bei Dir, wenn ich was zum Testen habe.

Parallel kannst Du in einem dafür geeigneten Forum das Thema Weekdaytimer ansprechen.

Gruß
Wolfram

wvhn

Probiere mal Zeile 286:
elsif($command->{deviceString} =~ /(setstate|setreading|set)\s+([a-zA-Z]+)\s*$/)

Gruß
Wolfram

Funsailor

Hi Wolfram,
jetzt werden Leerzeichen ignoriert!  8)
Prima...
- Asus PN 41- mapleCul V1.24.01 - FHEMDuino - FHEM 6.2 - HUE Bridge - ESPEasy Bridge -  Milight HUB - smartVISU 3.40 -

Funsailor

#44
Hi Wolfram,
im Weekday Modul wird ja hier das Attribut "commandTemplate" gesetzt:

  $attr{$name}{commandTemplate} =
     'set $NAME '. checkIfDeviceIsHeatingType($hash) .' $EVENT' if !defined $attr{$name}{commandTemplate};


Ich habe mal alle Readings der HMW - ausgelesen, damit könnte man erkennen das ein HMW-Rollladenantrieb angesprochen wird.
Oder man erzeugt das Template auf jeden Fall sobald eine gültige Condition eingetragen ist.
Wenn ich das hier richtig interpreiere, muss ich mich aber bis Ende nächste Woche gedulten:

Zitat von: Beta-User am 03 Februar 2023, 21:23:59
Hmmm, sieht in der Tat komisch aus. Ich hoffe, in der nächsten Woche mal dazu zu kommen, das mal intensiv anzusehen. Sonst bitte in 3 Wochen nochmal nachhaken!

Ich pass das mal in meiner Testumgebung folgendermaßen an und kläre das dann nächste Woche mit Beta-User ...


...
...
  my $isHeating         = checkIfDeviceIsHeatingType($hash);
...
...
  if ($isHeating)
  {
   $attr{$name}{commandTemplate} =
     'set $NAME '. checkIfDeviceIsHeatingType($hash) .' $EVENT' if !defined $attr{$name}{commandTemplate};
  }
  else
  {
   $attr{$name}{commandTemplate} = "$conditionOrCommand"; 
  }   
- Asus PN 41- mapleCul V1.24.01 - FHEMDuino - FHEM 6.2 - HUE Bridge - ESPEasy Bridge -  Milight HUB - smartVISU 3.40 -