Problem with paring M7 Inteli #25
Comments
|
Hi Robert, this is most likely something wrong with the bluetooth library or on os level with the bluetooth connection and pairing. From my testing only very specific sets of bluez, bluetooth adapters and linux kernel versions did work. If you have the possibility please test with win10 to rule out the operating system as the cause, Best |
|
Hi @userx14 I am using Debian 12, I am using ssh console, for this you need a graphical mode ? PS. I also tested on BT 4.0 (Cambridge Silicon Radio) and the same problem. BR, |
|
Hi Robert, If I remember correctely, you could use bluetoothctl on the terminal, but you need to do this simulteneously to running the python script with something like a terminal multiplexer. The Camebridge Silicon Stick will work on linux, but NOT on Windows. ATS2851 sounds fine for both OS. Regards, |
|
Unfortunately, it doesn't want to pair: Which version of bluez are you using ? Is it possible to read data without pairing ? BR, |
|
BT 4.0 works better than BT 5.3, at least with bluetoothctl: BR, |
|
Now your script returns this: |
|
Hi Robert,
I think it was an old ubuntu version with bluez 5.55. You could also try ubpm, he uses the QT Bluetooth library.
You need bluetooth pairing to work, in order to read out the data.
This still looks like some error in the bluetooth library (_wait_for_services_discovery). Regards, |
|
@userx14 Thanks for your reply, Download data works: Now I need to figure out why it doesn't work on x86 virtual machine with BT 4.0 (and 5.3) with Debian 12 64bit, maybe some ideas ? BR, |
|
I made a clone of the MAC address of the paired BT 4.1 Raspberry PI and changed the MAC to BT 4.0 (other machine) on which the omblepy reading does not work. BR, |
|
I'm not really sure what it could be, but it is interesting that you got it working with a pi zero w. Maybe you can find a difference when you try to look at the communication with the bluetooth stack: Regards |
|
HI @userx14 I came to the same thoughts, that it is the fault of BT firmware or drivers. I will continue to fight with BT :) BR, |
|
Same problem with BT5.0/5.1 on RTL8761B chipset, with btmgt at ombley launch, I even tried to confirm pairing: BR, |
|
Hi, @userx14 I got a good scan just not sure what else helped :) Bingo! works with BT4.1 (Cambridge Silicon Radio) i BT5.1 (RTL8761B) - If bluetoothctl console is enabled then everything works, just how to solve it permanently? It is necessary to remember that the BT of the phone with the app should be turned off because the Omron disappears from the possibility of reading data when the app connects to the Omron. BR, |
|
Looks like this problem: Workaround does not solve this problem: Interesting article works correctly bluetoothctl and bt-agent tool: There is another problem with BT5.3 - ATS2851 chipset: BR, |
Not sure how a permanent fix looks like,
Probably the omron does not support multiple connections, sounds as expected. |
|
The workaround for the problem is very simple to script in bash: An additional issue, Omron sends data only 2 times data - after establishing a connection 2 times and then disappears from transmission. BR, |
|
Hi Robert, thanks for posting the bash script, I think I should add a note about running bluetoothctl to the readme of this project.
Does that mean that only two records are sent, or that after the second time reading all the records, the transmission does not work anymore? And what part stops working, the pairing process, the unlocking process or the data readout? Regards, |
|
This is probably the nature of Omron, when it connects to a paired device, it sends all the data, and then it disconnects and disappears from the search? This is not cool when you have a paired phone and omblepy, because the phone will establish a connection faster and even when it downloads the data it doesn't have a chance to download through omblepy. BR, |
|
I think it does poll the omron from time to time so that it can automatically synchronize new data. Can you disable this in the omron app options (auto synchronization)? To be fair, omron very likely didn't plan for third party readout tools. Regards, |
Trying to pair but no luck :(
The text was updated successfully, but these errors were encountered: