Hallo zusammen,
aufgrund dieser Diskussion https://forum.fhem.de/index.php/topic,97049.msg902378.html#msg902378 habe ich 98_WOL angepasst, um die Abhängigkeit zum Twilight Modul zu entfernen.
Da ich selbst nur eingeschränkt testen kann, wäre ich dankbar, wenn jemand mit komplexeren Szenarien das Ganze testen könnte und hier Feedback geben kann.
Anmerkung: Ich habe mich im ersten Schritt darauf beschränkt die Abhängigkeit zu entfernen, weitere kleinere Anpassungen (z.B. in der Commandref, oder bei den Set-Befehlen) werden bald nachgereicht.
Danke!
EDIT: Schon die erste Aktualisierung :)
Zitat
# Changelog:
# 2019-02-07, v1.02: First quick revision of commandref
# Added German commandref
# Removed textboxes for set commands
# Added version Info
# 2019-02-07, v1.01: Removed dependency with Twilight Module
EDIT 12.02.2019: Kommt ab morgen über das offizielle Update.
Hat von der 4 Runterladern schon jemand ein Feedback? (auch "funktioniert wie zuvor" wäre ein schönes Feedback :-))
Würde ggf. die nächsten Tage einchecken...
ZitatHat von der 4 Runterladern schon jemand ein Feedback?
die scheinbar nicht, aber der Fünfte ;D
Weil mein WOL gerade nicht wollte, hab ich mal gespielt und geguckt. Absturz, wenn man Unsinn in useUdpBroadcast schreibt ::)
Zitat
2019.02.10 10:11:55 3: [WOL_TV] invalid Broadcastadress<*.255.255.255> - use ddd.ddd.ddd.ddd
2019.02.10 10:11:57 3: [WOL_TV] set WOL_TV on
2019.02.10 10:11:58 3: [WOL_TV] waking WOL_TV with MAC ab:1C:B0:0F:79:zz IP 192.168.xyz.abc
2019.02.10 10:11:58 4: [WOL_TV] keeping WOL_TV with MAC ab:1C:B0:0F:79:zz IP *.255.255.255 busy
Bad arg length for Socket::pack_sockaddr_in, length is 0, should be 4 at /usr/lib/arm-linux-gnueabihf/perl/5.24/Socket.pm line 157.
scheinbar wird geprüft aber trotzdem gespeichert. Dann ist mir beim udp der Port ins Auge gefallen. Das macht so ja keinen Sinn. Es wird immer Port 9 benutzt.
<OT> Könnte das mein Problem sein ? <OT>
hab dann mal Deine Version ausprobiert: funktioniert wie zuvor. ;D
Grüße Markus
Hi Markus,
gefühlt werden alle meine "geerbten" Module von genau einer Person genutzt :D
Den fehlerhaften Check beim Attribut habe ich gefixt (im ersten Post aber noch nicht angehängt).
WOL nutzt UDP port 9 wenn kein anderer Port angegeben ist, allerdings gibt es beim broadcast garnicht die Möglichkeit einen port anzugeben... Da beißt sich die Katze in den Schwanz ;-)
Ich könnte natürlich noch erlauben einen Port mitzugeben, oder zumindest zwischen 7 und 9 auszuwählen... Deine Meinung?
Wieso machst du überhaupt einen broadcast? Oder war das nur zum Testen?
Grüße,
Oli
Hi Oli,
ZitatOder war das nur zum Testen?
Ja.
ZitatIch könnte natürlich noch erlauben einen Port mitzugeben, oder zumindest zwischen 7 und 9 auszuwählen... Deine Meinung?
(fast)keine Meinung, da ich nicht verstehe, was der Port im Zusammenhang bedeutet. :'( Ich hab halt ein WOL mit udp f. ein WLAN-device. mal geht's, dann aber nicht. Wenn es nicht klappt, hilft auch 1.000-mal on nichts. Ob da der Port Schuld sein könnte ? :-\ Wenn es mal wieder passiert, probier ich mal andere Ports.
Ich würd vorerst die jetzige Port-Logik auskommentieren u. auf fix 9 belassen.
Danke&Grüße
Markus
Ich würde die neue Version mo/Di auch mal antesten.
Nutze wol um bei Bedarf meinen home PC vom Büro aus anzuschalten.
Gesendet von meinem Doogee S60 mit Tapatalk
@Markus: UDP Pakete für wake-on-lan werden typischerweise über port 9 oder 7 geschickt. Hat dein Device immer Strom? Wenn ein Gerät stromlos war, geht WOL normalerweise nicht mehr.
Ich belasse es erstmal bei der derzeitigen Logik.
@Frank: Danke, werde deinen Test mal noch abwarten.
Kurz, weil mobil
ZitatHat dein Device immer Strom?
Im konkreten Fall ja.
Hallo, bei mir funktioniert es so
Ich habe an der Eingangstüre einen DashButton, wenn ich dort drücke, schaltet im Arbeitszimmer erst die PCA301 auf ON, danach kommt der WOL Befehl zum Einschalten des PC
"set AZ_PC_Steckdose on;; sleep 10 ;; set WernerPC on;;"
Das funktioniert mit dem alten WOL gut.
Wenn ich dann am PC sitze, habe ich auch einen DashButton der dann den PC per WOL runterfährt, dann die Steckdose ausschaltet und im Schlafzimmer die Bettlampe und Steckdose einschaltet.
{fhem("set WernerPC off; sleep 1 ; set Schlaf_Bett_Werner on; sleep 120 ; set AZ_PC_Steckdose off")}
so bin ich auch zufrieden ;) :)
Gruß Werner
PS: am nächsten WE kann ich das neue WOL ja mal testen
Moin Moin,
die "neue" WOL Version läuft genauso wie die "alte"
Ich kann keine Veränderung feststellen.
Zitat von: Frank_Huber am 12 Februar 2019, 08:40:39
Moin Moin,
die "neue" WOL Version läuft genauso wie die "alte"
Ich kann keine Veränderung feststellen.
So soll das sein :-) Danke für's Testen.
Kommt dann ab morgen über's reguläre Update.
Hallo KerniSani,
du bist der neue Maintainer vom WOL-Modul. Darf ich dich um eine Erweiterung des Moduls bitten?
Docker wird mehr und mehr auch hier genutzt. WOL geht aber nicht über Subnetze hinweg (MagicPackage), wird per Default nicht geroutet. Damit das im Modul auch funktioniert könnte mal den etherwake-Call über SSH auf den Host durchführen. Mach ich aktuell so.
Siehe Thread https://forum.fhem.de/index.php/topic,87714.0.html
Andere Idee, ähnlich wie im Bluetooth-Modul per Daemon auf dem Host. https://wiki.fhem.de/wiki/PRESENCE#Unterschied_presenced_.2F_lepresenced_.2F_collectord
Ich selber habe mir dazu das Modul modifiziert, aber die Frage war schon mehrfach da. Vielleicht wäre es mit geringem Aufwand einzubauen. Ich kann gerne testen wenn es dir helfen würde.
Danke dir
Zitat von: kadettilac89 am 24 Mai 2019, 21:59:12
Ich selber habe mir dazu das Modul modifiziert, aber die Frage war schon mehrfach da. Vielleicht wäre es mit geringem Aufwand einzubauen. Ich kann gerne testen wenn es dir helfen würde.
Sorry, ich war länger nicht aktiv. Magst du mir deine modifizierte Version schicken, dann schaue ich mir das an, und übernehme es (ggf. mit Modifikationen). Ich habe keine Docker am Laufen, daher würde ich gerne auf das Angebot zu testen zurückkommen...
Hi,
Zitat von: kadettilac89 am 24 Mai 2019, 21:59:12
WOL geht aber nicht über Subnetze hinweg (MagicPackage), wird per Default nicht geroutet.
Aber dafür gibt es doch den gezielten Broadcast mit dem Attribute packet_via_UDP
Damit funktioniert das wunderbar über Subnetze hinweg. etherwake sehe ich bei mir als völlig obsolete an.
Ich arbeite nur mit UDP Methode und setze generell die Broadcast Adresse via Attribute packet_via_UDP.
Ich arbeite analog auch aus Windows heraus mit Powershell Scripts so.
Eine Begründung für die Behauptung in Magicpacket gibt es aus meiner Sicht nicht:
https://de.wikipedia.org/wiki/Wake_On_LAN#Magic_Packet
Aber ich muss nicht Recht haben :)
Gruß Otto
Zitat von: Otto123 am 20 Dezember 2019, 23:39:35
Hi,Aber dafür gibt es doch den gezielten Broadcast mit dem Attribute packet_via_UDP
Damit funktioniert das wunderbar über Subnetze hinweg. etherwake sehe ich bei mir als völlig obsolete an.
Ich arbeite nur mit UDP Methode und setze generell die Broadcast Adresse via Attribute packet_via_UDP.
Ich arbeite analog auch aus Windows heraus mit Powershell Scripts so.
Anforderung war bezogen auf Docker-Fhem ... UDP-Paket fehlt... "# method to wake via lan, taken from Net::Wake package"
perl -MNet::Wake -e ''
Can't locate Net/Wake.pm in @INC (you may need to install the Net::Wake module)
--> Nicht im Container enthalten. Man könnte natürlich nachinstallieren ....
Zitat von: Otto123 am 20 Dezember 2019, 23:39:35
Eine Begründung für die Behauptung in Magicpacket gibt es aus meiner Sicht nicht:
https://de.wikipedia.org/wiki/Wake_On_LAN#Magic_Packet
Englisches Wiki ist ausführlicher ... https://en.wikipedia.org/wiki/Wake-on-LAN#Subnet_directed_broadcasts
A principal limitation of standard broadcast wake-on-LAN is that broadcast packets are generally not routed. This prevents the technique being used in larger networks or over the Internet. Subnet directed broadcasts (SDB)[8][9] may be used to overcome this limitation.
Es gibt Wege aber das Bedarf Konfiguration wie Host-Mode. Aus Docker im Default Netzwerk kommt nichts raus, UDP könnte gehen wenn man weitere Ports durchreicht.
Zitat von: Otto123 am 20 Dezember 2019, 23:39:35
Aber ich muss nicht Recht haben :)
Ich auch nicht :)
Mir geht es darum ggf. nützliche Funktionen für Module anzufragen ...
Für mich ist meine Modifikation ausreichend. Ich will keine Zusatzpakete im Docker oder weitere Ports NAT'en oder Firewall anpassen. Ich sehe an PM und ein paar Posts hier dass es Nachfrage gibt. Daher die Nachfrage an den Modulauthor.
Zitat von: KernSani am 20 Dezember 2019, 21:19:01
Sorry, ich war länger nicht aktiv. Magst du mir deine modifizierte Version schicken, dann schaue ich mir das an, und übernehme es (ggf. mit Modifikationen). Ich habe keine Docker am Laufen, daher würde ich gerne auf das Angebot zu testen zurückkommen...
Phil1602 hat das Modul um einen Parameter erweitert, vielleicht gibt er dir die Version wenn du ihn anschreibst.
https://forum.fhem.de/index.php/topic,87714.msg968916.html#msg968916
Meine Modifikation im Modul habe ich im selben Thread ein paar Beiträge weiter oben gepostet ..
https://forum.fhem.de/index.php/topic,87714.msg943068.html#msg943068
Vielleicht macht es Sinn das Thema etwas generischer anzugehen. Einfach ein Attribut wie von Phil1602 vorgeschlagen
Ich hab das Modul mal um einen "CMD" Mode erweitert, sodass ein Command (Fhem, Perl oder System) ähnlich des ShutdownCmd definiert werden kann und dann direkt aufgerufen wird ohne dass Etherwake oder Wakeonlan verwendet wird. Den Entwurf davon werde ich mal im zugehörigen Forum posten.
Finde das besser, bietet viel mehr Möglichkeiten da losgelöst von ssh oder Docker.
Testen ist kein Problem, Version hier anhängen oder PM.
Hi,
Zitat von: kadettilac89 am 21 Dezember 2019, 09:20:45
Vielleicht macht es Sinn das Thema etwas generischer anzugehen. Einfach ein Attribut wie von Phil1602 vorgeschlagen
Ich hab das Modul mal um einen "CMD" Mode erweitert, sodass ein Command (Fhem, Perl oder System) ähnlich des ShutdownCmd definiert werden kann und dann direkt aufgerufen wird ohne dass Etherwake oder Wakeonlan verwendet wird. Den Entwurf davon werde ich mal im zugehörigen Forum posten.
Finde das besser, bietet viel mehr Möglichkeiten da losgelöst von ssh oder Docker.
sorry erstmals, dass ich meinen Ansatz damals nur als Idee geteilt hatte und nicht den Code, habe KernSani meine Änderung nun zukommen lassen und auch nochmal hier angehängt.
Sicherlich kann man daran aber auch noch was verbessern, war von mir wie gesagt eher ein Quickfix, da ich im Bridged Docker Netzwerk laufen wollte und hatte dann die Idee die FritzBox API (über das FB Device) für WOL zu nutzen.
Ich habe dazu einfach einen zusätzliche Mode "wolCmd" hinzugefügt.
Falls es auch jemand über die FB realisieren möchte, der wolCmd sieht bei mir dann wie folgt aus:
get <FritzBoxDevice> tr064Command Hosts:1 hosts X_AVM-DE_WakeOnLANByMACAddress NewMACAddress "XX:XX:XX:XX:XX:XX"LG
Phil
Zitat von: Phil1602 am 25 Dezember 2019, 22:36:04
Ich habe dazu einfach einen zusätzliche Mode "wolCmd" hinzugefügt.
Falls es auch jemand über die FB realisieren möchte, der wolCmd sieht bei mir dann wie folgt aus:
get <FritzBoxDevice> tr064Command Hosts:1 hosts X_AVM-DE_WakeOnLANByMACAddress NewMACAddress "XX:XX:XX:XX:XX:XX"
LG
Phil
Alternativ über SSH würde es so aussehen wobei die Parameter bzw. der wake-Befehl abhängig vom Host-OS sind. Alles in Anführungszeichen funktioniert.
"ssh <user host>@<ip host> -p <ssh-port> sudo wake <interface> <mac_addr>"
Beispiel "ssh fhem_USR@192.168.2.99 -p 50 sudo wake em0 33:96:1F:1F:1F:1F"
Phil1602 hat vorgelegt. Mir gefällt das ssh-Command als Text einzutragen irgendwie nicht. Ich habe um SSH-Mode erweitert ... damit können die ssh-Werte per Attribut gesetzt werden. Für die meisten hier wird die Anpassung von Phil1602 ausreichen. Ob du SSH auch einbaust überlasse ich dir KernSani ... die Attribute sind nur ein paar Zeilen, jedoch die Rückfragen zu ssh landen dann hier :). Ich kann es für mich dann auch modifizieren.
Ich habe der Datei ".ssh" angehängt damit man sie unterscheiden kann. Die Endung muss entfernt werden.
Hallo zusammen,
ich bin endlich dazu gekommen, mir die patches anzusehen. Was mir vorschwebt:
* es gibt ein WOLCmd Attribut, welches das bisherige sysCmd-Attribut ersetzt
* das neue Attribut kann FHEM, Perl oder SysCmd enthalten
* Wenn SSH-Host gesetzt ist, wird der Befehl (der dann logischerweise zwingend ein SysCmd sein muss) über SSH ausgeführt
* Die zusätzliche SSH Option wird auch im shutdownCmd genutzt, oder gibt es aus eurer Sicht Fälle, wo wake-up über ssh und shutdown nicht SSH sind (oder umgekehrt)? Sprich, müsste man das nochmal irgendwie trennen?
Grüße,
Oli
ich editiere mal ohne Zitate ...
* es gibt ein WOLCmd Attribut, welches das bisherige sysCmd-Attribut ersetzt
==> macht Sinn, wüsste nicht was dagegen spricht
* das neue Attribut kann FHEM, Perl oder SysCmd enthalten
==> OK
* Wenn SSH-Host gesetzt ist, wird der Befehl (der dann logischerweise zwingend ein SysCmd sein muss) über SSH ausgeführt
==> OK
* Die zusätzliche SSH Option wird auch im shutdownCmd genutzt, oder gibt es aus eurer Sicht Fälle, wo wake-up über ssh und shutdown nicht SSH sind (oder umgekehrt)? Sprich, müsste man das nochmal irgendwie trennen?
==> Ich nutze das nicht, aber du sprichst was an was aus Usability Sicht nicht so einfach ist. Wenn ich über SSH ein WOL machen will habe ich einen "Jump-Server" der etherwake o. ä. ausführt da das Ziel noch offline ist (Sinn von WOL).
Das Runterfahren wird aber, sinnvollerweise, direkt auf dem Ziel ausgeführt. Man bräuchte eigentlich 2 SSH destinations. Außer man bedient sich dem Jump-Server und legt dort ein Script ab, aber dann wirds mit Rückgabe und Fehler abfangen komplexer.
==> Oder meintest du was anderes?
Folgendes könnte man machen:
- SSH Connection string nicht über 4 Attribute sondern nur eines ... Format, "fhem_WOL@192.168.0.2 -p 500" ... generell schöner.
Um WOL und Shutdown über SSH vollständig abzudecken bedarf es 4 Parameter. Ich schau mal vielleich komm ich am Abend dazu das mal zu bauen und einen Screenshot zu posten.
"sshConnectionWOL fhem_WOL@192.168.0.2 -p 500"
"sshConnectionDWN fhem_DWN@192.168.0.4 -p 200"
"WOLCmd wake em0"
"DWNCmd shutdown now"
Mit 2 Parameters wäre es relativ einfach das auszufähren, wenn SSH-String gefüllt einfach verketten ... $qxWOL = "ssh ".$sshConnectionWOL." -t ".CmdWOL ..... wenn SSH-String leer dann Befehl direkt ausführen ...
Mit dem Connection string wäre es auch einfach das Attribut schon beim Anlegen zu testen was späteren Support einfacher macht (was nicht funktioniert wird nicht gespeichert) ....
$ ssh -q $sshConnectionWOL exit
$ echo $?
schau dir das mal an, ich denke das wäre verständlich und für mich OK :)
SSH im angehängten Modul quick'n'dirty eingebaut. Perl ist nicht meine Mutter-Programmier-Sprache, mehr dirty .... ;)
Attibute:
defmod WOL_PC WOL 34:97:FF:FF:FF:FF 192.168.0.22 SSH
attr WOL_PC CmdDWN shutdown now <----
attr WOL_PC CmdWOL wake em0 <----
attr WOL_PC sshConnectionDWN fhem_WOL@192.168.0.22 -p 24 <---
attr WOL_PC sshConnectionWOL fhem_WOL@192.168.1.25 -p 50 <---
attr WOL_PC webCmd on off
Log:
2020.01.09 18:19:02.776 3: [WOL_PC] set Device: on Cmd: >"ssh fhem_WOL@192.168.1.25 -p 50 sudo wake em0 34:97:FF:FF:FF:FF"< executed
2020.01.09 18:18:57.138 3: [WOL_PC] set Device: off Cmd: >"ssh fhem_WOL@192.168.0.22 -p 24 sudo shutdown now"< executed
Meldung wenn eine SSH-Verbindung eingetragen wird die nicht funktioniert (zum Test nur beim WOL-String):
[WOL_PC] SSH-Login on Host failed: timeout or invalid ssh String <fhem_WOL@192.168.1.25 -p 55>
--> Die Prüfung ist streng, aber reduziert die Supportanfragen zu "deinem" Modul. In der Commandref könnte man auf die Anleitungen von Otto123 verweisen wenn er nihcts dagegen hat, der hat in seinem Blog zu Fhem auch Anleitungen wie SSH mit key zu konfigurieren ist.
Fragen: möchtest du per Definition die MAC immer am Ende des WOL-CMD anhängen, oder Platzhalter $mac, $ip o. ä. zulassen und dann im Sourcecode ersetzen? Ich möchte ungern die MAC direkt im Attribut setzen da diese Information in der DEF enthalten ist. Wenn du die MAC fest am Ende anhängst wird jedoch CMD nicht funktionieren. Platzhalter würden es sehr dynamisch machen.
Wenn du schon Modul änderst, kleiner Bug ... der Ping hat zwar -c 2 -t 2 aber dennoch läuft der Befehl länger als die 4 Sekunden die als Timeout gesetzt sind. Ggf. Timeout höher setzen und im qx ein ... timeout 5 ... o. ä. mitgeben.
2020.01.09 18:40:38.827 1: Timeout for WOL_Ping reached, terminated process 16623
Hi, danke erstmal:-D Schau ich mir später an. Ich hatte gestern vergessen zu erwähnen: Ich daxhte an Platzhalter ;-)
Kurz, weil mobil
Hallo zusammen,
danke für den Input. Neben ein paar kleineren Code-Bereinigungen und vereinzelt besserem Fehler-Handling ist in angehängter Version ist nun folgendes umgesetzt:
* Für bestehende WOL Devices ändert sich nichts (sprich: abwärtskompatibilität sollte bestehen)
* Es gibt im DEF die neue Option CMD (alternativ zu BOTH, EW und UDP)
* Es gibt folgende neue Attribute:
* wolCmd: kann FHEM, Perl (in {}) oder Systemkommando (in "") sein. Dieses Kommando wird ausgeführt, wenn mode CMD gesetzt ist
* sshHost: ist ein SSH Ziel in der Form user@host:port (wobei user@ und port optional sind). Wenn sshHost gesetzt ist (und mode CMD), wird wolCmd als ssh Befehl ausgeführt, dabei ist es unerheblich, ob der Befehl in "" gesetzt ist, oder nicht.
* sshHostShutdown: identisch zu sshHost, das (bereits bestehende) shutdownCmd wird über ssh ausgeführt, dabei ist es unerheblich, ob der Befehl in "" gesetzt ist, oder nicht.
Commandref fehlt noch, und ich habe zwei Fragen in die Runde:
1. Derzeit werden die remote Kommandos durch das Modul fest vorgegeben mit "sudo" ausgeführt. Sollte man das besser dem user überlassen (er schreibt selbst sudo ins wolCmd oder per Attribut steuern ("useSudo")? Ich persönlich würde es dem User überlassen (er schreibt's ins wolCmd)
2. Aktuell kann über das wolCmd letztendlich alles auf dem sshHost ausgeführt werden, was der (sudo) user darf. Im vorgeschlagenen Code war angedeutet, dass man das evtl. beschränken könnte. Ich persönlich denke, ein Beschränkung würde nur die Möglichkeiten des WOL-Moduls beschränken und keine zusätzliche Sicherheit bieten (im Zweifelsfall führe nehme ich halt nicht WOL sondern die Kommandozeile)
Ich habe die Coding-Änderungen soweit mir das möglich ist getestet und habe die angehängte Version in meinem Produktivsystem am Laufen, wäre aber dankbar, wenn ein paar Leute das in ihrer Umgebung testen könnten - sowohl mit alten "klassischen" WOLs als auch mit den neuen Möglichkeiten- bevor ich es einchecke. Bis dahin gibt es dann auch noch eine erweiterte CommandRef.
EDIT: Ich hatte vergessen zu erwähnen, sowohl im shutdownCmd als auch im wolCmd können die Platzhalter $IP und $MAC verwendet werden.
Danke,
Grüße,
Oli
Zitat von: KernSani am 10 Januar 2020, 00:10:13
1. Derzeit werden die remote Kommandos durch das Modul fest vorgegeben mit "sudo" ausgeführt. Sollte man das besser dem user überlassen (er schreibt selbst sudo ins wolCmd oder per Attribut steuern ("useSudo")? Ich persönlich würde es dem User überlassen (er schreibt's ins wolCmd)
auch OK.
Zitat von: KernSani am 10 Januar 2020, 00:10:13
2. Aktuell kann über das wolCmd letztendlich alles auf dem sshHost ausgeführt werden, was der (sudo) user darf. Im vorgeschlagenen Code war angedeutet, dass man das evtl. beschränken könnte. Ich persönlich denke, ein Beschränkung würde nur die Möglichkeiten des WOL-Moduls beschränken und keine zusätzliche Sicherheit bieten (im Zweifelsfall führe nehme ich halt nicht WOL sondern die Kommandozeile)
auch OK. Ggf. ein Hinweis in die Commandref, dass es empfohlen wird einen eingeschränkten User auf dem Host zu nutzen und nicht unbedingt root.
Ich habe das Modul mal eingespielt. WOL hat funktioniert. Ich teste am Wochenende noch ein wenig
Hallo Oli,
ich wäre dafür sudo unbedingt dem User zu überlassen! Normalerweise braucht es doch kein sudo für ssh.
Ich wäre auch noch für eine Änderung des Default Verhaltens: Das ist derzeit BOTH - also wenn man der DEF nichts mitgibt.
Das halte ich für Unsinn, default sollte UDP sein, das reicht normalerweise aus. BOTH führt beim nicht nachdenkenden Benutzer lediglich dazu, das er etherwake nachinstalliert und dadurch gezwungen anfängt das Ganze mit erhöhten Rechten zu betreiben.
Mir erscheint das mit den ssh Attributen etwas überattribusiert :)
Gruß Otto
Hi Otto,
Zitat von: Otto123 am 10 Januar 2020, 09:40:53
ich wäre dafür sudo unbedingt dem User zu überlassen! Normalerweise braucht es doch kein sudo für ssh.
der sudo wird dem remote-Kommando vorangestellt, sehe ich aber genauso (hatte ich ja oben auch geschrieben) und werde das heute Abend rausnehmen
Zitat
Ich wäre auch noch für eine Änderung des Default Verhaltens: Das ist derzeit BOTH - also wenn man der DEF nichts mitgibt.
Das halte ich für Unsinn, default sollte UDP sein, das reicht normalerweise aus. BOTH führt beim nicht nachdenkenden Benutzer lediglich dazu, das er etherwake nachinstalliert und dadurch gezwungen anfängt das Ganze mit erhöhten Rechten zu betreiben.
Guter Punkt. Ich wollte mir auch etwas einfallen lassen, dass der User nicht zwingend MAC und IP mitgeben muss bei der DEF.
Zitat
Mir erscheint das mit den ssh Attributen etwas überattribusiert :)
sind ja "nur" drei neue Attribute ;-) Weniger ging nicht... :-) Wobei die ssh- und command-Optionen tatsächlich den eigentlichen Sinn von WOL etwas ad absurdum führen. In diesem Modus wird WOL zu einer billigen Ausgabe eines PRESENCE Devices das zufällig Commands absetzen kann... ::) Allerdings ermöglicht es natürlich alle Devices (egal ob echtes WOL oder WOL über ssh) gleich zu behandeln.
Grüße,
Oli
Gruß Otto
[/quote]
wäre es nicht eleganter ein Attribut "command_Type" zu haben mit drop down auswahl und ein zweites Attribut für die commands? (on und off command per pipe getrennt z.B.)
Naja das mit der IP kommt ja daher, das WOL auch Presence macht. Der Gedanke laut commandref ist ja noch, wenn man sie nicht weiß, die Broadcast Adresse mitzugeben.
Dazu hätte ich noch die Idee, dass man die eventuell fehlenden Broadcast Adresse aus der IP Adresse ableiten kann. Bei all meinen bisherigen Umgebungen und Versuchen schlug eine fehlende Broadcast Adresse für Magic Paket bisher immer fehl - sicher weil dann ein Broadcast an ALLE gemacht wird, den mittlerweile jede Netzwerktechnik verwirft. Also wenn überhaupt, dann geht sowieso nur ein gezielter Broadcast an die richtige Netzwerkadresse.
Wenn die fehlt (weil vom User nicht angegeben) halte ich es für legitim die aus der IP abzuleiten und zu setzen. Immer noch besser als die Aussage "funktioniert nicht" ;)
Gruß Otto
Zitat von: Frank_Huber am 10 Januar 2020, 10:10:12
wäre es nicht eleganter ein Attribut "command_Type" zu haben mit drop down auswahl und ein zweites Attribut für die commands? (on und off command per pipe getrennt z.B.)
Verstehe ich nicht ganz. Was verstehst du unter command_Type? Perl/FHEM/System?
Danke,
Oli
Zitat von: KernSani am 10 Januar 2020, 10:22:01
Verstehe ich nicht ganz. Was verstehst du unter command_Type? Perl/FHEM/System?
Danke,
Oli
Ja, genau. Dann brauchst nicht für alles ein eigenes Attribut.
Gesendet von meinem Doogee S60 mit Tapatalk
Zitat von: Frank_Huber am 10 Januar 2020, 13:08:51
Ja, genau. Dann brauchst nicht für alles ein eigenes Attribut.
Hab ich ja nicht. shutdownCmd gibt es bereits, daran will ich grundsätzlich nichts ändern (Kompatibilität), wolCmd ist neu und realisiert neue Funktionalität. Dazu kommen noch die zwei sshHosts, die man theoretisch natürlich in ein einzelnes Attribut packen könnte. Grundsätzlich halte ich es persönlich aber für übersichtlicher unterschiedliche Attribute für unterschiedliche Funktionalität zu haben als n Dinge in ein Attribut zu packen (wie war das jetzt gleich? Pipe getrennt, Komma getrennt oder doch Doppelpunkt oder vielleicht Leerzeichen? Und kam jetzt wakeup oder shutdown zuerst? ... ;))
Grüße,
Oli
Zitat von: Otto123 am 10 Januar 2020, 10:17:57
Dazu hätte ich noch die Idee, dass man die eventuell fehlenden Broadcast Adresse aus der IP Adresse ableiten kann. Bei all meinen bisherigen Umgebungen und Versuchen schlug eine fehlende Broadcast Adresse für Magic Paket bisher immer fehl - sicher weil dann ein Broadcast an ALLE gemacht wird, den mittlerweile jede Netzwerktechnik verwirft. Also wenn überhaupt, dann geht sowieso nur ein gezielter Broadcast an die richtige Netzwerkadresse.
Wenn die fehlt (weil vom User nicht angegeben) halte ich es für legitim die aus der IP abzuleiten und zu setzen. Immer noch besser als die Aussage "funktioniert nicht" ;)
Die Subnetzmask eines remote Hosts herauszufinden ist aber nicht einfach... Variante 1 wäre generell von /24 auszugehen (einfach), alternativ die netmask vom lokalen (also FHEM) Server zu finden und damit die broadcast-Adresse zu berechnen...
Angehängte Version fügt nicht mehr automatisch den "sudo hinzu, hat dafür eine Commandref
Ich wäre für Variante 1 :D einfach und viel besser als nix ;)
Hallo Oli,
mit ist was aufgefallen. Im SSH-Fall wird das Command nicht an den auszuführenden String gehängt. Zusätzlich, Parameter -T unterdrückt die Warnung "Pseudo-terminal will not be allocated because stdin is not a terminal."
Zeile 324
#Enclose SSH command in double quotes
$sshCmd .= " -T ".$cmd; <--------------- neu
$sshCmd .= "\"";
$cmd = $sshCmd;
ups... da habe ich eine Zeile zuviel auskommentiert :-[
Angepasst, (wie vorgeschlagen mit -T)
und Otto's Vorschlag zur default broadcast-Adresse ist auch umgesetzt.
Zitat von: KernSani am 11 Januar 2020, 14:45:01
ups... da habe ich eine Zeile zuviel auskommentiert :-[
Angepasst, (wie vorgeschlagen mit -T)
und Otto's Vorschlag zur default broadcast-Adresse ist auch umgesetzt.
sieht jetzt gut aus.
Danke!
Könntest du bitte noch die Meldung s. u. ausblenden?
2020.01.11 19:14:39.436 1: Timeout for WOL_Ping reached, terminated process 20791
Nachdem mein Host down ist benötigt der Ping 11 Sekunden. Der Ping hat zwar -w 2 (Dauer 2 Sekunden) aber die Ausführung dauert 11 Sekunden. WArum auch immer. Timeout in Zeile 155 auf Wert 20 müsste das lösen. Oder kann man im Blocking-Aufruf die Meldung abfangen und erst bei verbose 3 ausgeben? Ich habe aktuell jede Minute den Eintrag im Log.
root@2deff4cbb70f:/opt/fhem# date;ping -c 1 -w 2 192.168.0.26;date
Sa 11. Jan 19:31:56 CET 2020
PING 192.168.0.26 (192.168.0.26): 56 data bytes
--- 192.168.0.26 ping statistics ---
1 packets transmitted, 0 packets received, 100% packet loss
Sa 11. Jan 19:32:07 CET 2020
root@2deff4cbb70f:/opt/fhem#
Interessant...
pi@fhem:~ $ date;ping -c 1 -w 2 172.16.4.10;date
Sa 11. Jan 20:07:54 CET 2020
PING 172.16.4.10 (172.16.4.10) 56(84) bytes of data.
--- 172.16.4.10 ping statistics ---
2 packets transmitted, 0 received, 100% packet loss, time 41ms
Sa 11. Jan 20:07:56 CET 2020
Die Timeout-Meldung kommt jetzt auf level 4.
EDIT: Kleine Anekdote am Rande... Habe gerade festgestellt, dass mein Log voll mit WOL Timeout-Meldungen ist... Schock, was habe ich jetzt wieder verpfuscht? Bis mir die Erkenntnis kam: Ich hatte den timeout auf 1 Sekunde gestellt, um zu testen, ob die Meldung richtig geloggt wird und vergessen, ein reload zu machen, nachdem ich den timeout wieder zurückgestellt hatte ;-)
Wenn keine Einwände kommen, würde ich die Version dann bei Gelegenheit mal im SVN einchecken...
Zitat von: KernSani am 26 Januar 2020, 21:04:52
Wenn keine Einwände kommen, würde ich die Version dann bei Gelegenheit mal im SVN einchecken...
ich habe für Wol die SSH-Variante im Einsatz und nichts negatives festgestellt. Habe somit nichts dagegen :)
Zitat von: KernSani am 26 Januar 2020, 21:04:52
Wenn keine Einwände kommen, würde ich die Version dann bei Gelegenheit mal im SVN einchecken...
Darf ich nachfragen, hast du es vergessen, oder gab es die passende Gelegenheit noch nicht? ;)
Ups... ich fürchte ich habe das vergessen... Shame on me.. kommt heute Abend
Kurz, weil mobil....
Hallo, ich habe das Modul für meinen HTPC getestet. Offenbar werden die Attribute "sshHost" und "sshHostShutdown" beim Zuweisen der Werte geprüft (s.u.). Das führt allerdings zu dem Problem, dass die Werte bei einem "FHEM-Restart" nicht wieder zugewiesen werden, wenn der HTPC gerade offline ist.
if ( ( $attrName eq "sshHost" or $attrName eq "sshHostShutdown" ) and $cmd eq "set" ) {
...
VG
Hajo
es ist richtig, es wird geprüft. Wenn du einen Jump-Server verwendet soll der aber auch dauerhaft erreichbar sein, sonst macht die ssh-Config keinen Sinn.
Beim Restart von Fhem wird da aber mMn nicht geprüft, nur beim erstmaligen Anlegen des WOL-Devices.
Zitat von: kadettilac89 am 20 Dezember 2020, 17:05:56
...
Beim Restart von Fhem wird da aber mMn nicht geprüft, nur beim erstmaligen Anlegen des WOL-Devices.
Ich bin darauf gekommen, weil das Attribut "sshHostShutdown" bei mir immer wieder nach dem Restart fehlte, obwohl es in der cfg stand. Ich habe es aus der Zeile herausgenommen und nun überlebt es auch den Restart. "sshHost" verwende ich derzeit nicht, aber dafür dürfte das Selbe gelten.
VG
Hajo
Zitat von: hajo23 am 22 Dezember 2020, 11:43:49
Ich bin darauf gekommen, weil das Attribut "sshHostShutdown" bei mir immer wieder nach dem Restart fehlte, obwohl es in der cfg stand. Ich habe es aus der Zeile herausgenommen und nun überlebt es auch den Restart. "sshHost" verwende ich derzeit nicht, aber dafür dürfte das Selbe gelten.
dürfte eigentlich nicht verschwinden. Habe mal testweise bei mir eingetragen und rebootet. Attribute bleiben bestehen. Solange alles funktioniert OK, ansonsten musst du Logs und eine detaillierte Beschreibung was genau configuriert ist, liefern ...
Zitat von: kadettilac89 am 22 Dezember 2020, 13:57:12
dürfte eigentlich nicht verschwinden. Habe mal testweise bei mir eingetragen und rebootet. Attribute bleiben bestehen. Solange alles funktioniert OK, ansonsten musst du Logs und eine detaillierte Beschreibung was genau configuriert ist, liefern ...
Ich habe hier einen Log-Ausschnitt mit der Startphase
2020.12.27 11:32:39 0: Server shutdown
2020.12.27 11:32:41 1: Including fhem.cfg
2020.12.27 11:32:44 3: WEB: port 8083 opened
2020.12.27 11:32:45 2: eventTypes: loaded 2740 events from ./log/eventTypes.txt
2020.12.27 11:32:45 1: Including /opt/fhem/FHEM/cul.cfg
2020.12.27 11:32:45 3: Opening BerryCUL device /dev/ttyAMA0
2020.12.27 11:32:46 3: Setting BerryCUL serial parameters to 38400,8,N,1
2020.12.27 11:32:46 3: BerryCUL: Possible commands: mCFiAZOGMKRTVWXefltux
2020.12.27 11:32:46 3: BerryCUL device opened
2020.12.27 11:32:46 1: Including /opt/fhem/FHEM/mcp23017.cfg
2020.12.27 11:32:46 1: Including /opt/fhem/FHEM/s20.cfg
2020.12.27 11:32:47 3: TPLinkHS110: HS110_WLAN1 defined.
2020.12.27 11:32:48 3: KNXTUL opening KNX
2020.12.27 11:32:48 3: KNXTUL device opened
2020.12.27 11:32:49 1: Including /opt/fhem/FHEM/Raumtemperatur.cfg
2020.12.27 11:32:49 3: Opening JLLaCR device /dev/ttyUSB0
2020.12.27 11:32:49 3: Setting JLLaCR serial parameters to 57600,8,N,1
2020.12.27 11:32:50 3: JLLaCR device opened
2020.12.27 11:32:50 3: LaCrosse_00: I/O device is JLLaCR
2020.12.27 11:33:00 1: Including /opt/fhem/FHEM/sysmon.cfg
2020.12.27 11:33:01 1: Including /opt/fhem/FHEM/wecker.cfg
2020.12.27 11:33:01 1: Including /opt/fhem/FHEM/wakeonlan.cfg
2020.12.27 11:33:04 3: [PN50] SSH-Login to Host failed: timeout or invalid ssh String <xyz@192.168.2.81>
...
define PN50 WOL 24:4B:FE:C8:0F:37 192.168.2.81 EW
attr PN50 devStateIcon off:remotecontrol/black_btn_POWEROFF2 on:remotecontrol/black_btn_YELLOW
attr PN50 group PN50
attr PN50 interval 60
attr PN50 room Kodi
attr PN50 shutdownCmd sudo shutdown -h now
attr PN50 sshHostShutdown xyz@192.168.2.81
Wie Du siehst, wird beim Restart geprüft, ob der SSH-Login möglich ist. Bei mir ist der HTPC idR. ausgeschaltet. Daher muss der Versuch scheitern. Das Attribut wird nicht geladen und der SSH-Shutdown funktioniert nicht mehr.
VG
HaJo
Hallo Oli,
irgendwie hat es die Beschreibung der Platzhalter $MAC und $IP im wolCmd nicht bis in die Doku geschafft.
Mir fehlte an der Stelle noch die UdpBroadcast Adresse :) Vorschlag $BC
Ich habe mir den Code mal angeschaut und mit meinem ziemlich amateurhaften Perl Auge die Stellen identifiziert und würde mal einen Patch anhängen.
Vielleicht findest Du die Zeit mal zu schauen.
Ich habe dann noch eine sub für die 99_myUtils gebaut mit der man über einen RemoteHost (oder auch den Dockerhost) WOL ohne weitere Installation machen kann.
siehe hier (https://forum.fhem.de/index.php/topic,115793.msg1128741.html#msg1128741).
Viele Grüße
Otto
Zitat von: Otto123 am 03 Februar 2021, 14:57:48
Hallo Oli,
irgendwie hat es die Beschreibung der Platzhalter $MAC und $IP im wolCmd nicht bis in die Doku geschafft.
Mir fehlte an der Stelle noch die UdpBroadcast Adresse :) Vorschlag $BC
Ich habe mir den Code mal angeschaut und mit meinem ziemlich amateurhaften Perl Auge die Stellen identifiziert und würde mal einen Patch anhängen.
Vielleicht findest Du die Zeit mal zu schauen.
Ich habe dann noch eine sub für die 99_myUtils gebaut mit der man über einen RemoteHost (oder auch den Dockerhost) WOL ohne weitere Installation machen kann.
siehe hier (https://forum.fhem.de/index.php/topic,115793.msg1128741.html#msg1128741).
Viele Grüße
Otto
Hi Otto,
danke für den Patch. Ich kapiere ihn nur nicht ;-) Was du erreichen willst, ist dass im wol_by_cmd "$BC" durch die im Attribut useUdPBroadcast-Adresse angegebene Adresse ersetzt wird, oder?
Und was macht "willi" da drin? :-D
Grüße,
Oli
Hallo Oli,
ZitatWas du erreichen willst, ist dass im wol_by_cmd "$BC" durch die im Attribut useUdPBroadcast-Adresse angegebene Adresse ersetzt wird, oder?
so ist es.
Soweit ich verstanden habe, wird die sub WOL_by_cmd auch bei shutdown verwendet. "willi" ist sozusagen der Dummy um dabei auf drei Parameter zu kommen, wo der Dritte bei shutdown nicht gebraucht wird :)
Die Variable $host wird da anderweitig verwendet?
Ich glaube vor zwei Monaten habe ich gerade begonnen zu verstehen wie die Parameter Übergabe funktioniert.
Gruß Otto
Zitat von: Otto123 am 26 März 2021, 21:13:17
Ich glaube vor zwei Monaten habe ich gerade begonnen zu verstehen wie die Parameter Übergabe funktioniert.
WOL ist noch mit Prototypen... mache ich mittlerweile nicht mehr... Aber auch da könnte man optionale Parameter definieren ;-)
Ich habe es ein klein wenig anders gelöst. Magst du mal testen?
Grüße,
Oli
Sieht auf den ersten Blick gut aus.
defmod woltest WOL 11:22:33:44:55:66 192.168.178.2 CMD
attr woltest useUdpBroadcast 192.168.178.255
attr woltest wolCmd "echo $IP $MAC $BC"
schreibt alles ins Log ;)
2021.03.26 22:52:20 3: [woltest] set woltest on
2021.03.26 22:52:20 3: [woltest] waking woltest with MAC 11:22:33:44:55:66 IP 192.168.178.2 via CMD
2021.03.26 22:52:20 3: [woltest] Executing command >"echo 192.168.178.2 11:22:33:44:55:66 192.168.178.255"<
192.168.178.2 11:22:33:44:55:66 192.168.178.255
Danke :) ich schau mir später den Code noch an um zu lernen.
Schönes Wochenende
Otto
Ich habe im Wesentlichen deine Änderungen übernommen, nur den Willi weggelassen und frage stattdessen ab, ob $bc gesetzt ist...
Ich glaube meine Intension mit Willi damals war, genau darauf aufmerksam zu machen, dass es noch unschön ist. ;D
Hat funktioniert - allerdings habe ich gestern auch eine Weile gebraucht um die Erklärung hochzuholen. ::)
Habe noch ein bisschen getestet, ein klein wenig umgebaut und checke jetzt ein...