RCT Power - BAT status check removed because their content is unknown

[pob90]

I see battery.status2 sporadically set to 2048. The raise instruction then stops using the remaining values. I'm in contact with RCT but still no answer.

[hhoefling]

Ich meine gelesen zu haben das 2048 "balancing" bedeutet.

[benderl]

Ich meine gelesen zu haben das 2048 "balancing" bedeutet.

Hast Du eine Doku dazu? Bisher haben wir leider keine offizielle Rückmeldung von RCT bekommen.

[pob90]

Ich meine gelesen zu haben das 2048 "balancing" bedeutet.

In der 2.0 ist das Problem im Prinzip gefixt. Zumindest wird kein raise mehr aufgerufen. Scheint also bekannt zu sein.

[benderl]

Nein, dort werden trotz Fehlerstatus ungleich "0" weiter Werte abgefragt. Bei manchen Fehlermeldungen kann es aber durchaus sinnvoll sein, das nicht zu machen oder eine Warnung im Status anzuzeigen.

Es wäre gut, wenn wir eine Liste der Fehlerstati hätten.

[pob90]

Nein, dort werden trotz Fehlerstatus ungleich "0" weiter Werte abgefragt. Bei manchen Fehlermeldungen kann es aber durchaus sinnvoll sein, das nicht zu machen oder eine Warnung im Status anzuzeigen.

Es wäre gut, wenn wir eine Liste der Fehlerstati hätten.

Mit gefixt meinte ich auch, das die Regelung und Anzeige in 2.0 weiterhin funktionieren. Ich habe heute von RCT die Nachricht bekommen, dass bit 11 "Balancing active" bedeutet. Ich checke, ob ich alle Info's mit hier teilen darf. Melde mich wieder!

[hhoefling]

Bit 11 also 2048 Siehe 👍 https://rctclient.readthedocs.io/en/latest/inverter_bitfields.html

[pob90]

Bit 11 also 2048 Siehe 👍 https://rctclient.readthedocs.io/en/latest/inverter_bitfields.html

Antwort gestern von RCT: "Hi Peter, wir versuchen möglichst viel Informationen offen zu halten, die von mir gegebene Information ist frei zu verwenden."

Hier also die Definitionen für den Status:

battery.status:

define BC_RESULT_DISCONNECTED 0 /* Battery is disconnected /

define BC_RESULT_CONNECTING_NO_PUMP 1 /* Battery in connecting state, but DC-Link should not be pumped /

define BC_RESULT_CONNECTING 2 /* Battery in connecting state and DC-Link should be pumped /

define BC_RESULT_CONNECTED 3 /* Battery is connected /

Das Unterschied zwischen battery.status2 und battery.status:

battery.status2 – kommt vom BMS battery.status – kommt vom Wechselrichter,

dabei die Bits haben gleiche Bedeutung.

define BAT_STATUS2_DISCONNECTED (1UL << 0) /* Battery disconnected /

define BAT_STATUS2_RELAY_TEST (1UL << 1)

define BAT_STATUS2_READY (1UL << 2)

define BAT_STATUS2_CALIBRATION (1UL << 3) /* Calibration at high voltage /

define BAT_STATUS2_STANDBY (1UL << 4) /* Battery standby (connected) / bootloader /

define BAT_STATUS2_SHUT_DOWN (1UL << 5) /* Shut Down /

define BAT_STATUS2_PRECHARGE (1UL << 6) /* Precharge /

define BAT_STATUS2_STARTUP (1UL << 7) /* Startup /

define BAT_STATUS2_BATTERY_FULL (1UL << 8) /* Battery is full /

define BAT_STATUS2_BATTERY_EMPTY (1UL << 9) /* Battery is empty /

define BAT_STATUS2_CALIBRATION_EMPTY (1UL << 10) /* Calibration at low voltage /

define BAT_STATUS2_BALANCE (1UL << 11) /* Balancing active /

define BAT_STATUS2_ERROR (1UL << 12) /* Error /

define BAT_STATUS2_UPDATE (1UL << 13) /* Update running /

[hhoefling]

Hm... Ich habe Battery.status = 0 = BC_RESULT_DISCONNECTED 0 Kann nicht sein. Aber Batteie ist da und funktiuoniert (musste also status 3 sein)

[hhoefling]

Es gibt drei objecte die "status" im Namen haben.

(stat1 im rct-module) 0x70A2AF4F 'battery.bat_status (stat2 im rct-module) 0x71765BD8 'battery.status' (stat3 im rct-module) 0x0DE3D20D 'battery.status2'

für stat1 habe ich die Werte 256,,512,1024 und 8 bisher angetroffen. für stat3 die Werte 0 und 256

@peter, fragt doch mal nach 'battery.bat_status", der scheint ergibiger zu sein.

[hhoefling]

Der oben zuerste erwähnte "battery.stats" als Enum ist warscheinoch eher das Feld 0xDC667958, 770, 'power_mng.state', 'Battery state machine'

dort habe ich eine 3, was dann richtigerweise BC_RESULT_CONNECTED 3 / Battery is connected / bedeuten würde.

Alles immer noch etwas durcheinande....

[pob90]

Der oben zuerste erwähnte "battery.stats" als Enum ist warscheinoch eher das Feld 0xDC667958, 770, 'power_mng.state', 'Battery state machine'

dort habe ich eine 3, was dann richtigerweise BC_RESULT_CONNECTED 3 / Battery is connected / bedeuten würde.

Alles immer noch etwas durcheinande....

Ich hatte nach allen drei gefragt. Daher denke ich, das es eher ein typo in der Antwort ist und die BC definitionen zu battery.bat_status gehören.

Ich versteh aber auch nicht, was uns das alles in dem Zusammenhang bringt. Ich wollte eigentlich nur erreichen, dass die Regelung weiterhin funktioniert. Ob balancing gerade läuft ist mir da komplett egal

[benderl]

So ganz egal kann es aber der Regelung nicht sein. Wenn der Speicher gerade sein Balancing macht, kann er de facto doch nicht genutzt (entladen) werden. Es kann also passieren, dass die Regelung erkennt: Es gehen 2kW in die Batterie, dann erzeuge ich mal schnell 2kw Bezug am EVU, damit nicht mehr der Speicher, sondern das Auto geladen wird. Wenn das Balancing dabei läuft, entstehen aber dann wirklich dauerhaft 2kW Bezug am EVU und der Speicher lädt fleißig weiter.

Ist aber dann eher potentiell ein Thema für 2.x, als das irgendwie an die 1.9 dranzuflanschen.

[benderl]

Damit die Module zwischen 1.9 und 2.x weiterhin konsistent sind, wird es aber eher auf einen Backport aus 2.x hinauslaufen, als diesen PR zu mergen.

@LKuemmel kannst Du das bei Gelegenheit bitte umsetzen?

[pob90]

So ganz egal kann es aber der Regelung nicht sein. Wenn der Speicher gerade sein Balancing macht, kann er de facto doch nicht genutzt (entladen) werden. Es kann also passieren, dass die Regelung erkennt: Es gehen 2kW in die Batterie, dann erzeuge ich mal schnell 2kw Bezug am EVU, damit nicht mehr der Speicher, sondern das Auto geladen wird. Wenn das Balancing dabei läuft, entstehen aber dann wirklich dauerhaft 2kW Bezug am EVU und der Speicher lädt fleißig weiter.

Ist aber dann eher potentiell ein Thema für 2.x, als das irgendwie an die 1.9 dranzuflanschen.

Also bei mir ging die Regelung mehr als einen Tag nicht mehr wegen permanentem raise. Das kann also eigentlich nicht am balancing alleine gelegen haben. Ich hab dann aber auch nicht weiter geforscht und den Wechselrichter neu gestartet. Jetzt geht erstmal wieder alles.

[pob90]

Damit die Module zwischen 1.9 und 2.x weiterhin konsistent sind, wird es aber eher auf einen Backport aus 2.x hinauslaufen, als diesen PR zu mergen.

@LKuemmel kannst Du das bei Gelegenheit bitte umsetzen?

Ja, das wäre auch mein Favorit. Soll ich dann diesen PR einfach schliessen?

[pob90]

So, seit gestern ca. 20 Uhr gehts wieder los. Balancing hat gestartet und die Battery wurde geladen und danach wieder komplett entladen.

Eigentlich würde ich annehmen, dass so gegen Mitternacht das balancing abgeschlossen ist. Allerdings steht battery.status2 auch jetzt um ca. 10 Uhr immer noch uf 2048 (=balancing). Durch das raise steht der Battery SOC immer noch auf 12%, die Entladeleistung auf 2.52 kW und damit wird auch der Hausverbrauch komplett falsch berechnet. Außerdem hat während der Entladezeit die openWB mit dem Laden eines Fahrzeugs angefangen wenn auch mit komplett falschen Werten. Wenigstens ging dabei nicht alles ins Netz:). So sieht das Dashboard der openWB aktuell aus:

Das liefert die RCT App: Und das kommt mit meinem rct_read.py script raus:

0x70A2AF4F battery.bat_status -> battery.bat_status = 0

0x71765BD8 battery.status -> Battery status = 0

0x0DE3D20D battery.status2 -> Battery extra status = 2048

0x1156DFD0 power_mng.battery_power -> Battery discharge power [W] = -202.3123016357422

0x959930BF battery.soc -> SOC (State of charge) = 0.08151320368051529

Ich lasse das Ganze jetzt einfach mal weiterlaufen und schau wann bzw. ob balancing verschwindet.

[hhoefling]

Seit der Umstellung auf den LRS in der 1.9''er wird dort ebenfalls alles ausser 0 im Status als Error gewertet Die alten RCT[2] Module haben nur den Faultstate gesetzt aber die Daten weitergereicht. Ich verwende noch die vor-LRS Module, und habe keinen Datenausfall.

[pob90]

Seit der Umstellung auf den LRS in der 1.9''er wird dort ebenfalls alles ausser 0 im Status als Error gewertet Die alten RCT[2] Module haben nur den Faultstate gesetzt aber die Daten weitergereicht. Ich verwende noch die vor-LRS Module, und habe keinen Datenausfall.

Das ist genau was ich mit diesem PR erreichen wollte. Aber eben für alle die mit stable laufen. Klar kann ich mir jetzt auch eine standalone installieren und meine beidem openWB's damit steuern. Aber das ist eigentlich nicht Sinn der Sache. Darum bin ich froh wenn das Verhalten der 2.0 dann auch in der 1.9 so ist. Es kann natürlich sein, dass es ein Fehler in der RCT Anlage ist. Kann aber auch sein, dass der Status einfach nur anzeigt, dass überhaupt Balancing seit dem letzten Einschalten erfolgt ist. Verschwindet bei dir die 2048 wieder oder bleibt die auch so lange da? Habe gerade auch nochmal bei RCT nachgefragt!

Meine Anlage schaut jetzt aus Sicht der RCT-App wieder wie im Normalbetrieb aus.

Leider steht status2 immer noch auf 2048 und openWB funktioniert daher auch regelungstechnisch nicht.

Die Summen (Hausverbrauch, EVU Import) sind natürlich komplett falsch, da die Hausverbrauch aufgrund von angeblicher Speicherentladung falsch ist.

[pob90]

So ganz egal kann es aber der Regelung nicht sein. Wenn der Speicher gerade sein Balancing macht, kann er de facto doch nicht genutzt (entladen) werden. Es kann also passieren, dass die Regelung erkennt: Es gehen 2kW in die Batterie, dann erzeuge ich mal schnell 2kw Bezug am EVU, damit nicht mehr der Speicher, sondern das Auto geladen wird. Wenn das Balancing dabei läuft, entstehen aber dann wirklich dauerhaft 2kW Bezug am EVU und der Speicher lädt fleißig weiter.

Ist aber dann eher potentiell ein Thema für 2.x, als das irgendwie an die 1.9 dranzuflanschen.

Also bei mir passiert das Balancing offenbar nur abends oder in der Nacht. Ich kenn mich jetzt mit dem Regelalgorithmus der openWB nicht wirklich aus. Aber ich hätte vermutet, dass kein PV Bezug aber EVU Bezug in die Batterie nicht dazu führt, dass eine Auto geladen wird. Wie macht die openWB denn das bei anderen Anlagen? Ist da Balancing überhaupt ersichtlich?

[hhoefling]

Das 30 Tage intervall ist bei mir in den nächsten Tagen rum. Dann kann ich genauer Berichten wie sich die alten RCT Module in der 1,9'er bei mir Verhalten. Zum 2048'er: Der geht bei mir von alleine wieder weg. Die 1.9' merkt sich den Faultstate zwar länger, da er aber nicht zum Abbruch den Datenabfrage führt, stört der 2048 Status nicht weiter,

[benderl]

Also bei mir passiert das Balancing offenbar nur abends oder in der Nacht. Ich kenn mich jetzt mit dem Regelalgorithmus der openWB nicht wirklich aus. Aber ich hätte vermutet, dass kein PV Bezug aber EVU Bezug in die Batterie nicht dazu führt, dass eine Auto geladen wird. Wie macht die openWB denn das bei anderen Anlagen? Ist da Balancing überhaupt ersichtlich?

Aktuell wird da noch gar nichts berücksichtigt. Für die Zukunft wäre es nur sinnvoll zu wissen, was die Fehlerstati bedeuten. Daher hatte ich nachgefragt. Da wir ja jetzt eine offizielle Info haben, sollte ein entsprechender Kommentar im Code das zumindest festhalten. Ob/wie die Regelung später mal damit umgeht, wird sich zeigen.

Meine Sonnenbatterie macht das Balancing auch mal tagsüber, bisher habe ich aber noch nicht nach Statusbits gesucht.

[pob90]

Antwort von RCT bzgl balancing: Hi Peter,

„balancing“ bleibt so lang wie es für das BMS nötig, kann mehreren Tagen lang so bleiben. Sobald das Differenz zwischen einzelnen Zellspannungen unter 50 mV sinkt, wird diese Bit gelöscht.

[hhoefling]

Ohne Anspruch auf Vollständigkeit habe ich hier mal eine Seite mit Informationen angefangen.

https://github.com/hhoefling/openWB_lite/blob/master/docs/rct.md

Balacing habe ich weiterhin nicht "bei der Arbeit" erwischt.

[pob90]

Es ist Mal wieder soweit. Das bit ist gesetzt und die OpenWB 1.9 wirft wieder Fehler. Die Änderung ist jetzt nicht sehr kompliziert. Gibt es eine Möglichkeit, sie zeitnah zu mergen? Ansonsten muss ich mir jetzt echt mal ne standalone aufbauen. Danke!

[pob90]

Seit knapp 4 Wochen steht meine RCT auf Balancing. Keine Ahnung warum aber das dieser PR jetzt schon ins dritte Monat geht ist mehr als nur ein Trauerspiel.

[benderl]

Ersetzt durch #2811 Danke für die Status-Definitionen. Mal sehen, ob man da in Zukunft mehr daraus erkennen kann.