Moin liebe Leute,
ich bin mal wieder zu blind >:(
In einer DOIF möchte ich entweder alle 60 Sekunden oder aber bei Auftreten eines Events von einem der insg. 17 Devices einen Trigger haben.
([+60] or [hz.*] or [ww.*] or [HW.*]) (set l_temp | [hzsp:state] | [hzvl:state] | [hzrl:state] | [wwsp:state] | [wwsh:state] | [wwvl:state] | [wwrl:state] | [wwzv:state] | [wwzr:state] | [HWBR:state] | [HWHP:state] | [HWWP:state] | [HWZP:state] | [res:state] | [HWi1:state] | [HWi2:state] | [HWi3:state] |)
Also [hz.*] z.B. klappt ja nicht; das läuft auf einen "error: Wrong timespec hz.*: either HH:MM:SS or {perlcode}". Auch ["hz.*"] und ein paar andere Versuche generieren Fehler dieser Art oder auch direkt in Perl ala "PERL WARNING: ^* matches null string many times in regex; marked by <-- HERE in m/^* <-- HERE $/ at fhem.pl line 4142."
Frage ist also, wie ich einen Event in einem der mit "hz..." oder "hw..." oder was auch immer beginnenden Devices erfassen kann, ohne jedes Device explizit aufführen zu müssen. Ich bin mir sicher, das es irgendwie geht, aber irgendwie bin ich heuer zu dumpf, um drauf zu kommen ...
Kann ich nicht nachvollziehen, bei mir funktioniert ["hz.*"], getestet mit
(["du.*"]) ({Log 1, "$EVENTS"})Ergebnis
Zitat2016.10.26 12:21:13 1: x1
Den Unterschied, den ich sehe, sind die "" bei Ellert ..??
Grüße
Stephan
... na wenn das so ist, war ich ja schon fast richtig; nur noch die beiden dargestellten Versuche zusammenfügen ...
([+60] or ["hz.*"] or ["ww.*"] or ["HW.*"]) (set l_temp blablub ...)
... und so tun? Probiere ich gleich mal ... (tictoc...)
Nö. Sobald ich das wie o.a. eintrage, erhalte ich wieder den Perl- Fehler "PERL WARNING: ^* matches null string many times in regex; marked by <-- HERE in m/^* <-- HERE $/ at fhem.pl line 4142.". Allerdings sind nun die Fehler mit der "error: Wrong timespec hz.*: either HH:MM:SS or {perlcode}" weg, die ja direkt in der GUI beim DOIF angezeigt wurden.
BTW: der PERL- Fehler taucht nur ein mal auf, wenn FHEM komplett neu gestartet wird, nicht aber bei einem ReReadCFG ...
gehts denn, wenn du *nur* "hz.*" verwendest? ohne das "or" ?
Grüße
Stephan
... gerade probiert ...
define l_set DOIF (["HW.*"]) (set l_temp blablub
... generiert ebenfalls beim Neustart des Systems den PERL- Fehler, aber nicht bei ReReadCFG und nicht im DOIF selber. Events werden von allem was mit HW... anfängt ausgelöst (HW = Hardware). Zumindest das ist ok und ja gewollt. Bleibt also die Frage, woher der PERL- Fehler kommt ...
Zeig mal bitte die attribute deiner HW.* devices. Ich suche gerade nach event*- Attributen, wie zb event-on-change oder event-on-update usw..
Zeile 4142 bezieht sich nämlich möglicherweise auf die feststellung von events..
Kannst du (davon unabhängig) mal ein device TEST anlegen (ohne attribute), und schauen, ob [TEST.*] funktioniert?
Stephan
Edit: ich kanns nicht nachstellen... bei mir geht bisher jede variante.. wann hast du das letzte update gemacht?
also die HW- Outputs sehen alle so aus (5 an der Zahl):
Internals:
CFGFN ./_HW/gpio_out.cfg
DEF 16
GPIO_Basedir /sys/class/gpio
NAME HWBR
NR 39
RPI_pin 16
STATE off
TYPE RPI_GPIO
WiringPi_gpio /usr/local/bin/gpio
Readings:
2016-10-26 17:06:48 Pinlevel low
2016-10-26 17:06:53 state off
Fhem:
interfaces switch
Attributes:
alias Öl- Brenner
devStateIcon off:sani_boiler@gray on:sani_boiler@red
direction output
group Aktoren
room KG.Heizung
sortby 1
webCmd :
Die HW- Inputs so (3 an der Zahl):
Internals:
CFGFN ./_HW/gpio_in.cfg
DEF 17
EXCEPT_FD 10
GPIO_Basedir /sys/class/gpio
NAME HWi1
NR 51
RPI_pin 17
STATE off
TYPE RPI_GPIO
WiringPi_gpio /usr/local/bin/gpio
lasttrg 1477493210.57009
Readings:
2016-10-26 17:01:29 Dblclick off
2016-10-26 17:01:29 Longpress off
2016-10-26 17:08:55 Pinlevel low
2016-10-26 17:01:29 state off
Fhem:
interfaces switch
Attributes:
active_low yes
alias Brenner Betrieb
devStateIcon off:sani_boiler@gray on:sani_boiler@red
direction input
group Rückmeldungen
interrupt both
pud_resistor off
room KG.Heizung
sortby 6
toggletostate yes
Das mit dem TEST- device probiere ich gleich mal; bin gerade etwas busy...
muss gleich los, fasse nochmal kurz meine Gedanken zusammen:
fhem aktuell?
Test-device probieren
Fehler tritt NUR an den HW-Devices auf? alle anderen funktionieren wie gewünscht?
Grüße
Stephan
zu 1: Ja, Update von gestern
zu 2: Kommt nachher
zu 3: Genau richtig. Alles andere verursachte nicht diesen Fehler
Zitat von: M_I_B am 26 Oktober 2016, 17:19:49
zu 1: Ja, Update von gestern
zu 2: Kommt nachher
zu 3: Genau richtig. Alles andere verursachte nicht diesen Fehler
was passiert bei:
define l_set DOIF (["^HW"]) (set l_temp blablub
@ Damian: Habe ich gerade ausprobiert: Selbe Fehlermeldung
@ abc2006: Test- Device: Keine (!) Fehlermeldung
Zusätzlicher Test: Zwei "echte" HM- Devices, Event abgegriffen mit "define LUM_set DOIF (["HM2BB"]) ..." (heißen okkinol HM2BB1 und HM2BB2). Keine (!) Fehlermeldung
Wäre jetzt auch meine nächste Frage gewesen, was passiert, wenn du die Devices vollständig auflistest, ohne regex.
["HM2BB"] reagiert tatsächlich auch auf Events von HM2BB2?
Nicht unmöglich ;-), irritiert mich aber...
grüße
Stephan
... ja, tatsächlich. Ich hatte vor längerer Zeit mal eine diesbezügliche Frage hier im Forum gestellt und bekam genau diesen Hint, um Events von mehreren Devices mit einem Schlag erfassen zu können, die alle mit den gleichen Namen beginnen.
Wenn ich das noch richtig im Kopf habe ist....
["HM2BB"] identisch mit [HM2BB1] or [HM2BB2] or [HM2BBx]
... resp sollte dann auch ...
["HW"] identisch sein mit [HWBR] or [HWHP] or [HWLP] or [HWZP] or [HWi1] or [HWi2] or [HWi3]
EDIT: Hier ein Beispiel, das es auch funktioniert. Die HM2BBx sind HM-Bewegungsmelder. Die Events sind von gerade eben...
Internals:
CFGFN /opt/fhem/_INC/00_Global_Sonne_real.cfg
DEF (["HM2BB"])
(set LUM W3 [LUM:W2], set LUM W2 [LUM:W1], set LUM W1 [LUM:W0], set LUM W0 {([HM2BB1:brightness]+[HM2BB2:brightness])/2})
(set LUM {(int((100*(([HM2BB1:brightness]+[HM2BB2:brightness])/2+0.5))/250))})
NAME LUM_set
NR 890
NTFY_ORDER 50-LUM_set
STATE cmd_1
TYPE DOIF
Readings:
2016-10-27 13:56:45 Device HM2BB2
2016-10-27 13:56:45 cmd 1.2
2016-10-27 13:56:45 cmd_event HM2BB2
2016-10-27 13:56:45 cmd_nr 1
2016-10-27 13:56:45 cmd_seqnr 2
2016-10-27 13:56:45 matched_event_c1_1 motion: off,noMotion
2016-10-27 13:56:45 state cmd_1
2016-10-27 13:54:05 timer_1_c1 27.10.2016 13:59:05
Condition:
0 EventDoIf('HM2BB',$hash,'',0)
Devices:
Do:
0:
0 set LUM W3 [LUM:W2], set LUM W2 [LUM:W1], set LUM W1 [LUM:W0], set LUM W0 {([HM2BB1:brightness]+[HM2BB2:brightness])/2}
1 set LUM {(int((100*(([HM2BB1:brightness]+[HM2BB2:brightness])/2+0.5))/250))}
Helper:
event motion: off,noMotion
globalinit 1
last_timer 0
sleeptimer -1
timerdev HM2BB2
timerevent motion: off,noMotion
triggerDev HM2BB2
timerevents:
motion: off
noMotion
timereventsState:
motion: off
state: noMotion
triggerEvents:
motion: off
noMotion
triggerEventsState:
motion: off
state: noMotion
Internals:
Itimer:
Readings:
Regexp:
0:
0 HM2BB
All:
0 HM2BB
State:
Trigger:
Attributes:
do always
Okay, also ist die gewünschte Funktion jetzt gegeben? Wundern tuts mich trotzdem...
lol: da stehts ja eigentlich sogar:
Zitat
Beispiele für Regex-Angaben:
["FS"] triggert auf alle Devices, die "FS" im Namen beinhalten
["^FS"] triggert auf alle Devices, die mit "FS" im Namen anfangen
["FS:temp"] triggert auf alle Devices, die "FS" im Namen und "temp" im Event beinhalten
([":^temp"]) triggert auf beliebige Devices, die im Event mit "temp" beginnen
(["^FS$:^temp$"] triggert auf Devices, die genau "FS" heißen und im Event genau "temp" vorkommt
[""] triggert auf alles
naja, hab ich auch was gelernt :-)
Grüße
Stephan
... nett, das ich DAU auch mal was weiß, was andere nicht wissen ;D
Nun gut. So wie ich das sehe existiert hier wohl irgendwie ein Problem, wenn die Devices auf direkter Hardware/GPIO's basieren. Ich kann mir zwar nicht erklären, was da dann anders ist, aber da der besagte PERL- Fehler ausschließlich bei Abfragen von direkter Hardware auftaucht, ansonsten aber funktioniert, schrammt das DOIF da wohl kurz die berühmte Wand...
Lange Rede, kurzer Sinn: Da ansonsten die Sache funktioniert, soll mich die Fehlermeldung im Log nicht kümmern. Ich bin aber sehr wohl bereit, das mir möglich zur Klärung und ggf. Beseitigung beizutragen...
Du könntest ja nochmal probieren, ob ein dummy HWirgendwas den gleichen fehler produziert. Also obs am Namen liegt, oder am GPIO/Modul (ggf noch ein andersnamiges GPIO-Device definieren. Wenn du dann weisst, woher es kommt, schaust du in die MAINTAINER.txt und postest im entsprechenden Forum einen Link, dann kann sich derjenige das mal anschauen (und vielleicht auch eine Begründung liefern;)
Grüße
Stephan
... hatte ich ja schon gemacht mit verschiedenen Dummy's, vorhandenen und neu dafür angelegten Dummy's so wie mit vorhandenen "anderen" Devices ...
Es taucht tatsächlich nur bei Devices auf, die auf GPIO's zugreifen. Bei meiner Hauptinstanz kann ich das so nicht testen, aber auf dem Heizungs-PI ist das reproduzierbar
... jetzt wird es aber ganz schräg >:(
define Bt_set DOIF (["HW"]) (set Bt | [HWBR:state] | [HWi1:state] | [HWi2:state] | [HWi3:state] |) DOELSE
#attr Bt_set do always
attr Bt_set verbose 4
define FileLog_Bt FileLog ./log/%Y-%m_BR-Test.log Bt
attr FileLog_Bt logtype text
attr FileLog_Bt room _Logdateien_
Varianten:
1.: Mit und ohne DOELSE -> Macht nie einen Unterschied
2.: Mit den Varianten ["HW"], ["HW:state"], ["^HW"], ["^HW:state"] -> Macht keinen Unterschied. Es wird NIE ein Event generiert
3.: Mit do always wird im halb- Sekunden - Takt ins Log geballert, egal ob ein Event da ist oder nicht
Nehme ich die weiter vorher beschriebene DOIF aus der Config, generiert diese Definition keinen PERL- Fehler (macht aber auch nicht was sie soll und hüllt sich in Schweigen).
Zitat von: M_I_B am 28 Oktober 2016, 17:57:38
... jetzt wird es aber ganz schräg >:(
define Bt_set DOIF (["HW"]) (set Bt | [HWBR:state] | [HWi1:state] | [HWi2:state] | [HWi3:state] |) DOELSE
#attr Bt_set do always
attr Bt_set verbose 4
define FileLog_Bt FileLog ./log/%Y-%m_BR-Test.log Bt
attr FileLog_Bt logtype text
attr FileLog_Bt room _Logdateien_
Varianten:
1.: Mit und ohne DOELSE -> Macht nie einen Unterschied
2.: Mit den Varianten ["HW"], ["HW:state"], ["^HW"], ["^HW:state"] -> Macht keinen Unterschied. Es wird NIE ein Event generiert
3.: Mit do always wird im halb- Sekunden - Takt ins Log geballert, egal ob ein Event da ist oder nicht
Nehme ich die weiter vorher beschriebene DOIF aus der Config, generiert diese Definition keinen PERL- Fehler (macht aber auch nicht was sie soll und hüllt sich in Schweigen).
Zum Verständins:
1. ["HW"] ist ein Ereignistrigger, hier wenn irgendwo im Eventmonitor HW im Device erscheint wird getriggert.
2. [HW] ist der Inhalt des Status des Devices HW, also etwas ganz anders im Vergleich zu Punkt 1.
3. ["HW:state"] wirst du normalerweise nicht im Eventmonitor sehen, da State dort nicht erscheint.
Gruß
Damian
... naja ebend, nich' nackend 8)
Wenn ich ["HW"] oder ["^HW"] sach', dann sollte doch bei jedem Ereignis von irgend einem Device, welches HW im Namen trägt resp. mit HW im Namen beginnt und seinen Zustand ändert (hier von on zu off oder umgekehrt) ein s.g. Ereignis statt finden und dem Ganzen den Startschubser geben... oder nicht?
... ich will ja nichts weiter, als einem Dummy die aktuellen Zustände aller Devices mit HWxy übergeben, wenn eines der mit HW- beginnenden Devices was zu sagen hat...
Zitat von: M_I_B am 28 Oktober 2016, 20:30:52
... naja ebend, nich' nackend 8)
Wenn ich ["HW"] oder ["^HW"] sach', dann sollte doch bei jedem Ereignis von irgend einem Device, welches HW im Namen trägt resp. mit HW im Namen beginnt und seinen Zustand ändert (hier von on zu off oder umgekehrt) ein s.g. Ereignis statt finden und dem Ganzen den Startschubser geben... oder nicht?
Nicht unbedingt. Das hängt davon ab, wie die Definition bzw. die Attribute gesetzt sind. Insb. ohne do always wird ja nur nach Zustandswechsel (des DOIF-Moduls) geschaltet.
... puhhh ... der Winni ::)
Also...
[HWBR] ist ein GPIO-out, welcher so definiert ist:
define HWBR RPI_GPIO 16
attr HWBR alias Öl- Brenner
attr HWBR devStateIcon off:sani_boiler@gray on:sani_boiler@orange
attr HWBR direction output
attr HWBR group Aktoren
attr HWBR room KG.Heizung
attr HWBR sortby 1
attr HWBR webCmd :
[HWix] sind ebenfalls GPIO-in, die bis auf den Index identisch so aussehen:
define HWi1 RPI_GPIO 17
attr HWi1 active_low yes
attr HWi1 alias Brenner Betrieb
attr HWi1 devStateIcon off:sani_boiler@gray on:sani_boiler@green
attr HWi1 direction input
attr HWi1 group Rückmeldungen
attr HWi1 interrupt both
attr HWi1 pud_resistor off
attr HWi1 room KG.Heizung
attr HWi1 sortby 6
attr HWi1 toggletostate yes
Wenn ich also manuell oder über ein DOIF HWBR on setze, dann ist das doch ein Ereignis, oder nicht? Und wenn HWi1 vom Brenner von off zu on gesetzt wird (Flamme erkannt), dann ist das doch auch ein Ereignis. Und in beiden Fällen wird doch auch ein Event ausgelöst, sonst könnte ich ja nicht drauf reagieren...
Was verstehe ich denn hier falsch? Mach ma' meinen Knoten aus'm Hirn raus bidde ...
Zitat von: M_I_B am 28 Oktober 2016, 20:41:07
Wenn ich also manuell oder über ein DOIF HWBR on setze, dann ist das doch ein Ereignis, oder nicht? Und wenn HWi1 vom Brenner von off zu on gesetzt wird (Flamme erkannt), dann ist das doch auch ein Ereignis. Und in beiden Fällen wird doch auch ein Event ausgelöst, sonst könnte ich ja nicht drauf reagieren...
Was verstehe ich denn hier falsch? Mach ma' meinen Knoten aus'm Hirn raus bidde ...
Poste doch einfach mal einen Auszug aus dem Eventmonitor, wo dein "HW" im Device zu erkennen ist und dann ein list vom betreffenden DOIF-Modul, dann kann ich ziemlich genau sagen, warum das Modul nicht das gemacht hat, was du erwartet hast.
... kein Problem:
...
2016-10-28 20:58:13.389 DOIF set_BRa cmd_event: HWBR
2016-10-28 20:58:13.410 RPI_GPIO HWBR on
2016-10-28 20:58:17.933 DOIF set_BRa cmd_event: HWBR
2016-10-28 20:58:17.945 RPI_GPIO HWBR off
2016-10-28 20:58:19.811 RPI_GPIO HWBR off
2016-10-28 20:58:19.828 DOIF HWBR_D cmd_nr: 4
2016-10-28 20:58:19.828 DOIF HWBR_D cmd: 4
2016-10-28 20:58:19.828 DOIF HWBR_D cmd_event: hzsp
2016-10-28 20:58:19.828 DOIF HWBR_D cmd_4
2016-10-28 20:58:19.928 RPI_GPIO HWBR off
2016-10-28 20:58:19.945 DOIF HWBR_D cmd_nr: 4
2016-10-28 20:58:19.945 DOIF HWBR_D cmd: 4
2016-10-28 20:58:19.945 DOIF HWBR_D cmd_event: hzsp
2016-10-28 20:58:19.945 DOIF HWBR_D cmd_4
...
Internals:
CFGFN ./_SW/erfassung.cfg
DEF (["HW"]) (set Bt | [HWBR:state] | [HWi1:state] | [HWi2:state] | [HWi3:state] |) DOELSE
NAME Bt_set
NR 116
NTFY_ORDER 50-Bt_set
STATE cmd_1
TYPE DOIF
Readings:
2016-10-28 21:01:39 Device HWWP_on
2016-10-28 14:38:00 cmd 1
2016-10-28 14:38:00 cmd_event HWWP_on
2016-10-28 14:38:00 cmd_nr 1
2016-10-28 21:01:39 matched_event_c1_1 cmd_nr: 4,cmd: 4,cmd_event: wwsp,cmd_4
2016-10-28 14:38:00 state cmd_1
Condition:
0 EventDoIf('HW',$hash,'',0)
Devices:
Do:
0:
0 set Bt | [HWBR:state] | [HWi1:state] | [HWi2:state] | [HWi3:state] |
1:
0
Helper:
event cmd_nr: 4,cmd: 4,cmd_event: wwsp,cmd_4
globalinit 1
last_timer 0
sleeptimer -1
timerdev HWWP_on
timerevent cmd_nr: 4,cmd: 4,cmd_event: wwsp,cmd_4
triggerDev HWWP_on
timerevents:
cmd_nr: 4
cmd: 4
cmd_event: wwsp
cmd_4
timereventsState:
cmd_nr: 4
cmd: 4
cmd_event: wwsp
state: cmd_4
triggerEvents:
cmd_nr: 4
cmd: 4
cmd_event: wwsp
cmd_4
triggerEventsState:
cmd_nr: 4
cmd: 4
cmd_event: wwsp
state: cmd_4
Internals:
Itimer:
Readings:
Regexp:
0:
0 HW
All:
0 HW
State:
Trigger:
Attributes:
verbose 4
Zitat von: M_I_B am 28 Oktober 2016, 21:03:00
... kein Problem:
...
2016-10-28 20:58:13.389 DOIF set_BRa cmd_event: HWBR
2016-10-28 20:58:13.410 RPI_GPIO HWBR on
2016-10-28 20:58:17.933 DOIF set_BRa cmd_event: HWBR
2016-10-28 20:58:17.945 RPI_GPIO HWBR off
2016-10-28 20:58:19.811 RPI_GPIO HWBR off
2016-10-28 20:58:19.828 DOIF HWBR_D cmd_nr: 4
2016-10-28 20:58:19.828 DOIF HWBR_D cmd: 4
2016-10-28 20:58:19.828 DOIF HWBR_D cmd_event: hzsp
2016-10-28 20:58:19.828 DOIF HWBR_D cmd_4
2016-10-28 20:58:19.928 RPI_GPIO HWBR off
2016-10-28 20:58:19.945 DOIF HWBR_D cmd_nr: 4
2016-10-28 20:58:19.945 DOIF HWBR_D cmd: 4
2016-10-28 20:58:19.945 DOIF HWBR_D cmd_event: hzsp
2016-10-28 20:58:19.945 DOIF HWBR_D cmd_4
...
Internals:
CFGFN ./_SW/erfassung.cfg
DEF (["HW"]) (set Bt | [HWBR:state] | [HWi1:state] | [HWi2:state] | [HWi3:state] |) DOELSE
NAME Bt_set
NR 116
NTFY_ORDER 50-Bt_set
STATE cmd_1
TYPE DOIF
Readings:
2016-10-28 21:01:39 Device HWWP_on
2016-10-28 14:38:00 cmd 1
2016-10-28 14:38:00 cmd_event HWWP_on
2016-10-28 14:38:00 cmd_nr 1
2016-10-28 21:01:39 matched_event_c1_1 cmd_nr: 4,cmd: 4,cmd_event: wwsp,cmd_4
2016-10-28 14:38:00 state cmd_1
Condition:
0 EventDoIf('HW',$hash,'',0)
Devices:
Do:
0:
0 set Bt | [HWBR:state] | [HWi1:state] | [HWi2:state] | [HWi3:state] |
1:
0
Helper:
event cmd_nr: 4,cmd: 4,cmd_event: wwsp,cmd_4
globalinit 1
last_timer 0
sleeptimer -1
timerdev HWWP_on
timerevent cmd_nr: 4,cmd: 4,cmd_event: wwsp,cmd_4
triggerDev HWWP_on
timerevents:
cmd_nr: 4
cmd: 4
cmd_event: wwsp
cmd_4
timereventsState:
cmd_nr: 4
cmd: 4
cmd_event: wwsp
state: cmd_4
triggerEvents:
cmd_nr: 4
cmd: 4
cmd_event: wwsp
cmd_4
triggerEventsState:
cmd_nr: 4
cmd: 4
cmd_event: wwsp
state: cmd_4
Internals:
Itimer:
Readings:
Regexp:
0:
0 HW
All:
0 HW
State:
Trigger:
Attributes:
verbose 4
Dein DOIF-Modul Bt_set tut natürlich nichts, weil es ja schon seit 2016-10-28 14:38:00 im Zustand cmd_1 steht. Das Modul arbeitet mit Zuständen und schaltet ohne do always nur nach Zustandswechsel, wie bereits geschrieben (das steht aber ausführlich in der Commandref zu DOIF).
Wenn do always einschaltest, dann wird das vermutlich deswegen zu einem "Feuerwerk" bei dir kommen, da du ja die anderen DOIF auch mit HW im Namen definiert hast und dann triggern sich die Dinger gegenseitig.
... ähhhh ... da muss ich mal intensiv drüber nachdenken ::)
ZitatZustandswechsel, wie bereits geschrieben
Vermutlich liegt da mein Verständnisproblem? Ist der Wechsel von z.B. HWBR von off zu on denn kein Zustandwechsel? Oder wie ist das gemeint?
Zitat von: M_I_B am 28 Oktober 2016, 21:28:53
... ähhhh ... da muss ich mal intensiv drüber nachdenken ::)
Vermutlich liegt da mein Verständnisproblem? Ist der Wechsel von z.B. HWBR von off zu on denn kein Zustandwechsel? Oder wie ist das gemeint?
Nein. Hier geht es um den eigenen Zustand des DOIF-Moduls. Das Modul führt die Befehle von cmd_1 nur dann aus, wenn es die nicht zuvor schon ausgeführt hat. Bei dir müsste also zunächst der DOELSE-Fall kommen (cmd_2) damit das Modul die Befehle von cmd_1 wieder ausführt. Allerdings wirst du mit der Definition ["HW"] niemals den DOELSE-Fall erreichen können.
Vermutlich ist also in deinem Vorhaben das do always erforderlich, aber dann musst du drauf achten, dass du keine Kettenreaktion auslöst (einen Loop)
DOIF1 -> DOIF2-> DOIF1 -> DOIF2 -> usw.
... AHHHH ... Jetzt hab ich das kapiert! Menno, ich werde echt älter ::) Habe ich schon mal erwähnt, das Altwerden echt schei.. ist?!
Ok, dann baue ich das mal um und eliminiere alles, was irgendwie eine Loop bauen könnte... Ich werde berichten, was geworden ist, und dann kommen wir wieder auf den PERL- Fehler zurück ;)
Vielen Dank für deine Geduld!
Zitat von: M_I_B am 28 Oktober 2016, 22:06:48
... AHHHH ... Jetzt hab ich das kapiert! Menno, ich werde echt älter ::) Habe ich schon mal erwähnt, das Altwerden echt schei.. ist?!
Ok, dann baue ich das mal um und eliminiere alles, was irgendwie eine Loop bauen könnte... Ich werde berichten, was geworden ist, und dann kommen wir wieder auf den PERL- Fehler zurück ;)
Vielen Dank für deine Geduld!
Ich denke der Fehler kommt durch diese Loops, denn die Fehlermeldung besagte es ja.