Thanks for the suggestion @wattmatters, just tested and yes this prevents discharge but this doesn’t address the charging challenge.
I experimented with number.sigen_plant_ess_max_charging_limit as, and this is logical, if it’s set to 0, the battery won’t charge. If you set it to say 4.0, it will charge at that limit from solar and/or grid to hit that charging rate. There’s no way to say number.sigen_plant_ess_max_charging_limit = sensor.sigen_plant_grid_export_power so that grid export is 0 until SoC is 100%.
If you want to prevent any export to the grid but still have solar charging the battery, then set the export power limit to zero and leave the battery charge limit alone at default.
Just updated ESS, and it works like a charm.
The only thing I’m missing (and I get that it can’t be done via Modbus) is the AI intentions graph (like in the app). The Sigenergy AI works almost perfectly, but sometimes I know my day will be different than usual—like not being home in the evening or using a lot of energy after sundown. In those cases, I want to see the AI’s intentions so I can take manual control ahead of time. Having the AI intentions graph on my dashboard would make the whole setup perfect. I’ve tried displaying it as a webpage on my dashboard, but due to how the webpage is built (intentionally?), it’s not possible. Any ideas?
Sorry if this has been answered before. I am getting this when I try to add my AC Charger to HA
Modbus exception during read for register 32000 on 192.168.50.89: Modbus Error: [Input/Output] No response received after 3 retries, continue with next request
I had my charger replaced as the original which I added successfully was tethered. That was replaced and I removed it from HA and now trying to re-add, it is giving me the above error.
I have the charger as ID=1 and Inverter as ID=2. The inverter is added fine
I did get an answer, and no it doesn’t provide this information. At least it didn’t back when I was looking for it. I manage my (third party) PV curtailment manually and my own logic aligns perfectly with the curtailment provided from my VPP:
The below is a binary sensor template that will become true as the battery approaches full with negative feed-in, and latch true until the SoC drops a bit.
I also built in logic to disable curtailment when my cars are plugged in have a available SoC, as the cars are both solar charging, and the PV won’t increase generation until the cars start charging, unless I disable curtailment.
- name: export_curtail_flag
state: >
{%- set soc = states('sensor.sigen_plant_battery_state_of_charge')|float(default=0) %}
{%- set feed_in_price = states('sensor.amber_feed_in_price')|float(default=0) %}
{%- set current_state = is_state('binary_sensor.export_curtail_flag', 'on') %}
{%- set EV_charging = is_state('binary_sensor.ev_charging_at_home', 'on') %}
{%- set EV_wants_charge = is_state('binary_sensor.car1_ready_to_home_charge', 'on') or is_state('binary_sensor.car2_ready_to_home_charge', 'on') %}
{{ (soc >= 99.8 and feed_in_price < 0 and not (EV_charging or EV_wants_charge) ) or (current_state and soc > 99 and feed_in_price < 0 and not (EV_charging or EV_wants_charge))}}
Thanks for the prompt reply. Where do this excellent code sit in HA?
I am new to all this and whilst I have a working HA setup for heating, using standard HA integrations, I’ve not used any third party coding, integrations or blueprints.
Ah okay, well if you’re going to be using the sigenergy integration (I assumed you already were), then you’ll need (well, not need, but by far the easiest way) to get HACS. That’s not hard, but YouTube will help you out there. HACS is the tool for managing custom integrations.
There’s also then add-ons in home assistant that are stand-alone applications that are run by homeassistant that can do any number of things. Some of which are file editors (I use studio code).
You can use that to edit the configuration.yaml file amongst others. I’m really skipping a lot here, but I’m getting to the point quickly. You can use the template integration (Template - Home Assistant) to add new sensors to your home assistant instance. The code I pasted is the yaml, with some Jinja (called templating) that is the simple logic for a binary sensors (state will simply be on or off).
None of it is really that complicated and there’s heaps of guides and explainers on setting up your HA instance to run custom integrations and the basics of how to modify and add to the configuration file.
What I posted above won’t curtail your system, it’s simply a flag that you can use as an input for other automations.
Does HA use the inverter time? I am interrogating plant register 30000, that is documented as “epoch”.
I always get Time : 176959386 which means Wed 2026-01-28 10:51:00 CET.
It does not change. My inverter was installed in dec 25. Puzzled…
gewe
Thanks. We’ve not even bought the Sigenegy inverter yet. When we do I’ll go through the steps you suggest. I can probably manage i, given some time, as I’ve done coding etc. before. But was hoping to bolt together other people’s work rather then start coding from scratch. Looks as if there is enough previous work to build on. Thanks for all your efforts.
I am not able to change
number.sigen_plant_ess_max_discharging_limit
I first change
switch.sigen_plant_remote_ems_controlled_by_home_assistant
to ‘on’, and then change the value for discharging, but it says value out of range and then goes back to ‘0’? Is ‘0’ the same as disabled or is it no discharge allowed? ‘0’ seems to be default when I activate the entity.
My plan is to adjust this value to prevent discharging during charging my EV with Chargeamps integration. I still want Sigenergy to charge the battery as normal disregarding what the EV caherger does.
Any Ideas or successful examples?
Edit:
I noticed if remote ems control is active, then Sigenergy stops the complete control over the battery, so that is not the way to go to reach the functionality wanted.
Edit 2:
I have an automation done to be tested now, using number.sigen_plant_ess_backup_state_of_charge, will see if it works.
After restarting the system 3 times (other reasons) I discovered the clock works for a few seconds, so date and time changes, so the date is correct after restart, but the clock does not tick…
Also the inverter ↔ gateway communication uses an adress chosen at random,
not distributed by my router, and that seems to be the reason inverter and gateway communicates with ethernet broadcasts. Ugly and lazy…
Here I’m sharing the automation I use to prevent the Sigenergy battery from discharging while my EV is charging with a Charge Amps Dawn. This ensures that the car always charges from the grid, while the Sigenergy AI remains unaffected and Tibber Grid Reward continues to function as intended.
ChargeAmp’s My Charge Space integration is used for the EV charger.
I don’t garantee the funcionality, I will update the script if bugs are detected.
Explanations in Swedish. Script last updated 2026-02-14
alias: "Billaddning: Skydda Sigenergy"
description: "Låser Backup SOC vid laddning. Släpper vid stopp ELLER paus (Suspended)."
mode: restart
triggers:
# START: När laddning startar
- entity_id: sensor.[your_unike_itenty]_1
to: Charging
id: laddar
trigger: state
# STOPP: När laddning avbryts (Kabel ur)
- entity_id: sensor.[your_unike_itenty]_1
to: Available
id: stopp
trigger: state
# PAUS: När Tibber/Bilen pausar laddningen (NYTT!)
- entity_id: sensor.[your_unike_itenty]_1
to: SuspendedEV
id: stopp
trigger: state
- entity_id: sensor.[your_unike_itenty]_1
to: SuspendedEVSE
id: stopp
trigger: state
# UPPDATERING: När hembatteriets nivå ändras (för att uppdatera låset)
- entity_id: sensor.sigen_inverter_battery_state_of_charge
id: batteri_okar
trigger: state
conditions: []
actions:
- choose:
# SCENARIO 1: Stopp eller Paus -> SLÄPP BATTERIET
- conditions:
- condition: trigger
id: stopp
sequence:
- action: number.set_value
target:
entity_id: number.sigen_plant_ess_backup_state_of_charge
data:
value: 0
# SCENARIO 2: Vi laddar aktivt -> LÅS BATTERIET
- conditions:
# Körs antingen vid start ELLER om batterinivån ändras...
- condition: or
conditions:
- condition: trigger
id: laddar
- condition: trigger
id: batteri_okar
# ...MEN BARA om laddaren faktiskt står på "Charging" just nu!
- condition: state
entity_id: sensor.[your_unike_itenty]_1
state: Charging
sequence:
- action: number.set_value
target:
entity_id: number.sigen_plant_ess_backup_state_of_charge
data:
# Sätter backup till nuvarande nivå (fryser batteriet)
value: >-
{{ states('sensor.sigen_inverter_battery_state_of_charge') | float(0) }}
A note for those having trouble connecting to Modbus. I have the latest version of the HA software. I don’t have HACS installed. I can only connect to Sigenergy via Wi-Fi. The IP address entered in secrets.yaml is the one Sigenergy uses to connect to my Wi-Fi. The installer provided the image below. I have access to Sigenergy sensors.
I have been in contact with Sigenergy about the ugly broadcasts. Basically crippled my network. I had to spend to get unifi gateway and switches to isolate the traffic and this fixed the issue.
To cut the story short, Sigenergy refused to acknowledge there is an issue. They said these broadcasts are necessary for their system to work and basically told me there is nothing they can do or will do.
It’s a nice piece of kit but sadly let down by shitty software. I work in a software company and if I told my customers that you need to reboot the application every night to make it work, that’s rubbish and unacceptable
