search

peterhinch / micropython-mqtt

A 'resilient' asynchronous MQTT driver. Recovers from WiFi and broker outages.
MIT License
575 stars 126 forks source link

Ability to set multiple wifi ssids and passwords in the configuration #12

Closed goatchurchprime closed 2 years ago

goatchurchprime commented 5 years ago

If ssid is of type list, then it could scan the network for the strongest signal in this list before connecting to it.

This would mean I'd have portable devices that could be programmed to connect with lots of wifi networks in different locations. This feature would make life as convenient as having my laptop automatically connecting to a different network when I'm in my office than at home without having to manually select it.

(It needs to select for the strongest signal, rather than the first match it finds, otherwise it's very difficult to control. When I did this with two devices that both knew the wifis of two phones I had to carry one phone and device to the other end of a field so I could get the other two devices to pair up properly.)

peterhinch commented 5 years ago

This would obviously only work for unsecured networks.

That commented-out code was part of the work in progress to support the Pyboard D. There are still firmware issues around the initial connection of that board. Scanning blocks for long periods especially on ESPx (many seconds) so I'm not keen on it unless the firmware improves to provide a nonblocking interface.

goatchurchprime commented 5 years ago

Is there a way for the network.connect() to time out, so it could cycle through the different ssids that it knows until it finds one that works?

peterhinch commented 5 years ago

The wifi_connect method will terminate if it fails to connect to a network. So the code could be amended to attempt to connect to each of a set of unsecured networks. I do feel that this is rather a specialist requirement.

There is a point I must raise in connection with this and your mDNS suggestion. Making changes to the connection code involves very time consuming testing. The point of this library is to be resilient. Proving this on multiple platforms and over different network conditions involves a substantial commitment in time and effort, testing such things as behaviour under marginal signal level conditions.

For me to undertake any of this work I would need to be convinced that there was significant demand from users.

In the absence of such demand you could undertake these changes in your own fork. If you do this and can demonstrate resilience on Pyboard 1.x, ESP8266, ESP32 and Pyboard D I'll be happy to amend the docs to provide a pointer to your solution.