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

[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