I placed a loop at the demo runner. As soon as it shuts down it starts right back up again.
Expect: is that the BLE and separately MQTToverBLE portion will shut down cleanly, and be able to reinit on a new BLE network connection.
Happens: is that while BLE portion remains connectable, the MQTT portion is broken and non-responsive entirely. After intentionally causing the demo to end, or a timeout, the loop starts, demoRunner starts over, the BLE GATT still works on next connection, but it seems that the semaphore for the network is never triggered a second time. YES, BLE works and the GATT callbacks are fine, but there seems to be a very unclear tie in to the Network and the Service.
Check for yourself: iot_demo_freertos.c LINE 273. (202007 tag / release branch) This semaphore is received/given only the the first run through. Connect, timeout (30S for MQTT to quit), then set a break point on LINE 277 and reconnect. You won’t trigger on that reconnect because the network or some layer doesn’t seem to know you are there.
To get effect: Either connect and wait for MQTT’s establishConnection to timeout, or write a “1” on UUID A9D7…30000. This is the proxy’s “GO” signal, it’ll fail because there is no proxy there, but it’s faster than waiting. The software SHOULD be able to recover from this as well.
Similar topic… I would strongly recommend separating BLE and MQTToverBLE !! I need BLE all the time, I need BLEoverMQTT only when the phone has conenction. Right now they are basically the same service as BLE won’t even enumerate it’s characteristics properly without calling MQTT’s _establishConnection(…). You have a system that could easily separate the definition of ble services/characterisitcs and their callbacks. Maybe just define the BLE service entirely separate from “business logic” side?