Securifi Community Forum
Securifi Products => Almond+ => Topic started by: BrownChiLD on March 09, 2017, 01:39:08 am
-
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.
(http://i.imgur.com/wW5WvCY.jpg)
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
-
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.
-
@ 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"
-
@ 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:
(http://i.imgur.com/cgBt1yt.jpg)
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
-
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. :)
-
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 :
(http://i.imgur.com/7FvPCYj.jpg)
(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?
-
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.
-
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.
-
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.
-
@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?
-
@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.
-
@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.
-
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
-
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 :-)
-
@ 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.
-
@ 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.
Thanks ashok, thanks for the data. So for this one, Almond simply stays open to receive and report whatever and WHENEVER the sensor throws at it. So it's the sensors' that are at fault. Good to get this confirmed.
Now if Almond can have an option to at least flag sensors that have not reported back since x minutes..
like a config to set each sensor its own TTL. So that we can set TTLs for sensors that are supposed to be polling its data... also good to easily test/spot if sensors do conform to this key feature..
Ill run through my different sensors and test for polling... can you please confirm WEB SOCKET event is triggered when sensor polls Almond the SAME DATA? Or will it just trigger event on actual updates/changes? because i scanned through the docs and it seems all the update events are based on CHANGES. so same data coming in doesn't seem to trigger any events
Notification and Event Updates
https://wiki.securifi.com/index.php/Websockets_Documentation#Notification_and_Event_Updates
want to create an app that will profile all my sensors if they are polling-type.
-
@ BrownChiLD,
There are quite a few sleepy devices, which won't respond even though we try to query the request.
-
@ BrownChiLD,
There are quite a few sleepy devices, which won't respond even though we try to query the request.
I see. well i hope you guys can implement a sort of time/out TTL setting that can be user-defined
for example, for sensors that we know regularly pings every interval, say 60 seconds... we can set a TTL on it for 5 minutes.. so if almond doesn't get repeat/ping/communication from it beyond that, it will flag as offline / timed out
This will at least give us AWARENESS of the presence of sensor in the system and not blindly trust that all is well because the device is "listed" on almond UI.
Then we the users can then prefer sensors that does the "check in" stuff. I know i would and all my customers would as well.
Then for those sleepy devices that doesn't regularly ping/check in, and doesn't respond even if almond queries it, we can then set a different TTL , a much longer perhaps? at least user defined.
Anyway just a suggestion since reliability is really questionable at the moment, the way i see it. I hate how these sensor manufacturers didn't even consider this fact. imagine someone breaking into your home and your sensors aren't going off because they were dead or ran out of batteries weeks ago and you find out the hard way.
tsk
-
Securifi is pretty tight lipped (can't seem to find out what OS and Chipset the Almond 3 is on [...]
Fwiw... https://wikidevi.com/wiki/Securifi_Almond_3