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:
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
Als welcher User läuft FHEM und als welcher User hast Du es probiert??
was sagt ein
ls -lha /volume1/@appstore/FHEM/bin/wolle_internet_shutdown.sh
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.
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:
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
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.
eingechecked
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
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.
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.
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?
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.
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.
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.
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).
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
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. :)
selbiges Problem habe ich auch
Also bei mir kommt seit heute auch folgende Fehlermeldung:
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?
Die Syntax für sysCmd hat sich geändert. :
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
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:
Attributes
attr <name> sysCmd <string>
Custom command executed to wakeup a remote machine, i.e. /usr/bin/ether-wake or /usr/bin/wakeonlan
Zitat von: Dietmar63 am 18 Februar 2014, 14:53:23
Die Syntax für sysCmd hat sich geändert. :
attr wol_rechner sysCmd "/usr/sbin/etherwake"
Gibt bei mir im Log
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 foundFunktioniert also auch nicht :(
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.
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:
# 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.
Also ich habe keine FB sondern FHEM auf nem Rasp laufen. Ich bin aber zuversichtlich, dass wir noch dahinter kommen, woran es liegt. :)
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.
Ich glaube ich habe den Fehler gefunden!
qx ("$sysCmd $mac");
die " machen hier glaube ich einen error.
Zumindest bei mir. Wenn ich diese entferne funktioniert WOL wieder.
Die Zeile muss also
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
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:
attr NAS stateFormat {sprintf("%s",ReadingsVal("NAS","isRunning","???")eq "true" ? "on":"off")}
Ok das mit State sehe ich anders.
Aber da du ja eine feine Lösung präsentiert hast, werde ich das so nutzen :)
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... :(
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?
Log
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
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!
lösch bitte mal diese Zeile:
sysCmd /usr/sbin/etherwake
dann mußte /usr/bin/wakeonlan aufgerufen werden - das funktioniert bei mir.
Alles klar. Seit dem Update gestern habe ich das nicht mehr ohne sysCmd getestet. Werde ich heute nachmittag/abend ausprobieren und Rückmeldung geben! :)
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.
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.
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???
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.
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. :)