31.03 Ertrag gem Modul 36kWh gem Fronius 40kWh, vorhersage gem modul 47kWh
01.04 Ertrag gem Modul 39kWh gem Fronius 54kWh , vorhersage gem modul 30kWh
02.04 Ertrag gem Modul 71kWh gem Fronius 88kWh , vorhersage gem modul 83kWh
03.04 Ertrag gem Modul 56kWh gem Fronius 69kWh , vorhersage gem modul 57kWh
04.04 Ertrag gem Modul 21kWh gem Fronius 25kWh , vorhersage gem modul 16kWh
05.04 Ertrag gem Modul 72kWh gem Fronius 90kWh , vorhersage gem modul 64kWh
06.04 Ertrag gem Modul 90kWh gem Fronius 101kWh , vorhersage gem modul 83kWh
07.04 Ertrag gem Modul 87kWh gem Fronius 108kWh , vorhersage gem modul 84kWh
setupBatteryDev01
WR10 pout=PowerFlow_Site_P_Akku:Wh pin=-pout charge=PowerFlow_Inverters_1_SOC cap=10000 show=1 icon=@dyn:::@dyn
setupInverterDev01
WR10 pvOut=PowerFlow_Site_P_PV:W etotal=PowerFlow_Inverters_1_E_Total:Wh capacity=10000 icon=inverter@red:solar ac2dc:Storage_1_Controller_Current_DC strings=Ost
setupInverterDev02
WR7 pvOut=PowerFlow_Site_P_PV:W etotal=PowerFlow_Site_E_Total:Wh capacity=8000 icon=inverter@green:solar strings=West
setupInverterDev03
138291915078 pvOut=138291915078_0_power:W etotal=138291915078_0_yieldtotal:Wh capacity=2500 icon=inverter@blue:solar strings=Garage
setupInverterStrings
Ost,West,Garage
setupMeterDev
WR10 gcon=PowerFlow_Site_P_Grid:W
contotal=Meter_0_EnergyReal_WAC_Sum_Consumed:Wh
gfeedin=-gcon
feedtotal=Meter_0_EnergyReal_WAC_Sum_Produced:Wh
conprice=0.23:€
feedprice=0.07123:€
setupRadiationAPI
OpenMeteoDWD_D2-API
setupStringAzimuth
Ost=E West=W Garage=S
setupStringDeclination
Ost=45 West=45 Garage=45
setupStringPeak
Ost=10 West=9.5 Garage=2.25
setupWeatherDev1
OpenMeteoDWD_D2-API
//------------------------------------------------------------------------------------------------------
// Dynamisch Titel "FHEM <letztes Oktett der Server-IP>" setzen
//------------------------------------------------------------------------------------------------------
function setFhemHeaderFromServerIP() {
try {
const serverIP = new URL(window.location.href).hostname;
const lastOctet = serverIP.split(".").pop();
const hdr = document.getElementById("hdr");
if (hdr && ! document.getElementById("fhem-title")) {
const container = document.createElement("div");
container.id = "fhem-title-container";
container.style.cssText = "display: inline-block; margin: 0; padding: 0; vertical-align: middle;";
const title = document.createElement("span");
title.id = "fhem-title";
title.textContent = "FHEM " + lastOctet;
title.style.cssText = "display:inline;color:#6d77e2;font-size:24px;font-weight:bold;" +
"text-shadow:2px 2px #c5c5c5;margin-right:6px;";
const indicator = document.createElement("span");
indicator.id = "sse-status";
indicator.style.cssText = "display:inline-block;width:5px;height:5px;margin-left:4px;" +
"border-radius:50%;vertical-align:middle;";
container.appendChild(title);
container.appendChild(indicator);
hdr.insertBefore(container, hdr.firstChild);
}
}
catch (e) {
console.warn("Fehler beim Ermitteln der Server-IP: ", e);
}
}
//------------------------------------------------------------------------------------------------------
// setHeaderStatusIcon (Farbwechsel für Statussymbol)
//------------------------------------------------------------------------------------------------------
function setHeaderStatusIcon(status) {
const indicator = document.querySelector("#sse-status");
if (! indicator || ! window.sseStatusAllowed) return;
// Alle Statusklassen entfernen
indicator.classList.remove("ok", "error", "waiting");
// Neue Statusklasse setzen
if (status === "ok") {
indicator.classList.add("ok");
indicator.style.backgroundColor = "#00cc00";
indicator.title = "SSE-Verbindung aktiv";
} else if (status === "error") {
indicator.classList.add("error");
indicator.style.backgroundColor = "#cc0000";
indicator.title = "SSE-Verbindung fehlgeschlagen";
} else if (status === "waiting") {
indicator.classList.add("waiting");
indicator.style.backgroundColor = "#ffcc00";
indicator.title = "Verbindungsaufbau läuft";
} else {
indicator.remove();
}
} if($cmd eq 'manual') {
$mode = 'virtual'; # manual is virtual setting - no command to be sent
return "SOMFY_set: No manual position given" if(!defined($arg1));
return "SOMFY_set: $arg1 must be between 0 and 100 or on/off for manual " if($arg1 !~ /^(on|off|200|150|98|[1-9]?0)$/ );
update_while_idle auf 1 
Zitat von: mistepke am 08 April 2026, 09:23:53Ich sehe das im Image das DateTime.pm fehlt. War das beabsichtigt?

Im FHEM ASC fehlen jeden Tag beliebige Fahrten von Rollos.
Auch mit den letzten Updates kommt es zu Merkwürdigkeiten. Einzelne Rollo Fahrten fallen willkürlich aus und ich weiß jetzt nicht mehr weiter, da es jahrelang sehr gut gelaufen ist.
- FHEM Update hat stattgefunden
- shutdown restart
- kompletter Neustart des RPI hat stattgefunden
- FHEM läuft im Docker Container, der ebenfalls regelmäßig mit updates versorgt wurde
- Verwendet wird TCM mit EnOcean als LAN Device
- Die Position der Antenne wurde bereits testweise verändert
- Die Entfernung der Rollos spielt keine Rolle, da alle problemlos auch über FHEM manuell gefahren werden können
- Das Logging von EnOcean, TCM und EnOcean ist auf verbose 5, der ASC_Debug Modus wurde aktiviert
Das heutige Problem: KU_S_Rollo_FSB61 hatte kein day_open und wurde dann nach dem Aufstehen manuell hoch gefahren
ASC Log von diesem Problem:
ASC_DEBUG!!! 2026.04.08 06:18:27 - FnSetCmdFn: KU_S_Rollo_FSB61 - Rollo wird gefahren, aktuelle Position: 100, Zielposition: 0. Grund der Fahrt: day open
2026.04.08 06:18:27.052 4: AutoShuttersControl (ASC) - Devname: KU_S_Rollo_FSB61 Name: ASC Notify: $VAR1 = [
'endPosition: open'
];
2026.04.08 06:18:27.053 4: AutoShuttersControl (ASC) - Devname: KU_S_Rollo_FSB61 Name: ASC Notify: $VAR1 = [
'anglePos: 0'
];
2026.04.08 06:18:27.054 4: AutoShuttersControl (ASC) - Devname: KU_S_Rollo_FSB61 Name: ASC Notify: $VAR1 = [
'position: 0'
];
ASC_DEBUG!!! 2026.04.08 06:18:27 - Notify: ASC_Pos_Reading Event vom Rollo KU_S_Rollo_FSB61 wurde erkannt - RECEIVED EVENT: $VAR1 = [
'position: 0'
];
ASC_DEBUG!!! 2026.04.08 06:18:27 - EventProcessingShutters: Fn wurde durch Notify aufgerufen da ASC_Pos_Reading Event erkannt wurde - RECEIVED EVENT: $VAR1 = 'position: 0';
2026.04.08 06:18:27.055 4: AutoShuttersControl (ASC) - Devname: ASC Name: ASC Notify: $VAR1 = [
'KU_S_Rollo_FSB61_PosValue: 0'
];
ASC_DEBUG!!! 2026.04.08 06:18:27 - EventProcessingShutters: KU_S_Rollo_FSB61 - Event vom Rollo erkannt. Es wird nun eine etwaige manuelle Fahrt ausgewertet. Int von ::gettimeofday: 1775621907 Last Position Timestamp: 1775621907 Drive Up Max Duration: 70 Last Position: 100 aktuelle Position: 0
2026.04.08 06:18:27.056 4: AutoShuttersControl (ASC) - Devname: ASC Name: ASC Notify: $VAR1 = [
'state: day open'
];
ASC_DEBUG!!! 2026.04.08 06:18:27 - EventProcessingShutters: eine automatisierte Fahrt durch ASC wurde erkannt! Es werden nun die LastDriveReading und StateReading Werte gesetzt!
ASC_DEBUG!!! 2026.04.08 06:18:27 - EventProcessingShutters: Fn wurde durlaufen und es sollten Debugausgaben gekommen sein. !!!Wenn nicht!!! wurde der Event nicht korrekt als Nummerisch erkannt.
2026.04.08 06:18:27.057 3: EnOcean set KU_S_Rollo_FSB61 open
2026.04.08 06:18:27.057 4: EnOcean KU_S_Rollo_FSB61 sent PacketType: 1 RORG: A5 DATA: 015E010A SenderID: FFBA2381 STATUS: 00 ODATA:
ASC_DEBUG!!! 2026.04.08 06:18:27 - FnSetDriveCmd: KU_S_Rollo_FSB61 - NICHT versetztes fahren
ASC_DEBUG!!! 2026.04.08 06:18:27 - FnSetDriveCmd: KU_S_Rollo_FSB61 - NoDelay: NEIN
2026.04.08 06:18:27.059 4: AutoShuttersControl (ASC) - Devname: ASC Name: ASC Notify: $VAR1 = [
'KU_S_Rollo_FSB61_lastPosValue: 100'
];
2026.04.08 06:18:27.059 4: AutoShuttersControl (ASC) - ShuttersCommandSet setDriveCmd wird aufgerufen
ASC_DEBUG!!! 2026.04.08 06:18:27 - FnShuttersCommandSet: KU_S_Rollo_FSB61 - Das Rollo wird gefahren. Kein Partymodus aktiv und das zugordnete Fenster ist entweder nicht offen oder keine Terassentür
2026.04.08 06:18:27.061 4: AutoShuttersControl (ASC) - Devname: ASC Name: ASC Notify: $VAR1 = [
'KU_S_Rollo_FSB61_nextAstroTimeEvent: 08.04.2026 - 21:41'
];
2026.04.08 06:18:27.063 4: AutoShuttersControl (ASC) - Devname: KU_S_Rollo_FSB61 Name: ASC Notify: $VAR1 = [
'ASC_Time_PrivacyDriveDown: 08.04.2026 - 18:01'
];
2026.04.08 06:18:27.064 4: AutoShuttersControl (ASC) - Devname: ASC Name: ASC Notify: $VAR1 = [
'state: created new drive timer'
];
Gemini hat gesagt
Die wichtigste Erkenntnis vorab: ASC arbeitet korrekt. Das Modul erkennt die Zeit, berechnet die Zielposition und setzt den Befehl set KU_S_Rollo_FSB61 open ab. Auch FHEM meldet in Zeile 06:18:27.057, dass das EnOcean-Paket (PacketType: 1) versendet wurde.
Das Problem liegt tiefer in der Hardware-Kommunikation oder dem Timing. Hier ist die Analyse der Schwachstellen:
1. Das "Kollisions-Problem" (Hauptverdächtiger)
Im Log steht: ASC_DEBUG!!! 2026.04.08 06:18:27 - FnSetDriveCmd: KU_S_Rollo_FSB61 - NICHT versetztes fahren.
Wenn mehrere Rollos gleichzeitig (auf die Sekunde genau) den Befehl zum Öffnen erhalten, feuert FHEM diese Befehle fast zeitgleich an dein EnOcean-LAN-Gateway. EnOcean ist ein sehr langsames Protokoll ohne echte Kollisionsprüfung beim Senden.
Die Folge: Die Funkwellen überlagern sich, das Gateway "verschluckt" sich oder der Aktor (FSB61) kann das überlagerte Signal nicht dekodieren.
Lösung: Nutze das Attribut ASC_Shutter_Drive_Stagger im ASC-Hauptdevice. Setze es auf einen Wert wie 5 oder 10 (Sekunden). Dies entzerrt die Fahrten und verhindert Funk-Staus.
2. Die "optimistische" Positionsmeldung
Auffällig ist, dass das Event position: 0 bereits um 06:18:27.054 im Log erscheint, während der eigentliche EnOcean-Sende-Befehl erst um 06:18:27.057 dokumentiert wird.
Das deutet darauf hin, dass das EnOcean-Device in FHEM die Position sofort auf "0" (offen) setzt, sobald der Befehl gesendet wurde, ohne auf eine Rückmeldung vom Aktor zu warten (optimistisches Update).
Wenn der Funkbefehl den Aktor nie erreicht hat, glaubt FHEM trotzdem, das Rollo sei offen.
Prüfung: Schau dir im FSB61-Device das Attribut confirm oder die Bestätigungstelegramme an. Sende nur dann ein Statusupdate, wenn der Aktor es quittiert.
3. LAN-Gateway & Docker-Latenz
Du nutzt ein EnOcean LAN-Device im Docker. Hier gibt es eine potenzielle Fehlerquelle im Netzwerkstack:
TCP-Keepalive: Wenn die Verbindung zwischen Docker/FHEM und dem LAN-Gateway kurzzeitig "schläft" oder abbricht, geht das erste Paket oft ins Leere, bevor die Verbindung neu initialisiert wird.
Docker-Netzwerk: Läuft der Container im bridge oder host Modus? Für LAN-Gateways ist der host-Modus (oder ein dediziertes Macvlan) deutlich stabiler, um Latenzen bei der Paketweiterleitung zu vermeiden.
4. Hardware-Ermüdung (FSB61)
Die FSB61-Aktoren haben Relais, die nach vielen Jahren der Nutzung "kleben" bleiben können.
Da du sagst, manuelles Fahren geht problemlos, ist ein mechanischer Defekt unwahrscheinlich, aber: Manuelle Fahrten erfolgen oft einzeln. Die Automatik fährt alle. Das verstärkt das unter Punkt 1 genannte Funk-Kollisionsproblem.
Zusammenfassung & Empfehlung
Um den Fehler einzugrenzen, solltest du folgende Schritte gehen:
Entzerrung (Sofort-Maßnahme): Setze im ASC-Device attr ASC_Shutter_Drive_Stagger 10. Beobachte, ob die Ausfälle aufhören.
TCM-Check: Prüfe das TCM-Device. Gibt es im Log Meldungen wie TCM_LAN_Device: disconnected?
Telegramm-Analyse: Vergleiche bei einer fehlgeschlagenen Fahrt, ob der Aktor überhaupt ein Bestätigungstelegramm schickt. Ein FSB61 schickt normalerweise nach Erhalt des Befehls und nach Ende der Fahrt ein Telegramm. Wenn im FHEM-Log nach dem sent Packet gar kein received Packet vom FSB61 auftaucht, ist das Paket physikalisch nicht angekommen.
Docker-Netzwerk: Stelle sicher, dass der Container die Kommunikation zum LAN-Gateway ohne große Umwege (NAT) führen kann.
Persönliche Einschätzung: Da es jahrelang lief und nun "willkürlich" passiert, ist eine gestiegene Funklast oder eine leichte Instabilität der Netzwerkverbindung zum LAN-Gateway (eventuell durch Docker-Updates/Kernel-Änderungen) am wahrscheinlichsten. Die Entzerrung der Fahrbefehle (Stagger) löst 90% dieser Probleme bei EnOcean-Systemen.
set manual nicht mehr. Der Befehl set Wohnzimmer_Fenster_Sued manual 10 ergibt die Fehlermeldung SOMFY_set: 100 must be between 0 and 100 or on/off for manualZitat von: viegener am 17 Oktober 2016, 23:36:29Es gibt eine neue Version des Somfy-Moduls in github, diese enthält eine erste Version einer umgedrehten Positionslogik, wie in diesem Thread andiskutiert:
https://forum.fhem.de/index.php/topic,24158.msg501349.html#msg501349
Es gibt dazu ein spezielles Attribut aufnehmen ([tt]positionInverse[/tt] mit dem Wert 1 wird die neue Logik eingeschaltet). Dann würde zwar intern weiter mit den Werten 0 bis 100/200 gerechnet, aber die externen Readings würden umgerechnet sodass dann:
Jetziger Wert 0 --> Neu: 100
Jetzt 100 --> Neu: 10
Jetzt 200 --> Neu: 0
Also ist dann 10 der Rolladen unten und 0 wäre geschlossen. Damit wäre das auch in derselben Richtung wie bei Homematic?
Die Umrechnung wird nur gemacht, wenn das Attribut gesetzt ist, so dass sich für existierende Nutzer nichts ändern muss.