Sensor Polling or Negative Response

[fillibar]

It has been noted before that there should be a way to identify if a sensor is not reporting anymore or has not reported in a specified timeframe. I have this problem with a motion detector that does not want to mesh (it always says motion, always) and a window sensor I found had a dead battery (but I never got warned about it). These scenarios should be something that can be resolved.

Now, a related issue has made some big news. I would say this should be another reason for Securifi to look into solving this and maybe setting themselves apart by being proactive about it (before it happens to a Securifi user/system).
http://arstechnica.com/security/2016/01/comcast-security-flaw-could-help-burglars-break-into-homes-undetected/

[SecureComp]

Old news.

Any system depending on electronic "links" is subject to polling issues.

The use of battery supported sensors is a choice, so is the use of wireless sensors and the associated risks.

That said, not a big deal to automate polling of "protection" sensors when in the Away or Armed Perimeter modes.

In fact, with the SDK or the new WS API, pretty easy to do.  It will be a battery killer, but it will work. Can even set an adjustable polling interval.

[fillibar]

Understood risk but I think this is a prompting for the industry, and in my request Securifi, to start building in ways to mitigate that risk in a way that the customer can readily deal with ESPECIALLY those that are not savvy enough to manipulate it in an SDK.

Having a set of polling options (they can even be defaulted OFF and have a warning message that it could drain the batteries) would be acceptable. In the case of my motion sensor... it is not using batteries. It has them as a backup but has a wired power as the primary. It is just too dumb apparently to mesh properly (and there is no option I know of yet to "repair" or try to get it to do otherwise).

But if you have a device that regularly reports back, even if it was every 2 hours, you SHOULD know if it did not report in when expected. If that model allows for changing the polling interval make that possible to manipulate. Yes, you could look at the history and figure it out manually... but the whole point of this stuff is making it "smarter".

[SecureComp]

Understood.

I have a problem with the article as it's a hyped attention grab by both the security firm and Ars Technica imho.

I'm going duplicate the test with some foil and a couple sensors and look at the times to re-integrate and report appropriate/proper status.  The issue is getting the correct status upon re-connect as well as paying attention to communication status while in Away or Perimeter Armed mode.

The risks with Wireless Security Systems and Hardline based Notification Systems are nothing new. By the same token, industry needs to work the issues, improve and innovate to mitigate risks. Yours is a good suggestion.

[fillibar]

Oh, totally an attention grab. Comcast was chosen because they are a big name, and most people hate them anyways. Time Warner uses a similar system, Lowe's Iris would be susceptible... Etc...

Heck, a wired one could have the cable cut if an intruder was that focused on it. Which also leads to a key point, whether they are prepared or opportunistic. Nothing would stop someone that is preparing to break into your house and planning it. Not much is likely to stop an opportunist EXCEPT deterrence. If it looks too tough or risky, they move on to your neighbor. If they decide it is yours, they are in.

All that being said, no reason not to try to mitigate it.

[multisystemelectronics]

A remote sensor is coupled to the host object and adapted to detect a target object...

[d.kiran]

In fact, with the SDK or the new WS API, pretty easy to do.  It will be a battery killer, but it will work. Can even set an adjustable polling interval.

@SecureComp, how do you use the WS API to poll a device though? I see only GetDeviceIndex and that gets it from the Almond not the device itself.

[rpr69]

@SecureComp, how do you use the WS API to poll a device though? I see only GetDeviceIndex and that gets it from the Almond not the device itself.

Same here, I've read the API pretty closely, and I don't see the capability to poll a device directly.

[SecureComp]

Think of it as "virtual" polling.

Naturally you'll be getting the response from the Almond, you're communicating at the application level.

No you won't talk directly to the device but you can throw something at the device and get an expected response. The info will vary from device to device obviously.  Think of it as a PING ECHO RESPONSE REQUESTED kind of thing. Now what you throw at the device will matter.

For example, if you want the status of a Light that is On, you can't just check and see if the light is on as reported by the Almond. You would send a DIM adjustment level to lower it 1%, no real impact on your lighting situation, and you should see an INDEX of the MULTI LEVEL SWITCH transition from 255 to xxx. That confirms the communication from the Almond to the device and from the device back to the Almond.  So you have to actually ask a device to do something or do something to the device as the case may be.

Other devices, such as the Home Energy Monitoring systems have configurable reporting features and regularly report power stats and you can kick an exception is there hasn't been a report over a given time.

Splunk really helps you analyze logs and events to get a look at what's happening but you can also just watch the sockets on the Almond via a web browser to get an idea.

So how about a specific request from your end. What device would you like to poll and how often?  If I happen to have that device, I'll walk you through the process. I have CREE light bulbs which is an easy thing because you can set the DIM level without toggling the State of the device. I have about a dozen or so of other types of devices.

Now if you want to go low level and actually watch the ZWave or Zigbee comms, that's more of a challenge but doable. Much easier to do off the Almond actually on a separate device like a Pi w/ a compatible radio and I'd set something up on GitHub for the effort.

[SecureComp]

I'm thinking, based on the original topic of this thread, the primary concern is with the following types of devices;

Motion Detectors
Door/Window Sensors
Locks
Siren
Glass Break Sensor

The main issue with these devices is they are awake only during an event or during the standard wake up event that is programmed in the firmware and can be as much as 2 hours between wake ups.

But take a Door Sensor.
What about sending a Tamper FALSE message to the device as a virtual polling action.  Not so great because what if it was Tampered? Well if it was, it should have reported it immediately or you have other issues. So your polling could first check the last recorded Tamper State and then send a Tamper False state.  But does that message get sent to the device immediately or is it just queued and sent during the next comm initiated by the device itself either during the next event or the next wake up?

And of course there's the whole battery thing.

And it's not that simple.  I shouldn't have picked the door sensor as an example because it is a binary switch. But go ahead and give me a list of sensor and I'll see what I can come up with.

[rpr69]

I see where you are going. I don't have any requirements outside the ones stated previously, but you've given me some food for thought, thanks! Hopefully I;ll get some time to look at it soon. I think it will add some devilish logic to my bridge app, hopefully I don't get lost in it...

[d.kiran]

Think of it as "virtual" polling.
No you won't talk directly to the device but you can throw something at the device and get an expected response. The info will vary from device to device obviously.  Think of it as a PING ECHO RESPONSE REQUESTED kind of thing. Now what you throw at the device will matter.

For example, if you want the status of a Light that is On, you can't just check and see if the light is on as reported by the Almond. You would send a DIM adjustment level to lower it 1%, no real impact on your lighting situation, and you should see an INDEX of the MULTI LEVEL SWITCH transition from 255 to xxx. That confirms the communication from the Almond to the device and from the device back to the Almond.  So you have to actually ask a device to do something or do something to the device as the case may be.

That is a good idea. I was mainly asking because my linear switch doesn't report the status if I use the mechanical switch to turn it on. After a few days I have realized that it was not really a problem because my motion detector triggered action still works to turn on the light even if the status is incorrect. In some cases, its an extra button press on the app.

The only thing that is slightly more important is the battery status update on my Kwikset 910 door locks. They stay at 70% even if the locks keep beeping like crazy. Apparently there is a specific command to send that will update the battery status. I will see if I can look that up.

[SecureComp]

That is a good idea. I was mainly asking because my linear switch doesn't report the status if I use the mechanical switch to turn it on. After a few days I have realized that it was not really a problem because my motion detector triggered action still works to turn on the light even if the status is incorrect. In some cases, its an extra button press on the app.

The only thing that is slightly more important is the battery status update on my Kwikset 910 door locks. They stay at 70% even if the locks keep beeping like crazy. Apparently there is a specific command to send that will update the battery status. I will see if I can look that up.

How often are you having to replace the batteries?

I've not had this issue yet with the 2 locks I'm using. Now I need to go check battery levels.  Do post up the code if you track it down, this is something I would need to resolve.

[d.kiran]

On the 912 (used multiple times every day) every 2-3 months. On the 910 (used probably once per day) it's been 8 months since I installed and did not have to change the batteries.

I will try to find that.