@nexxy & @bko
I'm confused by what I'm experiencing...
If if install the lastest Photon firmware from your Github
$ git clone https://github.com/spark/firmware.git
$ git checkout photon_043
then flash with:
$ sudo make PLATFORM=photon clean all program-dfu
The upload runs successfully, and the device goes into listening mode. I can then connect to the access point it creates (Photon-XXXX) and use most of the softAP functionality. e.g. visiting 192.168.0.1/hello returns "SoftAP Setup", /scan-ap sends me a json encoded list of neighboring APs...
However the configure-ap does not behave as expected/documented. For example running the below Python script:
import requests
import json
url = "http://192.168.0.1/configure-ap"
payload = {
"idx":0,
"ssid":"collective",
"sec":4194308,
"pwd":"53ccb6d1f946084a96221923b094a7fcf87834441e5ecae76ef7b9f54339ee1500d25cac3d3bd1baa7d211cc24f2b68a118d8cc7903dde1a5c1a5d27e316667ce40793284201881c92dfa9c1dd4b7ece54dda45da6e6ed86f248b284534dae13c14a456ac638cbfabc8ee9c17caf9dfd63a993f30987dfe05756889d5ac452c1",
"ch":6
}
r = requests.post(url, data = json.dumps(payload))
print r.content
where pwd was encrypted using rsa and the device public key
This prints {"r":0}, then sometimes the device stays in listening mode as expected, but sometimes it blinks red a whole lot and resets (nonetheless having returned "r":0). During this reset the device connects to the WiFi with the credentials from the post.
If the device hasn't reset already, I can then trigger that same flashing red & reset behavior by posting {"idx":0} to "/connect-ap", or simply issuing a GET to "/connect" (which is strange because I didn't see that endpoint handled in the softap_ip.c routes).
Also, it seems like the Content-Length header cannot be omitted in the posts.
Anyway, my question is basically can you point me in a direction that will lead me too more consistent HTTP behavior. I'm hoping to release an MVP in Beta in 3 weeks, and was really hoping to have HTTP connect smoothed out by then.