Device-os: AP mode on Photon

[m-mcgowan]

The photon can function as an access point (AP), which the system presently uses to perform wireless setup. This feature is useful for creating a local wifi-network where devices can interact with the photon without it being connected to a router.

A new API could be used to setup a AP:

WiFi.accessPoint(APConfig* config);

struct APConfig {
    SecurityType,
    Password,
    SSID  /* optional - uses device's SSID if not specified */
    IPAddress  /* IP Address */
    DHCP settings  etc..
};

Security type is the same as for WiFi.setCredentials() - UNSEC, WEP, WPA, WPA2.

Additional parameters such as the IP address, DHCP settings will be specified as an additional structure.

The functionality augments the current WiFi modes:

• calling WiFi.accessPoint() disconnects the device from the router if connected (implicitly calls WiFi.disconnect()) before establishing the AP
• a new LED color could be used to indicate the AP is functioning, e.g. breathing orange?
• calling WiFi.disconnect(), WiFi.off() WiFi.connect() or WiFi.listen() tears down the AP.

Once the access point is established, user code can use TCP server/client sockets or UDP sockets to communicate with local devices.

(Update: The photon does support simultaneous AP/STA modes, so this design will need reworking.)

[zsup]

Love it. Some thoughts:

• How might we expose things like Spark.function() and Spark.variable() in this mode? Can we abstract that so that people can use the same mechanisms for local communication from a connected device?
• What other tools can we give people to quickly do awesome things when the device is in AP mode?

[m-mcgowan]

Totally, was thinking the same! We could make available a TCP server that connected devices can communicate with using a simple protocol.

But then again, rather than invent a new protocol, we could expose a cut-down version of the existing cloud REST API.

The next level above variables and functions would be pub/sub - that's trickier, but not impossible.

[zsup]

I think it'd be interesting to use the same CoAP API that we use with the cloud and implement a CoAP library on the iOS/Android/Javascript side for interacting with it directly from the mobile SDK

[m-mcgowan]

Yes! That would keep the code required on the device to a minimum. I was thinking that CoAP isn't as accessible compared to http but if we provide client libraries, then that makes it accessible. I think the comms lib has the CoAP protocol and encryption concerns separated so should be fairly easy to host a TCP server talking unencrypted CoAP.

[zsup]

Also we could repurpose our own spark-protocol library to provide a javascript implementation, which we could probably use in the iOS and Android apps too

[piettetech]

1. there are several CoAP libraries available so you may not have to provide one.
   
   
   
   • Java CoAP, Californium
   
   
   • C CoAP, Erbium
   
   
   • libCoAp
   
   
   • jCoAp
   
   
   • OpenCoAP
     
     A quick search lists some also for Andriod
   
   
2. Some WNICs can operate as an Access Point while at the same time be connected to one. I don't know if the Broadcom chip used in the Photon can. But it would be very powerful feature to be able to act as either a repeater, or possibly as a private AP bridge router.

[m-mcgowan]

Looking through the comms library, the CoAP handling and encryption are quite tightly interwoven in places - if we want CoAP comms to be unencrypted, this will need reworking to some degree. (A question of how fundamental encryption is to the existing protocol and if it makes sense to remove it.)

@piettetech from browsing the broadcom community site, it seems the broadcom modules can function both as Station and AP mode together. I agree this would be super powerful, and we'll be sure to investigate this fully when implementing AP mode. (http://community.broadcom.com/community/wiced-wifi/wiced-wifi-forums/blog/2014/06/04/using-softap-and-clientsta-simulataneously) As the modules have one connected antenna, the STA and AP should be on the same channel.

[tomw]

Being able to open up a TCP connection directly to the Photon sounds great! Has there been any progress on this?

[pingdynasty]

+1 for implementing WiFi.accessPoint(APConfig* config) exactly as described by @m-mcgowan, it will make the device infinitely more flexible.
Services to run in AP mode can always be added later.

[tomasinouk]

+1
with services to be added later as those just sound to be too nice in the beginning.
I would like to have the option to access Photon via web interface or mobileAPP to get data locally and possibly configure wifi STA mode in case the wifi gateway would become available temporary (solar application e.g.. where router wakes up several times a day)

so it can switch between STA and AP dynamically.
Both modes AP, STA at the same time even better.

[wizwally]

+1
There is an AP mode implementation update?
I'm thinking about those implementations where the need is operating with the photon without having an Internet connection.

[xa4]

+1 for AP mode implementation

[crearc]

+1 this feature is essential for the device I'm building, and can't use the Photon without it. :(

[denizonural]

This is great! Has it been implemented on the photon?

I've got a new photon and searching all over to find how to use this. Any tips? Is it possible to use this feature and how?

The only documentations I've found for WiFi is this and it does not contain info about AP:https://docs.particle.io/reference/firmware/photon/#wifi

[sravanjosh]

Waiting to see this feature out !!!

Plz let us know whether this is already available in the current firmware, if not when is the plan for this release.

[singlerider]

+1 I need this for my project, or any way to RECEIVE a request (GET/POST) on the Photon, itself.

[m-mcgowan]

Yes, you create a TCPServer and parse the HTTP request. Being able to receive a connection is not related to supporting AP mode. .

[SoundsSerious]

+1 For on this! Adding mobile friendly features will take this IoT product to the next level IMO. Particle seems like a one stop shop for wireless communication and would buffer its standing if it could offer Bluetooth / WiFi Direct / and AP support. I love what you've done so far keep kicking ass!

[jdsarode]

Hi,

I did not find any Wifi.accesspoint() method if firmware of Particle photon.
Can anybody guide me how to set particle photon in AP mode

[m-mcgowan]

AP mode is still on our todo list - it's not done yet. This issue here is for planning the feature and tracking development.

[kasperkamperman]

What is the difference between this AP mode and the SoftAP that seems already supported?

The start message says:
_The photon can function as an access point (AP), which the system presently uses to perform wireless setup._

Isn't this already supported with the SoftAP (https://docs.particle.io/reference/firmware/photon/#softap-http-pages?

What possibilities will become available with this AP implementation?

[m-mcgowan]

SoftAP is a specific application of AP mode on the Photon. The application is to provide the protocol used to setup a photon via Wi-Fi. The general AP support exposes a separate networking interface that the application will be able to use to create it's own sockets, such as TCP servers, and so opens more possibilities than are currently available with the HTTP support via SoftAP.

[kasperkamperman]

Clear. So if I want to have my own app that communicates over TCP directly. I can do that with the implementation scheduled for release 0.7.0?

[alexgrauer]

Hi,

It would be great to have this feature working. Any estimated date for it to be released?
Thanksss!!!

[SoundsSerious]

I'd really like to have this feature. Connecting devices out in the wild away from a router is KEY for many products. Wouldn't it make sense to prioritize this features as would really enrich the particle ecosystem, and thus bring in new customers?

Many of the milestones for 6 / 7 have been low level technical issues that won't drive your sales. I'd really like to see this implemented. Not sure my business can tolerate seeing this issue keep slipping.

[kasperkamperman]

@keavin7 I think you are wrong. The key business model of Particle is connecting hardware to their cloud (which won't happen in AP mode). I expect that they don't make a lot of profit on their hardware. So I understand their way of prioritising.

[SoundsSerious]

@kasperkamperman you raise a very good point, something I didn't think about. In my head I was thinking of particle as 'the connection company'. WiFi + Cellular + Bluetooth -> Your Devices

[alexgrauer]

Hi @m-mcgowan, any news about this? Estimated date for this feature to be released?
Thankss

[rautmithil]

Hey @m-mcgowan , any update on this?

[SoundsSerious]

I've been waiting on this feature for years now. My suggestion is to switch over to the ESP32 / ESP8266 which both have well supported access point functionality if you need that for your device.

[VALERE91]

Same as @keavin7 here, I finally decided to switch all my projects to ESP32 and its little brother ESP8266

[beriberikix]

Hi @kasperkamperman @keavin7 @rautmithil @VALERE91 and the rest requesting AP mode - can you provide specifics on the use case you're targeting? I've read through the comments and but like to go back to the team with an update, clear understanding of what the community is looking to have built. Thanks!

[kasperkamperman]

I understand that pure AP mode is not so interesting for Particle, because your main product is the Cloud. Right now there is the SoftAP on which I can deliver a webpage so the user can setup their WiFi network. However I need to separately implement a webserver if I need to deliver a webpage or make some rest service available when I'm connected to the cloud.

The need for a webpage, is that the cloud in my use case has a too big delay. I want users to control a light product, directly.

Here a demo of local control vs cloud control:
https://www.kasperkamperman.com/blog/particle-photon-rgb-remote-local/
https://www.kasperkamperman.com/blog/particle-photon-rgb-remote-cloud/

I prefer that users can also control their light, without connecting to the cloud. In that case a good AP mode might serve.

[SoundsSerious]

@beriberikix SoftAP / Wifi Direct are both ways to operate away from a Fixed network, for instance with your phone on the road. This is a very common use case, and an entire market particle is missing out on. The internet of things is more than a bunch of products in your home.

For the most part, implementing this would roughly double the number of use cases for the photon and would lead to more sales... probably more than bug fixes or implementing new fancy IDE features......................

If you want extra points figure out a way the photon can use the phones internet connection to talk with the cloud through ios/android.

[jgc]

Key use case is so that a client can enter WiFi connection details via a web page on the device connected to via the AP without them taking 'ownership' of the device and specifically without needing to configure the device before sending it out.

[pingdynasty]

The important thing is to let the user/developer control what services run on the device, regardless of cloud connection, and regardless of what exact services are needed. Simply adding a _SoftAP configurable web page_ feature will only add to the clutter without solving any real problems.

I've previously commented here and on the forum about our approach which has been to hack the Photon firmware to pieces, re-implement the parts we need, and manually configure UDP, TCP, DNS, HTTP and other services, in both Soft AP and connected mode. It was a hard and painful process and largely felt like a waste of time, since we were working against the design decisions taken by the Photon team. In hindsight we would have been better off basing our work directly on Wiced.

Many, many products will need the ability to switch between Soft AP, cloud connection, and connecting to a local network without internet access.

I'm sure it's nice to demo a fully automated, cloud enabled platform but when that approach doesn't fit the use case then there should be tools available to the developers to build the right solution. The hardware has the capabilities for this, and the underlying libraries do too, so it's a real shame they are missing at the photon firmware layer.

[rautmithil]

In my use case, I have data from sensors coming to a local cloud for processing. The entire process needs to be local and I have to deploy them at places where people can configure it for setting up the wifi. I was looking to implement wifi provisioning without having to talk to the mother all the time. Also I agree with @jgc point of not giving ownership to the users.

[beriberikix]

Thank you all for your feedback, I believe I fully understand the feature request. I'm new to the Particle team and I am the Product Manager for our firmware. I've already started a discussion internally around this request and will update this issue when we have more to share.

Now, I hope I can provide a bit of background about how we got here. In the early days of Particle's history, we had a very small firmware team and we had to prioritize features that our community wanted the most - mainly, connecting to our cloud. With the Photon, we were pushing pretty hard on the relatively new wiced IP stack, which resulted in our small team reporting & squashing bugs just as much as we were developing features to connect to our cloud. Also, we generally take every decision about growing our system image size very carefully - the more we use, the less you can. Adding a webserver and the needed code to configure via a web page was deemed a "nice to have" while were still stabilizing the embedded platform.

Times have changed: wiced has stabilized and our team has grown (slightly!) We have always listened to the community and hear you about the need for AP support. We'll carefully look at the pros and cons of the feature, the scope and see if we can include it.

Lastly, I want to call out our on-going commitment to openness. The firmware is available here on github and we continue to develop it in the open. We've never been known to intentionally block our community or lock them in. Particle as a company would not be what it is today without our vibrant community and we value your investments and contributions. It also sounds like other folks have worked on this topic but we've never seen a pull request and we'd be delighted to accept one if someone has done work to flesh this out.

I hope that background helps - stay tuned for updates on the issue.

[shadowjig]

Any update on this feature? Looking to use this in a current project.

[elec3647]

I could REALLY use this feature. I'm essentially trying to write something like this now.

[wasimlodhi]

Any update about 0.8.0 ?

[wasimlodhi]

In milestoned 0.8.0 it will be possible to use tcp/udp in AP Mode?

[seanmcleod]

@beriberikix you mentioned updating this issue when Particle had more to share regarding this feature. That was in Sep 2017 but I don't see any updates here.

[wasimlodhi]

Any update about 0.8.0 ?

[wasimlodhi]

Any update about 0.8.0 ? March-2019 ?

[wasimlodhi]

@technobly when it will be included in release? and when it will be release? We are waiting it from very long time. Please update us.

[mickeyl]

Another year and a half have passed – since we're now on firmware 3.0, is there any update on this topic?

[wasimlodhi]

we are waiting ..... but no reply yet

[SoundsSerious]

To everyone waiting for this feature, would suggest the ESP32. Took a while to rebuild my system around it but its very slick. It seems particle has developed no interest in making this feature happen over 4-5 years.

GLHF!