What is Predbat doing here?

[Yuffi17]

Please can someone explain the following behaviour (or is this a bug?)

The image below shows server inverter reads for my hybrid inverter and battery. The filter is set to show both reads and writes and I don't see any writes (but the Predbat write counter works fine so I use this). I think I understand the top couple of entries - Predbat sets a charge to 100% going (although it seems confused about the end time?).
But earlier on, it seems to set a charge going from 01:00 to 01:30 and then keeps turning the charging on and off every few minutes - this results in a large number of writes on the write counter for what should have been a simple charging block... (see second image)

Inverter log

Writes

[gcoan]

The filter is set to show both reads and writes and I don't see any writes (but the Predbat write counter works fine so I use this)

the terminology of the GivEnergy portal log is confusing at best.

What this is actually showing is every time the portal detects that the inverter has a different setting to what was last sent via the GivEnergy app or portal. i.e. a local change has occurred direct to the inverter, and the inverter has been written to

It confuses matters by reporting these as 'reads' when in reality they are really just reads and detections of the changed status. But they all come from inverter writes, presumably by Predbat if nothing else is operating

It doesn't look correct, I don't see it on mine, enable AC charge only changed at the start and end of charging slots.

Can you check the givtcp log in case it is erroring with the command and share the predbat log as to what Predbat tried to do

[Yuffi17]

GivTCP log doesn't show any errors: log_inv_1.log
Here's the predbat log covering that period: predbat.log