Aktualisierung 98_WOL.pm

[UliM]

Hallo,
laut SVN wurde 98_WOL.pm am 11.03.13 durch user klassm auktualisiert.
Dabei wurde leider die bekannte Interferenz mit HMLAN nicht behoben,
siehe: Link

Kann klassm das bitte nachholen?

Danke+Gruß,
Uli

[UliM]

Hi,
leider noch immer nicht geschehen - nach dem letzten update war mein log wieder voll von disconnected/reappeared-Meldungen.

Sollte klassm sich bis Ende Juni nicht hier melden, werde ich die ping-Zeitbegrenzung auf 1s in 98_WOL.pm einchecken, siehe Link oben.

Gruß, Uli

[maeb3]

Bitte bei der Gelegenheit (Aktualisierung 98_WOL.pm) am Besten auch gleich die Thematik "IP-Adresse enthält 100" bereinigen.  
Mit

Code Auswählen Erweitern

if (`ping -c 1 $ip` =~ m/100/) {
im Modul wird nach "100" in der Antwort des Pings gesucht, wie sie z.B. bei "100% packet loss" vorkommt und daraus geschlossen, dass das Gerät nicht online ist. Die "100" wird aber auch gefunden, wenn sie in der IP-Adresse enthalten ist (z.B. 192.168.10.100).

Besser wäre daher:

Code Auswählen Erweitern

if (`ping -c 1 $ip` =~ m/100%/) {
mit dem %-Zeichen hinter der 100; dann wird nach "100%" gesucht und IP-Adressen mit "100" funktionieren wieder.

(siehe auch Beitrag 62653 oder Beitrag 52087

Grüße, maeb3

[UliM]

Hi,
eingecheckt, revision 3510.
Ab morgen per update.
Gruß, Uli

[StefanP]

Hallo Uli,
ich hab gestern ein Update gemacht. Dabei ist auch die neue Version von 98_WOL auf meine FB gelangt. Danach fiel mir ein dass ich schon lange eine Änderung im WOL-Modul mitschleppe und immer zur Aufnahme in den offiziellen Code vorschlagen wollte:

In der Sub "WOL_GetUpdate" fehlt meiner Meinung der Update der STATE-Variable, so dass WOL-Objekte in der Oberfläche immer "ON" dargestellt werden.
Nach Anpassung:

Code Auswählen Erweitern


sub WOL_GetUpdate($)                                                        
{                                                                            
  my ($hash) = @_;                                                          
                                                                             
  my $ip = $hash->{IP};                                                      
  #if (system("ping -q -c 1 $ip > /dev/null") == 0)                          
  ####                                                                      
  #changed 2013-07-27 by UliM                                                
  #based on Thread http://forum.fhem.de/index.php?t=msg&th=11823&goto=69801&rid=86#msg_69801
 #if (`ping -c 1 $ip`      =~ m/100/)                                                      
  if (`ping -c 1 -w 1 $ip` =~ m/100%/)                                                      
  {                                                                                        
    $hash->{READINGS}{state}{VAL} = "off";                                                  
    $hash->{READINGS}{isRunning}{VAL} = "false";                                            
    $hash->{STATE} = "off";                                                                
  } else                                                                                    
  {                                                                                        
    $hash->{READINGS}{state}{VAL} = "on";                                                  
    $hash->{READINGS}{isRunning}{VAL} = "true";                                            
    $hash->{STATE} = "on";                                                                  
  }                                                                                        
  $hash->{READINGS}{state}{TIME} = TimeNow();                                              
  $hash->{READINGS}{isRunning}{TIME} = TimeNow();                                          
                                                                                           
  InternalTimer(gettimeofday()+$hash->{INTERVAL}, "WOL_GetUpdate", $hash, 0);              
}                                                                                          


Nun wird auch der Status richtig angezeigt. Spricht was gegen die Änderung was ich übersehen hatte?
Bei mir läuft die Änderung seit ca. einem Jahr ohne Seiteneffekte.
Sorry, dass ich das erst nach deiner Änderung schreibe, aber es war mir bis zum Update (mal wieder) entfallen und da ich deinen Kommentar im Code entdeckt habe war die Zeit reif für diesen Kommentar.

Gruß StefanP

[betateilchen]

Spricht was gegen die Änderung was ich übersehen hatte?

Ja. Man sollte STATE besser nicht direkt beschreiben, weil es sonst Probleme mit stateFormat geben kann. STATE wird normalerweise automatisch aus state abgeleitet.

Das separate Setzen von VAL und TIME kannst Du Dir übrigens sparen, wenn Du die Funktion ReadingsSingleUpdate() verwendest.
Erhöht außerdem die Lesbarkeit von Quelltext erheblich.

[StefanP]

Hallo betateilchen,
kannst Du mir mehr zum stateFormat sagen (oder mir 'ne Quelle zum nachlesen nennen)?
'stateFormat' steht doch als Attribut gar nicht für WOL-Devices/Entities(?) zur Verfügung. Wie wird denn dann STATE ordentlich upgedated, damit's in der der Oberfläche richtig angezeigt wird?

Danke für Erleuchtung ;-)

Gruß StefanP

[rudolfkoenig]

Doku zu stateFormat gibts natuerlich unter http://fhem.de/commandref.html#stateFormat

Da kann man auch sehen (paar Zeilen vorher), dass es allen Modulen zur Verfuegung steht, die die "neuen" readingsUpdate Funktionen verwenden, WOL tut es noch nicht...

[betateilchen]

dass es allen Modulen zur Verfuegung steht, die die "neuen" readingsUpdate Funktionen verwenden, WOL tut es noch nicht...

Dann sollte man vielleicht mal besser an dieser Stelle ansetzen anstatt noch mehr unschöne (im Sinne von nicht mehr "zeitgemäße") Dinge einzubauen.

(ist nur so ein Gedanke und meine ganz persönliche Meinung)

[StefanP]

Nun bin ich halt eher Anwender und kein Entwickler, schon gar nicht vom Modul WOL. Zeitlich bin ich momentan nicht in der Lage der (erfreulicherweise) stürmischen Entwicklung von fhem zu folgen (eigentlich bin schon ich froh wenn fhem einfach läuft). Je nachdem wie lange das letzte Update zurückliegt bin ich eher meist erstaunt/überrascht/schockiert über die vielen Neuerungen. Cooles Projekt, Respekt und Dank an alle Mitstreiter, trotzdem habt ihr mich abgehängt ;-)

Gruß StefanP

[Dietmar63]

Wenn ihr mich als Maintainer akzeptiert/eintragt, baue ich das Modul auf readingsUpdate um - klasm hat wenig Zeit.
Ich habe noch eine Erweiterung für NAS_Control in der Schublade, die würde ich dann mit freigeben.

[betateilchen]

Wenn Du das mit dem eigentlichen/bisherigen Maintainer abgesprochen hast und er nix dagegen hat, ist doch eigentlich alles geklärt.

frisch, fromm, frei ans Werk :)

[Dietmar63]

klasm meldet sich nicht

[Dietmar63]

ich sehe schon - ich stehe schon als Maintainer drin.

Code Auswählen Erweitern

FHEM/98_WOL.pm               dietmar63            http://forum.fhem.de Unterstützende Dienste
werde mich alsbald darum kümmern.

[rudolfkoenig]

>  klasm meldet sich nicht

Ich waere nicht so ungeduldig, Matthias liest vlt. nicht alle Gruppen regelmaessig, ich wuerde ihm noch Zeit geben. Er ist definitiv aktiv, siehe Link

Nach meinem willkuerlichen Regel sollte man 3 Wochen abwarten, bis man wegen nicht-aktivitaet des Betreuers selbst aktiv wird. Aber jeder freut sich ueber Patches :)


>  ich sehe schon - ich stehe schon als Maintainer drin.

Da ist aber nur Wunschdenken, in meiner Version steht klassm drin.

[Matthias]

Hi,

sorry, ich komme nicht dazu ständig das ganze Forum zu lesen. Danke Rudolf für den Hinweis auf den Thread hier! Wenn dietmar64 das Modul übernehmen will, habe ich nichts dagegen. Vermutlich kennt er die FHEM Interna sowieso (wesentlich) besser als ich. Also: Feel free!

Matthias

[Dietmar63]

Hallo,

bin wieder aus dem Kurzurlaub zurück - werde mich der Sache demnächst annehmen.
Wird ein wenig dauern, weil auch die Doku angepasst werden muss.

Wenn ich soweit bin, werde ich über das Forum einen zweiwöchigen Test anstoßen.
Für 5.5 wird es wohl noch nicht reichen.

[volschin]

Hallo zusammen,
ich bin auch gerade dabei das Modul zu testen. Dabei ist mir aufgefallen, dass der Status anscheinend nicht korrekt aktualisiert wird.

Wie im Screenshot erkennbar steht in den Readings im status korrekt on in STATUS aber ???.

Das ist doch sicher ein Bug, oder?

[Dietmar63]

Und hier der von mir angekündigte zweiwöchige Testphase für die Neuerung NAS_Control implementiert in 98_WOL.

Das Modul ist nebenbei komplett überarbeitet worden und bietet jetzt die Möglichkeit das Magicpaket regelmäßig an ein Gerät zu senden. Dies ist notwendig um bestimmte NAS(von Buffalo) wach zu halten. Auf mancher Hardware funtioniert WOL nicht richtig. Das dürfte an der speziellen hardware bzw. firewalls liegen. Ich habe nur eine FB 7270 zur Verfügung und kann nur dort Tests durchführen. Bei anderer Hardware bin ich darauf angewiesen, dass ihr testen helft.

Die Ursprünge und die Entwicklung der Funktion nas_control kann hier nachgelesen werden:
http://forum.fhem.de/index.php?t=msg&goto=80341&rid=405&srch=nas_control#msg_80341
Wir haben uns entschlossen kein eigenes Modul zu erstellen, sondern die Funktionalität in 98_wol.pm einzubauen.

Die alten Definitionen sollten so wie vorher funktionieren(Aufwärtskompatibilität)!
Wer also Zeit und Interesse hat - bitte testen, Doku ansehen und Feedback senden.

Eine komplette Definition könnte also so aussehen:

Code Auswählen Erweitern


define NAS                    WOL 00:24:A5:A6:10:E0 192.168.2.196 UDP 240
attr   NAS                    interval 3600
attr   NAS                    event-on-change-reading isRunning, STATE

Das Gerät NAS wird also alle 240 Sekunden per UDP-Methode mit einem Magicpaket versorgt.
Die alten Definitionen

Code Auswählen Erweitern

define NAS                    WOL 00:24:A5:A6:10:E0 192.168.2.196
sollten wie vorher funktionieren.

[StefanP]

Hallo,
ich benutze das Wol-Modul eigentlich nur um Geräte auf ihren Betriebszustand zu überwachen, nicht um sie einzuschalten. Geht das weiterhin?
Übersetzt Du den commandref-Teil noch? Ansonsten könnte ich Dir wenigstens da Unterstützung anbieten.

Gruß StefanP

[Dietmar63]

Ja - es sollte weiterhin funktionieren.

Man kann aber jetzt mit

Code Auswählen Erweitern


attr   NAS                    interval 3600

das Abfrageintervall verändern.
Bisher war es auf 15 Minuten fest eingestellt.

Eigentlich ist für deinen Zweck Presence gedacht. Es ist viel flexibler einsetzbar.

Übersetzt Du den commandref-Teil noch?

Wenn die Test ok sind, werde ich es eventuell übersetzen. Es ist bis dahin vielleicht noch Verbesserung an der Doku notwendig.

[StefanP]

Hallo Dietmar,

Eigentlich ist für deinen Zweck Presence gedacht. Es ist viel flexibler einsetzbar.

stimmt, aber als ich auf die Idee kam den Fernseher zu überwachen, um das Grundlicht zu schalten, gab's Presence noch nicht; da hab' ich eben Wol "mißbraucht". Die Manipulation des Abfrageintervalls ist cool, da hatte ich direkt im Code 180 Sekunden gesetzt.

Ja - es sollte weiterhin funktionieren.

Aber während das Device an ist, schickst Du doch regelmäßig MagicPackets (So ich deinen Code richtig verstehe). Wäre es nicht eine Idee noch den Mode "none" oder so einzuführen?

Ich werd' dein Modul auf jeden Fall bei mir (Fhem auf FB7390, WOL überwacht zwei Mediengeräte) testen und berichten.

Gruß StefanP

[Dietmar63]

Aber während das Device an ist, schickst Du doch regelmäßig MagicPackets (So ich deinen Code richtig verstehe). Wäre es nicht eine Idee noch den Mode "none" oder so einzuführen?

ja - aber nur dann wenn die Angabe repeat (Zeile 164) gesetzt ist:

(siehe Anhang / see attachement)

Also:
Die Überwachung(per ping) findet immer statt.
Das Gerät wird nur dann ge'wol't, wenn einmalig der Befehl "set xxx on" gesendet wird. Und dies wird nur dann wiederholt durchgeführt, wenn bei der Definition des wol der Parameter repeat mitgegeben wird. Die Wiederholung wird durch den Aufruf der Funktion InternalTimer(...+$hash->{REPEAT}...) erreicht.
 

[StefanP]

Hallo Dietmar,
jetzt hab' ich's auch kapiert ;-)
Mein Perl ist nicht ganz so fließend.

Gruß StefanP

[Dietmar63]

kein Problem.

Ich habe versucht die Erweiterung einzubauen, ohne die alte Funktionalität zu verändern.

Intern gibt es aber starke Veränderungen:
Ich habe festgestellt, dass in den Funktionen Parameter genutzt werden, die nicht übergeben wurden. Wie es möglich war, dass 98_wol trotzdem funktioniert hat, bleibt für mich im Dunkeln. Das Modul funktionierte auf meiner Fritte erst nachdem ich die Parameter mitgegeben hatte.

Aktuelle Version von 98_wol in 5.4:

(siehe Anhang / see attachement)

In Zeile 149 wird $host verwendet, eine Variable, die in Zeile 134 nicht übergeben wird: ???

Die Versorung von $host mit 255.255.255.255 in Zeile 143 funktionierte bei mir nicht.
 
Viel Lesen und Testen brachte bei mir die Erkenntnis, dass es möglich war mein NAS dann zu wecken, wenn ich als IP die Originaladresse des NAS 192.168.2.196 oder die Broardcastadresse 192.168.2.255 weitergegeben hatte.

[StefanP]

Hallo Dietmar,

Die Versorung von $host mit 255.255.255.255 in Zeile 143 funktionierte bei mir nicht.

Hast Du dir $host mal nach Zeile 143 ausgeben lassen? Vielleicht ist es ja doch schon gesetzt.

Ich habe deine Version bei mir eingesetzt. Meine bisherigen Aufrufe wie "define DerBreite WOL 5C:33:8E:83:91:26 192.168.23.184 180" funktionieren bei deiner Version natürlich nicht. Ob die refresh-zeit aber jemals funktioniert hat oder nur ignoriert wurde, muß ich nochmal nachvollziehen. Leider ist der STATE immer noch nicht gleich isRunning, d.h. man sieht in der normalen Anzeige nicht den aktuellen Zustand des überwachten Devices (das hatte ich bei mir immer "weggepatcht"). Wahrscheinlich hast Du recht und ich werde für meinen Nutzen wirklich auf Presence umsteigen. Ich suche jetzt aber mal meine WOL-fähigen Geräte zusammen um Dir ein paar Tests zu liefern.

Gruß StefanP

[Dietmar63]

define DerBreite WOL 5C:33:8E:83:91:26 192.168.23.184 180

kann auch nicht funktionieren. Zwischen der IP und 180 ist noch die Methode notwendig mit der geweckt werden soll: EW oder UPD oder BOTH.
etwa so:

Code Auswählen Erweitern

define NAS                    WOL 00:24:A5:A6:10:E0 192.168.2.196 UDP 240


Leider ist der STATE immer noch nicht gleich isRunning, d.h. man sieht in der normalen Anzeige nicht den aktuellen Zustand des überwachten Devices (das hatte ich bei mir immer "weggepatcht").

Das ist auch nicht beabsichtigt.
Der state sagt etwas über den Zustand des WOL aus, ob derzeit der Weckmodus eingeschaltet ist oder nicht. Und das Reading isRunning sagt etwas darüber aus, ob das abhängige Gerät eingeschaltet ist(auf ping reagiert). Diese beiden Zustände können natürlich auseinanderlaufen, wenn auch nur für kurze Zeit.

Mit "set NAS on" wird das wol angeschaltet und die Magicpakete versandt(eins oder mehrere). Wenn das abhängige Gerät dann eingschaltet ist und auf ping reagiert, ist das Reading isRunning true.

Ich sehe keinen Bedarf etwas zu ändern. Vielleicht mußt die die Logik "Gerät ist an" auf das Reading isRunning umbauen. Dann hast du was du willst. Auf isRunning könnte man sogar ein notify einrichten.

[Dietmar63]

Hast Du dir $host mal nach Zeile 143 ausgeben lassen? Vielleicht ist es ja doch schon gesetzt.

ja - habe ich und es ist in der alten Version von 98_wol nicht gesetzt bzw. es ist auf 255.255.255.255 gesetzt und damit wird das Magicpaket an 255.255.255.255 gesendet und kommt bei mir nirgends an.

[StefanP]

Vielleicht mußt die die Logik "Gerät ist an" auf das Reading isRunning umbauen. Dann hast du was du willst. Auf isRunning könnte man sogar ein notify einrichten.

Die Logik basiert auch auf dem isRunning-Reading. Ich hatte STATE = isRunning gepatcht, weil dadurch einfach der Betriebs-Status des Geräts als Icon dargestellt wurde. Wie gesagt, hatte ich WOL benuzt und verbogen weil's sonst nix gab.

Gruß Stefan

[maeb3]

Hallo zusammen,

ich habe das neue Modul bei mir mal eingespielt und für das Wecken und "kontinuierliche am Laufen halten" meiner Buffalo Linkstation Mini konfiguriert (UDP-Methode; repeat alle 180 Sekunden; Ping-Check alle 3600 Sekunden).

Bisher funktioniert alles so, wie ich es erwarte.

Ein Fehler ist mir noch aufgefallen:

In "sub WOL_Initialize" steht

Code Auswählen Erweitern

$hash->{AttrList}  = "interval shutdownCmd".
                        $readingFnAttributes;
Es muss aber ein Leerzeichen hinter shutdownCmd und vor das 2. Anführungszeichen, also

Code Auswählen Erweitern

$hash->{AttrList}  = "interval shutdownCmd ".
                        $readingFnAttributes;
denn ohne das Leerzeichen gibt es im FHEM Frontend als auswählbares Attribut in der DropDown-Liste nicht "shutdownCmd" und "event-on-change-reading", sondern nur den ungültigen Wert "shutdownCmdevenet-on-change-reading". Das Leerzeichen muss also da noch rein.

Grüße,
 Matthias

[Dietmar63]

werde ich ändern

[Dietmar63]

gemacht - wird nach dem Einchecken gefixed sein.

Hat jemand von Euch die alte Definitionsvariante geprüft und kann etwas dazu sagen, ob sie noch so funktioniert wie erwartet/bisher?

Code Auswählen Erweitern

define NAS                    WOL 00:24:A5:A6:10:E0 192.168.2.196

[Dietmar63]

Prüf mal bitte, ob du mit dem Attribut stateFormat auch erreichst was du willst.

Beispiel:

Code Auswählen Erweitern

attr   NAS               stateFormat {sprintf("%s",ReadingsVal("NAS","isRunning","notFound"))}
evenuell geht auch:

Code Auswählen Erweitern

attr   NAS               stateFormat {ReadingsVal("NAS","isRunning","notFound")}
Ich könnte mir sehr gut vorstellen, dass du dann auf den Patch verzichten kannst.
Diese Lösung ist mir erst jetzt eingefallen.

[Dietmar63]

98_WOL eingecheckt.

[betateilchen]

Dein WOL Problem entwickelt sich hier zu einer echten Seuche. Wieviele Threads brauchst Du eigentlich noch?

[Dietmar63]

Wenn du genau liest, wurde dieser thread eröffnet, weil der ping keine zeitliche Begrenzung hatte und für manche hier im Forum beschriebene HMLAN-Disconnects verantwortlich gemacht wurde.

Der thread wurde von uliM eröffnet.
Ich habe ihn nur genutzt, um meine Änderung bekannt zu geben!

Dass manche Pi's mit WOL nun Probleme haben, kann mit der Änderung wenig zu tun haben - ist jedenfall der jetzige Stand der Erkenntnisse.

[betateilchen]

kann es sein, dass hier im Thread ein Beitrag verschwunden ist? Meine Antwort hier im Thread kam vorhin auf einen Beitrag von ChrisW

[Dietmar63]

kann sein!

[ChrisW]

Ja hast recht mein Beitrag hab ich gelöscht da es nicht am WOL lag (zumindest der absturz) War wohl ziemlich Zeitgleich.

[Dietmar63]

WOL eingecheckt.

Ich habe des Attribut sysCmd ergänzt.
Per

Code Auswählen Erweitern

attr nas    sysCmd /usr/bin/wakeonlan
kann das System Kommando im Modus EW geändert werden.

[ChrisW]

Super Lösung vielen Dank

Aber das root Problem mit fhem und sachen aus dem usr/bin hab ich nun auch beim culflash ...  Muss mal rausfinden wie ich fhem als root benutze für sowas.

[betateilchen]

Muss mal rausfinden wie ich fhem als root benutze für sowas.

Das macht absolut keinen Sinn.

[Dietmar63]

was sollte man deiner Meinung nach tun?

[betateilchen]

Einzig gangbare Lösung für den Fragesteller: Nachdenken und endlich versuchen, Linux zu verstehen.

Programme in /usr/bin stehen in /usr (= User!) damit man eben KEINE Root-Rechte braucht, um diese ausführen zu dürfen. Deshalb ist es absolut sinnlos, einem regulären User oder einem permanent laufenden Prozess (wie z.B. fhem) die root-Rechte zu gewähren.

Das Hauptproblem hier im Thread ist in meinen Augen ein User, der einfach nicht weiß, was er eigentlich tut, weil ihm jegliches Grundverständnis fehlt. Das ist kein persönlicher Vorwurf, aber ich vermisse einfach die Bereitschaft, sich dieses fehlende Grundlagenwissen auch nur ansatzweise aneignen zu wollen. Stattdessen wird hier eine copy&paste-fertige Abschreiblösung verlangt - auch das ist für mich der falsche Lösungsansatz.

[bugster_de]

Hallo,

ich glaube ich kann da betateilchen nur zustimmen. Ich habe das 98_WOL seit geraumer Zeit im Einsatz und ich muß sagen, es ist kein Modul so pflegeintesiv wie dieses hier. Ich habe es jetzt mal aus dem automatischen Update rausgenommen (als einzigestes Modul), da ich auch mit der menge an Änderungen / Verbesserungen momentan nicht schritthalte. Die Idee des Moduls ist echt klasse, und ich finde es super, dass sich jemand diesem Modul annimmt (Danke Dietmar63), aber ich glaube die schiere Anzahl an Hardware Varianten und Kombinationen lässt die Komplexität des Moduls explodieren (FHEM auf Linux, RPi, FB, etc. mit HTPC, NAS, Webradios, etc.)

Effekte bisher:
der Shutdwn Command hat so wie implementiert nicht funktioniert (zumindest auf der FB7390 nicht). Siehe anderen Thread hier im Forum
mein HTPC, der als einzigster ein WOL device in FHEM ist, wacht dauernd mitten in der nacht auf. Ich hatte ewige Zeiten die Windows Update Verwaltung im Verdacht, bis ich jetzt gemerkt habe, dass das WOL wohl irgendwann mal einen Ping oder sowas schickt. Davon wacht der HTPC dann auch auf

Code Auswählen Erweitern

... das Hauptproblem hier im Thread ist in meinen Augen ...
...copy&paste-fertige Abschreiblösung verlangt...
nur hier im Thread? Jeder der mal ein etwas komplexeres Stück Perl Code gepostet hat, wird oftmals danach mit Anfragen überschüttet. Bei FHEM muß man sich halt im Klaren darüber sein, dass man Perl programmieren muß und dass gewisse Linux Verständnisse sehr hilfreich sind. Zumindest ich habe nicht die Zeit, jedem den Code dann so zu überarbeiten, dass er komplett copy&paste ist. deshalb nochmal Danke an Dietmar63, dass er sich dem Modul annimmt.

[Mani007]

Hallo ich seh gerade das ihr fleißig über das WOL modul diskutiert .

Mir ist aufgefallen wenn man fhem auf der FB7390 laufen hatt ist das ether-wake modul immer unter /usr/sbin/ether-wake abgelegt .

Betateilchen ist gerade off also sorry wenn ich vorgreife . Er hatmir in einem andern topic schon geschrieben ich soll nen link auf /usr/bin machen .

1. Ist /usr/bin/ und /usr/sbin/ read only filesystem.
2. In /usr/bin/ gibt es kein ether-wake was wohl daran liegt das es auf Linux distribution eben unter
/usr/bin liegt auf der Fritzbox unter /usr/sbin/ (ich hoffe das ist so korrekt) .

Ich versuche mich daran gerade 2 verschiedene Pfade abzufragen . Sonst müsste jeder FB7390 Nutzer der das Modul nutzen
will das nach jeden update abändern .Leider sind meine Perl kenntnisse noch zu schlecht .

Wäre vielleicht nicht so ein großes Problem zu lösen ??

Ich finde das Modul klasse !!!!

[Dietmar63]

Wenn die FB box tatsächlich mit ether-wake einen host wecken kann, dann macht es nicht unbedingt Sinn den Befehl immer irgendwo neu zu compilieren.

Ich habe deshalb dem Modul vor wenigen Tage folgendes Attribut gespendet:

Code Auswählen Erweitern

attr nas    sysCmd /usr/bin/wakeonlan
dort läßt sich auch mit modifiern wie -i lan ... eine Ergänzung anhängen. Am Ende wird dann noch die MAC angefügt.

Meine FB 7270 regiert darauf in keinster Weise. Mein NAS muss mit dem Parameter UDP(auch in 98_wol verfügbar) geweckt werden. Damit klappt es. Weiter oben habe ich beschrieben, dass die Funktion bei CPAN gemopst und für fhem angepasst wurde.

Wer auf häufige ping zur Überwachung des Nas verzichten kann, hat die Möglichkeit mit

Code Auswählen Erweitern

attr   NAS                    interval 3600
Dann wird nur einmal pro Stunde der Wachzustand überprüft. Ich glaube übrigens nicht, dass das 98_wol noch für  dissconnects von HMLAN verantwortlich ist. Der ping ist inzwischen durch den Parameter ping -c 1 -w 2 $ip zeitlich sehr begrenzt. Ich hätte intervall vielleicht in pingIntervall umbenennen sollen.

[Mani007]

Hallo,

1. Wenn die FB box tatsächlich mit ether-wake einen host wecken kann, dann macht es nicht unbedingt Sinn den Befehl immer irgendwo neu zu compilieren.

Ich kann jetzt bloß von meiner 7390 ausgehen. Ich  habe momentan keine 7270 zum testen da . Aber mit ether-wake -i eth0 MacAdressemeinesPC`s auf der Konsole startet mein
PC. Mich verwundert es das die 7270 das nicht tut .

Syscmd habe ich zu meiner schulden überlesen sorry . Aber Funktioniert einwandfrei Vielen Dank und Gute Arbeit jetzt muss ich nicht mehr jedes mal den Pfad abgleichen .

[bugster_de]

Hi,

ether-wake auf der Fritzbox:
http://www.wehavemorefun.de/fritzbox/Ether-wake

das Ether-wake auf der FB ist ein spezielles Etherwake aus der BusyBox Implementierung und entspricht NICHT dem Standard ether-wake von Linux Systemen. In busy-box wohl deutlich limitiert im Funktionsumfang.

Ausserdem haben das nicht alle Fritzboxen drauf.

[Dietmar63]

lt. Eric sollte es auf einer FB 7270 funktionieren:

Nabend,

so...habe mal geschaut auf der 7270 mit FRITZ!OS 05.50:

ether-wake liegt in /usr/bin und /usr/sbin

beide funktionieren mit dem Aufruf:
ether-wake BC:xx:C5:xx:10:E7

Standardmäßig nutzt ether-wake wohl eth0 als Interface. Je nach
Konfiguration kann das möglicherweise nicht passen. Klappt vielleicht
"ether-wake -i lan BC:AE:C5:76:10:E7" bei dir? Funktioniert bei mir
ebenfalls.

Habe grade das WOL Modul aktualisiert. EW und UDP funktionieren bei mir
beide. Der einzige Unterschied laut Wireshark: EW sendet ein Layer2 Frame (Ethernet Type 0x0842: WOL), während UDP ein Layer3 Paket (Ethernet Type 0x0800: IPv4) verschickt.

Bei ether-wake kann das Ganze also nicht geroutet werden. Vielleicht liegt hier das Problem?

Gruß, Eric

Ich habe noch 50.22 drauf - darin könnte das Problem bei mir begründet liegen. Ich werde auf 50.53 umsteigen und berichten.

[Dietmar63]

apropos shutdownCmd:
was funktioniert daran nicht? Ich selbst nutze ihn nicht, deshalb kann ich nichts dazu sagen.
Ich wüßte eh nicht wie man einen Host wieder zum Schalfen bewegt, wenn er vorher aufgeweckt wurde.

[Matthias]

@Dietmar63:
Zum Beispiel via ssh. Alternativ auf einen HTTP-Request (z.B. via Apache) hören. Über Sicherheit sollte man sich da allerdings ausführlich Gedanken machen ...