Battery mode "charge" on FoxESS H3 Smart not usable

[stefan-juergens]

Hi,

i am using a FoxESS H3 Smart inverter.
The "normal" stuff is working well, but one thing is not usable.
I want do charge the battery at night - there the prices are cheap - but when I set the battery mode to "charge", the battery is loading with 0,44 kW - which is normal, because the inverter is in the working mode "self-use".
It is only possible to charge with full power when I set the inverter working mode to "Force charge".

But I can't set the inverter to this mode, because I am using cvcc to control the battery. I use EOS-connect and EOS-addon in HomeAssistant to optimize the battery charging etc.
And the EOS-connect uses only the battery mode from EVCC to set the "charge", "hold" and "normal" battery state.

So.... it is possible to change the template of then foxess-h3-smart template or create a custom template?
Maybe I can configure there what will happen by setting the battery mode. Then I can maybe use the modes to set the specific registers and change the working mode.
I tried to to this, but it seems that it is not working or I make something wrong :-)

Is there a way to achieve my plans?

Thanks
Stefan

[premultiply]

If you know what registers have to set for transition between normal, hold and charge mode it should be easy to fix it in the template.

[stefan-juergens]

Cool, can you help me?
I tried to create a custom template:

• type: custom
  name: battery-ng
  power:
  source: modbus
  uri: 192.168.178.156:502 # IP deines WR
  id: 247
  register:
  address: 39237 # Battery Charge/Discharge
  type: holding
  decode: int32
  soc:
  source: modbus
  uri: 192.168.178.156:502 # IP deines WR
  id: 247
  register:
  address: 37612 # Soc
  type: holding
  decode: int16
  batterymode:
  source: switch
  switch:
  • case: 1 # normal
    set:
    source: sequence
    set:
    • source: const
      value: 15
      set:
      source: modbus
      uri: 192.168.178.156:502 # IP deines WR
      id: 247
      register:
      address: 46611 # min soc on grid
      type: writemultiple
      decode: uint16
    • source: const
      value: 0 # Self-Use
      set:
      source: modbus
      uri: 192.168.178.156:502 # IP deines WR
      id: 247
      register:
      address: 49203 # Working mode
      type: writemultiple
      decode: uint16
  • case: 3 # charing
    set:
    source: sequence
    set:
    • source: const
      value: 15
      set:
      source: modbus
      uri: 192.168.178.156:502 # IP deines WR
      id: 247
      register:
      address: 46611 # min soc on grid
      type: writemultiple
      decode: uint16
    • source: const
      value: 3 # Force Charge
      set:
      source: modbus
      uri: 192.168.178.156:502 # IP deines WR
      id: 247
      register:
      address: 49203 # Working mode
      type: writemultiple
      decode: uint16
      capacity: 20 # kWh
      minsoc: 15 # %
      maxsoc: 100 # %

Yes, I know that the "case 2" hold is missing, but I wanted to test "normal" and "charge" first.
But this seems not to work.
If I set the battery mode through the REST API, the working mode is not changed.
Also after using the REST API to set the battery mode, I get then errors - something with "can't read battery mode...."
I also set the "min son on grid" in "charge" mode - this is not necessary, but change it back to "normal" mode I set it to 15%.
For mode 2 "hold" the standard way is setting the "min soc on grid" to the current SoC value, also setting the working mode to "self-use" - but it is possible to use the "current soc" as a value for the "min son on grid"?

I hope that explains a little bit.

It would be great if you can help me with the code.

Thanks a lot
Stefan

[andig]

If I set the battery mode through the REST API, the working mode is not changed.

Keep it simple. Use

evcc meter --battery-mode <mode>

evtl. noch mit Watchdog falls notwendig.

[stefan-juergens]

Sorry, was bedeutet "watchdog"?

[Gics78]

I'm interested in a solution of "Force Charge" in EVCC myself because I want to use all the feature in just one service. But it seems to be complicated (I am a noob) and is made even more complicated by FoxEss themselves.

In the meantime - as you are already using HA - have a look at the nathanmarlor
foxess_modbus HACS Integration! This I my go-to workaround too for setting Force Charge!

Concering the H3 Smart: Read this important thread too. Unfortunately I don't have a H3smart (only regular H3) and I am far from knowing how to apply registers myself but maybe this points you into the right direction. Happy new year!

[stefan-juergens]

Hi,
in HA the "Force Charging" is working for me - at night. At day when the PV is producing, the "Force Charging" uses ONLY the PV production.
Right now - as I know - there is now way to Force Charge from grid when the PV is producing from HomeAssistant.
I know, that only from the FoxESS App it is possible to set 2 different Charging periods where I can set "Load from grid".
But - as I know - no one knows which registers are used for doing this over modbus.

Tomorrow I get a LAN Switch with Port mirroring. I hope that I can track the LAN messages from the Inverter and the Inverter Internet module. Maybe I can trace the commands which are send to the inverter when I activate and set the 2 Charging periods.

But we will see.

Stefan

[Gics78]

1. Bist Du sicher dass Du über "Force Charge" in nathanmalor und nicht über EVCC arbeitest? Diese 0,44kw kommen mir nämlich sehr bekannt vor, siehe hier PS: für den Smart brauchst Du die letzte Beta (Stand now)

2. Meines Wissens setzt die von mir verlinkte nathanmalor Foxess Integration direkt Force Charge via Modbus um, aber wie gesagt, bin ein Noob und könnte mich auch irren! EVCC wiederum arbeitet über das Setzen des MinSoc, was nur "Maintanence Ladung" bewirkt.

3. ForceCharge/Discharge und die Ladeperioden sind zwei verschiedene Welten bei FoxESS, siehe auch die von mir oben verlinkte Grafik. Ladeperioden sind über modbus beim H3XX nicht möglich (sondern nur über web API, aber auch dafür gäbe es integrationen)

4. die folgende Einschränkung ist bei Force Charge bekannt: " If you Force Charge during the day, the inverter will prioritise energy drawn from the grid over PV energy, which means your PV generation will probably drop to 0." Das klingt aber nicht nach Deinem Problem.

Sorry für den switch nach Deutsch, ging schneller. Aber englisch wäre auch okay.

[Gics78]

Die Preisfrage ist nun:
a) Wie setzt die nathanmarlor Integration Force Charge/Force Discharge via Modbus um?
b) wie kriegt man das nach EVCC
...und damit ist mein Wissen leider am Ende!

[stefan-juergens]

Wir können auch gerne im Deutschen bleiben - ist meine Muttersprache.

In HA läuft alles soweit, da kann ich über "Force Charge" gehen.
Aber im Gegensatz zu deinem englischen Zitat, verhält es sich bei mir umgekehrt.
Am Tag, wenn ich PV produziere und ich Force Charge einstelle, wird NUR das von der PV Produktion genommen und NICHTS vom Netz.

Das mit EVCC ist korrekt - aber das Verhalten kann man ja vielleicht ändern :-) Doch über den Working Mode zu gehen - also Force Charge - bringt nur nachts etwas, nicht aber am Tag, da dort wie bereits erwähnt nur der PV Strom genommen wird.

Das mit den Perioden...
Da würde ich halt gerne wissen wie das Internetmodul mit dem Inverter kommuniziert - ich hoffe über ModBus.
Ich hoffe halt das über die Cloud das Internetmodul angesprochen wird und dieses dann die Kommandos über ModBus an den Wechselrichter sendet.
Morgen wie gesagt bekomme ich einen LAN Switch mit Port Mirroring, dann kann ich den Verkehr zwischen dem Internetmodul und em Wechselrichter trocken und dann mal schauen was man da so sieht und - ob man überhaupt was sieht woraus man schlau werden könnte.

[Gics78]

in HA läuft alles soweit, da kann ich über "Force Charge" gehen.

Sicher? Du nutzt ja gleichzeitig MinSoc. Funktioniert es auch ohne? Bisher war das nämlich das Hauptproblem und würde zu dem anderen Thread passen. Oder mach die Gegenprobe und schalte über nathanmarlor 1.14.0b3 mit tweak in Zeile 126.

Das mit den Perioden...

Da kannst Du Dich mal durch die Diskussionen in der verlinkten repo wühlen. Zumindest wurde das schon versucht bisher mit negativem Outcome (Ausnahme H1) - aber nur mit dem "normalen" HX ohne smart oder pro Es gibt eine handvoll repros die das über den API Key der FoxESS Cloud lösen. Ich hab das für mich verworfen, aber wenn Du es unbedingt benötigst wäre das ein Weg.

[stefan-juergens]

Hi nochmal,
Das mit dem HA ModBus tweak (line 126) - was war eigentlich genau deren Problem?
Das habe ich nicht wirklich gecheckt.

Kannst du mir das noch mal kurz erklären?

Gruß
Stefan

[Gics78]

Das mit dem HA ModBus tweak (line 126) - was war eigentlich genau deren Problem?

Kurzfassung: In der Nathanmarlor Integration funktioniert Force Charge "like intended", in EVCC leider nicht. Leider ändert FoxESS regelmässig etwas an den Modbus Registern, so dass es (gerade aus Sicht von EVCC, die natürlich auch noch andere Firmen abdecken müssen) schwierig ist hier kompatibel zu bleiben. Mit dem Hx Smart ist FoxESS mal wieder gelungen selbst die auf FoxESS spezialisierte Integration "zu zerschießen", so dass man bei diesen Geräten bis zum Erscheinen einer neuen Version diese eine Zeile selbst anpassen muss. Und vorsicht bei Firmware-Updates!
Ich persönlich mag eigentlich EVCC mit seiner GUI und "Kompaktheit", leider funktioniert es mit FoxEss aber nicht "as intended". Mit HA kann ich zwar alles abbilden, aber halt durch "Zusammenstöpseln" von verschiedenen Integrationen und add-ins. Aber das wird dann wohl meine Zukunft werden...

[stefan-juergens]

Hi,
ja das verstehe ich soweit.
Aber was bewirkt diese Zeile?
Ich meine was funktioniert dann besser - oder überhaupt?
Mir ist nicht das eigentliche Problem bei der HA Integration klar.

[stefan-juergens]

Hi,
ah.... jetzt hab ich es mit dem Tweak.
Nach der Änderung verhält er sich nun im "Force Chargiing" wie ich gerne möchte.
Jetzt lädt er auch vom Netz wenn die PV noch produziert.
Ist super.
Nun müssen wir nur noch EVCC beibringen bei den "Battery modes" über den Working Mode zu gehen und nicht über den min_soc_on_grid - das wäre dann eigentlich die Lösung!

Mal schauen ob das irgendwie hinzubekommen ist.

[Gics78]

Tja, da beisse ich seit langem auf Granit. Bzw. die Antwort war: finde die Lösung und dann submitte einen pull-request. Dein "Issue" ist ja auch zur Diskussion downgegraded worden obwohl es natürlich so in EVCC nicht funktioniert. Ich kann aber eben nur sagen der Weg den EVCC wählt funktioniert mit FoxESS nicht, aber ich bin leider nicht klug genug den Weg der nathanmarlor Integration technisch nachzuvollziehen (ich habe schon öfters das repro durchforstet, aber ich verstehe nur Bahnhof). Es ist leider auch nicht "one size fits all", weil selbst mit der nathanmarlor Integration neben Typ auch firmware-Versionen abgefragt werden müssen, weil FoxEss bei updates gerne mal an den Registern schraubt...
Nur so langsam weiss ich eben nicht mehr wozu ich EVCC eigentlich noch brauche, weil die Funktionalität eben eingeschränkt ist und ich alles "besser" in HA automatisieren kann. Auf der anderen Seite finde ich EVCC einfach nice... hassliebe

Der tweak für die H smart wird bestimmt in eine der nächsten Updates dort eingearbeitet werden, die sind eigentlich sehr flott.