Say that Home Assistant can hand out a shared unit - #216
Merged
Conversation
The page carried a caution that shared connections were coming and this was not how to do it yet. They have landed: the modbus integration hands out units over connections it shares, so two integrations on one device serialize behind a single connection rather than competing for the bus. The caution becomes the instruction, with the call and a pointer to the official guide. What it said about migrating holds, and is why this is a small change: only the one place that turned config-flow values into a connection moves, and the library, coordinator and entities do not.
Asking Home Assistant for a unit was a tip beside a page that still taught building your own connection. That is how it works now, so it is the instruction: "Setting up the entry" asks the modbus integration for the unit, and building the connection yourself moves under it, for a standalone script or a Home Assistant too old to hand one out. Two things follow from not owning the connection, and both were wrong on the page. There is no teardown to register, and calling close() on a shared connection takes the link from whoever else holds a unit on it. And the wedged-link recipe cannot apply: a unit carries no connection to recycle, and dropping a shared link would hit integrations that never asked for it. Message spacing moves to the unit for the same reason. Pacing one slow device should not pace everything else on the link.
A consumer gets a unit, so close() and disconnect() were never reachable from where the page warned about them. Building the connection yourself belongs to the pages that cover it, not to the Home Assistant one.
The checklist item on the config flow and the one on async_setup_entry both moved on each side. Keeps #217's addition to the first, that the flow asks nothing the library settles by probing, and this branch's replacement of the second, which asks modbus for the unit.
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
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.
The integration page carried a caution that shared connections were coming and this was not how to do it yet. They have landed in home-assistant/core#179658: the
modbusintegration hands out units over connections it shares, so two integrations on one device serialize behind a single connection rather than competing for the bus.The caution becomes the instruction, with the call and a pointer to the official guide (documented in home-assistant/developers.home-assistant#3308).
What the caution said about migrating turned out to hold, which is why this is a small change: only the one place that turned config-flow values into a connection moves, and the library, coordinator and entities do not. The example below the callout still builds its own connection, which is what a standalone script does and what an integration does until the shared version reaches it.
npm run buildpasses, internal links valid.