meshcore-dev/meshcore-ha

Problem In custom_components/meshcore/logbook.py, the adaptive-mode background RX_LOG collector is scheduled as a tracked task: if adaptive and hash_key is not None: hass.async_create_task( _collect_incoming_rx_logs(hass, coordinator, hash_key, event_data) ) hass.async_create_task() puts the task in the set that hass.async_block_till_done() waits on, which Home Assistant calls during the startup "wrapping up" phase before firing EVENT_HOMEASSISTANT_STARTED. _collect_incoming_rx_logs() sleeps through _INCOMING_BG_PASS_INTERVALS (0.5s + 1.0s), so any channel message received while HA is still starting holds up the wrap-up phase — and a steady stream of them keeps holding it up. It showed up on my instance in the bootstrap timeout list: 2026-09-08 17:36:39.109 WARNING (MainThread) [homeassistant.bootstrap] Setup timed out for bootstrap waiting on {<Task pending name='Task-6140' coro=<_collect_incoming_rx_logs() running at /config/custom_components/meshcore/logbook.py:249

Doesn't work. Tried pairing it manually with a pin via terminal and trusting it too. Doesn't work at all with Bluetooth on my seeed nrf devices

When sending a direct/private message through the Home Assistant integration using a USB Serial Companion, the message appears to keep using the previously saved DM path / contact out_path. If that path is no longer valid because one of the companions has moved to another repeater area, the message may fail instead of automatically falling back to flood routing. From the MeshCore FAQ, the official app behavior appears to be: Try the known saved path. Retry when the message is not ACKed. After multiple failed retries, reset/clear the saved path. Send again using flood as a fallback. It would be very useful if meshcore-ha could implement the same behavior for direct/private messages sent through Home Assistant. Why this matters A companion is often mobile by design. When a companion moves to another location or another repeater area, the previously learned route may become stale. In the official MeshCore app, this appears to be handled by retrying and eventually falling back to flood.

Having error on Meshcore Intergration start in HA Core: This error occurred in a custom integration. Logger: habluetooth.wrappers Source: custom_components/meshcore/meshcore_api.py:119 Integration: MeshCore (documentation) First reported: 20:13:25 (1 occurrence) Last reported: 20:13:25 E2:B0:5B:4E:DE:F5: The BleakClient.connect() function was called without using the bleak-retry-connector. To reliably establish a connection, use the bleak_retry_connector.establish_connection() function. See https://github.com/Bluetooth-Devices/bleak-retry-connector So sometime connection falls. Only reload of Meshcore Integration (thru automation) helps. Connecting to companion node on NRF52840.

Problem The integration doesn't serialize commands going to the device today. meshcore_api.py:55 allocates self._device_lock = asyncio.Lock() with the comment "Add a lock to prevent concurrent access to the device", but nothing in the codebase actually uses it. This surfaced as a race in #250 (send_channel_message scope param): the new code issues set_flood_scope(scope) → send_chan_msg → set_flood_scope(""), three calls that mutate global device state. Any other in-flight command from the coordinator (periodic telemetry, repeater status, contact-list refresh) or from another concurrent service call can interleave between set and send and either observe the scoped state or clobber it. The packet then goes out under the wrong region. #250 merged the user-facing feature without closing the race, since the fix is broader than that PR's scope. Proposed direction Wrap mesh_core.commands.X access at the api layer so every integration-issued command goes through _device_lock. Probably: ex