3rd Party Bluetooth Binding. Beta testers needed

Tags: #<Tag:0x00007f0152f36d08> #<Tag:0x00007f0152f7fb20>

(Vlad Kolotov) #767

Yeah, if it is too far, the connection might not be stable hence it could lose command you send.

Let us know how it goes, later we can add some GATT files so that the binding automatically recognises that unknown characteristic and has On/Off channel for it.

(jimonnet) #768

Hi @vkolotov. I’ve installed your awesome binding following all the documentation available, made sure that permissions are given, and the bluetooth service is running. I have a Raspberry pi 3B / Raspbian Stretch / OH 2.3 / RPI Internal bluetooth hardware / Bluez 5.47 / TinyB transport environment and I’m just trying to detect presence with a simple beacon (but without actually connecting to it).

I’m using a beacon like this: https://www.beaconzone.co.uk/Sanwo, which is flawlessly seen by both the oficial bluetooth binding and my own android device. However, by installing your binding the device is not recognized. I forced the recognition somewhat by uninstalling and installing the binding and the transport. The device is temporarily recognized and added to the inbox, then I added it as a Thing by using the PaperUI (I haven’t enabled the feature which does this automatically). After this I noticed that the Thing becomes online, but goes offline after some time (30 secs or so). (NOTE: The device/thing is also recognized if I execute bluetoothctl and enable scan. See below.)

By inspecting the log you find entries like this:

2018-12-07 13:39:39.710 [WARN ] [.core.thing.binding.BaseThingHandler] - Handler BluetoothDeviceHandler of thing bluetooth:ble:EC24B830ECD3 tried checking if channel online is linked although the handler was already disposed.

Initially, I was thinking the binding won’t work for my environment, but later found that if I run “sudo -u openhab bluetoothctl” and specify “scan on”, the following happens:

  1. The device (and also other nearby devices) gets discovered in OH without having warn messages in the log. It also becomes online.
  2. At the same time that bluetoothctl discovers, changes (e.g. RSSI) or removes the device, these changes are also recognized by OH. [DEL] changes make the device Offline. [NEW] changes make the device Online again.
  3. bluetoothctl seems to have frequent disconnects ([DEL]/[NEW]) with this device although it is positioned nearly (but this seems to be a separate issue). Disconnects have a frequency of one every 3-5 mins. Is this TinyB instability?
  4. If I exit from bluetoothctl or if I type “scan off”, the Thing becomes offline again and you don’t receive changes anymore in OH.

NOTE: This is NOT a device-specific issue. if scan is enabled I see that other things/devices are quickly recognized: Other owned devices, a TV from a neighbor :), even bluetooth equipment from the cars passing nearby. If scan is not enabled by using bluetoothctl, the binding just recognizes the Pi’s bluetooth adapter but nothing else.

Then it seems that, for my environment, discovery is not being automatically performed and also it seems that discovery needs to be enabled to perform basic presence recognition. BTW: I see that “Enable background discovery” is enabled in the binding config. Could you tell me If I’m missing something or if this is a bug?

UPDATE: I’m attaching my debug trace. Everything seems to be fine, but the binding apparently does not recognize the device as expected and enters a “Protocol is unknown” infinite cycle. However, this might be just related to the way in which the binding addresses the device. Note that if I execute bluetoothctl and enable the scan, the binding seems to work OK.

Debug trace.txt (28.0 KB)

(orzech) #769

Hi, @vkolotov
When can we expect DBus instead of TinyB ? :slight_smile:

(Vlad Kolotov) #770

Hi @jimonnet, thank you very much for a proper description of your problem, it is very thoughtful and “advance” :slight_smile: well done.

Yes, you are right, looks like there is something wrong with adapter “thing”. Does it get discovered by the binding? Do you enable (it is actually enabled by default) “Discovering control”?

If everything works as expected, both checkboxes should be enabled. This would indicate that your adapter is in the scan mode. Otherwise, your devices will go offline soon.

UPDATE: From the log file you’ve posted it is not clear if you added your adapter thing from OH inbox. There must be one for your adapter, you have to add it, otherwise the binding won’t manage it, hence it won’t enable discovery for devices. I can make guess that you’ve adde an adapter from the inbox, then added your device, and then removed your adapter thing. Is this right?

(Vlad Kolotov) #771

Hey @orzechszek, it is work in progress now. It is mostly working, however there are still some issues. @xrucka is the main contributor for this, he’s done great work to implement this. Unfortunately I don’t have enough time at the moment to help him, but yeah that would be great if we could get rid of TinyB.

(vossivossi) #772

Sorry for asking a maybe stupid question, but I just started to dig into bluetooth stuff. I understand that the binding is generic and that it has some specific extensions like BlueGiga, BlueZ and Blukii.
What is about the very common protocols like iBeacon protocol and Eddystone? Are they also supported?

(Vlad Kolotov) #773

You are probably confusing the official binding with the 3rd party binding.

(Lukáš Ručka) #774

Hi @orzechszek ; I’ve managed to produce a new draft couple of weeks ago + uploaded to github couple of days ago. If you can help with testing, I’ll be more than glad for that.

You can fetch the code under bluetooth-manager-dbus and corresponding bundle

It has not yet been migrated to openhab > 2.2.0 and latest bluetooth binding - hope I’ll get around it later this week. You can report possible issues in the rewrite wip here.

(orzech) #775

I’m working on last snapshot 2.4.0. Will it work with tiny-b binding in paralell or have I remove it? Now I have Bluez 5.47. Should EXPERIMENTAL parameter be enough? I don’t wan’t to break this configuration, because some solutions in my openhab base on it.

(Lukáš Ručka) #776

I’m working on last snapshot 2.4.0.

Have not tested that one yet, so this might be a big unknown. On the other hand, only the osgi bundle stuff are used, so it should be compatible.

Will it work with tiny-b binding in paralell or have I remove it?

From transport’s perspective, there is no difference whether it runs alone or next to tinyb. However, as tinyb uses bluez as well, so the two libraries might end up accessing the same adapters and devices – the concurrency issues must be managed by binding. I have bypassed this issue during development by disabling tinyb transport. As for switching, you should be able to keep everyting set up as is, it won’t change channels nor items.

Now I have Bluez 5.47. Should EXPERIMENTAL parameter be enough?

I started on 5.41, If I recall correctly, it should be enough.

I don’t wan’t to break this configuration, because some solutions in my openhab base on it.

Understood, however I cannot really guarantee it won’t (temporarly) break your setup just yet.

(jimonnet) #777

Yeah! That was the only missing part in this puzzle. Note for adopters: If you don’t like adding the Things using the simple mode, don’t forget adding the local bluetooth adapter first!

This now works like a charm. Instability seems to have been fixed as well.

Thanks for your help @vkolotov! Now I think I would have to purchase a couple of Xiaomi watch/bands to expand my device base and add at least one extra bluetooth interface.

(marcel) #778

Hi, I’m using a docker image to run OH, (2.4M8)

Struggling to get the binding going. Bluez seems to run well, but tinyB is not…
I installed in on the docker server, not in the docker container. Where should TinyB run?

cd /usr/lib/bluetooth
:/usr/lib/bluetooth$ ./bluetoothd --version

sudo -u openhab bluetoothctl
[NEW] Controller 00:1A:7D:DA:71:11 docker-server #1 [default]
[NEW] Controller 10:08:B1:FC:C3:6A docker-server
[NEW] Device C4:7C:8D:61:4D:38 Flower mate

sudo systemctl status bluetooth
● bluetooth.service - Bluetooth service
   Loaded: loaded (/lib/systemd/system/bluetooth.service; enabled; vendor preset: enabled)
   Active: active (running) since wo 2018-12-12 13:57:30 CET; 1s ago
     Docs: man:bluetoothd(8)
 Main PID: 1985 (bluetoothd)
   Status: "Running"
    Tasks: 1
   Memory: 932.0K
      CPU: 27ms
   CGroup: /system.slice/bluetooth.service
           └─1985 /usr/lib/bluetooth/bluetoothd

dec 12 13:57:30 docker-server systemd[1]: Starting Bluetooth service...
dec 12 13:57:30 docker-server bluetoothd[1985]: Bluetooth daemon 5.46
dec 12 13:57:30 docker-server systemd[1]: Started Bluetooth service.
dec 12 13:57:30 docker-server bluetoothd[1985]: Starting SDP server
dec 12 13:57:30 docker-server bluetoothd[1985]: Bluetooth management interface 1.14 initialized
dec 12 13:57:30 docker-server bluetoothd[1985]: Endpoint registered: sender=:1.37 path=/MediaEndpoint/A2DPSource
dec 12 13:57:30 docker-server bluetoothd[1985]: Endpoint registered: sender=:1.37 path=/MediaEndpoint/A2DPSink
dec 12 13:57:30 docker-server bluetoothd[1985]: Endpoint registered: sender=:1.37 path=/MediaEndpoint/A2DPSource
dec 12 13:57:30 docker-server bluetoothd[1985]: Endpoint registered: sender=:1.37 path=/MediaEndpoint/A2DPSink

269 │ Waiting │ 80 │ 1.1.3 │ org.sputnikdev:org.eclipse.smarthome.binding.bluetooth.transport.tinyb 270 │ Active │ 80 │ 1.1.6 │ org.sputnikdev:org.eclipse.smarthome.binding.bluetooth

19:27:54.319 [ERROR] [ome.binding.bluetooth.transport.tinyb] - bundle org.sputnikdev.org.eclipse.smarthome.binding.bluetooth.transport.tinyb:1.1.3 (269)[binding.bluetooth.transport.tinyb.activator(374)] : The activate method has thrown an exception
java.lang.IllegalStateException: Could not load native libraries for TinyB
        at org.sputnikdev.esh.binding.bluetooth.transport.tinyb.activator.TinyBActivator.activate(TinyBActivator.java:19) ~[?:?]
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:?]
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) ~[?:?]
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:?]
        at java.lang.reflect.Method.invoke(Method.java:498) ~[?:?]
        at org.apache.felix.scr.impl.inject.methods.BaseMethod.invokeMethod(BaseMethod.java:228) ~[39:org.apache.felix.scr:2.1.2]
        at org.apache.felix.scr.impl.inject.methods.BaseMethod.access$500(BaseMethod.java:41) ~[39:org.apache.felix.scr:2.1.2]
        at org.apache.felix.scr.impl.inject.methods.BaseMethod$Resolved.invoke(BaseMethod.java:664) ~[39:org.apache.felix.scr:2.1.2]
        at org.apache.felix.scr.impl.inject.methods.BaseMethod.invoke(BaseMethod.java:510) [39:org.apache.felix.scr:2.1.2]
        at org.apache.felix.scr.impl.inject.methods.ActivateMethod.invoke(ActivateMethod.java:317) [39:org.apache.felix.scr:2.1.2]
        at org.apache.felix.scr.impl.inject.methods.ActivateMethod.invoke(ActivateMethod.java:307) [39:org.apache.felix.scr:2.1.2]
        at org.apache.felix.scr.impl.manager.SingleComponentManager.createImplementationObject(SingleComponentManager.java:334) [39:org.apache.felix.scr:2.1.2]
        at org.apache.felix.scr.impl.manager.SingleComponentManager.createComponent(SingleComponentManager.java:114) [39:org.apache.felix.scr:2.1.2]
        at org.apache.felix.scr.impl.manager.SingleComponentManager.getService(SingleComponentManager.java:947) [39:org.apache.felix.scr:2.1.2]
        at org.apache.felix.scr.impl.manager.SingleComponentManager.getServiceInternal(SingleComponentManager.java:919) [39:org.apache.felix.scr:2.1.2]
        at org.apache.felix.scr.impl.manager.AbstractComponentManager.activateInternal(AbstractComponentManager.java:750) [39:org.apache.felix.scr:2.1.2]
        at org.apache.felix.scr.impl.manager.AbstractComponentManager.enableInternal(AbstractComponentManager.java:661) [39:org.apache.felix.scr:2.1.2]
        at org.apache.felix.scr.impl.manager.AbstractComponentManager.enable(AbstractComponentManager.java:427) [39:org.apache.felix.scr:2.1.2]
        at org.apache.felix.scr.impl.manager.ConfigurableComponentHolder.enableComponents(ConfigurableComponentHolder.java:665) [39:org.apache.felix.scr:2.1.2]
        at org.apache.felix.scr.impl.BundleComponentActivator.initialEnable(BundleComponentActivator.java:339) [39:org.apache.felix.scr:2.1.2]
        at org.apache.felix.scr.impl.Activator.loadComponents(Activator.java:381) [39:org.apache.felix.scr:2.1.2]
        at org.apache.felix.scr.impl.Activator.access$200(Activator.java:49) [39:org.apache.felix.scr:2.1.2]
        at org.apache.felix.scr.impl.Activator$ScrExtension.start(Activator.java:263) [39:org.apache.felix.scr:2.1.2]
        at org.apache.felix.scr.impl.AbstractExtender.createExtension(AbstractExtender.java:196) [39:org.apache.felix.scr:2.1.2]
        at org.apache.felix.scr.impl.AbstractExtender.modifiedBundle(AbstractExtender.java:169) [39:org.apache.felix.scr:2.1.2]
        at org.apache.felix.scr.impl.AbstractExtender.modifiedBundle(AbstractExtender.java:49) [39:org.apache.felix.scr:2.1.2]
        at org.osgi.util.tracker.BundleTracker$Tracked.customizerModified(BundleTracker.java:482) [?:?]
        at org.osgi.util.tracker.BundleTracker$Tracked.customizerModified(BundleTracker.java:415) [?:?]
        at org.osgi.util.tracker.AbstractTracked.track(AbstractTracked.java:232) [?:?]
        at org.osgi.util.tracker.BundleTracker$Tracked.bundleChanged(BundleTracker.java:444) [?:?]
        at org.eclipse.osgi.internal.framework.BundleContextImpl.dispatchEvent(BundleContextImpl.java:908) [?:?]
        at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:230) [?:?]
        at org.eclipse.osgi.framework.eventmgr.ListenerQueue.dispatchEventSynchronous(ListenerQueue.java:148) [?:?]
        at org.eclipse.osgi.internal.framework.EquinoxEventPublisher.publishBundleEventPrivileged(EquinoxEventPublisher.java:213) [?:?]
        at org.eclipse.osgi.internal.framework.EquinoxEventPublisher$1.run(EquinoxEventPublisher.java:124) [?:?]
        at org.eclipse.osgi.internal.framework.EquinoxEventPublisher$1.run(EquinoxEventPublisher.java:1) [?:?]
        at java.security.AccessController.doPrivileged(Native Method) ~[?:?]
        at org.eclipse.osgi.internal.framework.EquinoxEventPublisher.publishBundleEvent(EquinoxEventPublisher.java:122) [?:?]
        at org.eclipse.osgi.internal.framework.EquinoxEventPublisher.publishBundleEvent(EquinoxEventPublisher.java:112) [?:?]
        at org.eclipse.osgi.internal.framework.EquinoxContainerAdaptor.publishModuleEvent(EquinoxContainerAdaptor.java:168) [?:?]
        at org.eclipse.osgi.container.Module.publishEvent(Module.java:476) [?:?]
        at org.eclipse.osgi.container.Module.start(Module.java:467) [?:?]
        at org.eclipse.osgi.internal.framework.EquinoxBundle.start(EquinoxBundle.java:383) [?:?]
        at org.apache.karaf.bundle.command.Restart.doExecute(Restart.java:51) [42:org.apache.karaf.bundle.core:4.2.1]
        at org.apache.karaf.bundle.command.BundlesCommand.execute(BundlesCommand.java:55) [42:org.apache.karaf.bundle.core:4.2.1]
        at org.apache.karaf.shell.impl.action.command.ActionCommand.execute(ActionCommand.java:84) [14:org.apache.karaf.shell.core:4.2.1]
        at org.apache.karaf.shell.impl.console.osgi.secured.SecuredCommand.execute(SecuredCommand.java:68) [14:org.apache.karaf.shell.core:4.2.1]
        at org.apache.karaf.shell.impl.console.osgi.secured.SecuredCommand.execute(SecuredCommand.java:86) [14:org.apache.karaf.shell.core:4.2.1]
        at org.apache.felix.gogo.runtime.Closure.executeCmd(Closure.java:599) [14:org.apache.karaf.shell.core:4.2.1]
        at org.apache.felix.gogo.runtime.Closure.executeStatement(Closure.java:526) [14:org.apache.karaf.shell.core:4.2.1]
        at org.apache.felix.gogo.runtime.Closure.execute(Closure.java:415) [14:org.apache.karaf.shell.core:4.2.1]
        at org.apache.felix.gogo.runtime.Pipe.doCall(Pipe.java:416) [14:org.apache.karaf.shell.core:4.2.1]
        at org.apache.felix.gogo.runtime.Pipe.call(Pipe.java:229) [14:org.apache.karaf.shell.core:4.2.1]
        at org.apache.felix.gogo.runtime.Pipe.call(Pipe.java:59) [14:org.apache.karaf.shell.core:4.2.1]
        at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:?]
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [?:?]
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [?:?]
        at java.lang.Thread.run(Thread.java:748) [?:?]

(Vlad Kolotov) #779

Hi @marcel_verpaalen, TinyB transport is trying to load some native libraries that are used to talk to DBus. Only some certain OSs and hardware are supported. So not sure what would be it in in docker environment.

How is it supposed to work in docker env? Does docker container have access to Dbus of the host?

(Constantinos Contis) #780

anyone have managed to connect a xiaomi mi kettle?I install the TinyB ,the binding ,find and add my openhabian adapter (Rpi default) then i add the kettle with a bunch of channels but nothing seems to work.At log the kettle connects and dissconnects every 2-3 seconds and i dont get any other info like status or temperature change…I use opehabian 2.3 on a Rpi 3.

(Vlad Kolotov) #781

Hi @Constantinos_Contis, you don’t need to enable “Connection control” channel. Leave it disabled and you will get some other channels that are “advertised” by your kettle.

(Constantinos Contis) #782

i get all the channels i need but they dont seem to update their values.

(Vlad Kolotov) #783

I suggest you to remove the thing, re-add it from the inbox, do not enable “Connection Control”, wait until new channels get discovered (they won’t be discovered instantly) probably 1-2 mins. Try to refresh your browser page (if you use PaperUI) as paper UI does not add dynamic channels when they get resolved.

Just so you know, the channels that get added when you enable “Conection Control” are different to channels that get added when you disable it. These are different set of channels that get created (connected vs advertised).

(Constantinos Contis) #784

i just need temperature and status so i can dummy display them at my habpanel…so i re-add the kettle and i just link temperature and status when they discovered.Any other binding or adapter setting needed?

(Vlad Kolotov) #785

Nope, should be all good. Not sure how often mi kettle reports temperature though, so you might need to wait some time before it gets discovered…

(Constantinos Contis) #786

Done,seems ther temp is working now i just get the following error at log

2018-12-14 11:22:57.161 [WARN ] [impl.AbstractBluetoothObjectGovernor] - Error occurred while updating governor: /B8:27:EB:63:EF:FC/78:11:DC:C3:D8:24 / 23ae68 : GDBus.Error:org.bluez.Error.Failed: Software caused connection abort