I've purchased 2 sets of estimote dev kits, unable to get any consistent enough beaconing to do anything useful related to home automation.
I'm not alone, a few of my friends also play with home automation and none of us can get any given estimote among dozens to beacon reliably. They all work, just maybe 10% - 30% of the time.
Is this your app, the beacons, the technology, bad expectations... what could everyone be doing wrong that nobody can get a better than coin toss chance of detecting proximity to a beacon?
Will this mesh tech make any difference?
// FWIW, seems to be all beacons, not just yours, and all apps, not just yours. It's like the concept of expecting reliability is broken.
I have had 5 different ideas for projects just looking at your site. I currently work in an education company with little one's and there are a few ideas that would be awesome in a 3-5 year old age group. It would also be great as a research tool to figure out where children are spending their time in the classrooms during the day.
So... is this broadcast/observe and trickle, or true connections? From the tree demo, it looks like trickle with a limited observe window to limit the power consumption. If it were connection I would expect the tree to light up a little less randomly.
Of course, beacons do not keep the persistent connection since that would drain too much battery. But they are not synchronized, so you can pass data to one edge of the mesh and it will be passed with some latency to another edge - like on the tree video.
If you watch carefully the tree video it's like a chain reaction since more nodes are influencing other nodes in the range.
So yeah. Sounds like nothing new, and there is definitely severe limitations in latency and power consumption in using these methods to do anything except change some settings or toggle GPIOs. Not revolutionary, but definitely cool that you were able to reduce power consumption to run on batteries unlike other implementations that leave the receive on 100% of the time.
Any one aware of the technical details of how this was accomplished?
Is listening for other BLE transmissions low power enough that it can be done while keeping the claimed "several years" battery life, or is there something extra going on to limit the power cost of listening?
Is the protocol between the beacons themselves actually BLE in the mesh case? Or do they just expose that to phones?
Are the beacons establishing BLE connections for the mesh, or are they just taking advantage of announcements (which would likely allow avoiding some power consumption as long as the message is small)? A mix?
Beacons use only BLE to talk to each other; there no Zigbee or other connectivity technology. That way both phones or other beacons/BLE devices can inject data to mesh.
What specifically is a "world's first" here? Just curious because I know a hardware designer who designed battery-powered Bluetooth (not necessarily BLE) mesh networks for factory-scale alarm systems two years ago. Not sure if they ever made it to production, but I wouldn't be surprised. That system only required servicing once a year.
BLE (Bluetooth Low Energy) is supported these days by all modern phones and we haven't seen mesh implementations on top of BLE that would be low-power. There are other non-low-power BLE implementations for example for lightbulbs, but it's not useful for beacons since they need to be wireless due to operational costs of deployments at scale.
The thing about CSR BLE mesh is, they differentiate between "active" and "passive" members, and the "active" members use a lot of energy. Mesh in Estimote Beacons is the first that's truly sustainable on battery power alone.
We just released a new firmware to support mesh networking with bluetooth beacons - you can read more on our blog: http://blog.estimote.com/post/153812538740/introducing-the-w...
Happy to answer any questions here! : )