Or do you mean the
w command via serial terminal program while in Listening Mode?
Or do you mean the
No… I am looking for a very simple way for a consumer customer to connect a Particle Photon device to their computer (via a Serial cable) and easily configure the WiFi credentials without having to install any additional software.
We’ve concluded that using the SoftAP, getting the WiFi connection is the most troubling aspect of using our product in development.
We’d want to to use our web front end to do this, and was hoping that there is a “backup” method to attach in the case that there is difficulty during SoftAP setup.
this is what I was looking for, so thanks!
- I noticed this is still in beta does anyone know if (though it worked well for me) there is an update expected and if it will move into “production?”
Has anyone implemented this method for a product they are developing?
It looks like the customer would still need to have a Particle account to use this website. I’m not well versed in the product side of things, but it seems to me that there should be a way for customers to connect an embedded Particle device to their WiFi without having a Particle account.
Perhaps @rickkas7 or a Particle person can point us to what they feel is a robust connection paradigm for a product!
… this is that way, the caveat being that modern windows installations don’t come with a built in friendly interface to serial ports leaving you to install your own.
You could make this more user friendly by writing a quick GUI (.NET serial port support is pretty simple to use for example) You could also expose the wifi setup functions to the serial port with some extra routines so that listening mode was not required.
SoftAP is a common approach taken by many connected devices as a way to get credentials, I would agree that many people are likely to find it clunky and annoying but it works, there are other approaches.
WPS - It looks unlikely this will be supported, WPS is strictly a consumer grade solution and Particle have pointed at its vulnerabilities as a reason not to use it, even tho’ they pertain to the router implementation, not the client.
NFC - could work quite well for phones but I would imagine it would require a custom app, there appears to be a protocol designed for that purpose
Electric Imp - this rival device sets up WiFi using a photo diode and flashing your phone screen, devious.
Well, that’s just it. We noticed that for a certain population of a very common Verizon router that we had to advise end-users to pre-pend the password (like this) with a set of double zeroes.
We would classify that as “not working” as we had many beta testers (20%) in the group with this kind of router and in every case we needed to spend considerable time on the phone helping users getting the devices connected. In a broadly launched consumer product that would certainly get us less than 5 star ratings and runaway expenses, I’m sure.
Our product isn’t operational without WiFi in that its key selling feature is its ability to communicate via our servers to the devices and devices interact peer-to-peer (i.e. we are not “monitoring” we are interacting).
For example, if you look at certain products (advertising Particle relationship) reviews on Amazon… WiFi frustration is mentioned in nearly all of the less than 5 star ratings and these particular devices indeed do not rely on a WiFi connection to perform. iPhone app ratings are thin, but not impressive; mentioning WiFi connection as well.
I suppose we could pay a developer to come up with a front end for MAC and Windows to set the device serially, but damn it if that doesn’t suck.
Because of their experience with connected products, our manufacturer is aggressively pushing us towards another MCU/WiFi pair with better WiFi support, but we’ve spent time getting our product working well, negotiating the Particle Products learning curve and been getting interest from trade customers. It would be a shame if we had to rework our whole product away from the Particle EcoSystem because End-User WiFi setup is so troublesome (from our experiences).
I am hopeful that some folks who may have some experience with End-User setup may chime in.
I’m wondering if Particle’s strategy is to become the “Intel Inside” and provide (best-in-class) platform solutions to developers and end-users or are they simply a silent OEM putting all of the customer-facing development in the hands of their customers.
A “Particle-Powered” strategy where developers can simply customize the integration solutions would be terrific. We’d be happy to leverage that if we thought that Consumers would come to know that meant ease of setup and ongoing reliability. That would allow product creators to create products and not need to develop basic point-of-entry solutions. WiFi setup of Photon powered devices should be effortless and simple, both for developers and end-users. After the past few years of existence and growth, you’d think that Particle’s device attachment paradigms should be extremely vetted, sorted and best practices documented. I just don’t see any sharing of that, if it at all exists.
I’m not complaining, I’m offering up more of a strategic line of questioning.
@BulldogLowell, the folks at Particle do recognize this issue. From recent job postings, Particle seems to be showing interest in the ESP32. Since it has BLE, it could be used for device configuration making it easier, more reliable and much more generic. I have high hopes and expectations for their planned hardware refresh and I know that Particle is acutely aware of the pain points they need to address. Your commitment to their platform will be seen as a smart move IMO.
I appreciate your recognizing my point.
I we are then looking to a new hardware release to solve the ultimate concern, then that is probably way too far into the future for us. With Photon being now a couple of years into its release, and still in a not-ready-for-primetime state regarding its WiFi connectivity, It brings more concern to our issue as we would then have to wait for the new hardware issues to be vetted and (if it is Particle’s desire to develop some key integration solutions) wait for the secondary development of the key tools I mentioned above (or worse, develop our own).
We wanted to be in production in the next few months.
It seems that for a low volume commercial application we could probably deal with the extra overhead of assisting customers in any connectivity problems. In the case of a consumer product with broad distribution across a diverse set of end-user capabilities (not to mention the current “standards of expectation” set by other well-functioning products in the market today) I suspect that any launch would be costly for us on the back end.
Further, I’m concerned that (like the WiFi Photon development waned with the release of two consecutive cellular products with one seemingly developed exclusively for more industrial applications) that if we launch with Photon, we’d be releasing on a platform that would see very limited future development. We are afraid that we end up with yet another IoT platform that evolved like a movie going straight to DVD.
On the other hand, the fundamental underlying RESTful API is brilliant, and we adore it. In that regard we have a hard time containing our enthusiasm and creativity with the possibilities! So, like you we remain optimistic about future development. Its just that if future platforms (like the Photon and Electron) similarly launch with fundamental early-stage issues and no clear track to the desired endpoint, the possibility of an enduring platform that is an enabler of new product development seems not so bright.
I suggest to you that it was our optimism that led us so far along with Photon. I guess we need to ask these questions… Is it the strategy of Particle to create the hardware platform we seek? Will this be a “Powered by Particle” approach that:
- lets product developers lean on an enduring robust hardware chipset
- includes fundamental tools for integration (particularly at the user end)
- Still has the awesomeness of the Particle Cloud
PS: Is ESP32 really the future of IOT?
There is no panacea here, every IoT device that is wireless only has the exact same problem. the electric imp is the only one I know of that came up with a radical solution to the problem baked right into the product (I’m ignoring WPS here no doubt a router so old and **** it only uses WEP doesn’t have a WPS button anyway and plenty of other don’t use a physical button which makes it less n00b friendly. @peekay123 has posted before that it might even be vaguely pencilled in for 0.8.x ). You can setup the wifi without particle software using the serial port, its just a bit basic and will accept invalid settings for detected networks e.g selecting TKIP instead of AES. I don’t know why this is the case when the SoftAP solution is able to work that out for itself.
Your WEP issue probably exists with other devices too, WEP should be DEAD, nobody with a WEP network IMHO should be allowed an IoT device anyway, it is no longer fit for purpose. I suspect plenty of devices out there would simply refuse to connect to it.
If you can develop the application on the Photon you already have the skills to create an idiot customer friendly application for a Desktop. However connecting via serial will need a driver (pre win10 & to recognize the occasional issue where windows decides its a mouse) if using the Photon USB or a dongle/another USB->serial chip on your PCB. You also then require you customer to have a PC with USB ports, plenty of households out there these days that only have phones&tablets. WiFi & bluetooth are really the only ubiquitous communications methods out there. I originally suggested the product I am working on should support being setup over serial but the client didn’t want another port on their enclosure, however in my case unlike yours the end customer might have 100’s of boxes to setup.
And the last option, take the open source Particle app, remove all the Particle account bits and resubmit it to the store, although my understanding here is that on iOS the app is almost as clunky as SoftAP as it doesn’t like apps switching networks for you.
My solution to making entering WiFi credentials easy is by adding an LCD screen and button to make entering and seeing what you entered easier.
It’s not an ideal solution cost wise but it’s a way around all the other more complicated methods. I already planned on having an LCD screen so not so much of a deal for me.
Can you show me what you mean?
What are you displaying on the screen?
I don’t have an example to show you but I know I can have a customer enter their wifi name and password on an LCD screen, I’m using 4D systems touch screens but any kind could work as long as you have an input source for changing the wifi name and password as desired.
Then when the info is set you can just push that data to the Photon using the set Wifi credentials function.
Surely, his doesn’t work to setup the initial connection to a user’s WiFi, does it? There has to be more to it than this, or why would Particle go through the more convoluted process that they use now. I assume the initial connection requires some process that involves public/private keys and encryption, no?
I’m just talking about setting the Wifi Name and Password.
I planned on provisioning the each Photon before shipping it out so all the client needs to do is enter the Wifi info to connect and anything else that we need data for.
I assume Particle has a more complicated process because they can’t rely on the end user having an interface for entering and displaying data so they have to rely on other methods.
I think that once it is connected to WiFi, it is just another unclaimed device sitting out there.
We couldn’t come up with a decent way to do that with a device that we would hope to sell several thousand units. The Product aspect of the Particle Cloud is spectacular for getting us provisioned using their various APIs.
We’ve established a great method to handle the provisioning of the unit automatically (during user account setup). We too are utilizing a LCD display for this part of the process, but making the Particle connection (after WiFi connection) using a different paradigm.
We are extremely happy where we ended up with that, except that we had so many users having difficulty with WiFi setup, thus my griping.
Hey folks – lots of good questions in this thread so wanted to jump in and provide some perspective from the Particle team.
##SoftAP Setup reliability
As a general note, setup is one of the most difficult user experience challenges for IoT products. There isn’t a perfectly reliable option and, especially for Wi-Fi setup, the diversity of different setup interfaces (mobile, desktop operating systems) and destination networks (2.4/5GHz, WEP/WPA/WPA2/Enterprise networks, lots of different router hardware vendors).
It is also worth noting that implementation of Particle’s setup libraries is what ultimately determines the quality of the setup experience. If product creators are encountering issues implementing our setup libraries in a way that results in a reliable setup experience, we would absolutely like to know.
That being said, Particle’s SoftAP setup interface is intended and designed to work reliably. It sounds like you cited a couple of issues leveraging the mobile SoftAP setup SDK with your products:
- Issues submitting passwords for particular Verizon routers (WEP-encrypted networks)
- Using SoftAP, “getting the Wi-Fi connection”, which I interpret to mean connecting to the local network created by the Photon device
I’m not sure if you’ve already reached out with specific bug reports that our engineering team can engage on, but we’re committed to supporting our SoftAP setup process.
##Recommended setup method
There lots of ways that you conceivably set up an IoT device, some which are supported by our current Wi-Fi hardware, and some that are not:
Supported by current hardware
[Recommended] SoftAP setup (on a phone). This method is recommended by Particle for product creators and is the most secure, stable, and reliable. This is also industry best practice for configuring Wi-Fi only devices. This is the method that we use with our own Particle mobile app and package up as a set of SDKs for product creators and is currently and will be actively supported in the future.
SoftAP setup (from a desktop). This is available in beta as a setup method for Photon devices at http://setup.particle.io. Unlike SoftAP setup from a phone, it has not been packaged up as a SDK that can be easily leveraged by product creators for their own products. For that reason, it is not currently possible to “white label” that setup interface for use with a branded product leveraging OAuth.
Serial setup OTW (over the wire). This is also a possible option that is implemented via the Particle CLI, but requires configuration of serial drivers for many Windows machines.
Not supported by current hardware
- Bluetooth setup (on a phone)
- Bluetooth setup (from a desktop)
- NFC setup
I have may have missed one or two proprietary setup methods that use light or sound to encode and transmit network credentials, but those are not broadly supported within the industry and carry their own set of limitations and challenges that hinder and affect reliable setup.
Particle recognizes the value of using a bidirectional setup channel like Bluetooth to provide a more information rich configuration experience. We are always looking to provide the best setup tools to our customers and product creators, and may explore that configuration model in the future pending compatible hardware.
That being said…
Regardless of new hardware or setup experiences that we support in the future, we will continue to support the Photon and SoftAP setup as a configuration tool. We are committed to supporting product creators on our platform and will continue to support SoftAP setup.
Particle also has a demonstrated record of supporting legacy hardware. We still include and ship firmware updates to the Spark Core, which has been out of product for multiple years.
I hope that helps to address some of your concerns. If I missed some specific questions that you’d like answers to, please let me know! I’d be happy to help if I can.
One more addendum – reliability of SoftAP can also be affected by the firmware running on the Wi-Fi device. Running the latest version of system firmware is always best practice, as is limiting possible firmware interactions that might interfere with the SoftAP setup libraries during configuration.
Thanks for the reminder… We need to include regular testing our latest device firmware with the Particle firmware updates and push those out…
Very good point as we have not really focused on that during our development. Often times it means more work getting our libraries back in line with the Particle improvements and changes!
What are you guys building? Love to see the different stuff being built.
Believe me when I say… we really wish we could be telling people what we are doing by now!!