We have worked with many different panels over the years, and the general findings vary greatly on functionality, particularly on the sector the alarm panel has been created/intended from (ie bank sector, large commercial, residential etc).? Our general go to panel in more recent years is the Elk, as Jay has mentioned though no real keypad access from Crestron.? I personally don't see this as a hurdle, as you can do most functions without it, and basically if a password is required that will need to be entered before hand. The communication protocol is available and quite extensive.? Just requires more effort to make a seamless system for the homeowner.
I am just in the middle of a job where the security company has changed the panel from a Concept to a Elk.? However the client still wants it to work the way the Concept worked ie multiple arming functions etc.? Part of the head hitting the wall to how people are resistant to change, requires delicate conversations and? preferably discussions upfront as to expectations on how it will work, and could be easier etc...We have managed to get it to work in the way they want, however utilised all the areas in the panels, and many rules, and function keys to achieve this.
There are a couple of caveats with the Elk though (and would love any input on this):
- if you had an alarm or something else, alarm will not respond correctly from the Crestron connection, need to enter the pin and hit disarm a couple of times before operating correctly from the Crestron again.
- i have had instability on TCP connections over the years, and have insisted on rs232 because of it.? This obviously hinders remote programming, 3rd party Elk apps etc. More recent firmware on the Elk has seemed to fix this.
- When programming ELK, Crestron is kicked out (using TCP) therefore need to do an update when it reconnects to TCP (should be a normal programming practice anyway)
- Biggest Issue i am facing is with 3 & 4 Series processors.? I have modified the original Crestron Application Market module code a bit (added in Threadsafe etc).? However the modules crash internally somehow, not sure if it is a crash or just some data getting missed etc.? you can still control the panel, ie arm disarm, control outputs, however all feedback stops working (ie status etc).? This is only happening on larger systems that i can see, and obviously a large amount of data coming into the processor is overwhelming it.? For the time being on the systems this has become a problem, I have utilised a 2 series processor (cp2e etc) to deal with all the data received from the alarm panel then sending the processed data on to the 3/4 series processor.? Any bench testing this issue in the office doesn't show the issue, and working through this with a client is incredibly difficult, as it will just stop working at any time, and the client doesn't realise.
Matt
