We at bluz are looking for feedback on what the Particle community would like next. We started with Bluetooth LE as the first Compound, and while a new version of bluz is certainly on the table, we are always open to exploring new ones with other technologies (LoRa, Ethernet, XBee, whatever!), and we would love to hear what people think.
So, if you have thoughts on new Particle hardware, or upgrades to our current offering, please head over to the bluz forums or just respond here, we would love to know what you think!
A fully functional version of LORA RFM95W with working Reliable Datagram messaging which I can’t get working past a few hundred feet but get 1 mile range in the rural areas using regular non reliable datagram code.
I like LORA because it has great range and is cheaper than XBEE 900HP Pro modules.
I like XBee 900HP Pro’s because they are FCC compliant and have a more robust feature set.
If you can get all the features working on the LORA modules then I think they win hands down due to the lower cost.
It would be nice to have a breakout and code that allows just the RFM95W module to work with the Photons & Electrons. I’m currently using the Adafruit RFM95W + Atmel 34u2 Feather modules to work with the Photon.
We have been playing around with LoRa and the technology is pretty cool. At one point we were looking into a pure LoRa compound, so only the RFM95 on-board. It would have the same footprint as the Electron. The issue really started to come down to data rates, LoRa is slow. Connection times wouldn’t be quick and OTA updates would not be fast at all, think minutes to hours depending on the modulation settings.
How would you want to use the breakouts? Would they bridge a Photon/Electron to the cloud? Or do you just want to control other LoRa devices from an Electron/Photon but without the direct REST access to the end nodes?
The only “downside” to an Ethernet version (from a market perspective) is that Particle already has a psuedo-ethernet module: the Raspberry Pi. I personally would love an Ethernet version but I imagine sales would be stronger if the Particle Pi Agent didn’t exist.
I’d love to see a Particle compound with Lora or Xbee where the Lora/Xbee nodes would talk to a central receiver (like the Bluz does now) but still be flashable OTA and be able to use Particle cloud functions.
I’m mainly interested in the LORA modules as sensor nodes to get sensor data back and forth to a web-connected Photon or Electron. I do not necessarily need to program them OTA.
Yes, I believe the XBee are better data rate wise, they use a very different technology. Both aren’t terribly fast, however. Normal RF data rates are in the 10’s of kbps, maximum, and can drop much lower. To get the really long ranges, the data rates need to be pretty low and OTA updates become almost unfeasible.
By LoRa Compound, I basically mean an Electron (same MCU even) but with the LoRa radio instead of the UBlox cellular one. The footprint works, we had even spaced it out. So it would have USB, but no other radio technologies on-board for firmware updates.
OTA updates are definitely the hardest part. It would be possible too, so you could actually perform one it would just take a really long time. Connections would also take up a lot of time. About 1K of data is handed back and forth when a device connects to the Particle cloud, which happens so quick on the Photon you barely notice. But on a LoRa compound, it may take a good 30-60 seconds to connect to the cloud depending on the modulation settings.
Would it save space/time/etc to have a single master LORA<->Internet gateway that performed most of the cloud stuff and then you’d have nodes with a LORA radio which talked to that gateway? I can’t recall if LORA has security baked in but if so you could have the gateway to node communication occur over that encryption channel and then the gateway to particle cloud communication occur normally like every other Photon/Electron/etc.
If you need to maintain private keys for each node perhaps the nodes themselves could “upload” them upon connection with the gateway, store them there, and then the gateway itself would do the encryption.
We haven’t built this compound yet, so we don’t have a working version of it. We have done some proof of concept work and that was about as far as we got.
@harrisonhjones It could be possible to do things as you suggest, we went down this road initially with bluz as a matter of fact. There are downsides to it, but it could be one option. I have always been of the opinion that it is best to let the devices have the keys and connect individually, it is the most secure and allows the most flexibility even if it is a little slower.
Yeah, so the LoRa Compound we envisioned would be somewhat similar from the gateway standpoint. We would have an adapter that a LoRa Compound would plug in to, then a Photon/Electron would plug into the other side. This would be the gateway, very similar to the bluz gateway.
Then a LoRa compound out in the field would relay messages over that to the Particle cloud, just like bluz. So the topology would be very similar to bluz. At least the way we envisioned it…
For Home Automation (HA) purposes 128 devices@low power on one gateway are a absoluty MUST_HAVE in my eyes (8 @ 1 gateway is a no-go for this purpose, so I haven’t considered the bluz for that purpose yet, maybe others had the same thoughts…), as the bluz would be a very good device to integrate motion detection on battery power for example, and with LoRa for my understanding this would be perfect.
Another thing on (my) wishlist for HA would be a very tiny (and safe) power supply w/o transformer for 100-240V AC to easily develop and install tiny motion detection,sensors for metering, actors for shutters or blinds to already installed lamps, shutter wall switches and wall outlets to get rid of battery replacement (also for the (Photon/Core, but with the low current of the Bluz this one should be easier to design and even smaller). My current HA is FS20 (see www.elv.de/fs20-funkschaltsystem.html ) , which makes it already possible to have 255 components at 1 house code, with a big variety of actors, sensors and switches, UART control, and that one is already about 8-10 years available, also based on ATMEL. Maybe have a look at their integrated AC power supply, which seems to be robust and safe (have it running for 6 years now), possibly a good start to design a tiny AC shield.
Maybe I’m off-topic with some of my thoughts, just want to share them…
I agree that FiPy is good hardware but IoT is not just the hardware. A major role is well optimized firmware, programming language and Cloud Support.
First big advantage of Particle and Compound devices is support for Arduino Wiring programming language and support for normal C / C ++ and STM32 HAL. This allows a number of existing libraries for various sensors and external components quickly and easily be ported.
Unfortunately for PyCom still no support for C / C ++ and Arduino. When it comes to hardware I still think they are the most suitable programming languages.
When it comes to a complete IoT platform here are:
To @mcoderch’s point, I think the carrier-based technologies are great, but our view has always been that these should be gateways and not necessarily end-nodes. I don’t know how the pricing will work out for these LTE based technologies, but everything I have seen so far so far is a monthly subscription for one device. If that model continues, then they seem better fitted to act as a central hub for many other devices as the costs just don’t scale well.
Of course, there are many different use-cases to think of and some may require many cellular nodes, but I think we have tried to address that hub-and-spoke type case. I think that is why LoRa is quite interesting to us, we can follow the same pattern as bluz but cover much longer ranges.
@mf2105: By the way, it is possible to connect more than 8 bluz to a Raspberry Pi powered gateway. One of our community members created the project and so you can connect many bluz boards through one WiFi or Ethernet powered hub pretty easily. So bluz extends beyond just the hardware gateways offered.
