Backend architecture changes needed between Photon and Photon 2

Brainstorming
1

Our current systems are powered by the Photon, but we're making progress toward incorporating the Photon 2 into future designs. The only major difference between them is the wifi setup and device pairing process. With the Photon, it was nice that there was a certain amount of hand-holding available through the devicesetup SDKs, but now our options are more flexible but less obvious. The Wi-Fi credentials setting vs. device setup page outlines that the recommended way is much simpler than how it was done before, but also doesn't say exactly what needs to be done. We want to make small updates to our current mobile apps to incorporate the BLE credentials setting, but we may have to further implement the rest of device setup for the Photon 2 so account creation, device claiming, and access token management look as similar as possible to the Photon. If not, would we be able to "migrate" over to the recommended wifi-only setup process for Photons that have not yet been connected, and find a different way to manage users internally and decide on who has access to specific devices? We would ideally want to update our app instead of create a separate one, as well as have the process of setting up wifi be fairly seamless between Photon and Photon 2s.

I realize a lot of this backend work that we'll need to do is obvious, but I am much more of an embedded engineer than a full stack engineer and we're a very small company that doesn't otherwise have people more familiar with this setup.

Given this, what makes more sense for us in transitioning from the Photon to the Photon 2 from an architecture point of view; Trying to modify our current approach of using the devicesetup sdk with the recommended approach of handling everything on the backend, or going the other way and implement everything that happens in the devicesetup sdk for Photon 2s? I know this question is heavily dependent on what we're working with today, but I'm curious if there are other developers running into the same situation of having a product that will be migrating between Photons and what their solutions are.

2

@jettonj
Depends upon whether your devices are headless or not.

Our Photon devices all have a screen and 4 buttons and we have moved from using SoftAP to user AP selection and password input on screen. We also have an SD card storage and file download to storage so that once connected via a phone hotspot more complex WiFi credentials and PEM certificates can be loaded. Think passwords that are 64 chars and contain !?()/ etc. We will probably carry this over for Photon2.

Photon2 also has BLE and this opens up the option of a headless device (SoftAP also is not available).

Clearly with a BLE WiFi setup the user experience can be better however you will need an App to talk to the device. A white label app I believe was mentioned by Particle.

I hope this helps. Will

3

Our devices are essentially headless - we have a few LEDs that are visible to the user, and some capacitive touch buttons that accompany them. I'm not so much worried about our current Photon products, but how we'll incorporate the new Photon 2s.

I hadn't heard of Particle's plans for another white-label app for BLE pairing, but I have found that the rn-ble-setup example works decently for iOS. While this would absolutely be useful, I don't believe it will solve our back-end questions. It might make the most sense to just move toward doing everything internally and remove any direct calls to Particle from the apps. We'll know more as we get further along.