WOL - Shutdown funktioniert nicht mehr.

Wolle02 · 12 Februar 2014, 19:42:49

Hallo,

ich habe bei mir das WOL Modul laufen, welches mir jedesmal wenn ich nach Hause komme den Rechner einschaltet. Abends beim ins Bett gehen wird in der ganzen Wohnung das Licht ausgeschaltet und der Rechner mittels des Shutdown Commandos heruntergefahren.
Dies funktioniert seit dem Wochenende jedoch nicht mehr.

Im Logfile schreibt er mir dann folgende Fehlermeldung:

Code Auswählen


2014.02.12 18:31:23 3: WOL set Wolle_internet off
2014.02.12 18:31:23 3: [Wolle_internet] shutdownCmd: /volume1/@appstore/FHEM/bin/wolle_internet_shutdown.sh executed
2014.02.12 18:31:23 3: Unknown command /volume1/@appstore/FHEM/bin/wolle_internet_shutdown.sh, try help.
2014.02.12 18:31:23 3: WOL keeping Wolle_internet with MAC 00:22:15:17:7B:8E IP 192.168.178.66 busy

Scheinbar wird das Shutdownskript nicht gefunden oder falsch interpretiert.
Wenn ich das Skript manuell vom angegebenen Ort ausführe wird der Rechner korrekt heruntergefahren.

Gruß
Wolle

Wernieman · 13 Februar 2014, 08:06:54

Als welcher User läuft FHEM und als welcher User hast Du es probiert??

was sagt ein

Code Auswählen

ls -lha /volume1/@appstore/FHEM/bin/wolle_internet_shutdown.sh

Dietmar63 · 13 Februar 2014, 11:21:04

Sieh mal die Doku an.
Es hat auf vielfachem Wunsch eine Änderung gegeben: <command> kann nun jeder fhem-Befehl sein.

Ein Systemaufruf muss in "" geschrieben werden.

Wolle02 · 13 Februar 2014, 17:27:37

Hallo Dietmar,

danke für den Tip, das wars. Der Shutdown Command funktioniert damit wieder. Aber mal zum Verständnis: Wie hätte ich denn diese Änderung mitbekommen sollen, wenn man nicht absolut alles hier mitliest?
Gibt es da irgendeinen Prozess dafür? Die "List of last changes" beim Update check ist da nicht wirklich hilfreich.

Und eine weitere Sache ist mir jetzt auch noch aufgefallen. Ich weiß nicht, ob es Bug oder Feature ist, aber es stellt sich bei mir als Problem dar.
Wenn mein Rechner läuft und ich drücke meine "ins-Bett-geh-Taste", wird der Rechner jetzt mit dem Shutdown Command wieder korrekt herunter gefahren. So weit so gut.
Wenn ich den Rechner aber vorher manuell ausgeschaltet habe und dann die "ins-Bett-geh-Taste" drücke, dann fährt mein Rechner plötzlich wieder hoch, obwohl er das ja nicht soll. Im Logfile habe ich das hier gesehen:

Code Auswählen

2014.02.13 17:13:24 3: [Wolle_internet] shutdownCmd: "/volume1/@appstore/FHEM/bin/wolle_internet_shutdown.sh" executed
2014.02.13 17:13:26 3: WOL keeping Wolle_internet with MAC 00:22:15:17:7B:8E IP 192.168.178.66 busy

Da scheint 2 Sekunden nach dem Ausschaltkommando (was ins Leere läuft, weil der Rechner ist ja schon aus) nochmal ein Magic Paket geschickt zu werden, was den Rechner aktiv halten soll. Der weckt dann den Rechner wohl wieder auf.

Ist das so gewollt?

Gruß
Wolle

Dietmar63 · 13 Februar 2014, 19:19:01

Zitatdanke für den Tip, das wars. Der Shutdown Command funktioniert damit wieder. Aber mal zum Verständnis: Wie hätte ich denn diese Änderung mitbekommen sollen, wenn man nicht absolut alles hier mitliest?
Gibt es da irgendeinen Prozess dafür? Die "List of last changes" beim Update check ist da nicht wirklich hilfreich.

Ich glaube es ist leider nur so organisiert, dass man hier lesen/suchen muss.
Also update nicht so oft machen.
Nach update prüfen, ob alles noch fuktioniert. Lesen welche module sich geändert haben und die commandref lesen.
Log lesen.

Ich musste bei dieser Änderung leider den Weg einschlagen die Definition von WOL zu ändern. Das mache ich aber nur in Ausnahmefällen.

ZitatUnd eine weitere Sache ist mir jetzt auch noch aufgefallen. Ich weiß nicht, ob es Bug oder Feature ist, aber es stellt sich bei mir als Problem dar.
Wenn mein Rechner läuft und ich drücke meine "ins-Bett-geh-Taste", wird der Rechner jetzt mit dem Shutdown Command wieder korrekt herunter gefahren. So weit so gut.
Wenn ich den Rechner aber vorher manuell ausgeschaltet habe und dann die "ins-Bett-geh-Taste" drücke, dann fährt mein Rechner plötzlich wieder hoch, obwohl er das ja nicht soll. Im Logfile habe ich das hier gesehen:

Code: [Auswählen]
2014.02.13 17:13:24 3: [Wolle_internet] shutdownCmd: "/volume1/@appstore/FHEM/bin/wolle_internet_shutdown.sh" executed
2014.02.13 17:13:26 3: WOL keeping Wolle_internet with MAC 00:22:15:17:7B:8E IP 192.168.178.66 busy

Da scheint 2 Sekunden nach dem Ausschaltkommando (was ins Leere läuft, weil der Rechner ist ja schon aus) nochmal ein Magic Paket geschickt zu werden, was den Rechner aktiv halten soll. Der weckt dann den Rechner wohl wieder auf.

Ist das so gewollt?

Nein, deine Beobachtung ist richtig.
Ich kann das Verhalten aber leicht ändern. Du kannst nacherher einen update durchführen, dann ist WOL in einer neuen Version eingecheckt, bei der nach dem shutdown kein WOL Paktet mehr gesendet wird.

Dietmar63 · 13 Februar 2014, 19:22:18

eingechecked

Wolle02 · 13 Februar 2014, 21:26:13

Super, vielen Dank für die schnelle Hilfe. Ein Update Check zeigt mir noch kein Update für WOL an, aber wahrscheinlich wird das erst morgen angezeigt. Ich melde mich mit dem Ergebnis.

BtW: Ich weiß nicht wer für das Forum zuständig ist, aber wäre das nicht vielleicht ein Vorschlag für jedes Modul einen geschlossenen Thread zu erstellen, in den nur der Entwickler posten kann und dort die Änderungen dokumentiert sind? Dann bräuchte man nicht immer rumsuchen. Und warum wird in den CommandRef eigentlich Deutsch immer so stiefmütterlich behandelt?

Gruß
Wolle

Dietmar63 · 13 Februar 2014, 22:26:06

deutsch - weil es aufwendig ist doku zu erstellen und bei Änderungen zu pflegen.

Zitatfür jedes Modul einen geschlossenen Thread zu erstellen, in den nur der Entwickler posten kann und dort die Änderungen dokumentiert sind?

guter Vorschlag - vielleicht liest ja jemand mit.

Wolle02 · 15 Februar 2014, 11:26:38

Sorry für die späte Rückmeldung. Ich habe das Update gemacht und beim "ins-bett-gehen" fährt der Rechner nun nicht mehr hoch, wenn die gesamte Wohnung "ausgeschaltet" wird.

Allerdings habe ich beim Update etwas anderes festgestellt.
Ich habe das Update vom Büro aus gemacht; also zu einem Zeitpunkt wo niemand zu Hause war. Nach dem Update muss ja in der Regel FHEM mittels Shutdown Restart neu gestartet werden. In dieser Situation habe ich festgestellt, dass auch hier nun beim Neustart von FHEM ein Magic Paket gesandt wird, das den Rechner wach halten soll.

Code Auswählen

2014.02.14 12:13:03 3: WOL keeping Wolle_internet with MAC 00:22:15:17:7B:8E IP 192.168.178.66 busy

Dadurch wurde der Rechner hochgefahren, obwohl niemand zu Hause ist.

Kannst du das eventuell auch noch ändern?

Dietmar63 · 15 Februar 2014, 15:56:53

Das Verhalten liegt nicht unbedingt an WOL.
Es kann sein, dass in der fhem.save der Status von WOL noch auf on stand.

Nach einem Restart wird die fhem.save abgearbeitet, und dem WOL dann das Kommando set wol on gesendet. Dann wacht dein HTPC auf.

Wolle02 · 15 Februar 2014, 17:20:29

Hmmm, ich verstehe zwar nicht so ganz, warum der Status noch auf ON stehen sollte, aber ok ich kann damit leben, weil es doch eher sehr selten vorkommt, dass ich ein Shutdown Restart nicht von zu Hause aus mache. In der Regel sitze ich ja vor dem Rechner und dann ist er ja eh an.

Vielen Dank für deine Hilfe.

Dietmar63 · 15 Februar 2014, 19:32:07

in bestimmten Fällen wird die fhem.save geschrieben - wann genau kann ich auch nicht sagen, manchmal aber auch nicht.
Dann kann der Status für WOL in der save noch auf on stehen udn wird bei einem Neustart wieder eingestellt. Es soll so etwas sein, wie ein Gedächtnis über den Neustart hinweg.

siggi85 · 18 Februar 2014, 13:34:30

Bevor ich einen neuen Thread aufmache, dachte ich: schreib ich lieber hier rein.

Kann es sein, dass das WOL Modul momentan ein Problem hat? Mein WOL (welches bis vor ca 2 Wochen problemlos funktioniert hat) startet meinen Rechner nicht mehr. Ich habe meinen Rechner vor FHEM immer mit einer Android WOL App gestartet, welches auch immer noch funktioniert. Seit dem Problem habe ich zusätzlich Etherwake installiert. Über die Kommandozeile funktioniert das aufwecken auch mit Etherwake, jedoch über FHEM nicht.
Anbei mein WOL Device (wobei es auch bei einem frischen Device nich funktioniert).

Code Auswählen

define wol_rechner WOL aa:22:cc:44:ee:66 192.168.12.10
attr wol_rechner devStateIcon false:black_FS20.off true:black_FS20.on
attr wol_rechner fp_wohnzimmer 140,450,2,HTPC
attr wol_rechner group HTPC
attr wol_rechner interval 30
attr wol_rechner room Wohnzimmer
attr wol_rechner shutdownCmd set media_pc shutdown
attr wol_rechner stateFormat isRunning
attr wol_rechner sysCmd /usr/sbin/etherwake
attr wol_rechner webCmd on:off:refresh

Auszug ausm Log

Code Auswählen

2014.02.11 18:15:20 3: WOL waking  wol_rechner with MAC aa:22:cc:44:ee:66 IP 192.168.12.10 
2014.02.11 18:15:22 3: WOL keeping wol_rechner with MAC aa:22:cc:44:ee:66 IP 192.168.12.10 busy

Die MAC Adresse aa:22:cc:44:ee:66 ist natürlich nur ein Beispiel.

Owel · 18 Februar 2014, 14:06:12

selbiges Problem habe ich auch

Also bei mir kommt seit heute auch folgende Fehlermeldung:

Code Auswählen

WOL set Tower on
2014.02.18 14:05:07 3: WOL waking  Tower with MAC 00:25:23:24:7C:04 IP 192.168.188.12 
2014.02.18 14:05:09 3: WOL keeping Tower with MAC 00:25:23:24:7C:04 IP 192.168.188.12 busy
sh: 1: /usr/bin/wakeonlan 00:25:22:24:6C:03: not found

Seither hat das funktioniert.
wenn ich /usr/bin/wakeonlan 00:25:22:23:4D:03 in der Console ausführe tut das auch wunderbar.
Was ist hier passiert?

Dietmar63 · 18 Februar 2014, 14:53:23

Die Syntax für sysCmd hat sich geändert. :

Code Auswählen

attr wol_rechner sysCmd "/usr/sbin/etherwake"

man kann auf vielfachem Wunsch nun jeden fhem-Befehl angeben. Beispiel: wie <command> in at oder notify.
siehe auch Doku

siggi85 · 18 Februar 2014, 15:15:03

Zitat von: Dietmar63 am 18 Februar 2014, 14:53:23
man kann auf vielfachem Wunsch nun jeden fhem-Befehl angeben. Beispiel: wie <command> in at oder notify.

Achso, das ist irgendwie an mir vorbei gezogen. Das werde ich zu Hause mal testen.

EDIT:
In der commandref steht es noch anders drin:

Code Auswählen

Attributes

    attr <name> sysCmd <string>
    Custom command executed to wakeup a remote machine, i.e. /usr/bin/ether-wake or /usr/bin/wakeonlan

Owel · 18 Februar 2014, 15:46:32

Zitat von: Dietmar63 am 18 Februar 2014, 14:53:23
Die Syntax für sysCmd hat sich geändert. :
Code Auswählen Erweitern
attr wol_rechner sysCmd "/usr/sbin/etherwake"

Gibt bei mir im Log

Code Auswählen

2014.02.18 15:45:17 3: WOL set Tower on
2014.02.18 15:45:17 3: WOL waking  Tower with MAC 00:25:22:24:6C:03 IP 192.168.178.11 
2014.02.18 15:45:19 3: WOL keeping Tower with MAC 00:25:22:24:6C:03 IP 192.168.178.11 busy
2014.02.18 15:45:19 1: [Tower] system command '"/usr/bin/wakeonlan"' not found

Funktioniert also auch nicht

siggi85 · 18 Februar 2014, 15:55:44

Ich weiß, dass das "shutdownCmd" Attribut daraufhin geändert wurde, aber das sysCmd wüsste ich bisher nicht. Ich sage das nur auf die Gefahr hin, dass du das vielleicht vertauscht haben könntest?!
Dazu kommt noch, dass es bei mir vorher auch ohne Etherwake funktioniert hat, also mit dem Net::Wake(CPAN) Modul.

Dietmar63 · 18 Februar 2014, 18:02:03

ZitatIch weiß, dass das "shutdownCmd" Attribut daraufhin geändert wurde, aber das sysCmd wüsste ich bisher nicht. Ich sage das nur auf die Gefahr hin, dass du das vielleicht vertauscht haben könntest?!

stimmt, habe ich auf die Schnelle durcheinander gebracht.

ZitatDazu kommt noch, dass es bei mir vorher auch ohne Etherwake funktioniert hat, also mit dem Net::Wake(CPAN) Modul.

Diese Methode ist unverändert geblieben, und läuft bei mir problemlos mit dem NAS von Buffalo.

Kann es sein, dass die Probleme seit der Umstellung auf FB 6.03 zusammenhängen.

ich habe diesen Code eingebaut:

Code Auswählen


  #               Fritzbox               Raspberry
  my @commands = "/usr/bin/ether-wake", "/usr/sbin/etherwake";

  my $standardEtherwake = "no etherwake installed";
  foreach my $sysCmd (@commands) {
     if (-e $sysCmd) {
        $standardEtherwake = $sysCmd;
     }
  }

  my $sysCmd = AttrVal($hash->{NAME}, "sysCmd", $standardEtherwake);

mit ihm soll intelligent nach dem Pfad des etherwake Kommandos gesucht werden. Funktioniert auf meiner FB auch soweit. Ich prüfe nocheinmal nach was los sein könnte.

siggi85 · 18 Februar 2014, 18:09:12

Also ich habe keine FB sondern FHEM auf nem Rasp laufen. Ich bin aber zuversichtlich, dass wir noch dahinter kommen, woran es liegt.

Dietmar63 · 18 Februar 2014, 18:37:32

kann jemand von euch mal die anhängende Datei ausprobieren.

Ich glaube meine Schleife hat nicht richtig funktioniert, und die RPI Pfade wurden nicht ausgewählt, bzw. "/usr/sbin/etherwake" funktioniert wg. der Rechteverwaltung nicht.

Owel · 19 Februar 2014, 06:58:48

Ich glaube ich habe den Fehler gefunden!

Code Auswählen

qx ("$sysCmd $mac");
die " machen hier glaube ich einen error.
Zumindest bei mir. Wenn ich diese entferne funktioniert WOL wieder.
Die Zeile muss also

Code Auswählen

qx ($sysCmd $mac); lauten.

Und wenn du schonmal dabei bist, kannst du bitte auch den STATE abhängig von isRunning setzen?
Ich habe öfters den Fall dass STATE=on aber isRunning = false und umgekehrt. Kommt daher dass ich den PC nicht nur mit FHEM bediene.

Danke
Owel

Dietmar63 · 19 Februar 2014, 21:52:24

habe eine geänderte Version eingecheckt.

Zitat
Und wenn du schonmal dabei bist, kannst du bitte auch den STATE abhängig von isRunning setzen?
Ich habe öfters den Fall dass STATE=on aber isRunning = false und umgekehrt. Kommt daher dass ich den PC nicht nur mit FHEM bediene.

STATE soll den Zustand des WOL angeben und nicht den Zustand des zu schaltenden Geräts, insofern sehe ich keine Veranlassung den STATE mit isRunning zu synchronisieren.

Wenn du für dich den STATE des anzuschaltenden Geräts in der Anzeige des WOL sehen möchtest, kannst du stateFormat verwenden:

Code Auswählen

attr   NAS               stateFormat {sprintf("%s",ReadingsVal("NAS","isRunning","???")eq "true" ? "on":"off")}

Owel · 20 Februar 2014, 07:24:33

Ok das mit State sehe ich anders.
Aber da du ja eine feine Lösung präsentiert hast, werde ich das so nutzen

siggi85 · 20 Februar 2014, 15:45:18

Die on/off Lösung für den STATE finde ich schöner als meine true/false Lösung, habe ich auch mal übernommen.

Aber an geschaltet bekomme ich meinen Rechner immer noch nicht über das WOL Modul. off und refresh funktionieren super, aber on streikt weiterhin...

Dietmar63 · 20 Februar 2014, 17:28:50

Schalte mal für das WOL verbose auf 5, und veröffentliche den Output im log dazu.

Bitte auch die Definition angeben. Welches Kommando führst du beim shutdown aus?

siggi85 · 20 Februar 2014, 21:28:00

Log

Code Auswählen

2014.02.20 21:21:07 3: [wz_wol_htpc] set wz_wol_htpc on
2014.02.20 21:21:07 3: [wz_wol_htpc] waking  wz_wol_htpc with MAC e0:cb:4e:40:b7:aa IP 192.168.12.20 
2014.02.20 21:21:07 4: [wz_wol_htpc] keeping wz_wol_htpc with MAC e0:cb:4e:40:b7:aa IP 192.168.12.20 busy
2014.02.20 21:21:07 5: [wz_wol_htpc] standard wol command: /usr/bin/wakeonlan
2014.02.20 21:21:07 5: [wz_wol_htpc] user wol command(sysCmd): '/usr/sbin/etherwake'
2014.02.20 21:21:07 5: [wz_wol_htpc] executing /usr/sbin/etherwake e0:cb:4e:40:b7:aa

Definition

Code Auswählen

define wz_wol_htpc WOL e0:cb:4e:40:b7:aa 192.168.12.20
attr wz_wol_htpc devStateIcon off:black_FS20.off on:black_FS20.on
attr wz_wol_htpc fp_wohnzimmer 137,434,2,HTPC
attr wz_wol_htpc group HTPC
attr wz_wol_htpc interval 30
attr wz_wol_htpc room Wohnzimmer
attr wz_wol_htpc shutdownCmd set wz_xbmc_htpc shutdown
attr wz_wol_htpc stateFormat {sprintf("%s",ReadingsVal("wz_wol_htpc","isRunning","???")eq "true" ? "on":"off")}
attr wz_wol_htpc sysCmd /usr/sbin/etherwake
attr wz_wol_htpc verbose 5
attr wz_wol_htpc webCmd on:off:refresh

Etherwake von Commandozeile funktiniert, sowohl als root,pi und fhem Nutzer (Sticky Bit ist gesetzt).

EDIT: Ich seh gerade wir sind ja noch in einem "Shutdown funktioniert nicht Thread". Bei mir funktioniert das Aufwachen nicht, der Shutdown funktioniert!

Dietmar63 · 21 Februar 2014, 00:24:55

lösch bitte mal diese Zeile:

Code Auswählen

sysCmd /usr/sbin/etherwake
dann mußte /usr/bin/wakeonlan aufgerufen werden - das funktioniert bei mir.

siggi85 · 21 Februar 2014, 11:47:26

Alles klar. Seit dem Update gestern habe ich das nicht mehr ohne sysCmd getestet. Werde ich heute nachmittag/abend ausprobieren und Rückmeldung geben!

Dietmar63 · 21 Februar 2014, 12:02:41

sbin/etherwake funktioniert bei mir nicht.
Ich vermute, dass es mit Berechtigungen zu tun hat. Fhem läuft auf dem Rpi unter dem user fhem, darf eigentlich nichts aus sbin aufrufen. Es gibt bestimmt die Möglichkeit sudo für fhem zuzulassen, aber einfacher ist wakeonlan zu nutzen. Bei mir wacht der Büro-PC damit auf.

Der eine oder andere hat einfach solange die binarys etherwake hin- und herkopiert oder umbenannt, bis der wol funktionierte.

Eventuell müssen wir mit Wireshark prüfen ob die Magic-Pakete ankommen.

siggi85 · 21 Februar 2014, 12:21:20

Die Berechtigung meiner etherwake Binary steht eigentlich auf 755 + Sticky Bit, Berechtigung sollte eigentlich passen. Habe es auf Kommandozeile unter jedem User probiert (auch dem fhem Nutzer).
Aber ich werde es noch mal ohne den sysCmd und mit wakeonlan probieren. Falls das nicht klappen sollte, gucke ich parallel mal in tcpdump ob Pakete generiert wurden.

siggi85 · 21 Februar 2014, 18:59:46

Nach ein bisschen testen funktioniert es nun.

Durch den Eintrag "stateFormat {sprintf("%s",ReadingsVal("wz_wol_htpc","isRunning","

")eq "true" ? "on":"off")}" oder "stateFormat isRunning" ist der STATE des WOL Devices nicht auf "on". Sobald ich das stateFormat Attribut raus nehme und über setstate den Status auf "on" setze funktioniert WOL wieder.

Kann es sein, dass in dem Skript eine Prüfung existiert, dass der "set WOL on"-Befehl nur durchgeführt wird, wenn der State des WOL-Devices auf on steht???

Dietmar63 · 21 Februar 2014, 20:50:24

ja,

das Modul wurde seinerzeit so programmiert, dass man das Geräte mit dem define definiert. Dann wird das zugehörige Gerät nicht gestartet. Mit "set xxx on" wird das Wol in den Zustand on versetzt und einmal bzw. regelmäßig Magicpakete versand.

siggi85 · 21 Februar 2014, 22:37:25

Achso, na das erklärt einiges.

Dann weiß ich in Zukunft wie ich mit dem WOL Modul umzugehen habe damit es in meiner Umgebung funktioniert.
Aber das stateFormat-Attribut ist dann ein gefährliches für die korrekte Funktionsweise.
Wenn man das Modul nicht umschreibt, wäre vielleicht ein Hinweis in der Commandref hilfreich. Der nächste stolpert vielleicht wieder in das Problem.