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

WiFi boards: some way to standardize the handing and recovery from errors #457

Open
deadprogram opened this issue Sep 10, 2022 · 3 comments
Labels
enhancement New feature or request

Comments

@deadprogram
Copy link
Member

This issue is intended to start a conversation about some ways to improve and process the different errors that can occur, and also do so in a consistent way for all of the various WiFi adaptors.

For example:

  • adaptor error with the hardware itself
  • wifi error such as losing connection with the access point
  • network error such as the remote machine dropping connection
  • protocol error such as mqtt errors (in theory handled already by mqtt package?)

maybe we want to define handler functions, so that applications can do whatever seems correct for that application. for example, wifi error handler could be called on losing connection with access point, and could try to reconnect.

If no handler is set up for disconnections, it may be a good idea to reconnect. Of course, the handler can be overridden.

At the very least make it pretty easy to hook up a handler to a typical behavior, even if not the default. If you have an adaptor error, maybe you want to write a handler to try to restart the adaptor by setting some pins to power cycle it.
We probably do not need to provide the typical behaviors, just the hooks then we can look at enhancing it based on what we need ourselves, and what other people ask for.

This is in part based on conversations already started with @sago35

Chime in humans of TinyGo!

@deadprogram deadprogram added the enhancement New feature or request label Sep 10, 2022
@deadprogram
Copy link
Member Author

Related attempts to address some of these things:

#311
#445

@aykevl
Copy link
Member

aykevl commented Sep 14, 2022

  • adaptor error with the hardware itself
  • wifi error such as losing connection with the access point

I agree, a hook that allows handling these in a graceful way would probably be the cleanest approach. Especially for wifi errors. For adapter errors, I'm not sure: it should in theory not happen but of course it happens in the real world. I guess the driver could deal with it by resetting the adapter and trying again (triggering a network error on all open connections because they all got reset with the adapter reset).

  • network error such as the remote machine dropping connection
  • protocol error such as mqtt errors (in theory handled already by mqtt package?)

I think these two should be propagated as usual. For example, if you do a send or receive but there is a network error, the operation should exit with an error.

@deadprogram
Copy link
Member Author

Thanks for the feedback @aykevl

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

No branches or pull requests

2 participants