Command Corruption

I have some evidence that very occasionally ( less than 1% of the time) a command (sent from the portal/app and possibly givtcp) can be corrupted by the time it reaches the inverter. Usually this will result in the command not being actioned because the corruption has resulted in an invalid/harmless command. However very occasionally (again probably less than 1% of the time) the corruption will cause the inverter to restart, or kick off a battery recalibration, or some other unexpected action.

Has anyone else got any evidence of this happening?

Yes. I had my system perform an uncalled for battery calibration, which started just after I'd been amending the 'charge to' setting for the night. Didn't notice it start, presumably because I was using the portal with it's minutes long update cycle.

I've also had the battery mysteriously decide to stop supporting the house load just after midnight (when we were asleep). Refused to behave properly despite numerous resets etc. the following morning. Phoned the helpline and they decided it was actually flat (state of charge bug) so kicked off the software update & calibration. I was doubtful that was the case and I was proven right by it taking 3 hours to discharge to the grid (9.5kWh pack, max discharge rate), suggesting the indicated charge of 80% or so was about right! Following the subsequent full charge it did then work correctly though, so I guess whatever register was corrupted got reset in the process.
It's all made me a bit worried to use the portal, despite it all working fine since install last summer and throughout the winter until this weirdness started a couple of months ago.

From time to time (can't figure the schedule) the portal sends time synchronisation commands to the inverter shortly after midnight. I see them on my firewall, but they aren't logged anywhere as far as I know.

@TheDragon (GivEnergy) Mentioned something about CRC checking in commands in the new version, so maybe it's a real issue.

My understanding of the "network" on the Inverter is that all incoming Modbus TCP/IP commands are converted to RS485 serial and sent to the inverter as a stream of bytes by the 'dongle'. The problem with this is that if you have two devices sending commands at the same time (e.g. the app locally, and the portal) then it's possible that the commands get intertwined, because TCP makes no guarantees about how data is split between packets, and the dongle doesn't understand the structure of Modbus packets so can't prevent this.

rjp My understanding of Modbus is that there is one master device and many slave devices. The master is in control of the bus and slave devices respond to data requests from the master when it issues a request with the slave address in the packet. This process should mean that there is only ever one device transmitting data on the bus at any one time. Doesn't mean a packet can't get corrupted, hence CRC. Perhaps @TheDragon (GivEnergy) or some Modbus guru can advise whether the inverter or dongle is the master device or if Modbus over TCP means the dongle gets to speak up if the bus is quiet.

Tim Yes this is why CRC is now enforced going forward.