[GELÖST] WOL notify/event nach fhem Neustart (wegen state none)

[popy]

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:

Code Auswählen Erweitern


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:

Code Auswählen Erweitern


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

[Ellert]

- 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.

[RaspiLED]

Probier mal ^on statt on im notify,
Äh Quatsch on.* sollte nur on sein
Gruß Arnd


Gesendet von iPhone mit Tapatalk

[popy]

- 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

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

[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:

Code Auswählen Erweitern


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

[popy]

Update vom Update 
Habe jetzt einen dirty Workaround gemacht.
Dieser deaktiviert für 30 Sekunden beim Start die notifys:

Code Auswählen Erweitern


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

[KernSani]

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

[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

Sorry für die blöde Frage, was wäre das Richtige Forum? 

[KernSani]

Steht hier drin: https://fhem.de/MAINTAINER.txt


Kurz, weil mobil

[popy]

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?

[Otto123]

Danke, die File kannte ich noch nicht.
Kannst du den Thread dorthin Bitte verschieben?

Kannst Du selbst, unten links ...

[popy]

Erl. danke. Da habe ich ja noch einiges zu lernen... 

Hoffe hier kann mir jemand helfen.
pOpY

[popy]

Niemand eine Idee?

[CoolTux]

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.

[CoolTux]

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.

[popy]

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.

[CoolTux]

Deine Regex für das Notify würde ich ändern in

Code Auswählen Erweitern


WOL_WZ.*:on {

Sofern es nur auf on vom state reagieren soll.

[nils_]

andere frage:
wie oft startest du denn fhem neu??

[popy]

Deine Regex für das Notify würde ich ändern in

Code Auswählen Erweitern


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

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 
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

[Otto123]

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:

Code Auswählen Erweitern

2019-01-24_09:39:19 LSK2012 off
Der Zustand vor und nach dem Start hat sich nicht geändert.

Code Auswählen Erweitern

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

[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:

Code Auswählen Erweitern

2019-01-24_09:39:19 LSK2012 off
Der Zustand vor und nach dem Start hat sich nicht geändert.

Code Auswählen Erweitern

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)?

[Otto123]

Leider nicht.

Gruß Otto

[Frank_Huber]

Hi,

Hast Du es schon mit dem Reading "isRunning" versucht?
Evtl wird dieses beim Start nicht durchgeschüttelt...

/Frank

[Otto123]

Hi,

gute Idee von Frank! Funktioniert auch, gerade getestet.
event-on-change-reading muss dann natürlich auf .* stehen. 

Gruß Otto

[popy]

Danke Frank und Otto!

Was genau muss ich wie setzen?



Gesendet von meinem ONEPLUS A6013 mit Tapatalk

[Otto123]

Vorschlag (nicht getestet):

Code Auswählen Erweitern

attr WOL_WZ.* event-on-change-reading .*
und das regExp im notify:

Code Auswählen Erweitern

WOL_WZ.*:isRunning:.true {...}
bzw:

Code Auswählen Erweitern

WOL_WZ.*:isRunning:.false {...}

[popy]

Vorschlag (nicht getestet):

Code Auswählen Erweitern

attr WOL_WZ.* event-on-change-reading .*
und das regExp im notify:

Code Auswählen Erweitern

WOL_WZ.*:isRunning:.true {...}
bzw:

Code Auswählen Erweitern

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

[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

[Otto123]

Naja, dann musst du das quasi "entprellen", wirst Du wohl ein zweites Gerät brauchen.
als Stichworte:
Presence
notify disabledForIntervals
DOIF mit wait
watchdog

[l2r]

hi,

ich habe da für ein ähnlichen Problem mal was mit deinem Userreading gebaut, welches ich abfrage:

Code Auswählen Erweitern

status {if( ReadingsVal($name,"state",0) ne "none") {ReadingsVal($name,"state",0)} else {ReadingsVal($name,"status",0)}}

Code Auswählen Erweitern

event-on-change-reading status,state muss dann gesetzt sein.

Gruß Michael

[popy]

hi,

ich habe da für ein ähnlichen Problem mal was mit deinem Userreading gebaut, welches ich abfrage:

Code Auswählen Erweitern

status {if( ReadingsVal($name,"state",0) ne "none") {ReadingsVal($name,"state",0)} else {ReadingsVal($name,"status",0)}}

Code Auswählen Erweitern

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

[Otto123]

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

[l2r]

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

[Otto123]

@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

[popy]

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.

[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

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 

WOL def - ALT:

Code Auswählen Erweitern


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:

Code Auswählen Erweitern


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):

Code Auswählen Erweitern


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):

Code Auswählen Erweitern


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

[Otto123]

Nein du hast nicht alles erklärt. Wieso kannst Du mit state arbeiten?

Ich verstehe noch nicht wieso Du wieder mit state "arbeiten" kannst.

Das toggeln beim herunterfahren sollte doch genauso passieren wie bei isRunning ?

Gruß Otto

[KernSani]

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.

[popy]

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

[popy]

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

[Otto123]

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) ...

[popy]

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