Hallo,
habe bei mir nun mit WOL eingestellt das mein PC runterfährt und auch wieder hochfährt!
Nun ist aber das Problem das der PC nach einer gewissen Zeit nicht mehr auf das WakeOnLan reagiert jedoch direkt nach dem Runterfahren schon.
Wenn ich jedoch z.B. die WakeOnLan App auf meinem Smartphone nutze geht der PC sofort an!
Kennt das Problem evtl. jemand und hat eine Lösung?
Gruß
Moin,
wie hast Du WOL eingerichtet? Am Besten Du lieferst ein list <WOL Name> in Codetags (die # Taste über dem :-X Smily)
Gruß Otto
Sehr gerne. ;)
Internals:
DEF 4C:CC:6A:93:A3:6D 192.168.50.43 UDP
IP 192.168.50.43
MAC 4C:CC:6A:93:A3:6D
MODE UDP
NAME AZ_PC
NR 23
REPEAT 000
STATE off
TYPE WOL
Helper:
DBLOG:
active:
DBLogging:
TIME 1505720650.23506
VALUE on
isRunning:
DBLogging:
TIME 1505721472.39074
VALUE false
packet_via_UDP:
DBLogging:
TIME 1505720650.40044
VALUE 192.168.50.43
state:
DBLogging:
TIME 1505721472.39074
VALUE off
READINGS:
2017-09-18 09:44:10 active on
2017-09-18 09:57:52 isRunning false
2017-09-18 00:11:29 packet_via_EW none
2017-09-18 09:44:10 packet_via_UDP 192.168.50.43
2017-09-18 09:57:52 state off
TIMER:
AZ_PC_ping:
HASH AZ_PC
MODIFIER ping
NAME AZ_PC_ping
helper:
Attributes:
room 01_Arbeitszimmer
shutdownCmd "wget http://192.168.50.43:7760/forcepoweroff"
Eingerichtet hatte ich das ganze nach dieser Anleitung: http://heinz-otto.blogspot.de/2015/04/computer-mit-fhem-und-ausschalten.html
Nur das runterfahren wollte auch nicht so wie ich das wollte deswegen habe ich da eine Alternative benutzt!
Wie hast Du den Rechner eingerichtet, der Hochfahren soll? E hört sich an, als ob der Zielrechner nicht die Netzwerkkarte mit Dauerstrom versorgt. So wird er nicht mehr reagieren, wenn die Internen Speicher (Elkos) leer sind .. also nach zeit X
Exakt das wäre auch mein Ansatz. Problem liegt nicht bei FHEM, sondern beim Rechner der nicht mehr auf den WOL reagiert.
Zitat von: Psychokiller am 18 September 2017, 09:59:51
Eingerichtet hatte ich das ganze nach dieser Anleitung: http://heinz-otto.blogspot.de/2015/04/computer-mit-fhem-und-ausschalten.html
Nö hast Du nicht :o Du hast vergessen ->
ZitatUm zu konfigurieren, dass ein UDP Broadcast versendet wird, muss noch die Broadcast Adresse konfiguriert werden.
Am Besten also in der Oberfläche das Attribut eintragen:
attr AZ_PC useUdpBroadcast 192.168.50.255@Werner Wenn aber eine App auf dem Smartphone den Rechner immer aufwachen kann. Dann ist er doch generell in Bereitschaft ;)
Gruß Otto
Jop der Rechner ist definitiv erreichbar ich kann die Android App "WakeOnLan" sowie "Unified Remote" nutzen bei beiden Apps geht der Rechner direkt an wären bei FHEM keine Reaktion ist!
@Otto123
attr AZ_PC useUdpBroadcast 192.168.50.255
dieses habe ich nicht eingefügt da ich davon ausgehe das damit ein WakeOnLan befehl an alle im Netzwerk befindlichen Geräte gesendet wird oder verstehe ich das Falsch?
Gruß
Psycho
Zitat von: Psychokiller am 18 September 2017, 10:46:16
dieses habe ich nicht eingefügt da ich davon ausgehe das damit ein WakeOnLan befehl an alle im Netzwerk befindlichen Geräte gesendet wird oder verstehe ich das Falsch?
Ja und nein. Man muss den wake on lan Befehl an alle schicken! Alle lauschen mit und nur der mit der MAC wacht auf.
Eventuell ist genau das des Rätsels Lösung. Eine Weile kennt Dein Switch den Anschluss, deswegen geht es erstmal. Wenn er die Adresse vergessen hat weiß er nicht mehr was er machen soll und verwirft das Paket.
Gruß Otto
Warum so komplex? MAC und IP definieren, fertig...
#WOL Modul
define WOL_WHS WOL 00:25:22:FF:XX:XX 192.168.XXX.XX BOTH
attr WOL_WHS room Windows Rechner
Denn die NW-Karte des Rechners lauscht war es das schon. Einen Broadcast brauchts da nicht...
Zitat von: Tedious am 18 September 2017, 10:57:21
Warum so komplex? MAC und IP definieren, fertig...
Komplex?
UDP arbeitet ohne ether-wake
Bei BOTH wird mit TCP gearbeitet und man muss erst ether-wake installieren.
Das ist nicht komplex? :-*
@Otto
Du hast recht, habe es falsch "gelesen". Hatte verstanden, das es auch mit dem Handy nicht geht .. war aber genau anders herum ;o)
P.S. Es ist klar, das ein Rechner im Ausgeschalteten Zustand, aber er hört auf WOL, auch (deutlich) Strom zieht?
Natürlich. ein Unicast ist um ein vielfaches sicherer als ein Broadcast (Stichwort "Smurf Attack"). Netzwerk-Bandbreite spielt heutzutage zwar meist keine Rolle mehr, aber auch das ist definitiv ein Nachteil des Broadcasts. Etherwake installieren ist nun wahrlich kein Hexenwerk. UDP ist prinzipiell ungeregelter Datenverkehr, ich persönlich würde davon absehen wenn möglich...
Zitat von: Wernieman am 18 September 2017, 11:07:54
P.S. Es ist klar, das ein Rechner im Ausgeschalteten Zustand, aber er hört auf WOL, auch (deutlich) Strom zieht?
Ich habe festgestellt, das hängt stark von der Hardware ab. Die moderneren Boards und gute ATX Netzteile bleiben da erfreulich unter 0,5 Watt. Es lohnt sich immer genau zu schauen. Notfalls auch umzurüsten.
BTW: Das Aufwachen Paket ist meines Wissens immer ein Broadcast. Um ihn nicht durchs gesamte Netz zu schicken (255.255.255.255) ist es gut eine "gezielte" Broadcast Adresse zu haben damit er auf ein Subnetz beschränkt wird. Wobei Broadcasts sowieso nicht geroutet werden ...
Zitat von: Tedious am 18 September 2017, 11:16:49
UDP ist prinzipiell ungeregelter Datenverkehr, ich persönlich würde davon absehen wenn möglich...
Dann ist deine Empfehlung mit BOTH ein Schuss in die .... ::)
Vielen Dank für eure Hilfe.
Habe nun das Attribute mal hinzugefügt und werde beim nächsten Aufweckversuch berichten!
@Wernieman
In anbetracht dessen das mein PC vorher 24/7 angewesen ist, denke ich kann ich den Stromverbrauch im WOL betrieb verkraften und das schon als fortschritt ansehen. ;D
Gruß
Psycho
Nein. Ein TCP-WOL an eine IP/Mac ist KEIN Boradcast!
Zitatie Netzwerkkarte wartet auf ein so genanntes Magic Packet (Schutzmarke von AMD), bei dessen Empfang der Rechner eingeschaltet wird.
Das Datenpaket ist entweder direkt an die Netzwerkkarte adressiert oder wird als Broadcast verschickt. Es enthält sechsmal in Folge den hexadezimalen Wert FF; unmittelbar danach erscheint die ununterbrochene 16-malige Wiederholung der MAC-Adresse der Netzwerkkarte des jeweiligen Zielsystems. Dieser Inhalt kann in ein beliebiges Paket (z. B. IP, IPX) verpackt sein. Es existieren viele Software-Tools (z. B. etherwake für unixähnliche Betriebssysteme), die solche Pakete versenden können.
Ja, ich nutze BOTH. Aber eben nicht als Broadcast in ein Subnetz. Aber Du hast nicht ganz unrecht, der Parameter seht dort schon zu lange, den sollte ich durch EW ersetzen.
@Tedious
ich sage mal so: Ich will nicht streiten was genau die Definition für "broadcast" ist.
Letztlich hat die Netzkarte keine logische Verbindung mehr - das Magic Packet muss an alle im Segment gehen.
Solange wie noch einer weiß an welchem Anschluss die MAC aktiv war kann er das Paket dahin schicken, wenn die arp table leer ist geht das nicht mehr. Dann müsste die Netzwerkkomponente wissen wo es lang gehen soll. Weiß sie auch, anhand der Netzwerk Broadcast Adresse, die ist per Definition im class c Netz die x.x.x.255.
Das Perl Modul mit dem bei WOL UDP Pakete verschickt werden, will sich die Adresse offenbar nicht "errechnen". Warum auch immer. etherwake macht das wahrscheinlich einfach. Ist nur eine Annahme von mir!
BTW: UDP ist auch kein ungeregelter Verkehr, es ist verbindungsloser Verkehr, der Sender bekommt keine Quittung.
Jetzt ist gut :D
Zitat von: Otto123 am 18 September 2017, 10:51:50
Eventuell ist genau das des Rätsels Lösung. Eine Weile kennt Dein Switch den Anschluss, deswegen geht es erstmal. Wenn er die Adresse vergessen hat weiß er nicht mehr was er machen soll und verwirft das Paket.
Cooltux hat dieses Verhalten im Umkehrschluss hier im Prinzip unfreiwillig nachgewiesen -> https://forum.fhem.de/index.php/topic,66671.msg687237.html#msg687237
Er verwendet die Routine aus WOL -> also bei UDP muss bei dem Modul die Broadcast Adresse angegeben sein.
Die kann im Übrigen auch ruhig unabhängig vom konkreten Subnetz 255.255.255.255 sein. Eigentlich könnte das Modul die intern als default nehmen damit es nicht zu
komplex wird. ;D ;D
Weiß sie auch, anhand der Netzwerk Broadcast Adresse, die ist per Definition im class c Netz die x.x.x.255.
Vom Prinzip her hat Otto Recht und in 99% der Haushalte wird das auch funktionieren.
Dennoch erlaubt mir die Anmerkung das die Broadcastaddresse sich immer aus dem Subnetz errechnet. Genau so wie die Anzahl der Host oder die so genannte Netzadresse.
Ich verwende kleinere Subnetze, davon aber dann viele. Bei mir ist die Netzmaske z.B. nicht 255.255.255.255 sondern 255.255.255.248
Das ergibt 6 Clientadressen pro Subnetz und somit für 192.168.1.x , 31 Subnetze (wenn ich mich jetzt nicht verrechnet habe)
Grüße
Ich würde auch so rechnen - und damit ist das attr hier auch voll berechtigt!
Das mit dem Broadcast war die Lösung!
Vielen Dank
Gruß
Psycho