Bluetooth Binding: "Critical error while reading DBUS response"

At startup, I see this error in the logs:

15:53:44.788 [INFO ] [org.openhab.core.Activator           ] - Starting openHAB 4.3.5 (Release Build)
15:53:45.166 [INFO ] [b.core.internal.i18n.I18nProviderImpl] - Time zone set to 'Europe/Brussels'.
15:53:45.174 [INFO ] [b.core.internal.i18n.I18nProviderImpl] - Location set to 'XXXXXXXXXXXXXXXXX'.
15:53:45.175 [INFO ] [b.core.internal.i18n.I18nProviderImpl] - Locale set to 'nl_BE'.
15:53:45.176 [INFO ] [b.core.internal.i18n.I18nProviderImpl] - Measurement system set to 'SI'.
15:53:55.794 [INFO ] [b.core.model.lsp.internal.ModelServer] - Started Language Server Protocol (LSP) service on port 5007
15:53:58.931 [WARN ] [tty.util.ssl.SslContextFactory.config] - Trusting all certificates configured for Client@2304e6a6[provider=null,keyStore=null,trustStore=null]
15:53:58.936 [WARN ] [tty.util.ssl.SslContextFactory.config] - No Client EndPointIdentificationAlgorithm configured for Client@2304e6a6[provider=null,keyStore=null,trustStore=null]
15:54:05.027 [INFO ] [.io.openhabcloud.internal.CloudClient] - Connected to the openHAB Cloud service (UUID = 3e...42, base URL = http://localhost:8080)
15:54:05.229 [WARN ] [tty.util.ssl.SslContextFactory.config] - Trusting all certificates configured for Client@e3f3c30[provider=null,keyStore=null,trustStore=null]
15:54:05.231 [WARN ] [tty.util.ssl.SslContextFactory.config] - No Client EndPointIdentificationAlgorithm configured for Client@e3f3c30[provider=null,keyStore=null,trustStore=null]
15:54:06.016 [INFO ] [internal.manager.ShellyManagerServlet] - Shelly Manager started at http(s)://192.168.1.9:8080/shelly/manager
15:54:30.417 [ERROR] [com.github.hypfvieh.DbusHelper       ] - Critical error while reading DBUS response (maybe no bluetoothd daemon running?)
org.freedesktop.dbus.errors.NoReply: No reply within specified time
        at org.freedesktop.dbus.RemoteInvocationHandler.executeRemoteMethod(RemoteInvocationHandler.java:202) ~[?:?]
        at org.freedesktop.dbus.RemoteInvocationHandler.invoke(RemoteInvocationHandler.java:89) ~[?:?]
        at jdk.proxy22.$Proxy146.Introspect(Unknown Source) ~[?:?]
        at com.github.hypfvieh.DbusHelper.findNodes(DbusHelper.java:41) ~[?:?]
        at com.github.hypfvieh.bluetooth.DeviceManager.scanForBluetoothAdapters(DeviceManager.java:114) ~[?:?]
        at org.openhab.binding.bluetooth.bluez.internal.DeviceManagerWrapper.scanForBluetoothAdapters(DeviceManagerWrapper.java:45) ~[?:?]
        at org.openhab.binding.bluetooth.bluez.internal.BlueZDiscoveryService.startScan(BlueZDiscoveryService.java:90) ~[?:?]
        at org.openhab.binding.bluetooth.bluez.internal.BlueZDiscoveryService.lambda$0(BlueZDiscoveryService.java:71) ~[?:?]
        at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:572) ~[?:?]
        at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:358) ~[?:?]
        at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:305) ~[?:?]
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1144) ~[?:?]
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:642) ~[?:?]
        at java.lang.Thread.run(Thread.java:1583) [?:?]

This seems tied to bluetooth.service, and that indeed seems not to be running:

erik@MinipcLG2:/usr/share/openhab/addons$ sudo systemctl status bluetooth.service
○ bluetooth.service - Bluetooth service
     Loaded: loaded (/usr/lib/systemd/system/bluetooth.service; enabled; preset: enabled)
     Active: inactive (dead)
       Docs: man:bluetoothd(8)

aug 02 03:47:36 MinipcLG2 systemd[1]: bluetooth.service - Bluetooth service was skipped because of an unmet condition check (ConditionPathIsDirectory=/sys/class/bluetooth).

But what does that mean…? My Linux box, by the way, doesn’t have a Bluetooth dongle or something like that. I installed the binding on @seime’s advice, in order to get my b-parasite sensors working.

Does anyone have any advice? :slight_smile:

Hi @ErikDB

While I can’t help you with the Bluetooth Binding, we have the b-parasite sensor included in Theengs Decoder.

So you could use OpenMQTTGateway on an ESP32 or Theengs Gateway on your machine running openHAB (Bluetooth required though) to receive the b-parasite sensors. With the MQTT Binding in openHAB they will also be auto-discovered.

The bluetooth binding is needed by the BTHome binding, and Bluetooth connectivity is provided by the ESPHome binding.

When installing the Bluetooth binding you also get a lot of bundles that either provides adapter support (like BlueZ) or device support (like Airthings).

It may look like the BlueZ bundle expects BlueZ linux package to exist, which is doesn’t on your setup. Try to disable any other Bluetooth bundle except for Bluetooth core.

What exactly do you mean by this? And/or how would one do that? :slight_smile:

openhab-cli console

bundle:list |grep Bluetooth

For each in the list that isn’t `Bluetooth Binding`, run bundle:uninstall XXX where XXX is the bundle ID to the left:

Note: Start with the BlueZ one (in my setup bundle ID 306 and see if this solves the problem (or creates new ones, I’m by no means any expert here on inter bundle dependencies).

If it doesn’t help, double check that OH hasn’t reinstalled it after the OH restart.

openhab> bundle:list|grep Bluetoo
302 │ Active │  80 │ 4.3.1                 │ openHAB Add-ons :: Bundles :: Bluetooth Binding
303 │ Active │  80 │ 4.3.1                 │ openHAB Add-ons :: Bundles :: Airthings Bluetooth Adapter
304 │ Active │  80 │ 4.3.1                 │ openHAB Add-ons :: Bundles :: AM43 Bluetooth Adapter
305 │ Active │  80 │ 4.3.1                 │ openHAB Add-ons :: Bundles :: BlueGiga Bluetooth Adapter
306 │ Active │  80 │ 4.3.1                 │ openHAB Add-ons :: Bundles :: BlueZ Bluetooth Adapter
307 │ Active │  80 │ 4.3.1                 │ openHAB Add-ons :: Bundles :: Blukii Bluetooth Adapter
308 │ Active │  80 │ 4.3.1                 │ openHAB Add-ons :: Bundles :: DaikinMadoka Bluetooth Adapter
309 │ Active │  80 │ 4.3.1                 │ openHAB Add-ons :: Bundles :: EnOcean Bluetooth Adapter
310 │ Active │  80 │ 4.3.1                 │ openHAB Add-ons :: Bundles :: Generic Bluetooth Adapter
311 │ Active │  80 │ 4.3.1                 │ openHAB Add-ons :: Bundles :: Govee Bluetooth Adapter
313 │ Active │  80 │ 4.3.1                 │ openHAB Add-ons :: Bundles :: HD Powerview Bluetooth Adapter
314 │ Active │  80 │ 4.3.1                 │ openHAB Add-ons :: Bundles :: RadonEye Bluetooth Adapter
315 │ Active │  80 │ 4.3.1                 │ openHAB Add-ons :: Bundles :: Roaming Bluetooth Adapter
316 │ Active │  80 │ 4.3.1                 │ openHAB Add-ons :: Bundles :: RuuviTag Bluetooth Adapter
1 Like

It seems to exist:

erik@MinipcLG2:~$ sudo apt install bluez
Pakketlijsten worden ingelezen... Klaar
Boom van vereisten wordt opgebouwd... Klaar
De statusinformatie wordt gelezen... Klaar
bluez is reeds de nieuwste versie (5.72-0ubuntu5.3).
0 opgewaardeerd, 0 nieuw geïnstalleerd, 0 te verwijderen en 1 niet opgewaardeerd.

To my surprise, this showed nothing… :thinking:

openhab> bundle:list | grep -i Bluetooth
openhab>

I removed the BlueZ Bluetooth Adapter, and the error is gone. Also, the BLE device I wanted to connect with, still does its thing in openHAB. Hooray!

I now upgraded to 5.0.1, and this seems to happen every time… Is there a way to avoid that?

If you specify bluetooth in the addons.cfg, it will happen every time. It might also happen every time OH is upgraded.

It seems that OH expects Bluez and the bluetooth service to be running - did you try to enable it to silence the Bluez discovery?

That file is filled with only commented lines.

I think this is what you mean:

erik@MinipcLG2:/usr/share/openhab/addons$ sudo systemctl status bluetooth
○ bluetooth.service - Bluetooth service
     Loaded: loaded (/usr/lib/systemd/system/bluetooth.service; enabled; preset: enabled)
     Active: inactive (dead)
       Docs: man:bluetoothd(8)

aug 28 19:09:44 MinipcLG2 systemd[1]: bluetooth.service - Bluetooth service was skipped because of an unmet condition check (ConditionPathIsDirectory=/sys/class/bluetooth).
aug 28 19:54:00 MinipcLG2 systemd[1]: bluetooth.service - Bluetooth service was skipped because of an unmet condition check (ConditionPathIsDirectory=/sys/class/bluetooth).
aug 28 21:11:18 MinipcLG2 systemd[1]: bluetooth.service - Bluetooth service was skipped because of an unmet condition check (ConditionPathIsDirectory=/sys/class/bluetooth).
aug 28 21:18:09 MinipcLG2 systemd[1]: bluetooth.service - Bluetooth service was skipped because of an unmet condition check (ConditionPathIsDirectory=/sys/class/bluetooth).
erik@MinipcLG2:/usr/share/openhab/addons$ sudo systemctl start bluetooth
erik@MinipcLG2:/usr/share/openhab/addons$ sudo systemctl status bluetooth
○ bluetooth.service - Bluetooth service
     Loaded: loaded (/usr/lib/systemd/system/bluetooth.service; enabled; preset: enabled)
     Active: inactive (dead)
       Docs: man:bluetoothd(8)

aug 28 19:09:44 MinipcLG2 systemd[1]: bluetooth.service - Bluetooth service was skipped because of an unmet condition check (ConditionPathIsDirectory=/sys/class/bluetooth).
aug 28 19:54:00 MinipcLG2 systemd[1]: bluetooth.service - Bluetooth service was skipped because of an unmet condition check (ConditionPathIsDirectory=/sys/class/bluetooth).
aug 28 21:11:18 MinipcLG2 systemd[1]: bluetooth.service - Bluetooth service was skipped because of an unmet condition check (ConditionPathIsDirectory=/sys/class/bluetooth).
aug 28 21:18:09 MinipcLG2 systemd[1]: bluetooth.service - Bluetooth service was skipped because of an unmet condition check (ConditionPathIsDirectory=/sys/class/bluetooth).
aug 28 21:18:32 MinipcLG2 systemd[1]: bluetooth.service - Bluetooth service was skipped because of an unmet condition check (ConditionPathIsDirectory=/sys/class/bluetooth).

?

For some reason (ConditionPathIsDirectory=/sys/class/bluetooth) the service won’t start… I assume it’s got something to do that my mini pc probably doesn’t support Bluetooth?

I’m by no means an Linux system administrator, maybe someone with more knowledge regarding BlueZ and general linux bluetooth setup can comment.

@laursen @wborn, apologies for the spam, but I saw you contributed to the Bluez binding. Maybe you could offer some useful insight here? :slight_smile:

Anyone? :smiling_face_with_tear:

Could you elaborate on how OpenMQTTGateway is to be installed/flashed onto the ESP32? The docs don’t seem to mention any (yaml) code?

No yaml or any other code required. Just install the generic BLE binary of OpenMQTTGateway from the web upload page, which is esp32dev-ble or any of the other BLE version if your ESP32 is an Olimex, M5stick …

Then follow the inital Wifi and MQTT configuration

With an MQTT broker and the MQTT binding installed, the gateway itself will also be auto-discovered for easy adjustment of the gateway parameters, but the default reception of BLE broadcasts once a minute should be fine for your b-parasite sensor.