This would be EXTREMELY helpful, but I can’t figure out if smart things can do this, but if it can’t, is there any way anyone can write a script that’ll make it work?
I need to be able to detect smart things hub’s proximity from other ‘things’ that are connected to it. This way I can reference where a personal presence thing or a smartphone that has the app installed on it and where it is in reference to another ‘thing’. With this I can identify what things are where, and can automate based on proximity. For example, if I’m playing music through a speaker in my room, I need to be able to move the sound to play to a different speaker based on where my personal presence device is in the house in reference to other ‘things’.
I don’t believe there is anyway that you can do this right now. The hub cannot get anymore detailed information from your smartphone other than its general location. I have been working on a beacon based solution to do this, but it keeps getting put on the back burner.
This is called “microlocation,” and as @obycode said, at present the only practical inexpensive (meaning under $500) way to do this is with iBeacons, such as those from Estimote. But those are bluetooth based and don’t at present work directly with SmartThings.
In the general maker community a lot of people are doing some of this with Kinect and various hardware add ons from Raspberry Pi to Arduino, but the costs tend to be upwards of $700 per room and it can get really kludgy.
RFIDs can also do a form of microlocation, but there you usually have to be very close. Good for doors and light switches, but not what’s called “occupancy detection,” meaning knowing who’s in a particular room.
There is considerable speculation that HomeKit will bring microlocation into home automation, but not until late 2016, and that’s all just guesses based on the HomeKit database, which divides rooms into zones.
So we’ll see. But Google microlocation and you should find a lot of discussion.
p.s. SmartThing’s two methods of presence detection are phone based geolocation and the zigbee presence indicator. Geolocation typically has a radius of 500 feet as a minimum. The zigbee indication doesn’t know direction, the hub just knows whether it can connect to it or not. That’s typically a radius of 50 to 75 feet, but can’t tell you what too. It’s in, just that it’s within range or not.
I’m not sure that this is entirely off the table though.
Each item uses a z-wave to communicate (I think), and that wave has a specified strength associated to it. Just like you can triangulate the exact location of a wifi network you should be able to do the same with triangulation techniques for z-wave devices.
I think it’s possible, we just need to dig a little deeper into it.
Possible yes, but triangulation requires at least 2 fixed reference points to begin your calculations for 2D space. Once you move into 3D space you will need more. Currently, at best, you would only have programmable access to the hub, the other devices aren’t going to be able to provide any information.
I’m not sure exactly how it works, but I’m thinking it’s attached to your phone. If that’s the case then couldn’t that be tied in with smartthings indirectly? With a simple integration module I think it would be possible to use redpin to do proximity detection at least with multiple phones or smart devices and then indirectly tie smartthings to them. Kind of like a workaround.
you cannot use Redpin to microlocate your zwave devices
you could possibly use Redpin to microlocate your phone while you’re walking through different rooms in your apartment, but it will be more reliable to do this with Estimote ibeacons, which could then be linked via IFTTT to SmartThings
I like to think of ways to get around potential problems. Here’s my solution to this issue:
programs like redpin operate by use of wifi networks and triangulate based on how strong the signal of the receiving device is to one or another wifi hotpoints. That’s obviously not how smartthings works, but that doesn’t stop this from working.
Why do I say that? Because tools like Tasker exist, which could potentially tie redpin to a specific service…say…sms, or pushbullet. Guess what? Both SMS and pushbullet connect to IFTTT. What does IFTTT connect to? It connects to all of my smartthings devices. Therefore, redpin is connected to smartthings, if I want it to be, even though it operates on a totally different network.
So long as my wifi hotpoints are in the same place as my desired smartthings devices, then I can simulate a fully functional proximity detector.
If you want to put a fully functioning wifi device next to every fully functioning zwave device, sure, you can, but you just more than doubled the cost of your network in terms of money and energy draw. ( Zwave and zigbee exist in the first place because wifi is expensive.)
If that’s what you want, I’d just go for an all wifi network from the beginning.
Ok, so who wants to start a kickstarter and make a team to make a zwave proximity detector that works with smart things? I mean if no one else is getting off their butts to do it, clearly a lot of people want this (just from my searches alone in the past few hours it shows a HUGE want and need for this tech), then we could do pretty well off if we could bulid it ourselves.
It also helps to understand the problems that have already been solved.
Zwave and Zigbee are both mesh network protocols They were designed to solve an existing problem–network devices were too expensive, both in terms of money and energy draw. And when one went offline, the whole network went nuts.
So they are intentionally meant for installations where most end devices are pretty dumb, pretty inexpensive, and sleep a lot.
The network doesn’t worry if any one device goes offline for awhile (it might be just getting new batteries). There is no way to force sequencing.
Messages get passed around from neighbor to neighbor, for up to four “hops,” which greatly extends the potential physical range while still keeping the individual devices stupid, cheap, and low powered.
All of which is terrible for microlocation. You don’t know where any one signal is likely to travel, and manufacturers intentionally keep the devices stupid so they don’t cost much.
But while terrible for microlocation, it’s great for home automation, where we want to keep both total costs and energy draw down.
Microlocation is already solved using iBeacons. That’s what they’re for. But there’s no Bluetooth radio in the V1 SmartThings hub.
One has been announced for inclusion in the V2 hub. So there’s really no point in trying to do something with zwave that zwave is implicitly unsuited for when the V2 hub is already announced with a more appropriate technology. By the time your kickstarter campaign was done, it would already be obsolete.
If you can’t stand waiting, I’d switch to an all Wifi network. It sounds like WiFi is a better fit for the models you’re considering, and since you’re already investing in a very sophisticated central server, you’ll have a lot more options with WiFi than someone who’s trying to run home automation from just the ST hub and a phone. Just a thought.