76_SolarForecast - Informationen/Ideen zu Weiterentwicklung und Support

[DS_Starter]

Vorsicht, es ging nur um den hinteren Teil mit "PowerBatOut" und "BatOut" in konsistent "BatPowerOut": <Device><Type><Direction>.
Du hast es ja schon selber richtig geschrieben

Ah ok, verstehe 

Ja Model (SolCastAPI), in dem Hinweistext steht aber mehr "Modul"

Hilf mir mal bitte, wo? Hab Tomaten auf den Augen und sehe es nicht.
Einen Hinweislink baue ich gern zum Wiki ein wenn ich einen passenden Abschnitt erstellt habe.
Muß nur daran denken.    Gerne mal erinnern.

Es ist aber unglücklich, auf nicht offizielle Contribs zu verweisen. Typisches FOSS Problem mit der Maintenance

Bin ich auch nicht glücklich damit und hätte auch nie gedacht, dass es sich so zieht, zumal es fertig ist und nur noch eingecheckt werden muß.  Jens hatte seinerzeit auf meine Nachfrage hin versichert er kümmert sich wieder darum. Das ist aber auch schon wieder Monate her.
Zwischenzeitlich hatte ich auch schon daran gedacht die relevanten Parts direkt ins Modul zu holen. Dann bräuchte es kein externes Device mehr.

Es ist aber ein gutes Beispiel dafür was passieren kann wenn man Funktionen "aufspaltet". Die Diskussion hatten wir schon öfter. Das macht dann u.U. keinen Spaß mehr und hindert mehr als es nutzt.

LG

[minierm]

Ja Model (SolCastAPI), in dem Hinweistext steht aber mehr "Modul"

Hilf mir mal bitte, wo? Hab Tomaten auf den Augen und sehe es nicht.
Einen Hinweislink baue ich gern zum Wiki ein wenn ich einen passenden Abschnitt erstellt habe.
Muß nur daran denken.    Gerne mal erinnern.

Ich meinte nur: Man (ich) sieht das Model vor lauter Modulen nicht "Module" ist irgendwie hängen geblieben.

The selected SolarForecast Model cannot use AI support.
Your local 76_SolarForecast module is up to date.
checked module:

[DS_Starter]

Hallo zusammen,

in meinem contrib liegt die Version 1.42.0.

Was ist neu bzw. umgesetzt:

- es können mit den Attributen setupBatteryDevXX  bis zu 3 Batteriegeräte definiert werden.
- für die Optimierung der Bats gibt es ctrlBatSocManagement01 - 03
- die Batterien bzw. deren Ladungsempfehlungs-Status für die kommenden Stunden können in der
  Balkengrafik Ebene 1 eingeblendet werden. Ein Mouse-Over zeigt nähere Informationen zum Batteriestatus.

- Zur grafischen Steuerung der Batterien gibt es nun zusätzliche optionale Schlüssel und den setupBatteryDevXX Attributen

icon=<inaktiv>[@<Farbe>][:<aufladen>[@<Farbe>]][:<entladen>[@<Farbe>]]]
icon    Icon zur Darstellung der Batterie in der Balkengrafik (optional)
    <inaktiv> - Icon und ggf. Farbe bei Inaktivität (kein Aufladen oder Entladen)
    <aufladen> - Icon und ggf. Farbe wenn die Batterie aufgeladen wird
    <entladen> - Icon und ggf. Farbe wenn die Batterie entladen wird

[show=<Option>]
show    Steuerung der Anzeige der Batterie in der Balkengrafik (optional)
    0 - keine Anzeige des Gerätes (default)
    1 - Anzeige des Gerätes

zum Beispiel:
show=1
icon=measure_battery_50@grey:measure_battery_100@green:measure_battery_100@red

Die Angaben sind optional, es gibt default Voreinstellungen.

- das Rundungsproblem des BatOut-Wertes in der Flowgrafik ist beseitigt (#1508)

ToDos: Offen ist noch die Implementierung von Infos zu mehreren Batterien in der Flowgrafik. Stand jetzt wird der dargestellte SOC als Durchschnitt aller definierten Batteren bzw. deren SOC's gebildet. Das wird wohl auch so bleiben. Allerdings will ich noch die separaten Werte der Einzelbatterien irgendwie in der Grafik unterbringen.
 

Wie immer nach dem Download aus dem contrib FHEM restarten.

LG,
Heiko

[grappa24]

Sehr cool, habs gleich mal umgesetzt ...
Danke Heiko ...

[DS_Starter]

Mir ist gerade noch die Idee gekommen das Icon der aktuellen Stunde entsprechend des SOC dynamisch zu gestalten. Da gibt es ja im Fundus einige Abstufungen. Kommt dann noch mit rein.

[Parallix]

Wow, dass das Multi-BAT-Features so schnell kommen würden, hätte ich nicht gedacht. Toll!

Eine Sache bereitet mit aber Kopfschmerzen:

...
Stand jetzt wird der dargestellte SOC als Durchschnitt aller definierten Batteren bzw. deren SOC's gebildet. Das wird wohl auch so bleiben.

Einen ungewichteten SOC-Durchschnittswert zu bilden, ist inhaltlich sehr problematisch! Du müsstest schon einen Gesamt-SOC unter Berücksichtigung der Einzelkapazitäten der einzelnen BAT-Systeme bilden, die ja durchaus unterschiedlich sein können.

[cwagner]

Nochmals vielen Dank. Dann warst Du ja von Anfang an auf der richtigen Spur. Auch Deine Vermutung ist richtig, dass configdb über seine Housekeeping-Funktion (reorg) diese Dateien nicht abräumt, weil sie alle unique sind, einmal entstehen und dann ja nicht mehr geändert werden.

Das sind die Sicherungsdatei-Sicherungen, erkennbar an dem Zeitstempel am Ende des Namens. Sie werden kurz nach Mitternacht geschrieben.

Ggf. hast du als configDB eigene Housekeeping Möglichkeiten um alte Versionen automatisch zu löschen?

Da werde ich mir wohl einen kleinen Housekeeper bauen müssen, dazu werde ich noch lernen müssen, ob und wie man bei configdb im filedelete-Dialog Joker einsetzt.

Christian

[DS_Starter]

Moin,
@Parallix,

Einen ungewichteten SOC-Durchschnittswert zu bilden, ist inhaltlich sehr problematisch! Du müsstest schon einen Gesamt-SOC unter Berücksichtigung der Einzelkapazitäten der einzelnen BAT-Systeme bilden, die ja durchaus unterschiedlich sein können.

Für die diversen Kalkulationen wie SOC-Steuerung und Ladeempfehlung wird das auch gemacht. Ich ergänze im Wiki noch etwas zu dem Wichtungsverfahren.

Der Hinweis war lediglich auf die Anzeige in der Flowgrafik bezogen, weil mir noch kein guter Ansatz eingefallen ist X Batterien als Block darzustellen. Wenn mir keine weitere Idee kommt, werde ich wohl ein Textfeld mit den Einzelwerten der Batterien einblenden. Dann sieht man wie sich der Grafikwert zusammensetzt.

@Christian,
in die Hilfe zum Attr ctrlBackupFilesKeep schreibe ich einen Hinweis für configDB User.

[Parallix]

...
Der Hinweis war lediglich auf die Anzeige in der Flowgrafik bezogen, weil mir noch kein guter eingefallen ist X Batterien als Block darzustellen. Wenn mir keine weitere Idee kommt, werde ich wohl ein Textfeld mit den Einzelwerten der Batterien einblenden. Dann sieht man wie sich der Grafikwert zusammensetzt.
...

Normalerweise würde man so etwas ja als (Teil-)Baum darstellen. Das gesamte Gebilde setzt sich zusammen aus einzelnen Teilbäumen, es wäre also ein allgemeiner Graph. Letzterer entsteht dadurch, dass man rechts an den bisherigen BAT-Knoten (der nunmehr zum Summenknoten würde) die einzelnen BAT-Systeme anpflanscht. Dann wären alle Infos in einer Grafik, ohne diese zu überfrachten.

[DS_Starter]

Letzterer entsteht dadurch, dass man rechts an den bisherigen BAT-Knoten (der jetzt ein Summenknoten wäre) die einzelnen BAT-Systeme anpflanscht. Dann wären alle Infos in einer Grafik, ohne diese zu überfrachten.

Im Prinzip eine gute Idee die ich auch schon hatte.
Allerdings gibt es in unserem Setup die Möglichkeit Smartloader, Geräte die eine Batterie direkt laden, zu integrieren.
Diese Geräte hätten einen direkten Bezug zu einer oder mehreren Batterien was wiederum bedeuten würde Schlüssel für die Beziehungen von Smartloader und spezifischer Batterie einzuführen und abzubilden.
Deswegen ist eine Blockdarstellung besser geeignet.
Vllt. bekomme ich es noch irgendwie hin einen Block zu erstelle wo man innen drin die Einzelbatterie mit ihren Werten sieht.

Wer Lust und Laune hat, kann sich daran gern mal versuchen.

Edit: Aber dein Hinweis zu einem Summenknoten (wie bei den Invertern) ist vllt. ein guter Weg. D.h. die jetzige Batterie würde zu einem Summenknoten werden, in den alle Zu/Abflüsse münden. Die einzelnen Batterien würden als Äste an den Knoten angesetzt und in/out vom/zum Knoten könnten dargestellt werden.
 

[Parallix]

...
Allerdings gibt es in unserem Setup die Möglichkeit Smartloader, Geräte die eine Batterie direkt laden, zu integrieren.
Diese Geräte hätten einen direkten Bezug zu einer oder mehreren Batterien was wiederum bedeuten würde Schlüssel für die Beziehungen von Smartloader und spezifischer Batterie einzuführen und abzubilden.

Wenn es von den Smartloadern eigenständige Verbindungen zu einem oder mehreren BAT-Systemen gibt, die nicht über den Wechselrichter laufen (der bislang als solcher leider noch nicht Bestandteil der Grafik ist), so könnte man die Smartloader dann doch noch von rechts von den einzelnen BAT-Systemen platzieren? Horizontal ist doch (noch) relativ viel Platz, oder?

Wenn nur die SOC-Werte der einzelnen BAT-Systeme in einen Mega-Knoten zu sehen wären, dann fehlen meines Erachten wichtige Informationen, z.B. die Info, welche BAT tatsächlich gerade wie viel liefert oder wie stark geladen wird.

PS: Bin heute den ganzen Tag weg. Mache mich morgen aber gerne mal daran, meine Vorschläge zu bebildern.

[DS_Starter]

Anbei siehst du ein produktives Beispiel von mir mit einem Samrtloader.
Das wird alles schon sortiert aufgebaut.
An den Platz der jetzigen Batterie würde wieder ein Summenknoten wie bei den Invertern/Producern kommen und die Batterie(n) als Verästelung nach rechts rücken und auf den neuen Knoten arbeiten.
Damit wäre alles konsistent und auch gut managebar abgebildet.

Wenn nur die SOC-Werte der einzelnen BAT-Systeme in einen Mega-Knoten zu sehen wären, dann fehlen meines Erachten wichtige Informationen, z.B. die Info, welche BAT tatsächlich gerade wie viel liefert oder wie stark geladen wird.

Solche aufgeschlüsselten Infos können daneben stehen, muß ja nicht nur der Average SOC sein. Wäre kein Problem.

[Parallix]

Anbei siehst du ein produktives Beispiel von mir mit einem Samrtloader.
Das wird alles schon sortiert aufgebaut.
An den Platz der jetzigen Batterie würde wieder ein Summenknoten wie bei den Invertern/Producern kommen und die Batterie(n) als Verästelung nach rechts rücken und auf den neuen Knoten arbeiten.
Damit wäre alles konsistent und auch gut managebar abgebildet.

Klingt gut!

Was aber immer noch etwas stört ist, dass BAT-Systeme, die DC-gekoppelt sind, ja über den WR laufen, in der Grafik aber eigentlich nicht korrekt abgebildet werden. Durch einem Anbringen von Pfeilen an die (Flow-)Kanten könnte man dieses Manko aber relativ einfach beseitigen. Dann gäbe es auch bei o.g. DC-Anbildung der BATs keine Kante(n) mehr von den BAT-Systemen zum Haus.

[DS_Starter]

@all,

ich habe die V in meinem contrib upgedated.
Neben ein paar kleineren Fixes ist es nun möglich die Farbgebung der Standard Icons für die Batteriedarstellung persönlich anzupassen, d.h. ohne Angabe eines definierten Icons.
Also etwa diese Notation:

icon=@#ace600:@yellow:@red  oder
icon=:::@#4d4d4d

Es ist auch möglich (Icon) und/oder Farbe für "keine Ladeempfehlung" anzupassen:

[[icon=<empfohlen>@<Farbe>]:[<aufladen>@<Farbe>]:[<entladen>@<Farbe>]:[icon=<unterlassen>@<Farbe>]]

icon    Icon und/oder (nur) Farbe zur Darstellung der Batterie in der Balkengrafik (optional)
    Die Farbe kann als Name (z.B. blue) oder HEX-Wert (z.B. #d9d9d9) angegeben werden.
    <empfohlen> - die Aufladung ist empfohlen aber inaktiv (kein Aufladen oder Entladen)
    <aufladen> - wird verwendet wenn die Batterie aktuell aufgeladen wird
    <entladen> - wird verwendet wenn die Batterie aktuell entladen wird
    <unterlassen> - wird verwendet wenn die Aufladung nicht empfohlen ist

Die Möglichkeiten sind wichtig, da das Icon-Design zukünfig dynamisch mit dem SOC korrespondieren wird.
Falls man allerdings eigene Icons definiert, ist dieses Feature nicht möglich.
Deswegen belässt man lieber den Standard und ändert nur die Färbung nach Bedarf.

EDIT: Zur aktuellen Stunde wird bei den Batterie-Icons der aktuelle SOC abgebildet und per Mouse-Over auch der genaue Wert.

LG
 

[DS_Starter]

Das Modul in meinem contrib hat wieder ein Update bekommen.
Nun gibt es eine Batterie SoC Entwicklungsprognose die Einfluß auf die angezeigten Ladeempfehlungs-Icons der jeweiligen Batterie hat.
Diese SoC-Prognose berücksichtigt den aktuellen SoC, die zu erwartende PV in Beziehung zur Verbrauchsprognose (=Überschuß), den optimalen SoC aus der SoC-Steuerung sowie die Steuerung der Ladeempfehlung.

Der Prognose-SoC bezieht sich immer auf den Anfang der angezeigten Stunde.
In dem Screenshot sieht man den aktuellen SoC als Startpunkt und die weitere Prognose (den Wert der ersten Folgestunde als Beispiel im Mouse-Over)

LG