Cisco Is Abandoning the LoRaWAN Space With No Lifeboat For IoT Customers 37
Cisco is exiting the LoRaWAN market for IoT device connectivity, with no migration plans for customers. "LoRaWAN is a low power, wide area network specification, specifically designed to connect devices such as sensors over relatively long distances," notes The Register. "It is built on LoRa, a form of wireless communication that uses spread spectrum modulation, and makes use of license-free sub-gigahertz industrial, scientific, and medical (ISM) radio bands. The tech is overseen by the LoRa Alliance." From the report: Switchzilla made this information public in a notice on its website announcing the end-of-sale and end-of-life dates for Cisco LoRaWAN. The last day customers will be able to order any affected products will be January 1, 2025, with all support ceasing by the end of the decade. The list includes Cisco's 800 MHz and 900 MHz LoRaWAN Gateways, plus associated products such as omni-directional antennas and software for the Gateways and Interface Modules. If anyone was in any doubt, the notification spells it out: "Cisco will be exiting the LoRaWAN space. There is no planned migration for Cisco LoRaWAN gateways."
Re: (Score:3)
Probably agriculture, things like soil moisture sensors, irrigation control gates, silo methane detectors, stuff that needs to run for months without being charged but only get queried once in a blue moon. There may be other uses, but that's what I'm aware of.
Cisco introduced devices ~2018 (Score:2)
Here's a cisco blog entry about Cisco promoting LoRaWAN from Oct 2018 and Wikipedia tracking the specification back to 2015
https://en.wikipedia.org/wiki/... [wikipedia.org]
https://blogs.cisco.com/govern... [cisco.com]
October 29, 2018
IoT Evolves: the coming of long range WAN
Michael Harttree
Re:What are common applications for LoRa? (Score:5, Informative)
This is really the point. I'm in the IoT industry and more specifically Smart Home because that is where the money is. A few years ago, the promise of IoT (Internet Of Everything - woohoo!) was that you'd be able to hook up everything to the Internet and get data from it. "Data is the new oil!" was the mantra. All you needed was to come up with a radio technology to enable it. Semtec had LoRa and built an alliance and org around it and vendors dutifully brought out radios, receivers, dev boards, all to support it. The mobile wireless guys came out with Narrow Band LTE - user the gard band of LTE and make it cheap! But.... yeah, you've guessed it, technology in search of a business model. It all _sounds_ like it should be able to make money, right? Just think of all those farmers wanting rainfall data on their crops, or pipeline makers wanting acoustic readings of their pipes crossing the tundra, or um, home owners wanting sensors all over their house, or electricity meters, and, er., well, all of these are good applications, but they are onesie-twosies and super low volume. Compare it to light bulbs. Tens of thousands of lights are sold every week in the US. For some of those applications, you'd be lucky to get a few hundred deployed, and yet, the effort and cost to do so, would run into the $100k's just in labor alone. I'm not surprised that Cisco is dropping out. I bet they sold, phew, maybe hundreds of their gateways! Perhaps they were really good at sales and sold thousands! You get the idea.
The radio tech does still live on, and is used as one of the sub-gig radios of choice, but the whole LoraWAN thing is dead IMO. No money in it.
Re: (Score:3)
No points today, but mod up.
Thanks for a meaningful and insightful comment from someone who knows about the subject.
Re: What are common applications for LoRa? (Score:3)
I wouldn't say it's dead, but companies like Cisco outprice themselves from the market.
The applications are limited, but could still be valuable to users like monitoring water levels in wells and send alarms when it's too low or too high.
Low bandwidth long distance multiple measurement points data where it's too expensive to have a 4G/5G modem at every point and WiFi is insufficient.
Re:What are common applications for LoRa? (Score:5, Insightful)
Smarthome IoT has nothing to do with LoRaWAN. Those were never use cases designed for. LoRaWAN was designed for localised wireless telemetry of mass devices across a facility. It has very real use cases not met by any other system (specifically the idea to keep things in house is why places like refineries and chemical plants put up LoRaWAN towers instead of relying on LTE/5G). This isn't consumer stuff, it's sold at insane premium. You want a temperature sensor? That'll be $400 thanks.
The bigger problem with LoRaWAN is other industrial wireless applications got cheaper and more capable. The idea of a LoRaWAN gateway that supports 1000 devices made sense when the ISA and Emerson were shipping gateways with a device limit of 50. That's now changed and I see little reason for LoRaWAN to exist. It was always a niche product that unfortunately came too late.
The LTE/5G case was also not "in search of a business model". They have one already. There are millions upon millions of devices deployed. In some countries all smart meters work on it, in other countries private companies use it for low power telemetry. It's used for monitoring everything from street lights, and storm water lift pumps, to the coffee machine in your office. Heck 5G's biggest changes didn't actually care about *you*. Your smartphone getting faster was a side-effect. Their most important change was the way devices connect to access point allowing as the high adoption of LTE / Narrow band was crippling access points.
Re: (Score:2)
>> technology in search of a business model.
What is the missing link is to have a standard way to share internet connection out of the box without entering passwords and the like.
At best openly without access controls (yes, that makes it open to abuses, but not a problem if limited to 10% of your connection.)
Re: (Score:2)
LoraWAN isn't so much dead as just entering the late stage where high profit margins aren't possible. The hardware is cheap so companies that want high margins are getting out, but there is still plenty of support from others.
Personally I've been using CC1101 for domestic smart stuff, but only because I already had experience with it from years back when I used it professionally. Now there are cheaper and better Lora modules I'd probably use those if I was starting over.
Re: (Score:2)
Thanks for the info. Essentially this is just another instance of "never trust a hype".
Re: (Score:2)
I remember when this was trying to be sold in industrial settings - a lot of "new" vendors popping up with new sensors. all looking for a problem to solve. Every client i worked with immediately dismissed it based on pure security concerns and overall lifetime costs being more than just wiring in a new instrument in the plant.
Re: (Score:2)
I work for a small company that sells all kinds of IoT equipment and development services in this area. LoRaWAN has become the largest income source, even on project where other types of IoT would make more sense, like remote controlled electrical sockets. So I guess the reports of its death are greatly exaggerated.
Re:What are common applications for LoRa? (Score:4, Informative)
Meshtastic uses it, so you can use it for "SMS" off grid. A limitation is in the gateway space though... but the "no money in it" issue is a factor.
Re: (Score:2)
While true, Meshtastic is more or less lying in its own name. It's not actually a mesh. The "routing protocol" is a shouting match; there is no routing; it's even worse than ALOHA. It's simply not possible to build reliable networks with Meshtastic because of this as multi-hop paths will randomly diverge from one another. In an OSI analogy, it's got layer 4/7 running directly atop unreliable layer 2 domains; there is no layer 3.
LoRAWAN does proper mesh routing but is just a bureaucratic nightmare. It's very
Vending machines in Japan (Score:2, Interesting)
They keep track of their inventory and send those details over a LoRa network back to the distributors.
Re: (Score:3)
It least in Europe it's used a lot in Smart City applications for sensors. Things like environmental sensors (weather, water levels, etc), parking sensors, smart metering... It works very well for that.
Re: (Score:2)
As a hacker I can give one application. I like to grow chillies and gardening and have ausmale hothouse out in the garden. In there I have 2 Feather boards connected to temperature and humidity and light sensors.
I tried WiFi but the range to my hotspot means reception is very flaky. I could jack up the signal strength but I am not keen on making my WiFi Signal available to half the street. So LoRa worked well here. In the cellar I have a Raspberry Pi with a LoRa hat that picks up the sensor readings and MQ
The IoT protocols (Score:5, Informative)
Bluetooth / BLE - supported by smart phones. Limited application layer, limited range.
z-wave - decent network layer, good application layer, used to have a very good industry trade group. Almost all hubs though required the hub maker and the device maker to have communicated before the device could be fully controlled by the hub. Not a requirement of the standard but the way everyone did it. Now controlled by the Connected Standards Alliance.
Zigbee - good networking, good application layer with the by far the most defined functionality. Most interoperability of all standards. Device makers and coordinators (hubs) need never even know about each other before the device can be controlled. The Zigbee Alliance was the worst trade group imaginable. Documentation extremely hard to read to know what the protocol does, testing and certification a pain. Alliance would regularly throw device makers under the bus. Zigbee Alliance is now the Connected Standards Alliance
Thread / Matter over Thread - Currently has the most hype and marketing. Thread is a beautiful networking protocol that solves a problem no end user wanted solved. (Thread effectively puts all devices on the internet which means all device makers have their devices call home and try to have them controlled by their servers. It allows vendor lock in. ) Matter is essentially the ZigBee application layer but with most of the faults of ZigBee fixed. Unfortunately standard is now in bureaucratic hell. It is getting bloated fast, with multiple ways to do the same thing being added and the number of features still only a fraction of what ZigBee supports. There is also a degree of disregard for device makers in favor of companies that want to control the devices. Investors believe there is more money in controlling the devices so there are more voting member trying to control the devices than make them. (note zigbee 2.0, the predecessor to Matter, was plague by this problem). Matter is developed by the Connected Standards Alliance.
Re: (Score:2)
Re: (Score:1)
You can always have a local server controlling the devices, on the same network, No internet access even required.
Even, you could have a private internet-facing server to control devices at different sites. Or have something form of tunnelling to connect different sites.
On the device side, you can pair a wifi modem with a micro controller, or even use something like the ESP32, where your application code can live next to the WIFi/IP
Re: (Score:2)
WiFi does not necessarily need to call the manufacturer's server though. You can always have a local server controlling the devices, on the same network, No internet access even required. Even, you could have a private internet-facing server to control devices at different sites. Or have something form of tunnelling to connect different sites. On the device side, you can pair a wifi modem with a micro controller, or even use something like the ESP32, where your application code can live next to the WIFi/IP stack.
It doesn't have to, but many do. If you're familiar with Tuya WiFi devices you know all too well how shitty it is to have a smart device that has to connect to an API server in China in order to work. Even with Local Tuya and TuyaLocal these devices will end up failing and need to reconnect to the API server eventually. I avoid WiFi smart home devices at all costs (nope, will never use Shelly) and prefer either Zwave or ZigBee because there is absolutely no possibility of them having a secret backdoor insta
Re: (Score:3)
Matter works local only, it doesn't connect anything to the internet if you don't want it to.
WiFi - the application layer is Matter or MQTT.
LoraWAN - the main benefit is range, which can be tens of kilometres. The idea was to have people running their own LoraWAN gateways all over the place, and optionally handling traffic on behalf of other users by providing an internet connected gateway. You can use it locally as well, of course.
Lora is also very low power, so ideal for battery/solar powered sensors.
Cisc
Re: (Score:2)
Matter allows local-only control. But your claim that "it doesn't connect anything to the internet if you don't want it to." is both true and not.
Matter doesn't promise to allow you to turn off other cloud connectivity. Worse, it doesn't even promise to provide all functionality.
Say you have a switch plug module. It has a switch on/off and also monitors power usage. The device may expose the switch but not the power usage data.
And there's nothing in the standard that forbids this.
The only good thing I can t
Re: (Score:2)
Question: hasn't BT ever gotten the long range version implemented in IoT world?
I've long used long range bluetooth intercoms. We're talking around 1km range. Current versions are advertised with about 1,5km range.
If no, why hasn't it?
Re: (Score:2)
Z-Wave - The Z-Wave standard is controlled by the Z-Wave Alliance that works with the Connected Standards Alliance, the CSA does not list Z-Wave as a standard it controls. All Z-Wave semiconductors are manufactured by Silicon Labs. All members of the Z-Wave Alliance develop or purchase products using of Silicon Labs technology.
Re: (Score:2)
For z-wave, you can just get a radio dongle and run a software hub like Home Assistant. That helps a bit with compatibility as you aren't waiting for a big company to release a firmware update to support your device.
Re: (Score:3)
Thread / Matter over Thread - Currently has the most hype and marketing. Thread is a beautiful networking protocol that solves a problem no end user wanted solved. (Thread effectively puts all devices on the internet which means all device makers have their devices call home and try to have them controlled by their servers. It allows vendor lock in. )
Thread is an IP6-based transport protocol that runs on top of the local radio mesh 802.15.4 link layer standard.
Matter is strictly an application-level protocol that can use Thread or TCP as a transport layer.
By no means do you need to put Thread devices on the internet. You don't even need to bridge Thread/Matter onto TCP/IP if you don't want to, although that is a common use case. Even if you do run a Thread/Matter WIFI bridge, you can absolutely run a local Matter TCP/IP hub. If a Thread/Matter device
Re: (Score:2)
"then I just wouldn't buy that device" assumes they tell you that before you buy it. Which they won't b/c it's not essential information, as far as the vendor is concerned.
So you'll buy it then hope that they take it back w/o any restocking fees... after all, you're not returning it for being DOA, but rather in the category of "buyer's remorse".
Re: (Score:2)
"then I just wouldn't buy that device" assumes they tell you that before you buy it. Which they won't b/c it's not essential information, as far as the vendor is concerned.
So you'll buy it then hope that they take it back w/o any restocking fees... after all, you're not returning it for being DOA, but rather in the category of "buyer's remorse".
That's true of any of this stuff though, be it Zigbee, Z-Wave, or Thread. A device maker can always make a device functionally unfit for purpose by making it have to phone home to function or to activate it. It's not a unique problem for Thread/Matter devices.
It would be nice if there was a watch dog group that gave out a seal a manufacturer could put on the box that says "Certified for full local control", but AFAIK, there isn't, so you just have to do your homework a bit. If it is something I'm going t
Re: (Score:2)
Zigbee and ZWave cannot phone home. Further, I've never ran into such Zigbee or ZWave device that requires extra work to pair. Yes, Zigbee devices are hit or miss re complying with the standard clusters/attributes.
Re: (Score:2)
Zigbee and ZWave cannot phone home. Further, I've never ran into such Zigbee or ZWave device that requires extra work to pair. Yes, Zigbee devices are hit or miss re complying with the standard clusters/attributes.
Well neither can Thread, but a device can require a proprietary app or an authorization obtained from a cloud service to become fully functional. So in that case the path is device -> local radio mesh -> hub -> app -> cloud. I was responding to FeelGood314's comment above that. "Thread effectively puts all devices on the internet which means all device makers have their devices call home and try to have them controlled by their servers.". My point is that any ostensibly local protocol can be
Wonder if this is fallout from the NextNav thing (Score:2)
https://www.eff.org/deeplinks/... [eff.org]
ESP32 (Score:2)
Ultimately Cisco would have to compete with a $40 ESP32 which by 2030 will have more features than the Cisco offering, most likely.
They are probably smart to exit the market.
The folks already doing open source LoRA are unaffected.
Same mistakes get made over and over again.
Re: (Score:2)
ESP32s don't have a LoRa radio, meaning they can't reach nearly as far as LoRa can...
Re: (Score:2)
But there are ESP32 based LoRa solutions, currently at ~$50/node.
Re: (Score:2)
Also, it's LoRa for the radio space. LoRA for the machine learning space. Get your context right, geez! :-)