+1 for the BLE API
I have a couple projects that would definitely benefit from this.
1 Like
What I’d love to see next:
- sleep modes
- BLE API
Thanks for asking!
Wanted to circle back to thank everyone for the input! We see some clear patterns emerging and will take this input into our sprintly product planning process. We have a couple of more near-term stability fixes out the door, and hope to get to some of the juicy new product features (Bluetooth, sleep modes, HA networks) shortly.
7 Likes
For me, I’d love to see items in the following order:
- BLE API
- NFC API
- Allow devices of all sorts to join the same mesh. No reason why two Argons can’t join the same mesh (even if only one is the ‘master’).
- Mesh Network being able to use alternative gateways. For example, if I have 3 Xenons, 1 Argon and 1 Boron – if the WiFi goes down, the devices connect to the cloud via the Boron, and switch back if the WiFi becomes stable again.
- Easier way to have Argons switch WiFi networks. Easier for units to switch the Mesh they are apart of.
- Support for the debugger in the VS-Code environment.
BLE API
(Assuming this means directly communicating with a xenon / boron / argon from a standalone BLE device)
- I, and many others, want to be able to connect directly to these devices with our own custom apps on our smartphones to interface with them.
I can see so many applications where for less than $10, you can add configurability through a smartphone. The possibilities seem endless. Industrial sensor configuration? Screw you HART foundation. I have BLE on my sensors. It doesn’t end there… #limitless
5 Likes
- XIP access for more program space would be a huge reason to switch from Photon to Mesh devices for production products
- BLE would awesome
^ THIS ^
I kind of doubt we'll see this happen (for various reasons, some practical, some business/ROI-related), but I'd love to be wrong! Edit: Okay, reserving judgement until HA details come out. 
4 Likes
@dougal, this functionality is exactly what is being planned for the High Availability (higher cost tier) mesh networks.
So you’ll be able to specify “primary” and “secondary” gateways? I had the impression that the mesh would just always use the “best available” gateway, based on nearest path. If you can somehow configure (or if it’s just automatic) that WiFi should always be primary and only use Cellular when no WiFi gateways are available, that will be better than what I was expecting.
@dougal, how Particle implements HA is still not defined. The “best available” may be based on “cost of route” or pre-defined fallback order. In a true HA mesh, you may have primary and secondary gateways in different segments of a large mesh (eg. “at both ends”). There are many possibilities which Particle needs to explore.
3 Likes
I like @peekay123’s list + HA capability as already discussed.
If I pick up one item, it’s stability – the mesh stability of course, and the cloud connection stability also. I think the cloud integration is a major differentiator of Particle Mesh, but I am disappointed and frustrated when the device seems disconnected from the cloud so often (i.e. Particle.publish/Ping/Diagnostic/OTA etc. do not go through) although I am sure the device is sending the events over the local mesh network (by Mesh.publish) perfectly fine.
- General reliability
- Mesh networks
- WiFi connectivity
- cloud monitoring of devices
- NFC API
Thanks for asking.
Thanks all for taking the time to share this feedback. It all aligns pretty well with our expectations. For those counting at home, here's the feedback tally (below).
We've already begun preliminary work on the first two (BLE APIs and Sleep modes) and will begin discussion of the features below internally.
BLE API ++++++++++++
Sleep modes +++++++++
Device recovery (HW watchdog) +++++
NFC API ++++
Topology mapper ++++
User access to external flash +++
HW debugging in workbench +++
High availability networks +++
Mesh management API +
One free HA network +
Stable threading
Sleepy end devices
"Efficient" mesh OTA (download once, distribute locally)
Boron Cellular API completeness
Cellular data metering in dashboard
Update CLI to support Mesh
Gateway can join mesh as an end device
Easier switching of Wi-Fi / mesh networks
XIP for external flash
9 Likes
I definitely agree with that! It would be really nice to be able to have both an Argon and a Boron gateway on a single network (without the steep price tag).
1 Like
Great stuff.
I think folk know I’m keen on BLE, specifically:
Bluetooth characteristics
- Private UUID characteristics r/w/notify
Transparent UART
- Straight write mode like serial print so folk can roll their own if they so desire
- Particle publish via BLE
- Particle function via BLE
The latter two need some careful consideration as to how its handled, a command string, string delimiter etc etc. Folk should be able to follow the spec with some examples in nodejs and arduino to implement on their end. I say nodejs because a lot of hybrid apps are running angular and running a simple command line nodejs script is pretty straight forward and easily ported to their mobile framework of choice (ie Ionic).
Thinking aloud, it could even be possible that BLE function calls are made via a write to a characteristic and BLE publishes are via another characteristic with notify on. That would make life pretty easy.
As an aside, what mongoose os do with their RPC approach is pretty cool.
2 Likes
Just got my particle. +1 more for NFC!
+1 to the XIP - more program space would be great
Sleep modes +1
- Bluetooth mesh (High priority)
- BLE API (High priority)
- Sleep modes (very important)
- Sleepy end devices (very important)
- Device recovery (HW watchdog)
- 2MB flash memory access
- NFC API
- Topology mapper
Is there any plan for Bluetooth mesh ?
@developer_bt, Particle is implementing mesh using Thread on 802.15.4 and not on Bluetooth. I don’t believe there is any plan to support BLE mesh.
2 Likes