Feature Request: V2X / V2H Bidirectional DC Charger Manual Control (Start Discharge Session)

[heineherholdt1]

Feature Request: V2X Manual Control for DC Charger (Start/Stop Discharge Session)

Summary

The Sigenergy app exposes a V2X section with:

1. A "Bi-directional V2X operation" toggle
2. 2. An "Add Manual Control" button that starts a timed V2H/V2X discharge session (30/60/90/120 min or custom)
      These map to Modbus registers that are not currently exposed in the HA integration. As a result, V2H discharge cannot be triggered from Home Assistant — setting max_discharging_power_limit and turning on the dc_charging switch alone is not sufficient to initiate a V2X discharge session.

Setup

• Sigenergy inverter with DC Charger
• • Vehicle: BYD Sealion 7 (V2X capable)
• • • Integration version: v1.2.4
• • • • "Bi-directional V2X operation" is enabled in the Sigenergy app

What's needed

• Expose the V2X bidirectional enable register as a switch/select entity
• • Expose a way to trigger a V2X discharge session (start + duration), equivalent to the app's "Add Manual Control" — ideally as a button entity or HA action/service

Why

Without this, automating V2H (discharge to home when house battery is low and no PV is available) requires manually opening the Sigenergy app each time. The Modbus protocol v2.9 likely contains these registers — they just aren't implemented in the integration yet.

[TD944]

I have wondered about this too. The remote EMS mode now has an option for V2G although selecting this did not appear to change the charging mode in the sigen app.

[TypQxQ]

Only VG available from Sigenergy. Can't test it either because I don't have a Sigenergy charger.
Your request should be to Sigenergy to expose the functionality via Modbus. When they do, I will add it here.
They have ignored my emails since last year so you might have better luck.

[purcell-lab]

I have automated V2H & V2G using this integration.

Thus far I have been using the Command Discharging (PV First) option, which has also directed the DCEV to start discharging. I have been able to reduce Grid Export ESS discharging limits to 0W and to force V2H flow directly from vehicle to load.

I have also been able to get the ESS to charge the vehicle (Self Consumption) and get the vehicle to charge the ESS (but only when the EC is also producing solar).

The new V2G mode is also interesting, which seems to match the grid output to the vehicle output.

So many options and different methods.

[TD944]

Do you integrate the V2G with emhass or is it your own automation?

[purcell-lab]

Here is a good battery automation that takes the EMHASS states and controls the SigEnergy which includes V2G during the Command Discharging mode.

https://sigenergy.annable.me/automation/

[TD944]

Thanks. I use a variation of that which I have tailored. For instance I found that the original script would curtail production if it was above forecasted. Similarly on the export front instead of limiting the battery discharge I restrict the grid export limit. For my current use case I was planning on running my usual EMHASS plan and then activating the charging session if the export price was above a threshold. In the current setup because EMHASS is not expecting the V2G it may cap the export threshold at a limit based on the battery alone. I'm yet to experience a price spike since using EMHASS so we'll see.
It looks from your numbers like you are really pumping through the V2G capacity! I haven't been that game yet and really I am using V2G for the occasional spikes.
It seems like having EMHASS factor in V2G use would only be of marginal if any benefit for my use case but if you are running it daily it might be more worthwhile. Most spikes are so short lived it is quite reasonable to throw everything to 100% until it is over.

[heineherholdt1]

Hi I am the Sigenergy distributor for south africa and have a direct line to RND If you need anything to make it work better just let me know. I have attached the convo i had with them

…

________________________________ From: TD944 ***@***.***> Sent: Sunday, 14 June 2026 05:50:28 To: TypQxQ/Sigenergy-Local-Modbus ***@***.***> Cc: heineherholdt1 ***@***.***>; Author ***@***.***> Subject: Re: [TypQxQ/Sigenergy-Local-Modbus] Feature Request: V2X / V2H Bidirectional DC Charger Manual Control (Start Discharge Session) (Discussion #370) Thanks. I use a variation of that which I have tailored. For instance I found that the original script would curtail production if it was above forecasted. Similarly on the export front instead of limiting the battery discharge I restrict the grid export limit. For my current use case I was planning on running my usual EMHASS plan and then activating the charging session if the export price was above a threshold. In the current setup because EMHASS is not expecting the V2G it may cap the export threshold at a limit based on the battery alone. I'm yet to experience a price spike since using EMHASS so we'll see. It looks from your numbers like you are really pumping through the V2G capacity! I haven't been that game yet and really I am using V2G for the occasional spikes. It seems like having EMHASS factor in V2G use would only be of marginal if any benefit for my use case but if you are running it daily it might be more worthwhile. Most spikes are so short lived it is quite reasonable to throw everything to 100% until it is over. — Reply to this email directly, view it on GitHub<#370?email_source=notifications&email_token=B25HDCRDFW63ADNYJOZ4C7L47YOIJA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCNZSHE2DMMBQUZZGKYLTN5XKMYLVORUG64VFMV3GK3TUVRTG633UMVZF6Y3MNFRWW#discussioncomment-17294600>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/B25HDCW57C4H4LGHZWZJ3IT47YOIJAVCNFSNUABIKJSXA33TNF2G64TZHM4TGOJVGMYTSOJSHNCGS43DOVZXG2LPNY5TCMBSGQ4DMOBSUF3AE>. You are receiving this because you authored the thread.Message ID: ***@***.***>

[TD944]

I would be curious your experience with V2G with the sealion 7. At the moment I can export up to 2.5kW or so and then it cuts out. Are you getting the full 12.5/25kW output from the BYD?

[purcell-lab]

If you need anything to make it work better just let me know. I have attached the convo i had with them

Thanks,

My wishlist for Sigen DCEV.

• Uplift from OCPP v1.6j to v2.1 - bidi capabilities
• Expose more of the Sig V2G control modes from the app to modbus
• Enable the ability to reset the charge port after an error condition - currently this requires physically removing and reinserting the charging gun which is difficult for remote support. Maybe a limitation of CCS2.

[TD944]

Yes. They are all great. Especially the last one. I'm sure there are higher level alarms I haven't encountered but especially for things like abnormal charging stop (which is usually because the car is asleep) there seems to be no safety reason no to allow clearing the alarm.

[Roving-Ronin]

@heineherholdt1 Hi Heine,

If you could get Sigenergy to implement the GRID side voltage and current sensors originally detailed in modbus v2.8 (2025-11-20 iirc and then dropped in version dated 2025-11-25) it would be great!

Here's what was originally published (some of these register numbers have recently been reallocated and used elsewhere, such as 30286 that is now PLANT Average ESS Cell Temp.).

BTW would you know if Martha is still in change of R&D? Was working with her on a number of things (Shelly and also looking at support for ESPHome based devices that would massively open up the market for Power/Energy monitoring and automations and at better scalability and lower costs) and then Facebook killed my account of 15 years (posted a link to some yaml to help a new user) and that was the only method Martha used for comms.

[heineherholdt1]

Yes i can

…

________________________________ From: TD944 ***@***.***> Sent: Sunday, 14 June 2026 10:17:00 To: TypQxQ/Sigenergy-Local-Modbus ***@***.***> Cc: heineherholdt1 ***@***.***>; Author ***@***.***> Subject: Re: [TypQxQ/Sigenergy-Local-Modbus] Feature Request: V2X / V2H Bidirectional DC Charger Manual Control (Start Discharge Session) (Discussion #370) I would be curious your experience with V2G with the sealion 7. At the moment I can export up to 2.5kW or so and then it cuts out. Are you getting the full 12.5/25kW output from the BYD? — Reply to this email directly, view it on GitHub<#370?email_source=notifications&email_token=B25HDCQ4YZBLKCUXJINDMS347ZNPZA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCNZSHE2TSMBRUZZGKYLTN5XKMYLVORUG64VFMV3GK3TUVRTG633UMVZF6Y3MNFRWW#discussioncomment-17295901>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/B25HDCUMVLJH6S6UNI5OPST47ZNPZAVCNFSNUABIKJSXA33TNF2G64TZHM4TGOJVGMYTSOJSHNCGS43DOVZXG2LPNY5TCMBSGQ4DMOBSUF3AE>. You are receiving this because you authored the thread.Message ID: ***@***.***>

[heineherholdt1]

Yes Martha is still there. She is the product managerSent from my iPhoneOn 16 Jun 2026, at 06:37, Roving Ronin ***@***.***> wrote: @heineherholdt1 Hi Heine, If you could get Sigenergy to implement the GRID side voltage and current sensors originally detailed in modbus v2.8 (2025-11-20 iirc and then dropped in version dated 2025-11-25) it would be great! Here's what was originally published (some of these register numbers have recently been reallocated and used elsewhere, such as 30286 that is now PLANT Average ESS Cell Temp.). image.png (view on web) BTW would you know if Martha is still in change of R&D? Was working with her on a number of things (Shelly and also looking at support for ESPHome based devices that would massively open up the market for Power/Energy monitoring and automations and at better scalability and lower costs) and then Facebook killed my account of 15 years (posted a link to some yaml to help a new user) and that was the only method Martha used for comms. —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: ***@***.***>

[Roving-Ronin]

Ah yes Global Product Mgr, not R&D. Thanks

[heineherholdt1]

Reply from RNDHas discussed with R&D, the address for grid side voltage will be added into the new modbus protocal and firmware by the end of this monthSent from my iPhoneOn 16 Jun 2026, at 09:39, Roving Ronin ***@***.***> wrote: Ah yes Global Product Mgr, not R&D. Thanks —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: ***@***.***>

[Roving-Ronin]

Thanks for that Heine, to confirm just the voltage or current also ? BTW do you think that Sigenergy might also be able to make the modbus definitions documents available to all, as currently access is restricted to people with installer accounts (for which you have to be a licensed electrician to register for access). Allowing developers to gain access easily/rapidly would be of great benefit, verses the current situation of waiting for someone to 'leak' the latest release of said documentation.

This would allow developers doing (great) integrations like TypQxQ (Andrei) / https://github.com/seud0nym/sigenergy2mqtt and other Energy Management Systems such as EMHASS ( https://github.com/davidusb-geek/emhass ), Home Assistant Energy Optimiser ( https://haeo.io/latest/ ) and Energy Manager (https://energymanager.com.au/) and other supporting 'add-ons' that work with them like these cards I've published for all: https://github.com/Roving-Ronin/EMS-Events-Card

Once again many thanks, greatly appreciated !

[Roving-Ronin]

@heineherholdt1 Hi Heine, just wondering if you might have heard anything back from SIG R&D in regards these requests? Thanks !

[heineherholdt1]

I attached it in the previous replySent from my iPhoneOn 17 Jun 2026, at 05:03, Roving Ronin ***@***.***> wrote: Thanks for that Heine, to confirm just the voltage or current also ? BTW do you think that Sigenergy might also be able to make the modbus definitions documents available to all, as currently access is restricted to people with installer accounts (for which you have to be a licensed electrician to register for access). Allowing developers to gain access easily/rapidly would be of great benefit, verses the current situation of waiting for someone to 'leak' the latest release of said documentation. This would allow developers doing (great) integrations like TypQxQ (Andrei) / https://github.com/seud0nym/sigenergy2mqtt and other Energy Management Systems such as EMHASS ( https://github.com/davidusb-geek/emhass ), Home Assistant Energy Optimiser ( https://haeo.io/latest/ ) and Energy Manager (https://energymanager.com.au/) and other supporting 'add-ons' that work with them like these cards I've published for all: https://github.com/Roving-Ronin/EMS-Events-Card Once again many thanks, greatly appreciated ! —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: ***@***.***>

[Roving-Ronin]

Hi Heine,

Apologies for pinging you again, but would it also be possible to ask R&D if they might be also able to add:

1. A 'PLANT' sensor for:

• [ESS] Daily charge energy
• [ESS] Daily discharge energy

Currently there are the following registers but they are specific to an inverter, so there is no 'native' (i.e. poll a modbus register) method to obtain these readings for a site with number Sigenergy BESS installed in a plant.

2. For the ESS / Battery a sensor that is 'missing' is a register for the Inverter ESS (and Plant version?) for the Battery Current.
   Breaking it out into per module current, voltage, power, energy and temperature would also be great, if possible.

3. I'm not sure if Sigenergy would agree to this other one, but I know a number of people also have asked re the 'Self Consumption' of the Sigenergy unit itself, after seeing for instance 3000W from ESS, but the Load only being 2700W, hence 300W of Self Consumption, powering the EC and x number of ESS modules.

Currently you can manually calculate this power sensor (kW) and another for Self Consumption Daily Energy (kWh), but working to have integrations querying 'the official source of truth' (i.e. modbus register) versus 'calculated sensors, might be a better option?

Calculated Self Consumption (Power)

Calculated Self Consumption Daily (Energy)

---

@TypQxQ Andrei - Is it an idea for the other currently 'calculated' sensors to be officially published as registers, instead of having to do work arounds?

[Roving-Ronin]

@heineherholdt1 I'm thinking this might be worthwhile if you where to open a new dedicated discussion on issues/requirements for Sigenergy R&D / Modbus enhancements and fixes? Apologies again for piling it on, but just remembered this issue, that is becoming a brick wall that some countries users are speeding into, with mandatory implementations coming imminently.

I believe that South Africa uses fixed DNSP (i.e. Eskom) Grid Maximum Export Limits, that you get assigned as either zero-export limit or a percentage of the sites main grid breaker size, so you wouldn't have this issue. But in other countries (such as Australia), we have Dynamic Export Controls / Emergency Backstop / Commons Smart Inverter Profile (CSIP) being rolled out. For Energy Management Software this has/is causing major issues as Sigenergy modbus has register 40038 - "[Grid Point] Maximum Export Limitation".

When your only using fixed export limits this single register works fine, with the installer set export limit being stored and the user / Remote EMS then being able to enter a value (the same or less than the installer set value) that is stored in #40038.

The issue that arises though is when CSIP is used the DNSP sends out the dynamically changing Export Limit value and it is stored into this same register, meaning that is the user/Remote EMS has said 'no I don't want to export the CSIP maximum of say 30kW, I only want to export 1kW (as they aren't paying enough to warrant the export or the user's ESS SoC% is low)', then the users setting is overwritten by the DNSP's CSIP value.

As users already battling this issue has flagged: "Be aware of the Reconciliation Loop that occurs when the Sigenergy confirms the grid export limit with the network (happens every 10-15 mins), that will reset any ModBus setting back to the default export limit."

I believe this issue has been attempted to be flagged with Sigenergy but in near 12 months, no updates / communication has been heard to fix it. To fix this issue (that will get even worse in Australia with more states/territories about to mandate CSIP-AU in H2'2026) was to ask if Sigenergy could add an additional register for the DNSP's CSIP value to be stored in, instead of storing it in #40038.
Then to update the firmware logic to check and see:

• If Fixed Export Limit then respect the lower value of the DNSP Fixed Limit or the user/Remote EMS set limit, stored in 40038 (Current Firmware Process), else;
• If Dynamic / CSIP Export Limit, save CSIP value into a 'new register' whilst allowing user/Remote EMS value to also be saved to #40038, then check and apply the lower of the two register values.

If you could flag this also, it would be greatly appreciated. Thanks !

[heineherholdt1]

I have sent both requests to themAll 👍 Sent from my iPhoneOn 18 Jun 2026, at 06:42, Roving Ronin ***@***.***> wrote: @heineherholdt1 I'm thinking this might be worthwhile if you where to open a new dedicated discussion on issues/requirements for Sigenergy R&D / Modbus enhancements and fixes? Apologies again for piling it on, but just remembered this issue, that is becoming a brick wall that some countries users are speeding into, with mandatory implementations coming imminently. I believe that South Africa uses fixed DNSP (i.e. Eskom) Grid Maximum Export Limits, that you get assigned as either zero-export limit or a percentage of the sites main grid breaker size, so you wouldn't have this issue. But in other countries (such as Australia), we have Dynamic Export Controls / Emergency Backstop / Commons Smart Inverter Profile (CSIP) being rolled out. For Energy Management Software this has/is causing major issues as Sigenergy modbus has register 40038 - "[Grid Point] Maximum Export Limitation". When your only using fixed export limits this single register works fine, with the installer set export limit being stored and the user / Remote EMS then being able to enter a value (the same or less than the installer set value) that is stored in #40038. The issue that arises though is when CSIP is used the DNSP sends out the dynamically changing Export Limit value and it is stored into this same register, meaning that is the user/Remote EMS has said 'no I don't want to export the CSIP maximum of say 30kW, I only want to export 1kW (as they aren't paying enough to warrant the export or the user's ESS SoC% is low)', then the users setting is overwritten by the DNSP's CSIP value. As users already battling this issue has flagged: "Be aware of the Reconciliation Loop that occurs when the Sigenergy confirms the grid export limit with the network (happens every 10-15 mins), that will reset any ModBus setting back to the default export limit." I believe this issue has been attempted to be flagged with Sigenergy but in near 12 months, no updates / communication has been heard to fix it. To fix this issue (that will get even worse in Australia with more states/territories about to mandate CSIP-AU in H2'2026) was to ask if Sigenergy could add an additional register for the DNSP's CSIP value to be stored in, instead of storing it in #40038. Then to update the firmware logic to check and see: If Fixed Export Limit then respect the lower value of the DNSP Fixed Limit or the user/Remote EMS set limit, stored in 40038 (Current Firmware Process), else; If Dynamic / CSIP Export Limit, save CSIP value into a 'new register' whilst allowing user/Remote EMS value to also be saved to #40038, then check and apply the lower of the two register values. If you could flag this also, it would be greatly appreciated. Thanks ! —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: ***@***.***>

[twghacc]

My experience in the last couple of days using the 1.2.5 integration and the latest firmware and app from Sigenergy:

1. In the app the 'manual control' option that you see within the DC charger settings will start a session and export from the EV. It will ask you to stop any other active sessions.
2. Via the integration, changing to the V2G mode will start exporting to the grid but will not start a session (so it will export from the sigenstore). You have to start a session manually (as in toggling the 'dc charge' switch, not manually in the app) and then it will export form the EV. The order does not seem to matter.
3. The original "discharge" modes seem to export from the sigenstore and not from the EV. It will use only a small amount of kW from the EV (between 1 and 2) which does not seem to match the load or anything I could easily identify.

[Roppeleghs]

Really useful thread, thanks all — this answers a lot of what I was trying to work out

@purcell-lab purcell-lab and @twghacc - may I ask a couple of follow-up questions on your setups, if you don't mind:

1. Your reports seem to differ slightly on which mode actually pulls from the EV vs the SigenStor (purcell-lab: Command Discharging (PV First) drove EV discharge; twghacc: V2G mode exports from the SigenStor unless a session is separately started via the dc_charging switch, and the original "discharge" modes pull a strange small 1-2kW from the EV regardless). Is this difference down to integration version (1.2.4 vs 1.2.5), firmware version, or something else environmental? Trying to work out if this has stabilised or is still in flux.

2. Is EV-side SoC exposed anywhere via Modbus, or only charge/discharge power and connection state? I'd want a discharge floor for the vehicle (analogous to ess_discharge_cut_off_state_of_charge for the plants) if it's not on the Sigenergy side, would that have to come from a separate vehicle-specific integration instead?

3. @purcell-lab On the EMHASS integration via the annable.me automation: does that account for the DCEV as a genuinely separate dispatchable asset in the LP solver, or does EMHASS just see one combined battery_scheduled_power and the automation maps that onto whichever plant/EVDC combination achieves it? Trying to work out if this needs EMHASS-side changes or just HA automation changes.

4. Any early signs of battery degradation from daily V2H/V2G cycling, or is everyone still too early into this to tell?

For context, we're at the early planning stage (no vehicle hardware yet), looking at BYD + the 25kW EVDC alongside an existing two-plant Sigenergy + EMHASS setup. Our two plants alone (48kWh combined) weren't able to keep up with ground source heat pump demand on high-consumption winter days last year, so the goal is to use the EV as a genuine third dispatchable asset in daily Phase 2/3-style cycling (off-peak charge, daytime/evening discharge), not just an occasional emergency reserve. This thread has been the most useful evidence I've found so far on whether that's viable, so appreciate everyone sharing their experience.

[twghacc]

1. I'd say than more than the integration version the sigenstore firmware version is more influential on how the different modes behave. Up until the version ending in 111 (last October) using the discharge modes would export from the EV and you had to set the export limit to 0 if you wanted to charge the battery from the EV. Then in version 113 (Jan-feb) just starting a bi-directional session would immediately start charging the battery from the EV without further actions required. If you wanted to export you had to set the battery charge limit to 0 so it would export from the EV. This has once again changed in the latest firmware with the addition of the new V2G mode.
2. The EV SOC is a sensor in the DC charger device.
3. That would depend on the car. I have a 4 year old EV with 800volt battery. Before I got the DC charger it was reporting 100% SOH. Six months later still reporting 100%SOC. Granted, I am using a Wican ODBC dongle to read the ODBC and it could be wrong but that is what I got..

[TD944]

Which BYD are you planning to get? I'm using a Sealion 7 but it seems to cap exports at around 2.5kW (on a 12.5kW DC charger). Possibly the other models allow more.

[astrobilluk]

I'm new to HA controlling Sigenergy kit and have the EVDC 12.5kW. Thought I was going nuts not being able to find the control to switch between Fast/XSPV/Bi and also initiate a manual session. This thread is helpful - thanks guys. I've reached the towering heights of starting and stopping a DC charge session to my 2025 Ioniq 5 and the next task is to leave the app in Bi mode and see if I can get the flow direction right using other params from HA. I've subscribed to this thread and if I have anything useful to add from my own fiddling will do so. Could be a while.