Choose style:

Author Topic: SECURITY FLAW in Sensors: Almond or all Gateways? Sensor issue?  (Read 7733 times)

0 Members and 1 Guest are viewing this topic.

Offline BrownChiLD

  • Chestnut
  • ***
  • Posts: 64
  • Thanks: 0
  • Registered : 12/08/2013
    YearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYears
i've been in HOME ALARM system business for many years using 433mhz signal and the biggest down fall of this system is 433mhz senors do not routinely communicate w/ the control panel to indicate their presence, and stratus.. they simply transmit signal when triggered (ie: door sensor opened/close) .. and when the trigger happens, you hope to God the Alarm CP is on and receiving signals properly, because if at that brief moment the  control panel is busy (frozen) it will miss that "one time" signal from the sensor and you got yourself a missed event.

Now, moving on to "SMART HOMES" with alarm systems, I would've expected things would be MORE RELIABLE than an analog 433mhz system

So i tried this on my A+..

Had 3 Door sensors "CLOSED" (different brands)

Rebooted A+
...during reboot i opened the door sensors..

After reboot and even waiting a bit longer, i was shocked to see all 3 sensors are showing "CLOSED" status and no alarms were triggered.



Even worst... I did another test..

All sensors in closed status..
I removed the batteries (simulating power/battery failure or sensor out of range)

The Router did not indicate any change , alert, or notice that sensors went missing..  in fact it maintained the "CLOSE" status throughout as if all are normal.

Now I am really questioning RELIABILITY of these smart systems for SECURITY purposes.

So is this flaw by design with smart homes? I thought the smart devices are constantly broadcasting their statuses and presence ..

Or is this A+ issue? How about other gateways? are they any better?

Am I the only one concerned about this?

ps
I am extra concerned because I just closed a contract with a client, I was supposed to setup for them a complete alarm system using Almond+ and few sensors..
now i dont think i can give it my stamp of approval .... tsk

Offline lmmmmm

  • Chestnut
  • ***
  • Posts: 72
  • Thanks: 0
  • Registered : 15/05/2014
    YearsYearsYearsYearsYearsYearsYearsYearsYearsYears
Re: SECURITY FLAW in Sensors: Almond or all Gateways? Sensor issue?
« Reply #1 on: March 09, 2017, 12:22:51 pm »
my experience is not all sensors play nice with A+.

I've had sensors that connect but then behave as you described. 

I try to stick with sensors that have been known to work.

The ones I have that work, work well and do what you are seeking.

Offline Ashok

  • Securifi Staff
  • *
  • Posts: 2770
  • Thanks: 3
  • Registered : 25/07/2014
    YearsYearsYearsYearsYearsYearsYearsYearsYearsYears
Re: SECURITY FLAW in Sensors: Almond or all Gateways? Sensor issue?
« Reply #2 on: March 09, 2017, 05:51:54 pm »
@ BrownChiLD,

There are situations, where even though we added full support for door sensors, depending upon the manufacturer request or the way they send the response, support needs to be added accordingly. However, please do send logs with the description "Logs for Ashok closed"

Offline BrownChiLD

  • Chestnut
  • ***
  • Posts: 64
  • Thanks: 0
  • Registered : 12/08/2013
    YearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYears
Re: SECURITY FLAW in Sensors: Almond or all Gateways? Sensor issue?
« Reply #3 on: March 10, 2017, 04:42:02 am »
@ BrownChiLD,

There are situations, where even though we added full support for door sensors, depending upon the manufacturer request or the way they send the response, support needs to be added accordingly. However, please do send logs with the description "Logs for Ashok closed"

So are you saying this door sensor is at fault, and the one firing once per trigger only?

i've tried 3 brands of door sensors already .. i have a schlage brand door sensor here too from amazon ill try that later and send you the logs.

i extracted the actual data from router via websockets ..
1. Sensor closed
2. reboot router
3. Open Sensor while rebooting

As expected, router shows sensor is still closed.

live JSON data of this particular sensor shows the following:


Notice:
"Value":"false" (door sensor is closed, wrong data, because sensor is open right now)
Last Epoch Time: 1489137070 (this shows the time prior to me rebooting the router. )


if the sensor is at fault, sending data to A+ based on TRIGGER only, can I make the A+ then proactively request data from Sensor?

also, side stepping a bit on the other issue I have where A+ is showing all sensors as "normal" when in fact some of the sensors are off or out of range already.. why can't A+ at least use time stamp to warn Users if a sensor has timed out or has not reported to the A+in a while ..

I'm a bit frustrated at the unreliability of the situation in both REAL-STATUS of Sensors and sensor time outs



my experience is not all sensors play nice with A+.

I've had sensors that connect but then behave as you described. 

I try to stick with sensors that have been known to work.

The ones I have that work, work well and do what you are seeking.


I'm actually happy to hear you confirm that there are sensors that work as SHOULD BE, reliable! Although I have used leading brands as well as chinese brand sensors on my A+ already. all seem to be the same issue :(

May i know what sensors you are using that behaves properly?

Regards

Offline spooky123

  • Backer
  • *
  • Posts: 129
  • Thanks: 0
  • Registered : 30/09/2014
    YearsYearsYearsYearsYearsYearsYearsYearsYearsYears
Re: SECURITY FLAW in Sensors: Almond or all Gateways? Sensor issue?
« Reply #4 on: March 10, 2017, 12:18:20 pm »
LONG POST ALERT!

My experience is the Almond is behind others, but its a problem with others too. I notice more problems with the Almond having correct sensor status than the same sensors on SmartThings and Vera. I suspect it is a sign of product maturity.

If you look for sensors that state instant status update then that helps. Almond does not poll for sensor status. SmartThings didn't either but there is a way to enable it and not sure if that is in the standard product now. I understand an issue is then sensor battery life potentially.

Securifi is pretty tight lipped (can't seem to find out what OS and Chipset the Almond 3 is on or if there is an upgrade future for the Almond+ platform) so some of this is speculation....

From personal experience, I have a mix of lamp modules. Some Almond gets status correct, some out of sync. The same modules have correct status on SmartThings always. I know some of the modules are specifically "Instant Status" and others not. Regardless, other HA hubs seems to accommodate that.

When Almond released support for the Linear Garage Opener, for me, it constantly timed out and had incorrect status. I don't believe Linear claims instant status. Almond fixed in firmware updates, but I believe Almond either enabled polling of it or it wasn't accpeting, understanding, or timing out on the status update. Securifi would have to answer that.

It's great the Securifi can and is willing to tweak this stuff in.

My personal opinion is similar to yours... the HA hub is the central piece and it must do what is needed to have correct status. Whether than is polling, interpreting incoming status messages, not dropping / timing out status messages, etc. The hub can't lose, drop, not process, not poll, etc and must be responsible and always have correct status. Some are better than others at delivering that, but none is this segement are problem free.

That said, there are a wide variety of sensors with varying quality of build themselves so I understand there is a general bigger issue there as well especially considering the different types... zwave, zigbee, insteon, etc.

I'd say if you are looking for mission critical, then you want to do a lot of homework on sensors and hubs and you might have to accept being locked in on brand, price, features, etc. 

For example, pretty old now, somewhat custom, and severly lacking in features and options at the time.... I used a Leviton system I got off of ebay a number of years ago. Status of Leviton branded and compatible (Vizia series???) was rock solid... availability of module types sucked, pricing high, features lacking, and remotes & controls very outdated.

My hope is that the Almond will continue to evolve. My opinion is that the ability to get it to a highly functional, flexible, and reliable platform and exceed where others are at today has not been fast coming and has been stagnant. I get that is a tall order with sensor variety, but ultimately I think that's what we all want from HA.

Overall, I like the Almond platform and want them to succeed. I like the community sharing and support but also would like to see an official publication of 100% functionally supported sensors; so as I chose devices I can either accept that it might involve Securifi tweaking, sending logs, etc vs work out of the box. Also, the ability to program my own sensors, polling, etc.. I don't really want to program my own sensors because I don't have the time, but vs having no recourse or waiting moon ages for firmware updates then if it were critically important to me, then I would. Other brands have a lot of user activity so in many cases it's just grabbing someone else's programming.

I have stuck with the Almond, but if I were doing it today, I would go a different path... primarily because I don't see the Almond+ has any intent of getting to a current, supported, chipset, OS, and deliver on the open platform. So at this point, my opinion is it is self-obsoleting and I'd not re-comit to that.

Just my two cents, after that long lenght... yes it bothers me too. :)

Offline BrownChiLD

  • Chestnut
  • ***
  • Posts: 64
  • Thanks: 0
  • Registered : 12/08/2013
    YearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYears
Re: SECURITY FLAW in Sensors: Almond or all Gateways? Sensor issue?
« Reply #5 on: March 10, 2017, 07:55:03 pm »
Ey spook!

Your long bunny post is appreciated actually. so thanks.. lemme return the favor :P

I have actually done a ton of research but i never looked into this particular issue because in my head, it's 2017, and by now this (sensor information integrity) is most certainly one of the most basic functionalities that should be baked into these products, specially ones that claim SECURITY! Someone must have thought of it right?

I've been in the security industry for over 10 years (from surveillance to alarm systems) and I was excited to start offering "SMART HUB" (Zwave/zgbee) based Security systems. I've been to sourcing exhibits China and HK :

(HK 2015)


so yes i did quite a lot of research into the industry and i discovered that:
1) 90% of Smart home stuffs coming out of China look great but are awesome hype but absolute crap
2) I've tested over 10 gateways/hubs from Chinese companies and they are all crap in my book. the app sucked and they (almost all!) base their logic in the cloud (require internet connection!!).. and everytime i challenge the manufacturers about this terrible dependency they keep defending their product w/ their all-hype no substance reasoning delivered via trademark broken english
3) Apart from the usual branded ones (aeon labs, GE, Schlage, etc) I've tested almost a hundred different sensors from different manufacturers in China and surprisingly only most were at lease decent, specially the small Z-wave plug (fibaro oem) that i have running all over my place now.

So these learning and tests brought me to the following business decision:
1) It is ok to purchase sensors/devices from a few China manufacturers.
2) it is NOT OK to purchase hubs from China manufacturers and we definitely want to stick with leading non-china makers for our system's logic.

This works out greatly for me too since for my market, it is more possible for me to purchase volume (MOQ) devices (required by manufacturers) rather than hubs.
So if i can acquire cheaper sensors that work with solid quality hubs = I am able to offer good quality at more affordable price.

Which brings me to now... excited to do business this 2017 and offer a smarter "MORE RELIABLE" HA and alarm system (coming from our current 433mhz line up) .... and Almond was my pick!
but at my very first project, shocked at this major, major flaw :(  - and im hoping im just missing something and it aint so :( 

I find it ridiculous how so many companies are rushing to hype their awesome HA stuff only to have the same underlying flaw that make these systems more of a toy for geeks rather than professional solutions  .. im specially disgusted at those marketing HA for SECURITY - because this is no better than much cheaper and scalable one-way 433mhz alarm systems  :(

#dismayed


Back to A+, i am still hopefully and glad they are responsive and very active in development. I actually hope this is an Almond flaw! Because if so im sure these guys will fix it, with enough pressure from us .. but if it is a sensor flaw (one-time firing based on trigger by design), then that is a bigger issue :( I dont think Almond can do anything about it.. Even if it tries to poll for info if devices do not respond then no dice.. But the least ALmond can do is show to user notices of inactive devices or at least flag time for outs..

hmmm.. ISN'T ZWAVE and ZIGBEE "two-way" communication devices by design?! I thought this would be by default in all z-wave and zigbee certified devices?



Offline spooky123

  • Backer
  • *
  • Posts: 129
  • Thanks: 0
  • Registered : 30/09/2014
    YearsYearsYearsYearsYearsYearsYearsYearsYearsYears
Re: SECURITY FLAW in Sensors: Almond or all Gateways? Sensor issue?
« Reply #6 on: March 11, 2017, 08:16:48 am »
hmmm.. ISN'T ZWAVE and ZIGBEE "two-way" communication devices by design?! I thought this would be by default in all z-wave and zigbee certified devices?

I agree, but both have flaws.... Zwave has been non-standardized though there has been a recent movement on standards and Zigbee can suffer from a distance from the hub issue.  Like you indicate, the sensors have a varying degree of quality of  operation as well. HA hubs have a tall order, I don't discount that.

Offline lmmmmm

  • Chestnut
  • ***
  • Posts: 72
  • Thanks: 0
  • Registered : 15/05/2014
    YearsYearsYearsYearsYearsYearsYearsYearsYearsYears
Re: SECURITY FLAW in Sensors: Almond or all Gateways? Sensor issue?
« Reply #7 on: March 13, 2017, 12:54:49 pm »
The sensors I use are by PEQ.  I havent really put too much effort into security. The motion sensors and door sensors trigger immediately and reset after about 5 seconds with A+ getting the notifications.

IMO, A+ is not the best for security as they only have Home/Away modes. They need an arm/disarm mode as well so you can get security device notifications only when mode is armed.

Offline fillibar

  • Backer
  • *
  • Posts: 2060
  • Thanks: 4
  • Registered : 02/08/2013
    YearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYears
Re: SECURITY FLAW in Sensors: Almond or all Gateways? Sensor issue?
« Reply #8 on: March 13, 2017, 06:21:19 pm »
Here is my $0.02 on this.
Yes, it is a problem (in my book) that there is not a configurable polling interval from the Almond (or preferably by device) however... Many of the devices I have do not provide any regular status. They only send something when they are triggered. If an Almond is not on (or rebooting) it has no idea it missed something. I am not sure I have seen any mention of polling a device in most of my device manuals. Although I suppose on those there could be workaround just to test if they are still alive (automatically change a known config value, then change it back) assuming the device confirms changes...

Is it Securifi's problem if Almonds do not have polling or some workaround? Yes. Although there are definitely device factors in there to be wary of.
Is it Securifi's problem if Almonds do not get a status when they are incapable of receiving it? No. Device problem (if it does not send regular status).
Is it Securifi's problem if a device does not send a status when you really think it should (ex: WD500Z do not status when turned on/off manually unless you double-press)? No. Device problem.
Almond 3 mesh handling the home.

Offline cswilly

  • Backer
  • *
  • Posts: 65
  • Thanks: 1
  • Registered : 02/08/2013
    YearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYears
Re: SECURITY FLAW in Sensors: Almond or all Gateways? Sensor issue?
« Reply #9 on: March 14, 2017, 09:30:40 am »
@Ashok can explain what Securifi know about various sensors they have tested.

From my experience, typically battery-powered wireless sensors cannot be polled. They are asleep saving battery power. The wake-up can be on a schedule or on an event (e.g. motion event). I do not see what Securifi can do about this. I would love battery-powered wireless sensors to report the status on a schedule (one an hour). But if they do not do this, we are done.

Does anybody know of battery-powered wireless sensors that do report status on a schedule? I would also think battery-powered wireless sensors should report the status of their batteries. Does anybody know of a sensor that does this?

Offline fillibar

  • Backer
  • *
  • Posts: 2060
  • Thanks: 4
  • Registered : 02/08/2013
    YearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYears
Re: SECURITY FLAW in Sensors: Almond or all Gateways? Sensor issue?
« Reply #10 on: March 14, 2017, 11:39:37 am »
@cswilly:
None of my battery operated sensors are reporting on a schedule. I do not know if any are capable of it (do not think so).
I do have multiple different sensors that report battery state. Some report a % value, and some just send a "low battery" state.

I know at least one of the ones I have is able to be polled. The Monoprice Multi-Sensor (#15902) mentions in it's manual that it can receive a command (MULTILEVEL REPORT) to provide the current temperature, light, and humidity and another command (BATTERY GET) for battery level. Nothing for motion but that should trigger a push anyways. This sensor also sends battery % and a low battery alert.
Almond 3 mesh handling the home.

Offline BrownChiLD

  • Chestnut
  • ***
  • Posts: 64
  • Thanks: 0
  • Registered : 12/08/2013
    YearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYears
Re: SECURITY FLAW in Sensors: Almond or all Gateways? Sensor issue?
« Reply #11 on: March 14, 2017, 11:45:52 am »
@ALL,
Well, certainly an interesting discussion ... So it's pretty clear, it's not Almond's problem alone (no polling/timeout mechanism) it is also smart device problem (acting like dumb blind firing 433mhz sensors)

Gosh this is terribly disappointing.  I started dabbling into z-wave and zigbee 3 years ago, and i was excited, but didnt feel it has matured enough for me to spend time on it. now it's 2017 and it matured in many "FLARE and FLASHY" stuff, but everyone seems to have forgotten the basics = RELIABILITY.

I can't believe no-one thought of circumventing the issues being discussed here.. 


@cswilly 
I do not mind losing 2 months battery life as long as system integrity is sold.. rather than boast over 1 year battery life, but cheat customers out of reliability.

I guess the SENSORS/DEVICES have to take the lead here.. they need to poll the always listening A+.. i think ALmond will simply receive it and update its own timestamp for the device..  this way also if A+ missed the trigger, next time it polls A+ will get the latest sensor status.

I am also interested to find sensors devices that polls , it's that or nothing. (at least for security stuff, door sensors, motion, smoke detectors, etc) . If you find some pls do share. Ill do the same.


Offline grouter

  • Beta Testers
  • *
  • Posts: 501
  • Thanks: 1
  • Registered : 01/01/2015
    YearsYearsYearsYearsYearsYearsYearsYearsYears
Re: SECURITY FLAW in Sensors: Almond or all Gateways? Sensor issue?
« Reply #12 on: March 14, 2017, 12:09:23 pm »
The Aeon Labs Multisensor6 is one that has a number of options for reporting status, with many of them (or all?) with settings able to be different based on whether the sensor is running on battery or USB power. There are thresholds to trigger reports, etc.

I've had limited success changing parameters on the A+ and no success on the A3 due to the A3's improper LCD GUI formatting on the parameters screen.

Here are some battery-related options.

9 (0x09) - Report the current power mode and the product state for battery power
mode.
Value1 (MSB): 0x00=USB power mode, 0x01=Battery power mode.
Value2 (LSB): 0x00= keep sleep state for Battery power mode, 0x01=keep
awake for 10 minutes for battery power mode.
Note: this parameter cannot be used as Set usage.

39 (0x27) - Configure low battery value.
Value=10 to 50. (10% to 50%), when the current battery level is lower than
this value, it will send out the low battery alarm

40 (0x28) - Enable/disable the selective reporting only when measurements reach a
certain threshold or percentage set in 41-44 below. This is used to reduce
network traffic. (0 = disable, 1 = enable)
Note: If USB power, the Sensor will check the threshold every 10 seconds. If
battery power, the Sensor will check the threshold when it is waken up.

44 (0x2C) - Threshold change in battery level to induce an automatic report.
Note:
1. The unit is %.
2. The default value is 10, which means that if the current battery level is
changed more than 10%, it will send out a battery report.

Here's a link to the current gen's guide:
https://s3.amazonaws.com/cdn.freshdesk.com/data/helpdesk/attachments/production/6028954764/original/9%20Multisensor%206%20V1.07%20-%20ES.pdf?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAJ2JSYZ7O3I4JO6DA%2F20170314%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date=20170314T154633Z&X-Amz-Expires=300&X-Amz-Signature=0d654583965c9dc54f5a6860e88e749881b9bd6f1756f41eb7e20da4942b7b93&X-Amz-SignedHeaders=Host&response-content-type=application%2Fpdf

And all of their guides:
https://aeotec.freshdesk.com/support/solutions/articles/6000088070-gen5

Offline cswilly

  • Backer
  • *
  • Posts: 65
  • Thanks: 1
  • Registered : 02/08/2013
    YearsYearsYearsYearsYearsYearsYearsYearsYearsYearsYears
Re: SECURITY FLAW in Sensors: Almond or all Gateways? Sensor issue?
« Reply #13 on: March 14, 2017, 12:57:11 pm »
The Aeon Labs Multisensor6 is one that has a number of options for reporting status,
...
https://aeotec.freshdesk.com/support/solutions/articles/6000088070-gen5

@grouter Thanks for the hints! I even have an Aeon Labs Multisensor6  so will have a look.

It would be nice if we could configure the parameters via the web interface or the app. The A+ screen is a pain; especially for me as my A+ is hidden in difficult-to-reach-but- gives-great-coverage point only accessible via a ladder :-)

Offline Ashok

  • Securifi Staff
  • *
  • Posts: 2770
  • Thanks: 3
  • Registered : 25/07/2014
    YearsYearsYearsYearsYearsYearsYearsYearsYearsYears
Re: SECURITY FLAW in Sensors: Almond or all Gateways? Sensor issue?
« Reply #14 on: March 16, 2017, 11:18:55 am »
@ BrownChiLD and cswilly,

We just ran a simple test again using Zigbee and Z-wave sensors and found that there are sensors, which send the query after 3 minutes (Securifi), 45 minutes (Climax) and 4 hours (Nyce). Hence, it mostly depends upon the sensor to update the status, once they rejoin the network after the controller has been rebooted or turned on.

 

Page created in 0.085 seconds with 16 queries.