Github Devices Community Docs Blog

BT device parsing for HM-10

While looking for ways to get OMG working with [BLE, RF, IR, BME280, PIR, Analog], I reviewed the BTtoMQTT() function of ZgatewayBT.

From my understanding, it looks like the function only parses the BLE packets once the BLEinterval has elapsed. Meaning that all of the serial data from the HM-10 is stored in the returnedString String until being parsed.
From testing, with the BT devices in my house, the returnedString grows to around a length of 800 before the BLEinterval elapsed and the string is parsed.

  • Is there a timing or other reason why the returnedString can’t be parsed once the OMG has received a complete packet for a BLE device instead of waiting until the timeout?

Using an old post by 1technophile, it shows that a packet ends in a CR LF. If we find OK+DISA (packet start) and CR LF (packet end) in returnedString, shouldn’t we be able to parse this part of the String, then remove it from the buffer?

On another note, I was reading an old article about using the String class and it mentioned reserving space for global strings to keep them from fragmenting in the heap. Has this been fixed in the ESP core, or should it be considered?

  • I don’t know much about fragmentation, so maybe this isn’t an issue?

I’ve implemented a proof of concept for the HM10 changes in case I’m not explaining myself well. (This version also moves a lot of values to PROGMEM using F() macros, uses strstr_P strcmp_P functions, and optimizes a few other functions for testing.)

1 Like


No there is no special reason, and I agree there is room for improvements.

It should improve the performances.

I’m not the more relevant to comment on this point.

Nice, feel free to submit a PR when you are ready and I will test it with my setup