76_SolarForecast - Informationen/Ideen zu Weiterentwicklung und Support

[DS_Starter]

Neue Version ist nach weiteren Tests eingecheckt und morgen früh im Regelupdate.

LG

[DS_Starter]

Eine Kleinigkeit ist mir heute aufgefallen.

Der Key Mode wurde im consumerxx Reading 1:1 abgebildet, also statt "mode=must (can)" stand dort die Angabe aus dem Key mode=<Device>:<Reading>.
Bisher passte es auch, aber mit dem neuen Feature ist das unschön.
Das habe ich angepasst, sodass der aufgelöste Mode im Reading abgebildet wird.

Darüber hinaus wird der Mode auch in consumer Legend beim Mouse-Over über dem Icon mit ausgegeben.
Kommt heute Abend ins Repo.

LG

[DS_Starter]

Die neue V ist eingecheckt.

Im Wiki habe ich einen Absatz zur Batterieimplementierung begonnen.

LG

[Dracolein]

Ja moin zusammen, winterliche Grüße. Habe grade zufällig gesehen, dass meine PV-Vorhersagebalken leer (bzw. alle = 0) sind.
Roter Punkt oben rechts bei Solcast, mouseover: "API-Abfrage fehlgeschlagen"

Habe mich direkt bei solcast mit meinen alten Logindaten eingeloggt, dort scheint alles normal.
Folglich habe ich die letzten Seiten hier im Thread durchgelesen, ob ich Änderungen informativ verpasst habe.... ohne Befund.

Das tolle Feature zum Configuration Check - siehe Screenshot - :
Du darfst diesen Dateianhang nicht ansehen.

okay, direkt gecheckt, wenngleich ewig nichts dran geändert, siehe Screenshot 2:
 Du darfst diesen Dateianhang nicht ansehen.

Eigentlich alles da, oder nicht?

[DS_Starter]

Moin,

du müsstest die Roof Ident Pair Keys p1, p4, p3 nochmal setzen mit:

 set ... roofIdentPair ...

Steht ja auch im Check und mit der Handlungsanweisung  .
Wir hatten das schon vor kurzem mal. Da ist mir möglicherweise bei einem Update eine Umstellungsroutine mißglückt.

Du siehst die bereits definierten Paare mit:

 get ... statusApiData

[Dracolein]

einwandfrei, jetzt habe ich wieder Daten, herzlichen Dank

[DS_Starter]

Habe den Fehler in der internen Update-Routine auch gefunden. Fix checke ich heute Abend ein.
(Hat nur Bedeutung für User die noch nicht upgedated haben).

[Parallix]

Die neue V ist eingecheckt.

Im Wiki habe ich einen Absatz zur Batterieimplementierung begonnen.

Danke für die wirklich gut gelungene Doku! Nur einige wenige Begriffe sind fachlich noch nicht ganz richtig. So sollten z.B. die Readings im Abschnitt "Wie eine Batterie eingebunden wird" wie folgt umbenannt werden:
"totale Batterieladung" -> "Bis dato vorliegende Lade-Enenergiemenge"
"totale Batterieentladung"  -> "Bis dato vorliegende Entalde-Enenergiemenge"

Vor dem Hintergrund, dass es Systeme gibt, die mehrere voneinander unabhängige Batterie-Verbindungen besitzen (bei meinem GW25K-ET sind es z.B. 2), wäre es super, wenn auch solche Systeme vom Modul abgebildet werden können. Denn nur so können so wertvolle Features, wie z.B. das prognosebasierte SOC-Management, genutzt werden. Hierzu müsste im Grunde ,,nur" ermöglicht werden, mehrere BAT-Devices anlegen zu können. Das geht in der aktuellen Version leider noch nicht, oder?

[DS_Starter]

Hallo Parallix,

danke für die Hinweise. Habe ich im Wiki eingepflegt.

Vor dem Hintergrund, dass es Systeme gibt, die mehrere voneinander unabhängige Batterie-Verbindungen besitzen (bei meinem GW25K-ET sind es z.B. 2), wäre es super, wenn auch solche Systeme vom Modul abgebildet werden können. Denn nur so können so wertvolle Features, wie z.B. das prognosebasierte SOC-Management, genutzt werden. Hierzu müsste im Grunde ,,nur" ermöglicht werden, mehrere BAT-Devices anlegen zu können. Das geht in der aktuellen Version leider noch nicht, oder?

Man kann zwar momentan mit einem zusammengefassten Dummy Device arbeiten um die Batterie(n) einzubinden.
Das ist aber eine "Krücke" weil dann die spezifischen Kalkulationen das SOC-Management oder die "PV-Prognose und Verbrauch optimierte Beladungssteuerung unter Berücksichtigung einer Wirkleistungsbegrenzung" nicht für die vorhandenen (eigentlich getrennten) Batteriestacks funktionieren.

Das kann ich mit vorsehen. Ist aber eine größere Aktion, denn die Attribute und Readings sowie internen Kalk-Routinen müssen auf XX Batteriedevices umgebaut werden. Die grafische Darstellung ist dann ebenfalls aufzubohren.
Machbar ist es ähnlich wie bei den Invertern oder Producern.

LG,
Heiko

[Parallix]

...

Vor dem Hintergrund, dass es Systeme gibt, die mehrere voneinander unabhängige Batterie-Verbindungen besitzen (bei meinem GW25K-ET sind es z.B. 2), wäre es super, wenn auch solche Systeme vom Modul abgebildet werden können. Denn nur so können so wertvolle Features, wie z.B. das prognosebasierte SOC-Management, genutzt werden. Hierzu müsste im Grunde ,,nur" ermöglicht werden, mehrere BAT-Devices anlegen zu können. Das geht in der aktuellen Version leider noch nicht, oder?

Man kann zwar momentan mit einem zusammengefassten Dummy Device arbeiten um die Batterie(n) einzubinden.
Das ist aber eine "Krücke" weil dann die spezifischen Kalkulationen das SOC-Management oder die "PV-Prognose und Verbrauch optimierte Beladungssteuerung unter Berücksichtigung einer Wirkleistungsbegrenzung" nicht für die vorhandenen (eigentlich getrennten) Batteriestacks funktionieren.

Das kann ich mit vorsehen. Ist aber eine größere Aktion, denn die Attribute und Readings sowie internen Kalk-Routinen müssen auf XX Batteriedevices umgebaut werden. Die grafische Darstellung ist dann ebenfalls aufzubohren.
Machbar ist es ähnlich wie bei den Invertern oder Producern.

Danke für die gute Aussicht!

[The Grue]

[...] kann man den Consumer-Key 'mode' nun auch als Device:Reading Kombination angeben. [...]

Großartig, danke

[der-Lolo]

Hallo Heiko,
mein FHEM Update heute morgen hat mir wohl meine Solar Prognose verbogen - was muss ich tun?

[DS_Starter]

Hi,

mach einfach was in dem Check angegeben ist (wird ja als Handlungshilfe extra ausgegeben  ):

Code Auswählen Erweitern

set Prognose setupStringDeclination
wahrscheinlich kommt danach noch die Aufforderung die Ausrichtung anzugeben:

Code Auswählen Erweitern

set Prognose setupStringAzimuth


Der Neigungswinkel und die Ausrichtung der Strings wird seit Version 1.38.0 geprüft weil man OpenMeteo als unabhängigen Wetterdienst einrichten kann. Dieser Dienst braucht diese Angaben.
Wenn du aktuell keine Zeit/Lust hast, kannst du erstmal ungefähre Werte eintragen und bei Gelegenheit präzisieren.
SolCast + DWD braucht diese Werte nicht zwingend.

LG,
Heiko

[der-Lolo]

The specified inclination angle has an incorrect format

kommt nach

set Prognose setupStringDeclination

The provided module direction has wrong format

kommt nach

set Prognose setupStringAzimuth

[DS_Starter]

Welchen Wert hast du denn bei "set Prognose setupStringDeclination" mitgegeben?

Du musst natürlich bei den Befehlen Werte mitgeben wie in der Online-Hilfe dazu ausgeführt.