Getting started ELK and HAI

You can configure the keypad LEDs off after inactivity, not sure if you mean something else. And it is a pretty good comparison you've compiled. Now you just need to make a decision on which features are more important to you, and you got your system.

I was referring to the ready/arm LED. When I contacted Elk they mentioned that all indicators will go off so ready/arm status is not visible. Unfortunately the prewire for the front door keypad is in plain sightly through the front door windows. With my current Ademco alarm I don't have a keypad there, which is a real pain. This alone might persuade my to go with the Elk.
 
So with ELK status light off it will appear that the system is disarmed, and this is somehow a good thing? Like others said before in this thread, I think the LED light is not that big of a deal. IMO it's better if it appears armed, and with automation you can write rules that will detect house occupancy and automatically arm the system, in day or night modes, in case you forget it.
 
Rsw686 - Just wondering, why are you so interested in Insteon? Have you already invested in it or did you pick this as your future lighting technology?

Also, I do like the Elk keypad options better than HAI, mainly due to the cost of the 5.7E but I also like the small Elk keypad that fits in a single-gang box.

David
 
I relate HAI to "Apple" and Elk to "Android". If you want to pick a bunch of single manufacturer boxes and get a system running with no thought or integration, then it's a HAI install. If you need to integrate more 3rd party products and can relate to how X, Y and Z inter-relate and communicate...Elk.
You had to go and screw that up for me... I'm an apply guy, not an Android guy - guess it's time to ditch the Elk and go HAI ;) (purely kidding)

- Omnistat2 thermostat support is missing occupancy settings and fan cycle mode
Don't hold me to this - I use RCS in this house, but I used HAI in the previous house and I swear I had access to the Fan mode. Occupancy I thought I could switch between home/away (never cared though - set it and forget it). I know with the RCS it's no bid deal - I access functions that aren't built-in by sending serial commands to the RCS - to set/clear messages, display outside temp as pulled from wunderground.com, etc.

Work2Play,

When using Elve with the Elk M1 the Elve software can control all features exposed by the Elk M1. Does it work in reverse where you can control lights in the Elve from the Elk? This would be similar to how the ISY994i works where you export the lighting list and import into the Elk.
I can't say I'm following you here. Elk can't talk to Elve really - but Elve sees everything that happens in the Elk. I mean, I can't write a rule in the Elk that says to trigger XXX action in Elve - but I can't imagine that being the case with ISY either. The Elk needs its own PIM AFAIK - it can't use Elve as one as it might be able to use an ISY as if it were one. That said, I can turn on an output with the Elk and have Elve respond to it if I want. In the case of lighting, I run 3 PIM's. 1 for Elk, 1 for Elve, 1 for RUC/Programming. Even though Elve can control the lighting through the Elk, it has some strengths in direct access. Important feature - Elk by itself doesn't track status after Scenes are activated; but Elve has functionality built-in to go poll devices after a scene they're in has been activated. Previously I figured there was no way to get Elve to trigger an update that Elk would see, but it seems from basic testing that Elve's requests for status updates are seen by the Elk as well. I know for a fact that tonight, I turned off all the downstairs lights via a Link and I see all the lights' correct status in eKeypad right now. And thinking about it, I think it's always pretty accurate except the link status, which is usually "on" since I never really turn off links the way I use them. This might require more testing, but if merely having Elve running in the background with a PIM solves the Elk status issue, then that seems like a huge win to me! I'll try to do a little more testing to confirm this.


So with ELK status light off it will appear that the system is disarmed, and this is somehow a good thing? Like others said before in this thread, I think the LED light is not that big of a deal. IMO it's better if it appears armed, and with automation you can write rules that will detect house occupancy and automatically arm the system, in day or night modes, in case you forget it.
The point here was that the Elk keypad can go dark so you don't know if it's armed or disarmed. Because of the poster's placement of the keypad, this is important - and it's one I strongly agree with. An intruder seeing an "Armed" status through the window is fine, I suppose - but seeing "Disarmed" is a huge problem!!!!! And if someone were casing your house, they might learn to recognize an "Armed" light even if there isn't a "Disarmed" - so it's best to just let them know you have an alarm and leave them with no idea when it's armed or not.
 
Rsw686 - Just wondering, why are you so interested in Insteon? Have you already invested in it or did you pick this as your future lighting technology?

No investment in it. I'm leaning towards UPB for the reliability and capability to convert a dimmer to a on/off switch. I do like the Insteon wireless keypad. Having a few of these on end tables would be a convenient way to control the rooms.
 
Don't hold me to this - I use RCS in this house, but I used HAI in the previous house and I swear I had access to the Fan mode. Occupancy I thought I could switch between home/away (never cared though - set it and forget it). I know with the RCS it's no bid deal - I access functions that aren't built-in by sending serial commands to the RCS - to set/clear messages, display outside temp as pulled from wunderground.com, etc.

Actually there is a new setting on the HAI Omnistat2 for fan cycle. The usual fan auto and fan on modes are there. The fan cycle mode allows the fan to come on for a period of time then off. I have always wanted this for spring and fall days where the heat / ac doesn't run much. I could always make rules in the controller to run the fan if the hvac hasn't run in x time.

The occupancy setting allows the thermostat to be linked to the HAI alarm state. You program temps for day, night, vacation in the thermostat it. You could always program these in the controller itself, but changing the temps can be done from the thermostat instead of the programming software.

I also think Elk is missing the ability to read humidity from the HAI thermostat. At least that is what I've read from some posts.

I can't say I'm following you here. Elk can't talk to Elve really - but Elve sees everything that happens in the Elk. I mean, I can't write a rule in the Elk that says to trigger XXX action in Elve - but I can't imagine that being the case with ISY either. The Elk needs its own PIM AFAIK - it can't use Elve as one as it might be able to use an ISY as if it were one. That said, I can turn on an output with the Elk and have Elve respond to it if I want. In the case of lighting, I run 3 PIM's. 1 for Elk, 1 for Elve, 1 for RUC/Programming. Even though Elve can control the lighting through the Elk, it has some strengths in direct access. Important feature - Elk by itself doesn't track status after Scenes are activated; but Elve has functionality built-in to go poll devices after a scene they're in has been activated. Previously I figured there was no way to get Elve to trigger an update that Elk would see, but it seems from basic testing that Elve's requests for status updates are seen by the Elk as well. I know for a fact that tonight, I turned off all the downstairs lights via a Link and I see all the lights' correct status in eKeypad right now. And thinking about it, I think it's always pretty accurate except the link status, which is usually "on" since I never really turn off links the way I use them. This might require more testing, but if merely having Elve running in the background with a PIM solves the Elk status issue, then that seems like a huge win to me! I'll try to do a little more testing to confirm this.

We are on the same page. That would be interesting if the Elk sees the status when the Elve polls. I was just looking for some capability from the Elk if I decided to get the Navigator touchscreen.
 
The other feature I haven't seen in either systems is the ability to have a zone activate for vacation only alarm mode. I have a motion in the downstairs room where my 55 and 85lb labs stay during the day. I don't trust the pet immune motion with them. I end up bypassing the zone sometimes when I arm away mode. Anybody know if the Elk and HAI should be able to bypass the zone automatically with rules in the controller based on the alarm arm state (away vs vacation)?
 
The other feature I haven't seen in either systems is the ability to have a zone activate for vacation only alarm mode. I have a motion in the downstairs room where my 55 and 85lb labs stay during the day. I don't trust the pet immune motion with them. I end up bypassing the zone sometimes when I arm away mode. Anybody know if the Elk and HAI should be able to bypass the zone automatically with rules in the controller based on the alarm arm state (away vs vacation)?

You can bypass a zone with programming rules in the HAI and those rules can be based on any arm state.
 
If you are planning for more than 48 zones the Elk is a much better value. Every 16 inputs over 48 costs over $200 for HAI and around $80 for Elk.

I keep hoping HAI will come up with a cheaper input only expander or 32 or 48 zone expander at the $200 price point but so far no luck.

I am almost considering an elk to monitor any zone that isn't tied to security and using Elve to bridge the two panels.
 
My Ademco system that came with the house has the 2K EOL resistors installed at the panel side. Basically the 2 wire cable goes panel -> sensor -> eol at panel side -> panel. From my understanding these are serving no purpose to supervise the circuits since they are not located at the sensor. If the wire is cut or shorted downstream the panel won't see the difference.

I know HAI requires 1K EOL resistors and Elk is 2.2K. The Elk is close enough it should just work. If I go HAI I would need to replace the resistors. Either way it sounds like I should just leave them off since they are installed at the panel. Or I should pull every contact and install the resistor there.
 
That's personal choice - I wouldn't bother in an existing system; I'd just ditch 'em.

rsw686 - I'll test this theory better today in a little while - I want to know if Elve's status updates are making it to the Elk - as it seems like the Elk is always pretty accurate these days.

Also for the thermostats - I know my RCS can be set somewhere to cycle on its own - I'm just now in the couple-week cycle in the fall where we don't really run the system at all so I was going to look at adding something to cycle the air every couple hours if the system hasn't run on its own. I'll either do it through the RCS directly or via the Elk with counters and an ever xxx minute rule to see how long it's been since the system has run.

Another thing I did - I used to always turn the fan on to cycle but forget about it and it'd run for days. Now I have a rule that triggers - whenever I manually trigger the Fan to ON, the Elk sees it and starts a timer and turns it off for me 20 minutes later.

Last - even un-supported features are generally accessible through direct serial commands. You'll never be able to read something back like humidity unfortunately, but you can always send serial commands; I know I could do this with my RCS if I cared - as it can have all the different setbacks and modes for each alarm state, and I could set the alarm state via custom strings. I've just never bothered because people are home pretty much 24/7... today I use a couple rules to heat/cool the part of the house we're typically in, but that's about it and I do it purely from the Elk. Same thing back when I had HAI T-Stats; I disabled programming and made them work purely via the M1. That said, the Omnistat2 is a very smart/advanced controller and if you use setbacks much, you'll probably see efficiency gains by using it instead of sending updates via any controller; when it knows what it's doing next, its predictive calculations work so it'll be the temperature you want at a set time rather than start working on it then.
 
Even though EOLs resistors are spec'ed to be at the "End-Of-the-Line" for obvious reasons, I strongly suggest that they always be installed even if they are placed at the panel.

Some day when I have the time (ha, ha), I will add the reason behind my position on this topic in a link in my signature. If I can figure out to do it, and if it is allowed.
 
Even though EOLs resistors are spec'ed to be at the "End-Of-the-Line" for obvious reasons, I strongly suggest that they always be installed even if they are placed at the panel.

Some day when I have the time (ha, ha), I will add the reason behind my position on this topic in a link in my signature. If I can figure out to do it, and if it is allowed.

Believe me, there is enough information (and opinions) on EOL resistors in this forum that one could write a book on the subject! :)
 
Back
Top