Questions regarding the Ademco Vista ICM plugin

[jwshome2]

Chris,

Installed the ICM (thanks for your earlier advice) and the plugin, and everything is communicating properly. I'm using an Ademco Vista 20P panel.

But I'm seeing two problems:

1. I don't think the plugin is keeping up with the flow of communications on the Ademco keypad bus. For example - if I open a door, the Ademco keypad instantly sees the fault, but the plugin does not seem to recognize it.
   
2. The parsing of the messages by the plugin doesn't always seem to be right - and I'm assuming this will affect the status or value of the devices, and therefore any scripts that are triggered by status or value changes.
   
   For example, I have a device called "West Entry Door". The vistaicm_messages.log file shows a command received as follows:

FAULT 10 WEST ENTRY DOOR

and then later, another message shows as:

FAULT 10 WEST Ready to Arm

Looks like what happened is that the plugin missed the "Entry door" text and incorrectly assumed that the "Ready to Arm" text was part of the device name. Or something like that.

I think the ICM is aware of this information as it happens - it seems there may be some breakdown of constant communicataions between the ICM and the plugin.

Any ideas?

[ChrisDunn]

Jon,

What you are seeing is an anomaly of the ICM. I noticed this when using a Sniffer on the network without the plug-in being involved. Here's the background.

The display on the web-based control for the ICM uses 2-lines (just as the display on an alpha-keypad uses). What the ICM does is to send out each line of the display as seperate messages. The ICM sometimes will change the messages right in the middle of what should be one contiguous displayed message.

So, in your example below, it would normally appear as the following two messages:

FAULT 10 WEST
ENTRY DOOR

and,

****DISARMED****
Ready to Arm

However, sometimes the ICM will mix the messages and you will end up with what you have below, which is:

FAULT 10 WEST
Ready to Arm

The plug-in accounts for this however and while it will try to rebuild the full message, it actually looks for keywords in the messages to let it know what has occurred.

The primary purpose of the plug-in was to keep the statuses in synch, so for that part, I think that everything should be fine (as in the panel and all zones should have the correct status). The log file however may show these anomalies, but they should only be cosmetic.

When I get my ICM back I can look at the messages again and see if there is a way to skip printing those out (by identifying that they are from different display statuses).

Regards,
Chris

[jwshome2]

Chris,

Thanks for the explanation. All I really care about is the statuses - or, more accurately, the change in statuses - to trigger specific events. So if the problem I identified does not affect the statuses then I wouldn't spend time "fixing" it.

But this raises another question: does the ICM, and the plugin, pick up very quick faults - e.g. a door opening and then closing? Would it make a difference to the answer to this question if the system were armed (in which case the door opening would presumably trigger an alarm, after some waiting period) or if it were not armed (say, if you wanted to ring a chime every time the door opened)?

The reason I'm asking this is that I am not seeing in the logs a whole lot of "fault" activity, despite the fact that I have lots of alarm motion sensors and door sensors on my Ademco system.

As always, thanks so much for helping to educate the rest of us ...

Jon S.

[jwshome2]

Chris, any thoughts on the question above, regarding "quick faults" - e.g. a door opening and then quickly closing? Does the plugin pick this up? If I were to create an event based on a status change of the door, would it work?

Thanks for your help...

[jwshome2]

Chris - I think I am seeing the plugin respond reasonably quickly to the same information seen by the panel, so I believe the "issue" is resolved.

Thanks.