Hallo.
Ich habe mehrere WOLs die auf ein notify gehen.
Das notify hört nur auf einen state (on und ein anderes off).
Wenn ich jetzt "shutdown restart" mache dann werden diese immer ausgelöst -> was ich gerne lösen möchte.
Ich glaube dass Problem ist dass der state kurzzeitig nach dem start auf "none" steht und dann auf off/on geht (vermutlich nach dem ersten ping).
Das "attr WOL_WZ_NOTEBOOK event-on-change-reading state" war vorher auf ".*", aber auch mit "state" geht es nicht (Vermutlich wegem dem none state).
Habs schon mit "oldreadings state" versucht, aber die Werte sind immer gleich (Value() & OldValue()).
Würde mich über Denkanstöße freuen wie ich die notifys nach dem fhem rfestart verhindern kann?
Hier die defs:
Eins der WOLs:
defmod WOL_WZ_NOTEBOOK WOL XX:XX:XX:XX:XX:XX 192.168.0.XXX
attr WOL_WZ_NOTEBOOK alias Notebook
attr WOL_WZ_NOTEBOOK devStateIcon on:rc_TV1_on off:rc_TV refresh:rc_TV1_off
attr WOL_WZ_NOTEBOOK event-on-change-reading state
attr WOL_WZ_NOTEBOOK group Geräte
attr WOL_WZ_NOTEBOOK icon remotecontrol/black_btn_PC
attr WOL_WZ_NOTEBOOK interval 10
attr WOL_WZ_NOTEBOOK room Wohnzimmer
setstate WOL_WZ_NOTEBOOK on
setstate WOL_WZ_NOTEBOOK 2019-01-19 17:11:26 active off
setstate WOL_WZ_NOTEBOOK 2019-01-19 17:14:49 isRunning true
setstate WOL_WZ_NOTEBOOK 2019-01-19 17:11:26 packet_via_EW none
setstate WOL_WZ_NOTEBOOK 2019-01-19 17:11:26 packet_via_UDP none
setstate WOL_WZ_NOTEBOOK 2019-01-19 17:14:49 state on
Und das notify:
WOL_WZ.*:on.* {
my $hm = sprintf("%02d:%02d", $hour, $min);
Log 1, "act_on_PCs_WZ_ON: run! Tageslicht: ".Value("Tageslicht").", event: ".$EVENT;
if(Value("Tageslicht") eq "dunkel") {
Log 1, "act_on_PCs_WZ_ON: Szene FernsehLicht aktivieren, es ist dunkel!";
fhem "set WZ_Szenen scene Fernsehlicht";
}else{
Log 1, "act_on_PCs_WZ_ON: Szene FernsehLicht NICHT aktivieren, es ist zu hell!";
}
}
Lösungen:
Lösung 1 - mit isRunning anstatt state: https://forum.fhem.de/index.php/topic,96150.msg895748.html#msg895748
Lösung 2 - "none" state unterdrücken: https://forum.fhem.de/index.php/topic,96150.msg924266.html#msg924266
Lösung/Workaround 3 - notifys deaktivieren für 30 Sekunden: https://forum.fhem.de/index.php/topic,96150.msg891920.html#msg891920
- state wird aus dem Statefile wiederhergestellt, das müsset mit dem aktuellen Status gesichert werden.
- Den Regulären Ausdruck genauer formulieren in none steckt auch on.
Probier mal ^on statt on im notify,
Äh Quatsch on.* sollte nur on sein
Gruß Arnd
Gesendet von iPhone mit Tapatalk
Zitat von: Ellert am 19 Januar 2019, 18:15:43
- state wird aus dem Statefile wiederhergestellt, das müsset mit dem aktuellen Status gesichert werden.
- Den Regulären Ausdruck genauer formulieren in none steckt auch on.
Zitat von: RaspiLED am 19 Januar 2019, 19:41:27
Probier mal ^on statt on im notify,
Äh Quatsch on.* sollte nur on sein
Gruß Arnd
Gesendet von iPhone mit Tapatalk
Habe nur "...:on" oder auch "...:^on" getestet.
Leider ohne erfolg. :on triggert wie gewünscht nur auf "on" und "^on" triggert gar nicht mehr auf on (weil es ja keinen Zeilen Anfang gibt).
Ich glaube noch immer das Problem ist dass der state am anfang none ist dann je nach Geräte Status auf on/off wechselt, was das eine Event triggert.
Sprich der letzte state wird nicht gespeichert!?
Wäre über weitere Tipps dankbar.
Danke
pOpY
Update:
Habe im Code des Moduls nachgesehen und soweit ich das beurteilen kann wird der state nicht gespeichert?
SIehe letzte Zeile der WOL_Define funtkion:
sub WOL_Define($$) {
my ($hash, $def) = @_;
my @a = split("[ \t][ \t]*", $def);
my $u = "wrong syntax: define <name> WOL <MAC_ADRESS> <IP> <mode> <repeat> ";
return $u if(int(@a) < 4);
my $name = shift @a;
my $type = shift @a;
my $mac = shift @a;
my $ip = shift @a;
my $mode = shift @a;
my $repeat = shift @a;
$repeat = "000" if (!defined $repeat);
$mode = "BOTH" if (!defined $mode);
return "invalid MAC<$mac> - use HH:HH:HH:HH:HH"
if(!($mac =~ m/^([0-9a-f]{2}([:-]|$)){6}$/i ));
return "invalid IP<$ip> - use ddd.ddd.ddd.ddd"
if(!($ip =~ m/^([0-9]{1,3}([.-]|$)){4}$/i ));
return "invalid mode<$mode> - use EW|UDP|BOTH"
if(!($mode =~ m/^(BOTH|EW|UDP)$/));
return "invalid repeat<$repeat> - use 999"
if(!($repeat =~ m/^[0-9]{1,3}$/i));
$hash->{NAME} = $name;
$hash->{MAC} = $mac;
$hash->{IP} = $ip;
$hash->{REPEAT} = $repeat;
$hash->{MODE} = $mode;
delete $hash->{helper}{RUNNING_PID};
readingsSingleUpdate($hash, "packet_via_EW", "none",0);
readingsSingleUpdate($hash, "packet_via_UDP", "none",0);
readingsSingleUpdate($hash, "state", "none",0);
@Dietmar63: Kannst du da Bitte mal drauf schauen, bin mir nicht sicher ob es an mir oder am Modul liegt ;)
Danke
pOpY
Update vom Update :D
Habe jetzt einen dirty Workaround gemacht.
Dieser deaktiviert für 30 Sekunden beim Start die notifys:
global:INITIALIZED {
Log 1, "act_on_FHEM_Initialized: FHEM is now ".$EVENT;
my @devs = devspec2array("(act_on_PCs_.*)");
foreach (@devs)
{
#FHEM wurde neu gestartet -> notifys für 30 Sekunden ignorieren da ansonsten durch das WOL ein fehlevent ausgelöst wird
Log 1, "act_on_FHEM_Initialized: disable notify ".$_." for 30 Seconds";
fhem("set ".$_." inactive");
fhem('define at_'.$_.'_Activate at +00:00:30 set '.$_.' active');
fhem("set at_".$_."_Activate modifyTimeSpec 00:00:30");
}
}
Ist nicht so schön, und wäre für jeden weiteren Tipp dankbar.
Danke
pOpY
Da es ja so aussieht, als wäre tatsächlich das Modul mit Schuld, poste das mal im entsprechenden Forum, vielleicht kann man da ja was machen.
Kurz, weil mobil
Zitat von: KernSani am 20 Januar 2019, 20:14:58
Da es ja so aussieht, als wäre tatsächlich das Modul mit Schuld, poste das mal im entsprechenden Forum, vielleicht kann man da ja was machen.
Kurz, weil mobil
Sorry für die blöde Frage, was wäre das Richtige Forum? ::)
Steht hier drin: https://fhem.de/MAINTAINER.txt
Kurz, weil mobil
Zitat von: KernSani am 20 Januar 2019, 20:24:30
Steht hier drin: https://fhem.de/MAINTAINER.txt
Kurz, weil mobil
Danke, die File kannte ich noch nicht.
Kannst du den Thread dorthin Bitte verschieben?
Zitat von: popy am 20 Januar 2019, 20:32:10
Danke, die File kannte ich noch nicht.
Kannst du den Thread dorthin Bitte verschieben?
Kannst Du selbst, unten links ...
Erl. danke. Da habe ich ja noch einiges zu lernen... ;)
Hoffe hier kann mir jemand helfen.
pOpY
Niemand eine Idee?
https://forum.fhem.de/index.php/topic,83149.msg753762.html#msg753762
Sofern Dietmar noch als Modulauthor in der Maintainer benannt ist wird sich hier jemand neues finden müssen.
Ich habe den von Dir geposteten Codeteil mir angeschaut. Der kann Dein Notify nicht triggern, da sie readingsSingleUpdate kein Event werfen. Es muss also was anderes sein.
Zitat von: CoolTux am 23 Januar 2019, 20:30:35
https://forum.fhem.de/index.php/topic,83149.msg753762.html#msg753762
Sofern Dietmar noch als Modulauthor in der Maintainer benannt ist wird sich hier jemand neues finden müssen.
Sorry, das Wusste ich nicht.
Dietmar63 - Ruhe in Frieden! Mein Herzliches Beilleid für die Angehörigen.
Deine Regex für das Notify würde ich ändern in
WOL_WZ.*:on {
Sofern es nur auf on vom state reagieren soll.
andere frage:
wie oft startest du denn fhem neu??
Zitat von: CoolTux am 23 Januar 2019, 20:37:50
Deine Regex für das Notify würde ich ändern in
WOL_WZ.*:on {
Sofern es nur auf on vom state reagieren soll.
Habe ich bereits getestet, und keine Besserung.
Es liegt meiner Meinung nach nicht am Regex, das triggert korrekt auf on/off (habe noch ein zweites was auf off triggert).
Sondern dass sich er state von none auf on/off ändert.
Siehe: https://forum.fhem.de/index.php/topic,96150.msg891866.html#msg891866
Zitat von: nils_ am 24 Januar 2019, 08:50:29
andere frage:
wie oft startest du denn fhem neu??
Das ist eine berechtigte Frage.
Ich hatte vor kurzem ein Problem mit perl 5.24 was den Speicher vollaufen ließ.
Dies führte zu echt strange's Verhalten und außerdem wurden genau diese Notifys getriggert (ich glaube durch Neustart).
Habe schon alle Ursachen des Speicher volllaufen ausgemerzt (älteres Perl 5.20, kein apptime mehr usw.).
Das Ganze passierte natürlich um 03:00 Nachts und es wurden schön Lichter im Schlafzimmer ein/aus geschaltet :o :o :o
Mir ist halt bei der Analyse der Logs dann aufgefallen dass das passiert ist und auch beim fhem start passiert.
Darum möchte ich es beheben damit das obige nicht mehr passieren kann.
Hat von euch jemand ein WOL laufen?
Wie ist bei euch der state kurz nach dem starten? (Bei mir auf none und danach erst on/off was das notify auslöst)
pOpY
Moin,
ich kann das bestätigen, das WOL Modul liefert beim Systemstart einmalig einen Event mit dem vorhergehenden state.
Ich habe einfach ein FileLog definiert, das liefert diesen Eintrag beim Start:
2019-01-24_09:39:19 LSK2012 off
Der Zustand vor und nach dem Start hat sich nicht geändert.
Internals:
CHANGED
DEF 78:24:AF:43:AC:E5 192.168.56.33 UDP
FUUID 5c48bcb3-f33f-27f7-2ea4-579b415516afc076
IP 192.168.56.33
MAC 78:24:AF:43:AC:E5
MODE UDP
NAME LSK2012
NR 125
REPEAT 000
STATE off
TYPE WOL
READINGS:
2019-01-24 09:36:01 active off
2019-01-24 09:52:44 isRunning false
2019-01-24 09:36:01 packet_via_EW none
2019-01-24 09:36:01 packet_via_UDP none
2019-01-24 09:52:44 state off
TIMER:
LSK2012_ping:
HASH LSK2012
MODIFIER ping
NAME LSK2012_ping
helper:
Attributes:
event-on-change-reading state
interval 30
room Status
shutdownCmd "net rpc shutdown -I 192.168.56.33 -U xxxxn%xxxx"
useUdpBroadcast 192.168.56.255
Gruß Otto
Zitat von: Otto123 am 24 Januar 2019, 09:54:46
Moin,
ich kann das bestätigen, das WOL Modul liefert beim Systemstart einmalig einen Event mit dem vorhergehenden state.
Ich habe einfach ein FileLog definiert, das liefert diesen Eintrag beim Start:
2019-01-24_09:39:19 LSK2012 off
Der Zustand vor und nach dem Start hat sich nicht geändert.
Internals:
CHANGED
DEF 78:24:AF:43:AC:E5 192.168.56.33 UDP
FUUID 5c48bcb3-f33f-27f7-2ea4-579b415516afc076
IP 192.168.56.33
MAC 78:24:AF:43:AC:E5
MODE UDP
NAME LSK2012
NR 125
REPEAT 000
STATE off
TYPE WOL
READINGS:
2019-01-24 09:36:01 active off
2019-01-24 09:52:44 isRunning false
2019-01-24 09:36:01 packet_via_EW none
2019-01-24 09:36:01 packet_via_UDP none
2019-01-24 09:52:44 state off
TIMER:
LSK2012_ping:
HASH LSK2012
MODIFIER ping
NAME LSK2012_ping
helper:
Attributes:
event-on-change-reading state
interval 30
room Status
shutdownCmd "net rpc shutdown -I 192.168.56.33 -U xxxxn%xxxx"
useUdpBroadcast 192.168.56.255
Gruß Otto
Danke für die Bestätigung.
Hast du eine Idee wie man den Code ändern kann das wenigstens state wieder den letzten Zustand hat (bzw. diesen speichert/lädt)?
Leider nicht.
Gruß Otto
Hi,
Hast Du es schon mit dem Reading "isRunning" versucht?
Evtl wird dieses beim Start nicht durchgeschüttelt...
/Frank
Hi,
gute Idee von Frank! Funktioniert auch, gerade getestet.
event-on-change-reading muss dann natürlich auf .* stehen. ;D
Gruß Otto
Danke Frank und Otto!
Was genau muss ich wie setzen?
Gesendet von meinem ONEPLUS A6013 mit Tapatalk
Vorschlag (nicht getestet):
attr WOL_WZ.* event-on-change-reading .*
und das regExp im notify:
WOL_WZ.*:isRunning:.true {...}
bzw:
WOL_WZ.*:isRunning:.false {...}
Zitat von: Otto123 am 26 Januar 2019, 15:14:26
Vorschlag (nicht getestet):
attr WOL_WZ.* event-on-change-reading .*
und das regExp im notify:
WOL_WZ.*:isRunning:.true {...}
bzw:
WOL_WZ.*:isRunning:.false {...}
Danke funktioniert perfekt mit isRunning anstatt state!
Problem somit gelöst und ich kann meinen nich so schönen Workaround weggeben ;)
pOpY
Muss den wieder rauskramen.
Es haut noch nicht so ganz hin.
Irgendwie toggelt .isRunning manchmal während dem Niederfahren von Windows des WOL-Clients.
Das führt auch dann zu nicht gewollten Schaltzyklen (notify wird getriggert).
Ich bin nun auf den state und meinen Workaround von diesem Post zurück: https://forum.fhem.de/index.php/topic,96150.msg891920.html#msg891920
Hoffentlich läuft das besser.
Sonst noch jemand eine Idee?
pOpY
Naja, dann musst du das quasi "entprellen", wirst Du wohl ein zweites Gerät brauchen.
als Stichworte:
Presence
notify disabledForIntervals
DOIF mit wait
watchdog
hi,
ich habe da für ein ähnlichen Problem mal was mit deinem Userreading gebaut, welches ich abfrage:
status {if( ReadingsVal($name,"state",0) ne "none") {ReadingsVal($name,"state",0)} else {ReadingsVal($name,"status",0)}}
event-on-change-reading status,state muss dann gesetzt sein.
Gruß Michael
Zitat von: l2r am 27 März 2019, 16:59:04
hi,
ich habe da für ein ähnlichen Problem mal was mit deinem Userreading gebaut, welches ich abfrage:
status {if( ReadingsVal($name,"state",0) ne "none") {ReadingsVal($name,"state",0)} else {ReadingsVal($name,"status",0)}}
event-on-change-reading status muss dann gesetzt sein.
Gruß Michael
Danke!!
Das ist echt eine Super Lösung und funktioniert einwandfrei!
-> Kein Event mehr beim fhem Neustart
-> und ich kann wieder mit state arbeiten (was besser funktionierte als isRunning)
Ich beobachte das jetzt mal weiter und setzte den Thread geg. auf gelöst.
Nochmals vielen Dank
pOpY
Du solltest noch beschreiben warum das funktioniert, so auf die Schnelle habe ich das nicht verstanden. :-[
Du lässt jetzt Dein notify auf status triggern?
Und außer für status werden keine Events mehr erzeugt!
Ich verstehe noch nicht wieso Du wieder mit state "arbeiten" kannst.
Gruß Otto
das Reading status wird nur aktualisiert, wenn state nicht none ist. Außerdem wird es nur aktualisiert wenn state sich ändert (du hast recht: Event-on-change-Reading müsste für state und status gelten).
Gruß Michael
@Michael Deinen Code habe ich schon verstanden. :)
popy hatte aber das Problem, dass das Modul beim Neustart von FHEM einen state Event mit dem alten state wirft. Und das wird durch event-on-change-reading status (oder auch willi) zwar unterbunden aber nicht durch dein userReading :)
Zitat von: l2r am 28 März 2019, 16:16:47
das Reading status wird nur aktualisiert, wenn state nicht none ist. Außerdem wird es nur aktualisiert wenn state sich ändert (du hast recht: Event-on-change-Reading müsste für state und status gelten).
Gruß Michael
Warum muss auf state auch event-on-change-reading gemacht werden?
Mit NUR status bei event-on-change-reading funktioniert alles perfekt.
Zitat von: Otto123 am 28 März 2019, 14:45:08
Du solltest noch beschreiben warum das funktioniert, so auf die Schnelle habe ich das nicht verstanden. :-[
Du lässt jetzt Dein notify auf status triggern?
Und außer für status werden keine Events mehr erzeugt!
Ich verstehe noch nicht wieso Du wieder mit state "arbeiten" kannst.
Gruß Otto
Sorry für meinen ungenauen Post, hatte wenig Zeit ;)
Hier nochmals ausführlich:
Problem:
Ich hatte das Problem (mit Perl 5.24+) das bei (ich glaube blöderweise laufendem apptime) der Speicher der RPI vollgelaufen ist und fhem mitten in der Nacht neu startete.
Habe zur Sicherheit auf Perl 5.20 downgegraded und der Speicherverlauf ist jetzt TOP. Bin mir aber nicht sicher ob es, wie gesagt, ein laufendes apptime war.
Beim Neustart von fhem wurde der aktuelle state vom WOL einmal getriggert, da state beim starten "none" und dann auf den aktuellen Wert sich ändert -> notify wird getriggert.
Dies führte mitten in der Nacht dazu das Szenen im Schlafzimmer getriggert wurden -> nicht toll 8)
WOL def - ALT:
defmod WOL_SZ_TV WOL XX:XX:XX:XX:XX:XX 192.168.0.XX
attr WOL_SZ_TV alias Fernseher
attr WOL_SZ_TV devStateIcon off:rc_TV on:rc_TV1_on refresh:rc_TV1_off
attr WOL_SZ_TV event-on-change-reading .*
attr WOL_SZ_TV group Geräte
attr WOL_SZ_TV icon it_television
attr WOL_SZ_TV interval 10
attr WOL_SZ_TV room Schlafzimmer
attr WOL_SZ_TV shutdownCmd {`curl -u eguser:dintiseg --max-time 3 http://192.168.0.7:8888/?Shutdown`}
notify def - ALT:
WOL_SZ_TV:off {
Log 1, "act_off_PCs_SZ_OFF: Szene Aus aktivieren, es ist Schlafenszeit!";
fhem "set SZ_Szene_Alle scene Aus";
}
Durch meinen nicht so schönen Workaround (notifys beim starten für 30 Sekunden deaktivieren) oder jetzt, Michaels schönerem Workaround wird das triggern beim starten unterbunden.
WOL def - NEU (userreading status ist dazugekommen und event-on-change-reading status):
defmod WOL_SZ_TV WOL XX:XX:XX:XX:XX:XX 192.168.0.XX
attr WOL_SZ_TV alias Fernseher
attr WOL_SZ_TV devStateIcon off:rc_TV on:rc_TV1_on refresh:rc_TV1_off
attr WOL_SZ_TV event-on-change-reading status
attr WOL_SZ_TV group Geräte
attr WOL_SZ_TV icon it_television
attr WOL_SZ_TV interval 10
attr WOL_SZ_TV room Schlafzimmer
attr WOL_SZ_TV shutdownCmd {`curl -u eguser:dintiseg --max-time 3 http://192.168.0.7:8888/?Shutdown`}
attr WOL_SZ_TV userReadings status {if( ReadingsVal($name,"state",0) ne "none") {ReadingsVal($name,"state",0)} else {ReadingsVal($name,"status",0)}}
notify def - NEU (es wird auf status getriggert):
WOL_SZ_TV:status:.off {
Log 1, "act_off_PCs_SZ_OFF: Szene Aus aktivieren, es ist Schlafenszeit!";
fhem "set SZ_Szene_Alle scene Aus";
}
Es bewirkt dass der state "none" nicht in status übernommen wird.
Der status wird nur geändert wenn state was anders als "none" hat.
Somit wird beim starten von FHEM kein triger des notifys ausgelöst.
Ich hoffe jetzt ist alles geklärt ;)
pOpY
Nein du hast nicht alles erklärt. Wieso kannst Du mit state arbeiten?
ZitatIch verstehe noch nicht wieso Du wieder mit state "arbeiten" kannst.
Das toggeln beim herunterfahren sollte doch genauso passieren wie bei isRunning ?
Gruß Otto
Irgendwie hatte ich den Thread bisher überlesen... Ich habe ein Weilchen nachgedacht, ob ich an WOL selbst irgendwas drehen kann, aber es meiner Sicht ist es vollkommen korrekt, dass WOL beim Neustart erstmal auf "none" steht. Es sollte aber tatsächlich so sein, dass isRunning beim Neustart bestehen bleibt. Getoggelt wird isRunning nur, wenn ping erfolgreich/nicht erfolgreich... Also eigentlich sollte das den Zweck erfüllen.
Zitat von: Otto123 am 28 März 2019, 21:41:17
Nein du hast nicht alles erklärt. Wieso kannst Du mit state arbeiten?Das toggeln beim herunterfahren sollte doch genauso passieren wie bei isRunning ?
Gruß Otto
Weil ich jetzt mit status arbeite, was ein beschnittenes state ist (ohne none).
Mit state hatte ich früher nie das "toggeln" beim Herunterfahren des Clients, nur mit isRunning.
Ich beobachte das jetzt mal mit der status Lösung...
Was ist eigentlich der Unterschied state <> isRunning?
Kann in der Doku nichts drüber finden.
pOpY
Zitat von: KernSani am 28 März 2019, 21:59:34
Irgendwie hatte ich den Thread bisher überlesen... Ich habe ein Weilchen nachgedacht, ob ich an WOL selbst irgendwas drehen kann, aber es meiner Sicht ist es vollkommen korrekt, dass WOL beim Neustart erstmal auf "none" steht. Es sollte aber tatsächlich so sein, dass isRunning beim Neustart bestehen bleibt. Getoggelt wird isRunning nur, wenn ping erfolgreich/nicht erfolgreich... Also eigentlich sollte das den Zweck erfüllen.
Mit dem isRunning hatte ich beim Herunterfahren des Clients (welcher vom WOL überwacht wird) ein toggeln des isRunning.
Das führte auch zu komischen Effekten.
Weist du was der Unterschied zw. state <> isRunning ist?
pOpY
Zitat von: KernSani am 28 März 2019, 21:59:34
Getoggelt wird isRunning nur, wenn ping erfolgreich/nicht erfolgreich... Also eigentlich sollte das den Zweck erfüllen.
Genau so sehe ich das auch, also auch der Workaround mit userReadings und status dürfte bez. isRunning exakt den state wiederspiegeln (ich weiß der Threadtitel sagt noch was anderes) ...
Zitat von: Otto123 am 28 März 2019, 22:49:41
Genau so sehe ich das auch, also auch der Workaround mit userReadings und status dürfte bez. isRunning exakt den state wiederspiegeln (ich weiß der Threadtitel sagt noch was anderes) ...
Sorry fürs OffTopic gehen!
Dieser Thread ist gelöst, habe im OP alle 3 Lösungen reingteschrieben.
Für das aktuelle Thema (togglen beim Niederfahren) habe ich einen eigenen Thread aufgemacht: https://forum.fhem.de/index.php/topic,99121.0.html
Und ja du hast recht, das Problem besteht weiterhin da status bzw. isRunning immer von state abgeleitet ist und dieser das Problem hat mit dem toggeln.
Würde mich im neuen Thread über hilfe freuen.
Danke
pOpY