AP timeout? about configmanager

[nrwiersma]

I would default a little higher to like 10 minutes, but it should be easy to change. Otherwise good plan.

[nrwiersma]

Nice, then i think will be a good way forward. I will tackle #14 first, then move onto this. For the moment I will exclude #11 POST changes, due to the typing issues, and that can be tackled in another release.

[nrwiersma]

So i managed to get it all done and gave it a good test. Hope this helps out. I have tagged the new version 1.0 and it should show up in around 24h.

If you find any bugs, please open new issues for them so I can sort them out.

[nrwiersma]

Hi,

Thanks for the suggestion. I would say this falls outside of the scope of this project, and perhaps not a good default behaviour. I think this might be something that should be handled in your project. My thought is to have a callback when the AP is started much like setAPICallback, perhaps onAPStarted. This should allow you to do what you need.

What you think?

[nrwiersma]

Forget what I just said, you are right. This is part of the logical flow.

It can be achieved one of 2 ways:

1. Reset the device (easy).
2. Try switch in Wifi mode (less easy).

The timeout should be configurable, perhaps in minutes, with 0 turning it off.

Thoughts?

[JonSilver]

Probably a reboot is quicker and more reliable than trying to switch back to station mode from AP mode, and easier to program.

Can we default the timeout to 120 seconds or something, whilst setting it to 0 turns the timeout functionality off?

[JonSilver]

Of course, if there's no wifi ssid or password, the AP timeout should probably be disabled so the device just waits patiently for initial configuration.

[nrwiersma]

Good point. Will keep that in mind.

Thanks

[JonSilver]

I've been thinking about the rationale behind AP operations. The AP is useful mostly for initial set up, and then whenever something changes. So in fact the AP is of use very little of the time. So it makes no sense if there is a valid config already saved to start the AP just because the device can't connect to the Wi-Fi. In my case, the device entered AP mode and never came out again whenever our electrician switched off the power and then switched it back on, because the Wi-Fi connection retries were all over way before the router managed to boot up again. Yet the device already had a valid config saved (I validate the config based upon successful connection and save the valid flag).

Can we therefore think of a way to modify the default behaviour of config manager if it is determined that the saved config file is valid?

[nrwiersma]

It is actually intentional to start the AP after a failed Wifi connect cycle. The concept was that should you change your Wifi SSID or password, which happens, the devices would go back into AP mode to reset the new SSID and Password.

[JonSilver]

Indeed, but since it already has a config that worked before, could we not automatically select a shorter timeout (when we implement AP mode timeouts) because it's already configured? The whole point of most applications for ESP devices is to have high availability, reliable devices which need a minimum of user intervention. Once configured they should just work. If one changes the SSID or access key for the wifi (not a common occurrence for most people or companies) then fine, it should probably wait for a short time per reconnect cycle. But to give the device any chance of becoming unavailable for a period of minutes just because of some transient wifi problem makes it less reliable. Yes it'll be better once it can't just get stuck in AP mode as at present, but AP mode remains a fail-safe way in rather than a mode an already configured device should be able to enter for any length of time just because it couldn't connect a few times.

[nrwiersma]

So it seems we are talking about 2 different use cases:

1. Technical people using devices and expecting high availability from their devices.
2. A more "consumer" facing approach.

In use case 1, you are 100% correct, we should never go back into AP mode, or just long enough for you to connect (which would stop the reset).

In use case 2, this seems undesirable and to a more layperson, this would probably be really frustrating.

I think both use cases have merit and am trying to find the happy path that satisfies both. My guess is this lies in config on the library and would likely default to library to the use case 2, but provide instructions for use case 1. The reasoning being that more technical people will likely do the extra config for HA. Does this sound reasonable What are your thoughts around this?

[JonSilver]

OK I think a lot of it is going to be down to how ConfigManager is used by the overlying firmware. As I say, in my case the firmware tracks its success at connecting, so I can easily increase the connect retry count and /or interval to allow an existing config more time to connect before starting the AP, and also give it a shorter AP timeout once it gets there.

1. Where there's no valid SSID and password, I don't want to bother trying to connect, I just want to start the AP and wait for connection.

2. Where there's already an SSID and password, but the rest of the config isn't valid, we may as well try to connect and run the portal through regular webserver if successful, or...

3. start the AP if not, with a longer timeout just in case it was a temporary wifi outage.

4. Where there's a fully valid config which has been successful in the past, the device should concentrate on trying to connect, with AP mode a true last resort after lots of retries over a long period just in case the router is starting up. The AP timeout should be short, but reset and lengthened upon connection.

I guess with the right facilities for timeouts and retry parameters, I can implement all these logic items in my firmware without them being a part of how ConfigManager conducts its own business. That's why I implemented the first two parameterised items (retries and retry interval) separately from library initialisation, allowing them to be changed during the run. I'd like to see the same arrangement for AP timeout.

The Wiki could become an interesting place... :)

[nrwiersma]

Hi,

Thanks for the input, it seems like a very good middle ground.

Here is the rub, I have no idea if what comes out of the EEPROM is "valid" or not, like no idea. But I have a thought on solving the first set of steps. It could mark the EEPROM to indicate that we have written to it before, that would give some information. I think the first 2 bytes can be set to "CM" then the wifi and config. This will tell us to go straight to AP mode if it doesn't exist or, if it does, try the wifi. Additionally adding a setAPTimeout function should give you 90% of the functionality you are looking for, and is fairly simple.

Additionally putting a callback on the start of the AP mode will cover the rest. My thought here is that with issue #14, if there are Get only and Set only config options, you could make a Get only value (version perhaps) that can be looked at in the callback (We have already read the config here). If it is not what you expected, you can restart the device, putting directly back into Wifi connect mode. The other option is to set the AP timeout based on what you find in the config.

One find step would be to track and expose the current state (AP or API), giving you access to it in your portion of the loop, so you can react to things yourself.

With these steps, I think we can cover your use case for HA, but requires a little bit more work on your side. What do you think?

[JonSilver]

I like the idea of a callback. I actually envisaged telling ConfigManager if the config file is valid through a callback, but it might be unnecessary if all that logic is instead handled within the overlying code. But I like your idea of marking the config in the EEPROM.

I also like your idea of ConfigManager telling its client code which mode it's in. It would allow everything to be much more reactive.

I have no objection to putting more code into the client firmware... I'm wholly in favour of putting each piece of functionality in its natural home. I think we're moving toward ConfigManager allowing more of that by being more open and configurable for its client code. It's important not to lock the library down to just one inflexible way of working, to allow for more complex logic and the wide range of possible scenarios CM might find itself in.

[JonSilver]

Incidentally, I originally used the WifiManager library, but found its reliance on AP mode stifling. CM opens the way for a status/log page and much more, as well as sitting in the background and not getting in the way. The amount of code I need to write to implement CM is minimal, so I found it more elegant and neater. And delving into the code, it's also better organised and more maintainable/comprehensible/developable.

[nrwiersma]

Thanks, appreciate you saying so. I did the same thing, which is why I ended up writing CM :)

[nrwiersma]

I started looking at the solution to this and found (it has been a while since I wrote this) that the AP mode is in its own tight loop and never reaches the main loop function. This is due to the mDNS captive portal. I think it is better to remove the tight loop and find another way around the mDNS.

So far I have made the change to the magic bytes in EEPROM, so I am slowly getting there.

[JonSilver]

Thanks Nick, I shall try to test it all out over the weekend. Sorry about dropping off the radar for a few days... project deadline overload!