-
Notifications
You must be signed in to change notification settings - Fork 19
Multiple wifi #63
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
Comments
The libraries and all or most widely published user code currently are hard coded to expect a single entry in secrets with the network details. I am not aware of anything currently that would use any entries beyond the first. The libraries could eventually be updated to attempt to use the next one in a list if the first one is not available and so on, but that change will need to be carried out in a few libraries before it's widely usable in an easy manner. I know some other folks have requested similar functionality but no one has had it prioritized strongly enough to do yet. We are definitely willing to review PRs for that if you are interested in working on it though. That being said there are a few ways that you could try to minimize the effort involved in switching back and forth with the libraries as they exist today:
Then you could change just the boolean whenever you need to switch networks. |
It does also look like the base library |
@tekktrik my understanding is that the classes in this library are extending the ones from the PortalBase library, so I think you can use that argument without needing to specifically add it into this library. Though adding it here explicitly would allow it to appear in the documentation I think. |
@FoamyGuy is correct. PortalBase is the Base Class for all Portal style libraries. |
I don't think any of that information actually gets passed to the base classes though. Here's my train of thought: It looks like the only things getting passed to network = Network(
status_neopixel=status_neopixel,
extract_values=False,
debug=debug,
)
super().__init__(
WiFi(status_led=status_led),
extract_values=extract_values,
debug=debug,
) As is, |
I took a closer look at this. I had implemented this previously in the ESP32SPI library: https://github.com/adafruit/Adafruit_CircuitPython_ESP32SPI/blob/main/adafruit_esp32spi/adafruit_esp32spi_wifimanager.py#L133-L154 which just calls _get_next_ap to get the next access point. However, the MagTag uses the built in ESP32-S2 WiFi stack, so it completely bypasses this. The best place to add this functionality would be in PortalBase in https://github.com/adafruit/Adafruit_CircuitPython_PortalBase/blob/main/adafruit_portalbase/wifi_esp32s2.py. This would also give the functionality to the FunHouse and ESP32S2TFT libraries which use this file as well. I would recommend a similar approach where username and password can be tuples or lists and then it iterates among those on each connection attempt and then loops back when it hits the end. If just a string are given for the username and password, it should just keep trying to use those. Since this is more of a PortalBase feature, I'm going to move this issue there. |
I think it only makes one attempt and if it doesn't see the WiFi SSID (perhaps it's down at that moment), it fails. So another thing would be to have it try multiple attempts on failure which is how the ESP32SPI lib works. |
It looks like it tries a few times on the provided ssid and password, unless I'm misunderstanding: Adafruit_CircuitPython_PortalBase/adafruit_portalbase/network.py Lines 330 to 357 in a9bc7d7
|
Yeah, it looks like a ConnectionError is now returned, so #64 fixes that. |
thanks you everyone who's looking at this the idea is so i don't have to reprogram the tag so it looks like a change to allow a retry with next SSID on this part would be what would be an ideal implementation
|
The secrets.py looks suspiciously like a wpa_supplicant.conf file but we can only put one wifi in there is there a way to put multiple as I would love my tag to work at home and office
The text was updated successfully, but these errors were encountered: