Battery ignoring target charge limit

Is anyone else who charges their battery overnight seeing their battery charge to 100% despite it being set to charge to 80% or 90%?

The last 2 nights I set my battery (via the Battery API and via a local connection) to charge to 80 or 90% but both nights it has still charged to 100%. I verified that the target SoC was correct each time and confirmed it both nights via the API. It's been working fine for months. Wondering if it's anything to do with the recent maintenance mentioned by @Adam-Reynolds in another thread.

Anyone else?

chrisdev hmm shouldnt be, sounds like your API is turning AC charge on and setting the times but not setting the winter mode which is the basis around how it knows what percentage to charge too, what's your inverter SN i'll check the registers that actually changed and confirm.

chrisdev battery.api and local connection? Battery.api is a cloud based API. There is a local version of it via GivTCP but that is differnent. Which are you using? Local connection implies GivTCP

Battery.api has an audit, so GE can see a history of all calls made
Local is transparent, all GE can see is the current status of regsters. Local changes dont flush up to the cloud unless pushed

"Winter mode" is not a paramenter in the API calls. It just has <start>,<stop>, <SOC>. The process level API to "ChargeBattery" should do everything required to invoke the action

Adam-Reynolds Thanks Adam, my serial is CE2051G065 Let me know what you find. While you're there 🙂 could you take a look and see if I have a USB stick plugged into the battery ready for software updates please?

Seye I've previously been using the cloud battery API without issue to set 4 parameters each night (Enable AC charge, start, stop and ChargeTo %) but when I ran into the issue above I decided to try GivTCP instead to set the same parameters, with the same (unexpected) result.

chrisdev The signiture is the same ( by design), I just couldn't understand how you were doing it. No audit on the cloud if using GivTCP.
I use GivTCP mechanism too. I dont have any issues so must be something related to your installation

Adam-Reynolds As another data point, it happened again last night.

ChargeUpTo (and start/stop/AC change enable) was set to 80% at 21:00 via the battery API, and the API responded as such - it started charging at 22:00 as expected but it still charged to 100%. This method has worked flawlessly for months until 3 days ago.

chrisdev it is exactly that as I said previously, you're setting the charge ON, you're setting the times, you're setting the percentage.

But you're not turning the winter mode on. I'll ask one of the API guys to pop into this discussion to see if anything has changed from their side, as I don't deal with the API stuff.

chrisdev Your battery is reporting a USB drive installed.

chrisdev

Hi chris, the battery API has been hotfixed to include 'Winter Mode' which is currently what we use to cap the %limit of the battery instead of ac 1 charge times % limit. I'm unsure why your API was working for months but do respond back if you have any more issues with the % charge limit

Mickey (GivEnergy) Thanks both, appreciate the comments.

Apologies but I'm not totally clear on what I need to do to fix this. Do I need to turn on "winter mode" as I can't see any reference to it in the battery API documentation? (https://kb.givenergy.cloud/article.php?id=54). Is there another API end-point you can provide me?

The API should not touch wintermode. Mickey says it does now

If it is believed thats the issue you can set it on as suggested and see if it makes a difference.
You can manually set it on via the portal yourself. Inverter->Remote Control
Try immediatley charging to a percentage only a few above where it is now and see if it stops

You can then also run the API call you are using and see if its unsets the value

chrisdev

Hi Chris,

I've mentioned that this issue has been hotfixed. You should see the charge battery api work correctly now

So everything been working fine last couple of nights with the charge % set via the battery API. Then last night the battery was set to 60% which it completed and stopped as expected. But I decided to experiment and up the charge % to 65% using local control (GivTCP). Battery started charging again as expected, but continued on to 100% instead of stopping at 65%. Appreciate GivTCP is very much beta, so this is just an observation for expected behaviour vs reality for others who are trying to use local control.

not a helpful answer, but mine works fine.

To be fair its only charge to 100% currently as that what the calculations derive it needs. last spring/summer/ autumn the calcs we under 100% and it did stop at the popint requested.

I guess a bug could have been introduced in latest updates of the code

Also seeing the target SOC being ignored. Set to 75% via cloud - it's ignore overnight and charges for the full window. When I refresh in the morning, through the remote control portal, and it's charged to max and Target SOC is back at 100%. I'd like to set via GivTCP, but can't even get it to work through the native web interface.