I can write several numbers that are comma separated in a string and terminated with "\r\n", and all the appropriate individual characters are received. However, if the numbers have decimal places, the "\r\n" are never sent. The message may not be sent at all; I'm not sure because the device waits for the "\r\n" to report transmitted data.
I do not think this has anything to do with the decimal places specifically. It's more that the payload for a BLE packet is 20 bytes and once you've added the decimals your string it is exactly 20 bytes long before the \r\n. If the peripheral is waiting for an \r\n, e.g., because you a reading a line, then you may have to send a second message with that content. I think in a future version of the extension, we will make the WriteStringsWithResponse block use the response feature to implement a more proper streaming solution for messages of arbitrary sizes.
That's great. If it's a separate procedure it might be helpful to share the blocks (right click on the procedure and select Download Blocks as PNG) here so that others can use it in their projects.
Here's the splitting and blocking to 20 in a separate value procedure, in case you would like to try sending its output as a list all in one write, to see if the write block can accept a list of text segments.
That wasn't really the intent of the list input. Instead, it behaves like the other Write blocks and concatenates the contents of the list together. If you hit the payload limit then the string will be truncated. As I mentioned above, we should probably at least for write with response characteristics try to send all of the data in chunks.