... But cheap comes at a prize. Now that we find ourselves wanting to fine tune the module, we find a stumbling block in the module's sloppy interface, and obscure documentation. All that we have to work with is a PDF document (that has obviously been the product of an automated translation) describing AT commands to interface with the module's processor. Just look at a particularly... brilliant? extract from the document, and judge yourself:
7.1 Send "I am iron man, I am iron man, I am iron man, I am iron....." string. Yes, that is a joke, in sleep mode, you can send a long string (Length > 80 or more), that string can made module wake up, and you will receive "OK+WAKE" string through UART.
There are some alternative open source firmware projects for HM-10 that might be more helpful, but don't seem to be mature enough. So we are considering trying with a different Bluetooth module as an alternative, one that is less obscure and better documented.
This alternative is also not hassle free. The problem with Bluetooth modules is that each of them comes with it's own firmware, and it's own particular set of options and AT commands to interface with it. So if you write any code targeted at interacting with the Bluetooth module, it needs to be customized for the particular module that you are using. You cannot simply swap hardware keeping your code intact, which is not great for testing the different options.
It's also not great when you go and try to find guidance in the source code of other projects using Bluetooth with Arduino: each of them deals with Bluetooth differently depending on the module used; and often to understand it you need to study the specific module's documentation first.
We are quite frustrated about this, because it's a problem that the Arduino community has definitely solved with screens. Screens are a similar case: each of them is particular, has different characteristics, and has it's own way of interacting with it. But as with Bluetooth, they talk to Arduino via a serial interface, and "sort of" they function in the same way, despite their differences (it's all about switching pixels on an off, no matter the size of your screen). It would be a nightmare to program them if it were not for the amazing u8glib library, that abstracts away the nitty gritty details of each particular screen, and lets you interact with a broad set of them using a common high level interface.
Surely it must be possible to construct something similar for Bluetooth modules: their differences are smaller than their similarities, and can ceirtanly be abstracted into a higher level interface. Anyone looking for a challenge to work into?