Connect error: Method "Connect" with signature "" on interface "org.bluez.Device1" doesn't exist

[LarsStegman]

Description

Hello,

I have successfully found my scale's MAC address and configured it. The application successfully discovers the scale, but when it tries to connect it fails with the error Connect error: Method "Connect" with signature "" on interface "org.bluez.Device1" doesn't exist

I have a Silvergear Smart Scale model number 108.

Steps to Reproduce

1. Configure MAC address and other settings
2. Start add on in debug mode
3. Step on scale
4. Device is discovered
5. Connect fails with Connect error: Method "Connect" with signature "" on interface "org.bluez.Device1" doesn't exist
   .

Scale Brand / Model

Silvergear Smart Scale

Platform

Home Assistant OS on Raspberry Pi 5

Node.js Version

ha addon

App Version

1.21.1

Debug Logs

[ble-scale-sync] Generating config.yaml...
[ble-scale-sync] WARNING: MQTT is enabled but no broker URL is available
[ble-scale-sync] Install the Mosquitto add-on or provide a broker URL manually
[ble-scale-sync] Config generated successfully
[ble-scale-sync] Resetting Bluetooth adapter (hci0)...
[ble-scale-sync] Bluetooth adapter reset OK
[ble-scale-sync] Starting BLE Scale Sync...
2026-07-26 11:24:36.437 [Config] Loading config from /data/config.yaml
2026-07-26 11:24:36.464 [Sync] BLE Scale Sync (continuous)
2026-07-26 11:24:36.464 [Sync] Scanning for scale A0:85:61:91:E9:4F...
2026-07-26 11:24:36.467 [Sync] Adapters: Eufy Smart Scale P2/P2 Pro, Senssun Fat Scale, QN Scale, Renpho ES-WBE28, Renpho R-MSC04, Renpho ES-26BB, Beurer BF720/BF105, Xiaomi Mi Scale 2, Xiaomi Mijia Scale S800, Yunmai, Beurer / Sanitas, Sanitas SBF72/73, Soehnle Shape/Style, Medisana BS44x, Trisa, ES-CS20M, Exingtech Y1, Excelvan CF369, Hesley, Koogeek-S1, Inlife, Digoo, 1byone (Eufy), 1byone Scale (new), Active Era BS-06, Robi S9, Hutbit, MGB (Swan/Icomon/YG), Hoffen BS-8107, Standard GATT (BCS/WSS)
2026-07-26 11:24:36.468 [ConfigWatch] Watching /data/config.yaml for changes (auto-reload enabled)
2026-07-26 11:24:36.469 [BLE:debug] BLE handler: node-ble (BlueZ D-Bus)
2026-07-26 11:24:36.526 [BLE:debug] D-Bus connection established
2026-07-26 11:24:36.586 [BLE:debug] Discovery started
2026-07-26 11:24:36.586 [BLE] Scanning for device...
2026-07-26 11:24:47.608 [BLE:debug] Found device: 108 [A0:85:61:91:E9:4F]
2026-07-26 11:24:47.611 [BLE:debug] Stopping discovery before connect...
2026-07-26 11:24:47.615 [BLE:debug] Discovery stopped
2026-07-26 11:24:48.118 [BLE:debug] Connect attempt 1/6...
2026-07-26 11:24:48.120 [BLE] Connect error: Method "Connect" with signature "" on interface "org.bluez.Device1" doesn't exist
. Retrying (1/5) in 1000ms...
2026-07-26 11:24:48.120 [BLE:debug] Disconnecting before retry...
2026-07-26 11:24:48.121 [BLE:debug] Disconnect failed (ignored)
2026-07-26 11:24:49.131 [BLE:debug] Discovery started
2026-07-26 11:24:54.644 [BLE:debug] Connect attempt 2/6...
2026-07-26 11:24:54.646 [BLE] Connect error: interface not found in proxy object: org.bluez.Device1. Retrying (2/5) in 1500ms...
2026-07-26 11:24:54.646 [BLE:debug] Disconnecting before retry...
2026-07-26 11:24:54.647 [BLE:debug] Disconnect failed (ignored)
2026-07-26 11:24:56.157 [BLE:debug] Discovery started
2026-07-26 11:25:01.671 [BLE:debug] Connect attempt 3/6...
2026-07-26 11:25:01.672 [BLE] Connect error: interface not found in proxy object: org.bluez.Device1. Retrying (3/5) in 2000ms...
2026-07-26 11:25:01.673 [BLE:debug] Disconnecting before retry...
2026-07-26 11:25:01.673 [BLE:debug] Disconnect failed (ignored)
2026-07-26 11:25:03.685 [BLE:debug] Discovery started
2026-07-26 11:25:08.198 [BLE:debug] Connect attempt 4/6...
2026-07-26 11:25:08.199 [BLE] Connect error: interface not found in proxy object: org.bluez.Device1. Retrying (4/5) in 2500ms...
2026-07-26 11:25:08.199 [BLE:debug] Disconnecting before retry...
2026-07-26 11:25:08.200 [BLE:debug] Disconnect failed (ignored)
2026-07-26 11:25:10.713 [BLE:debug] Discovery started
2026-07-26 11:25:12.220 [BLE:debug] Connect attempt 5/6...
2026-07-26 11:25:12.221 [BLE] Connect error: interface not found in proxy object: org.bluez.Device1. Retrying (5/5) in 3000ms...
2026-07-26 11:25:12.221 [BLE:debug] Disconnecting before retry...
2026-07-26 11:25:12.222 [BLE:debug] Disconnect failed (ignored)
2026-07-26 11:25:15.231 [BLE:debug] Discovery started
2026-07-26 11:25:17.741 [BLE:debug] Connect attempt 6/6...
2026-07-26 11:25:17.743 [BLE:debug] Force StopDiscovery failed: No discovery started
2026-07-26 11:25:18.248 [BLE:debug] D-Bus connection reset
2026-07-26 11:25:18.248 [BLE:debug] D-Bus connection reset after GATT operation
2026-07-26 11:25:18.258 [BLE:debug] btmgmt: adapter powered off
2026-07-26 11:25:18.890 [BLE:debug] btmgmt: adapter powered on
2026-07-26 11:25:20.892 [BLE:debug] Preemptive btmgmt reset after GATT

Configuration file

scale_mac: A0:85:61:91:E9:4F
ble_adapter: ""
weight_unit: kg
height_unit: cm
user_name: larsstegman
user_height: 183
user_birth_date: "xxxx-xx-xx"
user_gender: male
user_is_athlete: false
user_weight_min: 40
user_weight_max: 150
mqtt_enabled: true
mqtt_auto: true
mqtt_broker_url: ""
mqtt_username: ""
mqtt_password: ""
mqtt_topic: scale/body-composition
mqtt_ha_discovery: true
mqtt_ha_device_name: Silvergear Smart Scale
garmin_enabled: false
garmin_email: ""
garmin_password: ""
scan_cooldown: 30
reset_bluetooth: true
debug: true
custom_config: false

[KristianP26]

Thanks, that log is unusually informative. The two different error messages are the whole story.

Attempt 1 fails with Method "Connect" ... doesn't exist, which is bluetoothd answering on a proxy we built earlier and cached. Attempts 2 to 5 fail with interface not found in proxy object, which is what dbus-next says when it freshly introspects the path and finds no org.bluez.Device1 on it. Different wording, same cause: the D-Bus object for your scale is being deleted between discovery and connect. The timing matches exactly. We stop discovery at 11:24:47.615, wait 500 ms, and connect at 11:24:48.118, and by then the object is gone. The tell is the silence right after: our RemoveDevice step logs nothing at all, which only happens when BlueZ says "Device not found", so the node was already gone at 48.121.

BlueZ scopes the Device object of a peer that is not connectable, or not discoverable, to the lifetime of a discovery session. Your scale looks like one of those.

On dev now (ghcr.io/kristianp26/ble-scale-sync:dev): when we see that error we stop stopping discovery between attempts and connect with scanning still active, only stopping it once the link is up, where BlueZ no longer drops the object. If every attempt still fails that way, the error message now says so plainly instead of repeating the D-Bus text. Nothing changes for other users: the strategy is only armed after the error is actually seen. The build also logs the advertised UUIDs, service data and manufacturer data at discovery, which is the one moment BlueZ still holds them.

To confirm the cause, and to know whether a GATT connection is possible for this model at all, two things would help.

1. The decisive one. Start the add-on, step on the scale, and the moment the log prints Discovery stopped run:

busctl --system introspect org.bluez /org/bluez/hci0/dev_A0_85_61_91_E9_4F | head -40

Then restart it and run the same command while the log still says Scanning for device..., before Discovery stopped. Paste both. If the second shows an org.bluez.Device1 block and the first says Unknown object or shows none, that confirms it.

2. Is it connectable at all. Open nRF Connect (or any BLE scanner) on a phone, find 108 at A0:85:61:91:E9:4F, and tell me whether a CONNECT button is offered and, if it connects, which services it lists. Also: which phone app reads this scale, and does it work?

I ask because of the second half of this. A different Silvergear model (#266) turned out to be a Tuya device advertising service 0000fd50. Tuya BLE scales only respond after an encrypted session handshake keyed on a per-device local key from the Tuya cloud, and if yours is in that family no amount of connect fixing will make it readable without that key. The Advert: line in the dev build will show it: if the UUID list contains 0000fd50-0000-1000-8000-00805f9b34fb, that is the answer, and I would rather tell you that now than after another week of debugging.

Most valuable of all, if you can manage it: an Android HCI snoop of one weigh-in through the working phone app (Developer options, "Enable Bluetooth HCI snoop log", weigh yourself, pull btsnoop_hci.log). That shows whether the app connects at all or only listens to advertisements, and gives me the frame format either way. That is how the Beurer BF788 in #229 got decoded.

[KristianP26]

Released in v1.21.2, so this is now on main, in the latest Docker image and in the Home Assistant add-on rather than only on dev. Everything described above applies to the released build; no need to run :dev to test it.

Leaving this open until you confirm it works for you.

[LarsStegman]

Hello,

thanks for the detailed response!

Unfortunately, it still doesn't seem to work.

I am using the "Silvergear Fit" app to connect to the scale. It works perfectly fine, but it's just annoying to have to pull out my phone every time.

busctl
I can't run busctl on Home Assistant, it doesn't seem to be available.

nRF
I did run nRF and it the device is not connectable. It only seems to offer service FFB0.

The log

Details

[ble-scale-sync] Generating config.yaml...
[ble-scale-sync] Config generated successfully
[ble-scale-sync] Bluetooth adapter reset disabled (reset_bluetooth: false)
[ble-scale-sync] Starting BLE Scale Sync...
2026-07-27 18:43:27.594 [Config] Loading config from /data/config.yaml
2026-07-27 18:43:27.621 [Sync] BLE Scale Sync (continuous)
2026-07-27 18:43:27.621 [Sync] BLE adapter: hci0
2026-07-27 18:43:27.622 [Sync] Scanning for scale A0:85:61:91:E9:4F...
2026-07-27 18:43:27.623 [Sync] Adapters: Eufy Smart Scale P2/P2 Pro, Senssun Fat Scale, QN Scale, Renpho ES-WBE28, Renpho R-MSC04, Renpho ES-26BB, Beurer BF720/BF105, Xiaomi Mi Scale 2, Xiaomi Mijia Scale S800, Yunmai, Beurer / Sanitas, Sanitas SBF72/73, Soehnle Shape/Style, Medisana BS44x, Trisa, ES-CS20M, Exingtech Y1, Excelvan CF369, Hesley, Koogeek-S1, Inlife, Digoo, 1byone (Eufy), 1byone Scale (new), Active Era BS-06, Robi S9, Hutbit, MGB (Swan/Icomon/YG), Hoffen BS-8107, Standard GATT (BCS/WSS)
2026-07-27 18:43:27.624 [Sync] Running exporter healthchecks...
2026-07-27 18:43:27.957 [Sync]   mqtt: OK
2026-07-27 18:43:27.957 [ConfigWatch] Watching /data/config.yaml for changes (auto-reload enabled)
2026-07-27 18:43:27.959 [BLE:debug] BLE handler: node-ble (BlueZ D-Bus)
2026-07-27 18:43:28.002 [BLE:debug] D-Bus connection established
2026-07-27 18:43:28.002 [BLE:debug] Using adapter: hci0
2026-07-27 18:43:28.044 [BLE:debug] Removed device from BlueZ cache
2026-07-27 18:43:28.093 [BLE:debug] Discovery started
2026-07-27 18:43:28.093 [BLE] Scanning for device...
2026-07-27 18:43:34.106 [BLE:debug] Found device: 108 [A0:85:61:91:E9:4F]
2026-07-27 18:43:34.110 [BLE:debug] Advert: addrType=public flags=04 uuids=[0000ffb0-0000-1000-8000-00805f9b34fb] manufacturerData={0xa0ac: 4fe9916185a0a02ca7c20da2}
2026-07-27 18:43:34.112 [BLE:debug] Stopping discovery before connect...
2026-07-27 18:43:34.115 [BLE:debug] Discovery stopped
2026-07-27 18:43:34.618 [BLE:debug] Connect attempt 1/6...
2026-07-27 18:43:34.620 [BLE] BlueZ removed the org.bluez.Device1 object for A0:85:61:91:E9:4F while discovery was stopped, so this peer is only visible while scanning is active. Retrying with discovery left running (#297).
2026-07-27 18:43:34.620 [BLE] Connect error: Method "Connect" with signature "" on interface "org.bluez.Device1" doesn't exist
. Retrying (1/5) in 1000ms...
2026-07-27 18:43:34.620 [BLE:debug] Disconnecting before retry...
2026-07-27 18:43:34.621 [BLE:debug] Disconnect failed (ignored)
2026-07-27 18:43:34.624 [BLE:debug] Device not in BlueZ cache; RemoveDevice is a no-op
2026-07-27 18:43:35.632 [BLE:debug] Discovery started
2026-07-27 18:43:36.644 [BLE:debug] Leaving discovery running for the next connect attempt (#297)
2026-07-27 18:43:37.149 [BLE:debug] Connect attempt 2/6...
2026-07-27 18:44:07.150 [BLE] Connect error: Connection timed out. Retrying (2/5) in 1500ms...
2026-07-27 18:44:07.150 [BLE:debug] Disconnecting before retry...
2026-07-27 18:44:07.152 [BLE:debug] Disconnect OK
2026-07-27 18:44:07.165 [BLE:debug] Device not in BlueZ cache; RemoveDevice is a no-op
2026-07-27 18:44:08.670 [BLE:debug] startDiscovery failed: Discovery already in progress
2026-07-27 18:44:08.671 [BLE:debug] Discovery already active, continuing
2026-07-27 18:44:10.675 [BLE:debug] Leaving discovery running for the next connect attempt (#297)
2026-07-27 18:44:11.179 [BLE:debug] Connect attempt 3/6...
2026-07-27 18:44:41.182 [BLE] Connect error: Connection timed out. Retrying (3/5) in 2000ms...
2026-07-27 18:44:41.183 [BLE:debug] Disconnecting before retry...
2026-07-27 18:44:41.184 [BLE:debug] Disconnect OK
2026-07-27 18:44:41.197 [BLE:debug] Device not in BlueZ cache; RemoveDevice is a no-op
2026-07-27 18:44:43.199 [BLE:debug] startDiscovery failed: Discovery already in progress
2026-07-27 18:44:43.200 [BLE:debug] Discovery already active, continuing
2026-07-27 18:44:44.204 [BLE:debug] Leaving discovery running for the next connect attempt (#297)
2026-07-27 18:44:44.708 [BLE:debug] Connect attempt 4/6...
2026-07-27 18:45:14.711 [BLE] Connect error: Connection timed out. Retrying (4/5) in 2500ms...
2026-07-27 18:45:14.711 [BLE:debug] Disconnecting before retry...
2026-07-27 18:45:14.712 [BLE:debug] Disconnect OK
2026-07-27 18:45:14.725 [BLE:debug] Device not in BlueZ cache; RemoveDevice is a no-op
2026-07-27 18:45:17.227 [BLE:debug] startDiscovery failed: Discovery already in progress
2026-07-27 18:45:17.228 [BLE:debug] Discovery already active, continuing
2026-07-27 18:45:18.231 [BLE:debug] Leaving discovery running for the next connect attempt (#297)
2026-07-27 18:45:18.733 [BLE:debug] Connect attempt 5/6...

[KristianP26]

Thanks, the nRF Connect check plus the screenshots is exactly what was needed, and it changes the diagnosis. Also noted on busctl: Home Assistant OS does not ship it, so I will stop asking for that.

Two things came out of this.

1. Your manufacturer data is decoded, and most of it is not payload

Our debug line showed manufacturerData={0xa0ac: 4fe9916185a0a02ca7c20da2}. BlueZ splits the first two octets of the manufacturer AD element off as a little-endian company id, so the actual bytes on air are:

ac a0 | 4f e9 91 61 85 a0 | a0 2c a7 c2 0d a2
 id      your MAC (LE)      real payload

4f e9 91 61 85 a0 is your MAC A0:85:61:91:E9:4F byte-reversed, confirmed exactly. And 0xA0AC is not a Bluetooth SIG assigned company id, the vendor invented it. So out of those twelve bytes only the last six carry anything: a0 2c a7 c2 0d a2. From a single sample I cannot tell which of those is weight, which is a status flag and which is a checksum, and I am not going to guess.

Worth recording as a lead: service FFB0, plus the MAC repeated inside the advert, plus a company id whose low byte is 0xAC, is the signature of the Lefu / Fitdays OEM family, which we already support under several other brand names. There is a reasonable chance the Silvergear 108 is another rebrand of hardware we partly understand.

2. One thing to re-check before I design around "broadcast only"

Your nRF result is strong evidence, but it is worth one more look before I commit to a listen-only design. Scales in this family very often advertise non-connectably while asleep, and only switch to a connectable advertisement for a short window while the display is lit. If you checked nRF Connect while the scale was idle, "no CONNECT button" is the expected result and would not mean it is never connectable.

That distinction matters a lot. It is the difference between needing a whole new passive code path and needing to connect at the right moment.

So, quickest first:

(A) Open nRF Connect, then step on the scale so the display lights up, and while it is still lit refresh the scan and look at the "108" entry again. Does a CONNECT button appear now? A screenshot of the entry while the scale is awake would settle it. If it does appear, try connecting and screenshot the service list.

Then, regardless of how (A) goes, the advert captures are what actually let me decode the weight:

(B) Five or six captures with known, clearly different weights. For each one: step on the scale or place the object on it, write down the exact kg the scale's own display shows, and capture the Advert: line from our DEBUG log at that moment (the raw manufacturer data bytes from nRF Connect work just as well). Please make the weights genuinely different rather than five readings of the same person. An ideal set is yourself, a second person of clearly different weight, then a heavy object alone at roughly 20 kg and again at roughly 40 kg. Widely spaced values are what pin down the scale factor and the byte order in one pass.

(C) One capture with the scale idle and nothing on it, so I can see which bytes are the resting state and which actually move. Easy to forget and genuinely useful.

(D) Does the scale's display, or the Silvergear Fit app, show body fat at all, or only weight? If body fat appears, is it immediate or does it take a couple of seconds? That tells me whether there is an impedance value hiding in those six bytes or whether this is a weight-only device.

(E) If you are on Android and willing: an HCI snoop of the Silvergear Fit app doing one complete weigh-in. Settings, Developer options, enable Bluetooth HCI snoop log, reboot the phone, do one weigh-in, then take a bug report and attach it. That single file answers everything at once: whether the app connects over GATT or only listens, and if it connects, the entire handshake. It is by far the highest value item here, but (A) and (B) are much less effort so please do not let (E) hold them up.

Where this leaves the issue

I am reclassifying this from a connect bug to a scale support request, because the connect failures are now fully explained rather than mysterious. For transparency about effort: if it turns out to be broadcast only, the adapter itself is a small file, but our Linux path currently cannot drive a manufacturer-data broadcast adapter at all. It only reads service data, which is the gap already tracked as #280. So a Silvergear adapter would work on Windows, macOS and both proxy transports immediately, and would need #280 fixed first to work on a Raspberry Pi or the Home Assistant add-on, which is presumably where you want it. That work is worth doing anyway, and your issue is a concrete second reason to do it.

With (B) and (C) I can very likely decode the weight. Whether this ends up as a listen-only adapter or an ordinary GATT one depends entirely on (A) and (E).

[KristianP26]

Status: nothing new to ask of you yet, and the manufacturer-data decode in my previous comment still stands (only the last six bytes carry payload; the rest is your MAC and an invented company id).

The one thing that would unblock a decode is more samples of those six bytes with the weight the scale displayed at the time. If you can catch two or three advertisements at known, different weights, that is enough to test whether the weight is in there at all.

[KristianP26]

@LarsStegman still nothing new needed from your side beyond the one thing that would unblock the decode: two or three advertisements captured at known, clearly different weights, with the six payload bytes and the weight the scale showed at the time.

Two or three samples is the minimum that can tell "the weight is in here" from "these bytes happen to change". One sample cannot.

One thing that did change on dev and may help you capture them: the proxy transports now print an Advert: line for every device they see, not only the ones an adapter claimed, so the raw manufacturer data is visible in the log without nRF Connect.

If the scale has since stopped being useful to you, say so and I will close this rather than leave it hanging.

[LarsStegman]

Hi, yes I am still using the scale. I thought I responded to your previous message, but obviously I did not. I have couple of days off soon, so I will take a look then :) what is the best way of capturing that is helpful for you? Using the Advert line?

[LarsStegman]

Now with the advert logging, I can just do it in a couple minutes :)

Weight 0.0kg

2026-08-21 10:45:01.821 [BLE:debug] Found device: 108 [A0:85:61:91:E9:4F]
2026-08-21 10:45:01.825 [BLE:debug] Advert: addrType=public flags=04 uuids=[0000ffb0-0000-1000-8000-00805f9b34fb] manufacturerData={0xa0ac: 4fe9916185a0a02c8a2a0dad}
2026-08-21 10:45:01.827 [BLE:debug] Stopping discovery before connect...
2026-08-21 10:45:01.830 [BLE:debug] Discovery stopped
2026-08-21 10:45:02.334 [BLE:debug] Connect attempt 1/6...
2026-08-21 10:45:02.335 [BLE] BlueZ removed the org.bluez.Device1 object for A0:85:61:91:E9:4F while discovery was stopped, so this peer is only visible while scanning is active. Retrying with discovery left running (#297).
2026-08-21 10:45:02.335 [BLE] Connect error: Method "Connect" with signature "" on interface "org.bluez.Device1" doesn't exist
. Retrying (1/5) in 1000ms...
2026-08-21 10:45:02.335 [BLE:debug] Disconnecting before retry...
2026-08-21 10:45:02.336 [BLE:debug] Disconnect failed (ignored)
2026-08-21 10:45:02.339 [BLE:debug] Device not in BlueZ cache; RemoveDevice is a no-op
2026-08-21 10:45:03.346 [BLE:debug] Discovery started

Weight 5.6kg

2026-08-21 10:59:48.022 [BLE:debug] Found device: 108 [A0:85:61:91:E9:4F]
2026-08-21 10:59:48.026 [BLE:debug] Advert: addrType=public flags=04 uuids=[0000ffb0-0000-1000-8000-00805f9b34fb] manufacturerData={0xa0ac: 4fe9916185a0a02cb0dc0da5}
2026-08-21 10:59:48.028 [BLE:debug] Stopping discovery before connect...
2026-08-21 10:59:48.031 [BLE:debug] Discovery stopped
2026-08-21 10:59:48.534 [BLE:debug] Connect attempt 1/6...
2026-08-21 10:59:48.535 [BLE] BlueZ removed the org.bluez.Device1 object for A0:85:61:91:E9:4F while discovery was stopped, so this peer is only visible while scanning is active. Retrying with discovery left running (#297).
2026-08-21 10:59:48.535 [BLE] Connect error: Method "Connect" with signature "" on interface "org.bluez.Device1" doesn't exist
. Retrying (1/5) in 1000ms...
2026-08-21 10:59:48.535 [BLE:debug] Disconnecting before retry...
2026-08-21 10:59:48.536 [BLE:debug] Disconnect failed (ignored)
2026-08-21 10:59:48.539 [BLE:debug] Device not in BlueZ cache; RemoveDevice is a no-op
2026-08-21 10:59:49.546 [BLE:debug] Discovery started
2026-08-21 10:59:50.550 [BLE:debug] Leaving discovery running for the next connect attempt (#297)
2026-08-21 10:59:51.055 [BLE:debug] Connect attempt 2/6...

Weight 108.8kg

2026-08-21 10:51:14.743 [BLE:debug] Found device: 108 [A0:85:61:91:E9:4F]
2026-08-21 10:51:14.746 [BLE:debug] Advert: addrType=public flags=04 uuids=[0000ffb0-0000-1000-8000-00805f9b34fb] manufacturerData={0xa0ac: 4fe9916185a0a0a0a0a206a8}
2026-08-21 10:51:14.748 [BLE:debug] Stopping discovery before connect...
2026-08-21 10:51:14.751 [BLE:debug] Discovery stopped
2026-08-21 10:51:15.255 [BLE:debug] Connect attempt 1/6...
2026-08-21 10:51:15.256 [BLE] BlueZ removed the org.bluez.Device1 object for A0:85:61:91:E9:4F while discovery was stopped, so this peer is only visible while scanning is active. Retrying with discovery left running (#297).
2026-08-21 10:51:15.256 [BLE] Connect error: Method "Connect" with signature "" on interface "org.bluez.Device1" doesn't exist
. Retrying (1/5) in 1000ms...
2026-08-21 10:51:15.256 [BLE:debug] Disconnecting before retry...
2026-08-21 10:51:15.258 [BLE:debug] Disconnect failed (ignored)
2026-08-21 10:51:15.261 [BLE:debug] Device not in BlueZ cache; RemoveDevice is a no-op
2026-08-21 10:51:16.268 [BLE:debug] Discovery started

During the weight test I wore clothes and socks so the impedance measurement is useless probably.

I have to say that with this version it was very difficult to get the scale to even show up. Before it used to show data almost instantly, but now I had to step on the scale 5 times before it would even show up.

[LarsStegman]

I actually managed to make a full measurement capture using PacketLogger on my iPhone + wireshark.

Final weight during measuring was 108.5kg

108.5kg: silvergear full iOS measurement.txt

5.6kg:

silvergear full iOS measurement 5_6.txt