Hi @peekay123 Thank you for the information. I know that, Particle mesh is implemented with using Thread but is there any plan for Bluetooth mesh? Or new Bluetooth support will be only for BLE?
@developer_bt, I am not aware of any plans to implement BLE mesh on particle devices.
I'm not sure what you mean by this. BLE is the technology upon which a mesh could be implemented (as Nordic does in their SoftDevice stack along with Thread). Particle will be implementing a "conventional" BLE API for mesh devices.
Confirming there is no plan for Bluetooth mesh.
2 Likes
Stable Threading +1
BLE API +1
3rd-Party Boron LTE SIM actually working +1
Until those things work AND have a reasonable track record, I will stick to the Electron and Photon. My use case requires threading for viable operation. I use way more data per month than Particle is going to be cost-competitive on. I need to be able to have the end user reconfigure WiFi credentials without physical access. The Photon does not have enough RAM to use MQTT with TLS.
If these things didn’t materialize I would eventually be forced to move to a different embedded platform (likely Amazon’s FreeRTOS port) within a year or so.
1 Like
Sorry 3rd party sim is out of the Boron SOM. It means LTE outside of US is a no go, and it was needed as fallback for single locations without coverage, in a multi location delivery to keep the contract. Hope to see at least an interface to one in the coming products.
THIS
- 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.
1 Like
Are we still limited to a single gateway per network at the moment?
Yes, still a limit of one gateway per mesh network. Multiple gateways is still a planned feature, but the release is not imminent.
Can you tell what the current situation of Particle OS using nRF52840’s internal watchdog circuit may be?
1 Like
Agreed. This is something that a lot of us could probably use.
If you had to guess, and it were a perfect world, and absolutely no one were ever going to hold you to that time schedule, which Q/H would you predict for the multiple gateway feature? I understand my use case might not be in the majority, but I would so love to have HA networks for IoT enterprise applications.
1 Like
I realize you're looking for an approximated timeframe answer--I'm afraid that's something that we don't have just yet.
We recognize high-availability networks are in demand, and I would love to see these available the same as anyone else. However, I think rather than thinking about when this will happen, the more appropriate question needs to be what needs to happen first?
We are actively focusing on reliability, with gen 3 being high priority. In particular, we want to focus on the stability and reliability of our different gateways. We want to ensure that both we and our community are confident in the reliability of gateway devices before expanding to high-availability gateway networks. Trying to implement high availability too early will only add more variables to debug and may not offer the excellent experience we intend to provide. I'm sure you would agree that implement high availability networks defeats the value proposition if all the gateways are not operating as expected.
3 Likes
With network reliability in mind and not looking at specific chronological goal, what percentage of completion would you say that network reliability is at? (e.g. Are we more than halfway there on reliability, or is there a significant amount of work that still needs to be done before development can be done on HA networks?)
That’s another difficult ask, as it’s a hard metric to measure. Ultimately, the best indication is whether or not we have any outstanding issues remaining that we are actively investigating–which in itself may be hard to pinpoint.
While the three most common gateway use cases will be an Argon, a Boron, and an Ethernet Featherwing Xenon there are a lot of variables that can break down in further subsets we may wish to address. Does the Argon work under the various wifi configurations our customers use? Is the Boron is a 2G/3G or LTE and what operator is it on? What if the Featherwing has an Argon or a Boron?
Even with a list of known issues, it’s still difficult to approximate a timetable given the difficulty of each, and also the consideration that we may have teams working in parallel for different connectivity issues. The team responsible for the Boron connectivity may differ than the team focused on an Ethernet gateway.
I would say that it’s unlikely to expect it in the near term. I would say that it’s unlikely there’ll be any plans for that to change within a 4-6 week period.As such, this is something I’d check in every month or month and a half to see if we have any ideas on where this might be at.
4 Likes
There are regular Gen 3 Community Council meetings which cover this stuff - but no one has asked the question about how far along the stability spectrum the engineering team have got. It’s like how long is a piece of string? We are having another meeting in 2 weeks so you should see some output about priorities after that. Clearly the recent BLE and NFC delivery has been a major milestone together will further improvements in mesh stability. I guess you are reading the release notes?
I added another topic but maybe it should have been in this list. I like to be able to setup a mesh network without a gateway.
Good points. Seen a number of high profile datacentre networking companies struggle when taking their products to HA.
Just to add 2c as devil’s advocate, …having worked for a carrier who espoused the view that the best way to have enterprise availability was to trust their network, I can reassure you the best way for customers to have high availability actually was having another carrier in there providing equal path redundancy. That’s how for example you avoid all ATM’s across the country falling over or not being able to scan customer plane tickets. Having 2 is often better than 1 ‘really good’ one. Start with multi master and look at how duplicates are handled at the head end, then figure out how to make the gateways smarter with single master so duplicates aren’t sent. Just 2c!
1 Like