Wake-on-LAN will einfach nicht

[fgordon]

Auf den ersten kurzen Blick auch wenn das vermutlich nicht der Fehler ist in Deinen Scripten steht immer eth12345 Dein Interface heißt aber tatsächlich enp12345

Wenn Du nur 1 Netzwerkinterface auf dem Board hast ist es sehr unwahrscheinlich, dass Du IPMI hast - möglich aber das wäre eher ungewöhnlich


Mein Vermutung ist auch, dass "NETDOWN=no" dazu führt dass "pre-down /usr/sbin/ethtool -s enp12345 wol g" eh nicht mehr ausgeführt wird.

ich mache solche Startsache grundsätzlich eher in der crontab, da sich beim "update" evtl Dateien ändern in denen man eigentlich nicht herumwerkeln sollte "default" könnte so ein Fall sein

Bei mir ist das dann ein crontab Eintrag
@ReBoot root /custom/scripte/startstuff.sh


und in /custom/scripte/startstuff.sh mache ich dann alles was ich zusätzlich haben will - ohne dass ich dann an 100 Ecken in irgendwelchen Configs rumwerkeln muss - und das wird auch als letztes ausgeführt beim Starten.

Darin würde ich a) den Status auslesen in eine Datei b) den wake on lan status setzen c) den Status danach nochmals auslesen in die Datei - nur um zu sehen dass er auch tatsächlich gesetzt wurde.

Für start stop nutze ich ein systemd kompatibles Konstrukt

einen "/etc/systemd/system/stopstuff.service"

[Unit]
Description=Start Stopp Stuff
DefaultDependencies=no
Before=shutdown.target reboot.target halt.target

[Service]
Type=oneshot
RemainAfterExit=true
ExecStart=/custom/scripte/startstuff.sh
ExecStop=/custom/scripte/stopstuff.sh

[Install]
WantedBy=multi-user.target

In der stopstuff.sh würde ich das gleiche wie oben nochmals machen.

Je nachdem wie fit Du bei scripten bist kannst ja nachfragen wenn was nicht klar ist evtl kann ich oder wer anders Dir da helfen

 

[BLU1312]

Vielen Dank für deine Antwort und sorry die späte Rückmeldung. Das mit den Skripts werde ich heute Abend probieren und mich melden und "meine" Lösung vorstellen. Vielleicht könntest du / ihr dann mal drüberschauen, ob das so passt. Alle anderen Änderungen (außer die von DELL vorgegebenen) würde ich rückgängig machen.

 

[BLU1312]

Ich habe doch jetzt direkt mal folgendes angelegt. Da weder bei mehrmaligem Hoch- noch Herunterfahren die Dateien /tmp/start.txt noch /tmp/stop.txt angelegt wurden, habe ich den Service per

sudo systemctl enable start_stop.service

aktiviert. Das hat aber leider auch nichts gebracht. Dazu habe ich den beiden start.sh- bzw. stop.sh-Skripten noch ein

chmod u+x /usr/local/bin/start_stop_scripts/*.sh

verpasst. Ebenfalls ohne Erfolg

/etc/systemd/system/start_stop.service

[Unit]
Description=Start Stopp Stuff
DefaultDependencies=no
Before=shutdown.target reboot.target halt.target

[Service]
Type=oneshot
RemainAfterExit=true
ExecStart=/usr/local/bin/start_stop_scripts/start.sh
ExecStop=/usr/local/bin/start_stop_scripts/stop.sh

[Install]
WantedBy=multi-user.target

/usr/local/bin/start_stop_scripts/start.sh

#!/bin/sh
ethtool enp12345 | grep Wake-on > /tmp/start.txt
ethtool -s enp12345 wol g
ethtool enp12345 | grep Wake-on >> /tmp/start.txt

/usr/local/bin/start_stop_scripts/stop.sh

#!/bin/sh
ethtool enp12345 | grep Wake-on > /tmp/stop.txt
ethtool -s enp12345 wol g
ethtool enp12345 | grep Wake-on >> /tmp/stop.txt

Im crontab steht folgendes:

@reboot sudo /etc/systemd/system/start_stop.service

 

[fgordon]

sudo ist aber kein User sondern ein Befehl - da muss "root" stehen in der crontab

Du musst da auch ein ausführbaren Programm eintragen wie z.B. ein Script und keine Definitionsdatei eines Systemd Dienstes, die ist nicht ausführbar

Also crontab

@reboot  root   /usr/local/bin/start_stop_scripts/start.sh

Cron Service muss natürlich enabled sein. (kannst ja checken mittels "systemctl status cron")

Gibt es denn bei der manuellen Ausfühtung von z.B. "sudo /usr/local/bin/start_stop_scripts/start.sh"
eine Fehlermeldung?

 

[BLU1312]

Danke für deine Antwort und sorry für meine späte Rückmeldung.

Ich habe den Crontab jetzt wie von dir erwähnt abgeändert. Der Cron Service ist auch enabled:

Loaded: loaded (/lib/systemd/system/cron.service; enabled; vendor preset: ena

Wenn ich das start.sh-Skript manuell ausführe, dann finde ich im /tmp-Ordner eine Datei start.txt mit den folgenden Einträgen:

Supports Wake-on: pumbg
Wake-on: g
Supports Wake-on: pumbg
Wake-on: g

Danach habe ich die /tmp/start.txt-Datei nochmal gelöscht und den Server neu gestartet: Die start.txt war aber nicht im /tmp-Ordner zu finden. Ein

ethtool enp12345 | grep Wake-on

hat dennoch

Supports Wake-on: pumbg
Wake-on: g

angezeigt.

Kann ich irgendwo sehen, warum das Skript eventuell nicht ausgeführt wurde?

 

[fgordon]

Vielleicht stehts an der falschen Stelle in der Crontab? muss nach shell und path-Defs stehen z.B. siehe Bild1

Das "&" hinten ist nur dass die Scripte im Hintergund ausgeführt werden und andere Aktionen in der crontab evtl bereits starten können, das ist bei Dir sicher nicht nötig.

mit "sudo systemctl status cron.service" nach dem Booten kann man sehen was da ausgeführt wurde
siehe "Bild 2"

Kartenflags sehen eigentlich gut - die sollte Wake-On-Lanen - denke Softwareseitig passt vermutlich alles.

 

[BLU1312]

Danke für deine Antwort.

Bei mir war wohl das Problem, dass ich per crontab -e meinen crontab editiert habe. Dort gibt es keine shell- und paths-Definitionen.

Ich habe es nun per nano /etc/crontab gemacht und diese sieht dann so aus, wie deine (nur eben mit meinem @ReBoot-Eintrag).

Wenn ich nun neustarte, dann ist auch die /tmp/start.txt drin und beinhaltet folgendes

Supports Wake-on: pumbg
Wake-on: g
Supports Wake-on: pumbg
Wake-on: g

Wenn ich den Rechner nun herunterfahre kann ich aber weder mit wol.exe, noch mit MagicPacket den Server wieder aufwecken.

Brauche ich denn das stop-Skript, das du erwähnt hast, überhaupt und wie binde ich das dann in den Crontab ein?

 

[fgordon]

Hmmm ne glaub das shutdown-script kann man nicht in die crontab einbinden.

Scripte beim runterfahren zuverlässig ausführen ist immer was das nicht so einfach ist - da muss ich auch mal schauen

------------------------------------------------------------------------------------

Bei mir tut das zuverlässig in "Linux" (Debianbasiertes aktuelles 20.3 Linux Mint)

im Verzeichnis "/etc/systemd/system/" eine Datei z.b. "stopstuff.service"

[Unit]
Description=StopStuff
DefaultDependencies=no
Before=shutdown.target reboot.target halt.target

[Service]
Type=oneshot
User=root
Group=root
ExecStart=/custom/scripte/stopstuff.sh  # <= ausführbares script

[Install]
WantedBy=halt.target reboot.target shutdown.target

folgende Rechte

-rwxr-xr-x   root root      stopstuff.service

dann

systemctl enable stopstuff.service

 

[karhu]

Sorry, hatte die Mail Benachrichtungen gar nicht an, deshalb komm ich grad erst wieder vorbei

Folgende Ideen noch:

1. Probier doch mal einen anderen Wake-Mechanismus außer MagicPaket aus. ethtool -s wol p enp12345 z.B. - damit sollte sich dein rechner gar nicht mehr ausschalten lassen (denn der weckt sobald irgendwas auf dem connector ankommt) - oder das u flag, das ist dann bei Unicast, also wenn du dann z.B. ein ssh <IP des systems> machen würdest, dann sollte das System aufwachen.
2. Gibts im BIOS evtl. ein Setting "Wake on controlled by" oder so ähnlich? Ich kenne das von Fujitsu Geräten, da konnte man BIOS oder OS einstellen und wenn da BIOS drin stand, dann waren die OS settings total egal und der Wake-On hat immer funktioniert, weil das BIOS dafür gesorgt hat, dass die flags richtig gesetzt sind.
3. Hattest du in deinen Posts den Namen des Interfaces oder die Mac anonymisiert? Oder hast du da irgendwas manuell rumgestellt? Denn interface Name und die hinterlegte MAC sehen für mich sehr generiert aus: (enp12345 und ether 12:34:56:78:91:01)
   Welche MAC hat denn das Interface physikalisch (evtl. steht das auf dem Board gedruckt) - und welche versuchst du zu wecken?

 

[BLU1312]

Vielen Dank für eure Antworten.

Bei mir tut das zuverlässig in "Linux" (Debianbasiertes aktuelles 20.3 Linux Mint)

im Verzeichnis "/etc/systemd/system/" eine Datei z.b. "stopstuff.service"

[Unit]
Description=StopStuff
DefaultDependencies=no
Before=shutdown.target reboot.target halt.target

[Service]
Type=oneshot
User=root
Group=root
ExecStart=/custom/scripte/stopstuff.sh  # <= ausführbares script

[Install]
WantedBy=halt.target reboot.target shutdown.target

folgende Rechte

-rwxr-xr-x   root root      stopstuff.service

dann

systemctl enable stopstuff.service

Das habe ich so gemacht und den Pfad + Dateinamen unter ExecStart durch /usr/local/bin/start_stop_scripts/stop.sh ersetzt. Dem wol-on-shutdown.service habe ich ein chmod 755 verpasst, damit die Berechtigungen so passen, wie von dir erwähnt.

Die stop.txt wird aber beim Herunterfahren nicht angelegt. Führe ich das Stop-Script /usr/local/bin/start_stop_scripts/stop.sh manuell aus, wird die Datei angelegt. Dem stop.sh-Skript habe ich ein chmod u+x gegeben.

Sorry, hatte die Mail Benachrichtungen gar nicht an, deshalb komm ich grad erst wieder vorbei

Folgende Ideen noch:

1. Probier doch mal einen anderen Wake-Mechanismus außer MagicPaket aus. ethtool -s wol p enp12345 z.B. - damit sollte sich dein rechner gar nicht mehr ausschalten lassen (denn der weckt sobald irgendwas auf dem connector ankommt) - oder das u flag, das ist dann bei Unicast, also wenn du dann z.B. ein ssh <IP des systems> machen würdest, dann sollte das System aufwachen.
2. Gibts im BIOS evtl. ein Setting "Wake on controlled by" oder so ähnlich? Ich kenne das von Fujitsu Geräten, da konnte man BIOS oder OS einstellen und wenn da BIOS drin stand, dann waren die OS settings total egal und der Wake-On hat immer funktioniert, weil das BIOS dafür gesorgt hat, dass die flags richtig gesetzt sind.
3. Hattest du in deinen Posts den Namen des Interfaces oder die Mac anonymisiert? Oder hast du da irgendwas manuell rumgestellt? Denn interface Name und die hinterlegte MAC sehen für mich sehr generiert aus: (enp12345 und ether 12:34:56:78:91:01)
   Welche MAC hat denn das Interface physikalisch (evtl. steht das auf dem Board gedruckt) - und welche versuchst du zu wecken?

Das mit dem ethtool -s enp12345 wol p habe ich probiert und dann per ethtool enp12345 | grep Wake-on abgefragt. Es stand auf "p". Zudem habe ich den wol-on-shutdown.service (siehe Zitat oben) und das start.sh-Skript, das @ReBoot aufgerufen wird, ebenfalls auf den Status "p" gesetzt. Allerdings ist der Server wie gewohnt heruntergefahren. Genauso beim Status "u".

Den Punkt 2. muss ich mir die Tage anschauen, ich muss gleich noch los.

Sowohl die Mac-Adresse, als auch den Interface-Namen habe ich verfälscht. Ich nutze aber die Mac-Adresse und das Interface, das ich über ifconfig auf der Shell angezeigt bekomme und das als einziges eine IP hat. Ich habe aber auch schon alle anderen Mac-Adressen angeschaut.

Ich werde den Server die Tage öffnen, wenn ich etwas Ruhe habe und schauen, ob da irgendwo etwas aufgedruckt ist.

Sorry, dass ich noch nicht alles direkt ausprobieren konnte.

 

[BLU1312]

Nach einer paar Tagen flachliegen konnte ich nun endlich mal schauen: Ich konnte nirgends auf dem Mainboard / dem LAN-Modul (im Gehäuse noch außerhalb) auf irgendeiner Beschriftung etwas zu finden, das aussieht wie eine MAC-Adresse.

Hier habe ich mal ein paar Bilder vom BIOS und den Punkten gemacht, die für mich interessant aussehen hinsichtlich WoL:

Die Menüpunkte des BIOS


Part 1 Übersicht des Servers


Part 2 Übersicht des Servers


Deep Sleep Control? Muss ich da was machen?


Den Punkt Wake on LAN habe ich nach dem Foto auf "LAN with PXE Boot" gestellt -> hat aber auch nichts gebracht.

Normal starte ich den Server immer ohne Monitor und sehe es deshalb wohl nicht. Diese Meldung bekam ich. Kann es sein, dass ich die Netzwerkkarte, die ich die ganze Zeit versuche anzupingen zu einem Docker-Container gehört und gar keine physische, sondern eine virtuelle ist? Den echten Namen der Karte habe ich durch enp1234 ersetzt (die 5 habe ich weggelassen, da es sonst zu lange geworden wäre O:-)).

 

[karhu]

Also das umbennenen der LAN Karte kannst du dir eigentlich sparen. Die Netzwerkkarte wird nach einem Schema benannt, dass keinerlei persönliche Information enthält (Consistent device Naming).
Deine MAC Adresse für den LOM (LAN-on-Motherboard) ist auf einem deiner BIOS Fotos zu sehen (48-4D...-AE);-) Das ist auf jeden Fall die Adresse die du wecken musst, damit die Karte selbst das Magic Packet erkennt und dann das System aufweckt.

Das docker interface ist ein link-local virtual interface, das sollte da nicht rein spielen. Vor allem ist das ja nicht aktiv, wenn der Rechner aus ist - dann gehts eben nur um das physkalische INterface und dessen MAC Adresse.

Ist die MAC die im BIOS angezeigt wird mit der MAC die du versuchst zu wecken identisch? Falls nicht probiers mal mit der BIOS mac.

 

[fgordon]

Und es muss da natürlich da eingesteckt sein - Server Boards haben ja meistens mehr als 1 LAN OnBoard.

Ganz zut Not geht halt dann halt eine Löäsung per Power on after AC Loss + eine schaltbare Steckdose wie einen SonOff mit Tasmota (dann kann man z.B. auch gleich den Stromverbauch monitoren) xD

 

[XclanStinger]

Wenn nach dem Neustart des Servers "wol g" angezeit wird, sollte der Server eigentlich richtig konfiguriert sein. Habe ein ähnliches Szenario. Ein Dell PowerEdge 2950 (Debian bullseye) steht im Keller und ein weiterer Server (PC mit Ubuntu Server 20.04 LTS) steht neben meinem Rechner im "Computerraum". Ich verwende aktuell keine VLAN oder ähnliches.

Beim Ubuntu Server war die Aktion mit dem Service erforderlich:

/etc/systemd/system/stingers-startup.service schaut so aus:
[Unit]
Description=Startup wol
After=network.target

[Service]
ExecStart=/usr/local/sbin/enable_wol.sh

[Install]
WantedBy=multi-user.target

und enable_wol.sh sieht wie folgt aus:

#!/bin/bash
ethtool -s enp7s0 wol g
echo "wol enabled"
exit

Letztendlich den Service starten.


Beim Dell Server war der Aufwand geringer. Alles was ich da gemacht habe war folgendes:
In der Datei /etc/network/interfaces steht:

source /etc/network/interfaces.d/*

auto lo
iface lo inet loopback

auto enp10s0f0
iface enp10s0f0 inet static
address 192.168.1.223/24
gateway 192.168.1.1
ethernet-wol g

Geweckt werden beide Server mit dem Handy (Ja, es funktioniert über WLAN von Handy-zu-WlanRouter-zu-Switch-zu-Server) über die App "Wake On Lan", jeweils mit Angabe der MAC-Adresse des jeweiligen Netzwerkinterface. Eine weitere Möglichkeit die Server zu wecken ist, von Linux aus, mit dem Programm "wakeonlan -f MACADRESSE".

Beim einrichten ist mir folgendes aufgefallen. Wenn "...wol g" sozusagen "manuell" eingegeben/eingestellt
wird und nach dem Neustart verschwindet ist es jedoch einmalig möglich, also direkt nach dem ersten Herunterfahren, den Server zu wecken. Wenn "g" fest konfiguriert ist, also nach einem Neustart erscheint, dann müsste, nach meiner Erfahrung, der Server also richtig konfiguriert sein.

Man kann den Server auch anpingen und danach die ARP-Tabelle (arp) anschauen. So lässt sich die richtige MAC auch ermitteln.

"g" steht für "Magic Packet", "u" für unicast messages, "b" für broadcast messages und "m" für multicast messages. Für das Troubleshooting wird empfohlen nur "g" einzustellen um ggf. Konflikte zu vermeiden.

Ich hoffe das ist in irgendeiner Form hilfreich.

 

[fgordon]

Meine 10 Gig Karten machen Hardwaremässig auch kein WOL mehr - ich nutze inzwischen vermehrt SOnOffs mit Tasmota auf den Systemen - funktioniert genauso zuverlässig. Immerhin die 2,5GBit Karten haben es noch.

Alternativ wäre auch piKVM dann noch eine Möglichkeit.......die wie Tasmota sicher immer funktioniert oder sich was mit einem ESP32/8266 wenn WLAN vorhanden ist zu häkeln - das aber halt beides mit Bastelei verbunden xD

 

[BLU1312]

Vielen Dank für eure Antworten.

Also das umbennenen der LAN Karte kannst du dir eigentlich sparen. Die Netzwerkkarte wird nach einem Schema benannt, dass keinerlei persönliche Information enthält (Consistent device Naming).
Deine MAC Adresse für den LOM (LAN-on-Motherboard) ist auf einem deiner BIOS Fotos zu sehen (48-4D...-AE);-) Das ist auf jeden Fall die Adresse die du wecken musst, damit die Karte selbst das Magic Packet erkennt und dann das System aufweckt.

Das docker interface ist ein link-local virtual interface, das sollte da nicht rein spielen. Vor allem ist das ja nicht aktiv, wenn der Rechner aus ist - dann gehts eben nur um das physkalische INterface und dessen MAC Adresse.

Ist die MAC die im BIOS angezeigt wird mit der MAC die du versuchst zu wecken identisch? Falls nicht probiers mal mit der BIOS mac.

Oh man, gut, dass ich mir dann die ganze "Mühe"/Umstände gemacht habe das zu verschleiern und auch noch eher für Verwirrung gesorgt habe damit. Und dann poste ich auch noch die Mac-Adresse. Naja.
Aber es ist definitiv diese LOM-Mac-Adresse, die ich anpinge. Ich habe sie mir im KeyPass notiert.

Und es muss da natürlich da eingesteckt sein - Server Boards haben ja meistens mehr als 1 LAN OnBoard.

Ganz zut Not geht halt dann halt eine Löäsung per Power on after AC Loss + eine schaltbare Steckdose wie einen SonOff mit Tasmota (dann kann man z.B. auch gleich den Stromverbauch monitoren) xD

Der Dell T30 hat tatsächlich nur eine Netzwerkkarte. Von daher müsste das auch passen. Das Power on AC Loss könnte schon aktiviert sein, da ich den Server an einer abschaltbaren Steckdose hatte und der beim Einschalten immer kurz gestartet, dann aber wieder rungefahren / ausgegangen ist. Wenn der Dell T30 das kann mit dem Power on after AC Loss, dann wäre das auch eine Alternative, die i.O. wäre.

Wenn nach dem Neustart des Servers "wol g" angezeit wird, sollte der Server eigentlich richtig konfiguriert sein. Habe ein ähnliches Szenario. Ein Dell PowerEdge 2950 (Debian bullseye) steht im Keller und ein weiterer Server (PC mit Ubuntu Server 20.04 LTS) steht neben meinem Rechner im "Computerraum". Ich verwende aktuell keine VLAN oder ähnliches.

Beim Ubuntu Server war die Aktion mit dem Service erforderlich:

/etc/systemd/system/stingers-startup.service schaut so aus:
[Unit]
Description=Startup wol
After=network.target

[Service]
ExecStart=/usr/local/sbin/enable_wol.sh

[Install]
WantedBy=multi-user.target

und enable_wol.sh sieht wie folgt aus:

#!/bin/bash
ethtool -s enp7s0 wol g
echo "wol enabled"
exit

Letztendlich den Service starten.


Beim Dell Server war der Aufwand geringer. Alles was ich da gemacht habe war folgendes:
In der Datei /etc/network/interfaces steht:

source /etc/network/interfaces.d/*

auto lo
iface lo inet loopback

auto enp10s0f0
iface enp10s0f0 inet static
address 192.168.1.223/24
gateway 192.168.1.1
ethernet-wol g

Geweckt werden beide Server mit dem Handy (Ja, es funktioniert über WLAN von Handy-zu-WlanRouter-zu-Switch-zu-Server) über die App "Wake On Lan", jeweils mit Angabe der MAC-Adresse des jeweiligen Netzwerkinterface. Eine weitere Möglichkeit die Server zu wecken ist, von Linux aus, mit dem Programm "wakeonlan -f MACADRESSE".

Beim einrichten ist mir folgendes aufgefallen. Wenn "...wol g" sozusagen "manuell" eingegeben/eingestellt
wird und nach dem Neustart verschwindet ist es jedoch einmalig möglich, also direkt nach dem ersten Herunterfahren, den Server zu wecken. Wenn "g" fest konfiguriert ist, also nach einem Neustart erscheint, dann müsste, nach meiner Erfahrung, der Server also richtig konfiguriert sein.

Man kann den Server auch anpingen und danach die ARP-Tabelle (arp) anschauen. So lässt sich die richtige MAC auch ermitteln.

"g" steht für "Magic Packet", "u" für unicast messages, "b" für broadcast messages und "m" für multicast messages. Für das Troubleshooting wird empfohlen nur "g" einzustellen um ggf. Konflikte zu vermeiden.

Ich hoffe das ist in irgendeiner Form hilfreich.

Danke, deine Skripte werde ich ausprobieren. So wie du aber sagst, wenn das wol g nach dem Booten da ist, dann sollte es auch so gehen - genau das habe ich auch gelesen, dass wol g erst durch festes einträgen stateful wird, also nach dem Booten noch vorhanden ist.

Meine 10 Gig Karten machen Hardwaremässig auch kein WOL mehr - ich nutze inzwischen vermehrt SOnOffs mit Tasmota auf den Systemen - funktioniert genauso zuverlässig. Immerhin die 2,5GBit Karten haben es noch.

Alternativ wäre auch piKVM dann noch eine Möglichkeit.......die wie Tasmota sicher immer funktioniert oder sich was mit einem ESP32/8266 wenn WLAN vorhanden ist zu häkeln - das aber halt beides mit Bastelei verbunden xD

Ich bin mir gar nicht sicher, aber ich glaube, dass ich nur eine 1 GB/s-Karte habe. Bzgl. piKVM: Ich habe zwar zwei Raspberry Pis am Laufen, aber zu großes Gefummel will ich damit nicht starten. Am liebsten wäre es mir, wenn der Sch**ß einfach laufen würde, wie er soll und ich mich gar nicht groß damit auseinandersetzen müsste.

 

[BLU1312]

Ganz zut Not geht halt dann halt eine Löäsung per Power on after AC Loss + eine schaltbare Steckdose wie einen SonOff mit Tasmota (dann kann man z.B. auch gleich den Stromverbauch monitoren) xD

Ich würde nochmal gerne auf das Thema zurückkommen: Von meinem Bruder habe ich mir eine Shelly Plug S mit Tasmota ausgeliehen, allerdings scheint die nicht komplett auszuschalten. Wenn ich den Server in der Shelly habe, dann bekommt dieser nicht mit, wenn ich die Shelly einschalte bzw. scheint nie zu 100% Stromlos zu sein. Wenn ich die Anschlussdose in der Wand stattdessen verwende und dort den Netzstecker direkt einstecke, dann klappt es.

Kannst du mir sagen, ob ich bei Tasmota noch etwas wie "komplett spannungsfrei" einstellen kann/muss? Gefunden habe ich nichts, kann aber auch daran liegen, dass ich gar keine Ahnung habe, wie sich diese Einstellung nennen könnte.

 

[fgordon]

Ich kenn den Shelly nicht.

Der SonOff POW hat ein Relais und trennt eine der beiden AC Leitungen physisch - mit Tasmota hat das direkt nichts zu tun. denke so sollten die meisten schaltbaren Steckdosen funktionieren also 1 oder 2-polig trennen so dass kein Stromfluss mehr möglich ist.

https://tech.scargill.net/wp-conten...-IMG_20191024_142940.jpg-‎-Photos-768x362.jpg

 

[BLU1312]

Danke. Dann schaue ich das bei der Shelly Plug S nach, wie die aufgebaut ist.

 

[fgordon]

Hast Du auch lange genug gewartet beim Testen zwischen aus und einschalten über den Shelly Plug? Also mindestens so 30 Sekunden.

Wen ich bei manchen Netzteilen ausschalten und recht kurz danach wieder ein funktioniert das auch nicht, dann hält das Netzteil vermutlich irgendeine der Versorgungsspannungen die für Power Loss Detect verantwortlich wohl noch aus Kondensatoren etc.

Denn egal ob herkömmliches oder Solid State Relay ich denke dass bei schaltbaren Steckdosen immer mindestens eine Leitung einfach getrennt wird - das ja Sinn der Sache. Bei den Fritz "Outdoor" Steckdosen sind es sogar beide Leitungen.