I have setup my AIO to export to the grid for Octopus flux peak rate. I've setup a giv-tcp-style program that automatically starts/stops the discharge and varies the rate to leave 40% at the end.
I am currently using the "battery discharge power" setting to restrict the rate, but since this doesn't account for house usage I'm currently refraining from setting it lower than 4kW. This is not ideal for two reasons:
If the house demand is more than 4kW then we will end up importing
I'd like to be able to set this lower so I can start earlier but slower
Is there any way to tell the inverter to limit itself by the export rate instead of the discharge rate?
Thanks.
D
#2DD
systemparadox Not that I know of. It's something I suggested quite a while back (although it was more along the lines of adding a bias to eco mode, so that it covered house load plus a fixed amount extra, which amounts to the same thing).
When you say "giv-tcp-style" - what exactly is that ? If it's modbus-based, I've been working on external control for a very similar problem (related to tuning charging rate to avoid clipping). I have actually been considering adding extra code to detect import during a fixed export, in order to adjust the discharge rate upwards.
Using the api for this sort of thing is much too slow. But I do use the API to kick off a similar sort of discharge - calculate a suitable discharge power to leave a fixed percentage at the end.
S
#3systemparadox
Yes it's modbus-based. giv-tcp and givenergy-modbus were far too overblown and messy for my liking. I never even managed to get giv-tcp to work. The current givenergy-modbus seems to be having a massive rewrite and doesn't work either. The only thing I managed to get working was the givenergy-modbus inside the giv-tcp repository, but even that is just a confusing mess of python dependencies. So I've written my own zero-dependency version in pure NodeJS. It's not quite ready but I do intend to release it soon.
I'm only polling every 5 minutes which is plenty for what I want. I did briefly consider whether I could do something about this if I ran it faster but to be honest there's already enough of a delay in the inverter responding to changes in demand, I'm not really keen on adding a further delay and tying it so closely to an external process.
It's interesting that you say "bias". One of the things I have been wondering about is whether there would be some advantage in being able to keep a small export rate to give the eco mode a bit of "extra pressure" to help compensate for the delay in the inverter ramping up to an increase in demand.
What do you mean by clipping on charging?
D
#4DD
systemparadox The current givenergy-modbus seems to be having a massive rewrite and doesn't work either. The only thing I managed to get working was the givenergy-modbus inside the giv-tcp repository, but even that is just a confusing mess of python dependencies. So I've written my own zero-dependency version in pure NodeJS. It's not quite ready but I do intend to release it soon.
Oh, that's a pity - a few of us have just started working on bringing givenergy_modbus back to life. (And I'm actively trying to reduce external dependencies.) [I'm also resisting adopting home assistant, since that seems an awful lot of overhead to run a fairly simple script.]
It's interesting that you say "bias". One of the things I have been wondering about is whether there would be some advantage in being able to keep a small export rate to give the eco mode a bit of "extra pressure" to help compensate for the delay in the inverter ramping up to an increase in demand.
Yes, that was exactly what I had in mind when I suggested it. But if the bias is set big enough, it would amount to an export that still responded if house load increased. https://community.givenergy.cloud/d/2155-suggestion-eco-mode-with-net-export
It's really something that has to be done by the inverter itself, and should be trivial since it should just be a minor tweak to what it's doing anway.
