Bluetooth Mesh

Devices & Integrations
1

Samsung is expected to finally bring its Bluetooth mesh bulb (announced at LightfairJune 2014) to market in about a month.

This is a tip of the iceberg look at what I believe will be Samsung’s HomeKit alternative. Based on the Bluetooth mesh from CSR:

CSR has an interesting history. British chipmaker, nokia’s failing demand hurt them badly a few years ago, Samsung bought them in 2012 to develop chips for their digital camera division. Used the audio chips more, though, they’re in a bunch of Samsung devices.

But when Samsung decided to back off digital cameras, they sold CSR again in 2014.

Meanwhile, CSR got involved in the Bluetooth SIG on Bluetooth mesh, and they’ve recently released it. A direct competitor to the future zigbee 3.0, it also, not coincidentally, should play very nicely with smartphones and Smartwatches.

http://www.csr.com/blog/2014/12/bluetooth-4-2-is-here-but-what-does-it-mean/

And very soon now Samsung will have a hue competitor bulb, but on a different protocol. Not just bluetooth. Bluetooth mesh, which is brand new.

And what does mesh topology give you? Extended range, to begin with. And resiliency when an individual node is temporarily unavailable.

http://blog.bluetooth.com/range-limitation-what-range-limitation-introducing-mesh-networks/

And that fits the SmartThings network model perfectly. :wink: zigbee mesh, zwave mesh, and now Samsung’s smart bulbs will be Bluetooth mesh?

Gee, I wonder what the new Bluetooth antenna in V2 ST hub might be used for? (And some of you guys thought it was just a marketing decision…)

2

If I was Sonos, I would be worried by this too. Bluetooth will allow a slew of MUCH cheaper bluetooth speakers to usurp them.

3

Agreed. Bluetooth mesh as supported under Bluetooth 4.2 is huge in a way most people will never realize, because things will “just work” the way people are always surprised that they don’t.

Sit downstairs in the Livingroom and control lights upstairs from your smartphone or smartwatch without noticeable lag. Microlocation becomes easier.

The ST hub remains relevant for everything that’s scheduled, rules based, or includes devices using other protocols. Which is a lot, of course.

4

So, do you think it is possible for someone to build a bluetooth-to-zwave bridge? Basically, looking at something like an AppleTV, acting as a hub using BT4.2 and also controlling zwave via a bridge device. Could the bridge device make zwave devices “look” like BT devices so it is seamless to a hub that doesn’t understand zwave? Of course, you have the issue with all the device types, etc.

Just a bit of stream of consciousness here.

5

Sure, if there’s a processor in the middle with both antennas. There’s no real interference issue. It’s “just” a matter of cost and complexity. Essentially that’s how the ST hub functions now. Only obviously with different protocols.

There are existing Bluetooth to zigbee bridges used in commercial sensor nets, but those are cheaper because they run in the same frequency. As far as I know there’s no off the shelf Bluetooth to zwave bridges, but somebody could make one. Although I expect an ST type hub rather than a pure bridge would make more sense. Just my opinion, though.

2 Likes
6

I hope you are right. However, it seems a little long in the tooth (pun intended) as this has been the promise since the late 90’s. Adding QOS in mesh networks is a challenge and I wouldn’t underestimate the the head start Sonos has.

7

Agreed for anything that has to coordinate multiple packets, like video and audio streaming. 3 way localized handshakes sound great in theory, but in practice result in a lot of lag as nodes wait for their neighbors so to catch up.

I’m one of those that believe this is best handled by end to end provisioning for specific streams, but obviously that’s another argument for a very smart hub like ST to manage traffic and force delivery in the right sequence. Basically creating de facto traffic classes even if it’s just the scheduler (hub) creating them virtually. And I think you need extra physical repeater nodes to make it work, which increases cost.

Another alternative is separate networks run from the same hub, again creating de facto traffic classes. I know some people argue for those, I just think dedicated nodes are messier than a smarter scheduler, especially in a residential setting where the homeowner may physically move things around.

So, yes, I agree Sonos is ahead of the QOS curve, but these problems have been known for years, I expect they’re being addressed one way or another. We’ll see.

(Translation of engineer speak above: mesh networks by their design don’t offered a guaranteed routing path from hub to end node. “Issue once, try many.” That creates the equivalent of buffering issues: packets arrive out of order, or bounce unpredictably creating odd lag or gaps. The whole point of a mesh network is to give the nodes permission to try alternate routes if a neighbor is temporarily unavailable.

Trying to force a way through for things that must arrive in a specified sequence, like a song, requires either making each node able to recognize different priorities (“traffic classes”) or making a central scheduler VERY smart or setting up a separate dedicated network which is expensive.

This is what keeps engineers up at night–you can design a perfect sensor net installation and then somebody wants to broadcast music on it. :scream:

So, QOS = quality of service from the end user’s point of view, which means messages arrive in a timely fashion in the order expected without lag or gaps or static. A QOS device usually does one of the things described above: prioritizes or reserves resources to improve end user perception of experience.

Mesh networks were originally designed to improve energy use in installations with relatively dumb, relatively cheap devices, many of which were battery operated. The whole idea was that some devices would be temporarily unavailable occasionally, if only because the batteries were being changed. Not an easy match with a use case like streaming music.)

*Edited to add:

And before someone starts trying to code a way around this, the goal isn’t to deliver packets in sequence. We could run a wire and do that. The goal is to deliver high QOS while retaining the cost, energy, and resiliency benefits of a mesh network. Which is what makes this an engineering problem in the first place. :wink:

8

Looks like they’re just now getting started on standards… Bluetooth Smart Mesh Working Group

I’m hopeful that this will enable support for TiltMyBlinds/MySmartBlinds, among other interesting smart products… now we’ll have 3 meshs to maintain and troubleshoot…

1 Like