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