Alternatywa dla przestarzałego pliku binarnego rfcomm w bluez

Od wersji bluez 5.44 pliki binarne rfcomm zawarte w bluez-utils (między innymi jak hcitool) są uważane za przestarzałe i od tej pory są zawarte tylko w pakiecie bluez-utils-kompatybil dostarczonym przez AUR.

Czy istnieje podobna aplikacja wiersza polecenia do łączenia urządzenia Bluetooth z portem szeregowym za pomocą modułu jądra rfcomm, czy muszę teraz używać PyBluez lub podobnych bibliotek?

Jeśli tak się stanie, jakie biblioteki Python 3 poleciłbyś?

A jeśli ktoś wie, proszę powiedz mi, dlaczego tak wiele bluez-utils nagle uważa się za przestarzałe. Nie mogłem nic na ten temat znaleźć.

ArchWiki zaleca wdrożenie funkcjonalności rfcomm przy użyciu nowego profilu D-Bus 1 API .

Niedawno znalazłem projekt bluez-tools , którego celem jest zaimplementowanie utraconej funkcjonalności przy użyciu obecnego interfejsu API Bluez D-Bus.

Bluez-tools jest dostępny na ArchLinux z repozytorium społeczności. Nie testowałem tego, a strona github stwierdza, że ​​wciąż jest w fazie beta. Ale zgodnie z dokumentacją, bt-serial powinien być w stanie zastąpić stary bluez rfcomm i bt-adapter + bt-agent + bt-device mają funkcjonalność hcitool.

Edycja: Patrząc na listę problemów i ostatnie zatwierdzenia, narzędzia bluez nie wydają się już aktywnie utrzymywane.

Znalazłem inne możliwe rozwiązanie. Znalazłem to, przeglądając czyjąś repozytorium git hub. Używa to wbudowanego modułu gniazda Python3.

Wymagania wstępne:

1. Masz działający adapter pod adresem <adres adaptera>.
2. Masz docelowe urządzenie Bluetooth w <adres urządzenia>.
3. Urządzenie jest przypięte.

Oznacza to, że można użyć tego samego rfcomm.

$python3
>>> import socket
>>> sock = socket.socket(socket.AF_BLUETOOTH, socket.SOCK_STREAM, socket.BTPROTO_RFCOMM)
>>> adapter = '00:11:22:33:44:55' #<adapter address>
>>> device = '55:44:33:22:11:00' #<device address>
>>> sock.bind((adapter, 1))
>>> sock.connect((device, 1))
## If not pinned it will ask you. You can use/adapt the bluez simple-agent for headless pinning
>>> sock.send(b'hello\n')
>>> sock.recv(100)
>>> sock.close()

chcę zwrócić uwagę na ten problem:

1. że ten projekt github zawiera niektóre funkcje rfcomm. (na podstawie plików testowych bluez).

2. Sam projekt bluez nadal zawiera plik rfcomm.c, który można łatwo skompilować za pomocą:

   gcc -lbluetooth rfcomm.c -orfcomm -DVERSION = xyz

... tylko jeden plik, nie trzeba kompilować całego projektu bluez. gdzie xyz jest wersją pobranego kodu źródłowego bluez tar.xz (teraz jest 5.46). przed pobraniem należy najpierw sprawdzić własne bluetoothd -vi pobrać pasujące źródło. bluez-libs jest zależnością tylko od powodzenia kompilacji.

Potrzebowałem rfcomm dla armv7 (raspberry 2) i nie ma pakietu aur dla rfcomm, i to był jedyny sposób, ale działa dobrze.

Nadal nie jestem pewien, dlaczego rfcomm jest przestarzały, bez dobrej alternatywy i jak rozmawiać z bluetooth, ponieważ był to port szeregowy w inny sposób. Ponieważ nawet jesteś ekspertem Pythona i ekspertem DBUS ... (jak zapewne wspomniany powyżej właściciel projektu prawdopodobnie) ... wciąż tylko w ten sposób udostępniono tylko fifo, a nie prawdziwe urządzenie postaci w / dev / ... że wszystkie inne programy (jak arduino ) może zobaczyć i pracować z.