BLE-only config entries never start the command queue, so all queued commands are silently dropped

[ahinko]

The problem

Setup: Luba 2 AWD 3000X, firmware 1.30.29.8, integration 0.6.4, pymammotion 0.8.14, HA 2026.8.2. Bluetooth-only config entry (source: bluetooth), no cloud account, ESP32-S3 BLE proxy.

Symptom: move_forward/back/left/right do nothing. Map sync does nothing. Schedule sync does nothing. No errors, no warnings, nothing in the log at any level.

Cause: the command queue processor is never started on a BLE-only entry.

• queue.start() has one caller: DeviceHandle.start()
• DeviceHandle.start() has one caller: _register_device_on_transport(), which is the cloud registration path
• a bluetooth entry registers via add_ble_only_device(), which never calls it
• the integration has no .start() calls anywhere

So queue._process() never exists and anything enqueued sits there forever. send_command_with_args() logs before it enqueues, which is why the log looks like the command was sent.

This explains why some commands work and others don't. async_send_and_wait goes straight to handle.send_raw and bypasses the queue, so leave_dock, cancel_job, start_task, blade height and lights all work. async_send_command goes through the queue, so the four move_* and every saga do not.

Evidence: with debug logging on, pressing cancel (unqueued) logs send_raw ... sending via ble in the same millisecond. Pressing sync schedules (queued) logs enqueuing PlanFetchSaga and then nothing, ever. Repeated three times, including after a config entry reload.

Fix that works, in custom_components/mammotion/__init__.py, capture the handle from both add_ble_only_device branches and start it:

ble_handle = await mammotion.add_ble_only_device(...)
await ble_handle.start()

Needs a full HA restart to load, a config entry reload re-runs setup from the cached module.

After that: the mower moves, Saga 'map_fetch' completed on attempt 1, PlanFetchSaga fetched 6 plans. The stock nudge buttons work too, at their hardcoded 0.4.

No PR because I don't know where you want it. add_ble_only_device could start the handle itself instead of documenting that the caller must (its docstring currently says "Call handle.start() to begin the command queue"), which would fix it for every consumer rather than just this integration. Happy to open a PR against whichever repo you prefer.

Note this is not the same as #681. Everyone in that thread has a cloud account, so their queue is running, and their commands reach send_raw and either work or return real errors. This failure is silent.

What Mammotion device are you using?

Luba 2 AWD 3000X

What version of the Mammotion integration are you using?

v0.6.4

What version of Home Assistant Core are you running?

core-2026.8.3

[mikey0000]

Thanks for the report I'll investigate it, ble has it's own polling loop so not sure what happened there.