Presence mesh rssi room detection?

From http://www.smartthings.com/things/ it says that the Presence will only generate away/returned events from the hub - I’m assuming that’s not accurate and that the repeaters (Outlet, powered Motion) will also extend Presence detection?

Looking at the EM357 datasheet (which was mentioned as the ThingModule’s radio - not sure what the Presence uses) I see that it supports RSSI and in fact attaches it to every packet - presumably including forwarded packets - see http://www.silabs.com/Support%20Documents/TechnicalDocs/EM35x.pdf page 4-2 section 4.4 :slight_smile:

  1. What’s the expected interaction between the Presence and repeaters? Do repeaters extend the effective range or does the Presence only talk to the hub?
  2. Can we get access to RSSI information on forwarded packets? I’m not familiar enough with ZigBee stacks in general and especially not the EM357.
  3. Can I integrate my own ZigBee hardware? I’ve got a few $35 “freakDuino Chibi” arduinos with a built-in ZigBee radio and all of the necessary bits to run off of AA batteries.
  4. How, exactly, does the Presence work? Does it continually transmit a broadcast beacon (and if so, what’s the interval)? Does it respond to (secure?) ping-like challenges from the hub (and if so, how often does the hub ping? Can the ping be triggered?)
  5. Firmware upgrades to the various SmartThings…doable if this feature gets implemented later?
  6. Long-term plan for room detection?

What I’m thinking here is that the Presence RSSI to various points in the mesh can be used to give a reasonable idea of what room one’s in - especially with a bunch of outlets and motion detectors at interesting sites.

Relevant to 3 and 4, if the existing setup can’t do it I’d like to use my existing ZigBee toys since they’re cheap and I already have them. :slight_smile: I’d leave them in promiscuous monitor mode and have them notify the hub (via ZigBee) when presence data becomes available ideally leaving the hub sort out what’s going on. (I also have a pile of sensors already integrated with my ZigBee toys and it’d be nice to have one solution for everything.)

5 is a point of general curiosity.

Where I’m going with 6…mapping out a space that’s not designed for positioning is difficult but extremely useful. Motion detectors, in pairs, can tell me whether I’m going upstairs or downstairs. The accelerometer can hint at where people are moving around (and in which chair, etc.) Combining these with RSSI data can allow for some very specific and hopefully compelling scenarios - everything people do today with Scenes but with less, or no, user intervention!

Really though, I just want my loft lights on when I’m up there and off when I go down for the night. :slight_smile:

ahhhh get out of my head! I’ve spent hours and hours thinking about this. I’ve always run into the same issue. RSSI just doesn’t seem to be accurate enough, plus some other stuff. So lets take a crack at your list.

1) What’s the expected interaction between the Presence and repeaters? Do repeaters extend the effective range or does the Presence only talk to the hub?

The tags are extended by the range of the outlets. I vaguely recall discussing this a bit ago to see if that would be removed. I can’t recall the outcome, but I’ll find out.

2) Can we get access to RSSI information on forwarded packets? I’m not familiar enough with ZigBee stacks in general and especially not the EM357.

Possible? yes. Are we doing it? no. A few reasons that I’ll talk about a bit more on #4

3) Can I integrate my own ZigBee hardware? I’ve got a few $35 “freakDuino Chibi” arduinos with a built-in ZigBee radio and all of the necessary bits to run off of AA batteries.

Yes you can! We’re working on support for XBee, plus of course our Arduino Shield. I haven’t had a chance to evaluate or look into the freakDuino, but I’ll order one and let you know if we can play nice together.

4) How, exactly, does the Presence work? Does it continually transmit a broadcast beacon (and if so, what’s the interval)? Does it respond to (secure?) ping-like challenges from the hub (and if so, how often does the hub ping? Can the ping be triggered?)

Every 3 seconds the presence tag reports in with some information. If the hub doesn’t see 3 check-ins in a row, it assumes it is off the property. It can respond to commands as well, like making it beep for example. One of the primary reasons for not using RSSI is its an absolute battery killer. Like years down to days. It’s just not worth it. It’s not the greatest way to tell if you’ve entered a room or not. I’ve been looking into trilateration using RSSI for a long time now. Gave it an initial shot with XBee’s as their RSSI is pretty mature. I found a huge issue with interference. If one of the devices is behind a wall, or next to a microwave, the device has lower signal strength and the calculated area just got a whole lot bigger. You would then have to map out your house and have too many things trying to monitor 1 tag to tell what room you’re in when a motion sensor could do that already.

5) Firmware upgrades to the various SmartThings…doable if this feature gets implemented later?

I’m not entirely sure. It’s not how we do things now. Firmware updates for the hub will be available via OTA update, but not sure about our Things. Let me look into that.

6) Long-term plan for room detection?

Room detection for sure. But not who is in which room.

Hah! I’ve also spent hours and hours…in fact, I completely tuned out at my company’s post-holiday party because I was too busy thinking of ways to build a device that would let me find my fiancee in the large, crowded space.

  1. Not entirely sure whether I want it extended or not - but I’ve got a smallish home and two hubs on the way. Having the option to select what devices will or won’t listen might be nice.

  2. Gotcha.

  3. Excellent! I’m a little soured on shields - it’s usually more PCB than you need or want, you can’t pick the pins being used unless the designer adds a pile of switches or headers, there’s no standard height so it’s a toss-up if they’ll stack (and adding spacer headers usually results in a comically tall stack), and there are three active standards for shields :slight_smile:

Incidentally - nice to see that the ThingShield has a selectable output - however, D2/D3 is kind of an odd choice since those are the only two interrupt pins. D6 for GPIO is a little odd too - hopefully it can be ignored / the trace can be cut - it’s one of the PWMs. Speaking of multiple shield standards, D2/D3 can’t be used for SoftSerial on the Mega or the Leonardo - http://arduino.cc/en/Reference/SoftwareSerial

The real reason, of course, is the $10-$30 tax that seems to be applied when one goes from breakout board to shield. :slight_smile: Speaking of cost, I don’t know what the single unit cost is for a ThingModule or ThingShield - with the module at volume being $10 I’d expect it to be no less than $35 for a single unit and $55 for the shield - I’d love to be wrong! The ThingModule seems roughly as capable as an Arduino for most things - rather than the shield, I’d prefer to see a simple-ish breakout board. The Electric Imp April is a good example — usb for power/programming and a basic LiPo circuit.

The freakDuino is especially compelling to me because it’s got a very flexible radio chip (as I type, it’s rigged up to WireShark and will be used to sniff Iris packets later this week!) and because of the price point - $38 got me the extended kit with antenna and AA regulator circuit. Depending on where you source parts and how much soldering you’re OK with it looks like it’ll take about double that to duplicate it using an XBee, XBee shield, and Arduino - let’s also ignore that all XBee shields are uniquely terrible in at least one way - and the result will be quite a bit larger - the freakDuino is only a little larger than my other Arduinos, not counting the AA battery holder attached to the bottom.

  1. This is excellent information - especially the responding to commands part - although I’m a little bit worried about some of the implications. If it’s just a broadcast beacon (let’s say MAC address) spoofing it becomes trivial - I won’t set it up to unlock my door but I could easily see someone less concerned doing that…hopefully there will be an option for a secure challenge?

Eesh. That’s worse than I was reading but the numbers did seem optimistic. Motion sensors are, unfortunately, useless for me - my dog moves around quite a bit and I don’t move enough to trip motion sensors reliably :slight_smile:

  1. Very interested - given that every device contains a SmartModule, and every SmartModule is a rather flexible thing, being able to hack and extend could be amazing - and, of course, pushing new firmware is just a generally nice bit of future-proofing.

  2. Nice. I really want SmartThings to be the final integration platform for all of the various sensors I have - so far it seems pretty close and I can’t wait to start integrating - wish I’d been fast enough to grab a dev kit.

  1. With ZigBee you can choose which route you want to make a message go through. I’m just not sure how easily that is going to be implemented. It’s a very interesting use case.

  2. We do have the switch that can flip between D0/D1 for the mega and leonardo, to D2/D3 for the Uno and most others. I’ve found its all about preference. SoftwareSerial is ok, its not ideal, but for majority of applications it works great. The ThingModule is a pretty sweet little device, but its difficult to program. That’s the trade off people get between that and the ThingShield is the super duper easy Arduino environment. We have plans to come out with at least one or two breakout boards for the ThingModule for easy wiring. The ThingModule unfortunately may not be available at launch. And yeah, $55 is way more than we want to charge for the shields.

I just started looking into the freakDuino. I want to make sure it can support the ZigBee HA joining process that ZigBee HA devices use.

  1. It’s rough. Another issue I’ve been reading about is more devices to read the RSSI from, doesn’t necessarily make it more accurate. Especially in smaller spaces.

  2. Firmware for end devices WILL be able to update OTA

  3. It’s not something we’re turned off to at all. If a developer comes up with a method of doing it or one of us does it, its something we have no qualms about implementing. It’s just a matter of figuring out how to do it reliably.

  1. Yeah - there’s a certain level of setup that I’m realizing I’m ok with and most aren’t - mapping out the location of every transmitter and figuring out the implications is probably on the far end :slight_smile: (for example, I recently made a spreadsheet with all of the FCC IDs of the receivers/transmitters in my house.)

  2. I realize I sounded far more critical than I wanted to. Whoops! Arduino support is massively important to get people experimenting - I’m just trying to re-purpose what I have (and figure out the cheapest path from here to full automation.)

  3. Makes sense - still something I’d like to do.

  4. Excellent!

  5. Yep - see previous statement about the gap between what an enthusiast will do (and put up with) and the average user is OK with.

…cross-referencing another thread, the Iris devices are AlertMe devices and, as I poke at ZigBee HA, I see that they’re ZigBee HA certified - and theoretically that means they’re compatible - haven’t seen what the ZigBee HA spec dictates / doesn’t dictate.

http://www.zigbee.org/Products/ByStandard/ZigBeeHomeAutomation.aspx - the AlertMe devices are visually identical (and if you dig around you can find out that Iris is an AlertMe rebrand.)

Unfortunately the nearest store closes too soon for me to get them tonight…but that could be a fantastic source of cheap, compatible, gear. I’ll have to go find some actual modules and throw the HA firmware on them, I suspect, unless there’s some really great ZigBee HA protocol documentation out there.

Any updates on freakDuino… any third party ZigBee chipsets, etc.?