premultiply
commented
8 months ago Irgendwie scheint der WR hier mit Anfragen überflutet zu werden die er aber quasi nie beantwortet bzw. beantworten kann.
/cc @andig Eine Idee wo diese Flut herkommt?
Closed thierolm closed 7 months ago
premultiply
commented
8 months ago Irgendwie scheint der WR hier mit Anfragen überflutet zu werden die er aber quasi nie beantwortet bzw. beantworten kann.
/cc @andig Eine Idee wo diese Flut herkommt?
andig
commented
8 months ago Mal mit timeout spielen? Alles Andere stoppen? Nur
evcc meterprobieren? 20x pro Sekunde ist sehr merkwürdig. Remotezugang möglich?
andig
commented
8 months ago Lustigerweise passiert das ja auch ausschließlich bei der Batteriesteuerung. Kann es sein, dass die erst im Setup freigeschaltet werden muss? Der Rest geht ja- es ist also kein grundsätzliches Modbusproblem?
andig
commented
8 months ago Geht im Test wunderbar:
gor main.go meter --log error,modbus:trace -c battery.yaml -b hold
[main ] INFO 2024/01/16 22:10:38 evcc 0.0.0
[main ] INFO 2024/01/16 22:10:38 using config file: battery.yaml
[modbus] TRACE 2024/01/16 22:10:38 modbus: send 00 01 00 00 00 06 01 06 00 20 00 00
[modbus] TRACE 2024/01/16 22:10:39 modbus: recv 00 01 00 00 00 06 01 06 00 20 00 00
[modbus] TRACE 2024/01/16 22:10:39 modbus: send 00 02 00 00 00 06 01 06 00 1f 00 03
[modbus] TRACE 2024/01/16 22:10:39 modbus: recv 00 02 00 00 00 06 01 06 00 1f 00 03
gor main.go meter --log error,modbus:trace -c battery.yaml -b charge
[main ] INFO 2024/01/16 22:10:49 evcc 0.0.0
[main ] INFO 2024/01/16 22:10:49 using config file: battery.yaml
[modbus] TRACE 2024/01/16 22:10:49 modbus: send 00 01 00 00 00 06 01 06 00 20 00 01
[modbus] TRACE 2024/01/16 22:10:49 modbus: recv 00 01 00 00 00 06 01 06 00 20 00 01
[modbus] TRACE 2024/01/16 22:10:49 modbus: send 00 02 00 00 00 06 01 06 00 1f 00 03
[modbus] TRACE 2024/01/16 22:10:49 modbus: recv 00 02 00 00 00 06 01 06 00 1f 00 03
gor main.go meter --log error,modbus:trace -c battery.yaml -b normal
[main ] INFO 2024/01/16 22:10:55 evcc 0.0.0
[main ] INFO 2024/01/16 22:10:55 using config file: battery.yaml
[modbus] TRACE 2024/01/16 22:10:56 modbus: send 00 01 00 00 00 06 01 06 00 1f 00 00
[modbus] TRACE 2024/01/16 22:10:56 modbus: recv 00 01 00 00 00 06 01 06 00 1f 00 00@thierolm laut /etc ist das IP 192.168.2.87- warum ist oben in der Config eine andere?
thierolm
commented
8 months ago @thierolm laut /etc ist das IP 192.168.2.87- warum ist oben in der Config eine andere?
Hab sie anonymisiert hier im Issue ... ;-)
thierolm
commented
8 months ago Hallo @andig , mit der neuen Version 0.123.9 bekomme ich das in #11745 Verhalten. Ich hab den Bug wieder geschlossen, da ich erst später gemerkt habe, dass er auch wieder mit der Batteriesteuerung zusammenhängt.
andig
commented
8 months ago @ioniks @docsnyder7 @TobiP3005 does battery control work for you? It's unclear for me why modbus goes berserk here.
docsnyder7
commented
8 months ago @andig No, but i have no tests with 123.9... 123.8 does not control my battery
ioniks
commented
8 months ago @andig the same for me, it's not working. (with previous version), i can't test the new because i change the template from solax to custom on MQTT.
I have changed the method to use MQTT and no more the solax template with Modbus because of my modbus proxy which sometime no longer works.
andig
commented
8 months ago Only thing that would help if someone can try modbus commands directly to check what works and then identify what evcc does differently.
docsnyder7
commented
8 months ago 123.9 does not work...
battery mode: modbus: exception '4' (server device failure), function '6'
i use a workaround with separate Modbus register writings.. are you need the holdings i use?
andig
commented
8 months ago Please check https://github.com/evcc-io/evcc/blob/master/templates/definition/meter/solax.yaml. Do we maybe need func code 16 instead of 6?
docsnyder7
commented
8 months ago What do you mean with func code... i write the number(0=selfuse, 2= backup)of der SolarChargeUseMode in the register 31(0x001F) and check the result with readholding 139 the other way.. writeholding 37 with 0A or 15A and check with readholding 145
Func Code 16 for multiple writings? funktionscode6 funktioniert mit Iobroker über evcc als modbusproxy, Funktionscode 16 nicht
andig
commented
8 months ago funktionscode6 funktioniert mit Iobroker über evcc als modbusproxy, Funktionscode 16 nicht
Hat das was mit dem Proxy zu tun oder kann das Gerät die 16 nicht? Spielt hier aber keine Rolle- wir nutzen schon 6.
andig
commented
8 months ago 31(0x001F) and check the result with readholding 139 the other way.. writeholding 37 with 0A or 15A and check with readholding 145
@docsnyder7 I'm losing track of what we're discussing here. Are you trying to say we are using the wrong registers (see https://github.com/evcc-io/evcc/blob/master/templates/definition/meter/solax.yaml for what we use) or different problem.
mit der neuen Version 0.123.9 bekomme ich
@thierolm hat nur .9 das Problem? Geht battery control in .8? Gibts Unterschiede im trace log?
docsnyder7
commented
8 months ago Nein , wir diskutieren schon dasselbe Thema… und laut dem Solax Template nutzen wir auch das gleiche Register (0x001F) , welches in Dezimal halt die 31 ist… aber du fragtest , ob man den func Code 16 statt 6 verwenden sollte… und ich hab dazu geschrieben, dass mit Code 6 ich das Register 31 beschrieben kann, mit 16 gehts nicht… somit dürfte die 6 schon passen… meine Anmerkung dazu war, dass ich das Write Holding 31 gegenchecke mit dem korrespondierenden readholding…
bei mir funtioniee die battery Control auch in der .8 nicht
ioniks
commented
8 months ago For information , with my HA automation i set just : Min battery soc = current battery soc and the battery stop discharging
premultiply
commented
8 months ago That does not help further. As this is Modbus communication please name it as register numbers, function codes/operations and data types.
thierolm
commented
8 months ago @thierolm hat nur .9 das Problem? Geht battery control in .8? Gibts Unterschiede im trace log?
Den Fehler aus diesem Ticket hier (#11714), bekomme ich mit der Version 0.123.8 .
Das Verhalten von Ticket #11745 bekommt man mit Version 0.123.9 .
andig
commented
7 months ago @docsnyder7 funktioniert bei Dir battery control über mbrtu oder ein anderes Tool? Welche Register für welchen Zustand? Siehe template welche wir verwenden. Ein Vergleich der Modbus Kommunikation könnte helfen.
Die Steuerung von @ioniks ist ein anderes Verfahren über minSoc- könnten wir auch machen wenn der Versuch hier nicht klappt.
ioniks
commented
7 months ago @premultiply @andig for the min soc i use a HA plugin
in this module the registrer is : For backup Mode : register is 0x67 and min value is 15 and max is 100 ( backup_discharge_min_soc)
For Self Use mode : register is 0x61 and min value is 10 and max is 100 ( selfuse_discharge_min_soc )
i check it in https://github.com/wills106/homeassistant-solax-modbus/blob/main/custom_components/solax_modbus/plugin_solax.py
andig
commented
7 months ago @ioniks that does not help. We know the docs. We need the physical modbus exchange for comparison. That said: how do you change the mode?
ioniks
commented
7 months ago @andig i use the plugin linked above (in HA)
I don't change the mode, i set the min soc only to current soc. (or i don't understand how to help you)
docsnyder7
commented
7 months ago @andig ich nutze den modbusproxy, den evcc zur Verfügung stellt im IObroker mit dessen modbus Addon.. meine Einstellungen und Holdings im Anhang, ebenso wie ein script...
zum Script... ich bekomme per Mqtt die Werte, welchen Modus evcc am loadpoint 1 grad hat (off,pv, pv+min, now) wenn dieser Modus gemeldet wird (und der Hausakku keine 60% hat), dann schreibt das script in das writeholdingregister 31 = 0x001F den wert 2, was dem wechselrichtermodus backup entspricht...
wechselt evcc wieder in modus OFF, dann schreibt das Script den wert 0= Eigenverbrauch ins register 31
in der register Übersicht im Bild2, sieht man auch die passenden readholdings zu den Write Holdings... die hab ich mir angelegt, um zu kontrollieren, ob die schreibbefehle geklappt haben... den die Writeholdings zeigen andere Werte und man kann nicht kontrollieren, ob der Befehl geklappt hat!
Das gleiche geht übrigens auch mit dem Entladestrom...den kann man auf 0A setzen und bei Evccmodus OFF wieder auf 15A zb
Modbus TCP ist das Mittel meiner Wahl Und ich habe eine X3Hybrid G2...wenn gleich die register gleich sind zu den G3 und G4 Modellen
premultiply
commented
7 months ago Ich habe die Register nochmal mit der Doku usw. verglichen und kann da erstmal keine Abweichung und kein offensichtliches Problem dort erkennen.
Für mich ist somit erstmal (nur) die Flut von Anfragen an den WR das Problem und mutmaßlich dies auch der Grund für die Fehlermeldung.
docsnyder7
commented
7 months ago Warum Flut? Nur auf den Battery Control bezogen oder in Summe aller von EVCC kommenden?
andig
commented
7 months ago Für mich ist somit erstmal (nur) die Flut von Anfragen an den WR das Problem und mutmaßlich dies auch der Grund für die Fehlermeldung.
Warum Flut?
S.o.
@thierolm ich konnte das Verhalten über SSH nicht provozieren. Gelingt Dir das irgendwie mit evcc meter? Dann könnte ich mal mit dem Debugger rein schauen. Ich sehe keine Ursache für die wiederholten Requests :(
andig
commented
7 months ago @daniell1 könntest du bitte bestätigen, ob die Batteriesteuerung bei Dir funktioniert?
andig
commented
7 months ago @thierolm gem. https://github.com/evcc-io/evcc/issues/11714#issuecomment-1898282086 ist die Fehlermeldung oben gegenstandslos. Stattdessen gibts nun keine Meßwerte mehr. Könntest Du bitte mal
evcc meterim "normalen" und im Battery Hold Modus ausführen um den Fehler nachzuvollziehen?
thierolm
commented
7 months ago ok, mach ich heute Abend ...
daniell1
commented
7 months ago @daniell1 könntest du bitte bestätigen, ob die Batteriesteuerung bei Dir funktioniert?
Hi. Was genau soll ich testen? Ich hatte im Rahmen dieses Fixes einmal umfangreich getestet: https://github.com/evcc-io/evcc/pull/11488#issuecomment-1878885352 Bisher gibt es bei mir kein unverändertes Verhalten.
daniell1
commented
7 months ago @thierolm gem. #11714 (comment) ist die Fehlermeldung oben gegenstandslos. Stattdessen gibts nun keine Meßwerte mehr. Könntest Du bitte mal
evcc meterim "normalen" und im Battery Hold Modus ausführen um den Fehler nachzuvollziehen?
Das wurde umgestellt. "Normal" ist der Modus Eigenverbrauch und bei aktiver Batteriesteuerung wird auf den manuellen Modus mit Charge&Dischrg Stop gestellt. Das bedeutet aber, dass weder entladen, noch gelanden wird, wenn genüg Überschuss vorhanden ist. Der Backup Modus ging nicht, weil er dort immer bis zum MinSoC entlädt oder bis zu Charge battery to geladen wird (siehe https://github.com/evcc-io/evcc/discussions/9301#discussioncomment-8012457). Idealer wäre wohl immer noch der Einspeisemodus, setzt aber eine minSoc Konfig 100% voraus oder mein Favorit, die Anpassung der Start/End Dischrg time: https://github.com/evcc-io/evcc/discussions/9301#discussioncomment-8016991
daniell1
commented
7 months ago Lustigerweise passiert das ja auch ausschließlich bei der Batteriesteuerung. Kann es sein, dass die erst im Setup freigeschaltet werden muss? Der Rest geht ja- es ist also kein grundsätzliches Modbusproblem?
Es gibt tatsächlich Einstellungen, die mittels PIN geschützt sind. Z. B. die SoC-Werte der Betriebsmodi ändern oder Chrg&Dischrg Period. Das Umstellen der Betriebsmodi, wie es in https://github.com/evcc-io/evcc/pull/11488/files gemacht wird, ist allerdings ohne PIN erreichbar. Sollte also nicht das Thema sein.
thierolm
commented
7 months ago @andig: Ich kann diesen Fehler und das in #11714 beschriebene Verhalten aktuell mit der Version 0.123.9 nicht mehr nachvollziehen. Anbei das Log (sieht gut aus): Solax_X3_evcc_0_123_9_modbus_trace_20230122.log
Aktuell ist die Batteriesteuerung aktiv. Ich würde den Issue jetzt erst mal schließen, und beobachten, ob sich das in #11714 beschriebene Verhalten in Zukunft nochmal zeigt.
daniell1
commented
7 months ago @andig: Ich kann diesen Fehler und das in #11714 beschriebene Verhalten aktuell mit der Version 0.123.9 nicht mehr nachvollziehen. Anbei das Log (sieht gut aus): Solax_X3_evcc_0_123_9_modbus_trace_20230122.log
Aktuell ist die Batteriesteuerung aktiv. Ich würde den Issue jetzt erst mal schließen, und beobachten, ob sich das in #11714 beschriebene Verhalten in Zukunft nochmal zeigt.
Evtl. war dein Wechselrichter im Idle Mode. Ich habe dazu noch keine Dokumentation gefunden, aber beobachtet, dass das bei einem Battery SoC von 10% oder drunter passieren kann. In beiden Log-Auszügen ist das der Fall. Im Idle nimmt der WR keine Konfigurationsänderungen mehr an. Erst am nächsten Tag nach einem Selbsttest. Wenn du den Fehler wieder hast, kontrolliere mal, ob du manuell den Betriebsmodus ändern kannst. Am WR oder in der App. Messwerte zeigte mein WR aber bisher immer an, zumindest soweit ich mich erinnern kann.
FalkRR
commented
7 months ago Sorry, wenn ich mich hier "einmische". Wenn der Kommentar nicht erwünscht ist, dann lasst ihn einfach so stehen, ich habe damit dann kein Problem.
Hallo zusammen,
(ich habe eine Qcells Anlage, in welcher der Solax Wechselrichter verbaut ist) Ich möchte hier meine Erfahrungen zur Batteriesteuerung beitragen. Wenn ich den Code bzw. das Template von evcc richtig verstanden habe, versucht evcc, die Batteriesteuerung über den Wechsel in den manuellen Modus des Solax-WR, Modbus Register 0x1F auf 3 und "Stop force charge&discharge", Register 0x20 auf 0 erreichen. Habe ich getestet, das Abschalten der Entladung des PV Akkus funktioniert, allerdings kommt nach Beenden der Batteriesteuerung das System in dem Backup - Modus zurück. Ich betreibe allerdings meine Anlage im Eigenverbrauchsmodus, müsste also von Hand dann noch den Betriebsmodus ändern. Was natürlich nur funktioniert, wenn der WR läuft (das ist der Fall wenn Min Soc > xx% , wobei xx ist im Standard auf 10% eingestellt ist ODER genügend Strom von den PV Modulen kommt). Ich halte das Umschalten des Betriebsmodus für einen nicht so guten Ansatz.
Wie habe ich das gelöst? Ich steuere den Akku nicht über evcc, sondern über FHEM (meine Hausautomatisierung läuft komplett in FHEM). Ich checke, ob der EV Charger lädt und wenn ja, schalte ich das PV Akku Entladen aus. Dazu verwende ich nicht den Betriebsmodus der Anlage, den lasse ich so, wie er eben ist. Stattdessen verwende ich die Einstellungen für die DischargePeriod1 und 2.
Period1 ist immer "enabled", das kann man m.E. auch nicht ändern. Period2 kann aber enabled/disabled werden (Schreiben in Holding Register 0x6C uint16, 0=disable Period 2, 1=enable).
Period1 steht bei mir auf Beginn=00:00 Uhr und Ende=00:00 Uhr (also de-facto auf "disabled"). Das sind übrigens die Holding Register 0x6A und 0x6B zum Schreiben, jeweils gepackt zu 2x8 bit in 2xuint16 wobei die Minuten in den 8 höheren bits stehen und die Stunden in den 8 niederen bits).
Period2 steht auf 00:00 - 23:59 Uhr (jeweils Holding Register 0x6F und 0x70 für Start und Ende der Periode2).
Das Entladen der Batterie steuere ich über "Set_Chrg&DischrgPeriod2_Enable" - Holding Register 0x6c, 0=disable, 1=enable. Wenn also das Entladen verhindern möchte, setze ich Register 0x6c auf "0" bzw. umgekehrt. Das ist das einzige Setting welches ich bei Bedarf (Laden des Autos) ändere.
Verwendete Modbus Register:
Holding Register, nur Lesen: 0x99 - Discharge Period1 Start / 2 x uint8 in einem uint16 Wert (Hi=Minute, Lo=Stunde) 0x9A - Discharge Period1 Ende / 2 x uint8 in einem uint16 Wert (Hi=Minute, Lo=Stunde) 0x9B - Set_Chrg&DischrgPeriod2_Enable / unit16, 0=disable, 1=enable 0x9E - Discharge Period2 Start / 2 x uint8 in einem uint16 Wert (Hi=Minute, Lo=Stunde) 0x9F - Discharge Period2 Ende / 2 x uint8 in einem uint16 Wert (Hi=Minute, Lo=Stunde)
Holding Register, nur Schreiben: 0x6A - Discharge Period1 Start / 2 x uint8 in einem uint16 Wert (Hi=Minute, Lo=Stunde) --> 0000 0x6B - Discharge Period1 Ende / 2 x uint8 in einem uint16 Wert (Hi=Minute, Lo=Stunde) --> 0000 0x6B - Set_Chrg&DischrgPeriod2_Enable / unit16, 0=disable, 1=enable --> 0 oder 1 zur Steuerung des Entladens 0x6F - Discharge Period2 Start / 2 x uint8 in einem uint16 Wert (Hi=Minute, Lo=Stunde) --> 0000 0x70 - Discharge Period2 Ende / 2 x uint8 in einem uint16 Wert (Hi=Minute, Lo=Stunde) --> 5923
Nur mal so als Anregung, wie die Batteriesteuerung ohne Wechsel des Betriebsmodus der Anlage funktionieren kann.
docsnyder7
commented
7 months ago So weit brauchst gar nicht gehen... ich nehme alternativ 0x0025 WriteHolding "Battery1_DischargeMaxCurrent" und setze den beim Laden des EV auf 0 und hinterher wieder auf die A die man benötigt! oder du schreibst den aktuellen Soc der Hausbatterie in die 0x0020 "Battery1_MinCapcity", dann sperrt der WR ja auch das Entladen und hinterher wieder auf den Satndartwert
premultiply
commented
7 months ago und setze den beim Laden des EV auf 0 und hinterher wieder auf die A die man benötigt!
Prima, was "benötigt" denn jeder Anwender so?? Ich würde sagen 1, oder?
oder du schreibst den aktuellen Soc der Hausbatterie in die 0x0020 "Battery1_MinCapcity", dann sperrt der WR ja auch das Entladen und hinterher wieder auf den Satndartwert
Prima, was ist denn der weltweite Standardwert?
Alles was eine individuelle Benutzerangabe bzw. Anlagenkonfiguration benötigt wollen wir eigentlich vermeiden wo es geht, da dies zu Fehlern, bleibenden Veränderungen und ggf. Flash-Schreibzyklen führt.
docsnyder7
commented
7 months ago @premultiply da hast du vollkommen Recht...
meine Werte zb sind 0 und 15A sowie 25% beim MinSoc ich weiß ihr wollt von der yaml weg, aber evt hat der User ja hier die Möglichkeit den Ampere Rahmen einmal festzuelegen, der über den Schieber realisiert werden soll?
premultiply
commented
7 months ago Die wenigsten Nutzer werden die zu ihrer Anlage passenden Werte kennen. Erst recht wenn diese schon mal durch falsche oder unbedachte Einträge durcheinander gebracht wurden.
docsnyder7
commented
7 months ago Stimmt... was wäre denn, wenn man statt des manuellen Modus den Backup nimmt... der PV Ertrag würde in den Hausakku fließen und für die Zeit des Ladens mit "schnell" das Haus samt WB mit Netzstrom versorgt.
FalkRR
commented
7 months ago Alles klar, es gibt viele "Wege nach Rom". Aber ich bin immer ein Freund davon, die Settings so zu verwenden, wie sie auch gemeint sind. So eine Logik sollte auch jemand, der - aus welchen Gründen auch immer - sich die Anlage ansieht, verstehen (z.B. Herstellersupport). Daher bin ich auf die "Discharge-Period" Einstellungen gegangen. Diese sollten auch in allen Betriebsmodi gelten. Und ja, Einstellungen wie Min SoC oder Ladeströme kann man temporär verstellen, diese sollten natürlich wieder auf Standard zurückgestellt werden. Wie gesagt, mit dem bei mir verwendeten Release von evcc (0.123.5) wurde mir der Betriebsmodus von Eigenbedarf auf Backup umgestellt, was so nicht beabsichtigt war. Danach habe ich das evcc-Batterienmangement erst einmal abgeschalten.
daniell1
commented
7 months ago Stimmt... was wäre denn, wenn man statt des manuellen Modus den Backup nimmt... der PV Ertrag würde in den Hausakku fließen und für die Zeit des Ladens mit "schnell" das Haus samt WB mit Netzstrom versorgt.
So war es schon mal. Das geht aber nicht. Siehe meine Kommentare hier: https://github.com/evcc-io/evcc/discussions/9301#discussioncomment-8017495 Probier den Backup Modus mal aus, dann weißt du weshalb.
daniell1
commented
7 months ago Alles klar, es gibt viele "Wege nach Rom". Aber ich bin immer ein Freund davon, die Settings so zu verwenden, wie sie auch gemeint sind. So eine Logik sollte auch jemand, der - aus welchen Gründen auch immer - sich die Anlage ansieht, verstehen (z.B. Herstellersupport). Daher bin ich auf die "Discharge-Period" Einstellungen gegangen. Diese sollten auch in allen Betriebsmodi gelten. Und ja, Einstellungen wie Min SoC oder Ladeströme kann man temporär verstellen, diese sollten natürlich wieder auf Standard zurückgestellt werden. Wie gesagt, mit dem bei mir verwendeten Release von evcc (0.123.5) wurde mir der Betriebsmodus von Eigenbedarf auf Backup umgestellt, was so nicht beabsichtigt war. Danach habe ich das evcc-Batterienmangement erst einmal abgeschalten.
Bei mir geht er vom manuellen Modus wieder in den Eigenverbrauchsmodus zurück.
daniell1
commented
7 months ago Der Einspeisemodus wäre noch ein einfacherer Weg. Ist hier bei den Kommentaren beschrieben: https://github.com/evcc-io/evcc/discussions/9301#discussioncomment-8017495 Der setzt aber die Änderung seines SoCs auf 100% voraus.
docsnyder7
commented
7 months ago Stimmt... was wäre denn, wenn man statt des manuellen Modus den Backup nimmt... der PV Ertrag würde in den Hausakku fließen und für die Zeit des Ladens mit "schnell" das Haus samt WB mit Netzstrom versorgt.
So war es schon mal. Das geht aber nicht. Siehe meine Kommentare hier: #9301 (reply in thread) Probier den Backup Modus mal aus, dann weißt du weshalb.
hab ich... der WR sperrt den Akku gegen Entladung und der Solarertrag geht in den Hausakku.. aller Verbraucher inkl WB werden von Netzstrom versorgt... wie gesagt, ich hab noch eine G2, kann sein, dass bei den neueren Modellen anders ist
daniell1
commented
7 months ago Stimmt... was wäre denn, wenn man statt des manuellen Modus den Backup nimmt... der PV Ertrag würde in den Hausakku fließen und für die Zeit des Ladens mit "schnell" das Haus samt WB mit Netzstrom versorgt.
So war es schon mal. Das geht aber nicht. Siehe meine Kommentare hier: #9301 (reply in thread) Probier den Backup Modus mal aus, dann weißt du weshalb.
hab ich... der WR sperrt den Akku gegen Entladung und der Solarertrag geht in den Hausakku.. aller Verbraucher inkl WB werden von Netzstrom versorgt... wie gesagt, ich hab noch eine G2, kann sein, dass bei den neueren Modellen anders ist
Wie viel kwh waren in dem Speicher und welche SoS Werte waren für den Backupmodus konfiguriert? Was passiert bei dir, wenn du keine PV Leistung hast, bspw. nachts, und dann in den Backupmodus wechselst?
docsnyder7
commented
7 months ago Soc seinerzeit 64%, Grid laden deaktiviert, Backup zeit von 0 Uhr bis 22 Uhr Wo stell ich denn soc wert für den Backup Modus ein? Die Werte sind bei mir alle werkseingestellt… ich hab hier nix verändert, außer den Modus zu aktivieren bzw. deaktiviert… Warum sollte ich nachts in den backupmodus wechseln? Weil das Auto lädt?
Describe the bug
After setting battery discharge control to true, error
battery mode: modbus: length in response header '0' must not be zero or greater than '254'is thrown.Steps to reproduce
Configuration details
Log details
What type of operating system are you running?
Linux
Version
0.123.8