Skip to content

Allow use on network interfaces other than WIFI. #167

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

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

andrewleech
Copy link

If network.WLAN doesn't exist autodetect other network adaptor and use that instead.

Assumes that interface is configured by the user.

I've been using this with a USB Network connection from micropython/micropython#16459 on a rpi pico (non wifi version).

If network.WLAN doesn't exist autodetect other network adaptor and use that instead.
Assumes that interface is configured by the user.
@peterhinch
Copy link
Owner

peterhinch commented Mar 5, 2025

This has been discussed before. I have mixed feelings. A great deal of the code is predicated on the assumption of an unreliable transport medium; mqtt_as therefore seems like overkill for a wired connection. This doc summarises my views.

Further comment is welcome. @bobveringa ?

@bobveringa
Copy link
Contributor

It would heavily depend on the implementation. The implementation as described above I think would add a lot of complexity and benifit very few people.

This has been proposed before (and is currently still open) in #57.

On the one hand, this does allow for more flexibility in using the driver. On the other it adds more complexity and code. One advantage I could think is that integration testing and other kinds of testing can be easier to implement, and it might be easier to get the library to work on more ports. But I have done no validation or testing to validate if it is actually easier.

When I have time to work on investigating testing I can take this issue into account, but this might take a while.

@andrewleech
Copy link
Author

Thanks for the feedback. I did see #57 (after I'd started making the changes here) and still thought this might be worth sharing as it's a much smaller change, mostly contained to a couple of sections of the code.

@peterhinch while I do agree with your thoughts in FUTURE_DEVELOPMENT when I went looking for an asyncio mqtt library to use to test and demo my USB NET pr this was the only one I found for micropython. I figured a fairly minimal amount of changes to it would make it work on pretty much any micropython network interface, without adding any more dependencies to get it working.

I did briefly try https://github.com/zcattacz/mqtt_as that was linked in one of the issues here but wasn't able to make it connect to my broker, I'm not sure why.

Longer term, there's a couple of pure-python mqtt libraries that might port from cpython pretty easily I might try next instead:

  • mqttools - mqtt 5.0 client & broker, only qos 0.
  • gmqtt - mqtt 5.0 client, minimal dependencies.
  • amqtt - client & broker, larger library, few more dependencies that would need to be worked around

I'd actually really like to try running the broker on micropython as well for use cases over USB where I'd like a desktop client app to be able to talk directly to the micropython board, rather than needing an additional server installed and configured, so mqttools could be a good fit.

@peterhinch
Copy link
Owner

I think a stripped-down version for wired interfaces along the lines of https://github.com/zcattacz/mqtt_as may be the best way forward. I'm wary of adding complexity to the core mqtt_as which aims to support MQTT3.1.1 on ESP8266.

A version supporting a variety of network interfaces also presents a workload in testing, documentation and support.

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

Successfully merging this pull request may close these issues.

4 participants