Mesh Hello World

[Darmitage]

@ScruffR and @RWB thank you for your candor and perspective on what appears to be a bit of a debacle for Particle. I share your confidence that Particle will resolve these issues. I have worked extensively with Digi’s DeviceCloud and RemoteManager, and there are a myriad of reasons why I am intensely loyal to Particle.

Accepting for the moment that Mesh is not ready for primetime, I wonder if Boron is? I am anxious to make the switch from Electron, but I cannot afford to waste time and lose focus if Boron is not ready for large scale commercial deployments.

[RWB]

@ScruffR

The hardware is, it’s the firmware that’s lacking/lagging maturity (yet) and Particle is aware of the issues, but would calling back all the delivered devices now and giving up the whole endeavour for the bad start help anybody?

No I never suggested not sending or recalling the devices. The recalling or never sending devices would only make sense if stability or satasifacrory performance is not achievable due to the hardware combo that as chosen.

@ScruffR

I’d rather have Paricle focus on improving what we’ve got than tie them down in that effort by forcing them to keep appologising and confessing their sins and crying over spilt milk.

I agree, we need them to get everything fixed so we can get the full value out of our financial investments. We’re not asking them to apologize all day, we just want MESH functionality sooner rather than later considering the extended wait and the fact that they lead us to believe everything was all good by not saying a single word about the MESH feature being basically unusable in its current state.

You can’t tell me everything was working well for everybody at Particle and you beta testers and the issues started only to show up after everybody received their devices. I do agree the Android setup issues did pop up as more Android devices were used for the setup process.

All I’m saying is that it would have been nice to have them say that the MESH is not currently where we or you need it to be but we are working on it 24/7 and we are going to send the hardware now since it’s ready and we are confident this is just a software issue and not a potential hardware issue.

If they would have just been upfront about it I and others would have know that this stuff may not work right once I set it up so don’t be surprised. Instead I excitingly spend a few days getting everything setup only to find out the MESH feature was not really useable for longer than a few hours from my testing.

I wasn’t really mad just disappointed because I felt like I was lead to believe the basic functionality was going to be there.

Even using the Argons without the MESH features is problematic since when the WIFi is lost it never reconnects without a manual reset.

The Boron is missing important Sleep Modes and until yesterday the cellular data consumption usage numbers were not available which are both critical for cellular development.

It’s obvious this is a bigger task than anticipated, I’m totally fine with that, I will hold onto the equipment and keep testing as firmware updates roll out.

@ScruffR

Many of the issues that pop up now were not anticipated - some even couldn’t be

e.g.

nd6 vs. IPv4: Who’d thought that in a pure IPv4 setting nd6 packets would be floating around?
Do you know or even care how many DNS servers your router sends out? There were many brands tested, but for some reason they all just used two. But surprise, surprise in the wild there are others that don’t do the same (there is no rule for or against it)

They had to have been well aware of these DNS issues causing the MESH to not work right. If not then the initial testing was not very widespread considering I have not heard of any real stable MESH setups reported on the forum yet.

@ScruffR

Android fragmentation is a problem for many app creators, testing against each and every flavour or customised version will always be impossible.

I totally expected this to happen with so many different devices in the wild.

@ScruffR

How do you communicate issues before you become aware of them?

Are you trying to say Particle had no idea the MESH feature was basically unstable to the point of not useable for more than 24 hours that was a total surprise to them?

I’m not inferring that they should have told us of the smaller bugs or issues that did not affect the basic MESH functionality.

I’m pretty sure the instability issues was part of the reason for the delayed shipment.

@ScruffR

There should have been a lot more time for beta testing with a wider audience (e.g. including Elites) but due to the manufacturing delays (mostly not Particle’s responsibility) that period has been cut short.

Most Elites got their devices for “testing” and prepping up for community support after some people started reporting about their issues.

My point exactly. The lack of beta testing and not being upfront about the MESH functionality being in the state it is in with RC25 firmware is what lead to the disappointmen. It took us 2-3 days of personal testing to figure this out and come to the conclusion that this stuff is not ready and they had to be fully aware of it. And I think to myself that they should have just been more upfront about it in my opinion.

It’s tough though because I can see it from their point of view also where they needed to get this hardware out the door and recoup that investment they they self funded until recouping the funds from us the early supporters of this product line.

I can see why they didn’t want to mention it until everybody started reporting back on what they already knew, that the basic MESH feature was not really useable / reliable.

It was only after we all reported back that then MESH is not working that Particle posted that they are aware of the issues and are working hard to get stuff fixed. I’m not mad, it’s just $150 investment on my end, I just wish they told us about the MESH issue ahead of time that’s all.

@ScruffR

Bigger companies also triple of up bodging their established product lines and are usually nowhere near as open in admitting that.

They didn’t really admit to the issues until after they took everyone’s money and we all reported back that the MESH was not working for most of us.

At that point they really had not choice but to say we are aware of the issue and we are working hard to fix this. What choice do we have at that point other than wait for a future fix or ask for a refund.

If we had of know the basic MESH was not stable we would have then had the option to choose to spend or cash on something that has little value until fixed in the future or maybe spend that on something else or spend money on Particles older more stable products. Personally I supported MESH and keep buying the Photons.

@ScruffR

Particle has been creating an entirely new kind of product line for them and IMO has always been rather open and transparent about their mishaps, limitations and even bodges. They might have been considered slow in their responses at times or overly optimistic about possible resolutions (e.g. timeline updates), but defintly not out of lack of consideration for their user base.

Overall Particle is AWESOME! The community is AWESOME! The Photon, Electron, E Series, and whole backend is AWESOME. The overall look and feel of the Particle website, marketing, and product line is the best out there in my opinnion and I’m not going anywhere and am working on useful and awesome products that integrate the Particle product line.

Just wish they were like, hey guys the Hardware is ready to ship and the software we are still working on, the MESH is not stable yet so don’t expect it to be until we get it there which may take a few more weeks or months. We sincearly hope you give everything a try and be active in reporting any issues so we can gather that day together so in the near future we have one of the BEST short range MESH IOT platforms on the market.

Thank you all for supporting this new technology and understanding that with this new technology there will be issues we need to tackle to get it where we all want and need it to be before we can integrate it into exciting new product lines that you will be able successfuly ship to your customers.

Thanks for supporting Particle again and working with us to create this new Particle MESH platform.

@ScruffR My only fear in speaking my opinnion here is that I rub you the wrong way which then prevents you from helping me with any future Particle related project issues.

[RWB]

@Darmitage

I have worked extensively with Digi’s DeviceCloud and RemoteManager, and there are a myriad of reasons why I am intensely loyal to Particle.

I agree also. Digimesh + Particles backend is a killer combo.

@Darmitage

Accepting for the moment that Mesh is not ready for primetime, I wonder if Boron is? I am anxious to make the switch from Electron, but I cannot afford to waste time and lose focus if Boron is not ready for large scale commercial deployments.

Currently there are no Sleep modes on the Boron devices.

You also need to verify that the data usage is working in the console now. I hear they just got that fixed yesterday but I have not verified that personally.

The Eseries LTE has everything working now if your wanting the lower power consumption and the LTE network.

[ScruffR]

@RWB

I’m pretty sure the instability issues was part of the reason for the delayed shipment.

Just for that - no. The really didn't get the devices in any earlier. Once they had the mass produced devices on in their warehouse they started sending them out.
That's the reason why we Elites didn't get any devices for testing earlier than the first pre-order customers.

For my feeling it was the choice between the devil and the deep sea.
Chosing to piss of customers for holding back devices in the warehouse and postponing even more or delivering (alleged) "banana ware".
But as it seems while they opted for the latter they still get the brunt for both.

BTW, you are running rc.25, IIRC the Spectra devices (early batch pre mass production - only atandees got) came with rc.15 - so there has still been 10 rc cycles in a few weeks. That's some pace testers need to keep up with.

@RWB

My only fear in speaking my opinnion here is that I rub you the wrong way which then prevents you from helping me with any future Particle related project issues.

No fear!
Disagreement on one front should not have any impact on unrelated topics.
I just know from personal conversations with Particle staff that some of the allegations are just not true and in parts they found themselves between a rock and a hard place with little to do about it.

[rocksetta]

I absolutely love the conversation. Thanks @will

@will

You win points for the entertaining analogy, even if I don’t agree with 100% of the commentary

I have 31 Mesh Devices, but like @RWB I am not even mad at the issues.

Quick questions @ScruffR are you even employed by Particle? Your bio doesn't mention anything about working for the company.

I tend to lean towards solutions, everyone should watch this 40 minute video about OpenThread by Google Nest

OpenThread: Bringing the Internet to low-power IoT devices (Google I/O '18)

It really highlights what a Mesh network is and what the Particle devices will eventually be able to do. Also points out how silly it is to use a Mesh network with only one gateway.

When I first was working with the Core and Photon on my High School curriculum I did not just rely on @peekay123 to solve all my problems (just like 50% of them Thanks @peekay123) , I set up Arduinos for every sensor and actuator that I got working with the Core. I proved things worked on the Arduino and then got things working on the core. What we really need here is to get the devices working on our own servers, using the Raspberry Pi3b border router or Linux cloud or desktop solutions, so that we can prove what works and what doesn't work using other methods. Parallel to us working on that, Particle can work out some of their bugs.

If developers can get the mesh working without the particle cloud by using the OpenThread software then Particle might rethink their strict 10 gateways maximum. (I have 15 Argons. I just want them all on the same network.)

Side note: I think a mesh network maxes out at 32 gateways, but prefers between 11 to 16 putting other gateways to sleep unless needed. If the lead gateway loses connectivity it automatically switches to the next best gateway.

[ScruffR]

@rocksetta

Quick questions @ScruffR are you even employed by Particle?

Nope, I'm not.

[ScruffR]

@rocksetta

STARTUP(System.enableFeature(FEATURE_ETHERNET_DETECTION));

This line has no business inside of setup(). It's a macro that wraps the enclosed instruction(s) in a special function that's called during the boot-up procedure. Having that inside another function means declaring a local function inside another one.

[rocksetta]

Thanks @ScruffR where should it go?

[ScruffR]

Just bellow the SYSTEM_THREAD(ENABLED) line.

https://docs.particle.io/reference/device-os/firmware/photon/#startup-

// The STARTUP call is placed outside of any other function
// What goes inside is any valid code that can be executed. Here, we use a function call.
// Using a single function is preferable to having several `STARTUP()` calls.
STARTUP( setup_the_fundulating_conbobulator() );

[rocksetta]

Done. Thanks @scruff. That nicely places both Featherrwing commands together. I personally don’t like using either of these as I think they add a slight delay in the devices communicating with each other.

[ScruffR]

I think on Xenons the SYSTEM_THREAD(ENABLED) call is currently a must have to keep the mesh communication stable - regardless of whether you use the Ethernet FeatherWing or not.

[rocksetta]

@ScruffR

I think on Xenons the SYSTEM_THREAD(ENABLED) call is currently a must have to keep the mesh communication stable - regardless of whether you use the Ethernet FeatherWing or not.

Can someone confirm the above statement about:

SYSTEM_THREAD(ENABLED)

Is it needed for stability? I would prefer not to use it for these reasons:

1. From Photon days I remember that activating threading caused other issues
   (Note: this call to thread has nothing to do with OpenThread. It is to do with running multiple functions at one time.)

2. My mesh devices seem stable without it.

3. It adds very obvious latency (delay) between calls. Without the above command mesh.publish() is almost simultaneous throughout my devices.

4. Even the Particle Featherwing does not need the above command. (You can reflash a Xenon using the Featherwing even if you don't have a mesh gateway (Argon) active)

I am fine using the statement, just want to make sure that we have to use the statement.