98_WOL.pm-Patch für State-Änderung

Dietmar63 · 19 November 2014, 19:45:18

Meine Test haben keine Fehler mehr ergeben. Ich habe das Modul eingecheckt.

Tommy82 · 19 November 2014, 20:07:36

Der Server ist definitiv an(geweckt über ein anderes WOL Tool), aber in Fhem wird er immer noch als off angezeigt

Internals: 
   DEF        c8:60:00:36:bd:fd 192.168.188.22 
   INTERVAL   900 
   IP         192.168.188.22 
   MAC        c8:60:00:36:bd:fd 
   MODE       BOTH 
   NAME       WHS_2011 
   NR         207 
   REPEAT     000 
   STATE      off 
   TYPE       WOL 
   Readings: 
     2014-11-19 19:54:37   isRunning       true 
     2014-11-19 19:54:22   packet_via_EW   none 
     2014-11-19 19:54:22   packet_via_UDP  none 
     2014-11-18 21:38:57   state           off 
Attributes: 
   devStateIcon on:it_pc@green off:it_pc@red 
   fp_Server  376,436,0, 
   icon       it_pc 
   interval   90

interval 90 müsste doch dann 1Minute 30 sein? Hab ich auch abgewartet, aber keine aktualisierung.

Dietmar63 · 19 November 2014, 21:06:06

Der Patch wurde vermutlich nicht richtig angewandt

Tommy82 · 19 November 2014, 21:10:03

Hallo Dietmar, hab beim anwenden keine Fehlermeldung bekommen!

Morgen müsste das Modul aber ja dann auch übers normale update eingespielt werden?

Dann guck ich dann einfach nochmal

Tommy82 · 20 November 2014, 20:18:16

Hallo,
hab das Update grade über fhem eingespielt und ein shutdown restart durchgeführe.
Trotzdem werden meine beiden Server als on angezeigt, obwohl nur einer an ist, der andere ist im Standbye.

Der WinServer ist definitiv im Standbye und nicht on

Code Auswählen

Internals: 
   DEF        bc:5f:f4:fb:7f:de 192.168.188.26 
   INTERVAL   900 
   IP         192.168.188.26 
   MAC        bc:5f:f4:fb:7f:de 
   MODE       BOTH 
   NAME       WinServer 
   NR         213 
   REPEAT     000 
   STATE      on 
   TYPE       WOL 
   Readings: 
     2014-11-20 18:50:58   active          off 
     2014-11-20 18:50:58   isRunning       true 
     2014-11-20 18:50:58   packet_via_EW   none 
     2014-11-20 18:50:58   packet_via_UDP  none 
     2014-11-20 18:50:58   state           on 
Attributes: 
   devStateIcon on:it_pc@green off:it_pc@red 
   fp_Home    399,1828,0, 
   fp_Server  391,1015,5, 
   icon       it_pc 
   interval   90 
   webCmd     on:off

Kann das am ACPI Modus (S4,S5 etc.) liegen?

Der STATE und auch state stehen immer auf on

Hab verbose jetzt mal auf 5 gestellt, mal sehn was der Log sagt

Code Auswählen

Internals: 
   DEF        bc:5f:f4:fb:7f:de 192.168.188.26 
   INTERVAL   90 
   IP         192.168.188.26 
   MAC        bc:5f:f4:fb:7f:de 
   MODE       BOTH 
   NAME       WinServer 
   NR         213 
   REPEAT     000 
   STATE      on 
   TYPE       WOL 
   Readings: 
     2014-11-20 20:21:20   active          off 
     2014-11-20 20:25:20   isRunning       true 
     2014-11-20 18:50:58   packet_via_EW   none 
     2014-11-20 18:50:58   packet_via_UDP  none 
     2014-11-20 20:25:20   state           on 
Attributes: 
   devStateIcon on:it_pc@green off:it_pc@red 
   fp_Home    399,1828,0, 
   fp_Server  391,1015,5, 
   icon       it_pc 
   interval   90 
   verbose    5 
   webCmd     on:off

Also wenn ich auf off stelle, dann kommt im Log

Code Auswählen

2014.11.20 20:28:01.559 3: [WinServer] set WinServer off
2014.11.20 20:28:01.603 3: [WinServer] no shutdown command given (see shutdownCmd attribute)!

Dietmar63 · 20 November 2014, 20:31:03

die Readings

Code Auswählen

   Readings: 
     2014-11-20 18:50:58   active          off 
     2014-11-20 18:50:58   isRunning       true 
     2014-11-20 18:50:58   packet_via_EW   none 
     2014-11-20 18:50:58   packet_via_UDP  none

sehen erst einmal gut aus.

der Wert

Code Auswählen

2014-11-20 18:50:58 isRunning true
und damit auch state, ist immer dann true, wenn ein Ping auf das Gerät eine Antwort liefert.
Prüf' mal, ob du auf telnet-Ebene auf einen Ping eine Antwort bekommt. Ich wette, dass das der Fall ist.

Der Server ist damit auf Netzwerkebene nicht vollständig heruntergefahren. WOL kann "vollständig Aus" von "fast Aus" nicht unterscheiden.

ZitatKann das am ACPI Modus (S4,S5 etc.) liegen?

Ja, es kann sein, dass WinServer auf bestimmte ACPI Modi auf ping nicht mehr reagieren. Das dürfte aber Serverabhängig sein.

Tommy82 · 20 November 2014, 20:37:20

Ja das kann durchaus sein, kann ich morgen mal testen. Aber vollkommen aus geht ja auch nicht wenn ich den Server per wol wecken will!?!

Dietmar63 · 20 November 2014, 21:28:59

Ich denke das ist geräteabhängig. Mein NAS liefert immer eine Antwort auf einen Ping. Ist also immer "on".
Der BüroPC(WIN7) liefert im Zustand "aus"(Hibernate oder Standby) keine Antwort auf ping, läßt sich trotzdem wecken.

Viele Dinge können einen WOL verhindern - ist halt nicht wirklich Standard.

Tommy82 · 20 November 2014, 22:15:56

Habs grade mal getestet, der ping liefert keine Antwort, daran kanns also nicht liegen

Code Auswählen

Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation. Alle Rechte vorbehalten.

C:\Users\Thomas>ping 192.168.188.26

Ping wird ausgeführt für 192.168.188.26 mit 32 Bytes Daten:
Zeitüberschreitung der Anforderung.
Zeitüberschreitung der Anforderung.
Zeitüberschreitung der Anforderung.
Zeitüberschreitung der Anforderung.

Ping-Statistik für 192.168.188.26:
    Pakete: Gesendet = 4, Empfangen = 0, Verloren = 4
    (100% Verlust),

Wenn ich im Wol Modul per set WinServer off den Server off schalte, müsste dann nicht zumindest kurzfristig der Status off gehen? Denn das passiert auch nicht

Dietmar63 · 21 November 2014, 21:57:01

ZitatWenn ich im Wol Modul per set WinServer off den Server off schalte, müsste dann nicht zumindest kurzfristig der Status off gehen? Denn das passiert auch nicht

Nein, nicht unbedingt.
Der Status wird asynchron per ping alle INERVAL Sekunden ermittelt - ist also nur mit Zeitverzögerung aktuell.

Tommy82 · 21 November 2014, 22:00:12

Geht bei mir überhaupt nicht auf off, auch nicht verzögert.

Und wie oben zusehen reagiert der Server auch nicht auf den ping wenn er aus ist

Dietmar63 · 21 November 2014, 22:47:22

Vieleicht hast du aus dem Prozess fhem keinen Zugriff auf ping und bekommst den Sachverhalt nicht mit.

Ich reichere das Modul mit Loggings an - teste ein wenig und gebe dann frei.
Morgen kannst du dann nach einem update vielleicht mit verbose 5 besser erkennen, was bei dir schief geht.

Tommy82 · 21 November 2014, 22:51:13

Ja das wäre super.
Muss ja einen grund geben.

Danke

Dietmar63 · 21 November 2014, 23:00:16

schon eingecheckt

Tommy82 · 22 November 2014, 13:42:43

Zitat von: Dietmar63 am 21 November 2014, 23:00:16
schon eingecheckt

Hi,7
hab das update durchgeführt, und dann versucht den Server (der wieder als on angezeigt wird=) auf off zu setzen,
dann kommt im Log:

Code Auswählen

2014.11.22 13:37:18.405 5: [WinServer] ping succesful - state = on
2014.11.22 13:38:48.488 5: [WinServer] executing: ping -c 1 -w 2 192.168.188.26
2014.11.22 13:38:48.491 5: [WinServer] result of ping:PING 192.168.188.26 (192.168.188.26): 56 data bytes

2014.11.22 13:38:48.492 5: [WinServer] ping succesful - state = on
2014.11.22 13:39:21.727 3: [WinServer] set WinServer off
2014.11.22 13:39:21.772 3: [WinServer] no shutdown command given (see shutdownCmd attribute)!
2014.11.22 13:39:21.813 5: [WinServer] executing: ping -c 1 -w 2 192.168.188.26
2014.11.22 13:39:21.815 5: [WinServer] result of ping:PING 192.168.188.26 (192.168.188.26): 56 data bytes

2014.11.22 13:39:21.817 5: [WinServer] ping succesful - state = on

Das sieht ja aus alsob eine ping rückmeldung kommen würde!?
In der Win7 cmd bekommt ping diese meldung nicht

Wie kann das sein, das beim Win7 Laptop keine Ping Rückmeldung kommt, laut Fhem aber eine kommt?