I don't see "hex" in that image. As I said before hex is a presentation of a number. So my guess is when you send <16>003MD<13> to the device you get something back like:
<4>037111,222222,33,4,5,6666,7777,88,999<crc-code><13>
(^P is decimal 16, ^D is decimal 4 and <cr> is decimal 13 usually)
The ^D, <crc-code> and <cr> can't be converted to a string. You should check if you get ^D0037 before going on to read the string but it's still save to read the complete reply into a buffer until the <cr>. In that case you know you have the whole answer and otherwise you generate a timeout and repeat the command. You can use a array of bytes as buffer.
After that you should (optionally) check the crc against the string you received. Or you could live dangerously and just accept the string as is. You need to strip off that ^D0037 and <crc-code> (the <cr> shouldn't have been but in the buffer because it was an end of string code).
Then you can split the string on the "," and convert the hex (if 11, 22 etc where in hex value) to an integer (or other type).
You could just read the whole string like you do now and strip out the <33 and >125 but when there is incomplete communications this could lead to strange results in your database.
If I use serial (RS-232) to communicate with the Inverter then all the data is in plain text ASCII, but if you use USB then it seems that all data is transmitted in hex (not sure if this is always the case.
Data can't be transported as hex. It's ALWAYS transported as bytes. It's how you interpret the bytes that could be different. For instance:
Bytes: $68 $65 $6C $6C $6F is hello in ascii
But bytes: $31 $31 is 11 in ascii and you can translate that to an integer as eleven or integer seventeen if it's a hex-number in ascii
But first you need to interpret the result into a string before converting it to numbers. Because that protocol doesn't use straight numbers looking at the "," and the 0037 etc.