Closed rchovan closed 2 years ago
Did you check #738?
Yes I read it, my device is using firmware with different version. It works randomly and for some time. I'm not sure where is the issue .
HA stopped
root@nas:~# hcitool lescan
LE Scan ...
0F:E6:5A:14:18:41 (unknown)
19:43:2E:44:96:CF (unknown)
C1:8D:6E:46:CF:00 RK-G200S-E
C1:8D:6E:46:CF:00 (unknown)
58:2D:34:37:27:D0 (unknown)
58:2D:34:37:27:D0 MJ_HT_V1
58:2D:34:37:24:46 (unknown)
DC:77:2B:67:FE:7A (unknown)
58:2D:34:37:24:46 MJ_HT_V1
It can see BLE devices outside of HA.
HA running
root@nas:~# hcitool lescan
Enable scan failed: Input/output error
It has same settings as BT4.0 device.
BT4.0
root@nas:/HA# btmgmt info
Index list with 1 item
hci0: Primary controller
addr 00:1A:7D:DA:71:0C version 6 manufacturer 10 class 0x2c0104
supported settings: powered connectable fast-connectable discoverable bondable link-security ssp br/edr hs le advertising secure-conn debug-keys privacy static-addr phy-configuration
current settings: powered ssp br/edr le secure-conn
name nas
short name
BT5.0
root@nas:/HA# btmgmt info
Index list with 1 item
hci0: Primary controller
addr 00:E0:4C:6A:FF:03 version 10 manufacturer 93 class 0x2c0104
supported settings: powered connectable fast-connectable discoverable bondable link-security ssp br/edr hs le advertising secure-conn debug-keys privacy static-addr phy-configuration
current settings: powered ssp br/edr le secure-conn
name nas
short name
I hope @Magalex2x14 can help you with this. One thing I notice is that both BT devices report the same MAC address in your last post? I guess the BT5.0 should show a different MAC, similar as in your first post.
sorry, copy/paste error, .. this one is correct BT5.0
root@nas:/HA# btmgmt info
Index list with 1 item
hci0: Primary controller
addr 00:E0:4C:6A:FF:03 version 10 manufacturer 93 class 0x2c0104
supported settings: powered connectable fast-connectable discoverable bondable link-security ssp br/edr hs le advertising secure-conn debug-keys privacy static-addr phy-configuration
current settings: powered ssp br/edr le secure-conn
name nas
short name
Hello, @rchovan ! In your situation, I'm confused by the small difference between the number of commands and events on the interface. I suspect that in the second case, almost nothing really appears on it except for the start scan commands themselves:
Let's look further:
uname -a
)btmon
command in the terminal, start HA, and in a minute interrupt btmon
by CTRL+C, and throw the result here (it can be very voluminous, it's better to put it in a text file)Also, in the last comment here the dude writes that he had to replace the firmware file in order for the adapter to work with USB3. Try plugging it into a USB2 port if your server has one.
Hi, I know, that it is lot of information, but maybe someone can pinpoint problem with this device. Thank you for your time and help.
My device is C-TECH BTD-01 Bluetooth 5.0 device.
I have it connected to USB2.0 desktop port with powered USB HUB (from USB port, not from adapter)
/: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/6p, 5000M
ID 1d6b:0003 Linux Foundation 3.0 root hub
/: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/14p, 480M
ID 1d6b:0002 Linux Foundation 2.0 root hub
|__ Port 2: Dev 2, If 0, Class=Hub, Driver=hub/4p, 480M
ID 0bda:5411 Realtek Semiconductor Corp. RTS5411 Hub
|__ Port 1: Dev 4, If 0, Class=Communications, Driver=cdc_acm, 12M
ID 1cf1:0030 Dresden Elektronik ZigBee gateway [ConBee II]
|__ Port 1: Dev 4, If 1, Class=CDC Data, Driver=cdc_acm, 12M
ID 1cf1:0030 Dresden Elektronik ZigBee gateway [ConBee II]
|__ Port 2: Dev 22, If 0, Class=Wireless, Driver=btusb, 12M
ID 0bda:8771 Realtek Semiconductor Corp.
|__ Port 2: Dev 22, If 1, Class=Wireless, Driver=btusb, 12M
ID 0bda:8771 Realtek Semiconductor Corp.
|__ Port 3: Dev 6, If 0, Class=Vendor Specific Class, Driver=pl2303, 12M
ID 067b:2303 Prolific Technology, Inc. PL2303 Serial Port / Mobile Action MA-8910P
|__ Port 5: Dev 5, If 0, Class=Human Interface Device, Driver=usbhid, 1.5M
ID 051d:0002 American Power Conversion Uninterruptible Power Supply
|__ Port 9: Dev 7, If 0, Class=Human Interface Device, Driver=usbhid, 1.5M
ID 046d:c01d Logitech, Inc. MX510 Optical Mouse
|__ Port 10: Dev 11, If 4, Class=Vendor Specific Class, Driver=option, 480M
ID 12d1:1436 Huawei Technologies Co., Ltd. Broadband stick
|__ Port 10: Dev 11, If 2, Class=CDC Data, Driver=cdc_ether, 480M
ID 12d1:1436 Huawei Technologies Co., Ltd. Broadband stick
|__ Port 10: Dev 11, If 0, Class=Vendor Specific Class, Driver=option, 480M
ID 12d1:1436 Huawei Technologies Co., Ltd. Broadband stick
|__ Port 10: Dev 11, If 5, Class=Mass Storage, Driver=usb-storage, 480M
ID 12d1:1436 Huawei Technologies Co., Ltd. Broadband stick
|__ Port 10: Dev 11, If 3, Class=Vendor Specific Class, Driver=option, 480M
ID 12d1:1436 Huawei Technologies Co., Ltd. Broadband stick
|__ Port 10: Dev 11, If 1, Class=Communications, Driver=cdc_ether, 480M
ID 12d1:1436 Huawei Technologies Co., Ltd. Broadband stick
|__ Port 10: Dev 11, If 6, Class=Mass Storage, Driver=usb-storage, 480M
ID 12d1:1436 Huawei Technologies Co., Ltd. Broadband stick
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/2p, 480M
ID 1d6b:0002 Linux Foundation 2.0 root hub
|__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/8p, 480M
ID 8087:8000 Intel Corp. Integrated Rate Matching Hub
I'm running Debian testing with this kernel
Linux nas 5.16.0-1-amd64 #1 SMP PREEMPT Debian 5.16.7-2 (2022-02-09) x86_64 GNU/Linux
Firmware for my device is installed from firmware-realtek (20210818-1) package. I can't determine version, only from dmesg output Bluetooth: hci0: RTL: fw version 0x0999646b
Here is modinfo for btrtl module :
root@nas:/HA# modinfo btrtl
filename: /lib/modules/5.16.0-1-amd64/kernel/drivers/bluetooth/btrtl.ko
firmware: rtl_bt/rtl8852au_config.bin
firmware: rtl_bt/rtl8852au_fw.bin
firmware: rtl_bt/rtl8822b_config.bin
firmware: rtl_bt/rtl8822b_fw.bin
firmware: rtl_bt/rtl8821a_config.bin
firmware: rtl_bt/rtl8821a_fw.bin
firmware: rtl_bt/rtl8761a_config.bin
firmware: rtl_bt/rtl8761a_fw.bin
firmware: rtl_bt/rtl8723ds_config.bin
firmware: rtl_bt/rtl8723ds_fw.bin
firmware: rtl_bt/rtl8723bs_config.bin
firmware: rtl_bt/rtl8723bs_fw.bin
firmware: rtl_bt/rtl8723b_config.bin
firmware: rtl_bt/rtl8723b_fw.bin
firmware: rtl_bt/rtl8723a_fw.bin
license: GPL
version: 0.1
description: Bluetooth support for Realtek devices ver 0.1
author: Daniel Drake <drake@endlessm.com>
srcversion: A598FD6D96AFC0D4B82A01F
depends: bluetooth
retpoline: Y
intree: Y
name: btrtl
vermagic: 5.16.0-1-amd64 SMP preempt mod_unload modversions
sig_id: PKCS#7
signer: Debian Secure Boot CA
sig_key: 4B:6E:F5:AB:CA:66:98:25:17:8E:05:2C:84:66:7C:CB:C0:53:1F:8C
sig_hashalgo: sha256
signature: 2B:10:4D:58:C7:64:C5:C7:5F:35:D5:46:DC:57:9F:82:7C:7F:45:32:
7F:AD:5E:EE:D3:35:BA:8A:0D:AE:B6:0E:65:92:7B:C4:83:C9:FC:33:
5F:10:2A:18:24:7E:67:0F:97:F4:80:1E:02:BE:0E:91:8C:C3:16:D8:
91:60:12:ED:A3:6B:1C:96:E8:4B:2F:7F:97:C3:0A:03:C7:A6:3C:D5:
22:9E:EC:58:F9:1D:0D:CA:4D:FE:78:59:2F:5C:41:A4:4B:4C:73:58:
F1:55:C6:51:03:8C:02:DE:8C:47:00:A5:A3:E2:19:C9:52:94:0A:AE:
B9:29:D8:56:1F:15:89:00:AD:DD:C7:26:BE:BE:C4:59:62:9B:3C:75:
89:B4:68:A2:99:27:53:04:62:97:AB:84:E4:DB:D9:C7:25:6F:3A:DA:
79:DC:9C:11:20:9F:09:BD:DE:41:34:04:3E:9D:71:AE:F0:CF:87:D5:
73:48:27:29:BF:1E:4E:F1:8F:16:53:7B:7F:E7:39:C9:6F:E1:EF:40:
75:A5:2B:9B:3C:26:BC:D8:DA:90:84:05:EB:C2:26:22:F6:19:B3:0D:
51:7D:92:74:5C:52:7C:25:F3:9A:11:B0:F4:63:B8:62:AA:36:92:AB:
62:B0:DF:9E:57:04:C2:91:D9:63:DD:98:C7:D5:83:3F
Here are md5 hashes for my files
root@nas:/HA# md5sum /lib/firmware/rtl_bt/rtl8761bu_config.bin
49951f548b87ea0258d128195ef6e0cf /lib/firmware/rtl_bt/rtl8761bu_config.bin
root@nas:/HA# md5sum /lib/firmware/rtl_bt/rtl8761bu_fw.bin
f6b8f224d74ad4e9ee8490c82ff80924 /lib/firmware/rtl_bt/rtl8761bu_fw.bin
And here are hashes for files from https://linuxreviews.org/Realtek_RTL8761B
root@nas:~/rtl_bt# md5sum *
84f1760abbd8fa58d8ac1483c5c9359f rtl8761b_config
647b1797b8586f5760205ffbdcdb2d84 rtl8761b_fw
Here are outputs from btmon with BT5.0 and BT4.0 for comparison.
And this is how it looks like, it is working some time, then it stop.
Thanks, @rchovan, for the detailed answer. I haven't looked deep into your logs yet, but from what I see when I take a quick look at bt50.log, I'm concluding that you have some component running, whose work interrupts the scan initiated by ble_monitor - once every few seconds, a scan is initiated with parameters differ than those used by ble_monitor:
At the very beginning of the log there is a whitelist setting:
Please note that ble_monitor uses the following scan options (hardcoded), and the whitelist implemented in ble_monitor works at the top level, in python, and is not used at the hci level:
Think about which of the components you use could behave this way? Find out which device has this address - C1:8D:6E:46:CF:00. And let us know - it's very interesting.
C1:8D:6E:46:CF:00 is Kettle Redmond RK-G200S-E. I'm using this integration https://github.com/ClusterM/skykettle-ha.
If there is issue with this interation, it is only on BT5.0 device, because with BT4.0 they work together without problem
I suspect that the problem may be related to the different behavior of the utilities used by SkyKettle to access Bluetooth functions, depending on the type of interface (gattool, hcitool, etc). I can’t say for sure right now - I need to study their code, but I think that this is close to the truth. ble_monitor uses a "low-level" approach, so it doesn't have this dependency. Look at this issue also - https://github.com/ClusterM/skykettle-ha/issues/9 Simultaneous normal operation of both integrations on the same interface is pretty difficult. The negative effects may not be noticeable, but they are still present anyway. The only way I see is to distribute them to separate interfaces. hci0 for one, hci1 for the other. It is worth asking the author of SkyKettle to implement support for working on an arbitrary interface (I did not find any mention of such functionality).
In the general case, if the integration does not often (for a long time) interrupt the scanning of the air (with the setting of a white list, for example), and does not often establish long connections, then the joint operation of such integration with ble_monitor is quite possible - the flow of data to ble_monitor will be interrupted only until the beginning of the next scan period (60 sec by default).
Hello @Magalex2x14
I just replaced BT5.0 with BT4.0 without any change in configuration, With BT4.0 both integrations work together without problem.
ble-monitor device
skykettle device
Do you have any idea why it works wit BT4.0 and not with BT5.0 ?
And I've observed another thing. hcitool lescan is much much faster with BT4.0 USB than BT5.0 USB.
@rchovan the author of the SkyKettle integration and I continued this topic here.
I'm closing this issue for now, as there's nothing we can do about it at the moment. We'll reopen if there's a reason...
Hi, I've changed my BT 4.0 to BT 5.0 adapter, but it does not work with my LYWSDCGQ devices. Main reason why I upgraded to BT5.0 is range. I have custom debian server, and bluetooth device is on 2m long USB 3.0 shielded cable.
My old BT4.0 device is
My new BT 5.0 device is
With BT 5.0 I can see other devices in log, but it does not receive messages from LYWSDCGQ.
I know, that this device need to load firmware, but it looks like it is working
If you need any more logs data, feel free to ask.