Oh I read it… just didn’t get a “warm and fuzzy” about the longevity of it.
Sometimes you don’t need to get emotional but can just take the words for what they literally mean
@ninjatill, I have been strongly advocating for a Photon 2 as I don’t believe the Argon has what it takes for the job (MHz, RAM, Flash, etc.) However, for a LOT of situations, it will fit the bill nicely.
If the Particle future is Mesh then it would stand to reason that future devices support it as well. It also goes to reason that long range mesh “bridges” and longer range nodes should be in their future with suitable adaptations to their billing model.
Particle’s mesh journey is just beginning and a lot of work remains to be done. One thing I know about Particle is THEY LISTEN so suggestions like yours are great to bring up!
This feature would make a lot of my applications, and customer applications, much more robust and easy to use.
Yes, this would be a very valuable capability. I had made a question regarding basically the same functionality here:
However @ninjatill has explained it better, I think. One of my use cases would be better served by a photon network with a local publish, mesh not necessarily being crucial for me. But to be able to extend a mesh network into two locales not within mesh distance but within the same Wireless network would open up a lot of possibilities!
Would something like Multicast help with your use-case?
I also would love to see this local publish feature.
It’s exactly the easy to use local communication feature I’m desiring for a large 50 to 100 room networks that still allow communication when WiFi is down.
The MESH doesn’t look like it’s going to cut it.
Yes. I use UDP Multicast in another project. In that case, all packets are not encrypted. Any other device on the network would potentially have access to the data or be able to join the multicast without authorization. I was looking for a built-in solution that would be a drop-in replacement for Particle.publish() but localized to the subnet. UDP probably would be a component of such a solution. I believe the new mesh devices use secure comms over UDP… it would be great if it was adapted for use on the LAN-side instead of the mesh-side.
They can’t get rid of the Photon until they have something just as stable to replace it.
That stability/reliability takes some real time and a lot of end user feedback to accomplish.
Yeah, I should have read more closely before I asked. I guess local cloud server isn’t being maintained any more? https://github.com/particle-iot/spark-server
Hi particles, I created a product for industry based on the Particle cloud and photon / electron – ubidots API and a radio mesh based on the great products and work by the guys at Low Power Labs (Moteino). For me the real-world problem is range from the Internet gateway (Particle) to the sensor node (Moteino) – and I’m getting over 400 metres (powered) and around 120 metres for ultra-low power battery operated sensor nodes. I’m using 433 Mhz radio – but LoRa will be the next step. I will be looking at a Particle Mesh based product as the security and regulatory compliance stuff is mostly done – and that is important in some markets – but not my current prospects. My product provides (through the particle cloud) two-way connectivity and control of external devices at the sensor node – and conditional (sensor reading thresholds) or un-conditional (operator clicks button on website) responses via ubidots.
OK – this was a shameless plug for my stuff – but on this forum most of you guys are more skilled makers than me and I’m sure you could build your own solution. If so, I spent a lot of time on various platforms and came to the conclusion that for an industrial SCADA-like solution Particle, radio and Ubidots were the best solution for range, reliability and functionality.
But if you want to save yourself a lot of time or have an actual industrial or other requirement - check out my stuff here www.scadascope.com
@DRCO The Particle MESH range is less than your getting with the LORA radios your using now so dont expect it to give you better range.
If you want long range certified radios you can also use the Xbee MESH radios. There is a Particle library for them already.
The LORA RFM69 radios can give you 1 mile urban city range but the radios do not have all the certifications like the XBee radios do.
Yes, I did some prototyping with X-Bee and for the cost I found them no better than RFM69HW and they were power hungry little guys. I can sleep my nodes and draw around 18nA - and still wake them up reliably at over 100 metres. For most of the applications I’m targeting that’ll give be over a year in-situ on three AA batteries. I agree the regulatory stuff is an issue - but have few work-arounds on the broadcast power that can see me operating under the rules in Australia - US is probably another matter. Regarding LoRa - there are a couple of SEMTECH- based platforms that should pass certification. The big problem is the slightest change in configuration or addition of connected devices voids the certification, including housings or antennas.
My view on an all Particle network is that while the MESH architecture is good and a single platform is a more solid base for a commercial product - they should make a LoRa- based low power node. Range is, in my experience, the absolute most desirable attribute in IoT applied to industry or commercial applications and while the MESH is solid you would need way too many nodes to achieve any workable range and that is just too many points of potential failure. I get it that the network heals itself and reroutes traffic in a single point of failure but if you are changing batteries, maintaining solar or supplying power to hundreds of units it is just unworkable.
The particle OS is open source, correct? Would anyone be interested in trying to adapt udp/TCP communications (whichever would be better for the majority) into a local.publish setup? I may be over simplifying this, and its certainly beyond my knowledge and skill level, but the framework for any .publish should be in the mesh or particle firmware, and adapting that to what is known about udp/TCP. Anyone think this is doable?
Theoretically it could be done, but a lot of the low-level OS stuff is way over my head.
Is putting a feature request in the forums enough, or is there a more official Particle feature request procedure?
It depends, I guess. Github would be a great ‘official’ place to request something like that, but the forums are great to discuss ideas first. Generally the forums are read by Particle as well. If not, there’s always the Elites who can pass things on to Particle. Trust me when I say we’re community advocates and are great at nagging the lovely folks over at Particle to get things done
Unfortunately, we’re not the ones who can make decisive calls regarding strategy and planning. That’s up to Particle, and more things weigh in there other than the wishes of those on the forums. That said, if we -the Elites- feel like something should be prioritized, you can bet on it we’ll make sure to mention it every so often. That’s still no guarantee, but surely doesn’t hurt the case.
It’s a bit of a double edge sword though; as elites, we see both the community, and a behind-the-scenes look at Particle, so we’ve got a reasonable idea what’s going on in either. With that in mind, we personally filter out things we may or may not push for, a great example being this very request. Sure, it would be awesome to have new feature X for a select audience that would make use of it, but I wouldn’t prioritize it over stability/reliability improvements that would benefit literally everyone. At that point we accept that other items have priority, and keep that feature request on the back-burner, to be discussed again as soon as resources allow, rather than continuously annoy them with it.
Hope that makes sense and provides some insight. TL;RD: Discourse for discussing, GitHub is more ‘official’ I suppose.
Undoubtedly this isn’t as high a priority as the stability items, and getting functional parity for the mesh devices with the Gen2 ones, and and I wouldn’t buck for it being that. But I certainly think that having a Local.publish would greatly increase the utility of Particle devices, and also that of the Mesh devices specifically, by enabling an extension of the mesh over greater distances within a facility, or communication between two separate mesh networks. More utility translating to greater adoption, I’d expect, and a leg up in functionality compared to the competition.
I have no idea how much is involved in satisfying a request like this, but I’d think that it would be closely related to the Particle.publish and Mesh.publish. I don’t mind how it comes to the attention of the powers that be, but would very much like to have this feature considered and hopefully at some point added into the features.
I’m bumping this topic, now the Mesh is officially a dead product. I’m using mesh.publish() on a number of implementations, and a local.publish() with similar functionality would be huge.
GitHub issue/feature request created - https://github.com/particle-iot/device-os/issues/2013