Neueste Beiträge

#41

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   

#42

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

#43

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]

#44

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.

#45

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

Letzter Beitrag von laserrichi - 16 Februar 2026, 16:32:42

habe dazu etwas gefunden: https://sh.com.hr/weather-station/your-vevor-7-in-1-wi-fi-weather-station-yt60234-in-weewx/

da hat jemand mit rtl_433 und FSK classic decoder

Code Auswählen Erweitern

rtl_433 -M utc -F json -Y classic -f 868.3M
Es scheint also irgendwie empfangbar zu sein.

#46

FRITZ!Box / Aw: FRITZ!Smart Energy 250

Letzter Beitrag von fred_feuerstein - 16 Februar 2026, 16:13:29

Ah danke für die Info. Also dann ist es eher als Zählerstand-Anzeige und weniger Verbrauchsanzeige nutzbar. Wenn das Interval von 1 Minute nicht heruntergesetzt werden kann.

Aktuell habe ich einen Poweropti auf der optischen Schnittstelle, der kann beliebig, auch bspw. alle 2 Sekunden, den Verbrauch/Einspeisung von der mMe melden.

#47

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

Letzter Beitrag von Bartimaus - 16 Februar 2026, 16:09:05

Mein Receiver wird bei Nichtbenutzung per Shelly vom Netz genommen. Er zieht im Standby locker 3-4W...., und auf den Komfort kann ich dank FHEM und Co locker verzichten

Ich kann mit der Meldung im Log leben, dachte die wäre für Dich vielleicht interessant

#48

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

Letzter Beitrag von olwaldi - 16 Februar 2026, 16:00:12

Dann hat Alles richtig funktioniert. Ich könnte noch den Fehlerlevel bzgl. deviceinfo.xml hochsetzen. Aber dann erfahren die, die den deviceinfoport auf 8080 setzen müssen (ich z.B., das nicht.

Man muß das dann wohl als Warnung lesen ... Wenn der Receiver dauernd an Stromnetz und Netzwerk hängt, sollte die Meldung nur 1x beim Starten von fhem kommen.

Grüßle, Michael

#49

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

Letzter Beitrag von Bartimaus - 16 Februar 2026, 15:51:20

Der Modelltyp ist in den Internals korrekt ermittelt

#50

Heizungssteuerung/Raumklima / Aw: THZ Tecalor (LWZ Stiebel E...

Letzter Beitrag von Gernertst - 16 Februar 2026, 15:49:18

Also ich habe jetzt folgende Optimierungen vorgenommen, um einen kontinuierlichen Durchfluss zu gewährleisten.

1. ich habe alle Raumventile in my Gekko so programmiert, dass die Ventile mindestens zu 25% offen bleiben

2. folgende Einstellungen direkt an der WP
  2.1 Steigung HK1 von 0,27 auf => 0,24
  2.2 Fusspunkt HK1 von 0 auf => 1Grad
  2.3 Anteil Vorlauf HK1 von 20% auf => 0%

3. und habe die Räume an meiner Regelung alle auf 24Grad gestellt

4. NE Warmwasser und NE Heizen von 1 auf => 0 gestellt

Somit müsste ich jetzt doch schonmal einen kontinuierlichen durchfluss erhalten?!
Und jetzt beobachte ich mal, wie warm die Zimmer werden und wie sich die WWasserzubereitung und das Heizen ohne Heizstab gestaltet...
Gibt es noch weitere Ansätze/ Tipps/ etc...?
Vielen Dank!!