Sensor 'listening' without altering existing network?


(Sergio Soto) #1

Hi everyone,

A little background:
I’m developing an indoor localization platform based on PIR motion sensors only. The goal of the project is beyond the scope of this thread, but the main idea is developing a solution to ‘tap’ into an existing generic sensor network (i.e. it can be using Zigbee, BLE, Z-Wave) in order to listen to activity on the motion sensors.

The setup:
As mentioned, the idea is to be able to listen to changes in the motion sensors. These sensors can be set up in an unknown but reasonably generic manner. For example, it can be a smartThings hub, a Philips HUE bridge, a Wink 2, etc, controlling them. The objective is to be able to include in this network either a new device (a Raspberry Pi with a zwave/zigbee dongle, for example), or a new hub (SmartThings, RPi with Home Assistant, etc) as a primary hub while leaving the original hub and its connected devices “intact”. Then this new device or hub can transmit all the updates to my server where I perform all the localization algorithms.

In short:
I want all motion sensor activity informed to my server without altering the existing network (except adding a new device or hub)

My background:
I’m an electronics engineer, doing my Masters in Embedded Systems. I have networking experience, but I’m just getting started with HA, zigbee and zwave.

Has anyone got a few pointers on what kind of setup I should be looking at? I wouldn’t mind having to design a (physical) device for this purposes. Since this is for research, let’s assume I have an “unlimited” budget so I can experiment with different hardware.


(Sergio Soto) #2

By the way, I have looked at options on creating a sniffer to monitor all traffic, but that is sort of an overkill since the “user” would be “installing” this setup in his own HA network. Privacy issues aside, I believe there has to be a simpler solution that properly integrates the device/hub to the network without having to “spy” on it.


(Glen King) #3

IFTTT can do this for you right now, without altering a thing in your SmartThings environment.

Recipe: IF “any new motion” (select particular motion sensor)
THEN: record event into Google spreadsheet (or whatever system you like)
Or: use Webhooks to write it into some other system.
OR: send an email saying “sensor q detected motion at (time)”
Etc.


#4

Do you need it to be local? Or can it use the Internet?

As @Glen_King mentioned, there are many HA/security systems which do optionally send some kind of notification when a sensor detects activity. IFTTT tends to be a very convenient way of collecting those. And you can use their webhooks channel to communicate back to your own system, you don’t have to have your own IFTTT service.

However, that is a cloud connection, so I don’t know if that’s what you were looking for or not.

Personally, I would be concerned about the degree of lag in a cloud-based system for something like localization.


#5

Also (I’m also an engineer) I know that in the past PIR – based microlocation systems have tended to fail because people would be shown in two places at once. That’s because of the relatively infrequent reporting period For these type of sensors (done to preserve battery life). For example, most won’t report inactivity until at least three minutes have passed, and even the higher sensitivity ones wait at least one minute.

So let’s say you have one sensor in the living room and another sensor in the dining room next door. It would be very common that you would be reported as being in the living room and the dining room at the same time because you would have left the living room, but been picked up by the dining room sensor before the living room sensor reported inactivity. So you would show as being in two rooms at once.

That works fine for home automation use cases where some overlap is acceptable, such as having the lights turn on when someone enters the room and then turn off after a few minutes of inactivity. The fact that the lights might remain on in the living room for a few minutes after a person walks out is not usually a problem.

Of course the advantage of PIR sensors is that they don’t detect through walls, meaning that the natural expression of a “room” is similar to what a person detects, so you don’t need the usual three or four devices per room to define a region.

Even so, there’s a great deal of work being done on microlocation right now in order to support home automation use cases, and I’m not aware of any that are using PIR sensors because of the slow reporting issue I already mentioned. And of course the big Home Automation push right now is not just for “someone is in the kitchen” but for “Michael is in the kitchen,” another reason most current micro location projects aren’t using PIR sensors.

I understand you may have come up with a way of getting around that, which would be great, I just wanted to mention it.

If you’d like to see what other people in this community have been using with SmartThings in terms of microlocation, see the following:

https://community.smartthings.com/tags/microlocation

(Sergio Soto) #6

Thank you both for your input!

@Glen_King, I’ve been looking at using both IFTTT or MQTT as alternatives. However this involves too much “user configuration” (explained below), I think. I honestly haven’t experimented with this myself yet, since I’m currently researching options before I go ahead and send a purchase order in order to start playing around with hardware.

@JDRoberts the microlocation tag was spot on. I spent all afternoon reading what others in the community have been doing. It does look like some have been trying something quite similar to what I’m trying to achieve. However, perhaps a little clarification on my intentions would be in good order.

I’m working on a project that focuses on behavioural analysis of patients. It’s based on monitoring daily activities and patterns, which are further analyzed in my backend. The activity tracking (read, assumptions on activity based on the location of the person in his/her house) is only a part of a more complex set of imputs to analysis algorithms. In fact, a current implementation exists using z-wave motion sensors and door/window sensors, configured on a custom gateway (controller) which reports any activity on them to the server. In the server, the algorithm takes care of filtering false positives, multiple users, and eventually handling pets and other cool stuff.

It all works fine and all, except for the part where it doesn’t make sense to install such sensors in homes where there’s a pre-existing home automation / surveilance network. It would make more sense to use those existing sensors (without altering their original state/functionality) and just use their output for the behaviour anaysis as well.

Since the goal is not something HA related, I’m not sure if this has been done before. I drew a diagram that possibly explains the ideal setup:

Additional-HUB

The idea would be to keep the HA/Security network “intact” (i.e. keeping the smart home functionality or whatever those sensors and lights were being used for), and just “extract” the sensor information somehow. The existing network is generic, in the sense that I cannot know if they are using a SmartThings HUB, Wink 2, Vera, etc. Therefore solutions involving configuring IFTTT and such would involve too much micromanagement. If this was going to be done once, in one location with one known HUB, that would be my go to solution for sure.

I have thought of two different approaches, but I would appreciate input from the community who has more experience on this. I have hopes that if this project succeeds, the outcoume would certainly benefit the HA community as well! :slight_smile:

The first approach I have in mind is depicted in the image above. Would it be possible to bring in say, a ST, or a HASS RPi or similar into a location and make it the primary controller while keeping functionality on the secondary? This new primary controller should be able to communicate with the server and send activity from the original sensors, as well as optional additional sensors (for example, the house didn’t have enough coverage with the current set of sensors). If this controller could be for example a ST and use IFTTT or an MQTT broker for example it wouldn’t be a problem, as long as it could be “pre-configured” somehow.

A second approach would be developing a device (hardware) that connects to the network as a device (Zigbee), and can somehow listen to the traffic (sort of like a sniffer, but that the user voluntarily adds to his network). I haven’t read much about people achieving this.

Local would be preferred over cloud, but it wouldn’t matter much as long as the objective is achieved.

Any input would be appreciated! I’ll report back any new findings I come up with as well. :grin:


#7

Thank you for the additional information.

The short answer is that no, it’s not going to work the way that you envision. For security reasons, many of the messages sent from the sensors on these types of systems are encrypted: even if you had a sniffer, for example, you wouldn’t know which sensor was reporting just from the message traffic.

Both zigbee home automation and Z wave only allow for one primary Coordinator/controller per network. And by design, all of the other nodes on a mesh network do not have access to the complete network information, only to their closest neighbors. A device on the east side of the house doesn’t even know how many devices there are on the west side of the house, for example. So you can’t simply join the network as an end device and track traffic from the sensors.

Z wave does have the concept of secondary controllers, and a secondary does get a copy of the complete network table at the time that it joined, but it still doesn’t get the sensor reports. Those go to the primary. And if you made your device the primary and the existing device the secondary it can interfere with a number of account functions, including the ability to add additional secondary controllers, some lock functions, etc.

So the issues that you would run into immediately is that if the home has zigbee sensors ( which includes the SmartThings – branded sensors), you aren’t going to get any information at all. If the home has Z wave sensors, you might be able to get some, but at the risk of interfering with existing home automation administration functions. And you can’t just listen for traffic, because you won’t know what sensor it’s coming from, for what the content of the message is. (For example, it might just be a low battery warning .)

Finally, quite a few systems use devices of different, and much less open protocols. Even smartthings has the ability to add ADT dual logo sensors to one of its hub models. These sensors can be used for the home automation rules, such as having a motion sensor triggering lights to come on in a room, but they are using a completely different encrypted network protocol on a completely different frequency from the standard SmartThings sensors.

My suggestion would be that you just plan on deploying your own sensors for your system even if the home already has a home automation system. This is not that uncommon. I myself use a medical monitoring system which has a completely different set of devices than either my home automation system or my home security system. (I am quadriparetic.)

I understand the desire not to have to deploy duplicative devices but unless you are willing to commit to fully integrating with the existing system, I just don’t see a way to get the information that you need, particularly if any protocol other than Z wave is used.


(Glen King) #8

On the duplicative device thing: I dreamed for ages of using the garage controller for multiple purposes. It has three buttons, only one of which is ever used. There is hypothetically an HA system that can utilize those buttons in some limited fashion, but I’ve never known of anyone doing so. So there are those two buttons, wasting away… lol