Hauptmenü

Neueste Beiträge

#91
Sonstiges / Aw: Neues Modul - 70_KEBA.pm z...
Letzter Beitrag von jackyno.71986 - 08 April 2026, 10:14:18
Hallo Zusammen,

könnte mir bitte jemand das Modul 70_Keba.pm zur Verfügung stellen?

Schöne Grüße

Matthias
#92
FHEM Development / Aw: SVN - Timeout
Letzter Beitrag von betateilchen - 08 April 2026, 10:11:34
Inzwischen funktioniert es auch hier wieder.
#93
Solaranlagen / Aw: 76_SolarForecast - Informa...
Letzter Beitrag von nookie - 08 April 2026, 10:09:01
Hi, nach einigen Hin und Her hab ich das Modul zum laufen bekommen, aber ich hab jeden Tag abweichungen bei der Erzeugung zu den Realen Werten und die Vorhersage die berechnet sich ja stündlich neu da versteh ich natürlich warum sich die vom vorabend zum tagesverlauf ändert.

Zur Anlage, ich habe insgesamt Drei WR`s ein Hoymiles-2250, ein Fronius Symo GEN24 10.0 mit 10Kw/h BYD Akku und ein Symo 8.2-3-M.


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


Was mache ich falsch?

mfg nookie
#94
FHEMWEB / Aw: [Voicecontrol] Button für ...
Letzter Beitrag von Prof. Dr. Peter Henning - 08 April 2026, 10:05:10
Es ging mir weniger ums Differenzieren, als darum, dass nur einmal abgespielt wird. Aber gut, der Weg ist tatsächlich einfacher als mit dem SSE-Server.

Da ich verschiedene FHEM-Server habe, wird mir als Titel der Seite jeweils das letzte Oktett der Server-IP angezeigt. Und bei dem FHEM mit dem SSE-Server kommt noch ein farbiger Punkt dazu, der den Status der SSE-Verbindung anzeigt. Rot=tot, Grün=SSE steht, Orange=wartet.

Wir bräuchten also in fhemweb.js auch noch eine Statusvariable. Dann könnte man z.B. bei blockiertem Audio wenigstens einen roten Punkt o.ä. anzeigen lassen.

LG

pah

//------------------------------------------------------------------------------------------------------
// 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();
    }
}
#95
Sonstige Systeme / Aw: 10_SOMFY.pm - Somfy RTS (u...
Letzter Beitrag von stef1938 - 08 April 2026, 09:55:42
Hallo andies,

vielen Dank, das sollte klappen!

Habe in line 749 einfach die 98 im code ergänzt:

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)$/ );

LG Stef
#96
Wallboxen und E-Fahrzeuge / Aw: 72_Wattpilot - Einbindung ...
Letzter Beitrag von nookie - 08 April 2026, 09:48:35
Hi, das Modul klappt gut, aber wenn ich die Auto`s ausstecke steht immer der letzte Powerwert dort, so dass das Modul SolarForecast dann einen verbrauch errechnet den es nicht gibt, kann man des abfangen?

mfg
Nookie


Update... ein blick in die Hilfe und Lösung gefunden ;) update_while_idle auf 1 ;)
#97
Server - Linux / Aw: Offizielles FHEM Docker Ba...
Letzter Beitrag von Sidey - 08 April 2026, 09:48:34
Zitat von: mistepke am 08 April 2026, 09:23:53Ich sehe das im Image das DateTime.pm fehlt. War das beabsichtigt?

Hallo mistepke,

Das ist nicht beabsichtigt und ein Fehler, den ich leider noch nicht lokalisiert habe.
Aktuell steckt in den ARM64 builds der Wurm, was sich in fehlenden CPAN Modulen bemerkbar macht.

Das letzt noch fehlerfrei Image ist 5.2.5-bookworm.


Grüße Sidey
#98
Automatisierung / Aw: ASC Rollo Fahrten finden n...
Letzter Beitrag von ch.eick - 08 April 2026, 09:42:08
Moin zusammen,
ich habe jetzt mal mit der Analyse begonnen und die KI gefragt :-)
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.

Meine erste Änderung ist dann jetzt

- attr ASC ASC_ShuttersDriveDelay 5
#99
Sonstige Systeme / Aw: 10_SOMFY.pm - Somfy RTS (u...
Letzter Beitrag von stef1938 - 08 April 2026, 09:27:39
Hallo viegener,

die Fuktion inverse ist genau die, welche mir hilft. Allerdings funktioniert damit der Befehl 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 manual
Hast du vielleicht eine Lösung?
Vielen Dank!

LG Stef

Zitat 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.


#100
Server - Linux / Aw: Offizielles FHEM Docker Ba...
Letzter Beitrag von mistepke - 08 April 2026, 09:23:53
Hallo,


mit der neuesten Docker Version geht jetzt Vitoconnect nicht mehr. Er kann das Modul nicht mehr laden mit dem Hinweise "reload: Error:Modul 98_vitoconnect deactivated:
 Can't locate DateTime.pm in @INC (you may need to install the DateTime module) (@INC entries checked: . ./FHEM ./lib /usr/src/app/core/lib/perl5/aarch64-linux-gnu /usr/src/app/core/lib/perl5 /usr/src/app/3rdparty/lib/perl5/aarch64-linux-gnu /usr/src/app/3rdparty/lib/perl5 /usr/local/lib/perl5/site_perl/5.38.5/aarch64-linux-gnu /usr/local/lib/perl5/site_perl/5.38.5 /usr/local/lib/perl5/vendor_perl/5.38.5/aarch64-linux-gnu /usr/local/lib/perl5/vendor_perl/5.38.5 /usr/local/lib/perl5/5.38.5/aarch64-linux-gnu /usr/local/lib/perl5/5.38.5 ./FHEM/lib) at ./FHEM/98_vitoconnect.pm line 93, <$fh> line 6227.
BEGIN failed--compilation aborted at ./FHEM/98_vitoconnect.pm line 93, <$fh> line 6227."

Ich sehe das im Image das DateTime.pm fehlt. War das beabsichtigt?

Danke und Gruß
Michael