Hauptmenü

Neueste Beiträge

#1
FHEM Code changes / Revision 30895: 76_SolarForeca...
Letzter Beitrag von System - 01 März 2026, 16:01:04
Revision 30895: 76_SolarForecast: contrib Version 2.2.2

76_SolarForecast: contrib Version 2.2.2

Source: Revision 30895: 76_SolarForecast: contrib Version 2.2.2
#2
Solaranlagen / Aw: 76_SolarForecast - Informa...
Letzter Beitrag von Parallix - 01 März 2026, 15:49:24
Zitat von: DS_Starter am 01 März 2026, 15:27:25...

:( Vielleicht bin ja der einzige mit o.g. Problem. Dann werde ich ein Dummy schreiben, welches für SF einen fiktiven SOC auf Basis früherer Verbrauchswerte bestimmt.
#3
Anfängerfragen / Aw: Homekit zur Überwachung
Letzter Beitrag von Guybrush - 01 März 2026, 15:42:41
Devices zu überwachen kannst du z.b. mit Watchdog gut umsetzen. Hier mal ein Beispiel für die Überwachung meiner Klimasteuerung:

defmod Essen.Klima.Watchdog watchdog Essen.Klima:mode:.* 00:15:00 SAME setreading OfflineDevices device-$NAME offline
attr Essen.Klima.Watchdog userattr notifyMessage
attr Essen.Klima.Watchdog DbLogExclude .*
attr Essen.Klima.Watchdog activateOnStart 1
attr Essen.Klima.Watchdog autoRestart 1
attr Essen.Klima.Watchdog group Watchdog
attr Essen.Klima.Watchdog room Interfaces->MQTT,Überwachung

bei mir wird das dann in das Dummy Device "OfflineDevices" geschrieben, wenn es länger als 15 Minuten keine aktualisierten Readings im Device gibt. Da läuft dann ein DOIF alle paar Minuten drüber, überprüft das und benachrichtigt mich falls nötig. Da kannst du dann aber auch alles andere machen, was du für dich brauchst. Ich hab bei den kritischen Sachen wie z.b. Wasserleckage etc noch zusätzlich Sprachdurchsagen über Sonos und Whatsapp Nachricht eingebaut.

Die HomeApp, von der du schreibst, sagt mir nichts. Aber grundsätzlich geht es bei sowas, was du suchst, nur drum bei events ein passendes reading zu beschreiben und darauf dann z.b. ein DOIF oder notify zu setzen
#4
Solaranlagen / Aw: 76_SolarForecast - Informa...
Letzter Beitrag von DS_Starter - 01 März 2026, 15:27:25
@Parallix,

ZitatDer Ladebedarf kann praktisch immer aus dem Neuanstecken eines BEV an der Wallbox abgeleitet werden. Der Energiemenge sollte sich aus früheren Ladevorgängen abschätzen lassen.
Das gilt vllt. für den initialen Bedarf, jedoch nicht für eine Fortschreibung die den Ladebedarf kontinuierlich neu bewertet - Unterbrechungen und Phasenreduktionen inklusive.
Außerdem setzt würde es voraussetzen, dass der Ladebedarf bei jeder Ladesession immer nahezu gleich bleiben würde. Da bezweifle ich. Wenn es so simpel ist braucht es eigentlich keinerlei Messungen, wir schätzen nur noch.

ZitatHierzu braucht man übrigens nicht einmal eine KI: Jeder Mensch, der ein Kraftfahrzeug führt, kennt seinen üblichen Wochen oder Monatsverbrauch oder kann diesen leicht durch Summation der Tankquittungen bestimmen.
Wenn es so einfach ist, kann man ein userReading mit diesem Wert anlegen welches ich konsumieren kann.
Dann steht auch der Pflichtangabe nichts im Wege.

ZitatUnd auch die beste KI kann nicht erahnen, in welcher Woche man z.B. zu einem Konzert fährt, für das man Tickets ergattert hat oder ob und wann man im laufenden Jahr in Urlaub fährt. Hier hilft ein Klick auf einen entsprechenden Button seines FHEM-Dashboards/Control-Panels oder das dortige Eintragen des Urlaubszeitraums sicher und - geeignete Modellierung vorausgesetzt - auch sehr präzise.
Kann sie micht, aber sehr wohl den E-Bedarf der nächsten Stunden wenn das EV angesteckt ist und der StartSOC sowie die Bat-Kapazität -> Zie-Soc bekannt ist.
#5
Solaranlagen / Aw: 76_SolarForecast - Informa...
Letzter Beitrag von DS_Starter - 01 März 2026, 15:20:13
Ich habe noch etwas an der contrib nachgebessert und hochgeladen.
#6
Anfängerfragen / Aw: readingsGroup commands mit...
Letzter Beitrag von Guybrush - 01 März 2026, 14:27:39
ich hab mir den Programmcode nun mal selbst angeschaut und so wie ich das sehe geht das nicht. Ich hab das nun für mich in die 33_readingsGroup.pm so angepasst, wie ich es brauchte. Dazu sollte aber besser mal justme1968 was sagen, da er die geschrieben hat.

Folgendes hab ich gemacht, damit man zumindest einfache Vergleiche anhand des Values machen und den link entsprechend dynamisch setzen kann.

In der 33_readingsGroup.pm hab ich folgende Funktion eingebaut:
sub readingsGroup_valueCheck($) {
    my ($value) = @_;

    $value =~ m/VALUE\(\s*'.*?'\s*\)/g;
    my $res = $&;

    if ($res) {

        my @str = split(/VALUE\(\s*'.+?\s*'\)/, $value);

        $res =~ s/VALUE\(\s*'//;
        $res =~ s/'\s*\)//;
        my @value = split(/','/, $res);

        return $str[0].($value[0] eq $value[1] ? $value[2] : $value[3]).$str[1] if (scalar(@value) == 4);
    }
}

dazu hab ich dann in der Datei alle Variablen "$value_prefix" ersetzt durch "readingsGroup_valueCheck($value_prefix)".

in fhem selbst habe ich dann statt des Attributs commands nun das Attribut valuePrefix gesetzt. In meinem Fall so:

attr OfflineDevices.RG valuePrefix <a style="cursor:pointer" onclick="FW_cmd('/fhem?XHR=1&cmd=setreading %DEVICE %READING VALUE('%VALUE','offline','confirmed','offline')')">

als valueSuffix muss natürlich noch "</a>" gesetzt werden, aber das sollte selbstverständlich sein.

so kann ich den Wert in der readingsGroup nun jederzeit zwischen offline und confirmed togglen ohne erst ins device gehen zu müssen. Wenn jemand eine einfachere Lösung hat, dann bitte gerne her damit. Ich finde es auch nicht so prickelnd in einer von fhem verwalteten Datei rumzufuschen, aber anders wusste ich jetzt nicht, wie es umzusetzen wäre und feedback gabs ja bislang keins  ;)

Vielleicht kann Justme1968 dazu auch mal was sagen.
#7
MQTT / Aw: "Der MQTT-Workshop (MQTT2-...
Letzter Beitrag von betateilchen - 01 März 2026, 14:15:31
Meine Behauptung war ja nicht, dass die Möglichkeiten in z2m für jedes Gerät die optimale Lösung sind. Aber in einigen Fällen kann man dadurch schon ganz gut selektieren bzw. zusammenfassen. Da es diese Parameter noch nicht immer gab, wollte ich nur auf die Möglichkeit hinweisen. Viele User aktualisieren zwar regelmäßig ihr z2m, aber wer liest schon release notes, um herauszufinden, was sich tatsächlich geändert hat.

Bei einem Bewegungsmelder oder Wassersensor möchte ich die Nachricht natürlich auch sofort haben.

#8
MQTT / Aw: "Der MQTT-Workshop (MQTT2-...
Letzter Beitrag von Beta-User - 01 März 2026, 13:36:12
Zitat von: betateilchen am 01 März 2026, 11:53:53Naja, die Grundsatzfrage ist: in welchen sinnvollen Intervallen BRAUCHE ich die Messwerte tatsächlich?

Früher lief das Ding unter deconz, und da gab es alle Minute oder so aktualisierte Messwerte :) . Das war völlig ausreichend, allerdings sind damit die Messwerte und der eigentliche Aktor getrennte HUEDevice-Instanzen gewesen, bei denen insbesondere Änderungen des Schaltzustands direkt durchgestellt wurden.

Im Moment gefällt mir der Gedanke noch nicht so richtig, Änderungen am Schaltzustand nicht direkt zu bekommen, was aber wohl die zwingende Folge von "throttle" wäre. 
Bei dem sowieso eigentlich immer eingeschalteten RCBO ist das aber kein pratisches Problem :) ; wenn der FI fliegen sollte, ist sowieso irgendwas anderes faul und die Reparatur würde dann vermutlich auch länger brauchen wie die Zeit seit der Meldung...

Weiter Filtern kann man dann ja immer noch 8) .
#9
Sprachsteuerung / Aw: alexa-fhem test version mi...
Letzter Beitrag von ferby09 - 01 März 2026, 13:16:37
Danke für deine Antwort und das Testen.

Leider funktioniert es weiterhin nicht bei mir.
Vorgestern war jedenfalls die Gerätesuche bei Alexa auch anders als sonst. Es wurde kein akustisches Feedback gegeben und die Gerätesuche lief auch nur wenige Sekunden.
Heute läuft sie wieder länger und ganz normal mit Ansage, dass es einen Moment dauern könnte.

Trotzdem wird mein device nicht gefunden, auch nach mehreren reloads.

Ich hatte zuerst alexa-fhem 0.5.65 und habe dann mit dem Befehl aus Post #24 auf Version 0.5.64 gedowngraded.

Was könnte ich denn noch prüfen?
Ist die Methode der Gerätesuche, einfach nur "Alexa, Gerätesuche" zu sagen, für ModeController richtig?
#10
Homematic / Aw: HM-LC-SW2-FM defekt: Siche...
Letzter Beitrag von Pfriemler - 01 März 2026, 13:14:57
Danke für die Klarstellung. Also keine Defekte, nur Funktionsstörungen. Unter "Ausfall" verstehe ich immer dauerhafte und spontan irreversible Betriebsverweigerung.

Macht es aber nicht besser mit der Diagnose. Dem Sw1PBU sollte es egal sein, er macht eine Gleichrichtung vom Netz, ab da sind die Eingangsfrequenzen irrelevant. Der Dim1TPBU schaltet mit FETs und nutzt dazu eine Nulldurchgangserkennung. Ich setze mal einen Versuch mit Funduskomponenten auf die Agenda: Meine Solarkoffer können auch 60 Hz ausgeben - wenn die Dinger mit 51 Hz ein Problem hätten, haben sie es mit Sicherheit auch mit 60 Hz.

stay tuned ... ich komme nur die nächsten drei Tage nicht dazu