Ok, aber hier ginge es ja nicht im ein Routing sondern um die schlichte Netzwerk-Switch-Funktion der FRITZ!Box. Und diese ist oder sollte unabhängig vom externen Bein 
sein.
Wir wissen, dass das, was üblicherweise Router genannt wird, mehr als das ist. Ein solches Gerät beinhaltet typischerweise noch einen Switch und einen WLAN Access Point. Und letztere sollten ausreichen, um das Anliegen des TE zu erfüllen.
Ich nahm einen Eindruck von der von dir verlinkten Website. Diese beschäftigt sich mit der Arduino IDE und der Programmierung per C++. Dies nutzte ich auch mal. Auch bin ich in C++ bewandert. Der verlinkte Artikel bezieht sich auf eine Bibliothek, die ein WiFi Objekt zur Verfügung stellt. Die dortige Umgebung ist eine andere als die der hier genutzte Firmware, welche auf einem RTOS (Real Time Operating System) basiert. Deshalb ist nicht zu erwarten, dass ein auf Arduino basiertes Programm sich so verhält wie die Shelly Firmware. Dies wäre bei Tasmota32 der Fall, weil dieses System auf C++ und Bibliotheken basiert. (Rui Santos begegnete mir vor Jahren bei Recherchen auf Websites auch bereits.)
Ich bin derzeit selbst mit einem WoMo unterwegs und nutze testweise einen Shelly Plus Plug S und einer FRITZ!Box 4020, die ich an meinem jetzigen Standort in ein MESH eingebunden habe. In den nächsten Tagen wird die FRITZ!Box wegen Weiterfahrt aus diesem Mesh verschwinden. Dann will ich dein Szenario mal testen. Allerdings habe ich ein erheblich weniger ausgestattetes WoMo als du und nutze darin keinen Shelly - die Speicherkapazität von knapp 200Ah (?) ist mir dafür zu schade. Unterwegs nutzen wir gelegentlich einen Hotspot per Smartphone, also ohne FRITZ!Box. Mal sehen, was ich in Kürze noch herausfinden kann. Ich bin dbzgl. sensibilisiert und werde mich ggf. dann hier noch einmal melden. Zumindest interessiert mich, was du noch herausfinden kannst.
Ich wünsche uns dabei viel Erfolg. Bis später vielleicht.
Vermutlich werde ich nicht weiterhelfen können, aber ...
Vermutlich arbeitet der Shelly im Wohnmobil.
habe ich sicherheitshalber mal in den Shell als Zeitserver eingetragen
Das ist nicht erforderlich. Der Shelly holt sich die Zeit (Synchronisation), sobald er kurzzeitig einen Zeitserver erreicht. Solange er nicht rebootet, läuft die interne Uhr auch ohne Zeitserver weiter. Für zeitgesteuerte Aufgaben (schedule jobs) wird mitunter die Uhrzeit benötigt, aber nicht in allen Fällen.
Du kannst die Suchfunktion nutzen - oben rechts.
Suchmuster: Shelly 3EM
Bei Bedarf erweiterten Filter verwenden ...
Viel Erfolg!
Ich schließe hiermit die Präsentation meines Skripts und dessen Pflege hier ab.
Ab nun pflege ich die Skript-Dokumentation ausschließlich auf einer von mir betriebenen Website.
Selbstverständlich stehe ich bei Fragen oder Wünschen bzgl. des Skripts hier im Forum weiterhin zur Verfügung.
Ich wünsche allen Anwendern gutes Gelingen und viel Freude daran.
Edit:
Ich biete nun ein geringfügig erweitertes Skript an, welches eine Motion Latenz nutzt. Weiteres dazu ist unter obigem Link zu finden.
Diese Motion Latenz ist konfigurierbar und sie sorgt dafür, dass wenn der Anwender einen Verbraucher (Lampe) manuell ausschaltet, er noch Zeit hat, den Erfassungsbereich eines Motion zu verlassen, ohne dass der Motion den Verbraucher einschaltet.
Nur komisch war, es hat vorher immer geklappt mit einmal geht es nicht mehr.
Dafür kann es mehrere Ursachen geben. Ist ein zusätzliches Magnetfeld oder ein ferromagnetisches Teil in der Nähe hinzugekommen, welches das Magnetfeld "verbiegt"?
Falls Reedkontakte enthalten sind, ich habe keinen solchen Sensor, diese können ihr Verhalten afaik im Laufe des Alterns verändern. Falls Hall-Elemente darin stecken ist dies afaik weniger wahrscheinlich.
Die durchaus interessante und auch wenig aufwändige Lösung von MIHO besitzt folgendes Verhalten nicht.
Wenn der Motion die Lampe für eine gewisse Dauer einschalten lässt und der Nutzer dann erst den Schalter betätigt, soll die Lampe nicht nach Ablauf dieser Dauer ausgeschaltet werden.
Wenn dieses Verhalten gewünscht ist, dann kann dies ausschließlich auf dem vom Motion angesteuerten Gerät (bspw. Shelly Plus 1) implementiert werden. Wenn dieses zugleich der Schaltaktor ist, implementiert mein Skript ein solches Verhalten und mehr, wenn meine Anleitung beachtet wird.
Welcher Shelly?
Hier ist der empfangende (ggf. schaltende) Shelly gemeint.
Ist Eco Mode aktiviert?
Dies gilt für WLAN, es könnte aber zugleich Bluetooth betreffen. Das kann vermutlich thgoebel beantworten.
Dann wäre dieser Eco Mode zu deaktivieren, um eine größere Feldstärke zu erreichen.
Mit Blu Shelly kenne ich mich nicht aus.
Wie weit ist der elektronische Sensor vom Empfangsgerät (ein Shelly?) entfernt?
Ich habe für so etwas ein Skript erstellt, welches nach dem Start die wichtigsten Informationen ausgibt.
Hierzu ist die Nutzung der Web UI (Web Browser mit IP Adresse des Plus 1) erforderlich.
Das Skript ist in diesem Forum veröffentlicht.
Einen Blu Motion konnte ich damit allerdings nicht testen, da ich keinen solchen habe.
so dass man beim Verlassen austasten kann und der Blu Motion einen aber nicht wieder erfasst und das Licht wieder anschaltet.
Solches habe ich nicht im Skript implementiert. Ich könnte allenfalls mit einem Motion dafür experimentieren.
Dann müsste das Skript mit einem Einschalten per Taster ein späteres, temporäres Ignorieren der Motion Nachricht aktivieren. Dieses Ignorieren würde mit dem Ausschalten per Taster bspw. für 10s aktiviert. So etwas ist möglich und vermutlich auch interessant.
Dazu braucht es erheblich mehr Informationen.
Welcher Shelly?
Welcher Sensor?
Wie platziert?
Welche Access Points wo platziert?
Ist Eco Mode aktiviert?
NIEMALS zeigt er mir rechts oben die Zeit an
und lässt mich auch nichts in den schedules ändern / speichern ?!
Ein Shelly hat keine batteriegepufferte Uhr. Er ist also nach seinem booten zwecks Zeitsynchronisation kurzzeitig auf den Zugriff auf einen Zeitserver angewiesen.
Stelle somit sicher, dass der Shelly Zugriff auf das Internet hat! Da er sicherlich in dein WLAN eingebunden ist (Cloud), wird dies gegeben sein.
Zeitpläne müssen trotzdem speicherbar sein.
Normalerweise kann man die Zeitzone und die Geo-Daten automatisch bestimmen lassen.
Reboots hasst du sicher einige durchgeführt, oder?
Wenn dann irgendwann Zeitpläne gespeichert sind, werden diese vermutlich passend wirksam.
Nun noch die hoffentlich letzte Version des Skripts.
Action URLs auf dem Motion: Keine anderen als die aufgelisteten!
Action URL auf einem remote Button, bspw. Shelly i4 oder Shelly Button 1: Kein anderer URL!
http://<IP Zieladresse>/script/<Skript Id>/toggle
Das automatische Ausschalten per Timer oder per "off" erfolgt ausschließlich, wenn per "on" (Motion-Anwendung) eingeschaltet wurde.
Schaltet man per "toggle" (Button) ein, während bereits per "on" (Motion) eingeschaltet war, bleibt die Lampe an, auch wenn der Motion ein "off" sendet.
Letzteres gilt bei jeder Quelle, die nicht per "on" einschaltet - also auch per angeschlossenem Schalter, wenn der Eingang als Schalter konfiguriert ist.
Ein angeschlossener Button kann entweder nur umschalten (ein->aus, aus->ein) oder er muss als detached eingestellt werden und per Action obigen URL mit "toggle" nutzen.
Die Bezeichnungen "on", "off" und "toggle" sind historisch aus der Weiterentwicklung entstanden. Insbesondere "toggle" ist hier nicht in jedem Fall wörtlich zu nehmen.
Ich bin zuversichtlich, dass ich damit alle möglichen Kombinationen berücksichtigt habe.
// Created by Gerhard Eichelsdörfer alias eiche - 2024-03-14
let Retrigger = true, // Set to false if you don't want the motion to retrigger!
MotionName = "motion",
RemoteName = "remote",
out = 0, // output id
on = null, // output status
th = null, // timer handle
src = null; // source of switching
function send_response(response, body) {
response.code = 200;
response.body = body;
response.send();
}
function switchSet(id, state) {
Shelly.call("Switch.set", {id:id, on:state},
function(result, errcode, errmsg, ud) {
if(errcode!==0) print("error in switchSet(" + ud.id + ", " + ud.state + "): ", errcode, ", ", errmsg);
}, {id:id, state:state}
);
}
function startTimer(dur) {
Timer.clear(th);
if(dur>0) {
dur = Math.floor(1000*dur);
th = Timer.set(dur, false, function () {switchSet(out, false);});
print("Timer started for " + (dur/1000) +" seconds");
}
}
// from a remote motion sensor - with an optional duration value
HTTPServer.registerEndpoint('on',
function (request, response) {
send_response(response, "OK");
let para = 0;
if(request.query.length > 0) para = JSON.parse(request.query);
if(!isNaN(para) && para>0 && (!on || (Retrigger && src===MotionName))) startTimer(para);
if(!on) {
src = MotionName;
switchSet(out, true);
}
}
);
// from a remote motion sensor - e.g. at the end of motion detected
HTTPServer.registerEndpoint('off',
function (request, response) {
send_response(response, "OK");
if(on && src===MotionName) switchSet(out, false);
}
);
// from a remote toggle call, e.g. from an i4.
HTTPServer.registerEndpoint('toggle',
function (request, response) {
send_response(response, "OK");
let tmp = src;
src = RemoteName;
let st = Shelly.getComponentStatus("switch:" + out);
if(st.output && tmp===MotionName) {
Timer.clear(th);
print("source: ", src, ", Timer cleared")
return;
}
Shelly.call("Switch.Toggle", {id:out},
function (result, errcode, errmsg, ud) {
if(errcode!==0) {
src = ud.src;
print(ud.msg, errcode, ", ", errmsg);
}
}, {src:tmp, msg:"error in remote toggle: "}
);
}
);
Shelly.addEventHandler(function(e) {
//print(JSON.stringify(e));
if(e.info.event==="toggle") {
on = e.info.state;
let st = Shelly.getComponentStatus("switch:" + out);
if(st.source!==undefined && st.source!=="loopback") src = st.source;
print("source: ", src, ", status: ", on ? "on" : "off");
}
});
//Do some user friendly printout
function messages() {
let ipAddress = Shelly.getComponentStatus("wifi").sta_ip;
if(ipAddress===null) ipAddress = '<IP address of your switching Shelly>';
let myId = Shelly.getCurrentScriptId();
print('The action URL of your motion with an optional duration is:');
print('http://' + ipAddress + '/script/' + myId + '/on?<duration in seconds>');
print('For switching off via motion the action URL is:');
print('http://' + ipAddress + '/script/' + myId + '/off');
print('When switching via remote command, e.g. Shelly i4, the URL for the remote action is:');
print('http://' + ipAddress + '/script/' + myId + '/toggle');
}
messages();
let info = Shelly.getComponentStatus("switch:" + out);
//print(JSON.stringify(info));
src = info.source;
on = info.output;Lasse bitte hier von dir lesen, wenn du weiter gekommen bist oder Erkenntnisse gewonnen hast!
Letzteres ist ja auch eine Art des Weiterkommens.
Da bin ich raus, habe keine zwei Blu Button. Konnte nicht einmal den einen zum funktionieren bewegen.
Da das Skript nicht sehr lang ist, täte ich ein zweites, gleiches Skript nutzen. Im zweiten Skript ist selbstverständlich die MAc Adresse des zweiten Blu Buttons einzutragen - und bei Bedarf andere URLs.
Wenn das funktioniert, kann man noch das Skript genauer analysieren und ggf. zusätzliche Einträge in CONFIG sowie weitere Funktionen parallel zu den jetzigen zusätzlich einbauen.
Das Skript beinhaltet sehr viel Code, um DAUs mitzuteilen, dass sie in CONFIG Sch... gebaut haben. Für die reine Funktionalität kann das Skript deutlich kürzer sein.
Wer eine Cloud nutzt, trägt auch die Verantwortung für unsicheres Verhalten. 
Ist der Zeitplan auf dem Shelly direkt eingetragen?
Nutze dafür bitte die Web UI und nicht die Cloud! Und auch nicht die App ...
Dann musst du mit dem Motion und dessen blind time experimentieren. Solange das Skript keine entsprechende Nachricht erhält, kann es nichts für dich tun.
Hier ein Screenshot mit der Protokollierung per Skript.
Es zeigt, dass der Timer für 11s gestartet wurde, die Quelle (source: motion) und dass eingeschaltet wurde (status: on).
Es folgen zwei Retrigger (Timer started for 11 seconds) und schließlich das Ausschalten.
Du kannst an den Uhrzeiten rechts erkennen, dass insgesamt 28s lang eingeschaltet war, wobei jede eintreffende Nachricht vom Motion mit 11s Dauer beaufschlagt ist.
Der URL auf dem Motion zu obigem Screenshot lautet 'http://192.168.179.15/script/1/on?11'
Du kannst ja auch im Motion zwei URL eintragen, einer zum Mini mit dem Skript und ein anderer welcher einen Shelly per HTTP Get und einer gewissen Dauer einschaltet. Es ist zu erwarten dass sich beide Schalt-Shelly gleich verhalten. Noch besser wäre ein Node-RED Flow zum untersuchen, wann der Motion die HTTP Requests gesendet hat. Zumindest sehr wahrscheinlich sendet der Motion in zu großen Zeitabständen.
Ändere doch mal die Dauer für den Test von 60s auf 180s oder mehr und schaue, wie sich die Lampe dann verhält!
Was aber in jedem Fall funktionieren wird, ist der URL vom i4 kommend, sofern dieser dort richtig eingetragen ist. Und das ist nach dem Titel dieses Thread besonders wichtig.
Ich nutze auch auf einem Motion zwei Movement Actions. Eine unter "Motion detected" und eine unter "End of motion detected". Auch dies kann per Skript verarbeitet werden. dann muss diese Nutzung aber dargelegt werden, damit bspw. ich das Skript darauf anpassen kann. Bisher entnahm ich deinen Darlegungen, dass der Motion das Licht eine gewisse Dauer einschalten soll und das Ausschalten per Taster (am i4) verhindert werden soll. Genau das tut das Skript. Die optionale Retriggerung ist nur eine Beigabe meinerseits.
Edit:
Per aktuellem Skript mit Datum 2024-03-13 kann man auch die Dauerangabe hinter on, also bspw. ?60, weglassen oder ?0 (Null) einsetzen. Dann wird der Timer nicht gestartet und die Lampe bleibt eingeschaltet. Das Skript bietet aber derzeit keine Möglichkeit, die Lampe vom Motion ausgehend unter "End of Motion detected" nur bedingt auszuschalten, nämlich nur dann, wenn die Lampe vom Motion eingeschaltet wurde. Um dies zu erreichen, denke ich über eine Ergänzung im Skript nach.
Ok, dann kannst du zumindest mit dem Skript aus #3 experimentieren und so die passende Dauer sukzessive herausfinden.
Dazu genügt es zunächst, den URL in einem Web Browser zu verwenden.
Yes, and also in this post:
Standard URL motion detected: http://192.168.0.247/relay/0?turn=on
Standard URL end of motion detected: http://192.168.0.247/relay/0?turn=off
Ich habe deinen Betrieb so verstanden, dass der Shelly, auf welchem das Skript läuft, die Lampe schaltet. In diesem Fall sind beide obigen URL völlig obsolet.
Falls nicht der Skript-Shelly die Lampe schaltet, muss hierfür im Skript statt der Methode "Switch.Set" u.a. die Methode "HTTP.Get" mit URL verwendet werden.
Das ist zunächst zu klären.
Der Motion muss wie in #50 beschrieben den URL http://<IP Adresse des Schalt-Shelly>/script/<Skript Id>/on?<Dauer in Sekunden> in seiner Action zur Bewegungserkennung verwenden.
Das Skript retriggert nach Voreinstellung (Retrigger = true) - die Lampe bleibt an (nach der blind time), solange das Licht nicht per Taster am i4 eingeschaltet wird. Ist die Lampe bereits per Motion eingeschaltet, wird nur das Abschalten deaktiviert. So kann der Anwender das Dauerlicht per Taster einschalten und der Motion hat trotz seiner Nachrichten keine Wirkung, weil im Skript die vom Motion eintreffende Nachricht ausschließlich im ausgeschalteten Zustand zum Zuge kommt oder wenn das Einschalten per Motion erfolgte (Retriggerung).
Der i4 muss den URL http://<IP Adresse des Schalt-Shelly>/script/<Skript Id>/toggle wie in #50 beschrieben per dem Taster/Eingang zugeordneter Action verwenden.
Zum testen kannst du diesen URL aber auch in der Browser Adresszeile anwenden. Mit diesem URL schaltet das Skript die Lampe ein und/oder lässt vom Motion eintreffende Nachrichten http://<IP Adresse des Schalt-Shelly>/script/<Skript Id>/on?<Dauer in Sekunden> ignorieren, bis die Lampe per i4 Taster ausgeschaltet wird. Da du afaik nur einen Taster dafür verwenden willst, habe dafür die toggle Funktion genutzt, weshalb der URL am Ende auch "toggle" beinhaltet (nur als verständlichen Namen).
Da ich derzeit keinen Pro 3EM besitze, kann ich dir nun nicht weiterhelfen.
Protokollfehler sollten die Funktion des Shelly nicht beeinflussen, es ist halt "unschön".
Ich täte an einer solchen Stelle das Protokoll auf einen Arbeitscomputer herunterladen und mir etwas genauer ansehen.
Vielleicht wäre dabei etwas Auffälliges zu finden.
