Open sterwen opened 5 years ago
Ok made a test stopping the bluetooth service and nothing is working, so it means that bluepy-helper is communicating with the dbus bluetooth service, but this looks obscure to me how
Additional testing result and some findings. The above phenomenon is due to an even received by the bluepy-helper but not sent back to the Python module. In the routine mgmt_scanning, a scnning end event is processed and the state is moved to DISCONNECTED but nothing is sent back to the Python that is waiting indefinitely for the response. Does anyone knows why this event ? What layer is raising it and upon what conditions ? Why no response sent back ?
Hello,
After long scan period (from few mn up to 10-15mn) the bluepy-helper do not send and advertisement back to the Python application and we sending the stop command a "device disconnected". Sometimes that error occur also on shorter scan but always during the stop phase. The error appears randomly in time but is certain for indefinite scans. It always happen after a certain time. Could we have a possible conflict with the bluez stack running also on the computer? (debian based machine). Has anyone experienced something similar ? (I guess yes, because there are issues with similar symptoms).
Related question: why is the bluepy-helper launch for each Peripheral (including Scanner), it prevent to have multiple GATT transactions interleaved ? At least it looks that having multiple concurrent transactions (Scan + GATT for instance) is not working. That could be understandable as each transaction has its own bluepy-helper executable instance that is making I/O on the hci socket. I suspect that transactions are messed up due to that, but I may have missed something.