76_SolarForecast - Informationen/Ideen zu Weiterentwicklung und Support

[MartinD]

@Gerd

In der Version 3.2 (Juni 2025) steht was von len=2 und uint32.

Im Modulhilfe steht:

Code Auswählen Erweitern

For an unsigned integer in big endian format this would be "n",
for a signed 16 bit integer in big endian format this would be "s>", in little endian format it would be "s<"
and for a 32 bit big endian float value this would be e.g. "f>". (see the perl documentation of the pack function for more codes and details).
Please note that you also have to set a -len attribute (for this object or for the device) if you specify an unpack code that consumes data from more than one register.
For a 32 bit float e.g. len should be 2.

Ich habe versucht

Code Auswählen Erweitern

obj-h40226-len 2
obj-h40226-unpack f>

was aber auch falsche Werte zurückgibt.
Und nun stehe ich da, und weiß nicht weiter.

Gruß
Martin

[DS_Starter]

@Hadl,

Der Leistungssprung zum Stundenwechsel ist meistens ca. 20%, kann das der safety margin sein, den er innerhalb der Stunde wieder aufbrauchen will wenn die Leistung ausreichend war?
Welche Logik ist dafür die Ursache?

Es wird in der aktuell laufenden Stunde ein Vergleich zwischen dem PV-Überschuß, der eingestellten Ladeleistung und dem Durchschnitt der noch prognostizierten Mindestladeleistungen vorgenommen.
Näheres hatte ich in https://forum.fhem.de/index.php?msg=1347884 erläutert.

Du kannst natürlich den Standard saftyMargin auf 0 setzen wie Parallix es getan hat und das Resultat beobachten.

[Wolle02]

Das ist doch völlig in Ordnung wenn man mit dieser Konfiguration klar kommt und sein Ziel erreicht. Wenn eure Anlage gut abgebildet wird muß man sich keinen weiteren Stress machen.

Manchmal reicht es eben nicht aus. Ein Hybridinverter vereint nunmal einen PV-Wechselrichter und einen Batterie-Wechselrichter in einem Gerät. Da es im Modul aber keinen solchen Typ nativ gibt, kann man den Umweg mit einem zusätzlichen (im Prinzip virtuellen) Batterie-Wechselrichter gehen. Das ist alles.

Das sollte natürlich keine Kritik an Dir und insbesondere an Deiner Arbeit sein (die ich an dieser Stelle nochmal deutlich würdigen möchte). Manchmal verstehe ich Dinge auch einfach nicht so Recht 

[DS_Starter]

Alles gut, hatte ich auch nicht so aufgefasst. 
Manchmal weiß ich nur nicht so recht wie ich die Vorgehensweisen noch besser darlegen/beschreiben soll.

[Parallix]

...
Ich habe versucht

Code Auswählen Erweitern

obj-h40226-len 2
obj-h40226-unpack f>

was aber auch falsche Werte zurückgibt.
Und nun stehe ich da, und weiß nicht weiter.
...

Bitte mal die Doku gucken, ob ein System mit "big endian" oder "litte endian" vorliegt! Da es ja lt. Doku definitiv ein Ganzzahlwert und kein Gleitkommawert ist, ist "f" sicher nicht richtig!

[MartinD]

@Parallix

es ist wohl Big-Endian.

Code Auswählen Erweitern

Modbus registers store data in Big-Endian format. Most-significant values are stored
first, at the lowest storage address

uint32 ist doch 32 bit, oder?

[MartinD]

Ich habe die Adressen mit Modbus Poll gescannt.
Komme aber auch nicht weiter.

Gruß
Martin

[MartinD]

@all:
Sorry, ich versuche den Thread nicht zu kapern.
Habe schon  hier erfolglos versucht.
Weiß nicht wo ich meine Fragen sonst stellen kann.

Gruß
Martin

[Hadl]

Es wird in der aktuell laufenden Stunde ein Vergleich zwischen dem PV-Überschuß, der eingestellten Ladeleistung und dem Durchschnitt der noch prognostizierten Mindestladeleistungen vorgenommen.
Näheres hatte ich in https://forum.fhem.de/index.php?msg=1347884 erläutert.

Hallo Heiko, ich habs mir nochmal durchgelesen und mit dem debug log verglichen. Ich glaube ich habe gefunden woher die Sprünge kommen.
Siehe Log im Anhang

Die "sum need" verändert sich teilweise relativ linear, dann bleibt sie aber auch mal wieder bei einem glatten Wert "hängen".
Die großen Sprünge kommen aber immer dann wenn sich die "number hrs" ändert. Hier sollte man evtl. mal schauen ob es nicht an den Ganzzahlen der Stunden liegt.


2025.09.15 11:59:49 1: PV_SolarForecast DEBUG> ChargeOTP - max OTP Bat 01: 651 W, sum need: 3255 Wh, number hrs: 5, average: 651 W
2025.09.15 12:00:05 1: PV_SolarForecast DEBUG> ChargeOTP - max OTP Bat 01: 813 W, sum need: 3410 Wh, number hrs: 6, average: 568 W
2025.09.15 12:00:08 1: PV_SolarForecast DEBUG> ChargeOTP - max OTP Bat 01: 813 W, sum need: 3752 Wh, number hrs: 5, average: 750 W

Aber auch die "sum need" und die "average" machen große Sprünge in den wenigen Sekunden

[Parallix]

@Parallix

es ist wohl Big-Endian.

Code Auswählen Erweitern

Modbus registers store data in Big-Endian format. Most-significant values are stored
first, at the lowest storage address

uint32 ist doch 32 bit, oder?

Ja, aber bitte gebe künftig doch etwas mehr an Hintergrundinfo an, gerne auch dauerhaft via Signatur. Stammt die Zeile, die Du oben zitierst aus der Modbus-Beschreibung Deines Wechselrichters oder von irgendwo anders her? Ich gehe mal von ersterem aus: Dann läge in er Tat ein nicht vorzeichenbehafteter 32-bit Ganzzahlwert im "big endian"-Format vor und du kannst z.B. folgendes in Deine ModbusAttr schreiben

Code Auswählen Erweitern

dev-type-U32-len 2
dev-type-U32-unpack L>und dann weiter unten z.B.

Code Auswählen Erweitern

obj-h40226-type U32
obj-h40226-poll 2
obj-h40226-reading <NameOfYourReading>


[DS_Starter]

@Hadl,

du hast vermutlich nicht die aktuelle Version im Einsatz. Der Logaufbau sieht aktuell so aus:

Code Auswählen Erweitern

2025.09.15 14:54:25.143 1: SolCast DEBUG> ChargeOTP - max OTP Bat 01: 3082 W, sum need: 5380 Wh, number hrs: 4, average: 1345 W
2025.09.15 14:54:25.143 1: SolCast DEBUG> ChargeOTP - The limit for grid feed-in is 4800 W
2025.09.15 14:54:25.143 1: SolCast DEBUG> ChargeOTP - NOTE: The hours listed below are the estimated number of hours remaining on the current day with at least the respective PV surplus.
2025.09.15 14:54:25.144 1: SolCast DEBUG> Bat 01 ChargeOTP - hod: 15, Start SoC: 18755 Wh, Surplus: 450 Wh (3 hrs), OTP: 1345 W, safety: 20 %
2025.09.15 14:54:25.144 1: SolCast DEBUG> Bat 01 ChargeOTP - hod: 16, Start SoC: 19205 Wh, Surplus: 827 Wh (2 hrs), OTP: 827 W, safety: 20 %
2025.09.15 14:54:25.144 1: SolCast DEBUG> Bat 01 ChargeOTP - hod: 17, Start SoC: 20032 Wh, Surplus: 3082 Wh (1 hrs), OTP: 3082 W, safety: 20 %
2025.09.15 14:54:25.145 1: SolCast DEBUG> Bat 01 ChargeOTP - hod: 18, Start SoC: 23597 Wh, Surplus: 1021 Wh (1 hrs), OTP: 1021 W, safety: 20 %
2025.09.15 14:54:25.145 1: SolCast DEBUG> Bat 01 ChargeOTP - hod: 19, Start SoC: - Wh, Surplus: 0 Wh , OTP: 600 W, safety: 20 %
2025.09.15 14:54:25.145 1: SolCast DEBUG> Bat 01 ChargeOTP - hod: 20, Start SoC: - Wh, Surplus: 0 Wh , OTP: 600 W, safety: 20 %
2025.09.15 14:54:25.146 1: SolCast DEBUG> Bat 01 ChargeOTP - hod: 21, Start SoC: - Wh, Surplus: 0 Wh , OTP: 600 W, safety: 20 %
2025.09.15 14:54:25.146 1: SolCast DEBUG> Bat 01 ChargeOTP - hod: 22, Start SoC: - Wh, Surplus: 0 Wh , OTP: 600 W, safety: 20 %
2025.09.15 14:54:25.146 1: SolCast DEBUG> Bat 01 ChargeOTP - hod: 23, Start SoC: - Wh, Surplus: 0 Wh , OTP: 600 W, safety: 20 %
2025.09.15 14:54:25.147 1: SolCast DEBUG> Bat 01 ChargeOTP - hod: 24, Start SoC: - Wh, Surplus: 0 Wh , OTP: 600 W, safety: 20 %


Aber auch die "sum need" und die "average" machen große Sprünge in den wenigen Sekunden

Da liegt sicherlich ein Mißverständnis in der Interpretation vor.
Die Angaben werden auf Stundenbasis ausgeschrieben.

[MartinD]

@Parallix
Danke!

Die Zitierte Zeile stammt aus SE-SunSpec die ich hier angehängt habe. 

Code Auswählen Erweitern

attr obj-h40226-unpack
kann ich dann wohl löschen oder?

[Max_Meyer]

Ja, aber bitte gebe künftig doch etwas mehr an Hintergrundinfo an, gerne auch dauerhaft via Signatur. Stammt die Zeile, die Du oben zitierst aus der Modbus-Beschreibung Deines Wechselrichters oder von irgendwo anders her? Ich gehe mal von ersterem aus: Dann läge in er Tat ein nicht vorzeichenbehafteter 32-bit Ganzzahlwert im "big endian"-Format vor und du kannst z.B. folgendes in Deine ModbusAttr schreiben
Code Auswählen Erweitern

Code Auswählen Erweitern

dev-type-U32-len 2
dev-type-U32-unpack L>und dann weiter unten z.B.
Code Auswählen Erweitern

Code Auswählen Erweitern

obj-h40226-type U32
obj-h40226-poll 2
obj-h40226-reading <NameOfYourReading>

Hallo Parallix Hallo MartinD,

ich würde nicht hxxxx (Holding-Register) nutzen - die sind üblicherweise zum setzen von Werten vorgesehen
                ixxxx wäre m.A.n. die bessere Wahl
U --> bedeudet unsigned  damit ist L  (an unsigned long value.) der richtige code aber die Typangabe geht natürlich auch (meistens)
wenn  die in der Doku genannten Datentypen passen sollten auch die richtigen Werte kommen
ggfls noch formatieren:
obj-i30597-format %.1f
ich würde auch den Datentyp nicht global - wie oben vorgeschlagen - sondern für jedes Register separat festlegen - da auch 16 Bit Register vorhanden sind
Die in Topic #4014 angehangene SPEC hatte fast ausschließlich  16Bit MBR
Welche SPEC passt denn zu deinem WR die aus #4014? oder #4035
 
Wie Parallix schon schrieb - bisschen mehr Content wäre hilfreich
Gruß Gerd

[MartinD]

@Parallix,

Das Reading ist aber immer noch nicht mit Monitoring von SE konform.

Woran könnte es liegen?

Gruß
Martin

[klaus.schauer]

Im Wiki bin ich auf ein Beispiel mit Dummy Wechselrichtern und Batterien gestoßen. M. E. wäre das - wenn das die Lösung sein sollte - aber aufwändig und unübersichtlich.
- Wäre es nicht sinnvoller, für den Wechselrichtertyp "PV-Inverter" zusätzliche Energiepfade für Solarspeicher (batIn, batOut) einzuführen? Hierbei wäre aber zu beachten, dass der Pfad "pvOut" auch negative Werte erlauben müsste. In meiner Konstellation nimmt der Hybridwechselrichter zur Ladung des Solarspeichers - gesteuert durch den HM 2.0 - auch Energie vom zweiten Wechselrichter oder Netz auf.

habe die gleiche Kombination - meine Lösung dazu sieht so aus

Danke für die Hilfestellung. Die Wertepaare hatte ich so schon eingetragen. Leider sind die Energieflüsse nicht richtig, sobald die Batterie ins Spiel kommt.
Ich habe jetzt wie empfohlen auch noch einen Batteriewechselrichter hinzugefügt.

Code Auswählen Erweitern

setupInverterDev01: wr4136601s strings=south capacity=10000 pvIn=SPOT_PDC_SUM:W pvOut=SPOT_PACTOT:W etotal=SPOT_EPVTOTAL:Wh asynchron=1
setupInverterDev02: wr4136602s strings=east capacity=3000 pvIn=SPOT_PDC_SUM:W pvOut=SPOT_PACTOT:W etotal=SPOT_ETOTAL:Wh asynchron=1
setupInverterDev03: wr4136601s strings=none capacity=10000 ac2dc=BAT_P_CHARGE:W dc2ac=BAT_P_DISCHARGE:W asynchron=1
setupBatteryDev01: wr4136601s pin=BAT_P_CHARGE:W pout=BAT_P_DISCHARGE:W pinmax=10000 poutmax:10000 intotal=BAT_LOADTOTAL:Wh outtotal=BAT_UNLOADTOTAL:W cap=19300 charge=ChargeStatus asynchron=1 show=1:bottom
setupMeterDev: wr4136601s gcon=Meter_Power_Grid_Consumation:W contotal=Meter_TOTAL_Grid_Consumation:Wh gfeedin=Meter_Power_Grid_FeedIn:W feedtotal=Meter_TOTAL_Grid_FeedIn:Wh asynchron=1
Das ändert aber nichts an den fehlerhaften Energieflüssen, siehe Beispieldiagramm. Die von der Batterie gelieferte Leistung von 561 W wird nochmals beim Hybridwechselrichter 01 als Solarertrag erfasst. Noch komplexer wird es, sobald der Wechselrichter 02 Energie in den Wechselrichter 01 zum Laden der Batterie einspeist.

Ich finde in der Anleitung "nur" die Definitionen eines Wechselrichters und eines Solarspeichers. Meine Konfiguration besteht aus
- SMA STP10.0SE (SUNNY TRIPOWER 10.0 SE) mit angeschlossenem Solarspeicher
- SMA STP3.0-3AV-40 (Sunny Tripower 3.0)
- SMA Homemanager 2.0

Daraus ergibt sich die Besonderheit, dass der Pfad "pvOut=SPOT_PACTOT" des Wechselrichters 01 auch negative Werte annehmen kann. Der Hybridwechselrichter nimmt zur Ladung des Solarspeichers - gesteuert durch den HM 2.0 - auch Energie vom zweiten Wechselrichter oder Netz auf. Dies ist aber derzeit nicht vorgesehen. Wie wird dies bei Dir gelöst?
 
Falls Du für diese Konstellation schon eine lauffähige Lösung hast, wäre ich an der Gesamtkonfiguration sehr interessiert.