Whenever I encounter any dbus errors during startup, I just restart openhab and the problem usually goes away. You should check that the dbus service is also running though.
Edit: The Failed to obtain handles for "Service Changed" characteristic message is certainly concerning though since I’ve never seen it occur on any of my setups. I’d suggest you look into solving that first.
So i upgraded to the last snapshot of OH 3, now the bluetooth binding connect well, but when I add a thing to the bridge :
2020-10-29 12:57:48.774 [ERROR] [nal.common.AbstractInvocationHandler] - An error occurred while calling method ‘Thin gHandler.initialize()’ on ‘org.openhab.binding.bluetooth.BeaconBluetoothHandler@f0c523’: Duplicate channels bluetooth :beacon:hci0:a4c138f3eee2:rssi
java.lang.IllegalArgumentException: Duplicate channels bluetooth:beacon:hci0:a4c138f3eee2:rssi
at org.openhab.core.thing.util.ThingHelper.ensureUniqueChannels(ThingHelper.java:152) ~[?:?]
at org.openhab.core.thing.util.ThingHelper.ensureUniqueChannels(ThingHelper.java:144) ~[?:?]
at org.openhab.core.thing.util.ThingHelper.ensureUniqueChannels(ThingHelper.java:140) ~[?:?]
at org.openhab.core.thing.binding.builder.ThingBuilder.withChannel(ThingBuilder.java:75) ~[?:?]
at org.openhab.binding.bluetooth.BeaconBluetoothHandler.initialize(BeaconBluetoothHandler.java:107) ~[?:?]
at jdk.internal.reflect.GeneratedMethodAccessor77.invoke(Unknown Source) ~[?:?]
at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:?]
at java.lang.reflect.Method.invoke(Method.java:566) ~[?:?]
at org.openhab.core.internal.common.AbstractInvocationHandler.invokeDirect(AbstractInvocationHandler.java:152 ) [bundleFile:?]
at org.openhab.core.internal.common.Invocation.call(Invocation.java:52) [bundleFile:?]
at java.util.concurrent.FutureTask.run(FutureTask.java:264) [?:?]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) [?:?]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) [?:?]
at java.lang.Thread.run(Thread.java:834) [?:?]
2020-10-29 12:57:48.778 [ERROR] [core.thing.internal.ThingManagerImpl] - Exception occurred while initializing handle r of thing ‘bluetooth:beacon:hci0:a4c138f3eee2’: Duplicate channels bluetooth:beacon:hci0:a4c138f3eee2:rssi
java.lang.IllegalArgumentException: Duplicate channels bluetooth:beacon:hci0:a4c138f3eee2:rssi
at org.openhab.core.thing.util.ThingHelper.ensureUniqueChannels(ThingHelper.java:152) ~[?:?]
at org.openhab.core.thing.util.ThingHelper.ensureUniqueChannels(ThingHelper.java:144) ~[?:?]
at org.openhab.core.thing.util.ThingHelper.ensureUniqueChannels(ThingHelper.java:140) ~[?:?]
at org.openhab.core.thing.binding.builder.ThingBuilder.withChannel(ThingBuilder.java:75) ~[?:?]
at org.openhab.binding.bluetooth.BeaconBluetoothHandler.initialize(BeaconBluetoothHandler.java:107) ~[?:?]
at jdk.internal.reflect.GeneratedMethodAccessor77.invoke(Unknown Source) ~[?:?]
at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:?]
at java.lang.reflect.Method.invoke(Method.java:566) ~[?:?]
at org.openhab.core.internal.common.AbstractInvocationHandler.invokeDirect(AbstractInvocationHandler.java:152 ) [bundleFile:?]
at org.openhab.core.internal.common.Invocation.call(Invocation.java:52) [bundleFile:?]
at java.util.concurrent.FutureTask.run(FutureTask.java:264) [?:?]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) [?:?]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) [?:?]
at java.lang.Thread.run(Thread.java:834) [?:?]
I already have a fix that would get merged in with the generic bluetooth binding PR.
Hello,
How I can declare new channel to the beacon things?
I saw only RSSI, but my Xiaomi mija temperature have other information to give.
Thank’s for your help
The beacon things don’t have any other channels. Support for arbitrary channels is going to be added as part of the bluetooth.generic binding that already has a PR that is waiting to get merged. If you are looking for the OH 2.5.x version of the bluetooth.generic binding I left instructions of how to install it on prior posts.
Hi @Tukks
Seems that we play around with the same devices. Unfortunately it looks as the connection is not yet very stable. I also didn’t get the data out of them yet. Even the RSSI status changes to frequently.
I have a PR pending - which improves the stability when notify characteristics are involved
Some of these bluetooth devices require some kind of keep-alive or they will close the connection after a short period of time. I’m in the process of adding a configuration to only connect on demand instead of trying to constantly keep the connection open. That way it will be able to read the values in the short period of time that the connection is open.
Thanks @cpmeister and @hairdresser
It is already a giant step forward for me beeing able to receive data from these devices.
Before the upgrade to latest snapshot versions I wasn’t even able to get the bluetooth adapter working.
Hi Connor,
since the GATT part been merged into the snapshot version of openHAB3 I thought it could be a good moment for trying it out 
So I brought my zoo of BLE devices in proximity to my OH3 test system as offered in the past:
The devices were discovered and added to the inbox. One out of them even shows at least some of the GATT’s as thing properties:
This is the square thermometer (“Xiaomi Mijia Bluetooth Thermometer 2 LYWSD03MMC”).
Is it all what can be expected yet? Or should some of the devices “known” by @vkolotov s 3rd party binding get more attributes decoded yet?
Setup:
Did you have a look at the channel tab of the thing as well? That would be more interesting.
Yes, I did 
Beside the “decoded” attributes which were used for the thing properties, a bunch of "unknown Bluetooth characteristic"s are there:
ok, bad luck
When activating the onboard Bluetooth of the RasPi in addition to the BlueGiga dongle, then the scan results are different between the two Bluetooth adaptors (Bluez vs. BlueGiga):
The bluez/RasPi Bluetooth does not show any generic device but shows the correct device/model names in thing label which is not the case for BlueGiga (just the iBKS-beacon is recognized and labeled accordingly).
Again: My question is still wether this is all which should work yet or if there should be more decoded already?
After playing some hours with the new official Bluetooth binding I don’t get any consistent GATT results from my BLE devices (beacons, thermometers, flower care, oxymeter), neither via Bluez nor BlueGiga.
I’m wondering if it is too early for expecting almost similar functional range as we had with the “3rd party binding” in the past… 
@cpmeister May I ask you directly, up to what extent Vlad’s work made it into the current snapshot? Could you elaborate a bit, what could work already and what should not be expected to work yet?
What do you mean by this? Are updates sporadic or do the gatt channels simply not show up for your device? I think I should note, based on the screen shots that you sent, that beacon and generic devices are completely different in the bluetooth binding. Beacon devices will only ever have an rssi channel. Generic devices will have the gatt channels. If you only discover your device as a beacon then it means that there was some kind of connection problem with the device so you might have to rerun discovery.
Right now discovery is a little spotty for the generic devices, but creating manually should work fine as long as you manually assign it to a bridge. I’m continuing to work on improving this. The generic binding will not work if it cannot connect to the device.
For devices that allow constant connections the generic binding should work fine. The only issue is when it doesn’t allow constant connections. I’m currently writing a fix for that.
Wrt Vlad’s work, the generic binding uses his characteristic database for reading/writing known characteristics. Multi adapter presence detection is handled by creating a Roaming bluetooth adapter.
Other than reliability (which I’ll continue to improve) what features do you feel are missing?
Hi Connor,
thanks for your reply and clarification. I think I do better understand now what’s happening …
Sorry for being a bit unclear with this statement
Let me explain:
I do test with some devices which are just beacons (“iBKS105” broadcasting as iBeacon and Eddystone at the same time) and “generic” devices broadcasting GATT’s. Some of the generic devices (but not all!) were previously recognized and decoded by Vlad’s binding.
What I see is that my devices have been discovered - but almost all just as beacons without characteristics/channels other than RSSI. Only surprising exception is the …
… which was not known to Vlad’s binding formerly. For this device, a bunch of GATT’s were discovered but just the standard attributes have been decoded correctly. The interesting channels holding the sensor values of temperature and humidity are missing. But I think it makes sense, since this device was not covered by Vlad’s characteristics database yet. Reversing the usage/meaning of the characteristics still needs to be done. Maybe I should play with the “unknown characterics” channels to find out the relevant (temperature, humidity) and how to decode them…
Well, considering the above in combination with…
… I felt uncertain about what should work already. That’s what I’ve meant with “inconsistent”. Again: Sorry about this…
Aaaahhh… good to know. Maybe this is the main issue here:
IIRC, Vlad said some day, all (most?) of the Xiaomi devices use a proprietary authentication mechanism which is not public (yet). If your GATT discovery currently depends on connecting the devices instead of just listening, these Xiaomi sensors simply can’t be discovered as “generic” since they refuse the connection attempt. Would you agree?
Happy to hear that. Let me know once this is done and merged. Happy to test then again…
Well, when thinking about this, two things come to my mind currently:
Handling of battery powered generic BLE devices
Some of those use tiny batteries like coin cells. This needs them falling asleep quite fast and sleep as long as possible and just wake if some sensor values have changed noticeably. What, if the binding tends connecting to them for polling? Have you already considered this and connect only for discovery or make connect configurable?
More channels for beacons
Beacons send information with the beacon broadcast, e.g.:
major/minor ID, UUID, transmit powerURL, PDU count, uptime, transmit power, battery voltageFor some I see use cases immediately:
So, it would be nice if the beacon data payload could be used to update additional channels.
@cpmeister I’ve probably reversed successfully the unknown temperature/humidity characteristic of the LYWSD03MMC:
I’ve connected with nRF Connect to the thermometer and observed the unknown generic characteristics and compared them with the values shown on the display of the device.
The guessed decoding is as this
UUID: ebe0ccc1-7a0a-4b0c-8a1a-6ff2997da3a6
Value: 0x TT-TT-HH-UU-UU
34-12-12-12-34
Where
T1-T2 = first byte of temp value
T3-T4 = second byte of temp value
H1-H2 = humidity value
U1-U4 = unknown
Example from screenshot above:
Temperature: 0x09F2 = 2549 = 24,49 degree celsius (device display “24,4”)
Humidity: 0x22 = 34 = 34% relative humidity (device display “34”)
I’ve observed changes in temp/hum on the display and compared it with the reported values while having the above decoding “algorithm” applied and got matching result.
Is such information sufficient to add them to the characteristics database?
What else do you need?
I am not sure if I understand this correctly but this does not seem to be true for all devices. I am using the Xiaomi Mijia Bluetooth Temperature and Humidity Sensors (MJ_HT_V1). These devices work with Vlad’s binding and I still use them with his binding (running an old version of OH2.5M3 on a Raspi and connected to my main OH instance via MQTT). Within Vlad’s binding these devices expose channels like temperature, humidity and battery level:
When I try to use the device with the new official bluetooth binding (OH3 Snapshot 2028), they are discovered as beacons…
and only expose one channel for RSSI:
This device is definitely part of Vlad’s database so there still seem to be issues with the binding.
I am absolutely no bluetooth expert (so please forgive me if I am writing nonsense) but I think I rember an old discussion that these devices do not support controlled connections at all. They rather seem to broadcast the payload like temperature etc.all the time. So could it be that the new official bluetooth binding is not supporting this case?
Yes. That confused me too at first. But with Connor’s clarification:
… it might be as I concluded here:
Maybe should wait for Connor’s comment on this…
