Add a forget/reset wifi button

[mrpher]

What version of this package are you using?
Latest

What problem do you want to solve?
Users may want to switch WiFi networks after having established a successful connection. Currently, the UI disables switching wifi networks is a successful connection exists.

What do you think is the correct solution to this problem?
Two parts:

1. Create a forget/reset wifi button on the networking page, which forces the wifi to disconnect and forget it's current connection so that the user is placed back in the new connection flow where the wifi-connect option is triggered, the device enters AP mode and the user can begin as if the device never had a connection in the first place.

2. Modify the networking page to permit hot-swapping of Wifi SSIDs for users who do not want to go through the wifi-connect flow but rather just connect to a different wifi ssid.

Are you willing to submit a pull request to implement this change?

[mrpher]

Sorry, my mistake I don't know how I missed it, there already is a disconnect button. But it doesn't seem to be working properly.

[maggie44]

The button changes between connect and disconnect based on your connection status. Although I'm not sure if that will help with your particular issue, I think it will probably just try and disconnect from networks created by Python Wifi-Connect and not touch others, but worth a shot. And that doesn't explain why the disconnect button reports an error.

It seems like there is a typo, whoops: https://github.com/maggie0002/balena-device-ui/blob/ea258dd2df4679af35e305aa687f32776b945317/ui/src/components/wifi/Connect.vue#L236

Could you try changing the path to v1/forget instead and see if it works? And if not, see if there are any logs in the console.

[mrpher]

Yup, that did it. I changed the following from path: 'v1/connect',

.post('/v1/wifi', {
          type: 'POST',
          path: 'v1/forget',
          params: {
            all_networks: false
          }

And it worked. Got a friendly notification and device went offline a few seconds later. Balena Device UI SSID appeared, and after connecting to it captive portal appeared.

One issue, and it may just be me, the input fields did not appear 🤔

[maggie44]

What input fields?

Are you able to submit a pull request with that change?

[maggie44]

Yup, that did it. I changed the following from path: 'v1/connect',

.post('/v1/wifi', {
          type: 'POST',
          path: 'v1/forget',
          params: {
            all_networks: false
          }

And it worked. Got a friendly notification and device went offline a few seconds later. Balena Device UI SSID appeared, and after connecting to it captive portal appeared.

One issue, and it may just be me, the input fields did not appear 🤔

I added the new path name in to fix the issue in: #51

By input fields, do you mean for connecting to wifi? I guess this is what the captive portal had been used for before, but there are so many different use cases I didn't want to limit it to that. Instead, it is just a holding page right now, so looks like it is displaying as intended.

That said, we could improve it a bit. Did you manage to try out the MDNS feature? If it is working ok, then we could include some text on the captive portal that says something like 'Go to pathname.local in your browser to access the user interface'. I don't think rendering the whole page in the captive portal window would make sense, it would be more powerful to have the user go in to their ordinary browser.

We could go a step further and add in some q-tabs to the top of the captive portal (https://quasar.dev/vue-components/tabs#along-with-qtabspanel). We could have the default page as described above, and then could have a tab for Wi-Fi which lets you connect the device to a network? Or do you think that is micro managing design a little?

[mrpher]

@Maggie0002 Yes, sorry perhaps I was confused by the expected behavior. Assume your wifi-connect was a fork of balena's which has the wifi & password input inside the captive portal.

That being said, I was thinking about it and I think you're right - just have the captive portal contain a button to forward users right to the device UI and let them set wifi there. Keeps it nice and simple.

What I like about that approach is that it keeps the captive portal, which is very useful because it auto-appears. Which means you don't have to go looking for the device's IP when on it's wifi as a client to get to the wifi page on the device.

[mrpher]

That covers "new" device setups. When you haven't ever defined a wifi network.

However I still think allowing hot-swap of wifi networks after the fact. Maybe thats a separate gh issue?

[maggie44]

@Maggie0002 Yes, sorry perhaps I was confused by the expected behavior. Assume your wifi-connect was a fork of balena's which has the wifi & password input inside the captive portal.

That being said, I was thinking about it and I think you're right - just have the captive portal contain a button to forward users right to the device UI and let them set wifi there. Keeps it nice and simple.

What I like about that approach is that it keeps the captive portal, which is very useful because it auto-appears. Which means you don't have to go looking for the device's IP when on it's wifi as a client to get to the wifi page on the device.

I don't think there is a way to direct people straight to the browser. The captive portal pop-ups you see as far as I know do not have the ability to open new windows, they can only render new pages or redirect within themselves. I don't really have any easily accessible hardware with me at the moment to do much testing on for these sort of things. We could add in the text that says go to 'hostname.local' and add in the button that you click which then copies the url to the clipboard ready to paste it in to the browser.

There is a question then however, on how to check whether MDNS is setup, because it would be better to use that first, and hostname second. @nucleardreamer can you think of any way to check the MDNS status from the UI? My instincts tell me not to bother, just to have an environment variable option in the UI container people can choose what URL they want in the captive portal and when it is missing default to the hostname of the device?

Hot-swap is still a bit tricky. It would require refreshing the list of networks while already connected to a network, and a bunch of devices do not allow it. My instinct is still to avoid adding that feature as it could open a can of worms and issues for people we would then have to debug. Considering how rare it would be outside of testing for someone to need to do this, I would be surprised if it gets enough attention as a feature to justify the potential work load.

I moved this issue to the discussions section as the conversation is on a bit of everything now. So far we would need new issues for:

• Add a forget all network button (this is where the conversation started, and although you managed to clear your old network without this feature, it should still be added as it will help with network debugging). <-- done

• If you really think the hot swapping thing is important, by all means put it in an issue so we can track it and consider it at a later date.

• Add the current MDNS or hostname to the captive portal <— done with hostname

[mrpher]

I'm sorry I didnt reply on this sooner. I did test the latest changes to the captive portal. Looks great, I like the tabbed technique.

Regarding the hot swap, I hadn't considered that it might be part of a hardware limitation. It's something users might be accustomed to on their PC, but to your point a Pi in access point mode might not have sophisticated enough wifi hardware to permit the same behavior. Maybe a more knowledgable balena pro would know in the forums - I'll ask.

Anyway, hot swap aside, I love the solution you came up with so far.

One question, are you experiencing the same issue as me with the password failing? Use the forget button to disconnecting from a good connection, connect to Balena Device UI wifi, get the captive modal, visit http://devicename.local, go to networking, select a good wifi, enter password and receive the following error.

[maggie44]

I'm sorry I didnt reply on this sooner. I did test the latest changes to the captive portal. Looks great, I like the tabbed technique.

Regarding the hot swap, I hadn't considered that it might be part of a hardware limitation. It's something users might be accustomed to on their PC, but to your point a Pi in access point mode might not have sophisticated enough wifi hardware to permit the same behavior. Maybe a more knowledgable balena pro would know in the forums - I'll ask.

Anyway, hot swap aside, I love the solution you came up with so far.

One question, are you experiencing the same issue as me with the password failing? Use the forget button to disconnecting from a good connection, connect to Balena Device UI wifi, get the captive modal, visit http://devicename.local, go to networking, select a good wifi, enter password and receive the following error.

Could you try this branch: #64

[maggie44]

Really appreciate all this testing you are doing. Keep it up 😊