Shelly Gen 3 + Loxone – Fallback bei Miniserver-Ausfall

Guten Tag zusammen,

ich habe eine Frage an euch und hoffe, dass mir jemand weiterhelfen kann. Vermutlich wurde das Thema schon einmal behandelt, allerdings habe ich bisher keine passende Lösung gefunden.

In meiner Wohnung sind zahlreiche Shelly Gen 3 Geräte im Einsatz (u. a. Shelly Dimmer Gen 3 und Shelly 1 Gen 3), die erfolgreich mit Loxone Miniserver kommunizieren.

Die Umsetzung ist so, dass die Eingänge der Shelly-Geräte nicht direkt mit den Ausgängen gekoppelt sind, sondern stattdessen per UDP Signale an den Miniserver senden. Dieser übernimmt dann die Logik und schaltet die entsprechenden Aktoren bzw. Dimmer. Das funktioniert im Normalbetrieb einwandfrei.

Allerdings habe ich folgendes Problem:

Sobald der Miniserver (oder das WLAN) nicht erreichbar ist, kann ich kein Licht mehr schalten, da die direkte Kopplung zwischen Eingang und Ausgang fehlt.

Meine Idee wäre daher eine Art Fallback-Mechanismus:

Solange der Miniserver erreichbar ist → normale Steuerung über Loxone

Wenn der Miniserver nicht erreichbar ist → automatische lokale Kopplung von Eingang und Ausgang im Shelly

Sobald der Miniserver wieder verfügbar ist → Rückkehr zum normalen Betrieb

Meine Frage: Gibt es eine Möglichkeit (z. B. per Script, Szenen oder Geräteeinstellungen), so eine Logik umzusetzen?

Oder hat jemand bereits eine ähnliche Lösung realisiert?

Vielen Dank im Voraus für eure Unterstützung!

Mit freundlichen Grüßen

Die Shelly Geräte werden in dieser Konstellation über UDP von Loxone ausgelesen, während die Ansteuerung der Aktoren über HTTP-Befehle erfolgt. Diese Kommunikationsstruktur hat sich in der Praxis als stabil und zuverlässig erwiesen.

Im Hinblick auf ein mögliches Ausfallszenario der zentralen Steuerung habe ich mich ebenfalls intensiv mit dem Thema beschäftigt. Dabei konnte ich ein entsprechendes Script implementieren, welches im Fehlerfall zuverlässig greift und die Funktionalität sicherstellt.

Grundsätzlich ist dein Ansatz hinsichtlich eines permanent aktiven Fallback-Betriebs absolut nachvollziehbar. In meinem Fall wird die Logik jedoch bewusst so umgesetzt, dass die zentrale Steuerung priorisiert arbeitet und der Fallback gezielt nur im Störfall aktiv wird, um ungewollte Parallelzustände oder Konflikte in der Logik zu vermeiden.

let MINISERVER_IP = "---------";
let CHECK_INTERVAL = 20000;
let failCount = 0;
let threshold = 3;
let currentMode = "unknown";

function setShellyMode(mode) {
if (currentMode === mode) return;

// Bei Gen 3 Button/Taster-Konfiguration nutzen wir 'Input.SetConfig'
// mode ist hier entweder 'detached' oder 'momentary'
Shelly.call("Input.SetConfig", {
id: 0,
config: {
type: "button", // Sicherstellen, dass es als Taster erkannt wird
enable: true,
invert: false
}
});

// Der entscheidende Befehl für die Trennung/Kopplung beim Taster
Shelly.call("Switch.SetConfig", {
id: 0,
config: {
in_mode: mode
}
}, function(res, error_code, error_msg) {
if (error_code === 0) {
currentMode = mode;
print("Taster-Modus erfolgreich geändert auf:", mode);
} else {
print("Fehler beim Umstellen:", error_msg);
}
});
}

function checkLoxone() {
Shelly.call("HTTP.GET", { url: "http://" + MINISERVER_IP + "/dev/sps/ping", timeout: 3 },
function(res, error_code) {
if (error_code === 0) {
// Loxone erreichbar -> Taster vom Relais trennen
if (failCount >= threshold currentMode !== "detached") {
setShellyMode("detached");
}
failCount = 0;
} else {
// Loxone offline -> Taster direkt mit Relais koppeln
failCount++;
print("Miniserver offline. Fail-Count:", failCount);
if (failCount >= threshold && currentMode !== "momentary") {
setShellyMode("momentary");
}
}
}
);
}

Timer.set(CHECK_INTERVAL, true, checkLoxone);
print("Taster-Fallback-Script gestartet...");
checkLoxone();