Alex Lisitsyn

@dmglogowskiOS, Thank you for this issue. It is a very good question. Unfortunately, the current API do propagate the error code to indicate an exception but do not provide the...

@dmglogowskiOS, I propose the workaround to add [the user error handler function](https://github.com/espressif/esp-modbus/pull/62/commits/17de1dd9dd265313a604ae765ff431198f813a8d#diff-dd92830e4ffcf57adb5d49bd716a026fea482b21638a01919a9be86cb9b472dbR494) to catch the exception code. It also allows to check the data buffers on user side (this can...

> I am unsure if it would be the best solution for my use case since I am working on a more object oriented (and C++ based) library based on...

> Obviously this second approach would definitely break the current API. This way will not be implemented. > I believe a possible way to handle this might be by adding...

Ok, good. This will be updated accordingly and let us keep it as a basic approach. I would keep the callback approach as well, because it can be useful in...

This [old CPP wrapper](https://github.com/alisitsyn/modbus_support/blob/mb_support/modbus_add_cpp_wrapper) will probably help you.

The issue has been fixed with commit 1eafc29df3d14ec379ea76f07337ae9816443e75

The component release is a bit postponed for now.

Hello @joaoviktor22, The Modbus `Function 43: Read Device Identification` is not supported by the stack. Usually vendors using the `Function 17 (0x11): Report Slave ID` command returning a free-form string...

@joaoviktor22 , Thank you for update and this feature request. This command will be added to the feature list with low priority.