I have an existing design, that I have working in every sense of the word. Board created, firmware working, web services working. I have cloned the javascript to use the softAP to connect to the wifi networks. It seems to be reliably working on the 10+ devices that I am running here with 0.6.3 firmware.
However. I would like to run my display when not connected to wifi, to give debugging info. So I enabled SYSTEM_THREAD from reading things here. And I thought that everything was working great, the display works great, and warns of no wifi connection, etc. But when I reset the device to send it to a beta tester, I noticed that the SoftAP configuration wasn’t working as well. Right now, it seems that I have 15 seconds (maybe while my firmware is getting started?), that the SoftAP works as before… but after that time, the SoftAP fails to respond to requests. The AP stays connected, but just quits talking to me.
@Tearinitup537, with SYSTEM_THREAD enabled the SoftAP and the user code will run at the same time. As such, your code needs to not interfere with the SoftAP by NOT running any WiFi or Cloud operations until SoftAP completes. That means looking at WiFi.listening() and WiFi.ready() prior to WiFi/Cloud operations and possibly WiFi.hasCredentials() to determine if credentials are available.
Thank You. I ran through all that code and put some Wifi.listening and ready checks here and there to make sure I wasn’t instigating any operations, though I don’t know how events and vars and messages registrations would really affect that behind the scenes. I do have them working at least as well as a blank setup and loop firmware.
I do see that the SoftAP solution in the docs “complete solution”, that serves its own pages, isn’t really stable long term for me on any of my devices, regardless of if the photon is on a carrier board or usb power. I have them on a high power bench supply, at some point the softap seems to quit responding. I haven’t nailed down a reproduction yet… has anyone really tested the softap onboard pages, with a known good power supply and just let it run, like for a day? From what I can see its no where near that stable.
@Tearinitup537, I have used SoftAP on a product that shipped with no credentials. I can’t say I let it run all day since that is not really how it should be used. Perhaps you should think of using a timeout on listening mode. If no credentials are entered within the time, you kick out of SoftAP and retry when you reboot for example. Or have a user button to kick it off.
I currently have them shipping that way, and have some in the field with a timeout set. Of course users are users… they get sidetracked, and don’t read stuff, and even if they read stuff they don’t do it. I think that the use case is stable enough to get a minute or two out of it in most cases, and that is likely good enough for now. How many caveats can you put on the product setup before it just looks shoddy though… don’t leave it running, don’t plug it into a usb port, don’t plug it into a cheap charger, don’t use it in noisy RF environments.
With a listen mode timeout, you can put the device into deep sleep. Tell the user that happens for security reasons (after all, it is an unsecured AP) and that they simply then need to unplug and replug the power to the unit to restart the setup process.
This is not a problem relating to the Photon but to the USB port itself. A USB power supply provides a known-good source of power.
Why would you power ANY quality electronics from a cheap USB charger. This applies to any and all devices. Cheap chargers are noisy, don’t provide their advertised current and are trouble waiting to happen. Recommend some chargers to your clients or provide one as part of your product.
This is kind of a general rule for a crowded spectrum like WiFi! Again, this is not necessarily a problem with the Photon.
