Repository navigation
fix(mqtt): map same-model vacuums via learned DID/DUID pairs - #165
Merged
Lash-L merged 1 commit intoOct 12, 2026
Merged
Conversation
The topic bridge built its DUID->DID map only from an explicit `did` in the cloud inventory (normally absent) or a unique-model fallback. With two or more vacuums of the same model, neither applied, so every request was dropped with "no deterministic rr/d mapping". Seed the map from the DID/DUID pairs the server already learns during onboarding (runtime_credentials.json). Also drop the early return on an empty inventory so learned pairs still apply. Fixes Python-roborock#163 Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Contributor
|
Thank you! Have some tweaks, but i'm going to merge in and then modify. |
Lash-L
added a commit
that referenced
this pull request
Oct 12, 2026
* fix(mqtt): don't guess a DID that onboarding already paired Follow-up to #165. The unique-model fallback could still map an unpaired DUID to a DID that runtime_credentials.json pairs with a different DUID (e.g. a replaced vacuum), so two DUIDs routed to one vacuum. Collect the learned pairs before the inventory loop and skip the fallback for DIDs they already claim. Also tolerate runtime_credentials.devices() raising, matching key_models_by_did(), and drop the --bridge-device-* hint from the drop warnings; that option no longer exists. * fix(mqtt): harden runtime credentials devices iteration and add tests
arjansingh
added a commit
to arjansingh/local_roborock_server
that referenced
this pull request
Oct 18, 2026
The rule said upstream uses sentence-case subjects with no type prefix. Upstream changed in 2026-09: in October 2026, 10 of 14 subjects were type(scope): summary, e.g. fix(mqtt): ... (Python-roborock#165). Following the old rule would make every contribution look out of date. Describe the current form, the types and scopes upstream uses, and tell the reader to re-check git log upstream/main before relying on it. Co-Authored-By: Claude <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #163
Problem
When two or more vacuums of the same model are onboarded, the MQTT topic bridge cannot map any of them.
_refresh_duid_to_did_maponly uses:didin the cloud inventory. Cloud imports normally do not include it.With same-model vacuums, neither applies. The bridge then drops traffic in both directions:
The server already knows the correct pairs. It stores them in
runtime_credentials.jsonduring onboarding (learned onboarding MQTT credentials did=... duid=...).Fix
runtime_state.runtime_credentials.devices(). These learned pairs override the inventory heuristics.Testing
tests/test_topic_bridge.py: threeroborock.vacuum.a10devices with nodidin the inventory. Each DUID must resolve to its own device topic. The test fails before the fix and passes after it.roborock.vacuum.a10). After the patch, the map contains all three pairs,m->d/d->mtraffic flows for each vacuum, and Home Assistant detects all three, including maps.🤖 Generated with Claude Code