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

Don't fail completely if we can't read a single register #680

Open
canton7 opened this issue Sep 28, 2024 · 2 comments
Open

Don't fail completely if we can't read a single register #680

canton7 opened this issue Sep 28, 2024 · 2 comments

Comments

@canton7
Copy link
Collaborator

canton7 commented Sep 28, 2024

This might be a bit tricky to implement... But:

  1. If we fail to read a batch containing a register, mark them all as "maybe bad"
  2. If we fail to read a single register marked "maybe bad", mark it as "bad", and always read individually
  3. If we succeed in reading a register marked "maybe bad", mark it as "good" (and include in future batches)
@canton7
Copy link
Collaborator Author

canton7 commented Feb 2, 2025

I started this a while back: https://github.com/canton7/foxess_modbus/tree/feature/continue-on-register-fail. Should probably get this over the line...

@canton7
Copy link
Collaborator Author

canton7 commented Feb 3, 2025

I was thinking about that this morning, and I think the approach I was taking won't work, as it only tracks whether a register we're intending to poll is actually unavailable, and not whether a register we're spanning as part of a larger read isn't available (which does happen).

I think we need to keep a separate list ranges of unavailable registers (as a list of tuples of (start, end)). If we do a read which fails due to "Invalid Address", we break that range down into a lot of single register reads, and construct our ranges of unavailable registers from the results. That's then fed into the range construction, in a similar way to how invalid_register_ranges is handled now, except that we don't assert if a know register falls into such a range.

We should then use issue_registry.async_create_issue to create something to display to the user, instructing them to read a particular wiki page. This will have instructions on making sure the correct firmware version is selected, and to open an issue with details if it is.

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

1 participant