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
returnedStringcan’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.)