- Willkommen im Forum „FHEM Forum“.
Neueste Beiträge
#11
Solaranlagen / Aw: 76_SolarForecast - Informa...
Letzter Beitrag von DS_Starter - 10 Mai 2026, 14:22:55Hallo Michael,
Das ist natürlich ein Grundübel und macht dir alles kaputt. Damit kann man keine Prognose oder Steuerung aufbauen. Die Werte werden abgeleitet aus:
setupMeterDev Smartmeter
gcon=Netzleistung:W
contotal=MT175_E_in:kWh
gfeedin=Einspeisung_Netz:W
feedtotal=MT175_E_out:kWh
In diesen Readings von Device Smartmeter muß enthalten sein:
contotal
Reading welches die Summe der aus dem Netz bezogenen Energie liefert (ein sich stetig erhöhender Zähler)
Wird der Zähler zu Beginn des Tages auf '0' zurückgesetzt (Tageszähler), behandelt das Modul diese Situation entsprechend.
In diesem Fall erfolgt eine Meldung im Log mit verbose 3.
feedtotal
Reading welches die Summe der in das Netz eingespeisten Energie liefert (ein sich stetig erhöhender Zähler)
Wird der Zähler zu Beginn des Tages auf '0' zurückgesetzt (Tageszähler), behandelt das Modul diese Situation entsprechend.
In diesem Fall erfolgt eine Meldung im Log mit verbose 3.
Wenn diese Vorgabe nicht eingehalten wird, kommt nichts gescheites heraus. Jetzt ist die Frage ob diese Readings
- MT175_E_in
- MT175_E_out
inhaltlich tatsächlich die Summen (In bzw. Out) der gesamten Laufzeit des Meters enthalten. Das müßtest du in deinem System verifizieren.
Auf unserer können wir die Datenlieferung verfolgen mit
ctrlDebug=collectData
Setz dir das mal. Am Besten per at-Device ein- bzw. ausschalten von 01:55 bis 02:05 und 03:55 bis 04:05. Es entstehen viele Daten etwa dieser Art:
Relevant sind diese Daten:
Daran sieht man was wann vom Meter geliefert wird.
Code Auswählen
Today_Hour02_GridConsumption: 17516200 Wh
Today_Hour04_GridFeedIn: 11315700 Wh
Das ist natürlich ein Grundübel und macht dir alles kaputt. Damit kann man keine Prognose oder Steuerung aufbauen. Die Werte werden abgeleitet aus:
setupMeterDev Smartmeter
gcon=Netzleistung:W
contotal=MT175_E_in:kWh
gfeedin=Einspeisung_Netz:W
feedtotal=MT175_E_out:kWh
In diesen Readings von Device Smartmeter muß enthalten sein:
contotal
Reading welches die Summe der aus dem Netz bezogenen Energie liefert (ein sich stetig erhöhender Zähler)
Wird der Zähler zu Beginn des Tages auf '0' zurückgesetzt (Tageszähler), behandelt das Modul diese Situation entsprechend.
In diesem Fall erfolgt eine Meldung im Log mit verbose 3.
feedtotal
Reading welches die Summe der in das Netz eingespeisten Energie liefert (ein sich stetig erhöhender Zähler)
Wird der Zähler zu Beginn des Tages auf '0' zurückgesetzt (Tageszähler), behandelt das Modul diese Situation entsprechend.
In diesem Fall erfolgt eine Meldung im Log mit verbose 3.
Wenn diese Vorgabe nicht eingehalten wird, kommt nichts gescheites heraus. Jetzt ist die Frage ob diese Readings
- MT175_E_in
- MT175_E_out
inhaltlich tatsächlich die Summen (In bzw. Out) der gesamten Laufzeit des Meters enthalten. Das müßtest du in deinem System verifizieren.
Auf unserer können wir die Datenlieferung verfolgen mit
ctrlDebug=collectData
Setz dir das mal. Am Besten per at-Device ein- bzw. ausschalten von 01:55 bis 02:05 und 03:55 bis 04:05. Es entstehen viele Daten etwa dieser Art:
Code Auswählen
2026.05.10 14:12:02.633 1: SolCast DEBUG> collect Inverter 01 data - device: STP_5000, source: pv, delivery: default =>
2026.05.10 14:12:02.634 1: SolCast DEBUG> pvOut: 4028 W, pvIn: 4052 W, AC->DC: 0 W, DC->AC: 0 W, etotal: 71913664 Wh
2026.05.10 14:12:02.635 1: SolCast DEBUG> collect Inverter 02 data - device: MQTT2_cerboGX_c0619ab34e08_solarcharger_Common, source: pv, delivery: bat =>
2026.05.10 14:12:02.635 1: SolCast DEBUG> pvOut: 1594 W, pvIn: 1594 W, AC->DC: 0 W, DC->AC: 0 W, etotal: 6143080 Wh
2026.05.10 14:12:02.636 1: SolCast DEBUG> collect Inverter 03 data - device: MQTT2_cerboGX_c0619ab34e08_vebus, source: bat, delivery: default =>
2026.05.10 14:12:02.636 1: SolCast DEBUG> pvOut: 0 W, pvIn: 0 W, AC->DC: 0 W, DC->AC: 45 W, etotal: 0 Wh
2026.05.10 14:12:02.636 1: SolCast DEBUG> summary data of all Inverters - pv: 5622 W, this hour Generation: 1045 Wh
2026.05.10 14:12:02.637 1: SolCast DEBUG> State of Plant derating: 0, info: The value of device "MQTT2_cerboGX_c0619ab34e08_solarcharger_Common", reading "Regulated" doesn't match the condition "1"
2026.05.10 14:12:02.637 1: SolCast DEBUG> currently saved 'pvrlvd' value: 1
2026.05.10 14:12:02.638 1: SolCast DEBUG> current percentage pvrl/pvapifc deviation of hod 15: 425.8 % -> pvrlvd: 1
2026.05.10 14:12:02.652 1: SolCast DEBUG> collect Energy Meter data - device: SMA_Energymeter =>
2026.05.10 14:12:02.652 1: SolCast DEBUG> gcon: 0 W, gfeedin: 3437.1 W, contotal: 1468.4 Wh, feedtotal: 9990.1 Wh
2026.05.10 14:12:02.653 1: SolCast DEBUG> write to pvHistory - day: 10, hod: 15, GridConsumption (gcons): 0 Wh
2026.05.10 14:12:02.653 1: SolCast DEBUG> collect Battery Readings data: device=MQTT2_cerboGX_c0619ab34e08_battery =>
2026.05.10 14:12:02.654 1: SolCast DEBUG> pin: 1506 W, pout: 0 W, totalin: 7910128.01605553 Wh, totalout: 7895642.85184491 Wh, soc: 89
2026.05.10 14:12:02.708 1: SolCast DEBUG> EnergyConsumption input -> PV: 1035 Wh, PP: 0 Wh, GridIn: 660 Wh, GridCon: 0 Wh, BatIn: 286 Wh, BatOut: 0 Wh
2026.05.10 14:12:02.709 1: SolCast DEBUG> EnergyConsumption result -> 89 Wh
2026.05.10 14:12:02.711 1: SolCast DEBUG> current Power values -> PV2Node: 4028 W, PV2Bat: 1594, PV2Grid: 0 W, Other: 0 W, GridIn: 3437 W, GridCon: 0 W
2026.05.10 14:12:02.711 1: SolCast DEBUG> current Power Battery -> BatIn: 1506 W (Node2Inv2DC: 0 W), BatOut: 0 W (DC2Inv2Node: 45 W)
Relevant sind diese Daten:
Code Auswählen
2026.05.10 14:12:02.652 1: SolCast DEBUG> collect Energy Meter data - device: SMA_Energymeter =>
2026.05.10 14:12:02.652 1: SolCast DEBUG> gcon: 0 W, gfeedin: 3437.1 W, contotal: 1468.4 Wh, feedtotal: 9990.1 Wh
2026.05.10 14:12:02.653 1: SolCast DEBUG> write to pvHistory - day: 10, hod: 15, GridConsumption (gcons): 0 Wh
Daran sieht man was wann vom Meter geliefert wird.
#12
Solaranlagen / Aw: Einbindung eines Sungrow S...
Letzter Beitrag von toron_go - 10 Mai 2026, 13:21:47Zitat von: tobmaster1985 am 10 Mai 2026, 12:41:49Welchen "Trick" suchst du?
Viele gute Frage aber wie schon gesagt bei ModBus bin ich scheinbar raus.
Also ich habe die
H13049 H13050 H13051 aber was du mit Revregs und unpack richtig gesetzt meinst 8-/
VG Toron
#13
Solaranlagen / Aw: Einbindung eines Sungrow S...
Letzter Beitrag von toron_go - 10 Mai 2026, 13:08:18Zwangsentladung in Netzt:
1. Den Schalter (Dummy) anlegen
Zuerst erstellen wir einen virtuellen Schalter, mit dem du die Entladung manuell oder per Zeitplan triggern kannst.
define SH06rt_Zwangsentladung dummy
attr SH06rt_Zwangsentladung alias Batterie Zwangsentladung ins Netz
attr SH06rt_Zwangsentladung devStateIcon on:general_aus:off off:general_an:on
attr SH06rt_Zwangsentladung room PV
attr SH06rt_Zwangsentladung setList on off
2. Das DOIF für die Steuerung
Dieser Code überwacht den Dummy und sendet die entsprechenden Modbus-Befehle an deinen Wechselrichter (SH06rt_Fast).
define di_SH06rt_Entladesteuerung DOIF ([SH06rt_Zwangsentladung] eq "on")
(set SH06rt_Fast EMS_mode_selection 2,
set SH06rt_Fast Charge_Discharge_command 187,
set SH06rt_Fast Charge_Discharge_power 5000)
DOELSE
(set SH06rt_Fast EMS_mode_selection 0,
set SH06rt_Fast Charge_Discharge_command 204,
set SH06rt_Fast Charge_Discharge_power 0)
attr di_SH06rt_Entladesteuerung alias Logik Zwangsentladung
attr di_SH06rt_Entladesteuerung room PV
attr di_SH06rt_Entladesteuerung wait 0:0
Getest und geht.
VG
1. Den Schalter (Dummy) anlegen
Zuerst erstellen wir einen virtuellen Schalter, mit dem du die Entladung manuell oder per Zeitplan triggern kannst.
define SH06rt_Zwangsentladung dummy
attr SH06rt_Zwangsentladung alias Batterie Zwangsentladung ins Netz
attr SH06rt_Zwangsentladung devStateIcon on:general_aus:off off:general_an:on
attr SH06rt_Zwangsentladung room PV
attr SH06rt_Zwangsentladung setList on off
2. Das DOIF für die Steuerung
Dieser Code überwacht den Dummy und sendet die entsprechenden Modbus-Befehle an deinen Wechselrichter (SH06rt_Fast).
define di_SH06rt_Entladesteuerung DOIF ([SH06rt_Zwangsentladung] eq "on")
(set SH06rt_Fast EMS_mode_selection 2,
set SH06rt_Fast Charge_Discharge_command 187,
set SH06rt_Fast Charge_Discharge_power 5000)
DOELSE
(set SH06rt_Fast EMS_mode_selection 0,
set SH06rt_Fast Charge_Discharge_command 204,
set SH06rt_Fast Charge_Discharge_power 0)
attr di_SH06rt_Entladesteuerung alias Logik Zwangsentladung
attr di_SH06rt_Entladesteuerung room PV
attr di_SH06rt_Entladesteuerung wait 0:0
Getest und geht.
VG
#14
Solaranlagen / Aw: Einbindung eines Sungrow S...
Letzter Beitrag von tobmaster1985 - 10 Mai 2026, 12:41:49Welchen "Trick" suchst du?
Das zwangsweise Laden/Entladen funktioniert auch ohne Sonne.
H13049 auf 2 setzen
H13050 auf 170 setzen zum Laden, 187 für Entladen
H13051 Leistung in W
Auf I05213 kann man den S32 Wert für die Batterieleistung auslesen.
Von allen Adressen aus der Sungrow Modbus Protokollbeschreibung muss 1 subtrahiert werden.
Die Adressen oben sind schon passend für die Abfrage mit Modbusattr.
Sind Revregs und unpack richtig gesetzt?
#15
Solaranlagen / Aw: 76_SolarForecast - Informa...
Letzter Beitrag von Mikel2906 - 10 Mai 2026, 12:21:09Hallo Heiko,
danke für deine Hilfe und das super Projekt. Ich benutze die aktuelle Version 2.6.5.
Zur meiner Person: Ich benutze FHEM schon seit mehreren Jahren, programmieren kann ich ein wenig und komme klar
Die Ausreißer der Variablen treten immer von 1 Uhr nachts und 4 Uhr morgens auf. Das sind die Werte die am Stromzähler angezeigt werden.
Beispiele:
Today_Hour02_GridConsumption: 17516200 Wh
Today_Hour04_GridFeedIn: 11315700 Wh
Das Skript für die Ladesteuerung funktioniert nur, wie bereits beschrieben, bleibt der Wert bei 3000 stehen.
Das Skript für die Ladesteuerung ist im Anhang.
Viele Grüße
Michael
danke für deine Hilfe und das super Projekt. Ich benutze die aktuelle Version 2.6.5.
Zur meiner Person: Ich benutze FHEM schon seit mehreren Jahren, programmieren kann ich ein wenig und komme klar
Die Ausreißer der Variablen treten immer von 1 Uhr nachts und 4 Uhr morgens auf. Das sind die Werte die am Stromzähler angezeigt werden.
Beispiele:
Today_Hour02_GridConsumption: 17516200 Wh
Today_Hour04_GridFeedIn: 11315700 Wh
Das Skript für die Ladesteuerung funktioniert nur, wie bereits beschrieben, bleibt der Wert bei 3000 stehen.
Das Skript für die Ladesteuerung ist im Anhang.
Viele Grüße
Michael
#16
Solaranlagen / Aw: Einbindung eines Sungrow S...
Letzter Beitrag von toron_go - 10 Mai 2026, 12:18:26Leider hier keine Reaktionen mehr
Wird wohl doch Zeit das System zu wechseln.
VG Toron
Wird wohl doch Zeit das System zu wechseln.
VG Toron
#17
FHEM Code changes / Revision 31201: 76_SolarForeca...
Letzter Beitrag von System - 10 Mai 2026, 12:11:16Revision 31201: 76_SolarForecast: contrib Version 2.6.8
76_SolarForecast: contrib Version 2.6.8
Source: Revision 31201: 76_SolarForecast: contrib Version 2.6.8
76_SolarForecast: contrib Version 2.6.8
Source: Revision 31201: 76_SolarForecast: contrib Version 2.6.8
#18
Solaranlagen / Aw: 76_SolarForecast - Informa...
Letzter Beitrag von DS_Starter - 10 Mai 2026, 11:58:06@all,
nach den vielen Diskussionen um die letzten Systemanpassungen verliert man leicht den Überblick.
Hier nun eine kurze Zusammenfassung was alles seit dem letzten Check-In der V 2.6.5 passiert ist.
Mit der V 2.6.6 bis 2.6.7 kommen folgende Fixes und Änderungen ins System.
Consumersteuerung:
- pro SF-Zyklus wird ein PV-Überschußbudget geführt, aus welchem sich die Verbraucher beim Einschaltvorgang bedienen.
Ist er aufgebraucht, wird kein Verbraucher im laufenden Zyklus mehr eingeschaltet und wird erst im nächsten wieder geprüft.
Das Verfahren verhindert "Toggling" von Verbrauchern weil im nächsten Zyklus PV-Überschuß überzogen wurde und Verbraucher
deshalb wieder abgeschaltet werden
- neuer Schlüssel swprio zur Prioritätssteuerung von Consumern
Flußgrafik:
- Bugfix der Entladeflüsse bei mehreren vorhandenen Batterien und unterschiedlicher WR-Architektur (Forum: https://forum.fhem.de/index.php?msg=1363211)
Der Einsatz der Consumer-Priorität kann nun dazu führen, dass can-Consumer im ungünstigsten Fall den ganzen Tag nicht
gestartet werden können wenn höher priorisierte Consumer das Budget aufbrauchen.
NEU: Mit der V 2.6.8 kommt nun eine erweiterte Form des Planungsprozesses von "can"-Consumern zum Einsatz.
- Vorprozess summiert für jede Stunde (hod) die bereits verplante pvpow aller anderen Consumer anhand ihrer ehodpieces.
Consumer ohne ehodpieces oder ohne pvpow werden übersprungen.
- die Auswahl des Planungsfensters prüft jetzt das Ergebnis des Vorprozesses statt direkt.
Ein Fenster das durch andere Consumer bereits ausgelastet ist wird übersprungen, und der Consumer wandert automatisch in
das nächste freie Fenster.
- swprio-Sortierung in greift weiterhin – höher priorisierte Consumer werden zuerst geplant und belegen die besten Fenster.
Niedriger priorisierte Consumer weichen automatisch aus.
- must-Consumer bleiben unberührt – sie ignorieren die Belegung und planen um den Peak.
Die V 2.6.8 habe ich ins contrib geladen.
LG,
Heiko
nach den vielen Diskussionen um die letzten Systemanpassungen verliert man leicht den Überblick.
Hier nun eine kurze Zusammenfassung was alles seit dem letzten Check-In der V 2.6.5 passiert ist.
Mit der V 2.6.6 bis 2.6.7 kommen folgende Fixes und Änderungen ins System.
Consumersteuerung:
- pro SF-Zyklus wird ein PV-Überschußbudget geführt, aus welchem sich die Verbraucher beim Einschaltvorgang bedienen.
Ist er aufgebraucht, wird kein Verbraucher im laufenden Zyklus mehr eingeschaltet und wird erst im nächsten wieder geprüft.
Das Verfahren verhindert "Toggling" von Verbrauchern weil im nächsten Zyklus PV-Überschuß überzogen wurde und Verbraucher
deshalb wieder abgeschaltet werden
- neuer Schlüssel swprio zur Prioritätssteuerung von Consumern
Flußgrafik:
- Bugfix der Entladeflüsse bei mehreren vorhandenen Batterien und unterschiedlicher WR-Architektur (Forum: https://forum.fhem.de/index.php?msg=1363211)
Der Einsatz der Consumer-Priorität kann nun dazu führen, dass can-Consumer im ungünstigsten Fall den ganzen Tag nicht
gestartet werden können wenn höher priorisierte Consumer das Budget aufbrauchen.
NEU: Mit der V 2.6.8 kommt nun eine erweiterte Form des Planungsprozesses von "can"-Consumern zum Einsatz.
- Vorprozess summiert für jede Stunde (hod) die bereits verplante pvpow aller anderen Consumer anhand ihrer ehodpieces.
Consumer ohne ehodpieces oder ohne pvpow werden übersprungen.
- die Auswahl des Planungsfensters prüft jetzt das Ergebnis des Vorprozesses statt direkt.
Ein Fenster das durch andere Consumer bereits ausgelastet ist wird übersprungen, und der Consumer wandert automatisch in
das nächste freie Fenster.
- swprio-Sortierung in greift weiterhin – höher priorisierte Consumer werden zuerst geplant und belegen die besten Fenster.
Niedriger priorisierte Consumer weichen automatisch aus.
- must-Consumer bleiben unberührt – sie ignorieren die Belegung und planen um den Peak.
Die V 2.6.8 habe ich ins contrib geladen.
LG,
Heiko
#19
Solaranlagen / Aw: 76_SolarForecast - Informa...
Letzter Beitrag von DS_Starter - 10 Mai 2026, 11:52:39Hallo Mikel2906,
willkommen bei SolarForecast. Ich habe gesehen dass du dich heute erst registriert hast.
Nun weiß ich nicht wieviel Vorkenntnisse bzgl. FHEM vorhanden sind weil nun einige Dinge besprochen werden müssen.
Zunächst sind die von dir beschriebenen Sachverhalte:
a) GridConsumption und GridFeedIn nachts gleichzeitig Ausreißer
b) Ladesteuerung über die Variable Battery_ChargeOptTargetPower_01 funktioniert ebenfalls nicht
zwei völlig getrennte Dinge. Die Ladesteuerung ist komplexer, da du (der User) hier eigenen Code verwenden muß um die vorgeschlagene Ladeleistung im Reading! Battery_ChargeOptTargetPower_01 (nicht Variable) in seinem spezifischen Batteriesystem umzusetzen.
Deswegen schlage ich vor zunächst Punkt a) zu betrachten. Nun sind die Fragen
- welche SF-Version setzt du ein? (steht in der GUI oben im Kopf)
- was heißt "GridConsumption und GridFeedIn nachts gleichzeitig Ausreißer" konkret?
- meinst du die Readings Current_GridConsumption bzw. Current_GridFeedIn?
- meinst du die Readings Today_HourXX_GridConsumption bzw. Today_HourXX_GridFeedIn?
Bitte beschreibe genauer was wir uns unter den Ausreißern vorstellen dürfen.
LG,
Heiko
willkommen bei SolarForecast. Ich habe gesehen dass du dich heute erst registriert hast.
Nun weiß ich nicht wieviel Vorkenntnisse bzgl. FHEM vorhanden sind weil nun einige Dinge besprochen werden müssen.
Zunächst sind die von dir beschriebenen Sachverhalte:
a) GridConsumption und GridFeedIn nachts gleichzeitig Ausreißer
b) Ladesteuerung über die Variable Battery_ChargeOptTargetPower_01 funktioniert ebenfalls nicht
zwei völlig getrennte Dinge. Die Ladesteuerung ist komplexer, da du (der User) hier eigenen Code verwenden muß um die vorgeschlagene Ladeleistung im Reading! Battery_ChargeOptTargetPower_01 (nicht Variable) in seinem spezifischen Batteriesystem umzusetzen.
Deswegen schlage ich vor zunächst Punkt a) zu betrachten. Nun sind die Fragen
- welche SF-Version setzt du ein? (steht in der GUI oben im Kopf)
- was heißt "GridConsumption und GridFeedIn nachts gleichzeitig Ausreißer" konkret?
- meinst du die Readings Current_GridConsumption bzw. Current_GridFeedIn?
- meinst du die Readings Today_HourXX_GridConsumption bzw. Today_HourXX_GridFeedIn?
Bitte beschreibe genauer was wir uns unter den Ausreißern vorstellen dürfen.
LG,
Heiko
#20
Bastelecke / Aw: unbekanntes Funkprotokoll ...
Letzter Beitrag von Ralf9 - 10 Mai 2026, 11:32:19Zitat von: DerD am 09 Mai 2026, 10:22:400x1D AGCCTRL0 - 0x90 ist erklärbar, hatte ich manuell auf 4db gesetzt um es empfindlich zu machen. Jetzt steht es wieder auf 8dB mit dem Ergebnis 0x1D AGCCTRL0 - 0x91 (90). Hat aber keinen offensichtlichen Einfluß auf die Erkennung bei mir, auch nicht bei Maximalwert 16db.0x1D AGCCTRL0 hat bei FSK eine andere Bedeutung als bei ASK/OOK
Zitat von: DerD am 09 Mai 2026, 10:22:40Das bei 0x1B AGCCTRL2 - 0x07 kann ich nicht erklären. cc1101_rAmpl steht auf 42dB (gewollt) und damit 0x07, das entspräche laut Datenblatt ja der Grundeinstellung (00000011) plus eben 42dB also 00000111 (0x07)Hast Du auch mal die 0x43 getestet ob es beim Empfang einen Unterschied macht?
0x43 stände für "The highest gain setting can not be used" und 33db. Das kann ich manuell über die settings so gar nicht vergeben, nur per raw definition vermutlich.
Zitat von: DerD am 09 Mai 2026, 10:22:40Dann vielleicht mal ein Schritt zurück: ich hatte als Basis rfmode den hier ausgewählt "HoneywActivL__SlowRf_FSK" und basierend darauf Frequenz, Deviation angepasst. Möglicherweise sollte ich von einer anderen Basis ausgehen? So wie ich das im SDR sehe, sind die Pulszeiten für SL/SH und LL/LH nämlich jeweils ziemlich gleich. Sprich es könnten die Einstellungen des CC1101 sein die nicht passen. Hast du einen Tipp was da zu empfehlen ist? Ich habe ja auch keinen anderen FSK-Sender mit dem ich testen könnte ob es da anders ist.Ich hab mir mal die Unterschiede zu den FSK rfmodes angeschaut.
Die rfmodes stehen am Anfang der signalduino_protocols.pm und können einfach miteinander verglichen werden.
0x12 MDMCFG2, wenn das sync-word bekannt ist, kannst Du auch mal 02 und 06 testen
0x14 MDMCFG0, bei den anderen rfmode wird 0xF8 verwendet
0x19 FOCCFG, bei FSK 0x16
0x1C AGCCTRL1, bei FSK 0x68 oder 0x40