Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Enhance address change functionality #50

Open
NoahAndrews opened this issue May 16, 2023 · 5 comments
Open

Enhance address change functionality #50

NoahAndrews opened this issue May 16, 2023 · 5 comments
Assignees

Comments

@NoahAndrews
Copy link
Member

Changing the Expansion Hub address should optionally (defaulting to true) perform discovery to check that no other devices on the bus have the same address. Additionally, ParentExpansionHub should have a discoverChildren(openNewlyFoundChildren: boolean = true) method that allows the application to prevent the user from selecting an address that's already being used on the bus.

@LandryNorris
Copy link
Contributor

LandryNorris commented May 30, 2023

Right now, we always open RevHub objects when we create them, meaning the user never has to worry about whether a hub has been opened. We could instead create a getChildAddresses(): number[] that lists child addresses instead of creating RevHub objects that aren't opened, and a discoverChildren(): RevHub[] that unconditionally opens the children. This keeps the current behavior where we only return opened RevHubs.

@NoahAndrews
Copy link
Member Author

I agree with the approach, but I don't love the names. Maybe "findAddressesOfPotentialChildren" and "openAllChildren"? The first one is tricky, since we don't want to give the impression that we're just listing the addresses of the children that we're currently communicating with. The doc comment will need to spell out what's happening clearly.

@LandryNorris
Copy link
Contributor

LandryNorris commented May 30, 2023

findAddressesOfRs485ConnectedChildren? It's quite long, but indicates what the devices are. Maybe devices is a better name than children in this case?

@NoahAndrews
Copy link
Member Author

findAddressesOfUsbConnectedChildren? It's quite long, but indicates what the devices are. Maybe devices is a better name than children in this case?

It's RS-485 not USB, but otherwise I like it.

The other thing to consider is the Control Hub, where we'll need to support doing this for USB and RS-485 children.

@LandryNorris
Copy link
Contributor

LandryNorris commented Jun 7, 2023

How about findAddressesOfAllChildDevicesConnectedToThisExpansionOrControlHubWhichMayBeConnectedViaRs485OrUsb()?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants