Hey there @RWB.
In the context of a mesh network, I would argue that Wi-Fi and cellular gateways create additional value beyond a simple Wi-Fi or cellular endpoint (Photon/Electron) that is reasonable to charge for.
The simplest example is OTA passthrough. Gateway devices will enable product creators to target individual devices within a Mesh network and OTA firmware to them. OTA is one of the primary features of our “Device Cloud” service that we otherwise charge on a per-unit basis for standalone Wi-Fi and cellular devices which we’ve decided to charge only at the gateway level for mesh networks.
Additionally, we intend to add features to our gateways to do things like consolidate sensor data at the gateway level before passing to the Cloud and locally distribute batch OTA firmware updates (download once, distribute to many) that will actually reduce data consumption.
Considering the cost of an example deployment of 100 Wi-Fi or cellular endpoints to a product creator versus a single mesh network of 2-5 gateways and 100 Xenons, the total cost is very likely to be lower, not higher.
Hope that helps to explain our rationale a little better.
That does help me understand better the reason for the charge and I do agree that the features you are talking about are worth paying for
If I use an LTE Boron but not in a mesh network will the cost be the same as an electron as far as cellular data and cloud pricing, or will it incur an additional gateway fee?
Seeing the lower cost of the Boron hardware, I’ll likely migrate electron projects to it if the ongoing cost is the same.
If you are not running a mesh off of your Boron there won’t be a gateway upgrade fee (which would only happen when running more than 10 gateways anyhow).
But that is actually already stated in post #2
Thanks, I wanted to be sure I was understanding the pricing.
I would really like to request that Particle stays open to the idea of free, larger than 10 mesh networks for Developers and Educators. 30 Mesh devices at $10 per month ($120.00 per year) does not seem like much for a large business, but for a hobby Developer it might be an issue.
I think there are lots of Developers who would like to work with between 10 and 50 Mesh devices. I am are not talking about 24/7 running networks, more proof of concept, such as my farm suggestion at Ratio of mesh-only (Xenon) to internet-enabled boards (Argon, Boron). Test that the system works and then dismantle it and build something else.
Just saying that in my opinion the backbone of the Particle devices is the forum and the multitude of excellent Developers who spend hours of there time solving problems for others: such as @ScruffR, @peekay123, @bko, @Moors7, @nrobinson2000, @timx and many others. If these people want to work with more than 10 Mesh devices perhaps their should be a way to make that possible.
It is not just the number of networks, which kicks in at 10, but also the type of network.
Pricing kicks in right away for the HA networks. That could put a damper on development since a HA network is inherently more complex and will need more development time, integration and testing to ensure the project gets it right. For the hobby developer, just getting that much hardware to do a HA network is expensive. The fees on top of that will add up quickly.
So I dug around a bit and found this https://docs.particle.io/support/pricing/general-questions/#do-i-have-to-pay-anything-to-use-particle-mesh-devices-
Which has this quote:
All Particle customers will get 10 free gateway upgrades for prototyping and evaluating Particle Mesh. All local communications between mesh endpoints are free.
With 10 free gateways, you could build:
One giant network of 100+ devices
Ten different networks of 10+ devices
Five different networks with redundant gateways (Ethernet + Cellular backup, for example)
Which looks a bit more positive. Does anyone know how to link gateways together to make the giant network, in my case of 30 devices?
You have to wait for Particle to enable High Avalibility networks before this is possible.
Thanks @RWB Any idea of a time frame for this? The course I teach does not start until Feb 2019.
Soon is what Particle says
So I have my 1 Argon and 3 Xenons working at school. I load my simple blink program on a Xenon. The targeted Xenon device flashes pink properly and all the Xenon devices reset properly, but the code does not work.
I think it might be my Photon code so I load Blink-an-LED from particle. Try another Xenon and the same thing. This time I try the Argon and not only does it not blink but same as the above post, the mesh devices do not reconnect until the Argon is unplugged and plugged in.
Also the Argon D7 never blinked. Any idea what is happening here…anyone…
I might connect an Argon without the Mesh and see if it works with the blink program
It’s not reliable right now in many ways unfortunately.
I’ve not had a problem executing code and suspect something else is going on here.
I have had code lock up once during the 3 days I have owned these but I’ve been able to mostly run code fine.
How are you flashing?
I have had inexplicable router, mesh, and pairing issues which I’ve worked through (the router one being - just keep trying different routers until you find one that works).
But code execution, while not “production quality” 100% uptime, has been fine considering where particle is in this product release.
I’ve have had mutiple Xenons freeze up and just stop running.
I just loaded up my trusty photon to check if the LED blink program actually worked and connected in seconds flashed and was blinking fine in about 9 seconds. So I guess I will try an Argon off-mesh and see if it works better.
Thanks @RWB, @cyclin_al and @jtmoderate876 for the replies, kind of feels like we are lone, unpaid, beta testers at the moment. Well actually we are a small group of unpaid beta testers.
Knowing the device works prompted me to look deeper. I tried an Argon off-Mesh and it still didn’t work but then looked at the firmware and noticed this
The default setup is not what was on my device. I think with the photon whenever that happened it would flash the new firmware, but I guess at the moment the Mesh devices don’t auto detect and update the firmware.
Anyway. Happy story my Argon works!
Next. Mesh.publish anyone got a simple program that allows each mesh device to brodcast some information that flashes D7 a distinct number of times. So as I watch my devices and add or subtract Xenons I can see if the Mesh knows they are there or gone.
I just noticed a little while ago that rc.26 was the default on the web IDE. One of my Xenons has rc.26, all the rest are on rc.25, but I can’t figure out how to get the others to the new version. I guess setting up a new Xenon gets the new firmware, but I just did that with a new Argon, but it installed rc.25. I can’t get Particle update to work on the mesh units, and if I flash using the Default, my firmware doesn’t update as @rocksetta notes.
Anyone have an idea on how to get rc.26 on our devices?
At least it seems it must be imminent!
I just saw today that rc.26 has gone. The old method to increase a version was to select the version and install an .ino. (Careful you couldn’t go back to an old version without a full factory reset, not sure if that has changed) If your photon was at the top of the list (default) then every time you installed an .ino the Photon would update if needed. This was a huge problem with bad Wifi, so I would often pick a version and have my class set every photon to that version, then if a new version came out I would test it, switch briefly to default update every photon and then switch to that version instead of default. Only because of bad wifi. The Argon seems to handle my school wifi better than the Photon so that might not be a problem now.
So Last night I tried to setup my 1 Argon and 3 Xenon network and I got the Argon working but the 3 Xenon’s just flashed green. This morning I tried again with the Argon which worked, but the xenons didn’t (just flashed green). I updated and installed a 4th Xenon and not really sure when but the old Xenons started working. Briefly I had all 4 Xenons breathing cyan.
About 5 minutes later all my Xenons are flashing cyan which I think means they have lost the Mesh, Argon stable. Will leave things for a while and see what happens.
Note: Not having much luck with adding multiple Xenons to one Argon with the app, after adding a Xenons it says do you want to add another. This has not worked well for me. If you have an issue it kicks you out of the add another so I have resigned myself to add each xenon individually.
P.S. I would be great if the app allowed multiple steps. On step to update a device, another step to assign Wifi and another step to Add Mesh devices to a mesh network. I am always starting from scratch, have entered my home Wifi password multiple times. Also since most laptops have Bluetooth it would be nice if there was a web or windows desktop app to do all this installing. I seem to remember some kind of web softapp for the photon.
The flashing green Xenon problem is a known issue. Apparently xenon’s have issues with reconnections when the Gateway has a hiccup. I too have had issues with xenon’s flashing green and then resetting one of them allows the network to pop back into action. Hopefully they flush some of that out in the next firmware release.
Sorry I put a bunch of posts here that were meant for my blog High School Robotics Course using the Particle.io Mesh Devices Blog
I will try to get my act together