Hello I'm hoping someone can help with this problem I've had for 4 weeks. I live in a very rural location in deepest darkest Lincolnshire and since a power cut every time the grid voltage goes to 248v and I'm exporting more than 1kw the pv cuts out. Even if I'm not exporting grid anywhere near 248v it stops. It's a gen 1 5kw hybrid inverter. Dsp 450 arm 453 firmware. The first trip says 260v but the inverter ignores this and does what it wants. If I start the car charging all is good, keeping the volts down below 248 limit. Never had this before. I have been doing register dumps to try and HR39 seems to do something only thing that I can see fault wise in the app is grid voltage 247.9 or grid 248v.
Which registers should I be looking at?
Oh it was here when I moved in a year ago.
Pv power cutting off at 248v
Re: Pv power cutting off at 248v
Can you compare the settings on your system to those shown here:
https://givenergymonitor.co.uk/inverter.html#grid
GivEnergy measurements are notoriously inaccurate, but if the settings are as follows:
Stage 1 = 262V
Stage 2 = 274V
General = 283V
Protection = 274V
then it shouldn't be cutting off below 253V.
https://givenergymonitor.co.uk/inverter.html#grid
GivEnergy measurements are notoriously inaccurate, but if the settings are as follows:
Stage 1 = 262V
Stage 2 = 274V
General = 283V
Protection = 274V
then it shouldn't be cutting off below 253V.
Re: Pv power cutting off at 248v
Thanks for replying.
HR64 = 270.7 V
HR72 = 260.2 V
HR79 = 261.0 V
HR83 = 261.0 V
But it still cutting the pv at 249, is there any other register that could be causing this?
HR64 = 270.7 V
HR72 = 260.2 V
HR79 = 261.0 V
HR83 = 261.0 V
But it still cutting the pv at 249, is there any other register that could be causing this?
- Attachments
-
- Screenshot_20260728-070500.png (180.89 KiB) Viewed 3237 times
Re: Pv power cutting off at 248v
This may sound crazy, but I think the General and Protection voltages are too low.
Your DNO won't help because 249V is below 253V and in the acceptable range.
I will work on a solution, but it will be for next summer. Shouldn't be an issue in the winter.
Your DNO won't help because 249V is below 253V and in the acceptable range.
I will work on a solution, but it will be for next summer. Shouldn't be an issue in the winter.
Re: Pv power cutting off at 248v
Thanks
What are the register numbers I should be looking at and I'll see if I can find a way to increase them a couple of volts
What are the register numbers I should be looking at and I'll see if I can find a way to increase them a couple of volts
Re: Pv power cutting off at 248v
If you can find a way to change register 83 from 2610 to 2740, I think that should fix it.
Be careful, if you were to accidentally set it to 274 (which would be 27.4V) it may brick the inverter.
Be careful, if you were to accidentally set it to 274 (which would be 27.4V) it may brick the inverter.
Re: Pv power cutting off at 248v
Thankyou so much
Ok with help from codex I've changed it
@'
import asyncio
from givenergy_modbus.client.client import Client
from givenergy_modbus.client import commands
from givenergy_modbus.model.register import HR
async def main():
client = Client(host="192.168.1.77", port=8899)
try:
await client.connect()
await client.detect()
await client.load_config()
address = client.plant.capabilities.inverter_address
before = client.plant.register_caches[address][HR(83)]
print(f"HR83 before: {before} ({before / 10:.1f} V)")
if before != 2610:
raise RuntimeError(f"ABORTED: expected HR83=2610, found {before}")
request = commands.set_v_ac_10min_protect(274.0, confirm=True)
await client.installer_command(request, timeout=2.0, retries=0)
await asyncio.sleep(2)
await client.load_config()
after = client.plant.register_caches[address][HR(83)]
print(f"HR83 after: {after} ({after / 10:.1f} V)")
if after != 2740:
raise RuntimeError(f"WRITE NOT VERIFIED: HR83 returned {after}")
print("SUCCESS: HR83 changed from 2610 to 2740 and verified.")
finally:
await client.close()
asyncio.run(main())
'@ | & "$env:TEMP\giv-hr83-venv\Scripts\python.exe" -
That means HR83 monitors sustained grid voltage rather than a brief spike. If the inverter’s internal measurement or calculation is substantially higher than the voltage displayed by GivTCP, a wrongly lowered HR83 could absolutely explain why it cuts out around an indicated 248–249 V, particularly while exporting.
More importantly, RubikCube isn’t suggesting an arbitrary increase. His app’s reference system shows:
Setting
Reference
Yours
Stage 1 upper
262.0 V
HR64: 270.7 V
Stage 2 upper
274.0 V
HR72: 260.2 V
General upper
283.7 V
apparently 261.0 V
Protection
274.0 V
HR83: 261.0 V
Your entire upper-voltage configuration looks thoroughly scrambled—possibly by that power cut. The official G99 document also gives approximately 262.2 V and 273.7 V for the two rapid overvoltage stages, which closely matches RubikCube’s reference values. ENA G99 specification�
So my conclusion is:
HR83 is highly relevant and 2610 looks wrong. Changing it to 2740 may well cure the fault.
But it must be written as exactly 2740, not 274. I wouldn’t write it yet until we first read and record the complete HR63–83 block, because several of your other grid-protection values also appear misplaced. We should restore the coherent profile, not alter one register blindly.
Let's see tomorrow when the grid voltage climbs towards 250
Ok with help from codex I've changed it
@'
import asyncio
from givenergy_modbus.client.client import Client
from givenergy_modbus.client import commands
from givenergy_modbus.model.register import HR
async def main():
client = Client(host="192.168.1.77", port=8899)
try:
await client.connect()
await client.detect()
await client.load_config()
address = client.plant.capabilities.inverter_address
before = client.plant.register_caches[address][HR(83)]
print(f"HR83 before: {before} ({before / 10:.1f} V)")
if before != 2610:
raise RuntimeError(f"ABORTED: expected HR83=2610, found {before}")
request = commands.set_v_ac_10min_protect(274.0, confirm=True)
await client.installer_command(request, timeout=2.0, retries=0)
await asyncio.sleep(2)
await client.load_config()
after = client.plant.register_caches[address][HR(83)]
print(f"HR83 after: {after} ({after / 10:.1f} V)")
if after != 2740:
raise RuntimeError(f"WRITE NOT VERIFIED: HR83 returned {after}")
print("SUCCESS: HR83 changed from 2610 to 2740 and verified.")
finally:
await client.close()
asyncio.run(main())
'@ | & "$env:TEMP\giv-hr83-venv\Scripts\python.exe" -
That means HR83 monitors sustained grid voltage rather than a brief spike. If the inverter’s internal measurement or calculation is substantially higher than the voltage displayed by GivTCP, a wrongly lowered HR83 could absolutely explain why it cuts out around an indicated 248–249 V, particularly while exporting.
More importantly, RubikCube isn’t suggesting an arbitrary increase. His app’s reference system shows:
Setting
Reference
Yours
Stage 1 upper
262.0 V
HR64: 270.7 V
Stage 2 upper
274.0 V
HR72: 260.2 V
General upper
283.7 V
apparently 261.0 V
Protection
274.0 V
HR83: 261.0 V
Your entire upper-voltage configuration looks thoroughly scrambled—possibly by that power cut. The official G99 document also gives approximately 262.2 V and 273.7 V for the two rapid overvoltage stages, which closely matches RubikCube’s reference values. ENA G99 specification�
So my conclusion is:
HR83 is highly relevant and 2610 looks wrong. Changing it to 2740 may well cure the fault.
But it must be written as exactly 2740, not 274. I wouldn’t write it yet until we first read and record the complete HR63–83 block, because several of your other grid-protection values also appear misplaced. We should restore the coherent profile, not alter one register blindly.
Let's see tomorrow when the grid voltage climbs towards 250
Re: Pv power cutting off at 248v
Bugger!!!!!
Just tripped at 249v!!!
Comparing my reg values to a working Gen1 capture HR80 is alot lower, ive upper it to match.. We'll see
HR80 ⚠ 2610 261.0 V — v_ac_high_limit_grid 2837 −227
Just tripped at 249v!!!
Comparing my reg values to a working Gen1 capture HR80 is alot lower, ive upper it to match.. We'll see
HR80 ⚠ 2610 261.0 V — v_ac_high_limit_grid 2837 −227