Ok so, looking at my logs from Admin_StateChange,I can see that my app behaves perfectly fine when I encounter the expected chain of events when I restart the bluetooth module. This is the expected chain of events I usually see:
** Service (unit_comms) Start **
admin statechange. old = STATE_ON new = STATE_TURNING_OFF
admin statechange. old = STATE_TURNING_OFF new = STATE_OFF
admin statechange. old = STATE_OFF new = STATE_TURNING_ON
admin statechange. old = STATE_TURNING_ON new = STATE_ON
StartListen2
listening
connected: true
and, I noticed that there is a deviation from this just before my listen call creates an exception, in this case, the states encountered in Admin_StateChange go like this:
** Service (unit_comms) Start **
admin statechange. old = STATE_ON new = STATE_TURNING_OFF
admin statechange. old = STATE_TURNING_OFF new = STATE_ON
StartListen2
listening failed
So the state goes from STATE_TURNING OFF straight to STATE_ON when the problem occurs, whereas usually, it goes from TURNING_ON to STATE_ON.
Why's it doing that?!?
I tried to change my code so that the trigger to listen is 'oldstate = TURNING_ON AND newstate = STATE_ON' instead of merely 'newstate = STATE_ON', but then it never listens when it does the TURNING_OFF to STATE_ON thing as that mix of states does not occur.
Any help graciously received!