BLE connection loss not recovered — repeated UnknownObject on GattCharacteristic1.WriteValue
Problem
When a SEM6000 device loses its BLE connection (e.g. after a brief power interruption or range drop), sem6000-mqtt does not recover. Instead, it keeps throwing the following warning every minute indefinitely, and no measurements are published until the service is manually restarted:
WARN Connector - Exception in scheduled job
org.freedesktop.dbus.errors.UnknownObject: Method "WriteValue" with signature "aya{sv}"
on interface "org.bluez.GattCharacteristic1" doesn't exist
at com.github.hypfvieh.bluetooth.wrapper.BluetoothGattCharacteristic.writeValue(...)
at org.magcode.sem6000.connector.Connector.send(Connector.java:247)
at org.magcode.sem6000.connector.Connector.requestMeasurements(Connector.java:236)
at org.magcode.sem6000.connector.Connector$1.run(Connector.java:144)
Root cause
When the BLE link drops, BlueZ removes the GATT characteristic D-Bus object. The Connector holds a stale reference to the BluetoothGattCharacteristic instance that was valid at startup. Subsequent writeValue() calls fail because the D-Bus path no longer exists. There is no code path that detects this condition and re-establishes the connection.
Environment
sem6000-mqtt version: 1.1.0- Platform: Home Assistant OS (Linux/ARM)
- BlueZ version: system-provided
Expected behavior
After a BLE disconnection, sem6000-mqtt should detect the broken link, re-scan for the device, reconnect, and resume publishing measurements automatically — without requiring a service restart.
Possible solutions
-
Catch UnknownObject in Connector.send() and trigger reconnect — when a DBusException (specifically UnknownObject) is caught during writeValue, invalidate the current device reference and schedule a reconnect attempt (e.g. exponential backoff). This is the most targeted fix.
-
Subscribe to BlueZ PropertiesChanged signals — listen for Connected: false on the device's D-Bus interface (org.bluez.Device1). On disconnect, proactively clean up the GATT references and re-initiate the connection flow before the next measurement cycle fires.
-
Periodic connection health check — before each requestMeasurements() call, verify that device.isConnected() is still true. If not, reconnect before attempting to write.
Workaround
Restart the sem6000-mqtt service whenever the device goes unavailable (e.g. via a systemd watchdog or an external automation that detects the MQTT sensor going stale).
BLE connection loss not recovered — repeated
UnknownObjectonGattCharacteristic1.WriteValueProblem
When a SEM6000 device loses its BLE connection (e.g. after a brief power interruption or range drop),
sem6000-mqttdoes not recover. Instead, it keeps throwing the following warning every minute indefinitely, and no measurements are published until the service is manually restarted:Root cause
When the BLE link drops, BlueZ removes the GATT characteristic D-Bus object. The
Connectorholds a stale reference to theBluetoothGattCharacteristicinstance that was valid at startup. SubsequentwriteValue()calls fail because the D-Bus path no longer exists. There is no code path that detects this condition and re-establishes the connection.Environment
sem6000-mqttversion: 1.1.0Expected behavior
After a BLE disconnection,
sem6000-mqttshould detect the broken link, re-scan for the device, reconnect, and resume publishing measurements automatically — without requiring a service restart.Possible solutions
Catch
UnknownObjectinConnector.send()and trigger reconnect — when aDBusException(specificallyUnknownObject) is caught duringwriteValue, invalidate the current device reference and schedule a reconnect attempt (e.g. exponential backoff). This is the most targeted fix.Subscribe to BlueZ
PropertiesChangedsignals — listen forConnected: falseon the device's D-Bus interface (org.bluez.Device1). On disconnect, proactively clean up the GATT references and re-initiate the connection flow before the next measurement cycle fires.Periodic connection health check — before each
requestMeasurements()call, verify thatdevice.isConnected()is still true. If not, reconnect before attempting to write.Workaround
Restart the
sem6000-mqttservice whenever the device goes unavailable (e.g. via a systemd watchdog or an external automation that detects the MQTT sensor going stale).