Neueste Beiträge

#1

Sonstige Systeme / Aw: Bresser Wetterstation 868M...

Letzter Beitrag von Ralf9 - 16 Februar 2026, 18:09:43

Die Datenbitlänge ist ca 87us, der Kehrwert davon ist eine Datenrate von ca 11500

Die Ermittlung vom DEVIATN ist etwas aufwändiger, das kann aus dem Spektrum ermittelt werden:

Der Frequenzhub (DEVIATN) ist  (obere Frequenz - untere Frequenz) / 2
https://forum.fhem.de/index.php?topic=106594.msg1148604#msg1148604

#2

FRITZ!Box / Aw: FRITZ!Smart Energy 250

Letzter Beitrag von JoWiemann - 16 Februar 2026, 17:50:21

Hallo Fred,

da habe ich mich vertan. Ich meinte sekündlich und nicht minütlich. Es geht ja um die Bereitstellung. Dem optischen Abnehmer ist das Intervall egal. Jedenfalls sollte es.

Grüße Jörg

#3

DOIF / Wie gestalte ich die Bedingung...

Letzter Beitrag von Marko1976 - 16 Februar 2026, 17:34:56

Hallo,
mal eine Frage an die Profis.
Ich möchte gerne eine Aufgabe jede zweite oder dritte Woche ausführen lassen.
Für ungrade Wochen kann ich ja folgenden Code nutzen:

Code Auswählen Erweitern

int(($mday-1)/7)==2))
Aber wie kann ich das zum Beispiel für jeden 2. Sonntag schreiben, also der 2., der 4., der 6. Sonntag etc.?

Das einzige was ich gefunden habe ist "$week". Mein Ansatz wäre jetzt die Kalenderwoche durch 2 und dann zu prüfen ob das Ergebnis eine Ganzzahl ist, also 2/2=1, 4/2=2, 6/2=3, aber 1/2=0,5, 3/2=1,5 etc.
Zur Prüfung ob es sich um eine Ganzzahl handelt habe ich dies gefunden:

Code Auswählen Erweitern

if ($variable eq int($variable)) {
    Log 1, "Ist eine Ganzzahl";
}Doch wie bekomme ich das kombiniert und beides dann in die Bedingungsabfrage des DOIF?
Außerdem wäre das keine Lösung für die 3. Woche, die 4. Woche Woche etc..

Gibt es keine einfachere Alternative?

#4

Solaranlagen / Aw: 76_SolarForecast - Informa...

Letzter Beitrag von DS_Starter - 16 Februar 2026, 17:22:21

Man sieht ziemlich deutlich, dass zwischen 11 und 17 Uhr der Verbrauch relativ unvorhersehbar ist (Gründe müsstest du kennen?), aber durch die eingebaute Trendfolge zwischen benachbarten Stunden wieder ausgeglichen wird. Dadurch korreliert der Verbrauch wieder mit der Tagesprognose.
Mit einem tieferen Netz (80-40-20) erreicht man evtl. eine stärkere Differenzierung, aber ich denke das wird mit der Hardware schlecht funktionieren. Die Abfrage dauert jetzt schon über 100ms.
Ich denke das funktioniert schon ganz gut.   

[Revision 30860: 98_todoist: adjustments for new todoist API]

#5

FHEM Code changes / Revision 30860: 98_todoist: ad...

Letzter Beitrag von System - 16 Februar 2026, 17:20:27

Revision 30860: 98_todoist: adjustments for new todoist API

98_todoist: adjustments for new todoist API

Source: Revision 30860: 98_todoist: adjustments for new todoist API

#6

Solaranlagen / Aw: 76_SolarForecast - Informa...

Letzter Beitrag von grappa24 - 16 Februar 2026, 17:09:09

mal was zur "Ablenkung" vom EV-Thema:
CO-Abweichung fortlaufend: 3 %, gestern: 4,7 %

Code Auswählen Erweitern

letztes KI-Training: 16.02.2026 04:00:26 / Laufzeit in Sekunden: 2364
KI Abfragestatus: ok
letzte KI-Ergebnis Generierungsdauer: 129.21 ms
Verbrauchernummer Wärmepumpe:  -

=== Modellparameter ===

Normierungsgrenzen: PV=11990 Wh, Hausverbrauch: Min=0 Wh / Max=6468 Wh
Trainingsdaten: 9003 Datensätze (Training=7202, Validation=1801)
Architektur: Inputs=69, Hidden Layers=50-25, Outputs=1
Hyperparameter: Learning Rate=0.005, Momentum=0.5, BitFail-Limit=0.34
Aktivierungen: Hidden=SIGMOID, Steepness=1.1, Output=LINEAR
Trainingsalgorithmus: INCREMENTAL, Registry Version=v1_common_active_pv
Zufallsgenerator: Mode=2, Period=10

=== Trainingsmetriken ===

bestes Modell bei Epoche: 455 (max. 15000)
Training MSE: 0.001790
Validation MSE: 0.001659
Validation MSE Average: 0.002098
Validation MSE Standard Deviation: 0.000179
Validation Bit_Fail: 1
Model Bias: 79 Wh
Model Slope: 0.9
Trainingsbewertung: ok

=== Fehlermaße der Prognosen ===

MAE: 148.61 Wh
MedAE: 69.67 Wh
RMSE: 198.20 Wh
RMSE relative: 47 %
RMSE Rating: acceptable
MAPE: 22.74 %
MdAPE: 14.65 %
R²: 0.86

=== Rauschen ===

Rauschen Bewertung: borderline
Empfehlung für Bit_Fail: 0.34 (Einstellung von aiControl->aiConBitFailLimit)

=== Drift-Kennzahlen ===

Drift Score: -
Drift RMSE ratio: -
Drift Slope: -
Drift Bias: -
Drift Bewertung: -

#7

Solaranlagen / Aw: 76_SolarForecast - Informa...

Letzter Beitrag von grappa24 - 16 Februar 2026, 17:00:38

Ja, das ist prinzipiell eine gute Idee.
Wenn ich aber die API integriere, schließe ich damit automatisch die EV-User aus die kein EVCC betreiben. Allerdings ist der Tipp Gold wert weil es ja eine MQTT Möglichkeit gibt wie ich in der Doku gelesen habe.
D.h. jeder User mit EVCC kann sich in FHEM ein MQTT Device erstellen welches die EVCC-Topics abonniert und ggf. darüber von FHEM/SF aus auch den Ladevorgang steuern.
Dann könnte ich bei der Einbindung bei Device:Reading Kombis als universelle Lösung bleiben und niemanden ausschließen.
Oder spricht etwas aus deiner/eurer Sicht dagegen?

Als EVCC User wäre das für mich perfekt   

#8

Multimedia / Aw: Modul für Denon (Marantz) ...

Letzter Beitrag von Shadow3561 - 16 Februar 2026, 16:36:20

@olwaldi

Schau mal in mein Modul. Dort sollte es richtig laufen und keine Fehlermeldung auftauchen. Erinnere mich vage daran seinerzeit etwas geändert zu haben bzgl. der Modellabfrage. Dort gab es je nach Alter des Gerätes unterschiedliche Methoden zu Abfrage.
Mit freundlichen Grüßen

#9

Sonstige Systeme / Aw: Bresser Wetterstation 868M...

Letzter Beitrag von Ralf9 - 16 Februar 2026, 16:35:39

Hier ist auch was

https://github.com/merbanan/rtl_433/blob/master/src/devices/vevor_7in1.c
https://github.com/merbanan/rtl_433/issues/3020

Für den sduino werden für den rfmode u.a. DEVIATN und Datarate benötigt

[könnte]

#10

Solaranlagen / Aw: 76_SolarForecast - Informa...

Letzter Beitrag von DS_Starter - 16 Februar 2026, 16:33:52

Ob du eventuell nicht einfach per API (z.B. evcc-API-Schnittstelle oder MQTT etc. zugreifst, damit du nicht das Rad neu komplett erfinden musst ?

Ja, das ist prinzipiell eine gute Idee.
Wenn ich aber die API integriere, schließe ich damit automatisch die EV-User aus die kein EVCC betreiben. Allerdings ist der Tipp Gold wert weil es ja eine MQTT Möglichkeit gibt wie ich in der Doku gelesen habe.
D.h. jeder User mit EVCC kann sich in FHEM ein MQTT Device erstellen welches die EVCC-Topics abonniert und ggf. darüber von FHEM/SF aus auch den Ladevorgang steuern.
Dann könnte ich bei der Einbindung bei Device:Reading Kombis als universelle Lösung bleiben und niemanden ausschließen.
Oder spricht etwas aus deiner/eurer Sicht dagegen?

Dann ist mir auch die Passage aufgefallen:

Code Auswählen Erweitern

Automatische Erkennung

Laden mehrere Fahrzeuge an einem Ladepunkt wird beim Anstecken die automatische Erkennung genutzt. Dafür wird der Ladezustand aller konfigurierten Fahrzeuge abgefragt und das plausibelste Fahrzeug ausgewählt. Hat die Erkennung ein falsches Fahrzeug ausgewählt (bspw. weil es an einem andern Ladepunkt geladen wird), kannst du die Zuordnung manuell korrigieren.
Die machen die Fahrzeugerkennung/Zuordnung über den Batterie Ladezustand und ordnen das Fahrzeug zu welches passen könnte. Man kann es zwar manuell ändern was für uns aber suboptimal wäre, weil die Folgeaktivitäten in SF sich auf diese Angaben verlassen müssen die wie es aussieht stimmen können oder auch nicht.

wäre es evtl. denkbar und vielleicht sogar nützlich, hier folgenden anderen alten Wunsch mit einzuarbeiten?
Ich denke, es gab schonmal den Wunsch nach "untergeordneten Verbrauchern" bzw. mehrstufigen Messungen.
Bei mir bspw. gibt es einen Verbraucher "Wohnzimmer". Im Wohnzimmer steht das Aquarium, das nochmal separat gemessen wird.
Abbildbar wäre das in der flow-Grafik als zweite Ebene unter den aktuell dargestellten Verbrauchern.

Vielleicht wäre das mit Wallbox und mehreren EVs eine Sonderform davon?

Naja, hier wird die logische und die Darstellungsschicht miteinander vermischt. Bei der eindeutigen EV-Identifikation geht es im Prinzip darum im Modul immer die richtigen Grundlagen für die Prognose von Ladezeiten, Ladezielen usw. für die KI als Trainingsgrundlage zu haben um eine darauf aufbauende Prognose zu rechnen. Wenn diese Daten zwischen mehreren Ev mit unterschiedlichen Eigenschaften und Nutzungsmustern gemischt werden, wird vermutlich kein optimales Ergebnis erzielbar sein. Es geht also in erster Linie um die Aufnahme und Speicherung (möglichst) sauberer Rohdaten.