Incorrect results, mixing of data, potentially resend the request...

[GerritJahn]

Thanks for this great piece of work! :-)

Tried to work with the library since yesterday - goal was reading some data from the inverter and publishing the same via MQTT - and found that the inverter, as described in the docs, does not always return correct or even any values back.

So one needs to check for existence, potentially compare against a valid data range, but most importantly look at the object_id which differs in almost all of my error cases between requested and received data!

Since I added a check for "requested object_id == frame.id" I did not see any further error with mixing data or so.

Would it make sense to implement this check within the library (somehow) and offer in addition a re-request-feature in order to allow to fetch the same data again (for a predefined number of tries)?

For the moment I just drop the data in the above mentioned case and all works stable and as expected. Of course the missing pieces could be easily changed to do what I need, but if the library would offer this feature, it might be even better (and more stable) - as otherwise everybody needs to write similar error-handling code over and over again :-)

Code Snippet looks basically as follows (mainly taken from the examples with some modifications before wrt range checks and so on):

     try: 

            # Check whether the inverter returns the same ID as requested which might not always be the case unfortunately:
            if object_info.object_id == frame.id:
                value = decode_value(object_info.response_data_type, frame.data)
                # Range-Check with pre-defined range, digits, factor as per own registry...:
                if value < min_range or value > max_range:
                    value = None
                else:
                    value = round(value * factor, digits)
            else:
                value = None

     except:
         value = None;

[pluskal]

We can confirm this behaviour live on a Power Storage 6.0 (BMS SW 5615): with a second client (the Home Assistant rct-power integration) polling the inverter concurrently, roughly every other unvalidated read returned a complete, CRC-valid frame belonging to a different object id — e.g. power_mng.soc_strategy reading 0 instead of the actual 5. So without the check the payload silently decodes to a wrong value for the requested OID, it is not just missing data.

Validating the response frame id against the requested OID (plus the CRC) and discarding foreign frames fixed it completely for us. do-gooder/rctpower_writesupport#45 implements exactly this pattern in the get path, in case it is useful as a reference.