simonw Posted March 1, 2010 Posted March 1, 2010 I want to install a centrally monitored alarm system. I am thinking about adding security to my ISY-driven Insteon system which is built around HA more than security, but I have a bunch of motion sensors and TriggerLincs. Option 1 would be to let ADT install one of their GE Simon XT systems and be done with it, but pricey monthly contract. Option 2 would be to try and add security features via the Elk M1 Gold. On Smarthome I don't see any decent wireless door/window sensors for the Elk. I have a bunch of the new TriggerLincs but I find it very disappointing they don't have battery status reports, let alone any supervision capabilities like "real" alarm system sensors. I like the idea of wireless alarm sensors with long battery life, low battery warning and system tamper alerts and supervision. Are such things available for the M1 Gold? What do you think? Thanks for your advice! Plus if you can recommend (or are) an Elk installer in the SF Bay Area I'd be glad to hear about that too. Simon
WayneW Posted March 1, 2010 Posted March 1, 2010 On Smarthome I don't see any decent wireless door/window sensors for the Elk. Elk supports a good variety of wireless sensors, either GE/Caddx or Honeywell, depending upon which wireless receiver you purchase. http://www.elkproducts.com/products/m1/Wireless.htm
brad77 Posted March 1, 2010 Posted March 1, 2010 To add to WayneW's post, see this post for some links pointing to some of the wireless sensors you can use with the GE Crystal interface. They don't have tamper warnings AFAIK, but I have been using the GE GENX458 sensors and most recently the iON micro sensors and have found both to work well. The iON's are particularly suited for installation into vinyl window frames and have a user-replaceable battery. I have been using the Elk M1 and have been very satisfied with it. The best part, IMO, is the fact that I can add sensors to my system as needed on my own. There's no need to have an installer come out to install them or update my system. That might not be your cup of tea, but it's a big reason for my decision to go with Elk.
apostolakisl Posted March 5, 2010 Posted March 5, 2010 Simon, The fact that you own an isy and are here on this forum means that you are not a "call ADT" person. The Elk is so much better than one of those "free" systems with the high monthly contracts. I have an Elk and ISY. My security system is all hardwired as I installed it when the house was under construction. I have browsed the wireless stuff by GE/Caddx and can't imagine that it wouldn't suit your needs. With my Elk, I don't have any monitoring at all. At $30 or $40/month, you can see it would only take about 2 years before you pay for a pretty kick *** Elk system with all kinds of home automation integration between it and your insteon stuff. I have the Elk setup to call and email me in the event of an alarm. From there I assess the situation and call police/fire if appropriate and reset the alarm from my iphone. I also have video setup so I can look in on the house and know what is going on. Since I always have my iphone with me this works out well.
simonw Posted March 6, 2010 Author Posted March 6, 2010 Thanks to all for the advice. I think I'm going to spring for the Elik M1G system and build a security system around that. I'll hardwire as many sensors as practical. Not so easy in my old house, but I'm not going to get the chance to do new construction! The Elk seems quite capable at HA all by itself. Does the ISY retain a role beyond integration with Insteon, passing on ELk commands to Insteon devices? The ISY is my favorite part of the setup and I'm not trying to bypass it. My house is about 1/3 done with Insteon. To do more I'm going to need to add neutrals or re-wire, not cheap. I guess I'll stick with Insteon but I'm open to suggestions if there is another product line that will work "better" with the Elk and ISY. The hard-wired Insteon stuff has been OK, but I find KPL buttons a hassle and the wireless devices flaky (like 2420M MS crapping out without ever giving a low battery warning) Thanks for your input! Simon
brad77 Posted March 6, 2010 Posted March 6, 2010 The Elk seems quite capable at HA all by itself. Does the ISY retain a role beyond integration with Insteon, passing on ELk commands to Insteon devices? The ISY is my favorite part of the setup and I'm not trying to bypass it. Actually it's the other way around. The Elk uses the ISY to turn devices on and off. You need to import a device file generated by your ISY into the Elk. The integration is snappy, and the ISY stays at the center of things, which is nice.
apostolakisl Posted March 11, 2010 Posted March 11, 2010 The UD folks keep promising better ISY/Elk integration. The ISY for the most part is easier to program and if it could just have the ability to monitor Elk zones and control Elk outputs that would make it damn near perfect. For now the way Elk and ISY communicate is via Insteon. Elk can monitor and control Insteon devices and ISY can do the same. Therefore you can let your insteon devices act as a go between. For example, you would like to write an ISY program that turns an Elk output on. You need to write a program to turn an Insteon device to some set value (like on or off), then write an Elk rule that states whenever said device turns on, then turn output such and such on.
ryarber Posted March 11, 2010 Posted March 11, 2010 Let me correct you a bit. The ELK and the ISY do not communicate via insteon, they communicate via ethernet. The ELK issues commands to the ISY to control devices and the ISY currently gives the ELK info on the status of all controllable devices and some others eg. motion sensors. One way you can communicate via lighting something that you want the ELK to do is to change the status of a device (eg. a switch or a KPL button). The ISY can't issue commands to the ELK like the ELK can to the ISY. So if you were doing a flow chart to show everything, you'd have the ELK hooking up to the ISY via a bidirectional arrow, then the ISY hooked up to the entire insteon network. My understanding of what is planned as far as ELK integration in the future is the ISY knowing the status of all the ELK's zones and outputs. It would also be very nice if the ISY could control other things on the ELK eg. texts and spoken messages and outputs. (many people who program the ELK, myself included, use output status as a variable in the ELK programming scheme). The ISY also knows the armed status of the ELK (eg. armed away, night, vacation, stay) and the ISY can arm/disarm the system via a web page. One thing that I thought would be easily implemented, but I may be wrong, is using the ELK armed status as a condition in programs in the ISY. I'm not a programmer so I don't know, but it seems that since the ISY already knows the armed status of the ELK, you would be able to add this as conditions for programs. I use some KPL buttons to control the ELK. I can write rules in the ELK system that if a button turns on, it will arm te ELK to night mode or away mode or vacation mode or stay mode. The ELK can be programmed just like the ISY can so it would have its own set of rules.
brad77 Posted March 11, 2010 Posted March 11, 2010 ryarber's right. The Elk doesn't talk directly with your INSTEON switches. In a typical setup (which I believe that mine is), the ISY is the only one with access to a PLM. The Elk asks the ISY to turn devices on and off on its behalf. The Elk is also aware of changes made to the status of any of the switches it monitors. What I do not know is whether this is via a polling mechanism from the Elk's side or if the ISY is updating the Elk with statuses as the events occur. Based on what I have learned so far, I would bet that it's the latter.
apostolakisl Posted March 11, 2010 Posted March 11, 2010 Yes, you are right, the Elk (when used with the M1XEP + ISY rather than the M1XSP) communicates indirectly with Insteon via its ethernet connection to ISY, but that is only a technical point with no real bearing on end-user operation and programming. The point is that ISY and Elk only talk to each other about Insteon stuff (plus a very limited alarm on/off control). The only way the two can relay info about other Elk stuff is to have Insteon products serve as "dummy switches" used simply to relay commands and status changes back and forth. This is cumbersome and requires the purchase of Insteon switches or KPL's dedicated to this purpose. It also requires writing a bunch of extra rules. It really would be nice to see the status of all alarm zones show up directly on ISY along with both status and control of outputs (and having these things be includable in programs). The other stuff Elk has like sending text to keypads and voice commands would be icing on the cake.
brad77 Posted March 11, 2010 Posted March 11, 2010 The point is that ISY and Elk only talk to each other about Insteon stuff (plus a very limited alarm on/off control). The only way the two can relay info about other Elk stuff is to have Insteon products serve as "dummy switches" used simply to relay commands and status changes back and forth. Fair enough. Sorry for missing your point. I can be a bit pedantic at times. It really would be nice to see the status of all alarm zones show up directly on ISY along with both status and control of outputs (and having these things be includable in programs). The other stuff Elk has like sending text to keypads and voice commands would be icing on the cake. Hear hear! +++, this.
IndyMike Posted March 11, 2010 Posted March 11, 2010 The point is that ISY and Elk only talk to each other about Insteon stuff (plus a very limited alarm on/off control). The only way the two can relay info about other Elk stuff is to have Insteon products serve as "dummy switches" used simply to relay commands and status changes back and forth. This is cumbersome and requires the purchase of Insteon switches or KPL's dedicated to this purpose. It also requires writing a bunch of extra rules. Per Michel you can also import X10 devices if you have the X10/A10 addon module. This would allow you to create true "dummy" X10 modules that were used for variables. At present, there does not appear to be a way to prevent the PLM from communicating the X10 code. In other words, using a X10 dummy module will cause X10 traffic on the powerline. Not the best if you have many events being communicated from the ELK, but it beats buying a $70 KPL to get 8 variables.
apostolakisl Posted March 12, 2010 Posted March 12, 2010 Indy mike, x10 would be a cheaper way to go for sure. You might also be able to use the fact that switchlincs can be set from 0 to 100% one percent at a time to get 101 trigger values. I haven't tried this but it seems like it would work for certain applications. I don't how the system would handle it if the value were changed by one program and then immediately changed to a new value by another program. I am guessing it would miss the first trigger.
ryarber Posted March 12, 2010 Posted March 12, 2010 The elk also has something called counters that I've used as variables as well. Counters are awesome because they can be set to something besides on or off, unlike the outputs. Outputs have their advantages because they can be put on a timer and I don't think the counters can. Either can be used as conditions in ELK rules so either will act as variables. Please add the awareness of ELK counters to the wish list for ELK integration.
simonw Posted March 13, 2010 Author Posted March 13, 2010 All you all - I've been learning from your posts, thank you - and I've ordered an Elk M1G. I really hope the Elk integration module will offer: 1) ability to have Elk notify ISY about Elk zone status changes (like motion triggers) 2) to read the Elk status and program accordingly in the ISY Michel, if you're listening, - is there a list of features that you intend to build in for the Elk module? Any commitments from the Elk folk so we can plan accordingly, either waiting or bailing I guess. Simon
ryarber Posted March 13, 2010 Posted March 13, 2010 Here is an incomplete list of features I'd like in the order I'd like them... I may add to it later 1. Programming conditions according to ELK's armed status 2. Knowledge of and ability to control ELK's outputs via programs (also serves as another source of variables) 3. ISY able to track and modify ELK counters as well as program with them (more variables, but instead of true/false variables, this one is integral, ie. having a value of 1,2,3,4, etc) 4. Ability to monitor ELK zones and use in programs. 5. Eventually, I'd like the ELK to have knowledge of ISY variables as well.
Michel Kohanim Posted March 14, 2010 Posted March 14, 2010 Hi ryarber, Thanks so very much for the feedback. I think most can be accomplished except access to ELK counters. The last time I checked, they are not specified in the interface. With kind regards, Michel
Recommended Posts
Archived
This topic is now archived and is closed to further replies.