ratgdo / homekit-ratgdo

A native HomeKit implementation of a Security+ 2.0 garage door controller based on ratgdo hardware
https://ratgdo.github.io/homekit-ratgdo/
GNU General Public License v3.0
215 stars 21 forks source link

Allow setting of WiFi SSID and Password from web page #224

Closed dkerr64 closed 3 weeks ago

dkerr64 commented 3 months ago

Opening this to track requested feature in #116 to allow changing WiFi SSID and password from web page (so that USB connection is not required).

At the moment this is NOT PLANNED.

Please discuss!

jgstroud commented 3 months ago

There are several libraries out there that help accomplish this. I did a proof of concept here and it worked just fine. If this were a commercial product and we were shipping it with firmware pre-installed, then this would be mandatory. However, given the nature of this project, I dont think this is required and can only add more places for things to go wrong. Unless someone gives me a really good reason, I would prefer not to implement this. We can keep the issue open for discussion though.

amoiseiev commented 1 month ago

For my education, what are the actual obstacles? What is the worse case scenario here? Wrong network configuration will force you to climb the ladder, which is exactly what you need to do to apply a new config in the current state.

I can attest that climbing on a ladder with a laptop just to change WiFi SSID/Password is not fun. I had to do it yesterday and it's not unusual to have such changes done during normal lifecycle of a product.

jgstroud commented 1 month ago

It's not just a matter of adding a page in the UI to specify a new SSID and password. Typically if a user needs to change the WiFi settings they are probably no longer able to connect to the old network. So this means switching to AP mode and providing an SSID for the user to connect to and setup the new WiFi. The basics are not hard and I've done a proof of concept. However there are a lot of details to cover, corner conditions error scenarios etc, and would require a lot of testing. also the codebase is somewhat fragile and I didn't want to add all of this logic to it. Given this is a hobbyist device and there is already a way to change wifi settings even through its not very convenient.

amoiseiev commented 1 month ago

The scenario you described is certainly only of the possible ones.

At the same time, there are devices that only implement a light version of it - a page where you can put new WiFi credentials to be applied, which is still helpful when you're migrating from an old SSID to a new one. You can either do it in advance of introducing a new router or you can create the old SSID temporarily to facilitate the migration. It's times faster, more convenient and doesn't introduce the complexity of an AP mode and other related moving pieces.

In any case, thank you for the context and your work on this software is highly appreciated.

jgstroud commented 1 month ago

Yes, I was only describing 1 scenario. Basically if we introduce the feature to do what you said, we will immediately get the requests for the rest of it to make it a more useful and complete solution. It can be done. But stability has always been the number 1 priority. We may eventually revisit this though.

dkerr64 commented 1 month ago

I've been thinking and researching this a bit more and come across some limitations.

Part of the function should be to scan the network for available WiFi SSIDs. This does not work if you are already connected to a WiFi access point. The scan requires that you first disconnect. This means that it is not really practical to allow user to request a scan from the web page.

You can do a scan during the boot process. In my case it takes about two seconds to complete. I looked at asynchronous scanning, but that doesn't work because of above limitation.

We could boot the device into Soft Access Point (SoftAP) mode. It creates its own network and SSID and then you connect a laptop or mobile device to that network and pull up a web page. However it is incredibly slow, and I mean really really slow. I was able to boot into this mode and it might be okay if we have the absolute minimum of a web page from which a user can set a SSID.

So, if we are to support this, then the design might look like...

We could allow a user to type in a SSID and password to the existing setting page... but we couldn't present a list of discovered SSIDs (unless we scan on every boot, and then the list would be old, whatever the available networks were at last reboot). If user enters invalid SSID/password then recovery process would boot into SoftAP mode.

amoiseiev commented 1 month ago

Thank you for the research.

I'm not advocating for a fully functional setup at this point, but for a simple one that would allow you to put the SSID and its password on a page.

If the SSID is unreachable or the provided credentials are wrong, it’s probably easier to revert to its previous configuration and restore connectivity this way. Fewer moving parts and probably better than falling back to a SoftAP mode due to a temporary glitch in connectivity. This will require articulating that the new SSID must already be available, but it will be the same with the scan functionality.

Side note - it’s interesting that ESP requires you to disconnect, maybe a hardware or framework limitation? In my understanding, typically a WiFi client can "pause," i.e., temporarily (for < 100ms) stop transmitting/receiving on the channel, and that’s how they perform scans without disconnecting.

dkerr64 commented 1 month ago

Included in release 1.8.0 (PR #242).

dkerr64 commented 3 weeks ago

Feature added to 1.8.0