fix: remove isBLEConnected guard from discover response handling

The !isBLEConnected() check was too restrictive — if BLE happened to be
connected (app in background) the standalone discover would silently drop
all responses. Tag matching already provides correct isolation: responses
matching _pending_node_discover_tag are handled by the standalone UI and
not forwarded to the BLE app; responses with a different tag fall through
to the normal forward path.

Also show short type names (Rpt/Snsr/Room) in the discover results list
instead of generic "known"/"NEW", with a '*' prefix for nodes not yet
in contacts — matching the repeater/sensor distinction the app shows.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
This commit is contained in:
Jakub
2026-05-21 08:37:17 +02:00
parent 64098bc4dc
commit 6249e63ec0
2 changed files with 12 additions and 7 deletions

View File

@@ -788,9 +788,9 @@ int MyMesh::getDiscoverResults(DiscoverResult dest[], int max_count) {
}
void MyMesh::onControlDataRecv(mesh::Packet *packet) {
// handle node discovery responses when in standalone UI mode (no companion app connected)
if (!_serial->isBLEConnected() &&
(packet->payload[0] & 0xF0) == CTL_TYPE_NODE_DISCOVER_RESP &&
// If we have an active standalone discover, check if this is a matching response.
// Tag matching provides isolation — no isBLEConnected check needed.
if ((packet->payload[0] & 0xF0) == CTL_TYPE_NODE_DISCOVER_RESP &&
packet->payload_len >= 6 + PUB_KEY_SIZE &&
_pending_node_discover_tag != 0 &&
!millisHasNowPassed(_pending_node_discover_until)) {
@@ -817,8 +817,8 @@ void MyMesh::onControlDataRecv(mesh::Packet *packet) {
r.timestamp = getRTCClock()->getCurrentTime();
}
if (_ui) _ui->notify(UIEventType::newContactMessage);
return; // our discover — don't forward to BLE app
}
return;
}
if (packet->payload_len + 4 > sizeof(out_frame)) {