Ademco Vista-128BPT

I just got an Ademco (Honeywell) Vista-128BPT (Turbo Series) for testing and tweaking the UI module before deploying it to the field and I noticed some flaws on the AMX documented feedback. Under the SECSTATUS-<status> there are 4 documented status:
ARMED
ARMED HOME
DISARMED
ALARM

The first 3 status work, but the ALARM one, which is extremely important doesn't. I armed the system to AWAY mode or fully armed and when I breach a zone, the alarm goes off but the AMX Comm module never sends out the ALARM or ALARMED status out. I've tried many times breaching different zones and still the same issue. Therefore, the feedback on touch panels never gets to show ALARM or ALARMED, it still has the ARM AWAY button lit, even though the alarm is going off.

Another issue is that I noticed is that the Zone Status is not reported correctly in the module when the system is armed to either AWAY or HOME. It does report correctly when the system is disarmed. Again, when the system is armed and a zone is breached, the alarm goes off, but the AMX module is not sending/processing the ALARM status, neither it is reporting which zone was breached. The way it is now, the module is not reliable. It basically provides arming and disarming, but the ALARM feedback and zone Status feedback is not reliable, especially when the system is alarming, when it should matter the most. The physical alarm keypad reports the breaches correctly.

Is there anything am missing here? The system is communicating correctly, but I am having these feedback issues. Have any of you noticed this limitation?

Thanks,

Ricardo

* Note: For those that want some type of individual zone feedback other than the simple text box, here is a function I edited from another alarm module to process it:

Comments

That's disappointing. I have a job in a couple weeks using that module so I can let you know what I find out. Security commands documents tend to be difficult or impossible to get, so this is not good to hear. Can you use the PASSBACK command to listen for the alarm command?
Paul

Yes. This Duet version is very limited. There is a big disconnect between the arm buttons and the keypad emulation. To arm the system the UI is using the built-in TP keypad and since the emulated keypad has no text feedback, you can't see what the system is doing when using the module emulated keypad numbers and keys.

ericmedley,

Is it possible for you to upload the old non-duet module for us. It is not available from AMX anymore. Maybe it works better... as most non-duet modules do.

Never mind. The old module uses 1200 baud rate and the Vista-128BPT panel requires 9600 baud rate. I actually found an old version of the non-duet module, but there is no way to change the baud rate to 9600. It is by default inside the Comm module 1200 and we don't have the .axs file for the Comm module, only the .tko.

Note that there are significant differences in talking to a 128BP/BPE and the newer BPT. Support at Honeywell will tell you they are the same. This is an outright lie.

They also will NOT divulge the protocols. When we dug in hard, they admitted they were different and only disclosed to trusted corporate partners. AMX is forbidden to give out the protocol to dealers, only to provide the "black box" module. Which is woefully inadequate and faulty.

They explain that this is to protect Honeywell from Chinese knock-off boards using a public protocol.

So unless you backward engineer it like the Chinese are doing anyway*, you aren't going to get the BPT to be satisfying.

Never mind. The old module uses 1200 baud rate and the Vista-128BPT panel requires 9600 baud rate. I actually found an old version of the non-duet module, but there is no way to change the baud rate to 9600. It is by default inside the Comm module 1200 and we don't have the .axs file for the Comm module, only the .tko.

Did you call TS? If you complain they might pass it to the Duet group and someone might fix it.
Paul

Yes. I did report it to tech support. There is another issue though in the UI module. The Arm, Arm Home and Disarm buttons rely on the built-in touch panel/iPad keypad to work, which is by default PORT 1. In my case, I can't use PORT 1 for the alarm, it is already used for IR devices. Usually I assign PORT 7 in my UI for alarm/security systems. In my case, the default UI won't work as I can't use PORT 1. Now, I have to redesign the UI to accept strings from PORT 7 instead of PORT 1, the default. My touch panel addresses are 10001:7:0, 10002:7:0, etc. I am sick of these duet modules that don't give us the tools to implement the module in the real World projects. In the past few years, I've found myself spending a lot of time trying to troubleshoot and rewrite Duet UI modules. The problem is that since we don't have access to the Comm modules (Black Boxes), we get really frustrated with Comm mudules that are not also doing what the support module documentation tells us that it should do. I miss the non-duet module days, where modules where better written and easier to implement.

I haven't done a virtual keypad in years. Does anybody have a code sample for this? I basically need numbers 1 to 9 and the OK button to process it. In addition, a text box to append the digits entered, so the end user can see what he is typing. The idea is that after typing the password and pressing OK or Done, the string gets sent to the UI module out of PORT 7.

I found a workaround for the virtual keypad. All my button channels are on PORT 7, but the text inputs are on PORT 1. I am basically passing both 10007 and 10001 to the UI module. PORT 7 handles everything: events and feedback. PORT 1 just the text input. It works fine, but we still have the issue with the Comm Module not reporting the Alarm state, nor the zones feedback when the system is alarming. I am trying to see if AMX can help... See my modified UI module code below. I've changed the channel mapping to fit other function, as well as added a text box and individual zone feedback. On the TP4 file I created my own keypad.

I kept digging into the Ademco settings and talked to an alarm expert with experience configuring the Ademco VISTA-128BPT and after additional settings, the ALARM feedback and zone breach now works. Apparently, since the 128BPT has a built-in serial port, some of the data fields differ a little from other panels. Also there is a need to enter Alt programming to set some other fields. Here is the settings I did:

To enter Programming: Installer Code + 8 + 0 + 0 + 0

Program *05: Enter 1 to view all zone faults/restores, enter 0 to view only events enabled in 1*79
Program *14: Enter 1 to set RS232 input at TB4 (Built-in Serial Port)
Program *79: Zone types restore reports for types 1-8 set to 1
Program *80: Zone types restore reports for types 9,10,16 and 14 set to 1

SETTINGS these last 3 made the difference
Program 1*78: Enter 1 for Extended Protocol Event reports, enter 0 for Simple
Program 1*79: To enable Event Log Types, enter 1 for each entry, 0 = disable
Program 1*80: When enabled automatically transfers zone fault/restore data of the RS232 output (TB4)

To program a field like 1*78 you need to enter the ALT PROGRAMMING by using #94 while in regular programming mode, then just enter *78 as regular programming. This was what hold me up until talking to an alarm expert.

I assumed you had the security settings correct prior to programming. Sounds like the module should work just fine then, which is a relief to me, since I have to integrate one here in a week or two. Most security systems do require a substantial amount of config to work with automation systems, since they aren't typically configured by default to do so, since there are security issues involved. Glad to hear the module will work ok.
Paul

Thanks for posting this useful info Ricardo! And I echo a_riot's gladness of the module working. Security integration always makes me a little itchy anyway and having a reliable comm module helps allay some of my fears.

I gave up on the AMX module and installed a cheap Cres... processor from EBay with their Ademco module running and then I pass strings back and forth to AMX via the Cres... processor using my own "protocol" Although it sounds like a lot of hassle, it took me 2 days vs 4 days and still getting no where using AMX alone. The end result was better than anything I was able to do using only the AMX module.