New Particle console

What I’m assuming is that the current way you’d handle devices should not be affected by the dashboard as it hasn’t been before. You should be able to select devices in the IDE as you’ve been doing before. The same should be true for the various APIs, and you should thus be able to roll your own solution should you be willing to make the effort.
That said, some confirmation on this part wouldn’t hurt, since these are just assumptions of my own :wink:

Got it. That’s what my understanding is after reading this particle.io/pricing

@duffo64, Hi there! Particle compounds that are grouped into a product are subject to the new pricing tiers. In general, Particle’s cloud infrastructure and software platform is hardware agnostic - Photons, Electrons, Red Bear duos, Bluz, etc. We strive to provide the same experience of OTA firmware upgrades, pub/sub, webhooks, console interfaces, etc. regardless of what type of hardware is connecting to the cloud.

To reiterate though, if these compounds are not grouped together as a product, the new pricing model does not apply.

Hope this is helpful!

Jeff

Hi Jeff, thanks for your reply.
I heard conflicting from sales@particle this morning. They are suggesting that I have to sign up for one of the paid tiers even though I do not have a ‘product’ in the console. I do not use any console features and don’t plan to.

Can I take yours as the final word?

Following up via DM for your particular situation @rahilj

Thanks. Appreciate your help.

Hey there. I know it’s a bit off topic, but for OTA updates only, why not this?
Use Particle CLI and a VBScript to process firmware updates?
The method described here Particle CLI talks about remote updates.

The following VB code remotely flashes one of my Photons with a compiled .bin file I have on my C: drive.

Dim oShell
 
Set oShell = WScript.CreateObject ("WScript.Shell")
oShell.run "cmd /K CD C:\"
oShell.run "%comspec% /k particle flash Photon1 photon_firmware_1470265344230.bin"
Set oShell = Nothing

If you had a .txt file with all the names of the Photons that need an update. The VBscript could read the file’s contents and for each of the Photon names insert the name into the

oShell.run "%comspec% /k particle flash Photon1 photon_firmware_1470265344230.bin" 

code line where “Photon1” would be the current photon’s name and "photon_firmware_1470265344230.bin’ would be your compiled .bin file.

If this could accomplish the task of updating many Photons then you might not need to pay for that feature.

Just saying. It’s an option.

1 Like

@bconstructive Sounds like a good idea for guys who just want to update a lot of devices without needing all the other stuff that comes with a cost.

I would also like to comment on the new pricing model. This is a shocking change to the business model for working with Particle. One of the major reasons we started working with Particle was the predictable cost structure, which is essential in creating a mass produced product. The other competitors charged monthly for their services so it was difficult for us to build the lifetime data costs into a product upfront. However, with Particle, this was different. The deal was a $2 fee for your cloud data transmissions. This was a fixed and manageable expense that worked for our cost estimations. Now, everything is different . . .

I remember back when the AWS IoT service was launched there was a thread here that discussed the cost of the AWS service. It was said that charging $5/million messages sent through the service was very expensive. If we look at the Rollout tier in comparison it costs $249/month for 10 million messages. Even if we apply the “expensive” AWS pricing scheme, that would equate to $50/month for the same level of messaging. So the question becomes whether the other console services are worth $199/month. Of course, the AWS IoT service is not the same as the Particle platform since it does not have the device management and firmware upgrade capability, but the price difference is vast.

I also find the concept of fixed device and messaging count tiers strange. If you are going to charge a monthly fee based on the number of devices or messages sent I would prefer to pay for my actual usage. Why do I need to pay for devices or messages in excess of what I actually use? I would guess that the tiered pricing scheme is designed to make thing easier to understand. If tiered pricing is required, then I think soft limits for overage would be better. For example if you have 1001 devices or messages > 10 million, paying an extra $0.249 per device or 10k messages would be manageable and predictable.

In planning our production budgets, stable pricing estimates are an absolute requirement. We cannot have a cloud cost that ranges from $0.249 per product per month to > $1 if we end up selling more than 1k units. This type of a volatile cost base makes it extremely difficult to include Particle in our products.

Beyond the details of the new pricing scheme, I find the overall issue of drastically changing the business model deeply disturbing. We have been working for over a year integrating Particle services into our various products with the understanding that it would be $2 for the cloud licensing fee. We also just executed a production contract with a client on Monday but now our pricing estimates are completely invalid. Changing from a one-time fixed cost to a monthly, ongoing fee is a big big deal for us. I understand and respect that Particle has their reasons for making these changes but this is a game changer for us.

6 Likes

I wonder if this kind of double tier pricing model would work:
Baseline cost which would cover the cost of support and some features. So these would mirror the current levels like prototype, pilot, rollout and scale etc. User could choose one that fits. Ie if you need fast support and SLA you’d choose scale.

Per device cost which would also vary based on tiers. So something like:

  • basic level which covers just the device management and OTA updates,
  • IOT level which has above + connectivity
  • IOT+ level which has above + webhooks and other fancy stuff

So then your montly invoice would be based on the baseline costs + (per device cost * amount of devices on that level)

Then everything would be easy to calculate beforehand and you would be able to cater to different use cases…

1 Like

Let me understand… I can have a single account with 1000 devices, not grouped in a product, and I can use for free the cloud? ok, I wouldn’t have all the cool features released with the console, but I can publish some vars and make OTA update, one device at time? If this is it, for me will be ok, I don’t need more.
Thanks, Flavio

1 Like

Hi @jeiden,

Sorry, I did not explain rather well my concern: it was a technical one. When I create a product in the console, I can choose only Particle products. Does this means that console does not play well with compounds, or should I choose the Particle product compatible with the compound (e.g. Photon if I have Duos) ?

Claudio

Hmm, I'm assuming that $2 fee was the lifetime cloud access? If so, then that hasn't changed I think. Before this price, there was also a recurring cost for dashboard features.
What's similar with the 'before & now' is that the dashboard offers optional features designed to make creating a product easier. Key to this is the fact that they are optional. If you don't want to use the dashboard, all the power to you, though you'll have to make some features yourself, should you have need for them.

@flavio.ferrandi I think those assumptions are correct. If you haven't meddled with products before, then nothing should change. The dashboard offers additional features to what's already there.
No promises, just what I think.

@Moors7 how can you do it? The dashboard before and the console now are required if you want to sell products to the final customers. You need customer claiming connected to a two-legged server, OTA updates to all devices, SSE events per product. And you can’t use Cloud API endpoints for product without going into the new tiers, you can’t either add a device to a product, so you can’t develop your own console on top of them.
Building a business using the platform as a developer and some tricks to find the way not to pay is a bad idea i think.
I want to pay the console because i like all the tools of the platform, that’s why i need to find a platform that make my business model sustainable.

I’ve never had the fortune to have to create a product before, so excuse my lack of knowledge on the subject.
You are right that you have to get users to sign up to a server, and you need a server to manage OTA and events. I personally don’t see a reason why the console is the only way to do so. And of those things could also be handled by a private server, though you’d have to make an effort to create/maintain it. The question then becomes if the development of that is worth it compared to the convenience the console would give you, given that everything would be contained in one platform.

The dashboard/console wasn’t there from the start of Particle, and people were still able to create products without it. I see no reason why that’s no longer possible now that it’s here. It might take (quite some?) more effort, but it’s still an option.

Again, just my personal thoughts on the matter.

3 Likes

True, I made a basic firmware flasher using the API while the paywall was up, but didnt take it further than that, since they said prices was under review.

New pricing is just too steep for me when only using the OTA part, all my data are logged with direct connections.
At the moment, my flasher works, but only with online devices, so room for improvement.

I would gladly pay a reasonable fee to help keep particle in business, but several times the cost of my dedicated server to enable OTA is too steep.

But making an opensource alternative would nee clarification on the fee is only if you use the product feature, theres some disagreement with whats written and what customer service says in this thread.

@duffo64 - currently, only creating products based on the Particle development kits are supported. In the future, we will likely support other compounds. If you want to take advantage of the product tools now, I would suggest using a Photon!

I see that there’s some confusion about what we’re charging for vs. what’s free, so I’d encourage everyone to take a read through the FAQ on our new pricing page (https://www.particle.io/pricing). If there are questions about the pricing structure that aren’t answered by the FAQ or aren’t clear, please let us know so we can improve the FAQ and make all of this clearer!

Thank you. Our product will be BLE based, so Photon isn't an option.

Claudio

"Particle provides free access to Particle Cloud for prototyping."
Seems to imply that when the “thing” is no longer in prototype, you have to pay.

"I’M A DEVELOPER / MAKER, AND I AM NOT CREATING A PRODUCT; WHAT DOES THIS MEAN FOR ME? ​"
Seems to imply that only makers and developers are entitled to the free tier.

"WHAT’S A PRODUCT?"
Defines a product as made with the console, but does not contradict the first point.

So just to be absolutely clear, anyone can have say a thousand photons registered to their account, and not group them as a product, but instead use a 3rd party tool to manage the OTA, and particle would be fine with this ?

1 Like