76_SolarForecast - Informationen/Ideen zu Weiterentwicklung und Support

[DS_Starter]

Irgendwas ist generell kaputt gegangen mit dem Update auf v1.53.0

Kaputt ist sicherlich nichts. Welche Version hattest du vorher? Hast du die Updates der Weiterentwicklungen immer mitgemacht?

[Prof. Dr. Peter Henning]

minimal mögliche Intervallzeiten gesetzt

Typischer Anfängerfehler - damit legt man sein System ziemlich lahm.

LG

pah

[seayak]

minimal mögliche Intervallzeiten gesetzt

Typischer Anfängerfehler - damit legt man sein System ziemlich lahm.

LG

pah

Hallo pah,

im Deinem Zitat von mir fehlt leider noch der nicht von Dir mit kopierte Zusatz "wenn technisch verantwortbar". Das beinhaltet auch den sorgsamen Umgang mit den Intervallzeiten. Auch die Beachtung von 300P gegebenen Hinweise wird ein technisch versierter User beachten.

Viele Grüße!

Peter

[Prof. Dr. Peter Henning]

Das beinhaltet auch den sorgsamen Umgang mit den Intervallzeiten. Auch die Beachtung von 300P gegebenen Hinweise wird ein technisch versierter User beachten.

Das sehe ich deutlich anders, weil damit immer noch nicht das Problem der zeitversetzten Messwerte gelöst wird. Statt eines reichlich absurden Sampling-Intervalls von 10 Sekunden für diese Daten wäre der richtige Weg eine Interpolation zu einem bestimmten Zeitpunkt.

LG

pah

[Burny4600]

Eine Frage noch zur Balkendarstellung der Batterie-Einheiten.

Jede Deye-Batterie hängt an einem Deye-Hybridinverter. Die beiden Hybridinverter und zugehörigen Batterien haben miteinander nichts zu tun.

Beide Batterien sind im Soll, aber die Batterie 2 zeigt eine gravierende Abweichung an.

setupBatteryDev01

Code Auswählen Erweitern

Deye_12k icon=@dyn:@#0CFB0C:@yellow:@red show=2:bottom label=beside cap=24000
pin=Akku_Leistung_BMS1__kW:kW pout=-pin charge=Akku_SOC__KAP
intotal=Akku_Energie_Ladung_Gesamt__kWh:kWh outtotal=Akku_Energie_Entladung_Gesamt__kWh:kWh
asynchron=1
setupBatteryDev02

Code Auswählen Erweitern

Deye_15k icon=@dyn:@#0CFB0C:@yellow:@red show=3:bottom label=beside cap=24000
pin=Akku_Leistung_BMS1__kW:kW pout=-pin charge=Akku_SOC__KAP
intotal=Akku_Energie_Ladung_Gesamt__kWh:kWh outtotal=Akku_Energie_Entladung_Gesamt__kWh:kWh
asynchron=1
Irgendwo muss ich da noch einen Fehler haben.

[300P]

.....gegenüber des 2ten Wertes ist die Abweichung so groß  .
Ausschlaggebend ist der Eintrag des 2.te Wertes in "graphicBeamXContent" - wenn keiner da ist ist die Abweichung halt so groß wie der Wert selbst ist.

Zeig mal den Bereich mit den Attributen

[300P]

Nachsatz zu meinem Post wegen evtl. Datenüberschneidungen:

Hab zur Vermeidung von Verwirrung in meinem Post extra nicht dabei angegeben, dass ich innerhalb von SF beim attr plantControl den Wert cycleInterval=0 gesetzt habe.
Der "automatische" zyklische Interval bei SF ist somit ausgestellt.
Die SF-Daten werden bei mir erst ganz am Ende in einem eigens dafür angelegtem Sammel-Notify für alle relevanten Daten (Dummy- / Verbrauchs- / Bezugs- / Leistungs- / Zustandsdaten / etc. / usw.) aktualisiert.
Der "triggeredByEvent" ist dort auf die Veränderung des Saldos der Bezugleistung im Smartmeter am Hausanschluss eingestellt. Das Smartmeter-Device hat eine Min-Interval von 30 oder aber der Saldo der Bezugsleistung ändert sich vorher.

Eine 100 % Lösung ist dies sicherlich auch nicht - aber die bekannten Probleme mit den negativen Werten im Log kenne ich bislang nur aus den Post anderer User...      

[TheTrumpeter]

Der "triggeredByEvent" ist dort auf die Veränderung des Saldos der Bezugleistung im Smartmeter am Hausanschluss eingestellt. Das Smartmeter-Device hat eine Min-Interval von 30 oder aber der Saldo der Bezugsleistung ändert sich vorher.

Das als "Führungsgröße" zu verwenden erscheint auf den ersten Blick schlüssig. Wie gehst Du dann mit den weiteren Geräten (Wechselrichter, Batterie) um?

Wenn sich der "PowerOffset" im SmartMeter ändert, kann eine Ursache eine Änderung der WR-Leistung sein, d.h. man müsste dessen Leistung sofort abholen. Machst Du das so und passen die Werte dann wirklich zusammen, d.h. steile Gradienten durch Wolken werden sauber abgebildet?

[300P]

Wie gehst Du dann mit den weiteren Geräten (Wechselrichter, Batterie) um?

Wenn sich der "PowerOffset" im SmartMeter ändert, kann eine Ursache eine Änderung der WR-Leistung sein, d.h. man müsste dessen Leistung sofort abholen. Machst Du das so und passen die Werte dann wirklich zusammen, d.h. steile Gradienten durch Wolken werden sauber abgebildet?

Alle Device werden - wie schon geschrieben - dann mit den aktuellen Werten abgeholt
==>>> Sie stehen ebenfalls auf manuellem Intervall bzw. reagieren auf diesen per Notify / triggeredByEvent.(siehe Screenshot)

Mir reicht dies so bislang - hab noch nie nachverfolgt ob und wie genau dies ist wenn z.B. Wolken kommen und gehen oder Verbräuche hoch/runter gehen
=>>> da sollen sich meine BWR doch Gedanken drum machen - mir ist's egal

PS:
Nach 30 Tagen sind das alles so oder so nur noch Stundenwerte.
und irgendwann dann nur noch Tageswert die ich mir ansehen will  ....

[Burny4600]

.....gegenüber des 2ten Wertes ist die Abweichung so groß  .
Ausschlaggebend ist der Eintrag des 2.te Wertes in "graphicBeamXContent" - wenn keiner da ist ist die Abweichung halt so groß wie der Wert selbst ist.

Zeig mal den Bereich mit den Attributen

[300P]

Da ist kein Eintrag - also Rätselraten oder 

Nimm mal die Werte der attr ...Beam5.. in ...Beam6... und lösch die in ..Beam5..

Könnte - Müsste aber nicht sein das es sich verändert. 


EDIT - Nachsatz:
Falls das nicht wirkt - du hast doch nur 1 Wert je Beam - Also schalt die Berechnung in GrafikControl aus:

Code Auswählen Erweitern

showDiff Zusätzliche numerische Anzeige der Differenz '<primärer Balkeninhalt> - <sekundärer Balkeninhalt>'.
no - keine Differenzanzeige (default)
top - Anzeige über den Balken
bottom - Anzeige unter den Balken

[Burny4600]

Nimm mal die Werte der attr ...Beam5.. in ...Beam6... und lösch die in ..Beam5..

Unter ...Beam6... definiert sieht es anders aus.

Irgendwie dürfte aber die Abweichung trotzdem nicht stimmen. Mir kommen diese Werte zu gring vor.

[300P]

Irgendwie dürfte aber die Abweichung trotzdem nicht stimmen. Mir kommen diese Werte zu gring vor.

Das sind sicherlich irgendwelche Rundungsdifferenzen (1 Wert je Beam s.o. beim Edit)

[300P]

@DS_Starter:

Dies ist noch aus der Zeit als es "nur" eine Anzeige mit 2 Werten gab

Code Auswählen Erweitern

showDiff    Zusätzliche numerische Anzeige der Differenz '<primärer Balkeninhalt> - <sekundärer Balkeninhalt>'.
no - keine Differenzanzeige (default)
top - Anzeige über den Balken
bottom - Anzeige unter den Balken
Aus dem obigen ergibt sich evtl. zukünftig der Wunsch einiger User das es pro Beam gesteuert werden könnte ?!?
Kannst du ja mal auf die berühmte ToDo-List nehmen 
.

[DS_Starter]

Aus dem obigen ergibt sich evtl. zukünftig der Wunsch einiger User das es pro Beam gesteuert werden könnte ?!?
Kannst du ja mal auf die berühmte ToDo-List nehmen 

Kann ich machen, wenn es den Wunsch geben sollte. 
Als wir zu Beginn nur einen Ebene hatten, war das egal. Nun sind es ja inzwischen 3, und wer weiß ob es dabei bleibt.