Context: We have a product with a P2 module that we use in our own fleet and are paying the monthly subscription for them. We've been approached by a customer who wants to purchase some of our devices and does not need the Particle integrations. The current device firmware works well with a companion application we've created in an offline mode. We'd like to sell them our product without dealing with the recurring costs.
Is it as simple as un-claiming and removing the device from the product to get it to run my user firmware and essentially operate as a WiFi enabled uController? If so, it obviously wouldn't have access to Particle cloud functionality.
Thanks!
Unclaim the device, and if it's in a product also remove it from the product.
You should use SYSTEM_MODE(SEMI_AUTOMATIC) in your firmware, then:
- For fully online, use
Particle.connect().
- For Wi-Fi only, use
WiFi.connect().
- For BLE only use
BLE.connect().
- For no network, don't call anything else.
What does it do if the firmware calls Particle.connect() but when it gets to the cloud there's no product/claim on it? Would it get added to my account billing somehow?
If it's possible we'd like to be able to claim the device later if they opt to pay for our connected features where we charge a small fee (that covers the Particle hosting cost), and to that end it'd be nice to keep the same firmware that is periodically calling Particle.process().
It works best if the user has to do something manual to switch between connected and non-connected mode, because otherwise the device will continuously try to connect to Wi-Fi or the cloud.
If the device is configured for Wi-Fi but not in a product and unclaimed, it will still connect to the cloud, and even things like Particle.publish will appear to succeed but no one can receive the data. If you have a lot of devices doing that and sending a lot of data into the void the Device IDs could get blocked from cloud access permanently for terms of service violation for unbilled device use.
Is there a way to test if the device is part of a group? can you give a rough order of magnitude for number of messages/publishes before alarm bells go off? I'd love to be able to, say, check if the device was added to a group on boot only, and internally disable any particle functionality based on that bool, but I guess thats kind of chicken and egg to use Particle Cloud to determine if Particle Cloud is enabled lol.
There is no exact limit, but at boot or once or twice a day is reasonable.
Any chance there's a handy Particle/System function that fetches if the device is in a group? Or should I have it send a query to Cloud REST API to test if it's in some given product group, and thus active? If the REST API is the way, suggestions on token management that I should use for that call?
There is no direct way to tell if the device is in a group from the device side. The DeviceGroupHelperRK library is one way; it includes firmware and a webhook to retrieve the information. That library pre-dates API users. As long as you are in a product, you should use an API User instead, which can limit the token permissions.
Since the P2 TCPClient can't do HTTPS, it can't curl directly to the api.particle.io REST api to test it's own membership.
That library looks great, but I see it relies on Particle.subscribe and Particle.publish to interact with the webhook. This is probably not great to do with a device that may have no owner or product membership, yeah?
I guess I'm just looking for some reassurance that our devices publishing to test it's ownership every boot or so wouldn't trigger any issues. Since they'd be in customer hands, I can't control how often they're booted, but I don't think it'd possibly be more than like 10-20 times a day. I get that you guys have the right to pull the plug on devices making unbilled access to the Cloud, so if we have to roll a separate interface to do something like this either in our companion app or an endpoint that the TCPClient can talk with, we can do that.
There is no good solution. If the unclaimed and non-product device subscribes and attempts to publish, the calls will return a success result code, but the subscription won't get the response because the publish goes into the void instead of to a webhook. This isn't ideal, but it would work. You could use EEPROM to add a secondary check so it would only happen once a day, even if the device was booted repeatedly, which might be a workaround.