Bluetooth makes a mesh of itself with new spec

MANET v2?

If I recall from when I looked at MANET, the key challenge is the mesh node nearest to an out point. If nodes in the mesh need to communicate outside the mesh, the edge node with the best external connectivity will take a hit in terms of bandwidth and power resources.

I like the idea of a mesh as it has a fair amount of adaptability and resilience (which is why it shows up in military applications) but you do have to be aware of the specifics. If there's only one node in a position to gateway and you only have battery power, the clock is ticking..

Should be really useful for a Local of Things mesh

e.g. Sensors and control.

So you could have very cheap, cordless, coin-cell-powered, environment sensors in every room, and be able to monitor them from central device and have distributed displays. Also power control and power use sensing could become a lot cheaper than ridiculously expensive and IP range consuming WiFi versions!

I hope that the spec. addresses security too, because even sensors could become a security risk.

O RLY?

I have no idea how well or poorly BT5 / mesh performs in practice, but I do have some extensive experience with another competing wireless standard implemented along all those same principles as described in the article, and boy do they suck mightily in practice. "Only non-battery nodes route" sounds good until you realise 95% of your network consists of battery powered sensors and portable remotes, all of which sleep all of the time meaning you can never read anything from them when you need a current value, you can never change any parameter because it will take hours or days to propagate, and your "mesh" doesn't even qualify as a daisy-chain because too few mains nodes (so you end up installing wall plugs and such you don't even want, just as relays). Oh and you're never supposed to move those, because that would screw up the routing table, and repairing that takes so long due to all the sleeping and meshing that it tends to get scheduled as an overnight operation that by the way doesn't even happen unless the controlling software stack requests it.

Of course, as mentioned, none of this is about Bluetooth - it's possible they somehow miraculously managed to avoid all the same pitfalls everyone else keeps being forced into by the laws of physics and constrained power sources. Who knows, maybe it's positively brilliant...

Wait for V2

Bluetooth Mesh version 1 uses flood routing. As a result performance will be a disaster in a large or dense mesh, or if there are more than occasional packets. It also defines yet another IoT object model, resulting in a closed ecosystem that does not easily allow a mix of wired and wireless networking, or integration with established control systems.

It has clearly been rushed to launch to compete with more mature solutions such as ZigBee, Thread and Wi-Fi.

Version 2 is should be adding an IP transport so existing application layers can be used. It also adds routing tables to improve efficiency (although still reverts to flood routing when the routing tables are out of date). That version may be worth using...

“beacons” that offer one-to-many links

" “beacons” that offer one-to-many links and are often used to provide location-dependent services or information"

I think you mean

" “beacons” that offer one-to-many links and are often used to spam ads"