Setup WiFi on Photon without using iOS Setup Library

Actually, that does work. Pressing that will transfer ownership to the account your're trying to set it up with. Just tested that.

OK, thats great. But not a great user experience for customers! I would need to explain that the process will seem broke, but actually works. So what we really need is the solution where an claimed device can be (re) set with Wifi.

To set the device into listening mode - I presume you can set the RST low for 3 seconds?

A solution like that is in the works, whereby the device can be reconfigured for wifi without having to have a Particle account.

Well, close, but try the SETUP button instead :wink:

@Moors, I should have been more specific. In my case I did not want the ownership to change hands and therefore had not removed the claim on the device.

In other words, device is claimed by “A” (say the manufacturer), but the device is in the customer’s hands, “B”. “B” can set up the WiFi without owning the device. All good!

Actually, with the Photon, ownership will be transfered automatically, regardless of who currently owns it. Physical ownership = virtual ownership.
The photon I tested it with was claimed to my “main” account, but now belongs to my test account, after I pressed the “transfer ownership” button, without confirming that from my main account (the original owner). @zachary once explained this in great detail, he should know more about it, should you be interested.

Hi Kevin

Yes, this feature is now available - I completed it last night for iOS. Android is still pending (next 2 weeks).
Read here:


and here:

Still need to push new SparkSetup pod v0.3.0 to cocoapods (it is currently only on our github repo, but feel free to clone/pull and use it).

Feedback welcome

Now that is surprising and unexpected, and sounds like out of spec…!

Wonder why my transfer did not work?

Yes, am very interested I will look up @zachary’s posts to find this mention, or if you have the link, that would be appreciated.

TL;DR

  1. Ownership transfer on the Photon is fluid. Physical ownership is virtual ownership. This solves one of the most common issues experienced on the Core.
  2. End user ownership is completely separate from a product manufacturer’s ability to control her devices in the field.

Longer Explanation

If you’ve ever been at a hackathon where a hundred Cores were set up via the mobile app using TI’s Smart Config and everyone claimed the wrong Core or one person claimed all the Cores, then you understand the problem we needed to solve.

In those cases, there is no way to be able to control a Core you are holding in your hand and are the rightful owner of. The only recourse is to find the person who owns it, and ask her to unclaim it so you can claim it. Eventually we automated this process in Particle Build to reduce the burden on our support team and allow users to take care of the issue quickly themselves.

With the Photon’s soft AP setup process, only one Photon can be claimed at a time so no one can take over a whole roomful of devices in an instant.

More importantly, if you have a Photon in your possession, and it is claimed by someone else, you just need to perform setup to claim the device. If you are borrowing the device from a friend, you can claim it from your friend, and then when you give it back, the friend can simply claim it again.

It is important to know that building a product on the Particle platform requires additional steps that one does not normally take when prototyping with Photons. Products identify themselves to the cloud, and the team members that belong to the organization that created the product always have the ability to control the devices regardless of which end user has claimed each one. Product management for organizations is completely separate from claiming.

These product management capabilities are exposed in the organization dashboard that is in private beta right now.

Photon Claiming Flow

As part of the soft AP setup process (technical docs), in addition to sending Wi-Fi credentials, we transfer something called a “claim code”. At a high level the process looks like this:

  1. Mobile app (with user access token) gets a claim code from the cloud
  2. Mobile app gives Photon (both offline) the claim code
  3. When Photon connects to cloud it publishes the claim code, which the device service uses to make the association between the Photon and the user.

Another important thing to know—the cloud is the source of truth for ownership. Sometimes I notice people implying that the device knows who its owner is—it does not. We control access through the cloud.

And one last important thing to remember about soft AP setup—both the mobile app and the Photon are offline during soft AP and can not know for certain the current status of ownership.

@jeiden just came up with this great diagram today — we’ll be incorporating this or some revision of it into some product creator documentation soon, but he suggested it could be helpful here. :+1: It describes one specific way (out of many) that product creators can manage customer authentication. It’s not the whole story, but it’s helpful info in this conversation.

3 Likes

Thanks @zachary, now understand the concepts better.

I think I now know why the ownership transfer did not work (within the Particle app), it is (?) because the device was part of my company’s product fleet (am part of Dashboard beta) and my customer test account did not have a token provided by the company.

Just hanging out for @ido’s device config app now!

1 Like

yes - the documentation is really useful. I have just emailed again for beta access to the Organisation beta - I need access to this to progress - any timelines on how long before access is provided?

That sounds correct @UMD. Products can only be claimed by customers of the appropriate org, not by generic Particle users. :+1:

@Kevin Our Customer Success team has been managing the gradual rollout of the dashboard beta and gathering the feedback in rounds. @jonlogan leads that team — you two could have a private chat about which wave you’re currently in so you know what to expect.

@zachary, this is off topic, but related.

Problem with this scenario is that our organisation would like to claim the devices, not the customers. This means that we are restricted to using the Web IDE to claim. This is not a viable option in bulk (the poor Web IDE’s device’s panel fills up)… (perhaps this should be a new topic)…

Totally understandable! You should create customers for claiming them! You can even use your same email address! :+1:

Also, the organization can control the devices even if they’re not claimed if you’ve got them properly setup as products.

@zachary, it is this statement that is giving us grief:

“the organisation can control the devices even if they’re not claimed if you’ve got them properly setup as products.”

We can download firmware no worries to unclaimed devices via the Dashboard, which is a great and necessary facility. The problem is that we have no visibility of the devices connecting to our services (assume because of the API key) until it is claimed via the Web IDE.

Excuse the length of the following, but it is my documentation of what we are doing (once again, off topic):

------------- begin ----------
Out of box. Listening mode - flashing blue

Connect via serial port and enter “i” to dump the device id:

Your device id is 400029xxxxxxxxxxxx230

Next went to dashboard:

Imported a device, with the check box “Force imported devices to switch to this product” checked. In the Devices screen, Firmware version displayed as “unknown”, email “none” and “never connected” (which is all expected). When I attempted to set the firmware version with a “Lock and Flash on reset”, red message box “Error changing desired firmware version: [object Object]” was displayed. This was not expected.

Next, set up WiFi credentials in terminal - flashing cyan (i.e. downloading firmware) then - breathing blue (i.e. connected)

Next went to dashboard:

Device now Firmware version now displaying: “reporting incorrect Product ID” (expected)

Selected firmware and Locked and Flashed Now. - Flashing cyan (i.e. downloading firmware), then breathing blue (i.e. connected).

Next went to our web service.

Device did not report as being online.

Next went to Dashboard logs,

Device did not report at all.

Conclusion, device has not been claimed.

Put the device into listening mode, logged on via Particle app. Attempted to claimed Photon under my test account, the following was displayed “Oops. Setup process couldn’t claim your Photon! If the Photon LED is blinking blue or green … please contact support”

Next, whilst still in listening mode, attempted to claimed Photon under the company account, the following was displayed “Oops. Setup process couldn’t claim your Photon! If the Photon LED is blinking blue or green … please contact support”. This was unexpected.

Next tried to claim the device from the Web IDE. This worked - our service now sees the device as does the Dashboard logging service.

Conclusion: can only claim devices via the Web IDE. Devices are only visible to our web service if the device has been claimed by us via the Web IDE.

------------- end ----------

Hopefully you can see the issue… am pretty sure that I am just missing a piece or two of the process. Also sure that others may have similar issues.

Thanks - Harry @UMD

Great diagram, it really helps understand the processes! Thanks!

@UMD You are correct. The device cannot receive firmware updates until it has been claimed by either a customer or user. That’s why you were receiving those errors when trying to flash devices that had not been claimed yet.

Maybe @ido could shed some light on why the device setup on mobile was failing, but keep in mind that when you ship out your product, you will want them to be claimed by customers.

See the diagram above for the flow. Currently @ido and @nexxy are working hard on updating our SDKs to handle customer authentication. Support in the mobile SDKs should be available within the next two weeks. You are on the bleeding edge of what our platform can do :slight_smile: .

I am also working on more detailed documentation of the setup/authentication process for product creators. Expect that to be released next week.

Jeff

1 Like

@jeiden, yep, understood, bleeding edge! Happy to work hard with Particle to get a smooth commissioning process in place for us product makers.

Not sure that this comment is correct: “The device cannot receive firmware updates until it has been claimed” - evidence (75% sure) is that the firmware does download, and does run, but not “associated with an owner” in the cloud.

Our issues can be boiled down to this:

a) we need to test the kit before it leaves the factory, this means that it needs to be claimed

b) As we don’t know who the customers are at point (a), we, as the manufacturer, need to claim the device so that we can fully test all functionality

c) The claiming process at (b) is clunky via the Web IDE. We would like to do this via particle CLI (but there is another issue within our corporate LAN environment - we use a proxy…). I don’t think particle cli has a claim function yet. (Are there plans to do so?)

d) I see that the fundamental philosophy is for the customer to claim the device, but it is not really needed in our use cases. We just want the customer to configure their own WiFi credentials.

Hope this makes sense. I think it is all achievable. We have a work around now which is the Web IDE. Problem is what happens when is scales (we call this a “happy problem”)?

Best wishes Harry @UMD

3 Likes

I have the exact same use case - which seems the appropriate way to manage a fleet of devices.

So the company remains the owner - not the customer.

I believe there is some documentation bring delivered next week to more fully explain the process - hopefully this will provide more insight.

2 Likes

Think again :wink:

1 Like