Incorrect sensor values

[charles-sd]

Hey folks!

I have been running this integration for the past month and a bit. Thank you and great job @StephanJoubert !
I am running a vanilla configuration of the integration installed via HACS, and connecting to a new Deye 8k inverter using the included LSW-3 WiFi Logger.

I have also created some automations using the sensors, but found that they misfire several times per day due to incorrect data. This happens when my WiFi logger experiences signal problems. I would expect potential gaps in data, but factually incorrect data is being reported instead, tripping up my automation logic.

Example:
I am attaching a history graph to demonstrate the problem. The 'status_connection' sensor has some gaps. I accept this is the reality that comes with a mediocre WiFi signal. What I was not expecting however, are the small blips of incorrect data that coincides with this. These can be seen as the Battery SOC dropping from 100% to 0% several times, and the 'Grid-connected status' briefly changing to Off-Grid multiple times. In this example there was a true Off-Grid event from 06:00 to 08:10. The inverter was not Off-Grid at any other point during the day.

It does not appear as if this integration has any trace logging available. I plan to look at the code and try debug as I suspect this is the state not being correctly maintained when an error occurs. Unless anyone can point out another way to fault find this?

[charles-sd]

Okay, I think I have found a race condition that causes the problem I am experiencing.

After adding extensive debug and tracing code, I could observe the network communication and identify what was happening. The underlying implementation of Modbus over TCP does not include logic to match each request message to a response message. It is not quite robust enough to correctly handle special cases of slow or erratic network communication.

Example:
My inverter definition causes two requests to be sent with each poll, as the registers are contained in two blocks. Let's call them Register Block A and Register Block B. Note that these blocks are not of the same size, which helped me spot the problem quite easily.
Sometimes (I assume when the WiFi signal is not great) the response messages don't arrive or are slow to arrive over the network. The integration will then time out and retry sending the requests that it is busy waiting on. It may send multiple request and the inverter may respond multiple times, even after the integration has timed out and moved on.
The integration can therefore receive the last response for Register Block B, when it has just requested and is waiting for Register Block A. Unfortunately, it assumes this response is for Register Block A and starts unpacking it blindly. This results in the incorrect values being assigned to sensors, as they are effectively being read from incorrect registers. This even happens when the number of returned registers are clearly not the same number as those requested.

I am busy wrapping up a basic code change to implement validation that will result in unexpected responses being discarded. This will stop values being incorrectly mapped to sensors. PR to follow.