ST IoT, Particle cloud constraint and other

Hello everyone,
i’m pretty new with the product and i’m still tinkering if i should buy it or not.
My main project will have to handle push notifications (apple and google), sensors and few other stuff. Since it will be an IoT project i’m looking around to see what the market can offer me.

My first question is why ST itself is just selling modules like SPWFxxxx where you are forced to use a board (you can’t flash a firmware on the wifi module itself from what i know).

The second question is if the particle cloud/API is a constraint you can’t avoid. Can i completely cut it off? For Android/iOS and the Photon itself.
As i said i will implement push notifications and i would like to handle GET requests myself (with ssl/tls) rather then be forced to use Particle API/cloud.

The main reason is that i would like to keep it as simple and as portable as i can so i can’t rely on Particle for this.


  1. If you use a module (which Particle is using one from USI), you will need to add all the necessary buttons, usb, power management ic etc can get started.

Buying a Photon simply makes it easier to get started. You can buy the bare module (P∅ or P1) just like those sold elsewhere.

  1. There is no constraint to use Particle cloud. You can choose not to use it if you don’t want to.

  2. You can do pretty much anything you want since firmware is open source and you can obtain the wiced firmware from Cypress if you purchase from them directly.

The whole idea is that the Particle ecosystem makes it easier to connect to the internet, do stuff like webhook integration, pub/sub etc.

If you are looking to write your own stack per say, you are welcomed to purchase the bare module and do your own development.

My first thoughts would be get yourself a Photon anyway, as it’s a really good product, and well documented. You can either go with the particle cloud, or choose not use use it at all using the system modes… when set to manual if you don’t enable the particle connection then it doesn’t exist as far as the Photon is concerned.

As far as why is ST selling modules like the SPWFxxx (like the SPWF01SA?), I think it’s because you’re comparing a prototyping/development board with a module that is intended to go in a finished design. A more apt comparison would probably be been something more like the Particle P1 (the MCU portion of the Photon) vs a ST SPWF01SA… (completely ignoring RAM and flash memory sizes and GPIO pins, etc). I’m happy for someone to say that’s complete baloney if I got that wrong though! :wink:

I don’t have any Photons myself as I went the ESP8266 route when starting with MCU+WiFi/IoT stuff, so never got around to getting one (might have to change that soon), but I’ve yet to see any real criticism of it, so it must be good. I was just lucky in one respect that the Digistump Oak came onboard on the Particle cloud (and then the Raspberry Pi), so I got to see and use their infrastructure, and continue to be amazed at how things continue to get better and better.

1 Like

I discarded the ESP8266 due to omologation problem that i eventually want to avoid in the final product.
The basic idea is to have a product with a photon inside which uses the wifi to locally communicate with smartphones and at the same time send push notifications through GCN/APNs… Everything without the particle stuff for the moment…
I know one can even setup its own spark-server and probably it will be my next step but for now i’m more focused on discarding particle related stuff (they are indeed amazing though)…

For now, no Particle = no encryption. There is a current effort to develop some support like the TlsTcpClient library and it is also somewhere on the Particle wishlist roadmap. However an Https client is a non-trivial task, as discussed elsewhere implementing it consumes significant resources on a pretty restricted platform leaving very little room for anything else. Something does seem to exist for the ESP8266, an arguably more restricted platform but I don’t know what using it leaves for your application.
I have seen suggestions made in other places that you offload secure comms to another device/service. This could be something like a Pi or perhaps a web application on a NAS on the trusted LAN. This doesn’t really help with a commercial product but certainly gets around the issue for bespoke or personal projects.
The remaining option is to use a product that is designed to support secure connectivity with a 3rd party cloud,- Onion, Pi Zero W, Lantronix xPico or some other mBed/WICED device of which there must be many more.

I get what you mean.
Lantronix xPico was in the list but then it would be the same as SPWF01SA where you need another micro/board to handle the application code.

I was looking for a particle-size device which can do SSL/TLS on its own as well as running its own application code/firmware.

Is the ESP8266 really the only one right now?
The ESP8266 is indeed capable looking at the API, it’s missing IC (canada cert), but it has FCC/CE. Is FCC/CE enough in Canada?

I’m sorry, what problem with the ESP8266? Just curious… as it does have one or two limitations that can be quite annoying, but for the most part, they can be relatively easily worked around by crafting code that takes those limitations into account. And the ESP8266 Arduino core should give you all the functionality you want. Or you could consider the ESP32 if your concern is with the single processor doing WiFi management and the application program at once… as it is dual-core so that will be a thing of the past.

And unfortunately no, it doesn’t look like FCC/CE is enough for Canada… they want their own chance to grab money from you so you need to have it tested to meet their requirements.

Is Canadian radio certification required if the device complies with foreign requirements such as FCC?
Yes, Canadian equipment certification is required. All radio equipment intended for Canada shall meet requirements of Canadian procedures and technical standards.

I found this

It seems particle hw can handle it then

1 Like

In its early days at least (which weren’t that long ago) that was a pretty big library the use of which could compromise your application, depending on what else you w ere trying to do.