Right now, my WiFi Time Provider is running as both STA (I can access it's web server via my network) and AP (it's broadcasting the SSID NixieTimeModule).
According to the documentation, this should not happen: "The module tries to connect to the configured Wireless LAN on start up. If it manages to connect, it will shut down the 'NixieTimeModule' open access point." When powered up, the blue LED shows that it connect to my network quickly, as it starts blinking about once per second.
Version is v352.
I see that v355 is on bitbucket (I received the v352 module only a week ago). When I look at commit cfe140d, which bumped the version from 352 to 355, the only change seems to be that the some defines were broken out into a different file. But, I also see a later commit, 521d716, which add functionality but doesn't bump the version (???). But, neither seem to have any changes in WiFi handling.
I eventually tracked it down. If you do a reset (i.e. http://[moduleip]/reset), the 8266 will apparently still remember the WiFi settings, even though they're wiped from the eeprom area the module code uses. The code doesn't see
(esid.length() > 0)
so it just goes straight to
...and it will come up both connected to the network, and as an AP.
The solution seems to be, in the resetEEPROM() function, add
...which should wipe the WiFi info saved by the ESP itself.
But then, there's another issue. When you set the SSID/password to connect to, it does, but it stays in STA_AP mode, so it's still providing an open network. A power cycle will fix that, but the better solution is, in wlanPageHandler(), just before it does storeCredentialsInEEPROM, add
Finally, let me suggest that the WiFi module be able to pull and display the version number for the clock it's attached to.
The tagging reflects released versions, and there is the wish to keep the version number of the WiFi aligned with the version number of the clock code. Often there are things in the clock code which cause a bump of the WiFi number and vice-versa.
There are also several different sets of firmware, and the version number tries to reflect the "feature compatibility" between repositories. Clearly, it's not possible to make a single version of the code, and often the version number reflects that a broad feature set is expected. So, for example, something fixed in the PIR code can mean that the version of the V2 code needs to go up, and the V1 code is aligned with that to keep things simple, even though V1 doesn't have any PIR code. (Yet - the 4 digit V1 code will change that).
That's a good suggestion about the version number of the clock code. I'll do that.
Please also note that newer versions have moved over to the standard "WifiManager" code base. This should take out many of the weirdnesses that you are seeing. The code was first done back in the old days when there was little support or documentation. All my recent development is done on the WiFiManager, and I'm largely happy with it. I'll be bumping the version to make it "official" quite soon.
The version numbering thing is usually handled by having different fields for numbering, e.g. 3.5.5 would be major/minor/patch release numbers. So, you would have it so perhaps only the 3.5 has to match, and then use the last number for fixes which don't change compatibility. So, if there were no fixes needed for one release, you might go from 3.5.5 to 3.6.0 when adding features.
But, making any changes without changing the version defeats the whole purpose of version numbering - to know exactly what code you're talking about.