3rd Party Bluetooth Binding. Beta testers needed

bluetooth
binding
Tags: #<Tag:0x00007f014749a710> #<Tag:0x00007f014749a5a8>

(Vlad Kolotov) #564

No worries. It is my fault not to make the documentation up to standard.

For the initial set up, you probably should not touch the settings I mentioned above. Just set locations for your adapters in OH and add “Location” channel for your devices.

I suggest you to play with the calibration parameters once everything is working but you are not satisfied with accuracy.

Not sure I understand this:

And the location channel is no option because the adapters are on other slave servers and send the value of RSSI over mqtt.

Have you added adapters in the binding? If so, go to their settings and set location parameter accordingly to where they located. As per this:


(Markus S.) #565

I have one adapter on my master openhab server per usb. The second adapter is on another slave server with openhab per USB. Can’t find both adapters on the same server. So i send the values from the slave to the master server and compares it. If master adapter is online and RSSI under -76 and slave adapter is online i am in the living room. :slight_smile:


(Vlad Kolotov) #566

I see now… You are using mqtt. In that case you won’t be able to use the binding indoor positioning system. How about adding your remote adapters via serial over IP? @Dibbler42 created a nice manual for that: Forwarding of serial and USB ports over the network to openHAB


(Markus S.) #567

Yes, this would be an option. I will test it. Thank you very much for your help.
Greetings, Markus.


(JohnD) #568

openhab.log

2018-07-17 22:22:23.393 [INFO ] [g.discovery.internal.PersistentInbox] - Added new thing 'bluetooth:adapter:001A7DDA7111' to inbox.
2018-07-17 22:23:59.700 [WARN ] [.core.thing.binding.BaseThingHandler] - Handler AdapterHandler of thing bluetooth:adapter:001A7DDA7111 tried checking if channel discovering is linked although the handler was already disposed.
2018-07-17 22:23:59.710 [WARN ] [.core.thing.binding.BaseThingHandler] - Handler AdapterHandler of thing bluetooth:adapter:001A7DDA7111 tried checking if channel discovering-control is linked although the handler was already disposed.
2018-07-17 22:24:00.160 [WARN ] [.core.thing.binding.BaseThingHandler] - BaseThingHandler.initialize() will be removed soon, ThingStatus can be set manually via updateStatus(ThingStatus.ONLINE)
2018-07-17 22:24:10.217 [WARN ] [impl.AbstractBluetoothObjectGovernor] - Error occurred while updating governor: /00:1A:7D:DA:71:11 / 1fb3b98 : GDBus.Error:org.bluez.Error.NotSupported: Operation is not supported
2018-07-17 22:24:20.475 [WARN ] [impl.AbstractBluetoothObjectGovernor] - Error occurred while updating governor: /00:1A:7D:DA:71:11 / 35bf4a : GDBus.Error:org.bluez.Error.NotSupported: Operation is not supported
2018-07-17 22:24:30.589 [WARN ] [impl.AbstractBluetoothObjectGovernor] - Error occurred while updating governor: /00:1A:7D:DA:71:11 / 35bf4a : GDBus.Error:org.bluez.Error.NotSupported: Operation is not supported
2018-07-17 22:24:40.607 [WARN ] [impl.AbstractBluetoothObjectGovernor] - Error occurred while updating governor: /00:1A:7D:DA:71:11 / 35bf4a : GDBus.Error:org.bluez.Error.NotSupported: Operation is not supported

lsusb
Bus 008 Device 006: ID 0a12:0001 Cambridge Silicon Radio, Ltd Bluetooth Dongle (HCI mode)

systemctl status bluetooth

● bluetooth.service - Bluetooth service
   Loaded: loaded (/lib/systemd/system/bluetooth.service; enabled; vendor preset: enabled)
   Active: active (running) since Tue 2018-07-17 22:20:29 CEST; 37min ago
 Docs: man:bluetoothd(8)
 Main PID: 25740 (bluetoothd)
   Status: "Running"
   CGroup: /system.slice/bluetooth.service
       └─25740 /usr/libexec/bluetooth/bluetoothd

Jul 17 22:20:29 orangepizero systemd[1]: Starting Bluetooth service...
Jul 17 22:20:29 orangepizero bluetoothd[25740]: Bluetooth daemon 5.47
Jul 17 22:20:29 orangepizero bluetoothd[25740]: Starting SDP server
Jul 17 22:20:29 orangepizero systemd[1]: Started Bluetooth service.
Jul 17 22:20:29 orangepizero bluetoothd[25740]: Bluetooth management interface 1.0 initialized

Adapter itself works correctly - finds the device and I can read the data from the xiaomi bluetooth termomter with this command:

gatttool -b XX:XX:XX:XX:XX:XX --char-write-req --handle=0x0010 --value=0100 --listen
Characteristic value was written successfully
Notification handle = 0x000e value: 54 3d 32 35 2e 37 20 48 3d 36 35 2e 37 00
Notification handle = 0x000e value: 54 3d 32 35 2e 38 20 48 3d 36 35 2e 36 00
Notification handle = 0x000e value: 54 3d 32 35 2e 37 20 48 3d 36 35 2e 37 00
Notification handle = 0x000e value: 54 3d 32 35 2e 38 20 48 3d 36 35 2e 36 00

Does anyone else have such a problem? how to fix it?


(Vlad Kolotov) #569

Thanks for reporting this @JohnD, I’ve responded on your ticket


(mcqwerty) #570

*Bump* Anyone know the answer to this? I would really like to have my things defined in a .thing file as I do for the things related to other bindings.

Thanks


(Baltazar72) #571

Hi … First thank you for this binding and all the great effort !

I just want to share with you that I bought the LM1010 bluetooth usb adapter (with external antennas) for improving range. I put them in different rooms, connecting with usbip …

These adapters turned out to stop reporting after the first report.
I found that I needed to set kernel parameter : enable_autosuspend = “N” for these adapters to keep reporting. see :
https://bbs.archlinux.org/viewtopic.php?pid=1781522#p1781522

I spent quite some time tracking this down, so I tougth I’d share it here.

Br
Torstein


(Thomas Bail) #572

Could you describe your setup, especialy what did you put into the different rooms and on whick system is your openhab running


(Baltazar72) #573

Hi

The USBIP setup is discussed here earlier … By you ?! :smile: Forwarding of serial and USB ports over the network to openHAB](http://)
I did use your information together with this one to make it persist :
https://unix.stackexchange.com/questions/406847/use-usbip-for-devices-that-are-being-removed-and-reconnected

I have the bluetooth-adapters in : Desktop (HTCP), a RaspberryPi 2, RaspberryPi 3, and a headless Server located troughout the appertment … (all my devices run ArchLinux)

Openhab (one of the latest snapshots) is currently running in the HTPC (ArchLinux gnome desktop), Bluez + Bluez-utils 5.47

Br
-Torstein


(Vlad Kolotov) #574

Awesome news @Baltazar72, I’ll add this to the troubleshooting section

These adapters turned out to stop reporting after the first report.
I found that I needed to set kernel parameter : enable_autosuspend = “N” for these adapters to keep reporting. see :
https://bbs.archlinux.org/viewtopic.php?pid=1781522#p1781522

How’s that usb adapter working? Better reception?


(Vlad Kolotov) #575

Hey @Baltazar72,

just wondering if you are using the “indoor positioning” feature of the binding? I have not heard from anyone if it is used so far… If so, could you please let me know how it goes? Cheers


(Vlad Kolotov) #576

Hi @mcqwerty, would you be able to create an issue on github and attach some details/files?

I have not tried defining adapters in files, so not sure if it is working. However I do not see any issues with that. Let’s create a ticket on github so I won’t forget to check it. Cheers


(Baltazar72) #577

wrong post …


(Baltazar72) #578

Hi, no I have only used for Miflora so far … Not used positioning …

Br
Torstein


(Baltazar72) #579

Reception is definetly better.
I’ll se if I can make an more “scientific” measurement, but for me it was a “needed” improvement on range, I can se devicec popping in on adapter locations not possible with the small usb “internal antenna” adapters.

Br
Torstein


(JohnD) #580

@vkolotov And what about this issue? can you help me?


(Vlad Kolotov) #581

Hi @JohnD, looks like you are not the only one who reported this, although it is not very common. Not sure what is the cause of it since I cannot reproduce this. However, I can possibly do a workaround for this. I’ll make a build for you to test, will you be able to test it?

Update: Replied on your github ticket with a link to download TinyB transport to test for you.


(Baltazar72) #582

Regarding “Location” … I have a “stationary” MiFlora device, but since I now have “multiple” bt-adapters, the updates from mi-flora is picked up by more than one adapter …
I see guess the “location” is set “only” by the last adapter that communicated with the device (as I don’t see the plant rushing between the livingrom and hall evere few minutes :smiley:

I’m just thinking maybe Location could be “calculated” by the rssi from multiple adapters ?
Im my specific case, the “kott-adapter” has 79-80 rssi, and the “stue-adapter” has an rssi on the same device with 90-91.

For a device to be determined as “moving” either adapter should not have the approx same rssi values in a number of measurements, and the device could be “located” with the adapter having the “lowest” value over n-measurements (preventing the “hopping”)?

Rambling on ( just an idea, and probably a lot of work to implement, or maybe this would not work uniform with different devices, causing you to make a “map” for each device…)
You could pull this a long way, and build a triangulation “map” of corresponding measurements eg stue-rssi=73-78 and kott-rssi=82-85 could mean location = “kitchen” … (even if you have no adapters int he kitchen)

This way, the “wife” could move the flowers around, and just get a message "Flower #2, located in the vicinity of the kitchen needs water :slight_smile: (the sticks just needs to be “numbered”)

Br Torstein

log looks like this :

2018-07-26 15:07:26.580 [vent.ItemStateChangedEvent] - Flower2_rssi changed from -80 to -79
2018-07-26 15:07:56.572 [vent.ItemStateChangedEvent] - Flower2_rssi changed from -79 to -80
2018-07-26 15:08:51.532 [vent.ItemStateChangedEvent] - Flower2_rssi changed from -80 to -81
2018-07-26 15:09:00.567 [vent.ItemStateChangedEvent] - Flower2_rssi changed from -81 to -90
2018-07-26 15:09:00.569 [vent.ItemStateChangedEvent] - Flower2_Location changed from kott to Stue
2018-07-26 15:09:14.568 [vent.ItemStateChangedEvent] - Flower2_rssi changed from -90 to -79
2018-07-26 15:09:14.569 [vent.ItemStateChangedEvent] - Flower2_Location changed from Stue to kott
2018-07-26 15:09:38.532 [vent.ItemStateChangedEvent] - Flower2_rssi changed from -79 to -80
2018-07-26 15:09:44.558 [vent.ItemStateChangedEvent] - Flower2_rssi changed from -80 to -91
2018-07-26 15:09:44.558 [vent.ItemStateChangedEvent] - Flower2_Location changed from kott to Stue
2018-07-26 15:09:56.561 [vent.ItemStateChangedEvent] - Flower2_rssi changed from -91 to -90
2018-07-26 15:10:08.553 [vent.ItemStateChangedEvent] - Flower2_rssi changed from -90 to -91
2018-07-26 15:10:19.537 [vent.ItemStateChangedEvent] - Flower2_rssi changed from -91 to -80
2018-07-26 15:10:19.537 [vent.ItemStateChangedEvent] - Flower2_Location changed from Stue to kott
2018-07-26 15:10:28.531 [vent.ItemStateChangedEvent] - Flower2_rssi changed from -80 to -91
2018-07-26 15:10:28.532 [vent.ItemStateChangedEvent] - Flower2_Location changed from kott to Stue
2018-07-26 15:10:33.561 [vent.ItemStateChangedEvent] - Flower2_rssi changed from -91 to -80
2018-07-26 15:10:33.561 [vent.ItemStateChangedEvent] - Flower2_Location changed from Stue to kott
2018-07-26 15:10:41.556 [vent.ItemStateChangedEvent] - Flower2_rssi changed from -80 to -79
2018-07-26 15:10:52.559 [vent.ItemStateChangedEvent] - Flower2_rssi changed from -79 to -91
2018-07-26 15:10:52.559 [vent.ItemStateChangedEvent] - Flower2_Location changed from kott to Stue
2018-07-26 15:11:03.583 [vent.ItemStateChangedEvent] - Flower2_rssi changed from -91 to -79
2018-07-26 15:11:03.584 [vent.ItemStateChangedEvent] - Flower2_Location changed from Stue to kott
2018-07-26 15:11:23.633 [vent.ItemStateChangedEvent] - Flower2_rssi changed from -79 to -91
2018-07-26 15:11:23.634 [vent.ItemStateChangedEvent] - Flower2_Location changed from kott to Stue
2018-07-26 15:11:29.528 [vent.ItemStateChangedEvent] - Flower2_rssi changed from -91 to -78
2018-07-26 15:11:29.528 [vent.ItemStateChangedEvent] - Flower2_Location changed from Stue to kott
2018-07-26 15:11:59.532 [vent.ItemStateChangedEvent] - Flower2_rssi changed from -78 to -79
2018-07-26 15:12:32.545 [vent.ItemStateChangedEvent] - Flower2_rssi changed from -79 to -78
2018-07-26 15:12:43.555 [vent.ItemStateChangedEvent] - Flower2_rssi changed from -78 to -91
2018-07-26 15:12:43.556 [vent.ItemStateChangedEvent] - Flower2_Location changed from kott to Stue
2018-07-26 15:12:53.555 [vent.ItemStateChangedEvent] - Flower2_rssi changed from -91 to -79
2018-07-26 15:12:53.556 [vent.ItemStateChangedEvent] - Flower2_Location changed from Stue to kott
2018-07-26 15:13:04.562 [vent.ItemStateChangedEvent] - Flower2_rssi changed from -79 to -78
2018-07-26 15:13:26.579 [vent.ItemStateChangedEvent] - Flower2_rssi changed from -78 to -91
2018-07-26 15:13:26.580 [vent.ItemStateChangedEvent] - Flower2_Location changed from kott to Stue
2018-07-26 15:13:37.529 [vent.ItemStateChangedEvent] - Flower2_rssi changed from -91 to -78
2018-07-26 15:13:37.531 [vent.ItemStateChangedEvent] - Flower2_Location changed from Stue to kott
2018-07-26 15:14:11.527 [vent.ItemStateChangedEvent] - Flower2_rssi changed from -78 to -91
2018-07-26 15:14:11.527 [vent.ItemStateChangedEvent] - Flower2_Location changed from kott to Stue
2018-07-26 15:14:22.545 [vent.ItemStateChangedEvent] - Flower2_rssi changed from -91 to -78
2018-07-26 15:14:22.545 [vent.ItemStateChangedEvent] - Flower2_Location changed from Stue to kott


(Vlad Kolotov) #583

Hi @Baltazar72, thank you for your suggestions. The location calculation is not based on the most recent adapter that received data as you say. The binding calculated distance between your device and all of your adapters based on RSSI. This is so called Indoor Positioning System.

There are a number of factors that can influence accuracy if the system, such us:

  1. Radio receivers in adapters are not all the same, hence they sense/report RSSI differently.
  2. Your adapters can be installed in different places, e.g. in a cupboard, roof cavity, wall etc, which brings further inconsistency.
  3. Bluetooth devices have different radio transmitters that emit radio waves with different strength, furthermore manufacturers can set up different levels of radio strength, this is mainly due to power consumption optimisation.
  4. Just because it is wireless communication, RSSI value that we receive is not consistent even if adapter and device are stationary.

In order to deal with this issues, the binding has various features/configurations:

  1. Kalman filter that is supposed to reduce noise from RSSI readings. There are several settings you could play with:
    • Kalman filter factors. Configured in the device settings. For your stationary devices you may easily choose strongest filter:
    • Signal propagation exponent. Configured in the adapter setting. Read the description of that config, it should be self explanatory.
  2. Measured transmit power. Configured in the device settings. This setting is intended to equalise differences in hardware/software of receivers and transmitters:

For a device to be determined as “moving” either adapter should not have the approx same rssi values in a number of measurements, and the device could be “located” with the adapter having the “lowest” value over n-measurements (preventing the “hopping”)?

What you are describing is called Hysteresis probably. It is a good approach to smooth behaviour, however it brings some latency. From my observation, Kalman filter + tweaking configs is enough to make it more or less stable.

Please try and let me know how it goes. Cheers.