Unexpected calibration

Twice in the last few months my battery has done a calibration (charge only). Both started at 5:31am which is just after my battery charge period ends.

I have a 9.5kWh battery and AC3 inverter and also use GivTCP on Home Assistant. I'm pretty sure this wasn't started by GivTCP, at least not by any of my automations.
I'm on battery firmware 3020 and inverter firmware DO.212-AO.212. The inverter was on firmware 210 the first time this happened. I had done a firmware update just before the first occurrence.

Is this normal. If it is, what triggers it?

Thanks.

andydsmith there was speculation a while back that random calibrations happen due to garbled messages from local controls. Perhaps if they coincides with remote messaging. A checksum got added to the message format to try to reduce this (?).
I hadn't heard of it happening for a while, though.

Is anything recorded in the activity log on the portal?

DD Thanks for the reply. I'm not sure where to find the activity log on the portal, but there is a notification to say that the calibration is finished.

I think that actually this must be linked to my Home Assistant automations. Both times it's happened the car has been charging and I think both times a new charge slot has started at 05:30. This triggers my automation to pause battery discharge. The GivTCP stats show two writes at this time, but there should only be one. I assume the second must have triggered the calibration, but I can't find anything in my automation that would have done this.

This automation runs every time I get an extra cheap charge slot, but I have only had the spurious calibration at 05:30am, which is the time my battery charge period ends. It may be that it only happens if the car is not charging before 5:30 and then starts at 5:30. This was what happened most recently, but the first occurrence is to long ago for me to check. It's going to be difficult to pin down if this is the case as I can't force this to happen.

andydsmith Put a delay of a minute or so between charge slots being changed and the battery pause.

The data corruption is likely caused by too many write requests on the modbus so putting a delay between trigger and action* is always a good idea. I tend to use values between 90-120 seconds.

*multiple actions from a single trigger should get a delay between actions as well, especially if it involves the battery.

andydsmith I had my second such callibration today at 05:01. I have a Gen 1 Hybrid Inverter.
Although I use HA and GivTCP there are no writes from GivTCP as I'm on Intelligent Octopus Flux.
There were some updates from Octopus in that minute to trigger a charging session so perhaps the API has a problem as well.
We lost about 50% of our generation today as the inverter stopped processing PV and Octopus had set the discharge rate to 737W.

SJB perhaps the API has a problem as well.

givtcp and the API use much the same mechanism: the dongle is effectively a tcp to modbus gateway, and it does the actual serial comms to the inverter.